이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
동시 사용자와 초당 처리량을 고려한 아키텍처를 처음 설계한 것은 사이드 프로젝트에서 이벤트 기간 트래픽 급증을 경험하면서였습니다. 평소와 다르게 동시 접속자가 갑자기 늘자 DB 커넥션 풀이 고갈되면서 오류가 났습니다. 비동기 처리와 연결 풀 설정을 조정해 단기적으로 해결했고, 이후 아키텍처를 재설계하는 계기가 됐습니다.
k6로 시나리오 기반 부하 테스트를 구성해 예상 최대 동시 접속자를 시뮬레이션했고, 어느 지점에서 응답 시간이 급격히 늘어나는지를 측정했습니다. 캐싱 레이어 추가와 읽기 전용 요청을 replica로 분산하는 방식을 적용하자, 같은 트래픽에서 DB 부하가 눈에 띄게 줄었습니다. 아키텍처 설계는 예상 트래픽을 먼저 수치로 정의하고 병목 지점을 테스트로 찾는 것이 결임을 배웠습니다.
이벤트성 트래픽 급증을 겪은 뒤 다음에는 순간 폭증을 처리 가능한 속도로 평탄화하는 구조가 필요하다고 생각했습니다. Kafka를 도입해서 사용자 요청을 큐에 쌓고, 컨슈머가 DB 처리 속도에 맞게 소비하는 구조로 바꿨습니다. 순간 1,000 TPS가 들어와도 실제 DB 쿼리는 200 TPS로 고르게 처리되는 것을 부하 테스트로 확인했고, DB 커넥션 고갈이 사라졌습니다. 다만 이 구조에서는 요청이 처리되는 시간이 즉시가 아니라 지연되기 때문에, 실시간 응답이 필요한 API와 큐 기반 처리가 가능한 API를 구분하는 설계 결정이 필요했습니다.
메시지 큐는 처리량을 늘리는 게 아니라 부하를 고르게 펴는 도구라는 인식을 가지고 쓰는 것이 중요했습니다.
트래픽이 늘면서 한 서비스의 응답이 느려지면 전체 API가 타임아웃 대기로 막히는 문제를 경험했습니다. p99 응답 시간이 갑자기 치솟아 3초를 넘었는데, 원인을 추적하니 외부 알림 서비스 호출이 느려지면서 스레드 풀이 가득 차는 상황이었습니다. Circuit Breaker 패턴을 적용해 오류율이 50%를 넘으면 해당 서비스 호출을 즉시 차단하고 빠른 실패(Fast Fail)를 반환하도록 바꿨습니다. 장애가 발생해도 알림 기능만 잠시 끊기고 핵심 API는 정상 응답을 유지하게 됐습니다. 이후 p99 응답 시간이 3,200ms에서 80ms로 돌아왔습니다.
아키텍처는 정상 경로뿐 아니라 장애 전파 경로를 먼저 설계해야 한다는 원칙을 이 경험으로 갖게 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 현대자동차 풀스택 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.