개발이 빨라지니까 디자이너가 병목이 됐다 — 팀스파르타의 해법

개발 속도를 AI로 3배 올렸더니, 디자이너가 숨을 못 쉬게 됐어요. 아이러니하죠.

팀스파르타가 1편에서 소개한 Stack MCP는 꽤 인상적이었어요. MCP(Model Context Protocol)를 통해 마크업 작업의 70~80%를 자동화했거든요. "이 화면 구현해줘"라고 말하면 디자인 시스템 기반으로 코드가 만들어지고, 실제 구현까지 빠르게 이어졌어요. 개발자 입장에서는 혁명적인 변화.

근데 예상 못 한 문제가 생겼어요. 개발이 빨라진 만큼 다음 태스크가 쉴 새 없이 쌓여갔고, 디자이너들은 오히려 깊게 고민할 여유를 잃어가고 있었어요.

"디자인을 충분히 고민할 시간이 없어요"

디자인팀 주간 회고에서 나온 말이에요. "디자인 단계가 병목이 되고 있어요"라는 목소리도 있었고요. 개발이 빨라졌으니 디자인도 빨라져야 한다는 압박이 생긴 거예요.

디자이너도 Stack MCP로 디자인 시스템 기반의 코드 프로토타입을 만들 수 있었지만, 디자인 프로세스를 완전히 대체하기엔 한계가 있었어요. 디자인은 한 번에 정답을 찾는 게 아니거든요. A안, B안, C안을 나란히 놓고 비교하면서 간격과 위계, 시각적 밸런스를 조정하는 과정이 필요해요. 코드 프로토타입은 빠르게 결과물을 확인하기엔 좋지만, 여러 레이아웃을 이리저리 바꿔가며 비교하기엔 너무 무거웠거든요.

디자이너가 가장 창의적이고 효율적으로 일할 수 있는 공간은 아직 피그마라는 결론이 나왔어요. 그래서 피그마 안에서 AI를 쓸 수 있는 방법을 찾기 시작한 거예요.

그렇게 나온 게 Stack Canvas예요.

말로 설명하면 피그마에 그려주고, 프로토타입을 컴포넌트로 바꿔준다

Stack Canvas는 팀스파르타의 토큰, 타이포그래피, 컴포넌트 규칙까지 학습한 AI가 Figma 캔버스 위에 라이브러리 인스턴스로 바로 배치해주는 도구예요. 다른 AI 디자인 도구들과 가장 다른 점은, 단순히 비슷하게 그려주는 게 아니라 실제 Stack 디자인 시스템 라이브러리의 컴포넌트를 직접 꺼내 쓴다는 거예요. (이 차이가 생각보다 엄청 커요.)

대표 기능 두 가지가 있어요.

첫 번째, 말로 설명하면 피그마에 그려줘요. "팀스파르타 스타일로 비행기 예약 화면 디자인해줘"라고 요청하면, Stack 라이브러리 정보를 이미 학습하고 있기 때문에 별도 수정 없이 디자인 시스템 컴포넌트로 바로 UI를 만들어요. 모바일, PC 각각 한 벌 작업하는 데 대략 4분. 빈 화면 앞에서 고민하는 대신 초안부터 빠르게 만들어서 "이 방향이 맞나?"를 논의할 수 있어요. 초안이 생기면 기준이 생기고, 기준이 생기면 피드백이 빨라지거든요.

팀스파르타에서는 Stack Canvas를 워크플로우에 맞게 정의해둔 Claude Skill과 함께 사용하고 있어요. 예를 들어 stack-figma-designer 스킬은 "화면의 목적"만 입력하면 사용자 예상 행동부터 정보 위계, 비주얼 디자인까지 자동으로 설계하는 거예요.

두 번째, 프로토타입을 Stack 컴포넌트로 변환해줘요. 코드로 직접 프로토타입을 만든 경우, 이미지나 링크를 붙여넣고 "이걸 Stack 컴포넌트로 바꿔줘"라고 하면, 같은 레이아웃과 정보 구조를 유지한 채 Stack 컴포넌트로 다시 구성해줘요. 프로토타입 이후에도 피그마에서 추가 작업이 필요한 상황을 고려한 거예요.

MCP 서버 + Figma 플러그인, 4일 만에 만들었다

Stack Canvas는 크게 두 파트로 구성돼요. MCP 서버와 Figma 플러그인.

MCP 서버는 피그마 라이브러리의 컬러, 타이포, 컴포넌트 variant 정보를 미리 보유하고 있어요. AI가 "Button 만들어줘"라고 하면, 어떤 ComponentSet Key를 쓰고, 어떤 토큰을 적용하고, 어떤 타이포그래피를 쓸지 판단하는 역할이에요. 말하자면 AI의 디자인 시스템 브레인인 거죠.

Figma 플러그인은 MCP에서 받은 명령을 Figma Plugin API로 실행해서, 실제로 컴포넌트를 놓고 색을 칠하고 레이아웃을 잡아요. 브레인이 판단하고, 플러그인이 실행하는 구조.

솔직히 놀라운 건 이 도구를 팀 내에서 나온 아이디어를 바탕으로 디자이너가 단 4일 만에 직접 구현했다는 거예요. 4일. 프로덕트 디자이너 조정한 님이 만들었다고 해요.

2026년 3월 24일 Figma MCP와 뭐가 다른가

여기서 짚고 넘어갈 게 있어요. 2026년 3월 24일에 업데이트된 Figma MCP도 라이브러리 컴포넌트를 꺼내 쓸 수 있거든요. 그러면 Stack Canvas가 필요 없는 거 아니냐는 질문이 당연히 나오잖아요.

차이는 속도예요. Figma MCP는 매번 "이 컴포넌트 어디 있지?"하고 찾는 과정부터 시작해요. 범용 도구니까요. Stack Canvas는 팀스파르타 디자인 시스템 규칙과 라이브러리 정보를 이미 알고 있어서, 찾는 시간 없이 바로 원하는 결과물을 만들 수 있어요. 범용성을 버리고 팀 전용으로 최적화한 거예요.

그리고 1편에서 소개한 Stack MCP와의 차이도 명확해요. Stack MCP는 결과물이 코드로 나와요. Stack Canvas는 결과물이 피그마에 나오는 거예요. 개발자한테는 MCP, 디자이너한테는 Canvas. 같은 디자인 시스템을 기반으로 하되 아웃풋이 다른 거죠.

그리는 도구를 넘어, 함께 고민하는 파트너로

팀스파르타가 다음으로 가려는 방향이 꽤 구체적이에요. AI가 단순히 결과물을 만드는 것을 넘어서, 디자이너의 판단 과정까지 함께하는 것. "이 화면은 이런 방향으로도 설계할 수 있어요"라고 여러 가능성을 먼저 제안하거나, 카피가 상황에 맞는지, 플로우에서 빠진 케이스는 없는지까지 검토해주는 식으로요.

그리고 단순히 디자인 시스템을 사용하는 걸 넘어서 "더 팀스파르타답게" 사용하는 것도 목표라고 해요. 팀스파르타의 주요 타겟을 이해하고, 간격과 정보 위계, 말투 같은 기준까지 학습시키겠다는 거예요.

개발이 빨라지면 디자인도 빨라져야 한다는 건 사실이에요. 근데 빨라지는 방법이 "디자이너가 더 빨리 움직여라"가 아니라 "디자이너의 도구를 바꿔라"였다는 거예요. 그 도구를 디자이너가 4일 만에 직접 만들었다는 점. 이게 이 이야기에서 가장 인상적인 부분이에요.