PySpark 면접 질문

동작하는 PySpark 코드를 작성할 수 있어도 이런 질문에서는 막힐 수 있습니다. 이 질문들이 묻는 것은 코드가 무엇을 적었는지가 아니라 엔진이 실제로 무엇을 하는지이기 때문입니다. 면접관이 이런 질문으로 시작하는 이유는 바로 작업을 튜닝해본 사람과 한 번 실행만 해본 사람을 구분할 수 있기 때문입니다. 이 섹션에서는 실행 모델 관련 질문과 완전한 답변에 포함되어야 할 내용을 다룹니다.

• transformation과 action의 차이는 무엇인가요? transformation은 실행 계획을 만들고 새로운 DataFrame을 지연 방식으로 반환합니다. 반면 count, collect나 쓰기 작업 같은 action이 실제 실행을 트리거합니다. action이 결과를 요청하기 전까지는 아무것도 계산되지 않습니다.
• 지연 평가는 왜 유용한가요? 옵티마이저가 실행 전에 전체 체인을 파악할 수 있어서, 필터 순서를 재배치하고 불필요한 컬럼을 제거하고 여러 단계를 결합할 수 있습니다.
• 좁은 변환인가요, 넓은 변환인가요? filter, select 같은 좁은 연산은 각 출력 파티션이 하나의 입력 파티션에만 의존합니다. groupBy, join, distinct 같은 넓은 연산은 파티션 간에 데이터를 재분배하는데, 이것이 바로 셔플입니다.
• 셔플이란 무엇이고 왜 중요한가요? 데이터가 네트워크를 오가며 디스크에도 기록되어 stage 경계를 형성합니다. 대개 작업에서 가장 비용이 큰 부분입니다.
• job, stage, task를 설명해 주세요. action이 job을 시작시키고, 셔플 경계가 이를 여러 stage로 나누며, 각 stage는 파티션마다 하나의 task를 실행합니다.
• RDD, DataFrame, 아니면 Dataset인가요? Catalyst 옵티마이저와 컬럼 기반 실행의 이점을 받을 수 있으므로 DataFrame을 우선적으로 사용합니다. RDD는 저수준 제어가 필요할 때를 위해 남아 있습니다. 타입이 있는 Dataset은 JVM 개념이므로, Python에서는 솔직히 말해 해당되지 않는다는 것이 정답입니다.

답변에 셔플과 stage라는 단어가 들어가야 할 때는 실제로 사용하세요. 면접관은 이를 당신이 Spark UI를 실제로 본 적이 있는지 판단하는 지름길로 삼습니다.

대부분의 시니어급 PySpark 면접은 사실상 성능 면접입니다. 질문은 정의를 묻는 형태가 아니라 시나리오 형태로 나옵니다.

• join이 느립니다. 무엇을 확인하나요? 먼저 양쪽 데이터의 크기를 확인합니다. 한쪽이 executor 메모리에 들어갈 정도로 작다면 브로드캐스트해서 셔플을 아예 건너뜁니다. 그렇지 않다면 클러스터 크기를 손대기 전에 파티셔닝과 스큐를 먼저 살펴봅니다.
• 데이터 스큐란 무엇이고 어떻게 해결하나요? 소수의 key가 대부분의 행을 차지해서, 다른 task가 다 끝난 뒤에도 하나의 task만 계속 실행됩니다. 해결책으로는 핫 key에 salting을 적용하거나, 작은 쪽을 브로드캐스트하거나, 같은 값으로 해시되는 null을 필터링하는 방법이 있습니다. 진단 신호는 Spark UI에서 나타나는 task 실행 시간의 편차입니다.
• cache나 persist는 언제 사용하나요? DataFrame이 여러 action에서 재사용되고 재계산 비용이 클 때입니다. 한 번만 쓰는 데이터를 캐싱하면 메모리를 낭비하게 되며, 오래 실행되는 작업에서는 unpersist 시점도 중요합니다.
• repartition인가요, coalesce인가요? repartition은 셔플을 유발하며 파티션 수를 고르게 늘리거나 줄일 수 있습니다. coalesce는 전체 셔플 없이 병합하므로 출력 파일 수를 줄이는 더 저렴한 방법입니다.
• Python UDF는 왜 피해야 하나요? 행이 JVM과 Python 프로세스 사이에서 직렬화되며, 옵티마이저는 함수 내부를 들여다볼 수 없습니다. 내장 함수를 우선 사용하고, 대응하는 내장 함수가 없을 때만 벡터화된 UDF를 고려하세요.
• collect는 왜 위험한가요? 전체 결과를 driver로 가져오기 때문에 driver의 메모리를 고갈시킬 수 있습니다.
• 작업이 메모리 부족으로 실패했습니다. 어떤 순서로 조사하나요? 먼저 driver인지 executor인지를 확인하고, 다음으로 스큐, 그다음 파티션 크기 설정, 마지막으로 메모리 설정을 봅니다. 처음부터 메모리를 늘리는 답변은 경험이 부족하다는 신호입니다.

플랫폼 팀 면접을 본 한 데이터 엔지니어는 일 년 동안 안정적으로 돌아가던 야간 작업이 왜 갑자기 네 시간이나 걸리게 됐는지 질문받았습니다. 통했던 답은 설정 변경이 아니라, 상류의 한 파트너가 join key에 null을 보내기 시작해서 모든 null 행이 하나의 파티션으로 해시됐다는 것이었습니다. 면접관은 바로 이 순서, 즉 클러스터보다 먼저 데이터를 살펴보는 순서를 높이 평가합니다.

직무별 관련 질문 모음은 직무별 면접 질문에서 확인할 수 있습니다.

남은 질문들은 튜토리얼만 따라 해봤는지, 실제로 파이프라인을 배포해봤는지를 확인합니다.

• 데이터를 효율적으로 읽으려면 어떻게 하나요? Parquet 같은 컬럼 기반 포맷, 필터 컬럼에 대한 파티션 프루닝, 술어 푸시다운입니다. 더 적은 바이트를 읽는 것이 이후 처리를 최적화하는 것보다 나은 이유를 설명하세요.
• 왜 스키마를 추론에 맡기지 않고 직접 정의하나요? 추론은 데이터를 한 번 더 훑어야 하는 비용이 들고, 실행할 때마다 타입 추측 결과가 일관되지 않을 수 있습니다.
• null과 중복 데이터는 어떻게 처리하나요? 관련 함수 사용법과 함께, null이 많은 join key가 스큐를 만든다는 점도 짚어야 합니다.
• 윈도우 함수는 어디에 쓰이나요? 순위 매기기, 누적 합계, key별 최신 레코드로 중복 제거하기 등에 쓰이며, 파이프라인에서 매우 흔한 작업입니다.
• 작은 파일을 수천 개 만들지 않고 결과를 쓰려면 어떻게 하나요? 쓰기 전에 coalesce나 repartition을 하고, 카디널리티가 적절한 컬럼으로 출력을 파티셔닝합니다.
• PySpark 코드는 어떻게 테스트하나요? 고정된 테스트용 DataFrame을 사용하는 작은 로컬 세션과, DataFrame을 받아 반환하는 함수로 분리된 비즈니스 로직입니다.
• 작업은 어떻게 제출하고 설정하나요? executor 수, 코어, 메모리 설정과 함께, 작은 executor가 너무 많아도, 큰 executor가 너무 적어도 자원이 낭비된다는 논리입니다.

PySpark 답변은 소리 내어 말할 때 실패하는 방식이 특징적으로 드러납니다. 지원자는 셔플이 비용이 크다는 것은 알지만 어떤 연산이 그것을 유발하는지는 말하지 못해서, 답변이 형용사의 나열이 되어버립니다. 질문 모음을 읽으면 익숙한 느낌은 생기지만, 그 느낌은 누군가 기다리는 동안 설명을 전달하는 것과는 다릅니다.

직접 구축한 파이프라인 하나를 골라 읽기부터 모든 변환, stage 경계가 어디에 있는지, 느려졌다면 무엇을 먼저 확인할지까지 처음부터 끝까지 설명해 보세요. 말을 다시 시작하지 않고 끝까지 말할 수 있을 때까지 소리 내어 연습하세요. 후속 질문까지 던지는 AI 면접관을 상대로 이런 질문을 연습하는 것이 노트를 다시 읽는 것보다 실제 면접에 가깝습니다. 바로 이것이 모의 면접 모드가 만들어진 이유입니다.

SubcueAI의 창립자 Aaron Cao는 질문을 더 많이 제공하는 것이 아니라, 바로 이 말하기의 간극을 중심으로 연습을 설계했습니다. 실제 면접에서는 데스크톱 앱과 브라우저 확장 프로그램의 사이드 패널이 면접관이 말하는 동안 구조를 보여줄 수 있는데, 이는 이미 연습한 내용에서 가장 효과가 큽니다. 설정은 몇 분이면 끝나며, 자세한 내용은 튜토리얼 페이지에서 확인할 수 있습니다.