91단계가장 자주 빠지는 다섯 가지 함정
1~90단계에서 수강생들이 가장 많이 넘어진 곳을 한 페이지로 정리한다.
걸리는 시간 · 읽기 약 10분 · 따라 하기 약 30분 · 난이도 ★☆☆ 기본
이 단계를 마치면
- 결과가 마음에 들지 않았던 대화를 열어, 다섯 함정 가운데 어디에 빠졌는지 지적할 수 있다.
- 달랑 한 문장짜리 요청을, 무엇을 확인할지 분명한 요청으로 고쳐 쓸 수 있다.
- 내가 가장 자주 빠지는 함정 하나를 알고, 그것을 막는 문장을 프로젝트 지침에 넣을 수 있다.
Claude가 엉뚱한 답을 내놓았을 때, 여러분은 보통 무엇을 탓하는가? 대개는 도구를 탓한다. 그런데 수업에서 "Claude가 이상한 답을 한다"며 가져온 대화를 열어 보면 이야기가 달라진다. 막히는 곳은 사람마다 제각각일 것 같지만, 실제로는 크게 다섯 가지로 모인다. 흐린 지시, 빠진 맥락, 한꺼번에 맡기기, 확인 생략, 받은 글 그대로 내보내기다. 게다가 이 다섯은 따로 놀지 않는다. 지시가 흐리면 맥락도 대개 빠져 있고, 한꺼번에 맡기면 확인할 엄두가 나지 않으며, 확인을 건너뛰면 결국 받은 글을 그대로 내보내게 된다. 함정 하나가 다음 함정을 불러온다.
왜 이 다섯인가
다섯 함정에는 공통점이 있다. 모두 사람이 해야 할 일을 Claude에게 넘긴 곳이다. 흐린 지시는 무엇을 원하는지 정하는 일을, 빠진 맥락은 상황을 파악하는 일을 넘긴다. 한꺼번에 맡기기는 순서를 정하는 일을, 확인 생략은 판정을, 받은 글 그대로 내보내기는 책임을 넘긴다. Claude는 넘겨받은 빈칸을 그럴듯한 추측으로 채운다. 추측이 맞으면 운이 좋았을 뿐이고, 틀리면 그 틀림은 매끄러운 문장 속에 숨어 버린다.
이 구조를 모르면 결과가 나쁠 때 도구를 탓하며 "아직 AI는 이 정도구나" 하고 접어 버린다. 그런데 같은 도구로 옆 팀은 잘만 쓰고 있다. 두 팀의 차이는 Claude에게 넘긴 빈칸의 수에서 생긴다. 실제로 잘 안 풀렸다는 대화를 들여다보면, 대개 이 다섯 가운데 둘 이상에 한꺼번에 빠져 있다.
다섯 함정을 피하는 법
피하는 법은 이미 앞에서 배웠다. 여기서는 어디서 배웠는지를 한곳에 모아 둔다.
| 함정 | 알아채는 신호 | 피하는 법 | 다시 볼 단계 |
|---|---|---|---|
| 흐린 지시 | 답이 매번 다른 형식으로 온다 | 누구로서 · 왜 · 무엇을 · 어디까지 · 어떤 형식으로를 채운다 | 9단계 · 다섯 칸 질문 틀 11단계 · 형식을 정하고 근거부터 받기 |
| 빠진 맥락 | 답이 일반론이다. 우리 회사 이야기가 없다 | 읽을 사람, 기준 자료, 이미 정한 것을 적는다. 모르면 되묻게 한다 | 10단계 · 맥락과 본보기를 함께 건네기 12단계 · 되묻게 하기 |
| 한꺼번에 맡기기 | 답이 길고 어디부터 봐야 할지 모르겠다 | 한 번에 결과물 하나. 단계마다 멈춘다 | 60단계 · 한 동료에게는 한 가지 일만 92단계 · 긴 작업은 쪼개고 맥락은 관리하기 |
| 확인 생략 | 숫자나 이름을 원본과 대조한 적이 없다 | 기준표로 채점하고, 숫자는 원본과 맞춘다 | 7단계 · 틀린 답을 알아보는 법 33단계 · 다 됐다는 말을 그대로 믿지 않는다 93단계 · 결과를 평가하는 기준 |
| 받은 글 그대로 내보내기 | 보고서에 내가 쓴 문장이 하나도 없다 | 결론과 마지막 문장은 내가 쓴다 | 13단계 · 고쳐 쓰기 대화 |
마지막 함정은 조금 더 이야기하고 넘어가자. 결과물에 내 이름이 붙는 순간 책임도 내 것이 된다. 회의실에서 "Claude가 그렇게 썼습니다"는 변명이 되지 못한다. 마지막 문장을 직접 쓰는 습관은 품질을 넘어 결국 책임의 문제다. 직접 쓰려면 읽어야 하고, 읽다 보면 틀린 곳이 눈에 들어온다.
모든 요청에서 다섯 가지를 빈틈없이 채울 필요는 없다. 가벼운 일은 가볍게 처리하면 된다. 밖으로 나가는 결과물, 숫자가 들어간 결과물, 윗사람이 읽을 결과물이라면 그때 다섯 가지를 모두 확인한다.
직급과 부서에 따라
경영진이 가장 자주 빠지는 함정은 받은 글 그대로 내보내기다. 보고받은 요약을 다시 요약해 이사회에 올릴 일이 많아서다. 팀장은 한꺼번에 맡기기에 약하다. 맡은 일이 많다 보니 한 번에 넘기고 싶어진다. 실무자는 맥락을 빠뜨린다. 자기에게는 너무 당연한 사정이라 굳이 적지 않는다. 재무나 법무처럼 숫자와 문구가 곧 결과인 부서는 확인을 생략했을 때 치르는 대가가 크고, 마케팅이나 기획처럼 초안을 많이 뽑는 부서는 흐린 지시 때문에 가장 많은 시간을 잃는다. 내 위치에서 가장 빠지기 쉬운 함정 하나만 먼저 알아 두면 다섯 가지를 다 외울 필요가 없다.
실수는 대개 바쁠 때 생긴다. 그래서 점검표가 필요하다. 보내기 전에 다섯 가지만 훑어보면 된다.
현장 장면
월요일 아침, 제조사 기획팀의 박 팀장은 출근하자마자 Claude 창을 열고 이렇게 입력한다.
지난달 실적 정리해 줘. 그리고 경쟁사 동향이랑 다음 달 계획도.
첨부한 엑셀 파일은 세 개다. 「9월 매출_v2」, 「9월 매출_최종」, 「9월 매출_최종_수정」. 어느 것이 확정본인지는 말하지 않았다. 누가 읽을 자료인지도 밝히지 않았다. 그래도 답은 길고 그럴듯하게 돌아온다. 매출 요약, 경쟁사 세 곳의 움직임, 다음 달 실행 계획 다섯 가지. 박 팀장은 합계를 검산하지 않은 채 그대로 임원 보고서에 붙여 넣는다.
화요일 임원 회의. 보고서를 넘기던 재무 담당 임원이 손을 멈춘다.
"이 합계는 어느 파일 기준입니까?"
박 팀장은 대답하지 못한다. 나중에 확인해 보니 Claude는 「v2」를 기준으로 삼았고, 그 파일에는 반품 조정이 빠져 있었다. 경쟁사 동향 가운데 하나는 출처가 없었다. 다음 달 계획은 지난주에 이미 다른 방향으로 정해진 내용과 어긋났다.
무엇이 문제였을까. 다섯 함정에 비춰 보면 이렇다.
| 함정 | 박 팀장이 한 것 | 빠진 것 |
|---|---|---|
| 흐린 지시 | "실적 정리해 줘" | 정리 형식(표인가 글인가), 분량, 비교 기준(전월 대비인가 계획 대비인가) |
| 빠진 맥락 | 파일 세 개를 그냥 첨부 | 어느 것이 확정본인지, 읽을 사람이 임원이라는 사실, 이미 정해진 다음 달 방향 |
| 한꺼번에 맡기기 | 실적·경쟁사·계획을 한 문장에 | 세 일은 필요한 자료도, 확인 방법도 다르다 |
| 확인 생략 | 합계를 검산하지 않음 | 원본 합계와 한 번 대조하기 |
| 받은 글 그대로 내보내기 | 답을 보고서에 그대로 붙임 | 결론을 자기 말로 다시 쓰기 |
박 팀장은 같은 일을 다시 맡긴다. 이번에는 세 번으로 나눈다. 첫 요청은 이렇다.
나는 기획팀장이고, 이 자료는 목요일 임원 회의에서 3분 안에 보고할 내용이다.
기준 파일은 「9월 매출_최종_수정」 하나다. 나머지 두 파일은 보지 마.
9월 매출을 계획 대비, 전월 대비로 비교해 표 하나로 정리해 줘. 제품군별 행, 합계 행 포함.
표 아래에 눈에 띄는 변화 세 가지를 한 줄씩. 원인은 파일에 근거가 있을 때만 적고, 없으면 [원인 확인 필요]라고 써.
경쟁사와 다음 달 계획은 이번에는 다루지 마.
답이 오자 박 팀장은 먼저 합계 행을 원본 파일의 합계와 맞춰 본다. 숫자 하나가 다르다. 어느 행에서 어긋났는지 묻자 반품 조정 행을 빠뜨렸다는 답이 돌아오고, 고친 표의 합계는 원본과 정확히 맞는다. 표 아래 세 문장 가운데 하나에는 [원인 확인 필요]가 붙어 있다. 박 팀장은 영업팀에 그 부분만 물어 채우고, 임원 보고에 쓸 결론은 자기 말로 직접 쓴다. 경쟁사 동향은 웹 검색을 켠 새 대화에서 출처 링크와 함께 따로 받는다(4단계). 다음 달 계획은 지난주 결정 문서를 첨부해 세 번째로 맡긴다.
전과 후를 나란히 놓으면 차이가 선명하다. 처음 요청은 짧았지만 확인할 거리가 없었다. 고친 요청은 길어졌지만 확인할 곳이 분명하다. 합계 하나, 원인 표시 세 개. 박 팀장이 쓴 시간은 몇 분 늘었을 뿐이다. 그리고 회의실에서 답하지 못할 질문은 사라졌다.
따라 하기
- 지난 한 주 동안 Claude와 나눈 대화 가운데 결과가 마음에 들지 않았던 것 세 개를 찾는다. 성공 기준: 세 대화의 첫 요청 문장을 그대로 옮겨 적었다.
- 대화마다 다섯 함정 중 어디에 빠졌는지 표시한다. 둘 이상이어도 괜찮다. 성공 기준: 대화마다 빠진 함정과 그 근거가 한 문장씩 있다. "그냥 별로였다"는 근거가 되지 못한다.
- 세 대화에서 가장 많이 나온 함정 하나를 고른다. 성공 기준: "나는 주로 ○○에 빠진다"는 문장이 적혀 있다.
- 그 대화 하나를 아래 프롬프트로 점검받고, 고쳐 쓴 요청을 새 대화에서 돌린다. 성공 기준: 고친 요청에 읽을 사람, 기준 자료, 결과물의 형식이 들어 있다.
- 처음 답과 새 답을 나란히 놓고 달라진 점을 한 문장으로 적는다. 성공 기준: "합계가 원본과 맞는다"처럼 누구나 확인할 수 있는 문장이다. "좋아졌다"로는 부족하다.
- 고른 함정을 막는 문장 하나를 프로젝트 지침에 넣는다. 예: "요청에 읽을 사람과 기준 자료가 없으면 답하기 전에 먼저 물어봐." 성공 기준: 다음 주에 같은 상황에서 Claude가 먼저 되묻거나, 내가 먼저 적는다.
복사해 쓰는 프롬프트
아래는 내가 전에 너에게 보낸 요청이다.
[예전 요청 전문]
이 요청을 다섯 가지 함정에 비춰 점검해 줘.
1. 흐린 지시: 무엇을, 어떤 형식으로, 얼마나 원하는지 빠진 곳
2. 빠진 맥락: 누가 읽는지, 왜 필요한지, 어떤 자료가 기준인지, 이미 정해진 것이 무엇인지
3. 한꺼번에 맡기기: 나눠서 맡겨야 할 일이 섞인 곳
4. 확인 생략: 결과를 내가 어떻게 확인할지 정해지지 않은 곳
5. 받은 글 그대로 내보내기: 결과를 그대로 복사해 쓸 위험이 큰 곳
항목마다 해당 여부와 근거를 한 줄씩 적어 줘.
점검이 끝나면 고쳐 쓴 요청을 하나 제안해 줘. 여러 일이 섞여 있으면 첫 번째 요청만 써 줘.
모르는 게 있으면 고쳐 쓰기 전에 먼저 물어봐.
막히면 이렇게
| 증상 | 원인 | 처방 |
|---|---|---|
| 점검표를 만들었는데 급할 때는 건너뛴다 | 점검을 기억에 맡겼다 | 프로젝트 지침에 "읽을 사람과 기준 자료가 없으면 먼저 물어봐"를 넣어 Claude가 되묻게 한다(5·12단계) |
| 다섯 가지를 다 채우다 보니 요청이 한 페이지가 된다 | 모든 일을 같은 무게로 다룬다 | 밖으로 나가거나, 숫자가 들어가거나, 윗사람이 읽을 결과물일 때만 다섯 가지를 모두 본다 |
| 다시 읽었는데도 틀린 곳을 놓친다 | 다시 읽기를 확인으로 착각했다 | 숫자는 원본의 해당 셀과, 인용은 원문과, 이름과 날짜는 원래 문서와 대조한다 |
스스로 점검
- ☐ 결과가 나빴던 대화 하나를 두고, 다섯 함정 중 어디에 빠졌는지 근거를 들어 말할 수 있는가
- ☐ 내가 가장 자주 빠지는 함정을 한 문장으로 말할 수 있는가
- ☐ 지난주 밖으로 나간 결과물 가운데 마지막 문장을 내가 쓰지 않은 것이 있다면, 그게 무엇인지 아는가
점검 해설 보기
- 결과가 나빴던 대화를 열어 첫 요청을 그대로 옮겨 적고, 다섯 함정 가운데 빠진 곳과 그 근거를 한 문장씩 말할 수 있으면 통과다. "그냥 별로였다"로만 말하게 된다면 「다섯 함정을 피하는 법」 표의 "알아채는 신호"와 대조해 보고, 「복사해 쓰는 프롬프트」로 그 요청을 점검받는다.
- "나는 주로 ○○에 빠진다"는 문장이 적혀 있고, 그 함정을 막는 문장이 프로젝트 지침에 들어가 있으면 된다. 떠오르지 않는다면 「따라 하기」 1~3번처럼 지난주 대화 세 개를 모아 가장 많이 나온 함정을 세고, 「직급과 부서에 따라」에서 내 위치에 가까운 설명을 찾아본다.
- 지난주 밖으로 나간 결과물을 떠올려, 결론과 마지막 문장을 내가 쓰지 않은 것이 있다면 그 이름을 댈 수 있으면 통과다. 기억나지 않는다면 보낸 메일과 보고서를 다시 열어 보고, 「다섯 함정을 피하는 법」 아래의 마지막 함정 설명과 13단계를 다시 읽는다.
기억할 것
- 보내기 전 다섯 가지: 무엇을, 누구에게, 한 가지만, 어떻게 확인할지, 마지막 문장은 내가.
- 다섯 함정은 모두 사람이 할 일을 넘긴 곳이다. Claude는 넘겨받은 빈칸을 추측으로 채운다.
- 확인은 다시 읽기가 아니라 대조다.
- 실수는 바쁠 때 생긴다. 바쁠수록 점검표에 기댄다.