AI에 브랜드를 넘기는 세 가지 방법, 그리고 토큰 92% 차이
모델 선택, MCP 연결, 마크다운 한 장. 방법은 늘었는데 결과를 가르는 건 따로 있어요. Atlassian이 실측한 숫자와 피그마 MCP 세팅법까지.

브랜드 하나를 파일 한 장에 담아 AI에게 넘길 수 있을까요. 색상과 타이포와 컴포넌트 규칙을 적어두면 AI가 우리 브랜드처럼 만들어줄까요.
2026년 상반기에 이 질문에 답하려는 시도가 세 갈래로 나왔습니다. 그리고 셋 다 같은 곳에서 막혔습니다.
첫 번째 · 모델을 고르게 하는 방식
피그마의 프롬프트투코드 툴 Make는 원래 앤트로픽의 Claude 4.6과 구글의 Gemini 3 중에서 모델을 고를 수 있었습니다. 여기에 OpenAI가 7월에 정식 출시한 GPT-5.6이 더해지면서 선택지가 셋으로 늘었고요. 피그마는 이 모델이 첫 시도의 결과물 품질과 속도를 함께 끌어올렸다고 밝혔습니다. 특히 강조한 건 빌드 중 오류가 나면 멈추지 않고 스스로 원인을 찾아 고치는 셀프 힐링이었는데요. 별도 마이그레이션 없이 모든 요금제에 바로 적용됐습니다. (Figma Blog · OpenAI)
여기서 흥미로운 건 GPT-5.6의 성능이 아니라 피그마가 판을 짠 방식입니다. 3대 모델 회사가 각자 신모델을 낼 때마다 피그마는 그걸 자기 툴에 끼워 넣는 자리에 서 있습니다. 자체 파운데이션 모델을 만드는 대신 캔버스라는 인터페이스를 쥐고, 그 위에 여러 회사의 최신 모델을 갈아 끼우는 쪽을 택한 것이죠. 어느 회사가 다음 라운드를 이기든 피그마는 그 결과물을 자기 캔버스로 끌어오면 됩니다. 제법 영리한 자리입니다.
다만 이 구도가 디자이너에게 떠넘기는 숙제도 있습니다. 이제 툴 하나 안에서도 “이 작업엔 어느 모델”을 판단해야 하거든요. 평균 일곱 개 도구를 쓰면서 아직 주력을 못 정한 상황에, 도구 선택 피로 위에 모델 선택 피로가 한 겹 더 쌓인 셈입니다. 그리고 품질과 속도가 좋아졌다는 말은 결국 벤더의 자체 평가입니다. 실제로 내 프로젝트에 어떤 모델이 맞는지는 직접 나란히 돌려봐야 알 수 있습니다.
두 번째 · 파일을 직접 읽게 하는 방식
모델을 고르는 것보다 근본적인 접근이 있습니다. AI가 피그마 파일을 직접 읽게 하는 겁니다.
피그마 Dev Mode MCP 서버가 그 통로입니다. 컴포넌트와 변수, 레이아웃 정보를 읽고 선택한 프레임에서 코드를 뽑아낼 수 있고요. Claude Code, Cursor, VS Code, Codex, Gemini CLI처럼 MCP를 지원하는 툴이면 모두 대상입니다. (Figma Help Center)
서버는 두 갈래입니다. 원격 서버는 모든 플랜과 시트에서 쓸 수 있고 로컬 설치가 필요 없습니다. 데스크톱 서버는 Professional 이상 유료 플랜의 Dev 또는 Full 시트에서만 열리고요. 연결 자체는 어렵지 않습니다. Claude Code 기준으로 터미널에 다음 한 줄이면 끝납니다.
claude mcp add --transport http figma https://mcp.figma.com/mcp
(Claude Code and Figma - Figma Help Center)
지금은 베타라 스타터 플랜을 포함해 무료입니다. 다만 호출 한도는 시트마다 갈립니다. 뷰어와 협업 시트는 월 호출 수가 크게 제한되고, Dev와 Full 유료 시트라야 넉넉한 분당 한도를 받고요. (Rate limits & access - Figma Developer Docs)
그런데 여기서 문제가 생깁니다. 연결은 쉬운데 결과가 갈리거든요.
MCP는 피그마 파일에 있는 것을 있는 그대로 넘깁니다. 레이어명이 “Frame 482”, “Group 17”처럼 정리가 안 돼 있고 컴포넌트와 오토레이아웃, 스타일 변수 없이 쌓아 올린 파일이라면 AI도 거기서 의미를 읽어내지 못합니다. 반대로 컴포넌트와 변수가 체계적으로 잡힌 디자인 시스템이라면 같은 MCP로도 결과물이 눈에 띄게 달라집니다. 도구가 새로 생겼다기보다는, 원래 있던 격차가 이제 코드 품질이라는 형태로 곧바로 드러나는 것에 가깝습니다. 핸드오프라는 단계가 사라지는 흐름과 정확히 같은 지점을 가리키는 이야기죠. 시안을 넘기는 단계가 없어지면 평소에 파일을 얼마나 깔끔하게 관리했는지가 곧 결과물의 품질이 됩니다. 잘 정리된 파일은 자산이고, 정리 안 된 파일은 이제 숨길 곳이 없는 부채가 되고요.
세 번째 · 문서 한 장으로 넘기는 방식
세 번째는 가장 가볍습니다. DESIGN.md는 구글이 자사 AI 디자인 툴 Stitch를 위해 만든 파일 포맷입니다. 색상과 타이포, 간격, 컴포넌트 같은 브랜드 정보를 AI 에이전트가 읽을 수 있는 형태로 정리해두는 방식인데요. 2026년 4월 오픈소스로 공개됐습니다. (Google) 이후 Vercel, Resend, Clerk, Mintlify, Nuxt, Atlassian 같은 회사들이 잇따라 자사 DESIGN.md를 공개하며 상반기의 눈에 띄는 흐름이 됐고요.
그런데 정작 이 방식을 직접 실측해 본 회사의 결론은 달랐습니다. Atlassian이 로그인 화면 하나를 만드는 과제에서 DESIGN.md만 단독으로 줬더니, 자사가 구축한 MCP 서버와 AI 스킬 조합보다 토큰을 약 92% 더 썼고, 실행마다 토큰 소비의 변동폭이 2.7배 컸으며 시간도 더 걸렸습니다. 토큰 양으로 보면 DESIGN.md가 721만, MCP가 375만, 스킬이 443만이었고요. 모델이 실제로 쓸 수 있는 컨텍스트 여유도 DESIGN.md 쪽이 약 30%로, 나머지 약 80%보다 훨씬 빠듯했습니다. (Inside Atlassian)
Atlassian은 이 테스트를 두고 “연구 논문이 아니다”라고 먼저 못박아 뒀습니다. 모델과 프롬프트, 디자인 시스템, 환경이 달라지면 결과도 달라진다고요. 자사 도구를 정당화하려는 의도가 섞였을 수 있고, 로그인 화면 하나라는 단일 과제만으로 일반화하기엔 이른 감도 있습니다.
왜 갑자기 이 문제가 중요해졌을까요
세 방법을 뜯어보기 전에, 애초에 이 질문이 왜 지금 나왔는지 짚어야겠습니다. AI 디자인 툴이 초기에 내세운 가치는 “빠른 초안”이었습니다. 그런데 팀들이 실제로 운영해보니 다른 문제가 쌓이기 시작했습니다. 드리프트입니다.
AI가 낸 결과물끼리 미묘하게 달라지고, 누가 어떤 프롬프트를 썼느냐에 따라 브랜드 톤이 조금씩 어긋납니다. 피그마의 State of the Designer 2026을 보면 디자이너의 72%가 이미 생성형 AI를 업무에 쓰고 98%가 지난 1년간 사용량을 늘렸는데, 같은 리포트에서 AI 도구를 평가하는 기준이 이동하고 있다고 짚습니다. 얼마나 빠른가에서 브랜드에 맞는가, 상업적으로 안전한가, 반복 적용해도 일관성이 흐트러지지 않는가로요. (Figma)
AI는 디자인 시스템에 담긴 토큰을 기반으로 색상이나 폰트는 맞출 수 있습니다. 하지만 그 브랜드의 “느낌”은 아직 정확히 이해하지 못합니다. 디자인 시스템에 명시되지 않은 맥락과 감도, 어조는 여전히 사람이 판단해야 하고요. 속도 경쟁에서는 AI를 이길 수 없지만, 일관성의 기준을 잡고 드리프트를 감지하는 역할은 사람 몫으로 남습니다.
다만 그 역할을 소화하려면 조건이 있습니다. 내가 관리하는 디자인 시스템이 AI가 소화할 수 있는 형태로 정리돼 있어야 합니다. 그렇지 않으면 “AI가 브랜드를 못 따라온다”는 불만이 생겨도 개선할 방법이 없습니다. 아래 세 방법은 결국 그 정리된 것을 어떻게 건네느냐의 문제입니다.
세 방법이 같은 곳에서 막힙니다
솔직히 이 결과가 놀랍지는 않습니다. 정적 파일 한 장은 브랜드를 한 번 적어두고 매번 통째로 프롬프트에 욱여넣는 방식입니다. 반면 MCP와 스킬 조합은 지금 필요한 조각만 그때그때 불러오는 구조라 같은 정보라도 꺼내 쓰는 효율이 다를 수밖에 없고요. 브랜드 가이드 전체를 매번 회의에 들고 가는 것과, 필요한 페이지만 찾아서 펼치는 것의 차이입니다.
세 방법을 나란히 놓으면 공통점이 보입니다. 모델을 셋 중에 골라도, MCP로 파일을 직접 읽혀도, 마크다운 한 장을 건네도, 결과를 가르는 건 넘기는 쪽의 정리 상태입니다. 레이어명이 엉망이면 MCP도 소용없고, 브랜드 규칙이 머릿속에만 있으면 DESIGN.md에 적을 것도 없습니다. 연결 방식이 세 갈래로 늘어난 만큼 재료의 품질이 그대로 드러나게 된 겁니다.
그럼에도 DESIGN.md가 빠르게 퍼지는 이유는 분명합니다. MCP 서버와 스킬을 직접 구축하려면 인력과 시간이 들지만, 마크다운 파일 한 장은 오늘 당장 누구나 만들 수 있으니까요. Atlassian도 그걸 알아서인지 DESIGN.md를 버리지 않고 그대로 배포하고 있습니다. 더 나은 구조로 가는 다리로 두고 쓰는 셈이죠. 이 격차가 정말 문제가 되는 쪽은 사내에 개발 인력이 있는 팀보다 오히려 혼자 일하는 디자이너나 소규모 팀입니다. MCP 서버를 직접 구축할 여력은 없는데 브랜드 일관성은 지켜야 하니, 정확도를 조금 내주더라도 가벼운 파일이 현실적인 선택지가 되거든요.
한 가지는 짚어두겠습니다. MCP가 코드까지 뽑아준다고 해서 그 코드를 그대로 올리시면 안 됩니다. MCP가 잘하는 일은 가져오는 것까지고, 뽑힌 코드 중에서 무엇을 쓸지 가려내는 눈은 여전히 사람의 몫으로 남습니다.
순서를 바꿔보세요
피그마에서 Dev Mode를 켜고 MCP 서버 토글을 확인해 보시는 것부터 시작하시면 됩니다. 지금은 무료라 부담 없이 시험해 보실 수 있고요. 팀에서 실무에 쓸 계획이시라면 지금 쓰는 시트가 Dev나 Full인지 미리 확인해 두세요. 협업이나 뷰어 시트로는 생각보다 금방 한도에 막히실 겁니다.
다만 연결하시기 전에 자주 쓰는 컴포넌트 몇 개의 레이어명과 오토레이아웃부터 정리해 보시길 권합니다. 결과 품질을 가르는 진짜 변수가 여기 있으니까요. 연결은 5분이면 되지만 정리는 그렇지 않다는 게 이 글에서 드리고 싶은 이야기의 전부이기도 합니다.
팀에서 쓰는 AI 생성 시안에 “브랜드 일관성 체크” 단계를 명시적으로 넣어보시는 것도 권합니다. 누가 언제 확인하는지 프로세스를 잡아두는 것만으로 드리프트가 꽤 줄어듭니다. 브랜드 가이드가 있으시다면 색상과 타이포, 컴포넌트 이름을 정리한 마크다운 파일 하나도 오늘 만들어보시고요. 완벽한 컨텍스트 엔진은 아니어도 아무 컨텍스트 없음보다는 훨씬 나은 출발점이 됩니다. 그리고 AI에게 맡긴 UI가 자꾸 브랜드에서 벗어난다면, 프롬프트를 더 길게 쓰기 전에 어떤 컨텍스트가 빠졌는지부터 점검해 보세요. 대체로 문제는 지시의 길이가 아니라 재료 쪽에 있습니다.
출처: GPT-5.6 is Now Available in Figma Make - Figma Blog · GPT-5.6 - OpenAI · Guide to the Figma MCP server - Figma Help Center · Claude Code and Figma - Figma Help Center · Rate limits & access - Figma Developer Docs · Stitch’s DESIGN.md format is now open-source - Google · Atlassian’s DESIGN.md is here - Inside Atlassian