이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
분산 시스템에서 확장성과 낮은 지연을 함께 달성하려면 데이터 분산 방식, 복제 전략, 서비스 간 통신 구조 세 가지를 동시에 고려해야 합니다. 수평 확장을 위해 샤딩이나 파티셔닝으로 데이터를 분산하되, 복제 지연이 늘어나지 않도록 일관성 레벨을 요구사항에 맞게 설정하는 게 핵심입니다. 서비스 간 동기 호출이 많으면 한 노드 장애가 전체로 퍼지기 때문에 비동기 메시지 큐 방식으로 결합도를 낮추는 전략을 선호합니다. 캐시 레이어를 앞에 두면 읽기 지연은 크게 줄지만 캐시 무효화 정책이 일관성을 결정합니다. 앞으로도 확장성과 지연 요구사항을 분리해서 각각 설계하는 방식을 유지하겠습니다. 앞으로도 확장성과 지연 요구사항을 분리해서 각각 설계하는 방식을 유지하겠습니다.
노이지 네이버 문제는 설계 초기에 리소스 격리 전략이 없으면 트래픽 증가 시 반드시 나타납니다. 캐시 무효화 정책이 일관성 보장의 실질적 핵심입니다.
트래픽이 예상보다 빠르게 늘어나는 상황에서 확장 결정이 늦으면 장애가 먼저 옵니다. 팀 프로젝트에서 단일 서버 기반 API를 운영하다 부하 테스트에서 한계를 발견한 적이 있습니다. 먼저 읽기 요청을 분리해 레플리카로 라우팅하는 방식으로 병목을 줄였고, 이후 기능 단위로 서비스를 분리해 각 서비스가 독립적으로 배포·확장되는 구조로 전환했습니다. 이 과정에서 가장 어려웠던 건 서비스 간 의존성을 끊는 작업이었습니다.
동기 호출을 비동기로 바꾸면 확장은 쉬워지지만 장애 전파 경로가 달라지기 때문에 서킷 브레이커를 함께 설계해야 했습니다. 지연을 낮추기 위해 자주 조회되는 데이터는 캐시를 앞에 두되 TTL과 무효화 조건을 명확히 정의하는 방식을 썼습니다. 아키텍처 결정은 현재 병목이 어디 있는가를 먼저 측정하고 설계해야 방향이 틀리지 않습니다.
분산 시스템 설계에서 출발점으로 삼는 건 CAP 정리가 만드는 트레이드오프입니다. 일관성과 가용성을 동시에 완벽하게 보장할 수 없다는 전제 아래, 어떤 상황에서 일관성을 양보하고 가용성을 선택할 것인가를 먼저 정합니다. 주문 처리처럼 데이터 정합이 핵심인 경우엔 강한 일관성을 유지하고, 사용자 활동 로그나 추천 데이터처럼 짧은 불일치가 허용되는 경우엔 최종 일관성으로 설계합니다. 지연을 낮추기 위해서는 지리적으로 분산된 읽기 복제본을 두고 사용자와 가까운 노드에서 응답하게 하는 방식이 효과적입니다. 쓰기는 리더에 집중하되 비동기 복제 지연을 허용 범위 안에서 모니터링하는 구조를 선호합니다. 핵심은 아키텍처를 단일 패턴으로 통일하는 게 아니라 서비스 요구사항에 따라 일관성 레벨을 나눠 설계하는 것입니다. 모든 데이터를 같은 수준으로 다루면 불필요한 지연 비용이 쌓입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.