이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
Spark를 처음 써본 건 졸업 프로젝트에서 로그 데이터 1억 건 처리를 단일 머신으로 하다가 시간이 너무 걸려서였습니다. 분산 처리가 뭔지 개념만 알고 있었는데, 실제로 클러스터를 로컬에서 띄워보고 스테이지 분리와 셔플 비용이 병목이라는 걸 직접 확인했습니다. 처음 짠 코드가 오히려 단일 처리보다 느렸는데, 그 이유가 파티셔닝 전략이 잘못됐기 때문이었습니다.
키를 제대로 고르지 않아서 특정 익스큐터에 데이터가 쏠렸습니다. 이후 파티션 수를 조정하고 브로드캐스트 조인을 적용하면서 처리 시간이 8배 줄었습니다. Flink는 실시간 처리를 따로 공부하면서 개념만 잡고 있고, 아직 제품 수준으로 써본 적은 없습니다. 그 프로젝트 이후로 분산 처리 코드를 짜기 전에 데이터 흐름을 먼저 그리는 습관이 생겼습니다.
Spark 이후 스트리밍 처리에 대해서도 공부한 경험이 있습니다. Spark는 배치 처리에 강하지만, 실시간으로 들어오는 이벤트를 처리해야 할 때는 구조 자체가 달라야 한다는 걸 이해했습니다. Flink가 이벤트 타임 처리와 상태 관리에서 강점을 갖는 이유를 학습하면서, 어떤 파이프라인에 어느 기술이 맞는지를 판단하는 기준이 생겼습니다.
배치로 처리하면 되는 것과 실시간으로 처리해야 하는 것을 구분하는 것이 기술 선택보다 더 먼저 해야 하는 판단이라는 걸 배웠습니다. 실시간 분석이 필요한 케이스에서 Flink 기반 파이프라인을 설계하는 프로젝트를 개인 스터디로 진행해봤습니다. 아직 프로덕션 경험은 없지만, 기술의 트레이드오프를 이해하고 상황에 맞게 고르는 관점은 갖추고 있습니다.
기술보다 문제의 특성이 기술 선택을 결정한다고 생각합니다. 이벤트 타임 처리가 스트리밍 파이프라인의 핵심 개념입니다.
대용량 데이터 처리 경험에서 설계 단계에서 고려해야 할 것이 많다는 걸 배웠습니다. 단순히 데이터를 빠르게 처리하는 것보다 어떻게 저장하고 어떻게 쿼리할지를 함께 설계해야 전체 파이프라인이 효율적으로 작동합니다. 파티셔닝이나 클러스터링 방식이 쿼리 패턴과 맞지 않으면 파티션 편향(skew)처럼 처리 시간이 특정 작업에 몰리는 문제가 생깁니다.
데이터 엔지니어링은 데이터를 이동시키는 것이 아니라 파이프라인 전체를 설계하는 것이라는 관점이 생겼습니다. 처리 속도를 개선하려면 어디가 병목인지를 먼저 측정해야 한다는 원칙도 그때 만들었습니다. 대용량 처리를 경험하면서 규모가 커질수록 설계 결정의 영향이 커진다는 걸 실감했습니다.
큰 데이터를 다룰수록 설계가 코드보다 중요합니다. 파티션 편향(skew) 관리가 분산 처리의 흔한 병목입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.