Gemini 3.5 Flash로 몇 분 만에 ML CI 실패의 근본 원인 찾기
손상된 ML 학습 파이프라인을 디버깅하는 일은 느리고 지루합니다. 두 개의 서로 다른 CI 실행에서 로그를 가져와 golden values와 비교하고, 회귀를 찾기 위해 커밋 기록을 뒤지며, 무엇이 왜 잘못되었는지 설명하는 보고서를 작성해야 하는 동안 팀은 기다리고 있습니다. 이 사용 사례는 그 전체 조사 과정을 자동화합니다.
ml-failure-audit 스킬을 Google의 Gemini 3.5 Flash 모델과 원격 추론 엔진으로서의 Gemini Agent API와 결합함으로써, Eigent의 멀티 에이전트 워크포스는 로그 가져오기, 기준값 추출, 증거 추적, 무거운 분석 위임, 구조화된 산출물 생성까지 CI 실패를 처음부터 끝까지 감사할 수 있습니다. 모든 과정은 단일 프롬프트로 이루어집니다.
모델로 Gemini 3.5 Flash 선택하기
Settings → Agents → Model로 이동해 클라우드 모델 목록에서 Gemini 3.5 Flash를 선택하세요. 자체 API 자격 증명을 사용하고 싶다면 Settings → API Keys → Gemini 아래에 Gemini 키를 입력하여 직접 사용할 수 있습니다.
Gemini 3.5 Flash는 긴 컨텍스트 작업에서 빠르고 비용 효율적인 추론에 최적화되어 있으며, 이는 정확히 CI 로그 분석이 요구하는 방식입니다.
Gemini Agent API를 원격 서브 에이전트로 활성화하기
Settings → Agents → Remote Agents로 이동해 Gemini Agent API를 켜세요. 그러면 Gemini Agent가 Eigent 워크포스 내부에서 호출 가능한 서브 에이전트로 등록됩니다.
활성화되면 Developer Agent는 수백 줄의 로그에 걸친 근본 원인 분석처럼 계산 집약적인 추론 작업을 하나의 모델 호출에 모두 처리하는 대신, 이를 Gemini Agent에 직접 넘길 수 있습니다. 이렇게 하면 두 단계 구조가 됩니다. Eigent의 로컬 에이전트는 오케스트레이션과 도구 사용을 맡고, Gemini Agent는 심층 추론을 담당합니다.
ml-failure-audit 스킬 업로드하기
Settings → Agents → Skills로 이동해 ml-failure-audit 스킬 패키지를 업로드하세요. **Skill Hub: ml-failure-audit**에서도 스킬 상세 정보와 설치 단계를 확인할 수 있습니다. 이 스킬은 CI 실패 감사를 위해 Eigent가 어떤 방식으로 접근해야 하는지 정의합니다. 어떤 산출물을 수집할지, 어떤 비교를 실행할지, 어떤 증거를 모을지, 최종 보고서를 어떻게 구성할지까지 포함합니다.
업로드가 완료되면 워크포스의 어떤 에이전트든 ML 감사 작업을 처리할 때 이 스킬을 호출할 수 있습니다.
작업을 Eigent에 보내기
모든 구성이 끝났다면 Eigent의 채팅에 작업 프롬프트를 입력하세요:
{{ml-failure-audit}} 스킬을 따르고, 복잡한 하위 작업은 원격 서브 에이전트를 사용해 마무리하세요.
Megatron-LM MIMO VLM 사전학습 golden metric CI 실패를 감사해 주세요. 로컬 NVIDIA/Megatron-LM checkout이 <your-commit-sha> 커밋에 있으며, 첨부한 CI 산출물(예: 성공/실패 실행 로그)도 함께 제공합니다. 실패한 워크로드는 sequence packing을 사용하는 8-GPU frozen start convergence check이며, global batch size는 32, total packed sequence length는 3200, packing buffer는 4, training iterations는 100입니다.
이 실패가 실제 모델 convergence/correctness regression인지, 아니면 metric/gating policy 문제인지 판단해 주세요. 저장소의 golden value comparison 코드와 CI 로그를 증거로 사용해 주세요. GPU training은 다시 실행하지 마세요.
repository URL, 대상 commit checkout, 그리고 비교하고 싶은 CI 산출물을 첨부한 상태에서 repo root에 source_refs, extracted_facts, calculations, final_answer, validation이 포함된 answer.json을 생성해 주세요. 간결한 answer.md도 함께 만들어 주세요.
Eigent는 즉시 조사를 계획하기 시작합니다.
프롬프트를 실행하기 전에 ml-failure-audit 스킬을 설치하세요.
입력은 직접 제공하세요: <your-commit-sha>를 감사할 커밋으로 바꾸고, 작업 공간에서 해당 리비전을 체크아웃한 뒤, 비교하고 싶은 CI 산출물(예: 성공 vs 실패 실행 로그, stderr 캡처, 또는 내보낸 CI 작업 출력)을 첨부하세요. Megatron-LM 예시를 조사 중인 어떤 저장소와 실패에도 맞게 변형할 수 있습니다.
Coordinator Agent가 작업을 계획하고 할당하기
Eigent의 Coordinator Agent는 프롬프트를 읽고 이를 구조화된 감사 계획으로 분해합니다. 핵심 단계(로그 가져오기, 데이터 추출, 증거 추적, 보고서 생성)를 식별한 뒤 전체 조사를 Developer Agent에 할당합니다.
Coordinator는 단순히 무작정 위임하지 않습니다. 스킬 참조, 저장소 컨텍스트, CI 로그 산출물을 함께 전달해 Developer Agent가 필요한 모든 것을 갖춘 상태에서 시작하도록 합니다.
Developer Agent가 스킬을 불러오고 로그를 가져오기
Developer Agent의 첫 번째 작업은 ml-failure-audit 스킬을 불러와 그 지침을 읽고 감사 방법론을 이해하는 것입니다.
그다음 4개의 명령을 병렬로 실행해 CI 로그 데이터를 가져오며, 두 개의 실패 로그와 관련 메타데이터를 동시에 수집합니다. 병렬 도구 실행 덕분에 데이터 수집 단계는 순차적으로 진행할 때보다 훨씬 짧은 시간에 끝납니다.
Golden Values를 추출하고 수정 커밋을 추적하기
로그를 확보한 후 Developer Agent는 Python 스크립트를 실행해 golden reference values를 추출합니다. 이는 성공적인 CI 실행이 생성해야 하는 예상 학습 메트릭, loss curve, 벤치마크 수치입니다. 그런 다음 이를 실패 로그에 기록된 값과 비교해 정확히 어디서, 얼마만큼 차이가 발생했는지 파악합니다.
이후 Developer Agent는 Megatron-LM 커밋 기록을 검색해 회귀의 원인이 되었을 가능성이 가장 높은 특정 코드 변경인 fix commit을 찾습니다. 이 커밋은 감사 보고서의 구체적인 증거가 되어, 관찰된 실패와 근본적인 코드 변경 사이의 직접적인 연결고리를 리뷰어에게 제공합니다.
깊은 추론을 Gemini Agent에 위임하기
원시 증거(log diff, golden value comparison, 추적된 커밋)가 모두 준비되면 Developer Agent는 Gemini Agent를 호출해 무거운 추론 단계를 수행하게 합니다.
Gemini Agent는 코드에서 무엇이 바뀌었는지, 그 변경이 학습 동작에 어떻게 영향을 미쳤는지, 가장 가능성 높은 근본 원인이 무엇인지 전체 맥락을 분석합니다. 몇 분 후, 실패 진단, 기여 요인, 권장 수정 사항을 포함한 완전하고 구조화된 감사 보고서를 반환합니다.
Developer Agent가 최종 감사 보고서를 작성하기
Developer Agent는 Gemini Agent의 분석을 바탕으로 작업 공간에 두 가지 산출물을 작성합니다:
-
answer.json: 실패 유형, 근본 원인, 영향을 받은 메트릭, 증거 커밋, 권장 해결책을 구조화된 필드로 담은 기계 판독 가능한 감사 기록입니다. 자동화 파이프라인, 티켓 시스템, CI 대시보드에 유용합니다. -
answer.md: 무엇이 실패했는지, 왜 실패했는지, 증거는 무엇인지, 다음에 무엇을 해야 하는지를 다루는 간결한 사람 친화적 감사 요약입니다. PR 코멘트, Slack 스레드, 인시던트 보고서에 바로 붙여넣을 수 있습니다.
두 파일 모두 작업 공간 폴더에 직접 작성되며 즉시 접근할 수 있습니다.
이 워크플로가 중요한 이유
ML CI 실패는 밀도 높은 로그 출력 속에 신호가 묻혀 있고, 근본 원인이 종종 증상보다 여러 커밋 뒤에 있기 때문에 디버깅이 매우 어렵기로 유명합니다. 이 워크플로는 세 가지 기능이 함께 작동하도록 하여 이를 해결합니다:
- 병렬 로그 가져오기로 산출물을 하나씩 가져오는 순차적 병목을 없앱니다.
- Python 기반 golden value 추출은 패턴 매칭이나 수동 검토에 의존하지 않고 정밀한 수치 비교를 적용합니다.
- 추론 서브 에이전트로서의 Gemini Agent는 가장 복잡한 추론 단계를 그에 최적화된 모델에 오프로딩하여 오케스트레이션은 가볍게, 분석은 깊게 유지합니다.
그 결과, 엔지니어가 30~60분 동안 집중해서 해야 할 근본 원인 감사 작업이 몇 분 만에 구조화된 산출물 추적과 함께 제공됩니다.
다음에 시도해 볼 것
첫 번째 감사가 끝나면 다음과 같은 후속 프롬프트로 워크플로를 확장해 보세요:
가장 최근의 CI 실패 3건에 동일한 감사를 실행하고 근본 원인을 비교하세요.
수정 커밋을 찾은 뒤, 감사 보고서가 미리 채워진 상태로 GitHub issue를 여세요.
매일 밤 새로 발생한 CI 실패를 감사하고 answer.md를 Slack에 게시하도록 트리거를 예약하세요.
다른 모델로 바꿔서 더 깊은 분석이 필요하면 Gemini 3.5 Pro를, 더 빠른 처리 시간이 필요하면 Gemini Flash Lite를 사용해 보세요.
더 나은 결과를 위한 팁
- CI 산출물을 명시적으로 첨부하세요. ml-failure-audit 스킬은 비교하려는 커밋 checkout과 로그 또는 내보낸 결과물(예: 성공 실행과 실패 실행)을 함께 제공할 때 가장 잘 작동합니다.
- repository URL을 포함하세요. Developer Agent는 이를 사용해 커밋 기록에서 fix commit을 찾습니다. 저장소로 바로 연결되는 링크가 있으면 검색 단계를 줄일 수 있습니다.
- 출력 파일을 지정하세요.
answer.json과answer.md둘 다 요청하면 Developer Agent가 두 형식 모두 생성하도록 지시할 수 있어, CI 파이프라인용 기계 판독 가능한 출력과 팀용 사람 친화적 출력을 모두 필요로 할 때 유용합니다. - 추론이 필요한 작업에는 Gemini Agent를 사용하세요. 원격 서브 에이전트 패턴은 로컬 에이전트가 데이터 수집을 담당하고 Gemini Agent가 종합을 담당할 때 가장 효과적입니다. 로컬 도구 사용으로 더 빠르게 처리할 수 있는 단순 조회에 호출하지 마세요.
