파라미터가 자꾸 빠지는 건 모델 탓이 아니다
← 전체 목차 · 이전: 도구가 5개일 땐 괜찮았는데 50개가 되니 왜 무너지는가 · 다음: Agent는 왜 안 써도 될 도구를 자꾸 쓰는가
로컬 테스트에서는 도구 호출이 멀쩡했는데 프로덕션에 올리자마자 파라미터 결손, 타입 오류, 포맷 붕괴, 다중 도구 간 파라미터 뒤섞임이 쏟아진다. "Prompt를 더 자세히 쓰자", "도구 설명을 다듬자"는 답은 전부 틀렸다 — 대형모델은 확률적 생성기이고, 출력의 무작위성은 모델의 고유 속성이라 아무리 자세한 Prompt로도 잔여 오류율을 0으로 만들 수 없다. 해법은 모델 밖에 있어야 한다.
네 가지 실패 유형
| 실패 유형 | 원인 | 결과 |
|---|
| 필수 파라미터 결손 | 사용자 요구가 모호한데 모델이 스스로 되묻지 않음 | 필드 공백 → 인터페이스 즉시 오류 |
| 타입/포맷 오류 | 숫자를 문자열로, 날짜를 임의 형식으로, 여분 문자를 덧붙임 | 파라미터는 다 있어 보이지만 해석 실패 |
| 여분(환각) 파라미터 | 인터페이스에 없는 필드를 모델이 스스로 생성 | 요청 본문 비대화, 하류에서 은근히 통과 후 늦게 터짐 |
| 다중 도구 파라미터 혼선 | A 도구의 파라미터를 B 도구에 그대로 적용 | 완전히 어긋난 무효 호출 |
Prompt는 건의, Schema는 경계다
도구 설명과 Prompt는 모델 입장에서 소프트 제약이다 — 모델은 이를 따르지 않아도 아무 피드백을 받지 않는다. Schema는 하드 경계다 — 규격에 안 맞는 출력은 애초에 인터페이스에 들어가지 못한다. 둘의 차이는 "얼마나 자세히 썼는가"가 아니라 강제 집행점이 있는가다.
모델 출력 = 후보 파라미터 (아직 신뢰할 수 없음)
↓
독립 검증 게이트 : 필수항목 / 타입 / 포맷 합규성 / 값 합법성
↓
불합격 → 하류로 내려보내지 않고 로그만 남김
합격 → 비로소 도구 실행
모델은 후보를 생성하고, 공학층이 사용 가능 여부를 판정한다. "모델 출력을 인터페이스에 직결"하는 경로는 전부 위험을 그대로 노출시키는 것이다.
결손을 만나면 묻지 말고 먼저 분류한다
결손 파라미터를 발견했을 때 "그냥 호출"도 "무조건 되묻기"도 정답이 아니다. 먼저 분류부터 한다.
| 분류 | 세부 | 처리 |
|---|
| 추론 가능 | 업무 고정값 | 시스템이 자동 채움 |
| 추론 가능 | 이번 대화 맥락에서 추출 가능한 값 | 맥락에서 자동 추출 |
| 추론 가능 | 과거 이력/캐시 값 | 캐시에서 자동 읽음 |
| 사용자 입력 필수 | 사용자 고유 정보, 확정 불가 필드 | 단건으로만 정확히 되묻기 — 넘겨짚지 않음 |
원칙: 확정할 수 있는 건 자동으로 채우고, 확정할 수 없는 건 비워 두고 되묻는다. 파라미터 처리는 사용자 대신 결정을 내려주는 일이 아니다. 되묻기도 품질이 갈린다 — "빠진 그 한 필드만" 물어야지, 전체를 다시 확인시키면 체험이 무너진다.
한 번 사용자가 채운 값(고정 선호, 상용 수치)은 캐시에 남겨 다음 요청에서 재사용한다. 파라미터 기억은 대화 내용을 저장하는 것이 아니라 재사용 가능한 필드로 정제해 축적하는 것이다.
다중 도구는 파라미터를 격리해야 한다
도구가 늘어날수록 모델이 A 도구의 파라미터 구조를 B 도구에 적용하는 사고가 초선형으로 늘어난다. 해법은 도구마다 완전히 독립된 처리 경로를 두는 것이다.
도구 1: 독립 파라미터 템플릿 + 독립 Schema + 독립 검증기 + 독립 실행 컨텍스트
도구 2: 독립 파라미터 템플릿 + 독립 Schema + 독립 검증기 + 독립 실행 컨텍스트
...
호출 시 → 해당 도구의 Schema만 로드 → 호출 전 "도구 ID ↔ 파라미터 구조" 매칭 재검사
"도구가 많을수록 똑똑해진다"가 아니라 격리가 안 되어 있으면 도구가 많을수록 뒤섞인다.
핵심 통찰
- 파라미터 오류는 확률성 결함이지 능력성 결함이 아니다 — 모델이 확률적으로 생성하는 한 잔여 오류율은 구조적으로 0이 될 수 없다. "이번엔 Prompt를 못 써서"가 아니라 "언제나 어느 정도는 틀린다"는 전제에서 설계해야 하며, 그래서 해법이 모델 바깥(Schema, 검증층)에 있어야 한다.
- 모델이 생성하는 것은 "후보 파라미터"이지 "사용 가능한 파라미터"가 아니다 — 이 직위 구분이 전체 설계를 결정한다. 모델 출력을 인터페이스에 직결하는 모든 경로는 위험을 그대로 하류로 넘기는 것과 같다.
- 결손을 전부 되묻는 것도, 전부 자동으로 메우는 것도 틀렸다 — "추론 가능"과 "사용자 입력 필수"를 나누지 않으면 둘 중 하나로 쏠린다: 모델이 멋대로 채워 은근한 오류를 만들거나(추정), 별것 아닌 것까지 전부 되물어 체험이 질문 폭격이 된다(과추문). 분류가 곧 균형점이다.
- 되묻기의 품질 지표는 "많이 묻는가"가 아니라 "적게 묻는가"다 — 단건 추궁, 중복 질문 없음, 전면 재확인 없음. 이 세 가지가 상용 Agent의 체감 체험을 가른다.
- 파라미터 기억은 대화를 저장하는 게 아니라 필드를 자산화하는 것이다 — 사용자가 한 번 준 정보를 재사용 가능한 구조로 정제해 두면, 다음 상호작용에서 사용자의 입력 비용을 낮추는 유일한 지렛대가 된다.
- 다중 도구의 위험은 도구 개수가 아니라 파라미터 경계의 모호함이다 — 도구를 3개에서 30개로 늘릴 때 모델의 혼동 확률은 초선형으로 오른다. 도구를 늘리기 전에 격리 메커니즘부터 갖춰야 한다.
- 화이트리스트 필터링은 눈에 잘 안 띄지만 효과가 크다 — 결손은 즉시 오류로 드러나 찾기 쉽지만, 여분 필드는 종종 조용히 통과했다가 하류에서 뒤늦게 터진다. Schema에 정의된 필드만 남기고 나머지는 버리는 것을 기본 동작으로 만들어야 한다.
엔지니어링 실전 Tips
- Schema에 다섯 항목을 반드시 채울 것: 필드명, 타입, 필수 여부, 값 범위, 포맷 규칙. Schema는 문서가 아니라 파라미터 입구의 하드 경계다.
- 검증 게이트는 모델 출력 직후, 인터페이스 호출 직전에 둘 것: 위치가 곧 비용이다 — 게이트에서 막으면 거의 공짜, 인터페이스에서 막으면 요청 하나를 낭비, 업무 데이터가 오염된 뒤 발견하면 복구 비용까지 든다.
- 불확실한 필드는 차라리 비워 두고 되묻기 큐로 보낼 것: 그럴듯해 보이는 값을 모델이 채우게 두지 말 것. 여분 파라미터보다 오류 파라미터가 더 위험하다 — 조용히 인터페이스를 통과하기 때문이다.
- 되묻기 엔진에 중복 방지 로직을 넣을 것: 같은 필드를 여러 턴에서 반복해서 묻지 않아야 한다.
- 다중 도구 앞단에서는 항상 "도구 ID ↔ 파라미터 구조" 매칭 검사를 한 번 더 할 것: 격리가 되어 있어도 호출 직전 재검사가 마지막 방어선이다.
- 파라미터 캐시에는 만료 정책을 둘 것: 선호와 상용 수치는 시간이 지나면 바뀐다. 무기한 재사용은 언젠가 오류 파라미터로 돌아온다.
- 면접/설계 리뷰 답변 구조를 그대로 따를 것: "왜 Prompt로 안 되는가(확률적 생성) → 4대 실패 유형 → 4층 치리(Schema/검증/보완·추궁/격리)" 순서로 설명하면 구조가 점수를 받는다.