우문현답
愚 問 賢 答
회사별 면접직군별진행 방식
    홈›회사별›배달의민족(우아한형제들)›데이터 엔지니어›질문 상세
    問
    배배달의민족(우아한형제들)데이터 엔지니어직무 역량2026년 출제

    Kafka 또는 Flink를 사용한 실시간 스트리밍 애플리케이션 개발 사례를 공유해 주세요.

    답변 미리보기

    Kafka를 직접 써본 경험은 학교 분산 시스템 수업에서 로그 수집 파이프라인을 만드는 실습이었습니다. 여러 서비스에서 발생하는 이벤트 로그를 단일 Kafka…

    예상 답변 시간
    90초
    예상 꼬리질문
    3회
    난이도
    난이도 중상
    출제 빈도
    높음
    INTERVIEWER'S INTENT · 면접관의 의도

    이 질문, 네 갈래로 뜯어봅니다.

    면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.

    問
    01
    활용 깊이가 어디까지인가?
    기본 토픽·컨슈머 수준인지, 파티션·재처리·스키마 결까지 다룬 결인지 살피는 자리. 깊이가 또렷한 답이 통합니다.
    骨
    02
    본인 결이 살아 있나?
    교과서적 답에 머무는지, 본인이 손에 쥐고 푼 결을 가르는지 묻는 자리. 본인 결이 보이는 답이 강합니다.
    語
    03
    운영 결이 있나?
    구성으로 끝나는지, 지연·실패·모니터링 결을 두는지 확인하는 자리. 운영 결이 보이는 답이 통합니다.
    本
    04
    한계도 인정하는가?
    장점만 답하는지, 비용·복잡도·운영 부담 같은 결을 짚는지 살피는 자리. 균형 결이 보이는 답이 강합니다.
    말로 해봐야 는다
    읽는 것과 말하는 건 다릅니다.
    이 질문, 소리 내어 답해 볼까요?
    배달의민족(우아한형제들) 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.
    음성으로 답해보기
    경험 기반 구체화약 65초실패 재처리 한계 진단과 DLQ·로그·Lag 기반 운영 설계 결실습 범위 한계와 차이를 인정하는 자기성찰 결
    예시 답변 1
    약 65초

    경험 기반 구체화

    Kafka를 직접 써본 경험은 학교 분산 시스템 수업에서 로그 수집 파이프라인을 만드는 실습이었습니다. 여러 서비스에서 발생하는 이벤트 로그를 단일 Kafka 토픽으로 수집하고, Consumer가 이를 읽어 DB에 집계하는 구조를 구현했습니다. 이 실습에서 가장 인상적이었던 것은 Producer와 Consumer의 속도가 다를 때 메시지 큐가 버퍼 역할을 한다는 것인데, Consumer가 일시적으로 멈춰도 데이터 유실 없이 재처리가 가능하다는 것을 직접 확인했습니다. 또 partition을 여러 개 쓰면 Consumer Group이 병렬로 처리할 수 있어 처리량이 선형으로 늘어난다는 것도 배웠습니다.

    토픽 설계에서 메시지 종류별로 토픽을 분리해야 할지 합칠지를 결정하는 것이 생각보다 중요한 설계 결정이라는 것도 이 실습에서 처음 고민했습니다.

    이 결의 특징
    여러 서비스 이벤트 로그를 단일 토픽으로 수집하고 컨슈머가 읽어 집계하는 구조를 구현하면서 파티션 여러 개로 컨슈머 그룹이 병렬 처리해 처리량이 선형으로 늘어남을 확인하고, 토픽 분리 여부가 중요한 설계 결정임을 처음으로 고민한 흔적이 있습니다.
    이 결이 통하는 자리
    컨슈머 일시 정지 시 데이터 유실 없이 재처리가 가능하다는 것을 직접 확인했고 파티션·컨슈머 그룹 병렬 처리를 이해한 결이 토픽 설계 고민과 함께 제시될 때 통합니다. 구현 범위와 설계 결정의 근거가 자신의 언어로 살아 있을 때 면접관의 꼬리질문이 줄어드는 결이 보입니다.
    예시 답변 2

    실패 재처리 한계 진단과 DLQ·로그·Lag 기반 운영 설계 결

    Kafka 실습에서 Consumer가 메시지를 처리하다 실패했을 때 어떻게 운영하는지를 고민하는 자리가 생겼습니다. 기본 구현에서는 Consumer가 실패하면 메시지를 다시 처리할 방법이 없는 자리가 됐습니다. offset을 커밋하지 않으면 재처리가 되는데, 문제는 어디서 실패했는지 알 수 없는 자리가 생기는 것이었습니다.

    Dead Letter Queue 개념을 공부해서, 처리 실패한 메시지를 별도 토픽으로 보내고 오류 원인을 로그로 기록하는 구조를 추가했습니다. 또 Consumer가 메시지를 얼마나 처리했는지 Consumer Lag를 측정하는 자리를 만들어서 처리 속도가 수집 속도를 못 따라가는 자리를 감지하는 구조를 설계했습니다.

    Kafka를 쓰는 것과 운영하는 것은 다른 자리라는 결이 그때 생겼고, 실패를 다루는 설계가 시스템의 신뢰를 만드는 결을 갖게 됐습니다. 그 결이 이후 파이프라인 설계에 실패 처리 자리를 먼저 두는 자리로 이어졌습니다.

    이 결의 특징
    컨슈머 실패 시 재처리 방법이 없는 구조를 발견하고 Dead Letter Queue로 실패 메시지를 별도 토픽으로 보내며 오류를 로그로 기록하는 구조를 추가했고, Consumer Lag으로 처리 속도가 수집 속도를 못 따라가는 자리를 감지하는 구조를 설계한 흔적이 있습니다.
    이 결이 통하는 자리
    Kafka를 쓰는 것과 운영하는 것이 다른 자리라는 인식이 DLQ·로그·Lag 측정이라는 구체적 운영 설계와 함께 제시될 때 통합니다. 실패를 다루는 설계가 시스템 신뢰를 만든다는 결이 파이프라인 설계 기준으로 살아 있을 때 면접관의 꼬리질문이 줄어드는 결이 보입니다.
    예시 답변 3

    실습 범위 한계와 차이를 인정하는 자기성찰 결

    Kafka 실습 경험을 말할 때 그 경험의 범위를 솔직하게 밝히는 자리가 생겼습니다. 수업에서 로컬 환경의 단일 브로커 Kafka 클러스터를 사용했는데, 실제 프로덕션에서는 다수 브로커·복제 설정·ZooKeeper 또는 KRaft 운영이 필요한 자리입니다. 수업 실습에서는 네트워크 파티션이나 브로커 장애 상황을 경험하지 않았고, 리더 선출이나 복제 지연이 실제로 어떻게 동작하는지는 이론으로만 아는 자리입니다. 또 대용량 실시간 데이터 환경에서 토픽 파티션 수 조정이나 리텐션 정책 설계는 실제 트래픽을 보면서 결정해야 하는 자리인데 그 자리를 경험하지 않았습니다.

    학교 실습과 운영 환경의 자리가 어떻게 다른지를 인정하는 것이 더 빠른 성장의 자리임을 알게 됐고, 모르는 자리를 밝히는 결이 신뢰를 만드는 자리임을 그때 배웠습니다. 그 결이 이후 기술 경험을 설명할 때 환경과 규모를 먼저 밝히는 자리로 이어졌습니다.

    이 결의 특징
    로컬 단일 브로커 환경이었기에 다수 브로커·복제 설정·리더 선출·복제 지연을 경험하지 않았고, 대용량 환경에서 파티션 수 조정이나 리텐션 정책 설계는 실제 트래픽을 보며 결정해야 하는 자리를 경험하지 않았다는 한계를 정확히 밝힌 흔적이 있습니다.
    이 결이 통하는 자리
    학교 실습과 운영 환경의 차이를 인정하고 기술 경험을 설명할 때 환경과 규모를 먼저 밝히는 결이 이 경험에서 생겼다는 흐름이 살아 있을 때 통합니다. 모르는 자리를 밝히는 것이 신뢰를 만든다는 자리에서 면접관의 꼬리질문이 줄어드는 결이 보입니다.
    !
    위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.
    ✕자주 빠지는 자리

    같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.

    • ✕Kafka를 썼다는 사실과 도구 나열에 머물고, 어떤 데이터 흐름을 어떻게 설계했는지 설명을 빠뜨립니다
    • ✕실시간 처리의 핵심인 지연 시간, 처리량, 장애 복구 같은 운영 관점을 짚지 않고 기능 소개로만 머뭅니다
    • ✕수집 후 적재, 스키마 관리, 중복 처리, 순서 보장 같은 데이터 품질 이슈를 어떻게 다뤘는지 놓칩니다
    ▶이어질 꼬리질문

    진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.

    壹그 파이프라인에서 지연 시간과 처리량은 어떻게 설계했습니까?
    대응병목 지점과 튜닝 근거를 풀어주는 결이 통합니다.
    貳장애가 났을 때 재처리와 데이터 유실 방지는 어떻게 했습니까?
    대응offset 관리, retry, DLQ 등 복구 전략을 짚어두면 좋습니다.
    參스키마 변경이나 중복 메시지는 어떻게 통제했습니까?
    대응스키마 호환성, idempotency, dedup 기준을 함께 설명하면 좋습니다.
    이제, 직접 답해볼 차례예요.
    눈으로 읽은 답은 면접장에서 나오지 않아요. 배달의민족(우아한형제들) 면접관과 이 질문으로 한 번 대화해 보세요.
    이 질문으로 모의면접 해보기
    또는, 다음 질문으로

    같은 흐름에서 자주 이어지는 질문들이에요.

    넥스트증권 · 백엔드
    Kafka를 이용한 실시간 데이터 스트림 처리 경험에 대해 구체적으로 설명해주실 수 있나요?
    이 질문 보기
    GS리테일 · 데이터 엔지니어
    Kafka를 활용한 실시간 데이터 파이프라인 설계 경험에 대해 이야기해 주세요.
    이 질문 보기
    GS리테일 · 데이터 엔지니어
    Kafka를 활용한 실시간 데이터 파이프라인 설계를 해본 경험에 대해 말씀해 주세요.
    이 질문 보기
    넥스트증권 · 데이터 엔지니어
    Kafka 기반의 실시간 데이터 수집 파이프라인을 구축한 경험에 대해 이야기해보세요.
    이 질문 보기
    안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히
    개인정보처리방침이용약관문의
    © 2026 우문현답. All rights reserved.
    이 페이지 목차
    01면접관의 의도02답변의 결03실수·꼬리질문04관련 질문
    말로 해봐야 는다
    이 질문, 배달의민족(우아한형제들) 면접관과
    음성으로 답해볼까요?
    모의면접 해보기
    첫 회 무료 · 종료 즉시 음성 폐기