우문현답
愚 問 賢 答
회사별 면접직군별진행 방식
    홈›회사별›피처링›MLOps›질문 상세
    問
    피피처링MLOps직무 역량2026년 출제

    Spark 또는 Ray를 활용하여 분산 처리 작업을 수행한 경험이 있다면, 어떤 사례인지 말씀해 주세요.

    답변 미리보기

    졸업 프로젝트에서 1억 개 이상 텍스트 레코드를 전처리하다가 단일 노드로 12시간이 넘어가자 Spark로 전환했습니다. 분산이 빠르다기보다, OOM으로 노드가…

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

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

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

    問
    01
    분산이 필요한 이유를 짚는가?
    데이터 양·처리 시간·메모리 한계 중 어떤 이유로 분산을 골랐는지 본인의 정의가 답에 있어야 합니다. '분산이 빠르다' 수준의 답은 면접관이 '단일 노드론 안 됐어요?'를 추가로 묻는 자리가 자주 보입니다.
    骨
    02
    Spark·Ray의 결을 알고 있는가?
    두 도구의 추상화 차이와 본인이 어느 쪽을 어떤 작업에 골랐는지 짚는 자리입니다. 도구 이름만 나열한 답은 깊이 의심이 들어가는 결로 통합니다.
    語
    03
    성능 튜닝 흔적이 있는가?
    파티션 수·셔플·메모리 설정을 본인이 손에 쥐고 튜닝한 흔적이 있어야 합니다. 기본값으로 돌린 답은 운영 감도가 약하다는 결로 보입니다.
    本
    04
    장애·재시도를 다뤘는가?
    노드 장애·태스크 재시도·체크포인트를 어떻게 다뤘는지 흔적이 있어야 합니다. 분산의 장애 모델을 인지 못 한 답은 깊이가 부족해 보이는 자리가 흔합니다.
    말로 해봐야 는다
    읽는 것과 말하는 건 다릅니다.
    이 질문, 소리 내어 답해 볼까요?
    피처링 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.
    음성으로 답해보기
    단일 노드 한계에서 분산을 선택하고 파티션 튜닝과 장애 재시도를 직접 다룬 결약 68초Spark UI 병목 수치 확인과 조인방식·자원 조정으로 성능 최적화 결장애 원인 체감 후 체크포인트·재시도 로그와 파티션 점검으로 복구 설계 결
    예시 답변 1
    약 68초

    단일 노드 한계에서 분산을 선택하고 파티션 튜닝과 장애 재시도를 직접 다룬 결

    졸업 프로젝트에서 1억 개 이상 텍스트 레코드를 전처리하다가 단일 노드로 12시간이 넘어가자 Spark로 전환했습니다. 분산이 빠르다기보다, OOM으로 노드가 죽는 게 반복돼서 다른 선택지가 없었습니다. 처음에는 기본 파티션 수로 돌렸다가 GC 경고가 쏟아지는 것을 보고 repartition으로 파티션을 늘렸고, 셔플 메모리 설정도 직접 손봤습니다. 태스크 재시도 기본값이 4회여서 그냥 뒀다가 특정 파티션이 데이터 치우침 때문에 반복 실패하는 걸 발견하고 salting 기법으로 분산시켰습니다. 분산 처리를 돌린다고 끝이 아니라 파티션이 고르게 퍼지는지 확인하는 게 운영의 핵심이라는 걸 그때 익혔습니다.

    이 결의 특징
    단일 노드에서 12시간이 넘고 OOM이 반복되자 분산을 선택한 이유가 명확하고, repartition으로 파티션을 늘린 뒤 GC 경고를 보고 셔플 메모리 설정까지 직접 손본 흔적이 구체 수치로 살아 있습니다. salting으로 특정 파티션 치우침까지 해소한 과정이 연결됩니다.
    이 결이 통하는 자리
    분산 처리 경험을 이론이 아닌 실제 OOM과 파티션 치우침 해결로 설명할 수 있을 때 통합니다. 파티션 균등 분포를 운영의 핵심으로 짚는 결이 분산 파이프라인을 실제 운영하는 팀의 면접에서 신뢰로 이어지는 자리가 자주 보입니다.
    예시 답변 2

    Spark UI 병목 수치 확인과 조인방식·자원 조정으로 성능 최적화 결

    Spark 성능 튜닝에서 파티션 외에 조인 방식이 얼마나 영향을 주는지 직접 비교하면서 배웠습니다. 텍스트 전처리 파이프라인에 기준 사전 데이터를 조인하는 단계가 있었는데, sort-merge join으로 돌리니 셔플이 크게 일어나면서 소요 시간이 예상의 두 배였습니다. 사전 데이터가 100MB 이하임을 확인하고 브로드캐스트 조인으로 바꾸자 해당 단계가 전체 파이프라인 시간의 30% 이하로 줄었습니다.

    Spark UI에서 스테이지별 실행 시간을 보는 방법을 그때 익혔고, 어느 스테이지가 병목인지 숫자로 확인하기 전까지는 최적화 방향을 찾기 어렵다는 걸 실감했습니다. executor 메모리와 코어 수를 클러스터 자원에 맞게 조정하는 것도 그 과정에서 손에 익혔습니다. 튜닝은 감으로 하는 게 아니라 UI에서 병목을 확인하고 한 변수씩 바꾸는 결임을 그 경험이 알려줬습니다.

    이 결의 특징
    sort-merge join이 셔플을 크게 일으켜 소요 시간이 예상의 두 배였다는 수치가 있고, 사전 데이터 100MB 이하를 확인한 뒤 브로드캐스트 조인으로 전환해 해당 단계를 전체 파이프라인 시간의 30% 이하로 줄인 과정이 구체적으로 담겨 있습니다.
    이 결이 통하는 자리
    Spark 성능 튜닝 경험을 UI 병목 수치와 조인 방식 선택으로 설명할 수 있을 때 통합니다. 감으로 최적화하지 않고 스테이지별 실행 시간을 확인한 뒤 변수 하나씩 바꾸는 결이 있을 때 데이터 엔지니어링 파이프라인 팀에서 면접관의 신뢰가 쌓이는 자리가 자주 보입니다.
    예시 답변 3

    장애 원인 체감 후 체크포인트·재시도 로그와 파티션 점검으로 복구 설계 결

    분산 처리에서 장애는 가정이 아니라 실제로 일어난다는 걸 프로젝트 중반에 처음 체감했습니다. 처리 중 특정 노드가 응답을 잃으면서 스테이지 전체가 재시작되는 상황이 발생했고, 중간 결과가 없어 처음부터 다시 돌아야 했습니다. 이후 장시간 파이프라인에는 체크포인트를 중간에 HDFS에 저장하도록 추가해, 재시도 시 특정 스테이지부터 이어갈 수 있게 했습니다.

    스파크 이벤트 로그를 활성화해 어떤 태스크가 몇 번 재시도됐는지 기록하는 방향도 함께 잡았습니다. 특정 파티션만 반복 실패하는 경우에는 salting과 함께 해당 파티션 데이터를 먼저 따로 확인하는 과정이 생겼습니다. 장애 복구 전략이 없으면 긴 파이프라인은 한 번의 노드 불안정으로 수 시간을 날리는 자리임을 직접 경험한 후 설계에 포함하게 됐습니다.

    이 결의 특징
    노드 장애로 스테이지 전체가 재시작되어 수 시간을 날린 경험 이후, 중간 결과를 HDFS에 체크포인트로 저장하고 이벤트 로그를 활성화해 태스크 재시도 이력을 기록하는 설계가 추가된 흔적이 답 안에 순서대로 보입니다.
    이 결이 통하는 자리
    장애 복구 전략을 처음부터 설계에 포함하는 감각을 갖춘 후보를 찾는 자리에서 통합니다. 체크포인트와 재시도 로그를 실제 장애 경험에서 내면화한 결이 드러날 때 장시간 배치 파이프라인을 운영하는 팀 면접에서 면접관이 운영 안정성을 긍정적으로 읽는 결이 보입니다.
    !
    위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.
    ✕자주 빠지는 자리

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

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

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

    壹Spark와 Ray 중 어느 쪽이 어떤 작업에 맞다고 보시나요?
    貳셔플이 병목이 됐을 때 어떻게 풀어가시나요?
    參비용이 너무 컸을 때 어떻게 대응하셨나요?
    이제, 직접 답해볼 차례예요.
    눈으로 읽은 답은 면접장에서 나오지 않아요. 피처링 면접관과 이 질문으로 한 번 대화해 보세요.
    이 질문으로 모의면접 해보기
    또는, 다음 질문으로

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

    쿠팡 · 데이터 엔지니어
    대량의 데이터를 처리할 때, 어떤 분산 처리 기술을 사용해본 경험이 있는지 이야기해줄 수 있나요?
    이 질문 보기
    카카오모빌리티 · 데이터 엔지니어
    Spark나 Flink와 같은 분산 빅데이터 처리 기술을 사용한 경험을 구체적으로 설명해 주세요.
    이 질문 보기
    배달의민족(우아한형제들) · 데이터 엔지니어
    Hadoop이나 Spark를 활용하여 대용량 데이터를 처리한 경험에 대해 말씀해 주세요.
    이 질문 보기
    삼성바이오에피스 · 공통직무·미지정
    Python이나 R을 활용한 데이터 분석 경험에 대해 말씀해 주세요.
    이 질문 보기
    안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히
    개인정보처리방침이용약관문의
    © 2026 우문현답. All rights reserved.
    이 페이지 목차
    01면접관의 의도02답변의 결03실수·꼬리질문04관련 질문
    말로 해봐야 는다
    이 질문, 피처링 면접관과
    음성으로 답해볼까요?
    모의면접 해보기
    첫 회 무료 · 종료 즉시 음성 폐기