이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 여러 사용자가 동시에 좌석을 예약하는 기능을 만들다가 중복 예약이 발생하는 버그를 경험했습니다. 처음엔 애플리케이션 레벨에서 예약 전 빈 좌석 여부를 확인하는 로직을 넣었는데, 동시 요청 사이에 타이밍 차이가 생기면 두 트랜잭션이 모두 빈 것으로 판단하는 문제가 있었습니다. DB의 SELECT FOR UPDATE로 행 잠금을 걸고 트랜잭션 범위를 정확히 설정하니 문제가 사라졌습니다. 이 경험에서 정합성 문제는 대부분 잠금 범위와 트랜잭션 경계 설계 실수에서 온다는 걸 배웠고, 이후로는 동시성이 필요한 기능 설계 시 낙관적 잠금과 비관적 잠금 중 어느 쪽이 적합한지를 트래픽 패턴과 충돌 빈도를 기준으로 판단하게 됐습니다.
데이터 정합성 문제를 풀면서 낙관적 잠금을 처음 써봤는데, 버전 충돌이 나면 어떻게 처리해야 하는지 막막했습니다. 충돌이 발생했을 때 단순히 오류를 반환하면 사용자 경험이 나빠지는 결이 있었습니다. 시니어 개발자에게 조언을 구했더니, 충돌 빈도가 낮은 케이스에서는 자동 재시도 로직을 넣어도 되지만, 충돌이 잦은 케이스에서는 비관적 잠금이 더 적합하다고 설명해줬습니다.
재시도 횟수 제한과 지수 백오프를 함께 적용하는 방식을 제안받아 구현했습니다. 충돌 빈도에 따라 잠금 전략을 선택해야 한다는 것을 혼자 고민했으면 더 오래 걸렸을 결이었습니다. 이 경험에서 구현 전에 트래픽 패턴을 먼저 분석하는 결이 생겼습니다.
동시성 문제를 한 번 해결한 뒤 같은 유형의 설계 질문이 다른 기능에서 또 생겼습니다. 매번 같은 트레이드오프를 처음부터 설명하는 것이 비효율적이었습니다. 낙관적 잠금 vs 비관적 잠금 선택 기준을 팀 위키에 문서로 정리했습니다. 충돌 빈도가 낮고 읽기가 많으면 낙관적 잠금, 충돌 빈도가 높고 쓰기가 많으면 비관적 잠금이라는 기준을 예시와 함께 남겼습니다. 이후 유사한 설계 결정이 필요할 때 팀원이 문서를 먼저 참고하게 됐고, 설계 리뷰 시간이 줄었습니다. 한 번 풀 때 절차로 남겨야 팀 자산이 되는 결이 있다는 것을 이 경험에서 배웠습니다. 개인 문제 해결 능력과 팀 설계 역량을 높이는 것은 다른 결이라는 것도 함께 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 코빗 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.