우리는 Figma 없이도 제품을 출시합니다

*원문을 번역한 글입니다.

*원문은 발행 이후 수정될 수 있으며, 본 번역은 발송 시점 기준으로 작성되었습니다.

GitHub 저장소가 제가 가장 좋아하는 디자인 도구가 되었습니다.

프로젝트의 50%는 승인을 받지 못합니다. 결과물이 잘못되어서가 아닙니다. 디자이너와 개발자 사이에서 무언가가 유실되기 때문입니다. 이 수치는 글로벌 브랜드의 제품팀 340곳을 조사한 연구에서 나온 것입니다. ONSIGHT Projection Report 2026은 이를 더욱 직설적으로 표현합니다.

데이터가 죽어 사라지는 지점을 하나만 꼽는다면, 디자인에서 실제 구현으로 넘어가는 핸드오프 단계입니다.

업계 종사자의 65%는 핸드오프를 제품 생애주기 전체에서 가장 문제가 많은 단계로 꼽았습니다. 우리는 이 문제를 이미 수년 전부터 알고 있었습니다. 그리고 이를 해결하겠다며 프로세스에 더 많은 도구를 추가해 왔습니다. 더 자세한 주석, 더 엄격하게 설계된 Figma 컴포넌트, 더 길어진 스펙 문서 같은 것들입니다. 해야 할 일만 훨씬 늘어났을 뿐, 문제는 여전히 반복됩니다.

저는 그 방식을 그만두었습니다. 어떤 철학적 신념 때문은 아니었습니다. 그 프로세스가 구조적으로 불필요해졌고, 시간은 많이 들면서 감당하기까지 어려워졌기 때문입니다.

지금의 제 워크플로우는 이렇습니다. 코드로 프로토타입을 만들고 디자인합니다. HTML과 CSS로 실제 인터랙션과 실제 상태를 구현합니다. 완성한 프로토타입은 GitHub 저장소에 푸시합니다. GitHub Pages를 이용하면 팀원 누구나 열어 보고, 공유하고, 직접 살펴볼 수 있는 라이브 URL로 배포됩니다. 실제 서비스에 배포할 수준의 결과물을 만들 때가 되면, 에이전트가 프로토타입 저장소를 읽고 시각적 완성도를 100% 그대로 유지한 컴포넌트와 버튼, 페이지를 생성합니다. 재사용할 수 있고, 곧바로 출시할 수 있는 형태로 말입니다.

이 저장소 자체가 스펙이자 단일 진실 공급원입니다.

새로운 워크플로우

이 방식은 제가 일하는 방법을 완전히 바꾸어 놓았습니다. 구체적인 과정이 궁금하시다면, 제가 작성한 가이드에서 저장소 구조와 에이전트 설정 방법을 확인하실 수 있습니다. 구독하시면 전체 가이드를 무료로 보내드립니다. 구독하기 →

예전에는 정반대 방식으로 일했습니다. Figma 파일에 주석을 꼼꼼하게 달아 개발자에게 넘기면, 개발자는 자신의 해석을 바탕으로 모든 것을 다시 구현했습니다.

컴포넌트는 얼핏 비슷해 보였고, 간격은 대략적인 값으로 구현되었으며, 예외 상태는 추측에 맡겨졌습니다. 애초에 수정할 필요가 없어야 했던 문제를 바로잡는 데 시간이 쓰였습니다. 그 방식을 멈추고 나서야 그 반복 과정이 얼마나 많은 에너지를 소모하고 있었는지 깨달았습니다.

기존 방식

이것은 바이브 코딩이 아닙니다. 프롬프트만으로 완성된 제품까지 밀어붙인 뒤, 결과가 잘 나오기만을 기대하는 방식이 아닙니다. 저는 VS Code의 Copilot 인터페이스에서 Claude와 함께, 의도가 분명하고 구조화된 코드를 작성합니다. AI는 페어 프로그래머 역할을 합니다. 모든 의사결정의 주도권은 여전히 저에게 있습니다. 이 차이는 중요합니다. 결과물을 읽는 에이전트가 설계 의도를 정확하게 이해해야 하기 때문입니다. 허술한 코드는 결국 허술한 컴포넌트를 만듭니다.

저장대학교와 Alibaba의 연구진은 2024년 ‘Prototype2Code’라는 논문을 발표했습니다. 이 연구는 UI 디자인 프로토타입에서 실제 배포 가능한 프런트엔드를 엔드 투 엔드로 생성하는 방법을 제시합니다. 이 워크플로우의 가능성은 이미 학계에서도 입증되기 시작했습니다. 논문에서 연구 시스템으로 설명한 방식을 우리는 이미 실제 프로덕션 환경에서 사용하고 있습니다.

디자이너와 개발자, 두 역할은 서로 반대편에서 출발해 같은 지점을 향해 움직이고 있습니다. Gartner는 2026년 말까지 개발자의 75%가 코드를 직접 작성하기보다 여러 AI 도구와 에이전트를 오케스트레이션하게 될 것이라고 전망합니다. 흔히 이는 개발자에게 일어나는 변화로 이해됩니다. 하지만 디자이너들 역시 이미 같은 일을 하고 있다는 사실은 상대적으로 덜 논의됩니다. 저는 제가 직접 작성한 프로토타입을 기준으로 여러 에이전트의 작업을 조율합니다. 이는 대다수 팀이 여전히 머물러 있는 단계보다 한발 더 진화한 디자인 워크플로우입니다.

이 변화가 던지는 불편한 결론은 팀 구조 자체에 관한 것입니다. 디자이너 한 명, 개발자 두세 명, 그리고 전체 프로세스를 조율하는 PM으로 구성된 전통적인 제품팀 구조는 단계마다 실패할 수 있는 ‘번역 계층’의 존재를 전제로 합니다. Hazelcast에서 우리는 두 명으로 일합니다. 저는 디자인과 코드를 담당하고, 동료는 프런트엔드 엔지니어링을 담당합니다. 이 구조가 제대로 작동하는 이유는 바로 그 번역 계층이 사라졌기 때문입니다. Hazelcast에서 우리는 두 명으로 일합니다. 저는 디자인과 코드를 담당하고, 동료는 프런트엔드 엔지니어링을 담당합니다. 이 구조가 제대로 작동하는 이유는 바로 그 번역 계층이 사라졌기 때문입니다. 어느 역할도 불필요해지는 것은 아닙니다. 다만 전달 과정을 관리하기 위해 존재하던 인력은 불필요해질 수 있습니다.

Jakob Nielsen은 2025년 UX 회고에서 Figma AI와 Vercel의 v0 같은 도구가 신기한 실험을 넘어 일반적인 실무 방식으로 자리 잡으면서, 상용 제품 제작을 위한 픽셀 단위 화면 작업의 시대가 사실상 2025년 3분기에 끝났다고 평가했습니다. 하지만 그가 명확하게 말하지 않은 것이 있습니다. 디자이너는 정적인 파일을 만들고, 개발자는 작동하는 코드를 만들며, 두 영역은 서로 만날 일이 없다는 전제 위에 세워진 팀 구조가 앞으로 어떻게 될 것인가에 대한 문제입니다.

개발자의 역할을 불필요하게 만든 디자이너는 더 좋은 Figma 파일을 만든 사람이 아니었습니다. 코드를 작성한 사람이었습니다.

디자이너의 역할을 불필요하게 만든 개발자는 단순히 더 빠르게 출시한 사람이 아니었습니다. 디자인 의도를 충분히 깊이 이해하고, 이를 코드에 직접 담아낸 사람이었습니다.

이 두 가지 변화는 지금 동시에 일어나고 있습니다. 두 역할은 빠르게 서로를 향해 수렴하고 있으며, 그 사이의 간격은 양쪽이 예상했던 것보다 훨씬 빠른 속도로 좁아지고 있습니다. 이 변화를 먼저 이해한 팀에서는 두 명이 여덟 명의 몫을 해내게 될 것입니다.

반대로 이를 이해하지 못한 팀은 2027년에도 여전히 얼라인먼트 회의 일정을 잡고 있을 것입니다. 아직 코드로 프로토타입을 만들지 않는 디자이너라면, 지금 배울 가치가 있는 것은 바로 그것입니다. Claude Code도, 에이전틱 파이프라인도 아닙니다. 우선은 프로토타입이면 됩니다. HTML과 CSS부터 시작해 보세요. 프로토타입을 저장소에 올리고, Figma 링크 대신 URL을 공유해 보세요. 나머지는 그다음에 자연스럽게 따라옵니다.

참고 자료:

현장 예측 보고서 2026 (65% 통계) https://www.constructionbriefing.com/news/embargo-designconstruction-handover-named-biggest-source-of-data-friction/8117238.article

프로젝트 실패율 50% 통계 (Kony 연구, 응답자 340명) https://www.developer-tech.com/news/2014/dec/11/designer-vs-developer-friction-ruining-your-ux/

Prototype2Code 논문 (저장대학교/알리바바, 2024) https://arxiv.org/abs/2405.04975

가트너, 2026년까지 개발자의 75%가 오케스트레이션을 활용할 전망 (https://firstlinesoftware.com/blog/ai-software-development-2026-2035/)

야콥 닐슨의 2025년 UX 회고록 https://medium.com/design-bootcamp/product-designers-are-not-being-replaced-they-are-being-sorted-6e2fb0492ed2

원문 출처: https://medium.com/design-bootcamp/the-designer-who-made-the-developer-redundant-the-developer-who-made-the-designer-redundant-4fe86b185259

DEET를 구독하고 커리어 성장을 위한 작은 습관을 시작해 보세요.