19. 모호함과 과잉생성 다루기

두 가지 흔한 불만

"내가 원한 건 이게 아닌데"의 배경에는 보통 두 문제가 있습니다.

• 모호함 문제: 요청이 여러 갈래로 해석될 때, 모델이 임의로 한 갈래를 골라 진행한다(5장에서 본 "넓은 가능성의 평균값" 문제).
• 과잉생성 문제: 부탁하지 않은 것까지 덧붙이거나, 필요 이상으로 길고 장황하게 답한다.

둘 다 결과를 "원한 것"에서 멀어지게 합니다. 이 장은 각각의 대응입니다.

모호함 — 모델은 멈추지 않고 가정한다

사람 동료라면 모호한 요청에 "이거 A 말씀이세요, B 말씀이세요?"라고 되묻습니다. 모델은 기본적으로 그렇게 하지 않습니다. 2장의 원리상, 모델은 멈추는 대신 가장 그럴듯한 해석으로 이어가도록 작동하기 때문입니다. 그 가정이 맞으면 다행이고, 틀리면 엉뚱한 결과가 나옵니다.

📌 핵심: 모델은 모호함을 만나면 침묵하지 않고 가정합니다. 그 가정의 통제권을 가져오는 것이 모호함 대응의 핵심입니다.

대응 A: 되물어보게 허용하기

기본 동작을 바꿔, 불확실하면 먼저 묻게 할 수 있습니다.

✅
"요청이 모호하거나 정보가 부족하면, 바로 작업하지 말고
먼저 명확히 할 질문을 해줘."

이 한 줄이 특히 유용한 경우: 작업이 크고(잘못 진행하면 손해가 큼), 요청에 빠진 정보가 많을 때입니다.

⚠️ 흔한 실수·미신: 그렇다고 모든 작업에 "항상 되물어봐"를 넣으면, 간단한 요청에도 질문만 잔뜩 돌아와 번거롭습니다. 되묻기는 불확실성이 크고 비용이 큰 작업에 선택적으로 쓰세요.

대응 B: 가정을 드러내게 하기

되묻는 대신, 진행하되 가정을 밝히게 하는 절충안도 있습니다. 속도와 안전의 균형이 좋습니다.

✅
"진행에 필요한 가정을 했다면, 답 앞에 '가정:'으로 명시하고 진행해줘."

이러면 모델이 막히지 않고 진행하되, 당신이 가정을 보고 "그건 아니야"라고 바로잡을 수 있습니다.

대응 C: 애초에 모호함 제거하기

가장 근본적인 건 5장으로 돌아가는 것입니다 — 작업·대상·형식·범위를 처음부터 구체화해 모호함의 여지를 없애는 것. 되묻기·가정 드러내기는 남은 모호함을 위한 안전망이지, 모호한 프롬프트의 면죄부가 아닙니다.

과잉생성 — 시키지 않은 것까지 한다

두 번째 문제. 모델은 종종 부탁한 것보다 많이 합니다. 요약을 시켰는데 분석까지 붙이거나, 한 가지를 물었는데 다섯 가지를 설명하거나, 짧게 답해도 될 것을 장황하게 늘립니다.

왜 그러나

두 원인이 있습니다. 하나는 모델이 "도움이 되려는" 방향으로 훈련되어, 더 많이 주는 것이 더 돕는 것이라고 기우는 경향입니다. 다른 하나는 사용자가 범위를 명시하지 않아, 모델이 "관련 있을 법한" 것까지 폭넓게 포함하는 것입니다.

대응: 범위와 분량을 못박는다

8·10장에서 본 출력 통제가 그대로 적용됩니다.

과잉생성 유발 ❌            범위 통제 ✅
"이 코드 봐줘"          →   "이 코드에서 *보안 취약점만* 짚어줘.
                            스타일·성능은 언급하지 마."
"제품 설명 써줘"        →   "제품 설명을 정확히 3문장으로.
                            그 이상도 이하도 말고."

💡 팁: 과잉생성을 막는 가장 효과적인 단어는 "~만"과 정확한 수량입니다. "장점만", "결론만", "3개만", "코드만(설명 없이)"처럼 포함 범위를 좁히면, 모델이 곁가지를 칠 여지가 줍니다.

최신 모델의 경향 — 양방향 주의

흥미롭게도 최근 모델은 기본적으로 더 간결하게 답하도록 조정된 경우가 많습니다. 그래서 과잉생성과 반대 문제 — 너무 짧거나 성의 없어 보이는 답 — 도 생깁니다.

⚠️ 흔한 실수·미신: "모델은 항상 장황하다"는 옛 경험일 수 있습니다. 모델·버전에 따라 기본 분량 경향이 다릅니다. 자세한 답을 원하면 "충분히 자세히, 예시를 들어"처럼 명시적으로 늘리는 지시가 필요할 수 있습니다. 즉 분량은 양쪽으로 통제 대상입니다.

🧪 직접 검증법: 같은 작업을 분량 지시 없이 줘보고, 모델의 기본 분량 경향을 파악하세요. 기본이 장황하면 "~만/짧게"로 죄고, 기본이 너무 짧으면 "자세히/예시 포함"으로 늘립니다. 모델마다 출발점이 다릅니다.

모호함·과잉생성 통합 대응

flowchart TB
    req["요청"] --> amb{"모호한가?"}
    amb -->|크게 모호 + 고비용| ask["되물어보게 하기"]
    amb -->|약간 모호| assume["가정 드러내며 진행"]
    amb -->|명확| scope{"범위가<br/>정해졌나?"}
    assume --> scope
    scope -->|아니오| limit["'~만' + 수량/분량 못박기"]
    scope -->|예| go["진행"]
    limit --> go

    classDef dec fill:#fef9c3,stroke:#eab308,color:#713f12
    classDef act fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    classDef good fill:#dcfce7,stroke:#22c55e,color:#14532d
    class amb,scope dec
    class ask,assume,limit act
    class go good

이 장에서 배운 것

• 모델은 모호함을 만나면 멈추지 않고 임의의 가정으로 이어간다. 그 통제권을 가져오는 것이 핵심이다.
• 모호함 대응 세 가지: 되물어보게 허용(고비용·고불확실), 가정을 드러내며 진행(절충), 애초에 구체화(근본).
• 과잉생성은 "더 많이=더 도움"이라는 경향과 범위 미명시에서 온다. "~만" + 정확한 수량·분량으로 막는다.
• 최신 모델은 기본 간결한 경우가 많아, 반대로 자세한 답을 원하면 명시적으로 늘려야 한다. 분량은 양방향 통제 대상이다.
• 되묻기·가정 드러내기는 남은 모호함을 위한 안전망이지, 모호한 프롬프트의 면죄부가 아니다.

✍️ 확인 문제

1. "이 데이터 정리해줘"라는 요청에 모델이 엉뚱한 방식으로 정리했습니다. 이 장의 어떤 문제이고, 세 가지 대응 중 무엇을 적용하면 좋을까요?

1. "코드 리뷰해줘"라고 했더니 보안·성능·스타일·네이밍까지 끝없이 나왔습니다. 과잉생성을 막는 프롬프트로 바꿔보세요.

1. (실습) 크고 모호한 요청("우리 서비스 개선안 좀 줘")을 받았습니다. 되묻기 또는 가정 드러내기 중 하나를 골라, 그 이유와 함께 프롬프트를 설계해보세요.

다음 → 20. 검증 가능한 출력 만들기
이전 ← 18. 환각을 줄이는 법 · 목차