엔지니어만을 위해 작성된 범위 문서는 내용을 이해하지 못한 구매자의 서명을 받게 된다. 그 서명이 이후 모든 변경 요청 분쟁의 원인이 된다.
해결책은 더 긴 문서가 아니다. 의도적인 구조를 가진 문서다 — 엔지니어에게는 필요한 정밀함을, 구매자에게는 승인하고 기준을 지킬 수 있는 명확함을 제공하는 구조.
두 독자, 하나의 문서
모든 AI 프로젝트 범위 문서에는 서로 다른 성공 조건을 가진 두 독자가 있다.
엔지니어링 팀은 무엇을 만드는지, 무엇을 만들지 않는지, 완료가 측정 가능한 기준으로 어떤 모습인지 정확히 알아야 한다. 여기서의 모호함은 재작업을 낳는다.
구매자는 무엇에 비용을 지불하는지, 범위 밖에 무엇이 있는지, 예상치 못한 상황이 발생하면 어떻게 되는지 알아야 한다. 여기서의 모호함은 분쟁을 낳는다.
대부분의 범위 문서는 한쪽 독자에게만 잘 맞고 다른 쪽은 무시한다. 엔지니어는 시스템 용어로 작성한다 — 엔드포인트, 레이턴시 예산, 모델 버전. 구매자는 결과 용어로 읽는다 — 생성된 리드, 절약된 시간, 액션당 비용. 어느 쪽 표현도 틀리지 않았다. 둘 다 같은 문서 안에 존재해야 한다.
아래 구조는 그 번역을 강제한다.
범위 문서에 필요한 네 가지 섹션
1. 경계
시스템이 무엇을 하는지 정확히 기술한다. 한 단락. 평이한 언어로.
예시: 이 시스템은 주당 최대 5,000개의 기업 레코드를 수집하고, 두 개의 소스에서 각 레코드에 기업 데이터를 보강하며, 정의된 ICP 기준으로 각 레코드를 점수화하고, 매주 월요일 오전 6시까지 지정된 S3 버킷에 순위가 매겨진 출력 파일을 전달한다.
이 문장은 엔지니어와 구매자 모두에게 유효하다. 엔지니어는 데이터 볼륨, 소스, 출력 형식, 전달 시간을 확인한다. 구매자는 무엇을 언제 받는지 확인한다.
경계를 한 단락으로 작성할 수 없다면, 범위가 아직 정의되지 않은 것이다.
2. 제외 항목
이 섹션은 가장 많이 생략되고, 생략했을 때 가장 비용이 많이 드는 항목이다.
제외 항목은 시스템이 하지 않는 것을 명시한다. 나중에 할 수도 있는 것이 아니다. 예산 밖의 것도 아니다. 이 계약에서 명시적으로 제외된 것이다.
위 시스템의 제외 항목 예시:
- CRM 쓰기 동기화는 포함되지 않는다. 출력은 파일로만 전달된다.
- 시스템은 입력 레코드를 검증하거나 정제하지 않는다. 잘못된 형식의 레코드는 건너뛰고 로그에 기록된다.
- 실시간 보강은 범위에 포함되지 않는다. 처리는 주간 배치 스케줄로 실행된다.
- 점수화된 레코드의 사람에 의한 검토는 포함되지 않는다.
이 섹션이 없으면, 구매자는 경계에 인접한 모든 것이 포함된다고 가정한다. 엔지니어는 구매자가 그것이 포함되지 않는다는 것을 안다고 가정한다. 그 간극은 실제 비용을 발생시킨다 — 보통 프로젝트 중간에 양측 모두 옳고 양측 모두 불만인 대화의 형태로.
첫 번째 스프린트가 시작되기 전에 제외 항목 목록을 작성하라. 구매자와 명시적으로 검토하라. 서면으로 확인을 받아라.
3. 측정 가능한 단위의 성공 기준
성공 기준은 형용사가 아닌 숫자여야 한다.
나쁜 예: 시스템은 잘 작동하고 정확한 결과를 제공해야 한다.
좋은 예:
- 유효한 입력 레코드에 대한 보강 매칭률 ≥ 85%
- 주간 배치가 예약된 실행의 ≥ 95%에서 오전 6시 이내에 완료되고 출력 파일을 전달
- 레코드당 점수화 레이턴시 99번째 백분위수에서 ≤ 200ms
- 200개 레코드 홀드아웃 세트 기준으로 측정된 ICP 점수화의 위양성률 ≤ 12%
이 숫자들은 두 가지 역할을 한다. 엔지니어에게는 구축 목표를 제공한다. 구매자에게는 코드를 읽지 않고도 검증할 수 있는 완료 정의를 제공한다.
구매자가 엔지니어링 도움 없이 성공 기준을 평가할 수 없다면, 그 기준은 아직 구매자가 읽을 수 있는 수준이 아니다.
4. 에스컬레이션 경로
범위 문서는 거의 항상 이 항목을 생략한다. 가장 비용이 많이 드는 대화를 예방하는 섹션이다.
에스컬레이션 경로는 다음 질문에 답한다: 프로젝트 진행 중 경계 밖의 무언가가 나타나면 어떻게 되는가?
다음을 명시해야 한다:
- 범위 외 항목을 누가 식별하는가 (엔지니어, PM, 또는 구매자)
- 어떻게 문서화되는가 (Slack 메시지가 아닌 서면 변경 요청)
- 누가 범위 변경을 승인하며 어떤 시간 내에
- 변경이 일정, 비용, 또는 둘 다에 영향을 미치는지, 그리고 그것이 어떻게 전달되는지
한 단락의 에스컬레이션 경로는 엔지니어가 도움이 될 것 같아서 범위에 인접한 무언가를 구축하고, 구매자가 그것을 보고 유지 관리될 것으로 기대하며, 다음 계약이 무엇이 약속되었는지에 대한 불일치로 시작되는 상황을 예방한다.
제외 항목 생략의 실제 비용
현실적인 예시: 팀이 리드 보강 파이프라인의 범위를 정의한다. 제외 항목 섹션이 비어 있다. 구매자는 CRM 동기화가 포함된다고 가정한다 — 데모 환경에 있었기 때문이다. 엔지니어는 그것이 논의된 적이 없다고 가정한다. 3주 후, 구매자가 CRM 동기화가 언제 시작되는지 묻는다. 엔지니어는 범위에 없었다고 말한다. 구매자가 계약서를 꺼낸다. 계약서에는 아무 내용이 없다.
해결 옵션: 무료로 구축하거나, 비용을 청구하고 관계를 손상시키거나, 부분적으로 협상한다. 세 가지 옵션 모두 1주차에 제외 항목 섹션을 작성하는 것보다 더 많은 비용이 든다.
재작업 비용은 단순히 엔지니어링 시간이 아니다. 신뢰 비용, 지연 비용, 그리고 병렬로 진행 중인 다른 모든 프로젝트에 대한 집중력 분산 비용이다.
AI 시스템에 특별히 적용하기
AI 시스템에는 특정한 범위 실패 패턴이 있다: 구매자는 시스템이 훈련되거나 설계된 적 없는 엣지 케이스를 처리할 것이라고 가정한다. 경계와 제외 항목을 정밀하게 정의하는 문서는 그 가정의 간극이 지원 티켓이 되기 전에 줄여준다.
DK1.AI에서는 모든 계약을 구조화하는 방식에 범위 명확성이 내재되어 있다. AI Brand Presence가 한 가지 예다 — 경계, 제외 항목, 성공 기준이 프로덕션 작업이 시작되기 전에 정의되므로, 양측 모두 무엇이 구축되고 무엇이 구축되지 않는지 정확히 안다.
그 원칙은 우리가 운영하는 모든 시스템에 적용된다.