AI 에이전트가 어제는 되던 일이 오늘 안 되는 이유, Pass^k로 보는 일관성 함정

평균 정확도가 감추고 있는 것

데모에서 에이전트가 태스크를 척척 해내는 걸 보면 '이 정도면 실서비스에 넣어도 되겠다' 싶죠. 그런데 같은 질문을 다시 던지면 결과가 달라지는 경우가 많아요. 금융 거래 대사나 계약서 의무 조항 검토처럼 미션 크리티컬한 작업에서는 이 '가끔 실패'가 곧 서비스 장애로 이어집니다.

문제는 대부분의 벤치마크가 이 변동성을 평균값 뒤에 숨긴다는 거예요. IBM Research가 공개한 자료에 따르면, AppWorld에서 GPT-4.1 기반 ReAct 에이전트는 5회 반복 실행 시 평균 77.4%의 성공률(Mean@5)을 기록했어요. 그런데 5회 모두 성공한 태스크는 53.0%에 불과했습니다. 24.4%p의 차이, 이게 바로 **일관성 갭(Consistency Gap)**이에요.

💡 용어 정리

• Mean@k: k번 실행 후 평균 성공률. 리더보드에서 말하는 '정확도'.
• Pass^k: k번 모두 성공한 태스크 비율. 사용자가 체감하는 실제 신뢰성.
• Pass@k: k번 중 최소 한 번 성공. 코드 생성 논문에서 자주 쓰는 낙관적 지표.

항상 Pass^k ≤ Mean@k ≤ Pass@k가 성립합니다. 글자 하나 차이인데 질문이 정반대예요.

이건 모델을 키운다고 해결되는 문제가 아니에요. 능력(capability)과 일관성(consistency)은 서로 직교하는 축입니다. 똑똑한데 들쭉날쭉한 에이전트는 얼마든지 존재해요.

근거자료: IBM Research - ALTK-Evolve Consistency

왜 에이전트는 '뒤집히는'가: Sharp vs Flat

에이전트가 API를 고르고, 인자를 넘기고, 재시도 여부를 판단하는 모든 순간은 다음 토큰에 대한 확률 분포에서 샘플링됩니다. 중요한 건 그 분포의 '모양'이에요.

• Sharp distribution: 한 토큰에 확률 질량이 집중됨. 2등과 격차가 커서 매 실행마다 같은 선택이 나옴.
• Flat distribution: 여러 토큰이 비슷한 확률로 붙어 있음. 사실상 동전 던지기에 가까움.

Sharp한 분포는 GPU 부동소수점 비결합성, 요청 배칭 같은 플랫폼 노이즈에도 흔들리지 않아요. 반대로 Flat한 분포는 그 미세한 흔들림에 순위가 뒤집힙니다. 게다가 트래젝토리는 수십 개의 결정이 체인처럼 이어지기 때문에, 스텝당 작은 뒤집힘 확률이 누적되면 런 전체가 달라질 확률이 커져요. 24%p 갭은 여기서 나옵니다.

그래서 greedy decoding도 못 막아요

Greedy decoding이나 고정 시드는 '분포를 토큰으로 바꾸는 방식'만 통제할 뿐, 분포 자체는 건드리지 못해요. 호스팅 엔드포인트에서는 런마다 확률이 미세하게 흔들리기 때문에 temperature 0에서도 오늘은 A, 내일은 B로 갈릴 수 있습니다.

진단 → 수정 파이프라인

1단계: Consistency Analyzer로 검출

녹화된 트래젝토리 하나를 받아서, 각 결정 스텝을 controlled resampling으로 재생합니다. 결정 스텝당 모델 호출 1회, k=5 completion을 한 번에 뽑는 방식(기본값)으로 오프라인에서 딱 한 번 돌려요. 새로운 툴 호출도, 환경 상호작용도, 엔드투엔드 재실행도 없습니다. 결과는 스텝별 consistency score로 뽑혀서 스코어카드에 기록돼요. 완전한 블랙박스 — logits도, 모델 내부도, 별도 계측도 필요 없어요. 이미 가진 트레이스만 있으면 됩니다.

2단계: 타겟 가이드라인 생성

플래그된 스텝마다 ALTK-Evolve 표준 포맷의 consistency guideline 후보가 만들어져요. 실제로 GPT-4.1이 AppWorld 태스크에서 생성한 예시를 볼게요:

[Guideline 1] 노트 본문의 체크박스 마커를 셀 때는,
일반 substring count 대신 라인 앵커드 정규식을 사용할 것.
노트 제목에 범례 라인으로 같은 기호가 반복되는 경우가 많음.

[Guideline 2] 노트 검색 결과는 항상 다중 매치 여부를 확인하고,
올바른 노트인지 검증한 뒤 진행할 것.

태스크 특화 지식이 아니에요. 문자열 카운팅 버그, 검증 안 된 검색 결과는 AppWorld 전반에서 불확실성이 높게 나타나는 결정 포인트예요. Analyzer는 '실패'가 아니라 '불안정성'을 노립니다. 이번엔 우연히 맞았지만 다음엔 틀릴 수 있는 스텝을 잡아내는 거죠.

📊 주의: 여기서 말하는 가이드라인은 프롬프트 엔지니어링의 'few-shot 예시'와는 결이 달라요. 트래젝토리에서 자동 증류된 재사용 가능한 판단 규칙이라고 보시면 됩니다.

실측 결과: 갭을 절반으로, 정확도는 그대로

AppWorld test_normal(168개 태스크), GPT-4.1 ReAct 에이전트로 평가했어요. 태스크당 베이스라인 트래젝토리 1개에서 가이드라인을 뽑고, 새 런 5회로 테스트했습니다.

핵심 포인트를 짚어볼게요.

• 갭이 절반으로: Pass^5가 53% → 69%로 뛰면서 Mean@5도 77.4% → 81.0%로 올라갔어요. 이전에 불안정했던 태스크 중 약 1/3이 '매번 성공하는 태스크'로 바뀌었습니다.
• Mean@5는 절대 안 떨어짐: 이건 nice-to-have가 아니라 하드 요구사항이었어요. Mean@5를 깎아서 Pass^5를 올리는 건 불안정성을 다른 데로 옮기는 것뿐이니까요.
• 일반화됨: 같은 시나리오의 다른 변형 태스크에 적용해도 Pass^5가 +13.0pp 올라갔어요. 같은 태스크 수치(+16.0pp)보다 3pp 낮은 정도. 트래젝토리 하나를 패치하는 게 아니라 전이 가능한 패턴을 잡고 있다는 뜻이에요.
• 약한 모델에서 더 선명하게: gpt-oss-120b에서는 같은 태스크 Pass^5가 10.1% → 16.1%(+6.0pp)로 올랐는데, 유사 태스크 일반화 수치(+8.7pp)가 같은 태스크 이득을 초과했어요. 트래젝토리 암기가 아니라 재사용 가능한 실패 패턴을 잡았다는 신호입니다.

이 기술의 한계와 주의사항

• 진단 비용은 공짜가 아니에요: 결정 스텝당 LLM 호출 1회가 추가됩니다. 트래젝토리가 길면 비용이 선형으로 늘어나요. 프로덕션 트래픽에 적용할 땐 샘플링 비율을 조절하는 게 좋아요.
• k=5는 기본값일 뿐: 태스크 특성에 따라 k를 키우면 더 안정적인 진단이 가능하지만 비용도 비례해서 늘어납니다.
• 가이드라인 자체가 오염될 수 있어요: 잘못된 트래젝토리에서 뽑은 가이드라인은 오히려 해가 될 수 있어요. 검출 단계의 신뢰도 임계값 관리가 중요합니다.
• 벤치마크 특화 위험: AppWorld에서 잘 작동한다고 다른 도메인(예: 사내 워크플로우)에서도 자동으로 통한다고 가정하면 안 됩니다.

국내 개발 생태계에서의 적용 맥락

국내 SI·금융권 프로젝트에 에이전트를 붙이는 상황을 생각해보면, 이 지표가 특히 유용해요. 발주처가 원하는 건 '평균 77% 성공'이 아니라 **'같은 요청에 항상 같은 결과'**거든요. 특히 정산·대사·심사 같은 업무는 단 한 번의 뒤집힘도 감사 이슈로 이어질 수 있어요.

실무에서는 다음 순서를 추천합니다:

1. 기존 로그에서 트래젝토리 20~30개만 추출해서 Consistency Analyzer로 스코어카드를 뽑아보세요. 그라운드 트루스가 없어도 돌아갑니다.
2. 상위 불안정 스텝을 대상으로 가이드라인을 생성해 시스템 프롬프트 또는 RAG 컨텍스트에 주입하세요.
3. 배포 전 A/B로 Pass^k를 비교하세요. Mean@k만 보면 개선 여부를 놓칩니다.

관련해서 AI가 만들어낸 코드를 그대로 프로덕션에 올릴 때의 리스크 관리 전략은 AI 생성 코드 프로덕션 리스크 관리 가이드에서 더 깊게 다뤘어요. 쿠버네티스 환경에서 대화형 옵저버빌리티를 구축하는 방법도 함께 보시면 에이전트 운영 관점에서 도움이 됩니다.

실무에 에이전트를 올린다면

정리하면 이렇습니다.

• Mean@k 옆에 Pass^k를 반드시 리포트하세요. 평균만으로는 '안정적인 에이전트'와 '운 좋은 에이전트'를 구분할 수 없어요. k=3만 돌려봐도 모르고 있던 갭이 드러납니다.
• 난이도가 올라갈수록 갭은 커진다는 걸 예상하세요. 가장 어려운 티어에서 평균값은 가장 오해를 부릅니다.
• 더 큰 모델로 가기 전에 일관성부터 잡으세요. 일관성은 능력과 직교하는 축이에요. 더 강한 모델은 Mean@k를 올리지만, 갭을 자동으로 줄여주진 않습니다.
• 진단에 그레이더도, 라이브 리플레이도 필요 없어요. 결정 스텝당 LLM 호출 1회(k=5 completion)면 충분합니다. 그라운드 트루스 없이, 환경에 태스크를 다시 던지지 않고도 돌아가요. 프로덕션 트래픽에서 엔드투엔드 재실행이 불가능한 상황에서 쓸 수 있는 이유가 여기 있습니다.

다음 단계 학습 방향

1. 직접 돌려보기: ALTK-Evolve 오픈소스 리포에 Consistency Analyzer와 가이드라인 생성 코드가 포함되어 있어요. 본인 태스크에 붙여서 스코어카드부터 뽑아보세요.
2. 원 논문 읽기: 전체 방법론과 평가는 arXiv 기술 리포트에 정리되어 있습니다.
3. 평가 파이프라인 재설계: 기존 벤치마크가 Mean@k만 리포트한다면, Pass^k를 추가하는 것만으로도 팀의 의사결정 품질이 달라져요.

정확도 숫자가 본인 태스크에서 재현되지 않는다면, 그건 실력 문제가 아니라 지표 선택의 문제일 수 있어요. Pass^k부터 찍어보세요.