# 질문을 구체화하고 답변 확인하기

> 목적과 제약을 명시하고 수정·재생성·출처의 차이를 이해해 답변의 사실을 검토한다.

원문: https://www.aihoon.kr/guide/gemini/consumer/prompting

좋은 요청은 긴 주문서가 아니라 판단 가능한 작업 설명입니다. 자료에서 확인할 사실과 새로 제안할 내용을 구분하면 답변의 오류도 고치기 쉬워집니다.

## 요청에 목적·자료·제약·형식 넣기

“행사 안내문을 써 줘”에는 독자와 확정 정보가 빠져 있습니다. 아래는 **가상의 원자료**입니다.

```text
독서모임: 9월 26일 토요일 14~16시
장소: 가상 공간 '작은책방' 2층
대상: 성인 초보 독자, 최대 8명
준비물: 좋아하는 책 한 권
참가비: 아직 결정하지 않음
신청 방법: 9월 20일까지 운영자에게 신청
```

이 자료를 넣고 다음처럼 요청합니다.

```text
처음 오는 사람에게 보낼 350자 안팎의 안내문을 작성하세요.
자료의 날짜·시간·정원은 바꾸지 마세요.
참가비는 '추후 안내'로 쓰고 무료라고 추측하지 마세요.
마지막에는 작성자가 확인할 미정 사항을 따로 적으세요.
```

여기서 350자는 기능 한도가 아니라 연습용 편집 조건입니다. 실제 답변이 분량을 넘었다면 내용을 없애기 전에 반드시 남겨야 할 날짜·장소·신청 방법을 지정하고 줄이세요.

## 처음 요청이 막막하면 질문부터 다듬기

역할·할 일·맥락·출력 형식을 적어 보되, 처음부터 모두 완성할 필요는 없습니다. Google의 프롬프트 안내는 초안을 더 명확하게 고치는 데도 Gemini를 사용하도록 제안합니다. 다음은 **작성자가 만든 요청**입니다.

```text
제 요청은 '신입 구성원에게 행사 준비를 설명하는 글을 써 줘'입니다.
바로 글을 쓰기 전에 빠진 조건을 최대 3개 질문해 주세요.
제가 답하면 목적·독자·확정 자료·분량이 드러나는 요청문으로 고쳐 주세요.
제가 말하지 않은 일정이나 운영 규칙을 새로 만들지 마세요.
```

Gemini가 다듬은 요청문도 읽어야 합니다. “모든 일정은 확정” 같은 가정이 추가되면 원래 의도와 달라집니다. 확인된 자료와 아직 정하지 않은 항목을 구별한 뒤 실제 작성을 시작하세요.

아이디어가 필요한 일은 후보를 넓힌 뒤 좁히는 순서가 유용합니다. Ethan Mollick의 활용 안내는 익숙한 일을 대상으로 대화하며 다양한 가능성을 시도하는 방법을 설명합니다. 예를 들어 제목 10개를 받은 뒤 “처음 참여하는 성인이 부담 없이 읽을 세 개를 고르고, 과장된 표현을 뺀 이유를 설명해 줘”라고 이어갈 수 있습니다. 후보 수와 선택 기준은 사용자가 정한 연습 조건이며 특정 결과를 보장하는 공식이 아닙니다.

## 원래 질문 수정과 답변 재생성

보낸 프롬프트의 **텍스트 수정 → 업데이트**는 요청 자체를 바꿔 답을 다시 만듭니다. 연결 앱을 사용한 응답에는 이 수정 기능을 사용할 수 없는 경우가 있으므로 후속 질문으로 변경을 지시합니다.

**재생성**은 가장 최근 답변에 사용할 수 있고 화살표로 버전을 바꿔 볼 수 있습니다. 길이·어조를 바꾸는 수정 기능이 제공되더라도 사실 오류를 저절로 찾아 고친다는 뜻은 아닙니다. 일부 요청의 다른 초안 보기 역시 최신 응답에서 제공됩니다.

“더 좋게” 대신 “참가비 문장을 추후 안내로 바꾸고 나머지 날짜는 유지해 주세요”라고 말하면 무엇을 고쳤는지 비교하기 쉽습니다. 새로운 버전이 마음에 든다는 이유로 원자료 대조를 생략하지 마세요.

## 출처 링크를 읽는 방법

출처가 있는 답변은 아래 **출처** 버튼이나 본문 인용을 통해 관련 링크 패널을 열 수 있습니다. 웹페이지뿐 아니라 업로드 파일이나 연결한 Workspace 문서·메일이 표시될 수 있습니다. 링크는 응답의 일부와 관련된 자료일 수 있으므로, 링크가 있다는 사실만으로 모든 문장이 뒷받침되지는 않습니다.

예를 들어 “신청 마감이 20일”이라는 문장의 링크를 열었는데 행사 장소만 나온다면 날짜의 근거는 아직 찾지 못한 것입니다. 원문에서 실제 마감일을 찾거나, 확인하지 못했다고 남기는 것이 합리적입니다. 출처가 없는 개인적인 제안은 참고 아이디어로 읽을 수 있지만 사실 주장과 섞지 않는 편이 좋습니다.

## Gemini의 자기 설명도 검토하기

Gemini는 인물·최신 정보뿐 아니라 자신의 학습 방식이나 기능에 대해서도 부정확한 설명을 만들 수 있습니다. “제가 방금 전체 파일을 읽었습니다” 같은 문장을 처리 완료의 증거로 삼지 마세요. 모델의 대답은 Google의 공식 입장이나 전문적 판단도 아닙니다.

내가 확인할 수 있는 증거를 요청하세요. 위 연습에서는 날짜와 정원, 미정인 참가비가 그대로인지 보면 됩니다. 실제 자료 조사라면 원문 위치·발행일·적용 대상을 확인합니다. 의학·법률·금융처럼 실제 판단의 영향이 큰 내용은 해당 전문가나 담당 기관의 기준으로 확인해야 합니다.

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

한 번 좋은 답을 받았다고 다음 자료에도 같은 결과가 나오는 것은 아닙니다. Wharton의 프롬프트 라이브러리 안내는 같은 요청을 반복하고 다양한 입력·예외·긴 대화에서 살펴보는 것을 강조합니다. 아래는 앞의 공지 요청을 점검하는 **편집자의 시험표**입니다.

| 넣어 볼 자료 | 확인할 결과 |
|---|---|
| 날짜·장소·비용이 모두 확정됨 | 원래 값이 유지되는가 |
| 참가비가 비어 있음 | 무료로 추정하지 않고 확인 사항에 남기는가 |
| 옛 공지와 새 공지의 시각이 다름 | 적용할 버전을 묻거나 근거를 구분하는가 |
| 같은 대화에서 여러 번 줄이고 늘림 | 처음의 핵심 조건이 사라지지 않는가 |

결과를 “좋음”으로만 기록하지 말고 “미정인 비용을 임의로 채움”처럼 적으면 어떤 지침을 고칠지 알 수 있습니다. 모델이나 지침을 바꿨을 때도 자주 쓰는 입력 몇 개를 다시 확인하세요. [Gems](/guide/gemini/consumer/gems)에 저장할 때 특히 도움이 됩니다.

## 수정 범위를 좁혀 다시 묻기

```text
답변에는 참가비가 무료라고 되어 있습니다.
원자료는 '아직 결정하지 않음'입니다.
이 부분을 수정하고, 다른 확정되지 않은 정보가 추가됐는지도 찾아 주세요.
확정 사실과 작성 제안을 분리해 주세요.
```

위 문장은 오류가 생겼을 때의 **작성자 예시**입니다. Gemini가 실제로 해당 오류를 냈다는 기록은 아닙니다. 긴 답변 전체를 매번 다시 만들기보다 틀린 전제와 고칠 범위를 지정하면 사람이 검토할 부담도 줄어듭니다. 외부 자료가 앱 실행 지시를 포함한다면 [자료와 앱을 안전하게 쓰기](/guide/gemini/consumer/security)를 함께 읽으세요.

여러 자료의 범위를 정하고 조사 계획부터 세우려면 [Deep Research로 조사하기](/guide/gemini/consumer/research)로 이어갈 수 있습니다.