AI 에이전트에게 Web 툴을 양산하게 하면 반드시 부딪히는 문제가 있습니다. 디자인이 매번 흔들린다는 점입니다. 같은 지시를 내려도 생성할 때마다 배색, 여백, 컴포넌트의 형태가 미묘하게 다릅니다. 600개 이상의 툴을 5개 언어로 운영하는 프로젝트에서, 이 디자인 고정 문제에 대해 시도했던 방법의 변천사와 각각의 한계를 기술합니다.

제1기: JSON으로 UI를 정의하여 고정하기 → 고정은 되었다. 하지만

처음에 시도한 것은 툴의 UI를 JSON으로 정의하고, 거기서부터 페이지를 생성하는 방식이었습니다. 대상은 이미지 프리뷰를 가지지 않는, 비교적 심플한 계산계 툴이었습니다. 라벨, 입력란, 출력란 등의 값을 JSON에 담고, 정해진 렌더링(Rendering)으로 화면을 만듭니다.

결과적으로 디자인을 고정한다는 목적은 달성되었습니다. JSON에 쓴 것이 그대로 나오기 때문에 생성 시의 흔들림은 사라집니다.

하지만 완성된 화면은 투박했습니다. 직선적이고 곡선이 전혀 없었습니다. 1셀마다 값이 들어가 있는 느낌. 솔직히 말하면 Excel 표입니다.

지금 되돌아보면 원인은 구조적입니다. JSON 정의 방식에서는 표현할 수 있는 디자인의 상한선이 '렌더러(Renderer)가 구현하고 있는 표현'으로 고정됩니다. JSON 스키마(Schema)에 라운드 처리(Corner radius)나 그라데이션, 예외적인 여백을 추가하면 표현은 늘어나겠지만, 그것은 스키마와 렌더러를 계속 비대하게 만드는 것을 의미하며, 결국 HTML과 CSS를 재발명하는 방향으로 향하게 됩니다.

흔들림을 죽이는 메커니즘은 표현력도 함께 죽이고 있었습니다.

제2기: 고정하는 대상을 '레이아웃'에서 '디자인 토큰'으로 바꾸기

방침을 바꿨습니다. 구조(Layout)를 고정하는 것을 그만두고, 아이덴티티(색상, 타이포그래피, 라운드 처리, 여백의 체계)만을 고정합니다.

구체적으로는 CSS 변수 파일을 정본(Source of truth)으로 하여, 모든 툴이 이 변수만을 사용하게 합니다(팔레트, 폰트, 라운드 처리, 그림자). 이에 더해, 움직이는 UI 키트(실제로 브라우저에서 열 수 있는 레퍼런스 구현체)를 준비합니다. "이 프로젝트의 카드/버튼/입력란은 이렇다"라는 견본을 사양서가 아닌 움직이는 HTML로 보유합니다. AI에게는 "JSON대로 그려라"가 아니라 "이 UI 키트의 부품과 변수를 사용하여 레이아웃은 자유롭게 구성하라"고 지시합니다.

이렇게 하면 레이아웃은 툴마다 최적화되면서도 브랜드는 통일되는 상태가 됩니다. 제1기와는 고정의 입도(Granularity)가 반대입니다. 제1기는 전부 고정해서 표현이 죽었습니다. 제2기는 토큰만 고정하고 구성은 자유롭습니다.

부수적인 효과로, AI 측의 디자인 능력이 모델 업데이트와 함께 향상된 것도 주효했습니다. "자유롭게 구성하라"가 성립하는 것은 구성한 결과가 제대로일 때뿐입니다. 제1기 시점에서는 "자유롭게 구성하면 흔들린다"가 전제였지만, 그 전제 자체가 시간이 흐르며 무너졌습니다.

제3기(현재): 공식적인 메커니즘을 활용하는 부분은 활용한다

현재는 자체 제작한 메커니즘에 더해, Claude Code의 스킬 메커니즘이나 디자인 시스템 연동을 위한 공식 기능들이 갖춰지고 있습니다. 디자인 규약을 AI에게 전달하는 것 자체가 공식적으로 지원되는 영역이 되어가고 있으므로, 자체 제작해야 할 부분은 프로젝트 고유의 부분(자신의 토큰, 자신의 UI 키트)으로만 축소하고 있습니다.

이 변천사에서 얻을 수 있는 것

첫째, "고정할 수 있었다 = 성공"이 아닙니다. 고정의 부작용(표현력의 상실)까지 포함하여 평가해야 합니다. 제1기는 목적을 달성하고 실패했습니다.

둘째, 고정할 입도를 선택하는 것입니다. 레이아웃까지 고정하면 Excel이 됩니다. 토큰만 고정하면 브랜드의 일관성과 구성의 자유를 양립할 수 있습니다.

셋째, 전제의 유통기한을 의심하는 것입니다. "AI에게 자유롭게 구성하게 하면 흔들린다"는 당시의 사실이었지만, 지금의 사실은 아니었습니다. 메커니즘은 전제가 무너지면 버립니다.

제한 및 주의사항

제1기의 JSON 방식이 항상 틀렸다는 뜻은 아닙니다. 장표(Form)처럼 구조의 동일성 자체가 가치인 출력물(그야말로 Excel 같은 것)이라면, JSON 정의는 지금도 정답입니다. 제 케이스는 Web 툴의 UI였기 때문에 오답이었습니다.

이 변천사는 2025~2026년 생성 AI의 능력 향상과 병행된 이야기입니다. 어디까지 고정해야 할지의 최적점은 모델의 능력과 함께 앞으로도 계속 움직일 것입니다.

시기: 2026년 전반기 (제1기의 JSON 카탈로그는 2026년 3월 백업에 존재함). 환경: Claude Code / 5개 언어 × 600개 이상의 Web 툴 운영.

Discussion