처음 만드는 AI 업무 절차서, 프롬프트보다 예외 상황을 먼저 적는 이유
처음 만드는 AI 업무 절차서는 프롬프트보다 예외 상황을 먼저 적는 편이 낫습니다. 비용, 처리 속도, 성과는 검증된 자료가 없어 판단 근거에서 제외했습니다.
먼저 확인한 범위
| 항목 | 이번 판단의 조건 |
|---|---|
| 대상 | 처음 AI 업무 절차서를 만드는 솔로 운영자와 작은 팀 |
| 시작 도구 | 무료로 작성할 수 있는 일반 문서 |
| AI의 역할 | 이미 정리된 내용을 절차서 형식의 초안으로 변환 |
| 사람의 역할 | 예외, 승인 주체, 책임 이동, 중단 조건 검수 |
| 제외 범위 | 비용, 사용자 수, 전환율, 운영 기간, 성과 비교 |
이 조건에서 답은 단순합니다. 좋은 문장을 만드는 일보다 일이 멈춰야 할 순간을 정의하는 일이 먼저입니다. 프롬프트가 매끄러워도 예외의 주인이 비어 있으면 절차서는 실제 상황에서 바로 흔들립니다.
3줄 요약
- 정상 사례는 업무가 평소처럼 흘러가는 기준입니다.
- 예외에는 판단할 담당자와 AI가 멈출 조건이 함께 붙어야 합니다.
- AI가 만든 초안은 문장보다 책임 경계 표로 검수할 수 있습니다.
절차서의 품질은 AI가 무엇을 쓰는지가 아니라, 어디서 멈추는지가 결정합니다.
평범한 하루보다 어긋난 순간이 먼저였습니다
가상 예시로 ‘편의점 1+1 행사 앱’의 문의 분류를 생각해봤습니다. 정상 사례만 적으면 흐름은 간단합니다. 문의 내용을 읽고, 행사 상품인지 확인하고, 정해진 답변 후보를 제시하는 식입니다.
문제는 정상 흐름 밖에서 생깁니다. 영수증이 흐리거나, 행사 기간을 확인할 수 없거나, 개인정보가 포함되거나, 환불 판단이 필요한 경우입니다. 이때 필요한 것은 더 긴 프롬프트가 아닙니다. 누가 판단하며, 어떤 상태에서는 자동 처리를 중단하는지에 대한 문장입니다.
저는 절차서의 첫 재료를 다음처럼 한 줄씩 나누는 편이 안전하다고 봅니다.
| 구분 | 한 줄 기록 예시 |
|---|---|
| 정상 사례 | 행사 정보가 확인되면 답변 후보를 작성 |
| 예외 | 행사 정보가 없거나 서로 충돌하면 판단 보류 |
| 담당자 | 정책 판단이 필요한 문의는 운영 담당자가 확인 |
| 중단 조건 | 개인정보나 환불 결정이 포함되면 자동 처리 중단 |
이 표는 완성된 절차서가 아닙니다. 다만 초안이 책임을 슬쩍 건너뛰지 못하게 만드는 최소 재료입니다.
[이미지 캡션: 무료 문서 안에서 정상 사례, 예외, 담당자, 중단 조건을 한 화면에 비교한 실제 절차 초안]
AI에는 결정이 아니라 정리를 맡겼습니다
AI가 맡을 부분은 이미 적힌 재료를 순서가 있는 문서로 바꾸는 일입니다. 입력, 확인 항목, 정상 처리, 예외 분기, 사람 검토, 종료 상태처럼 읽기 쉬운 구조로 정리하는 데에는 잘 맞습니다.
반대로 “알아서 안전하게 처리” 같은 문장은 책임 경계를 흐립니다. 안전의 의미도, 최종 판단자도, 보류된 업무의 도착지도 보이지 않기 때문입니다. 초안이 자연스럽게 읽힌다는 이유만으로 운영 가능한 문서가 되지는 않습니다.
초안 요청에 들어갈 내용도 거창할 필요는 없습니다.
- 업무의 시작 상태
- 정상 사례의 처리 결과
- 알려진 예외 상황
- 예외별 담당자
- 자동 처리를 멈추는 조건
- 판단할 수 없는 항목의 표시 방식
핵심은 빈칸을 추측해 채우지 않는다는 조건입니다. 확인되지 않은 부분은 미정 상태로 남아야 사람이 검수할 수 있습니다.
AI가 빈칸을 자연스럽게 메우는 순간, 절차서에는 근거 없는 책임자가 생길 수 있습니다.
문장 대신 책임 경계를 표로 읽었습니다
절차서 검수에서 먼저 볼 것은 표현의 매끄러움이 아닙니다. 한 단계가 실패했을 때 다음 책임자가 보이는지, 사람이 개입한 뒤 업무가 어디로 돌아오는지, 멈춘 건을 누가 닫는지가 더 중요합니다.
| 상황 | AI가 해도 되는 일 | 사람이 판단할 일 | 중단 뒤 상태 |
|---|---|---|---|
| 정보가 충분한 정상 문의 | 분류와 답변 후보 작성 | 필요 시 최종 확인 | 답변 대기 |
| 정보가 누락된 문의 | 누락 항목 표시 | 추가 확인 여부 결정 | 보류 |
| 정책 판단이 필요한 문의 | 관련 문장과 쟁점 정리 | 적용 정책 결정 | 검토 대기 |
| 민감한 정보가 포함된 문의 | 자동 처리 중단 표시 | 열람과 후속 조치 결정 | 격리 상태 |
| 서로 충돌하는 자료 | 충돌 지점 표시 | 신뢰할 자료 선택 | 판단 대기 |
여기서 빈칸은 문서 문제가 아니라 운영 문제입니다. 담당자가 없는 예외, 종료 상태가 없는 보류, 승인 뒤 복귀 지점이 없는 흐름은 초안을 다듬는다고 해결되지 않습니다.
복사해 쓰는 첫 절차서 체크리스트
아래 항목은 무료 문서의 첫 페이지에 그대로 옮겨 쓸 수 있는 검수 산출물입니다.
- 업무가 시작되는 입력과 종료 상태가 보이는가
- 정상 사례가 한 문장으로 구분되는가
- 알려진 예외마다 담당자가 있는가
- AI가 판단하지 않을 항목이 분리되어 있는가
- 중단 조건이 모호한 표현 없이 적혀 있는가
- 보류된 업무가 도착할 위치가 있는가
- 사람의 승인 뒤 되돌아갈 단계가 보이는가
- 확인되지 않은 내용이 사실처럼 채워지지 않았는가
- 같은 상황을 AI와 사람이 동시에 책임지지 않는가
- 최종 결과를 닫는 주체가 보이는가
체크리스트에서 답할 수 없는 항목은 프롬프트 수정 대상이 아니라 운영 합의 대상입니다.
실패는 대개 예외 다음 칸에서 생깁니다
예외를 적는 것만으로는 부족합니다. “문제가 생기면 사람이 확인”이라고 써두면 누가 확인하는지, 확인 전까지 업무는 어떤 상태인지, 확인 뒤 어디서 다시 시작하는지가 남습니다.
또 하나의 한계는 문서가 실제 정책을 대신할 수 없다는 점입니다. 개인정보 처리나 환불 권한처럼 별도 기준이 필요한 업무는 절차서 초안만으로 결정할 수 없습니다. 이번 글에는 실제 운영 기간이나 성과 자료도 없습니다. 따라서 이 구성이 처리 품질을 높였다고 주장할 근거는 없습니다.
검증 가능한 것은 구조뿐입니다. 정상 사례, 예외, 담당자, 중단 조건이 문서에 존재하는지 확인하고, 각 예외의 책임 이동을 표에서 추적할 수 있습니다. 그 이상은 실제 업무 기록이 쌓인 뒤 별도로 판단할 영역입니다.
최종 판단은 프롬프트보다 앞에 있습니다
처음 만드는 AI 업무 절차서라면 무료 문서로도 출발점은 충분합니다. 다만 첫 줄에는 멋진 지시문보다 정상 사례와 예외가 필요합니다. 그다음 담당자와 중단 조건을 붙이고, AI에는 초안의 구조화만 맡기는 편이 책임을 확인하기 쉽습니다.
최종 검수는 “잘 썼는가”보다 “문제가 생겼을 때 누가 이어받는가”라는 질문에 가깝습니다. 그 답이 표에서 보이지 않는다면 아직 자동화할 절차가 아니라, 먼저 합의할 업무입니다.
이어지는 기록
처음 만드는 AI 업무 절차서는 프롬프트보다 예외·담당자·중단 조건을 먼저 적고, 책임 이동을 표로 검수하는 문서에서 시작합니다.
근거와 범위
| 근거 | 뒷받침하는 내용 | 경계 |
|---|---|---|
| Google 자동완성, 2026-09-03 검토 | AI SOP template 정확한 검색어가 현재 제안 표면에 나타나는지 확인 | 검색어 표면 신호일 뿐 검색량·순위·구매 의도·성과는 아님 |
| 합성 편집 예시 | 이 글에서 다루는 항목이나 판단 흐름을 보여 줌 | 실제 운영 성과를 측정한 결과는 아님 |
검토일은 2026-09-03이고, 합성 편집 조건에서 비공개 자료·외부 전송·운영 성과를 사용하지 않았어요.