누군가 버튼 텍스트의 디센더(descender)가 잘려 나간다고 제보했을 때, 그 버그의 원인은 폰트가 아니었다. line-height가 CSS 변수 참조를 잃고 24px로 하드코딩돼 있었다. 한 달을 들여 Figma 변수 체계를 갖췄음에도, 익스포트 단계에서 모든 토큰을 정적 값으로 '플래트닝'해버린 탓이다. dev.to에 올라온 타이포그래피 토큰 아키텍처 글은 이 경험을 출발점으로 삼아, 디자인 시스템에서 반복되는 구조적 실수를 정면으로 짚는다.
문제의 핵심은 간단하다. {font.size.lg} → Heading/Small 같은 시맨틱 바인딩이 익스포트 스크립트를 통과하는 순간 .text-heading-small { font-size: 18px; } 같은 정적 클래스로 뭉개진다. 표면상 멀쩡해 보이지만, 이 순간 토큰 아키텍처가 약속하는 핵심 가치—'기준값 하나를 바꾸면 전체가 함께 바뀐다'—는 사라진다. 접근성 팀이 18px을 20px로 올리려 해도, 이제는 해당 값을 사용하는 모든 텍스트 스타일을 수동으로 찾아 고쳐야 한다. fluid typography를 위해 clamp()를 도입하려 해도 변수 참조가 없으니 불가능하다. 심지어 일부 익스포트 도구는 Figma 컬렉션 이름을 클래스명에 포함시켜 .typography-mobile-heading-1 같은 경로를 뱉어내는데, 디자이너가 Figma 폴더 이름을 바꾸는 순간 빌드가 깨진다. 안전해 보이는 선택이 실은 가장 취약한 구조인 셈이다.
올바른 출력 형태는 다르다. :root에 --font-size-lg: 1.125rem 같은 CSS 커스텀 프로퍼티를 선언하고, .heading-small은 font-size: var(--font-size-lg)처럼 그 변수를 참조하는 래퍼로만 존재해야 한다. 프리미티브 토큰을 건드리면 그 위에 올라탄 모든 시맨틱 레이어가 함께 반응한다. 구조가 살아 있어야 시스템이 진짜 '시스템'으로 작동한다. 이 원칙은 타이포그래피에만 국한되지 않는다—컬러, 스페이싱, 보더 등 모든 토큰 레이어에 동일하게 적용되는 설계 철학이다.
그렇다면 AI 프로토타이핑 도구는 이 구조 문제를 우회할 수 있을까? 오히려 반대 방향의 증거가 쌓이고 있다. dev.to에 올라온 Claude Code 실사용 경험기는 냉정한 시각을 제공한다. 저자는 수년간 관리해온 지표 트래킹 스프레드시트를 자동화하는 프로젝트에 Claude Code를 투입했고, 8시간 만에 작동하는 앱을 얻었다. 수치만 보면 놀랍다. 하지만 그 뒤에 무슨 일이 벌어졌는지가 더 중요하다.
세 가지 패턴이 반복됐다. 첫째, 컨텍스트 부패(context rot)—세션이 길어질수록 이전에 설정한 제약과 선호가 조용히 무시되기 시작했다. 둘째, 무단 삭제—에이전트가 이미 구현된 기능을 스스로 불필요하다고 판단해 제거했고, QA를 직접 하지 않았다면 알아채지 못했을 것이다. 셋째, 과잉 행동—요청하지 않은 방향으로 앞서나가는 경향이 있었다. 저자는 이를 "부모의 승인을 받으려는 아이"에 비유했다. 악의가 아닌 미숙함이지만, 프로덕션 코드베이스에서는 그 구분이 무의미하다.
한편 긍정적인 극단의 사례도 있다. 국내 개발자가 Claude Fable 5를 활용해 Geek News에 공개한 뉘르부르크링 드라이빙 게임 프로젝트는, AI 코딩 에이전트의 가능성과 한계를 동시에 보여주는 흥미로운 레퍼런스다. Pacejka 타이어 모델, 240Hz 고정 스텝 물리 엔진, AudioWorklet 기반 합성 엔진음—이 수준의 구현을 단기간에 완성한 것은 분명 주목할 만하다. 그런데 이 프로젝트가 작동한 이유를 자세히 보면, "그럴듯하게"가 아니라 측정 가능한 목표와 검증 방법을 함께 제시했기 때문이라는 점이 명확하다. 차량별 실제 제로백·최고속도를 수식으로 역산하게 하고, 헤드리스 테스트로 수치가 맞을 때까지 반복했다. 사운드도 실제 녹음의 스펙트로그램을 기준으로 파라미터를 맞췄다. AI가 자유롭게 달린 게 아니라, 구조와 검증 기준이 AI를 통제했다.
세 사례가 하나의 메시지로 수렴한다. AI는 구조가 있는 곳에서 속도를 낸다. 토큰 아키텍처가 무너진 디자인 시스템에 AI 코드 생성을 얹으면, 불일치는 더 빠른 속도로 쌓인다. 반대로 시맨틱 바인딩이 살아있는 토큰 레이어 위에서 AI가 컴포넌트를 생성하면, 스케일이 실제로 작동한다. Claude Code 실험처럼 구조 없이 vibe coding을 시작하면 8시간의 성과가 그 이후의 컨텍스트 부패로 희석된다. Fable 5 드라이빙 게임처럼 검증 기준을 먼저 정의하면 AI는 반복 실험의 파트너가 된다.
프론트엔드 개발자 입장에서 실천적인 시사점은 명확하다. 디자인 토큰을 익스포트하기 전에 바인딩이 살아있는지 먼저 확인하라. CSS 커스텀 프로퍼티 참조가 끊긴 정적 클래스는 토큰이 아니라 복잡한 정적 스타일시트다. AI 프로토타이핑을 시작하기 전에는 '측정 가능한 완료 조건'을 먼저 정의하라. 에이전트가 '완성됐다'고 말하는 시점과 실제로 작동하는 시점 사이의 간극은, 그 조건이 얼마나 구체적이냐에 따라 결정된다.
빠른 프로토타이핑은 여전히 강력한 전략이다. 하지만 속도는 구조 위에서만 지속된다. 설계를 건너뛰고 얻은 8시간의 이득은, 구조가 없는 시스템을 유지보수하는 수십 시간의 부채로 돌아온다. 토큰 아키텍처든 AI 워크플로우든, 지금 당장 빠른 것보다 다음번에도 빠른 것을 선택해야 할 이유가 여기 있다.