우리가 디자인 에이전트를 만든 방법

핵심 요약

• 취향은 컨텍스트에서 나옵니다. 모델은 이미 좋은 코드를 작성하지만, 당사의 작업처럼 보이는 결과물을 만들려면 디자이너의 원칙, AI slop에 대한 가드레일, 그리고 피드백의 배경에 담긴 추론이 필요합니다.
• 에이전트에게 디자이너의 컴퓨터를 주세요. 각 Slack 스레드는 자체 샌드박스를 받으며, 에이전트는 그 안에서 턴 사이에 프로젝트를 유지하고, 비디오 엔진, 이미지 도구, 공유 캔버스를 넘나들며 작업하고, 자신이 렌더링한 결과물을 검사합니다.
• 모델이 좋아지면 규칙을 삭제하세요. 모델의 약점을 보완하던 규칙은 만료됩니다. 따라서 디자인 원칙은 유지하되, 모델이 좋아지면 우회 방법들은 제거하세요.
• 장기 실행 에이전트에는 멀티플레이어 UX가 필요합니다. 큰 작업은 비동기 서브에이전트에서 수 시간 동안 실행되므로, Slack 스레드에는 계획, 실시간 진행 상황, 그리고 무엇이든 출하되기 전 승인 절차가 표시되며, 팀의 누구든 실행 중간에 에이전트를 조종할 수 있습니다.
• 포크할 수 있습니다. 오픈소스 저장소에는 전체 하네스가 들어 있으며, Managed Deep Agents가 이를 팀의 Slack에 배포해 줍니다.

‍

위의 프로모션은 Content Studio, 즉 Slack에서 단 하나의 프롬프트만으로 비디오, 소셜 그래픽, 재현된 UI 이미지, 슬라이드 덱 등을 만들 수 있는 저희 디자인 에이전트가 제작한 것입니다. 에이전트가 만들어내는 모든 에셋은 코드로 작성됩니다.

Content Studio는 전적으로 사내에서 Managed Deep Agents기반으로 구축되었습니다. 현재는 저희 회사에서 가장 널리 사용되는 GTM 에이전트 중 하나이지만, 처음부터 그랬던 것은 아닙니다. 초기 피드백은… 그리 좋지 않았습니다.

그렇다면 우리는 어떻게 이렇게 낮은 품질에서 여기까지 올라섰을까요?

우리는 4개월 동안 Content Studio에 우리의 취향과 디자인 원칙을 가르쳤으며, 대부분은 회사 전체 앞에서 에이전트가 실수하는 것을 지켜보는 방식이었습니다.

이 글에서는 GTM Engineering 팀이 디자인 팀과 협력하여 Content Studio를 처음부터 구축한 과정을 다룹니다: 우리에게 좋은 디자인이 무엇을 의미하는지, 에이전트에게 우리의 취향을 어떻게 가르쳤는지, 그리고 정지 이미지부터 출시 영화까지 무엇이든 만들 수 있게 해주는 하네스가 무엇인지 소개합니다.

우리는 디자인 에이전트를 오픈소스로 공개했습니다. 오픈소스 저장소를 포크하고, 브랜드 토큰, 폰트, 스킬을 추가한 뒤,, 브랜드 토큰, 폰트, 스킬을 추가하고 다음을 통해 팀의 Slack에 배포하세요: 로 팀의 Slack에 배포하세요..

그리고 10월 28일 GTM Engineering Live 10월 28일에 진행됩니다. 하네스와 UX의 내부를 들여다보고, 이 글에 담지 못한 작업도 보여드리겠습니다.

확장 가능한 디자인 에이전트 구축하기

LangChain은 빠르게 움직입니다. 우리는 끊임없이 제품 출시 캠페인, 웨비나, 블로그, 이벤트를 진행합니다. 각 이니셔티브는 블로그 헤더와 다이어그램부터 덱, 비디오, 광고 크리에이티브까지 에셋을 필요로 합니다. 저희 디자인 팀은 일이 밀려 있었고, 반복적인 요청들이 더 전략적이고 혁신적인 작업을 밀어내고 있었습니다. 린 스타트업으로서 우리는 회사 누구나 고품질의 브랜드에 맞는 작업물을 만들 수 있는 저마찰적인 방법이 필요했습니다.

이러한 요구를 해결하기 위해 우리는 Slack에 상주하는 디자인 에이전트인 Content Studio를 만들었습니다. 팀원이 원하는 것을 설명하고 관련 콘텐츠나 브리프를 첨부하면, 에이전트가 완성되고 브랜드에 맞는 파일을 돌려줍니다. Content Studio를 만들기 위해 우리는 세 가지가 필요했습니다:

1. 저희 디자이너들의 전문가적 판단, 에이전트의 스킬과 체크에 기록하여 무엇이 좋은 결과물인지 알 수 있도록 했습니다.
2. 커스텀 환경 모델을 둘러싸는 환경으로, 디자인 작업의 모든 계층을 위한 도구를 갖춘 영상 편집 컴퓨터를 포함합니다.
3. 적절한 UX하나의 Slack 스레드에서 몇 시간씩 진행되는 프로젝트에 팀 전체가 협업할 수 있도록 하기 위함입니다.

Managed Deep Agents 는 회사 내에서 Content Studio를 프로덕션화하는 데 필요한 모든 것을 제공해 주었습니다: 관리형 LangSmith Sandbox, Slack 연동, 관리형 도구, 범위가 지정된 에이전트 메모리, 그리고 에이전트 실행 스케줄링이 그것입니다. 이를 통해 소규모 팀이 파이프라인 구축 대신 디자인 작업, 스킬, 도구, Slack 경험에 시간을 쓸 수 있게 되었습니다.

주요 성과

• Content Studio는 회사 전체에서 3,000개 이상의 에셋을 제작했으며, 그중 80개가 넘는 슬라이드 덱도 포함됩니다. 그 덱 중 하나는 우리의 가장 많이 시청된 오가닉 YouTube 영상에 사용되기도 했습니다.
• 그 작업물이 포함된 게시물은 X에서 약 4.5M 회의 조회수를 기록했습니다.
• LangChain 계정에서 그 비주얼이 포함된 게시물은 다른 게시물에 비해 약 2배의 좋아요와 3.7배의 북마크를 기록했습니다.
• 이제 요청의 4분 중 3개는 마케팅 팀 외부에서 들어오며, 사용자의 75%는 매주 돌아오는 재방문자입니다.
• 이제 요청 1건당 중앙값 기준 약 50센트의 모델 비용이 들며, 9월 중순의 약 $8에서 크게 감소했습니다. 다음으로의 마이그레이션 후 우리 자체 코드는 약 80% 줄어들었습니다 Managed Deep Agents.

AI는 정말 디자인을 잘할까?

구축에 들어가기에 앞서, 먼저 금세기의 논쟁부터 짚고 넘어가 봅시다: AI는 정말 좋은 디자인을 만들어낼 수 있을까?

모델은 이미 실행 능력이 뛰어나 HTML과 CSS, 차트 스펙, 애니메이션 타임라인을 작성할 수 있었습니다. 하지만 우리의 맥락이 없었기 때문에 익숙한 패턴, 즉 Anthropic이 “distributional convergence”라고 부르는 것에 의존했습니다. 그 결과는 세련되어 보이면서도 수백 개의 다른 결과물과 비슷해 보이거나, 아름답게 애니메이션화되었지만도입부의 메시지를 전달하지 못할 수 있었습니다. 익숙함이 항상 나쁜 것은 아니지만, 우리는 에이전트가 자신의 목적에 따라 선택하길 원했습니다.

Katie Dill, Stripe의 디자인 총괄(Head of Design)은 유용한 비교를 들어준다. 제2차 세계대전 이후 빠르게 건축해야 한다는 압박 속에서 건축가들은 모더니즘의 깔끔한 형태와 텅 빈 표면을 두엇이고 복제했다. 복제품들은 외관은 유지했지만 그 뒤에 있는 사고와 개성은 잃었다. 그녀가 경고하는 것은 AI가 소프트웨어에 대해서도 같은 일을 할 수 있다는 점이다. 그녀는 이를 “zombie UI”라고 부르며, 우리에게 관점(point of view)이 필요하다고 말한다. “그렇지 않으면 AI가 당신 대신 관점을 내놓을 것”이기 때문이다.

우리는 AI가 디자인을 못 한다고 생각하지 않는다. 단지 당신이 제공하지 않는 한 관점이 없을 뿐이며, 우리의 관점을 부여한다는 것은 우리의 취향을 가르치는 일이었다.

디자인 에이전트에게 취향 가르치기

취향이란 올바른 작업과 좋은 작업을 가르는 판단력이다. 디자인에서 두 레이아웃이 모두 올바른 서체, 색상, 간격을 사용하더라도 오직 하나만이 자신의 메시지를 전달할 수 있다. 취향은 Dill이 말하는 "noticing(알아차림)에 정말 능숙해지는 것"에서 나온다.

바로 그 알아차림 덕분에 우리는 AI 슬롭(AI slop)을 발견하는 법을 배웠는데, 이는 주로 브리프가 어떤 결정을 에이전트에게 맡길 때 나타난다.

예를 들어, 아래 왼쪽 이미지는 우리 브랜드 스킬(색상, 서체, 로고 등을 포함)을 갖춘 로컬 코딩 에이전트가 만든 것이다. 하지만 최종 결과물은 올바른 로고 락업(logo lockup), 텍스트 정렬, 그리고 어떤 색상이 주(1차) 브랜드 색이고 어떤 색상이 보조(2차) 브랜드 색인지 같은 핵심 요소들을 놓쳤다.

같은 프롬프트가 Content Studio에서는 완벽하게 브랜드에 부합하는 이미지를 만들어냈다. 이는 로컬 에이전트가 브리프가 다루지 않은 각 결정을 자신이 가장 많이 본 방식으로 채워 넣었기 때문이다. 같은 방법론 아래에서 Content Studio는 동일한 빈틈을 우리의 선택으로 채웠다.

Content Studio에 준 가이드라인은 색상 토큰, 서체 굵기, 간격, 정렬 등 기본기에서 출발했다. 하지만 개선의 상당 부분은 그 위에 추가한 것들에서 나왔다. 프레임당 하나의 초점을 두는 것 같은 디자인 원칙, 흔한 AI 디자인 패턴에 대한 가드레일, 그리고 각 피드백의 근거가 되는 추론을 도입했다. 더 나은 기반 모델과 결합되어, 이것들은 Content Studio가 더 디자이너처럼 생각하고 소통하는 법을 배우는 데 도움이 되었다.

처음부터 그랬던 것은 아니다. 초기 모션 그래픽 중 하나에서 새가 화면 밖으로 날아가며 그 뒤로 1초 미만 동안 빛의 리본이 이어지는 장면이 있었다. 우리는 날카로운 모서리가 없기를 요청했지만, 첫 결과물은 둔탁하고 거친 둥근 모서리로 나왔다. 디자이너였다면 우리의 의도를 이해했을 것이다. 모서리는 부드러워져야 하고, 꼬리는 새의 이동 방향과 반대 방향으로 가늘어지며 사라져야 한다는 것을.

이후 반복(iteration)에 이르러서는 에이전트가 그 세부 사항을 디자이너의 눈으로 평가하고 있었다. 스케치를 활용해 새의 꼬리가 있어야 할 위치를 파악한 뒤, 리본이 계속 연결된 상태를 유지하는지 확인하기 위한 자체 프레임별 검사를 만들었다. 대부분의 시청자는 그 세부 사항을 의식적으로 알아차리지 못하겠지만, 무언가 어긋나 있다면 느낄 것이다.

측정 가능한 문제들이 가장 풀기 쉬웠다. 기본 대문자 표기는 리뷰에서 자주 지적되던 사항이었지만, 이제는 자동 검사가 모든 사례를 잡아낸다. 더 어려운 판단은 더 주관적이다. 캠페인 아이디어가 충분히 강력한지, 메시지가 명확하게 전달되는지, 실행이 청중의 공감을 얻는지 같은 것들이다. 디자이너가 그런 판단을 내릴 때, 우리는 그 추론을 스킬에 기록하여 에이전트가 이후의 초안에 적용할 수 있게 한다.

Content Studio는 누가 디자인 작업을 할 수 있는지를 바꿔놓았다. PM, 엔지니어, 창업자가 Slack에서 에이전트에게 브리프를 주면 브랜드에 부합하고 출시 준비가 된 결과물을 받고 자리를 뜰 수 있다. 현재 요청의 4건 중 3건이 마케팅 외부에서 들어온다. 디자이너에게는 역할이 크리에이티브 디렉터에 가깝게 이동했다. 모든 에셋을 직접 만드는 대신 방향을 설정하고 작업을 리뷰하는 것이다.

디자인적 판단을 제대로 갖추는 것이 과정의 한 부분이었다. 우리는 또한 에이전트가 그 판단을 실행할 도구와 환경을 제공해야 했다.

미디어 하니스 구축하기

디자이너는 여러 도구를 넘나들며 작업한다. 스틸 컷에는 Photoshop, 모션에는 비디오 엔진, 프로토타이핑과 협업에는 공유 캔버스를 사용한다. 또한 브랜드 가이드라인, 디자인 에셋, 회사 문서에 의존한다.

에이전트도 비슷한 환경이 필요하다. 작업할 컴퓨터, 디자인 과정의 각 부분을 위한 도구, 그리고 디자이너가 작업에 가져오는 맥락이 그것이다. 하니스(harness)는 이 요소들을 하나로 모아준다. Deep Agents 는 하니스의 기반이 되는 것, 즉 에이전트 루프, 계획 수립, 파일, 서브에이전트, 맥락 관리를 제공한다. Managed Deep Agents 는 이를 패키징하여 프로덕션에서 실행한다. 우리는 그 주변에 환경을 구축하여, 에이전트가 프로젝트를 유지 관리하고 여러 도구를 넘나들며 결과물을 검사할 수 있는 컴퓨터를 제공했다.

harness_v1

그 하니스의 첫 버전은 모델을 대신해 디자인을 해주려 했다. 초기 모델들이 우리가 출시하고 싶은 모션 그래픽이나 론치 필름을 만들려면 많은 도움이 필요했다. 그들이 아직 스스로 알아내지 못한 부분을 보완하기 위해, 우리의 직관은 자신들의 디자인 판단을 더 많이 지시사항과 코드에 담는 것이었다.

그래서 우리는 타이틀, 레이아웃, 애니메이션을 위한 115개의 재사용 가능한 UI 컴포넌트로 구성된 디자인 시스템과, 이를 언제 어떻게 사용할지에 대한 가이드를 만들었다. 이는 모델에게 기존 디자인 집합을 제공하여, 처음부터 새로 내려야 하는 창의적 결정의 수를 줄여주었다.

덕분에 브랜드 일관성은 유지할 수 있었지만, 에이전트는 각 프레임마다 같은 레이아웃과 애니메이션을 거의 변화 없이 반복했다:

우리는 이 모델들이 언젠가 이 작업을 훌륭히 해낼 것임을 알고 있었기에, 그 순간을 위해 환경을 계속 구축하면서 그 과정에서 스킬과 도구를 실험해 보았습니다. 때로는 모델을 돕기 위해 더 많은 참고 자료나 더 상세한 지침을 추가하기도 했습니다. 다른 때에는 그것들을 완전히 제거하고 모델이 스스로 무엇을 할 수 있는지 살펴보기도 했습니다.

하지만 결과는 여전히 우리가 원하는 수준에 미치지 못했고, 그 격차를 좁히려면 점점 더 많은 엔지니어링 작업이 필요했습니다. 우리는 스킬에 규칙을 계속 추가하고, 더 많은 모션 코드를 작성하고, 모델이 할 수 없는 부분을 보완하기 위해 더 많은 컴포넌트를 만들었습니다.

그런 다음 Opus 5.5가 출시되었고, 품질이 즉시 눈에 띄게 향상되었습니다. 우리는 스킬을 다시 검토하여 하드코딩된 규칙 대부분을 제거하고 설계 원칙과 상위 수준의 가이던스만 유지했습니다. 결과는 더욱 개선되었고, 다양성은 늘고 반복은 줄었습니다. 드디어 모델이 우리가 이전까지 미리 만들어 주려 했던 창의적인 결정을 스스로 내리고 있었습니다.

이것은 우리의 Bitter Lesson(씁쓸한 교훈)모델의 약점을 보완하기 위해 설계된 규칙들은 모델이 발전함에 따라 덜 유용해집니다. 지속되는 것은 모델이 사용하는 도구, 참조하는 컨텍스트, 그리고 사람들이 모델의 작업을 안내하는 방식을 포함한 모델 주변의 환경입니다. 창의적인 결정을 미리 만들어 두는 대신, 우리는 새로운 세대의 모델 각각을 활용할 수 있을 만큼 하네스를 유연하게 만드는 데 집중했습니다.

디자이너의 컴퓨터

하네스가 실제로 작동하는 모습을 보여드리기 위해, Content Studio에게 비디오 프로젝트를 처음부터 끝까지 어떻게 진행하는지에 대한 영화를 만들어 달라고 요청했습니다. 그 결과물은 픽셀 정글 속 앵무새가 주연으로 나오며, David Attenborough 스타일의 내레이션(ElevenLabs로 목소리 생성)이 담겼습니다. 이 영화를 통해 하네스의 여러 층위, 즉 작업 뒤에 있는 컴퓨터, 도구, 컨텍스트를 살펴보겠습니다.

디자인은 반복적입니다. 무언가를 만들고, 살펴보고, 수정하는 과정을 종종 여러 번 거치게 됩니다. 따라서 에이전트는 전체 대화에 걸쳐 계속 작업할 수 있는 컴퓨터가 필요합니다. 각 Slack 스레드에는 자체적인 LangSmith 샌드박스격리된 파일시스템과 셸을 갖춘 Linux 머신이며, 해당 프로젝트는 스레드가 존재하는 동안 그곳에 머문다.

에이전트가 만드는 모든 것은 코드로 구축됩니다. 슬라이드용 HTML 페이지, 차트용 데이터 스펙, 비디오용 애니메이션 타임라인 등 무엇이든 그렇습니다. 이 덕분에 처음부터 다시 시작하지 않고도 쉽게 반복 작업을 할 수 있습니다. 누군가 앵무새를 더 일찍 등장시켜 달라고 요청하면, 에이전트는 타이밍 값 하나만 변경하고 아트워크나 카피에 영향을 주지 않은 채 다시 렌더링할 수 있습니다. 평면 이미지나 생성된 비디오 클립에서는 사소한 수정조차 전체 애셋을 다시 만드는 일로 이어질 수 있습니다.

브리프, 플랜, 씬 코드, 오디오, 렌더 모두 하나의 프로젝트 폴더에 담기며, 이 작업의 모든 하위 에이전트가 그 폴더를 기반으로 작업합니다.

게다가 우리는 작업의 각 층위에서 디자이너가 손을 뻗는 도구들을 설치했습니다:

모션은 가장 어려운 계층입니다. 두 개의 엔진에서 실행됩니다:

1. 편집용 HyperFrames: HyperFrames, 동영상을 웹 페이지로 변환한다. 클립, 화면 녹화, 자막 및 텍스트는 그 페이지 위의 요소일 뿐이며, GSAP 타임라인에서 요소들을 자유롭게 배치합니다. 그래서 누군가 웨비나 자막 달기를 요청하거나 제품 데모를 편집해 달라고 하면, 에이전트가 웹 페이지를 편집하듯이 처리합니다. CLI는 기본적으로 에이전트의 편집 스위트 역할을 합니다. 컴포지션 린트 검사, 확인용 프레임 추출, 편집본 렌더링 등입니다. 우리는 또한 설치합니다 HeyGen의 공식 스킬, 따라서 에이전트는 이를 만든 사람들로부터 형식을 학습합니다.
2. motion-studio 애니메이션용: 웹 페이지는 빠른 움직임을 흐릿하게 하거나 사물을 빛나게 하거나 로고를 3D로 회전시킬 수 없는데, 그것이야말로 우리가 원했던 오리지널 애니메이션의 마감이었습니다. 그래서 우리는 자체 캔버스 엔진을 만들었습니다. 에이전트가 모든 프레임의 모든 픽셀을 그리는 코드를 작성하고, 엔진은 카메라 셔터가 움직임을 흐릿하게 만드는 것과 같은 방식으로 최대 16개의 순간을 각 픽셀에 블렌딩합니다. 앵무새 영화는 바로 이런 방식으로 만들어졌습니다.

두 엔진 모두 각 프레임을 타임스탬프를 기준으로 렌더링하므로, 10초 지점의 프레임은 언제 렌더링되든 동일하게 보입니다. 이를 통해 에이전트는 전체 영화를 렌더링하지 않고도 개별 순간을 검토할 수 있으며, 여러 프레임을 병렬로 렌더링하는 것도 가능합니다. 오디오도 같은 타임라인에서 실행되어 내레이션, 음악, 효과음이 영상과 동기화 상태를 유지합니다.

이 설정으로 에이전트는 거의 모든 것을 만들 수 있습니다. 하지만 별도의 지침이 없으면 우리의 디자인 선택이 아니라 모델 자신의 디자인 선택에 따라 작업합니다. 다음 과제는 이 에이전트가 우리의 브랜드와 디자인 표준에 맞춰 작업하도록 가르치는 것이었습니다.

디자이너의 뇌

우리는 에이전트의 지식을 각각 명확한 목적을 가진 네 가지 뚜렷한 기능을 중심으로 구성했습니다. 스킬(Skills)은 특정 작업을 수행하는 방법을 안내하고, 위키(wiki)는 우리 회사에 대한 맥락과 좋은 작업이 어떤 모습인지를 제공합니다. 측정 가능한 모든 것은 코드로 작성된 결정론적 검사인 게이트(gate)가 처리합니다. 별도의 메모리 계층은 사람들이 시간이 지나며 에이전트에게 가르쳐준 내용을 기록합니다.

기술

에이전트가 요청을 받으면 가장 먼저 하는 일은 그것이 어떤 종류의 작업인지 파악하는 것입니다. 이는 당사의 media-production 기술입니다. 우리는 이것을 라우터 스킬 대부분이 하나의 테이블이기 때문입니다. 각 행은 특정 종류의 요청(캠페인, 리스타일, 썸네일, 게시물, YouTube 패키지, 출시 영화, 짧은 애니메이션)을 이를 처리하는 경로와 전문 기술에 매핑합니다. 라우터는 해당 작업에 공유 시각 캔버스가 필요한지 여부도 결정하며, 사소한 수정이 전체 프로세스로 넘어가지 않도록 합니다.

위와 같은 영화의 경우 라우터는 launch-film 대규모 모션 프로덕션 연출을 위해 설계된 스킬을 선택합니다. 저희의 총 48개 스킬, 전체 약 1,000개의 파일은 주제가 아닌 작업 단위로 범위가 지정되어 있어, 각 스킬의 설명은 사용하지 말아야 할 시점을 포함하여 라우팅 규칙처럼 읽힙니다.

스킬은 서로 반복하는 대신 조합됩니다. launch-film 스킬은 연출을 담당하고, motion-studio 스킬은 영상과 사운드를 만들어, 애니메이션의 기법은 한 번만 작성됩니다. launch-film 스킬은 또한 실행할 서브에이전트들의 역할 브리프(role brief)와, 코드로 샷 단위까지 재구성한 실제 88초 런치 필름의 케이스 스터디도 담고 있습니다. 이 케이스 스터디는 에이전트가 영화를 서브에이전트들 사이에서 어떻게 분할할지 학습한 부분입니다. 하드 씬 전환 지점에서 컷을 나누고, 하나의 서브에이전트로 연속적인 카메라 무브를 유지하며, 누구든 병렬로 작업하기 전에 공유 코드를 고정(freeze)합니다.

설명은 스킬만큼이나 도구에서도 중요합니다. 컨텍스트 사용량을 낮게 유지하기 위해, 저희는 MCP 도구를 내장 검색 뒤에 두었습니다. 에이전트는 처음에 저희 자체 도구만으로 시작하고, 도구 이름과 설명 전반에 걸친 키워드 검색을 통해 필요에 따라 추가 도구 스키마를 로드합니다.

위키

스킬이 작업 수행 방법을 설명한다면, 위키는 그 작업을 잘 해내는 데 필요한 컨텍스트와 참고 자료를 제공합니다. 위키는 브랜드 토큰, 그래픽 언어, 톤앤매너부터 플랫폼, 캠페인, 제품 정보에 이르기까지 모든 것을 다룹니다. 별도의 모션 위키는 연출, 기법, 사운드, 리뷰를 다루며, 70편의 레퍼런스 필름 분석도 함께 제공합니다.

이 정보를 스킬들에 걸쳐 중복하는 대신, 저희는 위키로 직접 링크합니다. 이렇게 하면 공유 지식이 한곳에 모여 업데이트가 더 쉬워집니다. 폰트 규칙 같은 것이 변경될 때 한 번만 업데이트하면 되고, 모든 스킬이 최신 버전을 참조할 수 있습니다.

저희가 어떻게 일하는지 아는 것이 모션 디자인 비용을 반드시 낮추어 주지는 않습니다. 잘못된 크리에이티브 결정은 여전히 몇 시간의 렌더링 비용을 초래할 수 있습니다.

스펙 기반 디자인

모션은 렌더 시간과 토큰 모두에서 잘못될 경우 특히 비용이 큽니다. 스토리보드 프레임 하나를 렌더링하는 데 약 50밀리초가 걸리는 반면, 완성된 필름 1초를 만드는 데는 8~40초가 걸립니다. 서브에이전트들이 모든 액트를 작성하고, 렌더링하고, 검토하면 이러한 비용은 빠르게 누적됩니다. 그래서 에이전트는 아이디어를 먼저 스토리보드 단계에서 발전시켜 저렴하게 여러 방향을 탐색하고, 방향이 승인되면 그때 본격적인 프로덕션으로 넘어갑니다.

이러한 탐색을 지원하기 위해, 저희는 에이전트에게 무드보드에서 작업하는 디자이너처럼 영감을 얻을 수 있는 레퍼런스 필름 라이브러리를 제공했습니다. 마음에 드는 룩을 찾지 못할 때는 이미지 모델을 사용해 새로운 레퍼런스를 생성하며, 가장 유망한 옵션을 다듬기 전에 빠른 초안부터 시작합니다. 이 이미지들은 비주얼 방향을 잡는 데 도움을 주며, 스토리보드와 최종 필름은 여전히 실제 타이포그래피와 브랜드 자산을 사용해 코드로 제작됩니다.

방향을 정하고 나면, 승인된 스토리보드가 나머지 필름 제작의 기준이 되는 스펙이 됩니다. 그런 다음 프로젝트는 세 단계를 거칩니다:

1. 스토리보드: 비주얼 아이디어, 카피, 샷에 합의하기 위한 단계.
2. 애니매틱(animatic): 오디오에 맞춘 러프 컷으로, 스틸 이미지로는 확인할 수 없는 페이싱을 점검하기 위한 단계.
3. 프로덕션: 서브에이전트들이 승인된 샷을 제작, 검증, 렌더링하는 단계.

처음에는 이 순서를 스킬의 지침에 기술했고, 에이전트가 시간을 절약하려고 리뷰를 건너뛰는 경우가 있었습니다. 이제는 파이프라인이 이를 코드로 강제하여, 모든 액트가 리뷰를 통과하기 전까지 조립 단계가 대기하도록 하고, 지침은 여전히 크리에이티브 판단을 안내합니다. 반드시 지켜져야 하는 순서는 코드에 담기고, 판단은 프롬프트에 남습니다.

프롬프트하지 말고 가리키기

여러 방향 중 하나를 고르는 것은 팀의 결정입니다. Slack은 작업을 요청하고 받는 데는 잘 맞지만, 스레드는 선형적인 텍스트이고 스토리보드는 공간적인 매체이기 때문에 피드백이 무언가를 가리키는 대신 그것이 어디 있는지 설명하는 방식으로 끝나고, 모든 변경 사항, 한 단어 수정조차도 새로운 프롬프트로 다시 에이전트를 거쳐야 합니다.

Paper 이 문제를 해결해 주었습니다. Paper는 에이전트를 염두에 두고 만들어진 디자인 캔버스로, MCP 서버를 통해 에이전트가 파일을 직접 제어할 수 있습니다. 사람들도 같은 파일에서 작업하며 방향들을 나란히 비교하거나, 특정 프레임에 댓글을 달거나, 직접 수정할 수 있습니다. 캔버스가 공유되기 때문에, 에이전트는 파일로 돌아가 그 댓글과 수정 사항을 활용해 다음 반복 작업을 진행할 수 있습니다.

과제는 Paper의 에이전트 도구가 데스크톱 앱 안에서만 실행되는 반면, 저희 에이전트는 클라우드 샌드박스에서 작동한다는 점이었습니다. 이 간극을 메우기 위해, 저희는 항상 켜져 있는 Linux 워커에서 가상 디스플레이와 인증된 브리지를 사용해 Paper Desktop을 헤드리스(headless)로 실행합니다. 단 한 번의 셋업으로 팀 전체를 지원합니다.

승인된 후에도 스토리보드를 완성된 필름으로 만드는 데는 몇 시간이 걸릴 수 있습니다. 그 시점에는 작업이 작은 프로젝트처럼 되어, 하나로 모여야 하는 여러 조각들이 병렬로 제작되고 있습니다. 이 모든 것을 조율하는 것은 에이전트의 단일 턴(turn)으로는 감당할 수 없습니다.

참모총장으로서의 에이전트

앞서 언급한 앵무새 필름이 Slack에서 프로덕션 중간에 진행되던 상황을 생각해 보십시오. 한 사람은 레퍼런스를 공유하고, 다른 한 사람은 다른 오프닝을 제안하며, 세 번째 사람은 네 번째 프레임에 피드백을 남기는데, 그 모든 동안 에이전트는 여전히 제작 중입니다. 이는 메모를 담당하는 사람이 동시에 영화 제작도 책임지는 브레인스토밍과 같습니다. 동기식(synchronous) 서브에이전트는 메인 에이전트가 그들이 끝나기를 기다려야 하므로, 그 사이 사람들이 에이전트와 상호작용할 방법이 없어 여기서는 잘 맞지 않습니다.

이를 해결하기 위해, 저희는 서브에이전트를 비동기식(asynchronous)으로 만들고 메인 에이전트의 역할을 구현자에서 참모총장으로 바꾸었습니다. 메인 에이전트는 복잡한 프로젝트를 작고 고립된 작업들로 나누어 서브에이전트들에 할당하고, 작업을 병렬로 실행합니다. 그와 동시에 상황이 변할 때마다 팀에 알려, 사람들이 계속해서 피드백을 주고 프로젝트의 방향을 이끌 수 있도록 합니다.

각 작업에 대해 메인 에이전트는 역할, 관련 컨텍스트, 파일 소유권, 작업 검증 방법을 담은 명확한 브리프가 포함된 서브에이전트 프로필을 생성합니다. 또한 작업의 복잡도에 따라 모델과 effort 수준을 선택합니다.

메인 에이전트가 작업을 조율할 수 있도록 소수의 도구도 추가했습니다:

• start_task 서브에이전트에게 작업 일부를 백그라운드로 넘깁니다
• check_tasks 실행 중인 작업을 보여주고 완료된 보고서를 읽어옵니다
• cancel_task 그리고 resume_task 더 이상 브리프에 맞지 않는 작업을 중단하거나 중단된 지점부터 다시 진행합니다
• report_progress 서브에이전트가 작업 도중 업데이트를 보낼 수 있게 합니다
• schedule_wakeup 메인 에이전트에 타이머를 제공하여 다음 실행을 트리거하고 작업을 계속합니다

내부적으로 각 서브에이전트는 백그라운드 작업으로 실행되는 일반적인 Deep Agents task 도구입니다. 작업이 완료되면 우리 코드가 결과를 담아 메인 에이전트의 새 실행을 큐에 추가합니다. 사람들도 실행 중에 메인 에이전트의 방향을 조정할 수 있는데, 작업 중에 도착한 메시지는 다음 모델 호출 전에 삽입되기 때문입니다. 서브에이전트들은 프로젝트 폴더를 통해 조율하며, 각자 소유한 파일만 작성하고 진행 상황을 디스크에 유지합니다.

작업이 백그라운드에서 실행되는 동안 스레드에는 진행 상황이 표시되어야 합니다. 메인 에이전트는 계획과 예상 소요 시간(ETA), 실행 중인 서브에이전트가 표시되는 실시간 상태 줄, 렌더링 진행률과 비용, 각 편집에 대한 확인 응답, 그리고 무엇이든 공개되기 전의 승인 카드로 스레드를 최신 상태로 유지합니다.

이 접근 방식의 가장 명확한 테스트 중 하나는 52장짜리 프레젠테이션의 디자인을 바꾸는 하룻밤 작업에서 나왔습니다. 에이전트는 먼저 샘플 슬라이드 3장을 만들고 자신의 작업을 검토한 뒤, 승인을 위해 번호가 매겨진 배치로 나머지 슬라이드를 진행했습니다. 작업 중간에 새 슬라이드 2장도 추가했습니다. 하룻밤 동안 메인 에이전트는 약 1시간 동안 실행되었고, 그 서브에이전트들은 총 6시간 이상 작업했으며, 이 모든 과정에서 대화는 차단되지 않았습니다.

자가 개선 하네스

팀과 몇 달간 함께 일해 온 디자이너는 팀의 선호도를 파악하고 같은 피드백을 두 번 들을 필요가 없습니다. 기억이 없다면 에이전트는 새로운 스레드마다 처음부터 다시 시작해야 할 것입니다. 이를 피하기 위해 우리는 두 가지 학습 루프를 구축했습니다. 빠른 루프는 사람들이 피드백을 주는 즉시 이를 기록하고, 느린 루프는 백그라운드에서 완료된 프로젝트로부터 학습합니다.

빠른 루프: 누군가 규칙이나 선호도를 공유하면 에이전트는 같은 턴에 이를 저장합니다. Managed Deep Agents 는 메모리를 두 계층의 일반 파일로 저장하는데, 하나는 팀 전체가 공유하고 다른 하나는 각 개인에게 고유합니다.

개인 선호도는 스레드 간에 이어지지만, 공유 표준이 우선하며, 회사 채널을 위해 만들어진 모든 것은 회사의 톤을 따릅니다. 각 계층에는 모든 모델 호출 시 함께 로드되는 AGENTS.md 파일이 있습니다. 초기 버전이 500K 토큰까지 커진 후, 우리는 이제 이 파일들을 200줄 인덱스로 제한합니다.

느린 루프: 각 작업이 끝나면 우리의 learn_from_job 도구가 가벼운 서브에이전트를 실행하여 최대 5개의 근거 기반 교훈을 기록하고 사용된 스킬과 연결합니다. 이후 작업들은 이 교훈들을 읽고 평가하며, 일주일에 한 번 백그라운드 에이전트가 유용하다고 입증된 교훈들을 스킬과 위키에 통합합니다.

다음 단계

초기 리뷰들을 기억하시나요? 가장 큰 개선은 디자이너들의 판단을 리뷰 스레드 곳곳에 흩어두는 대신, 에이전트가 학습할 수 있는 공유 환경에 담은 데서 나왔습니다. 이 과정에서 우리는 디자인 작업을 더 많은 사람들이 접근할 수 있게 만들었습니다.

다음으로, 우리는 에이전트가 캠페인 전체 수명 주기를 관리하기를 원하며, 그 일부는 이미 작동하고 있습니다. 에이전트는 승인 권한을 가진 사람이 서명하면 Buffer를 통해 회사 소셜 게시물을 발행하고, 직원들이 자신의 계정에서 공유할 수 있도록 게시물 초안을 작성하며, 인용할 가치가 있는 게시물을 제안하는 일일 검토를 포함한 예정된 루틴을 실행합니다.

우리의 목표는 이를 더 발전시켜, 하나의 승인된 크리에이티브 방향이 하나의 스레드에서 전체 캠페인을 이끌도록 하는 것입니다. 에이전트는 브리프를 작성하고, 각 채널용 자산을 만들고, 게시물을 예약하고, 팀이 이를 확산하도록 돕고, 성과 데이터를 활용해 다음 캠페인에 반영할 것입니다. 사람들은 여전히 모든 것이 공개되기 전에 검토하고 승인합니다.

나만의 디자인 에이전트 만들기: 이 오픈소스 저장소 에는 이 글의 하네스가 담겨 있습니다: 샌드박스 컴퓨터, 스킬, 위키와 메모리, 비동기 서브에이전트, 그리고 Slack UX. 포크해서 브랜드 토큰, 폰트, 스킬을 추가하고 다음과 함께 팀의 Slack에 배포하세요: Managed Deep Agents.

그렇다면 10월 28일에 열리는 GTM Engineering Live 10월 28일에 진행됩니다. 저희는 harness와 UX의 내부 구조를 깊이 파헤치고, 이 글에 담지 못한 작업 내용도 보여드릴 예정입니다.