우문현답
愚 問 賢 答
회사별 면접직군별진행 방식
    홈›회사별›당근마켓›데이터 엔지니어›질문 상세
    問
    당당근마켓데이터 엔지니어직무 역량2026년 출제

    대규모 트래픽 처리를 위한 데이터 아키텍처의 구성 원리에 대해 설명해줄 수 있나요?

    답변 미리보기

    캡스톤 프로젝트에서 동시 사용자 1만 명 이상을 가정한 데이터 파이프라인 아키텍처를 설계했습니다. 직접 운영한 것은 아니었지만 부하 시뮬레이션까지…

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

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

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

    問
    01
    대규모 트래픽 처리 경험이 있는가?
    대규모 트래픽을 처리한 경험이 답에 있어야 합니다. 없으면 면접관이 '어떤 기술을 사용했나요?'를 추가로 묻는 경우가 자주 보입니다.
    骨
    02
    데이터 아키텍처 설계 원리를 아는가?
    데이터 아키텍처의 구성 원리에 대한 이해가 답에 있어야 합니다. 없으면 면접관이 '어떤 설계 원칙을 적용했나요?'를 추가로 묻는 경우가 많습니다.
    語
    03
    도전과제를 어떻게 해결했는가?
    직면했던 도전과제를 해결한 흔적이 답에 있어야 합니다. 없으면 면접관이 '어떤 방식으로 해결했나요?'를 추가로 묻는 경향이 있습니다.
    本
    04
    성과를 어떻게 측정했는가?
    성과를 측정한 방법에 대한 설명이 답에 있어야 합니다. 없으면 면접관이 '결과는 어땠나요?'를 추가로 묻는 경우가 자주 보입니다.
    말로 해봐야 는다
    읽는 것과 말하는 건 다릅니다.
    이 질문, 소리 내어 답해 볼까요?
    당근마켓 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.
    음성으로 답해보기
    수평 확장, 캐시, 큐 등 실제로 설계하고 검증한 구조를 중심으로 설명한다약 88초Lambda/Kappa 아키텍처 등 선택 기준과 본인 판단을 말한다약 83초아키텍처를 실제로 검증하고 튜닝한 과정을 중심으로 전달한다약 80초
    대규모 트래픽 대비 아키텍처를 설계한 경험 말하기
    약 88초

    수평 확장, 캐시, 큐 등 실제로 설계하고 검증한 구조를 중심으로 설명한다

    캡스톤 프로젝트에서 동시 사용자 1만 명 이상을 가정한 데이터 파이프라인 아키텍처를 설계했습니다. 직접 운영한 것은 아니었지만 부하 시뮬레이션까지 검증했습니다.

    설계의 핵심은 세 가지였습니다. 첫째, 입력 레이어에 메시지 큐(Kafka)를 두어 트래픽 급증 시 소비자 속도에 맞게 흘려보내는 구조, 둘째, 자주 조회되는 집계 결과는 Redis 캐시에 30분 TTL로 올려두는 패턴, 셋째, 분석 쿼리용 DB는 쓰기 DB와 분리해 읽기 전용 레플리카에서 처리하는 구조였습니다. 이 세 요소가 없을 때와 있을 때를 로컬 부하 테스트로 비교했는데, p99 응답 지연이 8.2초에서 0.9초로 줄었습니다.

    실패는 Kafka 컨슈머 그룹 파티션 수를 처음에 너무 작게 잡아서 소비 속도가 느려진 구간이 생긴 것이었는데, 파티션을 4개에서 12개로 늘리고 나서야 해소되었습니다. 이론은 알아도 파라미터 하나가 전체 처리량을 좌우한다는 것을 수치로 확인하는 경험이 컸습니다. 실제 운영 스케일은 경험해봐야 알겠지만, 설계 원칙을 먼저 검증하는 방법을 이 프로젝트에서 체득했습니다.

    이 결의 특징
    대규모 트래픽 대비 아키텍처를 설계한 경험 말하기에서 구체적인 수치와 상황을 함께 제시하며, 처음 상태에서 변화된 상태로의 전환점이 명백하게 드러나고 있습니다 이것이 구체적인 변화 과정으로 답변에 흔적으로 남아 있습니다.
    이 결이 통하는 자리
    이 결이 강하게 통하는 자리는 해당 직무의 핵심 역량을 단순 지식이 아닌 실제 실행 능력으로 입증해야 할 순간입니다. 면접관은 이 정도의 구체성으로 실행력을 판단합니다.
    데이터 아키텍처 선택 기준을 설명하기
    약 83초

    Lambda/Kappa 아키텍처 등 선택 기준과 본인 판단을 말한다

    대규모 데이터 처리 아키텍처를 공부하면서 Lambda 아키텍처와 Kappa 아키텍처의 차이를 실제 설계에 적용해봤습니다. 이론적으로는 알고 있었지만, 어느 상황에서 어떤 쪽을 골라야 하는지는 막연했어요.

    프로젝트 요구사항을 보고 Kappa를 선택했습니다. 배치 레이어를 별도로 관리하는 Lambda의 복잡성보다 단일 스트리밍 파이프라인으로 유지하는 게 팀 규모에 더 맞다고 판단했어요. Flink 기반으로 스트림 처리 잡을 만들었고, 이벤트 타임 기준 워터마크 설정이 가장 까다로운 부분이었습니다. 늦게 도착하는 이벤트를 얼마나 기다릴지 기준을 너무 짧게 잡았다가 늦은 이벤트가 드랍되는 문제가 생겼고, 워터마크 지연을 5초에서 30초로 늘려서 해소했습니다.

    아키텍처 선택은 성능 스펙보다 팀의 운영 능력이 먼저입니다. 아무리 좋은 구조도 운영할 사람이 없으면 장애 대응이 안 됩니다. 그 판단 기준을 갖게 된 게 이 경험의 핵심 배움이었습니다.

    이 결의 특징
    데이터 아키텍처 선택 기준을 설명하기에서 구체적인 수치와 상황을 함께 제시하며, 처음 상태에서 변화된 상태로의 전환점이 명백하게 드러나고 있습니다 이것이 구체적인 변화 과정으로 답변에 흔적으로 남아 있습니다.
    이 결이 통하는 자리
    이 결이 강하게 통하는 자리는 해당 직무의 핵심 역량을 단순 지식이 아닌 실제 실행 능력으로 입증해야 할 순간입니다. 면접관은 이 정도의 구체성으로 실행력을 판단합니다.
    설계보다 검증 과정을 중심으로 말하기
    약 80초

    아키텍처를 실제로 검증하고 튜닝한 과정을 중심으로 전달한다

    대규모 트래픽 처리 아키텍처를 설계보다 검증하는 과정이 더 어렵다는 걸 프로젝트에서 배웠습니다. 이론적으로 맞게 설계해도 실제 부하를 넣어보면 예상 외 병목이 나오거든요.

    로컬에서 k6로 동시 요청 500개 시뮬레이션을 돌렸을 때 처음에 DB 커넥션 풀이 먼저 터졌습니다. 쿼리 최적화보다 커넥션 풀 사이즈 설정이 문제였는데, 기본값이 10이어서 대기 큐가 쌓이는 구조였어요. 풀 사이즈를 40으로 늘리고 슬로우 쿼리 로그를 켜서 0.5초 이상 쿼리를 추려냈습니다. 그중 2개는 인덱스 누락이 원인이었고, 인덱스 추가 후 해당 쿼리가 0.5초에서 0.03초로 줄었습니다.

    부하 테스트 → 병목 식별 → 수정 → 재테스트 루프를 3번 반복했고, 매 루프마다 수치를 기록해서 어떤 변경이 어느 정도 효과를 냈는지 추적했습니다. 이 과정이 아키텍처를 이해하는 가장 좋은 방법이었고, 숫자로 보여주는 개선이 설득력이 다르다는 걸 경험했습니다.

    이 결의 특징
    설계보다 검증 과정을 중심으로 말하기에서 구체적인 수치와 상황을 함께 제시하며, 처음 상태에서 변화된 상태로의 전환점이 명백하게 드러나고 있습니다 이것이 구체적인 변화 과정으로 답변에 흔적으로 남아 있습니다.
    이 결이 통하는 자리
    이 결이 강하게 통하는 자리는 해당 직무의 핵심 역량을 단순 지식이 아닌 실제 실행 능력으로 입증해야 할 순간입니다. 면접관은 이 정도의 구체성으로 실행력을 판단합니다.
    !
    위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.
    ✕자주 빠지는 자리

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

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

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

    壹어떤 기술을 선택한 이유가 무엇인가요?
    貳이 아키텍처에서 직면한 가장 큰 도전은 무엇이었나요?
    參만약 다시 설계한다면 어떤 부분을 개선하겠어요?
    이제, 직접 답해볼 차례예요.
    눈으로 읽은 답은 면접장에서 나오지 않아요. 당근마켓 면접관과 이 질문으로 한 번 대화해 보세요.
    이 질문으로 모의면접 해보기
    또는, 다음 질문으로

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

    당근마켓 · 데이터 엔지니어
    대규모 트래픽 처리를 위한 데이터 아키텍처를 설계할 때 직면할 수 있는 도전과제를 어떻게 해결할 수 있을까요?
    이 질문 보기
    당근마켓 · 데이터 엔지니어
    대규모 트래픽을 처리하기 위한 데이터 아키텍처 설계 경험에 대해 말씀해 주세요.
    이 질문 보기
    HL그룹 · 백엔드
    대규모 트래픽 처리를 위한 아키텍처 설계 경험이 있다면 어떤 방식으로 접근했는지 설명해 주세요.
    이 질문 보기
    넥스트증권 · 백엔드
    대규모 사용자 트래픽을 처리하기 위해 아키텍처를 어떻게 개선하고 확장할 것인가요?
    이 질문 보기
    안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히
    개인정보처리방침이용약관문의
    © 2026 우문현답. All rights reserved.
    이 페이지 목차
    01면접관의 의도02답변의 결03실수·꼬리질문04관련 질문
    말로 해봐야 는다
    이 질문, 당근마켓 면접관과
    음성으로 답해볼까요?
    모의면접 해보기
    첫 회 무료 · 종료 즉시 음성 폐기