Cisco FAPO 공개 — 단계별 실패 추적으로 LLM 파이프라인을 자동으로 튜닝

개요

프롬프트 한 줄을 바꿨더니 정확도가 20%p 흔들렸다는 이야기, 한 번쯤 들어보셨을 겁니다. Cisco AI가 공개한 FAPO(Fully Automated Prompt Optimization) 는 바로 이 문제를 정면으로 다룹니다. 단순히 프롬프트만 다듬는 도구가 아닙니다. 멀티 스텝 LLM 파이프라인의 어느 단계에서, 왜 실패했는지를 분류하고, 프롬프트·파라미터·체인 구조까지 단계적으로 손봅니다. 게다가 이 모든 과정을 Claude Code나 Codex 같은 코딩 에이전트가 자율적으로 굴립니다.

GitHub에 Apache 2.0 라이선스로 풀려 있어서, 다국적 기업 인프라가 아니어도 손에 잡아 볼 수 있는 점이 매력입니다.

핵심 요약

• 3단계 에스컬레이션 — 프롬프트 수정 → 파라미터(검색 k값, temperature 등) → 체인 구조 변경 순으로 비용을 단계적으로 올린다.
• 단계별 실패 분류 — Retrieval, Cascading, Format, Reasoning 네 가지로 나눠 어느 노드를 고쳐야 하는지 짚어 준다.
• HoVer 35.9 → 83.8 — 동일 모델, 동일 평가에서 GEPA 대비 평균 +14.1pp 우위. 18개 비교 중 15개 승.
• Claude Code / Codex 오케스트레이션 — 사람이 매번 개입하지 않고, 코딩 에이전트가 6단계 루프(Evaluate → Iterate)를 자율적으로 반복.
• 데이터 누수 방지 설계 — 학습 분할에서만 관찰, 변형 파일은 불변, 모든 제안은 독립 리뷰어가 검증.

FAPO가 풀려는 문제 — 프롬프트만 고치면 끝이 아니다

기존 자동 프롬프트 최적화 도구는 대부분 프롬프트 텍스트만 손봅니다. 그런데 실제 LLM 파이프라인에서는 단일 프롬프트가 답을 만드는 일이 드뭅니다. 검색이 빈약하거나, 앞 단계 출력이 비어서 뒷단이 무너지거나, 답은 맞는데 포맷이 깨져서 파싱이 실패합니다. 프롬프트만 만져서는 못 풀 문제가 더 많다는 뜻입니다.

FAPO는 이 지점을 짚고 들어갑니다. 파이프라인 인지(pipeline-aware) 라는 표현 그대로, 체인 각 노드의 입출력을 직접 들여다보고 실패 원인을 분리합니다.

실패를 네 갈래로 나누기

1. Retrieval 실패 — 검색 결과가 비어 있거나, 질문과 거리가 먼 문서가 올라옴.
2. Cascading 실패 — 초반 단계가 빈 출력이라 후속 단계가 도미노처럼 무너짐.
3. Format 실패 — 정답은 안에 있는데 JSON 키, 마크다운 헤더 같은 형식이 어긋나 파서가 못 잡음.
4. Reasoning 실패 — 입력은 멀쩡한데 모델이 잘못된 결론으로 점프.

각 카테고리는 처방이 다릅니다. Format 실패라면 출력 스키마를 강제하는 쪽으로, Retrieval 실패라면 검색 k값을 키우거나 임베딩을 바꾸는 식이죠.

6단계 최적화 루프 — Claude Code가 직접 돌리는 사이클

FAPO는 다음 여섯 단계를 정해진 순서대로 반복합니다. 표지 이미지의 다이어그램이 바로 이 루프입니다.

1. Evaluate — 체인을 굴려 점수와 각 단계의 출력을 수집.
2. Attribute — 위 네 가지 카테고리로 실패의 근본 원인을 분류.
3. Propose — 원인에 맞춰 변형(variant)을 생성. 프롬프트만 바꿀지, 파라미터를 만질지, 구조까지 갈지 결정.
4. Review — 독립 리뷰어가 변형이 데이터 누수나 평가 범위를 벗어나지 않는지 확인.
5. Compare — 검증 셋에서 베이스라인보다 분명히 좋아질 때만 채택.
6. Iterate — 목표 정확도에 닿을 때까지 반복.

핵심은 4번 Review 단계입니다. 에이전트가 스스로 좋은 답을 만들어 내기 시작하면, 평가용 데이터까지 슬쩍 넘보는 일이 생기기 쉬운데 FAPO는 학습 분할만 관찰하도록 강제하고, 변형 파일을 불변(immutable)으로 묶어 둡니다. 평가 무결성을 지키는 안전장치를 처음부터 박아 둔 셈입니다.

3단계 에스컬레이션 — 싸게 고치고, 안 되면 깊게 들어간다

FAPO의 또 한 가지 특징은 돈과 위험을 단계적으로 키운다는 점입니다.

가벼운 수정으로 풀리면 그대로 끝내고, 안 풀리면 다음 레벨로 올라갑니다. 프롬프트만 바꿔도 될 일에 굳이 노드를 새로 박을 이유가 없으니까요.

성능 — HoVer와 IFBench에서 두 자릿수 점프

벤치마크 표를 보면 GEPA(기존 강자) 대비 격차가 큽니다.

특히 멀티 홉 추론이 핵심인 HoVer에서 35.9 → 83.8은 단순 프롬프트 손질로는 나오기 어려운 숫자입니다. 단계별 실패 추적과 구조 변경이 동시에 들어갔기 때문에 가능한 수치죠. 18개 모델·벤치마크 조합 중 15개에서 GEPA를 이겼고, 평균 격차가 +14.1pp 입니다.

기술 스택 — LangGraph + hephaestus 엔진

내부 구조는 의외로 단정합니다.

• 엔진: 도메인 무관(domain-agnostic) hephaestus 코어
• 체인 정의: LangGraph 상태 그래프
• 모델 제공자: OpenAI, Baseten, SageMaker
• 오케스트레이터: Claude Code 또는 Codex 에이전트

사용자는 입력과 기대 출력을 짝지은 데이터셋만 던져 주면 됩니다. FAPO가 검증/테스트 분할을 자동으로 잘라 베이스라인을 측정하고, 그 뒤로는 위의 6단계 루프를 알아서 돌립니다.

시작하는 법

GitHub 저장소(cisco-foundation-ai/fully-automated-prompt-optimization)를 클론한 뒤, case_id, task_type, context, expected, metadata 필드를 가진 JSONL 데이터셋과 채점 로직만 준비합니다. CLI로 베이스라인 평가를 한 번 돌리면, 이후부터는 에이전트가 자율적으로 반복하면서 점수를 올립니다.

어디에 쓸 만한가

• 멀티 홉 QA — 데모에서 39.3% → 70.3% 향상.
• 포맷 강제가 중요한 지시 따르기 — IFBench 강세가 이를 보여 줍니다.
• 분류 작업 — 라벨 일관성과 포맷이 동시에 중요한 경우.
• ReAct 스타일 에이전트 — 도구 호출과 추론을 섞는 구조의 튜닝.

실무자가 볼 핵심 포인트

• 프롬프트 한 줄이 답이 아닐 수 있다. 검색·파싱·체인 구조까지 의심하는 습관이 필요합니다. FAPO의 네 가지 실패 분류는 디버깅 체크리스트로도 쓰기 좋습니다.
• 데이터셋이 곧 성능의 천장이다. FAPO는 입력·기대 출력 페어 품질에 절대적으로 의존합니다. 라벨 노이즈와 커버리지부터 점검하세요.
• 에이전트에게 평가 셋을 보여 주지 말 것. 학습 분할만 관찰, 변형 파일 불변, 독립 리뷰어. 이 세 가지는 FAPO를 안 써도 사내 자동화에 그대로 가져갈 가치가 있습니다.
• 에스컬레이션 사다리를 따라가라. 프롬프트 → 파라미터 → 구조 순서를 지키면 변경 추적과 롤백이 훨씬 수월합니다.
• 에이전틱 코딩 도구가 전제다. Claude Code나 Codex 같은 코딩 에이전트가 없으면 FAPO의 자율 루프가 제 힘을 못 냅니다. 도입 전에 팀의 에이전트 운영 역량부터 점검해 두세요.

한계도 분명하다

• 최적화 품질은 데이터셋 품질·커버리지에 그대로 끌려갑니다.
• 공개된 지 얼마 안 된 프로젝트라 장기 운영 사례가 부족합니다.
• 단독 최적화 도구가 아니라, 에이전트 환경을 전제로 합니다. 가벼운 스크립트 한 줄로 쓰는 도구를 원하면 결이 다릅니다.

그래도 멀티 스텝 파이프라인을 굴리는 팀이라면 한 번쯤 붙여 볼 만한 자산입니다. 무엇보다 평가 무결성을 지키면서 자율 최적화를 돌리는 설계 자체가, 비슷한 사내 도구를 만들 때 참고할 만한 청사진이 됩니다.

원문 출처

원문 보기 · MarkTechPost (Asif Razzaq, 2026-06-20)