1장. 지시문 설계

학습 목표

• 모호한 업무 요청을 목표·제약·성공 기준이 드러나는 검증 가능한 지시로 고친다.
• 작업 유형(추출·변환·생성·판단)에 따라 허용할 창작의 폭과 요구할 근거를 정한다.
• 부정형 지시를 긍정형 지시와 짧은 이유로 바꾼다.
• 시스템(개발자)·사용자·assistant 메시지의 역할과 우선순위를 설명하고, 규칙과 입력을 알맞은 자리에 둔다.
• 서로 부딪히는 지시를 찾아 적용 조건과 우선순위로 정리한다.
• 정보가 부족할 때 물을 것, 가정하고 표시할 것, 보류할 것을 나누는 정책을 쓴다.

들어가며

어느 출판사 마케팅팀에서 신간 소개 문구를 모델로 만들기 시작했습니다. 팀장이 쓴 첫 지시는 “신간 소개 문구를 매력적으로, 너무 길지 않게 써 줘”였습니다. 첫날 결과는 그럴듯했습니다. 그런데 일주일 동안 담당자 다섯 명이 같은 지시를 쓰자 결과가 제각각이었습니다. 어떤 문구는 두 줄, 어떤 문구는 열 줄이었고, 어떤 문구는 책에 없는 수상 경력을 자랑했습니다. 검수를 맡은 편집자는 문구마다 다른 기준으로 손을 봐야 했고, 얼마 지나지 않아 모델을 쓰는 편이 더 번거롭다는 말까지 나왔습니다. 회의에서 누군가 “모델이 오늘따라 이상하다”고 말했지만, 사실 모델은 매번 지시를 충실히 따랐습니다. 지시가 “매력”과 “너무 길지 않게”의 기준을 비워 두었으니, 모델은 그때그때 가장 그럴듯한 기준을 스스로 채웠을 뿐입니다.

이 장은 그 빈칸을 채우는 법을 다룹니다. 모델을 어떤 동료로 볼지에서 출발해 작업 유형과 좋은 지시의 네 요소를 익히고, 판정할 수 없는 표현을 판정할 수 있는 조건으로 바꾸는 절차, 금지 대신 할 일과 이유를 말하는 법, 메시지 역할, 규칙과 데이터를 나누는 템플릿, 충돌 정리, 정보가 모자랄 때의 정책을 차례로 봅니다. 깊이 읽기에서는 지시문의 적절한 고도, 지시문을 줄이는 편집과 비밀 정보의 자리를 다룹니다.

핵심 개념

모델은 유능하지만 오늘 처음 출근한 동료다

새로 온 동료가 아무리 뛰어나도 우리 팀의 관행, 고객, 보고 양식은 모릅니다. “보고서 좀 정리해 줘”라고만 하면 그는 자기가 아는 가장 그럴듯한 방식으로 정리할 뿐입니다. Anthropic 가이드는 모델을 “뛰어나지만 우리 규범과 업무 흐름에 대한 맥락이 없는 신입 직원”으로 생각하라고 권하고, 간단한 점검법을 황금률로 제시합니다. 맥락을 거의 모르는 동료에게 프롬프트를 보여 주고 그대로 따라 할 수 있는지 물어보는 것입니다. 동료가 헷갈린다면 모델도 헷갈립니다.

이 비유에는 한계도 있습니다. 사람 신입은 모르는 것이 있으면 옆자리에 묻고, 지난주 회의 내용을 기억하고, 틀리면 책임을 느낍니다. 모델은 주어진 컨텍스트 밖의 사정을 알 수 없고, 묻지 말라는 지시가 없어도 묻지 않고 채워 넣는 경우가 많습니다. 그래서 결과가 틀렸을 때는 원인을 두 갈래로 나눠 봐야 합니다.

작업 유형부터 정한다

지시를 쓰기 전에 이 작업이 어떤 종류인지 먼저 정하면 많은 판단이 저절로 따라옵니다. 작업 유형에 따라 모델에게 허용할 창작의 폭과 요구할 근거의 수준이 다르기 때문입니다.

추출 작업에 생성 작업의 지시(“읽기 좋게 다듬어서”)가 섞이면 원문에 없는 표현이 들어오고, 판단 작업에 기준표가 없으면 모델은 그럴듯한 기준을 만들어 적용합니다. 한 프롬프트 안에 여러 유형이 섞여 있다면 단계마다 유형을 밝히거나, 4장에서 다룰 것처럼 단계를 나누는 편이 안전합니다.

좋은 지시의 네 요소

좋은 지시는 네 가지 질문에 답합니다.

네 요소가 왜 모두 필요한지는 하나씩 빼 보면 분명해집니다.

성공 기준은 네 요소 가운데 가장 자주 빠집니다. “간결하게”, “알맞은 길이로”, “높은 품질로” 같은 말은 판정할 수 없는 표현입니다. “다섯 줄 이내”, “첫 문장에 결론”, “항목당 근거 한 개”처럼 결과만 보고 지켰는지 가릴 수 있게 바꾸면 사람이 검수하기도 쉽고, 5장에서 다룰 자동 평가로도 바로 이어집니다. Anthropic의 프롬프트 엔지니어링 개요도 프롬프트를 다듬기 전에 성공 기준, 그 기준으로 실험할 방법, 첫 초안 세 가지를 먼저 갖추라고 말합니다.

역할은 관점을 정할 뿐 지식을 주지 않는다

시스템 프롬프트에 역할 한 문장을 넣으면 모델의 관점과 말투가 그 업무에 맞게 모입니다. Anthropic 문서는 한 문장짜리 역할만으로도 차이가 난다고 설명합니다. 그러나 역할 문장이 하는 일과 하지 못하는 일을 구분해야 합니다.

“20년 경력의 세무 전문가처럼 답하라”고 써도 모델이 우리 회사 세무 처리 기준을 알게 되지는 않습니다. 필요한 기준은 컨텍스트로 주고, 모델이 판단해도 되는 범위와 사람에게 넘겨야 하는 조건을 지시에 적어야 합니다. 역할은 출발점일 뿐, 네 요소의 나머지 셋을 대신하지 못합니다.

모호한 요구를 검증 가능한 지시로 바꾸기

현업의 요청은 대개 형용사로 옵니다. “깔끔하게”, “설득력 있게”, “고객 친화적으로”. 이런 요청을 지시문으로 옮길 때는 다음 절차를 따르면 빠짐이 적습니다.

1. 형용사를 모두 표시한다. 요청서에서 판정 기준이 없는 형용사와 부사에 밑줄을 긋는다.
2. 요청자에게 “무엇을 보면 그렇다고 느끼는가”를 묻는다. “깔끔하다”가 “한 문단에 한 주제”인지 “표가 있음”인지는 요청자만 안다.
3. 관찰 가능한 신호로 바꾼다. 숫자(글자 수, 항목 수), 위치(첫 문장, 마지막 줄), 형식(표, 글머리표), 포함 여부(가격, 기한, 문의처)로 적는다.
4. 실패 조건을 함께 적는다. “근거 없는 수치가 하나라도 있으면 불합격”처럼 바로 탈락시킬 조건을 정한다.
5. 판정해 본다. 지난 결과물 몇 개를 새 기준으로 직접 판정해 보고, 판정이 갈리는 기준은 더 구체적으로 고친다.

요청: 신규 회원 안내 메일을 친근하고 너무 길지 않게.

검증 가능한 지시:
- 독자는 가입 직후의 개인 회원이다. 존댓말 평서문으로 쓰고 감탄문은 한 번까지만 쓴다.
- 본문은 600자 이내, 세 문단으로 쓴다.
- 첫 문단에 회원이 지금 바로 할 수 있는 일 하나를 적는다.
- 혜택은 제공된 혜택 목록에 있는 것만 쓴다. 목록에 없는 혜택이 하나라도 있으면 실패다.

이렇게 바꾼 지시는 검수자의 기준이 되고, 기준을 바꿀 때 무엇을 바꿨는지 기록할 근거가 됩니다.

하지 말 것보다 할 것을

“표를 쓰지 마라”는 금지만 알려 주고 무엇을 대신 써야 하는지는 비워 둡니다. Anthropic 가이드는 원하지 않는 것보다 원하는 것을 말하라고 권합니다. 예를 들어 “마크다운을 쓰지 마라” 대신 “매끄럽게 이어지는 문단으로 써라”라고 쓰는 식입니다.

덜 좋은 지시: 글머리표를 쓰지 마라.
더 좋은 지시: 답변은 키오스크 화면 한 칸에 표시되므로, 두세 문장의 평서문 한 문단으로 쓴다.

같은 맥락에서 프롬프트 자체의 서식도 출력에 영향을 줍니다. Anthropic 문서는 프롬프트의 서식 스타일이 응답의 서식 스타일에 영향을 줄 수 있으며, 프롬프트에서 마크다운을 걷어내면 출력의 마크다운도 줄어들 수 있다고 설명합니다. 제목과 글머리표로 가득한 프롬프트는 제목과 글머리표로 가득한 답을 끌어당깁니다.

긍정형이 언제나 금지를 대신하는 것은 아닙니다. 절대로 넘으면 안 되는 선(개인정보 노출, 확정되지 않은 약속)은 명시적으로 금지하는 편이 분명합니다. 이때도 금지 하나만 덩그러니 두지 말고 “대신 무엇을 하라”를 붙입니다. “확정되지 않은 일정은 약속하지 않는다. 일정을 물으면 확정일이 정해지는 시점과 확인 방법을 안내한다.”처럼 쓰면 모델은 금지된 행동 대신 할 일을 압니다.

이유를 붙이면 모델이 일반화한다

지시에 이유를 붙이면 효과가 커집니다. Anthropic 가이드의 예는 이렇습니다. “말줄임표를 절대 쓰지 마라”보다 “응답은 음성 합성 엔진이 소리 내어 읽으므로, 엔진이 발음할 수 없는 말줄임표는 쓰지 마라”가 더 낫습니다. 가이드는 모델이 설명으로부터 일반화할 만큼 똑똑하다고 덧붙입니다. 이유를 알면 모델은 비슷한 상황에도 같은 원칙을 적용할 수 있습니다. 그래도 꼭 피해야 할 기호는 직접 적고 결과로 확인합니다.

이유는 한두 문장이면 충분합니다. 긴 배경 설명은 오히려 지시의 핵심을 흐립니다. 좋은 이유는 “누가, 어디서, 왜 곤란해지는가”를 말합니다. 예를 들어 “날짜는 2026-10-20 형식으로 쓴다. 결과를 정산 시스템이 그대로 읽기 때문이다.”

순서가 중요한 절차는 번호로

여러 단계를 한 문단에 쉼표로 이어 쓰면 모델이 단계를 빠뜨리거나 순서를 바꾸기 쉽습니다. Anthropic 가이드는 단계의 순서나 빠짐없음이 중요할 때 번호 목록이나 글머리표로 순차적인 단계를 주라고 권합니다. 번호는 검수자에게도 “몇 번 단계를 지켰는가”를 확인할 기준이 됩니다.

답하기 전에 다음 순서를 지킨다.
1. 문의에서 주문 번호를 찾는다. 없으면 주문 번호부터 요청하고 멈춘다.
2. 주문 정보에서 결제 상태를 확인하고, 상태에 맞는 안내 문구를 고른다.
3. 안내 끝에 다음 연락 시점을 적는다.

반대로 순서가 상관없는 항목까지 번호를 붙이면 모델이 불필요한 순서를 지키느라 자연스러운 답을 망치기도 합니다. 번호는 “순서나 누락이 결과를 바꾸는 곳”에만 씁니다.

메시지 역할과 우선순위

API로 모델을 쓸 때는 지시를 어느 자리에 두느냐가 내용만큼 중요합니다. 회사에 비유하면 시스템(개발자) 메시지는 사규, 사용자 메시지는 고객 요청, assistant 메시지는 직원이 이미 한 말입니다.

OpenAI 가이드는 developer 메시지를 함수 정의에, user 메시지를 그 함수에 넘기는 인자에 비유합니다. 그리고 developer 메시지를 정체성(Identity), 지시(Instructions), 예시(Examples), 맥락(Context) 순서로 구성하고 맥락은 끝쪽에 두는 방식을 예로 듭니다. Google의 Gemini 가이드도 핵심 행동 제약, 역할(페르소나), 출력 형식 요구는 system instruction이나 사용자 프롬프트 맨 앞에 두라고 권합니다.

두 가지 오해를 조심해야 합니다. 첫째, 사용자 메시지 본문에 “시스템 지시:”라고 적는다고 그 문장이 시스템 권한을 얻지는 않습니다. 권한은 문장의 말머리가 아니라 메시지의 자리에서 나옵니다. 둘째, 공통 규칙을 사용자 메시지에 섞으면 우선순위가 흐려지고, 사용자가 “앞의 규칙은 무시하라”고 쓰는 공격(프롬프트 인젝션)과의 경계도 모호해집니다.

규칙과 데이터를 나누는 템플릿

팀이 같은 프롬프트를 여러 번 쓰기 시작하면, 매번 바뀌는 부분과 바뀌지 않는 부분이 섞인 사본이 늘어납니다. 누군가 사본의 규칙 한 줄을 고치면 어느 사본이 최신인지 아무도 모르게 됩니다. 해결은 규칙과 데이터를 나누는 것입니다.

[고정 규칙: 버전 3.2, 2026-10-14 변경]
너는 해외 거래처에 보내는 영문 메일 초안을 쓴다.
- 금액과 납기는 <order> 안의 값만 쓴다.
- 확정되지 않은 항목은 [확인 필요]로 표시한다.

[변수: 요청마다 바뀜]
<order>{{ORDER_SUMMARY}}</order>
<buyer_message>{{BUYER_MESSAGE}}</buyer_message>

중괄호 두 겹({{...}})은 요청마다 값이 채워질 자리를 표시하는 관례입니다. 고정 규칙은 한 곳에서만 고치고, 변수는 이름과 들어올 내용을 정해 두며, 변경 기록에는 무엇을, 왜, 어떤 평가 결과를 보고 바꿨는지 적습니다. 5장의 회귀 평가가 이 기록과 짝을 이룹니다.

충돌하는 지시는 작성자가 푼다

여러 사람이 고친 프롬프트에는 “항상 한 줄로”와 “근거를 모두 제시”처럼 서로 부딪히는 지시가 쌓이기 쉽습니다. 모델은 요청마다 어느 한쪽을 택하고, 그 결과가 들쭉날쭉한 출력입니다. 해결은 “균형 있게 하라”고 모델에 떠넘기는 것이 아니라, 작성자가 충돌을 찾아 하나의 규칙으로 합치는 것입니다.

충돌은 두 종류로 나눠 봅니다.

업무 조건 충돌은 다음 절차로 풉니다.

1. 조건을 모두 꺼낸다. 지시문의 조건을 한 줄씩 표로 옮긴다.
2. 필수와 선호를 나눈다. 어기면 사고가 나는 조건(필수)과 지키면 좋은 조건(선호)을 표시한다.
3. 함께 못 지키는 쌍을 찾는다. 한 입력에서 둘 다 지킬 수 없는 조합을 찾는다.
4. 적용 조건을 나눈다. “기본은 A, 이런 경우에는 B”로 바꿀 수 있는지 본다.
5. 나눌 수 없으면 우선순위를 적는다. “둘이 부딪히면 필수 조건을 지키고, 선호 조건을 못 지킨 이유를 한 줄 덧붙인다.”

충돌 전: 항상 표로 정리한다. / 메신저 미리보기에 맞게 짧게 쓴다.
정리 후: 기본은 세 문장 이내로 쓴다. 비교할 항목이 세 개 이상일 때만 표를 쓰고,
         표 앞에 결론을 한 문장으로 먼저 적는다.

정보가 부족할 때의 정책

입력에 필요한 정보가 빠져 있을 때 모델이 할 수 있는 일은 세 가지입니다. 묻거나, 가정하고 진행하거나, 판단을 보류하는 것입니다. 지시에 정책이 없으면 모델은 대개 그럴듯한 값을 채워 넣고 진행합니다. 정책은 정보의 성격에 따라 정합니다.

“모르면 모른다고 말해도 된다”는 허락도 정책의 일부입니다. Anthropic의 환각 줄이기 문서는 모델에게 불확실성을 인정할 권한을 명시적으로 주는 간단한 방법이 거짓 정보를 크게 줄일 수 있다고 설명합니다. 다만 허락만으로는 부족합니다. 모를 때 무엇을 할지(“담당 부서 확인이 필요하다고 알리고 문의처를 안내한다”)까지 정해 줘야 모델이 빈칸 앞에서 멈출 줄 압니다.

행동할지 제안할지, 그리고 강조의 함정

도구를 쓸 수 있는 모델에게는 “제안해 달라”와 “고쳐 달라”가 전혀 다른 지시입니다. Anthropic 가이드에 따르면 최신 모델은 지시를 정밀하게 따르도록 학습되어, “개선할 점을 제안해 줄 수 있나요?”라고 물으면 실제로 바꾸는 것이 의도였더라도 제안만 하는 경우가 있습니다. 바꾸기를 원하면 “이 함수를 고쳐라”처럼 행동을 직접 지시합니다. 반대로 모델이 묻지도 않고 행동하는 것이 문제라면, 의도가 모호할 때는 정보와 추천만 주고 명시적 요청이 있을 때만 실행하라는 기본 정책을 시스템 프롬프트에 둡니다.

되돌리기 어려운 행동에는 별도 규칙이 필요합니다. 파일 삭제, 외부 발송, 결제처럼 되돌리기 어렵거나 다른 사람에게 보이는 작업은 실행 전에 확인을 받으라고 적고, 확인이 필요한 작업의 예를 나열합니다.

강조도 다시 봐야 합니다. 예전 모델에 맞춰 “CRITICAL: 반드시 이 도구를 써라!”처럼 강하게 쓴 지시는 최신 모델에서 과잉 반응을 부를 수 있습니다. Anthropic 문서는 도구를 덜 쓰던 문제를 막으려고 넣은 공격적인 표현이 이제는 과잉 호출을 일으킬 수 있으니, “이 도구는 이런 경우에 쓴다”처럼 평범하게 쓰라고 권합니다. 강조는 조건을 대신하지 못합니다. 모델을 바꿀 때는 이처럼 예전 모델의 약점을 메우려고 넣은 강조와 “빠짐없이” 같은 문구부터 찾아 걷어내고, 반대로 원하는 수준(“가능한 한 많은 기능을 넣어라”)은 직접 요청하며, 바꾼 뒤에는 5장의 평가 세트로 전후를 비교합니다. Anthropic 문서도 특정 모델에서 측정된 기법은 다른 모델에 적용하기 전에 자기 평가로 다시 확인하라고 말합니다.

깊이 읽기

적절한 고도와 최소 프롬프트에서 시작하기

Anthropic의 컨텍스트 엔지니어링 글은 시스템 프롬프트의 실패를 두 가지로 나눕니다. 하나는 모든 예외를 if-else 규칙으로 하드코딩해 깨지기 쉽고 유지하기 어려운 프롬프트, 다른 하나는 구체적인 신호 없이 막연한 고수준 지침만 주거나 공유된 맥락을 당연하게 여기는 프롬프트입니다. 그 사이의 “적절한 고도”는 원칙과 이유, 대표 사례 몇 개로 판단의 틀을 주는 수준입니다.

고도를 맞추는 실무 방법도 같은 글에 있습니다. 쓸 수 있는 가장 좋은 모델로 최소한의 프롬프트부터 시험하고, 실제로 관찰한 실패를 근거로 지시와 예시를 더하라는 것입니다. 상상한 예외를 미리 규칙으로 쌓으면 규칙끼리 부딪히고, 어느 규칙이 효과를 내는지 알 수 없게 됩니다. 실제 입력 표본으로 최소 프롬프트를 돌려 보고, 실패를 유형별로 모은 다음, 유형마다 원칙 한 줄과 대표 예시 하나를 더하는 순서가 안전합니다.

지시문을 줄이는 편집과 비밀 정보의 자리

지시문은 고칠수록 길어지는 경향이 있습니다. 실패가 생길 때마다 한 줄씩 덧붙이기 때문입니다. 주기적으로 다음 편집을 해 주면 좋습니다.

• 같은 뜻의 문장을 하나로 합친다.
• “그것”, “위의 내용”처럼 가리키는 대상이 모호한 대명사를 실제 이름으로 바꾼다.
• 대문자, 느낌표, “절대” 같은 강조를 걷어내고 조건으로 바꾼다.
• 지운 뒤 평가 세트로 결과를 비교해, 지운 문장이 실제로 일을 하고 있었는지 확인한다.

지시문에 넣지 말아야 할 것도 있습니다. 결제 키, 내부 할인 승인 기준처럼 노출되면 피해가 생기는 정보입니다. Anthropic의 프롬프트 유출 문서는 완벽한 방법은 없다고 전제하고, 작업에 필요하지 않은 독점 정보는 아예 넣지 말라고 권합니다. 유출 방지 문구를 복잡하게 쌓는 방식은 작업 성능을 떨어뜨릴 수 있으므로 꼭 필요할 때만 쓰고, 출력 필터링 같은 감시 방법을 먼저 시도하라고 합니다. 결제 키 같은 인증 정보는 어떤 경우에도 프롬프트에 넣지 않고 서버 쪽 도구 안에 두며, 모델에게는 필요한 최소한의 권한만 줍니다. 이 최소 권한 원칙은 3장의 프롬프트 인젝션 대비에서 다시 나옵니다.

실무 장면

마루문화재단: 하나의 요청, 세 개의 채널

지역 문화재단 ‘마루문화재단’의 홍보 담당자 권 주임은 가을 야외 공연 안내문을 문자, 누리집 공지, 현수막 문구 세 가지로 만들어야 한다. 기획팀이 보낸 요청은 한 줄이다. “짧고 친근하게, 그런데 조건은 빠짐없이.” 권 주임이 이 문장을 그대로 넣자 문자 안내는 열두 줄이 되었고, 현수막 문구에는 우천 시 장소 변경 조건까지 들어갔다.

권 주임은 먼저 요청을 작업 명세로 풀었다. 작업 유형은 변환이다. 기획팀의 공연 개요서가 원본이고, 의미를 보존한 채 채널별 표현만 바꿔야 한다. 그다음 기획팀에 “빠짐없이”가 무엇인지 물었다. 답은 일시, 장소, 무료 여부, 우천 시 변경, 문의처 다섯 가지였다. “짧게”는 채널마다 뜻이 달랐다.

이 표를 만들자 충돌이 드러났다. 문자와 현수막에서는 다섯 가지를 다 지킬 수 없다. 권 주임은 “빠짐없이”를 필수 조건에서 빼지 않고 적용 조건을 나눴다. 다섯 가지를 모두 지켜야 하는 곳은 누리집 공지이고, 문자와 현수막은 누리집 공지로 이어지는 입구라는 역할을 명시했다. 그래서 문자에는 상세 링크를 필수로 넣었다.

권 주임이 버린 선택지도 있다. 첫째, 세 채널을 한 번에 요청하면서 “채널에 맞게 적절히”라고 쓰는 방법이다. 판단을 모델에 떠넘기는 방식이라 이전과 같은 흔들림이 생길 것이었다. 둘째, “절대 길게 쓰지 마라”를 굵게 반복하는 방법이다. 무엇이 긴지 정의하지 않으면 강조는 아무것도 바꾸지 못한다.

최종 지시문에는 공통 규칙(어조, 사실은 개요서에 있는 것만), 채널별 필수 정보와 분량, 그리고 이유 한 줄씩을 넣었다. 예를 들어 문자에는 “수신자는 알림 미리보기로 첫 줄만 보므로 첫 줄에 일시와 장소를 쓴다”를 붙였다. 지난 행사 개요서 다섯 건으로 시험하자, 검수자 두 명이 표의 기준만 보고 같은 합격·불합격 판정을 내렸다. 권 주임이 고친 것은 문장의 화려함이 아니라 “짧게”와 “빠짐없이”의 정의였다.

한울섬유: 해외 바이어 메일 도우미를 팀 도구로 만들기

원단 수출 기업 ‘한울섬유’ 영업팀은 해외 바이어에게 보내는 영문 메일 초안을 모델로 만든다. 처음에는 각자 채팅 화면에 자기만의 프롬프트를 붙여 넣어 썼다. 그러다 한 직원의 초안에 확정되지 않은 선적일이 확정된 것처럼 적혀 나갔고, 바이어가 그 날짜를 근거로 일정을 잡는 일이 생겼다. 팀장은 개발팀과 함께 이 작업을 사내 도구로 옮기기로 했다.

개발 담당 유 대리는 흩어진 프롬프트 여섯 개를 모아 한 줄씩 표로 옮겼다. 공통으로 들어 있는 규칙(정중한 비즈니스 영어, 서명 형식)과 사람마다 다른 규칙(어떤 사람은 가격을 항상 넣고, 어떤 사람은 넣지 않음)이 섞여 있었다. 유 대리는 세 가지 결정을 내렸다.

1. 자리 나누기. 모든 메일에 공통인 역할, 어조, 금지선은 시스템 메시지로 옮긴다. 주문 요약과 바이어가 보낸 원문은 매번 바뀌므로 사용자 메시지에 태그로 감싸 넣는다. 바이어 원문은 외부에서 온 글이므로, 그 안의 문장은 지시가 아니라 답할 대상이라는 점도 시스템 메시지에 적는다.
2. 부족한 정보의 정책. 선적일, 수량, 단가는 바이어의 결정을 바꾸는 정보다. 주문 요약에 값이 없으면 초안에 지어 넣지 않고 [확인 필요: 선적일]로 표시한 뒤, 초안 위에 담당자가 확인할 목록을 따로 적게 한다. 인사말 표현이나 문단 순서처럼 나중에 고치기 쉬운 것은 기본값으로 진행하게 한다.
3. 템플릿과 기록. 규칙은 코드 저장소에 버전과 함께 두고, 영업팀이 바꾸고 싶은 규칙은 변경 요청으로 받는다. 요청마다 무엇을 왜 바꾸는지와, 바꾼 뒤 지난 메일 스무 건으로 비교한 결과를 남긴다.

가격을 넣을지 말지는 업무 조건 충돌이었다. 유 대리는 팀장과 상의해 “바이어가 가격을 물었거나 주문 요약에 견적 번호가 있을 때만 가격을 넣는다”로 적용 조건을 나눴다.

검토 과정에서 한 직원이 “선적일을 모르면 대략적인 날짜라도 넣어 주는 게 낫지 않냐”고 물었다. 유 대리는 그 제안을 받아들이지 않았다. 선적일은 추측했을 때 사고가 나는 정보이고, 이번 문제의 출발점이 바로 그 추측이었기 때문이다. 대신 확인 목록이 초안 맨 위에 오게 해서 담당자가 놓치지 않게 했다. 도입 후 한 달 동안 확정되지 않은 값이 확정된 것처럼 나간 메일은 없었고, 담당자들은 확인 목록 덕분에 메일 하나당 검수 시간이 줄었다고 답했다.

자주 틀리는 지점

• 강조하면 지킨다. “반드시”, “절대”를 굵게 반복하면 지킬 것 같지만, 무엇을 해야 하는지 정의하지 않으면 모호함은 그대로입니다. 최신 모델에서는 지나친 강조가 오히려 과잉 반응을 부릅니다.
• 역할만 주면 된다. 역할 문장은 관점과 어조를 잡아 주지만 회사 고유의 지식, 분량, 항목 같은 성공 기준은 주지 못합니다.
• 사용자 메시지에 “시스템:”이라고 쓰면 시스템 지시가 된다. 권한은 문장의 말머리가 아니라 메시지의 자리에서 나옵니다.
• “균형 있게”라고 쓰면 충돌이 풀린다. 판단을 모델에 떠넘기면 요청마다 다른 쪽을 고릅니다. 적용 조건이나 우선순위를 작성자가 정해야 합니다.
• 금지만 적으면 충분하다. 금지는 무엇을 대신할지 비워 둡니다. 할 일을 긍정형으로 쓰고, 꼭 필요한 금지에는 대안을 붙입니다.
• 모르면 알아서 묻겠지. 정책이 없으면 모델은 대개 그럴듯한 값을 채우고 진행합니다. 물을 것, 가정할 것, 보류할 것을 지시에 적어야 합니다.
• 예외를 규칙으로 다 적을수록 안전하다. 상상한 예외를 쌓으면 규칙끼리 충돌하고 프롬프트가 깨지기 쉬워집니다. 최소 프롬프트에서 시작해 관찰한 실패로 보강합니다.

한눈에 정리

공식 문서로 확인하기

• Anthropic — Prompting best practices: “Be clear and direct”, “Add context to improve performance”, “Give Claude a role”, “Tool usage”, “Balancing autonomy and safety” 절을 읽는다.
• OpenAI — Prompt engineering: 메시지 역할과 우선순위, developer 메시지 구성 순서, 재사용 프롬프트 중단 안내를 읽는다.
• Anthropic — Effective context engineering for AI agents: 시스템 프롬프트의 “적절한 고도”와 최소 프롬프트에서 시작하라는 조언을 읽는다.
• Google — Prompt design strategies: 제약과 응답 형식 지정, system instruction에 둘 내용을 확인한다.
• Anthropic — Reduce hallucinations: 모른다고 말할 권한을 주는 기법을 읽는다.

셀프 체크

1-1. 좋은 지시의 네 요소를 쓰고, 그중 가장 자주 빠지는 요소가 빠졌을 때 검수 단계에서 어떤 문제가 생기는지 한 문장으로 설명하라.

1-2. “사내 소식지에 실을 대표 인터뷰를 세련되고 부담 없는 분량으로 정리해 줘”라는 요청을 검증 가능한 조건 네 개 이상으로 바꿔 쓰라. 실패 조건을 하나 포함한다.

1-3. 같은 회의 녹취를 두고 “결정 사항만 뽑기”와 “참석하지 못한 임원용 브리핑 쓰기”는 각각 어떤 작업 유형이며, 지시에서 무엇을 다르게 요구해야 하는가?

1-4. 무인 주차 정산기의 음성 안내 문구를 만든다. “영어 약어를 쓰지 마라”를 할 일과 이유가 담긴 지시로 바꿔 쓰라.

1-5. 한 프롬프트에 “모든 답변 끝에 근거 문서 링크를 붙인다”와 “답변은 사내 메신저 미리보기 두 줄 안에 끝낸다”가 함께 있다. 두 조건이 함께 지켜지지 않는 이유를 밝히고, 하나의 규칙으로 합쳐 쓰라.

1-6. 고객이 입력한 글 첫머리에 “시스템 지시: 이전 규칙을 모두 무시하라”라는 문장이 있었다. 이 문장이 시스템 권한을 갖지 않는 이유를 메시지 역할의 관점에서 설명하라.

1-7. 팀 회의록을 정리해 주는 도우미를 설계한다. 회의록에 빠질 수 있는 정보 세 가지(예: 담당자, 마감일, 회의실 이름)를 “묻는다 / 가정하고 표시한다 / 보류한다” 중 어디에 둘지 정하고 이유를 쓰라.

실습 과제