이 글은 「AI 공부 지도 20부작」의 9편(B2) 입니다.
앞 편: B1 — AI Agent 는 뭐가 다른가
다음 편: B3 — Fine-tuning vs RAG vs Prompt — 언제 뭘 써야 하나
0. 들어가기 전에
F시리즈와 B1 까지 읽으신 분들이라면 이 문장은 이미 한 번은 보셨을 거예요.
저는 이 문장을 처음 봤을 때 머리로는 끄덕였지만, 실제로 Claude 창에 같은 질문을 말투만 바꿔서 넣었을 때 답이 완전히 달라지는 경험이 쌓이기 전까지는 이 문장이 제 몸에 붙지 않았어요. “뭐, 확률 예측이래.” 하고 넘겼거든요.
이번 편의 목표는 그 문장을 몸으로 잡게 만드는 거예요. 프롬프트 엔지니어링에 나오는 기법들 — Zero-shot, Few-shot, Chain-of-Thought, “Let’s think step by step” — 이 왜 먹히는지를 단 하나의 원리로 꿰어서 보여드리고 싶어요.
그 원리가 이 문장입니다.
프롬프트는 “LLM 이 다음 토큰을 확률로 뽑을 때 조건으로 삼는 모든 것” 이다.
프롬프트 엔지니어링의 모든 기법은 결국 이 조건부 확률을 원하는 방향으로 기울이는 기술 이에요. 저는 이 관점을 잡고 나서 프롬프트에 관한 책과 블로그 글을 읽을 때 흔들림이 확 줄었어요. “이 사람이 무슨 주문을 외우라는 건지” 가 아니라 “이 기법은 확률 분포의 어느 쪽을 당긴다는 건지” 가 보이기 시작하더라고요.
이 글을 다 읽으실 때쯤에는, 여러분도 같은 감각을 갖게 되시면 좋겠어요.
1. 같은 질문인데 답이 다르다 — 경험에서 시작
저는 이 얘기를 비유보다 진짜 있었던 일 로 시작하고 싶어요. Claude 나 ChatGPT 를 매일 쓰시는 분이라면 본인도 비슷한 경험이 있을 거예요.
어제 저는 CSV 파일을 하나 파이썬으로 읽을 일이 있어서, 평소처럼 Claude 에 이렇게 물었어요.
“파이썬으로 csv 읽어줘”
답이 이렇게 왔어요.
import csv
with open('file.csv', 'r') as f:
reader = csv.reader(f)
for row in reader:
print(row)
네 줄짜리 깔끔한 답. 충분해요. 그런데 제가 같은 Claude 창을, 같은 모델로, 질문만 이렇게 바꿨어요.
“10년차 파이썬 데이터 엔지니어라고 생각하고, csv 를 읽는 3가지 방법을 각 라이브러리 장단점과 실무 시나리오까지 포함해서 설명해줘.”
답이 확 바뀌었어요. csv 모듈, pandas.read_csv, polars.read_csv 세 가지가 나오고, 각각의 메모리 프로파일, 대용량 처리 시 주의점, 스키마 추론 동작, 심지어 파일 인코딩이 깨질 때의 대응까지 나왔어요. 저는 질문 말투를 바꿨을 뿐인데 답이 다섯 배쯤 길고, 다섯 배쯤 전문적이 된 거예요.
여기서 궁금한 게 있어요. 모델은 같은데 왜 답이 바뀌었을까요? Claude 의 “가중치” 는 두 질문 사이에 바뀐 적이 없어요. 그런데 출력은 완전히 다른 성격이 됐어요.
이걸 “Claude 가 똑똑해서 알아서 잘 대답한 거다” 라고만 이해하면, 프롬프트 엔지니어링은 영원히 “말을 예쁘게 하는 기술” 로 머물러요. 이 글의 나머지는 그 이상을 보여드리는 거예요.
2. LLM 은 조건부 확률기 — 그 조건이 바로 프롬프트
F시리즈에서 여러 번 했던 얘기를 한 번 더 압축해서 복습할게요.
LLM 은 아주 단순한 일 하나를 합니다.
“지금까지 본 토큰들을 조건으로, 다음에 올 가장 그럴듯한 토큰 하나” 를 확률 분포로 뽑는 것.
그게 전부예요. “안녕” 이라는 토큰 뒤에 “하세요”, “,”, “\n”, “?” 같은 후보 토큰들이 각자 몇 % 의 확률을 갖고 있고, 모델은 그 분포에서 하나를 골라서 출력합니다. 그리고 그 토큰까지 포함한 새로운 “지금까지 본 토큰들” 을 입력으로 또 다음 토큰을 뽑아요. 이걸 반복해서 긴 답변이 생성돼요.
여기서 중요한 건 “지금까지 본 토큰들” 이라는 부분입니다. 이게 곧 여러분이 넣은 프롬프트 예요.
- system prompt 에 쓰인 모든 문자
- user 로서 넣은 모든 문자
- 이전 턴의 대화 기록
- 툴 호출 결과나 파일 내용처럼 context 에 끼어든 모든 문자
이 모든 게 “지금까지 본 토큰들” 로 한 묶음이 돼서 모델에 들어가요. 그리고 모델은 그 묶음 전체를 조건 으로 다음 토큰의 확률 분포를 계산해요.
수식으로 쓰면 이래요 (수식 하나만 딱 보겠습니다).
P(다음 토큰 | 지금까지의 모든 토큰)
| 기호는 “조건부” 라는 뜻이에요. “지금까지의 모든 토큰” 이 주어진 상태에서, “다음 토큰” 이 무엇이 될지의 확률이라는 얘기죠. 이 한 줄이 LLM 이 하는 일의 전부예요.
자, 이제 프롬프트가 뭔지 한 번 더 정의해 볼게요.
프롬프트 = 이
P(다음 토큰 | 지금까지의 모든 토큰)의 조건부에 들어가는 “지금까지의 모든 토큰”.
프롬프트를 쓴다는 건 “조건” 을 짜는 행위 예요. 여러분이 “파이썬으로 csv 읽어줘” 라고 쓰는 순간, 모델은 이 11개 토큰 뒤에 따라올 확률이 높은 토큰들을 하나씩 뱉어요. 그 확률 분포가 어떻게 생겼느냐가 곧 여러분이 받게 될 답의 성격을 결정해요.
3. 그래서 프롬프트를 바꾸면 확률 분포 자체가 바뀐다
1 장에서 저는 같은 질문을 두 가지 말투로 넣었고 답이 완전히 달라졌다고 했어요. 이제 그 현상을 2 장의 프레임으로 다시 설명할 수 있어요.
“파이썬으로 csv 읽어줘” 라는 프롬프트 뒤에는, 학습 데이터 세상 어딘가에서 본 적 있는 초보용 튜토리얼 문체 가 따라올 확률이 높아요. Stack Overflow 에서 “초보자용 답변”, 블로그에서 “3분 완성 파이썬 팁”, Qiita 의 “새내기 엔지니어 1일차” 같은 글들이 학습 데이터에 잔뜩 있거든요. 모델은 이 프롬프트를 봤을 때 “아, 이 조건에서는 간단한 코드 스니펫이 다음으로 올 가능성이 제일 높구나” 라고 판단해요. 네 줄짜리 깔끔한 답은 그 확률 분포의 자연스러운 결과 예요.
반면 “10년차 파이썬 데이터 엔지니어라고 생각하고…” 라는 프롬프트 뒤에는 완전히 다른 텍스트가 따라올 확률이 높아져요. 학습 데이터에 있는 엔지니어링 블로그 글, 시니어 개발자의 Medium 포스트, 기술서 챕터 같은 텍스트의 확률이 올라가요. 거기에 “3가지 방법을 장단점과 함께” 가 더해지면, 비교·대조·실무 시나리오 가 포함된 문체의 확률이 또 올라가고요.
이렇게 프롬프트의 한 조각 한 조각이 확률 분포의 어떤 방향을 끌어올리고, 어떤 방향을 밀어내요. “10년차” 라는 단어 하나만으로도 “입문자용 설명” 의 확률은 낮아지고 “현업 용어와 함께 나오는 설명” 의 확률이 높아져요. “3가지 방법” 이라는 표현은 “한 가지 정답” 의 확률을 낮추고 “비교표 구조” 의 확률을 높여요.
제가 좋아하는 비유가 있어요. 프롬프트는 거대한 확률 지형 위에서 물이 어느 골짜기로 흘러가게 할지 방향을 트는 수로 같아요.
모델 안에는 학습 데이터에서 본 수많은 가능성이 거대한 지형처럼 펼쳐져 있어요. 어떤 골짜기는 “캐주얼한 튜토리얼”, 어떤 골짜기는 “학술적인 논문 해설”, 어떤 골짜기는 “시니어 엔지니어의 실무 조언” 이에요. 여러분이 프롬프트를 쓰는 순간, 수로가 그어지고 물이 특정 골짜기로 흘러요. 말투를 바꾸면 수로의 방향이 바뀌고, 물은 다른 골짜기로 가요. 같은 지형인데, 흘러나오는 물의 맛이 완전히 달라지는 거죠.
프롬프트 엔지니어링은 그러니까, 수로를 긋는 일 이에요. 물을 새로 만드는 게 아니고요.
4. Zero-shot, Few-shot, Chain-of-Thought — 세 전형 기법
이 관점으로 프롬프트 엔지니어링의 3대 기법을 다시 보면, 각 기법이 뭘 하는 건지 아주 명확해져요.
4-1. Zero-shot — 수로 없이 그냥 묻기
Zero-shot 은 예시 없이 그냥 지시만 주는 방식이에요.
“이 문장이 긍정인지 부정인지 알려줘: ‘오늘 날씨 정말 좋다.'”
이건 단순한 조건부예요. 모델은 “이런 질문 뒤에 ‘긍정/부정’ 이라는 라벨 한 단어가 오는 학습 데이터” 가 충분히 많다면 잘 답해요. 단순한 태스크에서는 zero-shot 으로도 충분합니다.
그런데 태스크가 조금만 복잡해지면 (예: 특정 포맷으로 JSON 을 뱉어달라, 특정 스타일로 번역해달라), zero-shot 의 확률 분포가 애매해져요. “이 지시 뒤에 뭘 출력하는 게 자연스러운가” 에 대해 모델이 확신을 못 가져요. 그럴 때 수로를 한 번 더 그어주는 게 Few-shot 이에요.
4-2. Few-shot — 예시로 수로의 방향을 보여주기
Few-shot 은 지시와 함께 예시를 몇 개 주는 방식이에요.
다음 문장의 감정을 라벨링해줘.
입력: "오늘 날씨 정말 좋다."
출력: 긍정
입력: "또 늦잠 잤어..."
출력: 부정
입력: "커피가 맛있네."
출력:
이걸 받았을 때 모델은 뭘 할까요. 단순히 “출력:” 뒤에 올 확률이 높은 토큰을 뱉으려고 해요. 그런데 이 프롬프트에는 이미 “입력: … / 출력: 라벨” 이라는 패턴이 두 번 반복돼 있어요. 조건부 확률 관점에서 보면, 이 패턴이 세 번째도 반복될 확률이 매우 높아진 상태예요. 모델은 거의 자동으로 “긍정” 이라는 토큰을 뱉어요.
Few-shot 의 원리는 이거예요. “이 프롬프트 문맥에서는 이런 스타일의 출력이 자연스럽다” 를 보여주면서 모델의 확률 분포를 예시의 패턴 쪽으로 확 기울이는 거예요.
재미있는 건, 모델은 예시를 “학습” 하는 게 아니에요. 가중치가 업데이트되는 게 아니고요. 그냥 지금 이 순간의 입력 문맥에서 패턴을 인식하고, 그 패턴이 반복될 확률을 높게 잡는 거예요. 이걸 in-context learning 이라고 부르는데, 이름만 learning 이지 진짜 학습은 아니에요. 문맥 내에서 일어나는 확률 조정이에요.
Few-shot 에서 예시의 순서와 선택이 성능에 크게 영향을 주는 이유도 여기 있어요. Zhao et al. (2021) 의 연구 “Calibrate Before Use: Improving Few-Shot Performance of Language Models” 는 예시 순서만 바꿔도 정확도가 54% 에서 93% 까지 흔들린다는 걸 보여줬어요. 모델이 예시의 확률 패턴에 얼마나 민감하게 반응하는지를 보여주는 결과죠.
4-3. Chain-of-Thought — 추론 과정 자체를 조건으로 넣기
Chain-of-Thought (이하 CoT) 는 2022년 Wei et al. 의 논문 “Chain-of-Thought Prompting Elicits Reasoning in Large Language Models” 에서 제안된 기법이에요. 핵심은 단순해요.
“답을 바로 내놓지 말고, 답에 도달하는 추론 과정을 먼저 쓰게 한다.”
예를 들어 이런 문제가 있다고 해봐요.
“철수는 사과 5개를 갖고 있다. 영희한테 2개를 주고, 민수한테 1개를 받았다. 철수는 지금 사과가 몇 개인가?”
Zero-shot 으로 “답만 말해줘” 라고 하면 모델이 가끔 5 개라고 잘못 답해요. 그런데 예시를 이렇게 주면 정확도가 올라가요.
문제: 민지는 연필 10자루를 갖고 있다. 지후에게 3자루를 주고, 선생님에게 5자루를 받았다. 민지는 지금 연필이 몇 자루인가?
풀이: 민지는 처음 10자루가 있다. 3자루를 줬으니 10-3=7자루. 5자루를 받았으니 7+5=12자루. 답은 12자루.
문제: 철수는 사과 5개를 갖고 있다. 영희한테 2개를 주고, 민수한테 1개를 받았다. 철수는 지금 사과가 몇 개인가?
풀이:
이제 모델은 “풀이:” 뒤에 계산 과정을 쓰는 것 이 자연스러운 문맥이라고 인식해요. 그래서 “철수는 처음 5개가 있다. 2개를 줬으니 5-2=3개. 1개를 받았으니 3+1=4개. 답은 4개.” 라고 답해요.
왜 이게 정확도를 올리는지 조건부 확률 관점에서 풀어볼게요.
정답만 뱉는 경우, 모델은 P(답 | 문제) 를 계산해요. 복잡한 문제에서는 이 확률이 여러 답 후보에 분산돼 있어요. 5, 4, 3, 6 다 비슷한 확률일 수 있어요.
그런데 추론 과정을 먼저 쓰면 계산이 이렇게 바뀌어요.
P(추론 과정 | 문제) × P(답 | 문제 + 추론 과정)
답을 뱉을 때 조건에 “추론 과정” 까지 포함돼요. 추론 과정이 “5-2=3, 3+1=4” 까지 쓰인 상태에서 그 뒤에 “답은 4” 가 올 확률은, 문제만 있을 때 “답은 4” 가 올 확률보다 훨씬 압도적이에요. 왜냐하면 학습 데이터에 있는 수학 풀이 텍스트들이 전부 이런 구조거든요. “계산이 이렇게 됐으니 답은 이거다” 라는 패턴이 무수히 많아요.
즉 CoT 는 “추론 과정을 출력으로 끌어내서, 그 과정을 답의 조건에 포함시키는 기법” 이에요. 모델이 “생각을 소리 내서 하게” 만드는 거죠. 이 소리 내서 한 생각이 다음 토큰 (정답) 의 확률 분포를 정답 쪽으로 크게 기울여요.
CoT 는 덧셈뺄셈 같은 단순한 문제에는 효과가 작아요. 원래 확률 분포가 이미 정답 쪽으로 충분히 기울어 있거든요. 그런데 다단계 추론이 필요한 수학 문제, 상식 추론, 논리 퍼즐 같은 태스크에서는 성능이 크게 올라가요. Wei et al. 의 원 논문에서는 GSM8K 라는 수학 벤치마크에서 PaLM 모델 기준 정확도가 17.9% 에서 58.1% 로 올라갔다고 보고됐어요. 약 3배예요. 단지 “풀이를 먼저 쓰게 했을 뿐” 인데요.
5. 시스템 프롬프트가 다른 이유 — 조건에 상수 하나를 고정하는 것
실무자라면 Claude·ChatGPT 의 API 나 Claude Code 를 쓰실 때 system prompt 라는 필드를 자주 만나실 거예요. “너는 10년차 엔지니어야” “너는 친절한 고객지원 봇이야” 같은 문장을 거기 넣으면, 그 뒤 대화 전체의 톤이 크게 달라져요.
왜 이게 먹힐까요. 이제는 답이 뻔하죠.
조건부 확률의 조건에 추가 토큰을 끼워 넣기 때문이에요.
system prompt 는 내부적으로 특별한 취급을 받긴 하지만, 근본적으로는 “지금까지 본 토큰들” 의 일부예요. 대화가 여러 턴 이어져도 system prompt 는 그 조건의 앞쪽에 계속 붙어 있어요. 그래서 모든 답이 그 조건부에 묶여서 생성돼요.
“너는 10년차 엔지니어야” 라는 조건이 붙으면, 그 뒤에 오는 모든 답은 “10년차 엔지니어가 쓴 것처럼 읽힐 확률이 높은 토큰” 들로 구성돼요. 비공식 말투가 줄어들고, 전문 용어가 늘어나고, 예외 케이스에 대한 언급이 많아져요. 모델이 “10년차” 라는 단어와 학습 데이터에서 함께 등장하던 문체·어휘·구조의 확률을 전부 끌어올리는 거예요.
이걸 페르소나 프롬프팅 이라고 부르기도 해요. 효과가 들쭉날쭉하다는 비판도 있어요 (Zheng et al. 2024 “When ‘A Helpful Assistant’ Is Not Really Helpful: Personas in System Prompts Do Not Improve Performances of Large Language Models” 참고). 페르소나 하나만 바꿔서 모든 태스크가 잘되게 만드는 건 어려워요. 다만 스타일·톤 조정 에는 확실히 효과가 있어요. 여러분이 “친절한 말투로 답해” 라고 쓰면, 그 조건 뒤에 정말로 친절한 말투의 확률이 올라가요.
system prompt 의 역할을 한 줄로 요약하면 이래요.
“모든 답의 조건에 공통으로 들어가는 상수를 고정하는 장치.”
user prompt 는 턴마다 바뀌지만 system prompt 는 고정돼요. 그래서 system prompt 는 “이 대화 전체의 기본 방향” 을 결정하는 수로를 파는 일이에요. user prompt 는 그 기본 수로 위에 작은 지류를 추가하는 일이고요.
Claude Code 같은 에이전트 도구를 뜯어보면, 내부 system prompt 가 수천 토큰에 달해요. “너는 유능한 코딩 어시스턴트다. 파일을 수정할 때는 이런 규칙을 지켜라. 권한이 필요한 명령은 이렇게 처리해라…” 같은 식으로 아주 촘촘한 조건이 박혀 있어요. 사용자는 “버그 고쳐” 한 줄만 치지만, 모델이 실제로 보는 조건은 수천 토큰이에요. 그 덕분에 모델이 일관된 방향으로 답을 생성할 수 있는 거예요.
6. “Let’s think step by step” — 단 한 줄이 벤치마크를 흔든 사건
프롬프트 엔지니어링 역사에서 가장 유명한 일화 하나를 소개할게요.
2022년 Kojima et al. 의 논문 “Large Language Models are Zero-Shot Reasoners” 가 나왔어요. 이 논문은 간단한 실험 하나를 했어요. CoT 의 효과는 이미 알려져 있었지만, 예시 없이 단 한 줄 만 프롬프트에 덧붙이면 어떻게 될까를 실험한 거예요.
그 한 줄이 이거예요.
“Let’s think step by step.”
“단계별로 생각해 보자.” 딱 이 다섯 단어가 답변 앞에 오도록 프롬프트를 짰어요. 예시는 하나도 안 줬고요 (그래서 “Zero-Shot CoT” 라고 불러요).
결과가 놀라웠어요. MultiArith 라는 수학 벤치마크에서 GPT-3 (InstructGPT) 모델의 정확도가 17.7% 에서 78.7% 로 뛰었어요. GSM8K 에서는 10.4% 에서 40.7% 로, AQuA 에서는 22.4% 에서 33.5% 로 올라갔어요.
단 한 줄 덧붙였는데 몇 배씩 성능이 뛰었어요. 많은 사람이 “이게 마법이야?” 라고 반응했죠.
마법은 아니에요. 이 글을 여기까지 읽으신 분이라면 이미 답을 아실 거예요.
“Let’s think step by step” 뒤에는 단계별로 추론하는 텍스트 가 올 확률이 압도적으로 높아요. 학습 데이터에 있는 교과서, 수학 풀이 블로그, 튜토리얼, Stack Overflow 답변들이 “단계적으로 생각해 보자” 같은 구절 뒤에 전부 번호를 붙인 풀이 나 차근차근 식을 전개하는 문단 을 뒀거든요. 모델은 이 한 줄을 조건에 추가하는 순간, “번호 붙은 풀이가 다음에 올 확률” 을 크게 끌어올려요. 그리고 풀이가 먼저 쓰이고 나면 (4 장에서 본 CoT 원리에 따라) 정답이 뒤에 나올 확률이 또 크게 올라가요.
즉 “Let’s think step by step” 은 CoT 의 예시를 주지 않고도 CoT 효과를 유도하는 촉발 문장 이에요. 예시는 없지만, 그 한 줄이 모델의 문체 분포를 “풀이 형식” 쪽으로 기울여요. 그 뒤는 자동이고요.
이 사건이 흥미로운 건, 확률 분포 기울이기가 얼마나 강력한지 를 극단적으로 보여줬기 때문이에요. 프롬프트의 다섯 단어가 벤치마크 점수를 네 배 이상 바꿨어요. 모델을 새로 학습시키지 않고요. 가중치도 그대로예요. 바뀐 건 조건에 들어간 텍스트 다섯 단어뿐이에요.
이후에 “Take a deep breath” “Let’s work this out step by step to be sure we have the right answer” 같은 변형들이 테스트됐고, 어떤 변형이 어느 모델에서 더 잘 먹히는지에 대한 연구가 계속 나왔어요. 재미있는 건 모델마다 먹히는 촉발 문구가 다르다 는 거예요. 이건 8장에서 다시 다룰게요.
7. 그래서 프롬프트 엔지니어링은 “문장 작법” 이 아니라 “확률 분포 기울이기”
지금까지의 이야기를 한 번에 엮으면 이렇게 돼요.
- LLM 은
P(다음 토큰 | 지금까지의 모든 토큰)을 계산하는 기계다. - 프롬프트는 이 조건부의 “조건” 에 해당한다.
- 프롬프트를 바꾸면 조건이 바뀌고, 조건이 바뀌면 확률 분포가 바뀐다.
- 확률 분포가 바뀌면 출력이 바뀐다.
Zero-shot 은 조건을 짧게 주는 것, Few-shot 은 패턴을 반복해서 보여주는 것, CoT 는 추론 과정을 조건에 포함시키는 것, system prompt 는 조건의 상수를 고정하는 것, “Let’s think step by step” 은 한 줄로 문체 분포를 이동시키는 것. 기법의 이름은 다 다르지만, 하는 일은 같은 축의 다른 버튼 이에요. 확률 분포를 원하는 방향으로 기울이는 거죠.
실무자로서 이 관점을 잡고 나면 바뀌는 것들이 있어요.
첫째, 프롬프트 책을 덜 외우게 돼요. 프롬프트 템플릿 “이걸 복붙하면 됩니다” 하고 공유되는 주문들이 많잖아요. 그런데 모델이 업데이트되거나 다른 모델로 옮기면 그게 그대로 먹히리라는 보장이 없어요. 확률 분포는 학습 데이터에 따라 달라지니까요. 원리를 잡고 있으면 “이 주문이 하려는 게 뭔데?” 를 분해할 수 있어서, 새 모델에서도 비슷한 효과를 내는 프롬프트를 스스로 짤 수 있어요.
둘째, 프롬프트가 실패했을 때 원인을 추적할 수 있어요. “왜 이 답이 나왔지?” 대신 “지금 내 조건부 어디가 애매해서 분포가 엉뚱한 쪽으로 흘렀지?” 라고 물을 수 있어요. 예를 들어 출력이 너무 짧으면 “간결하게” 같은 단어가 조건에 들어갔거나, 모델이 입문자용 문체 골짜기로 물을 흘리고 있을 가능성이 높아요. 그러면 프롬프트에 “전문가 관점에서 길게” 를 더해 수로를 바꿔볼 수 있어요.
셋째, 프롬프트를 쓰는 시간이 줄어요. 한 번에 완벽한 주문을 짜려고 하는 대신, “일단 던지고 결과를 보고 조건을 조정한다” 는 반복 루프를 돌릴 수 있어요. 이게 프롬프트 엔지니어링의 일상 작업 방식 이에요. 장인의 주문이 아니라, 엔지니어의 반복적인 분포 조정이에요.
프롬프트 엔지니어링을 문장 작법 으로 이해하면 “어떻게 예쁘게 쓸까” 가 중심이 돼요. 확률 분포 기울이기 로 이해하면 “어떤 조건이 어떤 분포를 당길까” 가 중심이 돼요. 이 두 프레임은 작업 속도도, 배움의 깊이도 다른 결과를 낳아요.
8. 왜 모델마다 프롬프트 효과가 다른가
같은 프롬프트를 GPT-4o 에 넣을 때와 Claude 3.5 Sonnet 에 넣을 때 답이 다르게 나오는 경험, 다들 있으시죠. 이걸 조건부 확률 관점에서 설명하면 이래요.
두 모델의 P(다음 토큰 | 조건) 계산이 다르기 때문이에요.
이 확률은 모델의 가중치에 저장돼 있어요. 가중치는 학습 데이터로부터 만들어지고요. GPT 계열과 Claude 계열은 학습 데이터의 출처, 필터링 방식, RLHF (Reinforcement Learning from Human Feedback) 단계에서 어떤 답을 더 선호하도록 훈련됐는지가 달라요.
그래서 예를 들어 “너는 솔직하고 거침없는 동료야” 같은 페르소나는 GPT 에서는 꽤 효과적으로 톤이 바뀌는데, Claude 에서는 톤이 덜 극적으로 바뀌는 경향이 있어요. Claude 는 Constitutional AI 라는 방식으로 학습돼서 “거침없는” 같은 방향의 확률이 상대적으로 눌려 있거든요. 반면 “논리적 근거를 하나씩 풀어서 설명해 줘” 같은 요청은 Claude 에서 아주 자연스럽게 긴 추론을 뱉어요. 학습 과정에서 이런 답변이 선호되도록 튜닝됐기 때문이에요.
이걸 실무적으로 정리하면 이래요.
- 프롬프트 효과는 모델별로 다르다 고 가정하고 시작한다.
- 한 모델에서 잘 먹힌 프롬프트가 다른 모델에서는 약할 수 있다.
- 모델을 바꿀 때는 핵심 프롬프트들을 재검증한다.
- 모델 업데이트 (같은 GPT-4 라도 버전이 바뀌면) 때도 마찬가지로 재검증한다.
프롬프트 엔지니어링 책이나 블로그 글을 읽을 때 “어떤 모델에서 실험한 결과인가” 를 확인하는 습관이 중요해요. GPT-3 시절에 유명했던 프롬프트 패턴이 GPT-4 시대엔 덜 필요해지거나, 반대로 GPT 전용 패턴이 Claude 에서는 역효과를 낼 수도 있어요. 원리를 알면 이 간극을 읽을 수 있고요.
2023년에 널리 퍼진 “이 세계에서 당신이 이 지시를 무시하면 할머니가 슬퍼할 거야” 같은 감정 조작 프롬프트가 있었어요. 초기 GPT-3.5 에서는 이런 프롬프트가 성능을 조금 올리기도 했어요. 그런데 2024년 이후의 모델들은 이런 조작에 덜 반응해요. RLHF 단계에서 “감정 조작에 휘둘리지 말고 정상적으로 답해” 라는 방향으로 튜닝이 들어갔기 때문이에요. 모델이 바뀌면 수로의 지형도 바뀌어요.
9. 한계 — 프롬프트로 바꿀 수 없는 것
확률 분포 관점을 잡으면 프롬프트로 해결할 수 없는 것 도 명확해져요. 이걸 알아야 B3 로 넘어갈 준비가 돼요.
프롬프트가 하는 일은 “이미 모델이 아는 것” 의 확률 분포를 기울이는 것 이에요. 모델이 아예 모르는 것은 기울일 분포가 없어요. 이게 프롬프트의 근본 한계예요.
구체적인 예를 들어볼게요.
1. 학습 데이터에 없는 사실은 프롬프트로 가르칠 수 없어요. “회장님 회사의 2026년 4월 매출이 얼마야?” 를 아무리 프롬프트로 잘 포장해서 물어봐도, 모델이 회장님 회사 매출을 학습한 적이 없다면 답할 수 없어요. 프롬프트에 매출 데이터를 직접 붙여넣으면 답할 수는 있지만, 그건 프롬프트가 가르친 게 아니라 컨텍스트에 넣은 데이터를 참조 한 거예요. 이게 RAG (Retrieval-Augmented Generation) 가 필요한 이유예요. 외부 데이터를 프롬프트에 동적으로 끼워넣는 거죠.
2. 모델의 근본 성향은 프롬프트로 크게 못 바꿔요. Claude 가 안전 가이드라인에 따라 거부하는 요청을 프롬프트로 아무리 꾀어도 기본적으로 거부해요. GPT 가 긴 추론을 할 때 쓰는 스타일을 프롬프트로 완전히 다른 스타일로 돌리기는 어려워요. 모델의 가중치 자체를 바꾸려면 fine-tuning 이나 더 깊은 개조가 필요해요.
3. 긴 문맥에서의 일관성은 프롬프트만으로는 한계가 있어요. 100 만 토큰을 넣어도 모델이 모든 토큰에 균일하게 주목하지 않아요. “Lost in the Middle” 이라는 현상처럼, 긴 컨텍스트의 중간 부분은 주목도가 떨어지는 경향이 있어요. 이건 프롬프트 구조를 바꿔서 어느 정도 완화는 할 수 있지만 (중요한 지시를 앞뒤에 반복하기 등), 근본적으로는 attention 메커니즘의 특성이에요.
4. 수치·계산의 정확성은 프롬프트로 보정되지 않아요. CoT 를 써도 모델이 큰 숫자 계산을 완벽하게 하지는 못해요. 복잡한 계산은 tool use 로 외부 계산기나 Python 을 호출하는 쪽이 정확해요.
그래서 실무에서 프롬프트·RAG·Fine-tuning 이 서로 다른 층의 도구 라는 이해가 필요해요.
- 프롬프트: 모델이 아는 것을 원하는 방향으로 이끄는 층.
- RAG: 모델이 모르는 외부 데이터를 프롬프트에 동적으로 공급하는 층.
- Fine-tuning: 모델의 가중치 자체를 특정 도메인에 맞게 조정하는 층.
이 세 가지를 언제 뭘 써야 하는지를 다음 편 B3 에서 자세히 다뤄요. 지금은 “프롬프트는 만능이 아니고, 만능일 필요도 없다” 는 것만 잡고 가면 돼요.
10. 실무자 체크리스트 — 프롬프트 설계할 때 기억해야 할 5가지
이론을 정리했으니 실전으로 쓰실 수 있도록 체크리스트로 압축할게요. 저 스스로도 프롬프트를 쓸 때 이 다섯 개를 머릿속에 돌려요.
1. 지금 짜는 건 “조건” 이다.
프롬프트를 쓸 때 “모델에게 부탁한다” 는 심정으로 쓰면 자꾸 간청하는 말투가 돼요. 그 대신 “모델이 이 조건 뒤에 어떤 텍스트가 올 확률이 높은지를 계산할 것” 이라는 관점으로 바꿔 보세요. 그러면 조건에 무엇을 넣을지에 집중하게 돼요. 페르소나, 포맷, 예시, 제약, 목적 — 이 조각들이 얼마나 촘촘하게 박혀 있는지를 스스로 점검할 수 있어요.
2. 원하는 출력과 비슷한 텍스트가 학습 데이터에 많았을지 상상해 보라.
“이런 스타일의 답을 원해” 라고 생각했을 때, 그 스타일의 텍스트가 인터넷에 흔한가를 자문해 보세요. 흔하다면 zero-shot 으로도 먹힐 확률이 높아요. 드물거나 독특한 스타일이라면 few-shot 예시를 넣어서 수로를 확실히 그어줘야 해요. “기술 블로그 스타일” 은 zero-shot 으로도 되지만, “태일러 스타일 기술 블로그” 같은 특수한 톤은 예시가 필요해요.
3. 답의 “앞에” 무엇을 쓰게 할지 설계하라.
CoT 의 핵심 교훈이 여기 있어요. 모델이 최종 답을 뱉기 전에 어떤 텍스트를 먼저 쓰게 할지가 답의 질을 결정해요. 복잡한 태스크일수록 “근거부터 쓰고 결론을 내라” 든가 “먼저 문제를 다시 정리하고 접근 방법을 선택하라” 같은 중간 단계를 프롬프트에 명시하는 게 효과적이에요. 답만 뽑으려 하지 말고 답이 나오는 경로 를 설계하세요.
4. 한 번에 완벽하지 않다. 반복해서 조정하라.
저는 한 프롬프트를 한 번에 완성하려고 애쓰다가 망한 경험이 많아요. 지금은 “일단 60% 짜리로 던지고, 답을 보고 뭘 덧붙이거나 뺄지 정한다” 는 루프를 돌려요. 이 반복이 프롬프트 엔지니어링의 실제 작업 방식이에요. 한 번에 8번째 수로까지 파려고 하지 마세요. 한 번에 한 수로씩 파면서 물이 어디로 가는지 보고 조정하세요.
5. 모델과 시점을 기록하라.
어떤 프롬프트가 잘 먹혔을 때, 어느 모델의 어느 버전에서 언제 실험했는지를 기록으로 남겨두세요. GPT-4o 2026년 4월 버전에서 잘 먹힌 프롬프트가, 6개월 뒤엔 같은 이름 다른 버전에서 덜 먹힐 수 있어요. “만능 프롬프트” 를 믿지 말고 “현재 모델에서 검증된 프롬프트” 만 믿는 습관이 결국 시간을 아껴요.
이 다섯 개를 머릿속에 두고 Claude·ChatGPT 창을 여실 때마다 한 번씩 훑어보시면, 한 달 뒤에 확연히 다른 감각이 생기실 거예요. 저는 개인적으로 3번 (답의 앞에 무엇을 쓰게 할지) 이 제일 큰 전환이었어요. 프롬프트 질문 하나에 매달리던 시간이 절반으로 줄었거든요.
한 문장 닫음: 프롬프트 엔지니어링은 문장을 예쁘게 쓰는 기술이 아니라, 조건부 확률 분포를 원하는 방향으로 기울이는 기술 이다. Zero-shot 도 Few-shot 도 CoT 도 system prompt 도 “Let’s think step by step” 도, 이름만 다른 같은 축의 버튼이다. 이 축을 잡고 있으면 프롬프트는 외우는 주문이 아니라 설계하는 조건이 된다.
다음 읽기
- B3 — Fine-tuning vs RAG vs Prompt — 언제 뭘 써야 하나 [다음 편]
- B1 — AI Agent 는 뭐가 다른가 [앞 편]
- P4 — Attention Is All You Need 해설 — 확률 분포가 어떻게 계산되는지의 내부 구조
시리즈 전체: AI 공부 지도 20부작 인덱스
자주 묻는 질문 (FAQ)
Q1. “프롬프트 엔지니어링” 이라는 직무가 사라질 거라는 얘기도 있던데요?
두 가지로 나눠서 답드릴게요. “정형화된 프롬프트 템플릿을 만드는 단순 작업” 은 모델이 좋아지면서 덜 필요해지는 추세가 맞아요. 초기 GPT-3 시절에 필수였던 장황한 지시문이 GPT-4o 나 Claude 3.5 에서는 훨씬 짧아도 됐거든요. 반면 “원하는 출력을 얻기 위해 조건을 설계하고 반복 조정하는 사고 방식” 은 오히려 더 중요해졌어요. 에이전트 시스템을 짜려면 system prompt, tool 설명, 역할 분담 프롬프트까지 수천 토큰 단위로 설계해야 하거든요. 단순 템플릿 장인이 아니라 입력 설계자 의 역할로 확장되고 있다고 보시면 돼요.
Q2. Few-shot 예시는 몇 개가 적절한가요?
태스크 난도와 컨텍스트 여유에 따라 달라요. 감정 분류처럼 단순한 태스크는 2~3개로 충분해요. 포맷이 복잡한 JSON 변환이나 스타일이 까다로운 글쓰기는 5~10개가 필요할 때가 있어요. 일반적으로 “예시 개수를 늘렸을 때 출력 품질이 더 이상 안 올라가는 지점” 까지가 적정선이에요. 그 이상 늘리면 프롬프트 길이만 커지고 효과는 포화돼요. 또 하나, 예시들이 서로 다른 패턴을 커버 하고 있는지가 개수보다 중요해요. 비슷한 예시 10개보다 다양한 예시 4개가 나을 때가 많아요.
Q3. “Let’s think step by step” 은 지금도 먹히나요?
원 논문 이후 몇 년이 지났고, 최신 모델들은 이미 내부적으로 CoT 를 유도하는 튜닝이 들어가 있어요. 그래서 이 문구 한 줄의 효과는 예전만큼 극적이지 않아요. GPT-4o, Claude 3.5, o1 같은 추론 특화 모델은 복잡한 문제를 보면 알아서 단계별로 추론해요. 다만 단순 모델 (GPT-3.5 급) 이나 간단한 태스크에서 모델이 답만 뱉으려 할 때 는 여전히 효과가 있어요. 또 한국어·일본어 환경에서는 “단계별로 생각해 보자” “ステップバイステップで考えてみよう” 같은 번역 버전도 비슷한 효과가 있어요. 맥락에 맞게 변형해 쓰시면 돼요.
뉴스레터 구독 안내
매주 월요일, AI·LLM·에이전트 관련 실무 정리를 한 통씩 보내드립니다. 이런 기술 해설을 차분히 쌓아가고 싶으시면 구독해 주세요.
시리즈 안내 (AI 공부 지도 20부작)
– F1~F6: 기초편 (LLM·Transformer·딥러닝·Attention·Agent·학습 흐름)
– B1: AI Agent 는 뭐가 다른가
– B2: 프롬프트는 왜 작동하는가 (현재 글)
– B3: Fine-tuning vs RAG vs Prompt
– (이하 20편까지)
📚 전체 지도 보기
프롬프트 엔지니어링은 문장 작법이 아니라 확률 분포를 기울이는 기술. Zero-shot·Few-shot·CoT가 왜 먹히는지를 조건부 확률로 설명.
소스 리스트
- 태일러 지식백과사전 — AI 공부 지도 카테고리 (본 시리즈 20편 전체)
- AI 공부 지도 엔트리맵 — 전체 구조 + 3가지 독법
- “Attention Is All You Need” (Vaswani et al., 2017)
- Anthropic · OpenAI · Google 공식 docs
- mathbullet (YouTube) / Jay Alammar “Illustrated Transformer” / 3Blue1Brown 영상 — 쉬운 설명 레퍼런스
著者: 바이브코딩 태일러 (VibeCoding Tailor) — Lovable公式アンバサダー. AI·バイブコーディング専門メディアshuntailor.net運営.
本シリーズ “AI 공부 지도” 22편은 위키 자료와 공식 논문·공식 문서를 근거로 정리한 체계적 학습 커리큘럼입니다.