9단계맥락과 본보기를 건네고, 모르면 되묻게 하기

걸리는 시간 · 읽기 약 15분 · 따라 하기 약 50분 · 난이도 ★☆☆ 기본

이 단계를 마치면

• 어떤 요청에든 "누가 읽는가"와 "왜 필요한가"를 사실로 적어 붙이고, 자료가 여럿이면 무엇이 기준인지 정해 줄 수 있습니다.
• 예시로 말투와 형식을 전하되, 예시의 내용은 따라오지 않게 할 수 있습니다.
• 일을 시작하기 전에 Claude가 확인 질문을 하게 하고, 질문의 개수와 방식(선택지, 기본값)을 정해 줄 수 있습니다.
• 급한 일에서는 묻지 않고 가정하게 하되, 가정한 것을 드러내게 할 수 있습니다.

내가 쓴 요청을 나는 완벽하게 이해합니다. 누구에게 보낼 글인지, 왜 하필 지금 이 일을 하는지 내 머릿속에서는 너무나 분명합니다. 바로 그래서 적지 않습니다. 그런데 Claude는 그 머릿속을 들여다볼 수 없습니다. 반대 방향의 문제도 있습니다. "간결하지만 딱딱하지 않게", "전문적이되 친근하게"라고 공들여 적었는데, 내가 생각한 간결함은 세 문장이고 Claude가 생각한 간결함은 두 문단입니다. 앞의 것은 말하지 않아서, 뒤의 것은 말로만 해서 생기는 어긋남입니다. 이 단계는 둘을 함께 풉니다.

맥락이 정하는 것들

읽는 사람을 알면 말의 높이가 정해집니다. 사장에게 올리는 글과 현장 직원에게 돌리는 글은 내용이 같아도 단어가 다릅니다. 목적을 알면 무엇을 앞에 둘지가 정해집니다. 결재를 받으려는 글은 요청이 먼저, 사과하는 글은 사과가 먼저 옵니다. 지금까지의 사정을 알면 피해야 할 것이 보입니다. 맥락이 없으면 Claude는 적당히 교양 있는 일반인이 정보를 얻으려 읽는다고 가정하고, 그 결과 문장은 매끄러운데 어딘가 겉도는 글이 나옵니다. 틀린 문장이 하나도 없으니 왜 겉도는지 지적하기조차 어렵습니다.

그래서 요청마다 두 문장을 습관처럼 붙입니다. 첫 문장은 누가 읽는지, 두 번째 문장은 왜 필요한지입니다. 두 번째는 "읽고 나서 그 사람이 무엇을 하기를 바라는가"로 바꿔 써도 좋습니다. 결재해 주기를, 일정을 비워 두기를, 불만을 거두기를. 손에 익으면 세 번째 문장으로 지금까지의 사정을 더합니다. "지난달 같은 공지를 보냈는데 문의가 많았다", "고객이 이미 두 번 항의했다" 같은 문장 하나가 글의 온도를 바꿉니다.

맥락은 사실로 적어야 힘을 씁니다. "중요한 고객이다", "민감한 사안이다"에는 무엇이 중요하고 무엇이 민감한지가 빠져 있습니다. "올해 매출에서 큰 비중을 차지하는 고객이고, 지난 분기에 납기 지연으로 한 번 항의했다"로 바꾸면 Claude는 무엇을 조심해야 할지 압니다.

자료를 함께 줄 때는 무게도 함께 줍니다. 옛 규정과 새 규정을 함께 올리고 아무 말도 하지 않으면 둘이 뒤섞인 답이 나올 수 있습니다. "새 규정 원문이 기준이고 나머지는 참고다. 어긋나면 기준을 따른다"라고 적습니다. 매번 같은 자료를 올린다면 5단계의 프로젝트 지식에 넣어 두면 됩니다. 이름을 "A사"로, 금액을 가공한 값으로 바꿔도 맥락은 대부분 살아남으니, 올리기 전에 7단계의 기준을 확인합시다.

말로 안 되는 것은 보여 준다

말투와 형식은 말로 설명하기가 유난히 어렵습니다. 쓰는 사람마다 같은 단어를 다르게 읽기 때문입니다. "좀 더 부드럽게." "아, 너무 부드러운데." "조금만 더 단단하게." 이렇게 몇 번 오가다 지쳐서 결국 직접 고쳐 씁니다. 이 문제는 예시 하나로 단번에 풀립니다. 마음에 들었던 보고서 한 단락, 고객이 고맙다고 했던 답장 한 통을 붙여 넣고 "이런 식으로"라고 하면 문장 길이, 존댓말의 높이, 숫자를 쓰는 방식, 단락을 나누는 법이 한꺼번에 전해집니다. 신입에게 보고서 쓰는 법을 한참 설명하느니 잘 쓴 보고서 한 부를 건네는 편이 빠른 것과 같습니다.

예시는 힘이 센 만큼 조심할 점도 있습니다.

• 내용까지 따라올 수 있습니다. 예시에 배송 지연 이야기가 있으면 전혀 다른 문의에도 배송 이야기가 섞여 듭니다. "형식과 말투만 따르고 내용은 따르지 마라"라고 적고, 예시를 <예시> 같은 표시로 감싸 경계를 분명히 합니다.
• 하나뿐이면 버릇까지 따라옵니다. 예시가 마침 세 단락이면 모든 답이 세 단락이 됩니다. 성격이 조금씩 다른 예시를 두세 개 주면 공통된 결만 남습니다.
• 좋은 글에서 골라야 합니다. 손에 잡히는 아무 글이나 주면 그 글의 약점까지 배웁니다. 계약으로 이어진 제안 메일, 문의가 적게 들어왔던 공지, 한 번에 결재가 난 기안서처럼 읽은 사람이 좋게 반응한 글이 가장 믿을 만합니다.
• 지울 것을 지웁니다. 고객 이름과 계약 금액은 물론 메일 서명, 첨부 파일 이름, 아래에 인용된 앞 메일까지 확인합니다.

맥락과 예시는 서로의 빈틈을 메웁니다. 예시는 감을 주지만 이번 상황이 무엇인지는 알려 주지 않습니다. 처음 써 보는 종류의 글처럼 마땅한 예시가 없을 때는 맥락과 설명으로 가고, 분량이나 금지어 같은 규칙은 예시가 있더라도 문장으로 따로 적습니다. "위 예시처럼 쓰되, 환불 금액은 확정해 말하지 마라" 같은 식입니다.

왜 가장 싼가

맥락과 예시를 성실하게 건네도 빈칸은 남습니다. 빠뜨린 줄도 모르는 조건이 있기 때문입니다. 무엇이 더 들어가야 하는지는 실제로 일을 해 보는 쪽이 더 잘 압니다. 그렇다면 그 빈칸을 Claude에게 찾게 하면 어떨까요? 일을 시작하기 전에 모르는 것을 먼저 물어보라는 문장 하나면 됩니다. "모르는 게 있으면 먼저 물어봐"는 가장 싼 품질 관리입니다.

답을 받은 뒤에 틀린 곳을 발견하면 다시 설명하고, 다시 받고, 다시 읽어야 합니다. 처음에 질문 몇 개에 답하는 편이 품이 훨씬 덜 듭니다. 일 잘하는 사람이 시작 전에 묻는 것도 같은 이유입니다. 되묻게 하면 얻는 것이 하나 더 있습니다. Claude가 던진 질문에 내가 바로 답하지 못한다면, 그것은 아직 아무도 정하지 않은 일입니다. 초안을 받기 전에 그 사실을 아는 것만으로 한 번의 되풀이를 아낍니다.

다만 따로 부탁하지 않으면 Claude는 대개 묻지 않고 바로 답을 냅니다. 묻기를 원한다면 분명히 말해야 합니다.

질문의 방식을 정한다

질문이 열 개 넘게 오면 답하다 지칩니다. 그래서 방식까지 정해 줍니다. "결과를 가장 크게 바꾸는 것만, 세 개 이내로"라고 개수를 줄이고, "내가 고르기만 하면 되는 선택지 형태로" 답하기 쉽게 만들고, "질문마다 네가 추천하는 기본값을 함께"라고 적습니다. 그러면 동의하는 것은 넘어가고 다른 것만 고치면 됩니다.

모든 일에 되묻기가 어울리지는 않습니다. 급한 일이라면 "모르는 것은 합리적으로 가정하고 진행하되, 가정한 것은 맨 위에 목록으로 적어줘"라고 할 수도 있습니다. 결과를 받은 뒤 가정 목록만 훑어보고 틀린 가정 하나를 고치면 됩니다.

이 표의 마지막 행이 되묻기가 노리는 곳입니다. 되묻기로 드러난 조건을 프롬프트에 넣어 두면 다음에는 질문이 줄어듭니다. 더는 질문이 나오지 않는 프롬프트가 잘 다듬어진 프롬프트입니다. "먼저 물어봐" 문장은 13단계에서 프로젝트 지침에 넣을 첫 번째 후보이기도 합니다.

말로 한참 설명해도 안 되던 일이 맥락 두 문장과 답장 한 통으로 풀린 사례, 그리고 질문 일곱 개를 받고 당황했다가 오히려 큰 실수를 피한 사례를 차례로 봅시다.

현장 장면

온라인 가전 판매 회사 고객지원팀 최 팀장의 받은편지함에는 오늘도 불만 문의가 쌓여 있었습니다. 답장 초안만이라도 Claude에게 받으면 팀원들이 한숨 돌릴 수 있을 것 같았습니다. 그는 원하는 바를 설명으로 전했습니다.

"사과는 짧게, 해결책은 구체적으로, 과장된 표현 없이 답장 써줘. 문의 내용: 설치 기사가 약속 시간에 오지 않았다."

답장은 "고객님께 큰 불편을 드려 진심으로 깊이 사과드립니다"로 시작해 사과만 세 문장이 이어졌습니다. 해결책은 "빠른 시일 내에 조치하겠습니다"가 전부였습니다. "더 짧게"라고 한 번 더 부탁하자 사과는 줄었지만 해결책은 여전히 흐릿했습니다. 최 팀장이 말한 "짧게"와 "구체적으로"를 Claude는 전혀 다르게 읽고 있었습니다.

최 팀장은 방법을 바꿨습니다. 먼저 맥락 두 문장을 적었습니다. "이 고객은 기사 방문을 위해 반차를 냈는데 헛걸음했다. 읽고 나서 재방문 일정을 바로 잡아 주기를 바란다." 그리고 지난달 고객이 고맙다고 회신해 온 답장 한 통을 찾아, 고객 이름과 주문 번호, 기사 이름, 자기 직통 번호를 지우고 붙여 넣었습니다. 그 답장은 사과가 딱 한 문장이었고, 곧바로 "내일 오전 재방문을 잡았습니다. 이 시간이 어려우시면 이 메일에 가능한 시간을 적어 주세요"로 넘어갔습니다. "위 답장과 같은 결로 써줘. 형식과 말투만 따르고 내용은 새 문의에 맞춰."

이번에는 사과 한 문장, 재방문 제안, 선택지, 연락처 순서로 답이 나왔습니다. 그런데 뜻밖의 것이 하나 따라왔습니다. 예시에 있던 "내일 오전"이라는 시간대였습니다. 새 문의의 고객은 평일 낮에 집에 없다고 분명히 적었는데도 말입니다. 최 팀장은 "재방문 시간은 예시를 따르지 말고, 고객이 적은 사정에 맞춰 두 가지 선택지로 제안해"를 더했습니다. 세 번째 답은 날짜만 고치면 보낼 수 있었습니다.

그 뒤로 최 팀장은 성격이 다른 답장 두 통을 더 골라 모두 세 통을 예시 묶음으로 저장했습니다. 요즘 답장 초안은 고객 사정 두 문장과 이 묶음, 그리고 "내용은 따르지 마라" 한 문장으로 시작합니다.

생활용품 회사 마케팅팀 임 팀장은 신제품 출시 보도자료 초안이 급했습니다. 제품 소개 자료를 올리고 다섯 항목으로 요청을 쓴 뒤, 끝에 "시작 전에 필요한 정보가 있으면 먼저 물어봐"를 붙였습니다. 돌아온 것은 초안 대신 질문 일곱 개였습니다. 처음엔 한숨부터 나왔지만, 하나씩 읽어 내려가다 가격 공개 여부에서 멈칫했습니다. 아직 아무도 정하지 않은 문제였습니다. 초안을 받고 나서야 알았다면 가격 문단을 지우고 다시 쓰느라 한 번을 더 돌았을 것입니다.

임 팀장은 대화를 새로 열고 "결과를 가장 크게 바꾸는 질문 세 개만. 선택지 형태로. 질문마다 네 추천 기본값을 적어"라고 방식을 정했습니다. 가격 공개 여부, 임원 인용, 경쟁 제품 언급 세 가지가 왔고, 답하자 초안은 한 번에 쓸 만하게 나왔습니다. 임 팀장은 세 질문과 답을 보도자료용 프롬프트에 옮겨 적었습니다. 다음 제품의 보도자료부터 Claude는 이 세 가지를 묻지 않습니다. 이미 답이 적혀 있으니까.

따라 하기

1. 8단계에서 쓴 프롬프트를 열고, 왜 항목에 "누가 읽는가"와 "왜 필요한가"가 사실로 적혀 있는지 봅니다. 형용사로만 쓴 곳은 사실로 바꾸고, "지금까지의 사정"을 한 문장 더합니다. - 성공 기준: 세 문장 모두 구체적인 명사가 들어 있고, 셋째 문장을 읽으면 무엇을 피해야 할지 짐작할 수 있습니다.
2. 관계있는 자료가 여럿이면 올리면서 무엇이 기준인지 적습니다. - 성공 기준: 올린 자료에 실명, 실제 금액, 계약 조건이 남아 있지 않고, 기준 자료가 하나로 정해져 있습니다.
3. 같은 종류의 글 가운데 읽은 사람이 좋게 반응한 글 하나를 찾아 이름, 금액, 서명, 인용된 앞 메일을 지웁니다. - 성공 기준: 이 글만 보고는 어느 회사, 어느 고객인지 알 수 없습니다.
4. 아래 첫 번째 프롬프트에 맥락과 예시를 넣어 새 대화에서 던집니다. 예시의 내용이 따라왔다면 그 세부를 지목해 "이 부분은 예시를 따르지 마라"를 더합니다. - 성공 기준: 결과가 예시의 결을 따르고, 새 과제에 없는 사실이 하나도 없습니다.
5. 성격이 다른 예시를 하나 더 모아 두 번째 프롬프트로 공통 규칙을 뽑아 저장합니다. - 성공 기준: 쓰는 방식에 관한 규칙 다섯 가지가 메모장에 있습니다. 13단계에서 지침으로 옮깁니다.
6. 처음 맡기는 종류의 일 하나를 8단계의 다섯 항목으로 쓰고, 맨 끝에 아래 세 번째 프롬프트를 붙여 새 대화에서 던집니다. - 성공 기준: Claude가 초안 대신 질문을 돌려줍니다.
7. 질문 가운데 내가 미처 생각하지 못한 것과 바로 답하지 못하는 것에 표시합니다. - 성공 기준: 내가 놓친 조건이 하나 이상 있고, 아직 정해지지 않은 것의 목록이 있습니다.
8. 질문에 답하고 결과를 받습니다. 정해지지 않은 것은 담당자에게 확인하거나 "미정"으로 답합니다. - 성공 기준: 결과를 받은 뒤 "아니, 그게 아니라"가 나오지 않거나 줄었습니다.
9. 질문과 답을 처음 프롬프트의 알맞은 항목에 옮겨 넣고 새 대화에서 다시 던집니다. - 성공 기준: 이번에는 질문이 줄었거나 나오지 않습니다.

복사해 쓰는 프롬프트

이 글을 읽는 사람은 [누구]다. 그 사람들은 [무엇을 이미 알고 / 무엇을 모른다].
이 글이 필요한 이유는 [왜]다. 읽고 나서 그 사람들이 [무엇을 하기]를 바란다.
지금까지의 사정: [지난번에 있었던 일, 피해야 할 것].
첨부한 [자료 이름]이 기준이다. 나머지는 참고만 하고, 어긋나면 기준 자료를 따른다.

아래 예시는 우리 팀이 좋다고 판단한 [글 종류]다. 형식, 말투, 문장 길이, 단락 나누는 법만 따르고 내용은 따르지 마라.
<예시>
[개인정보를 지운 예시 글]
</예시>

위 조건으로 [해 달라는 일]을 해줘. 예시와 달라진 부분이 있다면 끝에 한 문장으로 알려줘.

아래 예시 글들의 공통된 말투와 형식을 규칙 다섯 가지로 뽑아줘. 내용은 요약하지 말고 쓰는 방식만 적어줘. 나중에 이 규칙을 프로젝트 지침에 넣을 것이다.

<예시1>
[예시 글]
</예시1>
<예시2>
[예시 글]
</예시2>

바로 시작하지 말고, 이 일을 잘하려면 나에게 확인해야 할 것을 먼저 물어봐.
- 결과를 가장 크게 바꾸는 질문만 세 개 이내로 골라줘.
- 가능하면 내가 고르기만 하면 되는 선택지 형태로 물어줘.
- 질문마다 네가 추천하는 기본값을 함께 적어줘.
- 내가 답하면 그때 시작해.

모르는 것이 있어도 멈추지 말고 합리적으로 가정해서 진행해줘.
다만 결과 맨 위에 "가정한 것" 목록을 따로 적어줘. 내가 그 목록만 보고 틀린 가정을 고칠 수 있게.

막히면 이렇게

스스로 점검

• ☐ 지금 쓰는 요청에 "누가 읽는가"와 "왜 필요한가"가 사실로 적혀 있고, 자료를 둘 이상 올릴 때 어느 것이 기준인지 적었습니까?
• ☐ 예시를 붙이기 전에 지울 것을 지우고, "형식만 따르고 내용은 따르지 마라"를 붙였습니까?
• ☐ 처음 맡기는 일에 개수와 방식을 정한 "먼저 물어봐" 문장을 붙이고, 되묻기에서 나온 조건을 프롬프트에 옮겨 넣었습니까?

기억할 것

• 누가 읽는지, 왜 필요한지, 이 두 문장은 빼지 않습니다. 맥락은 형용사 대신 사실로 씁니다.
• 자료를 여럿 줄 때는 무엇이 기준인지 말해 줍니다.
• 말투와 형식은 보여 줍니다. 예시는 읽은 사람이 좋게 반응한 글에서 고르고, 내용은 따르지 않게 합니다.
• 시작 전에 묻게 하는 한 문장이 처음부터 다시 하는 수고를 줄입니다. 급한 일은 묻는 대신 가정하게 하되, 가정한 것을 드러내게 합니다.
• 더는 질문이 나오지 않는 프롬프트가 잘 다듬어진 프롬프트입니다.