부록 체크리스트와 설계 템플릿

컨텍스트 설계는 감으로 하면 매번 흔들리고, 점검표로 하면 반복 가능한 작업이 된다. 핵심은 거창하지 않다. 모델이 이번 호출에서 정확히 무엇을 봐야 하는지 정하고, 나머지는 과감히 치우는 것이다. 결국 좋은 결과는 멋진 문장 한 줄보다, 작은 작업 정의와 필요한 정보, 도구 정책, 출력 형식이 단단하게 맞물릴 때 나온다.¹²

이 부록을 쓰는 법

실무에서는 처음부터 완벽한 프롬프트를 만들려고 애쓰기보다, 먼저 작업을 한 문장으로 정의하고, 필요한 컨텍스트를 채우고, 작은 예제로 여러 번 시험해 보는 편이 훨씬 잘 통한다. 구조화된 템플릿은 결과의 일관성을 높여 주고, 반복 테스트는 숨은 실패 조건을 빨리 드러낸다.⁴⁵

권장 순서는 단순하다.

1. 먼저 작업을 한 문장으로 적는다.

2. 아래 체크리스트로 빈칸을 채운다.

3. 가장 가까운 템플릿 하나를 골라 붙여 넣는다.

4. 작은 입력으로 시험한 뒤, 실패 이유를 기록하고 한 항목씩 수정한다.

급할수록 한 번에 다 넣지 않는 편이 좋다. 모델에게 창고 전체를 들이붓는다고 더 똑똑해지지는 않는다. 오히려 중요한 지시가 박스 더미 밑으로 깔린다.

컨텍스트 설계 체크리스트

아래 항목은 순서대로 점검하면 된다. 실전에서는 write, select, compress, isolate라는 네 가지 감각을 함께 쓰게 된다. 필요한 것은 밖에 기록하고, 지금 필요한 것만 고르고, 길어지면 압축하고, 충돌하면 분리하는 식이다.³

1. 작업 정의

가장 먼저 할 일은 작업을 한 문장으로 못 박는 것이다.

• 이 작업을 한 문장으로 설명할 수 있다: X를 받아 Y를 만들고 Z를 최적화하며 C 제약을 지킨다.

• 누가 이 결과를 읽는지 분명하다. 예: 고객, 팀장, 개발자, 일반 사용자.

• 성공 기준이 보인다. 예: 정확한 요약, 실행 가능한 초안, 정책 위반 없는 답변.

• 하지 말아야 할 일도 적었다. 예: 추측 금지, 법률 해석 금지, 최신 정보 단정 금지.

• 한 번의 응답으로 끝나는지, 도구 호출과 여러 턴이 필요한지 구분했다.

작업 정의가 흐리면 평가도 흐려진다. AI가 이상한 답을 내놨을 때도 무엇이 실패인지 말하기 어려워진다.

2. 넣을 정보 고르기

좋은 컨텍스트는 많이 넣는 일이 아니라, 맞는 것을 넣는 일이다.

• 항상 유지되는 규칙은 시스템 지시문 쪽에 둔다.

• 매번 바뀌는 사실은 검색이나 도구로 실행 시점에 가져온다.

• 긴 문서는 통째로 넣지 않고 필요한 부분만 발췌하거나 요약한다.

• 현재 질문과 직접 관련 없는 배경 설명은 뺐다.

• 같은 내용을 다른 말로 반복하는 조각이 없는지 확인했다.

헷갈릴 때는 이렇게 자문하면 된다. 이 정보가 없으면 모델이 틀릴 가능성이 커지는가? 아니라면 일단 빼는 쪽이 안전하다.¹²

3. 지식과 검색

모델이 원래 아는 내용과, 지금 찾아와야 하는 내용은 분리해서 다뤄야 한다.

• 최신성 여부를 판단했다. 최신 정보가 중요하면 검색 또는 데이터 조회를 우선한다.

• 검색 결과의 신뢰 기준을 정했다. 예: 공식 문서 우선, 최근 문서 우선, 내부 문서 우선.

• 검색된 조각에 출처, 날짜, 문서 종류 같은 메타데이터를 붙일 수 있다.

• 충돌하는 문서가 있을 때 우선순위를 정해 두었다. 예: 최신 정책 > 오래된 FAQ.

• 근거 부족 시의 기본 행동을 정했다. 예: 모른다고 답하기, 추가 확인 요청하기.

검색은 정답 보장 장치가 아니다. 검색 품질이 낮으면 그럴듯한 오답이 더 당당해질 뿐이다.

4. 기억

기억은 편리하지만, 방치하면 오래된 메모가 현재 작업을 망친다.

• 이번 세션에만 필요한 단기 기억과, 다음 세션에도 남길 장기 기억을 구분했다.

• 저장할 항목을 좁혔다. 예: 사용자 선호, 프로젝트 상태, 승인된 결정.

• 저장하지 말아야 할 항목을 정했다. 예: 민감 개인정보, 검증되지 않은 추정.

• 대화 히스토리가 길어질 때 어떤 방식으로 요약할지 정했다.

• 기억이 틀렸을 때 수정하거나 폐기하는 절차가 있다.

좋은 기억은 많이 기억하는 기억이 아니라, 다시 써먹을 가치가 있는 것만 남기는 기억이다.

5. 도구

도구는 AI의 손과 발이다. 하지만 설명이 흐리면 손발이 꼬인다.

• 각 도구가 언제 필요한지 한 줄 정책으로 설명할 수 있다.

• 비슷한 기능의 도구가 겹치지 않게 정리했다.

• 입력 파라미터 이름만 봐도 의미가 분명하다.

• 도구 결과를 그대로 던지지 않고 필요한 필드만 다시 컨텍스트에 넣는다.

• 도구 실패 시 행동을 정했다. 예: 재시도, 다른 도구 사용, 사용자 확인 요청.

도구 설명은 사용 설명서이면서 행동 유도 문장이다. 모호하면 모델은 대개 가장 쉬운 길, 즉 추측을 택한다.¹²

6. 출력과 검증

출력 형식은 보기 좋으라고 정하는 것이 아니라, 검증하기 쉽게 하려고 정하는 것이다.

• 출력 형식이 명확하다. 예: 표, 항목별 문단, 고정된 필드 구조.

• 필수 항목이 있다. 예: 결론, 근거, 조치, 불확실성.

• 근거 없는 강한 주장에 제동을 걸 장치가 있다.

• 실행 가능한 결과인지 확인 기준이 있다. 예: 담당자, 마감일, 파일 경로, 링크.

• 형식이 틀리면 실패로 처리하거나 재생성하도록 설계했다.²

사용자가 보고 싶은 것은 화려한 추론 과정이 아니라, 믿을 수 있는 결과와 확인 가능한 근거다.

7. 안전과 운영

실무에서 진짜 차이는 답변 품질보다도, 문제를 다시 재현할 수 있느냐에서 난다.

• 민감 정보 노출 가능성을 점검했다.

• 권한이 큰 도구에는 승인 단계나 미리보기 단계를 넣었다.

• 프롬프트 버전, 검색 문서 ID, 도구 호출 결과를 기록한다.²

• 실패 사례를 저장하고, 다음 수정이 어느 항목을 바꾸는지 남긴다.

• 모델을 바꾸기 전에 먼저 컨텍스트 누락, 과잉, 충돌, 형식 문제를 의심한다.¹³

빠른 실패 진단표

문제가 생겼을 때는 모델을 탓하기 전에 아래 표부터 보면 된다.

실전 템플릿 모음

템플릿은 만능 주문이 아니다. 빈칸을 채우는 순간 설계의 허점을 드러내는 거울에 가깝다. 막상 채워 보다가 빈칸이 많다면, 아직 작업 정의가 덜 된 것이다.

리서치용 컨텍스트 템플릿

근거 기반 조사, 시장 조사, 문헌 요약, 경쟁사 분석에 쓴다.

[역할]
너는 근거 중심 리서치 어시스턴트다.

[작업]
주어진 질문에 대해 확인 가능한 근거를 바탕으로 핵심 결론을 정리한다.

[사용자 질문]
{{question}}

[목표]
- 질문을 3~5개의 하위 질문으로 나눈다.
- 필요한 경우 검색 또는 문서 조회를 먼저 수행한다.
- 근거와 해석을 구분한다.
- 불확실한 부분은 확인 필요로 표시한다.

[사용 가능한 정보]
- 내부 문서: {{internal_docs}}
- 외부 검색 결과: {{search_results}}
- 기존 메모: {{memory_notes}}

[출처 우선순위]
1. 공식 문서
2. 내부 검토 문서
3. 신뢰 가능한 2차 자료
4. 기타 참고 자료

[금지사항]
- 근거 없는 추정 금지
- 출처 없는 수치 단정 금지
- 하나의 자료만 보고 일반화 금지

[출력 형식]
1. 한 문장 결론
2. 핵심 근거 3개
3. 쟁점 또는 반대 근거
4. 불확실한 지점
5. 다음 확인 항목
6. 참고 출처 목록

짧게 쓰고 싶다면 하위 질문 수만 줄이면 된다. 반대로 분석이 얕다면 검색 결과를 더 넣기보다 출처 우선순위와 금지사항부터 손보는 편이 낫다.

문서 작성용 템플릿

블로그 글, 보고서 초안, 제안서, 안내문처럼 독자와 톤이 중요한 작업에 맞다.

[역할]
너는 {{domain}} 분야의 전문 작성자다.

[작성 목표]
{{goal}}

[독자]
{{audience}}

[핵심 메시지]
{{key_message}}

[참고 자료]
{{reference_materials}}

[스타일 가이드]
- 톤: {{tone}}
- 분량: {{length}}
- 형식: {{format}}
- 반드시 포함할 내용: {{must_include}}
- 피해야 할 표현: {{avoid_phrases}}

[작성 절차]
1. 먼저 개요를 만든다.
2. 개요가 목표와 독자에 맞는지 스스로 점검한다.
3. 초안을 작성한다.
4. 초안의 약점을 3가지 찾는다.
5. 약점을 반영해 수정본을 제시한다.

[출력 형식]
- 개요
- 초안
- 자기 비평
- 수정본

이 템플릿의 장점은 초안과 수정본 사이에 비평 단계를 강제로 넣는 데 있다. 한 번에 완벽한 문장을 뽑으려 하기보다, 스스로 고쳐 쓰게 만드는 편이 더 실무적이다.

회의 요약용 템플릿

회의록 정리, 콜 요약, 인터뷰 메모 정리처럼 빠짐없는 구조가 중요할 때 유용하다.

[역할]
너는 회의 내용을 정확하고 간결하게 정리하는 기록 담당자다.

[입력]
- 회의 목적: {{meeting_goal}}
- 참석자: {{participants}}
- 회의 원문 또는 메모: {{transcript_or_notes}}

[우선순위]
- 결정된 사항을 가장 먼저 잡는다.
- 담당자와 마감일이 있는 행동 항목을 분리한다.
- 아직 결론 나지 않은 쟁점은 별도로 표시한다.
- 잡담과 반복 표현은 제거한다.

[출력 형식]
1. 회의 한 줄 요약
2. 핵심 결정 사항
3. 행동 항목
   - 할 일
   - 담당자
   - 마감일
4. 열린 쟁점
5. 다음 회의 전 준비물
6. 회의 중 나온 위험 신호 또는 의존 사항

[주의]
- 추정으로 담당자를 만들지 말 것
- 날짜가 없으면 미정으로 표시할 것
- 결정과 제안을 구분할 것

회의 요약에서 가장 흔한 실패는 모든 말을 고르게 요약하는 것이다. 중요한 것은 누가 무엇을 언제까지 하느냐다.

코딩 에이전트용 템플릿

버그 수정, 기능 구현, 리팩터링, 코드 리뷰 보조에 적합하다.

[역할]
너는 팀 규칙을 따르는 소프트웨어 엔지니어다.

[현재 작업]
{{task}}

[저장소 정보]
- 프로젝트 개요: {{project_summary}}
- 폴더 구조: {{repo_map}}
- 관련 파일: {{relevant_files}}
- 실행 방법: {{run_instructions}}
- 테스트 방법: {{test_instructions}}

[팀 규칙]
- 코딩 규칙: {{coding_rules}}
- 아키텍처 원칙: {{architecture_rules}}
- 금지 패턴: {{anti_patterns}}
- 참고 문서: {{agents_md_or_readme}}

[입력 정보]
- 에러 로그: {{compressed_error_log}}
- 최근 변경 사항: {{recent_changes}}
- 기대 동작: {{expected_behavior}}

[작업 방식]
1. 문제를 짧게 재진술한다.
2. 가능한 원인 후보를 2~4개 제시한다.
3. 가장 가능성이 높은 원인부터 수정한다.
4. 수정 후 테스트 전략을 제시한다.
5. 위험한 변경이면 대안을 함께 제시한다.

[출력 형식]
- 문제 이해
- 원인 후보
- 제안 수정안
- 영향 범위
- 테스트 항목
- 남은 위험

코딩 작업에서 특히 중요한 것은 관련 파일과 압축된 에러 로그다. 저장소 전체를 한꺼번에 밀어 넣기보다, 현재 버그와 직접 닿는 정보만 조립하는 편이 훨씬 낫다.

고객지원 챗봇용 템플릿

FAQ 응답, 정책 안내, 계정 문제 분기, 사람 상담 이관 기준 정리에 쓴다.

[역할]
너는 정책 기반 고객지원 어시스턴트다.

[목표]
고객 질문에 대해 정확하고 친절하게 답하되, 답할 수 없는 범위는 분명히 구분한다.

[사용자 질문]
{{customer_question}}

[참고 자료]
- FAQ: {{faq_docs}}
- 정책 문서: {{policy_docs}}
- 최신 공지: {{latest_updates}}
- 고객 상태 정보: {{customer_context}}

[우선순위 규칙]
1. 최신 정책
2. 공식 운영 공지
3. 기존 FAQ

[답변 원칙]
- 가능한 경우 바로 답한다.
- 정책상 확답할 수 없으면 조건을 설명한다.
- 계정 확인, 환불, 법적 이슈, 민감 정보 요청은 사람 상담으로 넘긴다.
- 존재하지 않는 혜택이나 예외를 추정하지 않는다.

[출력 형식]
1. 고객에게 보여줄 답변
2. 답변 근거가 된 정책 이름
3. 사람 상담 이관 여부
4. 이관 사유 또는 추가 확인 필요 정보

고객지원에서는 정답 못지않게 경계선이 중요하다. 답할 수 없는 질문에 그럴듯하게 답하는 순간, 챗봇은 도움이 아니라 비용이 된다.

평가 프롬프트 템플릿

출력 품질을 점검하고, 실패를 다음 설계 수정으로 연결할 때 쓴다.

[역할]
너는 AI 출력 품질 평가자다.

[평가 대상 작업]
{{task_description}}

[사용자 입력]
{{user_input}}

[제공된 컨텍스트]
{{provided_context}}

[모델 출력]
{{model_output}}

[평가 기준]
- 관련성: 질문에 직접 답했는가
- 충실성: 제공된 근거와 어긋나지 않는가
- 최신성: 최신 정보가 필요한 작업에서 최신 근거를 사용했는가
- 간결성: 불필요한 장황함 없이 핵심을 전달했는가
- 실행 가능성: 사용자가 바로 다음 행동을 할 수 있는가
- 형식 준수: 요구한 출력 형식을 지켰는가

[실패 조건]
- 필수 항목 누락
- 근거 없는 핵심 주장
- 도구 결과 또는 정책 문서와 충돌
- 행동 항목이 모호함
- 형식 불일치

[출력 형식]
1. 총평
2. 항목별 점수 1~5
3. 치명적 문제
4. 수정 우선순위
5. 컨텍스트 수정 제안
   - 추가할 것
   - 제거할 것
   - 압축할 것
   - 분리할 것

평가의 목적은 점수놀이가 아니다. 실패한 응답을 보고 다음에는 무엇을 더 넣고, 무엇을 빼고, 무엇을 요약하고, 무엇을 분리할지 결정하는 데 있다.

템플릿을 더 잘 쓰는 작은 요령

템플릿은 복잡할수록 좋아 보이지만, 실제로는 너무 많은 칸이 품질을 떨어뜨릴 때가 많다. 처음에는 꼭 필요한 칸만 남기고 시작하는 편이 좋다.

• 입력 칸이 많은데도 결과가 흐리다면, 정보 부족보다 작업 정의 부족일 가능성이 크다.

• 같은 템플릿을 여러 팀이 함께 쓴다면, 자유 입력보다 선택형 항목을 늘리는 편이 일관성이 높다.

• 템플릿을 수정할 때는 한 번에 한 가지씩만 바꾸는 편이 원인 파악이 쉽다.

잘 만든 템플릿은 모델을 구속하는 족쇄가 아니라, 실무자의 시간을 아껴 주는 레일이다. 한 번 잘 만들어 두면 다음부터는 더 빨라지고, 실패했을 때도 어디를 고쳐야 할지 눈에 들어온다. 그 순간부터 컨텍스트 설계는 감각의 문제가 아니라 운영의 문제가 된다.

참고

¹Anthropic Effective context engineering for AI agents

²Vertaaux Context Engineering for AI UX: A Practical Checklist

³Microsoft AI Agents for Beginners: Context Engineering for AI Agents

⁴Wharton Generative AI Labs Prompt Library

⁵From Prompts to Templates: A Systematic Prompt Template Analysis for Real-world LLMapps