# 원하는 답이 나오는 요청 쓰고 고치기

> 목적·자료·조건·형식을 담아 요청하고 부족한 부분을 구체적으로 고칩니다.

원문: https://www.aihoon.kr/guide/consumer/better-prompts

좋은 요청은 특별한 주문이 아니라 작업 설명입니다. 누가 읽을 결과인지, 어떤 자료가 근거인지, 반드시 지켜야 할 조건이 무엇인지를 알려 주면 답변을 받은 뒤에도 무엇을 고칠지 판단하기 쉽습니다.

## 업무를 맡길 범위 정하기

먼저 해야 할 일을 나누세요. Claude가 자료를 정리할 수 있는 부분, 사람과 함께 선택할 부분, 자신이 직접 결정할 부분은 다를 수 있습니다. 목적을 이해하고 기능의 범위를 아는 것이 위임의 출발점입니다.

가상의 시민 강좌를 준비한다면 Claude에게 일정 후보와 준비물을 정리하게 할 수 있습니다. 그러나 실제 강사 섭외 여부나 강의실 예약을 하지 않은 상태에서 “확정 일정”을 만들라고 하면, 필요한 결정이 빠져 있습니다. 자료 정리와 결정의 책임을 요청 안에서 구분하세요.

```text
강좌 기획을 정리하려고 합니다.
첨부 메모에서 확정 사항과 제안 사항을 나누고,
담당자가 아직 결정해야 할 질문을 우선순위대로 정리해 주세요.
결정되지 않은 날짜·강사·가격을 확정하지 마세요.
```

## 명확한 요청과 예시

요청에 들어갈 내용을 다음처럼 나누면 빈칸을 찾기 쉽습니다.

| 요소 | 적을 내용 | 가상 예 |
|---|---|---|
| 목적·독자 | 무엇에 사용할지 | 처음 참가하는 시민이 읽을 안내문 |
| 자료 | 답변의 근거 | 확정 일정표와 운영 메모 |
| 조건 | 유지해야 할 사실 | 무료, 정원 20명, 신청 링크 미정 |
| 형식 | 실제 사용할 형태 | 제목·일시·대상·준비물·신청 순서 |
| 진행 방법 | 먼저 확인할 것 | 충돌하는 날짜가 있으면 먼저 알려 주기 |
| 대화 방식 | 협업할 때 필요한 태도 | 빠진 정보만 질문하고 전문 용어 풀어 쓰기 |

예시를 주면 길이나 문체를 전달하기 쉽지만, 예시의 사실까지 베끼지 않도록 역할을 밝힙니다. “아래 글은 형식 참고용이며 날짜와 장소는 새 자료를 따르세요”라고 적는 식입니다. 복잡한 일은 자료 확인→구성→작성으로 나눌 수 있고, 여러 조건이 얽히면 답을 내기 전 조건 충돌을 검토하도록 요청할 수 있습니다.

아래는 앞의 작업을 한 번에 설명한 예입니다.

```text
처음 참가하는 성인을 위한 90분 글쓰기 강좌 안내문을 작성해 주세요.
자료: 10월 17일 오후 2시, 마을회관 1층, 무료, 정원 20명.
참가자는 필기도구를 가져오며 노트북은 없어도 됩니다.
강사 이름과 신청 링크는 아직 없습니다.

먼저 작성에 꼭 필요한 미정 항목을 짚어 주세요.
그다음 제목, 소개 두 문장, 일시·장소·준비물, 신청 순서로 써 주세요.
미정 항목에는 대괄호를 두고, 유료 준비물을 새로 권하지 마세요.
```

결과에서 가장 먼저 볼 것은 무료·정원·노트북 조건이 유지됐는지입니다. 멋진 제목은 그다음입니다. 독자가 실제로 행동하는 데 필요한 정보가 빠졌다면 원고를 꾸미기 전에 채워야 합니다.

## 대안을 비교하고 요청을 재사용하기

같은 사실로 방향이 다른 초안을 받아 보면 선호를 더 분명히 말할 수 있습니다. 앞의 강좌 자료를 그대로 두고 “핵심만 적은 짧은 안내와 처음 오는 사람에게 친절하게 설명한 안내를 각각 써 주세요”라고 요청해 보세요. 두 안의 날짜·정원·무료 조건과 미정 표시가 유지되는지 먼저 확인한 뒤 말투와 길이를 비교합니다. 대안 수가 많다는 것 자체가 좋은 결과의 기준은 아닙니다.

좋은 예와 아쉬운 예를 함께 주고 차이를 말로 정리하는 방법도 있습니다. “이 두 안내문에서 처음 오는 사람이 날짜·준비물·신청 방법을 찾기 쉬운 이유를 짚어 주세요”라고 묻고, 실제 문장을 근거로 삼게 합니다. ‘전문적’이라는 평가보다 ‘확정 정보와 미정 정보를 분리한다’처럼 다음 글에도 확인할 수 있는 기준을 남기세요. 추출→비교→작성으로 이어지는 작업이라면 추출된 사실부터 확인해야 앞의 오류가 마지막 문장까지 이어지지 않습니다.

반복 요청은 목적, 바꿀 입력, 고정 조건, 좋은 결과 예, 마지막으로 확인한 날짜를 함께 저장하면 다시 쓰기 쉽습니다. 예를 들어 행사 안내 요청에는 `[일정표]`, `[독자]`, `[확정되지 않은 항목]`을 변수로 두고 무료·정원 같은 사실은 그때의 자료로 채웁니다. 예전 성공 결과의 날짜를 새 요청에 남겨 두지 마세요. 다른 행사에서도 시험해 보고 잘못 읽는 조건을 고친 뒤 [스킬](/guide/consumer/skills-and-plugins)로 묶을지 판단합니다.

### 반복해서 쓸 요청은 다른 입력으로 시험하기

Wharton Generative AI Labs의 재사용 프롬프트 안내는 한 번의 좋은 답보다 여러 입력·반복 실행·긴 대화에서 목표가 유지되는지를 확인하도록 제안합니다. 위 강좌 요청을 확정 정보가 다 있는 자료, 신청 링크가 없는 자료, 일정표와 변경 메모의 날짜가 충돌하는 자료로 각각 시험해 보세요.

각 결과에서 필수 사실·미정 표시·충돌 질문이 남는지 비교하고, 후속 수정을 몇 차례 해도 무료·정원 조건을 잃지 않는지 봅니다. 다른 사람이 요청을 재사용하거나 모델이 바뀌면 같은 기준으로 다시 확인합니다. 한 번 성공한 문구가 다른 자료에서도 항상 성공한다고 보장되지는 않습니다.

## 답이 짧거나 엉뚱할 때

답이 짧으면 무조건 “길게”보다 어떤 설명이 빠졌는지 말합니다. “처음 오는 사람이 건물을 찾을 수 있도록 입구와 도착 후 절차를 추가하되, 자료에 없으면 물어봐 주세요”처럼 필요한 깊이를 정합니다. 반대로 너무 길면 유지할 항목을 지정한 뒤 줄입니다.

요청에 대한 개선안도 Claude와 함께 만들 수 있습니다. “내 요청에서 서로 충돌하는 조건과 답을 바꿀 만큼 중요한 빈칸을 찾아 주세요”라고 물으면, 처음부터 긴 프롬프트를 완벽하게 설계해야 한다는 부담이 줄어듭니다.

```text
지금 초안은 참가자에게 노트북을 준비하라고 합니다.
자료에는 노트북이 없어도 된다고 되어 있습니다.
그 문장을 수정하고, 필수 준비물과 선택 준비물을 구분해 주세요.
새로운 준비물은 제안하지 마세요.
```

마지막 요청은 원고 전체를 다시 만드는 대신 문제의 조건을 고칩니다. 문체가 어색한 문제와 사실이 틀린 문제를 따로 다루면 원치 않는 변경을 줄일 수 있습니다. 반복해서 같은 조건을 설명하게 된다면 [개인 지침·프로젝트·스킬](/guide/consumer/personalization-and-memory)에 둘 기준인지 검토하세요.

요청을 고친 뒤에는 [답변의 근거와 빠진 조건](/guide/consumer/check-answers)도 확인하세요. 원하는 형식을 지킨 답변이 사실까지 맞는다는 뜻은 아닙니다.