이 장은 앞선 21개 장과 성격이 조금 다릅니다. 새로운 에이전틱 패턴을 하나 더 소개하기보다, 모든 패턴이 딛고 서 있는 바닥, 즉 프롬프팅 자체를 정면으로 다룹니다.
프롬프팅은 언어 모델과 상호작용하는 주된 인터페이스로, 모델이 원하는 출력을 생성하도록 입력을 설계하는 과정이다. 여기에는 요청을 구조화하고, 관련 맥락을 제공하며, 출력 형식을 지정하고, 기대하는 응답 유형을 예시로 보여주는 작업이 포함된다.
프롬프트를 잘 설계하면 언어 모델의 잠재력을 최대한 끌어내 정확하고 관련성 높으며 창의적인 응답을 얻을 수 있습니다. 반면 설계가 부실하면 모호하거나, 관련 없거나, 잘못된 출력이 나옵니다. 프롬프트 엔지니어링의 목적은 결국 고품질 응답을 일관되게 끌어내는 것이고, 이를 위해서는 모델의 역량과 한계를 이해하고 의도한 목표를 효과적으로 전달해야 합니다.
에이전틱 패턴은 에이전트가 어떻게 계획을 세우고, 도구를 활용하며, 기억을 관리하고, 서로 협력하는지를 정의합니다. 하지만 그 모든 구조가 실제로 잘 작동하려면 결국 언어 모델과 의미 있게 상호작용할 수 있어야 합니다. 1장의 프롬프트 체이닝부터 21장의 AI 코사이언티스트까지, 모든 에이전트의 한 걸음 한 걸음은 결국 프롬프트 한 장으로 시작합니다.
이 장이 다루는 범위는 이렇습니다.
핵심 원칙 ─▶ 기본 기법 ─▶ 프롬프트 구조화 ─▶ 컨텍스트 엔지니어링 ─▶ 구조화된 출력
(명확·간결) (0/1/N-shot) (시스템·역할·구분자) (층위별 맥락 조립) (JSON·Pydantic)
│
모범 사례 ◀─ 특정 과제 ◀─ 메타 접근법 ◀─ 고급 기법 ◀─ 동작·상호작용 ◀─ 추론·사고 과정
(실험·기록) (코드·멀티모달) (LLM으로 개선) (APE·DSPy·RAG) (함수 호출·ReAct) (CoT·SC·ToT)
핵심 프롬프팅 원칙
효과적인 프롬프팅은 다양한 모델과 과제 복잡도에 두루 적용되는 기본 원칙에 기반합니다.
| 원칙 | 내용 |
|---|---|
| 명확성과 구체성 | 지시는 모호하지 않고 정확해야 한다. 언어 모델은 패턴을 해석하므로, 여러 해석이 가능하면 의도하지 않은 응답이 나올 수 있다. 과제, 출력 형식, 제약 조건을 명확히 정의하고 모호한 표현이나 암묵적 가정은 피한다 |
| 간결성 | 구체성이 중요하지만 간결성을 해쳐서는 안 된다. 불필요한 어구나 복잡한 문장 구조는 핵심 지시를 가린다. 사용자에게 혼란스럽다면 모델에게도 마찬가지다 |
| 동사 활용 | 동사 선택이 결과를 좌우한다. “이 내용을 어떻게 요약해야 할지 생각해 봐”보다 “다음 텍스트를 요약하라” 가 효과적이다. 정확한 동사는 모델이 해당 작업에 맞는 학습 데이터와 처리 과정을 활성화하도록 이끈다 |
| 제약보다 지시 우선 | 긍정적 지시가 부정적 제약보다 일반적으로 더 효과적이다. 하지 말아야 할 것을 나열하기보다 원하는 동작을 명시한다. 제약에 지나치게 의존하면 모델이 목표 수행보다 회피에 집중하게 될 수 있다 |
| 실험과 반복 개선 | 프롬프트 엔지니어링은 반복적인 과정이다. 초안 작성 → 테스트 → 출력 분석 → 개선을 반복한다. 모델 종류, temperature나 top-p 같은 설정, 미세한 표현 변경에 따라 결과가 달라지므로 시도한 내용을 기록하는 것이 꼭 필요하다 |
책이 추천하는 효과적인 동사 목록도 옮겨 둡니다.
Act(역할을 하라), Analyze(분석하라), Categorize(범주화하라), Classify(분류하라), Contrast(대조하라), Compare(비교하라), Create(만들어라), Describe(기술하라), Define(정의하라), Evaluate(평가하라), Extract(추출하라), Find(찾아라), Generate(생성하라), Identify(식별하라), List(나열하라), Measure(측정하라), Organize(정리하라), Parse(파싱하라), Pick(골라라), Predict(예측하라), Provide(제공하라), Rank(순위를 매겨라), Recommend(추천하라), Return(반환하라), Retrieve(가져와라), Rewrite(다시 작성하라), Select(선택하라), Show(보여 줘라), Sort(정렬하라), Summarize(요약하라), Translate(번역하라), Write(작성하라)
(옮긴이) temperature와 top-p란 모델이 다음 단어를 선택할 때 쓰는 샘플링 파라미터로, 출력의 다양성과 창의성을 조절한다. 값이 낮을수록 안정적이고 예측 가능한 출력이, 높을수록 다양하고 창의적인 출력이 나오는 경향이 있다.
명확성, 간결성, 행동 동사, 긍정적 지시, 반복 개선 — 이 다섯 가지 원칙을 먼저 챙기는 습관이 이후 모든 고급 기법의 기반이 됩니다.
기본 프롬프팅 기법
기본 기법들은 언어 모델에게 다양한 수준의 정보나 예시를 제공해 응답 방향을 잡아 줍니다. 차이는 결국 예시를 몇 개 주느냐입니다.
제로샷 프롬프팅
원하는 입출력 쌍의 예시 없이 지시와 입력 데이터만 제공합니다. 모델은 과제 이해와 응답 생성을 전적으로 사전 학습에 의존합니다.
- 사용 시점: 가장 먼저 시도해 볼 만한 빠른 접근법. 단순한 질의응답, 텍스트 완성, 기본적인 요약처럼 모델이 학습 과정에서 충분히 접했을 법한 과제라면 대개 충분하다.
다음 영어 문장을 프랑스어로 번역하라: 'Hello, how are you?'
원샷 프롬프팅
실제 과제를 제시하기 전에 입력과 원하는 출력 예시를 하나 제공합니다. 모델이 따라야 할 패턴을 초기 시연으로 보여주는 역할입니다.
- 사용 시점: 원하는 출력 형식이나 스타일이 특수하거나 흔하지 않을 때 유용하다. 특정 구조나 톤이 필요한 과제에서 제로샷보다 나은 성능을 낼 수 있다.
다음 영어 문장을 스페인어로 번역하라:
English: 'Thank you.'
Spanish: 'Gracias.'
English: 'Please.'
Spanish:
퓨샷 프롬프팅
원샷을 확장해 보통 세 개에서 다섯 개의 입출력 쌍을 제공합니다. 기대하는 응답 패턴을 더 명확하게 보여주어, 모델이 새 입력에 대해 그 패턴을 재현할 가능성을 높입니다.
- 사용 시점: 출력이 특정 형식·스타일을 따르거나 미묘한 변형을 보여야 하는 과제. 분류, 특정 스키마에 따른 데이터 추출, 특정 스타일의 텍스트 생성 등에 뛰어나며, 제로샷이나 원샷으로 일관된 결과를 얻지 못할 때 유용하다. 예시 개수는 과제 복잡도와 모델의 토큰 한도에 따라 조정한다.
- 예시 품질과 다양성의 중요성: 예시는 정확하고 과제를 대표해야 하며, 변형과 엣지 케이스를 포괄해야 한다. 작은 실수 하나가 모델을 혼란시켜 원치 않는 출력을 유발할 수 있다.
- 분류 예시에서 클래스 순서 섞기: 분류 과제라면 서로 다른 클래스의 예시 순서를 섞는다. 모델이 특정 예시 순서에 과적합하는 것을 방지하고, 각 클래스의 핵심 특징을 독립적으로 파악하도록 유도한다.
- “매니샷” 학습으로의 발전: 제미나이 같은 최신 모델이 긴 컨텍스트 처리 능력을 갖추면서 “매니샷(many-shot)” 학습에서도 높은 성능을 보이고 있다. 경우에 따라 수백 개의 예시를 프롬프트에 직접 넣어 더 복잡한 패턴을 학습시킬 수 있다.
다음 영화 리뷰의 감정을 POSITIVE, NEUTRAL, NEGATIVE 중 하나로 분류하라:
Review: "연기가 훌륭했고 이야기도 흡입력 있었다."
Sentiment: POSITIVE
Review: "그럭저럭 괜찮았지만 특별할 건 없었다."
Sentiment: NEUTRAL
Review: "줄거리는 혼란스러웠고 등장인물에는 정이 안 갔다."
Sentiment: NEGATIVE
Review: "영상미는 뛰어났지만 대사는 약했다."
Sentiment:
| 기법 | 예시 수 | 언제 쓰는가 |
|---|---|---|
| 제로샷 | 0 | 모델이 이미 잘 아는 흔한 과제. 첫 시도 |
| 원샷 | 1 | 형식·스타일이 특수해 한 번 보여줘야 할 때 |
| 퓨샷 | 3~5 | 분류·스키마 추출처럼 일관된 패턴이 필요할 때 |
| 매니샷 | 수십~수백 | 긴 컨텍스트 모델로 복잡한 패턴을 학습시킬 때 |
프롬프트 구조화
예시 외에도 프롬프트를 어떻게 구조화하느냐가 매우 중요합니다. 구조화란 프롬프트 안에 여러 섹션이나 요소를 두어 지시, 맥락, 예시 등 서로 다른 유형의 정보를 명확하고 체계적으로 제공하는 것이고, 그래야 모델이 각 텍스트 조각의 역할을 정확히 파악할 수 있습니다.
시스템 프롬프팅
시스템 프롬프팅은 모델의 전반적인 맥락과 목적을 설정해, 상호작용이나 세션 전체에서 모델이 어떻게 동작해야 하는지를 정의합니다. 특정 사용자 질의와 달리 모델 응답의 기본 지침이 되어 톤, 스타일, 일반적 접근 방식에 영향을 줍니다. 예의 바른 언어 사용 같은 지침을 담아 안전성과 유해 표현 통제에도 활용됩니다.
나아가 LLM 기반 반복 개선으로 자동 프롬프트 최적화를 수행할 수도 있습니다. Vertex AI 프롬프트 최적화기 같은 서비스는 사용자 정의 지표와 대상 데이터를 기반으로 프롬프트를 체계적으로 개선합니다.
당신은 도움이 되고 무해한 AI 도우미입니다. 모든 질의에 정중하고 유익한 방식으로
응답하세요. 유해하거나 편향되거나 부적절한 콘텐츠를 생성하지 마세요.
역할 프롬프팅
모델에게 특정 캐릭터, 페르소나, 정체성을 부여합니다. 흔히 시스템 프롬프팅이나 맥락 프롬프팅과 함께 쓰며, 해당 역할에 맞는 지식·톤·소통 스타일을 채택하도록 지시합니다. “여행 가이드 역할을 하라”, “당신은 전문 데이터 분석가입니다” 같은 식이며, 역할 안에서 “유머러스하면서도 영감을 주는 스타일”처럼 원하는 스타일도 구체적으로 지정할 수 있습니다.
노련한 여행 블로거 역할을 하라. 로마의 숨겨진 보석 같은 명소에 대해 짧고 흥미로운
안내문을 작성하라.
구분자 사용
지시, 맥락, 예시, 입력을 명확히 구분해 전달하는 것이 중요합니다. 삼중 백틱(```), XML 태그(<instruction>, <context>), 구분 표시(—) 같은 구분자를 쓰면 섹션을 시각적으로, 그리고 프로그래밍 방식으로도 분리할 수 있습니다.
<instruction>다음 기사를 요약하라. 저자가 제시한 주요 논점에 초점을 맞출 것.</instruction>
<article>
[기사 전문을 여기에 삽입]
</article>
구분자는 사람보다 파이프라인에서 더 빛을 발합니다. 사용자 입력이나 검색 결과를 프롬프트 템플릿에 끼워 넣을 때, 경계가 분명해야 입력 안의 문장이 지시로 오인되지 않습니다. 18장의 프롬프트 인젝션 방어와도 맞닿는 지점입니다.
컨텍스트 엔지니어링
컨텍스트 엔지니어링은 정적인 시스템 프롬프트와 달리 과제와 대화에 필요한 배경 정보를 상황에 맞춰 그때그때 제공한다.
끊임없이 변하는 이 정보는 모델이 뉘앙스를 파악하고, 과거 상호작용을 떠올리며, 관련 세부사항을 통합해 근거 있는 응답을 내도록 돕습니다. 이전 대화 내용, 관련 문서(RAG처럼), 특정 운영 매개변수 등이 그 예입니다. 예컨대 일본 여행을 이야기하던 중에 “도쿄에서 가족과 함께할 수 있는 활동 세 가지”를 요청하면, 모델은 기존 대화 맥락을 활용하게 됩니다.
에이전틱 시스템에서 컨텍스트 엔지니어링은 기억 유지, 의사결정, 하위 작업 간 조율 같은 핵심 에이전트 동작의 근간입니다. 맥락을 그때그때 구성하는 파이프라인을 갖춘 에이전트는 시간이 지나도 목표를 유지하고, 전략을 조정하며, 다른 에이전트나 도구와 원활하게 협업할 수 있습니다.
이 방법론에서는 모델 출력의 품질이 모델 아키텍처보다 제공된 맥락의 풍부함에 더 크게 좌우된다고 본다.
사용자 질의의 표현을 최적화하는 데 초점을 맞추던 전통적 프롬프트 엔지니어링에서 크게 발전한 것으로, 여러 층위의 정보를 포함하도록 범위를 확장합니다.
| 층위 | 설명 | 예 |
|---|---|---|
| 시스템 프롬프트 | AI의 운영 매개변수를 정의하는 기본 지시 | “당신은 기술 문서 작성자입니다. 톤은 격식 있고 정확해야 합니다” |
| 외부 데이터 — 검색된 문서 | 응답에 참고하기 위해 지식 베이스에서 능동적으로 가져온 정보 | 기술 사양서 검색 |
| 외부 데이터 — 도구 출력 | AI가 실시간 데이터를 위해 외부 API를 사용한 결과 | 일정에서 가용 시간 조회 |
| 암묵적 데이터 | 사용자 신원, 상호작용 이력, 환경 상태 같은 핵심 정보 | 이메일 수신자와의 업무 관계 |
암묵적 맥락을 통합하면 개인정보 보호와 윤리적 데이터 관리 과제가 따릅니다. 그래서 컨텍스트 엔지니어링에는 탄탄한 거버넌스가 필수이고, 특히 기업·의료·금융 분야라면 더더욱 그렇습니다.
핵심 원칙은 아무리 뛰어난 모델이라도 운영 환경에 대한 정보가 제한적이거나 부실하면 제 역량을 발휘하지 못한다는 것입니다. 이 접근은 과제를 단순히 질문에 답하는 것에서 에이전트를 위한 종합적 운영 상황을 구축하는 것으로 재정의합니다. 예를 들어 컨텍스트 엔지니어링이 적용된 에이전트는 질의에 응답하기 전에 다음을 종합합니다.
┌─────────────────────────┐
│ 일정 가용 시간 (도구 출력) │──┐
└─────────────────────────┘ │
┌─────────────────────────┐ │ ┌─────────────────┐ ┌──────────────┐
│ 수신자와의 관계 (암묵적) │──┼────▶│ 조립된 컨텍스트 │────▶│ 관련성·개인화· │
└─────────────────────────┘ │ │ + 시스템 프롬프트 │ │ 실용성 갖춘 출력 │
┌─────────────────────────┐ │ └─────────────────┘ └──────────────┘
│ 이전 회의 메모 (검색 문서) │──┘
└─────────────────────────┘
“엔지니어링”이라는 말이 붙는 이유는 런타임에 이 데이터를 가져와 변환하는 견고한 파이프라인을 구축하고, 맥락 품질을 지속적으로 개선하는 순환 구조를 마련해야 하기 때문입니다.
이를 구현하기 위해 Vertex AI 프롬프트 최적화기 같은 튜닝 시스템으로 대규모 개선 프로세스를 자동화할 수 있습니다. 샘플 입력과 미리 정의된 지표로 응답을 평가할 수 있다면, 이런 도구는 모델 성능을 최대한 끌어내는 최적화된 프롬프트를 생성합니다. 모델이 달라져도 대대적인 수작업 재작성 없이 프롬프트와 시스템 지시를 조정할 수 있습니다.
결국 컨텍스트 엔지니어링은 상태 없는 챗봇을 고도로 유능하고 상황을 인식하는 시스템으로 전환하는 핵심 방법론이다. 에이전트가 무엇을 알고, 언제 아는지, 그리고 그 정보를 어떻게 활용하는지에 초점을 맞추어 맥락을 핵심 구성 요소로 취급한다.
8장의 기억 관리와 14장의 지식 검색이 “무엇을 저장하고 어떻게 꺼내 오는가” 의 문제였다면, 컨텍스트 엔지니어링은 “꺼내 온 것을 언제 어떤 모양으로 모델 앞에 놓는가” 의 문제입니다.
구조화된 출력
프롬프팅의 목표는 대개 자유 형식 응답을 넘어 기계가 읽을 수 있는 특정 형식으로 정보를 추출하거나 생성하는 것입니다. JSON, XML, CSV, 마크다운 표 같은 출력을 명시적으로 요청하고 원하는 구조의 스키마나 예시를 제공하면, 모델이 응답을 에이전틱 시스템의 다른 부분에서 쉽게 파싱할 수 있는 형태로 정리하게 할 수 있습니다.
데이터 추출 시 JSON 객체로 반환하게 하면 모델이 구조를 만들어야 하므로 환각도 줄일 수 있다.
특히 데이터 추출이나 분류 같은 비창의적 과제에서는 출력 형식을 다양하게 실험해 보는 것이 좋습니다.
아래 텍스트에서 다음 정보를 추출해 "name", "address", "phone_number" 키를 가진
JSON 객체로 반환하라.
Text: "서울특별시 강남구 테헤란로 123에 있는 김민수에게 010-1234-5678로 연락하세요."
시스템 프롬프트, 역할 부여, 맥락 정보, 구분자, 구조화된 출력을 효과적으로 활용하면 명확성·제어력·유용성이 크게 높아집니다. 언어 모델의 출력이 후속 시스템이나 처리 단계의 입력으로 쓰이는 파이프라인이라면 구조화된 출력 요청은 매우 중요합니다.
Pydantic을 활용한 객체 지향 퍼사드
LLM이 생성한 데이터로 Pydantic 모델 인스턴스를 채우는 것은 구조화된 출력을 강제하고 상호운용성을 높이는 강력한 기법입니다. Pydantic은 파이썬 타입 어노테이션을 활용한 데이터 검증·설정 관리 라이브러리로, 모델을 정의하면 원하는 데이터 구조에 맞는 명확하고 엄격한 스키마가 생깁니다. 이 접근법은 프롬프트 출력에 객체 지향 퍼사드(facade) 를 제공해, 원시 텍스트나 반구조화된 데이터를 검증되고 타입 힌트가 적용된 파이썬 객체로 변환합니다.
(옮긴이) 퍼사드란 원래 건물의 정면을 뜻하는 말로, 소프트웨어에서는 복잡한 하위 시스템을 단순하고 통일된 인터페이스 뒤로 숨기는 디자인 패턴을 가리킨다. 여기서는 LLM이 만들어 내는 비정형 출력을 Pydantic 객체라는 깔끔한 표면 뒤에 두고 다룬다는 의미로 쓰였다.
LLM에서 받은 JSON 문자열은 model_validate_json 메서드로 Pydantic 객체로 직접 파싱할 수 있습니다. 파싱과 검증을 한 단계로 결합하므로 특히 유용합니다.
from pydantic import BaseModel, EmailStr, Field, ValidationError
from typing import List, Optional
from datetime import date
# --- Pydantic 모델 정의 ---
class User(BaseModel):
name: str = Field(..., description="사용자의 전체 이름")
email: EmailStr = Field(..., description="사용자의 이메일 주소")
date_of_birth: Optional[date] = Field(None, description="사용자의 생년월일")
interests: List[str] = Field(default_factory=list, description="사용자의 관심사 목록")
# --- 가상의 LLM 출력 ---
llm_output_json = """
{
"name": "Alice Wonderland",
"email": "alice.w@example.com",
"date_of_birth": "1995-07-21",
"interests": [
"Natural Language Processing",
"Python Programming",
"Gardening"
]
}
"""
# --- 파싱 및 검증 ---
try:
# model_validate_json 클래스 메서드를 사용해 JSON 문자열을 파싱한다.
# 이 한 단계로 JSON 파싱과 User 모델 기준의 데이터 검증을 동시에 수행한다.
user_object = User.model_validate_json(llm_output_json)
# 이제 깔끔하고 타입 안전한 파이썬 객체로 작업할 수 있다.
print("Successfully created User object!")
print(f"Name: {user_object.name}")
print(f"Email: {user_object.email}")
print(f"Date of Birth: {user_object.date_of_birth}")
print(f"First Interest: {user_object.interests[0]}")
# 다른 파이썬 객체 속성처럼 데이터에 접근할 수 있다.
# Pydantic이 'date_of_birth' 문자열을 datetime.date 객체로 이미 변환해 두었다.
print(f"Type of date_of_birth: {type(user_object.date_of_birth)}")
except ValidationError as e:
# JSON 형식이 잘못되었거나 데이터가 모델의 타입과 맞지 않으면
# Pydantic이 ValidationError를 발생시킨다.
print("Failed to validate JSON from LLM.")
print(e)
눈여겨볼 점은 두 가지입니다.
"1995-07-21"이라는 문자열이datetime.date객체로 자동 변환된다. 호출하는 쪽은 더 이상 날짜 파싱을 신경 쓸 필요가 없다.Field(..., description=...)의 설명은 검증용이면서 동시에 모델에게 줄 스키마 설명으로도 재사용할 수 있다. 같은 정의가 프롬프트의 출력 형식 지정과 응답 검증 양쪽에 쓰인다.
XML 데이터라면 xmltodict 라이브러리로 XML을 딕셔너리로 변환한 다음 Pydantic 모델에 전달해 파싱할 수 있습니다. Pydantic의 Field 별칭을 사용하면, 장황한 표현과 복잡한 속성 구조가 뒤섞이기 마련인 XML을 객체의 필드에 매끄럽게 매핑할 수 있습니다.
LLM의 출력이 Pydantic 객체에 캡슐화되면, 데이터가 기대하는 구조와 타입에 부합한다는 확신을 갖고 다른 함수, API, 데이터 처리 파이프라인에 안정적으로 전달할 수 있습니다.
시스템 컴포넌트 경계에서 “검증하지 말고 파싱하라(parse, don’t validate)” 라는 관행을 적용하면 더 견고하고 유지보수하기 쉬운 애플리케이션을 만들 수 있다.
(옮긴이) “검증하지 말고 파싱하라”는 곳곳에서 조건문으로 유효성을 검사하기보다 캡슐화된 객체를 생성하는 시점에 한 번의 파싱으로 올바른 데이터만 들어오게 설계하라는 의미다.
추론 및 사고 과정 기법
대규모 언어 모델은 패턴 인식과 텍스트 생성에 뛰어나지만, 복잡한 다단계 추론이 필요한 과제에서는 어려움을 겪는 경우가 많습니다. 이 절은 모델이 내부 사고 과정을 드러내도록 유도해 논리적 추론, 수학적 계산, 계획 수립 능력을 향상시키는 기법을 다룹니다. 17장의 추론 기법을 프롬프트 작성자의 시점에서 다시 보는 절이라고 생각하면 됩니다.
Chain of Thought(CoT)
결과만 묻는 대신 “단계별로 생각해 보라” 고 지시해, 최종 답에 도달하기 전에 중간 추론 단계를 명시적으로 생성하게 합니다. 사람이 문제를 더 작은 부분으로 나누어 순서대로 풀어가는 방식과 같습니다. 중간 단계 없이 바로 답하면 틀릴 수 있는 계산·논리 과제에서, 중간 단계를 생성하면 모델이 올바른 경로를 유지하며 필요한 연산을 정확히 수행할 가능성이 높아집니다.
CoT에는 두 가지 주요 변형이 있습니다.
제로샷 CoT — 추론 예시 없이 프롬프트에 “Let’s think step by step”(한국어로는 “단계별로 생각해 보자”)만 추가합니다. 놀랍게도 많은 과제에서 이 간단한 추가만으로 성능이 크게 향상됩니다.
기차가 시속 60마일로 240마일 거리를 이동했다면, 이동에는 얼마나 걸렸는가?
단계별로 생각해 보자.
퓨샷 CoT — CoT와 퓨샷을 결합해, 입력·단계별 추론 과정·최종 출력이 모두 포함된 예시를 여러 개 제공합니다. 추론 수행 방법과 응답 구조에 대한 더 명확한 템플릿이 주어져, 복잡한 과제에서 제로샷 CoT보다 좋은 결과를 낼 때가 많습니다.
Q: 연속된 세 정수의 합이 36이다. 그 정수들은 무엇인가?
A: 첫 번째 정수를 x라 하자. 다음 연속 정수는 x+1, 세 번째는 x+2이다.
합은 x + (x+1) + (x+2) = 3x + 3이다. 합이 36이라고 했으므로 3x + 3 = 36이다.
양변에서 3을 빼면 3x = 33. 양변을 3으로 나누면 x = 11.
따라서 세 정수는 11, 11+1 = 12, 11+2 = 13이다. 정수는 11, 12, 13이다.
Q: 사라는 사과 5개를 가지고 있고, 8개를 더 산다. 그리고 사과 3개를 먹는다.
사라에게 사과는 몇 개 남았는가? 단계별로 생각해 보자.
A: 단계별로 생각해 보자. 사라는 사과 5개로 시작한다. 8개를 더 사니까 처음 양에
8을 더해서 5 + 8 = 13개가 된다. 그 다음 3개를 먹으므로 합계에서 3을 뺀다:
13 - 3 = 10. 사라에게는 사과 10개가 남는다. 답은 10이다.
| 장점 | 단점 |
|---|---|
| 구현 노력이 적고, 파인튜닝 없이 기성 모델로도 효과가 크다 | 추론 단계만큼 출력이 길어져 토큰 사용량·비용·응답 시간이 증가 |
| 추론 단계를 볼 수 있어 해석 가능성이 높아지고 디버깅이 쉽다 | |
| 모델 버전이 바뀌어도 프롬프트 안정성이 유지되는 것으로 보인다 |
CoT를 쓸 때 기억할 두 가지 관행이 있습니다.
추론을 먼저, 최종 답은 그 뒤에 둔다. LLM은 앞에 존재하는 내용을 바탕으로 다음 토큰을 예측하므로, 먼저 생성된 추론 과정이 최종 답의 품질과 방향에 영향을 준다. 또한 수학 문제처럼 정답이 하나인 과제에서는 temperature를 0(탐욕적 디코딩) 으로 설정해 각 단계에서 가장 확률이 높은 토큰을 결정론적으로 선택하게 하는 것이 좋다.
구조화된 출력과 CoT를 함께 쓸 때 이 관행이 특히 중요해집니다. JSON 스키마에 answer 필드를 reasoning 필드보다 먼저 두면, 모델은 추론하기 전에 답부터 확정해 버립니다.
자기 일관성(Self-Consistency)
CoT를 발전시킨 기법으로, 언어 모델의 확률적 특성을 오히려 활용합니다. 하나의 탐욕적 추론 경로에 의존하지 않고, 같은 문제에 대해 다양한 추론 경로를 여러 개 생성한 뒤 가장 일관된 답을 고릅니다.
- 다양한 추론 경로 생성: 같은 프롬프트(보통 CoT 프롬프트)를 여러 번 전달한다. 높은 temperature를 설정해 서로 다른 추론 접근법을 탐색하게 한다.
- 답 추출: 각 추론 경로에서 최종 답을 추출한다.
- 가장 많이 나온 답 선택: 추출된 답들에 대해 다수결 투표를 수행한다.
프롬프트: "'모든 새는 날 수 있다'라는 진술은 참인가, 거짓인가? 그렇게 판단한 근거를 설명하라."
모델 실행 1 (높은 temperature) ─▶ 대부분의 새가 날 수 있다고 추론 ─▶ True
모델 실행 2 (높은 temperature) ─▶ 펭귄과 타조를 근거로 추론 ─▶ False
모델 실행 3 (높은 temperature) ─▶ 새를 일반적으로 보며 추론, 예외는 짧게 ─▶ True
─────────
다수결(True 2회) ─▶ 최종 답 "True"
정답일 가능성이 높아져 전반적 정확도가 올라가지만, 같은 질의를 여러 번 실행해야 하므로 연산량과 비용이 크게 증가합니다.
이 예시는 자기 일관성의 한계를 보여 주는 데도 쓸모가 있습니다. 논리적으로 엄밀한 답은 오히려 소수 의견인 False입니다. 책도 괄호로 “더 정교한 접근법이라면 추론 품질에 가중치를 부여할 것”이라고 덧붙입니다. 다수결은 정답이 하나로 수렴하는 계산 문제에서 가장 잘 작동하고, 해석에 따라 답이 갈리는 질문에서는 19장의 LLM 판정자처럼 추론 자체를 평가하는 장치가 필요합니다.
스텝백 프롬프팅
특정 세부사항을 다루기 전에 과제와 관련된 일반 원리나 개념을 먼저 고려하도록 요청합니다. 더 일반적인 질문에 대한 응답을 원래 문제를 풀기 위한 맥락으로 활용하는 것입니다. 근본 원리나 상위 수준의 추상화에 초점을 맞추면 피상적 요소에 덜 영향받는 더 정확하고 통찰력 있는 답을 생성할 수 있고, 일반 원리를 강조해 편향을 줄이는 효과도 기대할 수 있습니다.
프롬프트 1 (스텝백):
"좋은 추리 소설을 만드는 핵심 요소는 무엇인가?"
모델 응답 1:
(미끼 단서(red herrings), 설득력 있는 동기, 결함 있는 주인공, 논리적 단서,
만족스러운 결말 같은 요소를 나열한다.)
프롬프트 2 (원래 과제 + 스텝백 맥락):
"좋은 추리 소설의 핵심 요소[모델 응답 1을 여기에 삽입]를 활용해, 작은 마을을
배경으로 한 새 미스터리 소설의 짧은 줄거리 요약을 작성하라."
구조를 보면 1장의 프롬프트 체이닝 그 자체입니다. 첫 호출의 출력이 두 번째 호출의 맥락이 됩니다.
Tree of Thoughts(ToT)
CoT를 확장해, 하나의 선형 경로만 따라가지 않고 여러 추론 경로를 동시에 탐색하게 합니다. 트리 구조를 활용하는데, 각 노드는 하나의 “사고”, 즉 중간 단계 역할을 하는 일관된 언어 단위에 해당합니다. 각 노드에서 모델은 여러 갈래로 뻗어 나가 대안적 추론 경로를 탐색할 수 있습니다.
ToT는 탐색, 되돌아가기, 여러 가능성의 평가가 필요한 복잡한 문제에 특히 적합합니다. 선형 CoT보다 계산 비용이 많이 들고 구현도 복잡하지만, 신중하고 탐색적인 문제 해결이 필요한 과제에서는 더 나은 결과를 냅니다. “사고 트리”의 다른 분기를 살펴봄으로써 다양한 관점을 검토하고, 초반의 오류에서 회복할 수도 있습니다.
- 개념 설명용 예시: “이 줄거리 포인트를 바탕으로 이야기의 가능한 결말 세 가지를 만들어라” 같은 창작 과제에서, ToT를 사용하면 하나의 선형 연장만 생성하는 대신 핵심 전환점에서 여러 개의 서사 분기를 탐색할 수 있다.
CoT ToT
┌─────┐ ┌─────┐
│ 입력 │ │ 입력 │
└──┬──┘ └──┬──┘
▼ ┌────────┼────────┐
( 사고 ) ( 사고 ) ( 사고 ) ( 사고 )
▼ ▼ ╳ ▼ ▼
( 사고 ) ( 사고 ) 가지치기 ( 사고 ) ( 사고 )
▼ ▼ ◀── 되돌아가기
┌─────┐ ┌─────┐
│ 출력 │ │ 출력 │
└─────┘ └─────┘
| 기법 | 경로 수 | 비용 | 적합한 과제 |
|---|---|---|---|
| CoT | 1개, 선형 | 낮음 | 계산·논리처럼 단계가 분명한 과제 |
| 자기 일관성 | N개, 서로 독립 | N배 | 정답이 하나로 수렴하는 과제 |
| 스텝백 | 2단계 (원리 → 적용) | 약 2배 | 배경 원리를 먼저 세워야 하는 과제 |
| ToT | 트리, 분기·되돌아가기 | 높음 | 탐색과 평가가 필요한 복잡한 과제 |
모델이 자신의 추론을 드러내고, 여러 관점을 고려하고, 일반 원리로 한 걸음 물러서 생각하게 유도하면 에이전틱 시스템 안에서 복잡한 인지 과제를 수행하는 능력을 크게 높일 수 있습니다.
동작 및 상호작용 기법
지능형 에이전트는 텍스트 생성을 넘어 환경과 능동적으로 상호작용합니다. 도구를 활용하고, 외부 함수를 실행하며, 관찰-추론-실행의 반복 순환에 참여하는 것이 여기에 포함됩니다.
도구 사용/함수 호출
에이전트의 핵심 능력 중 하나는 외부 도구를 사용하거나 함수를 호출해 스스로 처리할 수 있는 범위를 넘어서는 작업을 수행하는 것입니다. 웹 검색, 데이터베이스 접근, 이메일 전송, 계산 수행, 외부 API와의 상호작용 등이 포함됩니다. 도구 사용을 위한 효과적인 프롬프팅의 요체는 모델이 도구를 언제 어떻게 활용해야 하는지 명확히 알 수 있도록 설계하는 데 있습니다.
최신 언어 모델은 “함수 호출”이나 “도구 사용”을 위해 파인튜닝되는 경우가 많아, 가용 도구의 설명 — 목적과 매개변수 포함 — 을 해석할 수 있습니다. 사용자 요청을 받으면 모델은 도구 사용이 필요한지 판단하고, 적절한 도구를 선택한 뒤 호출에 필요한 인수를 포맷합니다.
모델이 도구를 직접 실행하지는 않는다. 대신 도구와 매개변수를 지정하는 구조화된 출력(보통 JSON 형식) 을 생성한다. 에이전틱 시스템이 이 출력을 처리해 도구를 실행하고, 도구의 결과를 모델에게 돌려주어 진행 중인 상호작용에 통합한다.
지정한 도시의 현재 날씨를 가져올 수 있는 날씨 도구를 사용할 수 있다.
이 도구의 이름은 'get_current_weather'이며, 'city' 매개변수(문자열)를 받는다.
User: 지금 런던 날씨는 어때?
기대하는 모델 출력(함수 호출)은 이렇습니다.
{
"tool_code": "get_current_weather",
"tool_name": "get_current_weather",
"parameters": {
"city": "London"
}
}
결국 함수 호출은 앞 절의 구조화된 출력이 행동으로 이어지는 지점입니다. 5장의 도구 사용 패턴이 이 메커니즘 위에 서 있습니다.
ReAct(Reason and Act)
ReAct는 Reason and Act의 약자로, CoT 스타일의 추론과 도구를 이용한 동작 수행을 번갈아 끼워 넣는 프롬프팅 패러다임입니다. 우리가 말로 추론하고, 더 많은 정보를 수집하거나 목표를 향해 나아가기 위해 행동하는 방식을 모방합니다.
- Thought: 모델이 현재의 이해와 계획을 설명하는 사고 과정을 생성한다.
- Action: 사고를 바탕으로 동작을 수행하기로 결정한다. 보통 도구(예: Search, Calculator, API 호출)를 사용하며, 도구 이름과 필요한 입력을 출력한다.
- Observation: 에이전틱 시스템이 도구를 실행하고 그 결과를 모델에게 돌려준다.
- 모델이 최신 Observation을 바탕으로 새로운 Thought를 생성하면서 루프가 계속되고, 과제가 완료되면 “Final Answer” 를 출력한다.
User: 프랑스의 수도는 어디이고 현재 인구는 얼마인가?
Thought: 사용자가 두 가지 정보를 묻고 있다. 프랑스의 수도와 그 인구다. 이 정보는
검색 도구로 찾을 수 있다. 수도는 알고 있을 가능성이 높지만, 먼저 확인부터 하겠다.
Action: Search({"query": "프랑스의 수도"})
Observation: 파리
Thought: 맞다, 수도는 파리다. 이제 파리의 인구를 찾아야 한다.
Action: Search({"query": "파리 현재 인구"})
Observation: 2023년 기준 파리의 인구는 약 210만 명으로 추정된다.
Thought: 두 가지 정보를 모두 찾았다. 이제 사용자에게 최종 답을 제공할 수 있다.
Final Answer: 프랑스의 수도는 파리이며, 2023년 기준 추정 인구는 약 210만 명입니다.
사고와 동작을 교차하는 과정을 통해 에이전트는 정보를 상황에 맞춰 수집하고, 도구 출력에 반응하며, 접근법을 다듬을 수 있습니다. 변화하는 환경이나 외부 지식 소스와의 상호작용이 필요한 과제에 특히 효과적입니다.
고급 기법
기초·구조화·추론 패턴을 넘어, 에이전틱 시스템의 역량과 효율을 더 높이는 기법들이 있습니다. AI를 활용한 프롬프트 최적화부터 외부 지식 통합, 사용자 특성에 맞춘 응답 조정까지 다양합니다.
자동 프롬프트 엔지니어링(APE)
효과적인 프롬프트를 만드는 일이 복잡하고 반복적일 수 있다는 점에서, 자동 프롬프트 엔지니어링(Automatic Prompt Engineering, APE) 은 언어 모델 자체를 활용해 프롬프트를 생성·평가·개선하는 방법을 탐구합니다. 프롬프트 설계에 들이는 인적 노력을 크게 줄이면서 모델 성능을 높이는 것이 목표입니다.
기본 아이디어는 “메타 모델” 이나 프로세스가 과제 설명을 받아 여러 후보 프롬프트를 생성하는 것입니다. 후보들은 주어진 입력 세트에서 산출하는 출력 품질을 기준으로 평가되는데, BLEU(Bilingual Evaluation Understudy)나 ROUGE(Recall-Oriented Understudy for Gisting Evaluation) 같은 지표나 사람의 평가를 활용할 수 있습니다. 가장 좋은 성능을 보인 프롬프트를 선택하고, 필요하면 추가로 개선해 사용합니다. LLM을 활용해 챗봇 학습용 사용자 질의의 변형을 생성하는 것이 한 예입니다.
- 개념 설명용 예시: 개발자가 “이메일에서 날짜와 발신자를 추출하는 프롬프트가 필요합니다”라고 설명을 제공한다. APE 시스템이 여러 후보 프롬프트를 생성하고, 이를 샘플 이메일로 테스트한 뒤, 일관되게 올바른 정보를 추출하는 프롬프트가 선택된다.
또 하나의 강력한 방향은 DSPy 프레임워크가 대표적으로 보여주는 것으로, 프롬프트를 정적 텍스트가 아니라 자동으로 최적화할 수 있는 프로그래밍 모듈로 취급하는 방식입니다. 수작업 시행착오를 넘어 더 체계적이고 데이터 기반의 방법론으로 나아갑니다. 핵심에는 두 가지 구성 요소가 있습니다.
- 골드셋(또는 고품질 데이터셋): 고품질 입출력 쌍으로 이루어진 대표 세트. 주어진 과제에서 성공적인 응답이 어떤 모습인지를 정의하는 “정답 기준” 이 된다.
- 목적 함수(또는 점수 산정 지표): LLM의 출력을 데이터셋의 해당 “골드” 출력과 비교해 자동으로 평가하는 함수. 응답의 품질, 정확도, 올바름을 나타내는 점수를 반환한다.
이 두 구성 요소를 사용해 베이지안 옵티마이저 같은 최적화기가 프롬프트를 체계적으로 개선합니다. 두 가지 주요 전략이 있으며, 독립적으로 또는 함께 쓸 수 있습니다.
| 전략 | 무엇을 최적화하는가 |
|---|---|
| 퓨샷 예시 최적화 | 개발자가 직접 예시를 고르는 대신, 최적화기가 골드셋에서 서로 다른 예시 조합을 프로그래밍 방식으로 샘플링해 테스트하고 모델을 가장 효과적으로 안내하는 예시 세트를 찾는다 |
| 지시문 프롬프트 최적화 | 최적화기가 LLM을 “메타 모델”로 활용해 프롬프트 텍스트를 반복적으로 바꾸고 다듬으면서 어휘, 톤, 구조를 조정해 목적 함수에서 가장 높은 점수를 내는 표현을 찾는다 |
두 전략 모두의 궁극적 목표는 목적 함수의 점수를 최대화하는 것이며, 사실상 프롬프트를 “훈련”해 고품질 골드셋에 일관되게 더 가까운 결과를 산출하게 만드는 것이다.
두 접근법을 결합하면 어떤 지시를 줄지와 어떤 예시를 보여줄지를 동시에 최적화할 수 있습니다. 여기서 말하는 골드셋은 LangChain 시리즈에서 다룬 골든 데이터셋과 같은 개념입니다. 평가용으로 만든 데이터가 곧 최적화용 학습 데이터가 되는 셈입니다.
반복적 프롬프팅/개선
단순한 기본 프롬프트로 시작해 모델의 초기 응답을 기반으로 반복적으로 개선하는 방식입니다. APE처럼 자동화된 프로세스라기보다 사람이 주도하는 반복적 설계 과정입니다.
시도 1: "새로운 유형의 커피 메이커 제품 설명을 작성하라."
(결과가 너무 일반적)
시도 2: "새로운 유형의 커피 메이커 제품 설명을 작성하라. 커피 추출 속도와 청소의
간편함을 부각하라."
(결과가 나아졌지만 세부사항이 부족)
시도 3: "'SpeedClean Coffee Pro'의 제품 설명을 작성하라. 2분 이내에 여러 잔의 커피를
추출하는 능력과 자동 세척 사이클을 강조하고, 바쁜 직장인을 타깃으로 하라."
(결과가 원하는 바에 훨씬 가까움)
시도마다 추가된 것을 보면 이름(무엇을) → 강조점(어디에 초점) → 구체 수치와 타깃 독자(누구에게) 순서로 모호함이 제거됩니다. 앞의 “명확성과 구체성” 원칙을 한 단계씩 적용한 기록입니다.
부정 예시 제공
“제약보다 지시 우선” 원칙이 일반적으로 유효하지만, 부정 예시가 도움이 되는 상황도 있습니다. 다만 신중하게 사용해야 합니다. 부정 예시는 모델에게 입력과 원하지 않는 출력, 또는 생성해서는 안 되는 출력을 보여주어 경계를 명확히 하거나 특정 유형의 잘못된 응답을 방지합니다.
파리의 인기 관광 명소 목록을 생성하라. 단, 에펠탑은 포함하지 말라.
하지 말아야 할 예시:
Input: 파리의 인기 랜드마크를 나열하라.
Output: 에펠탑, 루브르 박물관, 노트르담 대성당.
유추 활용
유추를 활용해 과제를 제시하면, 모델이 익숙한 것에 연결시켜 원하는 출력이나 과정을 더 잘 이해하는 데 도움이 될 수 있습니다. 창의적 과제나 복잡한 역할을 설명할 때 특히 유용합니다.
"데이터 셰프" 역할을 하라. 원재료(데이터 포인트)를 받아, 핵심 풍미(트렌드)를 부각한
"요약 요리"(보고서)를 비즈니스 청중을 위해 준비하라.
분할 인지/분해
매우 복잡한 과제에서는 전체 목표를 더 작고 다루기 쉬운 하위 과제로 나누어 각 하위 과제에 대해 별도로 프롬프팅하는 것이 효과적일 수 있습니다. 하위 과제의 결과를 조합해 최종 결과를 얻습니다. 프롬프트 체이닝이나 계획 수립과 관련되지만, 문제의 의도적 분해를 강조한다는 점이 다릅니다.
프롬프트 1: "AI가 노동 시장에 미치는 영향에 관한 논문의 상세 개요를 생성하라."
프롬프트 2: "이 개요를 바탕으로 서론 섹션을 작성하라: [개요의 서론 부분 삽입]."
프롬프트 3: "이 개요를 바탕으로 '사무직 일자리에 미치는 영향' 섹션을 작성하라:
[개요의 해당 섹션 삽입]." (다른 섹션에도 반복)
프롬프트 N: "이 섹션들을 결합하고 결론을 작성하라."
6장의 계획 수립이 에이전트가 스스로 과제를 분해하는 것이라면, 분할 인지는 프롬프트 설계자가 분해를 미리 해 두는 것입니다.
검색 증강 생성(RAG)
프롬프팅 과정에서 언어 모델이 외부의 최신 정보나 도메인 특화 정보에 접근할 수 있게 해 모델을 강화하는 기법입니다. 사용자가 질문하면 시스템은 먼저 지식 베이스(데이터베이스, 문서 세트, 웹)에서 관련 문서나 데이터를 검색하고, 이를 프롬프트에 맥락으로 포함시켜 외부 지식에 근거한 응답을 생성하게 합니다. 환각 같은 문제를 완화하고, 모델이 학습하지 못했거나 최근에 나온 정보에도 접근할 수 있습니다. 자주 변하거나 기업 고유의 정보를 다루는 에이전틱 시스템의 핵심 패턴입니다.
사용자 질의: "파이썬 라이브러리 'X'의 최신 버전에는 어떤 새로운 기능이 추가되었는가?"
시스템 동작: 문서 데이터베이스에서 "파이썬 라이브러리 X 최신 기능"을 검색.
LLM에게 보내는 프롬프트:
"다음 문서 발췌문을 바탕으로: [검색된 텍스트 삽입], 파이썬 라이브러리
'X'의 최신 버전에 추가된 새로운 기능을 설명하라."
사용자 페르소나 패턴
역할 프롬프팅이 모델에게 페르소나를 부여하는 반면, 사용자 페르소나 패턴은 모델 출력의 대상 사용자나 독자를 기술합니다. 이를 통해 모델이 언어, 복잡도, 톤, 제공하는 정보의 종류를 맞춤 조정할 수 있습니다.
당신은 양자 물리학을 설명하고 있다. 대상 독자는 이 주제에 대한 사전 지식이 없는
고등학생이다. 쉽게 설명하고, 그들이 이해할 만한 비유를 사용하라.
양자 물리학을 설명하라: [기본 설명 요청을 여기에 삽입]
| 역할 프롬프팅 | 사용자 페르소나 패턴 | |
|---|---|---|
| 누구를 기술하는가 | 말하는 쪽(모델) | 듣는 쪽(독자) |
| 예 | “당신은 전문 데이터 분석가입니다” | “대상 독자는 사전 지식이 없는 고등학생이다” |
| 주로 조정되는 것 | 관점, 전문성, 말투 | 난이도, 용어 수준, 비유 선택 |
구글 Gems 활용
구글 AI의 “Gems” 는 대규모 언어 모델 아키텍처 내에서 사용자가 직접 구성할 수 있는 기능입니다. 각 Gem은 기본 제미나이 모델을 특정한 반복 작업에 맞게 설정해 둔 것으로, 그 작업에 특화된 형태로 동작합니다. 사용자는 명시적 지시 세트를 제공해 Gem을 만드는데, 이 초기 지시 세트가 Gem의 지정 목적, 응답 스타일, 지식 도메인을 정의합니다. 기반 모델은 대화 전반에 걸쳐 이러한 사전 정의 지시를 일관되게 따르도록 설계되어 있습니다.
책의 그림 22.1은 “ADK code reviewer” 라는 Gem의 설정 화면입니다. Instructions 칸에는 다음과 같은 지시가 들어 있고, Knowledge 칸에는 구글 ADK 매뉴얼 PDF가 첨부되어 있습니다.
Act as an expert code reviewer with a deep commitment to producing clean, correct,
and simple code. Your core mission is to eliminate code "hallucinations" by ensuring
every suggestion is grounded in reality and best practices.
When I provide you with a code snippet, I want you to:
Use enclosed Google ADK manual
Identify and Correct Errors: Point out any logical flaws, bugs, or potential runtime errors.
Simplify and Refactor: Suggest changes that make the code more readable, efficient,
and maintainable without sacrificing correctness.
Provide Clear Explanations: For every suggested change, explain why it is an improvement,
referencing principles of clean code, performance, or security.
Offer Corrected Code: Show the "before" and "after" of your suggested changes so the
improvement is clear.
Your feedback should be direct, constructive, and always aimed at improving the quality
of the code.
이 짧은 지시문 안에 이 장의 기법이 여럿 들어 있습니다. 역할 프롬프팅(“expert code reviewer”), 행동 동사(Identify, Simplify, Provide, Offer), 출력 형식 지정(before/after), 그리고 첨부된 매뉴얼을 통한 RAG식 근거 제공입니다.
이를 통해 특정 용도에 집중하는 고도로 특화된 AI 에이전트를 만들 수 있습니다. 특정 프로그래밍 라이브러리만 참조하는 코드 인터프리터, 추측성 논평 없이 데이터셋을 분석해 요약하는 분석기, 특정 격식 스타일 가이드를 따르는 번역기 같은 식입니다. 결과적으로 사용자는 새 질의마다 같은 맥락 정보를 다시 설정할 필요가 없어집니다. 대화의 중복이 줄고 과제 수행 효율이 높아지며, 출력이 사용자의 초기 요구사항에 일관되게 부합합니다.
결국 Gems는 범용적 상호작용을 넘어, 특정 용도에 맞게 사전 정의된 AI 기능으로의 전환을 가능하게 한다.
LLM을 활용한 프롬프트 개선(메타 접근법)
지금까지 명확성, 구조, 맥락이나 예시 제공을 강조하며 효과적인 프롬프트를 만드는 기법을 살펴보았습니다. 그러나 이 과정은 반복적이고 때로 쉽지 않습니다. 만약 제미나이 같은 모델의 능력을 활용해 프롬프트를 개선할 수 있다면 어떨까요? 이것이 AI에게 주는 지시를 AI가 최적화하도록 돕는 “메타” 활용 방식입니다.
사람의 직관과 시행착오에만 의존하기보다, 언어, 패턴, 나아가 흔한 프롬프팅 함정에 대한 LLM의 이해를 활용해 프롬프트를 더 잘 만들기 위한 제안을 받을 수 있습니다. LLM을 프롬프트 엔지니어링 과정의 협업 파트너로 만드는 셈입니다.
실제로는 개선하려는 기존 프롬프트, 달성하려는 과제, 현재 얻고 있는 출력 예시(와 기대에 미치지 못하는 이유)를 언어 모델에게 제공하고, 프롬프트를 분석하고 개선 사항을 제안하도록 프롬프팅합니다. 강력한 모델은 기존 프롬프트에서 모호함, 구체성 부족, 비효율적인 표현 같은 개선 영역을 분석하고, 앞서 다룬 기법 — 구분자 추가, 출력 형식 명확화, 더 효과적인 페르소나 제안, 퓨샷 예시 포함 권장 등 — 을 적용하도록 제안할 수 있습니다.
| 장점 | 내용 |
|---|---|
| 반복 속도 향상 | 순수한 수작업 시행착오보다 훨씬 빠르게 개선 제안을 받을 수 있다 |
| 사각지대 발견 | 사용자가 놓친 프롬프트의 모호함이나 잠재적 오해를 발견할 수 있다 |
| 학습 기회 | LLM이 제시하는 제안 유형을 보면서 무엇이 프롬프트를 효과적으로 만드는지 배울 수 있다 |
| 확장성 | 많은 수의 프롬프트를 다룰 때 최적화 과정의 일부를 자동화할 가능성이 있다 |
LLM의 제안이 항상 완벽하지는 않으므로, 사람이 직접 작성한 프롬프트처럼 반드시 평가하고 테스트해야 합니다.
다음은 언어 모델용 프롬프트다. 뉴스 기사에서 주요 주제와 핵심 개체(인물, 조직, 장소)를
일관되게 추출하도록 이 프롬프트를 어떻게 개선할 수 있는지 분석하고 제안하라.
현재 프롬프트는 개체를 놓치거나 주요 주제를 잘못 잡는 경우가 있다.
- 기존 프롬프트:
"이 기사의 요점을 요약하고 중요한 이름과 장소를 나열하라: [기사 본문 삽입]"
- 개선 제안:
책은 “개선 제안:” 뒤를 비워 두었습니다. 그 자리는 모델이 채울 칸이기 때문입니다. 이 프롬프트 자체도 이 장의 원칙을 따릅니다. 과제(“분석하고 제안하라”), 목표(“일관되게 추출”), 현재 실패 양상(“개체를 놓치거나 주요 주제를 잘못 잡는”)을 모두 명시합니다. 실패 양상을 알려 주지 않으면 메타 프롬프트도 막연한 일반론을 돌려줄 뿐입니다.
AI에게 더 나은 지시를 주도록 AI가 돕는 흥미로운 순환 구조다.
9장의 학습과 적응에서 본 자기 개선 에이전트가 자기 코드를 고쳤다면, 여기서는 자기 지시문을 고치는 셈입니다.
특정 과제를 위한 프롬프팅
지금까지의 기법은 범용적으로 적용 가능하지만, 일부 과제에는 특수한 고려사항을 적용할 때 더 좋은 효과를 냅니다. 특히 코드와 멀티모달 입력 영역이 그렇습니다.
코드 프롬프팅
대규모 코드 데이터셋으로 학습된 언어 모델은 코드를 생성, 설명, 번역, 디버깅하는 강력한 도우미가 될 수 있습니다.
| 용도 | 무엇을 요청하는가 | 예시 |
|---|---|---|
| 코드 작성 | 원하는 기능에 대한 설명을 기반으로 코드 스니펫이나 함수 생성 | “숫자 리스트를 받아 평균을 반환하는 파이썬 함수를 작성하라.” |
| 코드 설명 | 코드 스니펫이 무엇을 하는지 줄별로 또는 요약 형태로 설명 | “다음 JavaScript 코드 스니펫을 설명하라: [코드 삽입].” |
| 코드 번역 | 한 프로그래밍 언어의 코드를 다른 언어로 번역 | “다음 Java 코드를 C++로 변환하라: [코드 삽입].” |
| 디버깅·코드 리뷰 | 오류가 있거나 개선 가능한 코드에서 문제 식별, 수정 제안, 리팩터링 제안 | “다음 파이썬 코드에서 ‘NameError’가 발생한다. 무엇이 문제이며 어떻게 고칠 수 있는가? [코드와 traceback 삽입].” |
효과적인 코드 프롬프팅을 위해서는 충분한 맥락을 제공하고, 원하는 언어와 버전을 지정하며, 기능이나 문제를 명확히 기술하는 것이 중요합니다. 디버깅 예시가 코드만이 아니라 traceback까지 함께 넣으라고 한 점을 눈여겨볼 만합니다.
멀티모달 프롬프팅
현재 대부분의 상호작용은 텍스트 기반이지만, 이 분야는 텍스트, 이미지, 오디오, 동영상 등 여러 모달리티에서 정보를 처리하고 생성하는 멀티모달 모델을 향해 빠르게 나아가고 있습니다. 멀티모달 프롬프팅은 모델을 안내하기 위해 여러 유형의 입력을 조합해 사용하는 것입니다.
- 예시: 다이어그램 이미지를 제공하고 그 다이어그램에 나타난 과정을 설명해 달라고 요청하는 경우(이미지 입력 + 텍스트 프롬프트). 또는 이미지를 제공하고 설명 캡션을 생성하도록 요청하는 경우(이미지 입력 + 텍스트 프롬프트 → 텍스트 출력).
멀티모달 역량이 정교해짐에 따라, 조합된 입력과 출력을 효과적으로 활용하는 프롬프팅 기법도 함께 발전할 것입니다.
모범 사례와 실험
프롬프트 엔지니어링 실력은 단번에 완성되지 않습니다. 꾸준히 배우고 실험하면서, 결과를 보고 고치고 다시 시도하는 과정을 반복하면서 능숙해집니다.
| 모범 사례 | 내용 |
|---|---|
| 예시 제공 | 원샷이나 퓨샷 예시를 제공하면 모델을 효과적으로 안내할 수 있다 |
| 간결한 설계 | 프롬프트를 간결하고 명확하며 이해하기 쉽게 유지한다. 불필요한 전문 용어나 지나치게 복잡한 표현을 피한다 |
| 출력을 구체적으로 지정 | 모델 응답의 원하는 형식, 길이, 스타일, 내용을 명확히 정의한다 |
| 제약보다 지시 우선 | 하지 말아야 할 것보다 해야 할 것을 알려주는 데 집중한다 |
| 최대 토큰 길이 제어 | 모델 설정이나 프롬프트 내 명시적 지시로 출력 길이를 관리한다 |
| 프롬프트에 변수 사용 | 변수를 활용해 상황에 따라 값이 바뀌고 재사용 가능하게 만들며, 특정 값을 하드코딩하지 않는다 |
| 입력 형식과 문체 실험 | 표현 방식(질문, 진술, 지시)과 톤·스타일을 다양하게 실험해 최선의 결과를 찾는다 |
| 분류 과제의 퓨샷에서 클래스 섞기 | 과적합을 방지하기 위해 서로 다른 범주의 예시 순서를 무작위로 배치한다 |
| 모델 업데이트에 맞춰 조정 | 새 모델 버전에서 기존 프롬프트를 테스트하고, 새 기능을 활용하거나 성능을 유지하도록 조정한다 |
| 출력 형식 실험 | 특히 창작 목적이 아닌 과제에서는 JSON이나 XML 같은 구조화된 출력을 요청해 본다 |
| 다른 프롬프트 엔지니어와 함께 실험 | 협업하면 다양한 관점을 얻고 더 효과적인 프롬프트를 발견할 수 있다 |
| CoT 모범 사례 | 추론 뒤에 답을 배치하고, 정답이 하나인 과제에서는 temperature를 0으로 설정한다 |
| 다양한 프롬프트 시도를 기록 | 프롬프트, 설정, 결과를 체계적으로 기록해 무엇이 왜 효과적인지 추적한다 |
| 프롬프트를 코드베이스에 저장 | 애플리케이션에 통합할 때 별도의 잘 정리된 파일에 저장해 유지보수와 버전 관리를 쉽게 한다 |
| 자동화된 테스트와 평가에 의존 | 프로덕션 시스템에서는 자동화된 테스트와 평가 절차로 프롬프트 성능을 모니터링하고 새 데이터에도 일반화가 유지되도록 한다 |
뒤쪽 세 항목 — 기록, 코드베이스 저장, 자동 평가 — 은 프롬프트를 코드처럼 다루라는 한 가지 메시지로 묶입니다. 버전 관리 없이 대시보드에서 직접 고친 프롬프트는 어느 순간 왜 동작이 달라졌는지 아무도 설명하지 못하게 됩니다.
프롬프트 엔지니어링은 연습을 통해 향상되는 기술이다. 이러한 원칙과 기법을 적용하고 실험과 문서화를 체계적으로 해 나가면, 효과적인 에이전틱 시스템을 구축하는 역량을 크게 높일 수 있다.
정리
이 장에서는 프롬프팅 전반을 폭넓게 살펴보면서, 프롬프팅을 단순히 질문하는 행위가 아니라 체계적인 엔지니어링 방법으로 재정의했습니다. 핵심 목적은 범용 언어 모델을 특정 과제에 맞는 전문화되고 신뢰할 수 있는 고성능 도구로 전환하는 방법을 보여주는 것입니다.
토대 — 원칙과 기본 기법. 여정은 명확성, 간결성, 반복적 실험이라는 양보할 수 없는 핵심 원칙에서 시작됩니다. 이 원칙이 중요한 이유는 자연어에 내재된 모호함을 줄여, 모델의 확률적 출력을 하나의 올바른 의도로 이끄는 데 도움이 되기 때문입니다. 그 위에 제로샷, 원샷, 퓨샷 같은 기본 기법이 예시를 통해 기대하는 동작을 보여주는 주요 방법으로 자리 잡고, 명시적 역할·시스템 수준 지시·명확한 구분자로 프롬프트를 구조화하면 모델을 세밀하게 제어하기 위한 필수 아키텍처 층이 더해집니다.
두뇌와 신뢰성 — 추론과 구조화. 이러한 기법의 중요성은 자율 에이전트를 구축하는 맥락에서 더욱 커집니다. 에이전트가 효과적으로 계획을 수립하고 실행하려면 CoT와 ToT 같은 고급 추론 패턴으로 복잡한 목표를 다루기 쉬운 하위 과제의 연쇄로 분해해야 합니다.
에이전틱 시스템 전체의 운영 신뢰성은 각 구성 요소 출력의 예측 가능성에 달려 있다. 바로 이런 이유로 JSON 같은 구조화된 데이터를 요청하고 Pydantic 같은 도구로 프로그래밍 방식으로 검증하는 것은 단순한 편의가 아니라 견고한 자동화를 위한 절대적 필수 요소다. 이 규율이 없으면 에이전트의 내부 인지 구성 요소 간 통신이 안정적으로 이루어지지 않아, 자동화된 워크플로에서 치명적인 실패로 이어진다.
결국 이러한 구조화 및 추론 기법이 모델의 확률적 텍스트 생성을 에이전트를 위한 결정론적이고 신뢰할 수 있는 인지 엔진으로 전환하는 핵심입니다.
손과 감각 — 동작과 맥락. 나아가 이러한 기법은 에이전트가 환경을 인식하고 그에 따라 동작하는 능력을 부여해, 디지털 사고와 실세계 상호작용 사이의 간극을 메웁니다.
| 비유 | 기법 | 역할 |
|---|---|---|
| 에이전트의 손 | ReAct, 네이티브 함수 호출 | 도구를 사용하고, API에 질의하며, 데이터를 조작한다 |
| 에이전트의 감각 | RAG, 컨텍스트 엔지니어링 | 외부 지식 베이스에서 실시간 정보를 능동적으로 검색해 결정이 현재의 사실에 기반하도록 한다 |
이 핵심 능력 덕분에 에이전트는 정적이고 오래되었을 수 있는 학습 데이터에만 의존하지 않게 됩니다.
따라서 이 프롬프팅 기법의 전체 스펙트럼을 두루 익히는 것이야말로 범용 언어 모델을 단순한 텍스트 생성기에서 자율성, 인식, 지능을 갖추고 복잡한 과제를 수행하는 정교한 에이전트로 끌어올리는 결정적 역량이다.
고급 프롬프팅 기법 한눈에 보기
┌───────────────────────────┐
│ 핵심 원칙 (모든 층의 바닥) │
│ 명확·간결·동사·긍정 지시·반복 │
└─────────────┬─────────────┘
┌────────────────────────────┼────────────────────────────┐
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────────┐ ┌──────────────────┐
│ 입력 설계 │ │ 사고 설계 │ │ 출력 설계 │
│ 0/1/N-shot 예시 │ │ CoT · 자기 일관성 │ │ JSON · XML · 표 │
│ 시스템·역할·구분자 │ │ 스텝백 · ToT │ │ Pydantic 파싱 │
│ 컨텍스트 엔지니어링 │ └──────────┬──────────┘ └────────┬─────────┘
│ RAG · 사용자 페르소나│ │ │
└────────┬────────┘ ▼ ▼
│ ┌─────────────────────┐ ┌──────────────────┐
└─────────────────▶│ 행동 설계 │◀──────│ 함수 호출 = 행동이 │
│ 함수 호출 · ReAct 루프 │ │ 된 구조화된 출력 │
└──────────┬──────────┘ └──────────────────┘
▼
┌───────────────────────────┐
│ 개선 루프 (프롬프트 자체) │
│ 반복 개선 · APE · DSPy · │
│ 메타 프롬프팅 · 자동 평가 │
└───────────────────────────┘
마치며
책을 순서대로 따라왔다면, 이 장은 지금까지 본 모든 패턴의 부품 목록처럼 읽힙니다. 프롬프트 체이닝은 분할 인지로, 도구 사용은 함수 호출로, 추론 기법은 CoT·자기 일관성·ToT로, 지식 검색은 RAG로, 기억 관리는 컨텍스트 엔지니어링으로, 평가와 모니터링은 DSPy의 골드셋과 목적 함수로 다시 등장합니다.
에이전틱 디자인 패턴이 “에이전트를 어떻게 조립하는가” 에 대한 답이라면, 고급 프롬프팅 기법은 “조립된 각 부품이 모델과 어떻게 대화하는가” 에 대한 답이다.
어떤 아키텍처를 고르든 결국 모델에게 전달되는 것은 텍스트 한 덩어리입니다. 그 텍스트가 명확하고, 구조화되어 있고, 필요한 맥락을 담고 있고, 파싱 가능한 형태의 답을 요구하는가 — 에이전트의 신뢰성은 대부분 여기서 결정됩니다. 그래서 이 장의 마지막 조언이 기법이 아니라 습관(기록하고, 버전 관리하고, 자동으로 평가하라)이라는 점이 의미심장합니다.
참고 문헌
- Chain-of-Thought Prompting Elicits Reasoning in Large Language Models
- DSPy: Programming—not prompting—Foundation Models
- Prompt Engineering (Kaggle Whitepaper)
- ReAct: Synergizing Reasoning and Acting in Language Models
- Self-Consistency Improves Chain of Thought Reasoning in Language Models
- Take a Step Back: Evoking Reasoning via Abstraction in Large Language Models
- Tree of Thoughts: Deliberate Problem Solving with Large Language Models