'Do & Don't'와 제약조건: 원하는 것/원치 않는 것 명시하기

결과를 흔드는 가장 큰 원인은 모델의 능력이 아니라 요구사항의 빈칸입니다. 우리는 보통 "이렇게 해줘"는 말하지만, "이건 절대 하지 마"와 "여기까지만 해"를 적지 않습니다. 그 빈칸은 대개 모델이 채우고, 그 채움이 곧 수정 지옥의 시작이 됩니다.

이 장의 목표는 간단합니다. 금지/허용, 범위 제한, 반드시 포함할 항목, 피해야 할 표현을 짧고 단단하게 설계해서 결과 편차를 줄이는 것입니다. 핵심은 '나쁜 답을 고치는 능력'이 아니라, 나쁜 답이 나오기 어려운 프롬프트를 만드는 습관입니다.

Do & Don't는 '글쓰기 팁'이 아니라 '사양(Spec)'이다

Do & Don't는 취향을 적는 칸이 아닙니다. 실무에서 Do & Don't는 모델에게 주는 작업 사양입니다.

예를 들어 "보고서 요약해줘"는 목적만 있고 사양이 없습니다. 그러면 모델은 다음을 스스로 결정합니다.

• 어디까지가 요약인지(배경 포함? 숫자 포함?)

• 무엇이 '중요'한지(리스크? 성과? 다음 액션?)

• 무엇을 빼야 하는지(세부 절차? 불확실한 추정치?)

반대로 사양이 있으면 모델이 결정할 영역이 줄어듭니다. 모델이 결정할 영역이 줄어들수록 결과는 안정적이 됩니다.

"Don't"를 그대로 쓰면 실패하는 이유: 금지 대신 '대체 행동'을 주기

"과장하지 마", "AI처럼 쓰지 마", "헛소리 하지 마" 같은 Don't는 의외로 잘 안 먹힙니다. 이유는 간단합니다.

첫째, '하지 말라'는 말은 무엇을 해야 하는지를 알려주지 않습니다. 둘째, "AI처럼", "과장", "헛소리" 같은 단어는 사람에게도 주관적이라 기준이 흔들립니다. 결국 모델은 금지어를 피해가면서도 비슷한 행동을 하거나, 오히려 금지 대상(예: 과장 표현)을 떠올리며 문장을 만들기도 합니다.

그래서 Don't를 쓸 때는 원칙적으로 한 번 더 번역합니다.

• Don't(금지) → Do(대체 행동)

예시는 다음과 같습니다.

• "지어내지 마" 대신 "근거가 없으면 '확인 불가'라고 쓰고, 필요한 추가 정보를 질문해라."

• "장황하게 쓰지 마" 대신 "각 단락은 3문장 이하, 핵심 주장 뒤에 바로 예시 1개를 붙여라."

• "감정 과잉 금지" 대신 "평가·감탄 표현을 빼고, 관찰/사실/행동 제안만 써라."

Don't가 완전히 쓸모없는 것은 아닙니다. 다만 Don't만 잔뜩 적으면 결과가 좋아지기보다, 제약에 눌린 어정쩡한 글이 나오기 쉽습니다. Don't는 '경계선'을 긋는 도구이고, 방향은 Do가 잡아야 합니다.

제약조건의 4종류: 무엇을 통제하려는지부터 분류하기

제약조건은 종류가 다르면 쓰는 방식도 달라집니다. 실무에서 특히 자주 쓰는 네 가지를 먼저 구분해 두면 설계가 쉬워집니다.

1) 범위(스코프) 제약: "여기까지만"

스코프 제약이 없으면 모델은 친절하게 배경을 늘리고, 관련 개념을 추가하고, 반대 의견까지 붙이며 글을 키웁니다. 요약이나 답변이 '길어지는 문제'는 대부분 길이 제약보다 범위 제약이 먼저입니다.

스코프 제약은 다음처럼 씁니다.

• "아래 입력 텍스트에 포함된 내용만 사용하라. 외부 지식으로 보강하지 마라."

• "정책/법률 해석은 하지 말고, 일반적인 주의사항만 제시하라."

• "비교 대상은 A와 B만. C를 언급하지 마라."

2) 포함(필수) 제약: "이건 반드시"

필수 항목은 '좋으면 넣어줘'가 아닙니다. 누락되면 실패인 요소를 말합니다.

필수 제약은 '검증 가능한 형태'로 적어야 합니다.

• "반드시 포함: 결론 1문장 + 근거 3개 + 다음 행동 2개"

• "반드시 포함: 반대 의견 1개와 그에 대한 대응 1개"

• "반드시 포함: 용어 정의(한 줄) 후 본문 시작"

3) 금지(배제) 제약: "이건 빼라"

금지 제약은 가장 강력하지만, 가장 남용되는 도구이기도 합니다. 금지는 결과의 안전장치로 쓰고, 너무 많아지면 모델이 중요한 규칙을 놓치기 쉽습니다.

금지 제약은 다음 세 가지 중 하나로 명확히 만드는 편이 좋습니다.

• 금지 주제(예: 개인정보, 경쟁사 비방)

• 금지 표현(예: 과장/단정/모호어)

• 금지 행동(예: 근거 없는 수치 생성, 없는 출처 만들기)

4) 허용(예외) 제약: "이럴 땐 이렇게"

모델이 실수하는 순간은 대개 '모호한 상황'입니다. 그래서 사양에는 금지보다 예외 처리가 필요합니다.

• "정보가 부족하면 추정하지 말고 질문 1~2개만 해라."

• "정답이 하나로 고정되지 않으면, 선택지 2개와 선택 기준만 제시해라."

• "근거가 없으면 '확인 불가'라고 표시하고, 다음에 확인할 자료를 제안해라."

이 예외 규칙이 없으면 모델은 질문 대신 출력을 계속 만들려고 하거나, 그럴듯한 답을 만들어 냅니다.

하드 제약 vs 소프트 제약: '법'과 '선호'를 섞지 않기

제약은 모두 같은 무게가 아닙니다.

하드 제약은 위반하면 실패입니다. 예를 들어 "개인정보를 포함하지 마라", "JSON만 출력하라", "항목은 정확히 5개" 같은 규칙입니다.

소프트 제약은 선호입니다. 예를 들어 "가능하면 비유를 써라", "되도록 전문용어를 줄여라" 같은 규칙입니다.

문제는 하드와 소프트를 같은 어조로 섞을 때 생깁니다. 모델 입장에서는 모두 '비슷한 부탁'처럼 보이기 쉽기 때문입니다. 따라서 프롬프트에서 두 종류를 분리해 적는 것이 안전합니다.

• 필수(하드): must, only, exactly, never

• 선호(소프트): preferably, try to, if possible

한국어로도 똑같습니다.

• 하드: "반드시", "오직", "정확히", "절대"

• 소프트: "가능하면", "되도록", "권장"

'피해야 할 표현'을 설계하는 법: 금지어 목록보다 '판정 규칙'

실무에서 흔히 하는 방식은 금지어 리스트를 길게 붙이는 것입니다. 하지만 금지어만 나열하면 두 가지 문제가 생깁니다.

첫째, 금지어를 피해 동의어로 돌아옵니다. 둘째, 문장이 어색해지고 핵심이 흐려질 수 있습니다.

따라서 표현을 통제하고 싶다면 "이 단어를 쓰지 마"보다 "이런 유형의 문장 구조를 쓰지 마"가 더 안정적입니다. 예를 들면 다음과 같습니다.

• 모호어 금지: "많은/여러/상당히/일부" 같은 표현 대신, 숫자·범위·조건으로 쓰기

• 과장 금지: "최고/완벽/혁신" 같은 표현 대신, 검증 가능한 효과(시간/비용/오류 감소 등)로 쓰기

• 단정 금지: "반드시/무조건" 대신, 전제 조건을 붙여 쓰기(예: "X라면 Y일 가능성이 높다")

표현 통제는 '글맛' 문제가 아니라 '검증' 문제입니다. 사람이 빠르게 체크할 수 있는 규칙으로 바꾸면 재작업이 줄어듭니다.

제약조건은 5개 이내가 기본이다: 가장 비싼 실수부터 막기

제약을 많이 넣을수록 결과가 좋아질 것 같지만, 실제로는 반대가 자주 일어납니다. 규칙이 많아지면 모델도 사람처럼 우선순위를 놓치고, 서로 충돌하는 규칙이 생깁니다.

그래서 처음에는 3~5개만 둡니다. 기준은 하나입니다.

• 수정 비용이 큰 실패를 먼저 막는다.

예를 들어 글이 조금 길어지는 것은 편집으로 해결할 수 있지만, '근거 없는 사실'이나 '금지해야 할 내용'은 손실이 큽니다. 이런 항목부터 하드 제약으로 올립니다.

실무에서 자주 1순위로 올리는 제약은 보통 다음 중 일부입니다.

• 불확실하면 '모른다/확인 필요'를 허용하고, 추정을 금지

• 입력 자료 밖의 내용 보강 금지(또는 보강 시 "추정/일반론" 라벨)

• 반드시 포함할 핵심 항목(숫자, 결론, 다음 액션 등)

규칙을 '앞에' 두고 '다시' 말하라: 긴 작업일수록 반복이 필요하다

모델은 긴 답을 만들수록 규칙을 놓치기 쉽습니다. 특히 문서를 길게 쓰게 할수록, 프롬프트 앞부분의 제약이 뒤로 밀립니다.

그래서 중요한 규칙은 세 번 등장시키는 편이 안전합니다.

• 시작: 규칙 블록(최상단)

• 중간: 본문 작성 지시 바로 앞에서 한 번 요약

• 끝: 출력 직전 체크리스트

반복은 장식이 아니라 보험입니다. 특히 "절대 포함하면 안 되는 것"이 있을 때는 더 그렇습니다.

2단계 워크플로로 '수정 지옥'을 끊기: 작성 → 자기검사

제약이 까다로운 작업은 한 번에 끝내려고 할수록 실패합니다. 대신 작업을 두 단계로 나눕니다.

1단계에서 작성하고, 2단계에서 제약 체크리스트로 자기검사한 뒤, 위반한 부분만 국소 수정하게 합니다. 이 방식은 "다시 써"가 아니라 "어디가 규칙을 어겼는지 찾아서 그 부분만 고쳐"로 움직이게 만들어 결과가 안정적입니다.

자기검사 체크리스트는 길 필요가 없습니다. 5개 내외의 하드 제약만 넣어도 충분합니다.

바로 쓰는 템플릿: Do/Don't 사양 블록

아래 템플릿은 7장에서 다룬 요소를 한 덩어리로 만든 '사양 블록'입니다. 5장에서 다룬 형식/길이 고정과 함께 쓰면 가장 강합니다.

템플릿 A) Do/Don't + 범위 + 예외 처리

아래를 복사해 {}만 채워 쓰면 됩니다.

역할: 너는 {역할}이다.

목표: {사용자}가 {원하는 결과}를 얻도록 {산출물}을 만든다.

범위(스코프):

• {자료/입력}에 있는 내용만 사용한다.

• 다루지 말 것: {금지 주제/범위 밖 항목}

반드시 포함(Do, 하드):

• {필수 항목 1}

• {필수 항목 2}

• {필수 항목 3}

절대 하지 말 것(Don't, 하드):

• {금지 행동 1: 예) 근거 없는 수치/출처 생성}

• {금지 행동 2: 예) 개인정보/민감정보 포함}

• {금지 행동 3: 예) 과장/단정 표현}

예외(불확실성 처리):

• 정보가 부족하면 추정하지 말고, 질문을 최대 2개만 한다.

• 답을 확정할 수 없으면 '확인 필요'라고 표시하고, 무엇을 확인해야 하는지 쓴다.

작업 방식(2단계):

1. 초안을 만든다.

2. 아래 체크리스트로 자기검사하고, 위반 항목만 고쳐 최종본을 낸다.

자기검사 체크리스트:

• 필수 항목이 모두 들어갔는가?

• 범위를 벗어난 내용이 들어갔는가?

• 추정/지어냄이 있는가?

• 금지 표현/금지 행동이 있는가?

• 최종 출력이 요청한 작업에만 집중하는가?

템플릿 B) Don't를 Do로 번역하는 한 줄 패턴

Don't를 그대로 쓰고 싶을 때, 아래 패턴으로 한 번 더 번역해 붙입니다.

• "{하지 말 것}" → "대신 {할 것}을 하라. 불가능하면 {예외 처리}를 하라."

예를 들어 "장황하게 쓰지 마"를 이렇게 바꿉니다.

• "장황하게 쓰지 마" → "핵심 주장 → 근거 → 예시 순서로만 쓰고, 각 단락은 3문장 이하. 더 길어질 것 같으면 요약만 먼저 내고 '추가 확장 가능'이라고 표시해라."

미니 실습: 실패 모드 3개를 '규칙'으로 바꿔보기

지금 하는 일을 하나 떠올려 보세요. 요약, 이메일, 기획서 초안, 고객 답변, 코드 리뷰 중 무엇이든 좋습니다. 그 작업에서 자주 겪는 실패를 세 개만 적습니다.

예를 들어 "요약"이라면 실패는 보통 이런 식입니다.

• 배경이 너무 길다

• 결론이 없다

• 없는 내용을 있는 것처럼 말한다

이제 각각을 규칙으로 바꿉니다.

• 배경이 너무 길다 → "첫 문장은 결론. 배경은 2문장까지만."

• 결론이 없다 → "반드시 '결론: …' 한 줄을 포함."

• 없는 내용을 말한다 → "입력에 없는 내용은 '확인 필요'로 표시. 추정 금지."

이 세 줄만으로도 결과의 흔들림이 크게 줄어듭니다. 규칙을 늘리기 전에, 먼저 가장 비싼 실패 3개부터 막는 것이 순서입니다.

마무리

Do & Don't와 제약조건의 목적은 모델을 '통제'하는 데 있지 않습니다. 수정할 필요가 없는 결과가 나오게 만드는 것이 목적입니다.

오늘부터는 Don't를 길게 늘어놓는 대신, Don't를 Do로 번역하고, 범위를 자르고, 필수 항목을 못 박고, 불확실할 때의 행동을 정해 두세요. 그러면 불필요한 출력이 먼저 사라지고, 그 자리에 필요한 출력이 남습니다.

다음 장에서는 한 번에 끝내려는 습관을 버리고, 제약을 유지한 채로 작업을 단계로 쪼개는 대화형 워크플로로 넘어가겠습니다.