이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 동시 접속자가 갑자기 늘어나는 상황을 가정해 트래픽 분산 아키텍처를 설계해본 경험이 있습니다. 단일 서버 구조에서 시작해 부하가 집중되는 지점을 시뮬레이션으로 찾아보니, DB 쿼리 레이어가 가장 먼저 병목이 됐습니다. Redis를 캐시 레이어로 추가해 조회 빈도가 높은 데이터를 메모리에 올리자 응답 시간이 절반 이하로 줄었습니다. 그 다음에는 로드 밸런서를 앞에 두고 애플리케이션 서버를 수평 확장했는데, 이 과정에서 세션 공유 문제를 Redis로 통합해 해결했습니다. 실무 수준의 대용량 트래픽 처리는 아직 경험이 없지만, 병목 지점을 데이터로 찾고 순서대로 제거하는 접근 방식이 유효하다는 것을 이 실험에서 확인했습니다. 아키텍처 설계는 확장보다 병목 발견이 먼저라는 결을 얻었습니다.
대용량 트래픽 아키텍처에서 본인 사례로 닫힌 경험은 로드밸런서 도입 후 부하 테스트를 실행한 케이스였습니다. 단일 서버에서 로드밸런서를 통한 다중 서버 구조로 바꾼 뒤, 실제로 트래픽 분산이 이루어지는지를 부하 테스트 도구로 확인했습니다.
서버 한 대에 요청이 몰리지 않고 여러 서버에 나누어지는 것을 로그로 확인했습니다. 아키텍처 설계는 구조를 정하는 것만큼 실제로 의도한 대로 동작하는지를 확인하는 것이 완성이라는 결이 생겼습니다.
대용량 트래픽 아키텍처에서 측정 가능한 결과로 닫힌 경험은 부하 테스트에서 병목이 예상과 달랐던 케이스였습니다. 로드밸런서와 서버 확장으로 처리량이 늘 것이라고 예상했는데, 부하 테스트에서 데이터베이스 연결이 병목이라는 것을 발견했습니다.
서버를 늘려도 DB 연결이 한계에 달하면 전체 처리량이 늘지 않는다는 걸 이해했습니다. 트래픽 처리 아키텍처에서 한 계층을 개선해도 다른 계층이 병목이면 전체 성능이 개선되지 않는다는 결이 남아 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 HL그룹 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.