AI가 내 디자인을 망치는 이유, 이제 알았다: Component.md가 답이다

"거의 맞는데 왜 틀리지?" 이 찝찝함, 저만 느끼는 게 아니었어요

Lovable로 화면 뽑고, Claude Code로 컴포넌트 만들고, Figma Make로 레이아웃 잡고. 요즘 AI 디자인 도구 써보지 않은 개발자나 PO가 없을 정도잖아요.

근데 막상 써보면 꼭 이런 느낌이 들어요. 폰트가 조금 이상하고, 여백이 몇 픽셀 어긋나고, 에러 상태에서 색상이 바뀌어야 하는데 안 바뀌고. "거의 맞는데, 정확히는 아닌" 그 묘한 찝찝함.

피그마 파일을 그대로 넘겼는데 왜 이런 일이 생기는 걸까요?

오늘은 디자인 시스템 전문가 Ian Guisard가 1년 넘게 직접 테스트하며 찾아낸 근본 원인과, 그 해결책인 Component.md 개념을 한국 개발팀 관점에서 풀어보려 해요.

피그마는 '진실'이 아니라 '정보'를 담는 곳이에요

많은 분들이 디자인 시스템과 컴포넌트 라이브러리를 같은 말로 쓰는데, 사실 둘은 달라요.

디자인 시스템은 "이 제품의 언어가 어떻게 작동하는가"를 정의하는 규칙의 집합이에요. 컴포넌트 라이브러리는 그 규칙으로 특정 시점에 만들어진 결과물이고요. 문법이 디자인 시스템이라면, 컴포넌트 라이브러리는 그 문법으로 쓴 문장이에요.

지금까지는 이 둘을 헷갈려도 괜찮았어요. 왜냐면 피그마 파일을 읽는 독자가 사람 개발자였거든요. 파일에 없는 내용, 포커스 상태에서 외곽선이 생긴다거나, 에러일 때 스크린 리더가 뭐라고 읽어야 한다거나, 이런 것들을 사람은 암묵적으로 채워 넣었어요.

그런데 지금은 독자가 바뀌었어요. AI 도구가 파일을 읽고 코드를 만들어냅니다. 중간에 사람이 없어요.

AI가 추측하는 곳이 품질이 무너지는 곳이에요

Ian은 Figma Make, Claude Design, Lovable, Claude Code를 자기 실제 피그마 파일로 1년 넘게 직접 돌려봤어요.

결론은 간단했습니다. 결과물은 항상 아슬아슬하게 맞아떨어지고, 그 차이를 고치는 데 처음 만드는 것보다 훨씬 많은 시간과 비용이 들었다는 것.

피그마 파일이 알려주는 건 이런 것들이에요. 레이어 구조, 색상값, 크기, 변형 종류, 간격. 이 정도는 잘 읽어요.

근데 피그마 파일이 절대 알려주지 못하는 것들이 있어요. 어떤 토큰이 어떤 상태에서 쓰이는지, 포커스가 어떻게 이동하는지, 에러 상태에서 뭘 보여줘야 하는지, 스크린 리더에게 어떻게 읽혀야 하는지. 이 정보들은 디자이너 머릿속에 있거나, 슬랙 대화에 흩어져 있거나, 코드 리뷰 코멘트 어딘가에 묻혀 있어요.

AI는 정보가 없으면 추측해요. 그 추측이 쌓이면 "비슷하지만 다른" 무언가가 나와요.

실제로 오늘의집 디자인팀이 공유한 사례를 보면, Figma MCP로 화면 하나 그리는 데 15분에서 20분이 걸렸는데, 숙련된 디자이너가 직접 하면 5분이면 됐다고 해요. 시간도 더 걸리고 정확도도 아쉬웠다는 거죠.

사람들이 모르는 것: 우리는 이미 '스펙 없는 인계'를 매일 하고 있어요

이 문제를 해결하려는 시도들은 이미 많아요. 피그마 화면 캡처를 프롬프트에 붙여 넣거나, Figma MCP로 프레임을 긁어오거나. 근데 이 우회책들이 생기는 이유 자체가 피그마가 사람을 위해 만들어진 파일이라는 데 있어요.

대부분의 디자인팀에서 진실의 원천은 여러 곳에 흩어져 있어요.

일부는 피그마에, 일부는 디자이너 머릿속에, 나머지는 슬랙 스레드와 코드 리뷰에. 이걸 대부분 문제로 인식하지 않아요. 사람끼리는 대화로 채울 수 있으니까요. 하지만 AI에게는 그게 지뢰밭을 건너라는 것과 같아요.

그래서 Component.md가 뭔가요?

Ian이 제안하는 건 단순해요. 컴포넌트 하나당 마크다운 파일 하나. 피그마가 절대 담지 못했던 정보들을 텍스트로 저장하는 거예요.

이 파일에 들어가는 건 다섯 가지예요.

첫째, API 사양이에요. 이 컴포넌트가 어떤 속성을 받고, 어떻게 조합해서 쓰는지를 정의해요.

둘째, 구조 사양이에요. 크기, 간격, 밀도에 따라 값이 어떻게 달라지는지 명시해요.

셋째, 색상 할당이에요. 어떤 상태에서 어떤 토큰을 써야 하는지를 표 형태로 담아요.

넷째, 접근성 사양이에요. 포커스 순서, 스크린 리더 안내 방식, 플랫폼별 차이를 적어요.

다섯째, 동작 사양이에요. 닫힘 규칙, 에러 상태, 빈 상태가 뭘 해야 하는지를 정의해요.

마크다운이기 때문에 어떤 LLM도 읽을 수 있어요. Claude Code든, Cursor든, Lovable이든, 이 파일 하나만 넘겨주면 추측 없이 구현이 가능해져요.

이게 왜 혁신적이냐고요? 사람도 읽고 AI도 읽는 하나의 파일이에요

기존 정적 문서 사이트들은 독자가 20분을 투자해서 읽을 사람이라는 가정 위에 만들어졌어요. 이 가정이 이제 무너졌어요.

독자는 맥락이 없는 AI 도구일 수도 있고, 특정 질문 하나만 있는 개발자일 수도 있어요.

Component.md는 이 두 독자를 동시에 만족시켜요. "스택 버튼 그룹에서 액션 순서가 어떻게 되나요?"라고 개발자가 물어도, AI 도구가 구현 스펙을 달라고 해도, 같은 파일이 답을 줘요.

2026년 들어 이 흐름은 더 빠르게 커지고 있어요. Google Labs가 Stitch 프로젝트에서 DESIGN.md라는 유사한 개념을 공개했고, W3C Design Tokens Community Group은 2025년 10월에 첫 안정 버전 스펙을 발표하며 Figma에서 JSON, CSS로 이어지는 변환 파이프라인을 공식 지원하기 시작했어요. Figma, Sketch, Framer 등 10개 이상의 도구가 이 스펙을 지원하거나 구현 중이에요.

스펙은 인터페이스예요. 사람도 질문할 수 있고 AI도 빌드할 수 있는 공통 언어가 된다는 거죠.

추출과 추론을 분리하면 환각이 사라져요

Ian의 uSpec 2.0은 두 단계로 작동해요.

첫 번째는 추출이에요. uSpec 피그마 플러그인이 컴포넌트를 돌면서 레이아웃, 변형, 토큰, 레이어 트리 등 피그마 파일이 줄 수 있는 정보를 전부 JSON으로 뽑아내요. 이건 스크립트가 해요. AI가 할 필요가 없는 단계예요.

두 번째는 추론이에요. 추출된 데이터를 구조 담당, 색상 담당, 접근성 담당 에이전트들이 병렬로 나눠서 각자의 영역을 추론해요. 그리고 최종적으로 하나의 component.md로 합쳐져요.

핵심 원칙은 이거예요. AI는 추론이 필요한 곳에서만 작동한다는 거예요. 숫자를 뽑는 건 스크립트가 하고, 그 숫자가 무엇을 의미하는지 해석하는 것만 AI가 맡아요.

예를 들면 이래요. 피그마에서 "leading content: true, subcomponent: icon"으로 표현되는 걸 기계적으로 추출하면 그냥 그대로 나와요. 근데 AI가 추론하면 "leadingContent: 'icon' | 'image' | 'text' | 'none'"이라는 코드에서 바로 쓸 수 있는 enum 형태로 변환돼요. 이 차이가 구현 품질의 차이예요.

추출 없이 추론하면 환각이고, 추론 없이 추출하면 데이터 덤프예요.

디자인 팀장이 아니어도 지금 당장 고민해야 할 질문

Ian이 던지는 질문이 있어요. "1년 후에도 당신의 컴포넌트는 사람만 읽을 수 있는 상태인가요?"

이건 디자이너만의 질문이 아니에요. PO도, 개발 리드도, CTO도 마찬가지예요.

지금까지 우리는 피그마 파일 만들고, 개발자가 보면서 코드 짜는 사이에 수많은 구두 전달과 "당연히 알겠지"가 있었어요. AI 도구가 그 해석 레이어를 맡기 시작하면서 그 암묵적 지식들이 전부 문제로 드러나고 있어요.

건축으로 비유하면 이래요. 건축가는 스케치로 아이디어를 낸 다음 도면을 만들어요. 시공업체는 스케치가 아니라 도면을 보고 건물을 지어요. 피그마는 스케치예요. Component.md가 도면이에요. AI는 도면을 보고 건물 짓는 시공업체고요.

설계도 없이 AI에게 건물 맡기면, 거의 맞는 건물이 들어서는 건 당연한 거예요.

앞으로 어떻게 달라질까요?

uSpec 2.0은 오픈소스로 공개됐어요. uspec.design에서 문서를 볼 수 있고 GitHub에서 코드도 직접 확인할 수 있어요.

Google Stitch의 DESIGN.md, Ian의 Component.md, W3C 토큰 스펙, 이 세 흐름이 2026년을 기점으로 수렴하고 있어요. 방향은 하나예요. 디자인 시스템의 독자가 두 배가 됐다는 것. 사람과 AI 도구, 둘 다를 위한 시스템이 필요해졌어요.

AI 도구의 품질 한계는 모델 쪽에서 결정되지 않아요. 디자인 시스템 쪽에서 결정돼요.

지금 당장 실무에 적용해보고 싶다면, 자주 구현 실수가 나오는 컴포넌트 하나를 골라서 Component.md를 시범 작성해보세요. 색상 토큰, 에러 상태, 접근성 사양을 마크다운으로 정리하는 것부터 시작하면 돼요. 그 파일 하나가 다음번 AI 도구와의 인계를 얼마나 다르게 만드는지 직접 느낄 수 있을 거예요.

마무리

디자인 시스템은 항상 언어였어요. 이제 그 언어는 사람만 아니라 AI도 읽어야 해요.

피그마는 아이디어를 다듬는 스튜디오로 남고, Component.md가 모든 구현자가 읽는 설계도가 돼요. AI 도구가 "거의 맞는데 틀린" 결과를 내는 건 모델이 부족해서가 아니에요. 읽을 스펙이 없어서예요.

스펙을 만드는 것, 그게 지금 디자인 시스템 팀이 해야 할 가장 중요한 일이에요. 그리고 솔직히, AI 도구를 진지하게 쓰는 모든 팀이 고민해야 할 질문이기도 해요.

지금 여러분의 디자인 시스템, AI가 읽을 수 있는 상태인가요?