AI 에이전트 범위 문서 작성법

2026년 8월 게시.

TL;DR: 범위 문서는 “우리 비즈니스에 AI 에이전트가 필요해요”라는 말을 견적 낼 수 있는 숫자와 클라이언트가 서명할 수 있는 문서로 바꿔주는 것입니다. 여기에는 트리거, 입력, 출력, 다루는 도구, 명시적으로 제외되는 것, 그리고 서면 인수 테스트 목록까지 여섯 부분이 필요합니다. 구축비를 견적 내기 전에 작성해야지, 그 후가 아닙니다. 저는 이를 구축과 별도로 고정 500~1,000달러의 감사(audit) 결과물로 가격을 책정합니다.

[운영자의 시각] 저는 컨설팅 브랜드와 텍사스주 프플러그빌에 있는 피클볼 시설 Pickleland에서 30개 이상의 프로덕션 에이전트를 운영하고 있고, 그 경험을 바탕으로 클라이언트를 위한 에이전트 구축 작업의 범위를 잡아왔습니다. 에이전트 작업이 틀어지는 가장 흔한 원인은 코드가 아닙니다 — 청구서가 나가기 전에 아무도 “완료”가 무슨 뜻인지 적어두지 않았다는 것입니다. 범위 문서는 이 문제를 한 번의 미팅으로 해결합니다. 제가 만드는 결과물 중 가장 화려하지 않지만, 가장 많은 다툼을 막아주는 것이기도 합니다.

목차

왜 제안서 이메일이 아니라 범위 문서인가

제안서 이메일은 당신이 무엇을 할지를 설명합니다. 범위 문서는 “완료”가 무엇을 의미하는지를 정의합니다 — 충분히 구체적이어서, 당신과 클라이언트 둘 다 완성된 에이전트를 놓고 대화 없이도 통과했는지 아닌지에 동의할 수 있을 정도로요.

이 구분이 중요한 이유는 AI 에이전트 가격 책정이 구축비가 고정된 무언가에 붙어 있을 때만 통하기 때문입니다. 정의되지 않은 범위에 고정 가격을 매기면, 실제로는 이행할 수 없는 숫자를 견적 낸 셈이 됩니다 — “우리 비즈니스를 위한 AI 에이전트”라는 클라이언트의 머릿속 그림은 당신이 선을 긋기 전까지 공짜로 계속 커집니다. 그리고 계약금을 받은 후에 선을 긋는 대화는, 그 전에 경계를 정의해두는 것보다 훨씬 껄끄러운 대화가 됩니다.

저는 작은 작업을 포함해 모든 구축마다 이 문서를 작성합니다. 단일 워크플로우 에이전트는 반 페이지짜리 버전을 받습니다. 멀티 에이전트 시스템은 전체 문서를 받습니다. 형식은 바뀌지 않습니다 — 길이만 달라질 뿐입니다.

범위 문서에 필요한 여섯 가지

1. 트리거. 무엇이 에이전트를 작동시키는가 — 양식 제출, 예약된 시간, 수신 이메일, 다른 도구에서 오는 웹훅. 트리거의 범주가 아니라 정확한 트리거를 명시하세요. “리드 양식이 제출되면 실행됨”은 범위입니다. “수신 리드를 처리함”은 범위가 아닙니다.

2. 입력. 에이전트가 받는 데이터가 무엇이고 어디서 오는가. 출처만이 아니라 필드를 나열하세요 — “이름, 이메일, 회사 규모, Typeform 제출의 자유 텍스트 메시지 필드”이지, “양식 데이터”가 아닙니다.

3. 출력. 에이전트가 무엇을 만들어내고 어디로 가는가. 같은 규칙: 목적지와 형식을 명시하세요. “사람의 승인을 위해 #leads 슬랙 채널에 초안 답변을 게시함”은 범위입니다. “리드에 응답함”은 범위가 아닙니다.

4. 다루는 도구와 통합. 에이전트가 호출하는 모든 API, 데이터베이스, 플랫폼. 여기는 또한 명시적으로 통합하지 않는 것을 적어두는 곳이기도 합니다 — 발견 미팅에서 한 번 언급했다는 이유로 자신의 CRM이 포함됐다고 가정하는 클라이언트가, 제가 본 범위 확대(scope creep)의 가장 흔한 원인입니다.

5. 제외되는 것. 인접해 보이더라도 에이전트가 하지 않을 것들을 짧고 명시적으로 나열한 목록. 리드 분류 에이전트를 만드는 중이라면, 당연해 보이더라도 “아웃바운드 메시지를 보내지 않음”이라고 적으세요 — 당신에게 당연한 것이 소프트웨어 범위를 한 번도 잡아본 적 없는 클라이언트에게는 당연하지 않습니다.

6. 인수 테스트 목록. 최종 결제 전에 완성된 에이전트가 통과해야 하는 실제 사례 목록. “잘 작동한다”가 아니라 구체적이고 확인 가능한 사례여야 합니다: “제공된 데이터셋의 샘플 리드 10건 중 9건을 정확히 분류함”, “수동 개입 없이 연결된 슬랙 채널에 성공적으로 게시함”, “형식이 잘못된 제출(이메일 필드 누락)을 크래시 없이 처리함”. 이 섹션이 문서에서 가장 중요합니다. 나중에 무엇을 의도했는지 다시 논쟁하지 않고도 양측이 가리킬 수 있는 유일한 부분이기 때문입니다.

템플릿

이것이 제가 실제로 사용하는 구조입니다. 복사해서 여섯 섹션을 채우면, 가격을 매길 수 있는 문서가 완성됩니다.

AGENT SCOPE DOCUMENT — [Client name] / [Project name]
Date: [date]

1. TRIGGER
   [What starts this agent running]

2. INPUTS
   [Exact data fields and their source]

3. OUTPUTS
   [What the agent produces, in what format, sent where]

4. TOOLS & INTEGRATIONS
   Included: [every API/platform/database touched]
   Explicitly excluded: [anything adjacent that is NOT built]

5. EXCLUSIONS
   [What this agent will not do, even if related]

6. ACCEPTANCE TESTS
   [ ] [Specific, checkable test case]
   [ ] [Specific, checkable test case]
   [ ] [Specific, checkable test case]
   ...

BUILD FEE: $[amount], due [payment terms]
MAINTENANCE RETAINER: $[amount]/month, starting [date]
CHANGE REQUESTS: priced separately, quoted before work starts

Signed: _______________  Date: _______

구축비와 리테이너 항목이 존재하는 이유는 가격이 바로 위의 범위에 직접 고정되도록 하기 위해서입니다 — 아직 구축 가격을 매겨본 적이 없다면 두 숫자를 어떻게 산정하는지 참고하세요. 이 문서에 서명하는 클라이언트는 같은 동작으로 범위와 가격 둘 다에 서명하는 것이며, 그것이 핵심입니다.

이 문서를 만들어내는 통화를 진행하는 방법

저는 범위 산정 세션 자체를 구축비와 별도로 고정 500~1,000달러 감사로 가격을 책정합니다 — 클라이언트가 진행하기로 하더라도 절대 구축비에 포함시키지 않습니다. 이유는 두 가지입니다. 범위 산정 단계가 무급 영업 활동이 되는 것을 막고, 클라이언트가 이 통화를 무료 상담처럼 취급하지 않고 진지하게 받아들이게 만듭니다.

통화 자체는 30~45분이며, 위의 여섯 섹션 순서대로 구조화됩니다. 저는 대화가 “AI 에이전트가 이론적으로 당신의 비즈니스를 위해 무엇을 할 수 있는가”로 흘러가게 두지 않습니다 — 그건 다르고 더 비싼 대화이며, 아무도 가격을 매길 수 없는 문서를 만들어내는 대화입니다. 저는 트리거를 가장 먼저 묻는데, 프로세스를 시작하는 것이 무엇인지 말하지 못하는 클라이언트는 대개 아직 자동화할 만큼 안정적인 워크플로우를 갖고 있지 않기 때문입니다 — 이는 둘 중 누구도 구축을 약속하기 전에 드러내는 것이 좋습니다.

빈 페이지가 아니라 프롬프트로 시작하기

저는 이 문서의 첫 초안을 손으로 쓰지 않습니다. 통화 노트 — 종종 지저분한 불릿 포인트 문단일 뿐인 것 — 를 가져와서 Claude에 다음을 붙여넣습니다.

Here are my raw notes from a scoping call for an AI agent build. Turn them
into a scope document with exactly these six sections: Trigger, Inputs,
Outputs, Tools & Integrations, Exclusions, Acceptance Tests. For each
section, flag anything the notes don't specify clearly enough to build
against, rather than guessing or filling the gap yourself. The acceptance
tests need to be specific and checkable — reject vague criteria like
"works correctly" and either sharpen them into a concrete test case or
flag them for me to clarify with the client.

[paste raw notes]

마지막 지시사항 — 빈틈을 채우지 말고 표시하라 — 이 중요한 부분입니다. 모델은 문서를 완성하기 위해 그럴듯해 보이는 인수 테스트를 기꺼이 지어냅니다. 그리고 클라이언트가 실제로 의도한 것과 맞지 않는, 그럴듯해 보이는 테스트는 물어봐야 하는 빈칸보다 더 나쁩니다.

아직도 보이는 흔한 실수들

제외 섹션을 마지막에 쓰거나 아예 건너뛰기. 제외 섹션은 대부분의 사람들이 선택 사항으로 취급하는 부분입니다. 하지만 가장 많은 분쟁을 막아주는 부분이기도 합니다. 인수 테스트보다 먼저 쓰세요, 나중이 아니라.

결과가 아니라 행동을 묘사하는 인수 테스트. “에이전트가 클라이언트의 톤을 이해해야 한다”는 행동입니다. “에이전트의 초안 답변이 샘플 사례 10건 중 7건에서 수정 없이 승인된다”는 결과입니다. 결과만이 확인 가능합니다.

서면 노트 없이 한 번의 대화만으로 범위를 잡기. 범위 문서가 그 작업의 첫 서면 결과물이라면, 며칠 후에 기억을 더듬어 통화를 재구성하고 있는 것입니다. 통화 중에 여섯 섹션 순서대로 노트를 작성하면, 문서는 거의 저절로 완성됩니다.

클라이언트가 범위를 쓰게 두기. 클라이언트가 자신의 언어로 원하는 것을 설명하는 것은 문서에 대한 입력이지, 문서 자체가 아닙니다. 클라이언트의 언어는 대개 기능 형태이지(“우리 리드를 처리해줬으면 해요”) 테스트 형태가 아닙니다. 그것을 확인 가능한 인수 기준으로 번역하는 것이 범위 산정 세션의 실제 가치입니다 — 그래서 이것이 클라이언트가 직접 채우는 양식이 아니라 유료 결과물인 것입니다.

이 작업에 쓰는 도구들

**Claude**는 위의 프롬프트를 사용해 통화 원본 노트로부터 문서 초안을 작성하고, 추측하는 대신 빈틈을 표시해줍니다.

**Notion**은 완성된 범위 문서가 보관되는 곳입니다. 계약금을 받기 전에 클라이언트와 공유되며, 작업 전체의 서류 기록을 보관하는 곳과 동일합니다.

**Airtable**은 어떤 작업이 범위 산정 중인지, 서명 완료인지, 구축 중인지를 클라이언트별로 한 행씩 추적해서, 범위 문서가 몇 주 동안 아무도 모르게 서명되지 않은 채로 방치되는 일이 없도록 합니다.

FAQ

범위 문서는 얼마나 길어야 하나요?

모든 인수 테스트를 확인 가능하게 만드는 데 필요한 만큼이면 되고, 그 이상은 필요 없습니다. 단일 워크플로우 에이전트는 반 페이지일 수 있습니다. 여러 통합이 있는 멀티 에이전트 시스템은 두세 페이지가 될 수 있습니다. 길이가 목표가 아닙니다 — 클라이언트와 개발자가 각자 인수 테스트를 읽고 통과 여부에 독립적으로 동의할 수 있는 것이 목표입니다.

서명 후 클라이언트가 범위를 바꾸고 싶어 하면 어떻게 하나요?

그것은 변경 요청이며, 작업이 시작되기 전에 별도로 가격을 매겨 견적을 냅니다 — 위 템플릿처럼 이 조건을 문서 자체에 적어두세요. 서명 후에 조용히 확장될 수 있는 범위 문서는 사실상 범위 문서가 아닙니다.

아주 작은 자동화에도 범위 문서가 필요한가요?

네, 짧게라도 필요합니다. 가치는 길이에 있지 않습니다 — 구축을 시작하기 전에 서면 인수 테스트 목록을 갖고 있는 것에 있습니다. 그래야 “완료”가 느낌이 아니라 체크리스트가 됩니다. 바로 이 이유로, 범위를 비공식적으로 잡은 작은 작업이 제대로 범위를 잡은 큰 작업보다 더 오래 걸린 경우도 있었습니다.

범위 문서 자체의 소유권은 누구에게 있나요 — 결과물의 일부인가요?

저는 클라이언트가 구축으로 진행하든 안 하든, 그것을 만들어낸 감사 비용을 지불했기 때문에 그들이 계속 소유하는 것으로 취급합니다. 제가 보유하는 것은 기본 템플릿과 프롬프트입니다. 작업 전반에 걸쳐 재사용 가능한 뼈대를 보유하는 것과 같은 방식입니다 — 문서의 구조는 제 것이고, 그들의 구체적인 비즈니스에 대한 채워진 내용은 그들의 것입니다.

다음 단계: 제 AI 에이전트 입문 강좌는 이런 범위 문서가 설명하는 에이전트를 구축하는 방법을 다룹니다. 코워크 프로그램은 이런 종류의 범위 산정과 구축을 연습할 구조화된 환경을 원하는 운영자를 위한 것입니다. 범위 문서를 직접 작성해드리길 원한다면 30분 세션을 예약하세요.