AI가 디자인을 대신하는 게 아니라, 디자인팀의 작업 환경을 바꾸고 있다

AI가 디자인을 대신한다는 말은 너무 단순합니다. YC 디자인 총괄 Eve Bouffard가 소개한 작업은 AI가 디자이너의 자리를 빼앗는 장면보다, 디자이너가 생각한 것을 구현하고 확장하는 비용이 낮아지는 장면에 가깝습니다.

그는 Conductor와 Paper Design 안에서 제품을 만들고, 음성으로 생각을 입력하고, Claude와 Codex 같은 코딩 에이전트에게 셰이더와 브랜딩 도구를 만들게 합니다. 이 과정에서 디자인은 더 이상 한 번 만든 화면으로 끝나지 않습니다. 제품, 랜딩 페이지, 소셜 카드, 행사장 스크린까지 같은 시각적 규칙을 공유하는 작업으로 넓어집니다.

요약

• Eve Bouffard는 Conductor, Paper Design, 음성 입력, 코딩 에이전트를 활용해 제품 디자인과 브랜딩 작업을 빠르게 반복하는 AI-first 워크플로를 소개합니다.
• Paxel, SOTA Zine, Startup School 사례를 통해 트랜스크립트, soul.md, 무드보드, 셰이더, 자동화 도구가 디자인 프로세스의 핵심 맥락이 되는 방식을 보여줍니다.
• 중요한 변화는 AI가 최종 결과물을 자동으로 만드는 것이 아니라, 디자이너가 더 많은 실험을 하고 하나의 디자인 언어를 여러 환경으로 확장할 수 있게 된다는 점입니다.

타이핑보다 빠르게 생각하는 사람을 위한 도구

영상의 첫 장면에서 Bouffard는 자신이 최근 거의 전적으로 Conductor와 Paper Design 안에서 작업한다고 말합니다. 시각적 영감이 필요할 때는 Pinterest로 작은 무드보드를 만들고, 실제 작업에서는 타이핑 대신 음성으로 생각을 설명합니다. 생각하는 속도가 타이핑하는 속도보다 빠르다는 것을 깨달았기 때문입니다. 00:24부터 보기

이 장면에서 중요한 것은 음성 입력이라는 기능 자체가 아닙니다. 디자인 도구가 결과물을 그리는 캔버스에서, 생각을 계속 외부화하고 바로 시험해보는 환경으로 변하고 있다는 점입니다. 디자이너는 완성된 명세서를 만든 뒤 실행하는 대신, 아직 정리되지 않은 의도를 말하고 결과를 보면서 다음 지시를 만들 수 있습니다.

Paxel은 코딩을 위한 Spotify Wrapped다

Paxel은 사람들이 코딩 에이전트를 어떻게 사용하고 있는지 이해하기 위해 만든 프로젝트입니다. Codex, Claude, Cursor의 트랜스크립트를 읽어 모델 선호, 한밤중의 커밋 패턴, 플랜 모드 사용 여부, 자주 쓰는 프롬프트를 분석합니다. 에이전트를 사용하다 가장 크게 좌절한 순간까지 보여주려는 발상은 Spotify Wrapped의 문법에서 출발했습니다. 01:25부터 보기

이 프로젝트가 흥미로운 이유는 AI 사용 기록을 단순한 로그로 보지 않기 때문입니다. 사용자는 자신이 어떤 모델을 좋아하는지뿐 아니라, 어디에서 막히고 어떤 방식으로 문제를 풀고 있는지를 되돌아볼 수 있습니다. AI 워크플로우가 팀의 개인적 습관으로만 남지 않고, 관찰하고 개선할 수 있는 디자인 대상이 됩니다.

에이전트에게 버그 리포트를 보내는 인터페이스

Paxel의 기능 요청 폼은 사용자가 팀에 티켓을 제출하는 기존 방식과 다릅니다. 사용자는 에이전트에게 말하듯 문제를 설명하고, 화면 녹화나 스크린샷을 첨부합니다. 그러면 에이전트가 작업을 실행하고 Pull Request를 열며, 팀은 그 결과를 검토해 병합할지 결정합니다. 08:30부터 보기

여기서 인터페이스의 변화는 버튼 이름에만 있지 않습니다. 사용자는 더 이상 문제를 정해진 티켓 형식으로 번역하지 않아도 됩니다. 대신 제품을 사용하는 과정에서 발견한 맥락을 그대로 전달하고, 에이전트가 실행 가능한 변경으로 바꿉니다.

다만 이 방식이 작동하려면 마지막에 사람의 검토가 남아 있어야 합니다. 에이전트가 PR을 여는 것과 제품에 변경을 반영하는 것은 다른 단계입니다. 생성 속도가 빨라질수록 무엇을 병합하지 않을지 결정하는 품질 게이트가 중요해집니다.

디자인의 맥락은 파일이 된다

SOTA Zine 프로젝트에서는 의도적으로 AI를 그래픽 디자인에 참여시키지 않았습니다. Illustrator에서 사람이 직접 만든 물리적인 진을 통해, 사람이 공들여 만든 결과물의 감각을 남기고 싶었기 때문입니다. 동시에 프로젝트의 회의 내용은 빠짐없이 기록해 soul.md라는 프로젝트 문서에 넣었습니다. 12:51부터 보기

soul.md는 단순한 회의록이 아닙니다. 프로젝트에서 나눈 대화, 선언문, 판단의 배경을 모아 에이전트가 참고할 수 있는 단일한 맥락 저장소로 사용됩니다. Bouffard는 요약된 메모만 남기기보다 가능한 한 많은 대화와 생각을 포착하라고 설명합니다. 14:32부터 보기

이 방식은 AI에게 좋은 프롬프트를 한 번 잘 쓰는 것보다 오래 갑니다. 에이전트가 매번 빈 화면에서 시작하지 않고, 프로젝트가 무엇을 중요하게 여기는지에 접근할 수 있기 때문입니다. 디자인 파일이 결과물의 저장소라면 soul.md는 판단과 맥락의 저장소입니다.

“디자인해줘” 대신 기준을 전달해야 한다

에이전트가 사람을 놀라게 하는 결과를 내놓은 사례도 나옵니다. Bouffard는 샌프란시스코의 실제 지도를 인터랙티브한 SF 지도처럼 표현했고, 그 과정에서 design.md, soul.md, 스크린샷, 무드보드를 함께 제공했습니다. 20:04부터 보기

그가 경고하는 실패 방식은 간단합니다. “디자인해줘”라고만 말하면 평범한 결과가 나옵니다. 반대로 좋아하는 웹사이트를 모아두고, 원하는 분위기와 피해야 할 것까지 설명하면 에이전트는 여러 레퍼런스의 공통 패턴을 찾아 결과에 반영할 수 있습니다.

결과의 품질은 프롬프트의 문장력만으로 결정되지 않습니다. 어떤 화면을 좋아하는지, 어떤 사례를 싫어하는지, 이 프로젝트가 지키려는 감각이 무엇인지가 함께 전달되어야 합니다. 디자인 시스템이 토큰과 컴포넌트만의 체계가 아니라, 취향과 판단의 기록까지 포함하는 체계가 되는 셈입니다.

브랜딩은 한 장의 키비주얼이 아니라 파라미터가 된다

Startup School 2026 브랜딩에서 팀은 YC다운 인상을 유지하면서도 기존 브랜딩의 반복처럼 보이지 않는 변주를 시도했습니다. 오렌지 그라디언트와 Paper Shaders를 활용했고, 연사 카드가 추가될 때마다 같은 규칙 안에서 새로운 변형이 나오도록 자동화했습니다. 25:14부터 보기

연사 카드 작업은 특히 기존 디자인 실무와 다릅니다. 연사가 늘어날 때마다 같은 배치를 손으로 반복하는 대신, Claude에게 템플릿을 만들게 하고 받은편지함에서 이미지를 가져오는 작업까지 연결했습니다. 셰이더의 입자감, 가장자리, 회전, 스케일을 조정하는 작은 도구와 고해상도 결과물을 얻기 위한 화면 녹화 도구도 직접 만들었습니다. 26:31부터 보기

이렇게 보면 브랜딩의 단위가 바뀝니다. 예전에는 로고, 색상, 키비주얼, 적용 가이드가 중심이었다면, 이제는 여러 환경에서 같은 인상을 재생산할 수 있는 규칙과 파라미터가 중요해집니다. 행사장 스크린과 소셜 카드가 같은 디자인 논리를 공유할 수 있는 이유입니다. 29:41부터 보기

추가 리서치: soul.md는 무엇을 저장하는가

영상에서 말하는 soul.md는 특정 제품의 공식 표준명이라기보다, 프로젝트가 중요하게 여기는 감각과 판단의 맥락을 에이전트가 계속 참고하도록 만든 문서에 가깝습니다. 즉 design.md가 “무엇을 만들고 어떻게 구현할지”를 설명한다면, soul.md는 “왜 이 프로젝트가 이런 선택을 해야 하는지”를 보존하는 층입니다.

최근 공개된 Soul.md Standard 초안은 이 이름을 에이전트의 페르소나를 정의하는 선언적 문서로 정리합니다. 정체성, 목소리, 상호작용 방식, 의사결정, 안전 기준을 도구나 코드와 분리해 기록하고, 여러 실행 환경에서 재사용할 수 있게 하자는 제안입니다. 아직 RFC 초안이고 모든 에이전트가 지원하는 표준은 아니지만, 영상 속 soul.md를 이해하는 데 유용한 구분을 제공합니다.

이 둘을 디자인팀의 언어로 번역하면 다음과 같습니다.

• 결과물: 화면, 브랜드 그래픽, 셰이더, 코드
• 운영 규칙: 파일 구조, 기술 스택, 검토 절차, 배포 방식
• 프로젝트의 영혼: 지키려는 인상, 타협하지 않을 것, 싫어하는 레퍼런스, 판단의 이유

좋은 soul.md는 “세련되게 만들어줘”처럼 평가할 수 없는 형용사를 늘어놓는 문서가 아닙니다. 예를 들어 “차갑지만 위협적이지 않아야 한다”, “기술적이어도 개발자 도구처럼 보이면 안 된다”, “반복되는 그래픽 안에서 각각의 연사가 구별되어야 한다”처럼 결과를 보고 맞고 틀림을 판단할 수 있는 문장으로 써야 합니다. 더 중요한 것은 성공한 취향만이 아니라 실패한 시도와 그 이유도 남기는 일입니다.

다만 soul.md를 만능 컨텍스트 파일로 오해하면 안 됩니다. 페르소나와 미감의 기준을 담는 문서가 요구사항, 사실 데이터, 접근 권한, 테스트를 대신할 수는 없습니다. 에이전트가 맥락을 읽는다고 해서 그 판단이 자동으로 옳아지는 것도 아닙니다. soul.md는 디자이너의 판단을 대체하는 파일이 아니라, 판단을 반복해서 전달하고 검토할 수 있게 만드는 인터페이스에 가깝습니다.

실무에서는 프로젝트 시작 때 한 번 쓰고 끝내기보다, 다음 네 가지를 계속 갱신하는 편이 유용합니다.

1. 우리가 만들려는 인상 — 세 문장 안에서 설명할 수 있는 기준
2. 절대 하지 않을 것 — 자주 나오는 평범한 결과와 금지할 패턴
3. 판단 사례 — 좋은 결과와 나쁜 결과, 그리고 그 차이를 만든 이유
4. 다음 에이전트가 물어야 할 질문 — 맥락이 부족할 때 확인해야 하는 것

이렇게 관리하면 soul.md는 프롬프트 모음이 아니라 팀의 미감과 판단을 축적하는 작은 디자인 시스템이 됩니다.

crit의 관점: 구현이 싸질수록 기준의 설계가 비싸진다

이 영상의 장점은 AI를 추상적인 미래가 아니라 실제 작업물의 연속으로 보여준다는 데 있습니다. Paxel에서는 코딩 세션을 관찰하고, SOTA Zine에서는 AI를 의도적으로 배제하고, Startup School에서는 에이전트를 사용해 브랜드를 확장합니다. “AI를 써야 한다”는 하나의 결론보다, 프로젝트의 목적에 따라 AI의 역할을 다르게 배치하는 장면이 남습니다.

특히 인상적인 것은 AI가 만든 결과보다 AI에게 전달한 맥락입니다. 음성으로 빠르게 생각을 전달하고, 무드보드와 스크린샷을 제공하고, 회의와 판단을 soul.md에 축적하는 일은 모두 에이전트의 실행력보다 먼저 필요한 작업입니다. 자동화 이전에 조직의 기억과 기준을 만드는 셈입니다.

다만 이 사례를 일반적인 디자인팀의 표준 워크플로우로 바로 받아들이기는 어렵습니다. YC처럼 기술적 실험을 빠르게 수용할 수 있는 조직, 제품과 브랜딩을 함께 다룰 수 있는 디자이너, 에이전트가 코드를 실행하고 PR을 열 수 있는 개발 환경이 전제되어 있습니다. 또한 영상은 성공한 결과를 중심으로 보여주기 때문에, 에이전트가 맥락을 잘못 해석했을 때의 비용과 실패율은 충분히 드러나지 않습니다.

가장 큰 긴장은 여기에 있습니다. 에이전트가 더 많은 결과물을 만들어낼수록 디자이너는 더 적게 만들고 더 많이 판단해야 합니다. 그런데 그 판단 기준이 문서화되어 있지 않으면, 빠른 생성은 평범한 결과물을 더 많이 생산하는 능력으로 끝날 수 있습니다.

AI 디자인 워크플로우에서 새로운 경쟁력은 “얼마나 잘 만들 수 있는가”만이 아닙니다. 무엇을 만들고 싶은지 설명할 수 있는가, 결과를 보고 무엇이 어긋났는지 말할 수 있는가, 그 판단을 다음 작업에 다시 사용할 수 있는 형태로 남길 수 있는가가 중요해집니다.

질문

• 팀의 soul.md에는 회의록 외에 어떤 판단과 실패를 남겨야 할까요?
• AI가 만든 결과물을 평가하는 디자이너의 기준은 어떻게 팀의 공용 언어가 될 수 있을까요?
• 브랜딩이 파라미터와 코드로 확장될 때, 일관성과 반복 사이의 경계는 어디에 있을까요?
• 더 빠르게 만드는 능력과 더 좋은 것을 고르는 능력 중, AI 시대에 더 희소한 것은 무엇일까요?

원본 영상

YouTube에서 전체 영상 보기