이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 프로젝트에서 이벤트 기간 트래픽을 처리할 때 단일 서버로는 한계가 왔습니다. 먼저 수평 확장(Horizontal Scaling)을 적용하고 로드밸런서를 앞에 두는 구조로 변경했습니다. 그래도 DB 조회가 병목이 돼서 읽기 전용 레플리카를 분리하고 캐시 레이어를 추가했습니다. 안정성 측정은 응답 시간 P95와 에러율을 기준으로 봤고, 개선 후 피크 시간 에러율이 0.8%에서 0.05% 수준으로 낮아졌습니다. 트래픽이 몰릴 때 터지는 게 아니라 천천히 느려지다 안정화되는 구조를 만드는 게 목표였고, 그 방향으로 설계했습니다.
트래픽이 몰릴 때 터지는 게 아니라 느려지다 안정화되는 구조가 목표였습니다. 에러율보다 응답 시간 분포가 실제 사용자 경험에 가까운 지표라는 걸 그때 배웠습니다.
대용량 트래픽에서 단일 서비스 장애가 전체 시스템으로 번지는 것을 막는 설계가 안정성의 핵심이라고 생각합니다. 서킷 브레이커 패턴은 하위 서비스가 연속으로 실패할 때 호출 자체를 차단해서 장애가 연쇄되는 것을 막는 방식입니다. 팀 프로젝트에서 외부 API 의존도가 높은 서비스를 설계할 때, API 타임아웃을 명시적으로 설정하지 않았더니 응답 지연이 모든 요청을 블로킹하는 상황을 경험했습니다. 그 이후로 타임아웃과 재시도(retry with exponential backoff)를 기본으로 설정하는 것이 습관이 됐습니다.
일시적 장애는 재시도로, 반복 장애는 서킷 브레이커로 분리해 대응하는 구조가 필요합니다. 안정성은 장애를 막는 것이 아니라 장애가 퍼지지 않도록 격리하는 것입니다. 격리가 시스템을 지속 가능하게 합니다.
트래픽 안정성을 측정할 때 어느 수준이면 괜찮은가를 미리 정의하는 것이 중요하다고 생각합니다. 가용률이나 P99 레이턴시를 SLO(서비스 수준 목표)로 먼저 정해두면, 모니터링 지표와 알람 기준이 구체적으로 설정됩니다. 모니터링 수업에서 SLO 기반 알람 설계를 실습할 때, 임계값이 없으면 문제가 발생해도 언제 대응해야 하는지 기준이 없다는 것을 배웠습니다. 또한 피크 트래픽 전에 카오스 엔지니어링 방식으로 의도적으로 장애를 발생시켜 시스템 반응을 미리 확인하는 방법도 공부했습니다.
장애를 당해보기 전에 미리 경험해두는 것이 실제 상황에서 대응 속도를 높입니다. 안정성은 측정 가능한 목표가 있을 때 달성됩니다. 목표가 기준을 만들어줍니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.