에이전트가 읽고 쓰는 디자인 시스템과,
실제 제품 코드를 고치는 에이전트 Molly

'에이전트가 읽고 쓸 수 있는 디자인 시스템'을 만든다.

기존 디자인 시스템은 문서, Storybook, 피그마 라이브러리처럼 사람이 읽도록 만들어졌다. 하지만 에이전트에게 필요한 건 달랐다. 컴포넌트 이름과 prop 타입처럼 환각을 막는 최소 정보는 항상 담아 보내고, 토큰·의존성·상세 설명처럼 부피 큰 정보는 실제로 쓸 때만 불러온다. 그래서 디자인 시스템을 ‘사람이 읽는 문서’에서 ‘에이전트가 필요한 만큼만 찾아 쓰는 시스템’으로 다시 정의했다.

파일 하나만으로 일관성을 지키기는 어려웠다

‘DESIGN.md 파일 하나면 AI가 우리 디자인 언어로 말한다’는 접근이 업계에 퍼지기 시작했다. 그래서 우리 환경에서도 테스트했다. 결과는 분명했다. 파일 하나로는 복잡한 SaaS 대시보드의 일관성을 지키지 못했고, 없는 컴포넌트를 만들어내는 환각이 많이 발생했다.

그렇다고 모든 정보를 넣으면, 비용이 증가했다

파일 하나만 주면 정보가 부족해 환각이 난다. 그렇다고 전체 컴포넌트 목록을 통째로 넣으면, 매 요청마다 AI가 읽어야 할 양(토큰)이 너무 커져 비용과 속도가 나빠진다. 결국 ‘환각을 막는 것’과 ‘비용을 줄이는 것’을 동시에 잡아야 했다.

버튼 하나를 사용하려면 무엇을 알아야 할까?

에이전트가 버튼을 제대로 쓰려면 이름만으로는 부족했다. MCButton가 어떤 역할의 버튼인지, 어떤 prop을 받을 수 있는지, 어떤 토큰과 상태를 써야 하는지까지 알아야 했다. 그래서 버튼 하나를 작은 설명서처럼 정리했다. 이름, props, 토큰, 상태, 의존성, 사용 규칙을 기계가 읽을 수 있는 구조로 나눠 담았다. 그 결과 에이전트가 없는 버튼을 지어내거나 실제 컴포넌트를 잘못 쓰는 일이 줄었다. 처음 만든 결과물도 우리 제품 코드에 더 가까워졌다.

어떻게 사용하는지 이해하기 쉬운 구조가 필요했다

사람이 읽던 문서를 4개 층으로 다시 짰다. 층마다 답하는 질문이 다르기 때문이다. 무엇이 있는지(L1), 어떻게 엮이는지(L2), 제품에서 무슨 뜻인지(L3)를 나눠야 필요한 만큼만 골라 보낼 수 있었다. 에이전트는 MCP 도구로 그 층마다 필요한 것만 꺼내 쓴다.

에이전트도 쓰고, 사람도 보는 디자인 시스템

같은 데이터를 두 가지 화면으로 만들었다. 에이전트는 MCP로 필요한 정보를 가져가고, 사람은 디자인 시스템 사이트에서 컴포넌트와 토큰, 패턴을 직접 확인할 수 있다.

개선될 수 있는 Loop를 만든다

에이전트가 디자인 시스템에서 딱 맞는 컴포넌트를 찾지 못하면(유사도 0.5 미만), 바로 만들지 않고 ‘DS-Missing’ 대기열로 보낸다. 그러면 LLM이 이 요청을 ‘새로 만들기 · 기존 확장 · 이번만 커스텀’ 중 무엇인지 자동으로 분류하고, 사람은 검토가 필요한(Pending) 항목만 확인해 결정한다. 이렇게 쌓인 요청은 디자인 시스템을 어디부터 보완할지 알려주는 신호가 되고, 반복될수록 시스템이 더 촘촘해지는 loop가 만들어진다.

Molly는 아이디어를 실제 제품 코드로 바꾸는 에이전트다.

디자인 시스템을 에이전트가 읽을 수 있게 만들었지만, 그것만으로는 부족했다. 개발자가 아닌 사람도 ‘여기 이렇게 바꾸고 싶다’고 말하면, 실제 제품 코드까지 이어지게 만들고 싶었다. 고객 피드백을 가장 가까이서 듣는 PM·SA(솔루션 아키텍트)가 직접 개선을 시작할 수 있게 하는 것이 목표였다. 그래서 그들이 이미 쓰는 자리에 세 가지 진입점을 뒀다. 대화하다 떠오른 개선은 Slack 스레드에서 그대로 요청하고, 실제 화면 위에서는 Chrome 확장 프로그램으로 ‘여기 이렇게’ 하고 바로 지목하고, 깊게 파고드는 작업은 Playground에서 캔버스·프로토타입·PR까지 이어간다.

Molly가 일하는 순서

실제 사용 모습

보이지 않던 에이전트 작업을 로그로 들여다본다

에이전트 작업은 그냥 쓰면 블랙박스다. 그래서 모든 작업을 기록했다. 어떤 생각으로, 어떤 맥락(DS 컨텍스트)을 근거로, 토큰을 얼마나 써서, 얼마의 시간이 걸렸는지. 이 로그로 에이전트를 튜닝하고, 비용과 최적 LLM을 비교하고, 모델을 바꾸면 어떤 결과가 나오는지 실험할 수 있게 했다.

사람이 믿을 수 있게, 검증하고 계속 개선하는 게이트.

기존 컴포넌트를 조합하는 작업은 잘했다. 하지만 새 컴포넌트나 패턴을 ‘생성’하는 데는 약했다. 이걸 끌어올리려고 많은 실험을 거쳐 평가 프레임워크를 설계했고, 출력이 3단계 평가를 거치게 했다.

1. 1
   Automated

   typecheck · render · route · prop · DS 그라운딩(환각) 검사. 전부 통과/실패 하드 게이트 — 하나라도 실패하면 반려한다. 기계가 확실히 잡는 건 기계가.

2. 2
   Design critic

   1단계를 통과한 화면만, 기준 화면(정답 시안 reference가 있으면 그것, 없으면 우리 서비스의 좋은 화면을 모은 ‘골든 세트’)과 나란히 놓고 visual-craft(간격·정렬·타이포·색·계층)의 일치도를 0~100%(matchScore)로 매긴다. 기계가 못 잡는 시각 완성도를 판정하는 단계다.

   matchScore 기준

   matchScore가 임계선 미만이면 자동 개선을 먼저 돌리고 재평가한다. 1단계 하드 게이트를 전부 통과하고 이 임계선을 넘겨야 최종 통과. 다만 솔직히, 이 루프가 끌어올리는 건 내부 골든 세트(서비스 화면 24장) 대비 평균 약 85%까지다. 마지막 5~10%, 기준선 아래의 미세한 craft는 사람의 몫으로 3단계에 넘긴다.

3. 3
   Human-in-the-loop

   마지막 판단은 사람이 한다. 개발자가 코드를 리뷰하고, PM이 확인한 뒤, PR을 승인해야 실제 제품에 반영된다.

세 시스템이 서로를 보완하며 더 나은 결과를 만든다

지식(Knowledge)은 에이전트가 엉뚱한 답을 내지 않도록 올바른 기준을 알려주고, 에이전트(Agent)는 그 기준대로 실제 제품 코드를 고친다. 평가(Evaluation)는 그 결과를 점검해, 걸러낸 교정 내용을 다시 지식으로 쌓는다. 세 가지를 따로 쓸 때보다 하나로 이었을 때, 쓸수록 더 나아지는 선순환이 된다.

결과를 가른 건 더 똑똑한 모델이 아니라, 근거·경계·검증을 설계한 ‘구조’였다.