Webflow 코드 컴포넌트 공부 정리 | 두 가지 경로가 보여주는 것
Webflow에서 AI로 React 컴포넌트를 만드는 두 가지 방법을 공부하면서 든 생각들.
Webflow 공식 블로그에서 AI 코드 컴포넌트 관련 글이 올라왔다. AI로 React 컴포넌트를 만드는 두 가지 경로를 소개한 내용인데, 읽다 보니 “디자이너가 직접 할 수 있는 것”의 경계가 어떻게 달라지는지 궁금해졌다.
처음엔 그냥 기능 소개 글이겠지 싶었다. 그런데 두 가지 경로를 나란히 두고 설명하는 방식이 흥미로워서 좀 더 파봤다. 같은 결과물인데 왜 두 경로를 따로 만들었을까, 하는 질문이 자꾸 남았기 때문이다.
1️⃣ 이게 뭐냐?
Webflow에서 코드 컴포넌트를 만드는 방식이 두 가지다. 하나는 캔버스 경로, 다른 하나는 코드베이스 경로다.
캔버스 경로는 자연어 프롬프트를 입력하면 React 컴포넌트가 바로 Webflow 캔버스에 올라오는 방식이다. 터미널이나 CLI 없이도 되고, 생성된 컴포넌트는 속성 패널에서 props를 직접 조작할 수 있다. 아코디언이나 탭 UI 같은 인터랙티브 요소를 개발자에게 티켓으로 넘기는 대신 프롬프트로 만들어보는 식이다.
코드베이스 경로는 DevLink라는 CLI 기반 방식이다. AI 에이전트가 Webflow 공식 문서를 읽고 코드를 작성하면 .webflow.tsx 파일이 로컬에 생긴다. 버전 관리와 코드 리뷰까지 포함한, 기존 개발 워크플로우에 가까운 방식이다. 복잡한 컴포넌트를 다루거나 팀 단위로 관리해야 할 때 더 맞는 경로인 것 같았다.
두 경로의 결과물은 동일한 React 컴포넌트다. 다른 건 만드는 사람과 맥락이다. 디자이너가 캔버스에서 빠르게 시도하거나, 개발자가 코드베이스에서 꼼꼼하게 관리하거나, 어느 쪽이든 같은 파일 형식으로 귀결된다.
2️⃣ 내가 든 생각
이 글에서 인상적이었던 건 “같은 결과물, 두 가지 경로”라는 구조다. Webflow가 디자이너와 개발자 중 어느 한쪽만 타겟으로 삼지 않고 둘 다 커버하려 했다는 게 느껴졌다.
디자이너 입장에서 캔버스 경로가 흥미로운 건, 기존에 개발자에게 넘겨야 했던 작은 컴포넌트들을 직접 시도해볼 여지가 생긴다는 점이다. 공부한 내용 기준으로만 보면, 간단한 인터랙션 정도는 프롬프트로 처리할 수 있게 되는 것 같다.
👉🏻 그런데 공부하다 보니 이 질문이 계속 머릿속을 맴돌았다 — 프롬프트로 만든 컴포넌트가 기존 디자인 시스템과 얼마나 잘 붙느냐는 거다.
캔버스에서 빠르게 만들 수 있다 해도, 그 컴포넌트가 기존 스타일 토큰이나 컴포넌트 가이드라인과 어떻게 연결되는지, 수정이 생겼을 때 어떻게 관리하는지 같은 부분이 공부한 문서에서는 명확하지 않았다. 빠르게 만든다는 것과 잘 관리한다는 것 사이에 갭이 있을 것 같다는 생각이 들었다.
💡 여기서 드는 질문? AI가 만든 컴포넌트의 “책임”은 누가 지는 걸까. 프롬프트를 입력한 사람이 그 코드의 내용을 얼마나 파악하고 있어야 하는 구조인지 궁금해졌다.
3️⃣ 앞으로 어떻게 쓸까?
공부한 내용 기준으로 보면, 캔버스 경로는 작은 프로토타입이나 일회성 컴포넌트에는 맞을 것 같다. 반면 디자인 시스템에 편입시켜야 하거나 여러 명이 함께 쓰는 컴포넌트라면 코드베이스 경로가 더 안정적이지 않을까 싶다.
아직 문서만 본 입장에서는 단정하기 어렵지만, 도구가 두 가지 경로를 제공한다는 건 사용자가 그 차이를 직접 판단해야 한다는 뜻이기도 한 것 같다.
⭐️ 마지막으로, 두 경로를 공부하며 남은 생각
정리해보니 두 경로의 차이는 속도보다 책임이 어디에 얹히느냐에 가까웠다. 캔버스 경로는 빠르게 결과를 만드는 대신 코드의 관리 책임이 모호해질 수 있고, 코드베이스 경로는 개발 흐름에 녹아드는 대신 진입 장벽이 있다.
공부 끝에 남은 건 — 빠르게 만들 수 있느냐보다 자신이 만든 것을 얼마나 파악하고 있느냐가 더 중요한 문제라는 한 줄짜리 생각이다.