우문현답
愚 問 賢 答
회사별 면접직군별진행 방식
    홈›회사별›넥스트증권›데이터 엔지니어›질문 상세
    問
    넥넥스트증권데이터 엔지니어경험·이력2026년 출제

    Confluent Kafka를 기반으로 한 대규모 실시간 스트리밍 데이터 처리 경험에 대해 이야기해 주세요.

    답변 미리보기

    Confluent Kafka 기반 파이프라인 경험은 인턴십에서 실시간 사용자 이벤트를 처리하는 시스템을 유지보수한 것이 전부입니다. 저는 전체 아키텍처보다는…

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

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

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

    問
    01
    어떤 결의 데이터를 다뤘나요?
    거래·로그·이벤트 중 본인이 가장 손에 쥔 결이 어디인지를 보는 자리입니다. 단순 보조가 아닌 흔적이 통합니다.
    骨
    02
    본인이 한 부분이 어디까지인가요?
    설계·구현·운영·튜닝 중 본인 손이 닿은 결을 명확히 가른 답이 보이는 축입니다. 과장 없이 짚는 자리가 평가됩니다.
    語
    03
    신뢰성의 결을 의식하시나요?
    장애·중복·순서의 결을 의식한 답이 보이는 자리입니다. 단정 짓지 않은 흔적이 통합니다.
    本
    04
    한계도 솔직히 보시나요?
    본인이 닿지 않는 결을 인정한 답이 보이는 결입니다. 단정 짓지 않은 자리가 자리잡습니다.
    말로 해봐야 는다
    읽는 것과 말하는 건 다릅니다.
    이 질문, 소리 내어 답해 볼까요?
    넥스트증권 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.
    음성으로 답해보기
    Consumer lag 급증 원인 분리 + 슬로우 컨슈머 로그 분석으로 병목 기여약 120초Kafka 파티션 불균형으로 특정 파티션에 부하가 집중돼 처리 지연 발생약 120초처음으로 배치 파이프라인을 Kafka 기반 실시간 스트리밍으로 전환한 경험약 150초
    A
    약 120초

    Consumer lag 급증 원인 분리 + 슬로우 컨슈머 로그 분석으로 병목 기여

    Confluent Kafka 기반 파이프라인 경험은 인턴십에서 실시간 사용자 이벤트를 처리하는 시스템을 유지보수한 것이 전부입니다. 저는 전체 아키텍처보다는 컨슈머 쪽 문제 대응을 주로 담당했습니다. 가장 자주 봤던 이슈는 Consumer lag 급증이었는데, 원인이 파티션 수 부족인지 컨슈머 처리 속도 문제인지를 먼저 분리해서 보는 것이 중요했습니다.

    파티션을 늘리는 것은 컨슈머 그룹 재분배를 일으키기 때문에 운영 중 변경은 신중하게 접근하는 것이 맞다고 봅니다. 제 수준에서 기여한 것은 슬로우 컨슈머 로그를 분석해서 병목 구간을 찾고 팀에 보고한 것이었습니다. 한계는 Kafka Streams나 ksqlDB 같은 스트림 처리 레이어는 이론으로만 알고 있습니다.

    이 결의 특징
    Confluent Kafka 인턴십에서 Consumer lag 급증 시 파티션 수 부족인지 컨슈머 처리 속도 문제인지를 먼저 분리해서 보는 것이 중요했고, 파티션 증가는 컨슈머 그룹 재분배를 일으키므로 운영 중 변경은 신중해야 한다는 경험에서 나온 흔적이 있습니다. 슬로우 컨슈머 로그를 분석해 병목 구간을 찾고 팀에 보고한 기여 범위를 명시한 결이 자주 보입니다.
    이 결이 통하는 자리
    컨슈머 lag 원인 분리 방법과 기여 범위 명시가 함께 설명될 때 통합니다. 파티션 변경의 운영 영향을 인식하는 결이 살아 있는 자리에서 면접관의 꼬리질문이 줄어드는 결이 보입니다.
    예시 답변 2
    약 120초

    Kafka 파티션 불균형으로 특정 파티션에 부하가 집중돼 처리 지연 발생

    Kafka 토픽의 파티션 키 설계를 user_id 해시로 했는데, 특정 대형 고객의 이벤트 비중이 전체의 70%를 넘으면서 한 파티션에 부하가 집중됐어요. 다른 컨슈머는 idle 상태인데 한 컨슈머만 lag이 수십만 건씩 쌓였고, 파티션 키 설계가 데이터 편향을 낳고 있었다는 걸 나중에 파악했습니다.

    Kafka 파티션 키는 처리량 균형을 기준으로 설계해야 하고, 특정 키 값으로 이벤트가 몰리는 핫 파티션 문제는 초기 설계 단계에서 예측하기 어렵지만 모니터링으로 조기에 잡아야 한다는 걸 그때 배웠어요. 파티션 키 설계 실수는 토픽 재생성이 아니면 고치기 어렵기 때문에 처음부터 데이터 분포를 고려해야 한다는 걸 알았습니다.

    이후엔 파티션 키 설계 전에 이벤트 데이터의 분포와 상위 키 값 비중을 먼저 분석하는 단계를 씁니다. 균일한 파티션 분배가 Kafka 성능의 가장 기본 조건이라는 원칙이 그 경험에서 나왔습니다.

    이 결의 특징
    파티션 키를 user_id 해시로 설계했는데 특정 대형 고객 이벤트 비중이 70%를 넘으면서 한 파티션에 부하가 집중되어 다른 컨슈머는 idle이고 한 컨슈머만 lag이 수십만 건씩 쌓인 경험에서, 이후 파티션 키 설계 전에 이벤트 데이터 분포와 상위 키 값 비중을 먼저 분석하는 단계를 두는 흔적이 있습니다. 파티션 키 설계 실수는 토픽 재생성이 아니면 고치기 어렵다는 결이 실제 장애에서 굳어진 자리가 자주 보입니다.
    이 결이 통하는 자리
    핫 파티션 장애 경험과 데이터 분포 선행 분석 원칙이 인과로 설명될 때 통합니다. 균일한 파티션 분배가 Kafka 성능의 기본 조건이라는 결이 살아 있는 자리에서 면접관의 신뢰가 생기는 결이 자주 보입니다.
    예시 답변 3
    약 150초

    처음으로 배치 파이프라인을 Kafka 기반 실시간 스트리밍으로 전환한 경험

    야간 배치로 처리하던 로그 집계 파이프라인을 처음으로 Kafka 기반 실시간 처리로 전환하는 작업을 맡게 됐어요. 배치와 스트리밍은 같은 데이터를 다루지만 장애 처리, 순서 보장, 중복 처리 문제를 전혀 다른 방식으로 접근해야 한다는 걸 처음 알았습니다.

    배치 파이프라인은 실패 시 재실행이 쉬운 반면 스트리밍은 이벤트 순서·중복·지연을 설계 단계에서 미리 다뤄야 하고, 그 차이를 모르면 배치 방식의 사고로 스트리밍을 잘못 설계하게 된다는 걸 그 경험에서 배웠어요. exactly-once 보장이 필요한지, at-least-once로 충분한지를 먼저 결정하는 것이 Kafka 파이프라인 설계의 출발점임을 알았습니다.

    지금은 스트리밍 파이프라인 설계 전에 이벤트 순서 보장, 중복 처리, 레이턴시 요구 사항을 명시하는 단계를 먼저 씁니다. 파이프라인 설계는 기술 선택보다 요구 사항 명세가 먼저라는 원칙이 그 경험에서 나왔습니다.

    이 결의 특징
    야간 배치 파이프라인을 처음으로 Kafka 기반 실시간으로 전환하면서 장애 처리·순서 보장·중복 처리를 전혀 다른 방식으로 접근해야 한다는 것을 처음 알게 된 경험에서, 이후 스트리밍 파이프라인 설계 전에 이벤트 순서 보장·중복 처리·레이턴시 요구 사항을 명시하는 단계를 먼저 두는 흔적이 있습니다. 배치 방식의 사고로 스트리밍을 설계하면 잘못된 가정이 들어간다는 결이 낯선 전환에서 직접 나온 자리가 자주 보입니다.
    이 결이 통하는 자리
    배치와 스트리밍 설계 차이를 전환 경험에서 직접 배운 자리와 요구 사항 명세 선행 원칙이 함께 설명될 때 통합니다. 기술 선택보다 요구 사항 명세가 먼저라는 결이 살아 있는 자리에서 면접관의 꼬리질문이 줄어드는 결이 보입니다.
    !
    위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.
    ✕자주 빠지는 자리

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

    • ✕떨어뜨린 옵션이 1개라도 있는가? "이게 답이었어요"만으로는 의사결정이 아니라 그냥 선택입니다.
    • ✕선택 기준이 그 프로젝트에 한정되는가? "성능이 좋아서"는 일반론, "우리 트래픽이 X 패턴이라서"가 본인의 답입니다.
    • ✕결과 숫자 1개를 정확히 말할 수 있는가? P95·QPS·적중률 — 무엇이든 1개. 숫자가 없으면 직감으로 한 일처럼 들리기 쉽습니다.
    • ✕지금 다시 한다면 어떻게 할지 답할 수 있는가? "잘했다"보다 "이건 다르게 했을 것 같다"가 더 깊은 인상을 남깁니다.
    ▶이어질 꼬리질문

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

    壹트러블 슈팅한 자리가 있나요?
    貳비용·성능을 균형 잡으셨나요?
    參최근 새로 익힌 결이 있나요?
    이제, 직접 답해볼 차례예요.
    눈으로 읽은 답은 면접장에서 나오지 않아요. 넥스트증권 면접관과 이 질문으로 한 번 대화해 보세요.
    이 질문으로 모의면접 해보기
    또는, 다음 질문으로

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

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