원래 디자인 챕터에서 Figma Make를 적극적으로 썼어요. 새로운 기능 개발 전 UT(Usability Test)를 할 때도, 개발자나 PO와 화면 의도를 맞출 때도요.
정적인 Figma 파일이나 노션 PRD보다 훨씬 효과가 좋았거든요. 클릭 등으로 흐름이 보이니까 만들고 있는 제품에 대한 가치를 쉽게 전달할 수 있었어요.

과거에 Figma Make를 활용한 가설검증 글도 썼었죠.

그러다 Figma Make가 AI 크레딧 기반 요금제로 전환됐어요. 토큰값이 갑자기 너무 비싸져서ㅠ 이대로는 챕터 전체가 계속 쓰기는 어렵겠다 싶었어요.

마침 그 시점에 Lenny's Newsletter에서 Notion 디자인팀이 AI로 일하는 방식이 발행됐는데요. 핵심은 Prototype Playground라는 Next.js 기반 공유 리포지토리, 그리고 /figma, /deploy 같은 Claude Code 슬래시 커맨드로 디자인을 코드로 빠르게 끌어오는 워크플로우였어요.
글을 읽으면서 "이거 우리도 그냥 Claude Code로 만들면 되겠는데?"

솔직히 처음엔 따라 만들 수 있겠나 싶었어요. 그래도 일단 무식하게 영상 그대로 따라가며 시작했어요. /figma, /deploy, Icon Search Skill 중에 우리에게 가장 절실했던 건 /figma였거든요.
첫 화면 하나를 돌려봤는데 정합성은 부족해도 나름 쓸만하더라고요. 토큰 소모도 Figma Make에 비하면 엄청 없는 편이었고요.

/figma https://www.figma.com/design/… 만 입력하면 해당 화면이 그대로 클릭 가능한 프로토타이핑으로 떨어지는 구조예요.
단순한 코드 변환이 아니라, 피그마에서 공통 컴포넌트로 등록된 요소는 미리 개발해둔 동적인 공통 컴포넌트와 자동으로 연결되도록 설계했어요.
안 그러면 같은 인터렉션을 매번 새로 짜야 했거든요. 공통 컴포넌트로 미리 개발되지 않은 인터렉션은 어쩔 수 없이 프롬프트 몇 번으로 따로 구현해야 하는데요.
한 번 등록해두면 다음부터는 재사용 가능해서 시간이 지날수록 노가다 비중도 줄어드는 장점이 있었어요.

노션 디자인팀 처럼 디자이너별로 각자의 네임스페이스를 갖는 구조도 만들었어요. 서로의 작업을 침범하지 않으면서, 다른 디자이너의 로컬 컴포넌트가 마음에 들면 쉽게 내 프로젝트로 땡겨올 수 있고요. 충분히 검증된 컴포넌트는 공통 컴포넌트로 승격시키는 흐름도 같이 설계했어요. 챕터 단위로 동일한 환경에서 자산이 자연스럽게 누적되는 구조를 만들고 싶었어요.

정합성을 업데이트하고 나서 부터 효용은 생각보다 컸어요.
세일즈 팀에서는 아직 개발이 완료되지 않은 프로덕트를 고객사 앞에서 시연할 때 활용하고 있어요. 프로토타입 링크를 바로 공유하기도 하고, 미팅 자리에서 직접 클릭하며 보여주기도 해요.
고객사 반응이 정말 좋더라고요. 단순 Figma 이미지 짜집기로는 절대 불가능했을 것이라고 생각해요. 물론 사내에서도 스쿼드원들과 함께 화면 리뷰할 때 직접 클릭해보며 묻고 답하는 환경이 자연스러워졌어요. 정적인 Figma 화면 앞에서 "이 버튼 누르면 어떻게 돼요?"를 매번 말로 설명하던 시간이 사라진거죠.

Figma Make와 직접 비교하면 둘 다 장단이 있어요. Figma Make는 정적인 라이브러리를 연결하거나 npm registry를 붙여서 실제 개발된 디자인 시스템과 매끄럽게 연결할 수 있다는 장점이 있어요.
가이드라인을 잘 작성해두면 우리 시스템 결을 곧잘 따라가거든요. 근데 결정적으로 첫째, 토큰값이 너무 비싸요. 챕터 전체가 가볍게 쓰기엔 부담이 컸거든요. 둘째, 라이브러리를 한 번에 하나밖에 못 불러와요. 그래서 챕터원들끼리 작업물이나 컴포넌트를 유기적으로 공유하기 어려워서 지속 가능성이 떨어진다고 판단했어요.

반대로 클로드코드로 만든 /figma는 자유도가 훨씬 높았어요. 디자이너별 네임스페이스에서 만든 로컬 컴포넌트가 자연스럽게 챕터 전체로 이어지니까, 시간이 갈수록 자산이 누적되는 구조가 됐어요. Figma 개발에 의존하지 않고 필요한 도구가 있다면 자유롭게 불일 수 있는 큰 장점이 있는거죠.

물론 아직 정합성이나 속도 개선은 더 필요해요. 디자이너 의도와 다르게 나올 때도 있고, 자체 검증 루프가 길어질 때도 있고요.
그래도 이제는 외부 도구로 갈아탈 것 같진 않아요. 물론 기대 이상으로 혁신적인 도구가 나온다면 모를까요..
이러한 도구들을 직접 만들면서 기존 성숙하지 못한 SaaS 제품들은 자연스럽게 버림받을 수 밖에 없다고 생각들었습니다.