변수와 조건으로 프롬프트 확장하기

템플릿의 기본 구조를 만들었다면 이제 한 단계 더 나아갈 차례다. 잘 만든 템플릿은 한 번 쓰고 버리는 문장이 아니다. 상황이 조금 바뀌어도 중심은 유지한 채 유연하게 움직여야 한다. 그래야 비슷한 업무를 만날 때마다 새 프롬프트를 처음부터 짜지 않아도 된다.

중급 프롬프트에서 변수와 조건은 바로 이 유연함을 만든다. 변수는 바뀌는 값을 담는 손잡이이고, 조건은 상황이 달라졌을 때 흔들리지 않게 해 주는 방향표지판이다. 템플릿이 뼈대라면, 변수와 조건은 관절에 가깝다. 관절이 없으면 몸은 단단할 수는 있어도 움직이기 어렵다.

왜 확장이 필요한가

실무에서는 같은 업무처럼 보여도 미묘하게 다른 경우가 끊임없이 나온다. 같은 요약 업무라도 대표에게 보내는 요약과 신입사원 교육용 요약은 다르다. 같은 설명 업무라도 비전공자에게 설명할 때와 내부 전문가에게 설명할 때는 말의 깊이와 어휘가 달라진다. 같은 답변 초안이라도 정중한 공지와 친근한 안내는 결이 다르다.

이럴 때 템플릿이 너무 딱딱하면 매번 새로 써야 한다. 반대로 너무 느슨하면 아무 상황이나 다 받아들이려다 중심을 잃는다. 중급 단계에서 중요한 것은 템플릿을 무한히 길게 만드는 것이 아니라, 자주 바뀌는 요소만 골라서 확장 포인트로 빼는 것이다.

쉽게 말해 이렇게 생각하면 된다. 본체는 하나로 두고, 스위치만 갈아 끼우는 것이다. 독자 수준, 톤, 길이, 상황별 처리 방식이 그 대표적인 스위치다.

모든 것을 변수로 만들지 말고, 자주 바뀌는 것만 고르기

변수 설계에서 가장 흔한 실수는 두 가지다. 하나는 변수를 너무 적게 잡아서 결국 템플릿을 통째로 다시 고치게 되는 경우다. 다른 하나는 반대로 거의 모든 문장을 변수로 바꿔 버려 템플릿이 아니라 빈 종이가 되어 버리는 경우다.

좋은 변수는 두 가지 질문을 통과해야 한다.

• 이 값은 업무마다 자주 달라지는가?

• 이 값이 바뀌면 출력 방식도 눈에 띄게 달라지는가?

이 두 질문에 모두 "그렇다"라고 답할 수 있다면 변수로 뺄 가치가 높다. 예를 들어 {audience_level}은 좋은 변수다. 초급자와 전문가에게 같은 설명을 내보내면 만족도가 크게 달라지기 때문이다. {tone}도 자주 유용하다. 사과문과 홍보 문구와 내부 메모는 같은 정보라도 말투가 완전히 달라진다. {length} 역시 중요하다. 3줄 요약과 1페이지 설명은 같은 업무가 아니다.

반면 너무 세세한 표현까지 변수화하면 템플릿 운영이 피곤해진다. 예를 들어 "첫 문단의 비유 사용 여부", "문장당 평균 길이", "쉼표 개수" 같은 수준까지 매번 조정하려 들면 템플릿이 실무 도구가 아니라 실험 장비가 된다.

처음에는 변수를 네다섯 개 정도로 시작하는 편이 좋다. 정말 자주 바뀌고, 품질 차이를 크게 만드는 요소부터 잡는 것이다.

독자 수준별 출력을 설계하는 법

독자 수준은 가장 강력한 변수 가운데 하나다. 같은 내용을 설명하더라도 독자가 누구냐에 따라 필요한 정보의 깊이, 용어의 밀도, 예시의 개수가 달라진다.

초급자를 위한 출력은 낯선 개념을 부드럽게 연결해 주는 역할이 중요하다. 전문 용어를 쓰면 쉬운 설명을 붙이고, 추상적인 개념은 짧은 예시와 함께 풀어야 한다. 반대로 중급자나 전문가에게는 정의를 길게 반복하기보다 차이점, 예외, 판단 기준이 더 중요해진다.

예를 들어 같은 주제를 설명하는 템플릿이라도 이렇게 나눌 수 있다.

중요한 점은 {audience_level}을 넣는 것으로 끝내지 않는 것이다. 변수 이름만 있다고 AI가 자동으로 기준을 이해하는 것은 아니다. 각 수준에서 무엇이 달라져야 하는지 조건으로 함께 적어 줘야 한다.

예를 들면 이런 식이다.

독자 수준: {audience_level}

조건:
- 초급이면 전문 용어를 최소화하고, 꼭 필요한 용어에는 한 줄 설명을 덧붙여라.
- 중급이면 개념 설명 뒤에 실제 활용 예시를 1개 포함하라.
- 고급이면 기본 정의는 짧게 처리하고, 예외 상황과 한계를 우선 설명하라.

이렇게 설계하면 같은 템플릿으로도 설명의 높낮이를 자연스럽게 바꿀 수 있다. 한마디로, 내용은 같아도 계단의 높이를 조정하는 셈이다.

톤은 감각이 아니라 선택지로 관리하기

많은 사람이 톤을 "좀 더 부드럽게", "조금 더 세련되게" 같은 감각적 표현으로 지시한다. 물론 그럴 수도 있다. 하지만 반복 가능한 템플릿을 만들려면 톤 역시 선택지로 관리하는 편이 낫다.

예를 들어 {tone} 변수 하나만 두더라도 선택 가능한 값을 미리 좁혀 두면 훨씬 안정적이다. "정중한", "친근한", "전문적인", "담백한"처럼 팀 안에서 공통으로 이해할 수 있는 단어를 쓰는 것이다. 이때도 역시 조건이 필요하다. 정중한 톤이 무엇을 뜻하는지, 친근한 톤이 어디까지 허용되는지 기준이 있어야 한다.

다음처럼 설계할 수 있다.

이를 템플릿에 넣으면 이렇게 된다.

톤: {tone}

조건:
- 정중한 톤이면 예의 있는 표현을 사용하되 과도한 사과 표현은 피하라.
- 친근한 톤이면 쉬운 문장을 사용하되 지나치게 가벼운 유행어는 쓰지 말라.
- 전문적인 톤이면 정확한 용어를 사용하되 핵심 용어는 짧게 풀어 설명하라.
- 설득형 톤이면 장점과 행동 제안을 분명히 하되 과장된 확신 표현은 피하라.

이렇게 하면 톤이 기분에 따라 흔들리지 않는다. 같은 팀에서 여러 사람이 써도 결과가 어느 정도 비슷한 결을 유지할 수 있다.

길이 제한은 글자 수보다 정보 우선순위까지 함께 정하기

길이 변수도 단순히 "짧게 써 줘" 수준에서 끝내면 효과가 약하다. 짧게 쓰라는 말은 쉽지만, 무엇을 줄이고 무엇을 남길지는 여전히 불분명하기 때문이다.

그래서 {length}를 설계할 때는 분량만 정하지 말고 정보 우선순위도 함께 정하는 편이 좋다. 예를 들어 3줄 요약에서는 결론과 행동 항목만 남기고 배경 설명은 줄이도록 할 수 있다. 반대로 긴 설명에서는 배경, 이유, 예외, 예시까지 포함하게 만들 수 있다.

다음 표처럼 생각해 보자.

길이 변수를 실제 템플릿에 넣으면 이렇게 쓸 수 있다.

분량: {length}

조건:
- 짧게이면 핵심 결론을 먼저 제시하고, 세부 사례는 생략하라.
- 보통이면 결론과 이유를 함께 쓰고, 필요한 예시는 1개만 포함하라.
- 자세히이면 배경, 판단 근거, 예외 사항, 다음 행동까지 포함하라.

이 설계가 중요한 이유는, 길이가 줄어들어도 품질이 무너지지 않게 해 주기 때문이다. 무작정 짧게 만들면 알맹이가 빠지기 쉽다. 하지만 무엇을 먼저 남길지 정해 두면 짧은 답도 쓸모가 있다.

상황별 분기는 템플릿을 현실에 맞춘다

현실의 업무는 늘 반듯하지 않다. 자료가 빠져 있을 수도 있고, 요청이 모호할 수도 있고, 민감한 주제가 섞일 수도 있다. 이런 순간에 템플릿이 자주 무너진다. 그래서 조건문은 단순한 옵션이 아니라 실제 업무를 견디게 하는 장치다.

특히 다음과 같은 상황은 분기 규칙을 미리 넣어 두면 좋다.

• 입력 정보가 부족할 때

• 독자나 채널이 바뀔 때

• 긴급도에 따라 처리 속도와 표현이 달라질 때

• 금지 조건이나 민감 표현이 포함될 수 있을 때

예를 들어 고객지원 답변 초안 템플릿이라면 이런 분기가 가능하다.

상황 변수:
- 문의 유형: {case_type}
- 긴급도: {urgency}
- 정책 근거 충분 여부: {policy_status}

조건:
- 환불 문의이면 절차와 필요 정보를 먼저 안내하라.
- 장애 문의이면 현재 상태, 확인 중 여부, 다음 안내 시점을 포함하라.
- 긴급도가 높으면 첫 문장에서 상황 인지와 우선 대응 의사를 밝히라.
- 정책 근거가 불충분하면 확답하지 말고 확인이 필요한 항목을 분리하라.

이런 분기는 프롬프트를 더 똑똑해 보이게 만드는 장식이 아니다. 실제로 가장 많이 틀어지는 지점을 고정해 주는 안전장치다.

변수와 조건은 짝으로 움직일 때 힘이 세다

여기서 한 가지 중요한 감각이 있다. 변수만 있고 조건이 없으면, 템플릿은 빈칸은 많지만 방향이 없는 문서가 된다. 반대로 조건만 많고 변수가 없으면, 지나치게 고정된 규정집이 된다.

둘은 짝으로 움직일 때 가장 강하다. 예를 들어 {audience_level}이라는 변수가 생기면, 초급·중급·고급에서 무엇이 달라지는지 조건이 따라와야 한다. {tone}이 있다면 각 톤에서 허용되는 표현과 피해야 할 표현이 함께 와야 한다. {length}가 있다면 분량별 정보 우선순위가 붙어야 한다.

즉, 변수는 선택지이고 조건은 해석 규칙이다. 선택지만 있고 해석 규칙이 없으면 사람도 헷갈리고 모델도 흔들린다.

실전 예시: 하나의 설명 템플릿을 여러 상황으로 확장하기

이제 아주 흔한 업무 하나를 잡아 보자. "어떤 개념을 설명해 달라"는 요청이다. 이 업무는 얼핏 단순해 보이지만, 독자 수준과 톤과 길이에 따라 결과가 크게 달라진다.

먼저 일회성 프롬프트는 보통 이렇게 생긴다.

프롬프트 템플릿이 뭔지 설명해 줘.

나쁘지 않다. 하지만 이 문장만으로는 누구에게, 어떤 깊이로, 어떤 말투로, 어느 정도 길이로 설명해야 하는지가 전혀 보이지 않는다.

이것을 확장 가능한 템플릿으로 바꾸면 다음처럼 만들 수 있다.

당신은 업무 개념을 설명하는 도우미다.
제공된 주제를 독자 수준과 목적에 맞게 설명하라.

입력:
- 주제: {topic}
- 독자 수준: {audience_level}
- 톤: {tone}
- 분량: {length}
- 목적: {purpose}

공통 규칙:
- 핵심 개념을 먼저 설명하라.
- 추상적인 설명만 하지 말고 필요하면 예시를 포함하라.
- 주제와 직접 관련 없는 내용으로 확장하지 말라.

조건:
- 초급이면 쉬운 표현을 사용하고, 낯선 용어는 짧게 풀이하라.
- 중급이면 원리와 활용법을 함께 설명하라.
- 고급이면 차이점, 한계, 예외 상황을 포함하라.
- 정중한 톤이면 단정하고 차분한 문장을 사용하라.
- 친근한 톤이면 부담 없는 말투를 쓰되 가벼운 농담은 넣지 말라.
- 짧게이면 정의와 핵심 특징만 제시하라.
- 자세히이면 예시와 실무 적용 장면까지 포함하라.

출력 형식:
1. 한 줄 정의
2. 핵심 설명
3. 예시 또는 적용 장면
4. 주의할 점

이 템플릿의 좋은 점은 한 번 만들면 여러 상황에 재사용할 수 있다는 것이다. 예를 들어 초급·친근한·짧게 조합이면 입문용 설명이 되고, 고급·전문적인·자세히 조합이면 내부 교육 자료의 초안이 된다. 하나의 본체에서 다양한 버전을 뽑아낼 수 있는 셈이다.

실전 예시: 이메일 초안 템플릿을 분기형으로 만들기

이메일 초안도 변수와 조건이 특히 잘 먹히는 업무다. 독자와 목적과 톤이 달라질 때 결과 차이가 바로 보이기 때문이다.

단순 프롬프트는 이렇다.

이메일 답장 써 줘.

이제 이것을 조금 더 일하는 도구답게 바꿔 보자.

당신은 실무 이메일 초안을 작성하는 보조자다.
주어진 상황에 맞춰 읽기 쉬운 이메일 초안을 작성하라.

입력:
- 이메일 목적: {email_goal}
- 수신자 관계: {recipient_type}
- 톤: {tone}
- 분량: {length}
- 반드시 포함할 정보: {must_include}
- 피해야 할 표현: {avoid_terms}

공통 규칙:
- 핵심 요청이나 전달 사항을 분명히 하라.
- 수신자와 관계에 맞는 예의를 유지하라.
- 불필요하게 장황한 서두는 줄여라.

조건:
- 외부 고객이면 내부 용어를 쓰지 말라.
- 내부 팀원이면 배경 설명을 줄이고 실행 항목을 명확히 하라.
- 정중한 톤이면 요청 표현을 부드럽게 하라.
- 단호한 톤이면 기준과 마감 일정을 명확히 하되 공격적으로 쓰지 말라.
- 짧게이면 한 문단과 핵심 bullet 3개 이내로 정리하라.
- 회신 요청 메일이면 원하는 답변 기한을 포함하라.
- 사과 메일이면 문제 인지, 유감 표현, 후속 조치를 포함하라.

출력 형식:
- 제목 제안
- 이메일 본문
- 빠뜨리기 쉬운 체크 포인트 1줄

이 템플릿은 상황별 분기가 분명하다. 외부 고객인지 내부 팀원인지, 사과 메일인지 회신 요청 메일인지에 따라 문장의 역할이 달라진다. 이제 같은 템플릿을 써도 꽤 다른 맥락을 처리할 수 있다.

좋은 변수는 사람이 넣기 쉽고, 나쁜 변수는 해석부터 어렵다

프롬프트를 만드는 사람은 보통 변수 이름을 가볍게 생각한다. 하지만 변수 이름은 생각보다 중요하다. 사람이 매번 값을 넣어야 하기 때문이다.

예를 들어 {style}이라는 변수는 너무 넓다. 무엇을 넣어야 하는지 애매하다. 정중한 톤을 뜻하는지, 문단형 출력을 뜻하는지, 마케팅 문체를 뜻하는지 알기 어렵다. 반면 {tone}, {output_format}, {audience_level}처럼 역할이 분명한 이름은 사용하기 쉽다.

좋은 변수 이름에는 세 가지 특징이 있다.

• 무엇을 넣어야 하는지 바로 이해된다.

• 비슷한 값을 반복해서 넣기 쉽다.

• 팀원이 봐도 해석이 크게 갈리지 않는다.

예를 들어 {reader}보다 {audience_level}이 더 낫고, {kind}보다 {case_type}이 더 낫다. 템플릿은 만드는 순간보다 나중에 다시 꺼내 쓸 때 가치가 커지기 때문에, 읽자마자 이해되는 변수명이 큰 힘을 발휘한다.

조건문은 친절해야 하지만, 지나치게 복잡하면 안 된다

조건문이 많아질수록 템플릿은 정교해질 수 있다. 하지만 어느 순간부터는 오히려 무거워진다. 이때 생기는 문제는 두 가지다. 첫째, 사람이 템플릿을 읽기 어렵다. 둘째, 어떤 조건이 실제로 중요한지 흐려진다.

조건문은 자주 실패하는 지점에만 붙이는 편이 좋다. 매번 문제가 되는 곳, 품질 차이를 크게 만드는 곳, 실수 비용이 큰 곳부터 우선한다. 예를 들어 고객응대에서 "정보가 불충분하면 확답하지 말 것"은 매우 중요한 조건이다. 반면 "가능하면 문장의 리듬을 자연스럽게 할 것"은 템플릿의 핵심 조건이라고 보기 어렵다.

조건문을 쓸 때는 문장을 이렇게 바꾸면 도움이 된다.

• 추상적 표현보다 행동 지시로 쓴다.

• 예외 상황을 명시한다.

• 빈칸 처리 방식을 정한다.

예를 들어 "정확하게 써라"보다는 "입력 자료에 없는 사실은 추가하지 말라"가 낫다. "좋은 길이로 써라"보다는 "짧게일 때는 결론 먼저, 세부 사례 생략"이 낫다. 조건문은 감상평이 아니라 행동 규칙이어야 한다.

하나의 템플릿을 여러 버전으로 쪼개지 않게 만드는 방법

실무에서는 템플릿이 늘어나기 시작하면 금세 비슷한 파일이 여러 개 생긴다. "보고용 요약", "임원용 요약", "짧은 보고용 요약", "정중한 임원용 요약"처럼 이름만 조금 다른 템플릿이 쌓이기 쉽다. 이렇게 되면 관리가 어려워지고, 어느 템플릿이 최신인지도 헷갈린다.

이 문제를 줄이는 가장 좋은 방법이 바로 변수화와 조건 분기다. 비슷한 업무라면 템플릿을 여러 개 복제하기보다, 공통 본체 하나를 두고 자주 바뀌는 지점만 변수로 설계하는 편이 낫다.

예를 들어 다음 네 문장은 사실 별도 템플릿이 아니라 하나의 템플릿이 처리할 수 있는 범위일 때가 많다.

• 팀장용 짧은 회의 요약

• 실무자용 자세한 회의 요약

• 임원용 담백한 브리프

• 교육용 쉬운 설명형 요약

이 네 개를 전부 따로 만드는 대신 {audience_level}, {tone}, {length}, {purpose}를 중심으로 하나의 공통 템플릿을 만드는 것이다. 그러면 수정이 필요할 때도 본체 한 곳만 고치면 된다.

변수 설계는 결국 업무 분류 감각이다

프롬프트를 잘 확장하는 사람은 문장을 화려하게 꾸미는 사람이 아니라, 일이 어디서 달라지는지를 잘 아는 사람이다. 어떤 업무는 독자 수준 차이가 가장 중요하고, 어떤 업무는 형식 차이가 중요하다. 또 어떤 업무는 정보 부족 시 처리 방식이 핵심이다.

예를 들어 교육 자료라면 {audience_level}과 {example_depth}가 중요할 수 있다. 마케팅 카피라면 {tone}과 {channel}이 중요할 수 있다. 고객지원이라면 {case_type}과 {policy_status}가 중요할 수 있다. 같은 "프롬프트 확장"이라도 무엇을 변수로 뽑아야 하는지는 업무에 따라 다르다.

그래서 좋은 질문은 이것이다.

"이 업무에서 결과를 가장 많이 바꾸는 차이는 무엇인가?"

그 차이가 바로 변수 후보가 된다.

확장 가능한 템플릿을 만드는 간단한 순서

처음부터 완벽하게 설계하려 하면 손이 멈추기 쉽다. 그럴 때는 아래 순서로 작게 시작하면 좋다.

이 순서를 따르면 템플릿이 지나치게 복잡해지는 일을 막을 수 있다. 먼저 본체를 세우고, 꼭 필요한 손잡이만 붙이는 것이다.

이 장의 핵심 정리

좋은 템플릿은 하나의 문장을 길게 늘이는 방식으로 확장되지 않는다. 대신 자주 바뀌는 요소를 변수로 빼고, 그 값에 따라 어떻게 달라져야 하는지를 조건으로 붙인다. 독자 수준은 설명의 깊이를 바꾸고, 톤은 표현의 결을 바꾸고, 길이는 정보의 우선순위를 바꾼다. 상황별 분기는 예외와 누락과 민감한 순간에 템플릿이 흔들리지 않게 만든다.

핵심은 한 개의 프롬프트로 모든 것을 해결하는 만능 문장을 만드는 데 있지 않다. 오히려 공통 본체 하나를 두고, 필요한 만큼만 유연하게 움직이게 만드는 데 있다. 그래야 템플릿이 복붙용 문장이 아니라, 여러 업무 맥락을 버티는 실전 도구가 된다.

다음 장에서는 여기서 한 걸음 더 나아가, 입력이 모호하거나 정보가 비어 있을 때도 쉽게 무너지지 않는 템플릿을 만드는 방법을 살펴본다.