이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
학부 졸업 프로젝트에서 IoT 센서 5만 건 이상의 배치 데이터를 처리해야 하는 상황이 있었습니다. 처음에는 단순 pandas 루프로 처리했는데, 로컬에서 30분 이상 걸렸습니다. Spark를 써보려 했지만 팀 환경에 Spark 클러스터를 올리는 게 어려웠고, 대신 Dask를 선택해 단일 머신에서 멀티코어를 활용했습니다.
파티셔닝 단위를 잘못 설정해서 메모리 오버플로가 난 적이 있었는데, 그때 청크 사이즈를 조정하면서 메모리와 속도의 균형을 맞추는 방법을 익혔습니다. 최종적으로 처리 시간이 4분대로 줄었고, 결과 파일은 Parquet으로 저장해 재사용 속도도 높였습니다. 분산 처리를 처음 배울 때 클러스터 없이도 시작할 수 있다는 걸 그 과정에서 알게 됐습니다.
Dask로 분산 처리를 처음 설정하면서 파티셔닝 단위를 잘못 잡아 메모리 오버플로가 난 경험이 있습니다. 청크 사이즈를 너무 크게 설정해서 각 파티션이 메모리를 초과하는 상황이 반복됐습니다. 처음에는 전체 코드 구조 문제라고 생각했는데, Dask 대시보드로 메모리 사용 패턴을 보니 파티션마다 할당량이 균일하지 않다는 것을 확인했습니다. 청크 사이즈를 조정하면서 처리 속도와 메모리 균형을 맞추는 실험을 몇 번 반복했습니다.
처음 설정이 맞을 것이라고 가정하지 않고 실행 결과를 모니터링하는 습관이 생긴 것이 이 경험의 결과였습니다. 분산 처리는 구현이 아니라 측정하고 조정하는 과정이라는 것을 그때 배웠습니다.
대량 데이터 처리 결과를 Parquet 형식으로 저장한 것이 이후 작업 속도에 큰 차이를 만든 경험이 있습니다. 처음에는 CSV로 저장했는데, 이후 분석에서 파일을 불러올 때마다 파싱에 시간이 많이 걸렸습니다. Parquet로 바꾸자 같은 파일을 로드하는 시간이 크게 줄었고, 컬럼 단위 쿼리도 훨씬 빨라졌습니다. 처리와 저장을 별개로 생각했는데, 처리 결과가 어떻게 사용되는지를 먼저 생각하면 저장 형식 선택이 달라진다는 것을 배웠습니다. 데이터 파이프라인에서 저장 형식은 단순한 선택이 아니라 이후 모든 작업의 속도에 영향을 주는 결정이라는 것을 그때 이해했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 데이터 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.