AI 디자인 도구, 프롬프트보다 구조가 품질을 결정한다

프롬프트를 정교하게 다듬으면 AI 출력 품질이 좋아질 거라고 믿는 팀이 많다. CLAUDE.md에 디자인 시스템 규칙을 빼곡히 적고, 컴포넌트 사용법을 자세히 설명하고, 금지 사항까지 명시한다. 그런데 실측 데이터는 전혀 다른 이야기를 한다.

Dev.to에 공개된 James Coombs의 연구 'Told vs Known'은 60개 컴포넌트로 구성된 디자인 시스템을 기준으로 6가지 유형의 AI 디자인-투-코드 도구를 통제된 ablation study(n=9)로 비교했다. 결론은 단순하고 날카롭다. AI 출력 품질을 결정하는 단일 변수는 AI가 디자인 시스템에 대해 '설명을 들었느냐(Told)'가 아니라 '직접 알고 있느냐(Known)'였다.

'Told'와 'Known'의 차이는 점진적이지 않다

'Told' 방식은 자연어 문서, 상세한 프롬프트, 가이드라인 파일로 AI에게 디자인 시스템을 설명한다. AI는 이를 해석해서 코드를 생성한다. 문제는 이 '해석' 단계마다 드리프트가 누적된다는 점이다. variant='primary'라고 알려줬는데 실제 API는 variant='default'일 수 있고, 팀의 바이올렛 팔레트가 일반적인 파란색으로 대체될 수 있다. 결정적으로, AI는 실제로 존재하지 않는 컴포넌트를 그럴듯하게 만들어낸다. 이게 진짜 위험이다. 명백히 틀린 코드는 바로 다시 쓴다. 그럴듯하게 틀린 코드는 리뷰를 통과하고 머지된다.

'Known' 방식은 AI가 실제 소스를 구조화된 인터페이스로 직접 조회한다. 컴포넌트의 정확한 이름, 정확한 props, 정확한 import 경로, 실제 사용 예시를 해석 없이 가져온다. 연구 데이터에서 두 방식의 점수 차이는 이렇다.

프롬프트 거버넌스 파일과 아무 가이드도 없는 경우의 점수가 사실상 동일하다는 것이 핵심이다. 더 많은 제약을 추가할수록 오히려 출력 품질이 떨어지는 '밀도 역전' 현상도 확인됐다. 정성껏 작성한 CLAUDE.md가 11점 차이로 MCP 구조화 쿼리에 패배한다.

세 가지 'Known' 구현 경로

구조적 접근에는 세 가지 경로가 있고, 각각 트레이드오프가 다르다.

AST 파싱 컴포넌트 인덱스는 TypeScript 소스를 파싱해서 컴포넌트명, prop 타입, 변형(variant), 토큰을 구조화된 인덱스로 만든다. 빌드 시 자동 재생성되므로 최신 상태를 유지하지만, Dialog와 Sheet 중 언제 어느 것을 써야 하는지 같은 '의도'는 담지 못한다.

Figma Code Connect 방식은 Figma 컴포넌트를 React 컴포넌트에 수동으로 매핑한다. 정의상 100% 정확도지만, 새 컴포넌트나 변형이 생길 때마다 수동 업데이트가 필요하다. 컴포넌트 수에 비례해서 유지보수 비용이 선형적으로 늘어난다.

AI 에이전트 + MCP 서버는 에이전트에게 쿼리 인터페이스를 제공한다. 에이전트가 추측하는 대신 검색으로 컴포넌트를 발견한다. "파일 업로드를 처리하는 컴포넌트가 뭐야?" 같은 탐색적 질문도 가능하다. MCP 서버를 한 번 구축하면 현재와 미래의 모든 AI 도구가 혜택을 받는다. Coombs는 이 서버를 구축하는 데 약 1주일이 걸렸다고 밝혔다.

API 문서도 '설명'이 아닌 '구조'여야 한다

이 문제는 디자인 시스템에만 국한되지 않는다. Dev.to의 또 다른 실무 사례는 동일한 원리가 API 설계에서 얼마나 치명적으로 작동하는지 보여준다. 한 MCP 기반 헬프데스크 서비스는 create_ticket이 숫자 id를 반환하는데 get_ticket_context는 문자열 id를 요구하는 타입 불일치를 수개월간 발견하지 못했다. 121개 가능한 툴 체인 중 107개가 이 문제로 깨져 있었다.

더 아이러니한 부분은 API 문서 자체가 "list_tickets가 반환한 id를 그대로 전달하라"고 안내하고 있었다는 것이다. 인간 개발자는 id를 클릭으로 처리하고 방어적 형변환 코드를 테스트에 넣기 때문에 문제를 눈치채지 못했다. 에이전트는 문서를 문자 그대로 따랐고, 그 결과 문서가 적극적으로 실패를 유도하는 셈이 됐다. 에이전트는 지금까지 존재했던 API 소비자 중 가장 문자 그대로(literal) 동작하는 존재다. 문서가 '설명'이 아닌 '계약'으로 설계되지 않으면, 에이전트는 그 허점을 가차없이 드러낸다.

런타임도 구조의 문제다: Bun과 Claude Code

'구조가 먼저'라는 원칙은 도구 선택에도 적용된다. Anthropic이 Claude Code를 Node.js가 아닌 Bun 위에 구축한 결정은 이 맥락에서 읽힌다. CLI는 서버와 달리 하루에도 수십 번 콜드 스타트가 발생한다. Bun의 5~15ms 스타트업 타임은 Node.js의 50~80ms와 비교할 때 단순한 성능 수치가 아니라 '도구가 무겁다는 느낌'을 제거하는 UX 결정이다. TypeScript를 컴파일 없이 직접 실행하고, bun build --compile로 자기 완결적 바이너리를 생성하는 구조는 배포 파이프라인을 단순화한다. 런타임 선택 역시 "이 도구가 어떤 구조로 운영될 것인가"를 먼저 설계한 결과다.

시사점: AI 워크플로우 설계의 순서를 바꿔라

세 사례가 하나의 방향을 가리킨다. AI 도구의 출력 품질을 높이려 할 때 프롬프트 개선은 마지막 수단이어야 한다. 설계 순서는 이래야 한다.

1. 구조화된 컨텍스트 소스를 먼저 만든다. 디자인 시스템이라면 MCP 서버나 AST 인덱스, API라면 타입 안전한 스키마와 라운드트립 테스트.
2. AI가 추측하지 않고 조회할 수 있는 인터페이스를 설계한다. 에이전트가 '알아야 할 것'을 문서로 설명하는 대신, 에이전트가 실시간으로 질의할 수 있는 구조를 제공한다.
3. 프롬프트와 가이드라인은 이 구조 위에서 최소한으로 운용한다. 데이터가 보여주듯, 규칙 파일의 밀도를 높이는 것은 효과가 없거나 역효과다.

이 원칙은 비용 효율도 좋다. MCP 서버는 한 번 구축하면 Cursor든, v0든, 미래에 등장할 어떤 AI 도구든 동일한 구조화된 컨텍스트를 공유한다. 도구별로 프롬프트를 튜닝하는 비용이 구조 투자 비용으로 대체되고, 그 투자는 매번 새 도구가 연결될수록 상각된다.

디자인-개발 협업에서 AI의 역할을 탐구하는 팀이라면 질문 순서를 바꿔야 한다. "이 AI 도구에 어떻게 설명할까"가 아니라, "이 AI 도구가 우리 시스템을 직접 알 수 있는 구조를 갖추고 있는가"를 먼저 물어야 한다. 더 나은 프롬프트는 더 나은 구조를 대체하지 못한다.