도구가 5개일 땐 괜찮았는데 50개가 되니 왜 무너지는가
← 전체 목차 · 이전: Agent는 어떤 도구를 호출해야 할지 어떻게 아는가 · 다음: 파라미터가 자꾸 빠지는 건 모델 탓이 아니다
같은 모델, 같은 개수의 도구인데 어떤 팀은 호출 정확률 99%, 어떤 팀은 70%다. 같은 팀 안에서도 도구를 5개에서 50개로 늘리는 순간 정확률이 단애처럼 떨어진다. Prompt를 아무리 다듬고 예시를 더 넣어도 이 두 현상은 설명되지 않는다 — 변수를 Prompt 하나로 고정해도 격차가 그대로이기 때문이다. 원인은 모델 능력이 아니라 도구를 모델에게 어떻게 조직해서 보여주느냐, 즉 아키텍처에 있다.
평면 나열 구조의 함정
도구를 그냥 쌓아 올려 매번 전체 목록을 tools 필드에 통째로 밀어 넣으면, 모델은 매 결정마다 전체 집합에서 골라야 한다.
도구 수 ↑ → 한 번의 결정에서 고려할 후보 ↑ → 오판 확률 ↑ (구조적 필연)
Prompt만 다듬는 것 ✗ 결정 공간의 지수적 증가를 해소하지 못함
이것은 "모델이 헷갈린다"는 능력 문제가 아니라 한 번의 선택에 떠안기는 정보량의 문제다. 설명을 아무리 정교하게 써도 후보 수 자체는 줄지 않는다.
결정 공간을 압축하는 4층 아키텍처
| 층 | 이름 | 하는 일 | 해결하는 문제 |
|---|
| 최상층 | 분류 내비게이션 | 먼저 작업 대분류를 판단 → 그 분류 안에서만 구체 도구 선택 | 매 스텝 후보 집합을 작게 유지 |
| 중간층 | 복합 도구 | 자주 함께 쓰이는 도구 여러 개를 하나의 조합 도구로 미리 묶음 | 다단계 호출을 모델이 일일이 조율하지 않게 해 누적 오차 감소 |
| 하위층 | 실행 검증층 | 파라미터 제출 후 형식·권한·합법성을 먼저 검사, 불합격이면 명확한 수정 지침을 반환 | 실패를 곧장 재시도가 아니라 정확한 정정으로 전환 |
| 우회 경로 | 결과 전처리층 | 도구의 원본 응답을 그대로 넘기지 않고 구조적으로 추출한 핵심 정보만 전달 | 응답이 길고 복잡해 후속 판단이 전부 틀어지는 사고 방지 |
네 층은 "모델을 더 똑똑하게 만드는" 방향이 아니라 확률적 추론을 구조적 확정으로 바꿀 수 있는 결정은 전부 구조에 맡긴다는 하나의 원칙에서 나온다. 분류 내비게이션은 N택 1을 두 번의 작은 선택으로 쪼개고, 복합 도구는 여러 스텝의 조율을 한 번의 호출로 접는다.
오류 유형별로 다르게 대응하기
실행 검증층을 통과하지 못한 실패를 전부 "재시도"로 뭉뚱그리면 안 된다. 오류 종류마다 회복 지점이 다르다.
| 오류 유형 | 처리 | 이유 |
|---|
| 파라미터 형식 오류 | 파라미터만 다시 채우게 함 | 전체 체인을 다시 돌 필요가 없음 |
| 도구 선택 오류 | 결정 노드로 롤백, 재선정 | 실행 자원을 낭비하지 않음 |
| 인터페이스 실행 실패 | 일시적 장애 vs 업무 오류를 구분해 각기 다른 재시도·강등 전략 적용 | 재시도해도 소용없는 오류에 무의미한 재시도를 반복하지 않음 |
핵심 통찰
- 도구 수와 오류율의 관계는 "능력"이 아니라 "구조"의 문제다 — 평면 나열 구조에서 한 번의 결정 비용은 도구 총수에 비례해 커진다. "5개에서 통했던 것이 50개에서 무너진다"는 것은 모델이 퇴보한 게 아니라, 애초에 규모를 감당하도록 설계된 적 없는 아키텍처가 한계에 부딪힌 것이다.
- 결정 공간을 줄이는 보편적 수단은 "결정자를 강화"가 아니라 "선택 범위를 압축"이다 — 분류 내비게이션은 한 번의 N택 1을 두 번의 소범위 선택으로 바꾸고, 복합 도구는 다단계 조율을 한 번의 호출로 접는다. 공통점은 구조적으로 고정할 수 있는 결정은 모델의 확률적 추론에 맡기지 않는다는 것이다.
- 검증층의 가치는 오류를 막는 데 있지 않고, 오류를 실행 가능한 수정 지침으로 바꾸는 데 있다 — "호출 실패"만 돌려주면 모델은 맹목적으로 재시도한다. "어느 필드가 왜 틀렸고 기대값이 무엇인지"를 돌려주면 실패가 한 번의 유효한 정보 입력으로 바뀐다.
- 결과 전처리층은 가장 자주 누락되는 층이다 — 도구 응답이 길고 복잡할 때 Agent가 핵심을 못 짚어 후속 판단이 전부 틀어지는 사고는 "모델 이해력 부족"처럼 보이지만, 실제로는 원본 응답을 결정에 필요한 최소 정보 집합으로 수렴시키는 책임자가 없었을 뿐이다. 이 층을 보강하면 토큰 비용과 오류율이 동시에 줄어든다.
- 오류를 하나의 종류로 취급하면 회복 전략도 하나가 된다 — 파라미터 오류는 파라미터만 다시 채우면 되고, 도구 선정 오류는 결정 노드로 되돌아가야 하며, 인터페이스 오류는 일시 장애와 업무 오류를 구분해야 한다. 이 구분이 없으면 모든 실패가 "처음부터 다시"로 수렴해 자원을 낭비한다.
- 소수 도구로 검증된 아키텍처는 아무것도 증명하지 못한다 — 5개 도구에서 잘 도는 체인은 평면이든 계층형이든 차이가 드러나지 않는다. 규모 압박 테스트(도구를 5개에서 50개로 늘려 정확률 곡선을 보는 것)만이 아키텍처가 평면인지 계층형인지를 실제로 가른다.
엔지니어링 실전 Tips
- 도구 설명을 아무리 다듬어도 안 되면 아키텍처를 의심할 것: 같은 Prompt 템플릿인데 완성률이 두 배 이상 차이 난다면 격차는 템플릿 바깥, 즉 조직 구조에서 온다.
- 분류 내비게이션의 목표는 "매 스텝의 후보 집합을 작게 유지"이지 계층 수를 늘리는 것이 아니다: 대분류가 다시 수십 개로 갈라지면 압축 효과가 사라진다.
- 복합 도구는 호출 로그에서 고빈도 연쇄 패턴을 찾아 만들 것: 임의로 조합하지 말고 실제로 자주 함께 호출되는 시퀀스를 우선 묶어야 누적 오차 감소 효과가 크다.
- 검증 실패 응답은 필드 단위까지 정확해야 한다: "파라미터가 틀렸습니다"가 아니라 "
start_date 필드가 YYYY-MM-DD 형식이어야 합니다"처럼 써야 모델이 정정할 수 있다.
- 일시 장애와 업무 오류를 같은 재시도 큐에 넣지 말 것: 업무 오류(예: 권한 없음, 존재하지 않는 리소스)에 재시도를 거는 것은 순수 낭비이며, 오히려 강등이나 사람 확인으로 보내야 한다.
- 규모 압박 테스트를 회귀 스위트에 넣을 것: 도구 수를 5개에서 50개로 늘려 정확률 곡선이 완만한지, 단애처럼 떨어지는지를 정기적으로 확인해야 아키텍처의 실제 한계를 안다.