지난 글에서 트레이스를 남기는 이야기를 했다. 기록이 갖춰지면 그다음에 하게 되는 일이 실패한 작업을 열어 보는 것인데, 여기서 대부분 같은 함정에 빠진다. 마지막 걸음을 본다.
답이 이상하니 답을 만든 걸음을 보고, 거기서 프롬프트를 고친다. 그런데 대개 그 걸음은 자기가 받은 것을 성실하게 처리했을 뿐이다. 어긋난 자리는 세 걸음 앞이다.
한 걸음이 무너지는 여섯 자리
에이전트의 한 걸음은 여섯 단계로 나뉘고, 실패는 그중 한 자리에서 시작한다.
이 여섯을 구분하는 이유는 처방이 전부 다르기 때문이다. 도구 설명이 모호해서 난 문제에 프롬프트의 지시문을 더 붙여도 안 낫고, 종료 조건이 없어서 도는 문제에 도구를 더 붙이면 더 오래 돈다.
증상에서 자리를 거슬러 찾기
실무에서 보는 것은 증상이고 고쳐야 하는 것은 자리다. 자주 나오는 증상과 그 뒤에 있는 자리를 정리하면 이렇다.
| 증상 | 대개 어긋난 자리 | 확인하는 법 | 처방 |
|---|---|---|---|
| 조건 하나가 무시된 답 | 1. 이해 | 첫 걸음의 계획에 그 조건이 적혀 있는가 | 요청을 조건 목록으로 먼저 풀어 적게 한다 |
| 같은 조회를 조금씩 바꿔 반복 | 2. 계획 | 도구 인자 로그를 걸음 순서로 나열해 본다 | 종료 조건 명시, 진척 지표, 걸음 상한 |
| 있는 기능인데 「할 수 없다」 | 3. 도구 선택 | 그 도구 설명과 이웃 도구 설명을 나란히 읽는다 | 이름·설명에서 겹치는 부분 제거 |
| 도구가 400을 계속 뱉음 | 4. 인자 채우기 | 실패한 호출의 인자를 스키마와 대조 | 스키마 단순화, 예시 추가, 오류를 사람 말로 |
| 근거 없이 단정한 답 | 5. 결과 해석 | 그 주장의 근거가 된 도구 결과를 열어 본다 | 빈 결과를 다르게 다루도록 명시 |
| 절반만 하고 끝냄 | 6. 종료 판단 | 계획의 항목과 실제 밟은 걸음을 대조 | 완료 조건을 점검 목록으로 |
확인하는 법 칸이 이 표의 핵심이다. 증상만 보고 자리를 짐작하지 말고 트레이스에서 그것을 열어 확인한 다음 고친다. 같은 증상이 다른 자리에서 오는 경우가 흔하다 — 「절반만 하고 끝냄」은 종료 판단 문제일 때도 있지만 애초에 계획에 절반만 있었던 경우도 많다.
가장 비싼 실패는 조용한 실패
여섯 중 5번이 유독 나쁘다. 오류가 안 나고 로그가 깨끗한데 답만 틀리기 때문이다.
전형적인 모양은 이렇다. 조회 도구가 결과 0건을 돌려준다. 에이전트가 그것을 「없는 것이 확인됨」으로 읽고 다음으로 넘어간다. 그런데 실제로는 검색어를 잘못 넣어서 0건이었다. 이후 걸음은 전부 「없다」는 잘못된 전제 위에 쌓이고, 최종 답은 자신 있게 틀린다.
여기서 문제는 모델이 아니라 도구가 두 가지 다른 상황을 같은 값으로 돌려준다는 것이다. 「찾아봤고 정말 없다」와 「질의가 이상해서 못 찾았다」가 둘 다 빈 배열이다.
그래서 처방은 프롬프트가 아니라 도구 쪽에 있다.
- 빈 결과에 이유를 함께 돌려준다 — 「조건에 맞는 항목 없음. 검색한 범위: 2026-01~08」
- 성공과 실패를 값으로 구분한다 — 빈 배열과 오류를 같은 자리에 넣지 않는다
- 결과의 신뢰도를 함께 준다 — 유사도 점수가 낮으면 「관련 있는 결과 없음」이라고 말해 준다
도구 스키마 설계에서 다룬 원칙이 여기서 다시 나온다. 도구의 반환값은 모델이 읽는 문장이므로, 애매하게 쓰면 애매하게 읽힌다.
루프는 오류가 아니라 진척으로 잡는다
2번 자리의 실패, 즉 끝나지 않는 루프도 흔하고 비싸다. 이것을 오류 횟수로 잡으려는 시도가 자주 있는데 안 된다. 루프는 오류 없이도 돈다. 검색을 조금씩 바꿔 가며 100번 하는 동안 모든 호출이 200을 돌려준다.
잡는 방법은 진척을 재는 것이다.
- 최근 다섯 걸음 동안 작업 기록의 「어디까지」가 안 움직였으면 돌고 있는 것이다
- 같은 도구를 비슷한 인자로 세 번 이상 불렀으면 신호다. 인자를 정규화해 해시로 세면 쉽게 잡힌다
- 계획의 항목이 하나도 완료로 바뀌지 않은 채 걸음만 늘고 있으면 신호다
잡은 뒤의 처리도 정해 둔다. 그냥 멈추는 것보다 한 번은 스스로 빠져나올 기회를 주는 편이 낫다. 「같은 접근을 반복하고 있습니다. 다른 방법을 쓰거나, 못 하겠으면 지금까지 알아낸 것을 정리하고 끝내세요」를 문맥에 넣어 주면 상당수는 거기서 정리하고 나온다. 그래도 안 되면 멈춘다.
회복은 걸음이 아니라 작업 단위로 설계한다
실패를 다루는 마지막 조각은 「어디까지 되돌릴 것인가」다. 대부분의 구현이 걸음 단위 재시도만 갖고 있는데, 그것으로 안 되는 실패가 있다.
| 무엇이 실패했나 | 어디로 돌아가나 |
|---|---|
| 도구 호출이 일시적으로 실패 | 그 호출만 다시 |
| 인자를 잘못 채움 | 그 걸음을 오류 내용과 함께 다시 |
| 도구 선택이 틀림 | 그 걸음 앞으로 돌아가 다른 도구를 고르게 |
| 계획이 틀림 | 계획 세우는 자리로 돌아가 다시 세우게 |
| 요청 이해가 틀림 | 사람에게 되묻는다 |
아래 둘이 대개 빠져 있다. 계획이 틀렸는데 걸음 단위 재시도만 있으면, 에이전트는 틀린 계획의 다음 항목을 성실하게 계속 수행한다. 「계획을 다시 세운다」가 가능한 동작으로 들어 있어야 한다.
그리고 맨 아래 줄이 중요하다. 어떤 실패는 고칠 수 없고 되물어야 한다. 요청이 애매해서 생긴 실패를 에이전트 혼자 반복해서 푸는 것은 비용만 쓰고 답은 안 나오는 가장 나쁜 조합이다. 사람을 어디에 붙일지 정할 때 되묻는 자리도 함께 정해 둔다.
정리
- 증상은 마지막 걸음에 보이지만 어긋난 자리는 대개 그보다 앞이다
- 한 걸음은 이해·계획·도구 선택·인자 채우기·결과 해석·종료 판단 여섯 자리에서 무너진다
- 여섯을 나누는 이유는 처방이 전부 다르기 때문이다. 프롬프트로 안 되는 것이 대부분이다
- 증상에서 자리를 짐작하지 말고 트레이스에서 확인한 다음 고친다
- 가장 비싼 것은 결과 해석의 실패다. 오류도 안 나고 로그도 깨끗한데 답만 틀린다
- 빈 결과에 이유를 붙이고 성공과 실패를 값으로 구분한다. 이건 도구 쪽 수정이다
- 루프는 오류 없이 돈다. 오류 횟수가 아니라 진척으로 잡는다
- 같은 도구를 비슷한 인자로 세 번 부르면 인자 해시로 잡힌다
- 루프를 잡으면 바로 멈추기 전에 스스로 빠져나올 기회를 한 번 준다
- 회복은 호출·걸음·계획·되묻기 네 단계로 두고, 「계획을 다시 세운다」를 반드시 포함한다
읽어주셔서 감사합니다. 😊