같은 일을 시켜도 어떤 요청은 바로 쓸 수 있는 결과를 내고 어떤 요청은 다시 손봐야 합니다. 차이는 표현의 세련됨이 아니라 판단에 필요한 정보가 들어 있느냐입니다. 이 수업에서는 업무 요청이 실패하는 세 자리를 짚고, 요청에 반드시 넣어야 할 네 가지를 다룹니다.
요청이 실패하는 세 자리
프롬프트가 기대에 못 미칠 때 원인은 대개 셋 중 하나입니다. 그리고 셋은 서로 다른 방식으로 고쳐야 합니다.
| 빠진 것 | 결과물에 나타나는 증상 | 고치는 방법 |
|---|---|---|
| 맥락 | 일반론만 나온다. 어느 회사, 어느 제품 이야기인지 모르는 글 | 실제 자료를 붙인다 |
| 판단 기준 | 항목은 다 있는데 무엇이 중요한지 모른 채 나열만 되어 있다 | 무엇을 기준으로 고르고 정렬할지 적는다 |
| 출력 형태 | 내용은 맞는데 회의에 그대로 못 들고 간다 | 분량·구성·받는 사람을 적는다 |
세 가지가 왜 따로인지 예로 보겠습니다. "경쟁사 분석 좀 해줘"라는 요청은 셋이 모두 빠졌습니다. 여기에 맥락만 채워 "우리는 중소기업용 회계 SaaS를 만들고 경쟁사는 A사와 B사야. 경쟁사 분석 좀 해줘"라고 하면 결과가 눈에 띄게 좋아집니다. 하지만 여전히 무엇을 기준으로 비교할지가 없어서, 받는 사람이 궁금해하지 않는 항목까지 나옵니다.
여기에 판단 기준을 더하면 이렇게 됩니다.
우리는 중소기업용 회계 SaaS를 만든다. 경쟁사는 A사와 B사다.
아래 붙인 두 회사의 가격 페이지와 기능 소개를 읽고,
"10인 미만 사업장이 우리 대신 저 회사를 고를 이유"라는 기준 하나로만
비교해 줘. 그 기준과 무관한 차이는 빼도 된다.
마지막 한 줄이 특히 중요합니다. 무엇을 빼도 되는지 알려 주면 결과가 짧아지면서 동시에 쓸모 있어집니다. 기준만 주고 제외 범위를 안 주면, 기준에 맞는 내용에 안 맞는 내용까지 얹어서 길게 나오는 경우가 많습니다.
시험에서는 "프롬프트를 더 자세히 쓰면 항상 좋아진다"는 선택지가 오답으로 나옵니다. 길이가 아니라 판단에 필요한 정보인지가 기준입니다. 회사 연혁을 세 문단 붙여도 비교 기준이 없으면 결과는 나아지지 않습니다.
업무 요청에 넣을 네 가지
실무에서 바로 쓸 수 있는 골격은 네 칸입니다. 순서는 바뀌어도 되지만 빠지면 티가 납니다.
- 누구로서, 누구를 위해 — "재무팀 담당자로서, 비재무 부서장이 읽을 자료를 만든다"
- 실제 자료 — 요약하지 말고 원문을 붙입니다. 사람이 미리 요약하면 그 요약에서 이미 정보가 깎입니다
- 판단 기준 — 무엇을 중요하게 볼지, 무엇을 뺄지
- 출력 형태 — 분량, 구성, 형식
이 중 2번에서 실수가 가장 잦습니다. 자료가 길다고 사람이 먼저 정리해서 넣으면, 정작 필요했던 단서가 그 정리 과정에서 사라집니다. 계약서 검토를 맡기면서 "주요 조항만 뽑아서" 붙이면, 문제가 될 조항은 대개 주요 조항으로 보이지 않는 곳에 있습니다.
3번은 "중요한 것만 뽑아 줘"로 대체할 수 없습니다. 무엇이 중요한지는 요청하는 쪽이 정하는 것이기 때문입니다. 같은 회의록이라도 다음 세 요청은 완전히 다른 결과를 냅니다.
| 기준 | 뽑히는 것 |
|---|---|
| 결정된 사항과 담당자 | 실행 항목 목록 |
| 합의되지 않은 채 넘어간 쟁점 | 다음 회의에서 다시 다룰 목록 |
| 일정에 영향을 주는 발언 | 리스크 목록 |
4번의 "받는 사람"은 형식뿐 아니라 내용의 깊이를 정합니다. 같은 분석이라도 팀 내부 공유용과 임원 보고용은 생략해도 되는 것이 다릅니다.
설명보다 예시가 강할 때
사내 문체나 형식을 재현해야 할 때는 설명보다 예시를 붙이는 편이 훨씬 정확합니다. "우리 회사 공지 톤으로 써 줘"는 해석의 여지가 크지만, 지난 공지 두 건을 붙이면 톤·인사말·맺음말·존칭 수준이 한 번에 전달됩니다.
예시를 쓸 때 흔한 실수는 좋은 예만 붙이는 것입니다. 피해야 할 형태가 분명하다면 그것도 함께 보여 주는 편이 낫습니다.
아래는 우리 팀이 쓰는 장애 공지 형식이다.
[좋은 예]
- 언제부터 언제까지 무엇이 안 되었는지 먼저 쓴다
- 원인은 한 문장, 재발 방지는 한 문장
- 사과 표현은 마지막에 한 번만
[피해야 할 형태]
- 사과로 시작해 세 문단이 지나도 무슨 일이 있었는지 안 나오는 글
이 형식으로 아래 상황을 공지문으로 써 줘.
예시는 두세 개면 충분합니다. 더 붙인다고 계속 좋아지지 않고, 오히려 예시에 있는 특정 표현을 그대로 가져다 쓰는 일이 늘어납니다. 예시가 특정 사례에 치우쳐 있으면 그 사례의 세부까지 따라오므로, 형식은 같고 내용은 다른 예시를 고르는 것이 좋습니다.
기술 자료를 다룰 때
비개발 직군도 기술 자료를 다뤄야 할 때가 있습니다. 개발팀이 보낸 장애 보고서를 읽고 고객 공지를 만들거나, API 문서를 보고 제휴 가능 여부를 판단하는 일입니다.
이때 가장 위험한 요청은 "쉽게 설명해 줘" 하나만 던지는 것입니다. 쉬운 설명은 필연적으로 무언가를 생략하는데, 무엇을 생략해도 되는지는 읽는 사람의 목적에 달려 있습니다. 생략 기준을 주지 않으면 결정에 필요한 부분이 잘려 나갈 수 있습니다.
| 목적 | 함께 적어야 할 것 |
|---|---|
| 고객 공지 작성 | "고객이 겪은 증상과 복구 시점만 남기고 내부 구성 이야기는 빼 줘" |
| 제휴 가능 여부 판단 | "우리가 추가로 개발해야 하는 것이 있는지, 있다면 무엇인지 중심으로" |
| 일정 협의 | "작업 단위와 각각의 선후 관계가 드러나게" |
그리고 기술 자료에서는 모르는 것을 모른다고 표시하라고 요청하는 편이 안전합니다. 용어가 낯설수록 결과가 그럴듯한지 아닌지 판단하기 어렵기 때문입니다. "자료에 없는 내용은 추측하지 말고 '자료에 없음'이라고 적어 줘"라는 한 줄이 검토 시간을 크게 줄입니다.
시험 함정
- "프롬프트는 길고 자세할수록 좋다"는 선택지 — 판단에 필요한 정보인지가 기준이지 분량이 기준이 아닙니다.
- 맥락·판단 기준·출력 형태를 하나로 뭉뚱그리는 선택지 — 셋은 증상이 다르고 고치는 방법도 다릅니다.
- 자료를 사람이 먼저 요약해 붙이라는 선택지 — 그 요약 과정에서 정작 필요한 단서가 사라집니다.
- "중요한 것만 뽑아 줘"로 판단 기준을 대신할 수 있다는 선택지 — 무엇이 중요한지는 요청하는 쪽이 정해야 합니다.
- 예시를 많이 붙일수록 좋아진다는 선택지 — 두세 개면 충분하고, 많으면 특정 표현을 그대로 베끼는 일이 늘어납니다.
- 기술 자료에 "쉽게 설명해 줘"만 붙이는 선택지 — 무엇을 생략해도 되는지가 목적마다 다릅니다.
실습 시나리오
실제 시험과 같은 형식의 시나리오 문제입니다.
고객 지원팀이 지난달 문의 300건을 정리해 개선 과제를 뽑으려 합니다. "이 문의들 분석해 줘"라고만 요청했더니 유형별 건수만 나열된 결과가 나왔습니다. 요청을 고칠 때 가장 먼저 더해야 할 것은 무엇입니까?
빌드 연습 · 요청 하나를 네 칸으로 다시 쓰기
약 30분1.실패한 요청 고르기
최근에 결과가 기대에 못 미쳤던 요청을 하나 골라 원문 그대로 적습니다.
기대 결과 · 실제로 썼던 문장이 손에 있고, 어떤 결과가 나왔는지도 함께 적혀 있습니다.
2.빠진 자리 찾기
맥락·판단 기준·출력 형태 중 무엇이 빠졌는지 표시합니다.
기대 결과 · 세 항목 각각에 있음·없음이 표시되고, 없는 항목이 결과의 어떤 증상과 이어지는지 한 줄로 적혀 있습니다.
3.네 칸으로 다시 쓰기
누구로서 누구를 위해, 실제 자료, 판단 기준, 출력 형태를 채워 요청을 다시 씁니다.
기대 결과 · 네 항목이 모두 들어간 요청문이 완성되고, 제외해도 되는 범위가 한 줄로 명시되어 있습니다.
4.두 결과 비교
원래 요청과 다시 쓴 요청을 각각 실행해 결과를 나란히 놓습니다.
기대 결과 · 두 결과의 차이가 어디에서 왔는지 항목별로 지목할 수 있습니다.
5.재사용 가능한 형태로 저장
자료 부분만 바꾸면 다시 쓸 수 있도록 요청문을 틀로 정리합니다.
기대 결과 · 바뀌는 부분과 고정된 부분이 구분되어 표시되어 있습니다.