에이전트를 위한 디자인 시스템

이 글은 영문 원본을 바탕으로 작성되었습니다.

프랑스 사람으로서 저는 주방에서 가족을 위해 요리하는 시간을 사랑합니다. 디자이너로서는 즐거운 인터랙션을 만드는 일을 사랑하고요. 그래서 2026년 상반기, 저는 어느 인터랙션 쿠커(interaction cooker) 안에서 엄청난 시간을 보냈습니다. 거기서 뭘 했냐고요? 에이전트에게 요리를 가르쳤습니다. 어떻게 했는지, 이 글에서 풀어 보겠습니다. :)

지난 20년간 디자인 시스템은 사람을 위해 지어진 주방이었습니다. 토큰, 컴포넌트, 가이드라인은 공유된 식료품 저장고이자 공유된 작업 방식이었고, 덕분에 디자이너와 엔지니어는 서로 어깨너머로 지켜보지 않고도 같은 요리를 만들 수 있었습니다.

작년에 요리사가 바뀌었습니다. 이제 시스템에 가장 자주 손을 뻗는 것은 더 이상 디자이너가 아닙니다. 에이전트입니다.

사소한 변화처럼 들리지만, 일 전체를 바꿉니다. 사람 요리사는 즉흥적으로 대응합니다. 레시피를 읽고, 저장고를 흘끗 보고, 레시피가 빠뜨린 열 가지를 맛으로, 수백 번 만들어 본 경험으로 조용히 채워 넣습니다. 에이전트는 아무것도 채워 넣지 않습니다. 레시피가 할 수 있다고 적힌 것만 정확히 만들고, 레시피가 침묵하는 지점에서 멈춥니다. 요리사가 손에 쥐고 있던 판단을, 종이 위에 적어 두지 않으면 그 요리는 사라집니다.

그래서 일이 옮겨 갔습니다. 불 앞에서 보내는 시간은 줄고, 무엇을 요리할 가치가 있는지 정하고, 맛볼 수 없는 누군가도 따라 할 수 있을 만큼 정확하게 레시피를 적는 시간이 늘었습니다.

데이터로서의 시스템

맛볼 수 없는 요리사에게 필요한 방식으로 라벨을 붙인, 재료 하나를 보겠습니다.

export const couponCardManifest: ComponentManifest = {
  id: 'CouponCard',
  layer: 'experiences',
  description: 'Animated coupon reveal with discount value, copyable code, and a "Use Now" CTA. Conversion-stage reward delivery.',
  funnelStages: ['conversion'],
  intent: 'reward',
  flowPredecessors: ['FlipCard', 'ScratchReveal', 'SpinWheel'],
  flowSuccessors: ['Burst'],
  brandHooks: [
    { prop: 'value', brandAspect: 'product', description: 'Discount value, e.g. "15%", "₩5,000".' },
    { prop: 'title', brandAspect: 'tone',    description: 'Coupon title, in brand voice.' },
  ],
  compositionRules: [{
    role: 'reward',
    pairsWith: ['FlipCard', 'ScratchReveal', 'SpinWheel'],
    constraints: 'Use as the reward reveal after a discovery interaction. Always pair with a CTA so users can act on the coupon.',
  }],
};

디자이너가 이걸 읽으면 쿠폰을 봅니다. 에이전트가 이걸 읽으면 그 재료가 식사 안에서 어디에 속하는지, 무엇을 위한 것인지, 앞에 무엇이 와야 하고 뒤에 무엇이 와야 하는지, 그리고 어느 부분을 손님이 간 맞추고 어느 부분을 주방이 지키는지를 배웁니다. 맛은 constraints 줄에 있습니다. 그 한 문장이 곧 디자인 결정이며, 즉흥적으로 대응하지 않는 요리사를 위해 적힌 것입니다.

모든 재료가 이런 라벨을 달고, 세 개의 층에 나뉘어 진열됩니다. 맨 아래에는 가공되지 않은 프리미티브, 가운데에는 준비된 요리, 맨 위에는 플레이팅과 테마. 그래서 에이전트는 빽빽한 저장고 하나가 아니라 알맞은 선반으로 손을 뻗습니다.

브랜드도 데이터입니다. 레시피는 시드(seed)가 도착하기 전까지 그것이 누구의 것인지 모릅니다.

// Same recipe. Two brands. Two seeds.
export const skincareBrand = {
  seed: { primary: '#1FA46A', mode: 'light', radiusBase: 8 },
  designNotes: 'Clean and inviting. Avoid aggressive urgency.',
};
export const streetwearBrand = {
  seed: { primary: '#000000', mode: 'dark', radiusBase: 2 },
  designNotes: 'Minimal, monochrome, sharp corners. Bold CTAs, nothing cute.',
};

같은 쿠폰 레시피에 이 두 시드를 건네면, 하나는 부드럽고 초록빛에 둥글게 나오고, 다른 하나는 날카롭고 검으며 에디토리얼하게 나옵니다. 그 아래 뼈대는 동일합니다. designNotes는 요리사를 위해 적힌 맛이라서, 에이전트는 각 브랜드가 어떤 느낌이고 싶은지 읽고 그쪽으로 요리합니다.

쿠커 (The Cooker)

라벨은 어떤 재료가 요리에 들어갈 수 있다고 말해 줍니다. 하지만 그 요리가 실제 메뉴 위에서, 실제 테이블에 나갔을 때 제대로 어우러지는지는 증명해 주지 않습니다. 바로 그것을 위해 Interaction Cooker가 있습니다.

쿠커는 테스트 주방입니다. 레시피, 브랜드의 하우스 스타일, 그리고 라이브러리를 받아서, 에이전트가 만들 법한 방식으로 인터랙션 전체를 처음부터 끝까지 플레이팅합니다. 우리가 적은 레시피가 올바른 레시피였는지를, 어떤 것도 돈을 내는 테이블에 닿기 전에 확인하는 곳입니다.

쿠커에서 같은 O/X 퀴즈 레시피를 스킨케어 브랜드로 렌더링한 모습: 초록빛, 둥근 모서리, 스킨케어 질문.

그리고 스트리트웨어 브랜드로: 검정, 날카로운 모서리, 스트리트웨어 질문. 같은 레시피, 같은 뼈대, 정반대의 느낌.

크래프트는 어디로 갔나

장인에게 저장고와, 거기서 즉흥적으로 요리해도 되는 요리사를 보여주면 그는 움찔합니다. 같은 요리를 천 번 찍어내는 기계처럼 들리니까요. 대부분의 AI 인터페이스를 전자레인지에 돌린 것처럼 느끼게 만드는 바로 그것이죠.

크래프트는 떠나지 않았습니다. 판단이 한 단계 아래로 옮겨 갔을 뿐입니다.

판단은 접시에서 내려와, 그 접시에 들어가는 모든 것 위로 옮겨 갔습니다. 재료, 레시피, 그리고 요리책 자체로요. 재료는 요리사가 손을 뻗도록 허락되기 전에 맛보고 승인됩니다. 레시피는 출시된 뒤가 아니라 요리책에 들어오는 순간 심사됩니다. 요리책 전체가 하나의 기준을 따릅니다. 이것들을 제대로 해 두면, 접시마다 일일이 맛볼 필요가 없습니다.

어차피 접시마다 다 맛볼 수도 없습니다. 이 요리들은 여러 테이블, 여러 하우스 스타일, 여러 목표를 한꺼번에 넘나들도록 만들어졌고, '테이블 × 하우스 스타일 × 목표'는 사람이 하나씩 확인할 수 있는 숫자가 아닙니다. 플레이팅한 뒤 결과를 맛본다는 예전 방식은 이 곱셈을 견디지 못합니다. 판단은 더 일찍, 재료 안에 살아 있어야 합니다. 거기서 내린 하나의 좋은 결정이 그로부터 만들어지는 모든 것에 간을 배게 하니까요.

위의 라벨에서 이미 그 모양을 보셨습니다. 재료가 앉을 수 있는 순서. 브랜드가 간을 맞추는 부분과 주방이 지키는 부분 사이의 경계선, 그래서 백 개의 테이블이 모두 일관되면서도 어느 하나 똑같이 나오지 않게 하는 것. 요리사가 반드시 지켜야 할 한 문장으로 적힌 맛. 그것이 한 번 적어 두면 모든 식사에 걸쳐 유지되는 판단입니다.

주방을 무방비로 둔 것도 아닙니다. 두 번째 요리사가 각 레시피를 라인에 올리기 전에 적힌 기준에 비춰 맛봅니다. 그리고 근무 중인 요리사에게는 즉흥의 여지가 주어집니다. 이미 아는 요리에 기댈 수 있지만, 끈에 묶인 채로요. 그래서 우리가 요청한 식사 안에 머물고, 메뉴 밖으로 벗어나지 않습니다.

요리사는 자유롭습니다. 단, 나쁜 요리를 플레이팅하기 어렵게 지어진 주방 안에서요. 그 주방이 곧 크래프트입니다.

무엇이 출시됐나

5월, 첫 실제 식사가 나갔습니다. 에이전트가 만든 광고 캠페인이 실제 광고주의 테이블에 올랐습니다. 손으로 주문 즉석 조리한 것이 아니라 요리책에서 플레이팅한 OX 퀴즈였죠. 시식이 아닌 첫 번째 사례였습니다.

그리고 성과를 냈습니다. 에이전트가 플레이팅한 요리는 우리가 손으로 만든 것들과 견줘 손색이 없었고, 손님이 느낄 만한 품질 저하는 없었습니다. 그것이 우리가 가장 먼저 확인해야 했던 것입니다. 주방이 구성한 식사가 디자이너가 손으로 플레이팅한 것만큼 좋다는 것.

다음 베팅은 더 큰 것이고, 지금 시험하고 있습니다. 주방이 훌륭한 요리 하나를 대규모로 플레이팅할 수 있다면, 손님마다 다른 요리를 플레이팅할 수도 있습니다. 두 번째 단계는, 손님 유형마다 맞춰진 식사가 이 풍성하고 성과 좋은 요리들조차 능가한다는 것을 보이는 일입니다. 하나의 주방, 손님마다 한 접시.

저는 단일 요리보다 주방을 더 신뢰합니다. 레시피와 브랜드의 모든 조합이 자동으로 검사되고, 규칙을 어기는 것은 어떤 것도 패스(pass)를 통과해 나가지 못합니다. 이 패스는 실재하는 것으로, 빌드가 매번 실행하는 테스트 묶음입니다:

it('no relationship field references a missing manifest')
it('every recipe step component is registered and reachable')
it('a manifest never supersedes itself')
it('no tokensConsumed entry is stale (listed but unused in source)')
it('every component export has a manifest')

이 중 하나라도 실패하면, 그 요리는 결코 주방을 떠나지 못합니다.

무엇이 버텼고, 무엇이 아니었나

요리책은 버텼습니다. 맛볼 수 없는 요리사도 따라 할 수 있도록 레시피를 데이터로 적어 둔 것은 옳은 베팅이었습니다.

솔직한 부분도 있습니다. 우리의 첫 레시피들은 우리만의 억양으로 적혔고, 우리가 리워드를 생각하는 방식에 너무 물들어 있었습니다. 그걸 따르는 에이전트에게는 우리가 카드에 적어 둔 것 이상이 필요했고, 우리는 에이전트가 알맞은 순간에 엉뚱한 재료로 손을 뻗는 것을 지켜보며 그걸 배웠습니다. 해결책은 레시피 안에, 카드 위의 더 날카로운 표현 안에 있었습니다.

// before — written in our accent, the agent reached wrong
constraints: 'Use as the reward.'

// after — the words do the work, the agent stops guessing
constraints: 'Use as the reward reveal after a discovery interaction. Always pair with a CTA so users can act on the coupon.'

우리는 여전히 그것들을 다시 쓰고 있습니다.