프롬프트 엔지니어링은 AI 모델이 필요한 결과를 안정적으로 내도록 지시문을 쓰고, 테스트하고, 다듬는 작업입니다. 프롬프트에 무엇을 넣는지(할 일, 맥락, 예시, 입력)와 그것을 어떻게 배치하는지(순서, 형식, 구분자)를 모두 다룹니다. 이름은 기술적으로 들리지만, 대부분은 신중하게 글을 쓰고 결과를 확인하는 일입니다.
이 페이지는 Coddy 프롬프트 엔지니어링 가이드의 목차입니다. 이 작업이 왜 효과가 있는지 설명하고, 핵심 기법을 각 기법을 가르치는 페이지와 연결하며, 대충 쓴 프롬프트와 설계한 프롬프트의 차이를 보여 줍니다.
프롬프트 엔지니어링이 효과가 있는 이유
언어 모델은 눈앞에 있는 모든 것을 바탕으로 다음에 올 내용을 작은 조각 단위로 하나씩 예측하며 텍스트를 생성합니다. 여러분의 의도, 프로젝트, 이전 대화는 그 텍스트가 입력에 들어 있지 않는 한 모델이 알 수 없습니다. 그러니 프롬프트는 이미 여러분을 이해하는 누군가에게 보내는 부탁이 아니라, 모델이 응답하는 상황 전체입니다.
여기서 바로 한 가지 결과가 나옵니다. 프롬프트가 열어 둔 질문은 모델이 가장 전형적인 선택으로 채우는 경향이 있습니다. 가장 흔한 언어, 가장 흔한 길이, 가장 흔한 독자층입니다. 전형적인 선택이 원하던 것일 때도 있습니다. 그렇지 않다면 해결책은 프롬프트에서 그 질문을 닫는 것입니다. 좋은 프롬프트는 그럴듯한 답변의 범위를 좁혀서, 남은 답변 대부분이 쓸모 있게 만듭니다.
이 작업을 좌우하는 사실이 두 가지 더 있습니다. 답변은 샘플링으로 만들어지므로 같은 프롬프트도 실행할 때마다 다른 답을 낼 수 있습니다. 한 번 잘 된 프롬프트가 아니라 대부분 잘 되는 프롬프트여야 좋은 프롬프트입니다. 그리고 모델은 프롬프트 안의 모든 텍스트를 의미 있는 것으로 받아들일 수 있으므로, 붙여 넣은 이메일이나 엉뚱한 문장 하나가 자료라고 분명히 표시하지 않으면 지시로 읽힐 수 있습니다.
대충 쓴 프롬프트와 설계한 프롬프트
두 탭 모두 같은 일을 요청합니다. 고객 리뷰를 긍정과 부정으로 분류하는 일입니다. 각각 무엇을 돌려받는지 비교해 보세요.
하나씩 살펴보면 다음과 같습니다.
- 복합적. 속도는 마음에 들어 하지만 로그아웃 문제로 불만이 있습니다.
- 긍정. 러닝 기록이라는 필요를 충족하고 있습니다.
- 부정. 고객센터가 답하지 않은 점에 불만이 있습니다.
전체적으로 긍정 하나, 부정 하나, 복합 하나로 의견이 섞여 있습니다.
대충 쓴 프롬프트의 답변은 사람이 읽기에는 괜찮지만 프로그램은 쓸 수 없습니다. 라벨이 설명과 섞여 있고, 질문에 없던 세 번째 분류가 생겼고, 끝에 요약까지 붙었습니다. 설계한 프롬프트는 모든 라벨을 정의하고, 예시로 출력 형태를 고정하고, 리뷰를 태그로 감싸 지시와 헷갈릴 가능성을 줄입니다. 리뷰 천 개에 실행해도 프로그램이 훨씬 일관되게 파싱할 수 있는 결과가 나오고, 완벽한 보장이 필요하다면 API의 구조화된 출력 기능과 코드의 검증 단계로 남은 틈을 메웁니다.
핵심 기법
아래의 각 기법은 여러분이 뜻한 것과 모델이 받은 것 사이의 서로 다른 틈을 메웁니다. 실제 프롬프트는 대부분 여러 기법을 섞어 씁니다.
| 기법 | 하는 일 | 이럴 때 쓰세요 |
|---|---|---|
| 제로샷 프롬프팅 | 예시 없이 지시만 준다 | 흔한 작업이고 설명이 명확할 때 |
| Few-shot 프롬프팅 | 입력과 출력 예시를 몇 개 보여 준다 | 형식이나 판단 기준을 설명보다 보여 주는 게 쉬울 때 |
| 생각의 사슬(CoT) 프롬프팅 | 답보다 추론 과정을 먼저 요청한다 | 수학이나 논리처럼 여러 단계가 있는 문제일 때 |
| 역할 프롬프팅 | 누구의 말투와 기준을 쓸지 정한다 | 독자와 수준이 중요할 때 |
| 구조화된 출력 | 답을 JSON, 표, 템플릿으로 고정한다 | 프로그램이나 스프레드시트가 결과를 읽을 때 |
| 구분자와 XML 태그 | 지시와 붙여 넣은 자료를 분리한다 | 프롬프트에 문서, 코드, 사용자 텍스트가 들어갈 때 |
| 프롬프트 템플릿 | 좋은 프롬프트를 빈칸이 있는 틀로 만든다 | 같은 종류의 요청을 반복할 때 |
| 프롬프트 체이닝 | 작업을 서로 이어지는 단계로 나눈다 | 프롬프트 하나가 너무 많은 일을 할 때 |
| 자기 일관성 | 답을 여러 개 뽑아 다수결로 정한다 | 추론 경로 하나로는 믿기 어려울 때 |
| 생각의 나무 | 여러 추론 경로를 탐색하고 점수를 매긴다 | 계획이나 탐색이 필요한 문제일 때 |
| ReAct | 추론과 도구 호출을 번갈아 한다 | 모델이 정보를 찾거나 행동해야 할 때 |
| 메타 프롬프팅 | 모델에게 프롬프트를 쓰거나 개선하게 한다 | 프롬프트를 어떻게 써야 할지 막혔을 때 |
| 컨텍스트 엔지니어링 | 지시문뿐 아니라 모델이 보는 모든 것을 설계한다 | 모델을 중심으로 앱이나 에이전트를 만들 때 |
처음이라면 프롬프트 작성법에서 프롬프트 하나의 구성 요소부터 익히고, 이어서 few-shot 프롬프팅과 구조화된 출력을 보세요. 이 세 가지로 일상적인 문제 대부분을 해결할 수 있습니다.
프로그램을 위해 만든 프롬프트
소프트웨어에 들어간 프롬프트는 아무도 본 적 없는 입력으로 수천 번 실행되므로, 채팅 메시지보다 더 많은 것을 명시합니다. 아래 프롬프트는 코드 diff를 보고 커밋 메시지를 씁니다. 각 부분을 꺼 보면서 무엇을 막아 주는지 확인해 보세요. 예시가 없으면 스타일이 흔들리고, 제약 조건이 없으면 모델이 perf나 style처럼 팀에서 쓰지 않는 타입을 쓸 수 있습니다.
function validatePassword(password) {
- if (password.length > 8) {
+ if (password.length >= 8) {
return null;
}
return 'Password must be at least 8 characters';
}fix(auth): accept passwords of exactly 8 characters
- The check used > 8, so an 8-character password was rejected
- The rule now matches the error message, which says "at least 8"
프롬프트 엔지니어링 공부 방법
프롬프트를 직접 실행하고 돌아온 결과를 꼼꼼히 들여다보면서 배웁니다. 실용적인 순서는 이렇습니다.
- 프롬프트의 구성 요소를 익히세요. 할 일, 맥락, 입력, 형식, 제약 조건입니다. 실패의 대부분은 이 중 하나가 빠진 데서 옵니다.
- 반복하는 실제 작업을 하나 고르세요. 티켓 요약, 에러 설명, 이메일 초안 같은 작업을 골라 프롬프트를 씁니다.
- 테스트 입력을 5~10개 모으세요. 빈 입력, 아주 긴 입력, 다른 언어로 된 입력처럼 까다로운 것도 넣습니다.
- 한 번에 하나만 바꾸세요. 그리고 모든 입력으로 다시 실행합니다. 세 가지를 바꿨는데 결과가 좋아지면 어떤 변경이 도움이 됐는지 알 수 없습니다. 이 과정은 프롬프트 반복 개선에서 자세히 다룹니다.
- 특정 실패가 생겼을 때 기법을 더하세요. 형식이 흔들리면 예시를, 여러 단계의 답이 틀리면 단계별 추론을, 붙여 넣은 텍스트가 지시에 섞이면 구분자를 씁니다.
주요 모델 제공사들도 자사 모델을 위한 프롬프트 가이드를 공개하고 있습니다. 각 가이드는 해당 모델 계열이 무엇에 가장 잘 반응하는지 설명하므로 읽어 볼 만합니다.
프롬프트 엔지니어는 직업인가?
특히 채팅 모델이 처음 널리 쓰이기 시작했을 때 "프롬프트 엔지니어"라는 직함으로 채용한 회사들이 있었습니다. 하지만 이 기술은 다른 직무의 일부인 경우가 더 많습니다. 개발자는 자신이 만드는 AI 기능을 위해 프롬프트를 쓰고, 고객지원 팀은 고객에게 답하는 어시스턴트를 위해 쓰며, 분석가와 작가는 매일 프롬프트를 씁니다.
AI 제품을 만드는 팀에서는 이 일의 범위가 넓어졌습니다. 모델의 입력에 무엇을 넣을지(검색한 문서, 도구 결과, 대화 기록, 메모리) 고르는 일이 지시문의 표현만큼 중요해졌고, 이 넓어진 일을 흔히 컨텍스트 엔지니어링이라고 부릅니다. 프롬프트가 많은 입력에서 제대로 동작하는지 측정하는 일, 흔히 평가(evaluation)라고 부르는 일이 나머지 절반입니다.
최신 모델에서 달라지는 것
초기 프롬프트 엔지니어링은 요령에 기댔습니다. 마법 같은 문구, 정교한 페르소나, 같은 지시를 여러 번 반복하기 같은 것들입니다. 지금의 모델은 평범한 지시를 훨씬 잘 따르고, 추론 모델은 답하기 전에 이미 내부적으로 문제를 차근차근 풀기 때문에 단계별로 생각하라는 요청의 효과가 예전보다 작습니다.
변하지 않은 것은 애초에 요령이 아니었던 부분입니다. 여러분이 말하지 않으면 모델은 여전히 여러분의 독자, 데이터, 제약 조건, 좋은 결과의 모습을 알 수 없습니다. 명확하게 명세하는 능력이 오래가는 기술이고, 이 가이드가 대부분의 페이지를 할애하는 것도 그 능력입니다.
자주 묻는 질문
프롬프트 엔지니어링을 쉽게 설명하면 무엇인가요?
프롬프트 엔지니어링은 AI 모델이 필요한 답을 내도록 지시문을 신중하게 쓰고, 안정적으로 그렇게 될 때까지 테스트하고 고치는 일입니다. 모델에게 무엇을 알려 주는지(할 일, 맥락, 예시)와 그것을 어떻게 배치하는지(순서, 형식, 구분자)를 모두 다룹니다.
코딩을 몰라도 프롬프트 엔지니어링을 배울 수 있나요?
네. 할 일을 명확히 말하기, 맥락 제공하기, 예시 주기, 출력 형식 지정하기 같은 핵심 기술은 모두 채팅 앱에서 쓸 수 있습니다. 코딩은 프롬프트를 여러 번 실행하거나, 여러 입력으로 테스트하거나, 결과를 프로그램에 넘기고 싶을 때 쓸모가 생깁니다.
프롬프트 엔지니어링을 배우는 데 얼마나 걸리나요?
기초는 오후 한나절이면 됩니다. 좋은 프롬프트의 구성 요소와 few-shot 예시, 구조화된 출력 같은 몇 가지 기법이면 충분합니다. 실제 작업에서 안정적인 결과를 얻으려면 더 오래 걸립니다. 프롬프트를 많은 입력에 테스트하고 실패하는 경우를 고치는 과정에서 실력이 생기기 때문입니다.
프롬프트 엔지니어는 실제 직업인가요?
"프롬프트 엔지니어"라는 직함으로 채용한 회사도 있지만, 그보다는 다른 직무의 일부인 경우가 많습니다. AI 기능을 만드는 개발자, 작가, 분석가, 고객지원 팀이 그렇습니다. AI 제품을 만드는 팀에서는 평가 작업, 그리고 모델이 보는 모든 것을 설계하는 일과 겹치는데, 이 일을 요즘은 흔히 컨텍스트 엔지니어링이라고 부릅니다.
최신 AI 모델에서도 프롬프트 엔지니어링이 여전히 쓸모 있나요?
최신 모델은 요령이 덜 필요합니다. 평범한 지시를 더 잘 따르고, 추론 모델은 단계별로 생각하라고 하지 않아도 문제를 차근차근 풉니다. 여전히 쓸모 있는 것은 애초에 요령이 아니었던 부분입니다. 할 일을 말하고, 모델이 알 수 없는 사실을 알려 주고, 좋은 답이 어떤 모습인지 정의하는 것입니다.
