가장 비용이 많이 드는 AI 프로젝트는 나쁜 엔지니어링 때문이 아니라 첫날 내려지지 않은 범위 결정 때문에 실패한다.
모델이 없어서가 아니다. 데이터셋이 없어서도 아니다. 경계가 없어서다.
팀이 개발을 시작하면 범위는 기본적으로 확장된다. 모든 이해관계자가 유스케이스를 추가한다. 모든 데모에서 새로운 엣지 케이스가 드러난다. 6주 후, 시스템은 한 가지를 안정적으로 하는 대신 열두 가지를 엉성하게 한다. 이 결과는 예측 가능하며 — 예방도 가능하다.
먼저 정확한 워크플로 경계를 정의하라
AI 시스템의 범위 문서에는 두 가지 측면이 있다: 시스템이 다루는 것, 그리고 명시적으로 다루지 않는 것.
두 측면 모두 똑같이 중요하다. 대부분의 팀은 첫 번째 측면만 작성한다. 두 번째를 작성하는 팀은 거의 없다.
유용한 경계 정의는 다음과 같은 형태를 띤다:
- 범위 내: 시스템은 인바운드 리드 레코드를 읽고, 정의된 ICP에 따라 점수를 매기며, 구조화된 요약을 공유 큐에 작성한다.
- 범위 외: 시스템은 이메일을 발송하거나, CRM 필드를 업데이트하거나, 라우팅 결정을 내리지 않는다.
두 번째 목록은 제한이 아니다. 설계 결정이다. 모든 엔지니어, 모든 검토자, 그리고 모든 미래의 이해관계자에게 시스템이 어디서 멈추는지를 — 출시 전날 밤 11시에 누군가 논쟁을 벌이기 전에 — 정확히 알려준다.
DK1.AI에서는 모든 제품이 이런 명시적 경계에서 시작된다. AI Brand Presence가 명확한 예다: 이 제품은 AI 기반 검색 및 디스커버리 서피스 전반에서 기업이 어떻게 노출되는지를 다룬다. 유료 미디어, 소셜 스케줄링, 또는 전통적인 의미의 SEO는 관리하지 않는다. 그 경계는 첫 번째 인보이스 이후에 발견되는 것이 아니라 처음부터 명시된다.
킥오프 전에 거부 목록을 작성하라
거부 목록은 첫 번째 스프린트 전에 제외하기로 결정한 모든 기능이다.
직관에 반하는 것처럼 들린다. 아무것도 만들기 전에 만들지 않을 것을 정의하는 것이다. 하지만 거부 목록의 모든 항목은 3개월 차에 하지 않아도 될 재작업 1주일이다.
아웃바운드 AI 시스템의 실용적인 거부 목록은 다음을 포함할 수 있다:
- 활성 통화 중 실시간 데이터 보강 없음
- 파일럿 단계에서 프로덕션 CRM에 대한 직접 쓰기 접근 없음
- 영어 워크플로가 안정화될 때까지 다국어 지원 없음
- 자동 발송 없음 — 모든 아웃바운드는 운영자 승인 필요
각 거부 항목은 하나의 실패 모드를 제거한다. 통화 중 실시간 데이터 보강은 핵심 작업과 무관한 레이턴시와 오류 처리 복잡성을 유발한다. 파일럿 중 CRM 직접 쓰기는 AI의 버그가 데이터 정리 프로젝트를 만든다. 기본 워크플로가 안정화되기 전의 다국어 지원은 두 가지 문제를 동시에 디버깅하는 것을 의미한다.
거부 목록은 영구적이지 않다. 시작 위치다. 하지만 팀이 범위가 수동적으로 누적되도록 내버려두는 대신 범위를 추가하는 명시적 결정을 내리도록 강제한다.
거부 목록 세션 진행 방법
킥오프 전에 시스템을 구축할 사람들과 사용할 사람들을 모아라. 모든 사람에게 10분을 주어 포함된다고 가정하는 기능을 적게 하라. 목록을 수집하라. 그런 다음 항목별로 검토하며 묻는다: 시스템이 핵심 가치를 제공하기 위해 이것이 v1에 있어야 하는가?
그 질문을 통과하지 못하는 것은 거부 목록에 올린다. 이유를 문서화하라. 그 문서화가 중요하다 — 4주 차에 이해관계자가 해당 기능을 요청할 때, 거절된 것이 아니라 연기된 이유에 대한 서면 기록이 있다.
살아있는 계약으로서의 범위
요구사항은 변한다. 이것은 계획의 실패가 아니라 — 정상이다. 문제는 범위 변경이 의도적으로 이루어지는지 아니면 표류에 의해 이루어지는지다.
표류는 이렇게 생긴다: 이해관계자가 작은 추가 사항 하나를 요청한다. 팀은 사소해 보이기 때문에 수락한다. 세 번의 작은 추가 후, 시스템은 범위가 정해진 것과 실질적으로 다른 일을 하고 있으며, 원래의 성능 벤치마크는 더 이상 적용되지 않는다.
살아있는 범위 계약은 시스템을 경직되게 만들지 않으면서 표류를 방지한다. 작동 방식은 다음과 같다:
- 제안된 범위 변경은 공식 수정안으로 문서화된다 — 추가되는 것과 대체하거나 연기하는 것을 설명하는 한 문장.
- 팀은 원래 경계 정의에 대해 수정안을 검토한다. 이것이 시스템의 핵심 작업을 변경하는가? 새로운 실패 모드를 도입하는가?
- 수정안이 수락되면 거부 목록이 업데이트된다. 이전에 거부된 기능이 이제 범위에 포함된다면, 원래 거부 이유를 명시적으로 재검토한다.
이것은 관료주의가 아니다. 2인 팀의 경우 전체 프로세스는 20분이 걸린다. 이것이 방지하는 것은 시스템을 취약하고 디버깅하기 느리게 만드는 복잡성의 조용한 누적이다.
DK1.AI에서 범위 검토는 정해진 체크포인트에서 이루어진다 — 지속적으로도 아니고, 전혀 하지 않는 것도 아니다. 목표는 작업하기에 영원히 흥미로운 시스템이 아니라 프로덕션에서 조용히 실행되는 시스템이다.
실질적인 결과
잘 범위가 정해진 시스템은 더 빠르게 구축되고, 테스트하기 쉬우며, 유지 관리 비용이 적다. 경계 문서는 인수 기준이 된다. 거부 목록은 범위 크리프에 대한 회귀 테스트가 된다. 수정 프로세스는 변경 로그가 된다.
이 중 어느 것도 대규모 팀이나 공식적인 프로세스 프레임워크를 필요로 하지 않는다. 첫 번째 스프린트가 시작되기 전에 한 시간의 집중된 대화가 필요할 뿐이다.
지루한 것이 이긴다. 18개월 동안 한 가지를 안정적으로 하는 시스템은 6주 동안 여덟 가지를 인상적으로 하는 시스템보다 가치 있다.