우리가 디자인 에이전트를 어떻게 구축했는지

주요 요약

맛은 맥락에서 비롯됩니다. 모델들은 이미 좋은 코드를 작성하지만, 당신의 디자이너들이 제시하는 원칙과 AI 오류에 대한 안전장치, 그리고 피드백의 근거를 필요로 하며, 이를 통해 당신의 스타일을 닮은 결과물을 만들어냅니다.

에이전트에게 디자이너용 컴퓨터를 제공하세요. 모든 Slack 스레드는 자체 샌드박스를 갖게 되며, 에이전트는 턴 간에 프로젝트를 보관하고 비디오 엔진, 이미지 도구 및 공유 캔버스를 넘나들며 작업하며 자신의 렌더링을 검사합니다.

모델이 개선되면 규칙을 삭제하세요. 모델의 약점을 보완하는 규칙은 유효 기간이 지나므로, 모델이 점점 더 발전함에 따라 설계 원칙을 유지하고 우회 방식은 제거해야 합니다.

장기간 실행되는 에이전트에는 멀티플레이어 UX가 필요합니다. 대규모 작업은 비동기 하위 에이전트에서 몇 시간 동안 실행되므로, Slack 스레드에서는 계획과 실시간 진행 상황, 그리고 최종 배포 전 승인 과정을 확인할 수 있으며, 팀 내 누구나 작업 중에도 에이전트를 조정할 수 있습니다.

포크할 수 있습니다. 오픈소스 리포지토리에는 전체 허니스가 포함되어 있으며, Managed Deep Agents는 이를 귀사의 Slack 팀에 배포합니다.

위의 프로모션은 Slack에서 단 하나의 프롬프트만으로 동영상, 소셜 그래픽, 재구성된 UI 이미지, 슬라이드덱 등을 제작할 수 있는 디자인 에이전트인 Content Studio가 제작했습니다. 이 에이전트가 생성하는 모든 자산은 코드로 작성됩니다.

Content Studio는 관리형 딥 에이전트를 기반으로 전적으로 사내에서 개발되었습니다. 현재는 당사 내에서 가장 널리 사용되는 GTM 에이전트 중 하나이지만, 처음부터 그렇게 시작된 것은 아닙니다. 초기 피드백은… 그다지 좋지 않았습니다.

그렇다면 우리는 어떻게 이렇게 낮은 품질에서 지금과 같은 수준으로 발전했을까요?

우리는 콘텐츠 스튜디오에게 우리의 취향과 디자인 원칙을 가르치는 데 네 달을 보냈습니다. 주로 전사 앞에서 콘텐츠 스튜디오가 잘못된 일을 하는 모습을 지켜보며 말이죠.

이 글에서는 당사의 GTM 엔지니어링 팀이 디자인 팀과 협력하여 Content Studio를 처음부터 구축한 과정을 소개합니다: 우리에게 있어 좋은 디자인이란 무엇인지, 어떻게 에이전트에게 우리의 취향을 학습시켰는지, 그리고 이를 통해 스틸 이미지부터 런칭 영상까지 어떤 콘텐츠든 제작할 수 있게 해주는 하드웨어와 소프트웨어 구성 요소에 대해 설명합니다.

우리는 디자인 에이전트를 오픈소스로 공개했습니다. 오픈소스 리포지토리를 포크한 뒤, 브랜드 토큰, 글꼴 및 기능을 추가하고, 관리형 딥 에이전트를 통해 팀의 Slack에 배포하세요. 그리고 10월 28일에 열리는 GTM 엔지니어링 라이브 행사에 참여해 주세요. 이번 행사에서는 하네스와 UX의 내부 구조를 자세히 살펴보고, 이 글에 담지 못한 작업들도 선보일 예정입니다.

규모에 맞는 디자인 에이전트 구축

LangChain은 빠르게 발전합니다. 우리는 지속적으로 제품 출시 캠페인, 웨비나, 블로그 및 이벤트를 진행하고 있습니다. 각각의 활동에는 블로그 헤더와 다이어그램부터 프레젠테이션 자료, 동영상, 광고 크리에이티브에 이르기까지 다양한 자산이 필요합니다. 우리 디자인 팀은 반복적인 요청으로 인해 더 전략적이고 혁신적인 업무를 수행할 여유가 부족한 상황이었습니다. 애자일 스타트업으로서, 회사 내 누구라도 높은 품질과 브랜드 정체성을 갖춘 작업을 손쉽게 제작할 수 있는 간편한 방식이 필요했습니다.

이러한 요구를 해결하기 위해 우리는 Slack에 통합된 디자인 에이전트인 Content Studio를 개발했습니다. 팀원은 원하는 내용을 설명하고 관련 콘텐츠나 브리프를 첨부하면, 이 에이전트가 브랜드 이미지에 맞는 완성된 파일을 반환합니다. Content Studio를 구축하기 위해 우리는 세 가지 요소가 필요했습니다:

우리 디자이너들의 전문적인 판단이 에이전트의 기술과 검사에 반영되어, 무엇이 좋은지 잘 알고 있습니다.

디자인 작업의 모든 레이어를 위한 도구가 갖춰진 영상 편집용 컴퓨터를 포함한, 모델을 둘러싼 맞춤형 환경.

올바른 UX를 통해, 한 개의 Slack 스레드에서 몇 시간 동안 진행되는 프로젝트에 대해 팀 전체가 협업할 수 있습니다.

관리형 딥 에이전트는 우리 회사 내에서 Content Studio를 프로덕션 환경으로 전환하는 데 필요한 모든 것을 제공했습니다: 관리형 LangSmith 샌드박스, Slack과의 통합, 관리형 도구, 범위가 제한된 에이전트 메모리 및 에이전트 실행 스케줄링. 이를 통해 소규모 팀은 기반 구축 작업이 아닌 설계 작업, 기술 습득, 도구 활용 및 Slack 경험에 시간을 집중할 수 있습니다.

주요 결과

콘텐츠 스튜디오는 회사 전반에 걸쳐 3,000개가 넘는 자산을 제공했으며, 그 중에는 슬라이드덱도 80개 이상 포함되어 있습니다. 이 중 하나의 슬라이드덱은 당사에서 가장 많은 조회 수를 기록한 유기적 YouTube 영상에도 사용되었습니다.

그의 작업을 담은 게시물은 X에서 약 450만 회의 조회수를 기록했다.

LangChain 계정에서는 시각적 요소가 포함된 게시물이 다른 게시물에 비해 좋아요 수는 약 2배, 북마크 수는 3.7배 더 많았습니다.

현재 요청의 4분의 3이 마케팅 부서 외부에서 발생하며, 사용자의 75%는 매주 다시 방문하는 재방문자입니다.

현재 중앙값 기준 요청 비용은 모델 사용 비용으로 약 50센트이며, 이는 9월 중순의 약 8달러에서 하락한 수치입니다. 관리형 딥 에이전트로 마이그레이션한 이후 우리 자체 코드 크기는 약 80% 축소되었습니다.

AI는 과연 디자인에 능숙한가요?

빌드에 들어가기 전에, 먼저 세기의 논쟁을 짚고 넘어가 보겠습니다: 과연 AI가 좋은 디자인을 만들어낼 수 있을까요?

이 모델은 이미 실행 능력이 뛰어나 HTML과 CSS를 작성하고, 차트 스펙 및 애니메이션 타임라인을 제작할 수 있었습니다. 그러나 이 모델에는 우리만의 맥락이 부족했기 때문에 익숙한 패턴에 의존하게 되었고, 앤트로픽에서는 이를 ‘분포적 수렴’이라고 부릅니다. 그 결과는 겉보기에는 세련되어 보이지만 결국 수백 개의 다른 작품들과 별다를 바 없거나, 아름답게 애니메이션화되었음에도 불구하고 핵심 메시지를 전달하지 못하는 상황으로 이어질 수 있었습니다. 익숙함이 항상 나쁜 것은 아니지만, 우리는 우리 에이전트가 자신의 목적에 부합하는 선택을 내리기를 원했습니다.

스트라이프의 디자인 총괄 책임자인 케이티 딜은 유용한 비교를 제시합니다. 제2차 세계대전 이후 빠르게 구축해야 하는 압박 속에서, 건축가들은 모더니즘의 깔끔한 형태와 담백한 표면을 반복적으로 모방했습니다. 이러한 모방은 외관만 유지할 뿐, 그 이면에 담긴 사유와 개성을 잃어버리고 말았습니다. 그녀는 AI가 소프트웨어에서도 같은 일을 할 수 있다고 경고합니다. 그녀는 이를 ‘좀비 UI’라고 부르며, “당신이 스스로 관점을 가지지 않으면 AI가 대신해 주게 될 것”이라고 말합니다.

우리는 AI가 디자인에 약하다고 생각하지 않습니다. 다만, 사용자가 제공하지 않는 한 AI는 자신의 관점을 갖지 못하며, 우리의 관점을 주는 것은 곧 우리의 취향을 학습시키는 것을 의미합니다.

디자인 에이전트에게 취향을 학습시키기

취향이란 올바른 작업과 훌륭한 작업을 구분하는 판단력입니다. 디자인에서는 두 가지 레이아웃이 모두 적절한 서체, 색상, 여백을 사용하고 있을 수 있지만, 그중 하나만이 핵심 메시지를 효과적으로 전달합니다. 취향은 딜이 말하는 “세밀하게 관찰하는 능력을 매우 높이는 것”에서 비롯됩니다.

그러한 인식 덕분에 우리는 AI의 허술함을 식별하는 법을 배웠으며, 이는 대개 요약문이 의사결정을 에이전트에게 맡길 때 나타납니다.

예를 들어, 아래 왼쪽의 이미지는 당사 브랜드 스킬(색상, 글꼴, 로고 등 포함)을 활용한 현지 코딩 에이전트에 의해 제작되었습니다. 그러나 최종 결과물에는 올바른 로고 레이아웃, 텍스트 정렬, 그리고 당사의 주요 색상과 보조 색상이 무엇인지와 같은 핵심 요소가 누락되어 있었습니다.

동일한 프롬프트는 콘텐츠 스튜디오에서 완벽히 브랜드 정체성에 부합하는 이미지를 생성했습니다. 이는 로컬 에이전트가 브리프에서 다루지 않은 각 결정 사항을 가장 많이 접했던 내용으로 대체했기 때문입니다. 이러한 방법론을 통해 콘텐츠 스튜디오는 동일한 미비점을 우리만의 선택으로 채워 넣었습니다.

우리가 Content Studio에 제공한 가이드라인은 색상 토큰, 글꼴 굵기, 간격, 정렬 등 기본 사항에서 시작되었습니다. 그러나 대부분의 개선은 그 위에 추가된 요소들에서 비롯되었습니다. 우리는 프레임당 하나의 중심 포인트를 두는 원칙, 일반적인 AI 디자인 패턴에 대한 가이드라인, 그리고 각 피드백의 근거와 같은 디자인 원칙을 도입했습니다. 이러한 요소들은 더 나은 기반 모델과 결합되어 Content Studio가 디자이너처럼 더 깊이 생각하고 소통하도록 돕습니다.

처음부터 그렇게 시작된 것은 아니었습니다. 초기 모션 그래픽 중 하나에서, 새가 화면 밖으로 날아가며 뒤에는 불빛의 리본이 잠깐 동안 따라갑니다. 우리는 날카로운 가장자리를 피하도록 요청했지만, 첫 번째 결과물은 거칠고 둥근 가장자리로 어색하게 나왔습니다. 디자이너라면 우리가 무엇을 의미하는지 이해했을 것입니다. 가장자리는 부드럽게 처리되어야 하고, 꼬리는 새의 이동 방향과 반대쪽으로 가늘어지며 희미해져야 합니다.

후속 버전에서는 에이전트가 디자이너의 시각으로 그 디테일을 평가하고 있었다. 새의 꼬리 위치를 파악하기 위해 간단한 스케치를 활용한 뒤, 리본이 제자리에 붙어 있도록 프레임별로 자체 검사를 구축했다. 대부분의 시청자는 그 디테일을 의식적으로 인지하지 못하겠지만, 무언가 어긋나면 이를 직감적으로 느낄 것이다.

측정 가능한 문제들은 해결하기 가장 쉬웠습니다. 이전에는 기본 대문자 사용 문제가 리뷰에서 자주 지적되었지만, 이제는 자동 검사가 모든 사례를 포착합니다. 더 어려운 판단은 보다 주관적이며, 예를 들어 캠페인 아이디어가 충분히 강력한지, 메시지가 명확히 전달되는지, 또는 실행이 청중에게 공감을 불러일으키는지 여부와 관련됩니다. 디자이너가 이러한 판단을 내릴 때, 우리는 그 근거를 스킬로 기록해 두어 에이전트가 향후 초안 작성 시 이를 적용할 수 있도록 합니다.

Content Studio는 디자인 작업을 수행할 수 있는 권한을 변경했습니다. PM, 엔지니어 또는 창업자는 Slack에서 에이전트에게 간략히 설명한 뒤, 브랜드에 맞고 바로 출시할 수 있는 결과물을 받아갈 수 있습니다. 이제 요청의 4분의 3은 마케팅 부서 외부에서 들어오고 있습니다. 디자이너들의 역할은 모든 아티팩트를 직접 제작하기보다는 방향을 설정하고 작업을 검토하는, 크리에이티브 디렉터에 가까워졌습니다.

디자인 판단을 올바르게 내리는 것은 과정의 한 부분에 불과했습니다. 또한 우리는 에이전트가 이를 실행할 수 있도록 필요한 도구와 환경을 제공해야 했습니다.

미디어 하네스 구축

디자이너는 정지 이미지를 위한 포토샵부터 움직임을 위한 비디오 엔진, 프로토타이핑과 협업을 위한 공유 캔버스에 이르기까지 여러 도구를 넘나들며 작업합니다. 또한 브랜드 가이드라인, 디자인 자산, 회사 문서에도 의존합니다.

에이전트 역시 작업할 수 있는 컴퓨터, 설계 프로세스의 각 단계를 위한 도구, 그리고 디자이너가 업무에 가져오는 맥락 등과 유사한 환경이 필요합니다. 하네스는 이러한 요소들을 하나로 통합합니다. Deep Agents는 에이전트 루프, 계획, 파일 관리, 서브에이전트 및 컨텍스트 관리를 포함한 핵심 하네스를 제공합니다. Managed Deep Agents는 이를 프로덕션 환경에서 패키징하고 실행합니다. 우리는 이 하네스를 중심으로 환경을 구축하여, 에이전트가 프로젝트를 유지하고 다양한 도구 간에 작업하며 결과를 검토할 수 있는 컴퓨터를 제공합니다.

harness_v1

우리가 개발한 그 하네스의 첫 번째 버전은 모델을 위한 디자인 작업까지 수행하려 했습니다. 초기 모델들은 우리가 출시하고자 하는 모션 그래픽이나 런칭 영상을 제작하는 데 상당한 도움이 필요했습니다. 아직 스스로 해결하지 못하는 부분을 보완하기 위해, 우리의 직관은 지침과 코드에 더 많은 자체 디자인 판단을 반영하는 것이었습니다.

따라서 우리는 제목, 레이아웃 및 애니메이션을 위한 115개의 재사용 가능한 UI 컴포넌트와 이를 언제 어떻게 사용해야 하는지에 대한 가이드를 포함한 디자인 시스템을 구축했습니다. 이를 통해 모델은 기존 디자인 세트를 기반으로 작업할 수 있게 되어, 처음부터 모든 창의적 결정을 내려야 하는 부담을 줄였습니다.

그 덕분에 브랜드 정체성을 유지할 수 있었지만, 에이전트는 각 프레임마다 별다른 변화 없이 동일한 레이아웃과 애니메이션을 반복적으로 적용했습니다:

우리는 이 작업에서 모델들이 결국 뛰어난 성과를 낼 것임을 알고 있었기 때문에, 그 순간을 대비해 환경을 지속적으로 구축하며 그 과정에서 다양한 기술과 도구를 실험해 왔습니다. 때로는 모델을 돕기 위해 더 많은 참조 자료나 보다 상세한 지침을 추가하기도 했고, 또 다른 경우에는 이를 아예 제거한 뒤 모델이 스스로 어떤 일을 해낼 수 있는지 확인하기도 했습니다.

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

그러던 중 Opus 5.5가 출시되었고, 품질이 즉각적으로 향상되는 것을 확인할 수 있었습니다. 우리는 기존의 기술을 재검토하여 하드코딩된 규칙 대부분을 제거하고, 설계 원칙과 고수준 가이드라인은 그대로 유지했습니다. 그 결과는 더욱 개선되어 다양성이 증가하고 반복이 줄어들었습니다. 마침내 모델은 이전에 미리 구현하려 했던 창의적인 결정들을 스스로 내리기 시작했습니다.

이것이 바로 우리의 ‘쓴 교훈’이었습니다. 모델의 약점을 보완하기 위해 설계된 규칙들은 모델이 발전함에 따라 그 유용성이 점점 떨어집니다. 결국 남는 것은 모델을 둘러싼 환경으로, 여기에는 모델이 사용하는 도구들, 모델이 기반으로 삼는 맥락, 그리고 사람들이 모델의 작업을 어떻게 안내하느냐가 포함됩니다. 우리는 사전에 창의적 결정을 미리 정해두기보다는, 각 새로운 세대의 모델이 제공하는 장점을 최대한 활용할 수 있도록 하네스를 충분히 유연하게 만드는 데 집중했습니다.

디자이너의 컴퓨터

하네스의 실제 작동 모습을 보여주기 위해, 콘텐츠 스튜디오에 비디오 프로젝트 전 과정에서 하네스가 어떻게 작동하는지 담은 영상을 제작해 달라고 요청했습니다. 그 결과물에는 데이비드 애튼버러 스타일의 내레이션으로 픽셀 정글 속 앵무새가 등장하며, 음성은 ElevenLabs를 통해 구현되었습니다. 이제 이 영상을 활용해 하네스의 구성 요소인 컴퓨터, 도구, 그리고 그 작동 배경이라는 여러 층위를 차례로 살펴보겠습니다.

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

에이전트가 생성하는 모든 것은 코드로 구현되며, 슬라이드용 HTML 페이지든 차트용 데이터 사양이든 비디오용 애니메이션 타임라인이든 마찬가지입니다. 이는 처음부터 다시 시작하지 않고도 손쉽게 반복 작업을 가능하게 합니다. 만약 누군가 앵무새를 더 일찍 등장시키도록 요청한다면, 에이전트는 단 하나의 타이밍 값을 수정한 뒤 작품이나 텍스트 내용에는 영향을 주지 않은 채 다시 렌더링할 수 있습니다. 반면 평면 이미지나 생성된 비디오 클립의 경우, 작은 수정조차도 전체 자산을 다시 제작해야 하는 상황으로 이어질 수 있습니다.

브리프, 플랜, 씬 코드, 오디오 및 렌더링은 모두 하나의 프로젝트 폴더에 실시간으로 저장되며, 현장의 모든 서브에이전트가 이 폴더에서 작업합니다.

게다가 우리는 디자이너가 작업의 각 단계에서 손쉽게 사용할 수 있는 도구들을 설치했습니다:

모션은 가장 복잡한 계층입니다. 두 가지 엔진에서 실행됩니다:

편집을 위한 하이퍼프레임: HeyGen의 오픈소스 비디오 프레임워크인 하이퍼프레임은 비디오를 웹페이지로 변환합니다. 클립, 화면 녹화, 자막 및 텍스트는 모두 해당 페이지 위의 요소에 불과하며, GSAP 타임라인이 이를 이동하고 배치합니다. 따라서 누군가 웨비나에 자막을 달거나 제품 데모를 편집해 달라고 요청하면, 에이전트는 마치 웹페이지를 편집하듯이 작업합니다. 이 프레임워크의 CLI는 사실상 에이전트의 편집 도구 세트와 같으며, 구성의 정합성을 검사하고 프레임을 추출해 확인하며, 편집된 영상을 렌더링하는 기능을 제공합니다. 또한 HeyGen의 공식 스킬을 설치하여, 에이전트가 해당 도구를 개발한 이들로부터 형식을 학습하도록 합니다.

애니메이션을 위한 motion-studio: 웹 페이지에서는 빠른 움직임을 흐릿하게 처리하거나 물체를 빛나게 하거나 로고를 3D로 변환하는 작업을 할 수 없으며, 이것이 바로 우리가 원했던 오리지널 애니메이션의 완성도였습니다. 그래서 우리는 자체 캔버스 엔진을 개발했습니다. 에이전트는 각 프레임의 모든 픽셀을 그려내는 코드를 작성하고, 이 엔진은 카메라 셔터가 움직임을 흐릿하게 만드는 방식과 동일하게, 각 프레임에 최대 16개의 순간을 혼합합니다. 앵무새 영화는 바로 이러한 방식으로 제작되었습니다.

두 엔진 모두 각 프레임을 타임스탬프를 기준으로 렌더링하므로, 10초에 해당하는 프레임은 언제 렌더링되든 동일하게 표시됩니다. 이를 통해 에이전트는 전체 영상을 렌더링하지 않고도 개별 순간을 검사할 수 있으며, 동시에 여러 프레임을 병렬로 렌더링할 수도 있습니다. 오디오는 동일한 타임라인에서 처리되므로 내레이션, 음악, 효과음이 영상과 동기화된 상태를 유지합니다.

이 설정을 통해 에이전트는 거의 모든 것을 생성할 수 있습니다. 그러나 추가적인 지침이 없으면, 에이전트는 우리보다는 모델 자체의 설계 선택에 따라 동작하게 됩니다. 다음 과제는 에이전트가 우리의 브랜드 및 디자인 기준 내에서 작동하도록 학습시키는 것이었습니다.

디자이너의 두뇌

우리는 에이전트의 지식을 각각 명확한 목적을 가진 네 가지 독립적인 기능으로 구조화했습니다. 스킬은 특정 작업을 수행하는 방법을 안내하고, 위키는 당사에 대한 맥락과 훌륭한 업무가 어떤 모습인지에 대해 제공합니다. 측정 가능한 모든 사항은 코드로 작성된 결정적 검사인 게이트를 통해 처리됩니다. 또한 별도의 메모리 계층은 시간이 지나면서 사람들이 에이전트에게 전달하는 내용을 저장합니다.

에이전트가 요청을 받으면 가장 먼저 하는 일은 그 요청이 어떤 작업인지 파악하는 것입니다. 이는 우리 미디어 제작 스킬에서 담당합니다. 우리는 이를 라우터 스킬이라고 부르는데, 대부분의 내용이 하나의 테이블로 구성되어 있기 때문입니다. 각 행은 특정 유형의 요청(캠페인, 리스타일, 썸네일, 게시물, 유튜브 패키지, 론칭 영상, 단편 애니메이션 등)을 처리하는 경로와 전문 스킬로 매핑합니다. 또한 라우터는 해당 작업에 공유 비주얼 캔버스가 필요한지 여부를 판단하며, 작은 수정 사항은 전체 프로세스에서 제외합니다.

위와 같은 영화의 경우, 라우터는 대규모 모션 프로덕션을 감독하는 데 적합한 ‘런칭 필름’ 스킬을 선택합니다. 저희가 보유한 48개의 스킬 중 총 약 1,000개의 파일은 주제가 아닌 작업에 맞춰 설계되어 있으므로, 각 스킬의 설명은 사용 시기와 함께 라우팅 규칙처럼 기술됩니다.

스킬은 서로를 반복하는 대신 구성됩니다. launch-film은 연출을 담당하고 motion-studio는 영상과 사운드를 제작하므로, 애니메이션 제작 과정은 한 번만 작성하면 됩니다. 또한 launch-film은 시작할 하위 에이전트들을 위한 역할 설명서와, 우리가 코드로 촬영 장면 하나하나까지 재구성한 실제 88초짜리 런칭 필름의 사례 연구도 포함합니다. 이 사례 연구에서 에이전트는 하위 에이전트들 간에 영화를 분할하는 방법을 학습했습니다. 에이전트는 장면 전환 시점을 명확히 설정하고, 한 하위 에이전트가 연속적인 카메라 움직임을 유지하며, 모두가 병렬로 작업하기 전에 공유된 코드를 고정합니다.

도구에 대해서도 기술과 마찬가지로 설명이 중요합니다. 컨텍스트 사용을 최소화하기 위해, 우리는 MCP 도구들을 내장형 검색 기능 뒤에 배치했습니다. 에이전트는 처음에는 자체 도구만 사용하며, 필요에 따라 키워드 검색을 통해 도구 이름과 설명 전반에서 추가 도구 스키마를 로드합니다.

스킬은 작업 수행 방법을 설명하는 반면, 위키는 이를 잘 수행하는 데 필요한 맥락과 참고 자료를 제공합니다. 여기에는 브랜드 토큰, 그래픽 언어 및 목소리부터 플랫폼, 캠페인, 제품 정보에 이르기까지 모든 내용이 포함됩니다. 전용 모션 위키에서는 연출, 크래프트, 사운드, 리뷰 등에 관한 내용과 함께 70편의 참고 영화에 대한 분석도 다룹니다.

이 정보를 여러 스킬에 중복해서 저장하는 대신, 우리는 위키와 직접 연결합니다. 이렇게 하면 공유된 지식을 한 곳에 모아두고 업데이트를 더 쉽게 할 수 있습니다. 글꼴 규칙과 같은 내용이 변경될 때에는 이를 한 번만 수정하면 되며, 모든 스킬에서 최신 버전을 참조할 수 있습니다.

우리가 어떻게 일하는지 안다고 해서 모션 디자인이 반드시 저렴해지는 것은 아닙니다. 잘못된 크리에이티브 결정 하나로도 여전히 수시간의 렌더링 비용이 발생할 수 있습니다.

스펙 기반 설계

모션은 렌더링 시간과 토큰 모두에서 잘못될 경우 비용이 특히 많이 듭니다. 스토리보드 프레임 하나를 렌더링하는 데는 약 50밀리초가 걸리는 반면, 완성된 영상 1초를 만드는 데는 8초에서 40초가 소요됩니다. 하위 에이전트들이 각각의 장면을 작성하고 렌더링하며 검토하기 때문에 이러한 비용은 순식간에 누적됩니다. 따라서 에이전트는 먼저 스토리보드에서 아이디어를 발전시켜 다양한 방향을 저렴하게 탐색한 뒤, 어느 한 방향이 최종적으로 승인되면 본격적인 제작으로 넘어갑니다.

그 탐색을 지원하기 위해, 우리는 에이전트에게 영감을 얻을 수 있는 참고 영화 라이브러리를 제공했으며, 이는 마치 디자이너가 무드보드를 기반으로 작업하는 것과 유사합니다. 적합한 비주얼을 찾지 못할 경우, 이미지 모델을 활용해 새로운 참조 자료를 생성하며, 가장 유망한 옵션을 정교화하기에 앞서 간단한 초안부터 시작합니다. 이러한 이미지는 시각적 방향성을 설정하는 데 도움을 주는 반면, 스토리보드와 최종 영상은 여전히 실제 타이포그래피와 브랜드 자산을 사용하여 코드로 제작됩니다.

일단 방향을 정하면, 승인된 스토리보드는 나머지 영화 제작의 기준이 됩니다. 이후 프로젝트는 세 단계를 거칩니다:

스토리보드는 시각적 아이디어, 카피 및 쇼트를 협의하기 위한 것입니다.

스틸 이미지로는 보여줄 수 없는 템포를 확인하기 위해 오디오에 맞춰 시간을 조정한 초안 영상입니다.

프로덕션에서는 하위 에이전트들이 승인된 샷을 빌드하고 검사하며 렌더링합니다.

우리는 먼저 이 순서를 스킬의 지침에 명시했으며, 에이전트는 시간을 절약하기 위해 때로 검토 단계를 생략하곤 했습니다. 이제 파이프라인은 코드로 이를 강제 적용하므로, 모든 액션이 검토를 통과할 때까지 어셈블리가 대기하게 되며, 동시에 지침은 여전히 크리에이티브 호출을 안내합니다. 항상 유지되어야 하는 이 순서는 코드에 구현되고, 판단은 프롬프트에 남아 있습니다.

포인트, 프롬프트하지 마세요

그러한 방향 중에서 선택하는 것은 팀의 결정입니다. Slack은 업무를 요청하고 받는 데에는 잘 작동하지만, 스레드는 선형적인 텍스트이고 스토리보드는 공간적 구조이기 때문에 피드백이 대상을 가리키기보다는 그 위치를 설명하게 되며, 한 단어만 수정하는 작은 변경사항이라도 새로운 프롬프트로 에이전트를 통해 다시 처리해야 합니다.

Paper은 이를 우리를 위해 해결해 주었습니다. 이는 에이전트를 염두에 두고 설계된 디자인 캔버스로, 에이전트가 파일을 직접 제어할 수 있도록 하는 MCP 서버를 갖추고 있습니다. 사용자들은 동일한 파일에서 작업하며, 지침을 나란히 비교하고 특정 프레임에 댓글을 남기거나 직접 편집할 수 있습니다. 캔버스가 공유되기 때문에, 에이전트는 해당 파일로 다시 돌아와 이러한 댓글과 편집 내용을 활용하여 다음 반복 작업을 안내할 수 있습니다.

문제는 Paper의 에이전트 도구가 자체 데스크톱 앱 내에서만 실행되는 반면, 우리 에이전트는 클라우드 샌드박스에서 작동한다는 점이었습니다. 이 격차를 해소하기 위해 우리는 가상 디스플레이와 인증된 브리지를 활용해, 항상 켜져 있는 Linux 워커에서 Paper Desktop을 헤드리스로 실행합니다. 하나의 설정으로 팀 전체를 지원합니다.

승인을 받은 후에도 스토리보드를 완성된 영화로 만드는 데에는 수시간이 걸릴 수 있습니다. 그 시점이 되면 작업은 여러 개의 요소가 병렬로 제작되어야 하며, 이들이 최종적으로 하나로 결합되어야 하는 작은 프로젝트와도 다름없습니다. 이 모든 과정을 조율하는 일은 단일 에이전트 턴으로는 감당하기 어려운 수준입니다.

참모장으로서의 에이전트

앞서 언급한 앵무새 영화를 생각해 보세요. Slack에서 제작 중간쯤에 한 사람이 레퍼런스를 공유하고, 다른 사람은 다른 오프닝을 제안하며, 세 번째 사람은 네 번째 프레임에 대한 피드백을 남깁니다. 이 모든 과정이 에이전트가 아직 작업을 진행하고 있는 와중에도 이루어집니다. 마치 메모를 하는 사람이 동시에 영화 제작까지 책임지는 브레인스토밍과도 같습니다. 이 상황에서는 동기식 서브에이전트가 잘 작동하지 않습니다. 주 에이전트가 그들이 끝나기를 기다려야 하므로, 그 사이에 사람들이 에이전트와 상호작용할 방법이 없기 때문입니다.

이를 해결하기 위해 우리는 하위 에이전트들을 비동기식으로 구현하고, 메인 에이전트의 역할을 실행자에서 참모장으로 전환했습니다. 이를 통해 복잡한 프로젝트를 더 작고 독립적인 작업들로 분리하고, 각 작업을 하위 에이전트들에게 할당한 뒤 병렬로 처리합니다. 동시에 상황이 변화함에 따라 팀원들에게 지속적으로 정보를 제공하여, 사람들이 계속해서 피드백을 제공하고 프로젝트를 방향성 있게 이끌 수 있도록 합니다.

각 작업에 대해, 메인 에이전트는 자신의 역할, 관련 맥락, 파일 소유권 및 작업 검증 방법을 명확히 담은 간략한 설명과 함께 서브에이전트 프로필을 생성합니다. 또한 작업의 복잡성에 따라 모델과 노력 수준을 선택합니다.

또한 메인 에이전트가 작업을 조율할 수 있도록 소규모 도구 세트를 추가했습니다:

start_task는 백그라운드에서 하위 에이전트에게 부품을 전달합니다

check_tasks는 현재 실행 중인 작업을 표시하고 완료된 보고서를 읽습니다

cancel_task 및 resume_task는 더 이상 요구사항에 맞지 않는 작업을 중단하거나, 중단된 지점에서 다시 이어받습니다.

report_progress를 사용하면 하위 에이전트가 작업 중간에 업데이트를 보낼 수 있습니다.

schedule_wakeup은 메인 에이전트에게 다른 실행을 트리거하고 작업을 계속 진행할 수 있는 타이머를 제공합니다.

내부적으로 각 서브에이전트는 백그라운드 작업으로 실행되는 일반적인 Deep Agents 작업 도구입니다. 해당 작업이 완료되면, 우리의 코드는 결과를 포함한 메인 에이전트의 새로운 실행을 큐에 넣습니다. 또한 사용자는 메인 에이전트가 실행 중일 때에도 작업을 조정할 수 있는데, 작업 중에 수신된 메시지는 다음 모델 호출 전에 삽입되기 때문입니다. 서브에이전트들은 프로젝트 폴더를 통해 상호 협력하며, 각각 자신이 소유한 파일만 작성하고 진행 상태를 디스크에 저장합니다.

작업이 백그라운드에서 실행되는 동안, 스레드는 현재 진행 상황을 표시해야 합니다. 메인 에이전트는 계획과 예상 완료 시간, 실행 중인 하위 에이전트와 렌더링 진행 상태 및 소요 비용을 반영한 실시간 상태 라인, 각 편집에 대한 확인 기록, 그리고 모든 내용이 공개되기 전의 승인 카드를 통해 이를 최신 상태로 유지합니다.

이 접근 방식을 가장 명확히 검증한 사례 중 하나는 52페이지 분량의 프레젠테이션을 하룻밤 만에 리스킨하는 작업에서 나왔습니다. 에이전트는 먼저 샘플 슬라이드 세 장을 생성하고 자신의 작업을 검토한 뒤, 나머지 슬라이드를 번호가 매겨진 일괄 처리로 진행해 승인을 받았습니다. 또한 그 과정에서 두 개의 새로운 슬라이드도 추가했습니다. 하룻밤 동안 메인 에이전트는 약 한 시간 동안 작동했고, 서브에이전트들은 총 여섯 시간 이상 작업을 수행했는데, 이 모든 과정에서 대화 흐름을 방해하지 않았습니다.

자기 개선형 하네스

몇 달 동안 팀과 함께 일해 온 디자이너는 팀의 선호 사항을 파악하고, 같은 피드백을 두 번이나 들을 필요가 없습니다. 메모리가 없다면 에이전트는 새로운 스레드가 생길 때마다 처음부터 다시 시작해야 할 것입니다. 이를 방지하기 위해 우리는 두 가지 학습 루프를 구축했습니다. 빠른 루프는 사용자가 피드백을 제공하는 즉시 이를 수집하고, 느린 루프는 백그라운드에서 완료된 프로젝트들을 기반으로 학습합니다.

빠른 루프: 누군가 규칙이나 선호 사항을 공유하면, 에이전트는 해당 내용을 같은 턴에 저장합니다. 관리형 딥 에이전트는 메모리를 두 개의 계층으로 구성된 일반 파일 형태로 저장하며, 하나는 팀 전체에서 공유되고 다른 하나는 각 개인에게 고유한 것입니다.

개인적인 선호는 스레드 간에 이어지지만, 공유된 표준이 우선하며 회사 채널용으로 생성된 모든 내용은 회사의 목소리를 따릅니다. 각 레이어에는 모델 호출마다 로드되는 AGENTS.md 파일이 있습니다. 초기 버전에서 파일 크기가 50만 토큰까지 커졌던 이후, 현재는 이러한 파일을 200줄로 제한하고 있습니다.

느린 루프: 각 작업이 완료된 후, 우리의 learn_from_job 도구는 경량의 서브에이전트를 시작하여 최대 다섯 가지 근거 기반 교훈을 수집하고 이를 해당 기술과 연관시킵니다. 이후의 작업에서는 이러한 교훈을 읽고 평가하며, 일주일에 한 번 배경 에이전트가 유용하다고 판단된 교훈들을 기술과 위키에 반영합니다.

다음은 무엇인가요

그 초기 리뷰들을 기억하시나요? 가장 큰 개선은, 디자이너들의 판단을 에이전트가 학습할 수 있는 공유 환경에 담아내는 데서 비롯되었으며, 이를 리뷰 스레드 곳곳에 흩어놓는 방식에서 벗어났기 때문입니다. 그 과정에서 우리는 디자인 작업을 더 많은 사람들에게 접근 가능하게 만들었습니다.

다음으로, 에이전트가 캠페인의 전 주기를 관리하도록 하고자 하며, 그 중 일부는 이미 작동하고 있습니다. 에이전트는 승인된 담당자가 최종 확인을 완료하면 버퍼를 통해 회사의 소셜 게시물을 자동으로 발행하고, 직원들이 자신의 계정에서 공유할 수 있도록 게시물 초안을 작성하며, 인용할 만한 게시물을 추천하는 일일 검토를 포함한 예약된 루틴을 실행합니다.

우리의 목표는 이를 한 단계 더 발전시켜, 승인된 하나의 크리에이티브 방향이 하나의 흐름에서 전체 캠페인을 이끌어갈 수 있도록 하는 것입니다. 에이전트는 브리프를 작성하고 각 채널에 맞는 자산을 제작하며 게시물을 스케줄링하고, 팀이 이를 확대·확산하도록 지원하며, 성과 데이터를 바탕으로 다음 캠페인을 기획합니다. 모든 콘텐츠는 대중에 공개되기 전에 여전히 사람들의 검토와 승인을 거칩니다.

자신만의 디자인 에이전트를 구축해 보세요: 오픈소스 저장소에는 이 게시물에서 소개된 하네스가 포함되어 있습니다—샌드박스 컴퓨터, 스킬, 위키 및 메모리, 비동기 서브에이전트, 그리고 Slack UX가 모두 포함되어 있습니다. 이를 포크한 뒤, 브랜드 토큰, 폰트, 스킬을 추가하고, 관리형 딥 에이전트와 함께 팀의 Slack에 배포해 보세요. 그런 다음 10월 28일에 열리는 GTM 엔지니어링 라이브 행사에 참여해 주세요. 우리는 하네스와 UX의 내부 구조를 자세히 살펴보고, 이번 게시물에 담지 못했던 작업들을 선보일 예정입니다.

관련 콘텐츠

“기업 하네스”를 구축하는 다섯 가지 구성 요소

컨텍스트 엔지니어링은 검색에서 시작됩니다

컨텍스트 엔지니어링: 딥 에이전트는 어떻게 기억하는가

귀하의 에이전트가 실제로 무엇을 하고 있는지 확인하세요

저희의 에이전트 엔지니어링 플랫폼인 LangSmith는 개발자가 모든 에이전트의 결정을 디버깅하고, 변경 사항을 평가하며, 한 번의 클릭으로 배포할 수 있도록 지원합니다.