업무용 스크립트 요청문에 입력·출력·오류 원칙 담기
“자동화해 줘”를 실행 가능한 작업 설명으로 바꿉니다. 민감정보 없는 합성 샘플과 손으로 확인한 기대 결과를 붙여, 팀별 작업 기록 집계 스크립트를 요청하는 문장을 완성합니다.
반복되는 AI 작업은 프롬프트 구조를 일정하게 유지하면 검토와 재사용이 쉬워집니다. 이 글에서는 변수, 예시, 작업별 체크리스트를 포함한 작은 프롬프트 템플릿 라이브러리를 만드는 방법을 설명합니다.
이런 분께비슷한 작업을 AI 채팅 도우미에게 반복적으로 요청하며, 일관되고 검토하기 쉬운 프롬프트를 재사용하고 싶은 사람을 위한 글입니다.
보고서 요약, 실행 항목 추출, 코드 검토, 메시지 수정처럼 비슷한 작업을 AI에게 반복해서 요청한다면 매번 기억에 의존해 프롬프트를 다시 쓰는 과정에서 불필요한 차이가 생길 수 있습니다. 중요한 제약 조건이 빠지거나, 출력 형식이 달라지거나, 예시가 서로 일관되지 않을 수 있습니다. 프롬프트 템플릿 라이브러리를 사용하면 각 반복 작업을 재사용하고 검토할 수 있는 작은 작업 명세로 관리할 수 있습니다.
유용한 템플릿은 변하지 않는 지시사항과 매번 달라지는 입력값을 분리해야 합니다. 고정된 부분에는 작업 목적, 규칙, 기대 출력 형식, 확인 항목을 작성합니다. 변수에는 프로젝트명, 대상 독자, 원문, 날짜, 요청 언어처럼 실행할 때마다 달라지는 값을 넣습니다.
이 예제는 합성 예제입니다. AI 채팅 도우미를 이용해 매주 업무 로그를 요약하고 회의 메모에서 실행 항목을 추출하는 두 가지 작업을 반복한다고 가정합니다. 각 작업은 변수, 지시사항, 예시, 체크리스트의 네 부분으로 저장할 수 있습니다.
| 템플릿 | 변수 | 주요 출력 |
|---|---|---|
| weekly_summary | project, audience, log_text | 간결한 주간 요약 |
| meeting_actions | meeting_name, notes | 실행 항목 목록 |
변수는 지시사항이 아니라 자리표시자입니다. 예를 들어 project에는 Atlas, audience에는 engineering team, log_text에는 해당 주의 기록이 들어갈 수 있습니다. 이렇게 값을 분리하면 재사용 프롬프트 자체가 변경된 것인지, 단순히 입력 데이터만 달라진 것인지 쉽게 구분할 수 있습니다.
복잡한 표현보다 구조의 일관성이 더 중요합니다. 실용적인 템플릿에는 작업 설명, 변수 자리표시자, 명시적인 규칙, 입력·출력 예시, 마지막 자체 점검 항목을 포함할 수 있습니다. 체크리스트는 실제로 확인할 수 있는 실패 유형에 초점을 맞추는 것이 좋습니다. 예를 들어 없는 정보를 만들어냈는지, 필수 필드를 누락했는지, 날짜를 변경했는지, 근거 없는 결론을 추가했는지를 확인할 수 있습니다.
템플릿을 지나치게 범용적으로 만들면 실제 작업에 필요한 규칙이 약해질 수 있습니다. 수십 개의 선택 변수를 가진 하나의 만능 프롬프트보다, 작업별로 작고 명확한 템플릿을 여러 개 관리하는 편이 일반적으로 더 쉽습니다.
다음 표준 라이브러리 스크립트는 두 개의 합성 템플릿을 정의하고, 필수 변수가 모두 있는지 확인한 다음, 선택한 템플릿을 생성해 outputs 폴더에 저장합니다. 대상 파일이 이미 존재하면 중단하므로 기존에 생성한 프롬프트를 실수로 덮어쓰지 않습니다.
from pathlib import Path
from string import Template
TEMPLATES = {
"weekly_summary": {
"required": ["project", "audience", "log_text"],
"template": Template(
"Task: Summarize the weekly work log.\n\n"
"Project: $project\n"
"Audience: $audience\n\n"
"Rules:\n"
"- Use only information present in the log.\n"
"- Separate completed work, open issues, and next steps.\n"
"- Keep dates and numbers unchanged.\n"
"- If something is unclear, label it as unclear instead of guessing.\n\n"
"Example format:\n"
"Completed:\n"
"- Finished data cleanup.\n"
"Open issues:\n"
"- Waiting for test results.\n"
"Next steps:\n"
"- Review results when available.\n\n"
"Checklist:\n"
"- Every statement comes from the log.\n"
"- Dates and numbers are preserved.\n"
"- No unsupported status claims are added.\n\n"
"Work log:\n$log_text\n"
),
},
"meeting_actions": {
"required": ["meeting_name", "notes"],
"template": Template(
"Task: Extract action items from the meeting notes.\n\n"
"Meeting: $meeting_name\n\n"
"Rules:\n"
"- Do not invent owners or deadlines.\n"
"- Preserve names and dates exactly as written.\n"
"- Mark missing owner or deadline as Not specified.\n\n"
"Example format:\n"
"Action | Owner | Deadline\n"
"Send draft | Mina | 2026-09-25\n"
"Check budget | Not specified | Not specified\n\n"
"Checklist:\n"
"- Each action is supported by the notes.\n"
"- Owners are not inferred.\n"
"- Deadlines are not invented.\n\n"
"Meeting notes:\n$notes\n"
),
},
}
selected = "weekly_summary"
values = {
"project": "Atlas",
"audience": "engineering team",
"log_text": (
"2026-09-14: Cleaned 120 test rows.\n"
"2026-09-16: Compared two validation reports.\n"
"Open issue: three records still have missing labels.\n"
"Next: review those records with the team."
),
}
spec = TEMPLATES[selected]
missing = [name for name in spec["required"] if not values.get(name)]
if missing:
raise SystemExit("Missing variables: " + ", ".join(missing))
rendered = spec["template"].substitute(values)
output_dir = Path("outputs")
output_dir.mkdir(exist_ok=True)
output_file = output_dir / f"{selected}_prompt.txt"
if output_file.exists():
raise SystemExit(f"Stop: {output_file} already exists.")
output_file.write_text(rendered, encoding="utf-8")
print(f"Wrote {output_file}")
합성 weekly_summary 예제에서 필수 변수는 project, audience, log_text이며 세 값이 모두 제공됩니다. 따라서 생성된 프롬프트에는 Atlas, engineering team, 네 줄의 업무 로그가 포함되어야 합니다. $project 같은 자리표시자는 남아 있으면 안 됩니다.
작은 라이브러리는 하나의 Python 파일이나 일반 텍스트 폴더로 관리할 수 있습니다. 규모가 커지면 summarize-weekly-log, extract-meeting-actions, review-code, classify-feedback처럼 안정적인 파일명이나 식별자를 사용하는 것이 좋습니다. 각 템플릿은 하나의 반복 작업에 집중하도록 유지합니다.
프롬프트가 변경되면 무엇을 왜 바꿨는지 기록합니다. 예를 들어 AI가 반복적으로 마감일을 임의로 만들어낸다면, 추론한 마감일을 금지하는 규칙과 체크리스트 항목을 추가할 수 있습니다. 이렇게 하면 프롬프트가 막연한 지시사항을 계속 쌓아가는 대신 실제로 관찰된 문제를 기준으로 변경됩니다.
각 템플릿마다 작은 합성 테스트 사례 하나를 유지하는 것도 유용합니다. 템플릿을 수정한 뒤 동일한 테스트 변수로 다시 생성하고 필수 섹션, 라벨, 제한 조건이 그대로 있는지 확인합니다. 이것만으로 AI가 항상 프롬프트를 따를 것이라고 보장할 수는 없지만, 의도하지 않은 프롬프트 변경을 발견하는 데 도움이 됩니다.
흔한 실수 중 하나는 프롬프트 템플릿이 출력 품질을 보장한다고 생각하는 것입니다. 구조가 잘 잡힌 프롬프트는 모호성을 줄일 수 있지만 생성된 답변은 여전히 검토해야 합니다. 또 다른 실수는 규칙을 지나치게 많이 추가해 중요한 요구사항을 찾기 어렵게 만드는 것입니다. 가장 중요한 제약 조건은 작업 설명과 출력 형식 가까이에 배치하는 것이 좋습니다.
재사용 템플릿이나 예시 안에 비밀번호, 비밀키, 개인 키, 불필요한 개인정보를 넣지 마세요. 변수를 사용하면 프롬프트 관리가 쉬워지지만, 변수 자체가 접근 제어나 데이터 보호 기능을 제공하는 것은 아닙니다.
마지막으로 프롬프트 검증과 결과 검증을 구분해야 합니다. 모든 변수가 정확히 삽입되었는지 확인하는 것은 프롬프트 생성 과정을 검증하는 것입니다. 이것만으로 AI 답변의 사실 정확성을 확인할 수는 없습니다. 반복 작업에서 결과에 사실, 계산, 분류, 의사결정이 포함된다면 프롬프트 체크리스트와 별도의 출력 결과 체크리스트를 함께 유지하는 것이 좋습니다.
2026-09-21 · hand-checked example · Python 3.12
설명과 예제는 직접 작성했습니다. 관련 동작과 개념은 아래 공식 자료에서 확인할 수 있습니다.