프롬프트 엔지니어링 — AI에게 제대로 말 거는 법

지난 글에서 트랜스포머가 “문장을 어떻게 이해하는지”를 살펴봤다. 어텐션 메커니즘이 단어 간의 관계를 수치로 계산하고, 그 결과를 바탕으로 다음 토큰을 예측한다는 흐름이었다. 그런데 여기서 자연스러운 질문이 생긴다. 같은 LLM에게 질문해도 왜 어떤 때는 훌륭한 답이 나오고, 어떤 때는 엉뚱한 답이 나오는 걸까?

답은 생각보다 단순하다. LLM은 주어진 텍스트의 문맥을 이어받아 확률적으로 다음 내용을 생성하는 기계다. 입력을 어떻게 구성하느냐가 출력의 방향을 통째로 바꾼다. 프롬프트 엔지니어링은 바로 이 입력을 의도적으로 설계하는 기술이다.

왜 “질문 방식”이 이렇게 중요한가

직장 동료에게 업무를 부탁하는 상황을 떠올려보자. “이거 좀 봐줘”와 “이 데이터의 2023년 월별 매출을 꺾은선 그래프로 요약해서 팀장님 보고용 PPT 한 장으로 만들어줘”는 완전히 다른 결과물을 낳는다. LLM도 마찬가지다. 구체성, 맥락, 형식 지정이 곧 결과물의 품질이다.

게다가 LLM은 “이해”하는 게 아니라 “패턴을 이어받는” 시스템이다. “오늘 점심 뭐 먹지?”라는 질문에 대해 훈련 데이터에서 가장 자주 따라왔던 종류의 텍스트를 생성한다. 그러니 우리가 원하는 방향의 패턴을 프롬프트에 심어두면, 모델은 그 패턴을 자연스럽게 이어받는다. 이게 프롬프트 엔지니어링의 핵심 원리다.

프롬프트의 해부학

좋은 프롬프트는 아무렇게나 쓴 질문이 아니다. 크게 네 가지 구성 요소로 이루어진다.

프롬프트 해부학 — 좋은 프롬프트의 구조

System Prompt는 AI의 역할과 행동 규칙을 정의하는 영역이다. “당신은 친절한 한국어 요리 전문가입니다”처럼 대화 전체의 기준점을 설정한다. ChatGPT나 Claude API에서 시스템 메시지가 이 역할을 한다.

Context는 모델이 상황을 파악할 수 있도록 필요한 배경 정보를 주입하는 부분이다. 오늘 냉장고에 있는 재료, 사용자의 알레르기 정보, 분석할 데이터 등이 여기에 들어간다. LLM은 훈련 당시의 정보만 알고 있으므로, 최신 정보나 도메인 특화 정보는 반드시 컨텍스트로 제공해야 한다.

Task는 정확히 무엇을 해달라는 지시다. “번역해줘”가 아니라 “영어 원문의 격식체를 유지하면서 자연스러운 한국어로 번역해줘”처럼 구체적일수록 좋다. 모호한 지시는 모호한 결과로 돌아온다.

Output Format은 결과물의 형태를 미리 지정하는 것이다. JSON, 마크다운, 번호 목록, 표 등 원하는 형식을 명시하면 파싱과 후처리가 훨씬 쉬워진다. 특히 LLM을 프로그래밍적으로 활용할 때는 출력 형식 지정이 필수다.

이 네 가지가 모든 프롬프트에 항상 필요한 건 아니다. 간단한 질문에는 Task 하나로 충분할 수 있다. 하지만 복잡하고 중요한 작업일수록 이 구조를 의식적으로 채워넣을수록 결과물이 달라진다.

주요 프롬프팅 기법

구조를 알았으니 이제 실전 기법을 살펴보자. 각 기법은 상황에 따라 선택하고, 필요하면 조합한다.

주요 프롬프팅 기법 비교

Zero-shot: 예시 없이 바로 요청

가장 단순한 형태다. 예시나 추가 맥락 없이 원하는 작업을 직접 요청한다.

"다음 리뷰가 긍정적인지 부정적인지 분류해줘: '배송이 늦었지만 제품 품질은 훌륭했어요.'"

최신 대형 모델들은 Zero-shot만으로도 상당히 잘 작동한다. 충분히 훈련된 모델이라면 새로운 예시 없이도 패턴을 일반화할 수 있기 때문이다. 빠른 프로토타이핑이나 간단한 작업에 적합하지만, 복잡한 추론이나 도메인 특화 작업에는 한계가 있다.

Few-shot: 예시를 보여주고 따라오게 하기

두세 개의 입출력 예시를 먼저 보여준 뒤 실제 질문을 한다. 모델이 패턴을 파악하고 그대로 따라오게 만드는 방식이다.

감성 분석을 해줘:

입력: "오늘 최고의 하루였어!" → 출력: 긍정
입력: "다시는 이 가게 안 가" → 출력: 부정
입력: "그냥 평범한 하루" → 출력: 중립

입력: "음식은 맛있었는데 서비스가 별로였어" → 출력:

Few-shot의 핵심은 예시의 품질이다. 예시가 일관성 없거나 모호하면 모델도 일관성 없는 결과를 낸다. 또한 예시의 순서나 레이블 표기 방식도 은근히 결과에 영향을 준다. 감성 분석, 특정 형식의 데이터 변환, 스타일 일관성이 필요한 작업에 특히 효과적이다.

Chain-of-Thought: 단계적 추론을 유도하기

단순히 답을 요청하는 게 아니라 “단계별로 생각해봐”라고 유도하는 방식이다. 2022년 Google Brain 팀의 연구에서 발표된 이 기법은 복잡한 추론 문제에서 LLM의 정확도를 극적으로 향상시켰다.

다음 문제를 단계별로 풀어줘:

철수는 사과 12개를 가지고 있었다. 영희에게 절반을 주고, 
남은 것의 1/3을 먹었다. 철수에게 남은 사과는 몇 개인가?

“Let’s think step by step”이라는 한 문장을 추가하는 것만으로도 모델의 추론 성능이 눈에 띄게 오르는 경우가 많다. 이는 모델이 중간 추론 과정을 텍스트로 생성하면서, 그 텍스트 자체가 다음 추론의 컨텍스트가 되기 때문이다. 수학 문제, 논리 퍼즐, 복잡한 계획 수립 등 순차적 추론이 필요한 작업에 효과적이다.

단점은 토큰 소모가 크다는 것이다. 답 하나를 얻기 위해 훨씬 많은 텍스트를 생성하므로 비용과 속도 면에서 트레이드오프가 있다.

Role Prompting: 역할을 부여해 전문성 끌어내기

모델에게 특정 전문가의 역할을 부여하면 그에 맞는 어조와 깊이로 응답한다.

당신은 15년 경력의 심장내과 전문의입니다. 
일반 환자도 이해할 수 있도록 심방세동의 증상과 치료 옵션을 설명해주세요.

“전문의”라는 역할을 부여하면 모델은 그 역할에 맞는 어휘, 논리 구조, 주의사항을 훈련 데이터에서 끌어온다. 재미있는 점은 “당신은 초등학생입니다”처럼 반대 방향의 역할도 효과적으로 작동한다는 것이다. 복잡한 개념을 쉽게 설명받고 싶을 때 유용하다.

실전에서 자주 쓰는 기법들

이 외에도 실무에서 자주 활용되는 패턴들이 있다.

Negative Prompting: 하지 말아야 할 것을 명시하는 방식이다. “존댓말을 쓰지 마세요”, “불확실한 내용은 추측하지 말고 모른다고 해주세요” 같은 제약 조건은 원치 않는 행동을 억제한다.

Persona Assignment: Role Prompting과 유사하지만 더 상세한 인물 설정을 주는 방식이다. 이름, 성격, 말투, 전문 분야, 금기 사항까지 설정하면 챗봇이나 AI 캐릭터 구현에 활용된다.

Structured Output: JSON 스키마를 프롬프트에 직접 명시하거나, “다음 형식으로만 답해줘”와 함께 예시를 제공하면 파싱 가능한 출력을 안정적으로 받을 수 있다. 특히 API 연동에서 필수적인 패턴이다.

Iterative Refinement: 한 번의 프롬프트로 완벽한 결과를 기대하지 않고, 초안을 받은 뒤 “더 구체적으로”, “마지막 단락을 다시 써줘”, “더 공식적인 어조로” 같은 후속 지시로 점진적으로 개선하는 방식이다.

프롬프트 엔지니어링의 한계

기법들이 효과적이긴 하지만, 만능은 아니다.

모델 의존성: 같은 프롬프트가 GPT-4에서는 잘 되지만 다른 모델에서는 다르게 동작할 수 있다. 각 모델은 훈련 데이터와 파인튜닝 방식이 달라서, 모델마다 프롬프트를 조정해야 하는 경우가 많다.

할루시네이션 문제: 아무리 좋은 프롬프트를 써도 모델이 없는 사실을 만들어내는 걸 완전히 막을 수는 없다. “확실하지 않으면 모른다고 해줘”라고 지시해도 모델은 여전히 그럴싸한 거짓말을 할 수 있다.

컨텍스트 길이 제한: 프롬프트가 길어질수록 좋아지지만, 모델마다 처리할 수 있는 최대 길이가 정해져 있다. 이 한계를 넘으면 초기 내용이 “잊혀지는” 현상이 생긴다. 이 문제를 해결하는 방법 중 하나가 다음 글에서 다룰 RAG(검색 증강 생성)다.

비결정론적 출력: 같은 프롬프트라도 실행할 때마다 다른 결과가 나올 수 있다. temperature 같은 파라미터로 어느 정도 제어할 수 있지만 완전한 재현성을 보장하기는 어렵다.

좋은 프롬프트를 만드는 실용적 원칙

이론을 마무리하며 실전에서 바로 써먹을 수 있는 원칙들을 정리한다.

1. 명확하고 구체적으로: “좋은 글 써줘” 대신 “B2B SaaS 스타트업의 투자 유치 덱용 Executive Summary를 300자 이내로 작성해줘. 핵심 문제-솔루션-시장 규모-차별화 포인트 순서로.”

2. 역할과 청중을 지정하라: 누가 말하고, 누구에게 전달되는 글인지 명시하면 어조와 전문성 수준이 자동으로 맞춰진다.

3. 형식을 먼저 설계하라: 원하는 출력 형태를 프롬프트 앞부분에 배치하면 모델이 처음부터 그 형식을 목표로 생성한다.

4. 제약 조건을 명시하라: 글자 수, 금지 단어, 포함해야 할 요소, 문체 등 구체적인 제약이 창의성보다 훨씬 중요하다.

5. 예시는 황금이다: 원하는 결과의 예시를 하나라도 보여주면 천 마디 설명보다 효과적이다.

6. 반복적으로 개선하라: 첫 번째 프롬프트가 완벽할 필요는 없다. 결과를 보고 무엇이 부족한지 파악해 조금씩 수정하는 것이 실제 작업 방식이다.

마치며: 소통 기술로서의 프롬프트 엔지니어링

프롬프트 엔지니어링은 사실 새로운 개념이 아니다. 명확하게 지시하고, 충분한 맥락을 주고, 원하는 결과물의 형태를 미리 보여주는 것 — 이건 오래전부터 좋은 매니저, 좋은 작가, 좋은 커뮤니케이터가 해왔던 일이다. LLM이 등장하면서 이 소통 기술이 소프트웨어 역량으로 편입된 것뿐이다.

중요한 건 기법을 외우는 게 아니라 “내가 원하는 게 뭔지”를 정확히 아는 것이다. 요구사항이 명확하면 프롬프트는 자연히 명확해진다. 반대로 내가 원하는 게 뭔지 모르면 아무리 좋은 프롬프트 기법도 도움이 안 된다.

그리고 프롬프트 엔지니어링만으로는 해결할 수 없는 문제들이 있다. 모델이 훈련 당시에 알지 못했던 최신 정보, 사내 문서, 개인 데이터가 필요한 경우가 그렇다. 이때 등장하는 것이 **RAG(Retrieval-Augmented Generation)**다.

다음 글: RAG(검색 증강 생성) — LLM에게 외부 지식을 연결하는 법

읽어주셔서 감사합니다. 😊