개발자의 도메인 지식, 그리고 기획자의 브릿지 ROI

도메인 지식(Domain Knowledge)이라는 게임에서, 나는 항상 당했다. 첫  서비스 기획 업무 때부터 지금까지, 개발자들은 내가 예상하지 못한 B와 C를 언급했다. 내가 A라는 기능을 요청하면, 그들은 "그럼 기존 알고리즘은 어떻게 할 거예요?"라고 물었다. "DB에 저장되는 데이터 규모는 고려했어요?"라고도 했다. 그들의 질문이 악의인지, 내가 놓친 걸 채워주는 건지 지금도 헷갈린다. 하지만 분명한 건, 그들이 가진 레거시 시스템(Legacy System)에 대한 이해도는 내 요구사항 식별(Requirements Elicitation) 능력보다 훨씬 깊었다는 점이다.
연차는 숫자가 아니었다. 개발자들은 이  도메인에서 7년,9년을 보냈다. 나는 기획자로서 0년 차였을 뿐이다. 그들이 말하는 B와 C는, 이미 수년 간 고객 민원으로 듣고, 버그로 경험하고, 패치로 해결해온 영역이었다. 반면 나는 사용자 여정(User Journey)을 그리는 게 전부였다. 그래서 나는 항상 쩔쩔맸다. 부서장에게는 "완성도가 낮다"며 욕을 먹고, 현업에게는 "왜 개발자 말을 못 막느냐"며 아쉬운 소리를 들었고, 결국 개발자에게 휘둘리는 기획자가 되었다.
그래서 의문이 들었다. 서비스 기획이라는 직군은 뭘 위한 걸까? 엔드유저(End User)인 현업, 라이더, 고객들이 개발자에게 직접 요건을 주면 되지 않나? 어릴 때 도스 프로그램은 복잡한 UI/UX가 없었다. 그때도 기획자가 있었을까? 크리스 소이어는 타이쿤 시리즈를 기획자 없이 혼자 개발했다. 그러니까 능력 없는 것끼리 서로 남탓하려고 직군을 나눈 건 아닐까?
하지만 여기서 커뮤니케이션 오버헤드(Communication Overhead)라는 개념을 깨달았다. 개발자가 직접 엔드유저를 만나 요건을 받으면, 하루 8시간 중 4시간은 미팅에 쓴다. 남은 4시간으로 코드를 짤 수 있을까? 그리고 엔드유저는 자기가 필요한 걸 말하지, 기술적으로 가능한 걸 모른다. "이 화면에 버튼 하나만 넣어주세요"라는 요구는, 사실 "A/B 테스트를 위한 버튼이에요, 아니면 전체 사용자 대상이에요? 모바일에서도 보여야 해요? 권한은 누구에게 주나요? 로그는 남기나요?" 같은 10개의 질문으로 확장된다. 이걸 개발자가 하나하나 물어봐야 한다면, 개발 일정은 폭주하고, 스프린트(Sprint)는 무너진다.
기획자의 진짜 가치는 브릿지(Bridge)에 있다. 기술 언어와 비즈니스 언어를 번역하는 ROI다. 개발자는 "DB 컬럼 추가하고 인덱스 타는지 확인해야 해요"라고 말하고, 현업은 "고객이 검색했을 때 3초 이내에 결과 나와요?"라고 말한다. 기획자는 이 두 문장을 하나의 User Story로 만든다. "고객이 검색했을 때 3초 내 결과를 보여주기 위해, DB에 인덱스를 추가한다." 이게 바로 Product Owner가 하는 일이다.
크리스 소이어가 1인 개발자로 타이쿤을 만들 수 있었던 건, 그가 동시에 기획자였기 때문이다. 그는 게이머였고, 개발자였고, PM이었다. 하지만 기업  서비스는 혼자 만들 수 없다. 엔드유저는 수만 명, 개발자는 수십 명, 현업 부서는 수십 개다. 1인 기업과 1,000인 기업의 차이는 바로 이 커뮤니케이션 구조의 복잡도다. 기획자 없이 개발자와 엔드유저가 직접 소통하는 건, 마이크로서비스 아키텍처(MSA)에서 모든 서비스가 직접 통신하면 네트워크가 복잡해지는 것과 같다. API Gateway가 필요하듯, 기획자가 그 중간에 있어야 비용이 줄어든다.
나는 능력 없는 기획자였다. 하지만 그건 기획자라는 직군이 불필요하다는 뜻이 아니라, 내가 제대로 된 브릿지 역할을 못했다는 뜻이다. 개발자가 B와 C를 언급할 때, 그게 악의인지 도움인지 구분하려면 내가 그들의 레거시를 이해해야 했다. 그들이 왜 그 질문을 하는지, 어떤 민원을 겪었는지, 어떤 기술적 한계가 있는지. 그걸 모르면, 나는 '요구사항 전달자'에 그치고 만다. 하지만 그걸 안다면, 나는 '요구사항 정제자'가 된다.
기획자는 남탓을 위한 직군이 아니다. 능력 없는 사람들이 만든 게 아니다. 사람들이 서로의 전문성을 극대화하기 위해 만든 인터페이스(Interface)다. 개발자는 코드에 집중하고, 현업은 비즈니스에 집중하고, 기획자는 그 둘의 시선을 일치시키는 게 ROI다. 하지만 나는 그 인터페이스를 제대로 구현하지 못했다. 그래서 개발자는 나를 통해 요구사항을 듣는 게 아니라, 나를 우회해서 직접 확인해야 했다. 그게 바로 내 실패의 뿌리였다.