만약 여러분의 팀이 AI 툴 도입을 결정하고 예산을 집행했는데, 팀의 속도가 달라진 것 같지 않다면 어떨까요? 가장 먼저 의심해야 할 건 도구의 성능이 아니라 ‘작업 기반’입니다. 이번 글에서 중점적으로 다뤄볼 이야기는 두 가지입니다. AI 시대의 협업 효율은 도구의 정교함이 아니라 작업 기반의 선택에 의해 결정된다는 것, 그리고 프로덕트 메이커가 가장 먼저 의심해야 할 것은 가장 익숙하고 당연해 보이는 작업 도구와 프로세스라는 것입니다.

이 글에서 자주 등장하는 '작업 기반'의 개념은 디자인과 개발이 공통으로 참조하는 SSOT(Single Source of Truth)가 위치하는 곳을 의미합니다. 피그마 캔버스도 작업 기반이 될 수 있고, 마크다운/HTML/CSS 같은 코드 파일도 작업 기반이 될 수 있죠. 단, 여기서 핵심은 "그 자리에 무엇을 두어야 하는가?"입니다.

미리 요점만 콕 집어보면?

AI 시대의 협업 효율은 도구의 정교함보다 SSOT(Single Source of Truth)가 위치한 작업 기반의 선택에 의해 결정됩니다.
피그마 중심 워크플로우는 필연적으로 디자인·개발 사이의 병목 지점을 만들지만, 마크다운·HTML·CSS 같은 코드 기반은 의도와 구현의 어긋남을 줄입니다.
새로운 도구를 더 붙이기 전에 디자인 시스템을 코드 친화적 기반에 정의해보는 실험이 작업 기반 자체를 바꾸는 출발점이 될 수 있습니다.

피그마 MCP를 도입했는데 왜 빨라진 느낌이 없을까?

많은 팀이 비슷한 코드 자동완성을 넘어 협업 프로세스에도 AI 도구를 붙이고 있습니다. 피그마 MCP(Model Context Protocol)를 연결해 시안을 코드로 변환하는 시도가 그 대표적인 경우입니다. 그런데 이상하게도 결과는 기대에 못 미칩니다. 부분 부분은 빨라지는데, 태스크 하나를 처음부터 끝까지 끌고 가는 E2E(End-to-End) 체감으로는 큰 차이가 없기 때문이죠.

시안에서 코드를 추출하면 결과를 다시 사람이 손봐야 하고, 디자이너가 시안을 수정하면 그 변경을 코드 쪽에 어떻게 흘려보낼지 매번 새롭게 협의해야 합니다. AI 도구가 늘어날수록 협업의 병목 지점은 오히려 더 많아지는 구조죠.

이런 상황에서 우리가 던져야 할 질문은 "어떤 도구를 더 붙일까?"가 아닙니다. 다리(Bridge)를 더 튼튼하게 만드는 동안, 정작 강의 위치를 바꿔야 하는 게 아닌지 의심해야 합니다.

프론트엔드 코드 디자인을 HTML로, 다시 피그마로 변환할 때

이 구조적 문제가 잘 드러나는 사례가 있는데요. 만약 급한 일정으로 개발자가 와이어프레임 없이 코드로 화면을 먼저 만든 상황을 가정해 보겠습니다. 피그마 캔버스 없이 실물 구현체가 먼저 나온 상황입니다. AI로 개발자들의 코드 작업 속도가 기하급수적으로 빨라지면서, 현업에서는 이런 상황이 더 자주 발생합니다.

이제 디자이너는 화면을 보고 디테일을 다듬고 싶어 합니다. 하지만 디자이너는 피그마에서 작업하길 원하죠. 선택지는 둘입니다. 앱 스크린샷을 피그마에 올리거나(당연하게도 비트맵이라 컴포넌트로 분해되지 않습니다), 코드를 HTML 목업으로 변환하고, 그 HTML을 다시 파싱(Parsing)해서 피그마 위에 컴포넌트 형태로 복원하거나죠. 후자를 택해도 역해석은 완벽하지 않습니다.

한 가지 흥미로운 점은 피그마는 outline과 border를 구분하지 않는다는 점입니다. Dev Mode는 stroke를 항상 border로 출력하기 때문에, 포커스 링처럼 outline이어야 할 요소가 border로 구현되고, 버튼 높이가 달라지는 식의 오차가 생깁니다. 디자이너에게는 어차피 테두리지만, 개발자에게는 레이아웃이 틀어지는 문제인데요. 디자인-개발 협업 도구를 자처하는 피그마가 그동안 개발자들을 고생시켜 온 이슈 중 하나입니다.

이런 어긋남이 쌓이면서 일부 컴포넌트는 형태만 비슷한 박스로 바뀌고, 디자이너는 그 어긋난 캔버스 위에서 다시 디자인해야 합니다. 개발자는 그 결과를 받아 다시 코드에 반영합니다. 일이 끝나고 보면, 두 사람 모두 본업이 아닌 일에 가장 많은 시간을 쓰고 있었습니다. 한 사람은 정확하지도 않은 역파싱 도구를 만들고, 다른 한 사람은 실물 스크린샷 위에 디자인을 다시 그리고 있습니다.

이 상황은 처음부터 양쪽이 코드 기반 위에서 일하기로 합의했다면 일어나지 않았을 일이죠. 이처럼 SSOT(Single Source of Truth)를 어디에 둘지 정하지 못한 결과, 양쪽이 그 원본을 매번 새로 만드느라 시간을 소비합니다.

'피그마 없이'의 정확한 의미

사실 해결의 방향은 단순합니다. 디자인 작업의 기준점을 피그마 캔버스에서 빼내고, 그 자리에 마크다운(Markdown), HTML, CSS를 두는 것이죠. 코드가 해석할 수 있는 일관되고 범용적인 규칙 기반으로 옮긴다는 뜻입니다.

다만, 디자이너가 프론트엔드 코드를 직접 짜야 한다는 뜻은 아닙니다. 여기서 말하는 "코드베이스(Codebase)"는 배포되는 자바스크립트나 컴포넌트 코드를 의미하지 않습니다. 디자인 시스템과 의도가 코드가 읽을 수 있는 형태로 정의되는 작업 기반을 가리키는 표현입니다.

작업은 이런 식으로 진행됩니다. "이 디자인 시스템을 DESIGN.md로 정리해줘", "Primary Color 변경을 md 문서에 반영해줘"와 같은 자연어 요청을 디자이너가 던지면, AI가 그것을 구조화된 규칙으로 바꾸고, 결과가 HTML/CSS로 즉시 렌더링되어 시안 역할을 합니다. 특정 도구를 고집할 필요는 없습니다. 자연어 의도를 코드 친화적인 기반으로 옮길 수 있는 환경이라면, 어떤 조합이든 같은 효과를 낼 수 있죠. 중요한 것은 도구의 이름이 아니라 작업 기반의 선택입니다.

캔버스 기반 워크플로우의 고질적인 문제는 따로 있는데요. 디자이너가 피그마에 시안을 그릴 때, 호버(Hover) 상태, 에러 상태, 빈 화면, 로딩 처리 같은 영역은 미처 그리지 못한 채 개발에 넘어오는 일이 반복됩니다. 미완성은 별도 코멘트로 표시되지 않은 채 개발자에게 도착하고, 코멘트가 없으면 빈자리는 그대로 코드가 됩니다. 없는 부분을 완성해 나가는 부담이 개발자에게 암묵적으로 넘어오는 거죠.

이 문제가 캔버스 기반에서 반복되는 이유는 구조 때문입니다. 피그마 캔버스는 화면의 '완성된 순간'만 담기에 최적화되어 있습니다. 하지만 코드는 완성된 순간이 아니라, 캔버스를 구조화해서 바라봅니다. 그렇기에 빌드 단계나 렌더링 결과처럼 어긋남을 즉시 렌더링 오류로 드러내죠. 반면, 피그마 캔버스는 구조화 누락이 있어도, 사람의 눈이 알아채기 전까지는 수면 위로 올라오지 않습니다.

핵심은 작업 기반의 엄격함이죠. 코드 기반 위에서는 어긋남이 즉시 드러나지만, 캔버스 위에서는 어긋남이 누적돼도 사람이 알아채기 전까지 보이지 않습니다. 그래서 AI와 잘 협업하려면, 코드가 필요합니다.

디자이너만의 이야기는 아닌 이유

이런 마찰은 사실 디자이너와 개발자만의 이야기가 아닙니다. 기획자는 노션(Notion)에 요구사항을 정리하고, 팀 리더는 지라(Jira)같은 도구로 일정을 관리합니다. 각자의 도구가 따로 있어서, 그 도구들 사이를 AI가 오가며 맥락을 잃게 됩니다.

그래서 AI에 "이 스프린트의 요구사항을 바탕으로 코드를 짜줘"라고 요청할 때, 요구사항이 노션(Notion)에, 디자인이 피그마에, 코드가 깃헙(GitHub)에 흩어져 있고, 그 데이터 양식이 모두 다르다면 어떨까요? AI는 매번 세 곳을 연결하는 통역사가 되어야 합니다. 통역이 늘어날수록 오차도 누적됩니다.

반면, 요구사항이 Spec.md로, 디자인 시스템이 DESIGN.md로 정리되어 있다면, AI는 하나의 기반 위에서 모든 맥락을 읽습니다. 기획자가 스펙 문서를 수정하면 그 변경이 곧바로 개발자의 컨텍스트가 됩니다. 별도의 전달 과정이 필요없죠. 이렇듯 코드 기반으로의 전환은 디자이너에게만 요구되는 변화가 아닙니다. 팀의 모든 작업이 AI가 읽을 수 있는 하나의 기반 위에 올라올 때, 비로소 AI는 협업의 중심에 설 수 있으니까요.

작업 기반을 바꾸면 ‘무엇’이 달라질까?

코드 기반으로 전환했을 때 가장 먼저 체감되는 변화는 바로 속도입니다.

캔버스 기반에서는 화면 하나를 만드는 데 며칠이 걸리는 사이클이 반복됩니다. 시안을 받고, 빈 부분을 묻고, 다시 받고, 코드로 옮기고, 디자이너가 QA(Quality Assurance)에서 디테일을 잡아주면 다시 수정하죠. 그런데 코드 기반에서는 같은 작업이 몇 시간 안에 끝납니다. 디자이너가 의도를 마크다운으로 정리하면 그것이 곧 시안이자 명세이고, 코드는 그 명세를 직접 참조하기 때문입니다. 사람의 손을 거치며 모호해지는 지점이 줄어듭니다.

자잘한 디자인 QA도 구조적으로 빨라집니다. AI에게 "패딩(padding) 4px만 늘려줘" 같은 요청을 했을 때 토큰(Token) 한 줄을 고치는 일이 됩니다. 기존에는 디자이너가 피그마에서 변경한 뒤 개발자가 코드 곳곳에 같은 값을 손으로 반영해야 했다면, 이제는 명세 한 줄을 바꾸는 것만으로 전역 테마 설정까지 일관되게 적용됩니다. 디자인 디테일이 구현 단계에서 누락되는 일도 거의 없고요. 원본이 한곳에 있고, 그 원본을 사람도 AI도 같이 보는 구조이기 때문입니다.

어려운 점: 피그마는 도구가 아니라 사고방식이다

이 전환 과정에서 가장 큰 저항은 디자이너의 적응입니다. 이 어려움은 기술적 문제가 아니죠.

터미널 화면을 처음 마주하는 디자이너의 반응은 대체로 비슷합니다. 검은 화면, 알 수 없는 명령어, 렌더링되지 않은 마크다운 텍스트의 기호들까지, "이건 개발자가 할 일이죠."라는 반응이 자연스럽게 나옵니다. HTML로 렌더링된 결과를 옆에 띄워도 어렵습니다. "텍스트 기반 규칙을 수정하고, 반영된 화면을 확인한다"는 사이클 자체가 너무 낯설기 때문입니다.

이 어려움은 단순한 학습 곡선이 아닙니다. 디자이너에게 피그마는 도구가 아니라, 사고의 방식이기 때문입니다. 화면 위에 요소를 놓아보고, 옆에 두어보고, 색을 입혀보고, 다시 빼보는 동작 자체가 디자이너의 사고 과정입니다. 그 과정을 텍스트 편집으로 옮기라는 것은 도구를 바꾸자는 제안이 아니라, 마치 작업 방식 자체를 만들어보자는 제안이죠. 그러니 그 무게를 처음부터 충분히 고려하고, 접근하는 것이 중요합니다.

이러한 저항을 줄이는 데 효과적인 접근은 두 가지입니다.

실효성을 직접 체감시키는 것. 며칠이 걸리던 QA가 몇 분 만에 반영되는 경험을 하거나, 의도한 디테일이 구현에서 누락되지 않는 것을 확인하면 새로운 기반에 대한 저항감이 떨어집니다.
시대적 맥락을 함께 공유하는 것. 이 방향이 특정 팀의 선택이 아니라, 업계 전체가 머지않아 마주할 흐름이라는 점을 함께 짚어갑니다.

도구를 강제하는 일보다는 변화의 방향을 함께 바라보는 일이 아무래도 다른 무게로 다가오지 않을까요?

새로운 패러다임을 맞이하는 자세

그렇다면 우리가 적극적으로 취해야 할 자세는 무엇일까요?

첫째, AI 시대의 협업은 도구가 아니라 작업 기반이 결정합니다. AI 도구를 더 정교하게 붙이는 일과 작업 기반 자체를 코드 쪽으로 옮기는 일은 같은 작업이 아닙니다. 피그마 MCP를 정교하게 다듬는 데 쓰는 시간 대부분은 결국 다리를 다듬는 작업입니다. 다리가 정교해진다고 강의 위치가 바뀌지는 않듯, 작업 기반 자체를 옮기는 시도에 시간을 써야 합니다.

둘째, 가장 익숙한 도구를 가장 먼저 의심해야 합니다. 피그마는 분명 좋은 도구입니다. 디자이너에게도, 개발자에게도 오랫동안 신뢰받아 온 환경이죠. 협업의 표준으로 자리 잡은 데는 분명 이유가 있습니다. 다만 "원래 이렇게 하는 거니까"라고 받아들이는 작업 방식 중에는 특정 시대의 제약이 만들어낸 것도 많습니다. 패러다임이 바뀔 때, 이 둘을 구분해 내는 일이 중요해 질겁니다.

마치며: 우리 팀에서 해볼 수 있는 작은 시도들

우리가 영화를 볼 때를 생각해 볼게요. 아무리 훌륭한 번역가가 열심히 자막을 달아도, 원어로 봐야만 그 영화를 온전히 이해할 수 있을 겁니다. 자막은 결국 번역자의 해석을 한 번 거친 결과물이기 때문입니다. 그런데 이제 원어로 봐야 할 이유가 생겼습니다. AI는 강력한 작업 도구이고, AI를 제대로 활용하려면, 결국 AI가 가장 잘 이해하는 언어인 ‘코드’로 작업하는 것이 유리하니까요. 그런데도 아직 많은 팀이 여전히 더 나은 자막을 붙이는 데 집중하고 있습니다. 피그마와 코드 사이에, Notion과 GitHub 사이에 더 정교한 번역 도구를 끼워 넣으면서요.

이 글의 결론을 단순화한다면 "피그마를 버리자" 가 될 수도 있죠. 하지만 그런 단순한 결론은 아닙니다. 피그마는 여전히 좋은 도구고, 당장 기존에 쓰던 도구들을 한 번에 옮기는 것이 모든 팀에게 최선도 아닐 거고요.

다만 프로덕트 메이커라면 한 번쯤 점검해 볼 만한 질문은 있습니다. “지금 팀의 작업이 하나의 기반 안에서 일어나고 있는가, 아니면 서로 다른 기반 위에서 일어나고 있는가?” 우리가 겪고 있는 병목이, 초기 인터넷 시대에 수신한 이메일을 출력해서 손으로 답장을 쓰고, 그 답장을 다시 스캔해서 이메일로 보내던 것과 같은 성격의 일은 아닌지 생각해 봐야 합니다.

AI 툴을 도입했는데도 협업이 빨라진 것 같지 않다면, 도구의 성능을 의심하기 전에 작업 기반의 정합성을 점검해 보세요. 당장 해볼 수 있는 작은 시도는 새로운 도구를 더 붙이기 전, 디자인 시스템을 마크다운 같은 코드 친화적 기반에 정의해 보는 겁니다. 그 작은 실험이 작업 기반 자체를 바꾸는 결정으로 이어질지, 아니면 기존 워크플로우의 보완 정도에서 끝날지는 팀마다 다를 거예요. 다만 그 실험을 해보지 않는다면, 답을 영영 알 수 없다는 것만큼은 분명하니까요.