더 나은 AI 프롬프트 작성법: 초보자를 위한 확인·수정 방법

AI에 다음과 같이 지시했다고 해 봅시다.

이 회의 메모로 후속 이메일을 작성해 줘.

답은 매끄럽습니다. 모두에게 감사를 전하고, 결정 세 가지를 나열하고, 다음 할 일을 배정합니다. 문제는 하나뿐입니다. 메모에 있는 것은 결정 두 개가 아니라 제안 두 개이며, 할 일 하나는 누가 맡을지 합의되지 않았습니다.

문장은 좋지만 이메일을 보낼 준비는 되지 않았습니다.

이럴 때 많은 초보자는 프롬프트를 더 길게 쓰거나 특별한 공식, “세계 최고의 커뮤니케이션 전문가” 같은 인상적인 역할이 필요하다고 생각합니다. 더 유용한 진단은 간단합니다. AI는 유용한 답과 유창하지만 부정확한 답을 구분하는 방법을 전달받지 못했습니다.

좋은 프롬프트는 확인 가능한 과제 요청서처럼 작동합니다. AI가 할 일을 밝히고, 그 일에 필요한 정보를 제공하고, 답이 넘으면 안 되는 경계를 지키며, 사람이 결과를 쉽게 살펴보게 합니다. 모든 요청에 모든 요소가 필요한 것은 아니며 첫 메시지가 완벽할 필요도 없습니다.

한 프롬프트가 다른 프롬프트보다 나은 기준

일상 과제에는 세 가지 실용적인 검사를 사용하세요.

• 유용한가: 염두에 둔 다음 행동에 결과를 사용할 수 있는가?
• 충실한가: 자료의 중요한 사실, 구분, 불확실성을 보존하는가?
• 확인 가능한가: 결과를 믿기 전에 무엇과 비교해야 하는지 알 수 있는가?

“전문적으로 작성해 줘”는 어조에 영향을 줄 수 있지만 어느 질문에도 답하지 않습니다. “확정된 결정과 미해결 질문을 구분하고 담당자를 지어내지 마”는 답합니다.

이 글에서는 가상의 회의 메모 연습으로 프롬프트 하나를 단계별로 만듭니다. 회의, 인물, 프로젝트는 실제가 아닙니다.

1. AI에 분명한 일 하나 맡기기

AI의 역할이 아니라 필요한 결과부터 시작하세요.

막연한 요청:

이 회의 메모를 처리하는 데 도움을 줘.

더 분명한 요청:

아래 회의 메모로 프로젝트 팀에 보낼 후속 이메일 초안을 작성해 줘.

두 번째 요청은 행동, 원본 자료, 결과물, 독자를 특정합니다. 회의에 참석하지 않은 유능한 동료에게 지시한다고 상상해 보세요. 무엇을 전달해야 하는지 알 수 있을까요?

더 쓰기 전에 “완료”의 의미를 정하세요. 이 예시에서는 팀이 결정된 내용, 누군가 하기로 한 일, 아직 답이 필요한 내용을 볼 수 있어야 합니다. 아무리 문장이 좋아도 이 범주가 섞이면 실패입니다.

Anthropic의 프롬프트 개발 지침에도 같은 생각이 나옵니다. 표현을 다듬는 데 시간을 쓰기 전에 성공 기준과 시험 방법을 정하라는 것입니다. 일반 채팅에 평가 시스템까지 필요하지는 않습니다. 짧은 머릿속 확인 목록이면 충분합니다.

2. 결과를 바꿀 수 있는 맥락 추가하기

AI는 “후속 이메일을 써 줘”라는 한 문장만으로 비공개 회의 기록을 추론할 수 없습니다. 원본 자료와 사용 방식에 영향을 주는 배경을 포함하세요.

이 연습에 필요한 맥락은 다음과 같습니다.

회의 메모

- 팀은 새 도움말 페이지를 9월 18일 시범 운영하기로 확정했습니다.
- Mei는 9월 8일까지 첫 초안을 준비합니다.
- 그룹은 동영상 추가를 논의했지만 결정하지 않았습니다.
- 누군가 자막 비용을 확인해야 하지만 담당자와 마감일은 정해지지 않았습니다.
- 고객은 지원팀이 초안을 검토할 수 있는지 아직 확인해야 합니다.

수신자와 목적도 중요합니다. 이 문서는 약속을 분명히 보여 줘야 하는 내부 후속 이메일입니다. 이전 프로젝트 회의의 모든 역사는 아마 필요하지 않을 것입니다.

프롬프트에는 과제, 필요한 자료, 경계, 필요한 결과를 조합할 수 있습니다. 실제 작업을 바꾸는 부분만 사용하세요.

관련 맥락과 최대한 많은 맥락은 다릅니다. 긴 컨텍스트 언어 모델을 연구한 한 논문에서는 시험한 검색·질의응답 과제에서 모델이 긴 입력의 모든 위치를 똑같이 안정적으로 사용하지 않았습니다. 모델과 기능은 계속 바뀌므로 보편적인 한계로 볼 수는 없습니다. 그래도 중요한 자료를 무관한 텍스트 속에 묻지 않고 정리할 이유가 됩니다.

각 세부 정보에 대해 물어보세요.

이 내용을 삭제하면 올바른 답이 달라질 수 있는가?

그렇다면 필요할 수 있습니다. 아니라면 빼는 편을 고려하세요. 보내기 전에는 과제에 필요하지 않은 이름, 연락처, 계정 정보, 내부 기록, 기타 민감한 자료도 제거합니다. 기밀 자료라면 사용하는 도구의 최신 데이터 정책을 확인하세요.

3. 사실, 제약 조건, 미확인 사항 보호하기

맥락은 AI가 사용할 수 있는 자료를 알려 줍니다. 경계는 AI가 조용히 바꾸면 안 되는 내용을 알려 줍니다.

회의 메모에는 서로 다른 범주가 있습니다.

• 사실은 9월 18일 시범 운영일처럼 기록된 정보입니다.
• 제약 조건은 확정 날짜를 보존하라는 것처럼 결과가 따라야 하는 규칙입니다.
• 미확인 사항은 자막 비용 확인 담당자처럼 AI가 책임 있게 채울 수 없는 공백입니다.

요청에 이 구분을 추가하세요.

확정된 결정, 배정된 행동, 제안, 미해결 질문을 구분하세요.
담당자, 마감일, 결정, 고객 답변을 지어내지 마세요.
메모에 필요한 세부 정보가 없다면 "확인 필요"로 표시하세요.

권위 있게 들리게 해 달라는 요청보다 유용한 지침입니다. 권위 있는 문체로도 제안을 결정으로 바꾸거나 없는 담당자를 만들 수는 없습니다.

금지 사항을 길게 나열하는 것보다 긍정적인 지침을 적용하기 쉬운 경우가 많습니다. “섞지 마”라고만 하지 말고 답이 사용할 범주를 지정하세요. 결과를 위험하거나 사용할 수 없게 만드는 실패에는 부정적 경계를 남겨 둡니다.

4. 살펴보기 쉬운 출력 요청하기

출력 요구 사항은 장식이 아닙니다. 답을 더 쉽게 사용하고 확인하게 해야 합니다.

이메일에는 다음을 추가하세요.

다음 구조를 사용하세요.

1. 두 문장으로 된 회의 요약.
2. 확정된 결정.
3. 메모에 적힌 담당자와 날짜만 포함한 배정된 행동.
4. 미해결 질문과 담당자가 없는 행동.
5. 부정확한 부분을 고쳐 달라는 마무리 요청.

이메일은 250단어 이내로 작성하고 직접적이고 중립적인 표현을 사용하세요.

구역을 나누면 누락이 드러납니다. “미해결 질문”을 따로 두면 해결되지 않은 문제가 매끄러운 문단 속에서 사라지기 어렵습니다. 단어 제한은 초안이 회의록 전체로 늘어나는 일을 막습니다.

원하는 형식, 분류, 어조를 설명하기 어렵다면 예시가 도움이 됩니다. OpenAI, Google, Anthropic 모두 예시로 출력을 유도하는 방법을 문서화합니다. 하지만 예시는 뜻을 보여 주는 선택적 근거이지 필수 요소가 아닙니다. 익숙한 과제와 분명한 요청에는 필요하지 않을 수 있습니다.

완성된 프롬프트

조립한 요청은 다음과 같습니다.

아래 회의 메모로 프로젝트 팀에 보낼 내부 후속 이메일 초안을 작성하세요.
확정된 결정, 배정된 행동, 해결되지 않은 질문을 쉽게 볼 수 있어야 합니다.

확정된 결정, 배정된 행동, 제안, 미해결 질문을 구분하세요.
담당자, 마감일, 결정, 고객 답변을 지어내지 마세요.
메모에 필요한 세부 정보가 없다면 "확인 필요"로 표시하세요.

다음 구조를 사용하세요.
1. 두 문장으로 된 회의 요약.
2. 확정된 결정.
3. 메모에 적힌 담당자와 날짜만 포함한 배정된 행동.
4. 미해결 질문과 담당자가 없는 행동.
5. 부정확한 부분을 고쳐 달라는 마무리 요청.

이메일은 250단어 이내로 작성하고 직접적이고 중립적인 표현을 사용하세요.

회의 메모
- 팀은 새 도움말 페이지를 9월 18일 시범 운영하기로 확정했습니다.
- Mei는 9월 8일까지 첫 초안을 준비합니다.
- 그룹은 동영상 추가를 논의했지만 결정하지 않았습니다.
- 누군가 자막 비용을 확인해야 하지만 담당자와 마감일은 정해지지 않았습니다.
- 고객은 지원팀이 초안을 검토할 수 있는지 아직 확인해야 합니다.

이 프롬프트가 원래 요청보다 긴 이유는 과제에 보존할 가치가 있는 구분이 있기 때문입니다. “이 폴더의 이름 다섯 개를 제안해 줘” 같은 요청에는 같은 구조가 필요하지 않습니다. 프롬프트 길이는 과제의 결과이지 품질 점수가 아닙니다.

5. 원본과 답 비교하기

초안이 자연스럽게 들리는지만 보고 판단하지 마세요. 회의 메모와 처음 정한 성공 기준을 바탕으로 비교합니다.

다음 순서로 확인하세요.

1. 포함 범위: 중요한 결정, 배정된 행동, 미해결 질문을 모두 포함했는가?
2. 충실도: 날짜, 담당자, 약속, 확실성의 정도를 바꿨는가?
3. 근거 없는 추가: 원본에 없는 이유, 이름, 마감일, 사실, 인용을 넣었는가?
4. 유용성: 팀이 구조를 다시 풀어내지 않고 이메일에 따라 행동할 수 있는가?

가격, 법률, 일정, 제품 동작, 기술 호환성처럼 현재 사실은 채팅에 붙여 넣은 텍스트가 아니라 공식 페이지에서 확인해야 할 수 있습니다. 해당 출처를 열어 확인하세요. AI에 “확실해?”라고 묻는 것은 독립 검증이 아닙니다.

NIST는 확신 있게 제시되는 거짓 내용을 알려진 생성형 AI 위험으로 설명하고 생성 결과의 출처와 인용을 검토하라고 권고합니다. 부정확한 답도 완성된 것처럼 들릴 수 있기 때문에 중요한 위험입니다.

6. 실패한 부분을 구체적으로 수정하기

첫 결과가 틀렸다고 프롬프트 전체를 버릴 필요는 없습니다. 실패를 지적하고 경계를 복원한 뒤 영향을 받은 부분을 수정해 달라고 하세요.

예를 들면 다음과 같습니다.

자막 비용 확인에는 담당자나 마감일이 없습니다. 이 항목을 “미해결 질문과 담당자가 없는 행동”으로 옮기고 추가한 이름을 삭제한 뒤 이메일 나머지는 그대로 유지하세요. 그런 다음 모든 날짜와 담당자가 메모와 일치하는지 확인하세요.

관찰 가능한 문제를 밝히므로 유용한 후속 요청입니다. “다시 해 봐”는 AI에 비교할 정보를 주지 않습니다.

프롬프트 작성은 반복 과정입니다. 과제와 결과를 비교하고, 부족한 점을 설명하고, 실패한 부분을 수정합니다.

어조, 길이, 형식, 근거 누락에도 같은 방식을 사용할 수 있습니다.

• “요약이 전문가를 대상으로 합니다. 프로젝트를 모르는 독자를 위해 도입부만 다시 작성하세요.”
• “두 선택지에 같은 기준을 사용하지 않았습니다. 가격, 접근 방식, 취소 조건을 각각 적용해 표를 다시 만드세요.”
• “두 주장에 출처가 없습니다. 삭제하거나 각각을 뒷받침하는 현재의 1차 출처를 연결하세요.”

좋은 프롬프트를 완벽한 문장보다 작업 과정으로 이해해야 하는 이유입니다. Google은 프롬프트 설계를 반복 과정으로 설명하고, 현재 OpenAI 지침은 모델과 프롬프트가 바뀔 때 동작을 시험하라고 권합니다. 초보자의 반복은 출력 하나를 확인하고, 결함 하나를 밝히고, 수정된 지침으로 다시 시도하는 것처럼 간단할 수 있습니다.

필요에 따라 줄일 수 있는 시작 틀

과제의 위험이나 복잡성 때문에 요청서가 필요할 때 사용하세요.

과제:
[자료]를 사용해 [독자 또는 상황]을 위한 [구체적인 결과]를 만드세요.

필요한 맥락:
[올바른 답을 바꿀 수 있는 정보만]

반드시 보존할 내용:
[사실, 구분, 요구 사항, 경계]

가정하지 말아야 할 내용:
[AI가 미확인 상태로 두거나 확인 필요로 표시할 항목]

출력:
[결과를 쓸 수 있게 하는 구역, 형식, 길이, 확인 항목]

현재 과제에 도움이 되지 않는 필드는 삭제하세요. 결과를 사용하기 전에 **유용하고, 충실하며, 확인 가능한가?**라고 물어봅니다. 프롬프트는 일을 설명하도록 돕습니다. 그래도 원본 확인, 최종 판단, 실제 행동은 사용자의 몫입니다.

참고 자료

• OpenAI: 프롬프트 엔지니어링 — 지침, 예시, 관련 맥락, 프롬프트·모델 변경에 따른 평가를 설명합니다.
• Google AI for Developers: 프롬프트 설계 전략 — 명확한 지침, 맥락, 예시, 응답 형식, 반복을 안내합니다.
• Anthropic: 프롬프트 엔지니어링 개요 — 프롬프트를 다듬기 전에 성공 기준과 시험을 정하는 방법입니다.
• Anthropic: 프롬프트 작성 권장 사항 — 모델별 지침을 포함한 명확성, 맥락, 예시, 구조화 프롬프트를 설명합니다.
• NIST AI 600-1: 생성형 인공지능 프로필 — 허위 생성, 정보 무결성, 사람의 감독, 데이터 개인정보 위험을 다룹니다.
• Liu 외: “Lost in the Middle,” TACL 2024 — 시험 대상 언어 모델이 긴 컨텍스트의 정보를 사용하는 방식을 분석한 실증 연구입니다.
• Schulhoff 외: “The Prompt Report” — 프롬프트 기법을 체계적으로 조사하고 분류한 논문입니다.