원래 제품의 새 기능이나 개선은 PRD 기반으로 기획 > 리뷰 > 디자인 > 개발 > QA를 거칩니다. 그런데 AI 도구 역량이 상향 평준화되면서, 기획 단계에서 프로토타입을 직접 만드는 경우가 많아졌습니다. 이 과정에서 좋았던 부분과 비효율적이었던 부분을 공유합니다.
——
1. 빌더 시스템 구축
프로토타입을 만들기 위해서는 사내 시스템 구축이 필요합니다. 사실상 이게 없으면 원하는 수준의 프로토타입 구현이 어려운데, 내부적으로는 필요성을 감지하고 디자인 시스템과 각종 컴포넌트, 도메인 지식, API 등의 시스템이 구축되어 있어 MCP 기반으로 사용 가능했습니다. 기존 프로토타입은 지금과 비교하면 사실상 사용이 불가한 수준입니다.
2. 의사 결정의 속도
사실 눈에 보이는 것과 그렇지 않은 것의 판단은 차이가 있습니다. 아무리 잘 완성된 PRD도 완벽하게 그려지지는 않는데요. 프로토타입은 이런 부분을 해소하고 빠른 의사 결정을 하게 됩니다. 불필요한 잡음은 제거되고 개선했으면 하는 부분 위주로 토론하게 됩니다.
3. 충분히 필요한 기능/개선인가?
잘 만드는 것과 필요한 것을 만드는 것은 다릅니다. 최근 클로드 코드 Fable 모델이 풀리면서 여러 프로토타입을 만들고 팀에 리뷰를 해봤습니다. 나름 필요하다고 판단된 기능들인데, 30% 프로토타입은 완성도는 좋지만 필요성에 대해서는 큰 공감을 얻지 못했습니다. 사실 폐기된다면 상당히 많은 토큰을 날리는 셈입니다.
———
AI를 받아들이는 조직 분위기와 이를 바탕으로 시스템을 구축하는 것이 매우 중요한 것 같습니다. 기반을 다져야 비개발자들이 접근 가능한 환경에서 프로토타입도 여러 방향으로 구현할 수 있을 것 같네요.
무엇보다도 ’이게 왜 필요한가?’에 대한 충분한 고민이 있어야 프로토타입 활용의 의미가 강해질 것입니다.
#AI #Product
