buzzvilbuzzvil:tech
← Blog
AI 네이티브 디자인 플레이북
designdesign-systemaiworkflowclaude-codemonorepo

AI 네이티브 디자인 플레이북

Maxence Mauduit
Maxence Mauduit

Product Lead - Head of Design

이 글은 영문 원본을 바탕으로 작성되었습니다.

지난 한 달간, 버즈빌 디자인 팀은 단 6명으로 5개의 웹 애플리케이션을 배포하고 344건의 커밋을 기록했습니다. 놀랍게도 이 과정에서 Figma는 거의 사용되지 않았습니다. 엔지니어링 스프린트 할당도, 핸드오프 티켓도, 지루한 대기 시간도 없었습니다. 제가 Figma에 쓰는 시간 자체도 이전의 10% 수준으로 줄어들었습니다.

이 글은 저희가 어떻게 여기까지 왔는지에 대한 기록입니다. 곧 저희와 같은 벽에 부딪힐 프로덕트 팀, 디자이너, PM, 엔지니어를 위해 썼습니다. 목업과 핸드오프로 이어지는 기존의 루프는 이제 시스템에서 가장 느린 구간이 되었고, 그 루프를 지탱하던 도구들은 새로운 시대의 속도에 맞지 않게 되었습니다.

왜 예전 루프는 무너졌나

Anthropic의 디자인 책임자인 제니 웬(Jenny Wen, 전 Figma 디자인 디렉터)은 2026년 3월 Lenny's Podcast에서 이렇게 말했습니다.

"엔지니어가 코딩 에이전트 7개를 동시에 돌리며 디자이너가 옵션을 탐색하기도 전에 동작하는 버전을 내놓는 상황에서는, 전통적인 '탐색-발산-수렴' 루프는 더 이상 통하지 않습니다." 1

실제 데이터가 이를 뒷받침합니다(2025-2026년 기준).

  • GitHub에 커밋된 코드의 51%가 AI에 의해 생성되거나 보조를 받았습니다. 2
  • AI 보조를 받는 엔지니어는 1인당 태스크 완료율이 21% 증가했고, PR 생성 건수는 98% 급증했습니다. 3
  • PR 크기 중앙값은 33% 커졌으며, PR 리뷰 시간은 91%나 늘어났습니다. 3

엔지니어가 이토록 빠르게 움직이면, "디자이너가 목업을 다 그려야 만들 수 있다"는 전제 위에 돌아가는 모든 단계가 병목이 됩니다. Anthropic 팀에서는 디자이너의 시간 배분이 실시간으로 뒤집히는 현상을 관찰했습니다.

작업 유형과거현재 (AI-Native)
목업 및 프로토타이핑60-70%30-40%
엔지니어와 페어링 (Jamming)약 20%30-40%
커뮤니케이션 및 조율약 10%(점점 축소)
코드에서 직접 구현0%새로 생긴 영역

디자이너의 시간은 이제 두 가지 새로운 모드로 옮겨갔습니다. 하나는 실행 지원(엔지니어가 만드는 동안 자문하고, 피드백을 주고, 코드에서 직접 다듬는 일)이며, 다른 하나는 단기 비전 설정(수년 단위의 로드맵 대신 3~6개월 단위의 전략)입니다. 1

버즈빌은 여기서 한 걸음 더 나아갔습니다. 저는 이제 목업을 만들지 않습니다. 대신 유저 스토리를 씁니다. 종이든 텍스트 파일이든 상관없습니다. 제품의 의도, 제약 조건, 성공 기준을 명확히 서술합니다. 그다음 Claude Code로 직접 코드를 짜거나 에이전트에게 작업을 맡깁니다.

픽셀 단위의 정교함에 쏟던 시간은 이제 "무엇이 왜 존재해야 하는가"를 깊게 고민하는 데 쓰입니다. 시각적 결과물은 이전보다 훨씬 빠르게, 프로덕션에 가까운 형태로 도출됩니다. 창의적 작업의 무게 중심이 '제작'에서 '기획 상류(잘 쓰인 유저 스토리, 날카로운 제약 설정, 덜어낼 것에 대한 결정)'로 이동한 것입니다.

이렇게 일하는 디자이너 한 명은 과거 디자이너와 프론트엔드 엔지니어가 한 스프린트 내내 매달려야 했던 결과물을 뽑아냅니다. 이제 질문은 "만들 수 있는가?"가 아니라 **"만들어야 하는가?"**로 바뀌었습니다.

"AI 디자인은 다 비슷비슷하지 않나요?"

가장 자주 나오는 우려입니다. 2025년 초반까지는 사실이었습니다. 제어되지 않은 LLM은 학습한 모든 데이터의 통계적 평균으로 수렴하기 때문입니다. 의도가 모호하면 모델은 가장 흔한 레이아웃과 뻔한 스타일로 빈 곳을 채웁니다.

해법은 잘 짜인 환경을 갖추는 것, 이른바 **'하네싱(Harnessing)'**입니다. design.md 같은 도구는 브랜드 보이스, 비주얼 언어, 컴포넌트 제약 등을 에이전트의 컨텍스트에 직접 인코딩할 수 있음을 보여주었습니다. CLAUDE.md 파일, 디자인 스킬, 훅이 결합될 때, 에이전트는 비로소 브랜드에 맞는 결과물을 만들어내는 디자인 환경을 구축하게 됩니다.

버즈빌에서는 다음 요소들을 실제 서비스에 배포하여 사용 중입니다.

  • 브랜드와 디자인 스킬: 비주얼 언어(브랜드 가이드라인, OKLCH 컬러 시스템 등)를 인코딩하여 생성 과정에서 이를 강제하는 Claude Code 전용 스킬입니다.
  • LLM 전용 내부 UI 라이브러리: @buzzvil/design-library는 에이전트가 올바른 토큰과 컴포넌트를 정확히 조합할 수 있도록 구조화되어 있습니다. 현재 5개 이상의 레포에서 사용 중이며, 60개의 브랜드×레시피 조합에 대해 검증되었습니다.
  • 일관성 강제 훅(Hooks): Biome 린트, 여백 컨벤션 등을 체크합니다. 하드코딩된 색상값은 커밋되기도 전에 시스템에서 차단됩니다.

준비된 환경 없이 AI를 활용하는 디자이너는 평범한 결과물을 얻을 뿐입니다. 이제 디자이너의 새로운 본업은 환경을 설계하는 일입니다. 제약을 정하고 브랜드를 인코딩하면, AI는 비로소 여러분의 디자인을 만들어냅니다.

디스커버리와 딜리버리의 명확한 분리

오랫동안 디자인에서 디스커버리와 딜리버리는 같은 도구 안에 있었습니다. Figma에서 탐색하고, Figma에서 발표하고, Figma에서 핸드오프했습니다. 의도는 바뀌어도 도구는 그대로였습니다. 그래서 두 모드가 구분되어 보이지 않았습니다.

AI 코딩 에이전트는 이 두 모드를 선명하게 드러냅니다. 디자이너가 몇 시간 만에 동작하는 프로토타입을 만들 수 있게 되면 질문이 바뀝니다. "이건 어떤 Figma 파일이지?"가 아니라 **"내가 지금 탐색 중인가, 배포 중인가?"**라고 말입니다.

마티 케이건(Marty Cagan)은 이 경계를 선명하게 긋습니다. 디스커버리는 **'배우기 위해 만드는 일(Building to Learn)'**이며, 딜리버리는 **'성과를 내기 위해 만드는 일(Building to Earn)'**입니다. 4 디스커버리는 네 가지 리스크를 검증합니다. 가치(value), 사용성(usability), 실현 가능성(feasibility), 지속 가능성(viability)입니다. 딜리버리는 확장성, 성능, 신뢰성, 보안, 그리고 고객이 믿고 쓸 수 있는 프로덕트에 필요한 모든 것을 검증합니다. 같은 "검증"이라는 단어를 쓰지만 양쪽의 의미는 완전히 다릅니다. 과거에는 제작 비용이 컸기에 이 구분이 주로 PM의 영역이었으나, 이제는 에이전트를 쓰는 디자이너가 몇 시간 만에 동작하는 프로토타입을 만들 수 있게 되면서, 디스커버리 루프가 만드는 사람 누구에게나 열렸습니다.

디스커버리: 학습을 위한 빌딩

디스커버리 산출물은 일회용입니다. 배포가 목적이 아니라 질문에 답하는 것이 목적이므로, 가치를 검증하다 실패한 프로토타입도 제 역할을 다한 것입니다. 잘못된 방향임을 분명히 해준 Figma 탐색도 몇 주를 아껴준 셈입니다.

Figma는 여전히 공간적 탐색에 적합한 도구입니다. 제니 웬이 지적하듯, 하나의 캔버스에 8-10개의 방향을 펼쳐놓고 동시에 비교할 수 있기 때문입니다. 코드 기반 도구는 선형적이고, 한 방향에 몰입해 매몰 비용 사고로 흐르기 쉽습니다. 1 여러 방향을 나란히 비교해야 할 때, 결정을 내리기 전에 이해관계자에게 옵션을 보여줘야 할 때, 브랜드나 비주얼 아이덴티티 작업을 탐색할 때 Figma를 쓰면 됩니다.

코드 프로토타입도 디스커버리 도구로 쓸 만해졌습니다. Claude Code로 빠르게 만든 프로토타입은, 실제 데이터, 실제 인터랙션, 실제 반응형 동작을 갖춘 채 몇 시간 안에 사용자 앞에 놓일 수 있습니다. 엔지니어링 티켓 없이도 말입니다.

딜리버리: 성과를 위한 빌딩

딜리버리는 방향이 이미 검증되었거나(또는 진행할 만큼의 신호가 있는) 상태를 전제합니다. 이 단계의 작업은 프로덕션 품질을 충족해야 합니다. 확장성, 신뢰성, 접근성, 토큰 준수, 반응형 동작 같은 것입니다.

딜리버리 루프는 이렇게 흘러갑니다.

  1. 의도를 쓴다. 검증된 방향을 유저 스토리, 제약 집합, 또는 "무엇이 왜 필요한가"에 대한 서술로 포착합니다. 종이도 됩니다. 마크다운 파일도 됩니다. 형식보다 정확함이 중요합니다.
  2. 코드로 만든다. Claude Code를 열고, 원하는 것을 설명하고, 마음에 들 때까지 반복합니다. 에이전트는 여러분의 토큰, 컴포넌트, 스탠딩 오더를 사용합니다.
  3. PR을 연다. 브랜치를 푸시하고, 무엇이 바뀌었는지 설명하고, 리뷰를 요청합니다.
  4. 리뷰하고 머지한다. 시각적 품질은 디자인 리뷰가, 정확성은 엔지니어링 리뷰가 담당합니다. 하나의 프로세스입니다.
  5. 배포한다. 머지하는 순간 Vercel이 배포합니다.

의도에서 프로덕션까지 전체 루프가 몇 시간 안에 끝날 수 있습니다. 디자이너가 직접 PR을 엽니다. 핸드오프는 없습니다.

딜리버리 단계에서는 Figma가 모든 면에서 잘못된 도구입니다. 컴포넌트 제작(토큰과 코드가 진실의 원천입니다), 페이지 레이아웃(직접 만드는 편이 빠릅니다), 스펙 핸드오프(디자이너가 PR을 엽니다), 반응형 디자인(캔버스에서는 반응형을 흉내 낼 수 없습니다) 모두 해당됩니다.

다섯 층의 하네스

AI 코딩 에이전트는 빠르고 지칠 줄 모르는 주니어 개발자처럼 동작합니다. 재능은 있지만 구조가 필요합니다. SmartScope의 조사에 따르면, 에이전트 컨텍스트 파일을 잘 구조화한 프로젝트는 중앙값 기준 실행 시간이 29% 줄고, 토큰 소비량이 17% 줄어든다고 합니다. 5

저희는 다섯 층을 운영합니다.

1. 스탠딩 오더(CLAUDE.md). 모든 레포의 루트에 두는 마크다운 파일입니다. 에이전트는 세션을 시작할 때마다 이 파일을 읽습니다. 프로젝트 맥락, 코딩 컨벤션, 패턴, 해야 할 일, 절대 하지 말아야 할 일, 파일 구조와 네이밍 규칙이 담깁니다. 여기에 컨벤션 하나를 인코딩해두면, 앞으로의 수정을 수백 번 아낄 수 있습니다.

2. 스킬(Skills). 반복되는 작업을 위한 재사용 가능한 플레이북입니다. 버즈빌에는 SDK 문서 배포, 브랜드 가이드라인 준수, 일러스트와 아이콘 생성, 대시보드 디자인 패턴, 블로그 포스트 작성을 위한 스킬이 있습니다. 스킬은 에이전트에게 특정 작업 범주를 어떻게 접근해야 하는지 알려줍니다. 누군가의 머릿속에만 있을 노하우를 밖으로 꺼내 인코딩하는 역할입니다.

3. 메모리(Memory). 에이전트가 세션 간에 유지하는 영속적인 노트입니다. 여러 번의 상호작용으로 확인된 패턴, 아키텍처 결정, 사용자 선호가 담깁니다. 축적되는 조직의 지식입니다.

4. 권한(Permissions). 에이전트가 자율적으로 할 수 있는 일과 사람의 승인이 필요한 일을 구분한 허용 목록입니다. 파일 쓰기, git 작업, 외부 API 호출 등 각각에 명시적인 권한 레벨이 붙습니다.

5. 훅(Hooks). 특정 이벤트에 자동으로 실행되는 체크입니다. 커밋 전, 파일 쓰기 후, 세션 시작 시 같은 시점에 돌아갑니다. 버즈빌에서는 Biome 린트와 포매팅, TypeScript 타입 체크, 여백 컨벤션, 파괴적 작업 경고를 훅으로 강제합니다.

원칙은 이렇습니다. 성공하면 조용히, 실패하면 요란하게. 에이전트는 가드레일 안에서 자유롭게 일합니다. 경계에 부딪히면 멈추고 묻습니다.

Anthropic 팀은 검증(verification)을 "가장 효과가 큰 팁"이라고 부릅니다. 에이전트가 스스로의 결과물을 체크할 수 있는 수단을 주면 품질이 극적으로 올라간다는 것입니다. 6 이 글에서 단 하나만 가져가신다면 이걸 가져가세요. 커밋 전에 검증하는 훅을 세팅하세요. 나머지는 전부 그 위에 복리로 쌓입니다.

공통 언어로서의 토큰

디자인 시스템은 참고하는 Figma 라이브러리가 아닙니다. 화면을 구성하는 실제 재료 그 자체입니다.

버즈빌의 모든 컬러, 간격 값, 타이포그래피 스케일, 섀도는 OKLCH 컬러 스페이스에서 생성된 시맨틱 CSS 변수로 존재합니다. 시스템은 세 층으로 이뤄져 있습니다.

  1. 프리미티브(Primitives): 원시 값입니다 (OKLCH 명도, 채도, 색상).
  2. 시맨틱(Semantic): 의도 기반의 이름입니다 (action-primary, surface-default, text-muted).
  3. 컴포넌트(Component): 특정 요소에 붙는 이름입니다 (button-bg, card-border).

에이전트가 페이지를 만들 때는 시맨틱 토큰을 씁니다. 컴포넌트를 만들 때는 컴포넌트 토큰을 씁니다. 주변이 모두 시스템적이기 때문에, 그 사이에 섞인 하드코딩 값은 자연스럽게 이상해 보입니다.

디자인 토큰과 코드 토큰을 정렬하는 것은 UX Collective가 꼽은 AI 네이티브 디자인 워크플로우의 1순위 전제 조건입니다. "MCP Server, Claude Code, Codex CLI가 같은 디자인 언어를 쓰도록 보장하는 것"이라고 표현했습니다. 7 Indeed의 Diana Wolosin은 1,056개의 프롬프트로 8개의 MCP 구성을 테스트해서, JSON 형식이 산문 문서 대비 토큰을 80% 적게 쓰고 비용은 5배 낮다는 것을 확인했습니다. 8

원칙, 레시피, 가이드라인

에이전트가 인터페이스를 조합할 때는 세 층의 지시가 필요합니다.

원칙은 타협할 수 없는 제약입니다. "레드를 배경 색상으로 쓰지 않는다." "모든 인터랙티브 요소는 최소 44px 터치 타겟을 가진다." "한글은 Noto Sans KR을 쓴다." 이런 것들은 맥락에 따라 바뀌지 않습니다.

레시피는 알려진 맥락을 위한 검증된 패턴입니다. "캠페인 인터랙션은 Hook → Challenge → Reward → Offer 순서를 따른다." "광고주 랜딩 페이지는 신뢰 지표로 시작해 케이스 스터디, CTA로 이어진다." 같은 것입니다.

가이드라인은 세분화된 규칙입니다. 톤앤매너, 토큰 사용법, 여백 컨벤션, 애니메이션 타이밍 같은 것입니다. 드리프트를 막아주는 촘촘한 지식입니다.

버즈빌에서는 이게 이렇게 매핑됩니다.

  • 원칙 → CLAUDE.md (레포 단위 스탠딩 오더)
  • 레시피 → 스킬 + 컴포넌트 패턴
  • 가이드라인 → 디자인 토큰 + 브랜드 가이드 + 훅

Design Systems Collective의 Cristian Morales Achiardi는 이런 흐름을 "에이전틱 디자인 시스템(agentic design systems)"으로 가는 전환이라고 설명합니다. 드리프트를 감지하고, 보고하고, 자율적으로 수정을 제안하는 시스템이라는 뜻입니다. 9 이제 디자인 시스템은 사람이 읽는 Figma 라이브러리가 아니라, 에이전트가 참조해 조합하는 구조화된 지식입니다.

PM과 엔지니어에게 달라지는 것

이제 팀의 디자이너는 목업을 넘기지 않습니다. 그리고 여러분 또한 UI 변경 사항을 직접 배포하게 될 것입니다.

AI 코딩 에이전트 덕분에 프로덕트 팀의 누구나 인터페이스를 만들고 수정할 수 있게 되었습니다. 플로우를 프로토타이핑하는 PM, 레이아웃을 조정하는 엔지니어, 대시보드 뷰를 추가하는 데이터 분석가 모두 UI 결과물을 만들어냅니다. 디자인 시스템, 토큰, 하네스가 받쳐주기 때문에, 그 결과물은 누가 작성했든 구조적으로 탄탄합니다.

달라지는 것은 협업 모델, 구체적으로는 "누가 무엇을 리뷰하는가"입니다.

스펙을 기다리지 마세요. 여러분이 Figma 파일을 검토하기도 전에 디자이너가 이미 동작하는 버전을 배포해버릴지도 모릅니다. 이제는 Figma 대신 PR(Pull Request)을 리뷰하세요.

여러분(엔지니어/PM)도 UI를 배포할 수 있습니다. 디자인 시스템과 AI 에이전트라는 도구가 있다면 UI 변경은 여러분도 직접 할 수 있습니다. 토큰과 컴포넌트를 사용해 직접 PR을 올리세요.

디자이너는 여러분의 UI를 리뷰합니다. 여러분이 UI 변경 사항을 배포하면, 디자이너는 시각적 품질, 일관성, 사용자 경험에 대한 책임을 지는 리뷰어가 됩니다. 이는 엔지니어링의 코드 리뷰와 거울처럼 대응하는 구조입니다. 여러분이 그들의 로직을 리뷰하듯, 그들은 여러분의 인터페이스를 리뷰합니다. 디자이너가 품질을 책임지기 위해 굳이 코드를 직접 짤 필요는 없습니다.

디자인 피드백은 코드 위에서 이뤄집니다. 다른 모든 기여를 리뷰할 때와 마찬가지로, PR에 코멘트를 달고 변경 사항을 제안하며 브랜치에서 함께 반복 수정(iterate)하세요.

디자인 시스템은 우리 모두의 공유 영역입니다. 토큰, 컴포넌트, 패턴은 팀원 모두의 결과물을 하나로 묶어주는 계약과 같습니다. 여러분이 토큰 하나를 바꾸면 디자이너의 작업에도 영향을 주며, 디자이너가 컴포넌트를 추가하면 여러분도 즉시 사용할 수 있습니다.

품질 게이트는 자동화됩니다. 린트(Lint), 타입 체크, 포매팅 같은 구조적인 문제는 '훅(Hooks)'이 자동으로 잡아냅니다. 사람의 리뷰는 프로덕트 적합성, 시각적 품질, 사용자 경험과 같이 '판단력'이 필요한 영역에만 집중합니다.

"누가 마크업을 쓰고" "누가 로직을 쓰는지" 사이의 경계는 이제 투과성을 가집니다. 그 투과성 속에서 팀의 결과물을 하나로 묶어주는 것이 디자인 시스템입니다.

어떤 디자이너가 성장하는가

제니 웬은 이 워크플로우에서 실제로 성장하는 디자이너를 세 가지 아키타입으로 정리합니다. 1 저희도 이 프레임을 그대로 채용에 적용합니다.

  1. 풀스택 제너럴리스트: 전통적인 T자형(한 가지 깊이, 나머지는 얕게)이 아니라, 여러 핵심 역량을 80% 수준으로 모두 갖춘 사람입니다. 리서치, 비주얼, 프로토타이핑, 프로덕트 사고, 가벼운 코드까지. 디자이너의 역할이 PM과 엔지니어링 영역으로 확장되는 지금, 여러 도메인 사이를 유연하게 움직일 수 있는 사람이 이 변화를 부담 없이 흡수합니다.
  2. 독보적인 스페셜리스트: 한 분야에서 업계 상위 10%에 드는 사람입니다. 비주얼 디자인, 모션, 타이포그래피, 일러스트레이션, 혹은 엔지니어링에 가까운 고도의 기술 디자인. 누구나 적당히 좋은 결과물을 만들 수 있는 시대에, 결과물을 특별하게 만드는 차별점은 이 사람에게서 나옵니다.
  3. 유연한 적응력을 가진 신입: 커리어 초기, 겸손하고, 기술적 호기심이 있으며, 이미 코드에서 만들어본 사람입니다. 제니는 직관에 반하는 주장을 합니다. "굳은 습관이나 기존 프로세스에 대한 애착이 없는 사람이, 프로세스가 빠르게 바뀌는 시기에는 오히려 유리합니다." Figma 중심 워크플로우의 근육 기억이 없기 때문에, 버려야 할 것이 없습니다.

공통점은 적응력입니다. 프로세스는 어떤 단일 도구나 방법에 붙박여서는 따라갈 수 없을 만큼 빠르게 바뀌고 있고, 그 애착 자체가 지금은 부채입니다. 화려한 케이스 스터디로 가득한 포트폴리오보다, 판단력과 속도, 코드에서 일해본 증거가 더 강력한 준비물입니다.

결과물 측정과 템포 유지

디자이너가 PR로 배포한다면, PR 수치를 측정해야 합니다.

버즈빌은 디자인 팀 PR을 핵심 결과(KR)로 추적합니다. 2026년 2분기에 디자이너 3명 이상이 총 30개 이상의 PR을 내는 것이 목표입니다. 1분기 베이스라인은 기여자 2명에 PR 16개였습니다. 새로운 지표입니다. PR 개수를 OKR로 쓰는 디자인 팀을 저희는 어디서도 찾지 못했습니다. 이 지표는 하나의 질문에 곧바로 답합니다. 디자이너들이 정말로 배포하고 있는가, 아니면 여전히 핸드오프만 하고 있는가?

핵심은 숫자가 아니라 추세입니다. 주마다 PR 개수는 늘어야 하고, 기여자는 다양해져야 합니다.

또 하나의 문제는 템포입니다. AI는 개인을 빠르게 만들어줍니다. 공통 리듬이 없으면 그 속도는 혼란을 낳습니다. 다섯 명이 하루에 스무 건씩 PR을 배포하는데 조율이 없다면, 그건 생산성이 아니라 소음입니다.

스탠드업은 작업이 며칠 걸린다는 전제 위에 서 있습니다. 스프린트 플래닝은 2주 단위를 전제합니다. 디자인 리뷰는 일주일에 방향 하나를 전제합니다. 개인이 하루에 기능 여러 개를 배포할 수 있게 되면, 이런 리듬은 조율에는 너무 느리고 도움이 되기에는 너무 잦습니다. 저희는 AI가 실제로 생산하는 것을 중심으로 케이던스를 다시 짰습니다. 커밋, PR, 측정된 산출물이 기준입니다.

  • 매일, 비동기, 산출물 기반. 스탠드업은 없습니다. 작업은 커밋과 열린 PR로 드러납니다. 산출물이 곧 상태 업데이트입니다.
  • 매주, 자동 생성되는 리뷰. 시스템이 모든 활성 프로젝트의 git 로그를 스캔해서 진척 리포트를 만듭니다. KR 완료율이 움직이거나, 움직이지 않거나 합니다. 이 방식은 "이번 주에 뭐 했어요?" 미팅을 증거 기반으로 바꿉니다. 의존성도 드러납니다. 인터랙션 라이브러리의 한 커밋이 디자인 라이브러리 문서에 영향을 주고, 그게 다시 SDK 문서에 영향을 주는 식입니다.
  • 매달, 이해관계자 정렬. 디자인 팀의 결과물을 소비하는 사람들과 1:1을 가집니다. 상태 보고가 아니라 정렬 점검입니다.
  • 분기마다, 실제 숫자로 OKR 리셋. 모든 KR은 자가 보고가 아니라 산출물에서 측정한 완료율을 가집니다. "Storybook 커버리지"가 92%인 것은 스토리 파일을 세어봤기 때문입니다. "디자인 팀 PR"이 16인 것은 GitHub에 쿼리해봤기 때문입니다.

이 케이던스는 두 가지 목적을 수행합니다. 개인에게는 체크포인트가 됩니다. 매일의 AI 보조 작업 속도에서 한 발 물러나, 방향이 여전히 맞는지 물어보는 순간입니다. 팀에게는 응집력을 제공합니다. 여섯 명이 독립적으로 배포해도, 여전히 하나의 프로덕트를 만들고 있다는 확신입니다.

AI는 개인의 결과물을 가속시킵니다. 템포는 그것을 하나로 엮습니다.

이 흐름이 향하는 곳

크리스토퍼 알렉산더(Christopher Alexander)는 이 패턴이 소프트웨어에 도달하기 훨씬 전에 그 본질을 설명했습니다. 《영원의 건축(The Timeless Way of Building)》(1979)에서 그는, 지속되는 품질이 공유된 패턴 언어에서 온다고 주장했습니다. 누구나 사용해 일관되고 아름다운 결과를 만들 수 있는, 살아있는 규칙의 시스템이라는 것입니다. 10 패턴이 올바르면 건물은 스스로 돌봐집니다. 언어가 공유되면 시스템은 영혼을 잃지 않고 확장됩니다.

알렉산더의 통찰은 건축에서 소프트웨어로 건너와 디자인 패턴, Wiki, 그리고 결국 디자인 시스템에 영감을 주었습니다. 지금 또 한 번 건너오고 있습니다. AI 에이전트는 새로운 종류의 빌더입니다. 이전의 어떤 빌더보다 빠르고 지칠 줄 모르지만, 결국 주어진 패턴만큼만 뛰어납니다. 그 패턴을 설계하는 것이 바로 우리의 역할입니다.

환경을 설계하고, 토큰을 배포하며, 직접 PR을 여는 팀이 앞으로 프로덕트가 만들어지는 방식을 정의할 것입니다. 다음 Figma 파일이 나오기만을 기다리는 팀은, 한 달이라는 시간이 어디로 사라졌는지 궁금해하게 될 것입니다.

자료가 더 풍부하고 환경에 대한 설명이 더 깊은 플레이북 전문을 따로 공개했습니다. 이 글은 전환을 고민하는 팀을 위한 요약 버전입니다.

Footnotes

  1. Jenny Wen, "The design process is dead. Here's what's replacing it." Lenny's Newsletter/Podcast, March 2026. lennysnewsletter.com ↩ ↩2 ↩3 ↩4

  2. Chris Roth, "Building An Elite AI Engineering Culture In 2026." cjroth.com ↩

  3. Greptile State of AI Coding Report / Index.dev, cited in "When product managers ship code: AI just broke the software org chart." dataworldbank.net ↩ ↩2

  4. Marty Cagan, "Build to Learn vs Build to Earn." Silicon Valley Product Group, April 2026. svpg.com ↩

  5. "AGENTS.md Optimization: 5x Performance Boost for AI Coding Agents." SmartScope. smartscope.blog ↩

  6. "Claude Code power user tips: Verification." Anthropic Help Center. support.claude.com ↩

  7. "Building AI-driven workflows powered by Claude Code and other tools." UX Collective. uxdesign.cc ↩

  8. "Your Design System Is Not Ready for AI Agents." Into Design Systems. intodesignsystems.com ↩

  9. "Towards an agentic design system." Cristian Morales Achiardi, Design Systems Collective. designsystemscollective.com ↩

  10. Christopher Alexander, The Timeless Way of Building (Oxford University Press, 1979). ↩

Related posts