이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 실시간 이벤트 스트리밍 처리 시스템을 팀 3인으로 설계했습니다. 단일 노드에서 잘 돌아가던 서버가 부하 테스트에서 초당 1,000건을 넘기자 병목이 생겼고, 원인을 찾으니 단일 큐에 모든 이벤트가 몰리는 구조였습니다. 파티셔닝 키 기준으로 큐를 분리하고 컨슈머를 수평 확장했더니 처리량이 4배 올랐습니다. 이 과정에서 파티션 리밸런싱 중 중복 처리 문제가 생겼고, 멱등성 키를 이벤트에 붙여 컨슈머가 중복 처리를 건너뛰도록 설계해 해결했습니다. 분산 시스템에서 확장성과 정확히-한-번 처리 보장 사이의 트레이드오프를 직접 다뤘다는 점이 이 프로젝트의 핵심 배움이었습니다.
분산 이벤트 처리 시스템에서 컨슈머 노드 하나가 장애가 생겼을 때 처리 중이던 이벤트가 유실되지 않도록 하는 구조를 설계하는 과정에서 어려움을 경험했습니다. 노드가 이벤트를 가져가서 처리하는 도중에 장애가 생기면, 이미 큐에서 꺼낸 이벤트는 다른 노드가 가져가지 못하는 상황이 됐습니다. 처리를 완전히 완료한 후에만 오프셋을 커밋하는 방식으로 바꾸니, 장애가 생겨도 미처리 이벤트는 다른 노드가 이어받아 처리할 수 있었습니다. 이 구조에서 같은 이벤트를 여러 번 처리하는 중복 처리 가능성이 남았는데, 처리 결과에 멱등성을 보장하는 것이 별도로 필요했습니다. 분산 시스템에서 장애 허용성과 정확히 한 번 처리는 함께 달성하기 어려운 목표이고, 두 가지 중 어느 쪽에 더 비중을 둘지를 시스템의 요구사항에 따라 결정하는 것이 설계의 핵심이라는 것을 이 경험에서 배웠습니다.
분산 이벤트 처리 시스템을 수평 확장하면서 처음에는 모니터링 구조를 충분히 갖추지 않았는데, 이것이 나중에 문제가 됐습니다. 처리량이 예상보다 낮아지는 상황이 생겼는데, 각 노드의 상태나 큐의 적체 상황을 실시간으로 볼 수 있는 수단이 없어서 원인을 찾는 데 시간이 걸렸습니다. 직접 로그를 수집해서 분석한 결과 특정 파티션에 이벤트가 몰리면서 일부 컨슈머만 과부하가 생기는 것이 원인이었는데, 이것을 모니터링이 있었다면 더 빨리 발견할 수 있었습니다. 분산 시스템은 단일 시스템보다 상태를 파악하기 어렵기 때문에, 구축 단계에서 모니터링을 기능과 동등한 우선순위로 가져가야 한다는 것을 이 경험에서 배웠습니다. 시스템 규모가 커질수록 사람이 직접 상태를 확인하는 방식은 한계가 있고, 관측 가능성을 설계에서부터 고려하는 것이 운영 비용을 낮추는 데 중요하다는 것을 알게 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.