AI 프로젝트의 범위 확장 (Scope Creep): PM이 중심을 잡는 방법

범위 확장 (Scope creep)은 합의된 범위를 넘어 프로젝트의 작업이 서서히 늘어나는 것을 의미합니다. AI 구축 작업에서는 "이것도 그냥 처리할 수 있지 않을까요?"라는 질문이 아주 사소하게 들리지만 실제로는 결코 사소하지 않기 때문에 이를 포착하기가 더 어렵습니다. 중심을 잡는 방법은 단순히 '안 된다'고 말하는 것이 아니라, 각 추가 사항이 요청되는 순간 그 비용을 가시화하여 클라이언트가 상황을 명확히 인지한 상태에서 선택하도록 만드는 것입니다.

범위 확장은 전체 프로젝트의 절반 이상에서 발생합니다. AI 작업에서는 그 비율이 더 높을 것이라고 생각하는데, 그 이유는 이러한 시스템이 작동하는 방식과 밀접한 관련이 있습니다. 왜 그런지, 그리고 제가 실제로 어떻게 대처하는지 설명하겠습니다.

AI가 범위 확장을 유도하는 이유

전통적인 기능은 경계가 명확합니다. "보고서를 추가해 주세요"라는 요청은 이미 범위를 정한 대시보드보다 명백히 더 많은 작업임을 알 수 있습니다. 하지만 AI는 그 경계를 모호하게 만듭니다. 에이전트 (Agent)가 이미 유창하고 그럴듯한 결과물을 생성하고 있기 때문에, 모든 새로운 요청이 새로운 범위라기보다는 작은 조정처럼 느껴집니다. "이미 결제 관련 질문에 답하고 있으니, 환불도 처리할 수 있을까요?"라는 요청이 있다고 가정해 봅시다. 환불 처리는 새로운 액션 (Action), 새로운 권한 (Permissions), 새로운 실패 모드 (Failure modes), 그리고 완전히 새로운 평가 케이스 (Eval cases) 세트를 의미합니다. 하지만 겉모습은 동일해 보이기 때문에 그렇게 느껴지지 않습니다.

두 번째 함정이 있습니다. AI는 확률적 (Probabilistic)이기 때문에, "정확도를 조금 더 높여주세요"라는 요청은 끝이 없는 요청이 될 수 있습니다. 작업 완료율을 80%에서 90%로 올리는 작업은 오후 한때에 끝날 수도 있고, 한 달이 걸릴 수도 있는데 클라이언트는 이를 진정으로 구분할 수 없습니다. 만약 제가 이를 드러내지 않는다면, 저는 미세 조정 (Tweak)으로 위장된 무제한의 작업을 수락하는 셈이 됩니다.

요청이 들어오는 순간 중심을 잡으세요

실수는 작은 추가 사항들을 그냥 통과시킨 뒤 마지막에 정산하려고 하는 것입니다. 그때가 되면 일정은 이미 어긋나 있고 대화는 대립적인 관계로 변합니다. 저는 모든 요청이 들어오는 즉시 동일한 방식으로 처리합니다:

그것이 실제로 무엇을 건드리는지 명시하세요. 환불(Refunds) 기능은 단순한 "의도(intent) 하나 추가"가 아닙니다. 그것은 하나의 액션(action), 권한 범위(permission scope), 새로운 실패 모드(failure mode), 그리고 새로운 평가 케이스(eval cases)입니다. 저는 이 점을 명확히 말합니다.
단순히 예/아니오가 아니라, 시간으로 가격을 매기세요. "안전함을 증명하기 위한 평가(evals)를 포함하여 대략 3일 정도 소요됩니다."라고 말하는 것입니다. 숫자를 제시하면 요청의 성격이 '부탁'에서 '의사결정'으로 재구성됩니다.
트레이드오프(trade-off)를 명시하세요. "환불 기능을 추가하거나, 아니면 원래 출시일을 지키거나 둘 중 하나를 선택해야 합니다. 기능을 추가하면 출시가 약 일주일 정도 밀립니다. 결정해 주십시오." 대부분의 클라이언트는 트레이드오프를 눈으로 확인할 수 있을 때 합리적인 선택을 합니다.
변경 사항으로 기록하세요. 시간 영향도를 포함한 한 줄짜리 변경 노트를 작성하세요. 이는 관료주의가 아니라, 나중에 아무도 다시 논쟁하지 않도록 공유된 기록을 남기는 것입니다.

제가 결코 '안 된다'고 말하지 않았다는 점에 주목하십시오. 저는 비용을 가시화하고 결정권을 다시 넘겨주었습니다. 그것이 업무의 전부입니다. 클라이언트는 자신들이 선택한 가치에 대해 비용을 지불하는 것을 원망하지 않습니다. 그들이 원망하는 것은 예상치 못한 상황(surprises)이며, 관리되지 않은 범위 확장(scope creep)이 만들어내는 것이 바로 그 예상치 못한 상황입니다.

이를 조기에 방지하기 위한 몇 가지 습관

입력 분포(input distribution)를 사전에 정의하세요. 많은 "범위 확장"은 사실 처음부터 모호했던 범위에서 비롯됩니다. 에이전트(agent)가 처리할 케이스를 정확히 합의했다면, 새로운 케이스는 선을 넘은 것이 명확히 보입니다.
범위를 평가 세트(eval set)와 연결하세요. "완료"의 기준이 고정된 테스트 케이스 세트일 때, 새로운 요청은 명백히 새로운 케이스가 되며, 이는 추가 작업이 논쟁의 대상이 아닌 구체적인 실체로 느껴지게 합니다.
파킹 로트(parking lot, 보류 목록)를 운영하세요. 범위에 포함되지 않는 좋은 아이디어들은 다음 단계를 위한 가시적인 목록에 올려둡니다. 사람들은 요청이 거절당하는 것이 아니라 기록되었다고 느낄 때 훨씬 더 쉽게 그 요청을 내려놓습니다.
정확도(accuracy) 요구사항을 특히 주의 깊게 살피세요. 누군가 "더 나은(better)" 결과를 원할 때, 저는 먼저 목표 수치와 테스트 세트에 대해 합의하도록 만듭니다. 그렇지 않으면 "더 나은" 상태는 결코 끝나지 않습니다.

직접 개발할 것인지 아니면 구매할 것인지(build-vs-buy)에 대한 결정이 일부 변화한 이유는 AI가 맞춤형 작업의 시작 비용을 낮추었기 때문이며, 이에 대해서는 The build-vs-buy line just moved에서 다룹니다. 시작 비용이 저렴해졌다는 점이 바로 지금 범위 관리(scope discipline)가 이전보다 덜 중요한 것이 아니라, 오히려 더 중요해진 이유입니다. 개발이 쉬워 보일 때, 계속해서 기능을 추가하고 싶은 유혹은 끊임없이 찾아옵니다.

핵심 요약 (Key takeaways)

범위 확장(Scope creep)은 모든 프로젝트의 절반 이상에 영향을 미치며, 새로운 요청이 기만적일 정도로 작아 보이는 AI 작업에서는 이를 파악하기가 더 어렵습니다.
"더 정확하게 만들어 주세요"라는 요구는 끝이 없을 수 있습니다. 이를 목표 수치와 테스트 세트(test set)에 고정하지 않으면 결코 끝나지 않습니다.
요청이 들어오는 즉시 선을 그으세요: 해당 요청이 무엇에 영향을 미치는지 명시하고, 소요 기간을 일(days) 단위로 산정하며, 트레이드오프(trade-off)를 명확히 하고, 이를 문서화하세요.
거절하는 것이 아닙니다. 비용을 가시화하여 결정권을 다시 상대방에게 넘기는 것입니다.
범위를 평가 세트(eval set)와 연결하고, '좋지만 범위 밖인(good-but-out-of-scope)' 아이디어들이 유실되지 않도록 별도의 보관함(parking lot)을 운영하세요.

자주 묻는 질문 (FAQ)

범위에 대해 엄격하게 구는 것이 고객 관계에 나쁘지 않나요? 오히려 그 반대입니다. 고객은 확정하기 전에 실제 비용을 알려주는 PM을 신뢰합니다. 작업 범위가 조용히 확장되고 아무런 설명 없이 마감일이 밀릴 때 고객은 신뢰를 잃습니다.

확신이 서지 않는 변경 사항의 비용을 어떻게 산정하나요? 범위를 제시하고 그것이 범위임을 명시한 뒤, 필요한 경우 조사 시간을 제한(timebox)하세요. "2일에서 5일 정도 소요됩니다. 확인을 위해 한 시간만 써보겠습니다"라고 말하는 것이 정직하면서도 실행 가능한 방식입니다.

고객이 모든 것이 범위 내에 있다고 주장하면 어떻게 하나요? 그럴 때는 합의된 입력 분포(input distribution)와 평가 세트(eval set)를 다시 지목하세요. 범위는 여러분이 함께 작성한 것입니다. 그 목록에 없다면 그것은 변경 사항이며, 이는 의견이 아닌 사실입니다.

만약 귀하의 AI 프로젝트가 매주 조금씩 커지고 마감일이 계속 밀리고 있다면, 문제는 까다로운 고객이 아니라 대개 누락된 변경 관리 프로세스에 있습니다. Shanti Infosoft 팀은 귀하가 실제로 방어할 수 있는 범위를 설정할 수 있도록 도와드릴 수 있습니다.