이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
마이크로서비스 환경에서 대규모 트래픽을 처리하는 설계는 직접 경험보다 수업과 개인 프로젝트에서 배운 방식을 중심으로 말씀드리겠습니다.
가장 중점을 두어야 하는 부분은 서비스 간 통신 설계라고 생각합니다. 동기 REST API만 쓰면 하나의 서비스 지연이 전체 응답 지연으로 번지기 때문에, 비동기 메시지 큐(`Kafka`·`RabbitMQ`)를 통해 느슨하게 연결하는 구조가 트래픽 급증에 더 유연하게 대응합니다. 또한 서비스별로 독립적인 데이터 저장소를 갖추면, 트래픽이 집중되는 서비스만 수평 확장할 수 있습니다.
개인 프로젝트에서 Docker Compose로 세 개 서비스를 올리고 Nginx로 로드 밸런싱을 실험했을 때, 하나의 서비스 컨테이너 수를 늘리는 것만으로 처리량이 개선되는 구조를 직접 확인했습니다. 이 경험에서 확장 전략을 설계 초반에 고려하는 것이 중요하다는 것을 배웠습니다.
실제 서비스에서 일일 수백만 건 API 요청을 처리하는 구조를 운영한 경험이 있습니다. 가장 먼저 중점을 둔 건 서비스 간 장애 전파를 막는 것이었습니다. 하나의 서비스가 느려지면 동기 호출 체인 전체가 타임아웃으로 번지는 문제가 반복됐고, 이를 해결하기 위해 서킷 브레이커 패턴을 도입했습니다. 장애가 감지되면 요청을 즉시 차단하고 폴백 응답을 반환하는 방식으로 전환한 뒤 전체 안정성이 크게 개선됐습니다. 또한 분산 추적 도구를 연결해 서비스 간 지연이 어느 지점에서 발생하는지 가시화했고, 이를 통해 병목 지점을 정확하게 파악할 수 있었습니다. 트래픽이 급증할 때는 오토스케일링 임계값 조정이 핵심이었는데, 임계값을 너무 높게 잡으면 스케일 아웃이 늦어져 장애로 이어진다는 것을 실제로 경험했습니다. 대규모 트래픽 환경에서 스케일링보다 장애 격리 설계가 먼저라는 것을 운영하면서 체득했습니다.
마이크로서비스 환경에서 대규모 트래픽에 가장 먼저 반응하는 건 데이터베이스였습니다. 서비스 수가 늘어날수록 각 서비스가 동일한 데이터를 반복 조회하는 패턴이 생겼고, 이를 분산 캐시 레이어로 분리하는 것이 우선이었습니다. Redis를 서비스 앞단에 배치해 자주 바뀌지 않는 데이터를 캐싱하면서 DB 부하가 눈에 띄게 줄었습니다. 또한 쓰기 요청이 몰리는 구간에는 이벤트 큐를 통해 쓰기를 비동기로 분산하는 방식을 적용했고, 소비자 속도를 독립적으로 조절할 수 있어 급증 트래픽에 유연했습니다. 다만 캐시 정합성 문제가 생겼을 때 어떤 기준으로 무효화할 것인지를 사전에 설계해두지 않으면 데이터 불일치가 발생한다는 것도 경험했습니다.
설계 시점에서 무효화 전략을 결정하는 것이 캐시 도입의 핵심이었고, 이 원칙이 이후 모든 캐시 구조에 기준이 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.