부록 C. 실무용 프롬프트 템플릿

프롬프트를 매번 처음부터 쓰기 시작하면, 개발보다 문장 다듬기에 더 많은 시간을 쓰게 된다. 게다가 어제 잘 되던 문장이 오늘은 어딘가 미묘하게 흔들리기도 한다. 그래서 실무에서는 멋진 한 줄보다, 여러 기능에 반복해서 붙여 쓸 수 있는 기본 틀이 더 중요하다.

이 부록은 그런 상황을 위한 치트시트다. 요약, 추출, 분류, 재작성, RAG, 툴 호출에 자주 쓰는 프롬프트를 바로 가져다 쓸 수 있게 모아 두었다. 그대로 복붙해서 시작해도 되고, 서비스 정책에 맞게 조금씩 줄이고 바꿔도 된다. 핵심은 단순하다. 프롬프트를 매번 새로 쓰지 말고, 템플릿으로 운영하자는 것이다.

이 부록을 쓰는 법

아래 템플릿에는 {{...}} 형태의 자리가 자주 나온다. 여기에 당신 서비스의 실제 값을 넣으면 된다.

템플릿을 고칠 때는 세 가지만 먼저 정하면 훨씬 수월하다.

• 입력이 무엇인지

• 출력이 어떤 모양이어야 하는지

• 정보가 부족할 때 어떻게 행동해야 하는지

이 세 줄기만 분명하면 프롬프트는 절반 이상 완성된 셈이다.

공통 베이스 템플릿

아무 기능이든 아래 기본 뼈대에서 출발하면 크게 흔들리지 않는다.

너는 {{role}}이다.
목표: {{goal}}

입력 규칙:
- 사용자가 준 입력만 사용한다.
- 입력에 없는 사실을 추측해 추가하지 않는다.
- 정보가 부족하면 부족하다고 명시한다.

출력 규칙:
- 출력 형식: {{output_format}}
- 길이 제한: {{target_length}}
- 말투/스타일: {{tone}}
- 결과만 출력하고 불필요한 설명은 생략한다.

실패 시 규칙:
- 판단이 어려우면 {{fallback_rule}}에 따라 답한다.

입력:
{{input_text}}

이 베이스 템플릿은 마치 반죽 같다. 여기에 요약이면 요약 규칙을, 분류면 라벨 규칙을, RAG면 근거 규칙을 얹으면 된다. 한 번 잘 만들어 두면 기능별 파생 템플릿을 만들기 쉽다.

요약 템플릿

요약은 가장 흔하지만, 가장 쉽게 미끄러지는 작업이기도 하다. 대충 쓰면 모델은 중요한 정보 대신 그럴듯한 문장을 길게 뽑아 내기 쉽다. 그래서 길이, 관점, 빠지면 안 되는 항목을 먼저 고정하는 편이 좋다.

한 문단 요약

뉴스, 공지, 긴 문의, 문서 초안을 짧게 줄이고 싶을 때 쓰기 좋다.

너는 한국어 요약 도우미다.
아래 텍스트의 핵심만 간결하게 요약하라.

규칙:
- 가장 중요한 내용만 남긴다.
- 세부 예시나 반복 표현은 줄인다.
- 입력에 없는 해석을 덧붙이지 않는다.
- 3문장 이내로 작성한다.
- 결과 요약만 출력한다.

입력:
{{input_text}}

회의록 요약

회의 기록은 그냥 짧게 줄이는 것보다, 결정 사항과 할 일을 분리하는 편이 훨씬 쓸모 있다.

너는 회의록 정리 도우미다.
아래 회의 내용을 읽고 정리하라.

출력 형식:
## 회의 요약
- 2~4문장으로 핵심 요약

## 결정 사항
- 확정된 사항만 정리

## 액션 아이템
- 누가, 무엇을, 언제까지 하는지 알 수 있게 정리
- 불명확하면 "담당자 미정" 또는 "기한 미정"으로 표시

규칙:
- 회의 내용에 없는 사실을 추가하지 않는다.
- 추측하지 않는다.
- 항목별로 짧고 명확하게 쓴다.

입력:
{{input_text}}

사용자 친화형 요약

원문이 너무 딱딱할 때, 내용을 바꾸지 않으면서 쉽게 풀어 설명하고 싶다면 이런 템플릿이 잘 맞는다.

너는 어려운 문서를 쉽게 풀어 설명하는 도우미다.
아래 텍스트를 일반 사용자가 이해하기 쉽게 요약하라.

규칙:
- 전문 용어는 쉬운 표현으로 바꾼다.
- 의미는 바꾸지 않는다.
- 핵심 메시지와 사용자가 알아야 할 행동을 함께 정리한다.
- 5문장 이내로 작성한다.

입력:
{{input_text}}

추출 템플릿

추출은 문장을 예쁘게 쓰는 작업이 아니라, 필요한 값을 정확히 꺼내는 작업이다. 그래서 실무에서는 자유 문장보다 JSON이나 고정 필드가 훨씬 낫다.

필드 추출 템플릿

문의 내용, 문서, 계약서, 폼 응답에서 필요한 값만 뽑고 싶을 때 쓴다.

너는 정보 추출기다.
아래 텍스트에서 필요한 정보를 추출하라.

추출 대상 필드:
{{output_schema}}

규칙:
- 반드시 JSON 객체 하나로만 출력한다.
- 값이 없으면 추측하지 말고 null을 넣는다.
- 원문에 있는 표현을 가능한 한 그대로 사용한다.
- JSON 외의 설명 문장은 출력하지 않는다.

입력:
{{input_text}}

예를 들어 {{output_schema}}는 이렇게 둘 수 있다.

{
  "customer_name": "string | null",
  "email": "string | null",
  "order_id": "string | null",
  "issue_type": "string | null"
}

근거 포함 추출 템플릿

값만 뽑는 것으로 부족할 때가 있다. 나중에 왜 그 값을 뽑았는지 확인하려면 근거 문장까지 함께 받는 편이 좋다.

너는 정보 추출기다.
아래 텍스트에서 필요한 정보를 추출하고, 각 값의 근거가 된 짧은 원문 구절도 함께 반환하라.

출력 형식:
{
  "fields": {
    {{output_schema}}
  },
  "evidence": {
    "field_name": "근거가 된 짧은 원문"
  }
}

규칙:
- 값이 없으면 null을 사용한다.
- 근거가 없으면 evidence에도 null을 넣는다.
- JSON만 출력한다.

입력:
{{input_text}}

이 템플릿은 검토 화면이 있는 서비스에서 특히 유용하다. 사람이 값을 확인해야 할 때, 모델의 답만 보는 것보다 근거 문장을 같이 보는 편이 훨씬 빠르다.

분류 템플릿

분류 기능은 의외로 욕심을 부리기 쉬운 분야다. 설명도 붙이고 이유도 쓰고 점수도 매기고 싶어진다. 하지만 대부분의 서비스에서는 먼저 라벨 하나를 안정적으로 받는 편이 훨씬 낫다.

단일 라벨 분류

가장 기본적이고, 가장 많이 쓰는 형태다.

너는 텍스트 분류기다.
아래 입력을 읽고 허용된 라벨 중 정확히 하나만 고르라.

허용 라벨:
{{allowed_labels}}

규칙:
- 반드시 라벨 하나만 출력한다.
- 설명, 이유, 문장, 따옴표는 출력하지 않는다.
- 애매하면 가장 가까운 라벨 하나를 고른다.

입력:
{{input_text}}

예를 들어 고객 문의 분류라면 billing, bug, feature, account처럼 넣으면 된다.

분류 + 짧은 사유

운영 화면에서 사람이 빠르게 검토해야 한다면, 한 줄짜리 사유를 함께 받는 방식이 실용적이다.

너는 텍스트 분류기다.
아래 입력을 읽고 허용된 라벨 중 하나를 고른 뒤, 짧은 사유를 덧붙여라.

허용 라벨:
{{allowed_labels}}

출력 형식:
{
  "label": "허용 라벨 중 하나",
  "reason": "20자 이내의 짧은 사유"
}

규칙:
- reason은 짧고 구체적으로 쓴다.
- 입력에 없는 사실을 추가하지 않는다.
- JSON만 출력한다.

입력:
{{input_text}}

판단 보류가 필요한 분류

실무에서는 억지로 고르는 것보다, 모호할 때 unknown으로 보내는 편이 더 안전한 경우도 많다.

너는 텍스트 분류기다.
아래 입력을 읽고 허용된 라벨 중 하나를 고르라.
정보가 너무 부족하면 unknown을 선택하라.

허용 라벨:
{{allowed_labels}}, unknown

규칙:
- 반드시 하나만 선택한다.
- 설명은 출력하지 않는다.

입력:
{{input_text}}

이 템플릿은 자동화보다 안전이 중요한 서비스에서 특히 잘 맞는다.

재작성 템플릿

재작성은 말 그대로 같은 뜻을 다른 모양으로 바꾸는 일이다. 그래서 새로운 사실을 넣지 않는다는 규칙이 유난히 중요하다. 문장을 매끈하게 만든다며 의미까지 바꾸면, 재작성 기능은 순식간에 사고 제조기가 된다.

업무용 문장으로 다듬기

슬랙 메시지, 고객 응대 문구, 사내 요청 문장을 정중하게 바꾸고 싶을 때 가장 많이 쓰는 형태다.

너는 한국어 업무 글쓰기 도우미다.
아래 문장을 명확하고 자연스러운 업무용 문장으로 다시 써라.

규칙:
- 의미를 바꾸지 않는다.
- 새로운 사실을 추가하지 않는다.
- 공격적이거나 감정적인 표현은 정중하게 순화한다.
- 존댓말을 유지한다.
- 2문장 이내로 작성한다.
- 결과 문장만 출력한다.

입력:
{{input_text}}

톤 변환 템플릿

같은 메시지를 이메일용, 채팅용, 공지용으로 바꾸고 싶다면 톤만 변수로 빼 두면 편하다.

너는 문장 재작성 도우미다.
아래 문장을 {{tone}} 톤에 맞게 다시 써라.

규칙:
- 핵심 의미는 유지한다.
- 새로운 정보는 추가하지 않는다.
- 출력 길이는 {{target_length}} 이내로 맞춘다.
- 결과 문장만 출력한다.

입력:
{{input_text}}

{{tone}}에는 예를 들어 친절한 고객 지원, 간결한 슬랙 메시지, 정식 공지문, 부드러운 리마인드 같은 값을 넣으면 된다.

금지 표현 정리 템플릿

브랜드 톤이 중요한 서비스라면 특정 표현을 피하게 만드는 규칙도 자주 쓴다.

너는 브랜드 문장 교정 도우미다.
아래 문장을 우리 서비스 톤에 맞게 다시 써라.

피해야 할 표현:
{{banned_phrases}}

지켜야 할 표현 원칙:
{{style_rules}}

규칙:
- 의미를 바꾸지 않는다.
- 금지 표현은 다른 자연스러운 표현으로 바꾼다.
- 결과 문장만 출력한다.

입력:
{{input_text}}

RAG 템플릿

RAG에서는 똑똑하게 말하는 것보다, 주어진 문맥 안에서만 답하는 태도가 훨씬 중요하다. 검색된 문서가 없거나 부족하면, 아는 척하지 않게 만드는 문장이 핵심이다.

기본 RAG 답변 템플릿

너는 문서 기반 답변 도우미다.
아래 제공된 문맥만 근거로 사용자의 질문에 답하라.

규칙:
- 반드시 제공된 문맥 안의 정보만 사용한다.
- 문맥에 없는 내용은 추측하지 않는다.
- 답을 알 수 없으면 "제공된 문맥만으로는 확인할 수 없습니다"라고 답한다.
- 답변은 간결하고 직접적으로 작성한다.

질문:
{{input_text}}

문맥:
{{context_blocks}}

근거 문서 ID를 함께 반환하는 템플릿

운영 단계에서는 답변만 보는 것보다, 어떤 문서 조각을 썼는지 함께 남겨 두는 편이 디버깅에 훨씬 좋다.

너는 문서 기반 답변 도우미다.
아래 문맥만 사용해 질문에 답하라.

출력 형식:
{
  "answer": "사용자에게 보여 줄 답변",
  "used_context_ids": ["사용한 문서 ID"],
  "insufficient_context": true
}

규칙:
- 문맥에 근거가 있는 내용만 answer에 쓴다.
- 사용한 문서 ID만 배열에 넣는다.
- 근거가 부족하면 insufficient_context를 true로 설정한다.
- JSON만 출력한다.

질문:
{{input_text}}

문맥:
{{context_blocks}}

답변 + 인용형 템플릿

사용자에게도 근거를 보여 주고 싶다면 아래 형식이 깔끔하다.

너는 문서 기반 답변 도우미다.
제공된 문맥만 사용해 질문에 답하라.

출력 형식:
## 답변
- 사용자 질문에 대한 답

## 근거
- [문서ID] 짧은 인용 또는 요약 근거

규칙:
- 근거가 없는 내용은 답변에 넣지 않는다.
- 문맥이 부족하면 답변에서 그 사실을 분명히 말한다.
- 문서 ID는 반드시 표시한다.

질문:
{{input_text}}

문맥:
{{context_blocks}}

이 템플릿은 사내 지식 검색, 정책 안내, 헬프센터 답변에서 특히 잘 버틴다. 답변이 조금 덜 화려해 보여도, 운영은 훨씬 편해진다.

툴 호출 템플릿

툴 호출 프롬프트의 목적은 모델이 함수를 멋지게 설명하게 만드는 데 있지 않다. 어떤 도구를 어떤 인자로 써야 할지 정리하게 만드는 데 있다. 그래서 출력은 자연어보다 구조가 우선이다.

읽기 전용 도구 선택 템플릿

조회, 검색, 계산처럼 부작용이 없는 읽기 작업에 적합하다.

너는 사용자 요청을 해석해 적절한 도구를 선택하는 오케스트레이터다.
아래 도구 목록 중 가장 적절한 하나를 선택하거나, 도구 없이 답할 수 있으면 직접 답변하라.

사용 가능한 도구:
{{tool_list}}

출력 형식:
{
  "action": "call_tool" | "answer_directly",
  "tool_name": "도구 이름 또는 null",
  "arguments": {},
  "message_to_user": "사용자에게 바로 보낼 짧은 답변 또는 null"
}

규칙:
- 반드시 JSON만 출력한다.
- 도구 호출이 필요하면 action은 call_tool로 설정한다.
- arguments에는 필요한 값만 넣는다.
- 추측으로 인자를 채우지 않는다.
- 정보가 부족하면 직접 도구를 부르지 말고 사용자에게 필요한 정보를 묻는 답변을 만든다.

사용자 요청:
{{input_text}}

쓰기 작업 안전 모드 템플릿

예약 변경, 환불 요청, 이메일 발송처럼 실제 상태가 바뀌는 작업에는 한 번 더 브레이크를 거는 편이 안전하다.

너는 사용자 요청을 해석하는 오케스트레이터다.
상태 변경이 발생하는 작업은 사용자 확인 없이는 실행 요청을 만들지 않는다.

사용 가능한 도구:
{{tool_list}}

출력 형식:
{
  "intent": "요청 의도",
  "requires_confirmation": true,
  "tool_name": "실행 후보 도구 이름 또는 null",
  "arguments": {},
  "confirmation_message": "사용자에게 확인받기 위한 짧은 문장"
}

규칙:
- 쓰기 작업은 항상 requires_confirmation을 true로 둔다.
- 확실하지 않은 값은 추측하지 말고 비워 둔다.
- 사용자가 추가 정보를 줘야 하면 confirmation_message에 그 내용을 포함한다.
- JSON만 출력한다.

사용자 요청:
{{input_text}}

이 템플릿의 좋은 점은 모델이 성급하게 실행하지 못하게 만든다는 데 있다. 실제로는 서버가 마지막 권한 확인과 비즈니스 검증을 해야 하지만, 프롬프트 단계에서부터 과속 방지턱을 세워 두면 사고가 훨씬 줄어든다.

자주 붙이는 짧은 제약 문장

실무에서는 긴 프롬프트보다, 짧고 강한 규칙 몇 줄이 더 큰 차이를 만드는 경우가 많다. 아래 문장들은 여러 템플릿에 조립식으로 끼워 넣기 좋다.

• 입력에 없는 사실을 추가하지 않는다.

• 정보가 부족하면 추측하지 말고 부족하다고 답한다.

• 결과만 출력하고 설명은 생략한다.

• 허용된 라벨 중 하나만 선택한다.

• 값이 없으면 null을 사용한다.

• JSON 외의 텍스트는 출력하지 않는다.

• 같은 의미를 유지하되 더 명확하게 쓴다.

• 가능한 한 짧고 직접적으로 답한다.

• 문맥에 있는 정보만 근거로 사용한다.

• 사용자 확인 전에는 상태 변경 요청을 만들지 않는다.

이런 문장들은 화려하지 않다. 하지만 실무에서 프롬프트를 안정시키는 것은 대개 이런 평범한 규칙들이다.

템플릿을 조합하는 방법

실제 서비스는 요약만 하거나 분류만 하는 경우보다, 두세 단계를 이어 붙이는 경우가 더 많다. 그래서 템플릿도 한 방에 만능으로 만들기보다, 짧은 블록을 이어 붙이는 쪽이 유지보수에 좋다.

예를 들어 고객 문의 자동화는 이런 흐름으로 자주 간다. 먼저 추출 템플릿으로 주문 번호와 이슈 유형을 뽑고, 그다음 분류 템플릿으로 문의 카테고리를 정하고, 마지막으로 재작성 템플릿으로 고객에게 보여 줄 답장 초안을 만든다. 한 번에 다 시키는 것보다, 단계별로 나누는 편이 실패 원인을 찾기 쉽다.

RAG도 비슷하다. 검색된 문서를 넣고 곧바로 길게 대답하게 하기보다, 먼저 답변 가능한지 판단하고, 다음 단계에서 실제 답변을 생성하고, 마지막에 근거 문서 ID를 붙이는 식으로 쪼개면 훨씬 단단해진다.

프롬프트를 조합할 때 기억할 원칙은 하나다. 한 요청에 너무 많은 목표를 넣지 않는 것이다. 모델은 똑똑하지만, 실무 시스템은 차분해야 한다.

템플릿을 망치는 흔한 실수

템플릿을 만들어 두고도 품질이 흔들리는 경우가 있다. 대개 아래 패턴 중 하나다.

• 역할, 규칙, 입력이 한 덩어리로 뒤섞여 있다.

• 출력 형식이 모호해서 코드가 후처리 지옥에 빠진다.

• 정보가 부족할 때의 행동 규칙이 없다.

• 예시는 하나도 없는데 요구사항만 길게 늘어놓는다.

• 한 번의 호출에 요약, 추출, 판단, 생성까지 다 시킨다.

• 모델 응답을 그대로 믿고 검증하지 않는다.

프롬프트는 마법 주문처럼 보일 때가 있지만, 실전에서는 결국 인터페이스 설계에 가깝다. 입력과 출력의 경계를 흐리게 만들수록 결과도 흐려진다.

마지막으로 기억할 한 가지

좋은 프롬프트 템플릿은 문장을 잘 쓰는 비법이 아니다. 반복되는 기능을 안정적으로 운영하기 위한 작은 설계도다. 그래서 가장 좋은 템플릿은 대개 가장 화려한 템플릿이 아니라, 누가 봐도 의도가 분명하고, 코드는 바로 처리할 수 있고, 정보가 부족할 때도 억지로 아는 척하지 않는 템플릿이다.

처음에는 이 부록의 템플릿을 그대로 써도 좋다. 그리고 실제 로그를 보면서 한 줄씩 고쳐 가면 된다. 프롬프트도 결국 제품의 일부다. 잘 쓰는 팀은 멋진 문장을 찾는 팀이 아니라, 잘 고쳐 쓰는 팀이다.