템플릿 10개가 '내 전용 AI 팀'이 되는 이유
실무에서 Gemini를 잘 쓰는 사람은 프롬프트를 "매번 새로 쓰는 문장"이 아니라 "업무를 반복 가능하게 만드는 양식"으로 취급합니다. 같은 종류의 일을 매번 다른 말로 시키면 결과물의 모양도 매번 달라지고, 결국 당신이 편집자·품질관리자 역할까지 떠맡게 됩니다.
반대로 템플릿은 업무 요청서의 표준 운영절차(SOP)입니다. 한 번 제대로 만들어 두면, 다음부터는 입력값만 바꿔도 품질과 형식이 비슷하게 재현됩니다. 프롬프트 패턴을 "재사용 가능한 구조"로 이해하고, 상황에 맞게 2~4개를 조합하는 습관이 핵심입니다.1
이 챕터의 목표는 단순합니다. 요약/비교/리라이팅/기획/리스크 점검 같은 반복 업무 10종을 템플릿으로 고정해, Gemini를 '내 전용 AI 팀'처럼 굴리는 기준선을 만드는 것입니다.
템플릿은 '패턴' 위에 세운다
템플릿은 결국 "잘 되는 프롬프트의 반복 가능한 골격"입니다. 골격을 만들 때 도움이 되는 것이 프롬프트 패턴입니다. 예를 들어 역할(페르소나), 출력 형식 고정, 제약 쌓기, 단계 분해, 자기 점검 같은 패턴은 모델이 흔들리기 쉬운 지점(목표/형식/누락/환각)을 잡아줍니다.1
복잡한 업무일수록 패턴의 효용은 커집니다. 복잡한 작업이 어려운 이유는 목표와 제약이 모호하고, 여러 단계 추론이 필요하며, 품질 기준(루브릭)을 말로 적지 않으면 모델이 제멋대로 기준을 세우기 때문입니다.2
여기서 좋은 소식은 하나입니다. 패턴은 '트릭'이 아니라 업무 지시서의 문장화라는 점입니다. 즉, 템플릿은 "누구나 따라할 수 있는 SOP 문장"이 됩니다.
ROADS로 '기본 양식'을 먼저 고정한다
이미 5장에서 기본 틀을 익혔다면, 6장에서는 그 위에 재사용 전용 베이스 프레임을 얹습니다. 복잡한 작업에서는 ROADS가 특히 유용합니다.2
ROADS는 다음 다섯 칸을 고정합니다.2
Role: 어떤 직무/관점으로 일할지
Objective: 단 하나의 분명한 목표
Audience: 결과물을 누가 읽는지
Deliverables: 산출물의 섹션/필드/형식
Standards: 제약, 톤, 길이, 근거 규칙, 금지 사항
이 다섯 칸을 템플릿 상단에 박아두면, 프롬프트가 길어져도 중심이 흔들리지 않습니다. 또한 팀에서 공유할 때 "왜 이렇게 시키는지"가 읽히기 때문에 SOP로 굳히기 좋습니다.
템플릿을 SOP로 만드는 3가지 장치
템플릿을 단순한 복붙 문장이 아니라 SOP로 만들려면, 아래 장치를 의도적으로 넣어야 합니다.
첫째, 변수 슬롯을 만든 뒤(예: {대상}, {목적}, {분량}) 값만 바꾸게 합니다.
둘째, STOP 지점을 둬서 큰 작업을 단계로 끊습니다(예: "계획만 내고 멈춰라"). 이는 복잡한 작업에서 드리프트(제약 무시, 누락)를 줄이는 가장 쉬운 방법입니다.2
셋째, 검증 루프를 붙입니다. 예를 들어 CoVe(Chain-of-Verification)는 "답 A를 낸 다음, 가정/엣지 케이스/근거를 점검해 A'로 수정"하도록 강제합니다.3
템플릿 라이브러리 운영: 저장보다 '관리'가 성능이다
템플릿은 10개만 잘 관리해도 체감 효율이 큽니다. 다만 "어딘가에 저장"으로 끝내면 금방 유실됩니다. SOP답게 운영하려면, 최소한 아래 원칙을 추천합니다.
이름 규칙(검색 가능하게)
템플릿 이름은 업무-산출물-버전 형태가 안정적입니다. 예: 요약_임원브리프_v1, 비교_도입의사결정_v2.
메타데이터(언제 쓰는지 한 줄)
각 템플릿 상단에 "언제 쓰는지/입력 예시/금지 사항"을 2~3줄로 적어두면, 미래의 내가 헤매지 않습니다.
미니 테스트 세트(품질을 눈으로 확인)
템플릿마다 대표 입력 2개만 정해두고, 수정할 때마다 같은 입력으로 돌려보면 품질 변화가 눈에 보입니다. 패턴 가이드에서도 "패턴을 조합해 만든 프롬프트를 저장하고, 필요하면 하나를 빼 보며 무엇이 효용인지 확인"하라고 권합니다.1
바로 써먹는 SOP 템플릿 10개
아래 템플릿은 그대로 복사해 {중괄호}만 채우면 됩니다. 가능하면 상단의 ROADS 블록을 지우지 말고 유지하세요(팀 공유 시 특히 강력합니다).2
1) 요약 SOP: '핵심-리스크-다음 행동'으로 끝내기
[ROADS]
Role: 너는 {직무: PM/컨설턴트/운영담당}이다.
Objective: 아래 자료를 의사결정/공유에 바로 쓰이게 요약한다.
Audience: {대상: 임원/팀/고객}.
Deliverables: 제목, 핵심요점, 리스크, 다음 행동.
Standards: 원문에 없는 내용은 만들지 말고, 불확실하면 '불확실'로 표시.
[TASK]
아래 내용을 요약하라.
[FORMAT]
1) 제목(한 줄)
2) 핵심 요점: 정확히 5개(각 1문장)
3) 리스크/불확실성: 2개
4) 다음 행동: 3개(각 항목에 담당 역할 포함)
[CONSTRAINT]
- 전체 {분량: 250~400자}
- 과장/광고 문구 금지
[INPUT]
{원문/메모/붙여넣기}2) 비교 SOP: 표로 비교하고 '추천 1개'까지 고정
[ROADS]
Role: 너는 객관적인 도입/구매 평가자다.
Objective: {옵션A} vs {옵션B}를 비교해 추천을 내린다.
Audience: {대상: 의사결정자/실무팀}.
Deliverables: 비교표 + 결론 + 리스크.
Standards: 추정은 '추정'으로 표시하고, 모호하면 질문으로 남긴다.
[TASK]
두 옵션을 아래 기준으로 비교하고 추천하라.
[FORMAT]
- 비교표(마크다운)
- 열: 기준 | 옵션A | 옵션B | 비고
- 행: 정확히 7개 기준
- 결론(3문장): 추천 1개 + 이유 2개
- 리스크 2개 + 완화 방안 2개
[CONTEXT]
- 우리 상황: {예산/일정/인력/기술수준}
- 우선순위(가중치): {예: 비용40/속도30/확장성30}
[INPUT]
{비교할 정보(스펙/가격/제약/링크 요약)}3) 리라이팅 SOP: 같은 의미, 다른 옷(대상/톤/길이)
[ROADS]
Role: 너는 편집자이자 카피 에디터다.
Objective: 원문의 의미를 유지한 채, 새 독자/톤에 맞게 다시 쓴다.
Audience: {새 독자}
Deliverables: 1) 리라이팅 2) 변경 요약
Standards: 의미 보존, 과장 금지, 정보 추가 금지.
[TASK]
아래 텍스트를 리라이팅하라.
[CONTEXT]
- 목적: {설득/안내/보고/공지}
- 톤: {예: 단정하고 친절/간결하고 단호/격식}
- 길이: {예: 200자 내/3문단}
- 반드시 포함: {키워드/문장/CTA}
- 반드시 피하기: {금지 표현 3개}
[FORMAT]
1) 리라이팅 본문
2) 변경 요약: 정확히 3줄(무엇을/왜/효과)
[INPUT]
{원문}4) 기획 SOP: 한 장 기획서(목표-대상-범위-성공지표)
[ROADS]
Role: 너는 {직무: PO/마케터/프로젝트리드}다.
Objective: {주제}에 대한 실행 가능한 한 장 기획서를 만든다.
Audience: {대상: 팀/리더/협업부서}.
Deliverables: 문제, 목표, 범위, 일정, 리스크.
Standards: 모르면 가정/질문으로 분리한다.
[TASK]
아래 정보를 바탕으로 한 장 기획서를 작성하라.
[FORMAT]
## 1. 배경/문제정의(3문장)
## 2. 목표(정량 KPI 3개)
## 3. 대상(핵심 페르소나 1개)
## 4. 범위
- 포함(In): 5개
- 제외(Out): 5개
## 5. 실행 계획(2주 단위 마일스톤 4개)
## 6. 의사결정이 필요한 질문(정확히 3개)
[INPUT]
- 주제: { }
- 현재 상황/제약: { }
- 사용할 자료(있으면): { }5) 리스크 점검 SOP: '법무/보안/운영' 관점 체크리스트
[ROADS]
Role: 너는 리스크 리뷰어(법무/보안/운영 관점)다.
Objective: 아래 초안의 리스크를 찾아 수정 방향을 제시한다.
Audience: {대상: 작성자/리더}.
Deliverables: 리스크 목록 + 완화책 + 수정안.
Standards: 추측은 표시하고, 사실 단정 금지.
[TASK]
아래 초안을 리스크 관점에서 점검하라.
[FORMAT]
1) 핵심 리스크 Top 7(각 항목에 심각도: 높음/중간/낮음)
2) 리스크별 완화 방안(각 1개)
3) 수정 권고 문장(원문에서 바꿔 쓸 대체 문장 5개)
[CONSTRAINT]
- '문제없음' 결론 금지(반드시 개선점 제시)
- 모르는 전제는 '추가 확인 필요'로 표시
[INPUT]
{초안/정책/공지/약관/제안서}6) 회의록→액션아이템 SOP: 실행으로 변환하는 템플릿
[ROADS]
Role: 너는 회의록 전문 비서다.
Objective: 회의 내용을 실행 가능한 작업 목록으로 바꾼다.
Audience: 회의 참석자 및 이해관계자.
Deliverables: 결정사항, 액션아이템, 미확정 질문.
Standards: 회의에 없던 내용은 만들지 않는다.
[TASK]
아래 회의 텍스트를 실행형 회의록으로 정리하라.
[FORMAT]
## 요약(3문장)
## 결정사항(3~7개)
## 액션 아이템(표: 담당 | 할 일 | 기한 | 의존성 | 상태)
## 미확정 질문(정확히 3개)
[CONSTRAINT]
- 담당이 불명확하면 '담당 미정'
- 기한이 없으면 '기한 미정'
[INPUT]
{회의 메모/녹취/채팅 로그}7) 이해관계자 메시지 SOP: '상황-영향-요청' 구조로 통일
[ROADS]
Role: 너는 이해관계자 커뮤니케이션 담당자다.
Objective: 오해 없이 빠르게 합의를 만든다.
Audience: {수신자: 리더/협업팀/고객}.
Deliverables: 제목 + 본문 + 다음 단계.
Standards: 모호한 표현을 피하고, 요청/기한을 명시한다.
[TASK]
아래 상황에 맞는 메시지를 작성하라.
[FORMAT]
- 제목 3개
- 본문: 3문단(상황 → 영향 → 요청/다음 단계)
- 마지막 줄: 필요한 답변 형식(예: 'A/B 중 선택', '가능한 시간 2개 회신')
[CONTEXT]
- 채널: {이메일/슬랙/카톡}
- 톤: {정중/단호/차분}
- 기한: {YYYY-MM-DD}
[INPUT]
{상황 설명}8) 계획 먼저, 실행은 멈추기(Plan-Then-Act): 큰 일을 '단계로 통제'
복잡한 작업은 먼저 계획을 받아 보고, 승인한 뒤에 1단계만 실행하게 하면 재작업이 급격히 줄어듭니다.2
[ROADS]
Role: 너는 실행 코치다.
Objective: {목표}를 최소 재작업으로 완수한다.
Audience: 나(실행 책임자).
Deliverables: 단계 계획 + 1단계 산출물.
Standards: 각 단계는 검증 가능해야 한다.
[TASK]
1) 먼저 전체 단계를 3~6개로 제시하라.
2) 각 단계마다 '입력/출력/검증 기준'을 한 줄로 써라.
3) 내 확인을 요청하고 STOP하라.
[INPUT]
- 목표: {예: 제안서 작성/교육 커리큘럼/리서치 보고서}
- 제약: {기간/분량/대상/금지사항}
- 사용 자료: {있으면}9) 근거 고정 SOP: 제공 자료만 쓰고, 없으면 '없다'고 말하기
사실성(근거)이 중요한 문서에서는 "아는 걸 섞지 말고, 제공 자료만 사용"을 명시하는 것이 안전합니다. 출처 기반 답변(Source-Grounded Answer)은 그런 상황에서 환각을 줄이는 전형적인 패턴입니다.2
[ROADS]
Role: 너는 근거 중심 분석가다.
Objective: 제공된 자료에서만 근거를 뽑아 요약/주장을 만든다.
Audience: {대상}.
Deliverables: 주장 + 근거 + 불확실성.
Standards: 자료 밖 정보는 '자료에 없음'으로 표시.
[TASK]
아래 자료만 사용해 답하라.
[FORMAT]
1) 결론 요약(3문장)
2) 근거(항목 5개): 각 항목 끝에 (근거: {자료 위치/인용문})
3) 불확실/추가 확인 필요(정확히 3개)
[CONSTRAINT]
- 제공 자료에 없는 사실은 단정 금지
- 추정이 필요하면 '추정'으로 라벨링
[INPUT]
{자료/발췌/링크 요약/문서 내용}10) 검증 루프 SOP(CoVe): "답→검증→수정"을 자동으로 돌리기
결과물 품질이 중요한 작업(대외문, 계약/정책 초안, 고위험 의사결정 메모)에서는 "한 번에 완성"보다 "한 번 만든 뒤 검증"이 더 안정적입니다. CoVe는 답 A를 먼저 만든 다음, 가정·엣지 케이스·근거를 점검해 A'로 교정하는 패턴입니다.3
[ROADS]
Role: 너는 작성자이자 검증자다.
Objective: {산출물}의 오류/누락을 줄여 최종본을 만든다.
Audience: {대상}.
Deliverables: 초안 A, 검증, 수정본 A'.
Standards: 과장/추정/근거 부족을 표시한다.
[TASK]
아래 입력으로 산출물을 만든 뒤, 검증 루프를 수행하라.
[PROCESS]
1) 초안 A를 작성한다.
2) A를 검증한다:
- 가정(Assumptions) 5개를 나열하고 타당성을 점검
- 엣지 케이스(Edge cases) 5개를 점검
- 근거가 필요한 주장 5개를 표시(근거 부족이면 '근거 필요')
3) 검증 결과를 반영해 수정본 A'를 제시한다.
4) 마지막에 '무엇이 바뀌었는지'를 5줄로 요약한다.
[INPUT]
{초안 작성에 필요한 정보/원문/요구사항}템플릿 조합 레시피: 최소 조합으로 최대 효과
현장에서 가장 자주 쓰는 조합은 "역할 + 형식 고정 + 제약"처럼 단순한 3종 세트입니다.1 여기에 업무 성격에 따라 하나만 더 얹으면 됩니다.
팩트가 중요하면 9번(근거 고정)이나 10번(검증 루프)을 붙이고, 일이 크면 8번(계획 후 실행)을 먼저 적용합니다.23
참고
1Prompt Patterns Cheat Sheet: 12 Reusable Patterns for Better AI Outputs (2026)
2Advanced Prompt Patterns: Templates That Tame Complex AI Tasks
3Advanced Prompting Techniques for 2025: ReAct, Toolformer, Self‑Consistency
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.