이제 디자이너가 PR을 올립니다
Product Designer - CDO
이 글은 영문 원본을 바탕으로 작성되었습니다.
6개월, 432개의 pull request, 디자인팀 하나. 무엇이 좋아졌고 무엇을 치렀는지 정리했습니다.
얼마 전, 저희 디자이너 한 명이 광고 참여 플로우에서 행운뽑기 컨셉을 살펴보고 있었습니다. 뭘 고치던 참은 아니었습니다. 방향이 아직 잡히기 전에 이리저리 둘러보는, 그런 시간이었습니다.
그런데 화면이 튀었습니다.
길어야 1초입니다. 광고 오버레이를 열었다 닫으면, 보고 있던 위치를 지키지 않고 화면이 맨 위로 돌아갑니다. 기능은 멀쩡했습니다. 에러도 없고, 크래시도 없고, QA 티켓에 적힐 만한 것도 없었습니다. 꽤 오래 라이브 상태였는데 아무도 눈치채지 못했습니다. 동작만 놓고 보면 문제가 없었으니까요.
Rina는 눈치챘습니다. Claude와 페어링해 원인을 파고들었고, 공유 훅 usePreventScroll이 오버레이 두 개가 동시에 스크롤을 잠글 때 저장해둔 스크롤 위치를 0으로 덮어쓴다는 것을 찾아냈습니다. 참조 카운팅 방식으로 근본 원인을 고치고, 회귀 테스트까지 붙여 PR을 올렸습니다.
PR을 연 지 46분 만에 프로덕션 배포. 그날 안에 끝났습니다. 그리고 수정이 공유 훅에 들어갔기 때문에, 그 오버레이를 쓰는 모든 파트너 앱이 한꺼번에 좋아졌습니다. 이 부분은 PR에 붙은 라벨만 봐도 바로 보입니다.
그러자 프론트엔드 개발자 Finn이 채널에 이렇게 남겼습니다.
오오 직접 배포하는 디자이너 🕺
이 글의 주인공은 그날 하루가 아닙니다. 그날을 당연한 하루로 만들어준 6개월이 주인공입니다.
디자인 PR이 대체 뭔가요
먼저 반론부터 짚고 가겠습니다. 늘 똑같은 질문이 나오고, 충분히 나올 만한 질문입니다. 디자이너가 프로덕션 레포에 코드를 올린다고요? 제정신인가요?
저희 팀의 물꼬를 튼 건 이 비유였습니다. PR은 Google Docs의 제안 모드 편집과 같습니다. 담당 엔지니어의 리뷰 없이는 아무것도 머지되지 않습니다. 다른 모든 변경과 똑같은 관문, 그러니까 lint와 타입 체크와 테스트와 CI와 코드 리뷰를 통과하기 전에는 사용자에게 닿지 않습니다. 권한을 가진 누군가가 승인하기 전까지, 디자이너 브랜치의 영향 범위는 0입니다.
바뀐 것은 안전장치가 아닙니다. 바뀐 것은 결과물입니다.
예전에는 Figma 파일 하나에 티켓 하나, Slack 스레드 하나, 그리고 "이 간격 이거 맞나요?" 같은 후속 질문까지 흩어져 있었습니다. 지금은 의도와 구현과 diff와 리뷰 대화와 배포가 전부 담긴 객체 하나가 있습니다. 디자인 PR이 곧 스펙입니다.
참고로 저희도 처음부터 여기 있었던 건 아닙니다. Figma Make로 프로토타입을 만들었고, 그다음엔 Vercel에 HTML 프로토타입을 올렸습니다. 탐색용으로는 나쁘지 않았지만 딜리버리에는 쓸 수 없었습니다. 디자이너가 컨텍스트를 아무리 넣어줘도, 레포 밖의 프로토타입은 우리 토큰도 컴포넌트도 데이터 구조도, 코드베이스가 이미 내려둔 마흔 가지 결정도 알지 못하니까요. 그걸 인정하기까지 두 달을 썼습니다. 실제 프로덕션 레포로 들어간 것이 속도와 품질을 한꺼번에 바꿔놓았습니다. 이유는 글 마지막에서 다시 이야기하겠습니다. 에이전트가 비로소 자기가 무엇 위에 쌓아 올리는지 보게 된 겁니다.
숫자부터 보겠습니다
6개월 동안 디자인팀 구성원이 저희 레포 전체에 올린 pull request 전부입니다.
| 2026 Q1 | 2026 Q2 | 2026 Q3 (9/4 기준) | |
|---|---|---|---|
| 올린 PR | 10 | 177 | 245 |
| 참여한 팀 비율 | 17% | 100% | 100% |
| 머지율 | 90% | 82% | 87% |
| 작업한 레포 | 3 | 14 | 15 |
이 표에서 중요한 건 두 가지고, 둘 다 합계가 아닙니다.
참여한 팀 비율. Q1의 PR은 전부 제 것이었습니다. 리드 한 명이 혼자 실험해본 수준이었고, 대부분의 팀이 딱 여기까지 하고 멈춥니다. Q2가 되어서야 리드의 취미가 아니라 팀의 기본값이 되었습니다. 저 줄이 100%에 닿은 것이 결과입니다. 177이라는 숫자는 그 결과가 만들어낸 것일 뿐입니다.
머지율. 디자인 PR의 82%와 87%가 머지됩니다. 나머지는 닫힌 탐색용 브랜치, 다른 PR로 대체된 스택, 그리고 리뷰에서 걸러진 나쁜 아이디어 몇 개입니다. 나쁜 아이디어는 원래 거기서 죽는 게 맞습니다. 디자인 PR의 머지율이 40%라면 워크플로우가 아니라 스코핑에 문제가 있는 겁니다.
이번엔 반대편에서 온 숫자입니다. Figma Dev Mode는 엔지니어가 디자인을 읽고 손으로 다시 만들라고 있는 기능입니다. 딜리버리가 정말로 코드로 옮겨갔다면, 그 통로는 저절로 비어야 합니다.
비었습니다. 강제한 사람은 없습니다. 엔지니어링 팀들에게 Dev Mode가 아직 필요한지 물었고, 다들 시트를 반납했습니다. 그 시트가 존재하던 이유인 핸드오프 자체가 사라졌기 때문입니다.
8월에 다시 늘어난 한 자리는 이 글 전체에 붙는 솔직한 각주입니다. 아직 Figma 우선 핸드오프로 돌아가는 파트너 커스터마이징 프로젝트가 하나 남아 있습니다.
탐색은 넓게, 딜리버리는 한 길로
그렇다고 Figma가 적이 된 건 아닙니다. "디자이너가 코드를 짠다"는 말을 대부분 "디자이너가 캔버스를 버렸다"로 읽으시는데, 그런 일은 일어나지 않았습니다.
탐색은 뭐든 씁니다. 캔버스, 한 번 쓰고 버릴 HTML 목업, 코드로 만든 프로토타입, 화살표를 그려 넣은 스크린샷. 여덟 개의 방향을 한 화면에 펼쳐놓고 한눈에 비교하는 데 Figma만 한 도구를 아직 못 봤습니다. 코드는 선형이라, 한 방향에 시간을 쓰기 시작하면 곧바로 그 방향을 변호하게 됩니다. 답에 가장 빨리 닿는 도구를 쓰시고, 그 산출물은 버릴 것으로 대하시면 됩니다. 실제로 버릴 것이니까요.
딜리버리는 오직 코드베이스입니다. 한 길뿐이고 예외는 없습니다. 사용자에게 나가는 것이라면 레포 안에서 만들어졌고, 테스트가 있고, 리뷰를 거쳤고, CI를 통과했습니다. 방향이 정해지는 순간부터 그것은 제품의 그림이 아니라 제품 그 자체가 됩니다.
그리고 Figma는 우리 디자인 시스템을 가진 적이 없습니다. 사본을 가지고 있었을 뿐입니다.
시스템은 처음부터 코드베이스에 있었습니다. 토큰, 컴포넌트, 동작, 제품을 이루는 실제 재료 말입니다. Figma에 있던 것은 손으로 맞춰주는 거울이었고, 손으로 맞추는 거울은 결국 주기를 정해놓고 어긋나는 것에 지나지 않습니다. Figma 라이브러리와 코드 중 뭐가 맞는지 한 번이라도 다퉈본 팀이라면 답을 이미 알고 계실 겁니다. 언제나 코드였습니다. 사용자가 만지는 것이 코드니까요.
그래서 거울 관리를 그만뒀습니다. 지금 디자이너는 시스템이 실제로 사는 곳에서 시스템을 바꿉니다. 같은 레포, 같은 PR, 엔지니어의 변경과 똑같은 리뷰. 토큰이 움직이면 한 번만 움직입니다. 한번 해보세요. 몸이 훨씬 가벼워집니다. ^^
그러니 워크플로우를 따라 하기 전에 이것부터 답해보시면 좋겠습니다. 우리 디자인 시스템은 실제로 어디에 사는가. 그리고 사본 관리를 그만두시면 됩니다.
무엇이 좋아졌나
기다림이 사라졌습니다. 다른 디자이너 한 명은 왜 직접 코드를 짜기 시작했느냐는 질문에 이렇게 답했습니다.
FE 엔지니어들이 디버깅으로 너무 바빠서, 그냥 제가 하기 시작했어요.
그 변경은 같은 주에 머지됐습니다. 예전 방식이었다면 목업 하나, 티켓 하나, 스프린트 경계 한 번, 그리고 버튼 하나 옮기려고 2주를 기다려야 했습니다.
실제 조건에서, 출시 전에. 코드 프로토타입은 진짜 데이터로, 진짜 화면 폭에서, 진짜 컴포넌트로 돌아갑니다. 엣지 케이스가 출시 이틀 뒤가 아니라 디자인하는 도중에 드러납니다. 반응형은 캔버스에서 흉내 낼 수 없고, 해보신 분들은 다 아십니다.
우선순위에서 늘 밀려나던 것들. 모션, 트랜지션, 제품을 의도적으로 느껴지게 만드는 작은 타이밍 결정들. 명세를 쓰는 비용이 커서 매번 우선순위 싸움에서 졌던 것들입니다. 이제는 디자이너가 그냥 합니다. 싸울 일 자체가 없어집니다.
수정이 공유 레이어에 쌓입니다. 코드베이스 안에서는 동작이 실제로 사는 곳, 보통은 공유 컴포넌트나 훅을 고치게 됩니다. 한 번 고치면 그것을 쓰는 모든 화면이 함께 좋아집니다. 디자인 품질이 화면 단위를 벗어났습니다.
만든 그대로 사용자에게 갑니다. 개인적으로 가장 중요하게 생각하는 부분입니다. 15년 동안 우리는 디자인과 구현 사이의 손실을 사업 비용처럼 받아들였습니다. 이제는 선택 사항입니다.
무엇을 치렀나
여기서 멈춘다면 저부터 이 글을 믿지 않을 겁니다.
리뷰 부담이 엔지니어에게 옮겨갑니다. 실제로 그렇습니다. 업계 전반에서 AI를 쓰는 팀은 1인당 PR이 98%, PR 크기 중간값이 33%, 리뷰 시간이 91% 늘었습니다. 코드를 만드는 일은 싸졌지만 읽는 일은 그대로였습니다(아주 그대로는 아니지만요). 이 계산 없이 디자이너를 레포에 넣으면, 디자인의 비용을 조용히 엔지니어링으로 옮긴 셈이 됩니다. 그리고 그 사실은 여러분보다 EM이 먼저 알아챕니다.
저희는 세 가지로 이 부담을 낮게 유지했습니다. 디자인 PR은 레포에 이미 있는 모듈과 컨벤션 위에서 만들어지므로 일관성이 구조적으로 확보됩니다. PR을 올리기 전에 브랜치에서 자동 리뷰가 한 번 돌기 때문에 리뷰어가 뻔한 것을 보지 않습니다. 그리고 대부분의 디자인 PR은 관련된 FE, BE PR과 함께 스택으로 올라가 한꺼번에 리뷰됩니다.
리뷰 자체도 AI의 도움을 받기 시작했습니다. Rina의 PR에서 Finn보다 먼저 입을 연 쪽을 보시면 됩니다. 봇이 이미 변경 요약과 파일별 정리, 잠금 동작의 시퀀스 다이어그램, 커버리지 변화까지 올려두었습니다. 사람이 PR을 열었을 때 그 diff는 이미 한 번 읽힌 상태였습니다. Finn이 할 일은 무엇이 바뀌었는지 재구성하는 것이 아니라, 이걸 내보내도 되는지 판단하는 것이었습니다. 리뷰 시간 91% 증가라는 숫자는 생성에는 에이전트가 있고 리뷰에는 없던 시점의 스냅샷이고, 그 격차는 빠르게 좁혀지고 있습니다.
끝까지 자동화되면 안 되는 것은 이것이 존재해야 하는가 라는 질문입니다. 그 질문은 diff의 양쪽 모두에서 사람 몫으로 남습니다.
도입 속도는 사람마다 다르고, 발목을 잡는 쪽은 대개 디자이너가 아닙니다. 지금은 버즈빌의 모든 디자이너가 이렇게 일합니다. 다만 거기까지 걸린 시간은 사람마다 크게 달랐고, 무엇이 각자를 붙잡았는지 돌아보면 배우기를 거부한 경우는 거의 없었습니다.
제품이 문제였습니다. 어떤 화면은 깔끔합니다. 컴포넌트 라이브러리가 있고 변경을 넣을 자리가 분명합니다. 어떤 화면은 오래됐고, 백엔드 작업과 얽혀 있고, 파트너의 릴리즈 일정 뒤에 서 있습니다. 이런 곳에서의 첫 PR은 실제로 더 어렵습니다.
더 자주는 주변 팀이 문제였습니다. PM과 엔지니어는 디자인 PR을 받아본 적이 없으니 이걸 어떻게 다뤄야 할지 몰랐습니다. 누가 리뷰하는가. 우리 스프린트가 밀리는가. 우리 오너십을 침범하는가. 전부 정당한 질문인데 답이 없으니, 일은 조용히 멈춰 섰습니다. 일이 멈추는 방식 중에 제일 나쁜 방식입니다.
이건 팀 하나하나 찾아가서, 도구가 아니라 대화로 풀었습니다. 그 시간을 미리 계산에 넣으시는 게 좋습니다. 이 워크플로우는 저절로 퍼지지 않습니다. 팀 하나, 대화 하나씩 퍼집니다.
두 갈래는 섞이고, 경계선은 저절로 그어지지 않습니다. 탐색과 딜리버리를 말로 나누는 건 쉽습니다. 그렇게 사는 건 어렵습니다. 디자이너는 이제 반나절이면 돌아가는 무언가를 만들 수 있고, 그러다 보면 이미 진짜처럼 보인다는 이유로 탐색용 프로토타입을 계속 다듬게 됩니다. 팀의 디자이너에게 지금 어느 쪽에 있느냐고 물어보세요. 답하지 못한다면 두 가지 일을 동시에 하고 있는 겁니다.
리듬 없는 속도는 소음입니다. 공통의 박자 없이 하루에 PR 20개를 올리는 팀은 생산적인 게 아니라 머지 큐일 뿐입니다. 저희는 데일리 스탠드업을 없앴고(열려 있는 PR이 곧 상태 공유입니다), 주간 리뷰는 git 로그에서 생성합니다. 개인의 속도가 먼저 올라갔고 협업의 박자가 뒤늦게 따라붙었습니다. 순서가 그랬고, 그 과정이 꽤 아팠습니다.
PR 수는 딜리버리만 잽니다. 옳은 것을 만들었는지는 전혀 말해주지 않습니다. 그래도 저희가 이 숫자를 보는 이유는, 디자이너가 실제로 출시하고 있는가 아니면 여전히 넘기고 있는가라는 무딘 질문 하나에 정직하게 답하기 때문이고, 목업을 예쁘게 만드는 걸로는 이 숫자를 속일 수 없기 때문입니다. 다만 PR 수를 최적화하는 팀은 자신만만한 실수를 300개 출시하게 됩니다. 탐색을 재는 깔끔한 지표는 아직 없고, 저도 드릴 것이 없습니다.
환경을 만드는 일이 곧 본업입니다
이걸 시도한 대부분의 팀은 뻔한 결과물을 받아 들고 "AI는 디자인을 못 한다"고 결론 내립니다. 문제는 워크플로우가 아니라 환경이었습니다.
AI가 모든 것을 똑같이 만든다는 걱정은 2024년에는 완전히 타당했습니다. 고삐 없는 모델은 자기가 본 모든 것의 평균값으로 수렴하고, 그 결과가 Tailwind 히어로 섹션에 그라데이션 덩어리입니다. 그건 셋업의 문제고, 이미 풀린 문제입니다. 제가 만든다면 이 순서로 만들겠습니다.
- 토큰을 진짜 재료로. 모든 색과 간격과 타이포 단계를 시맨틱 변수로 두고, primitive와 semantic과 component 세 겹으로 나눕니다. 표면 전체가 체계적이면 하드코딩된 hex는 여러분뿐 아니라 에이전트 눈에도 어색해집니다.
- 레포 안의 상시 지침. 모든 레포 루트에
CLAUDE.md하나. 거기 적어두는 규칙 하나가 앞으로의 교정 백 번을 아껴줍니다. - 크래프트를 담은 스킬. 그래야 지식이 시니어 디자이너 한 사람의 머릿속이 아니라 레포에 남습니다.
- 검증하는 훅. 성공하면 조용히, 실패하면 시끄럽게. 이 글에서 딱 하나만 가져가신다면 이것을 가져가세요.
- 프리뷰 환경. 공유 가능한 URL이 붙은 브랜치가 있어야 PR이 PM도 눌러볼 수 있는 것이 됩니다.
디자이너의 새로운 크래프트는 이 환경을 만드는 일입니다. 제약을 정하고, 브랜드를 코드로 새기고, 토큰을 배포하고, 스킬을 쓰십시오. 그러면 에이전트는 아무 디자인이 아니라 우리 디자인을 만들어냅니다.
월요일부터 바로 시작할 수는 없습니다
이런 글은 보통 5주짜리 계획과 "일단 PR을 올려보세요"라는 친절한 말로 끝납니다. 저도 그 버전을 먼저 썼다가 지웠습니다. 실제로 시간이 걸리는 부분을 통째로 건너뛰고, 마치 의욕 있는 디자이너 한 명이 혼자 내릴 수 있는 결정처럼 보이게 만들기 때문입니다. 그렇지 않습니다.
디자이너가 첫 줄을 쓰기 전에 누군가 치워둬야 하는 것들입니다.
회사가 실제로 승인한 LLM. 모델에 들어가는 소스 코드가 어떻게 처리되는지 검토를 거치고, 보안팀이 서명한 데이터 처리 답변이 붙은 전사 계약이어야 합니다. 누군가 조용히 개인 비용으로 결제한 구독이 아니라요. 버즈빌은 이미 전사로 정리해둔 상태여서 디자인이 필요로 하기 전에 해결돼 있었습니다. 아직이라면 이 항목 하나로 한 분기가 갈 수 있습니다.
엔지니어가 아닌 사람에게 열어주는 프로덕션 레포 쓰기 권한. 권한 설정 문제의 얼굴을 하고 있지만 사실은 정책 결정입니다. 그리고 그 결정은 여러분이 아니라 레포를 소유한 팀의 몫입니다.
그 결정에 대한 보안 검토. 누가 머지할 수 있는지, 브랜치 보호 규칙은 무엇인지, 그 브랜치가 시크릿에 닿을 수 있는지, 잘못된 변경이 들어가면 어떻게 되는지. 다 좋은 질문입니다. 질문을 받기 전에 답을 준비해두십시오.
엔지니어가 아닌 사람의 브랜치도 돌릴 수 있는 CI, 그리고 그 위에 얹는 프리뷰 환경. 순서를 봐주십시오. 프리뷰는 마지막 벽돌이지 첫 벽돌이 아닙니다. 이게 제일 재미있어 보여서 여기부터 시작했다가, 정작 디자이너가 브랜치를 못 올린다는 사실을 뒤늦게 발견하는 팀이 많습니다.
문서로 합의된 리뷰 정책. 디자인 PR의 필수 리뷰어는 누구인지, 그 리뷰가 그들의 스프린트와 경쟁하는지. 이걸 건너뛰면 PR은 일주일씩 열린 채로 있고, 다들 조용히 이 실험이 실패했다고 결론 내립니다.
그리고 이 모든 것 밑에는, 직무를 넘나드는 일이 침범이 아니라 도움으로 읽히는 문화가 있어야 합니다. 회사의 첫 디자인 PR이 영역 다툼을 부른다면, 코드를 한 줄이라도 쓰기 전에 그 대화부터 정리하십시오. 어떤 장치도 그것까지 막아주지는 못합니다.
저희는 이 길을 내는 데 몇 달이 걸렸고, DevOps와 보안과 엔지니어링 리드와 CTO가 짊어졌으며, 디자이너가 한 일은 거의 없었습니다. 이 대화들은 줄을 서면 오래 걸리고 각각 주인이 다르니, 일찍 그리고 동시에 시작하시는 게 좋습니다.
길이 열리고 나면, 사람이 올라타는 건 짧습니다. 작고 안전한 것부터 하시면 됩니다. 하드코딩된 hex를 시맨틱 토큰으로 바꾸기, 페이지 간격 고치기, 틀려도 아무 비용이 없는 것으로 전체 루프를 한 바퀴 돌기. 거기서 기능 하나를 끝까지 책임지는 데까지는 금방입니다.
하나만 기억한다면
에이전트는 자기가 닿을 수 있는 컨텍스트만큼만 강합니다. 레포 안에서는 여러분의 토큰과 컴포넌트와 데이터와 컨벤션을 보고 그 위에 쌓습니다. 밖에서는 짐작하고, 인터넷의 평균값을 돌려줍니다.
그러니 천장을 정하는 건 여러분이 계약한 모델이 아닙니다. 일이 실제로 벌어지는 자리에 모델을 데려다 놓을 수 있는 사람이 몇 명이냐가 천장을 정합니다.
코드베이스가 엔지니어만 들어갈 수 있는 방이라면, 회사 안에서 AI가 제 힘을 다 내는 방은 그 하나뿐입니다. 나머지 사람들에게는 채팅창 하나가 주어질 뿐입니다.
AI 네이티브 회사는 모두가 AI를 쓰는 회사가 아닙니다. 모두가 AI를 컨텍스트 안에 데려다 놓을 수 있는 회사, 여러 직무가 같은 제품과 같은 코드베이스 위에서 함께 일하는 회사입니다.
방향은 양쪽입니다
디자이너가 코드를 만지게 됐다면, 그 정직한 대가로 디자이너가 아닌 사람도 디자인을 만지게 됩니다. 지금 저희가 그 프로토콜을 세우고 있습니다. UI 문제를 발견한 엔지니어나 PM이 직접 고쳐서 디자인 PR을 올리고, 그 PR의 책임 리뷰어는 디자이너입니다. 강제가 아니라 선택이고, 누가 썼든 결과물이 구조적으로 성립하도록 디자인 시스템이 공통의 계약 역할을 합니다.
코드 리뷰를 그대로 뒤집은 모양입니다. 여러분이 우리 로직을 리뷰하고, 우리가 여러분의 인터페이스를 리뷰합니다.
생각해보면 이건 diff가 붙은 디자인 크리틱일 뿐입니다. 동료가 동료를 리뷰하고, 사람이 아니라 산출물을 놓고 이야기하는 것. 우리가 20년째 하자고 말해온 그것입니다.
의도한 것과 사용자가 만지는 것 사이의 거리는 이제 46분 남짓입니다. 그 거리를 완전히 지우기 전에, 아직 옮겨야 할 파트너가 몇 곳 남아 있습니다.
