이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
분산 시스템에서 잠금 문제를 접하면서 가장 먼저 이해한 것은 락을 무기한 들고 있으면 다른 노드 전체가 멈출 수 있다는 점이었습니다. 타임아웃을 제대로 설계하지 않으면 데드락보다 훨씬 조용한 장애가 발생할 수 있습니다.
팀 프로젝트에서 두 개 서비스가 공유 자원에 순서대로 접근해야 하는 구조를 구현했는데, 한 서비스가 락을 획득한 채로 응답이 느려지자 다른 서비스가 계속 대기하는 상황이 발생했습니다. 락 획득 후 일정 시간이 지나면 자동으로 해제되는 TTL 방식을 적용하고 나서야 대기가 해소되었습니다. 실패는 TTL을 너무 짧게 설정하여 정상 처리 중에도 락이 풀리는 경우가 발생한 것이었는데, 실제 처리 시간 분포를 측정하고 여유 있게 설정하였습니다.
잠금 설계는 획득보다 해제 조건이 더 중요합니다. 언제 어떻게 락이 풀릴지를 먼저 설계해야 장애를 막을 수 있습니다.
분산 시스템에서 타이머 관련 문제 중 처음에 이해하기 어려웠던 건 각 서버의 시계가 조금씩 다르게 간다는 것이었습니다. 로컬에서는 문제가 없는데 여러 노드에 배포하면 타이밍이 틀어지는 경우가 생겨요.
프로젝트에서 일정 시간마다 실행되는 작업을 여러 인스턴스에서 돌리는 구조를 만들었는데, 인스턴스마다 실행 시점이 몇 초씩 달라서 같은 작업이 중복 실행되는 문제가 생겼어요. 중앙 시각 서버를 기준으로 동기화하고, 작업 실행 전 중복 체크를 추가해서 해결했습니다. 실패는 처음에 중복 실행 가능성을 고려하지 않고 설계한 것이었어요.
분산 환경에서 타이머는 각 노드의 로컬 시계를 믿지 않는 것에서 시작합니다. 외부 기준점을 써야 일관성을 유지할 수 있어요.
분산 시스템에서 락 충돌이 발생했을 때 모든 노드가 동시에 재시도하면 오히려 충돌이 더 심해진다는 걸 경험했습니다. 재시도 자체를 잘 설계해야 했어요.
팀 프로젝트에서 여러 서비스가 동시에 같은 자원을 요청하는 시뮬레이션을 돌렸는데, 락 실패 후 즉시 재시도하도록 했더니 모든 서비스가 같은 시점에 재시도를 반복하면서 시스템 부하가 오히려 올라갔습니다. 재시도 간격을 랜덤하게 분산하는 지터와 점진적으로 늘리는 방식을 적용했더니 충돌이 줄었어요. 실패는 처음에 재시도 횟수 제한을 안 둬서 락을 못 얻는 요청이 계속 쌓인 것이었습니다.
재시도는 단순히 다시 시도하는 게 아니라, 언제 얼마나 기다렸다 시도할지를 함께 설계해야 효과가 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.