업무 매뉴얼 만들기, AI가 먼저 물어보게 요청문을 이렇게 써 보세요

혼자 해 오던 일을 첫 팀원에게 넘기려고 매뉴얼을 쓰다 보면, 정작 처음 하는 사람이 막힐 곳은 빠지기 쉽죠. 매주 하던 사람에게는 너무 당연해서 적을 생각이 안 나거든요. 이 글은 업무 매뉴얼 만들기를 AI에 맡길 때, AI가 바로 쓰지 않고 먼저 물어보게 만드는 요청문을 다룹니다.

방법은 Claude Code 공식 문서 Best practices의 “Let Claude interview you” 절에서 가져왔어요. 원래는 개발자가 큰 기능을 만들기 전에 기능 명세(spec)를 쓸 때 쓰는 방법인데, 여기서는 그걸 업무 매뉴얼에 옮겨 썼습니다. 공식 문서가 매뉴얼용으로 권한 방법은 아니에요.

2026년 10월 18일, 지어낸 예시 업무 하나(“매주 금요일 고객사에 주간 리포트 보내기”)로 업무 매뉴얼 만들기를 실제 AI에게 맡기고 인터뷰를 받아 봤어요. AI가 한 질문과 마지막에 쓴 매뉴얼은 실제 출력이고, 대표의 답은 이 글에서 지어낸 예시입니다.

결론부터, 요청문 끝에 이 두 줄을 붙여 보세요

업무 매뉴얼 만들기를 맡길 때 일 이름만 적으면 AI는 곧바로 매뉴얼을 씁니다. 아래처럼 쓰기 전에 나를 인터뷰해 달라는 말과 질문 방식, 정리할 칸을 붙이면 AI가 먼저 묻기 시작해요. 시험에 보낸 요청문 원문 그대로예요.

매주 금요일 고객사에 주간 리포트를 보내는 일을, 처음 맡는 팀원에게 넘길 업무 매뉴얼로 만들 거야.
쓰기 전에 나를 인터뷰해 줘. 뻔한 건 묻지 말고, 처음 하는 사람이 막힐 곳을 파고들어. 한 번에 하나씩 물어.
다 물었으면 순서 / 자주 틀리는 곳 / 막히면 물을 사람 / 끝났는지 확인하는 법 네 칸으로 한 장에 정리해.

첫 줄의 일 이름과 받을 사람만 바꿔 쓰면 됩니다. 뒤 두 줄이 AI가 먼저 묻게 만들고, 다 물은 뒤 어떤 모양으로 정리할지 정하는 부분이에요.

세 숫자 모두 이번 업무 매뉴얼 만들기 시험 한 번의 결과예요. 같은 요청문을 다시 보내면 질문 수와 내용은 달라질 수 있습니다.

개발자가 쓰는 인터뷰 방법을 업무 매뉴얼 만들기에 가져왔어요

Claude Code 공식 문서는 큰 기능을 만들 때 “have Claude interview you first”, Claude가 먼저 인터뷰하게 하라고 적고 있어요. 예시 요청문에는 “Don’t ask obvious questions, dig into the hard parts I might not have considered.”라는 줄이 있습니다. 뻔한 질문은 하지 말고, 사용자가 미처 생각하지 못했을 어려운 부분을 파고들라는 뜻이에요.

원문이 다루는 것은 개발이에요. 인터뷰 주제로 기술 구현, UI/UX, 예외 상황(edge case), 트레이드오프(tradeoff)를 들고, 결과물은 SPEC.md라는 명세 파일입니다. 질문은 AskUserQuestion이라는 질문 도구로 받으라고 하고요. 업무 매뉴얼 만들기로 옮기면서 바꾼 곳은 아래와 같아요.

네 번째 칸 “끝났는지 확인하는 법”도 같은 절에서 따왔어요. 문서는 가장 쓸모 있는 명세가 “end with an end-to-end verification step that proves the feature works”, 기능이 돌아가는지 처음부터 끝까지 확인하는 단계로 끝난다고 적습니다. 매뉴얼에서는 이 단계를 받은 사람이 스스로 끝났는지 점검하는 칸으로 바꿔 두었어요. 이 대응은 이 글에서 붙인 것이에요.

“매뉴얼 써 줘” 한 줄만 보내면 이렇게 나와요

비교하려고 업무 매뉴얼 만들기를 한 줄로도 시켜 봤어요. 새 대화에서 “매주 금요일 고객사에 주간 리포트를 보내는 일, 매뉴얼 써 줘.” 한 줄만 보냈더니 AI는 묻지 않고 바로 매뉴얼을 썼습니다. 개요부터 파일 관리까지 8개 절이었고, 첫머리에 “고객사나 리포트 내용은 아직 모르기 때문에 일반적인 기준으로 썼고, 회사마다 다른 부분은 [ ]로 비워 두었습니다.”라고 밝혔어요.

틀은 잘 잡혀 있고, 이 팀만의 사정이 들어갈 자리는 [ ]로 비워 두었어요. 요청문에 기준을 주지 않았으니 집계 기간도 “예: 월 00:00 ~ 금 12:00″라는 예시로 채웠는데, 예시 업무에서 정한 기준(지난주 월요일부터 일요일까지)과는 달라요. AI는 끝에 고객사 이름, 지표, 쓰는 업무 툴을 알려 주면 빈칸을 채워 주겠다고 했어요. 물어볼 것은 매뉴얼을 다 쓴 다음에 한 번에 나온 거죠.

같은 업무로 인터뷰 요청문을 보내자 첫 답에는 매뉴얼이 없었습니다. “순서는 당연히 알고 있을 거라 보고, 처음 하는 사람이 혼자 판단해야 하는 지점부터 물을게요.”라며 질문 하나만 내놓았어요. 리포트가 틀리거나 늦게 나간 적이 있었는지 묻고, 그런 일이 없었다면 “매주 하면서 제일 신경 쓰이는 단계가 어디인지”를 알려 줘도 된다고 괄호로 덧붙였고요.

AI가 먼저 물어본 12가지, 이런 걸 짚었어요

AI는 업무 매뉴얼 만들기에 들어가기 전에 12번에 나눠 물었어요. 대표 역할로 두세 문장씩 답하면, 그 답에서 다음에 막힐 곳을 골라 다시 물었습니다. 집계 기간 얘기를 꺼내자 “그 도구를 열었을 때 기본으로 잡혀 있는 기간”을 물었고, 관리자 화면이 나오자 로그인에서 막힐 만한 게 있는지 물었어요.

가장 쓸모 있었던 건 여섯 번째 질문이에요. 지난주 탭을 복사해 새 탭을 만든다고 답하자, AI는 수식이 탭 이름을 직접 가리키면 “숫자는 맞게 붙였는데 증감률만 틀리는 상황이 생겨요”라며 어느 탭을 참조하는지 물었습니다. 예시 답은 “그건 미처 생각 못 했네.”로 보냈어요. AI도 마지막 정리에서 이 단계가 “인터뷰하면서 처음 드러났어요”라고 짚었습니다.

질문 모양도 답하기 쉬웠어요. 여러 질문이 “예를 들면 이런 것들이요”라며 고를 수 있는 예를 두세 개 붙였거든요. 로그인을 물을 때는 2단계 인증 문자가 누구 휴대폰으로 가는지, IP 제한이 있는지, 비밀번호를 주기적으로 바꾸는지를 예로 들었고, 답하는 쪽은 맞는 것을 고르고 한 줄 보태면 됐습니다.

인터뷰가 끝나면 이런 한 장 업무 매뉴얼이 나와요

열두 번째 질문에는 AI가 스스로 “마지막 질문”이라고 붙였어요. 그 답을 보내자, 정리해 달라고 다시 말하지 않았는데도 네 칸 매뉴얼이 나왔습니다. 칸 이름과 순서는 업무 매뉴얼 만들기 요청문에 적은 그대로였어요.

순서 칸에는 인터뷰에서 나온 답이 단계마다 들어갔어요. 맨 위에 “미리 할 일(수요일까지)”로 팀장 외근 여부를 확인하라는 줄이 붙었고, 10단계 중 5번이 여섯 번째 질문에서 나온 “수식 고치기”였습니다. 자주 틀리는 곳 표는 8줄이었어요. 절반은 대표가 답하며 꺼낸 내용이고, 나머지 절반은 수식의 탭 참조, 주차 세는 기준, 비슷한 숫자, PDF 범위처럼 AI가 질문으로 먼저 꺼낸 것이었습니다. 둘 다 “틀리기 쉬운 것 / 맞게 하는 법” 두 칸으로 다시 썼고요.

눈여겨볼 곳은 AI가 채우지 않고 남긴 자리예요. 막히면 물을 사람 칸에는 “⚠️ 아직 정해진 대신 연락할 사람이 없습니다.”라고 적었고, 매뉴얼 아래에 넘기기 전에 정해 둘 것 두 가지를 따로 붙였습니다. 대신 연락할 사람을 정하라는 것, 수식이 탭 이름 없이도 맞게 돌도록 바꾸면 손으로 고치는 단계를 없앨 수 있다는 것이었어요. 확인 칸 8줄 가운데 PDF 범위, 날짜 범위, 오류 표시를 보는 항목은 인터뷰 내용을 바탕으로 덧붙였다고 AI가 스스로 밝혔고요.

업무 매뉴얼 만들기 요청문, 보내기 전과 받은 뒤에 볼 것

업무 매뉴얼 만들기를 처음 AI에 맡겨 볼 때 쓸 순서예요. 시험에서 본 것을 바탕으로 정리했어요. 공식 문서에 적힌 절차는 아니고, 이 글에서 권하는 방법입니다.

공식 문서는 명세가 끝나면 새 세션을 열어 그 명세를 들고 구현하라고 해요. 매뉴얼로 치면 5번처럼 받은 사람이 매뉴얼만 들고 처음부터 해 보는 단계에 가깝습니다.

AI 업무 설계 묶음의 첫 글은 일을 단계와 요청문으로 쪼개는 법을, AI 요청문 작성법은 금지 칸과 결과 형식 칸을 다뤄요. 만든 매뉴얼을 AI가 매번 꺼내 쓰는 절차로 묶는 방법은 에이전트 스킬 글에 있습니다.

업종과 업무에 맞춘 AX 설계 상담은 무료 AX 상담 신청에서 받습니다.

글에 나온 역할별 AI 작업 창은 Claude Code로 띄운 것이고, 공식 안내는 Claude Code 공식 문서에 있습니다.

이 글은 직접 만들고 운영하며 남긴 기록입니다. 적힌 수치는 작성 시점의 운영 계정 기준이며, 같은 결과나 수익을 보장하지 않습니다.