#프롬프트 엔지니어링

모델을 바꾸지 않고 입력만 설계해서 원하는 출력을 얻는 기술입니다. 파인튜닝과 달리 비용이 거의 들지 않고 즉시 실험할 수 있어, 대부분의 문제는 여기서 먼저 시도합니다.

#구성 요소

네 가지가 전부 필요한 건 아닙니다. 다만 결과가 기대와 다르면 넷 중 무엇이 빠졌는지 먼저 확인하는 게 빠릅니다.

#활용 예시

• 문장 요약
• 정보 추출
• 질의응답
• 텍스트 분류
• 대화
• 코드 생성
• 추론

#Best practices

OpenAI 공식 가이드의 8가지 권고입니다.

1. 최신 모델을 사용한다.
2. 프롬프트 앞부분에 지침을 두고 ### 또는 """ 로 지침과 맥락을 구분한다.
3. 원하는 맥락·결과·길이·형식·스타일을 구체적이고 자세하게 쓴다.
4. 원하는 출력 형식을 예시로 보여준다.
5. 제로샷 → 퓨샷 → (둘 다 안 되면) 파인튜닝 순으로 올라간다.
6. 두루뭉술하고("fluffy") 부정확한 표현을 줄인다.
7. 하지 말아야 할 것 대신 해야 할 것을 말한다.
8. (코드 생성) "선행 단어(leading words)"로 모델을 특정 패턴으로 유도한다.

6번과 7번이 실무에서 가장 자주 위반됩니다. "간결하게 써줘" 대신 "3문장 이내로 써줘", "존댓말 쓰지 마" 대신 "평서문으로 써줘" 가 훨씬 잘 먹힙니다.

#기법 (Techniques)

#기본

• Zero-shot
  • 예시 없이 지시만으로 작업을 시킵니다. 지시를 따르도록 튜닝된 요즘 모델은 상당수 작업을 제로샷으로 처리합니다. 항상 여기서 시작하세요.
• Few-shot
  • 프롬프트 안에 몇 개의 예시(데모)를 넣어 문맥 내 학습(in-context learning)을 유도합니다. 출력 형식을 맞추는 데 특히 효과적입니다.

#추론 강화

• Chain-of-Thought (CoT)
  • 복잡한 문제를 단계로 쪼개 풀게 해서 추론 정확도를 올립니다. ("Let's think step by step")
  • 예시

    다음 질문을 단계적으로 생각해서 답을 도출해줘.
    질문: 철수가 가지고 있는 사과가 10개이고, 그 중 3개를 친구에게 주었다. 남은 사과는 몇 개인가?
• Self-Consistency
  • 개념
    • 디코더에서 샘플링해 서로 다른 추론 경로를 여러 개 만듭니다. 경로마다 최종 답이 다를 수 있으므로, 답들을 모아 가장 일관된(빈도가 높은) 답을 채택합니다. 사람이 여러 방법으로 검산하는 것과 같은 발상입니다.
  • 핵심
    • 여러 경로로 추론한다.
    • 답안 중 빈도가 가장 높은 답을 출력한다.
  • 특징
    • 복잡한 추론의 정확도를 올린다.
    • 결과의 안정성을 높인다. 대신 호출 횟수만큼 비용이 곱해진다.
  • 예시

    다음 질문을 여러 번(다양한 샘플) 답한 뒤, 각 샘플의 최종 답을 모아 다수결로 최종답을 결정해줘.
    질문: 철수가 가지고 있는 사과가 10개이고, 그 중 3개를 친구에게 주었다. 남은 사과는 몇 개인가?
• Tree of Thoughts (ToT)
  • 개념
    • 하나의 질문에 대해 여러 개의 사고 흐름을 동시에 전개하고 그중 최적의 결과를 선택합니다. 결정 경로를 나무(tree)처럼 분기시켜 다양한 가능성을 탐색하게 합니다. Self-Consistency 가 "답만 모아 투표"라면, ToT 는 중간 단계마다 평가하고 가지치기합니다.
  • 예시

    이 문제를 해결할 수 있는 여러 접근 방식을 제시하고, 각 방법을 평가한 뒤 최적의 해결책을 추천해줘.
• Generated Knowledge Prompting
  • 개념
    • 답하기 전에 관련 지식을 먼저 생성하게 하고, 그 지식을 근거로 답하게 합니다. 모델이 이미 아는 것을 꺼내 쓰게 만드는 기법이라, 모델이 모르는 정보에는 효과가 없습니다.
  • 모르는 정보는 아래처럼 외부에서 넣어줘야 합니다 (→ RAG).
    • 실시간으로 바뀌는 정보 (주가, 스포츠 스코어 등)
    • 사내 정책, 계약서
    • 논문 등 전문 분야 자료
• Active-Prompt
  • 개념
    • CoT 예시를 아무거나 넣지 않고, 모델이 가장 헷갈려 하는(샘플 간 답이 갈리는) 질문을 골라 그것만 사람이 주석을 답니다. 적은 라벨링으로 큰 효과를 냅니다.

#에이전트 계열

여기서부터는 프롬프트 한 번으로 끝나지 않고 여러 번의 호출·도구 사용·상태가 얽힙니다. 사실상 에이전트의 구성 요소입니다.

• Prompt Chaining
  • 작업을 하위 작업으로 쪼개고, 한 프롬프트의 응답을 다음 프롬프트의 입력으로 넘깁니다. 각 단계가 단순해져 안정성과 성능이 올라가고, 어느 단계에서 틀렸는지 추적할 수 있습니다.
• ReAct (Reason + Act)
  • 추론(Thought)과 행동(Action)을 번갈아 하고 그 결과(Observation)를 다시 추론에 넣습니다. 오늘날 대부분의 도구 사용 에이전트가 이 구조입니다.
  • 예시

    질문: 대한민국의 2022년 1인당 GDP는 얼마였어?
    Thought → Action → Observation → Answer 순으로 단계별로 응답해줘.
• Retrieval Augmented Generation (RAG)
  • 외부 지식을 검색해 프롬프트에 붙여 답하게 합니다. → RAG 개요, RAG 프롬프트 샘플
• Program-Aided Language Models (PAL)
  • 모델이 답을 직접 계산하지 않고 코드를 작성하게 하고, 실행은 인터프리터에 맡깁니다. 계산·날짜 처리처럼 LLM 이 약한 영역을 확실하게 넘깁니다.
• Automatic Reasoning and Tool-use (ART)
  • 작업 라이브러리에서 비슷한 예시를 골라와, 추론 단계 중간에 도구 호출을 끼워 넣는 것을 자동화합니다.
• Automatic Prompt Engineer (APE)
  • 프롬프트를 사람이 쓰지 않고 LLM 이 후보를 생성·평가·선택하게 합니다. "Let's work this out in a step by step way to be sure we have the right answer" 가 이 방식으로 발굴된 문구입니다.
• Reflexion
  • AI 에이전트가 반성(reflection) 메커니즘으로 지속 학습·개선하게 하는 기술입니다. 실패한 시도를 스스로 언어로 되짚어 기억에 남기고, 다음 시도에서 그 기억을 참고합니다.
• Directional Stimulus Prompting
  • 작은 정책 모델이 힌트(키워드 등 "자극")를 만들어, 건드릴 수 없는 블랙박스 LLM 을 원하는 방향으로 유도합니다.

#Role — system / user / assistant

#OpenAI 공식 6대 전략

#1. 지시를 명확하게 (write clear instructions)

// 나쁜 예
회의록을 요약해줘
---
[회의록]

// 좋은 예
회의록을 한 문단으로 요약해줘. 그다음 발언자 목록과 각자의 요점을
Markdown 목록으로 작성해줘. 마지막으로 발언자가 제안한 후속 단계나
실행 항목을 나열해줘.
---
[회의록]

#2. 참고 자료를 제공한다 (provide reference text)

아래 삼중 따옴표 안의 글을 사용해서 질문에 답해줘.
글에서 답을 찾을 수 없으면 "답을 찾을 수 없습니다" 라고 답해줘.
---
"""문서 1"""
"""문서 2"""
"""문서 3"""

질문: [질문]

#3. 복잡한 작업을 단순한 하위 작업으로 쪼갠다 (split complex tasks into simpler subtasks)

- 의도 분류(classification)로 어떤 하위 작업을 탈지 먼저 정하게 한다
- 대화가 길어지는 애플리케이션에서는 이전 대화를 요약하거나 걸러낸다

#4. 모델에게 생각할 시간을 준다 (give the model time to "think")

먼저 문제의 해답을 직접 구하세요.
그다음 당신의 해답과 학생의 해답을 비교해서 학생의 답이 맞는지 평가하세요.
스스로 문제를 다 풀기 전에는 학생의 답이 맞는지 판단하지 마세요.

---

문제: XXX
학생의 해답: XXX

#5. 외부 도구를 활용한다 (use external tools)

// 예: 계산기
너는 계산기를 쓸 수 있는 어시스턴트다.
수학 계산이 필요하면 다음 형식을 사용해라:
계산: [수식]
예:
계산: 23 곱하기 47

#6. 변경을 체계적으로 테스트한다 (test changes systematically)

프롬프트 수정이나 전략을 확정할 때는 포괄적인 테스트를 정의하고 체계적으로 평가해야 합니다. 그래야 그 변경이 전체적으로 긍정적인 영향을 주는지 확인할 수 있습니다. 한두 개 예시로 좋아 보이는 프롬프트가 전체 데이터셋에서는 나빠지는 경우가 흔합니다. → 평가(Evaluation)

#프롬프트 인젝션

시스템 가드레일을 무시하게 만들어, 해서는 안 되는 말이나 행동을 하게 만드는 공격입니다.

#방지

• 안전 가드레일
• 명시적 금지
• 입력 유효성 검사 및 정제(sanitize)
• 이상 활동 감지
• 매개변수화 — 시스템 명령과 사용자 입력을 명확히 분리
• 아웃풋 필터링
• 동적 피드백 및 학습
• 내부 프롬프트 강화
• 최소 권한
• 상황·시나리오 기반 안내

위 목록은 전부 완화책이지 차단책이 아닙니다. 프롬프트는 울타리일 뿐이고, 실제 자물쇠는 권한입니다. 에이전트가 도구로 DB 를 지울 수 있다면 인젝션은 곧 데이터 삭제가 됩니다. → LangChain Step 06 — 도구 정의

#참고 자료

• IBM — 프롬프트 엔지니어링이란
• OpenAI — Best practices for prompt engineering with the OpenAI API
• OpenAI — Prompt engineering guide (6대 전략 원문)
• Prompt Engineering Guide (한국어)