카카오의 데이터 흐름을
설계한 엔지니어

카카오 데이터 엔지니어 면접에서 이 질문은 Kafka 아키텍처 이해도와 실시간 파이프라인 트러블슈팅 역량을 동시에 검증합니다. 답변은 반드시 STAR 구조(상황→과제→행동→결과)로 구성하세요.

1. 상황(Situation) 설정: "일별 수억 건 이벤트를 처리하는 Kafka 파이프라인에서 특정 파티션에 처리 지연이 집중되는 현상을 발견했습니다. 모니터링 대시보드(Grafana)에서 lag이 기하급수적으로 증가하는 것을 p99 레이턴시 그래프로 확인했습니다."

2. 근본 원인 탐색(Task): "Consumer Group의 partition.assignment.strategy 설정이 RoundRobin이 아닌 Range로 설정되어 있어, 특정 Consumer 인스턴스에 파티션이 과도하게 할당된 것이 원인이었습니다. Kafka 내부 로그와 JMX 메트릭을 5 Whys 방법론으로 파고들어 규명했습니다."

3. 해결(Action): "RoundRobin 전략으로 변경하고, 동시에 파티션 개수를 Consumer 인스턴스 수의 배수로 재설계했습니다. 또한 consumer.lag.monitoring Alert Rule을 설정하여 동일 문제의 조기 감지 체계를 구축했습니다."

4. 결과(Result): "재배분 정책 적용 후 p99 레이턴시를 기존 대비 80% 단축했고, 이후 3개월간 파티션 불균형 장애가 재발하지 않았습니다."

이 질문은 Spark 내부 동작 원리 이해 + 대용량 파이프라인 설계 경험을 검증합니다. "Spark를 사용했다"는 단계를 넘어, 왜 특정 최적화 선택을 했는지 이유를 반드시 설명해야 합니다.

파티셔닝 전략: "데이터 스큐(Data Skew) 문제로 일부 Executor에만 부하가 집중되는 현상이 발생했습니다. 핫 키(hot key)를 분석한 결과 카테고리 코드가 심각하게 불균등 분포임을 확인했습니다. 솔트(Salt) 기법으로 핫 키에 난수 접두사를 붙여 파티션을 재분산했고, repartitionByRange() 대신 repartition() + coalesce()를 목적에 따라 분리 적용했습니다."

셔플 최적화: "spark.sql.shuffle.partitions 기본값(200)이 데이터 규모와 맞지 않아 소규모 파티션이 다수 생성되는 문제를 발견했습니다. 데이터 규모와 Executor 코어 수를 고려해 적정 파티션 수를 산출했고, Broadcast Join을 활용해 소규모 차원 테이블의 셔플을 완전히 제거했습니다."

수치 결과: "이러한 최적화를 통해 일별 300GB 로그 처리 시간을 4.2시간에서 47분으로 단축했습니다(약 6배 개선). 동시에 클러스터 자원 사용률을 40% 줄여 인프라 비용도 절감했습니다."

카카오 연결: "카카오의 대규모 서비스(카카오톡, 픽코마 등)에서 발생하는 수십 TB 규모의 배치 처리에도 동일한 최적화 접근법을 적용할 수 있으며, 특히 MLOps 파이프라인의 피처 엔지니어링 단계에서 핵심 병목을 해소할 수 있다고 판단합니다."