멀티 프로덕트, 멀티 에이전트

흔히 떠올리는 구성은 이렇다. 모든 UX 에이전트에게 Figma skill 30개 전부, 디자인 시스템 스펙 전체, 브랜드 가이드라인, 모든 규칙 파일을 준다. 에이전트는 필요한 걸 다 갖게 된다. 대신 첫 프롬프트를 보내기도 전에 컨텍스트 창의 절반이 사라진다.

브랜드 2개, 웹 서비스 3개에 서비스마다 Figma 파일, DS 토큰, 사용자 제약이 따로 있으면 전부 미리 로드하는 건 현실적이지 않다. 클라이언트 포털 에이전트에게 어드민 포털 컴포넌트 skill은 필요 없다. A 브랜드 에이전트에게 B 브랜드의 토큰 명명 규칙은 필요 없다. 관련 없는 컨텍스트를 로드하면 토큰이 낭비되고 서로 섞일 위험도 커진다. 두 브랜드가 모두 컨텍스트에 있으니 에이전트가 B 브랜드의 간격 스케일을 A 브랜드에 적용하는 식이다.

해법은 skill 체인을 필요할 때만 로드하는 것이다. 공용 풀에는 skill이 30개 있다. 디자인 요청이 들어오면 두 가지가 일어난다. 범위 판별이 요청 대상 브랜드와 서비스를 정하고, 요구사항 플래너가 현재 디자인 상태에 맞는 skill 체인을 고른다. 체인은 지금 작업에 관련된 skill 3~6개만 로드한다. 나머지는 로드하지 않으니 토큰을 실제 작업에 쓸 수 있다.

요청과 UX 에이전트 사이에 LLM 라우터 에이전트를 따로 두지 않는다. 대신 가벼운 결정적 판별기가 범위를 정한다.

특정 제품을 대상으로 한 요청이 들어오면, 판별기는 먼저 브랜드(A 또는 B)를 정하고 그다음 그 브랜드 안의 웹 서비스를 정한다. A 브랜드에는 클라이언트 포털과 어드민 포털, 두 서비스가 있고 각각 UX 에이전트가 있다. B 브랜드에는 클라이언트 포털 하나와 UX 에이전트 하나가 있다. 서비스 셋, 에이전트 셋이다.

각 UX 에이전트는 서비스 하나만 담당하는 .claude/agents/ 파일이다. 시스템 프롬프트에 Figma 파일 URL, 브랜드의 DS 계약, 사용자 제약을 담고 있다. 작업을 받으면 공용 풀에서 필요한 skill만 로드하고, Figma MCP로 실행한 뒤 결과를 돌려준다.

브랜드로는 소유를 정한다. 어느 서비스, 어느 에이전트인지. 요구사항으로는 실행 계획을 정한다. 어떤 skill 체인을 로드할지. 라우팅 결정은 이렇게 둘이지만, 어느 쪽에도 전용 LLM 에이전트는 필요 없다. 서비스가 하나뿐인 브랜드에 라우터 에이전트를 두면, 답이 하나뿐인 결정에 에이전트 컨텍스트 하나만큼의 토큰을 통째로 쓰게 된다.

Figma skill 30개가 공용 풀에 있고, 어느 에이전트도 이 skill을 소유하지 않는다. 어떤 skill을 로드할지는 질문 하나로 정한다. 지금 디자인 상태가 어떤가?

답은 2×2 매트릭스로 정리된다. 한 축은 이 서비스에 디자인 시스템이 이미 있는지, 다른 축은 화면이 이미 있는지다.

Chain A는 DS 추출이다. 화면은 있는데 DS가 없는 경우다. 에이전트가 기존 화면에서 토큰을 뽑아 variable 시스템을 만들고, DS 규칙을 생성한다. skill 다섯 개: get-variable-defs, search-design-system, generate-library, create-ds-rules, audit-tokens.

Chain B는 화면 생성이다. DS는 있고 화면은 없다. 라이브러리를 검색해 기존 컴포넌트로 화면을 조립하고, 토큰 바인딩을 확인한다. skill 세 개: search-design-system, generate-screen, audit-tokens.

Chain C는 전체 빌드로, 가장 무겁다. 아무것도 없는 상태에서 DS를 먼저 만들고, 그 DS로 화면을 생성한다. skill 여섯 개: figma-use, generate-library, create-ds-rules, generate-screen, audit-tokens, sync-states.

Chain D는 유지보수를 맡는다. DS도 화면도 이미 있다. 바인딩을 확인하고, 분리된 인스턴스를 찾고, 어긋난 데가 없는지 점검한다. skill 세 개: search-design-system, figma-use, audit-tokens.

Chain D는 skill 3개(약 5K 토큰)를, Chain C는 6개(약 9K 토큰)를 로드한다. 30개를 전부 로드하면 약 45K 토큰이 든다. 첫 프롬프트를 보내기도 전에 컨텍스트 창 대부분이 사라지는 셈이다.

브랜드별 디자인 시스템의 원본은 Figma에 있다. variable, 컴포넌트, mode가 모두 거기 있다. 하지만 LLM 에이전트는 Figma variable을 구조화된 컨텍스트로 바로 읽지 못한다. 그래서 브랜드마다 .md 스펙 파일 묶음을 두고, 에이전트가 읽는 계약으로 쓴다. 이 파일들은 Figma 원본과 동기화한다.

브랜드별 구조는 이렇다. 루트에 design-system.md가 있다. foundations/에는 color.md, typography.md, spacing.md가, components/에는 button.md, input.md, card.md가 있고, 각 파일이 variant, 상태, 사용 규칙을 정의한다.

에이전트는 자기 브랜드의 스펙만 읽고, 다른 브랜드 스펙은 읽지 않는다. Figma 원본이 바뀌면 .md 계약도 갱신한다. 계약에 정의되지 않은 상태가 있으면 에이전트는 지어내지 않고 표시해 둔다. 계약은 drift를 막아 준다. 단, Figma 원본과 동기화돼 있을 때만.

모든 UX 에이전트는 Figma MCP 서버 하나에 연결된다. 서버는 링크 기반이라 에이전트마다 URL로 각자 다른 Figma 파일을 가리킨다. 서비스를 바꿀 때 서버를 다시 설정할 필요가 없다. 쓰기 권한은 2026년 3월 24일 use_figma와 함께 생겼다. 원격 서버에서만, Full 시트로 쓸 수 있고, Figma가 나중에 과금할 계획인 무료 베타다. 어느 에이전트가 어느 파일에 접근할지는 에이전트 시스템 프롬프트에 적은 에이전트-파일 매핑으로 제한한다.

핵심 도구는 이렇다. use_figma는 Plugin API가 지원하는 건 뭐든 쓸 수 있다. 프레임, variable, auto-layout, 컴포넌트 variant까지. search_design_system은 재사용할 수 있는 기존 컴포넌트를 찾는 데 쓰지만, 중복을 막으려면 명명 검증과 감사 검사도 함께 필요하다. 전체 도구는 16개(쓰기 7, 읽기 9)이고 Figma MCP 문서에 정리돼 있다.

현재 구현 기준으로는 이렇다. use_figma는 호출당 최대 약 20KB를 돌려주므로 큰 화면은 나눠서 생성해야 한다. MCP로는 이미지나 에셋을 가져올 수 없어서, 에셋이 많은 컴포넌트는 Figma에서 템플릿을 먼저 만들어 둔다. 커스텀 폰트는 아직 MCP에서 지원하지 않는다. 모든 에이전트가 OAuth 신원 하나를 같이 쓴다. 알고 있는 운영 리스크이고, 지금은 파일 허용 목록과 쓰기 확인 가드로 위험을 줄이고 있다. 에이전트별 서비스 신원은 앞으로 개선할 과제다.

여기까지가 이 흐름을 시험하며 내가 부딪힌 한계다. 제약은 모두 공용 skill 풀에 가드로 적어 뒀다. "15KB를 넘는 작업은 나눈다", "생성 전에 기존 템플릿을 확인한다" 같은 skill이 있어서 에이전트가 런타임에 벽에 부딪히지 않는다.