「요구사항 정리해줘」라고 했는데 견적서 초안이 나왔습니다

내부 프로젝트 관리 도구에 AI 채팅을 붙여 운영하고 있습니다. 자연어로 요청하면 LLM이 여러 도구 중 적절한 것을 골라 호출하는, 요즘 흔한 tool calling 구조입니다. 도구가 여러 개다 보니 '무엇을 고르느냐'가 곧 기능의 정확도가 됩니다.

얼마 전 활발히 개발 중인 기능의 UI 변경요청 5건을 정리할 일이 있었습니다. 채팅에 「요구사항 정리해줘」라고 넣었습니다. 기대한 동작은 개발 작업 항목 5건이 등록되는 것이었습니다.

그런데 AI가 호출한 것은 신규 영업·견적 스코핑용 도구였습니다. 기존 프로젝트의 변경요청 5건이 견적 역량 초안으로 만들어지고 있었습니다. 다행히 그 도구는 등록 전에 미리보기로 확인하는 단계가 있어서, 실제 데이터가 들어가기 전에 막았습니다.

코드를 의심했지만 코드는 멀쩡했습니다

처음엔 라우팅 로직이나 파라미터 매핑 버그를 의심했습니다. 그런데 이 구조에는 제가 짠 라우팅 로직 자체가 없습니다. 도구 선택은 전적으로 LLM이 각 도구의 description을 읽고 판단합니다.

그래서 두 도구의 설명을 나란히 놓고 읽어봤습니다. 범인은 바로 보였습니다.

견적 도구의 설명에 「'요구사항 추가' 류로 요청할 때 사용」이라는 문구가 있었습니다. 사용자 발화 「요구사항 정리해줘」와 정확히 겹칩니다. 반대로 정작 가야 했던 작업 등록 도구의 설명은 「신규 작업 등록.」 한 줄이 전부였습니다.

LLM 입장에서 다시 보면 이것은 오판이 아니라 합리적 선택이었습니다. 한쪽은 '요구사항이면 나'라고 광고하고 있었고, 다른 쪽은 변경요청·개선·버그를 받는다는 근거가 한 글자도 없었습니다. 모델은 주어진 텍스트 안에서 가장 그럴듯한 쪽을 골랐을 뿐입니다.

description은 문서가 아니라 라우팅 테이블입니다

여기서 인지가 한 번 뒤집혔습니다. 저는 도구 설명을 사람이 읽는 API 문서처럼 취급하고 있었습니다. 그런데 LLM 에이전트에서 description은 모델이 매 턴 읽고 분기를 결정하는 라우팅 테이블입니다.

'언제 사용'에 적은 문구가 곧 분기 조건입니다. 문서 쓰듯 자기 도구를 광고하면 광고 문구 그대로 낚입니다. 그리고 자기 홍보만 있는 설명들은 도구가 늘수록 반드시 서로 겹칩니다.

프롬프트는 안 고치고 설명만 고쳤습니다

반사적으로 떠오른 수는 시스템 프롬프트에 라우팅 규칙을 추가하는 것이었습니다. '기존 프로젝트 건에는 견적 도구를 쓰지 마라' 같은 규칙 말입니다. 그런데 이 방식은 프롬프트가 계속 비대해지고, 도구가 늘 때마다 재작업이 필요합니다.

무엇보다 채팅 경로가 하나가 아니었습니다. 요구사항 정리 전용 비서 경로는 처음부터 올바른 도구를 쓰게 설계돼 있었고, 이번 사건은 범용 비서 경로에서 터졌습니다. 프롬프트에 규칙을 넣으면 경로마다 같은 규칙을 복붙해야 합니다. 그래서 규칙을 도구 정의 자체에 붙이기로 했습니다. 바꾼 것은 세 곳입니다.

견적 도구 설명에 '신규 영업·견적 스코핑 전용'이라고 전용 범위를 명시

같은 설명에 '기존 프로젝트의 개발·수정·버그 건은 작업 등록 도구로'라는 네거티브 가드 한 줄 추가

작업 등록 도구 설명에 받아야 할 입력 유형(요구사항·변경요청·개선·버그)을 열거

검증은 실호출로 했습니다. 같은 변경요청 5건은 작업 등록 도구로, 신규 견적 문의는 견적 도구로 정확히 갈렸습니다. 기존 동작의 회귀도 없었습니다. 시스템 프롬프트에는 한 글자도 손대지 않았습니다.

물론 설명을 다듬어도 라우팅 오판을 0으로 만들 수는 없습니다. 오판이 나더라도 최종 답변까지 망가지지 않게 흡수하는 장치는 별도로 두는 편이 안전합니다.

헷갈리는 도구 쌍에는 네거티브 가드

이번 교정의 핵심은 네거티브 가드였습니다. 'X 건은 이 도구가 아니라 저 도구'라는 한 줄이 두 도구 사이에 상호배타 경계를 만듭니다. 각자 잘하는 것만 나열한 설명 두 개는 경계가 없어서, 겹치는 발화가 오면 모델이 그럴듯해 보이는 쪽으로 기웁니다.

다만 방향에 주의할 점이 있습니다. 가드가 서로를 가리키며 순환하면 어느 도구도 선택되지 않는 경우가 생깁니다. 가드는 한 방향으로, 헷갈리는 쌍에만 선별적으로 넣는 것이 좋습니다. 설명이 길어지는 만큼 매 턴 컨텍스트 비용이 늘기 때문입니다.

이번에는 도구 두 개의 경계 문제였지만, 도구가 수십 개 규모로 늘면 설명 길이와 노출 전략 자체가 별도의 설계 문제가 됩니다.

도구 설명 점검 체크리스트

도구 설명의 '언제 사용' 문구를 사용자 발화 관점에서 다시 읽어본다 — 광고 문구가 곧 분기 조건이다

경계가 헷갈리는 도구 쌍을 찾아 한쪽에 네거티브 가드를 넣는다 (한 방향으로만)

한 줄짜리 빈약한 설명에는 받아야 할 입력 유형을 열거한다

라우팅 교정은 프롬프트보다 도구 정의를 먼저 고친다 — 규칙이 도구와 함께 모든 경로에 배포된다

쓰기 도구에는 등록 전 미리보기 단계를 둔다 — 오판의 마지막 방어선이다

마무리

설명만으로 안 잡히는 모델이나 케이스도 있습니다. 그때는 라우팅 전용 프롬프트나 사전 분류 단계가 다음 수단입니다. 다만 첫 수단의 순서는 이번에 정해졌습니다. 도구 정의에 붙은 규칙은 도구와 함께 배포되고, 새 비서나 새 경로가 생겨도 그대로 유효합니다.