How to Design in the Agent Era

Chapter 1 · 해설: 와우멘토

How to Design in the Agent Era

A WOW Mentor strategy teardown.

오늘 와우멘토가 해부할 주제는 '에이전트 시대의 디자인'입니다. 무대에 선 인물은 AI 네이티브 디자인 도구 페이퍼(Paper)를 만든 스티븐 헤이니입니다. 그는 도입부에서 이렇게 말합니다. 에이전트는 당신의 속도를 높여 주고, 많은 수고를 덜어 주며, 번역이나 크기 조정 같은 작업을 대신 처리해 줄 수 있다고요. 그러나 곧바로 방향을 틀어, 자신들은 디자인에서 '인간이라는 요소'를 굳게 믿는 사람들이라고 못을 박습니다. 그래서 만들려는 것은 인간을 밀어내는 도구가 아니라, 인간이 에이전트와 함께 정말 빠르게 일하도록 돕는 도구라는 것입니다. 와우멘토가 이 첫 문장에서 주목하는 지점은, 그가 '에이전트가 무엇을 할 수 있는가'가 아니라 '그럼에도 인간이 왜 남아야 하는가'에서부터 이야기를 시작한다는 사실입니다. 도구를 파는 사람이 도구의 한계를 먼저 인정하는 이 순서 자체가, 그가 시장을 어떻게 설득해 왔는지를 압축해 보여 줍니다. 그가 페이퍼를 설명하는 방식은 단순합니다. 페이퍼는 디자인 도구인데, '에이전트 네이티브' 디자인 도구라는 것입니다. 그 말의 실체는 렌더링 엔진에 있습니다. 대부분의 디자인 도구가 자체 렌더링 엔진을 쓰는 것과 달리, 페이퍼는 HTML과 CSS를 실제 렌더링 엔진으로 사용합니다. 그는 이 선택이 왜 중요한지를 기술의 언어로 풀어냅니다. 에이전트는 HTML과 CSS를 아주 잘 이해하고, 그 언어는 이미 모델의 학습 데이터 안에 들어 있기 때문입니다. 반대로 자체 렌더링 엔진을 쓰는 도구는 에이전트가 다루기가 훨씬 어렵고, 그 결과 토큰 소모가 커지고 속도가 느려지며 정확도가 떨어진다고 그는 지적합니다. 와우멘토가 여기서 강조하고 싶은 것은, 이것이 단순한 기술 자랑이 아니라는 점입니다. 그는 남들과 같은 캔버스를 만들면서 렌더링 방식만 바꾼 것이 아니라, '에이전트가 이미 아는 언어로 그림을 그린다'는 하나의 전략적 결정을 내렸고, 그 결정이 속도와 비용과 정확도라는 세 개의 축을 동시에 움직였습니다. 흥미로운 반전은 이 선택의 원래 목적이 에이전트가 아니었다는 데 있습니다. 그는 페이퍼가 사랑에서 태어났다고 말합니다. 처음에는 혼자 시작한 창업자였고, 페이퍼는 그저 계속 굴러가던 사이드 프로젝트였습니다. '아무도 페이퍼에 관심을 갖지 않으면 어쩌나' 싶던 달도 있었지만, 어느 순간 사람들이 정말로 좋아하기 시작했다고 그는 회상합니다. 그가 반복해서 쓰는 표현은 '어차피 할 일이었다'입니다. 창업은 시장이나 경쟁자보다 먼저, 자신이 어차피 매일 하고 싶은 일, 다시 말해 '창업자와 시장의 궁합'이 가장 강한 자리에서 출발해야 한다는 것입니다. 그는 창의적인 도구를 만드는 일이라면 나쁜 하루를 보낼 일이 없다고까지 말합니다. 그런 그가 주위를 둘러보니, 디자인을 이야기할 때 피그마를 빼놓을 수 없을 만큼 피그마는 거대한 기업이 되어 있었습니다. 그러나 피그마가 대기업과 엔터프라이즈로 무게중심을 옮기는 사이, 그는 '디자이너 그 자체에 집중하는 새 도구가 나올 때가 되지 않았나'라고 물었습니다. 와우멘토가 이 대목에서 짚는 전략은, 거인이 위로 올라갈 때 비는 자리가 바로 신생 도구의 기회라는 오래된 진실입니다. HTML과 CSS를 택한 진짜 이유도 여기서 드러납니다. 그는 원래 디자이너와 개발자 사이의 '핸드오프'를 개선하려고 이 방식을 골랐다고 말합니다. 디자이너가 피그마나 스케치처럼 제약 없이 자유롭게 그리되, 그 결과물이 사실은 HTML이라면 개발 인계가 훨씬 나아질 것이라는 발상이었습니다. 그런데 여기서 그가 발견한 것이 핵심입니다. 인간을 위한 훌륭한 핸드오프를 만들었더니, 그것이 곧 에이전트를 위한 훌륭한 핸드오프이기도 했다는 것입니다. 에이전트에게 페이퍼 파일을 다루라고 하면, 그것은 말 그대로 CSS를 읽어 내는 일이고 에이전트는 무엇을 해야 할지 정확히 압니다. 그래서 그는 페이퍼를 '에이전트를 확장하는 시각적 인터페이스'라고 부릅니다. 프롬프트가 언제나 최선의 입력 수단은 아니며, 때로는 끌어다 놓고 직접 그리는 편이 더 빠르기 때문입니다. 영업 담당자도, 엔지니어도, 온갖 사람이 페이퍼를 쓰는 이유가 여기 있다고 그는 설명합니다. 와우멘토가 주목하는 지점은, 그가 '디자인 도구'라는 좁은 정의에 스스로를 가두지 않고 '에이전트와 대화하는 시각적 방식'이라는 더 큰 범주로 제품을 재정의했다는 점입니다.

셰이더와 폰트에 관한 대목은 이 회사의 성격을 가장 잘 드러냅니다. 페이퍼는 브라우저로 렌더링하기 때문에 셰이더, 곧 WebGL 애니메이션을 아주 쉽게 그려 냅니다. 페이퍼 셰이더스라는 오픈소스 라이브러리는 하프톤 도트나 뉴로 노이즈, 블렌딩 모드 같은 효과를 자유롭게 조합하게 해 주고, 브랜드 디자이너들이 특히 사랑한다고 그는 말합니다. 놀라운 것은 그들이 실제 종이의 무작위한 질감을 연구해 코드로 모델링했다는 대목입니다. 그는 '터무니없을 정도로' 완성도를 높이는 것이 라이브러리가 돋보이는 이유라고 말합니다. 그런데 그가 이 셰이더 라이브러리를 무엇이라 부르는지가 결정적입니다. 그것은 제품 개발이 아니라 '마케팅 예산'입니다. 광고를 사는 대신 세상에 쓸모 있는 라이브러리를 만들자는 것이고, 그것이 광고보다 훨씬 잘 작동한다는 것입니다. 쿼터라는 팀이 만드는 레트로 감성의 실적 발표 포스터가 이제 페이퍼로 제작된다는 사례, YC의 스타트업 스쿨에서 디자인을 이끄는 이가 합격자 이름을 넣은 맞춤 애니메이션 셰이더 티켓을 만들어 보내 준다는 사례처럼, 셰이더는 '공유하고 싶어지는 특별함'을 값싸게 만들어 냅니다. 곧 출시할 모노 폰트 '페이퍼 모노'도 같은 논리입니다. 터미널용이 아니라 마케팅에도 코드에도 두루 쓸 수 있는 만능 모노 폰트가 없기에 직접 만들었고, 숫자의 가독성에 특히 공을 들였습니다. 뉴욕의 어느 저녁 식사 자리에서 팀원이 페이퍼 모노 티셔츠를 입은 낯선 이를 마주쳤다는 일화를, 그는 세상에 백 장 남짓밖에 없는 그 셔츠가 이미 돌고 있다는 사실에 즐거워하며 들려줍니다. 여기에 더해 그는 잘 알려지지 않은 이미지 생성 기능도 보여 줍니다. '달을 바라보는 사려 깊은 남자' 같은 한 줄만 넣어도 네 개의 모델이 동시에 그림을 뽑아내는 '버라이어티 팩'으로 가능성의 공간을 빠르게 훑고, 만들어진 이미지에서 색을 추출하거나 벡터로 바꾸거나 셰이더를 다시 이미지로 먹여 더 화려하게 만드는 식으로 워크플로를 자유롭게 잇습니다. 와우멘토가 해석하는 이 전략의 본질은, 마케팅과 제품을 분리하지 않고 '세상에 선물을 만들어 던지는 행위' 자체를 성장 엔진으로 삼았다는 데 있습니다. 핸드오프 이야기는 곧 새로운 작업 스택으로 이어집니다. 페이퍼 안의 모든 것은 코드이기 때문에, 셰이더든 프레임이든 우클릭으로 리액트나 테일윈드 코드로 복사해 그대로 배포할 수 있습니다. 그런데 그가 결정적 순간으로 꼽는 것은 따로 있습니다. 2025년 12월, 이른바 클로드 코드의 폭발이 일어난 때입니다. 디자이너가 터미널에 들어갈 것이라고는 상상도 못 했다고 그는 말합니다. 그러나 그런 일이 실제로 벌어졌고, 그래서 데스크톱 앱으로 서둘러 넘어가야 했습니다. 디자이너들이 로컬 저장소를 갖고 깃허브를 배우기 시작한 흐름에 올라타야 했던 것입니다. 그가 그리는 새로운 에이전트 스택은 이렇습니다. 커서와 클로드 코드 같은 여러 에이전트가 있고, 페이퍼가 그 에이전트들과 소통하는 시각적 통로가 되며, 깃허브나 코드 리뷰가 그 뒤를 받칩니다. 그는 커서와 클로드 코드처럼 흩어진 에이전트들이 컨덕터 같은 앱으로 점점 통합되는 흐름도 짚습니다. 코드를 밀어 넣고 병합하는 일을 한 앱에서 처리하게 되면서, 스택이 여러 개의 분리된 도구가 아니라 하나로 뭉쳐 간다는 것입니다. 페이퍼와 컨덕터를 함께 쓰는 조합이 커뮤니티에서 자리 잡았다는 사실을 그는 즐거워합니다. 페이퍼는 데스크톱 앱에 MCP 서버를 심었고, 에이전트는 '어떤 폰트를 쓸 수 있나, 이 페이지의 기본 설정은 무엇인가' 같은 도구 호출을 거쳐 곧장 HTML을 씁니다. 에이전트가 HTML을 쓰고 페이퍼가 HTML을 렌더링하니 그 사이에 어떤 변환도 없습니다. 디자인에서 코드로, 코드에서 디자인으로 양방향이 열린다는 점도 그는 강조합니다. 실제 코드베이스의 colors.css를 페이퍼 캔버스에 스타일 가이드로 그려 내거나, 컴포넌트 아키텍처와 다이어그램을 만들어 코드베이스를 감사하는 식으로 말입니다. 그 결과가 바로 토큰 절약, 속도, 그리고 줄어든 환각입니다. 와우멘토가 주목하는 것은, 포맷을 오가지 않는다는 이 단순한 사실 하나가 제품이 도약한 순간의 핵심이었다는 점입니다. 여기서 그는 오래된 핸드오프의 근본 병폐를 짚습니다. 디자이너가 무언가를 그려 개발자에게 넘기면, 원래 의도대로 만들어지지 않거나, 만들어졌더라도 코드가 진화하면서 디자인과 어긋나 버립니다. 그러면 무엇이 진실의 원천인가 하는 질문이 남습니다. 페이퍼의 답은 명확합니다. 코드가 진실의 원천이고, 디자인 도구와 코드 양쪽이 같은 코드베이스 위에서 작동한다는 것입니다. 그는 수많은 팀이 디자인 시스템을 두 벌로 유지하는 현실을 지적합니다. 둘을 계속 동기화하는 것은 사실상 풀 수 없는 문제이며, 유지 비용과 정확도 문제를 동시에 낳습니다. 그래서 더 애자일하게 움직이는 신생 기업들은 코드베이스를 유일한 진실의 원천으로 다룹니다. 페이퍼에는 아직 컴포넌트 기능이 없고 이는 흔한 불만이지만, 그는 역설적인 논리를 폅니다. 코드베이스가 진실의 원천이므로 필요할 때 필요한 것을 '불러오면' 되기 때문에, 컴포넌트가 반드시 있어야 하는 것은 아니라는 것입니다. 크롬 확장인 페이퍼 스냅샷은 라이브 사이트의 실제 섹션을 스크린샷이 아니라 편집 가능한 레이어로 캔버스에 끌어옵니다. 사용자가 실제로 보고 있는 화면에서 출발해 그 위에 쌓아 올리고 반복하는, 가장 현실적인 시작점을 만들어 준다는 것입니다. 다듬은 결과물을 되돌릴 때도 방법은 단순합니다. 리액트로 복사해 IDE에 붙여 넣을 수도 있지만, 그냥 에이전트에게 '이 선택 영역을 코드베이스의 새 컴포넌트로 만들어 달라'고 말하면, 에이전트가 기존 코딩 관습과 규칙에 맞춰 그대로 반영해 줍니다. 이미 컴포넌트로 존재한다면 그것을 갱신할 뿐입니다. 그래서 이제는 인계라는 단계조차 사라지고, 한 사람이 바꾸고 반복하고 배포하는 하나의 고리만 남았다고 그는 말합니다. 와우멘토가 해부하는 이 사고의 전환은, '어느 쪽을 진실로 볼 것인가'라는 질문에 대한 답이 도구 전체의 구조를 결정한다는 통찰입니다. 가장 실전적인 대목은 모델의 결과물에서 'AI 티'를 걷어내는 방법입니다. 그는 아주 구체적인 규칙 몇 가지를 공유합니다. 첫째, 모델은 볼드체를 사랑합니다. 그러니 폰트 굵기를 가능한 한 가볍게 끌어내리라는 것입니다. 그것만으로 마법처럼 더 디자인된 것처럼 보입니다. 실제 시연에서 그는 새까만 헤드라인의 굵기를 한 단계만 낮춰도 화면이 즉시 더 정돈되고 다가가기 쉬워진다는 것을 보여 줍니다. 둘째, 모델은 대여섯, 일고여덟 종류의 폰트 크기를 남발합니다. 세 종류로 줄이라는 것입니다. 크기가 세 종류로 수렴하는 순간 화면이 훨씬 낫게 보인다고 그는 말합니다. 셋째, 모델은 대비를 자주 망칩니다. 텍스트가 정말 읽히는지 점검하고, 보조 요소일 뿐인데 너무 튀는 것들은 톤을 낮추라는 것입니다. 그리고 그가 반복해서 강조하는 원칙이 있습니다. '디자인의 상당 부분은 삭제하는 일'이라는 것입니다. 모델은 불안한 디자이너처럼 구석을 채우려 들고, 아무 의미 없는 작은 숫자와 아이콘을 흩뿌립니다. 그는 그것을 '불안한 에이전트'라 부릅니다. 카드 모서리를 채우려고 무의미한 일, 이 같은 잔숫자를 흩뿌리지만, 정작 그것이 무언가를 전달하느냐고 물으면 답은 '아니오'입니다. 아니라면 지우면 된다는 것입니다. 페이퍼에서는 요소를 지우면 나머지가 곧바로 제자리로 붙기 때문에 빈자리가 남지 않습니다. 모델이 뱉은 화면에서 헤드라인 하나를 고치려고 일일이 설명하고 다시 프롬프트해야 하는 대신, 그냥 선택해서 삭제 버튼을 누르면 모든 것이 제자리로 스냅되는 이 감각을, 그는 '훨씬 더 큰 통제감'이라고 표현합니다. 와우멘토가 짚는 핵심은, 좋은 디자인이 '더하는 재능'이 아니라 '덜어내는 판단'에서 나온다는 점, 그리고 그 판단을 빠르게 실행하게 해 주는 도구가 속도와 품질의 타협을 없앤다는 점입니다.

… The rest of this chapter continues in the full edition, available with a subscription.

Listen to this chapter