스코프 크리프의 함정: 그럴듯하지만 아닌 기능에 거절하는 법

앱을 출시했습니다. 사용자가 모였습니다. 그리고 이제 받은 편지함은 죄다 좋은 아이디어처럼 들리는 기능 요청으로 가득합니다.

“엑셀로 내보내기 추가할 수 있나요?” 합리적이죠. “청구서를 자동으로 보낼 수 있나요?” 말이 됩니다. “Stripe랑 연동할 수 있나요?” 거기에 진짜 돈이 있죠. “모바일 앱 추가할 수 있나요?” 다들 그걸 요청하죠. “이걸 우리 고객용으로 화이트라벨할 수 있나요?” 오, 이제 사업 모델이 보이네요.

각 요청은 하나하나 따로 보면 똑똑하게 들립니다. 합쳐 놓으면, 마치 다섯 개의 서로 다른 제품을 만드는 것처럼 들립니다.

이게 스코프 크리프입니다. 그리고 이것은 기술적 문제가 죽이는 것보다 더 많은 작은 AI로 만든 앱을 죽입니다. 당신이 기능을 만들기 때문이 아니라 — 그걸 만들려다 시간, 돈, 또는 정신이 바닥나기 때문입니다.

스코프 크리프가 잘 돌아가는 앱을 죽이는 과정

이렇게 흘러갑니다. 처음 세 요청은 합리적으로 보여서 예라고 합니다. AI 빌더에게 추가해 달라고 합니다. 새 기능마다 기존 코드에 부딪히기 때문에 일주일이 아니라 이 주가 걸립니다. 이제 다섯 가지를 하는 앱이 생겼고, 그중 셋은 잘하고 둘은 그럭저럭합니다.

그다음 네 번째 요청이 도착합니다. “권한 등급을 다르게 둘 수 있나요?” 갑자기 모든 화면에서 누가 무엇을 볼 수 있는지를 다시 생각해야 합니다. 그건 기능이 아닙니다. 아키텍처 변경입니다. AI 빌더에게 시킵니다. 모든 곳을 건드립니다. 이 주가 삼 주가 됩니다. 모든 뷰에 로직을 더했으니 앱은 느려집니다.

여덟 번째 요청쯤이면, 기능 요청 기계를 계속 돌리느라 너무 바빠서 원래 사용자들을 위한 새것을 출시하는 일을 멈췄습니다. 석 달 전 그 앱을 사랑했던 사람들은 자기가 요청한 게 아무것도 끝나지 않아 답답합니다. 새 요청을 하는 사람들은 기능이 한없이 걸려서 답답합니다.

잘 돌아가는 무언가를 만들었습니다. 모든 것이 되려다 그걸 망가뜨렸습니다.

의사결정 프레임워크

관문이 필요합니다. 모든 기능 요청은 세 가지 질문을 통과해야 합니다.

질문 1: 이건 이 앱에 속하는가, 아니면 다른 앱인가?

당신의 첫 앱은 한 가지 일을 정말 잘합니다. 일정 앱은 일정을 잡습니다. 청구 앱은 청구합니다. 서로 다른 앱입니다. 누군가 당신의 일정 앱에 청구를 요청한다면, 기능을 더하는 게 아니라 — 일정 앱에게 회계를 시키는 것입니다. 그건 다른 제품입니다.

좋은 시험법이 있습니다. “이 기능을 떼어서 단독으로 출시하면, 사람들이 사고 싶어 할까?” 그렇다면, 아마 다른 앱에 속합니다. 답이 “아니, 더 큰 것의 일부일 때만 말이 돼”라면, 당신은 올바른 스코프를 만들고 있는 겁니다.

“우리 CRM이랑 연동해 줘” 같은 요청을 받을 겁니다. 그게 실제로 뜻하는 건 “당신이 직접 CRM이 되어 줘”입니다. 그건 다른 앱입니다. CRM과 연동하는 건 나중에 할 수 있습니다. CRM 하나 분량의 기능을 더하면서 CRM이 되지 않을 수는 없습니다.

질문 2: 이건 사용자 대다수의 문제를 푸는가, 아니면 이 한 사람의 문제만 푸는가?

한 고객이 당신의 앱을 사랑하고 기능 아이디어를 갖고 있습니다. 그건 그 사람이 실제로 가진 진짜 문제입니다. 그리고 그 사람만 가진 진짜 문제이기도 합니다.

사용자가 스무 명인데 한 명이 무언가를 요청한다면 확인하세요. 나머지 열아홉 명도 이걸 기다리고 있나, 아니면 이 사람이 방금 떠올린 건가? 직접 물어볼 수도 있습니다. “당신 말고 다른 누군가에게도 이게 필요한지 물어볼 생각을 해 본 적 있나요?” 대개 답은 아니오입니다.

이건 위험한 질문입니다. 요청하는 그 한 고객이 가장 중요한 고객일 수도 있기 때문이죠. 그를 만족시켜야 할 수도 있습니다. 그건 제품 결정이 아니라 사업 결정입니다. 다만 눈을 똑바로 뜨고 들어가세요. 한 고객을 위해 무언가를 만들면, 앱을 키우는 게 아니라 외주 컨설팅을 차리는 것입니다.

질문 3: 이건 무엇을 치르게 하고, 원래 아이디어에는 어떤 비용을 치르나?

모든 것에는 비용이 듭니다. 엑셀 내보내기는 엔지니어링 시간을 잡아먹습니다. 앱의 복잡도를 늘립니다. 집중력을 갉아먹습니다. 사용자가 매일 불평하는 성능 개선 대신 그걸 만들었다면, 당신은 선택을 한 것입니다.

구체적으로 물으세요. “이걸 만들면, 무엇을 안 만들게 되나?” 답이 “아무것도, 우리는 시간이 무한하니까”라면, 당신은 솔직하지 않은 겁니다. 우리는 그렇지 않습니다. 시간은 유한합니다.

원래 아이디어에 드는 비용은 흔히 눈에 보이지 않습니다. 기능 요청에 깊이 빠져 있을 때, 사람들이 사랑했던 핵심을 유지하는 일을 멈추게 됩니다. 핵심이 느려집니다. 핵심에 버그가 늘어납니다. 핵심이 방치된 느낌을 줍니다. 그리고 결국 사람들은 떠납니다. 훌륭하게 작동하던 앱이 이제는 그럭저럭 작동하고, 애초에 설계되지 않은 일들을 하고 있으니까요.

실제 예: 접수 양식

누군가 간단한 고객 접수 양식을 만들었습니다. 고객이 작성하고, 코치가 검토하고, 일정을 잡습니다. 그게 앱입니다.

요청 1: “긴급 접수를 표시할 수 있나요?” 예, 그건 핵심 흐름의 변형입니다. 만드세요.

요청 2: “기록용으로 접수를 엑셀로 내보낼 수 있나요?” 이건 문서 기능입니다. 앱의 일이 아닙니다. 접수는 앱 안에 삽니다. 엑셀이 필요하면 복사해 붙여 넣으면 됩니다. 하지만 좋습니다, 내보내기는 편의로서 말이 될 수 있습니다. 만드세요.

요청 3: “접수가 자동으로 캘린더 일정을 만들 수 있나요?” 이제 일정 관리를 하고 있습니다. 앱은 접수를 위한 것이지 일정 관리를 위한 게 아니었습니다. 둘 다 원하는 사람이라면, 거기에 억지로 붙인 임시방편이 아니라 진짜 일정 시스템을 원할 겁니다. 정중히 거절하세요.

요청 4: “코치가 접수 후속 연락을 SMS로 보낼 수 있나요?” 이제 당신은 커뮤니케이션 시스템입니다. 안 됩니다.

세 번째 요청쯤이면 경계에 다다랐습니다. 앱은 접수입니다. 그 외 모든 것은 다른 앱입니다. 그 앱들과 연동하는 건 나중에 할 수 있습니다. 그것들이 되지 않고서는 더할 수 없습니다.

거절하는 법

가장 어려운 부분은 실제로 그 말을 하는 것입니다. 사용자를 답답하게 만들고 싶지 않으니까요.

솔직하게 말하세요. “정말 좋은 아이디어예요. 그런데 그건 우리가 여기서 만드는 것과는 다른 제품이에요. 우리가 만드는 건 [당신의 한 가지 일]입니다. 일정이든 청구든 CRM이든 다 하려고 하면, 전부 그럭저럭이 되고 어느 것도 훌륭하지 못해요.”

대개 고객은 이해할 겁니다. 그들은 떠오른 아이디어라서 물은 것이지, 당신을 시험하려고 물은 게 아닙니다.

때로는 반박할 겁니다. “하지만 난 둘 다 필요해요.” 바로 그때 권하세요. 진짜 일정 앱을 쓰세요. 진짜 청구 앱을 쓰세요. 진짜 CRM을 쓰세요. 그리고 이 앱은 잘하는 그 한 가지를 위해 쓰세요. 그게 솔직한 답입니다.

모든 것이 되고 싶은 유혹

작은 제품을 만들 때 가장 어려운 부분은 거절하는 것입니다. 거절은 돈을 식탁에 남겨 두는 것처럼 느껴집니다. 그 고객이 정말로 둘 다에 돈을 냈을 수도 있는데? 그 기능이 당신을 열 배 더 키웠을 수도 있는데?

그럴 수도 있습니다. 하지만 출시하지 않으면 당신은 열 배 큰 제품이 아닙니다. 다섯 가지를 어설프게 하는 절반쯤 만든 제품입니다. 핵심을 사랑했던 사람들은 답답합니다. 새 기능을 원했던 사람들도 답답합니다. 그리고 무언가 새것을 더하려면 먼저 낡은 다섯 가지를 리팩터링해야 하는 막다른 구석에 스스로를 몰아넣었습니다.

성장하는 제품은 한 가지 일을 정말 잘하고, 그다음 조심스럽게 더하는 제품입니다. 첫날부터 Salesforce가 되려 하지 않습니다. 그 한 가지가 필요할 때 손이 가는 앱, 그리고 그 일을 할 때 빠르고 믿음직하리라 신뢰하는 앱입니다.

거절하세요. 핵심을 지키세요. 그렇게 하면, 사람들이 정말로 쓰고 싶어 하는 무언가를 만들게 됩니다.