이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 주문-재고-알림 서비스를 Kafka로 연결하는 이벤트 기반 아키텍처를 처음 설계했습니다. 처음에는 서비스 간 직접 API 호출로 설계했는데, 재고 서비스가 잠깐 내려가면 주문 처리 전체가 막히는 문제가 생겼습니다. Kafka를 도입해 비동기 이벤트 큐로 처리하자 재고 서비스가 복구됐을 때 밀린 이벤트를 순서대로 소비하는 구조가 됐습니다. 다만 컨슈머 그룹 오프셋 관리를 처음에 잘못 설정해 재시작 후 이벤트가 중복 처리되는 버그를 만났고, 오프셋 커밋 전략을 명시적으로 설정하는 방법을 학습해 해결했습니다. 이벤트 기반 아키텍처는 서비스 간 결합도를 낮추는 대신 순서 보장과 중복 처리를 직접 관리해야 한다는 트레이드오프를 실감했습니다.
인턴 기간에 Kafka 기반 이벤트 처리 서비스에서 Consumer Lag이 갑자기 급증하는 상황을 마주했습니다. 처음에는 네트워크 문제인 줄 알고 서버를 재시작했는데, 재시작 후에도 Lag이 줄지 않았습니다. 직접 컨슈머 그룹 상태를 확인해보니 특정 파티션에 메시지가 몰려 있었고, 그 파티션 담당 컨슈머 하나가 처리 시간이 유독 길었습니다. 원인은 특정 사용자 ID의 이벤트가 한 파티션에 집중되는 핫 파티션 문제였습니다. 저는 파티셔닝 키를 사용자 ID에서 이벤트 타입과 시간대 조합으로 바꾸는 방향을 제안했고, 적용 후 Lag이 안정적으로 유지됐습니다. 처음에는 Lag 모니터링 수치만 보다가, 실제 파티션 분포까지 확인하는 방법을 그때 배웠습니다. 지금도 Kafka 문제를 만나면 파티션 분포를 먼저 펼쳐보는 습관이 남아 있습니다.
학부 프로젝트에서 RabbitMQ를 처음 쓸 때, 처리에 실패한 메시지가 그냥 사라지는 문제를 겪었습니다. 큐에서 꺼낸 메시지가 처리 중 오류가 나면 재시도 없이 유실됐고, 원인을 파악하기도 어려웠습니다. 찾아보니 Dead Letter Queue를 연결하면 실패 메시지를 따로 보관하고 재처리할 수 있다는 걸 알게 됐습니다. 저는 TTL과 DLQ를 함께 설정해서 실패 메시지를 별도 큐에 쌓아두고, 일정 횟수 재시도 후에도 안 되면 로그로 남기도록 설계했습니다. 그 뒤로 처리 실패를 추적하는 시각이 생겼고, 메시지 큐를 쓸 때 실패 경로를 먼저 설계하는 습관이 생겼습니다.
Exchange와 Binding 구조를 직접 손으로 그려보며 이해한 경험이라 지금도 선명하게 남아 있습니다. 복잡한 라우팅이 필요한 상황에서 RabbitMQ가 왜 쓰이는지도 그때 몸으로 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.