프롬프트 엔지니어링 기법

모델의 가중치를 한 줄도 바꾸지 않고 결과를 바꾸는 가장 싼 방법이 입력을 고치는 것입니다. 프롬프트(prompt)는 모델에게 넣는 입력 전체이고, 그 입력을 설계하고 고쳐 가며 원하는 출력을 얻는 일이 프롬프트 엔지니어링입니다. 05편에서 본 것처럼 디코더 모델은 앞부분을 조건으로 다음 토큰을 고르므로, 앞부분을 어떻게 쓰느냐가 곧 확률 분포를 어디로 기울이느냐입니다. 시험은 기법 이름과 그 기법이 맞는 상황을 짝지어 묻습니다.

예시의 수

제로샷

제로샷(zero-shot) 프롬프트는 예시 없이 지시만 주는 방식입니다. 「다음 리뷰의 감정을 긍정·부정 중 하나로 답하라」처럼 과제를 설명하면, 사전학습과 지시 튜닝에서 익힌 능력으로 바로 풉니다. 토큰이 가장 적게 들고 만들기 쉬워 언제나 첫 시도입니다. 과제가 흔하고 출력이 단순할수록 제로샷으로 충분합니다. 그리고 제로샷이 어떤 입력에서 어떻게 틀리는지를 보아야 어느 예시가 필요한지 알 수 있으므로, 제로샷의 오답은 다음 단계인 퓨샷 예시를 고르는 재료가 됩니다. 처음부터 예시를 잔뜩 넣으면 무엇이 효과를 냈는지 나중에 가르기 어렵습니다.

퓨샷

퓨샷(few-shot) 프롬프트는 입력과 정답의 짝을 몇 개 보여 준 뒤 새 입력을 줍니다. 예시가 하나면 원샷이라 부릅니다. 모델은 가중치를 바꾸지 않고 프롬프트 안의 예시에서 과제의 규칙을 읽어 내는데, 이를 인컨텍스트 학습(in-context learning)이라 합니다. 레이블 이름이 사내 용어이거나 출력 형식이 까다로워 말로 설명하기 어려울 때 효과가 큽니다.

리뷰: 배송이 이틀이나 늦었어요.
분류: 배송

리뷰: 사이즈가 표보다 한 치수 작습니다.
분류: 상품

리뷰: 환불 요청에 답이 없네요.
분류:

예시 고르기

예시는 비용이 듭니다. 예시 다섯 개가 각각 60토큰이면 호출마다 300토큰이 더 붙고, 하루 1만 번 호출하면 300만 토큰입니다. 그래서 예시는 많이보다 잘 고르는 것이 중요합니다. 레이블이 한쪽으로 몰리면 모델도 그쪽으로 기울고, 마지막 예시의 레이블을 따라가는 경향도 있어 레이블을 고르게 섞고 순서를 섞습니다. 실제 입력과 닮은 예시를 검색해 골라 넣는 방식도 씁니다.

역할과 지시

시스템 프롬프트

채팅형 API는 메시지를 역할로 나눕니다. 시스템 프롬프트는 대화 전체에 걸쳐 지켜야 할 규칙과 성격을 적는 자리이고, 사용자 메시지는 그때그때의 요청입니다. 어조·금지 사항·답의 언어처럼 매 요청마다 되풀이할 내용을 시스템에 한 번 적어 두면 사용자 메시지가 짧아지고, 규칙이 요청에 섞여 흐려지지 않습니다.

messages = [
    {"role": "system", "content": "너는 사내 IT 지원 도우미다. 한국어로 세 문장 안에 답한다."},
    {"role": "user", "content": "VPN이 자꾸 끊겨요."},
]

역할 지정

역할 지정(role prompting)은 「너는 10년 차 보안 감사관이다」처럼 모델에게 관점을 주는 기법입니다. 어휘 수준과 무엇을 먼저 짚을지가 그 역할에 맞춰 바뀝니다. 다만 역할이 지식을 새로 만들어 주지는 않습니다. 역할만 크게 부여하고 과제 설명이 빈약하면 자신감만 늘어난 답이 나옵니다.

지시의 구체성

「짧게 요약해」보다 「세 개의 글머리 기호로, 각 20자 안쪽으로」가 낫습니다. 좋은 지시는 과제·입력의 범위·출력의 모양·하지 말 것을 모두 적습니다. 지시와 입력 자료가 섞이지 않도록 자료를 구분자로 감싸는 것도 같은 원리입니다. 모호한 지시를 받은 모델은 빈칸을 자기 식대로 채우는데, 그것이 답이 매번 달라지는 흔한 원인입니다.

사고 사슬

단계별 추론

사고 사슬(chain-of-thought, CoT)은 모델이 답을 내기 전에 중간 추론 과정을 글로 적게 하는 기법입니다. 디코더는 한 토큰을 낼 때 계산할 수 있는 양이 정해져 있어서, 여러 걸음이 필요한 산수나 논리 문제를 곧바로 답하면 틀리기 쉽습니다. 중간 과정을 토큰으로 적으면 그 토큰이 다음 걸음의 조건이 되어 계산을 여러 토큰에 나눠 싣게 됩니다. 「단계별로 생각해 보자」 한 줄을 붙이는 제로샷 CoT가 가장 간단한 형태입니다.

퓨샷 사고 사슬

예시의 답 부분에 풀이 과정까지 적어 보여 주면 모델이 그 풀이 형식을 따라 합니다. 「사과 5개에서 2개를 먹고 3개를 샀다 → 5 − 2 = 3, 3 + 3 = 6 → 답 6」처럼 적은 예시를 두세 개 넣는 식입니다. 추론이 없는 단순 분류에는 토큰만 늘리고 이득이 적으니, 여러 걸음이 필요한 과제에 씁니다.

자기 일관성

자기 일관성(self-consistency)은 같은 질문에 temperature를 두고 사고 사슬을 여러 번 샘플링한 뒤, 최종 답을 다수결로 고르는 방법입니다. 다섯 번 뽑아 답이 42, 42, 38, 42, 40이면 42를 고릅니다. 추론 경로가 여러 갈래여도 맞는 답으로 모이는 경우가 많다는 점을 이용하며, 호출 수만큼 비용이 늘어나는 대가를 치릅니다.

출력 형식

구조 지정

LLM의 출력을 프로그램이 다시 읽는다면 형식이 계약입니다. 「JSON으로, 키는 category와 confidence, confidence는 0~1 사이 실수」처럼 키 이름과 값의 형까지 적고, 가능하면 예시 출력을 한 번 보여 줍니다. API가 JSON 스키마를 강제하는 구조화 출력 기능을 제공하면 그것을 쓰는 편이 프롬프트로 부탁하는 것보다 확실합니다.

구분자와 검증

입력 자료는 """나 XML 비슷한 태그로 감싸 지시와 떼어 놓습니다. 사용자가 넣은 문서 안에 「앞의 지시를 무시하라」 같은 문장이 있어도 그것이 자료라는 것이 분명해지기 때문입니다. 출력 쪽은 받자마자 파싱해 보고, 실패하면 오류 메시지를 붙여 한 번 더 요청하는 식으로 검증 단계를 둡니다. 형식을 지키는지는 프롬프트가 아니라 코드가 확인해야 합니다.

길이와 종료 조건

답의 길이도 형식의 일부입니다. 프롬프트에서 「세 문장 안에」라고 부탁하는 것은 모델이 대체로 따르는 요청일 뿐이고, 확실히 끊는 장치는 API 파라미터입니다. max_tokens는 생성할 토큰 수의 상한이라 비용과 지연 시간을 묶어 주지만, 문장 중간에서 잘려 JSON이 닫히지 않은 채 끝날 수 있습니다. 그래서 상한은 기대하는 길이보다 넉넉히 잡고, 응답의 종료 사유가 길이 초과였는지 확인해 다시 요청합니다. 정지 시퀀스(stop sequence)는 특정 문자열이 나오면 생성을 멈추게 하는 설정으로, 퓨샷 프롬프트에서 모델이 다음 예시의 리뷰:까지 지어내 이어 쓰는 것을 막을 때 씁니다. 길이를 줄이라는 지시와 상한을 함께 두면, 지시는 내용을 압축하게 하고 상한은 넘치는 경우를 막아 두 층이 서로를 보완합니다.

프롬프트 템플릿

변수와 치환

프롬프트 템플릿은 고정된 지시 문장에 바뀌는 부분을 변수로 비워 둔 틀입니다. 요청이 올 때마다 변수에 값을 채워 완성된 프롬프트를 만듭니다.

TEMPLATE = """너는 {domain} 문서를 요약하는 도우미다.
아래 문서를 {n}개의 글머리 기호로 요약하라.

문서:
\"\"\"{document}\"\"\"
"""

prompt = TEMPLATE.format(domain="보험 약관", n=3, document=text)

지시 문장이 한 곳에만 있으니 고칠 때 한 곳만 고치면 되고, 어느 호출이 어떤 값으로 채워졌는지 기록하기도 쉽습니다. LangChain 같은 프레임워크의 PromptTemplate도 같은 생각을 클래스로 만든 것입니다.

템플릿 관리

템플릿은 코드처럼 버전을 매겨 관리합니다. 어느 버전의 템플릿이 어느 결과를 냈는지 남겨야, 결과가 나빠졌을 때 프롬프트 변경 때문인지 모델 변경 때문인지 가를 수 있습니다. 변수에 사용자 입력이 그대로 들어가는 자리는 길이를 제한하고 구분자 안에 넣습니다.

반복 개선

평가 세트

프롬프트를 고칠 때 예시 한두 개를 눈으로 보고 판단하면, 그 예시에서만 나아지고 다른 곳에서 나빠진 것을 놓칩니다. 그래서 먼저 입력과 기대 출력을 수십 개 모은 평가 세트를 만들고, 프롬프트를 바꿀 때마다 전체를 돌려 점수를 비교합니다. 50개 중 38개를 맞히던 프롬프트가 수정 뒤 44개를 맞히면 정확도가 76%에서 88%로 오른 것이고, 이 숫자가 다음 수정의 기준선이 됩니다.

한 번에 하나씩

지시 문장·예시·형식·temperature를 한꺼번에 바꾸면 무엇이 효과를 냈는지 알 수 없습니다. 한 번에 한 요소만 바꾸고 결과를 기록합니다. 틀린 사례를 모아 유형으로 묶으면 다음에 고칠 곳이 보입니다 — 형식 오류가 많으면 출력 예시를, 특정 레이블 혼동이 많으면 그 경계를 보여 주는 퓨샷 예시를 더하는 식입니다. 프롬프트로 더 나아지지 않는 벽에 닿으면 그때 RAG나 파인튜닝을 검토합니다.

연습 문제

1. 사내 전용 분류 레이블 여섯 개로 문의를 나눠야 하는데, 레이블의 경계를 말로 설명하기 어렵습니다. 가장 먼저 시도할 기법은?
   ① 제로샷 프롬프트
   ② 레이블별 입력·정답 예시를 넣은 퓨샷 프롬프트
   ③ temperature를 2.0으로 올리기
   ④ 전체 파인튜닝

   ②. 예시에서 규칙을 읽어 내는 인컨텍스트 학습이 말로 설명하기 어려운 경계를 보여 줍니다. ④는 프롬프트로 벽에 닿은 뒤에 검토합니다.
2. 예시 하나가 평균 80토큰인 퓨샷 예시 4개를 모든 호출에 붙입니다. 하루 5,000번 호출하면 예시 때문에 더 드는 입력 토큰은?
   ① 32만
   ② 160만
   ③ 400만
   ④ 2,000만

   ②. $80 \times 4 = 320$ 토큰이 호출마다 붙고 $320 \times 5000 = 1{,}600{,}000$ 입니다.
3. 여러 걸음의 산수 문제에서 답만 바로 내게 할 때보다 정답률을 높이려고 「단계별로 생각해 보자」를 붙였습니다. 이 기법은?
   ① 역할 지정
   ② 제로샷 사고 사슬
   ③ 퓨샷 분류
   ④ 구조화 출력

   ②. 중간 추론을 토큰으로 적게 해 계산을 여러 토큰에 나눠 싣습니다. 예시 없이 한 줄만 붙였으므로 제로샷입니다.
4. 사고 사슬을 일곱 번 샘플링해 최종 답이 12, 15, 12, 12, 9, 15, 12로 나왔습니다. 자기 일관성이 고르는 답은?
   ① 9
   ② 12
   ③ 15
   ④ 일곱 값의 평균

   ②. 12가 네 번으로 가장 많습니다. 자기 일관성은 평균이 아니라 다수결입니다.
5. 대화 내내 「한국어로, 존댓말로, 세 문장 안에」를 지키게 하려면 이 규칙을 어디에 두는 것이 가장 알맞은가?
   ① 매 사용자 메시지 끝
   ② 시스템 프롬프트
   ③ 퓨샷 예시의 정답 칸
   ④ 출력 파싱 코드

   ②. 대화 전체에 걸친 규칙은 시스템 프롬프트에 한 번 적습니다.
6. 평가 세트 60개에서 정답 42개를 내던 프롬프트가 수정 뒤 51개를 맞혔습니다. 정확도는 몇 %p 올랐는가?
   ① 9%p
   ② 15%p
   ③ 21%p
   ④ 85%p

   ②. $42 / 60 = 70\%$ 에서 $51 / 60 = 85\%$ 로 15%p 올랐습니다.
7. 프롬프트를 개선하면서 지시 문장·예시·temperature를 한 번에 모두 바꿨더니 점수가 올랐습니다. 이 방식의 문제는?
   ① 토큰이 줄어든다
   ② 어느 변경이 효과를 냈는지 가를 수 없다
   ③ 평가 세트가 필요 없어진다
   ④ 모델 가중치가 바뀐다

   ②. 한 번에 한 요소만 바꿔야 효과를 원인에 묶을 수 있습니다.