이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
Kafka 같은 메시지 시스템을 쓸 때 가장 주의해야 할 건 메시지 유실과 중복 처리 문제라고 생각합니다. 컨슈머가 처리 도중 실패하면 같은 메시지를 다시 받게 되는 구조가 기본인데, 이 점을 모르고 쓰면 데이터가 중복으로 처리되는 문제가 생깁니다.
졸업 프로젝트에서 이벤트 스트리밍 구조를 처음 써봤을 때, 처리 완료 전에 오프셋을 커밋하도록 설정했습니다. 그 결과 컨슈머가 재시작되면 마지막으로 처리한 메시지가 사라지는 문제가 났습니다. 오프셋 커밋 시점을 처리 완료 후로 바꿨더니 유실은 해결됐는데, 이번엔 중복이 생겼습니다.
두 가지를 동시에 잡으려면 멱등성 설계가 필요하다는 걸 그때 배웠습니다.
메시지 시스템은 구조 자체보다 실패 시 어떤 일이 생기는지를 먼저 설계해야 한다는 감각이 그 경험에서 생겼습니다.
메시지 시스템을 처음 쓸 때 파티션 수와 순서 보장 범위를 잘못 이해해서 문제가 생긴 경험이 있습니다. 처리량을 늘리려고 파티션을 5개로 늘렸는데, 같은 사용자의 이벤트가 서로 다른 파티션으로 분산되면서 순서가 뒤바뀌는 경우가 생겼습니다.
Kafka는 파티션 내에서만 순서를 보장한다는 걸 그때 제대로 이해했습니다. 같은 키를 가진 메시지가 같은 파티션으로 가도록 파티션 키를 설정하고 나서야 순서 문제가 해결됐습니다. 처리량과 순서 보장은 트레이드오프가 있다는 걸 설계 단계에서 고려하지 않으면 나중에 수정 비용이 큽니다.
메시지 시스템을 도입할 때 어떤 메시지가 순서를 지켜야 하는지를 먼저 정의하는 게 중요하다는 걸 그 경험에서 배웠습니다.
메시지 시스템에서 주의해야 할 점으로 컨슈머 그룹 구성과 파티션 매핑을 꼽고 싶습니다. 컨슈머 수가 파티션 수보다 많으면 일부 컨슈머는 아무 메시지도 받지 못하는 상태가 됩니다.
팀 프로젝트에서 컨슈머를 6개 띄웠는데 파티션이 4개였습니다. 처음에는 왜 일부 컨슈머가 유휴 상태인지 몰랐는데, 파티션-컨슈머 관계를 확인하고 나서야 이유를 알았습니다. 파티션을 6개로 늘리거나 컨슈머를 4개로 줄여야 했습니다.
메시지 시스템을 쓸 때 처리량·파티션·컨슈머 수의 관계를 설계 단계에서 맞춰야 한다는 걸 그 경험에서 배웠습니다. 나중에 조정하면 운영 중 재할당이 발생해서 일시적인 지연이 생길 수 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 SK텔레콤 데이터 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.