프롬프트 템플릿의 기본 구조

프롬프트를 잘 쓰는 사람과, 프롬프트를 계속 써먹는 사람은 조금 다르다. 전자는 그때그때 좋은 문장을 만들 수 있다. 하지만 후자는 바쁜 월요일 아침에도, 다른 팀원이 대신 써도, 입력 자료가 조금 달라져도 비슷한 품질을 낸다. 중급 단계에서 우리가 노리는 것은 바로 두 번째 능력이다.

업무 구조를 잡아 두었다면 이제 해야 할 일은 간단하다. 그 구조를 매번 다시 쓰지 않아도 되는 틀로 바꾸는 것이다. 이 틀이 바로 프롬프트 템플릿이다.

템플릿은 멋진 문장을 외워 두는 장치가 아니다. 오히려 반대다. 매번 감으로 새로 쓰지 않게 만드는 장치다. 좋은 템플릿은 사람의 기분에 따라 흔들리지 않는다. 어떤 날은 짧게 쓰고, 어떤 날은 장황하게 쓰는 습관을 줄여 준다. 그래서 템플릿은 창의성을 죽이는 틀이 아니라, 반복 업무를 지탱하는 뼈대라고 보는 편이 맞다.

템플릿은 문장 모음이 아니라 조립식 구조다

많은 사람이 템플릿이라고 하면 긴 프롬프트 본문부터 떠올린다. 하지만 실제로는 긴 문장보다 구성 요소의 역할 분리가 더 중요하다.

프롬프트 템플릿은 보통 다섯 부분으로 나눠 생각하면 편하다.

이 다섯 가지를 구분해 두면 프롬프트가 훨씬 다루기 쉬워진다. 가장 흔한 실수는 이 다섯 가지가 한 문단 안에서 뒤섞이는 것이다. 그러면 읽을 때는 그럴듯해 보여도, 수정하려고 보면 어디를 고쳐야 하는지 잘 보이지 않는다.

예를 들어 회의록 요약 업무를 떠올려 보자. 어떤 부분은 절대 바뀌지 않는다. 회의록만 근거로 써야 한다든지, 결정사항과 미해결 이슈를 분리해야 한다든지, 근거 없는 추정은 하지 말아야 한다든지 하는 규칙이 그렇다. 반면 어떤 부분은 매번 바뀐다. 회의록 본문, 독자, 길이 제한, 보고 목적 같은 것들이다.

템플릿 설계의 핵심은 이 둘을 섞지 않는 데 있다. 바뀌지 않는 것은 고정하고, 바뀌는 것만 변수로 빼는 것이다. 그렇게 해야 복붙이 아니라 재사용이 된다.

고정 지시문: 템플릿의 성격을 정하는 뼈대

고정 지시문은 말 그대로 매번 유지되는 지시다. 템플릿을 만들 때 가장 먼저 세워야 하는 기둥이라고 할 수 있다.

여기에는 보통 작업의 역할, 목적, 기본 원칙, 금지 규칙이 들어간다. 쉽게 말해 "이 템플릿은 어떤 일을 하는 도구인가?"를 정의하는 부분이다. 이 부분이 약하면 템플릿은 매번 흔들린다. 마치 매번 다른 직무 설명서를 들고 일하는 사람처럼 행동하게 된다.

예를 들어 팀장 보고용 회의록 요약 템플릿의 고정 지시문은 이렇게 잡을 수 있다.

당신은 회의록을 팀장 보고용으로 정리하는 업무 보조자다. 제공된 회의록만 근거로 핵심 내용을 요약하라. 결정된 내용과 미해결 이슈를 구분하고, 자료에 없는 사실은 추정하지 말라.

이 문장에서 중요한 점은 문장이 멋있다는 것이 아니다. 역할과 경계가 분명하다는 점이다. 누가 읽는지, 무엇을 해야 하는지, 무엇을 하면 안 되는지가 드러난다.

고정 지시문을 쓸 때는 욕심을 부리지 않는 편이 좋다. 여기저기서 본 좋은 표현을 모두 붙이면 오히려 템플릿이 무거워진다. 핵심은 자주 바뀌지 않을 원칙만 남기는 것이다.

고정 지시문에 잘 들어가는 항목은 대체로 다음과 같다.

• 이 템플릿의 역할

• 작업의 기본 목적

• 반드시 지켜야 할 공통 규칙

• 자주 발생하는 위험에 대한 금지 조건

반대로 매번 달라질 수 있는 내용을 고정 지시문에 박아 넣으면 곤란하다. 예를 들어 독자 수준, 길이 제한, 출력 언어, 입력 자료 종류가 자주 바뀐다면 고정 문장에 박아 두기보다 변수나 조건으로 빼는 편이 낫다.

좋은 고정 지시문은 장황한 자기소개가 아니라, 이 템플릿의 성격을 한 번에 알려 주는 운영 규칙이다.

입력 변수: 바뀌는 것을 빈칸으로 분리하기

템플릿이 템플릿답기 위해서는 빈칸이 필요하다. 이 빈칸이 바로 입력 변수다. 변수는 말이 조금 어려워 보여도 뜻은 단순하다. 상황에 따라 바뀌는 값이다.

예를 들어 같은 회의록 요약 템플릿을 쓰더라도 다음 값은 매번 달라질 수 있다.

변수를 잘 뽑으면 템플릿은 오래 산다. 반대로 변수를 너무 적게 뽑으면 매번 문장을 크게 뜯어고쳐야 한다. 변수를 너무 많이 뽑으면 템플릿 자체가 흐물흐물해진다. 어느 부분까지 고정하고, 어디부터 유연하게 둘지 균형을 잡는 것이 중요하다.

초보자가 자주 하는 실수는 템플릿 전체를 거의 변수로 만들어 버리는 것이다. 그러면 템플릿이 아니라 빈 종이가 된다. 반대로 모든 것을 고정하면 실제 업무에 맞게 조절하기 어렵다. 그래서 질문 하나를 기억하면 좋다.

이 값은 다음 주에도 그대로일 가능성이 높은가?

높다면 고정 지시문 쪽에 두고, 낮다면 변수로 빼면 된다.

변수 이름을 붙일 때도 요령이 있다. 이름만 봐도 무슨 값을 넣어야 하는지 이해되어야 한다. {text}처럼 너무 넓은 이름보다 {customer_review_text}나 {report_goal}처럼 의미가 드러나는 이름이 좋다. 템플릿은 혼자만 쓰고 끝나는 경우보다, 나중에 다시 보거나 팀원이 이어받는 경우가 많기 때문이다.

변수는 단지 빈칸이 아니다. 템플릿을 살아 있게 만드는 관절이다.

조건문: 상황이 달라질 때 흔들리지 않게 만드는 장치

실무에서는 입력이 늘 깔끔하지 않다. 어떤 날은 정보가 충분하고, 어떤 날은 절반이 비어 있다. 어떤 요청은 초보자 대상이고, 어떤 요청은 전문가 대상이다. 이런 차이를 모두 새 프롬프트로 다시 쓰기 시작하면 금세 지친다. 그래서 필요한 것이 조건문이다.

조건문은 쉽게 말해 "이럴 때는 이렇게 처리하라"는 분기 규칙이다. 프로그래밍처럼 복잡하게 생각할 필요는 없다. 자연어로도 충분히 만들 수 있다.

예를 들어 이런 문장은 모두 조건문이다.

• 정보가 부족하면 추정하지 말고 확인이 필요한 항목으로 표시하라.

• 독자가 비전공자이면 전문 용어 뒤에 쉬운 설명을 덧붙여라.

• 결정사항이 없으면 해당 섹션에 '없음'이라고 적어라.

• 길이 제한을 넘길 경우 세부 사례보다 핵심 결론을 우선하라.

이런 분기 규칙이 있으면 템플릿은 예상 밖의 상황에서도 덜 흔들린다. 템플릿이 실패하는 이유는 보통 평범한 상황이 아니라 애매한 상황에서 규칙이 없기 때문이다.

조건문이 특히 빛나는 순간은 세 가지다. 첫째, 입력 누락이 자주 발생할 때다. 둘째, 독자나 형식이 상황에 따라 달라질 때다. 셋째, 예외 처리 방식이 업무상 중요할 때다.

예를 들어 고객 문의 답변 초안을 만드는 템플릿이라면, 정책 근거가 불명확할 때 사과 표현은 가능하지만 보상 약속은 하지 않도록 조건을 둘 수 있다. 교육 자료 요약 템플릿이라면 학습자 수준이 초급일 때 예시를 추가하고, 중급 이상일 때는 정의보다 차이점 중심으로 설명하도록 만들 수 있다.

조건문은 템플릿을 똑똑하게 보이게 하는 장식이 아니다. 현실의 흔들림을 견디게 하는 스프링에 가깝다.

출력 포맷: 읽기 좋은 답보다 붙여 넣기 좋은 답

중급 단계에서 중요한 변화 하나는, 이제 좋은 문장만으로는 만족하지 않는다는 점이다. 실무에서는 "괜찮게 쓴 답"보다 "바로 다음 작업에 넣을 수 있는 답"이 더 유용하다. 그래서 출력 포맷이 중요하다.

출력 포맷은 결과의 모양을 정하는 부분이다. 문단으로 낼지, 표로 낼지, 항목별 목록으로 낼지, 체크리스트로 낼지, 필드형 구조로 낼지를 결정한다.

가령 회의록 요약 업무에서 출력 포맷을 정하지 않으면 AI는 문단형 요약을 내놓을 가능성이 크다. 읽기는 편할 수 있다. 하지만 팀장이 빠르게 훑어보거나, 다른 문서에 옮기거나, 담당자와 기한을 확인하려면 다시 손을 봐야 한다. 이때 포맷을 먼저 정해 두면 사람이 뒤처리하는 시간이 줄어든다.

예를 들어 이렇게 지정할 수 있다.

이런 포맷은 보기 좋기만 한 것이 아니라 쓰기 좋다. 업무에 넣기 쉬운 출력이기 때문이다.

출력 포맷을 정할 때는 두 가지를 함께 물으면 좋다. 하나는 "누가 읽기 편한가?"이고, 다른 하나는 "이 답을 내가 다음에 어떻게 사용할 것인가?"다. 중급 프롬프트는 두 번째 질문을 놓치지 않는다.

검증 문장: 내보내기 전에 한 번 더 점검시키기

템플릿의 마지막 부품은 검증 문장이다. 이것은 의외로 자주 빠지지만, 반복 업무에서는 꽤 큰 차이를 만든다.

검증 문장은 답변을 내기 전에 스스로 확인하게 하는 짧은 기준이다. 예를 들면 이런 식이다.

최종 답변 전에 다음을 확인하라. 회의록에 없는 내용을 추정하지 않았는지, 결정사항과 미해결 이슈가 섞이지 않았는지, 담당자나 기한이 없으면 미정으로 표시했는지 점검하라.

이 문장이 있다고 해서 모든 실수가 사라지는 것은 아니다. 하지만 검증 문장이 없을 때보다 품질이 덜 흔들리는 경우가 많다. 특히 형식 누락, 금지 조건 위반, 불확실한 정보의 단정 같은 실수를 줄이는 데 도움이 된다.

검증 문장은 너무 추상적이면 힘이 약하다. "정확하게 써라"보다는 "원문에 없는 사실을 추가하지 않았는지 확인하라"가 낫다. "좋은 품질로 작성하라"보다는 "각 섹션이 모두 채워졌는지 확인하라"가 훨씬 낫다.

검증 문장을 잘 쓰려면 결과물을 보고 평가하는 말이 아니라, 실수 여부를 체크할 수 있는 문장으로 바꿔야 한다. 즉, 감상평이 아니라 체크 항목이어야 한다.

이 장 뒤에서 다룰 평가 루브릭이 더 본격적인 비교 도구라면, 검증 문장은 템플릿 안에 심어 놓는 미니 점검표라고 생각하면 된다.

다섯 부품을 한 번에 조립해 보기

이제 다섯 부품을 하나로 합쳐 보자. 다음은 바로 가져다 쓸 수 있는 기본형 템플릿이다.

당신은 {role}이다.
목적은 {goal}이다.

다음 입력을 바탕으로 작업하라.
- 입력 자료: {input_material}
- 대상 독자: {audience}
- 강조할 관점: {focus}
- 길이 또는 분량: {length}

작업 규칙:
- {fixed_rule_1}
- {fixed_rule_2}
- {fixed_rule_3}

조건 처리:
- 만약 정보가 부족하면 {fallback_rule}
- 만약 특정 항목이 없으면 {missing_value_rule}
- 만약 독자 수준이 초급이면 {beginner_rule}

출력 포맷:
{output_format}

검증:
최종 답변 전에 {check_1}, {check_2}, {check_3}을 확인하라.

이 템플릿이 대단해 보이는 이유는 길어서가 아니다. 어디가 고정이고 어디가 가변인지, 예외 상황을 어떻게 처리하는지, 무엇을 기준으로 점검하는지가 한눈에 보이기 때문이다.

여기서 중요한 점은 모든 템플릿이 이 모양일 필요는 없다는 것이다. 다만 처음 중급 템플릿을 설계할 때는 이 다섯 부품을 빠짐없이 넣어 보는 습관이 좋다. 익숙해지면 업무에 따라 더 단순하게 줄일 수도 있고, 반대로 더 세밀하게 늘릴 수도 있다.

한 번 쓰는 프롬프트를 템플릿으로 바꾸는 예시

이 차이를 더 또렷하게 보기 위해, 흔한 일회성 프롬프트를 템플릿으로 바꿔 보자.

먼저 일회성 프롬프트는 보통 이런 식이다.

이 회의록 요약해줘. 핵심만 정리해줘.

짧고 편하다. 하지만 누가 읽는지, 무엇을 남겨야 하는지, 정보가 부족하면 어떻게 할지, 어떤 모양으로 출력할지가 빠져 있다. 그래서 어떤 날은 핵심을 잘 짚고, 어떤 날은 엉뚱하게 친절한 문단을 길게 쓰기도 한다.

이를 템플릿으로 바꾸면 다음처럼 된다.

당신은 회의록을 보고용 문서로 정리하는 업무 보조자다.
목적은 팀장이 1분 안에 핵심 결정사항과 후속 액션을 파악하도록 돕는 것이다.

다음 입력을 바탕으로 작업하라.
- 입력 자료: {meeting_notes}
- 대상 독자: {audience}
- 길이: {length}

작업 규칙:
- 제공된 회의록만 근거로 작성하라.
- 결정된 내용과 미해결 이슈를 구분하라.
- 자료에 없는 사실은 추정하지 말라.

조건 처리:
- 담당자나 기한이 없으면 '미정'으로 표시하라.
- 결정사항이 없으면 '결정사항 없음'이라고 적어라.
- 정보가 불충분하면 '확인 필요' 섹션에 모아라.

출력 포맷:
1. 핵심 결정사항
2. 미해결 이슈
3. 다음 액션(할 일 / 담당자 / 기한)
4. 확인 필요

검증:
최종 답변 전에 각 섹션이 모두 포함되었는지, 추정 문장이 없는지, 누락값이 비어 있지 않은지 확인하라.

이제 이 템플릿은 회의 주제만 바꿔 계속 사용할 수 있다. 더 중요한 것은, 다른 사람에게 넘겨도 운영 방식이 비슷하게 유지된다는 점이다. 템플릿이 개인의 감각을 조금 덜 타게 되기 때문이다.

템플릿이 실패하는 흔한 이유

템플릿은 만들었다고 끝이 아니다. 처음 만든 템플릿이 잘 안 먹히는 이유도 비교적 뚜렷하다.

첫째, 고정 지시문이 너무 넓다. "친절하고 정확하게 답하라" 같은 문장은 나쁘진 않지만, 업무의 성격을 충분히 설명하지 못한다. 정확히 어떤 종류의 정확성인지가 없다.

둘째, 변수가 모호하다. {text} 하나로 다 해결하려고 하면 어떤 값을 넣어야 할지 헷갈린다. 입력 자료, 독자, 목표, 길이처럼 서로 다른 성격의 값을 분리해야 한다.

셋째, 조건문이 없다. 평범한 상황에서는 잘 작동해도, 정보가 비거나 예외가 생기면 바로 품질이 무너진다.

넷째, 출력 포맷이 "보기 좋게" 수준에 머문다. 보기 좋은 것과 바로 쓸 수 있는 것은 다르다. 포맷은 구체적이어야 한다.

다섯째, 검증 문장이 추상적이다. "좋게 써라"는 검증이 아니다. 무엇을 확인해야 하는지 체크 가능해야 한다.

결국 템플릿 실패의 원인은 대부분 문장 솜씨 부족이 아니다. 부품의 역할이 분리되지 않았기 때문이다.

작게 시작할수록 템플릿은 오래 간다

처음부터 완벽한 템플릿을 만들려고 하면 오히려 잘 안 된다. 변수도 열 개, 조건문도 여섯 개, 출력 규칙도 빽빽하게 넣다 보면 실제로는 아무도 쓰지 않는 무거운 문서가 되기 쉽다.

처음에는 자주 반복하는 업무 하나를 골라, 다섯 부품만 넣어 간단한 1차 템플릿을 만드는 편이 낫다. 그리고 실제로 두세 번 써 본 뒤 어디서 흔들리는지 확인하면서 변수를 추가하거나 조건문을 보강하는 것이 좋다.

템플릿은 책상 위에서 완성되는 설계도가 아니라, 실제 업무 속에서 다듬어지는 도구다. 너무 크게 시작하면 손이 안 가고, 너무 느슨하면 효과가 없다. 그래서 처음에는 "매주 반복하는 한 가지 업무를 덜 흔들리게 만들겠다" 정도의 목표가 가장 좋다.

기본 공식만 알아도 프롬프트 작성이 빨라진다

이 장의 핵심은 복잡한 기술을 배우는 것이 아니다. 프롬프트를 다음 공식으로 보기 시작하는 것이다.

고정 지시문 + 입력 변수 + 조건문 + 출력 포맷 + 검증 문장

이 공식을 머릿속에 넣어 두면 프롬프트를 처음부터 시처럼 짓지 않게 된다. 대신 조립한다. 어떤 규칙은 고정하고, 어떤 값은 바꾸고, 어떤 예외는 분기하고, 어떤 모양으로 내보내고, 마지막에 무엇을 확인할지 정한다.

이 차이는 생각보다 크다. 프롬프트가 문장 실력의 문제가 아니라 설계의 문제로 보이기 시작하기 때문이다. 그리고 바로 그 순간부터 프롬프트는 개인의 즉흥 노하우에서 재사용 가능한 업무 도구로 바뀐다.

이 장의 핵심 정리

템플릿은 잘 쓴 문장을 저장해 두는 창고가 아니다. 반복 업무를 덜 흔들리게 만드는 조립식 구조다. 고정 지시문은 템플릿의 성격과 공통 규칙을 정하고, 입력 변수는 매번 달라지는 값을 담는다. 조건문은 예외 상황과 입력 차이를 견디게 만들고, 출력 포맷은 결과를 다음 작업에 바로 쓰게 해 준다. 검증 문장은 마지막 순간의 실수를 줄이는 점검 장치다.

중급 프롬프트의 핵심은 매번 새로 잘 쓰는 것이 아니라, 조금 덜 힘들게 계속 비슷하게 잘 쓰는 것이다. 그 출발점이 바로 템플릿의 기본 구조를 이해하는 일이다.

다음 장에서는 이 기본 구조를 바탕으로, 변수와 조건을 더 적극적으로 활용해 독자 수준, 톤, 길이, 상황에 따라 템플릿을 확장하는 방법을 살펴본다.