프롬프트 템플릿 설계 – 재사용 가능한 모듈형 시스템 만들기
프롬프트도 코드처럼 관리된다. 변수와 템플릿으로 반복을 없애고 시스템을 설계한다.
들어가며: 프롬프트를 20번 쓰고 있다면, 잘못된 것이다
블로그 포스트 초안 10개를 AI로 작성한다고 가정합니다. 주제만 다를 뿐, 요청 방식은 동일합니다. 같은 어조, 같은 출력 형식, 같은 글자 수 제약. 매번 새 프롬프트를 타이핑하거나, 이전 것을 복사해서 주제만 수정합니다.
이 과정에서 두 가지 문제가 발생합니다.
첫 번째는 비효율입니다. 구조는 동일한데 매번 처음부터 씁니다. 두 번째는 불일관성입니다. 조금씩 다르게 수정된 10개의 프롬프트는 미묘하게 다른 결과를 냅니다. 9번째 포스트가 1번째와 다른 톤으로 나와도 그 이유를 추적할 수 없습니다.
소프트웨어 개발에서 같은 코드를 10번 복사하는 행위는 나쁜 코드입니다. 프롬프트 엔지니어링도 동일한 기준이 적용됩니다.
해결책은 단순합니다. **변하지 않는 구조(템플릿)**와 **변하는 값(변수)**을 분리하는 것입니다. 이것이 7편의 전부입니다.
1. 변수의 본질: 상수와 변수를 분리하라
1.1. 프롬프트를 함수로 바라보기
프로그래밍에서 같은 로직을 반복하면 함수로 추출합니다. 함수는 파라미터를 받고, 결과를 반환합니다. 프롬프트도 정확히 같은 방식으로 설계할 수 있습니다.
# 함수 관점으로 본 프롬프트
generate_blog_post(topic, tone, word_count, audience) → 초안
topic이 바뀌어도 tone, word_count, audience를 매번 다시 설계할 필요가 없습니다. 구조는 고정, 입력만 교체.
1.2. Before / After: 변수 없이 vs 변수 있이
Before — 매번 처음부터 쓰는 프롬프트:
너는 IT 기술 블로그 전문 작가야. "Next.js App Router 완전 정복"이라는 주제로
SEO에 최적화된 블로그 포스트 초안을 작성해줘. 독자는 웹 개발 입문자야.
어조는 친근하고 실용적으로. 800자 이내로.
이걸 다음 주제인 "TypeScript 제네릭"으로 바꾸려면? 문장 전체를 다시 씁니다.
After — 변수가 있는 프롬프트 템플릿:
너는 IT 기술 블로그 전문 작가야. "{{topic}}"이라는 주제로
SEO에 최적화된 블로그 포스트 초안을 작성해줘. 독자는 {{audience}}야.
어조는 {{tone}}으로. {{word_count}}자 이내로.
다음 포스트를 만들 때는 값만 교체합니다:
{{topic}}= "TypeScript 제네릭 완전 정복"{{audience}}= "중급 개발자"{{tone}}= "기술적이고 간결하게"{{word_count}}= 1200
구조는 한 번 설계. 이후에는 변수만 채웁니다.
| 구분 | 변수 없음 | 변수 있음 |
|---|---|---|
| 새 작업 준비 | 전체 재작성 | 값만 교체 |
| 출력 일관성 | 낮음 (매번 다름) | 높음 (구조 고정) |
| 오류 추적 | 불가 | 변수 단위 추적 가능 |
| 팀 공유 | 어려움 | 템플릿 공유 가능 |
2. 변수 유형: 다섯 가지를 구분해서 사용하라
변수는 모두 같지 않습니다. 역할에 따라 다섯 가지로 분류하고, 각각 다른 방식으로 처리해야 합니다.
2.1. 필수 변수 (Required)
반드시 값을 채워야 하는 변수입니다. 비어있으면 실행하지 않습니다.
표기: {{variable_name}}
예시:
분석 대상: {{target_text}}
2.2. 선택 변수 (Optional)
있어도 되고 없어도 되는 변수입니다. 없으면 해당 조건을 무시합니다.
표기: {{variable_name?}}
예시:
추가 제약사항: {{constraints?}}
(없으면 기본 설정을 따릅니다.)
2.3. 기본값 변수 (Default)
값이 없을 때 대신 사용할 값을 미리 지정합니다.
표기: {{variable_name:default_value}}
예시:
출력 언어: {{lang:한국어}}
글자 수 제한: {{word_count:800}}
값을 명시하지 않으면 자동으로 "한국어", "800자"가 적용됩니다.
2.4. 조건 변수 (Conditional)
특정 조건에 따라 프롬프트의 일부 블록 전체를 포함하거나 제외합니다.
표기: {{#if condition}} ... {{/if}}
예시:
{{#if include_summary}}
마지막에 3줄 요약을 추가해줘.
{{/if}}
include_summary = true일 때만 요약 지시가 프롬프트에 포함됩니다.
2.5. 반복 변수 (Loop)
리스트 형태의 입력을 순회하며 동일한 처리를 반복합니다.
표기: {{#each items}} ... {{/each}}
예시:
다음 항목들을 각각 한 문장으로 요약해줘:
{{#each paragraphs}}
- {{this}}
{{/each}}
3. 템플릿 해부학: 4구역 구조
잘 설계된 프롬프트 템플릿은 네 개의 구역으로 구성됩니다. 각 구역의 순서와 역할을 이해하면 어떤 작업에도 적용 가능한 구조를 만들 수 있습니다.
3.1. 4구역의 역할
[CONTEXT] — 누가, 어떤 상황에서 (Persona + Situation)
[INSTRUCTION] — 무엇을 어떻게 (Action + Method)
[INPUT] — 처리할 실제 데이터 (Variables)
[OUTPUT] — 출력 형식과 제약 (Format + Constraints)
3.2. 4구역 템플릿 예시: 기술 문서 번역기
[CONTEXT]
너는 IT 기술 문서 전문 번역가야. {{source_lang}}과 {{target_lang}}에 모두 능통하며,
기술 용어를 정확하게 유지하면서도 자연스러운 문체를 구사해.
대상 독자: {{audience}}
[INSTRUCTION]
아래 텍스트를 {{target_lang}}으로 번역해줘.
번역 원칙:
1. 기술 용어(API, 라이브러리명 등)는 원문 그대로 유지
2. 문어체 → {{target_tone}} 어조로 변환
3. 의미가 모호한 부분은 [주: 원문: xxx] 형식으로 주석 추가
{{#if preserve_formatting}}
4. 원문의 마크다운 포맷(헤더, 코드블록, 리스트)을 그대로 유지
{{/if}}
[INPUT]
번역 대상 텍스트:
---
{{source_text}}
---
[OUTPUT]
- 번역문만 출력 (설명 없이)
- 마크다운 포맷 유지
- {{word_limit?}}자 제한이 있는 경우 초과 시 자연스러운 위치에서 절단 후 "[계속]" 표기
이 템플릿 하나로 영→한, 한→영, 기술 문서, 마케팅 카피 등 다양한 번역 작업을 처리할 수 있습니다. 바뀌는 것은 변수뿐입니다.
4. 모듈형 시스템: 레고처럼 조립하는 프롬프트
템플릿 하나는 단일 작업을 처리합니다. 하지만 실제 업무는 여러 단계가 연결된 파이프라인입니다. 이 단계들을 독립적인 모듈로 만들고 조합하면, 복잡한 작업 흐름 전체를 자동화할 수 있습니다.
4.1. 원자 모듈: 재사용의 최소 단위
원자(Atomic) 모듈은 단 하나의 역할만 수행하는 가장 작은 프롬프트 단위입니다.
# 원자 모듈 예시
[tone_module]
어조: {{tone}} (공식적 / 친근한 / 기술적 / 설득적 중 하나)
[format_module]
출력 형식:
- 제목: H2 헤더
- 본문: 문단 단위 구분
- 핵심 키워드: **굵게** 표시
[audience_module]
독자 수준: {{audience_level}} (입문자 / 중급자 / 전문가)
전문 용어: {{terminology_policy}} (풀어서 설명 / 그대로 사용)
이 모듈들은 독립적으로도 쓸 수 있고, 다른 템플릿에 끼워 넣을 수도 있습니다.
4.2. 복합 모듈: 원자를 조합한다
복합(Composite) 모듈은 여러 원자 모듈을 조합해 하나의 완성된 역할을 수행합니다.
# 복합 모듈: 블로그 포스트 생성기
[CONTEXT]
너는 IT 기술 블로그 전문 작가야.
{{audience_module}} ← 원자 모듈 삽입
[INSTRUCTION]
"{{topic}}"을 주제로 블로그 포스트 초안을 작성해줘.
SEO 핵심 키워드: {{seo_keywords}}
[OUTPUT]
{{format_module}} ← 원자 모듈 삽입
{{tone_module}} ← 원자 모듈 삽입
글자 수: {{word_count:1000}}자 이내
4.3. 파이프라인: 모듈을 순서대로 연결한다
콘텐츠 제작 전체 흐름을 예시로, 3단계 파이프라인을 구성합니다.
[Step 1: 리서치 모듈]
입력: {{topic}}, {{depth_level}}
출력: 핵심 논점 5개 + 관련 데이터 목록
↓ 출력을 다음 스텝의 {{research_result}}로 전달
[Step 2: 초안 생성 모듈]
입력: {{research_result}}, {{tone}}, {{word_count}}
출력: 구조화된 블로그 초안
↓ 출력을 다음 스텝의 {{draft}}로 전달
[Step 3: 리뷰 & 개선 모듈]
입력: {{draft}}, {{review_criteria}}
출력: 수정된 최종본 + 변경 사항 요약
각 단계의 출력이 다음 단계의 입력이 됩니다. 이 구조에서 하나의 모듈을 교체하거나 업그레이드해도 전체 파이프라인이 영향받지 않습니다.
5. 실전 템플릿 라이브러리: 지금 바로 사용 가능한 3개
이론을 적용한 완성 템플릿입니다. 변수 값만 채워서 바로 사용하세요.
5.1. 코드 리뷰 템플릿
[CONTEXT]
너는 {{tech_stack}} 전문 시니어 개발자야.
코드 품질, 성능, 보안 세 관점에서 균형 잡힌 리뷰를 제공해.
[INSTRUCTION]
아래 코드를 리뷰해줘.
리뷰 기준:
- 버그 가능성 (Critical / Warning / Info로 분류)
- 성능 개선 포인트
- 보안 취약점
{{#if include_refactor}}
- 리팩토링 제안 (개선된 코드 스니펫 포함)
{{/if}}
[INPUT]
리뷰 대상 코드:
\`\`\`{{language}}
{{code}}
\`\`\`
[OUTPUT]
## 리뷰 요약
- Critical: (건수)
- Warning: (건수)
- Info: (건수)
## 상세 피드백
(항목별 설명)
5.2. 회의록 → 액션 아이템 추출 템플릿
[CONTEXT]
너는 프로젝트 매니저 어시스턴트야.
회의 내용에서 실행 가능한 결정 사항만 추출하는 것이 목적이야.
모호한 언급은 액션 아이템으로 처리하지 않는다.
[INSTRUCTION]
아래 회의록에서 액션 아이템을 추출해줘.
추출 기준:
- 담당자가 명확히 지정된 것만 포함
- 기한이 언급된 경우 반드시 기재
- 의사결정 사항과 실행 항목을 구분
[INPUT]
회의록:
---
{{meeting_notes}}
---
참여자: {{participants?}}
[OUTPUT]
## 의사결정 사항
| 결정 내용 | 결정자 |
|----------|--------|
## 액션 아이템
| 항목 | 담당자 | 기한 | 우선순위 |
|------|--------|------|----------|
## 미결 사항 (추가 논의 필요)
- (항목 없으면 "없음" 표기)
5.3. 데이터 분석 보고서 템플릿
[CONTEXT]
너는 데이터 분석 전문가야. {{domain}} 도메인에 익숙하며,
비기술적 의사결정자도 이해할 수 있는 언어로 인사이트를 전달하는 것을 중시해.
[INSTRUCTION]
아래 데이터를 분석하고 보고서를 작성해줘.
분석 관점: {{analysis_focus}} (트렌드 / 이상치 / 비교 / 예측 중 선택)
강조할 비즈니스 질문: {{business_question}}
[INPUT]
데이터:
{{data}}
기간: {{period?}}
비교 기준: {{baseline?}}
[OUTPUT]
## 핵심 발견 (Executive Summary, 3줄 이내)
## 상세 분석
(분석 내용)
## 비즈니스 시사점
(의사결정자용 제언)
## 한계 및 주의사항
(데이터 신뢰도, 분석 범위 등)
결론: 프롬프트도 코드처럼 관리된다
변수와 템플릿을 도입하는 순간, 프롬프트는 일회성 지시문에서 재사용 가능한 자산으로 변합니다.
단일 프롬프트를 잘 쓰는 것은 '사용자'의 영역입니다. 프롬프트를 시스템으로 설계하는 것은 '엔지니어'의 영역입니다. 변수로 추상화하고, 템플릿으로 구조화하고, 모듈로 조립하는 이 세 단계가 그 경계선입니다.
실용적인 적용 방법
지금 당장 아래 세 가지만 실천해 보세요.
- 반복하는 프롬프트를 찾아라. 주 3회 이상 비슷한 구조로 쓰는 프롬프트가 있다면 그것이 첫 번째 템플릿 후보입니다.
- 변하는 부분을
{{변수}}로 표시하라. 나머지는 구조가 됩니다. - 출력 형식을 고정하라.
[OUTPUT]구역을 명시하는 것만으로 일관성이 크게 향상됩니다.
8편을 향하여: Self-Consistency
템플릿으로 일관된 구조를 확보했다면, 다음 질문은 **"같은 질문을 여러 번 물어서 더 정확한 답을 얻을 수 있는가"**입니다.
이어지는 **[8편: Self-Consistency – 여러 추론 경로로 정답률 끌어올리기]**에서는 동일한 프롬프트를 복수로 실행하고 그 결과를 통합해 단일 실행보다 훨씬 높은 정확도를 달성하는 기법을 다룹니다. 특히 정답이 하나인 문제(수학 계산, 논리 추론, 분류)에서 이 기법의 효과는 극적입니다.
