기획안 하나를 승인받기까지 며칠이 걸리는지 세어본 적 있으십니까. 디자이너에게 와이어프레임을 요청하고, 피드백 라운드를 한 번 더 돌고, 개발자에게 실제로 어떻게 보일지를 다시 묻는 그 과정 말입니다. Stripe의 한 PM은 그 대기 시간 전체를 2분으로 압축하는 도구를 직접 코딩했습니다. Figma도, 외부 프로토타이핑 툴도 아닌, 회사 내부 디자인 시스템을 그대로 끌어다 쓰는 클릭 가능한 프로토타입을 말이죠. 도구의 이름은 Protodash. 코딩을 직업으로 삼지 않는 사람이 만든 것치고는, 꽤 무거운 의미를 담고 있습니다.

Stripe에서 일어난 일을 정확하게 봐야 합니다

Stripe의 Owen Williams는 이 도구를 이른바 '바이브 코딩(vibe coding)' 방식으로 만들었습니다. AI 모델에게 의도를 말하고, 나오는 코드를 조율하고, 다시 수정하는 방식입니다. 완성된 Protodash는 Stripe의 내부 디자인 시스템을 입력으로 받아, 클릭 가능한 인터랙티브 프로토타입을 약 2분 안에 생성합니다. 기존에는 이 작업에 디자이너의 몇 시간, 때로는 며칠이 필요했습니다.

여기서 중요한 것은 속도 자체가 아닙니다. Protodash가 사용하는 것은 Stripe 고유의 디자인 시스템입니다. 일반적인 목업 툴이 '그럴듯해 보이는' 화면을 만든다면, 이 도구는 '실제 제품과 동일한 컴포넌트'를 사용하는 화면을 만듭니다. 즉, 기획자가 직접 만든 프로토타입이 실제 개발 산출물과 시각적으로 거의 동일합니다. 이해관계자가 "실제로 어떻게 생기냐"고 묻는 질문 자체가 사라집니다.

이 사례가 Lenny's Newsletter를 통해 알려진 것은 2025년 상반기입니다. 단순한 생산성 해킹 사례로 소개됐지만, 내용을 들여다보면 그 이상입니다. PM이 디자이너의 협력 없이 고품질 프로토타입을 만들 수 있다는 것, 그리고 그것이 회사 내부에서 이미 실운용되고 있다는 것, 두 가지 사실이 함께 존재합니다.

이것이 이전과 다른 이유는 하나입니다

지금까지 PM이 '직접 프로토타입을 만든다'는 말은 대부분 Figma 기초 교육을 받거나, 간단한 플로우차트를 그리는 수준을 의미했습니다. 그것도 꽤 긴 학습 곡선과 함께였습니다. Balsamiq 같은 저충실도(low-fidelity) 툴을 쓰더라도 결국 "이게 실제로 어떻게 구현되느냐"는 질문은 늘 남았고, 디자이너와 개발자의 확인 없이는 그 답을 낼 수 없었습니다.

Protodash는 그 구조 자체를 바꿉니다. '프로토타입을 만드는 역할'이 반드시 디자이너에게 있어야 하는 것은 아니라는 전제를 실제 제품으로 증명했습니다. 더 중요한 것은, 이 도구를 만든 사람이 전문 개발자가 아니라 PM이라는 점입니다. 문제를 가장 가까이 가지고 있는 사람이 직접 해결책을 만들었습니다.

이 지점에서 한 가지 질문이 생깁니다. AI가 기술과 지식을 대체하기 시작한 지금, 프로토타입을 만드는 기술(skill)과 디자인 시스템에 대한 지식(knowledge)은 더 이상 PM의 병목 지점이 아닙니다. AI가 그 두 가지를 상당 부분 처리할 수 있게 됐으니까요. 그렇다면 PM에게 남는 것은 무엇일까요. 문제를 정확하게 정의하는 능력, 도구를 언제 어떻게 써야 할지 판단하는 감각, 그리고 불편한 현실을 직접 해결하려는 의지입니다. 이것은 기술도, 지식도 아닙니다. 태도에 가깝습니다.

역량을 기술(Skill), 지식(Knowledge), 태도(Attitude)의 세 축으로 볼 때, AI 도구가 가장 빠르게 대체하고 있는 것은 앞의 두 가지입니다. 반면 태도—문제를 외면하지 않고 직접 부딪히는 의지, 완벽하지 않아도 먼저 시도하는 자세—는 AI가 복제하지 못하는 영역입니다. Owen Williams가 Protodash를 만든 것은 뛰어난 코딩 실력 때문이 아닙니다. "이 불편함을 내가 직접 해결하겠다"는 결정이 먼저 있었기 때문입니다.

물론 이 변화가 디자이너의 역할을 축소시킨다는 식의 해석은 지나친 단순화입니다. Protodash가 만드는 것은 '확인과 합의를 위한 프로토타입'입니다. 디자이너가 담당하는 사용자 경험 설계, 비주얼 시스템의 의사결정, 접근성 검토 같은 영역은 이 도구의 범위 밖에 있습니다. 오히려 디자이너들은 저충실도 리뷰 미팅에서 벗어나, 더 복잡한 의사결정에 시간을 쓸 수 있게 됩니다. 역할이 사라지는 것이 아니라, 각 역할이 AI가 닿지 않는 깊이로 이동하는 것입니다.

한국 1인 사업자·기획자에게 이 사례는 무엇을 의미합니까

첫 번째 질문은 이것입니다. 지금 여러분이 가진 업무 흐름 중에서, "다른 사람에게 넘기는" 단계가 실제로는 필요하지 않은 것은 아닐까요.

많은 1인 사업자와 솔로 기획자가 프로토타입, 제안서 목업, 서비스 페이지 초안 등을 외주 또는 협업자에게 넘깁니다. 그 이유가 "나는 그 기술이 없어서"라면, 그 전제가 2025년에도 여전히 유효한지 확인이 필요합니다. v0.dev, Bolt, Lovable 같은 도구들은 이미 디자인 경험 없이도 컴포넌트 기반의 UI를 생성합니다. Figma의 AI 기능들은 와이어프레임을 보완하는 방향으로 빠르게 발전하고 있습니다. 기술 장벽이 낮아졌다는 것은, 여러분이 직접 만들어야 한다는 의무가 아니라, 직접 만들 수 있다는 선택지가 생겼다는 뜻입니다.

두 번째 질문은 조금 다른 결입니다. Protodash의 핵심은 Stripe의 디자인 시스템을 입력으로 쓴다는 점입니다. 즉, 회사 고유의 자산을 AI 도구와 연결했을 때 비로소 차별화된 결과물이 나옵니다. 1인 사업자나 소규모 팀이라면 이렇게 물을 수 있습니다. "내 비즈니스의 디자인 시스템, 즉 반복되는 언어·톤·구조·형식은 무엇인가?" 그것을 정의해두고, AI 도구에 그 맥락을 주는 것이 훨씬 일관된 산출물을 만들어냅니다. 서비스 기획서든, 제안서든, 콘텐츠 포맷이든 마찬가지입니다.

세 번째로 점검할 것은 여러분이 AI 도구를 사용하는 방식입니다. 지금 AI를 쓰고 있다면, "결과물을 받는 사람"으로서 쓰고 있습니까, 아니면 "문제를 정의하고 도구를 조율하는 사람"으로서 쓰고 있습니까. Owen Williams가 Protodash를 만든 방식은 후자입니다. "2분 안에 프로토타입을 만들어줘"라는 단순한 요청이 아니라, 어떤 입력이 필요하고 어떤 형태의 출력이 문제를 해결하는지를 스스로 설계한 다음, AI를 그 설계의 실행 도구로 썼습니다. 이 차이는 산출물의 품질에서 그치지 않고, 내가 도구를 통제하는 사람인지 도구에 의존하는 사람인지를 가릅니다.

구체적으로 시도해볼 수 있는 것들을 나열하지 않겠습니다. 대신 한 가지만 제안합니다. 다음 주 내에 "원래는 누군가에게 맡겼을 산출물 하나"를 AI 도구로 직접 만들어 보십시오. 완성도가 낮아도 됩니다. 그 경험이 다음에 무엇을 맡기고 무엇을 직접 할지를 훨씬 정확하게 판단하게 해줍니다.

Stripe 안에서 조용히 쓰이다 알려진 이 도구가 흥미로운 이유는 속도나 기술 때문이 아닙니다. "불편함을 발견한 사람이 해결책을 직접 만들었다"는 그 태도 때문입니다. 어떤 역할에 있든, AI 시대에 가장 쓸모 있는 역량은 여전히 그 태도에서 시작합니다. 기술은 빌릴 수 있고 지식은 검색할 수 있지만, 문제 앞에서 "내가 해보겠다"고 말하는 것은 본인만 할 수 있습니다.