동시 수정 시 충돌이 발생하는 이유와 해결법
동시 수정 충돌이 생기는 이유와 개발사에 요청할 저장·복구 흐름을 정리했어요.
안녕하세요. 사랑받는 IT 프로덕트의 첫걸음, 똑똑한개발자입니다.
오늘의 인사이트 요약
- 여러 담당자가 같은 정보를 고치면 뒤의 저장이 앞의 수정을 덮을 수 있습니다.
- 저장 전에 처음 불러온 버전과 현재 버전이 같은지 확인합니다.
- 충돌을 알린 뒤에도 작성 중인 내용과 다시 저장할 방법을 남깁니다.
관리자 화면에서 저장을 눌렀는데 동료가 바꿔둔 내용이 사라진다면, 어디서 잘못됐는지 찾는 데 시간이 듭니다. 입력도 했고 성공 메시지도 봤는데 서로 다른 내용을 기억하니 단순한 조작 실수로 판단하기도 어렵죠. 한 사람이 시험할 때는 보이지 않다가 여러 담당자가 함께 쓰면서 드러나는 문제입니다.
개발 시, 같은 정보를 여러 사람이 동시에 열어본다면 저장 기능에 충돌 처리까지 포함해야 하는데요. 오늘은 동시 수정 충돌이 생기는 이유와 개발사에 요청할 저장·복구 흐름을 정리해보았습니다.
1. 같은 정보를 함께 여는 곳을 찾아야 합니다.
동시 수정 충돌은 두 사람이 같은 순간에 저장할 때만 생기지 않습니다. 한 사람이 화면을 연 뒤 다른 사람이 먼저 수정했고, 뒤늦게 첫 사람이 오래된 화면을 저장해도 문제가 생길 수 있습니다. 자신의 눈앞에는 최신처럼 보여도 서버에 보관된 정보는 이미 바뀌었을 수 있기 때문입니다.
가상의 고객 관리 화면을 예로 들겠습니다.
담당자 A와 B가 같은 고객 정보를 열고, A는 연락처를 바꿔 저장합니다. 그 뒤 B가 담당 부서를 바꾸면서 화면 전체 값을 저장하면, B의 화면에 남아 있던 예전 연락처가 함께 전송될 수 있습니다. 시스템이 이를 그대로 반영하면 A가 수정한 연락처는 다시 예전 값이 됩니다.
연락처와 부서처럼 서로 다른 항목을 고쳤더라도 저장 방식에 따라 영향을 줄 수 있는데요. 수정한 항목만 보내면 이 예시의 덮어쓰기를 줄일 수 있지만, 같은 항목을 고치거나 항목끼리 조건이 연결된 경우까지 해결하는 것은 아닙니다. 화면의 입력 칸 수보다 어떤 정보가 함께 저장되는지부터 확인하는 편이 좋습니다.
똑똑한개발자팀은 여러 사람이 함께 사용하는 관리 화면이라면 동시 수정을 기본 검수 조건에 넣는 것이 좋다고 봅니다. 기획 단계에서 고객 정보, 일정, 작업 배정처럼 공동으로 다루는 대상을 표시해두면 출시 직전에 저장 방식을 급히 바꿀 부담을 줄일 수 있습니다.
2. 저장 전에 현재 버전을 확인해야 합니다.
뒤의 저장을 무조건 받아들이지 않으려면 사용자가 처음 읽은 버전과 현재 서버의 버전을 비교하는 방법을 검토할 수 있습니다.
두 버전이 같으면 저장하고, 중간에 바뀌었다면 저장을 멈춰 충돌을 알리는 방식입니다. 저장하면서 다른 사람의 수정 여부를 함께 검사해야 비교 직후에 바뀐 내용도 놓치지 않습니다.
웹에서는 ETag와 If-Match를 이용해 조건부 요청을 구현할 수 있습니다. ETag는 자원의 버전을 구별하는 표식이고, If-Match는 그 표식이 일치할 때만 요청을 처리하도록 전달하는 조건입니다. 조건이 맞지 않으면 서버는 412 Precondition Failed 응답을 보냅니다. 적용하려면 서버가 버전 비교와 저장 조건을 지원하도록 구현해야 합니다.
이처럼 이전에 읽은 자원을 기준으로 저장을 제한하는 방법은 MDN의 If-Match 안내에서 요청 예시와 함께 더 자세히 보실 수 있습니다. 기획자가 헤더 문법까지 정할 필요는 없지만, 이미 바뀐 정보를 덮어쓰지 않도록 어떤 조건을 검사하는지는 개발사와 합의하는 편이 좋습니다.
업무에 따라 한 사람이 편집하는 동안 다른 사람은 읽기만 하도록 제한할 수도 있습니다.
이 방식을 택하면 편집자가 창을 닫거나 연결이 끊겼을 때 제한을 어떻게 풀지도 정합니다. 어느 방식이든 화면에 다른 담당자의 접속 표시만 붙이는 것으로 저장 충돌 처리가 완성되지는 않습니다.
3. 충돌 뒤에도 작성 내용을 남겨야 합니다.
충돌을 감지했더라도 입력한 내용을 모두 지우고 새로고침하게 만들면 사용자는 같은 일을 다시 해야 합니다. 현재 저장된 값과 자신이 입력한 값을 비교할 수 있게 하고, 다시 입력하거나 복사할 내용을 남겨두는 편이 좋습니다. 저장되지 않은 초안과 실제 반영된 정보를 분명히 구분하는 안내도 필요합니다.
똑똑한개발자팀은 충돌 안내의 목적이 재시도를 요구하는 데서 끝나지 않아야 한다고 생각합니다.
무엇이 바뀌었고 어떤 내용을 다시 선택해야 하는지 알 수 있어야 업무를 이어갈 수 있기 때문입니다 사용자가 다른 담당자의 변경을 확인하기 전에 같은 저장 요청을 자동으로 반복하면 충돌 원인을 해결하지 못합니다.
또한 서로 다른 항목은 자동으로 합칠 수 있는지 검토하되, 이름이 다른 칸이라는 이유만으로 합치지는 않습니다.
가령 가상의 예약 업무에서 한 사람이 날짜를, 다른 사람이 이용 공간을 바꿨다면 두 값의 조합이 예약 가능한지 다시 확인해야 합니다. 항목 사이의 업무 조건까지 맞을 때 병합하도록 범위를 정합니다.
검수에는 화면을 나란히 열고 순서대로 저장하는 과정이 포함됩니다. 두 담당자가 같은 항목을 수정하는 경우, 서로 다른 항목을 바꾸는 경우, 오래 열린 화면에서 저장하는 경우를 확인합니다. 충돌 후 비교 화면에서 내용을 고르는 사이에 다른 변경이 생겨도 다시 검사하는지 살펴봐야 합니다.
저장이 막혔다는 안내뿐 아니라 마지막에 어떤 값이 남았는지도 확인합니다.
새로 조회한 화면에 선택한 값이 보이고, 이전에 입력한 초안은 더 이상 최신 정보처럼 표시되지 않아야 검수를 마칠 수 있습니다. 충돌 해결 후의 결과도 검수 항목에 넣으면 개발사와 완료 여부를 판단하기 쉬워집니다.
저장 기능은 버튼 하나로 보이지만 실제로는 여러 담당자의 업무가 만나는 곳입니다.
기획할 때 공동 편집 대상, 충돌 판단 조건, 비교 화면, 저장 후 결과를 함께 정하면 개발 범위도 구체적으로 논의할 수 있습니다. 모든 화면에 같은 장치를 붙이기보다 정보가 사라졌을 때의 영향과 동시 사용 여부를 보고 적용 대상을 고릅니다.
똑똑한개발자는 웹·앱부터 관리자 시스템과 SaaS까지 프로덕트를 기획·디자인·개발·운영해온 경험을 바탕으로 업무와 화면을 함께 설계합니다. 아래 소개서 이미지는 자체 서비스의 운영 화면을 담은 자료이며, 본문의 가상 고객 관리 사례나 동시 수정 방지 성과를 뜻하지는 않습니다.
여러 담당자가 함께 쓰는 관리자 화면의 저장 흐름을 점검하고 싶다면 아래 똑똑한개발자 링크로 문의해 주세요. 감사합니다. :)
제미나이, GPT, 클로드를 활용해 AI Agent 탑재 및 AX 전환의 전문성을 갖춘 IT 프로덕트 에이전시.
https://www.toktokhan.dev/?utm_source=landing&utm_medium=Conflict&utm_campaign=Conflict&utm_term=개발충돌발생