APP DEVELOPMENT TERM
동시성 제어
여러 요청이 겹쳐도 데이터의 규칙을 지키는 방법
동시성 제어는 여러 요청이 같은 데이터를 읽거나 바꿀 때, 처리 순서를 조정하거나 충돌을 확인해 서비스의 수량·상태 규칙이 깨지지 않도록 하는 방법입니다.
30초 이해
남은 한 자리에 두 사람이 함께 신청한다면
수업의 남은 자리는 1개인데 두 사람의 앱에 모두 ‘신청 가능’이 보입니다. 화면을 연 뒤 다른 사람이 신청할 수 있으므로, 화면에 보이는 자리가 곧 내게 확보된 자리는 아닙니다.
두 요청이 각각 ‘1자리 남음’을 읽고 둘 다 신청을 완료하면 정원을 넘길 수 있습니다. 서버와 데이터베이스는 변경 시점에도 신청 조건을 지키도록 처리해야 합니다. 이런 요청 간의 겹침을 다루는 개념이 동시성 제어입니다.
정확히 같은 순간에 버튼을 누르지 않아도 생길 수 있습니다. 한 요청이 읽고 저장하는 사이에 다른 요청이 들어와 처리 구간이 겹치는 경우도 포함합니다.
한 장으로 이해
요청은 두 개, 확정할 자리는 한 개
같은 자리의 조건 확인과 변경을 함께 보호합니다.
01 회원 앱
서로 다른 두 신청
신청자 A
수업 신청화면에는 1자리 남음신청자 B
수업 신청화면에는 1자리 남음화면에 보이는 자리만으로
확정을 보장할 수 없습니다.02 서버 · 데이터베이스
변경할 때 조건 지키기
같은 수업의 남은 자리
1→0자리가 남아 있을 때만 차감
조건 확인과 변경 사이의 충돌을 다루고, 신청 기록도 함께 확정합니다.
03 저장 결과 → 앱 안내
확정 1건 · 남은 자리 0개
한 요청
신청 완료확정된 신청 1건 저장다른 요청
마감 안내추가 확정하지 않음앱에는 서버가 확인한
처리 결과를 보여줍니다.
구현 방법은 조건에 따라
조건을 지키는 방법은 하나가 아닙니다
데이터베이스의 동작과 서비스 규칙에 맞춰 선택하며, 여러 방법을 함께 사용하기도 합니다.
조건부 변경
변경 명령에 수량·상태 조건을 넣고 실제로 바뀐 기록이 있는지 확인합니다. 이전 조회값만 믿고 저장하지 않습니다.
잠금
대상 기록을 확인하고 바꾸는 동안 충돌하는 변경을 기다리게 합니다. 잠금 범위·순서와 대기 시간을 함께 검토합니다.
충돌 확인
버전 번호처럼 변경 여부를 구분할 값을 확인합니다. 값이 달라졌다면 덮어쓰지 않고 최신 내용을 다시 읽어 재확인하거나, 정한 기준으로 작업을 재시도합니다.
단순한 수량 차감과 여러 기록에 걸친 조건은 다릅니다. 어느 방법이든 최종 저장 결과와 실패·충돌 처리를 함께 검수해야 합니다.
언제 사용하는 개념인가요?
예약·선착순 신청
남은 자리를 여러 사람이 함께 신청해도 확정 인원이 정원을 넘지 않아야 합니다.
재고·잔액 사용
서로 다른 주문이나 사용 요청이 겹칠 때 같은 재고·잔액을 중복으로 사용하지 않아야 합니다.
관리자의 동시 수정
두 관리자가 같은 기록을 수정할 때 먼저 저장된 내용을 뒤의 저장이 조용히 덮어쓰지 않도록 기준을 정합니다.
왜 중요한가요?
조회한 값과 변경할 때의 값을 구분합니다
조금 전에 읽은 수량·상태가 저장 순간에도 같다는 보장은 없습니다. 변경할 때 지켜야 하는 조건을 데이터 처리에 반영합니다.
허용할 결과를 먼저 정합니다
한 자리에 한 명만 확정할지, 대기를 받을지, 충돌 시 다시 확인할지 정합니다. 기술은 이 서비스 규칙을 지키기 위해 선택합니다.
앱 안내와 저장 결과를 맞춥니다
신청 버튼을 누른 것만으로 완료를 표시하지 않습니다. 서버가 확정한 결과에 따라 완료·마감·재확인을 안내합니다.
같은 한 자리로 비교하기
두 앱의 ‘1자리 남음’보다 저장할 때의 조건이 중요합니다
시작할 때 남은 자리는 1개입니다. 서로 다른 두 회원이 한 자리씩 신청하며, 두 요청은 정상적으로 처리되고 중간 취소는 없는 상황입니다.
변경 시점의 조건을 보호하면
- 한 요청이 남은 자리 조건을 충족해 신청을 저장하고 자리를 차감합니다.
- 다른 요청은 이미 자리가 없어졌음을 확인해 추가 확정을 하지 않습니다.
- 최종 결과는 확정 신청 1건·남은 자리 0개입니다. 앱에는 각각 완료와 마감을 안내합니다.
읽은 값만 믿고 따로 저장하면
- 두 요청이 모두 남은 자리 1개를 읽고 각각 신청 가능하다고 판단할 수 있습니다.
- 확인과 저장 사이의 겹침을 다루지 않으면 둘 다 신청을 확정할 수 있습니다.
- 수량이 음수가 되거나, 수량은 0인데 확정 신청이 2건 남는 등 구현에 따라 문제가 달라집니다.
남은 수량만 0인지 보지 말고 확정 신청 수도 함께 확인해야 합니다. A와 B 중 누가 확정될지는 고정하지 않습니다. 선착순의 정확한 우선순위가 필요하다면 그 기준도 별도로 설계해야 합니다.
자주 묻는 질문
“트랜잭션에 넣으면 동시성 문제도 모두 해결되나요?”
트랜잭션은 관련 변경을 함께 확정하거나 취소하는 단위입니다. 동시성 제어는 여러 작업이 겹칠 때 읽기·변경·충돌을 어떻게 다룰지에 관한 기준입니다. 함께 사용하며, 트랜잭션을 쓴다는 사실만으로 원하는 정원·상태 규칙이 보장되지는 않습니다.
“신청 버튼을 한 번만 누르게 하면 충분한가요?”
내 화면의 연속 클릭은 줄일 수 있지만 다른 회원·기기에서 오는 신청은 막지 못합니다. 같은 업무의 중복 요청을 구분하는 기준도 필요하며, 서로 다른 사람의 경쟁과는 나누어 처리합니다.
“잠금은 앱 전체를 멈추는 건가요?”
잠금의 대상과 범위에 따라 다릅니다. 특정 기록의 충돌하는 변경만 기다리게 할 수 있고, 모든 조회·변경을 한 줄로 처리할 필요는 없습니다. 기다리는 시간과 서로 기다리는 충돌도 검토해야 합니다.
“충돌하면 성공할 때까지 다시 보내면 되나요?”
자리가 소진된 마감과 일시적인 충돌은 다릅니다. 재시도할 오류·횟수·대기·종료 안내를 정하고, 필요한 경우 현재 데이터를 다시 읽어 전체 작업을 판단합니다. 이미 확정됐는지 모르는 요청이나 외부 결제·알림을 무작정 반복해서는 안 됩니다.
우리 서비스에 적용할 때 확인하세요
- 1동시에 바뀔 수 있는 수량·상태는 무엇이고, 절대로 허용하면 안 되는 결과는 무엇인가요?
- 2앱에서 본 값이 오래됐어도 서버와 데이터베이스의 변경 시점에 조건을 지키나요?
- 3서로 다른 두 요청을 겹쳐 보냈을 때 확정 건수·잔여 수량·각 화면 안내가 맞나요?
- 4마감·일시 충돌·같은 업무의 중복 요청을 구분하고, 재확인·재시도 기준을 정했나요?
공식 참고
서비스 기준은 공식 문서에서 다시 확인하세요
다음 자료
이해한 내용을 바로 적용해보세요
동시성 제어는 요청이 겹칠 때 지킬 규칙을 설명하는 용어입니다. 실제 앱·서버·데이터베이스의 처리는 동시 신청 가이드에서, 함께 저장할 범위는 트랜잭션 글에서 이어 볼 수 있습니다.
동시에 들어오면 곤란한 요청 하나를 골라보세요
‘한 자리에 확정 1건·잔여 0개·다른 요청은 마감’처럼 허용할 결과를 적으면, 개발팀과 구현·검수 기준을 구체적으로 맞출 수 있습니다.