Figma PDF 세 장으로 C++ 디자인 시스템 코드를 자동 생성한 이야기

썸네일

같은 파란색인데 개발자마다 다른 헥스 코드를 쓰고 있었어요. Win32 API의 COLORREF가 내부적으로 BGR 순서를 사용하다 보니 RGB와 BGR이 뒤섞이는 경우까지 있었죠. 웹 프론트엔드에는 디자인 토큰을 관리하는 성숙한 생태계가 있지만, C++ 네이티브 UI 세계에는 그런 게 없었어요. NHN Cloud의 Cloud Access Windows 클라이언트 팀이 마주한 현실이었어요.

디자인 시스템이 없으면 매번 디자이너에게 색상값을 확인해야 하고, 결과물은 개발자마다 조금씩 달라져요. 디자인 토큰은 보통 세 단계로 나뉘는데, 프리미티브 토큰은 색상값 자체, 시맨틱 토큰은 용도 정의, 컴포넌트 프리셋은 버튼 하나에 필요한 스타일을 한 번에 적용하는 역할이에요.

디자인 시스템 구조

Figma API 대신 PDF를 택한 현실적인 이유

Figma API를 직접 연동하는 방법도 검토했지만 Dev Seat 권한 문제로 막혔어요. 대신 디자인 부서에서 이미 전달받은 디자인 가이드 PDF를 Claude Code에 넘기는 방식을 선택했죠. Claude Code가 PDF를 읽고 분석할 수 있다는 점에 착안한 거예요.

디자인 토큰 계층

Color, Typography, Button 가이드 페이지를 각각 PDF로 export한 뒤 Claude Code에 요청했어요. 결과는 놀라웠죠. PDF 세 개를 순서대로 분석해서 `DesignTokens.h`, `SemanticTokens.h`, `Typography.h`, `ButtonStyles.h`, `DesignSystem.h`까지 전체 코드와 문서를 단시간에 생성해냈거든요.

Claude Code 변환 과정

네이티브 UI에서도 디자인 일관성을 지킬 수 있다

생성된 코드 구조가 깔끔해요. 원시 색상 토큰, 용도별 시맨틱 토큰, 타이포그래피, 버튼 프리셋이 각각 분리되어 있고, 통합 헤더 하나로 묶이는 형태죠. 더 이상 개발자마다 색상값을 다르게 정의하는 일이 없어진 셈이에요. 수작업으로 Figma 색상값을 하나씩 옮기던 시절에 비하면 비교할 수 없을 만큼 빠르고 정확해요.

이 사례가 흥미로운 건, 최신 API 연동이 안 되는 환경에서도 AI를 활용할 방법이 있다는 점이에요. PDF라는 전통적인 포맷이 AI와 만나니까, 도구의 한계를 우회하는 실용적인 경로가 되더라고요.