프롬프트

인공지능 모델의 프롬프트는 사용자가 원하는 출력을 기대하며 모델에게 제시하는 입력을 의미합니다. prompt라는 단어의 원래 뜻은 "행동을 재촉·촉구하다"입니다.^[1] 연극 무대 뒤에서 배우에게 대사를 속삭여 주는 프롬프터(prompter), 앵커의 눈높이에 대본을 띄워 주는 텔레프롬프터처럼 ‘재촉해서 일을 시작하게 하는’ 용법으로 이미 오래전부터 쓰여 왔습니다. 명령줄 인터페이스(CLI)의 C:\>와 같은 프롬프트는 사용자의 다음 명령 입력을 기대합니다. 2020년대에는 사용자가 모델에게 원하는 출력을 생성하기를 기대한다는 의미가 추가되었습니다.

1프롬프트 엔지니어링¶

프롬프트 엔지니어링(Prompt Engineering)은 대규모 언어 모델(LLM)이 원하는 출력을 내도록 입력 프롬프트를 작성하는 기술입니다. 언어 모델의 컨텍스트 학습를 활용하는 기법입니다.

2017년 어텐션 기반 트랜스포머 알고리즘이 등장한 이후, 계층을 추가하여 모델의 규모를 키우면 능력이 좋아진다는 딥러닝의 일반적인 방향성이 언어 모델에 적용되어 인터넷의 대규모 텍스트를 기반으로 대형 언어 모델들이 등장하기 시작했습니다. 실제로 언어모델은 규모의 법칙을 따른다는 것이 발견되었습니다. 그런데 규모가 증가할 수록 모델의 매개변수 최적화에 소요되는 연산량은 기하급수적으로 증가하기 때문에 2017년 이후로는 대규모 모델을 사전 훈련 (Pre-training)한 이후 특정한 작업에 맞춰 사후 훈련 (Post-training)에서 미세조정을 수행하여 응용 목표(downstream task)를 달성하는 방식을 활용했습니다. 전체 모델을 훈련하는 것에 비해서 미세조정은 그야말로 일부 매개변수만 조정하기 때문에 보다 효율적이지만 여전히 매개변수를 조정하는데 많은 노력과 연산 자원이 소요됩니다.

2021년부터는 프롬프트 기반 학습이 새로운 방향으로 제시되었습니다. Liu et al. (2021) 예를 들어, 번역용 모델 프롬프트는 "한국어: [입력] 영어: [출력]"과 같은 양식을 사용할 수 있습니다. 이 때, 입력 텍스트가 "나는 너를 사랑해"이라고 하겠습니다.

그럼 양식에 입력을 적용하면, 다음과 같이 프롬프트가 구성됩니다.

한국어: 나는 너를 사랑해 영어: [출력]

이러한 입력 프롬프트를 받은 모델은 [출력]을 채워 응답해야 합니다.

프롬프트 엔지니어링은 입력 $x$에 대한 기대 출력 $y$를 발생하는 가장 효과적인 프롬프트 함수 $f(x)$를 찾는 것을 의미합니다. 프롬프트 함수는 입력 $x$를 다른 형태 $x'=f(x)$으로 변형하는 무엇이든 가능합니다. 앞서 논의한 텍스트 양식도 프롬프트 함수입니다. 프롬프트 함수의 선택에 따라 모델 출력이 크게 차이가 나기 때문에 목표 달성을 위해 적절한 프롬프트를 선택하는 것이 중요합니다.

1.1프롬프트 형식¶

프롬프트 형식(prompt shape)은 크게 두 가지로 나뉩니다.

• 빈칸 채우기 프롬프트 (cloze prompt): 문장 중간에 모델이 채워야 하는 빈칸을 제시하는 방식.
  마스크 언어 모델(Masked LM, 예: BERT)처럼 사전 학습 방식이 빈칸 채우기 형태인 모델과 잘 맞습니다. 텍스트 재구성 과제에 유연하게 활용할 수 있습니다.

• 접두사 프롬프트 (prefix prompt): 앞부분(prefix)을 제시하고, 모델이 뒤에 텍스트를 이어서 완성하는 방식.
  왼쪽에서 오른쪽으로 텍스트를 이어 생성하는 자기회귀 언어 모델(Auto-regressive LM, 예: GPT 계열)이나 텍스트 생성(Generation) 과제에 잘 맞습니다.

1.2제로샷 프롬프트(Zero-Shot)¶

제로샷(Zero-Shot) 프롬프트는 예시 없이 과제의 수행 방법을 지시문으로 상세하게 설명하는 방식입니다. 역할, 출력 형식, 판단 기준 같은 정보가 모두 지시문에 담기 때문에 모델이 예시 없이도 과제를 수행할 수 있게 됩니다.

예시 1 — 감정 분류. 라벨 집합과 출력 형식을 지시문에 직접 명시합니다.

영화 리뷰의 감정을 '긍정', '부정', '중립' 중 하나로만 분류하세요.
리뷰: "화면은 아름답지만 전개가 다소 느리다."
감정:

모델은 지시문에만 근거해 중립과 같은 라벨을 답해야 합니다. 라벨 집합과 출력 형식이 명확하게 제시되어 있어, 예시 없이도 일관된 출력을 기대할 수 있습니다.

예시 2 — 조건부 요약. 대상 독자, 길이, 포함 요소를 지시문으로 제한합니다.

다음 글을 초등학생도 이해할 수 있도록 한 문장으로 요약하세요.
30자 이내, 주어와 술어를 반드시 포함하세요.
글: "광합성은 식물이 햇빛을 이용해 물과 이산화탄소로부터 포도당과 산소를 만드는 과정이다."
요약:

예상 출력은 식물이 햇빛으로 양분과 산소를 만든다.처럼 짧고 쉬운 문장입니다. 길이와 수준을 지시문에 못 박아 두면 예시 없이도 형식이 크게 흐트러지지 않습니다.

예시 3 — 정보 추출. 추출 대상과 예외 처리, 출력 형식을 함께 규정합니다.

다음 문장에서 장소, 날짜, 행사명만 추출하세요. 없는 항목은 '없음'이라 답하세요.
출력 형식: 장소: ... / 날짜: ... / 행사명: ...
문장: "지난 5월 12일 서울 시청 앞에서 열린 서울 스프링 페스타에 다녀왔다."

예상 출력은 장소: 서울 시청 앞 / 날짜: 5월 12일 / 행사명: 서울 스프링 페스타입니다. 추출 항목, 형식, 결측 처리까지 지시문에 담으면 예시 없이도 구조화된 답을 얻을 수 있습니다. 지시문이 모호할수록 출력이 흔들리므로, 제로샷(Zero-Shot)에서는 판단 기준과 형식을 최대한 구체적으로 적는 것이 핵심입니다.

1.3예시 제시형 프롬프트(Few-Shot)¶

예시 제시형 프롬프트(Few-Shot)는 지시문에 더해 소수의 입출력 예시를 함께 제시하는 방식입니다. 모델이 예시에서 형식, 라벨 집합, 변환 규칙을 귀납하도록 하여, 지시문만으로는 모호한 과제를 안정적으로 수행하게 합니다. 예시가 1개이면 단일 예시(One-Shot), 2개 이상이면 예시 제시형(Few-Shot)이라 부릅니다.

예시 1 — 자의적 라벨 매핑 (감정→이모지). 라벨과 기호의 대응이 임의적이라 지시문만으로 전달하기 어렵습니다.

문장: 최고예요! → 😀
문장: 그냥 그래요 → 😐
문장: 최악이에요 → 😞
문장: 생각보다 별로네요 →

예상 출력은 😞입니다. 세 이모지로 라벨 집합을 한정하는 규칙을 예시가 직접 보여 주므로, 모델이 새로운 문장도 같은 집합 안에서 답합니다.

예시 2 — 문체 변환 (구어체→보고서체). 변환 규칙을 예시로 모방시킵니다.

구어체: 배송 엄청 빨랐어요! → 보고서체: 배송 속도는 우수함.
구어체: 가격은 좀 비싼 듯 → 보고서체: 가격은 다소 높음.
구어체: 포장이 좀 부실했어요. → 보고서체:

예상 출력은 포장 상태는 미흡함.처럼 앞선 예시의 종결 방식(~함.)을 그대로 따릅니다. 지시문으로 "보고서체로 바꾸라"고만 하는 것보다 예시가 톤과 어미를 훨씬 정확하게 고정합니다.

예시 3 — 구조화 추출 (문장→JSON). 출력 스키마를 예시로 고정합니다.

문장: "화면은 아름답지만 전개가 느리다." → {"sentiment": "중립", "keywords": ["화면", "전개"]}
문장: "연출이 섬세하고 몰입감이 높다." → {"sentiment": "긍정", "keywords": ["연출", "몰입감"]}
문장: "배송은 빨랐지만 포장이 부실했어요." →

예상 출력은 {"sentiment": "중립", "keywords": ["배송", "포장"]}처럼 앞선 키 순서와 값 형식을 따릅니다. 스키마를 글로 설명하는 대신 예시 두 개로 보여 주면, 작은 모델에서도 형식 위반이 크게 줄어듭니다.

제로샷(Zero-Shot)이 지시문의 명확성에 의존한다면, 예시 제시형 프롬프트(Few-Shot)는 예시가 곧 명세 역할을 합니다. 출력 형식이 정해져 있거나 라벨·관례가 자의적일수록, 그리고 모델이 작을수록 예시 제시형 프롬프트(Few-Shot)의 효과가 큽니다.

1.4역할 지정¶

같은 질문도 역할을 지정하면 톤과 수준이 달라집니다. 시스템 프롬프트나 입력 앞부분에 너는 ...이다처럼 역할을 적어 모델의 관점과 어휘를 고정합니다.

예시 — 대상에 맞춘 설명. 역할이 없으면 기술적인 설명이 나오지만, 역할을 주면 답이 짧고 쉬워집니다.

[역할 없음]
질문: 물은 왜 파랗게 보여?

[역할 지정]
너는 5세 아이에게 설명하는 친절한 선생님이다. 두 문장 이내, 쉬운 말로만 답하세요.
질문: 물은 왜 파랗게 보여?

역할 없음은 빛의 산란과 물의 흡수 ...처럼 긴 설명을 내기 쉽고, 역할 지정은 물은 파란빛을 반사해서 파랗게 보여요. 해가 빛나면 더 잘 보여요!처럼 짧고 쉬운 답을 유도합니다. 전문가, 면접관, 검토자 등 역할을 바꾸면 같은 입력이라도 관점과 깊이가 달라집니다.

1.5단계적 추론(Chain of Thought)¶

여러 단계를 거쳐야 하는 문제는 중간 과정을 차례로 적게 하면 정확도가 올라갑니다. 단계적으로 풀라, 중간 계산을 모두 적으라는 한 줄 지시가 곧 단계적 추론 유도 프롬프트입니다. Wei et al. (2022)

한 반 학생 30명 중 60%가 안경을 쓴다. 안경 쓴 학생의 1/3이 여학생이다.
안경 쓴 남학생은 몇 명인가? 단계적으로 풀고 마지막 줄에 '답: N명' 형식으로 제시하세요.

예상 출력은 30 × 60% = 18명 → 18 × 1/3 = 6명이 여학생 → 18 − 6 = 12명, 답: 12명처럼 과정을 적은 뒤 답을 제시합니다. 곧바로 답을 요구하는 것보다 산술·논리 오류가 줄고, 틀렸을 때 어디서 틀렸는지 점검하기도 쉽습니다.

단계적 추론이 매우 효과적이어서, 최근 대부분의 모델은 단계적 추론 과정을 스스로 생성하도록 미세 조정되어 출시됩니다. 별도 지시가 없어도 내부적으로 단계별 사고를 전개하도록 학습된 모델이 늘고 있으며, 일반 모델도 사후 훈련 단계에서 단계적 추론 데이터를 포함해 학습합니다. 그 결과 간단한 문제는 명시적 지시 없이도 단계적으로 풀지만, 복잡한 과제에서는 여전히 단계적으로 풀라는 한 줄이 안정성과 검증 가능성을 높입니다.

1.6출력 형식 제어¶

후속 프로그램에서 바로 다루려면 출력을 JSON 같은 구조로 고정하는 것이 유리합니다. 지시문에 스키마와 설명 금지 같은 제약을 함께 적어 형식을 강제합니다.

다음 후기를 분석해 JSON으로만 출력하세요(설명 금지).
형식: {"sentiment": "긍정|부정|중립", "keywords": ["..."]}
후기: "배송은 빨랐지만 포장이 부실했어요."

예상 출력은 {"sentiment": "중립", "keywords": ["배송", "포장"]}입니다. 제로샷(Zero-Shot)·예시 제시형 프롬프트(Few-Shot)와 결합하면 keywords 개수나 값의 타입 같은 세부 규칙도 예시로 고정할 수 있습니다.

2한계 및 고려 사항¶

• 복잡·특화 작업의 한계: 프롬프트만으로는 고도로 특화된 지식·절차·제약이 필요한 작업에서 미세 조정이나 도구 결합 수준에 못 미칠 수 있습니다. 최신 정보, 사내 지식, 장기간 일관성이 요구되는 과제는 검색(RAG)이나 학습 기반 접근과 함께 쓰는 것이 효과적입니다.

• 민감성과 이식성 부족: 같은 의도의 문구를 조금만 바꿔도 출력이 크게 달라질 수 있습니다. 특정 모델·버전에 맞춰 다듬은 프롬프트가 다른 모델이나 업데이트된 버전에서 그대로 동작하지 않는 경우가 많아, 모델을 바꾸면 재검증이 필요합니다.

• 비용과 길이 제약: 예시와 지시를 늘릴수록 토큰 비용과 지연이 증가하고 핵심 지시가 희석될 수 있습니다. 컨텍스트 창을 초과하면 잘리거나 중간 정보가 손실되므로, 필요한 정보만 간결하게 넣고 우선순위를 명확히 하는 것이 중요합니다.

• 출력의 비결정성과 환각: 같은 프롬프트라도 temperature, top-p, seed 등에 따라 출력이 달라질 수 있으며, temperature를 0으로 두고 seed를 고정해도 엔진·병렬화 방식에 따라 완전한 재현성이 보장되지는 않습니다. 자세한 생성 인자는 생성 파라미터에서 다룹니다. 프롬프트로 사실성이나 공정성을 유도할 수 있으나, 모델의 환각이나 학습 데이터 편향 자체를 해소하지는 못하므로 중요한 사실은 외부 검증이 필요합니다.

• 프롬프트 주입(Prompt Injection): 외부 문서·웹 검색 결과·도구 출력·사용자 입력에 “이전 지시를 무시하라” 같은 문장이 섞이면 모델이 이를 지시로 따를 수 있습니다. 지시와 데이터를 구분하고 신뢰할 수 없는 입력을 권한 있는 지시로 취급하지 않도록 설계해야 하며, 이는 문서·도구를 컨텍스트에 들이는 다음 장(RAG·MCP)에서 특히 중요해집니다.