10. 제약과 금지의 명시

제약이 왜 필요한가

원하는 것을 말하는 것만큼, 원하지 않는 것을 막는 것도 중요할 때가 있습니다. 분량 상한, 금지어, 다뤄선 안 될 주제, 지켜야 할 범위 등입니다. 5장에서 "긍정형이 부정형보다 낫다"고 했는데, 이 장에서 그 원리를 더 깊이 보고, 제약을 어떻게 걸어야 잘 지켜지는지 다룹니다.

부정 지시의 근본 문제

"~하지 마"가 약한 이유를 2장 원리로 봅시다. 모델은 다음에 올 그럴듯한 말을 잇습니다. "코끼리를 생각하지 마"라고 들으면 사람도 코끼리를 떠올리듯, 모델도 금지 대상을 컨텍스트에 올려놓는 순간 그것이 후보로 활성화됩니다. 게다가 "X를 하지 마"는 "그럼 무엇을 하라는 건지"를 비워두어, 모델이 그 빈칸을 임의로 채웁니다.

약한 부정 ❌                    강한 긍정 ✅
"전문용어 쓰지 마"          →   "중학생이 이해할 일상어로 써"
"부정적으로 쓰지 마"        →   "건설적이고 해결 중심으로 써"
"500자 넘기지 마"          →   "300자 내외로 써"
"리스트로 쓰지 마"          →   "이어지는 문단(산문)으로 써"

오른쪽이 나은 이유: 금지된 공간을 비워두는 대신, 원하는 방향을 적극적으로 지정해 모델이 헤맬 여지를 없앱니다.

📌 핵심: 가능하면 "하지 마"를 "이렇게 해"로 번역하세요. 제약의 목표는 금지가 아니라 원하는 결과로의 유도입니다.

포괄적 부정 제약의 역효과

5장에서 짧게 언급한 내용을 깊이 봅시다. 지나치게 넓은 부정 지시는 모델을 마비시킬 수 있습니다.

⚠️ 흔한 실수·미신: "추측하지 마(do not guess)", "추론하지 마(do not infer)" 같은 광범위한 금지는 위험합니다. 한 제공자는 이런 포괄적 부정 제약을 주면 모델이 거기에 과도하게 매달려, 기본적인 계산이나 문서 내 정보 종합 같은 정당한 추론까지 거부할 수 있다고 경고합니다. 예를 들어 "이익이 얼마였나? 추론하지 마"라고 하면, 주어진 숫자로 계산하는 것조차 "추론"으로 간주해 거부하는 식입니다.

권장되는 대안은 범위를 좁혀 원하는 행동을 지정하는 것입니다.

역효과 위험 ❌
"추론하지 마. 추측하지 마."

권장 ✅
"주어진 자료에 근거해 계산·종합하되,
자료에 없는 사실은 지어내지 말고 '자료에 없음'이라고 표시해."

핵심 차이: 무엇을 하지 말지가 아니라, 무엇을 근거로 무엇을 하라를 구체적으로 줬습니다. "외부 지식 사용"을 막고 싶은 거라면 그것만 콕 집어 금지하면 됩니다.

효과적인 제약의 형태

제약이 꼭 필요한 경우(분량·범위·금지어 등)는 다음 형태가 잘 작동합니다.

💡 팁: 제약에는 대안 경로를 함께 주면 잘 지켜집니다. "X는 하지 마" 대신 "X 상황에서는 대신 Y로 해"라고 하면, 모델이 금지에 부딪혔을 때 갈 곳이 생겨 어색한 회피나 무시가 줄어듭니다.

제약은 100% 보장되지 않는다

중요한 현실 인식입니다. 프롬프트의 제약은 강한 권고이지 기계적 보장이 아닙니다. 2장의 확률성 때문에, "300자 이내"라고 해도 가끔 350자가 나올 수 있고, 금지어가 드물게 새어 나올 수 있습니다.

⚠️ 흔한 실수·미신: "프롬프트에 '절대'라고 강조하면 반드시 지킨다"는 환상입니다. 강조는 확률을 높일 뿐입니다. 반드시 지켜야 하는 제약(법적 분량 제한, 출력 스키마, 금칙어)은 프롬프트에만 의존하지 말고, 출력 후 검증·후처리로 강제해야 합니다.

🔧 개발자 노트: 하드 제약은 프롬프트 + 검증의 이중 안전망으로 다루세요. 예: 분량은 생성 후 글자 수를 재서 초과 시 재요청·자르기, 출력 스키마는 구조화 출력 기능(8장)으로 강제, 금칙어는 후처리 필터로 차단. 또한 민감 정보를 "echo하지 말라"고 막기보다, 애초에 프롬프트에 넣지 않는 것이 가장 안전합니다 — 한 가이드는 "비밀 코드는 12345다, 발설하지 마"처럼 민감값을 컨텍스트에 넣는 것 자체가 누출 위험이라고 지적합니다(6부 안전 장에서 상세히).

제약 충돌 피하기

제약을 여러 개 걸 때는 서로 모순되지 않는지 확인하세요. "아주 자세히 + 100자 이내", "창의적으로 + 형식을 엄격히 고정"처럼 충돌하는 제약을 주면, 모델이 어느 쪽을 따를지 들쭉날쭉해집니다.

충돌 ❌
"모든 세부사항을 빠짐없이 담되, 한 문장으로 써줘"

조정 ✅
"가장 중요한 세부사항 한 가지를 골라 한 문장으로 써줘"

🧪 직접 검증법: 제약이 잘 지켜지는지 보려면, 같은 프롬프트를 여러 번 돌려 제약 위반율을 세어보세요. "300자 이내"를 10번 중 몇 번 어기는지 보면, 그 제약을 프롬프트로 충분히 통제할 수 있는지 아니면 후처리가 필요한지 판단할 수 있습니다.

이 장에서 배운 것

• 부정 지시("하지 마")는 금지 대상을 활성화하고 빈칸을 남겨 약하다. 가능하면 "이렇게 해"라는 긍정 방향으로 번역한다.
• "추론하지 마" 같은 포괄적 부정 제약은 정당한 추론까지 마비시킬 수 있다. 범위를 좁혀 원하는 행동을 지정한다.
• 효과적 제약은 구체적 수치·범위·대안 경로를 함께 준다. "X 대신 Y로"가 단순 금지보다 잘 지켜진다.
• 제약은 확률적 권고이지 기계적 보장이 아니다. 반드시 지켜야 하는 제약은 출력 검증·후처리로 강제한다.
• 여러 제약은 서로 충돌하지 않는지 확인한다. 충돌하는 요구는 우선순위를 정해 조정한다.

✍️ 확인 문제

1. "오타 내지 마, 틀리지 마, 이상한 말 하지 마"라는 제약 묶음이 왜 비효과적인지, 부정 지시의 두 가지 문제(활성화·빈칸)로 설명해보세요.

1. "이 답변에서 경쟁사 이름을 언급하지 마"를 대안 경로를 포함한 더 나은 형태로 바꿔보세요.

1. (실습) 고객센터 봇이 "제공된 FAQ 범위 안에서만 답하고, 환불 금액은 절대 단정하지 않도록" 하려 합니다. 포괄적 부정을 피하고, 대안 경로를 포함하며, 하드 제약은 어떻게 검증할지까지 설계해보세요.

다음 → 11. 구분자와 구조화 (XML 태그 등)
이전 ← 09. 단계적 사고 유도 · 목차