디자인이 코드가 되는 시간이 '분' 단위로 줄었다
Figma 파일을 열고, MCP(Model Context Protocol)로 연결된 Cursor에게 레이아웃 구조와 디자인 토큰을 넘긴다. 몇 분 후 컴포넌트 코드가 에디터에 펼쳐진다. dev.to의 한 글이 묘사하는 이 장면은 더 이상 미래가 아니다. MCP는 단순한 도구가 아니라 AI 모델이 Figma의 레이아웃·색상·간격·타이포그래피 정보를 구조화된 방식으로 읽어들이는 프로토콜이다. 스크린샷을 보고 추측하던 시대에서, 설계 의도를 직접 해석하는 시대로 전환점이 당겨지고 있다.
그런데 '잘 만들어진 것처럼 보이는 코드'가 진짜 문제다
속도가 빨라질수록 오히려 더 선명해지는 위험이 있다. AI 보조 개발 워크플로우를 다룬 또 다른 글은 이것을 '거짓 자신감(False Confidence)'이라고 정확히 짚는다. 읽기 좋은 코드가 반드시 올바른 코드는 아니다. 빠른 진척이 반드시 실질적인 진척도 아니다. Cursor가 생성한 컴포넌트는 시각적으로 완벽해 보일 수 있다. 하지만 엣지 케이스, 퍼포먼스 가정, 비즈니스 컨텍스트—이 세 가지는 AI가 프롬프트에서 읽어낼 수 없다. 이 공백을 메우는 것은 여전히 개발자의 판단이다.
접근성은 '프론트엔드 티켓'이 아니라 '전사 설계'의 문제다
가장 날카로운 문제 제기는 접근성 책임 분산에서 나온다. 웹 접근성 책임 주체를 다룬 글은 냉정하게 선언한다. "접근성의 첫 언급이 프론트엔드 티켓에서 시작된다면, 진짜 접근성은 결코 달성될 수 없다." Figma→코드 자동화가 빨라진다고 해서 이 구조적 문제가 해결되지는 않는다. 오히려 악화될 수 있다. AI가 Figma 디자인을 그대로 코드로 옮긴다는 것은, 디자인 단계에서 누락된 접근성 고려가 코드 단계에서도 그대로 누락된다는 의미이기 때문이다.
실제 현장에서 접근성은 흔히 WCAG 2.x 준수라는 한 줄 체크박스로 처리된다. 그러나 진짜 접근성은 요구사항 정의, DB 설계(대체 텍스트 저장 필드 존재 여부), 콘텐츠 전략, 디자인 시스템, 개발, 테스트 전 단계에 걸쳐 협업으로만 완성된다. MCP가 Figma의 컴포넌트 구조를 읽는다 해도, 그 구조 안에 WAI-ARIA 상태가 설계되어 있지 않다면 자동 생성 코드는 시각적 완성도만 담보할 뿐이다.
AI는 코파일럿이지 오토파일럿이 아니다—이 명제의 실질적 의미
AI 보조 개발 워크플로우를 분석한 글은 유용한 프레임을 제공한다. AI를 '엄청나게 빠르지만 컨텍스트를 모르는 주니어 개발자'로 바라보는 것. 이 비유는 Figma→코드 자동화 맥락에서 더 구체적인 의미를 갖는다. AI는 디자인 토큰을 코드로 정확히 변환할 수 있다. 하지만 이 버튼이 키보드로도 접근 가능해야 하는지, 이 모달이 포커스 트랩을 구현해야 하는지, 이 이미지에 의미 있는 alt가 필요한지—이 판단들은 프롬프트 밖에 있다. '내가 설명할 수 없는 코드는 배포하지 않는다'는 원칙이 자동화 시대에도 변하지 않는 이유다.
시사점: 자동화가 빨라질수록 '판단의 게이트'를 앞당겨야 한다
MCP+Cursor 워크플로우가 성숙해질수록, 품질과 접근성의 책임 구조를 재설계해야 한다는 압력도 함께 커진다. 세 가지 실천 방향을 제안한다.
첫째, 접근성 요구사항을 Figma 단계에서 명문화한다. AI가 읽는 것은 Figma다. 디자인 단계에서 포커스 순서, 색상 대비, 상태 레이블이 정의되어야 자동 생성 코드에도 반영될 가능성이 생긴다.
둘째, 코드 리뷰의 기준을 '시각적 일치'에서 '접근성 트리 검증'으로 확장한다. AI가 생성한 코드는 디자인과 픽셀 단위로 일치할 수 있다. 그러나 스크린 리더가 읽는 접근성 트리는 별도로 검증해야 한다.
셋째, AI 생성 코드에 대한 '설명 책임'을 팀 컨벤션으로 명시한다. 속도가 빠를수록 '왜 이렇게 구현했는가'를 설명하지 못한 채 배포하는 유혹이 커진다. 이해하지 못한 코드를 배포하지 않는다는 원칙은 자동화 시대의 가장 기본적인 품질 게이트다.
전망: 자동화는 책임을 제거하지 않고 재분배한다
Figma→코드 자동화의 성숙은 피할 수 없다. MCP 프로토콜이 더 정교해지고, AI가 디자인 의도를 더 정확하게 해석할수록, 반복 구현의 시간은 계속 줄어들 것이다. 그러나 이 흐름이 가리키는 것은 개발자의 역할 소멸이 아니다. 판단의 위치 이동이다. 구현 속도가 자동화될수록, 개발자의 가치는 '무엇을 만들었는가'보다 '왜 이렇게 만들어야 했는가'를 설명하고 검증하는 능력으로 이동한다. 접근성도, 성능도, 아키텍처 결정도—AI가 제안하고 사람이 소유하는 구조는 앞으로도 바뀌지 않는다. 자동화가 빨라질수록 '판단하는 사람'의 책임은 오히려 더 무거워진다.