James Coombs는 구조화된 쿼리 서버를 갖춘 60개 컴포넌트 디자인 시스템을 구축하고, 이를 기준으로 AI 도구의 충실도(fidelity)를 측정하는 통제된 절제 연구(ablation study, n=9)를 수행한 디자인 엔지니어입니다.

60개 컴포넌트 디자인 시스템을 기준으로 6가지 범주의 AI 디자인-투-코드(design-to-code) 도구를 평가한 결과, 그 어떤 것보다 출력 품질을 더 잘 예측하는 단 하나의 변수가 있었습니다. 그것은 바로 도구가 디자인 시스템에 대해 말해졌는지(told) 아니면 그것을 알고 있는지(knew) 여부였습니다.

"말해준(Told)" 도구: 사용자가 자연어(natural language)나 문서로 컴포넌트를 설명합니다. AI는 이를 해석합니다. AI는 당신의 Button과 비슷해 보이는 것을 생성하지만, 잘못된 prop 이름, 잘못된 import 경로, 또는 그럴듯하지만 존재하지 않는 variant를 사용합니다.

"알고 있는(Known)" 도구: AI가 실제 컴포넌트의 구조화된 인덱스(structured index)를 쿼리합니다. AI는 정확한 이름, 정확한 props, 정확한 import, 정확한 사용 예시를 가져옵니다. 해석의 간극(interpretation gap)이 없습니다.

"Told"와 "Known" 사이의 간극은 점진적인 것이 아닙니다. 그것은 범주적(categorical)입니다.

"Told"가 실패하는 이유

AI에게 "variant='primary'를 사용하여 우리의 Button 컴포넌트를 사용해줘"라고 말하면, AI는 기본(primary) 버튼처럼 보이는 무언가를 생성합니다. 당신의 컴포넌트를 사용할 수도 있고, 일반적인 라이브러리의 것을 사용할 수도 있습니다. variant='primary'가 유효한 prop일 수도 있고, 당신의 API는 variant='default'를 사용할 수도 있습니다. 당신의 보라색 팔레트를 적용할 수도 있고, 일반적인 파란색을 적용할 수도 있습니다.

각 단계마다 해석의 드리프트(interpretation drift)가 발생합니다. 출력이 엔지니어에게 도달할 때쯤이면, 디자인 리뷰를 통과할 만큼은 비슷해 보이지만 재작성이 필요할 만큼은 틀린 상태가 됩니다.

더 나쁜 점은, "Told" 도구는 존재하지 않는 컴포넌트를 환각(hallucinate)한다는 것입니다. 이들은 비슷하지만 틀린 prop 이름을 사용합니다. 그럴듯해 보이지만 당신의 시스템에는 없는 토큰(token)을 적용합니다. 이는 명백하게 틀린 출력보다 더 나쁩니다. 명백하게 틀린 것은 재작성됩니다. 하지만 그럴듯하게 틀린 것은 그대로 병합(merged)됩니다.

그리고 당신의 디자인 시스템(design system)은 변경됩니다. 컴포넌트(Components)에는 새로운 변형(variants)이 생기고, 토큰(tokens)의 이름이 바뀝니다. "말해준(Told)" 도구들은 자신들의 학습 데이터(training data)에 들어있던 버전을 그대로 가지고 있습니다. 반면 "알고 있는(Known)" 도구들은 현재 상태를 쿼리(query)합니다.

세 가지 "알고 있는(Known)" 접근 방식

AST 파싱된 컴포넌트 인덱스 (AST-parsed component index). 소스 코드를 구조화된 인덱스로 파싱합니다: 컴포넌트 이름, 속성 타입(prop types, TypeScript 기준), 변형(variants), 토큰(tokens) 등입니다. 빌드 시점에 재생성됩니다. 구조는 포착하지만 의도(intent)는 포착하지 못합니다. 즉, Dialog와 Sheet 중 언제 무엇을 사용해야 하는지는 알지 못합니다.

수동 매핑된 컴포넌트 브릿지 (Figma Code Connect). 각 Figma 컴포넌트를 그에 대응하는 React 컴포넌트에 수동으로 매핑합니다. 정의상 100%의 충실도(fidelity)를 보장합니다. 하지만 수동 유지보수가 필요합니다. 새로운 컴포넌트나 변형이 생길 때마다 업데이트가 필요하며, 컴포넌트 수에 따라 선형적으로 규모가 커집니다.

AI 에이전트 + 구조화된 쿼리 (MCP server). 에이전트에게 쿼리 인터페이스(query interface)를 제공합니다. 에이전트는 추측하는 것이 아니라 검색을 통해 컴포넌트를 찾아냅니다. 미리 구축된 인덱스가 필요 없습니다. 단순 조회를 넘어 탐색("파일 업로드는 무엇으로 처리하나요?")에도 작동합니다. 인터페이스를 한 번만 구축하면 현재와 미래의 모든 AI 도구가 그 혜택을 누릴 수 있습니다.

데이터

저의 절제 연구(ablation study, n=9, 통제 환경)는 이를 확인해 주었습니다:

• 에이전트 + MCP 쿼리 (Known): 디자인 시스템 준수율 27.5 / 30
• AI 디자인 도구 해석 (Told): 16.3 / 30
• CLAUDE.md 규칙 ("항상 디자인 시스템을 사용하세요"): 16.1 / 30, 가이드가 없는 경우와 동일함

MCP 서버를 구축하는 데 약 일주일이 걸렸습니다. 이는 모든 AI 도구에 실제 디자인 시스템에 대한 구조화된 접근 권한을 부여합니다. 연결되는 새로운 도구가 늘어날수록 도구당 비용 분담(cost-per-tool amortization)은 개선됩니다.

"말해준(Told)" 방식이 괜찮은 경우

70%의 충실도가 목표인 일회성 프로토타입(Throwaway prototypes). 아직 디자인 시스템이 없는 상태에서의 초기 탐색(Greenfield exploration). 브랜드 충실도가 중요하지 않은 제품 데모.

"알고 있는(Known)" 방식이 필요한 경우

프로덕션 코드 생성(Production code generation). "비슷하지만 틀린" 임포트(import)가 명백히 틀린 것보다 더 해로운 디자인 시스템 마이그레이션. 그럴듯하게 틀린 출력이 병합(merged)될 수 있는 다인원 팀. 당신의 보라색(violet)이 다른 이의 보라색(purple)과 같지 않은, 브랜드가 매우 중요한 영역.

실질적인 시사점

어떤 AI 디자인 도구(AI design tool)를 평가하기 전에, 한 가지 질문을 던져보세요. 이 도구가 나의 실제 컴포넌트(components)를 쿼리(query)하는가, 아니면 추측하는가?

만약 당신의 팀이 실제 프로덕션(production)에 투입될 AI 코드를 생성한다면, 구조화된 쿼리 인터페이스(structured query interface)에 투자하세요. MCP 서버, CLI 도구, AST 인덱스(AST index) 등 그 형태(form factor)는 중요하지 않습니다. 중요한 것은 구조화된 접근(structured access)입니다. 한 번 구축해 두면 모든 AI 도구가 그 혜택을 입게 됩니다. 그 수익은 복리로 쌓입니다.

더 나은 문서를 작성하거나 더 상세한 프롬프트(prompts)를 작성함으로써 "말해준 것(Told)"의 충실도(fidelity)를 높이려 하지 마세요. 내 데이터에 따르면, 제약 조건(constraints)이 많아질수록 오히려 출력 품질이 저하됩니다 (밀도 역전(density inversion); 전체 방법론은 "Your CLAUDE.md Rules Achieve 0% Compliance"를 참조하세요). 2문장으로 구성된 프롬프트와 구조화된 쿼리의 조합은 포괄적인 거버넌스 파일(governance file)보다 11포인트 더 높은 성과를 보여줍니다.