05. 명확하고 구체적인 지시

가장 기본이지만 가장 큰 차이를 만든다

2부의 모든 기법 중 단 하나만 익혀야 한다면 이것입니다. 세 제공자 가이드가 한목소리로 첫머리에 두는 조언이고, 다른 기법(역할·예시·형식)은 사실 이 "명확하고 구체적으로"를 특정 방향으로 적용한 것에 가깝습니다.

4장에서 "구체성은 글자 수가 아니라 정보 밀도"라고 했습니다. 이 장은 그 정보 밀도를 어떻게 높이는지를 다룹니다.

왜 모호하면 나쁜가 — 원리

2장의 직관을 떠올려봅시다. 모델은 주어진 텍스트 다음에 올 가장 그럴듯한 말을 잇습니다. 프롬프트가 모호하면, "그럴듯한 다음 말"의 후보가 너무 넓어집니다. 모델은 그 넓은 가능성 중 평균적으로 가장 흔한 방향으로 흘러가기 쉽고, 그 평균이 당신이 원한 것과 어긋나기 일쑤입니다.

flowchart TB
    vague["모호한 지시<br/>'좋은 글 써줘'"] --> wide["가능한 해석이 넓음"]
    wide --> avg["가장 흔한 평균값으로 수렴<br/>→ 당신 의도와 어긋남"]

    clear["구체적 지시<br/>'2030 직장인용 3문장 캡션'"] --> narrow["해석이 좁음"]
    narrow --> hit["의도한 방향에 명중"]

    classDef bad fill:#fee2e2,stroke:#ef4444,color:#7f1d1d
    classDef good fill:#dcfce7,stroke:#22c55e,color:#14532d
    classDef neutral fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    class vague,wide,avg bad
    class clear,narrow,hit good

📌 핵심: 구체적인 지시는 모델이 헤맬 가능성의 공간을 좁힙니다. 당신이 좁혀주지 않으면, 모델이 임의로 좁힙니다 — 대개 당신이 원한 쪽이 아니라 가장 흔한 쪽으로.

명확함을 분해하기 — 6가지 점검 항목

"명확하게 쓰라"는 막연합니다. 점검 가능한 항목으로 쪼개봅시다. 프롬프트를 쓴 뒤 빠진 게 없는지 확인하세요. (전부 채울 필요는 없고, 작업에 필요한 것만.)

💡 팁: 한 제공자는 "동작 동사로 시작하라"고 권합니다 — "계획해", "초안 작성해", "조사해"처럼. 명사형("~에 대해")보다 동사형이 작업을 분명히 합니다. 같은 맥락에서 Google 워크스페이스 가이드는 "페르소나·작업·맥락·형식" 네 요소를 담으라고 정리합니다.

before / after — 항목을 채워가며

같은 요청이 항목을 채울수록 어떻게 좋아지는지 단계적으로 봅시다.

0단계 ❌  "회의 내용 정리해줘"

1단계     "회의록을 요약해줘"
          (작업은 분명해졌지만 대상·형식·분량 미정)

2단계     "회의록을 임원 보고용으로 요약해줘. 결정사항과
          다음 행동만, 각 3개 이하."
          (대상·범위·분량 추가)

3단계 ✅  "아래 회의록을 임원 보고용으로 요약해줘.
          - 결정사항: 최대 3개, 각 한 문장
          - 다음 행동: 담당자와 함께, 최대 3개
          - 톤은 간결하고 중립적으로
          <회의록>...</회의록>"

왜 나아졌나: 단계가 올라갈수록 모델이 임의로 결정해야 할 것(누구를 위해? 얼마나? 무엇을 포함?)이 줄었습니다. 3단계에서는 모델이 추측할 여지가 거의 없습니다.

부정형보다 긍정형으로

"~하지 마"보다 "~해라"가 대체로 더 잘 작동합니다. 모델에게 피할 것만 주면 "그럼 무엇을 하라는 거지?"의 공간이 여전히 넓기 때문입니다. 가능하면 원하는 행동을 적극적으로 기술하세요.

약함 ❌                          강함 ✅
"너무 길게 쓰지 마"          →   "3문장 이내로 써"
"전문용어 쓰지 마"          →   "중학생도 이해할 쉬운 말로 써"
"딱딱하게 쓰지 마"          →   "친구에게 말하듯 친근하게 써"

⚠️ 흔한 실수·미신: 광범위한 부정 제약은 오히려 역효과를 낼 수 있습니다. 한 제공자는 "추론하지 마(do not infer)", "추측하지 마(do not guess)" 같은 지나치게 포괄적인 부정 지시를 주면, 모델이 그 지시에 과도하게 매달려 기본적인 논리·계산·문서 종합조차 못 하게 될 수 있다고 경고합니다. 권장되는 대안은 "주어진 자료를 근거로 추론하고, 외부 지식은 쓰지 마"처럼 원하는 행동을 구체적으로 지시하는 것입니다.

구체성 ≠ 장황함

명확하게 쓰라는 조언을 "무조건 길게"로 오해하면, 4장에서 본 attention 분산 문제로 되돌아갑니다. 좋은 구체성은 핵심 정보를 더하는 것이지 말을 늘리는 것이 아닙니다.

장황하지만 모호함 ❌
"안녕하세요, 바쁘신 와중에 정말 죄송한데요, 혹시 가능하시다면
시간 되실 때 우리 제품에 관해서 뭔가 좀 좋은 느낌의 글을
하나 부탁드려도 될까요? 너무 부담 갖진 마시고요..."

간결하지만 구체적 ✅
"친환경 텀블러 신제품 인스타 캡션, 2030 직장인 대상, 3문장,
마지막에 행동 유도 문구 1개."

위쪽은 길지만 작업·대상·형식·분량이 하나도 없습니다. 아래쪽은 짧지만 모두 있습니다. 정중함은 모델 성능과 무관하니, 사람에게 쓰는 군더더기는 덜어내도 됩니다.

🔧 개발자 노트: 최신 모델일수록 의도 추론이 좋아져, 과하게 처방적인(prescriptive) 지시가 오히려 방해가 될 수 있습니다. 어떤 코딩 가이드는 "과잉 엔지니어링을 피하고, 요청되거나 명백히 필요한 변경만 하라"는 지시를 시스템 프롬프트에 두기도 합니다. 즉 구체성은 "모델이 알아서 잘할 영역까지 일일이 통제하라"는 뜻이 아닙니다. 결과를 좌우하는 항목에 구체성을 집중하세요.

모호한 단어를 사냥하기

실전 팁 하나: 자기 프롬프트에서 아래 같은 "고무줄 단어"를 찾아 구체화하세요.

🧪 직접 검증법: 프롬프트를 쓴 뒤, 위 고무줄 단어를 하나 골라 제거하고 구체값으로 대체한 버전을 만들어 둘을 비교해보세요. 출력의 일관성이 올라간다면 그 단어가 모호함의 원천이었던 것입니다.

이 장에서 배운 것

• 모호한 지시는 "그럴듯한 다음 말"의 공간을 넓혀, 모델이 당신 의도가 아닌 평균값으로 수렴하게 만든다.
• 명확함은 작업·대상·맥락·형식·분량·톤 6가지로 분해해 점검할 수 있다. 동작 동사로 시작하면 작업이 분명해진다.
• 부정형("하지 마")보다 긍정형("이렇게 해")이 대체로 낫고, 지나치게 포괄적인 부정 제약은 역효과를 낼 수 있다.
• 구체성은 정보를 더하는 것이지 말을 늘리는 것이 아니다. 정중함·군더더기는 성능과 무관하다.
• "좋은/잘/적절히" 같은 고무줄 단어를 구체값으로 바꾸는 것이 가장 빠른 개선법이다.

✍️ 확인 문제

1. 다음 프롬프트에서 6가지 점검 항목 중 빠진 것을 모두 찾아보세요.

> "이 데이터로 보고서 만들어줘."

1. "이메일이 너무 공격적으로 들리지 않게 써줘"를 긍정형으로 바꿔보세요. 왜 긍정형이 더 나은지도 한 줄로.

1. (실습) 아래 프롬프트에서 고무줄 단어를 모두 찾아 구체값으로 바꾸고, 6항목 중 어떤 것을 채웠는지 표시해보세요.

> "신입 교육용으로 우리 코드 컨벤션을 좀 잘 정리해줘. 너무 길지 않게, 적절히."

다음 → 06. 역할과 페르소나 부여
이전 ← 04. 좋은 프롬프트의 공통 속성 · 목차