Medic for Apache Spark - First Aid for Failing Jobs - Drasko Profirovic, Pinterest

한 줄 핵심

Pinterest는 Spark 실패 원인을 자동으로 진단하는 Medic를 MCP, 평가 하네스, 로그·메트릭 처리 개선, 멀티 에이전트 구조로 고도화해, 사람이 하던 난해한 장애 분석을 재현 가능하고 확장 가능한 진단 시스템으로 바꿨다.

시간별 요약

1. 0:01
   Spark 장애 지원은 분산 시스템 특성상 원인 파악이 어렵고 우선순위 충돌도 잦아서, 사람이 즉답하기보다 확장 가능한 진단 에이전트가 필요하다. 목표는 "왜 job이 실패했는가"에 대해 근거가 있는 리포트와 상황에 맞는 수정안을 제공하는 것이다.
2. 2:00
   초기에는 MCP로 데이터 리소스를 연결하고 단일 React 에이전트에 문제 해결 프롬프트를 몰아넣는 방식으로 시작했지만, 답변 품질이 들쭉날쭉했고 프롬프트 튜닝이 한계에 부딪혔다. 대용량 로그와 프로덕션 컨텍스트는 context window를 쉽게 소모해 추론이 멈추는 문제가 드러났다.
3. 4:01
   품질을 끌어올리기 위해 관측성과 테스트 가능성을 먼저 강화했다. OpenTelemetry를 LangFuse에 보내 실행 과정을 추적하고, production state를 record/playback 하는 end-to-end test harness와 offline eval로 리포트 품질을 수치화해 회귀를 막았다.
4. 6:02
   로그는 단순한 regex 필터로는 확장되지 않아 exception classifier pipeline을 도입했다. 성공한 job에 자주 등장하는 예외를 red herring으로 학습해 걸러내고, 상위 K개의 압축 예외와 특정 예외의 전체 로그만 MCP 도구로 제공함으로써 신호 대비 잡음을 크게 높였다.
5. 7:00
   메트릭은 원시 시계열을 그대로 넣는 대신 quarantine sub-agent가 그래프 이미지로 요약해 context 효율을 높였다. 이후 단일 에이전트를 역할 분리된 multi-agent 구조로 바꾸고, triage·research·healer·supervisor가 분업하면서 실패 원인 추정, 근거 수집, runbook 기반 복구 제안, 최종 보고서 조립까지 더 안정적으로 수행하게 됐다.

실무 인사이트

• 장애 진단 에이전트의 성능은 모델 자체보다도 로그·메트릭 전처리, context budget, 출력 제약, 평가 체계에서 더 크게 좌우된다.
• 프롬프트 하나로 모든 일을 시키기보다 역할별 에이전트와 전용 도구를 나누면 품질·유지보수·회귀 테스트가 동시에 좋아진다.
• 프로덕션 자동화는 감으로 개선하기보다 record/playback 테스트와 offline eval로 품질을 계량화해야 안전하게 확장된다.