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

https://www.langchain.com/blog/design-agent

위의 홍보 영상은 Content Studio가 만들었습니다. Content Studio는 Slack에서 프롬프트 하나만으로 영상, 소셜 그래픽, UI 재현 이미지, 슬라이드 덱 등을 만들 수 있는 저희 디자인 에이전트입니다. 에이전트가 만드는 모든 결과물은 코드로 작성됩니다.

Content Studio는 전부 사내에서 Managed Deep Agents 위에 구축했습니다. 지금은 사내에서 가장 널리 쓰이는 GTM 에이전트 가운데 하나가 되었지만, 처음부터 그랬던 것은 아닙니다. 초기 반응은… 썩 좋지 않았습니다.

Content Studio의 작업물에 대한 초기 Slack 반응입니다.

그렇다면 저희는 어떻게 그렇게 낮은 품질에서 여기까지 올 수 있었을까요?

Content Studio의 작업물에 대한 이후 Slack 반응입니다.

저희는 넉 달 동안 Content Studio에 저희의 안목과 디자인 원칙을 가르쳤습니다. 대부분은 회사 전체가 보는 앞에서 에이전트가 실수하는 모습을 지켜보며 가르친 것입니다.

이 글에서는 저희 GTM 엔지니어링 팀이 디자인 팀과 함께 Content Studio를 처음부터 어떻게 만들었는지 살펴봅니다. 저희에게 좋은 디자인이란 무엇인지, 에이전트에게 저희의 안목을 어떻게 가르쳤는지, 그리고 정지 이미지부터 출시 영상까지 무엇이든 만들 수 있게 해 주는 하네스를 다룹니다.

저희 디자인 에이전트를 오픈소스로 공개했습니다. 오픈소스 저장소를 포크하고, 브랜드 토큰과 폰트, 스킬을 추가한 다음, Managed Deep Agents로 팀의 Slack에 배포해 보세요.

GTM Engineering Live 녹화본도 확인해 보세요. 하네스와 UX의 내부를 자세히 들여다보고, 이 글에 다 담지 못한 작업도 보여 드립니다.

규모를 감당하는 디자인 에이전트 만들기

LangChain은 빠르게 움직입니다. 제품 출시 캠페인, 웨비나, 블로그, 이벤트가 끊이지 않습니다. 각 활동에는 블로그 헤더와 다이어그램부터 덱, 영상, 광고 소재까지 다양한 결과물이 필요합니다. 저희 디자인 팀은 일손이 빠듯했고, 반복적인 요청에 밀려 더 전략적이고 혁신적인 작업을 할 여유가 없었습니다. 작은 스타트업인 저희에게는 회사의 누구나 브랜드에 맞는 고품질 결과물을 손쉽게 만들 방법이 필요했습니다.

이런 요구를 해결하려고 저희는 Slack 안에 사는 디자인 에이전트인 Content Studio를 만들었습니다. 팀원이 원하는 것을 설명하고 관련 콘텐츠나 브리프를 첨부하면, 에이전트가 브랜드에 맞게 완성된 파일을 돌려줍니다. Content Studio를 만들려면 세 가지가 필요했습니다.

1. 디자이너의 전문적인 판단을 에이전트의 스킬과 검사에 담아, 무엇이 좋은 결과물인지 에이전트가 알게 하는 것.
2. 모델을 둘러싼 맞춤형 환경. 여기에는 디자인 작업의 모든 계층에 쓸 도구를 갖춘 영상 편집용 컴퓨터가 포함됩니다.
3. 알맞은 UX. 팀 전체가 Slack 스레드 하나에서 몇 시간씩 이어지는 프로젝트에 함께 참여할 수 있어야 합니다.

Content Studio 아키텍처입니다. Managed Deep Agents 위에서 Slack 스레드, 메인 에이전트, 비동기 서브에이전트, 스킬과 위키, 메모리, 관리형 도구, 스레드별 샌드박스가 동작합니다.

Managed Deep Agents는 Content Studio를 사내에서 프로덕션 수준으로 운영하는 데 필요한 모든 것을 제공했습니다. 관리형 LangSmith Sandbox, Slack 연동, 관리형 도구, 범위가 지정된 에이전트 메모리, 에이전트 실행 예약 기능입니다. 덕분에 작은 팀이 밑단 인프라 작업 대신 디자인 작업, 즉 스킬과 도구와 Slack 경험에 시간을 쏟을 수 있습니다.

주요 성과

• Content Studio는 슬라이드 덱 80개 이상을 포함해 회사 전반에 3,000개가 넘는 결과물을 만들어 냈습니다. 그중 한 덱은 저희 유튜브 영상 가운데 오가닉 조회수가 가장 높은 영상에 쓰이기도 했습니다.
• Content Studio의 작업물이 들어간 게시물은 X에서 약 450만 회 조회되었습니다.
• LangChain 계정에서 Content Studio의 비주얼이 들어간 게시물은 다른 게시물보다 좋아요를 약 2배, 북마크를 3.7배 더 받았습니다.
• 이제 요청 네 건 중 세 건은 마케팅 팀 밖에서 들어오며, 사용자의 75%는 매주 다시 찾아오는 재방문 사용자입니다.
• 요청 한 건에 드는 모델 비용의 중앙값은 9월 중순 약 8달러에서 현재 약 50센트로 줄었습니다. Managed Deep Agents로 이전한 뒤 저희가 직접 관리하는 코드는 약 80% 줄었습니다.

Content Studio로 내보낸 결과물 모음과 게시물 지표입니다.

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

구축 과정을 살펴보기 전에, 세기의 논쟁부터 짚고 넘어가겠습니다. AI가 정말 좋은 디자인을 만들어 낼 수 있을까요?

모델은 이미 실행력이 좋아서 HTML과 CSS, 차트 명세, 애니메이션 타임라인을 작성할 수 있었습니다. 하지만 저희의 맥락을 몰랐기 때문에 익숙한 패턴에 손을 뻗었고, 이는 Anthropic이 “분포 수렴(distributional convergence)”이라고 부르는 현상입니다. 그 결과물은 세련돼 보이면서도 다른 백 개와 똑같아 보이거나, 아름답게 움직이면서도 하고 싶은 말을 끝내 전하지 못할 수 있었습니다. 익숙한 것이 늘 나쁜 것은 아니지만, 저희는 에이전트가 목적에 맞는 선택을 내리기를 바랐습니다.

Stripe의 디자인 총괄인 Katie Dill은 도움이 되는 비유를 듭니다. 제2차 세계대전 이후 빨리 지어야 한다는 압박 속에서, 건축업자들은 모더니즘의 깔끔한 형태와 장식 없는 표면을 계속해서 베꼈습니다. 복제품은 겉모습은 유지했지만 그 뒤에 있던 생각과 개성은 잃었습니다. Dill은 AI가 소프트웨어에도 같은 일을 할 수 있다고 경고합니다. Dill은 이를 “좀비 UI”라고 부르며, 관점이 있어야 한다고 말합니다. “그렇지 않으면 AI가 대신 정해 줄 것”이기 때문입니다.

좀비 UI입니다. 겉모습은 유지하고 그 뒤의 생각은 잃어버린 복제품을 말합니다.

저희는 AI가 디자인을 못한다고 생각하지 않습니다. 관점을 주지 않으면 관점이 없을 뿐이며, 저희의 관점을 주려면 저희의 안목을 가르쳐야 했습니다.

디자인 에이전트에게 안목 가르치기

안목이란 맞는 작업과 좋은 작업을 가르는 판단력입니다. 디자인에서는 두 레이아웃이 똑같이 올바른 폰트, 색상, 간격을 쓰더라도 그중 하나만 하고 싶은 말을 전할 수 있습니다. 안목은 Dill이 말하는 “알아차리는 데 정말 능숙해지는 것”에서 나옵니다.

저희는 그렇게 알아차리는 능력으로 AI 슬롭(AI slop)을 가려내는 법을 배웠습니다. AI 슬롭은 브리프가 어떤 결정을 에이전트에게 맡겨 둘 때 가장 자주 나타납니다.

예를 들어 아래 왼쪽 이미지는 로컬 코딩 에이전트가 저희 브랜드 스킬(색상, 폰트, 로고 등 포함)을 써서 만든 것입니다. 하지만 최종 결과물은 올바른 로고 락업, 텍스트 정렬, 어떤 색이 주 브랜드 색이고 어떤 색이 보조 브랜드 색인지 같은 핵심 요소를 놓쳤습니다.

같은 프롬프트로 Content Studio에서는 브랜드에 완벽히 맞는 이미지가 나왔습니다. 로컬 에이전트는 브리프가 다루지 않은 결정마다 자기가 가장 많이 본 것으로 빈칸을 채웠기 때문입니다. 이 방법론 덕분에 Content Studio는 같은 빈칸을 저희의 선택으로 채웠습니다.

왼쪽은 저희 브랜드 스킬을 쓴 로컬 코딩 에이전트의 결과물이고, 오른쪽은 같은 프롬프트로 만든 Content Studio의 결과물입니다.

Content Studio에 준 가이드라인은 색상 토큰, 폰트 굵기, 간격, 정렬 같은 기본에서 시작했습니다. 하지만 개선의 상당 부분은 그 위에 더한 것에서 나왔습니다. 프레임마다 초점을 하나만 두는 것 같은 디자인 원칙, 흔한 AI 디자인 패턴을 막는 가드레일, 그리고 피드백 하나하나의 이유를 함께 넣었습니다. 더 나아진 기반 모델과 맞물려, 이런 요소 덕분에 Content Studio는 디자이너처럼 생각하고 소통하는 법을 익혀 갔습니다.

처음부터 그랬던 것은 아닙니다. 초기 모션 그래픽 하나에서는 새 한 마리가 1초도 안 되는 동안 빛의 리본을 뒤에 끌며 화면 밖으로 날아갑니다. 저희는 날카로운 모서리가 없게 해 달라고 했지만, 첫 결과물은 투박했고 모서리가 거칠게 둥글려져 있었습니다. 디자이너라면 저희 뜻을 알아들었을 것입니다. 모서리는 부드러워져야 하고, 꼬리는 새가 움직이는 반대 방향으로 가늘어지며 사라져야 했습니다.

“날카로운 모서리 없이”를 시도한 초기 결과물(왼쪽)과 저희가 의도한 모습(오른쪽)입니다.

이후 반복에서는 에이전트가 그 디테일을 디자이너의 눈으로 평가하고 있었습니다. 새의 꼬리가 있어야 할 위치를 간단한 스케치로 짚은 다음, 리본이 꼬리에 붙어 있는지 프레임 단위로 확인하는 검사를 스스로 만들었습니다. 대부분의 시청자는 이런 디테일을 의식적으로 알아차리지 못하겠지만, 무언가 어긋나 있다면 느낄 것입니다.

에이전트의 자체 검사입니다. 리본의 뿌리(노란색)는 새가 화면을 벗어날 때까지 새의 꼬리(자홍색)에 붙어 있습니다.

측정할 수 있는 문제가 가장 풀기 쉬웠습니다. 기본 대문자 표기 방식은 예전에는 리뷰에서 자주 지적됐지만, 이제는 자동 검사가 모든 경우를 잡아냅니다. 더 어려운 결정은 주관적인 것들입니다. 캠페인 아이디어가 충분히 강력한지, 메시지가 분명하게 전달되는지, 실행 결과가 대상에게 와닿는지 같은 것입니다. 디자이너가 이런 판단을 내리면, 저희는 그 이유를 스킬에 담아 에이전트가 이후 초안에 적용할 수 있게 합니다.

Content Studio는 누가 디자인 작업을 할 수 있는지를 바꿨습니다. PM, 엔지니어, 창업자도 Slack에서 에이전트에게 브리프를 주고, 브랜드에 맞고 바로 내보낼 수 있는 결과물을 받아 갈 수 있습니다. 이제 요청 네 건 중 세 건은 마케팅 팀 밖에서 들어옵니다. 디자이너의 역할은 모든 결과물을 직접 만들기보다 방향을 정하고 작업을 검토하는 크리에이티브 디렉터에 더 가까워졌습니다.

디자인 판단을 제대로 갖추는 것은 과정의 한 부분이었습니다. 에이전트가 그 판단을 실행할 수 있도록 도구와 환경도 줘야 했습니다.

미디어 하네스 만들기

디자이너는 여러 도구를 오가며 일합니다. 정지 이미지는 Photoshop, 모션은 영상 엔진, 프로토타이핑과 협업은 공유 캔버스에서 합니다. 브랜드 가이드라인, 디자인 에셋, 회사 문서에도 기댑니다.

LangSmith Sandbox 안에 있는 디자이너의 컴퓨터입니다. 앱 창, 파일, 독이 있습니다.

에이전트에게도 비슷한 환경이 필요합니다. 작업할 컴퓨터, 디자인 과정의 여러 부분에 쓸 도구, 그리고 디자이너가 작업에 가져오는 맥락입니다. 하네스가 이 조각들을 하나로 묶습니다. Deep Agents는 에이전트 루프, 계획, 파일, 서브에이전트, 컨텍스트 관리를 포함한 기반 하네스를 제공합니다. Managed Deep Agents는 이를 패키징해 프로덕션에서 실행합니다. 저희는 그 주변 환경을 만들어, 에이전트가 프로젝트를 유지하고 여러 도구를 오가며 작업하고 결과를 점검할 수 있는 컴퓨터를 줬습니다.

harness_v1

첫 번째 버전의 하네스는 모델 대신 디자인을 해 주려 했습니다. 초기 모델은 저희가 내보내고 싶을 만한 모션 그래픽이나 출시 영상을 만들려면 도움이 많이 필요했습니다. 모델이 아직 스스로 알아내지 못하는 부분을 메우려고, 저희는 직관적으로 저희의 디자인 판단을 지시문과 코드에 더 많이 넣었습니다.

그래서 제목, 레이아웃, 애니메이션을 위한 재사용 가능한 UI 컴포넌트 115개와, 언제 어떻게 쓸지에 대한 안내로 이뤄진 디자인 시스템을 만들었습니다. 덕분에 모델은 기존 디자인을 바탕으로 작업할 수 있었고, 처음부터 내려야 하는 창의적 결정의 수가 줄었습니다.

첫 번째 하네스에 미리 만들어 둔 UI 컴포넌트 115개 모음입니다.

덕분에 브랜드는 지킬 수 있었지만, 에이전트는 프레임마다 같은 레이아웃과 애니메이션을 별다른 변화 없이 되풀이했습니다.

저희는 모델이 결국 이 작업을 아주 잘하게 될 것을 알았기에, 그때를 대비해 환경을 계속 만들면서 스킬과 도구를 이것저것 실험했습니다. 어떤 때는 모델을 돕기 위해 참고 자료나 더 자세한 지시를 추가했습니다. 또 어떤 때는 그것들을 통째로 빼고 모델이 혼자서 무엇을 할 수 있는지 지켜봤습니다.

하지만 결과는 여전히 원하는 수준에 못 미쳤고, 그 격차를 좁히는 데 드는 엔지니어링 작업은 점점 늘어났습니다. 모델이 못하는 부분을 메우려고 스킬에 규칙을 계속 추가하고, 모션 코드를 더 작성하고, 컴포넌트를 더 만들었습니다.

그러다 Opus 5.5가 나왔고, 품질이 곧바로 뛰어올랐습니다. 저희는 스킬을 다시 살펴보고 하드코딩된 규칙 대부분을 걷어 내되, 디자인 원칙과 상위 수준의 안내는 남겼습니다. 결과는 더 좋아졌고, 다양성은 늘고 반복은 줄었습니다. 마침내 모델이 예전에 저희가 미리 만들어 주려 했던 창의적 결정을 스스로 내리고 있었습니다.

이것이 저희의 쓰라린 교훈(Bitter Lesson)이었습니다. 모델의 약점을 메우려고 만든 규칙은 모델이 나아질수록 쓸모가 줄어듭니다. 오래 남는 것은 모델을 둘러싼 환경입니다. 모델이 쓰는 도구, 모델이 참고하는 맥락, 사람이 모델의 작업을 이끄는 방식이 여기에 해당합니다. 저희는 창의적 결정을 미리 만들어 두는 대신, 새로운 세대의 모델이 나올 때마다 그 능력을 활용할 수 있을 만큼 하네스를 유연하게 만드는 데 집중했습니다.

디자이너의 컴퓨터

하네스가 실제로 어떻게 동작하는지 보여 주려고, Content Studio에게 영상 프로젝트를 처음부터 끝까지 어떻게 진행하는지에 관한 영상을 만들어 달라고 했습니다. 결과물은 픽셀 정글 속 앵무새가 주인공이고, David Attenborough 스타일의 내레이션(ElevenLabs로 음성 합성)이 깔린 영상입니다. 이 영상을 따라가며 하네스의 계층, 즉 작업을 뒷받침하는 컴퓨터, 도구, 맥락을 살펴보겠습니다.

디자인은 반복적인 작업입니다. 무언가를 만들고, 들여다보고, 고치기를 여러 번 되풀이합니다. 그래서 에이전트에게는 대화 전체에 걸쳐 계속 작업할 수 있는 컴퓨터가 필요합니다. Slack 스레드마다 파일 시스템과 셸을 갖춘 격리된 Linux 머신인 LangSmith Sandbox가 하나씩 주어지며, 프로젝트는 스레드가 살아 있는 동안 그곳에 머뭅니다.

에이전트가 만드는 모든 것은 코드로 만들어집니다. 슬라이드용 HTML 페이지든, 차트용 데이터 명세든, 영상용 애니메이션 타임라인이든 마찬가지입니다. 그래서 처음부터 다시 시작하지 않고도 쉽게 반복 작업을 할 수 있습니다. 누군가 앵무새를 더 일찍 등장시켜 달라고 하면, 에이전트는 타이밍 값 하나만 바꿔 다시 렌더링하면 되고, 그림이나 문구에는 영향을 주지 않습니다. 평면 이미지나 생성된 영상 클립이라면 작은 수정에도 결과물 전체를 다시 만들어야 할 수 있습니다.

브리프, 계획, 장면 코드, 오디오, 렌더링 결과물은 모두 하나의 프로젝트 폴더에 있으며, 이 작업에 참여하는 모든 서브에이전트가 이 폴더를 기반으로 일합니다.

에이전트의 컴퓨터에 있는 프로젝트 폴더입니다. 브리프, 계획, 장면 코드, 오디오, 렌더링 결과물이 들어 있습니다.

그 위에 디자이너가 작업의 각 계층에서 찾을 법한 도구를 설치했습니다.

에이전트의 컴퓨터에 설치된 디자이너의 도구 상자입니다.

모션은 가장 어려운 계층입니다. 모션은 두 가지 엔진으로 돌아갑니다.

1. 편집용 HyperFrames: HeyGen의 오픈소스 영상 프레임워크인 HyperFrames는 영상을 웹 페이지로 바꿉니다. 클립, 화면 녹화, 자막, 텍스트는 그 페이지의 요소일 뿐이고, GSAP 타임라인이 이 요소들을 움직입니다. 그래서 누군가 웨비나에 자막을 달거나 제품 데모를 편집해 달라고 하면, 에이전트는 웹 페이지를 고치듯 영상을 편집합니다. HyperFrames의 CLI는 사실상 에이전트의 편집 도구 모음입니다. 컴포지션을 린트하고, 확인할 프레임을 뽑아 보고, 편집본을 렌더링합니다. HeyGen의 공식 스킬도 설치해 두어서, 에이전트는 이 포맷을 만든 사람들에게서 직접 포맷을 배웁니다.
2. 애니메이션용 motion-studio: 웹 페이지로는 빠른 움직임에 블러를 주거나, 무언가를 빛나게 하거나, 로고를 3D로 돌릴 수 없는데, 저희가 오리지널 애니메이션에서 원한 마감이 바로 그런 것이었습니다. 그래서 자체 캔버스 엔진을 만들었습니다. 에이전트는 모든 프레임의 모든 픽셀을 그리는 코드를 작성하고, 엔진은 카메라 셔터가 움직임을 흐리게 하듯 각 프레임에 최대 16개의 순간을 섞어 넣습니다. 앵무새 영상도 이렇게 만들었습니다.

HyperFrames는 웹 페이지의 요소를 움직이고, motion-studio는 모션 블러를 넣어 모든 픽셀을 칠합니다.

두 엔진 모두 각 프레임을 타임스탬프를 기준으로 렌더링하므로, 10초 지점의 프레임은 언제 렌더링하든 똑같이 보입니다. 덕분에 에이전트는 영상 전체를 렌더링하지 않고도 특정 순간만 확인할 수 있고, 여러 프레임을 병렬로 렌더링할 수도 있습니다. 오디오도 같은 타임라인에서 돌아가므로 내레이션, 음악, 효과음이 화면과 맞아떨어집니다.

이렇게 갖춰 두면 에이전트는 거의 무엇이든 만들 수 있습니다. 하지만 추가 안내가 없으면 저희의 디자인 선택이 아니라 모델 자신의 디자인 선택을 기본값으로 삼습니다. 다음 과제는 에이전트가 저희의 브랜드와 디자인 기준 안에서 일하도록 가르치는 것이었습니다.

디자이너의 두뇌

저희는 에이전트의 지식을 목적이 분명한 네 가지 기능으로 나눠 정리했습니다. 스킬은 특정 작업을 수행하는 방법을 안내하고, 위키는 회사에 대한 맥락과 좋은 작업이 어떤 모습인지 알려 줍니다. 측정할 수 있는 것은 모두 게이트, 즉 코드로 작성한 결정적 검사가 처리합니다. 별도의 메모리 계층은 사람들이 시간이 지나며 에이전트에게 가르친 내용을 담습니다.

스킬

에이전트가 요청을 받으면 가장 먼저 어떤 종류의 작업인지 파악합니다. 이 일은 media-production 스킬이 맡습니다. 이 스킬은 대부분이 표 하나로 되어 있어서 저희는 이를 라우터 스킬이라고 부릅니다. 표의 각 행은 요청의 종류(캠페인, 스타일 변경, 썸네일, 게시물, 유튜브 패키지, 출시 영상, 짧은 애니메이션)를 그 요청을 처리할 경로와 전문 스킬에 연결합니다. 라우터는 작업에 공유 비주얼 캔버스가 필요한지도 결정하고, 작은 수정은 전체 프로세스를 거치지 않게 합니다.

media-production 라우터 스킬의 라우팅 표입니다.

위와 같은 영상이라면 라우터는 대규모 모션 제작을 연출하도록 설계된 launch-film 스킬을 고릅니다. 저희 스킬 48개(파일로는 1,000개 가까이)는 각각 주제가 아니라 작업 단위로 범위가 정해져 있어서, 스킬 설명이 라우팅 규칙처럼 읽히고 언제 쓰지 말아야 하는지도 담겨 있습니다.

스킬은 서로 반복하지 않고 조합됩니다. launch-film이 연출하고 motion-studio가 화면과 소리를 만들기 때문에, 애니메이션 기술은 한 번만 작성하면 됩니다. launch-film에는 이 스킬이 띄울 서브에이전트를 위한 역할 브리프와, 실제 88초짜리 출시 영상을 코드로 한 컷 한 컷 재현한 사례 연구도 들어 있습니다. 에이전트는 이 사례 연구에서 영상을 서브에이전트들에게 나눠 맡기는 법을 배웠습니다. 장면이 확 바뀌는 지점에서 자르고, 끊김 없이 이어지는 카메라 움직임은 서브에이전트 하나에게 맡기며, 병렬 작업을 시작하기 전에 공유 코드를 동결합니다.

스킬 폴더입니다. 각 스킬은 하나의 작업 단위로 범위가 정해져 있습니다.

설명은 스킬만큼이나 도구에도 중요합니다. 컨텍스트 사용량을 줄이려고 MCP 도구는 내장 검색 뒤에 두었습니다. 에이전트는 저희 자체 도구만 가진 채 시작하고, 필요할 때 도구 이름과 설명을 키워드로 검색해 추가 도구 스키마를 불러옵니다.

위키

스킬이 작업하는 방법을 설명한다면, 위키는 작업을 잘하는 데 필요한 맥락과 참고 자료를 제공합니다. 브랜드 토큰, 그래픽 언어, 보이스부터 플랫폼, 캠페인, 제품 정보까지 모든 것을 다룹니다. 별도의 모션 위키는 연출, 기법, 사운드, 리뷰를 다루며, 참고 영상 70편에 대한 분석도 함께 담고 있습니다.

저희는 이 정보를 스킬마다 복제하지 않고 위키에 직접 링크합니다. 그러면 공유 지식이 한곳에 모이고 갱신도 쉬워집니다. 폰트 규칙 같은 것이 바뀌면 한 번만 고치면 되고, 모든 스킬이 최신 버전을 참조할 수 있습니다.

위키입니다. 브랜드, 보이스, 플랫폼, 캠페인, 제품 참고 자료, 모션 위키로 이뤄져 있습니다.

저희가 어떻게 일하는지 안다고 해서 모션 디자인 비용이 꼭 줄어드는 것은 아닙니다. 창의적 결정을 하나 잘못 내리면 여전히 렌더링에 몇 시간을 날릴 수 있습니다.

스펙 기반 디자인

모션은 잘못 만들었을 때 렌더링 시간과 토큰 양쪽에서 특히 비쌉니다. 스토리보드 프레임 하나는 렌더링에 약 50밀리초가 걸리지만, 완성 영상은 1초 분량에 8초에서 40초가 걸립니다. 서브에이전트들이 막마다 작성하고, 렌더링하고, 리뷰하다 보면 이 비용은 빠르게 불어납니다. 그래서 에이전트는 먼저 스토리보드에서 아이디어를 발전시킵니다. 스토리보드에서는 여러 방향을 싸게 탐색할 수 있고, 방향이 승인되면 그때 본격적인 제작에 들어갑니다.

그런 탐색을 돕기 위해, 디자이너가 무드 보드를 보며 작업하듯 에이전트가 영감을 얻을 수 있는 참고 영상 라이브러리를 줬습니다. 알맞은 룩을 찾지 못하면 에이전트는 이미지 모델로 새 참고 이미지를 생성합니다. 먼저 빠른 초안을 만든 다음 가장 가능성 있는 안을 다듬습니다. 이런 이미지는 시각적 방향을 잡는 데 도움을 주지만, 스토리보드와 최종 영상은 여전히 실제 타이포그래피와 브랜드 에셋을 써서 코드로 만듭니다.

영상의 방향을 탐색하면서 이미지 모델로 생성한 룩 참고 이미지입니다.

방향을 고르고 나면, 승인된 스토리보드가 영상의 나머지 부분을 만들 때 기준이 되는 명세가 됩니다. 그런 다음 프로젝트는 세 단계를 거칩니다.

1. 스토리보드: 시각적 아이디어, 문구, 샷에 대해 합의합니다.
2. 애니매틱: 오디오에 타이밍을 맞춘 러프 컷으로, 정지 이미지로는 보여 줄 수 없는 리듬을 확인합니다.
3. 제작: 서브에이전트들이 승인된 샷을 만들고, 검사하고, 렌더링합니다.

처음에는 이 순서를 스킬의 지시문에 적어 두었는데, 에이전트가 시간을 아끼려고 가끔 리뷰를 건너뛰었습니다. 지금은 파이프라인이 코드로 이 순서를 강제합니다. 그래서 모든 막이 리뷰를 통과할 때까지 조립은 기다리고, 창의적 판단은 여전히 지시문이 안내합니다. 반드시 지켜야 하는 순서는 코드에 두고, 판단은 프롬프트에 남겨 둡니다.

프롬프트하지 말고 가리키세요

여러 방향 가운데 하나를 고르는 것은 팀의 결정입니다. Slack은 작업을 요청하고 받는 데는 잘 맞지만, 스레드는 일렬로 이어지는 텍스트이고 스토리보드는 공간적입니다. 그래서 피드백은 무언가를 가리키지 못하고 그것이 어디에 있는지 설명하게 되며, 단어 하나를 고치는 것까지 모든 변경을 새 프롬프트로 에이전트에게 다시 보내야 합니다.

Paper가 이 문제를 해결해 줬습니다. Paper는 에이전트를 염두에 두고 만든 디자인 캔버스로, 에이전트가 파일을 직접 제어할 수 있는 MCP 서버를 갖추고 있습니다. 사람들도 같은 파일에서 작업하며 여러 방향을 나란히 비교하거나, 특정 프레임에 댓글을 남기거나, 직접 수정할 수 있습니다. 캔버스를 함께 쓰기 때문에 에이전트는 파일로 돌아와 그 댓글과 수정 사항을 다음 반복의 길잡이로 삼을 수 있습니다.

문제는 Paper의 에이전트 도구가 데스크톱 앱 안에서만 동작하는 반면, 저희 에이전트는 클라우드 샌드박스에서 돌아간다는 점이었습니다. 이 간극을 메우려고 저희는 항상 켜져 있는 Linux 워커에서 Paper Desktop을 헤드리스로 실행하고, 가상 디스플레이와 인증된 브리지로 둘을 연결합니다. 이 구성 하나로 팀 전체를 지원합니다.

팀의 댓글이 달린 Paper의 영상 스토리보드입니다.

승인을 받은 뒤에도 스토리보드를 완성된 영상으로 만드는 데는 몇 시간이 걸릴 수 있습니다. 그 시점이 되면 작업은 작은 프로젝트처럼 되어, 여러 조각을 병렬로 만들어 하나로 합쳐야 합니다. 이 모든 것을 조율하는 일은 에이전트의 한 턴으로 감당할 수 있는 범위를 넘어섭니다.

비서실장 역할을 하는 에이전트

앞서 본 앵무새 영상이 Slack에서 한창 제작 중이라고 해 봅시다. 한 사람은 참고 자료를 공유하고, 다른 사람은 다른 오프닝을 제안하고, 세 번째 사람은 네 번째 프레임에 피드백을 남깁니다. 그동안 에이전트는 여전히 영상을 만들고 있습니다. 회의록을 쓰는 사람이 영상 제작까지 책임지는 브레인스토밍과 비슷합니다. 동기식 서브에이전트는 여기서 잘 맞지 않습니다. 메인 에이전트가 서브에이전트가 끝나기를 기다려야 해서, 그동안 사람들이 메인 에이전트와 소통할 방법이 없기 때문입니다.

이 문제를 풀기 위해 저희는 서브에이전트를 비동기로 바꾸고, 메인 에이전트의 역할을 구현자에서 비서실장(chief of staff)으로 옮겼습니다. 메인 에이전트는 복잡한 프로젝트를 더 작고 독립된 작업으로 쪼개 서브에이전트에게 배정하고, 작업을 병렬로 돌립니다. 그동안 상황이 바뀔 때마다 팀에 알려서, 사람들이 계속 피드백을 주고 프로젝트의 방향을 잡을 수 있게 합니다.

메인 에이전트는 작업마다 서브에이전트 프로필을 만들고, 역할, 관련 맥락, 파일 소유권, 작업 검증 방법을 담은 명확한 브리프를 줍니다. 또한 작업의 복잡도에 따라 모델과 노력 수준(effort level)도 고릅니다.

메인 에이전트가 작업을 조율할 수 있도록 작은 도구 묶음도 추가했습니다.

• start_task는 작업 일부를 백그라운드에서 서브에이전트에게 넘깁니다
• check_tasks는 실행 중인 작업을 보여 주고 끝난 작업의 보고서를 읽습니다
• cancel_task와 resume_task는 더 이상 브리프에 맞지 않는 작업을 멈추거나, 멈췄던 지점부터 다시 이어 갑니다
• report_progress는 서브에이전트가 작업 도중에 진행 상황을 보낼 수 있게 합니다
• schedule_wakeup은 메인 에이전트에게 타이머를 줘서, 다음 실행을 일으켜 작업을 이어 가게 합니다

내부적으로 각 서브에이전트는 백그라운드 작업으로 실행되는 평범한 Deep Agents task 도구입니다. 서브에이전트가 끝나면 저희 코드가 그 결과를 담아 메인 에이전트의 새 실행을 큐에 넣습니다. 메인 에이전트가 실행되는 도중에도 사람들이 방향을 바꿀 수 있습니다. 메인 에이전트가 일하는 중에 도착한 메시지는 다음 모델 호출 앞에 끼워 넣어지기 때문입니다. 서브에이전트들은 프로젝트 폴더를 통해 조율하며, 각자 자기가 소유한 파일만 쓰고 진행 상황을 디스크에 남깁니다.

비서실장 역할을 하며 비동기 서브에이전트를 병렬로 돌리는 메인 에이전트입니다.

작업이 백그라운드에서 돌아가므로, 스레드에서는 무슨 일이 일어나고 있는지 보여야 합니다. 메인 에이전트는 계획과 예상 완료 시간(ETA), 실행 중인 서브에이전트와 렌더링 진행률과 비용을 보여 주는 실시간 상태 줄, 수정 요청마다의 확인 응답, 무언가를 공개하기 전의 승인 카드로 스레드를 최신 상태로 유지합니다.

긴 작업이 돌아가는 동안의 Slack 스레드입니다. 계획, ETA, 실시간 상태, 승인 카드가 보입니다.

이 접근법을 가장 분명하게 시험한 사례는 52장짜리 프레젠테이션을 리스킨하는 밤샘 작업이었습니다. 에이전트는 먼저 샘플 슬라이드 세 장을 만들고 자기 작업을 검토한 다음, 나머지 덱을 번호가 매겨진 묶음 단위로 진행하며 승인을 받았습니다. 도중에 새 슬라이드 두 장도 추가했습니다. 밤새 메인 에이전트는 약 1시간 동안 실행됐고, 서브에이전트들은 합쳐서 6시간 넘게 일했으며, 그동안 대화는 한 번도 막히지 않았습니다.

스스로 개선되는 하네스

한 팀과 몇 달을 함께 일한 디자이너는 그 팀의 취향을 익혀서, 같은 피드백을 두 번 들을 필요가 없습니다. 메모리가 없다면 에이전트는 새 스레드마다 처음부터 시작해야 합니다. 이를 피하려고 저희는 학습 루프 두 개를 만들었습니다. 빠른 루프는 사람들이 피드백을 주는 즉시 그 피드백을 담고, 느린 루프는 백그라운드에서 완료된 프로젝트로부터 배웁니다.

빠른 루프: 누군가 규칙이나 선호를 알려 주면, 에이전트는 같은 턴 안에 그것을 저장합니다. Managed Deep Agents는 메모리를 평범한 파일로 두 계층에 저장합니다. 하나는 팀 전체가 공유하고, 다른 하나는 사람마다 따로 둡니다.

Slack 스레드에서 에이전트가 팀 규칙을 공유 메모리에 저장하는 모습입니다.

개인 선호는 스레드를 넘어 이어지지만 공유 기준이 우선하며, 회사 채널용으로 만드는 것은 모두 회사의 보이스를 따릅니다. 각 계층에는 모든 모델 호출과 함께 불러오는 AGENTS.md 파일이 있습니다. 초기 버전이 50만 토큰까지 불어난 뒤로, 이제 이 파일은 200줄짜리 인덱스로 제한합니다.

느린 루프: 작업이 끝날 때마다 learn_from_job 도구가 가벼운 서브에이전트를 띄워, 근거가 있는 교훈을 최대 다섯 개까지 정리하고 그 작업에 쓰인 스킬과 연결합니다. 이후 작업들이 그 교훈을 읽고 평가하며, 일주일에 한 번 백그라운드 에이전트가 쓸모가 입증된 교훈을 스킬과 위키에 반영합니다.

느린 루프입니다. 이후 작업이 평가한 작업 노트를 매주 스킬과 위키로 승격합니다.

다음 단계

초기 리뷰를 기억하시나요? 가장 큰 개선은 디자이너의 판단을 리뷰 스레드 여기저기에 흩어 두지 않고, 에이전트가 배울 수 있는 공유 환경에 담은 데서 나왔습니다. 그 과정에서 더 많은 사람이 디자인 작업을 할 수 있게 되었습니다.

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

저희의 목표는 여기서 더 나아가, 승인된 크리에이티브 방향 하나로 스레드 하나에서 캠페인 전체를 끌고 가는 것입니다. 에이전트가 브리프를 쓰고, 채널별 결과물을 만들고, 게시물을 예약하고, 팀이 게시물을 확산하도록 돕고, 성과 데이터를 바탕으로 다음 캠페인을 준비하게 됩니다. 그래도 공개 전에는 여전히 사람이 모든 것을 검토하고 승인합니다.

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

GTM Engineering Live 녹화본도 확인해 보세요. 하네스와 UX의 내부를 자세히 들여다보고, 이 글에 다 담지 못한 작업도 보여 드립니다.