에이전시 AI 스택은 에이전시가 AI 일을 돌리는 다섯 층이에요: 고객 메모리, 오케스트레이션, 제작, 리뷰, 측정이죠. 구독으로 가득한 폴더가 아니에요. 스택은 에이전시를 덜 책임 있게 만들지 않고 더 빠르게 하려고 존재하고, 사는 대신 세울 가치가 있는 유일한 층은 에이전시가 고객에 대해 아는 것을 담은 층이에요.
저는 에이전시가 AI 스토리로 사들여 결국 피치엔 인상적이고 딜리버리엔 혼란을 주는 도구 목록으로 끝나는 걸 봤어요. 스택 질문은 사실 기술 옷을 입은 운영 모델 질문이라, 지출 전에 둘을 분리할 가치가 있죠.
도구 수가 틀린 틀인 이유
기본 본능은 도구를 세는 거예요. 열두 플랫폼, 다섯 모델, 디자인 도구, 스크래핑 도구, 리포팅 도구요. 도구 수는 보여주기 쉽고 대개 무의미해요, 같은 구독의 두 에이전시가 완전히 다른 결과를 낼 수 있으니까요. 하나는 하나의 고객 진실로 워크플로에 연결했고, 다른 하나는 열두 탭에 메모리가 없죠.
중요한 스택은 층 사이에 무엇이 흐르는지로 정의되지, 각 층에 무엇이 앉는지가 아니에요. 브리프가 한 번 들어와 플랜, 액티베이션, 리포트, 그리고 다음 브리프를 먹이는 학습을 만들면 스택이 있어요. 각 도구가 0에서 시작하면 더미가 있고요. 그 구분이 전부이고, 구매 스프레드시트에선 보이지 않아요.
다섯 층
제가 본 모든 작동하는 에이전시 스택은 같은 다섯 층으로 귀결돼요. 제품이 아니라 해야 할 일이고, 규모에 따라 build, buy, process의 다른 혼합으로 각각 채울 수 있죠.
| 층 | 일 | Buy 또는 build |
|---|---|---|
| 고객 메모리 | 브리프, 과거 작업, 브랜드 규칙, 결과 보관 | Build — 이게 해자 |
| 오케스트레이션 | 일 라우팅, 맥락 보관, 루프 실행 | Buy, 그다음 설정 |
| 제작 | 카피, 크리에이티브, 플랜, 코드 초안 | Buy — 가장 빨리 움직이는 층 |
| 리뷰 | 오류 잡기, 브랜드 집행, 사실 확인 | 루브릭 build, 도구 buy |
| 측정 | 결과물을 결과에 정직하게 연결 | 데이터는 buy, 틀은 build |
순서가 중요해요. 메모리는 모든 것 아래 앉아요, 다른 모든 층이 에이전시가 이미 아는 걸 읽을 수 있을 때 더 유용하니까요. 리뷰는 제작 위에 앉죠, 리뷰 없는 제작이 에이전시가 자신감 있는 실수를 속도로 내보내는 길이니까요.
층 하나: 고객 메모리
이게 제가 먼저 세우고 가장 강하게 지킬 층이에요. 에이전시가 각 고객의 축적된 이해를 저장하는 곳이죠: 브리프 이력, 브랜드 규칙, 이기고 진 크리에이티브, 측정 읽기, 결정과 그 이유요. 뭐도 특별하지 않아요. 전부 복제하기 어려워요, 한 일에 특정하니까요.
일반 모델은 카테고리를 알아요. 당신 스택은 당신 고객을 알아야 하죠. 그 차이가 에이전시가 한나절에 할 수 있는 것을 고객의 사내 도구가 못 하는 이유이고, 유지하는 매달 복리로 쌓여요. 이 층이 왜 오래가는지의 긴 버전을 원하면 고객-메모리 데이터 해자 만들기에 썼어요.
층 둘: 오케스트레이션
오케스트레이션은 맥락을 나르며 일을 스택으로 움직이는 배관이에요. 브리프가 왔을 때 뭐가 돌고, 어떤 순서로, 어떤 메모리를 붙이고, 뭔가 보내지기 전에 사람이 어디를 보는지 같은 질문에 답하죠. 작은 에이전시에선 흔히 한 사람과 체크리스트고, 그건 정당한 답이에요. 큰 곳에선 워크플로 도구나 얇은 사내 앱이죠.
함정은 워크플로를 알기 전에 오케스트레이션 플랫폼을 사는 거예요. 소프트웨어가 설계하지 않은 프로세스를 흐뭇하게 인코딩해서, 에이전시가 기존 엉망을 자동화하게 되죠. 루프를 먼저 종이에 설계하고, 한 달 손으로 돌리고, 그다음에 그걸 나를 것을 찾으세요.
층 셋: 제작
제작은 상품화되는 층이고, 사는 게 거의 항상 세우는 것을 이기는 층이에요. 카피를 초안하고, 크리에이티브를 만들고, 플랜을 조립하고, 코드를 쓰는 모델과 도구가 어떤 에이전시의 사내 follow-up보다 빨리 나아져요. 여기서 당신의 일은 엔진을 세우는 게 아니라; 몇 개의 엔진을 골라 깊이 배우는 것이죠.
매주 새 생성기를 더하려는 욕구에 저항하세요. 제작에서 깊이가 넓이를 이겨요, prompt를 조정해 쓰고 실패 모드를 아는 도구와 casual하게 쓴 도구의 품질 차이가 도구 간 차이보다 크니까요. 두세 개를 고르고, 잘하고 못하는 걸 쓰고, 분기마다 그 목록을 수정하세요.
경계할 함정은 빨라 보이고 조용히 팀의 판단을 약화하는 도구예요 — 빠르지만 판단을 약화하는 도구 함정에 쓴 실패죠. 그런 도구는 구독보다 비싸요, 초안 시간 절약이 아무도 못 잡은 오류로 돌아오니까요.
층 넷: 리뷰와 QA
리뷰는 에이전시가 자신을 구별하는 곳이에요, 고객이 돈 내는 층이고 대부분의 스택이 소홀히 하는 층이니까요. AI가 제작을 싸게 하고 리뷰를 비싸게 만들어서, 확장하는 순간 병목이 리뷰 단계로 옮겨가죠. 리뷰 층 없는 스택은 확장하지 못해요; 뭔가 창피한 게 나가기 전까지 리뷰 부채를 쌓아요.
도구를 사도 루브릭은 세우세요. 무엇이 브랜드다운지, 무엇이 출처가 필요한 사실 주장인지, 뭔가 고객에 가까이 가기 전 뭐가 하드 스톱인지요. 루브릭은 에이전시의 판단을 명시화한 것이고, 주니어 운영자가 시니어를 어깨에 태우지 않고 시니어 품질 점검을 하게 하는 것이죠.
층 다섯: 측정
측정은 루프를 닫고, 그 일은 볼륨이 아니라 정직함이에요. 스택이 한 일이 무엇을 바꾸려 했고, 실제로 뭐가 움직였고, 그걸 일이 일으켰다고 얼마나 확신하는지 말할 수 있어야 하죠. 산출을 세는 것보다 어렵고, 요금을 방어할 수 있는 에이전시와 활동만 보여주는 곳을 가르는 것이에요.
데이터 배관은 사세요, 어트리뷰션 데이터가 당신이 통제하지 않는 플랫폼에 살니까요. 틀은 세우세요, 틀이 판단이 사는 곳이니까요. 얇고 규율 있는 틀 — 사업 결과 하나, 몇 개의 선행 신호, 무엇을 어트리뷰션할 수 있고 없는지의 솔직한 노트 — 이 아무도 안 읽는 스무 지표 대시보드를 이겨요.
세우는 순서
메모리와 손으로 돌리는 루프로 시작하세요. 고객 지식을 한 곳에 넣고, 일이 거치는 단계를 쓰고, 단계가 안 바뀔 때까지 수동으로 돌리세요. 그런 다음 가장 아픈 단계에 제작 도구를 더하세요. 제작이 리뷰 압력을 만들 만큼 빨라지면 리뷰를 더하고요. 측정할 게 생기면 측정을 더하세요.
그 순서는 첫 달 느려 보이고 일 년의 재작업을 아껴요, 아래 층이 안정될 때 각 층이 더해지니까요. 어려움을 겪는 에이전시는 보통 제작을 먼저 사고 나중에 메모리와 리뷰를 옆에 붙이려 한 곳이에요. 스택은 에이전시가 아는 것에서 위로 자라야 해요.
해본 스택 리뷰
일 년에 한 번, 실제 일 하나를 스택으로 끝에서 끝까지 통과시켜 감사하세요. 브리프가 들어오는 곳에서 시작해 오케스트레이션과 제작을 거쳐, 사람이 리뷰하는 곳을 이름 짓고, 측정 읽기에서 끝내세요. 각 인계에서 두 가지를 물으세요: 맥락이 넘어왔나, 새 입사자가 묻지 않고 따라올 수 있나? 맥락이 두 층 사이에서 사라지면 그 층을 먼저 고치세요, 단계 사이 메모리 누수가 다섯 도구를 다섯 무관한 과업으로 바꾸니까요. 결과를 만든 브리프로 아무도 trace 못 하면 측정 층이 장식이죠. 리뷰는 한나절 걸리고 구독 감사보다 더 많이 알려줘요, 목록이 아니라 연결을 시험하니까요.
FAQ
자체 모델이 필요한가요?
거의 없어요. 에이전시 스택의 가치는 메모리, 오케스트레이션, 판단에 있지 학습에 없어요. 파인튜닝은 크고 안정된 독점 데이터셋과 일반 모델이 못 다루는 과업이 있을 때만 값져요. 대부분의 에이전시는 둘 다 없으니 노력을 메모리 층에 쓰세요.
얼마나 세우고 얼마나 살까요?
빨리 나아지고 다른 회사도 쓰는 층은 사세요, 그건 시장을 앞지를 수 없으니까요. 당신의 특정 지식을 담고 특정 판단을 인코딩하는 층은 세우세요, 경쟁사가 살 수 없는 유일한 것이니까요. 메모리와 리뷰는 build 층이고, 제작과 데이터는 buy 층이에요.
가장 큰 스택 실수는?
그것들을 연결하는 워크플로를 설계하기 전에 도구를 더하는 것. 진전처럼 보이고, 갱신 목록을 만들고, 에이전시를 같은 병목 더 많은 구독과 함께 남기죠. 스택은 운영 모델을 따라야 하고, 결코 반대가 아니에요.
이 모든 것에서 고객 데이터를 어떻게 안전하게 유지하나요?
메모리 층을 경계로 다루세요. 고객 데이터는 당신 통제 저장소에 살고, 도구는 과업이 필요한 만큼만 읽고, 무엇이 들어가고 나갔는지 기록을 유지하세요. 거버넌스 대화이자 기술 대화이고, 스택 확장 전에 정해져야 해요.
짧은 정리
에이전시 AI 스택은 다섯 층이에요 — 고객 메모리, 오케스트레이션, 제작, 리뷰, 측정 — 을 운영 모델 둘레에 조립한 것이죠. 상품화되는 층은 사고, 아는 것을 담은 하나는 세우고, 스택을 메모리에서 위로 자라게 하세요. 실행 가이드가 이 스택이 섬기는 워크플로를 다루고, 에이전시 트랙이 에이전시 운영 모델로 돌려요.
에이전시가 스택을 반대로 — 도구 먼저 — 세웠다면, 무엇이 재설계를 강제했는지 듣고 싶어요.
감사합니다, Chandler
이 글은 한국어로 제공되지만, 코스 자료(영상, 템플릿, 컴패니언 가이드)는 영어, 일본어, 중국어(간체), 한국어로 제공돼요. 이 사이트는 13개 언어로 제공돼요.