이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 실시간 알림 서비스를 구현하면서 트래픽 처리 구조를 설계했습니다. 동시 요청이 몰릴 때 응답 지연이 급격히 늘어나는 문제가 있었고, Redis 기반 메시지 큐를 도입해 비동기 처리 구조로 바꿨습니다. 또한 DB 조회 빈도가 높은 데이터에 캐싱을 적용하면서 응답 시간이 개선됐습니다. 완전한 대규모 환경은 아니었지만, 병목이 어디서 발생하는지를 측정하고 구조를 바꾸는 흐름 자체를 경험한 게 의미 있었습니다. 실서비스 수준의 트래픽은 아직 다뤄보지 못했지만, 이 경험에서 배운 원칙을 실무에서 더 발전시키고 싶습니다.
병목을 측정하고 구조를 바꾸는 경험 자체가 실무에서 쓸 수 있는 가장 가치 있는 배움이라고 생각하고, 대규모 환경에서도 이 원칙은 그대로 적용된다고 봅니다.
저지연 서비스 구축에서 WebSocket 연결이 늘어날수록 메모리 사용량이 선형 증가하는 문제를 경험했습니다. 초기에는 연결 객체를 서버 메모리에 직접 저장했는데, 동시 접속자가 수백 명을 넘어가면서 메모리 부족이 발생했습니다. 연결 상태를 Redis에 분산해서 관리하고, 서버는 무상태(stateless)로 만드는 방식으로 전환했더니 수평 확장이 가능해졌습니다. 단일 서버에서 상태를 관리하는 구조는 확장 시 항상 병목이 됩니다.
상태를 외부로 분리하는 것이 확장성의 핵심입니다. 무상태 서버가 수평 확장을 가능하게 합니다. Redis가 분산 상태 관리를 담당합니다. 상태 분리가 확장성의 출발점입니다.
대규모 트래픽 처리 프로젝트에서 가장 먼저 막힌 것이 DB 커넥션 풀 고갈이었습니다. 요청이 몰릴 때 쿼리가 대기하면서 응답 시간이 급격히 늘어났고, 일부 요청은 타임아웃이 발생했습니다. 커넥션 풀 크기를 늘리는 것보다 읽기 트래픽을 캐시로 흡수하는 것이 더 효과적이었습니다. 자주 조회되는 데이터를 Redis에 캐싱했더니 DB로 가는 요청이 60% 이상 줄었고, 커넥션 풀 고갈 문제가 사라졌습니다. 트래픽 증가 시 DB가 아닌 캐시 레이어에서 대부분의 읽기를 처리하는 구조가 핵심이었습니다.
캐시가 DB 커넥션 압박을 줄입니다. 읽기 트래픽을 캐시로 흡수하는 것이 먼저입니다. 커넥션 풀보다 캐시 설계가 중요합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 당근마켓 ML 인프라 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.