"이 계약서 좀 봐줘" — 모호한 지시를 어떻게 정확히 정렬하는가
← 전체 목차 · 이전: 수십 개의 Skill에서 적중률을 어떻게 보장하는가 · 다음: Agent는 왜 작업 실행 전에 계획을 먼저 생성하는가
"모르면 되물어보게 Prompt에 써두면 된다"는 답은 양방향으로 실패한다. 핵심 정보가 빠져도 안 물어보고 그냥 밀고 나가거나(실행 편차), 사소한 것까지 반복해서 되묻거나(체험 붕괴) 둘 중 하나로 쏠린다. 되묻기를 모델의 자기 판단에 맡기는 순간, 시스템의 확정성을 모델의 자기 인식이라는 확률적인 것에 저당 잡히는 셈이다. 되묻기는 최후의 방어선이지 정렬 방안 자체가 아니다.
의도가 틀어지는 다섯 갈래
의도 편차는 모델의 이해력 문제가 아니라 의미 해석·도메인 지식·대화 로직 전 링크의 결손이 겹쳐 쌓인 것이다.
| # | 실효 유형 | 예시 |
|---|
| 1 | 문자 그대로 실행 | 동사만 실행하고 그 뒤의 진짜 목적(업무 잠재의미)을 못 읽음 — "계약서 좀 봐줘" → 훑어만 봄 (진짜 요구: 리스크 조항 심사, 핵심 조건 대조) |
| 2 | 파라미터 결손을 임의로 채움 | 모호한 지시에 핵심 파라미터가 빠지면 모델이 스스로 추측해 채워 넣음 |
| 3 | 도메인 매핑 부재 | 업계 은어·내부 약칭·전문 용어가 일반적 의미로 오해됨 |
| 4 | 되묻기 전략의 양극화 | 과도하게 되묻거나 아예 안 물어봄 — 효율과 체험을 동시에 잡지 못함 |
| 5 | 다중 턴 의도 표류 | 여러 턴에 걸쳐 암묵적 요구가 겹겹이 쌓이며 최초 목표에서 조금씩 벗어남 |
기준선: 구조화 의도 해석 + 도메인 지식 보완 + 등급별 확인
구조화 의도 해석 + 도메인 지식 보완 + 등급별 확인 ← 가장 신뢰할 수 있는 기준선
보조: 암묵적 요구 발굴 / 모호성 탐지 / 표류 교정
① 2층 의도 해석 구조
1층: 문자 의미 해석 → 명시적 지시를 추출
2층: 도메인 지식그래프 + 업무 규칙 → 암묵적 의도 보완
출력: 사용자의 문자 표현에 국한되지 않는 완전한 구조화 실행 의도
동사(무엇을 하라고 했나)와 목표어(진짜 무엇을 원하나)가 항상 일치하지는 않는다. "본다"고 했지만 진짜 목표는 "리스크 조항을 심사하고 핵심 조건을 대조한다"일 수 있다. 이 간극을 메우는 것이 2층의 역할이며, 언어 이해가 아니라 업무 규칙과 도메인 지식그래프의 문제다.
② 도메인 용어 매핑 라이브러리
업계 은어·약칭·내부 코드명을 표준 실행 지시로 변환하는 사전을 시나리오별로 분할해 필요한 것만 로드한다. 전역에 한 번에 욱여넣지 않는 것이 핵심이다 — 같은 약칭이 업무 라인마다 다른 의미를 가질 수 있기 때문이다. 아무리 되물어도 "내부 코드명 X가 뭘 가리키는지"는 알아낼 수 없다 — 사용자는 그것을 상식으로 여겨 설명하지 않는다. 유일한 해법은 실행 전에 미리 매핑 라이브러리를 준비해 두는 것이다.
③ 등급별 확인 전략
"매번 되묻는다"의 정답은 등급화다. 판정 축은 위험도 · 모호도 · 핵심 파라미터 결손 여부다.
| 지시 등급 | 판정 조건 | 처리 |
|---|
| 고위험 | 고위험·고모호·핵심 파라미터 결손 | 능동적으로 되물어 확인 |
| 저위험 | 저위험·맥락이 명확함 | 규칙 기반 자동 보완 후 실행 |
| 일반 | 통상적인 모호 지시 | 사용자 과거 행동 선호를 매칭해 보완, 매번 확인하지 않음 |
④ 다중 턴 표류 교정
매 턴 실행 전:
"현재 의도"를 "최초 핵심 목표"와 대조
편차 > 임계값 → 확인 트리거
아니면 → 계속 실행
여러 턴의 컨텍스트 윈도가 "잊어버림"은 막아주지만 "조금씩 벗어남"은 막지 못한다. 표류를 막으려면 최초 목표를 별도의 닻으로 명시 저장하고, 매 턴 실행 직전 현재 의도와 비교하는 별도의 검증기가 필요하다 — 이것은 기억 메커니즘이 아니라 교정 메커니즘이다.
생산 착지의 이상 처리
| 이상 문제 | 대응 |
|---|
| 도메인 지식 반복 | 업무 담당자가 코드 수정 없이 의도 매핑 규칙을 시각화 설정할 수 있게 함 — 업무는 매일 바뀌므로 코드 배포 없이 계속 최적화되어야 매핑 라이브러리가 부패하지 않음 |
| 과도한 되묻기 | 작업 단위로 되묻기 횟수 상한을 두고, 상한 도달 시 고신뢰도 자동 보완이나 후보 선택지 제시로 자동 승격 — 개방형 되묻기보다 선택형이 효율적 |
| 의도 하한선 | 신뢰도가 임계값 미만인 모호한 의도는 2~3개 후보 실행 방향을 생성해 사용자가 클릭으로 고르게 함 |
| 가관측성 | 의도 인식 정확률 · 사용자 평균 확인 횟수 · 실행 결과 부합률을 모니터링, 이상 시 자동 경보 |
| 장애 강등 | 의도 해석 모듈 장애 시 보수 모드로 강등 — 모든 모호 지시를 일괄 확인 트리거 (차라리 느릴지언정 틀리지 않음) |
핵심 통찰
- 되묻기는 대응이지 정렬 설계가 아니다 — "이해했는지 판단"의 책임을 모델의 자기 인식에 맡기는 것은 시스템의 확정성을 SLA 없는 컴포넌트에 저당 잡히는 것과 같다. 묻지도 되묻는지 않는지가 매번 확률적으로 갈린다.
- 의도 편차는 단일 지점 결함이 아니라 전 링크가 겹쳐 쌓인 결과다 — 의미 해석, 도메인 지식, 대화 로직 셋 중 하나만 빠져도 의도가 틀어진다. 그래서 모델을 더 강한 것으로 바꾼다고 해결되지 않는다 — 빠진 것은 파라미터가 아니라 링크다.
- 암묵적 요구의 본질은 "동사와 목표어의 불일치"다 — "본다"는 동사이고 "리스크 조항을 심사한다"가 진짜 목표어다. 암묵적 요구를 알아채는 것은 언어 이해가 아니라, 동사를 업무 목표로 되짚어 매핑하는 문제이며 이는 업무 규칙과 도메인 지식그래프가 있어야 풀린다.
- 업계 은어 문제는 대화 공학이 아니라 지식 공학이다 — 아무리 많이 되물어도 "내부 코드명이 무엇을 가리키는지"는 알아낼 수 없다. 사용자는 그것을 상식으로 여겨 설명하지 않기 때문이다. 유일한 해법은 실행에 들어가기 전에 시나리오별로 로드되는 용어 매핑 라이브러리를 미리 준비해 두는 것이다.
- 확인은 반드시 등급화해야 효율과 체험을 동시에 얻는다 — 확인 여부를 위험도·모호도·파라미터 결손도로 점수 매기는 함수로 바꿔야, 고위험은 능동 확인·저위험은 규칙 보완·일반은 과거 선호 매칭이라는 세 갈래가 동시에 성립한다.
- 다중 턴의 진짜 위험은 망각이 아니라 표류다 — 컨텍스트 윈도는 "기억 못함"은 해결하지만 "조금씩 벗어남"은 해결하지 못한다. 최초 핵심 목표를 닻으로 별도 저장하고 매 턴 편차를 비교하는 것은 기억 메커니즘이 아니라 검증기다.
- 의도 시스템은 업무 담당자가 직접 고칠 수 있어야 살아남는다 — 도메인 지식은 매일 바뀐다. 새 은어 하나를 추가할 때마다 코드를 고쳐 배포해야 한다면 매핑 라이브러리는 반드시 부패한다. 시각화 설정 가능성은 이 체계가 첫 분기를 넘겨 살아남는 전제조건이다.
- 강등 방향은 명확히 "느리게, 대신 틀리지 않게"여야 한다 — 의도 해석 모듈이 장애일 때 기본 동작은 "그대로 실행"이 아니라 "전부 확인 트리거"다. 정렬 시스템의 실패 모드는 보수적으로 기울어야 한다 — 잘못 실행한 대가가 한 번 더 묻는 대가보다 훨씬 크기 때문이다.
엔지니어링 실전 Tips
- 확인을 개방형 질문에서 선택형으로 바꿀 것. 사용자가 문장을 직접 조립하게 하는 것보다 후보 선택지를 제시하고 클릭하게 하는 편이 효율이 훨씬 높다.
- 되묻기 상한은 세션이 아니라 단일 작업 단위로 걸 것. 상한 도달 시 멈추는 것이 아니라 고신뢰 자동 보완이나 후보 제시로 자동 승격시켜야 사용자가 막다른 길에 갇히지 않는다.
- 후보 선택지는 2~3개로 제한할 것. 선택지가 많아지면 결정 비용이 다시 사용자에게 돌아가 되묻기를 없앤 의미가 사라진다.
- 매핑 라이브러리는 시나리오 단위로 분할해 로드할 것. 같은 약칭이 업무 라인마다 충돌할 수 있어 전역 주입은 오히려 새로운 오해석을 만든다.
- "사용자 평균 확인 횟수"를 반드시 모니터링할 것. 정확률이 높아도 확인 횟수가 치솟으면 등급 정책이 잘못 튜닝된 것이다 — 과도한 되묻기를 직접 반영하는 유일한 지표다.
- 강등 모드의 의미를 사전에 업무팀과 합의해 둘 것. "모든 모호 지시를 확인 트리거"가 특정 고처리량 시나리오에서는 사실상 서비스 정지와 같을 수 있으므로, 이것이 수용 가능한 실패 방식인지 미리 정해야 한다.