지난 10년 동안 소프트웨어 디자인의 도구와 방식은 빠르게 변해왔다. Sketch에서 시작해 Figma, InVision 같은 웹 기반 협업 툴이 등장했고, Origami와 Framer는 프로토타이핑의 가능성을 넓혔다. Pixelcloud, Wake, Abstract 같은 협업 도구가 생겨났고, Zeplin은 개발자 핸드오프를 더 체계적으로 만들었다. 디자이너들은 그때그때 더 좋은 툴과 플러그인을 찾아 조합하며 일해 왔다. 그러나 최근에는 이런 변화와는 결이 다른, 훨씬 근본적인 전환이 나타나고 있다. 바로 AI 에이전트와 함께 디자인하고, 그 결과를 다시 코드로 연결하는 방식이다.
Paper와 AI 에이전트를 중심으로 한 새로운 디자인 워크플로우다. 특히 Paper는 단순히 “AI가 디자인을 대신해 주는 툴”이 아니라, 사람이 직접 중심을 잡고 에이전트를 지휘하며 디자인과 구현을 함께 발전시켜 나가는 캔버스로 제시된다. 이는 단순한 생산성 향상이 아니라, 디자인과 개발의 관계 자체가 바뀌는 신호이다.
가장 인상적인 변화는, 이제 AI 에이전트가 단순히 아이디어를 제안하는 수준을 넘어 실제로 HTML/CSS를 생성하고 Paper의 캔버스를 직접 수정할 수 있다는 점이다. 에이전트는 MCP를 통해 Paper 안에서 프레임을 만들고, 수정 가능한 디자인 결과물을 남긴다. 이때 생성된 프레임은 단순한 이미지가 아니라 사용자가 직접 다시 편집할 수 있는 구조로 만들어지며, Paper의 flex 시스템까지 적용되는 경우가 많다. 그래서 디자이너는 결과물을 받기만 하는 것이 아니라, 캔버스에서 직접 레이아웃과 스타일을 손보고, 다시 그 결과를 에이전트에게 넘겨 코드로 구현하게 만들 수 있다. 즉, 디자인과 코드가 단절된 단계가 아니라 하나의 왕복 루프로 이어지는 것이다.
글쓴이는 이 변화를 “AI-native design”이라고 부른다. 이것은 AI가 사람을 대신해 디자인을 끝내는 방식이 아니라, 사람과 에이전트가 같은 작업 공간 안에서 반복적으로 협업하는 방식에 가깝다. 앞으로 디자이너는 다른 사람과만 협업하는 존재가 아니라, AI 에이전트와 훨씬 더 자주 일하게 될 것이다.
디자인과 UI 구현에는 주로 Claude Code, 특히 Opus 4.6을 사용하고, 프런트엔드 작업이나 빠른 수정에는 Codex 앱을 활용한다고 한다. 이 워크플로를 시작하려면 우선 Claude Code와 Paper MCP를 연결해야 한다. Paper 데스크톱 앱을 설치한 뒤 터미널에서 MCP 서버를 등록하고, Claude 안에서 /mcp 명령으로 연결 상태를 확인하면 준비가 끝난다. 설정 자체는 간단하지만, 그 이후 열리는 작업 방식은 이전과 전혀 다르다.
새 프로젝트를 시작할 때 글쓴이는 빈 화면에서 모든 것을 처음부터 만들지 않는다. 대신 Paper Snapshot을 활용한다. 이 크롬 플러그인은 웹사이트를 Paper 안으로 복사해 editable layer 형태로 가져올 수 있게 해 준다. 즉, 단순히 스크린샷을 참고하는 것이 아니라, 이미 존재하는 UI 패턴을 바로 캔버스로 가져와 구조와 스타일을 활용할 수 있다. 그의 가장 선호하는 방식은 먼저 Snapshot으로 참고할 만한 UI를 가져오고, 그다음 Claude에게 제품 스펙과 함께 “이 레퍼런스를 바탕으로 다시 설계해 달라”고 요청하는 것이다. 이렇게 하면 기본적인 컴포넌트와 프레임을 일일이 세팅하는 시간을 크게 줄일 수 있다.
이 과정에서 중요한 것은 프롬프트의 방식이다. 그는 짧고 추상적인 지시보다 구체적이고 맥락이 풍부한 요청이 훨씬 낫다고 강조한다. 전체 사용자 여정을 한 번에 만들라고 하기보다는 특정 페이지, 특정 컴포넌트, 특정 흐름 단위로 잘게 나눠서 요청하는 편이 결과가 좋다. 여기에 제품 스펙, 참고 스크린샷, 요구사항 문서 같은 부가 맥락까지 함께 제공하면 에이전트는 훨씬 더 나은 출발점을 만든다. 결국 AI와 일할 때도, 사람이 얼마나 명확하게 문제를 정의하느냐가 여전히 중요하다는 뜻이다.
기존 디자인이 있을 때도 이 방식은 유효하다. 그는 기존 파일 안에 에이전트와 집중적으로 실험할 별도의 페이지를 새로 만들어 작업하는 것을 좋아한다고 한다. QA 환경이나 배포 브랜치의 실제 앱 화면을 Snapshot으로 캔버스에 가져오고, Paper에서 선택해 둔 프레임을 기준으로 Claude에게 “이 프레임을 보고 이런 온보딩 플로를 만들어 달라”거나 “이 페이지의 구조를 유지하되 특정 산업군에 맞게 콘텐츠를 채워 달라”는 식으로 요청할 수 있다. 이 덕분에 단순한 와이어프레임을 만드는 것이 아니라, 꽤 현실감 있고 설득력 있는 시안을 빠르게 만들 수 있다. 고객 미팅이나 내부 리뷰를 위한 프로토타입을 준비할 때 특히 강력한 방식이다.
이 워크플로에서 중요한 순간은 AI가 완벽한 결과물을 한 번에 뽑아내는 장면이 아니다. 오히려 글쓴이가 말하는 “aha moment”는, Paper 위에서 에이전트가 실제로 화면을 구성하고 빌드해 나가는 과정을 보면서 디자인이 더 이상 사람이 혼자 하는 작업이 아니라는 사실을 체감하는 순간이다. 다만 그는 이 점을 지나치게 낙관적으로만 보지 않는다. 현실적으로 Opus가 한 번에 잘 만들어 줄 때도 있지만, 대부분은 사람과 에이전트가 여러 번 주고받으며 결과를 다듬게 된다. AI가 초안을 만들고, 사람이 Paper 캔버스에서 수정하고, 다시 에이전트에게 다른 변형안을 요청하고, 준비된 부분부터 코드로 구현하는 식이다. 결국 핵심은 “원샷 생성”이 아니라 반복적 협업이다.
그래서 구현 단계에서도 그는 한 번에 전체 페이지를 맡기지 말라고 조언한다. 디자인이 어느 정도 준비되었다면, 에이전트에게도 특정 페이지나 특정 컴포넌트처럼 작고 분명한 단위로 구현을 맡겨야 한다. 사람이 수동으로 작업할 때도 큰 문제를 작게 나누는 편이 안정적인 것처럼, AI에게도 더 세분화된 단위가 훨씬 좋은 결과를 만든다. 즉, 에이전트를 잘 활용하려면 더 큰 그림을 보는 능력만이 아니라, 일을 잘게 쪼개고 우선순위를 정하는 능력도 필요하다.
Paper는 복잡한 WebGL 캔버스 위에 추상적인 구조를 얹은 방식이 아니라, 더 네이티브한 React 기반 접근을 취하고 있기 때문에 에이전트가 그냥 익숙한 HTML/CSS를 써서 캔버스에 결과를 떨어뜨릴 수 있다고 설명한다. 이 구조 덕분에 디자인 결과와 실제 구현 사이의 간격이 줄어들고, 툴 자체도 더 빠르고 UI 작업에 적합한 감각을 준다고 말한다. 여기에 더해 Paper는 단순히 AI 기능만 있는 도구가 아니라, 셰이더 같은 새로운 표현 도구까지 접근 가능하게 만들면서 디자이너를 위한 더 나은 캔버스를 구축하고 있다고 평가한다. 팀에 대한 신뢰 역시 이유 중 하나다. 특히 창업자인 Stephen Haney가 Radix UI를 만든 인물이라는 점에서, 디자인과 개발의 경계를 오랫동안 고민해 온 팀이 이 문제를 풀고 있다고 본다.
“모델이 아직 UI를 아주 잘하는 것은 아니다”라고 솔직하게 인정한다. AI 모델이 많은 벤치마크에서 뛰어난 성능을 보이더라도, 실제 제품 수준의 세심한 UI 설계에는 여전히 반복과 수정이 필요하다는 것이다. 그래서 좋은 결과는 한 번의 생성이 아니라 사람의 감각과 여러 차례의 피드백 속에서 나온다. 둘째로, Paper는 아직 Figma와 비교했을 때 단축키나 세부 기능 면에서 부족한 부분이 있다고 한다. 예를 들어 데스크톱에서 scale 기능을 위한 k 단축키 같은 기본적인 요청도 아직 남아 있다는 이야기다. 즉, 가능성은 크지만 아직 완성형 도구라고 보기는 어렵다.
그럼에도 불구하고 글쓴이는 지금이야말로 AI-native하게 일하는 법을 익혀야 할 시점이라고 말한다. 자신이 초기 Ramp 시절에도 빠르게 제품을 만들며 일했지만, 지금의 Paper, Claude, Codex와 함께하는 속도는 그때와는 차원이 다르다고 느낀다고 한다. 도구의 발전이 단순히 몇 시간을 절약하는 수준이 아니라, 제품을 구상하고 만들고 수정하는 방식 자체를 바꾸고 있다는 뜻이다. 그래서 그는 지금 이 흐름을 놓치지 말아야 한다고 강조한다. 실제로 Paper가 Ramp의 SaaS 리포트에서 연이어 주목받는 벤더로 등장한 점도 이런 분위기를 보여 주는 사례로 제시된다.