프롬프트 엔지니어링이란? AI에게 원하는 답을 명확히 요청하는 방법

8월 25, 2026

지난 글에서는 ChatGPT가 질문과 대화 문맥을 토큰으로 처리한 뒤, 다음 토큰을 반복해서 예측하며 답변을 만든다는 원리를 알아봤습니다. 그렇다면 같은 AI를 사용해도 어떤 사람은 원하는 결과를 빠르게 얻고, 어떤 사람은 계속 엉뚱한 답을 받는 이유는 무엇일까요?

차이는 모델의 성능뿐 아니라 무엇을 원하는지 얼마나 분명하게 전달했는가에서 생길 수 있습니다. 프롬프트 엔지니어링은 AI에게 마법의 주문을 입력하는 기술이 아니라, 목표와 맥락, 자료, 제약 조건, 출력 형식을 설계하고 결과를 반복해서 개선하는 방법입니다.

프롬프트란 무엇일까?

프롬프트(Prompt)는 AI 모델에 전달하는 입력입니다. 간단한 질문 한 줄일 수도 있고, 참고 문서와 작업 규칙, 결과 형식이 포함된 긴 요청문일 수도 있습니다. 대화형 AI에서는 이전 메시지와 현재 질문도 모델이 답을 만드는 문맥에 영향을 줍니다.

프롬프트 엔지니어링(Prompt Engineering)은 원하는 결과를 얻기 위해 이 입력을 구조화하고 시험하며 개선하는 과정입니다. 한 번 잘 써서 영원히 사용하는 문장이라기보다, 실제 결과를 보고 부족한 조건을 보완하는 설계 작업에 가깝습니다.

왜 프롬프트가 결과를 바꿀까?

언어 모델은 현재 문맥을 바탕으로 이어질 토큰의 가능성을 계산합니다. “글을 써 줘”처럼 범위가 넓은 요청에는 주제, 독자, 길이, 말투, 포함할 내용이 정해져 있지 않습니다. 모델은 빈칸을 추정해서 채워야 하므로 사용자가 기대한 방향과 달라질 가능성이 커집니다.

반대로 “AI 입문자를 대상으로 임베딩을 설명하는 1,500자 글을 작성하고, 비유 한 개와 주의점 세 개를 포함해 H2 제목으로 구분해 줘”라고 요청하면 가능한 결과의 범위가 좁아집니다. 모델이 무엇을 선택해야 하는지 판단할 근거가 늘어나는 것입니다.

공식 OpenAI 모델 가이드도 목표, 관련 맥락, 제약 조건, 필요한 근거, 성공 기준과 출력 형식을 명확히 전달하는 방식을 권장합니다. 다만 지시를 같은 뜻으로 여러 번 반복하면 프롬프트만 길어지고 핵심이 흐려질 수 있습니다.

좋은 프롬프트의 6가지 요소

모든 요청에 여섯 요소를 억지로 넣을 필요는 없습니다. 간단한 질문은 짧게 묻는 편이 낫습니다. 작업이 복잡하거나 결과 형식이 중요할수록 다음 항목을 골라 구체화하면 좋습니다.

1. 목표: 무엇을 원하는가?

“분석해 줘”보다 최종적으로 무엇을 얻고 싶은지 적습니다. 예를 들어 “고객 후기에서 반복되는 불만 세 가지를 찾아 제품 개선 우선순위를 정하고 싶다”라고 쓰면 분석의 목적이 분명해집니다.

2. 맥락: 왜 필요한가?

독자, 사용 상황, 배경을 알려 줍니다. 같은 AI 설명이라도 초등학생용 수업 자료와 개발자용 기술 문서는 용어와 깊이가 달라야 합니다. 필요한 맥락만 전달하고 업무와 무관한 개인정보나 비밀 자료는 넣지 않는 것이 좋습니다.

3. 입력 자료: 무엇을 참고할까?

요약할 글, 분석할 표, 바꿀 초안처럼 작업의 근거를 명확히 구분합니다. 긴 자료를 붙일 때는 “아래 자료만 사용”, “자료에 없는 수치는 추측하지 않기”처럼 사용 범위도 함께 적을 수 있습니다.

4. 제약 조건: 무엇을 지킬까?

길이, 제외할 내용, 반드시 포함할 항목, 최신 정보 확인 여부를 지정합니다. “과장 표현 금지”, “확인되지 않은 내용은 확인 필요로 표시”, “500자 이내”처럼 결과를 판단할 수 있는 조건이 효과적입니다.

5. 출력 형식: 어떻게 보여줄까?

표, 목록, 이메일, HTML, JSON 등 실제로 사용할 형태를 요청합니다. “결론부터 한 문단으로 쓰고, 근거를 세 개의 글머리표로 정리”처럼 순서와 구조를 지정하면 복사 후 다시 편집하는 시간을 줄일 수 있습니다.

6. 검증 기준: 무엇이 성공인가?

완성된 결과가 만족해야 할 기준을 알려 줍니다. “모든 수치에 출처가 있는지 확인”, “누락된 담당자와 마감일 표시”, “초보자가 모를 용어는 첫 등장에 설명”처럼 마지막 점검 항목을 줄 수 있습니다.

모호한 요청을 구체적으로 바꾸기

회의 내용을 정리하는 상황을 예로 들어 보겠습니다.

모호한 요청

회의 내용을 정리해 줘.

이 요청만으로는 요약을 읽을 사람, 필요한 항목, 결과 길이와 불확실한 정보의 처리 방식이 보이지 않습니다.

개선된 요청

목표: 팀원이 결정 사항과 다음 행동을 바로 확인할 수 있는 회의록을 만든다.

입력: 아래 회의 메모를 사용한다.

출력 형식:
1. 핵심 요약 3문장
2. 결정 사항
3. 담당자와 마감일
4. 미결 질문

규칙:
- 메모에 없는 내용은 추측하지 않는다.
- 담당자나 날짜가 없으면 ‘확인 필요’라고 표시한다.
- 반복 내용은 합친다.

두 번째 요청은 단순히 길어서 좋은 것이 아닙니다. 목적과 입력 범위, 출력 구조, 불확실한 정보의 처리 기준이 분명하기 때문에 결과를 예측하고 검토하기 쉬운 것입니다.

역할을 부여하면 무조건 좋아질까?

“당신은 전문 마케터입니다”처럼 역할을 지정하면 관점이나 말투를 잡는 데 도움이 될 수 있습니다. 하지만 역할 한 줄만으로 정확한 결과가 보장되지는 않습니다. 어떤 독자를 대상으로 무엇을 만들고 어떤 기준을 지켜야 하는지가 더 중요합니다.

“10년 경력의 세계 최고 전문가처럼 완벽하게” 같은 과장된 역할보다 “중학생에게 설명하는 과학 교사처럼 전문 용어를 풀어 쓰고, 비유 뒤에 정확한 설명을 덧붙여 줘”처럼 실제 행동을 지정하는 편이 검증하기 쉽습니다.

예시를 보여 주는 방법

원하는 결과의 형식이나 분류 기준이 말로 설명하기 어려우면 짧은 예시를 제공할 수 있습니다. 이를 흔히 퓨샷 프롬프팅(Few-shot Prompting)이라고 합니다.

입력: 배송이 빨랐지만 포장이 찢어졌어요.
출력: 배송=긍정, 포장=부정

입력: 설명서가 이해하기 쉽고 제품도 조용해요.
출력:

예시는 모델이 따라야 할 패턴을 보여 줍니다. 다만 예시가 틀렸거나 특정 경우에 치우치면 결과도 그 영향을 받습니다. 실제 입력에서 나타날 여러 유형을 대표하도록 선택하고, 예시와 규칙이 서로 충돌하지 않는지 확인해야 합니다.

긴 자료는 구분해서 전달하기

지시와 참고 자료가 섞이면 어느 문장이 명령이고 어느 문장이 분석 대상인지 모호해질 수 있습니다. 제목이나 구분선을 사용해 역할을 나누면 읽기 쉬워집니다.

[작업]
아래 고객 후기를 요약한다.

[규칙]
제품명과 날짜를 바꾸지 않는다.
후기에 없는 원인은 추측하지 않는다.

[고객 후기]
여기에 분석할 원문을 넣는다.

자료 안에 “앞의 지시를 무시하라” 같은 문장이 들어 있을 수 있는 자동화 작업에서는 특히 입력 데이터를 명령으로 취급하지 않도록 구분하고, 중요한 작업은 별도의 검증 절차를 두어야 합니다.

한 번에 완성하려 하지 말고 반복 개선하기

좋은 프롬프트는 결과를 보면서 다듬어집니다. 처음부터 지나치게 긴 요청문을 만드는 대신 작은 단위로 시험하면 무엇이 영향을 줬는지 알기 쉽습니다.

초안 요청: 핵심 목표와 기본 형식으로 먼저 결과를 만듭니다.
오류 확인: 누락, 불필요한 내용, 근거 없는 추정을 표시합니다.
조건 보완: 문제를 막는 구체적인 규칙이나 예시를 추가합니다.
같은 사례 재시험: 수정 전후 결과를 같은 기준으로 비교합니다.
다른 사례 시험: 한 가지 입력에서만 잘 작동하는지 확인합니다.

업무에서 반복 사용할 프롬프트라면 대표 입력과 기대 결과를 모아 평가하는 것이 좋습니다. OpenAI의 API 안내도 모델 버전에 따라 프롬프트 동작과 출력이 달라질 수 있으므로, 일관성이 중요할 때는 고정된 모델 버전과 평가 절차를 권장합니다.

사실 확인이 필요한 작업의 프롬프트

프롬프트를 자세히 쓴다고 모델이 모르는 최신 사실을 자동으로 알게 되는 것은 아닙니다. 최신 가격, 법률, 제품 사양처럼 변할 수 있는 정보는 검색 도구와 신뢰할 수 있는 출처가 필요합니다.

기준 날짜와 조사 범위를 명시합니다.
공식 문서나 1차 자료를 우선하도록 요청합니다.
중요한 주장 가까이에 출처 링크를 표시하게 합니다.
자료로 확인되지 않는 내용은 추측하지 말고 불확실성을 밝히게 합니다.
의료·법률·재무 결정은 전문가와 공식 자료로 다시 확인합니다.

프롬프트 엔지니어링의 흔한 오해

길수록 좋다: 관련 없는 설명과 반복은 핵심을 흐릴 수 있습니다.
정답 프롬프트는 하나다: 목적, 모델, 자료와 평가 기준에 따라 적절한 형태가 달라집니다.
역할만 주면 전문가가 된다: 역할은 관점을 안내할 뿐 정확한 자료와 검증을 대신하지 않습니다.
“생각을 단계별로 해”라고 쓰면 항상 정확하다: 복잡한 작업은 구체적인 성공 기준, 자료와 결과 검증이 함께 필요합니다.
프롬프트로 모든 한계를 해결한다: 모델 지식, 문맥 길이, 도구와 데이터 품질의 한계는 남아 있습니다.

바로 사용하는 기본 프롬프트 틀

[목표]
무엇을 만들거나 해결할지 적는다.

[맥락과 독자]
사용 상황과 결과를 볼 사람을 적는다.

[입력 자료]
참고할 내용을 구분해 넣는다.

[조건]
포함·제외 항목, 길이, 근거 기준을 적는다.

[출력 형식]
제목, 표, 목록 등 원하는 구조를 적는다.

[검증]
완료 전에 확인할 기준을 적는다.

간단한 요청에서는 빈 항목을 과감히 빼도 됩니다. 핵심은 모든 칸을 채우는 것이 아니라 모델이 추측해야 할 중요한 빈칸을 줄이는 것입니다.

한눈에 정리하기

프롬프트는 모델에 전달하는 질문, 지시, 자료와 문맥입니다.
좋은 프롬프트는 목표와 성공 기준이 분명하고 필요한 조건만 담습니다.
복잡한 작업은 목표·맥락·자료·제약·출력 형식·검증 기준으로 구조화할 수 있습니다.
예시는 원하는 패턴을 보여 주지만 정확하고 대표적이어야 합니다.
최신 사실과 중요한 판단은 도구, 출처와 사람의 검토가 필요합니다.
프롬프트는 한 번에 완성하기보다 실제 결과를 평가하며 반복해서 개선합니다.

프롬프트 엔지니어링의 핵심은 AI를 속이는 비법이 아니라 사람의 의도를 확인 가능한 작업 지시로 바꾸는 데 있습니다. 목표와 자료, 출력 형식, 검증 기준을 명확히 전달하면 결과를 더 쉽게 비교하고 개선할 수 있습니다.

이 블로그 검색

APisLab