이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 한정 수량 판매 기능을 만들 때 동시성 문제를 처음 직접 겪었습니다. 동시에 여러 요청이 들어오면 재고가 음수가 되는 케이스가 테스트에서 재현됐고, 비관적 락(SELECT FOR UPDATE)으로 먼저 막았습니다. 트래픽이 낮을 때는 잘 동작했지만, 부하 테스트에서 락 경합으로 응답이 지연되는 문제가 생겼습니다. 낙관적 락으로 전환해 version 컬럼을 추가하고 충돌 시 재시도하는 방식으로 바꿨더니 처리량이 눈에 띄게 개선됐습니다. 다만 충돌이 잦은 상황에서는 재시도 비용이 비관적 락보다 높아질 수 있다는 걸 수치로 확인했고, 두 방식의 적합한 상황이 다르다는 걸 알았습니다.
동시성 전략은 요청 충돌 빈도를 먼저 따져야 한다는 원칙이 그때 생겼습니다.
트랜잭션·동시성 제어에서 트레이드오프를 의식하게 된 경험은 격리 수준을 높였을 때 데드락이 발생한 케이스였습니다. 데이터 정합성을 위해 격리 수준을 올렸는데 두 트랜잭션이 서로 상대방이 잠근 자원을 기다리는 상황이 테스트에서 발생했습니다.
격리 수준을 낮추면 팬텀 리드 가능성이 생기고, 높이면 데드락 위험이 올라간다는 것을 이해했습니다. 트랜잭션 설계는 정합성과 처리량 사이에서 업무 특성에 맞는 균형을 찾는 것이고, 격리 수준 하나의 선택도 트레이드오프를 동반한다는 결이 생겼습니다.
트랜잭션·동시성 제어에서 검증을 의식하게 된 경험은 동시성 버그는 단일 요청 테스트에서 재현이 안 된다는 걸 경험한 케이스였습니다. 코드 리뷰에서 경쟁 조건 가능성을 지적받았는데, 단일 요청으로 테스트할 때는 문제가 나타나지 않았습니다.
동시에 여러 요청을 보내는 부하 테스트를 만들고 나서야 실제로 재현됐습니다. 동시성 관련 로직은 단일 요청 테스트만으로는 검증이 부족하고, 동시 요청 시나리오를 별도로 설계해야 한다는 결이 남아 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 카카오페이 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.