AI가 일하게 만드는 입력 설계: 프롬프트, 템플릿, 규칙 만들기

AI 자동화를 처음 붙일 때 많은 사람이 제일 먼저 묻는다. "어떤 모델이 제일 좋아요?" 물론 모델도 중요하다. 하지만 실무에서는 그보다 먼저 물어야 할 질문이 있다. "AI에게 일을 어떻게 시킬 건가요?"

같은 모델을 써도 어떤 사람은 10분 걸리던 업무를 2분으로 줄이고, 어떤 사람은 결과를 다시 고치느라 더 오래 걸린다. 차이는 대개 성능이 아니라 입력 설계에 있다. 입력 설계란 AI에게 일을 맡기기 위해 필요한 지시문, 참고 자료, 출력 형식, 판단 기준을 한 덩어리로 만드는 일이다. 쉽게 말하면, "말을 잘 거는 기술"이 아니라 "업무 지시서를 제대로 쓰는 기술"이다.

이번 장에서는 이메일 요약, 문서 분류, 답변 초안, 보고서 초안처럼 반복적으로 발생하는 실무를 대상으로, 바로 복붙해서 쓸 수 있는 프롬프트와 템플릿, 규칙을 만드는 방법을 익힌다. 목표는 멋진 문장을 쓰는 것이 아니다. 내가 다시 손대는 시간을 줄이는 것이다.

좋은 결과는 똑똑한 AI보다 선명한 지시에서 나온다

사람에게 일을 맡길 때를 떠올려보자. "이거 좀 정리해 주세요"라고 말하면 결과는 들쭉날쭉하다. 하지만 "이 메일 20개를 읽고, 고객 불만 유형별로 묶고, 긴급 건만 맨 위에 올리고, 오늘 안에 답해야 할 건만 따로 표시해 주세요"라고 말하면 일이 훨씬 정확해진다.

AI도 똑같다. 막연한 요청에는 막연한 답이 온다. 반대로 맥락과 기준이 분명하면 AI는 놀랄 만큼 꾸준하게 일한다. 특히 자동화에서는 한 번 잘 시키는 것이 중요하다. 매번 손으로 다시 설명하면 자동화가 아니라 귀찮음의 외주가 된다.

입력 설계의 목적은 세 가지다. 첫째, AI가 해야 할 일을 좁힌다. 둘째, 결과물을 바로 다음 단계에 넘길 수 있게 만든다. 셋째, 검수 포인트를 미리 심어 오류를 줄인다. 이 세 가지가 갖춰지면 AI는 "대충 도와주는 도구"가 아니라 "일부 단계를 맡는 작업자"가 된다.

프롬프트는 채팅이 아니라 업무 지시서다

프롬프트를 잘 쓰려면 먼저 관점을 바꿔야 한다. 프롬프트는 질문이 아니라 작업 지시서다. 좋은 작업 지시서에는 늘 같은 요소가 들어간다.

• 무엇을 해야 하는가

• 어떤 자료를 보고 해야 하는가

• 어떤 기준으로 판단해야 하는가

• 어떤 형식으로 결과를 내야 하는가

• 모르면 어떻게 처리해야 하는가

이 다섯 가지가 빠지면 결과가 흔들린다. 반대로 이 다섯 가지를 넣으면 프롬프트가 길어져도 오히려 실무에서는 편해진다. 긴 프롬프트가 나쁜 것이 아니다. 애매한 프롬프트가 나쁜 것이다.

예를 들어 "이 메일 요약해 줘"는 짧지만 실무에는 약하다. 중요한 일정이 빠질 수도 있고, 요청 사항이 누락될 수도 있으며, 긴급도를 구분하지 못할 수도 있다. 반면 "아래 이메일을 읽고 5줄 이내로 요약하되, 요청사항·마감일·담당자·긴급도를 분리해서 보여줘. 불확실한 정보는 추정하지 말고 '확인 필요'로 표시해 줘"는 바로 쓸 수 있는 결과를 만들 가능성이 훨씬 높다.

입력 설계의 핵심 4요소

실무 자동화용 입력 설계는 복잡해 보이지만, 사실 네 가지 요소로 정리된다.

• 자료: AI가 읽을 원문, 메일, 회의록, 정책 문서, 고객 문의, 이전 보고서 같은 입력 데이터

• 목적: 요약, 분류, 초안 작성, 비교, 추출, 판단 보조처럼 이번 단계에서 해야 할 일

• 기준: 무엇을 중요하게 볼지, 무엇을 빼야 할지, 어떤 규칙을 따라야 할지에 대한 판단 원칙

• 형식: 표, JSON, 항목별 리스트, 제목+본문, 짧은 메모 등 다음 단계가 바로 사용할 출력 구조

이 네 가지 중 하나라도 빠지면 작업 품질이 흔들린다. 자료가 부족하면 엉뚱한 말을 만들고, 목적이 흐리면 두루뭉술해지고, 기준이 없으면 사람마다 다른 결과처럼 들쭉날쭉해지고, 형식이 없으면 붙여넣고 다시 정리하느라 시간이 든다.

특히 자동화에서 가장 많이 놓치는 것이 형식이다. 사람은 문장을 읽고 알아서 정리할 수 있지만, 다음 단계의 앱은 그렇지 않다. 메일 발송 도구, 데이터베이스, 슬랙 알림, CRM은 정해진 칸에 정해진 값을 받아야 움직인다. 그래서 "좋은 문장"보다 "예측 가능한 구조"가 중요하다.

출력 형식을 먼저 정하면 일이 빨라진다

실무에서는 종종 프롬프트를 먼저 쓰고, 결과를 본 뒤 형식을 고친다. 그런데 효율적인 순서는 그 반대다. 먼저 결과물이 어디로 갈지를 정하고, 그다음 그 형식에 맞게 프롬프트를 만든다.

예를 들어 이메일 요약 결과가 슬랙으로 갈 것인지, 노션 데이터베이스에 저장될 것인지, 엑셀 표로 쌓일 것인지에 따라 출력 형식은 달라진다. 슬랙이라면 짧고 한눈에 들어와야 하고, 데이터베이스라면 각 칼럼에 맞춰 분리되어야 하며, 보고서 초안이라면 문단 흐름이 자연스러워야 한다.

같은 일을 시켜도 출력 형식에 따라 재작업 시간은 크게 달라진다.

AI는 출력 형식을 알려주면 훨씬 안정적으로 일한다. 그래서 자동화에서는 "무엇을 말할까"보다 "어떤 칸에 나눠 담을까"를 먼저 고민해야 한다.

실무 프롬프트의 기본 골격

아래 골격은 대부분의 반복 업무에 그대로 적용할 수 있다.

당신은 [역할]입니다.
목표: [이번 단계에서 해야 할 일]
대상 자료: [입력 데이터]
중요 기준:
1) [중요하게 볼 기준]
2) [제외하거나 주의할 기준]
3) [판단이 어려울 때 처리 방식]
출력 형식:
- [필드1]
- [필드2]
- [필드3]
제약:
- 모르는 내용은 추정하지 말 것
- 근거 없는 단정 금지
- 필요한 경우 '확인 필요'로 표시

이 골격이 좋은 이유는 멋있어서가 아니라, 자동화에 필요한 질문을 빠뜨리지 않게 해 주기 때문이다. 역할은 톤과 관점을 맞춰 주고, 목표는 작업 범위를 좁혀 주며, 기준은 품질을 지키고, 출력 형식은 다음 단계 연결을 쉽게 만든다.

다만 역할은 과장할 필요가 없다. "세계 최고의 천재 컨설턴트" 같은 수식은 대부분 실무에 도움이 되지 않는다. 오히려 "고객 문의를 분류하는 운영 담당자", "회의록을 정리하는 프로젝트 매니저", "영업 이메일 초안을 쓰는 담당자"처럼 현실적인 역할이 더 유용하다.

템플릿은 반복을 줄이고, 규칙은 흔들림을 줄인다

프롬프트를 한 번 잘 썼다고 끝이 아니다. 실무에서는 같은 종류의 일이 계속 들어온다. 그래서 매번 새로 쓰는 대신 템플릿으로 묶어야 한다.

템플릿은 바뀌는 부분과 안 바뀌는 부분을 나누는 작업이다. 예를 들어 이메일 요약 업무에서는 요약 방식과 출력 형식은 거의 고정이고, 바뀌는 것은 메일 원문뿐이다. 이럴 때 템플릿을 만들어 두면 누구나 같은 품질로 돌릴 수 있다.

규칙은 더 중요하다. 규칙은 AI가 애매한 상황에서 멋대로 판단하지 않게 막는 울타리다. 예를 들어 이런 규칙이 있을 수 있다.

• 날짜가 명시되지 않으면 마감일을 추정하지 않는다.

• 고객 불만이 포함되면 긴급도를 한 단계 올린다.

• 법률, 세무, 의료처럼 민감한 조언은 초안까지만 작성하고 최종 판단은 사람에게 넘긴다.

• 입력 문서에 없는 사실은 추가하지 않는다.

이 규칙이 없으면 결과는 그럴듯해 보여도 위험해진다. 자동화에서 중요한 것은 '한 번 멋지게 맞추는 것'이 아니라 '계속 안전하게 비슷한 품질로 나오는 것'이다.

좋은 프롬프트보다 좋은 템플릿이 오래 간다

실무자는 종종 한 번 잘 나온 프롬프트를 비밀 무기처럼 여긴다. 하지만 조직에서 오래 쓰이는 것은 번뜩이는 한 문장이 아니라 관리 가능한 템플릿이다.

좋은 템플릿은 다음 조건을 갖는다.

• 누가 써도 비슷한 결과가 나온다.

• 입력 데이터만 바꾸면 다시 사용할 수 있다.

• 출력 형식이 고정되어 다음 도구에 연결하기 쉽다.

• 예외 상황 처리 방식이 포함되어 있다.

• 검수자가 무엇을 확인해야 하는지 드러난다.

즉, 템플릿은 개인의 감각을 조직의 자산으로 바꾸는 장치다. 당신이 휴가를 가도 돌아가는 자동화는 대개 프롬프트를 잘 쓴 시스템이 아니라 템플릿과 규칙이 잘 정리된 시스템이다.

실습 1: 이메일 요약 프롬프트 만들기

가장 빨리 효과를 보는 업무 중 하나가 이메일 요약이다. 특히 참조가 많은 메일, 고객 요청 메일, 내부 협업 메일은 읽는 시간도 길고 놓치기 쉬운 정보도 많다.

핵심은 '예쁘게 요약'이 아니라 '바로 처리 가능하게 요약'하는 것이다. 그래서 요약 프롬프트에는 요청 사항, 마감일, 담당자, 위험 신호가 꼭 들어가야 한다.

당신은 업무 이메일을 선별하고 정리하는 비서입니다.
아래 이메일을 읽고 바로 업무 처리에 사용할 수 있도록 요약하세요.

목표:
- 핵심 내용을 짧게 요약
- 요청사항과 마감일을 분리
- 긴급도를 판단
- 불명확한 내용은 '확인 필요'로 표시

출력 형식:
1. 한 줄 요약:
2. 발신자:
3. 요청사항:
4. 마감일:
5. 긴급도: 높음 / 보통 / 낮음
6. 확인 필요:
7. 추천 다음 행동:

규칙:
- 이메일에 없는 사실은 추가하지 말 것
- 일정이 모호하면 추정하지 말 것
- 요청사항이 여러 개면 번호로 구분할 것

이메일 원문:
[여기에 이메일 붙여넣기]

이 프롬프트의 장점은 사람이 다시 읽어야 할 이유를 줄인다는 점이다. 특히 '추천 다음 행동'이 있으면 메일을 읽고 멈추지 않고 바로 다음 단계로 넘어가기 쉽다. 예를 들어 "답장 필요", "담당자 전달", "캘린더 등록", "추가 정보 요청"처럼 행동으로 바뀌는 요약이 자동화에 적합하다.

실습할 때는 같은 프롬프트로 메일 5개를 돌려 보자. 그리고 결과를 보고 긴급도 판단이 들쭉날쭉하면 규칙을 추가하면 된다. 예를 들어 "오늘, ASAP, 긴급, 장애, 불만, 계약" 같은 단어가 있으면 긴급도를 높이도록 보정할 수 있다.

실습 2: 문서 분류 프롬프트 만들기

문서 분류는 생각보다 강력하다. 문서를 분류해야 저장 위치가 정해지고, 담당자가 정해지며, 이후 자동화도 붙일 수 있기 때문이다. 분류가 흔들리면 뒤의 흐름이 모두 흔들린다.

문서 분류 프롬프트는 반드시 '분류 기준'과 '근거'를 함께 요구해야 한다. 분류 결과만 받으면 틀렸을 때 왜 틀렸는지 알기 어렵다.

당신은 들어온 문서를 업무 유형별로 분류하는 운영 담당자입니다.
아래 문서를 읽고 가장 적절한 문서 유형을 하나 선택하세요.

가능한 문서 유형:
- 계약서
- 제안서
- 세금계산서
- 회의록
- 고객 문의
- 이력서
- 기타

출력 형식:
1. 문서 유형:
2. 신뢰도: 0~100
3. 분류 근거: 문서 안의 표현 1~2개
4. 담당팀 추천:
5. 확인 필요 여부:

규칙:
- 문서 유형은 하나만 선택
- 애매하면 '기타'로 두고 이유를 쓸 것
- 근거 없는 추정 금지
- 민감 정보는 반복 출력하지 말 것

문서 원문:
[여기에 문서 붙여넣기]

여기서 중요한 것은 신뢰도와 근거다. 신뢰도는 사람이 어디를 먼저 검수할지 정하는 데 도움을 주고, 근거는 분류 품질을 빠르게 개선하게 해 준다. 만약 계약서와 제안서를 자주 혼동한다면, 규칙에 "계약 당사자, 효력, 서명, 조항이 있으면 계약서 우선" 같은 기준을 더 넣으면 된다.

실습 3: 답변 초안 프롬프트 만들기

답변 초안은 시간을 가장 많이 아껴 주는 작업 중 하나다. 다만 여기서 중요한 것은 '완성 답변'이 아니라 '검수하기 좋은 초안'을 만드는 것이다. AI가 최종 책임자가 되면 위험하지만, 사람의 첫 문장 부담을 없애 주는 초안 작성자로 쓰면 매우 강력하다.

답변 초안 프롬프트는 톤, 금지 표현, 필요한 확인 항목을 분명히 적어야 한다.

당신은 고객 문의에 답변 초안을 작성하는 담당자입니다.
아래 문의에 대해 친절하고 간결한 답변 초안을 작성하세요.

목표:
- 핵심 질문에 먼저 답할 것
- 필요한 추가 정보가 있으면 따로 요청할 것
- 과도한 약속이나 확정 표현은 피할 것

톤:
- 친절하지만 과장하지 않음
- 짧고 명확함
- 책임 회피처럼 들리지 않게 작성

출력 형식:
제목:
답변 초안:
추가로 확인할 정보:
내부 전달 필요 여부:

규칙:
- 정책에 없는 보상, 환불, 일정은 임의로 약속하지 말 것
- 불확실하면 '확인 후 안내드리겠습니다'로 표현할 것
- 공격적 표현은 중립적으로 바꿀 것

고객 문의:
[문의 원문]

이 템플릿은 CS, 영업, 채용, 협업 메일에도 응용할 수 있다. 예를 들어 영업 답변이라면 제품 장점과 다음 행동 유도 문장을 넣고, 채용 답변이라면 절차와 예상 일정을 추가하면 된다.

답변 초안 자동화에서 흔한 실수는 AI에게 '친절하게 써 줘'만 말하는 것이다. 그러면 말이 길어지고 핵심이 뒤로 밀린다. 실무에서는 예쁜 문장보다 빠른 전달이 중요하다. 첫 문장에 결론이 오게 하는 규칙 하나만 넣어도 품질이 크게 올라간다.

실습 4: 보고서 초안 프롬프트 만들기

보고서 초안은 AI가 특히 잘하는 작업처럼 보이지만, 실제로는 가장 쉽게 망가지는 작업이기도 하다. 이유는 목표가 넓고, 사람이 원하는 구조가 암묵적이기 때문이다. "보고서 써 줘"는 거의 실패한다. 대신 보고서가 담아야 할 질문을 쪼개야 한다.

좋은 보고서 초안 프롬프트는 '무엇을 요약할지'보다 '어떤 의사결정을 돕는 문서인지'를 밝혀야 한다.

당신은 팀장에게 보고할 주간 업무 보고서 초안을 작성하는 담당자입니다.
아래 자료를 바탕으로 의사결정에 필요한 정보만 간결하게 정리하세요.

목표:
- 이번 주 핵심 성과 요약
- 문제 이슈와 원인 정리
- 다음 주 액션 제안

출력 형식:
1. 한 줄 요약
2. 주요 성과
3. 핵심 수치
4. 이슈 및 원인
5. 다음 주 액션
6. 팀장 확인 필요 사항

규칙:
- 자료에 없는 수치는 만들지 말 것
- 성과와 계획을 구분할 것
- 문제는 감정이 아니라 사실 중심으로 쓸 것
- 문장은 짧게, 항목은 바로 복사 가능하게 작성

자료:
[회의 메모, 작업 로그, 성과 수치, 메일 내용 등]

이 프롬프트가 실무적인 이유는 '보고서처럼 보이는 글'이 아니라 '보고 가능한 글'을 만들기 때문이다. 특히 '팀장 확인 필요 사항' 항목은 보고서가 단순 기록이 아니라 의사결정 문서가 되게 만든다.

예시를 한두 개 넣으면 품질이 더 안정된다

AI는 패턴을 잘 따른다. 그래서 출력 형식을 말로 설명하는 것도 좋지만, 짧은 예시를 한두 개 보여주면 결과가 더 고정된다. 이 방식은 특히 분류, 제목 생성, 메일 답변처럼 형식이 자주 흔들리는 작업에서 유리하다.

예를 들어 이메일 요약 프롬프트 끝에 아래처럼 한 개의 예시를 붙일 수 있다.

예시 출력:
1. 한 줄 요약: 고객이 납기 지연 사유와 수정 일정을 요청함
2. 발신자: A사 구매팀 김OO
3. 요청사항:
   1) 지연 사유 설명
   2) 수정 납기 일정 회신
4. 마감일: 2026-04-22
5. 긴급도: 높음
6. 확인 필요: 실제 출고 가능 일자
7. 추천 다음 행동: 생산팀 일정 확인 후 오늘 중 회신 초안 작성

예시는 길 필요가 없다. 오히려 짧고 명확할수록 좋다. 중요한 것은 "어떤 답이 좋은 답인지"를 보여 주는 것이다.

실패하는 프롬프트는 대개 세 가지 이유로 망한다

첫째, 범위가 너무 넓다. "이 문서 분석해 줘"는 할 수 있는 일이 너무 많다. 요약인지, 분류인지, 리스크 검토인지 정해야 한다.

둘째, 기준이 없다. "중요한 내용 위주로 정리해 줘"라고 하면 AI가 생각하는 중요함과 당신이 생각하는 중요함이 다를 수 있다. 고객 요청, 일정 변경, 비용 이슈처럼 중요 기준을 적어야 한다.

셋째, 출력 형식이 없다. 결과는 괜찮아 보여도 나중에 복붙하고 다시 정리해야 하면 자동화 효과가 크게 줄어든다.

아래는 자주 보이는 나쁜 프롬프트와 개선 방향이다.

프롬프트가 마음에 안 들 때는 문장을 고급스럽게 바꾸려 하지 말고, 이 세 가지를 먼저 점검하면 된다. 범위, 기준, 형식. 실무 프롬프트의 절반은 여기서 승부가 난다.

규칙은 품질 관리 문서처럼 써야 한다

자동화가 커질수록 프롬프트만으로는 부족하다. 특히 여러 사람이 함께 쓰는 환경에서는 규칙 문서가 필요하다. 규칙은 AI를 혼내기 위한 것이 아니라 품질 기준을 고정하기 위한 것이다.

예를 들어 고객 문의 자동화 규칙은 이렇게 정리할 수 있다.

• 환불, 법적 분쟁, 개인정보 이슈가 포함되면 자동 답변하지 않고 사람 검토로 보낸다.

• 욕설이나 강한 불만이 있으면 감정 완화 문장을 우선 배치한다.

• 주문번호가 없으면 해결책 제시보다 정보 요청을 먼저 한다.

• 내부 정책에 없는 보상은 초안에 넣지 않는다.

이 규칙은 프롬프트 안에 넣을 수도 있고, 별도 운영 문서로 관리할 수도 있다. 중요한 것은 사람이 나중에 봤을 때 "왜 이런 출력이 나왔는지"를 설명할 수 있어야 한다는 점이다. 설명 가능한 자동화가 결국 오래 간다.

내 업무에 바로 적용하는 입력 설계 캔버스

이제 당신 업무 하나를 골라 아래 캔버스로 설계해 보자. 이 작업만 해도 프롬프트 품질이 크게 오른다.

1. 업무 이름

예: 고객 문의 1차 답변, 견적 요청 메일 정리, 주간 보고 초안 작성

2. 입력 자료

예: 이메일 본문, 첨부 문서, 회의 메모, CRM 기록, FAQ 문서

3. 이번 단계의 목표

예: 요약, 분류, 초안 작성, 누락 정보 추출

4. 꼭 지켜야 할 기준

예: 일정 추정 금지, 정책 외 약속 금지, 민감 이슈는 사람 검토

5. 출력 형식

예: 제목 / 요약 / 요청사항 / 마감일 / 추천 액션

6. 애매할 때 처리 방식

예: '확인 필요'로 표시, 담당자 검토로 전달, 기타로 분류

7. 검수 포인트

예: 사실 추가 여부, 일정 정확도, 고객 톤 적절성, 누락 항목 여부

이 캔버스의 장점은 단순하다. 프롬프트를 감각으로 쓰지 않게 만든다. 한 번 캔버스에 적고 나면, 그다음부터는 문장을 다듬는 일이 아니라 시스템을 조정하는 일이 된다.

실전에서는 프롬프트를 한 번에 완성하지 않는다

처음부터 완벽한 프롬프트를 만들려고 하면 오히려 늦어진다. 실전에서는 작은 반복이 더 중요하다. 가장 좋은 방법은 실제 업무 자료 5개 정도를 넣고 결과를 비교해 보는 것이다.

이때는 다음 순서로 고치면 된다.

• 누락이 많으면 출력 항목을 더 구체화한다.

• 엉뚱한 판단이 많으면 기준과 금지 규칙을 추가한다.

• 말이 너무 길면 분량 제한을 건다.

• 형식이 흔들리면 예시 출력을 넣는다.

• 애매한 건이 많으면 '확인 필요' 처리 규칙을 강화한다.

즉, 프롬프트 개선은 문학이 아니라 운영이다. 잘 쓴 한 문장을 찾는 게임이 아니라, 오류를 줄이고 재작업을 줄이는 조정 작업이다.

이번 장의 핵심

AI 자동화에서 가장 큰 차이는 모델 이름이 아니라 입력 설계에서 난다. 프롬프트는 채팅 기술이 아니라 업무 지시서이고, 템플릿은 반복 업무를 고정된 품질로 돌리게 하는 장치이며, 규칙은 애매한 순간의 사고를 막는 안전장치다.

좋은 입력 설계는 늘 같은 질문으로 시작한다. 무엇을 할 것인가. 무엇을 보고 할 것인가. 어떤 기준을 따를 것인가. 어떤 형식으로 낼 것인가. 애매하면 어떻게 처리할 것인가.

이 다섯 가지가 잡히면 AI는 '똑똑한 말 상대'에서 '실무 단계를 맡는 작업자'로 바뀐다. 그리고 그 순간부터 자동화는 진짜로 일을 줄이기 시작한다.

다음 장에서는 이렇게 설계한 입력을 바탕으로, 문서·메일·회의 같은 비정형 데이터를 AI가 읽을 수 있는 작업 재료로 바꾸는 방법을 다룬다. 결국 자동화는 데이터가 밥이고, 입력 설계는 그 밥상을 차리는 일이다. 밥상이 좋아야 일도 잘한다.