처음 쓰는 AI 작업 절차서: 잘된 예보다 실패한 예를 먼저 두는 이유

처음 쓰는 AI 작업 절차서에는 잘된 예보다 실패한 예 한 개를 먼저 넣는 편이 낫습니다. 입력, 허용할 수 없는 결과, 사람의 수정 기준을 함께 적어야 다른 사람도 같은 산출물을 보고 통과와 반려를 가를 수 있기 때문입니다. 기능 설명보다 판별 기준이 먼저입니다.

먼저 확인한 조건

이 글은 특정 서비스의 성능을 평가한 기록이 아닙니다. 공개할 수 있는 범위 안에서, 처음 절차서를 만들 때 필요한 문서 구조와 검토 기준만 다룹니다.

항목	내용
검토일	2026-09-04
적용 대상	반복해서 만들고 사람이 최종 검토하는 AI 보조 업무
검증 범위	입력 예시, 실패 예시, 수정 기준, 인수인계 가능성
제외 범위	비용, 매출, 사용자 수, 전환율, 처리 기간, 특정 실행 환경
공개 제한	내부 모델, 제공자, 프롬프트, 제작 환경은 기록하지 않음

이 조건에서 답은 단순합니다. 절차서는 AI가 무엇을 할 수 있는지 설명하는 문서가 아니라, 사람이 결과를 어떻게 판정할지 합의하는 문서여야 합니다.

좋은 출력만 보여주면 따라 쓸 수는 있어도, 틀린 출력을 멈추기는 어렵습니다.

실패한 예가 기준선을 만든다

가상 업무로 ‘편의점 행사 안내문 요약’을 떠올려봤습니다. 잘된 예만 있다면 문서는 이렇게 끝나기 쉽습니다.

행사 정보를 짧고 읽기 쉽게 정리한다.

말은 자연스럽지만 판정에는 쓸 수 없습니다. 무엇이 빠지면 실패인지, 표현을 어디까지 바꿔도 되는지, 확인되지 않은 내용을 어떻게 다룰지가 보이지 않기 때문입니다.

실패 예시는 더 쓸모가 분명합니다.

입력에는 행사 대상과 제외 조건이 함께 있었지만, 출력에서 제외 조건이 빠졌다. 확인되지 않은 혜택도 확정된 사실처럼 덧붙였다.

여기에 사람의 수정 기준을 붙이면 절차가 됩니다.

• 원문에 없는 혜택은 삭제한다.
• 대상과 제외 조건은 함께 남긴다.
• 확인되지 않은 날짜나 재고 상태는 확정형으로 쓰지 않는다.
• 핵심 조건이 빠졌다면 문장을 다듬지 않고 반려한다.
• 사실은 맞지만 순서가 불편한 경우에만 사람이 편집한다.

이제 검토자는 ‘마음에 든다’가 아니라 ‘조건이 남았는가’로 판단할 수 있습니다. 저는 이 차이가 절차서와 사용 소감의 경계라고 봅니다.

무료 문서에 먼저 담을 것

처음부터 거대한 운영 문서를 만들 필요는 없습니다. 아래 틀은 그대로 복사해 빈칸을 채울 수 있는 최소 산출물입니다.

AI 작업 절차서

업무 이름
무엇을 반복해서 만드는가:

입력 예시
원문 또는 자료의 형태:
반드시 포함되는 정보:
입력에서 믿지 말아야 할 정보:

원하는 출력
사용 목적:
필수 항목:
허용하는 표현 변화:

실패 예시
잘못된 출력:
실패한 이유:
그대로 내보내면 생기는 문제:

사람의 수정 기준
즉시 반려할 조건:
수정 후 사용할 조건:
추가 확인이 필요한 조건:
사람만 결정할 항목:

최종 확인
다른 검토자가 같은 판단을 내릴 수 있는가:
판단이 갈렸다면 어느 문장을 고칠 것인가:

입력 예시는 출발점을 보여주고, 실패 예시는 멈춰야 할 지점을 보여줍니다.

다른 사람이 판별할 수 있어야 끝난다

절차서를 쓴 사람이 직접 검토하면 빈칸을 머릿속 지식으로 메우기 쉽습니다. 그래서 마지막 시험은 작성자가 아니라 다른 검토자를 기준으로 잡는 편이 안전합니다.

검토자에게는 입력, 결과, 절차서만 건넵니다. 별도 설명이 필요했다면 그 설명도 문서에 들어가야 합니다. 판단이 갈리면 어느 쪽이 맞는지부터 따지기보다, 기준 문장이 두 가지로 읽히는지 확인하게 됩니다.

복사해서 쓸 수 있는 판별 체크리스트는 다음과 같습니다.

• 입력에 반드시 있어야 할 항목이 적혀 있다.
• 원문에 없는 내용을 만들지 않는 기준이 있다.
• 실제로 틀렸다고 판정할 수 있는 실패 예시가 있다.
• 수정과 반려의 경계가 구분돼 있다.
• 사람이 직접 확인해야 하는 항목이 드러난다.
• 특정 담당자의 기억 없이도 결과를 검토할 수 있다.
• 판단이 엇갈릴 때 고칠 문서 위치를 찾을 수 있다.
• 최종 책임이 AI가 아니라 사람에게 남아 있다.

모든 사람이 같은 문장을 쓰게 만드는 것이 목적은 아닙니다. 같은 결함을 보고도 통과와 반려가 뒤집히지 않게 만드는 것이 목적입니다.

새 기능은 절차와 분리한다

새 스킬이나 실행 기능이 발표됐다는 사실만으로 기존 절차에 넣기는 어렵습니다. 공식 발표 날짜와 변경 내용을 먼저 확인하고, 현재 문서의 어느 업무에 적용되는지 구분해야 합니다.

제가 문서에 남기고 싶은 항목은 ‘새롭다’가 아니라 다음과 같은 적용 판단입니다.

• 공식 발표 날짜를 확인했는가.
• 변경된 기능이 입력, 생성, 검토, 실행 중 어디에 영향을 주는가.
• 기존 실패 예시가 여전히 실패로 잡히는가.
• 사람의 승인 전에 외부 실행이 일어나지 않는가.
• 적용하지 않을 업무도 명시돼 있는가.
• 확인할 수 없는 변경 사항은 보류로 남겼는가.

공식 변경 내용을 확인하지 못했다면 기능 소개를 절차에 섞지 않는 편이 낫습니다. 최신 기능을 따라가는 속도보다, 기존 판정 기준이 무너지지 않는지가 더 중요하기 때문입니다.

새 기능의 발표일은 적용 허가가 아니라 재검토를 시작하는 날짜에 가깝습니다.

실패와 한계도 문서의 일부다

이 방식도 모든 문제를 해결하지는 못합니다. 정답이 하나로 좁혀지지 않는 창작 업무에서는 검토자마다 판단이 달라질 수 있습니다. 입력 자료가 틀렸다면 출력 기준만 정교해도 사실 오류를 막기 어렵습니다. 법률, 건강, 재무처럼 결과의 위험이 큰 업무는 간단한 체크리스트만으로 맡길 범위가 아닙니다.

또한 실패 예시 하나가 모든 예외를 대표하지는 않습니다. 다만 첫 문서에서는 많은 성공 사례보다 치명적인 실패가 무엇인지 합의하는 출발점으로 충분히 쓸 수 있습니다. 판정이 반복해서 갈리는 지점은 다음 개정 때 실패 예시나 수정 기준으로 옮겨야 합니다.

최종 판단

처음 쓰는 AI 작업 절차서는 기능 목록보다 실패한 예 한 개에서 시작하는 편이 낫습니다. 그다음 입력 예시, 반려 조건, 사람의 수정 기준을 붙이면 무료 문서만으로도 업무의 경계를 확인할 수 있습니다.

유료 자료나 확장 기능은 이 첫 절차서가 실제 검토에 쓰이고, 다른 사람도 결과를 판별할 수 있다는 사실이 확인된 뒤에 두는 것이 순서에 맞습니다. 지금의 한 가지 행동은 위 체크리스트를 복사해 반복 업무 하나의 실패 예시부터 적는 것입니다.

이어지는 기록

• 처음 만드는 AI 콘텐츠 작업실, 새 기능보다 수정 요청 한 번을 먼저 시험하는 선택표
• 처음 만드는 AI 업무 절차서, 프롬프트보다 예외 상황을 먼저 적는 이유