솔직히 말하면, 저는 핸드오프 미팅을 항상 싫어했습니다. Figma 링크 공유하고, 스펙 문서 만들고, QA 단계에서 "여기 간격이 8px인데 코드는 10px이에요"라고 PR 반려하는 그 지루한 루프요. 그런데 최근 읽은 GeekNews의 프로덕트 디자인 변화 관련 글이 이 불만에 이름을 붙여줬습니다. "핸드오프 낭비(handoff waste)"라고요. 그리고 이 낭비가 지금 구조적으로 해체되고 있습니다.
병목은 항상 거기 있었다
Figma 목업을 프로덕션 코드로 '번역'하는 과정—이게 프론트엔드 개발자라면 누구나 알고 있는 진짜 병목입니다. 디자이너가 픽셀을 밀고, 개발자가 다른 매체에서 그걸 재현하려 하고, QA가 두 결과물을 비교합니다. Figma에서 볼 때는 완벽했는데 실제 구현하면 line-height가 조금 다르고, border-radius가 살짝 틀리고, 간격이 8px이어야 하는데 0.5rem이 되어버리는 그 순간들. 저만 밤새운 게 아니었을 겁니다.
기사에서 지적한 것처럼, Figma에서 밀어내는 모든 픽셀은 엔지니어가 완전히 다른 매체에서 지켜야 할 약속입니다. 그리고 도구 사이의 거리가 멀수록 그 약속은 깨질 가능성이 높아집니다.
Monday.com 케이스가 보여주는 현실
기사에서 소개된 Monday.com 엔지니어링팀 사례가 특히 날카롭습니다. Figma 링크를 Cursor에 그냥 붙여넣었더니 어떻게 됐냐고요? AI가 생성한 코드에서 디자인 시스템 컴포넌트는 통째로 무시됐고, 색상은 하드코딩됐고, 타이포그래피는 시스템 기본값을 덮어쓰고 있었습니다.
이거 보자마자 저도 뒤통수를 맞은 기분이었어요. AI가 코드를 못 짜서가 아닙니다. 컨텍스트가 없어서입니다. AI는 Figma 파일의 시각적 결과물만 보고 코드를 만들 뿐, 그 뒤에 있는 디자인 시스템의 토큰 체계나 컴포넌트 사용 규칙을 모릅니다. 결국 color: #1E40AF 같은 하드코딩이 튀어나오는 거죠. 디자인 토큰으로 --color-primary-700을 정성스럽게 정의해둔 게 순식간에 무용지물이 됩니다.
MCP가 연결하는 것: 컴포넌트 아키텍처와 AI
Monday.com의 해결책이 흥미롭습니다. 그들은 디자인 시스템 MCP(Model Context Protocol) 를 구축했습니다. 컴포넌트 목록, 디자인 토큰, 접근성 규칙, 사용 패턴을 머신 리더블한 형태로 만들고, 11개 노드의 에이전틱 워크플로우로 AI에게 구조화된 컨텍스트를 주입한 겁니다.
여기서 WebMCP 프로젝트와 연결점이 생깁니다. WebMCP(Web Meta Component Protocol)는 웹 컴포넌트의 생성과 상호작용을 표준화하려는 프로토콜인데, 결국 이 방향과 같은 문제를 다루고 있습니다. "컴포넌트의 의미와 규칙을 기계가 읽을 수 있게 만들자"는 거요. AI가 Figma 파일을 보는 게 아니라, 디자인 시스템의 스펙을 직접 읽게 만드는 것—이게 핸드오프 병목을 실제로 해소하는 구조입니다.
사실 이건 flexbox냐 grid냐를 고르는 문제가 아닙니다. 아키텍처 레벨의 전환입니다.
보이는 작업은 여전히 인간의 영역
그렇다고 AI가 다 해결해준다는 얘기는 아닙니다. 기사에서 "보이는 작업(visible work)"과 "보이지 않는 작업(invisible work)"을 구분한 부분이 저한테는 가장 핵심이었어요.
코드가 지저분해도 앱이 작동하면 사용자는 모릅니다. PRD가 AI로 생성됐어도 문제 정의가 정확하면 상관없습니다. 하지만 UI는 다릅니다. 사용자 입장에서는 버튼 하나의 hover 상태, 토스트 메시지의 등장 타이밍, 폼 에러 메시지의 위치 하나하나가 즉시 인지됩니다. Lighthouse 점수가 98이어도 애니메이션이 어색하면 사람들은 바로 느낍니다.
AI는 학습 데이터에 있는 패턴은 훌륭하게 따라가지만, 수십 건의 사용자 인터뷰와 히트맵 데이터, 경쟁사 감사 결과를 종합한 의사결정은 아직 컨텍스트가 너무 큽니다. 마이크로 인터랙션의 적절성, 컬러 대비의 감각적 판단, WCAG 2.1 AA 기준을 넘어서는 실제 접근성 경험—이건 여전히 인간이 책임져야 합니다.
디자인 시스템이 진짜 인프라가 된다
이 흐름에서 프론트엔드 개발자로서 가장 중요하게 봐야 할 시사점은 이겁니다. 디자인 시스템의 품질이 AI 출력의 품질을 결정한다는 것.
지금까지 Design Token이나 컴포넌트 문서화는 "좋으면 좋은" 수준의 작업이었습니다. 토큰 네이밍이 좀 지저분해도, Storybook 문서가 조금 불완전해도, 컴포넌트 사용 가이드가 없어도 어떻게든 굴러갔죠. 하지만 AI가 이 시스템을 직접 읽고 코드를 생성하는 구조에서는 다릅니다. 문서화가 없으면 AI가 하드코딩합니다. 규칙이 불명확하면 AI가 임의로 결정합니다. @layer로 레이어 구조를 명확히 잡아두지 않으면 AI가 생성한 스타일이 기존 시스템을 오버라이드합니다.
Container Queries나 :has() 같은 최신 CSS 기능을 디자인 시스템에 도입할 때도 마찬가지입니다. AI에게 "이 컴포넌트는 Container Query 기반으로 작성해"라고 말하려면 시스템 자체에 그 규칙이 명시적으로 존재해야 합니다.
전망: 오케스트레이터와 픽셀 푸셔의 격차
기사의 마지막 경고는 꽤 무겁습니다. "AI를 오케스트레이션하는 디자이너"와 "Figma에서 픽셀을 미는 디자이너" 사이의 격차가 12개월 내 막대해질 것이라고요. 프론트엔드 개발자도 다르지 않다고 생각합니다.
AI가 생성한 컴포넌트 코드를 리뷰할 수 있는가, 토큰이 잘못 매핑된 걸 감지할 수 있는가, MCP에 전달할 컨텍스트를 구조화할 수 있는가—이게 앞으로의 프론트엔드 역량 기준이 될 겁니다. 로딩 스켈레톤을 언제 넣어야 하는지, 트랜지션 duration이 200ms인지 300ms인지가 왜 다른지를 아는 감각. 이건 AI가 대체하기 어렵습니다.
번들 사이즈를 줄이고 Core Web Vitals를 개선하는 기술적 역량은 기본이고, 그 위에서 AI 출력을 비판적으로 평가하고 디자인 시스템을 머신 리더블하게 유지하는 역량이 추가됩니다. 핸드오프가 사라지는 건 좋은 일입니다. 하지만 그 자리를 채우는 건 더 높은 수준의 판단력이지, 더 적은 책임이 아닙니다.