인간 에이전트 팀(Human-Agent Teams) 소개: Slack의 최고제품책임자에게 듣는 실전 운영법
Anthropic이 2026년 8월 19일 공개한 이 글은 사람과 AI 에이전트가 한 팀으로 일하는 조직을 실제로 어떻게 운영하는지를 다룬 시리즈의 두 번째 편으로, Slack의 최고제품책임자(Chief Product Officer, CPO) Jaime DeLanghe와 나눈 대화를 여섯 가지 실천 원칙으로 정리한 것입니다. 첫 편이 Anthropic 내부에서 얻은 교훈이었다면, 이번 편은 AI가 등장하기 훨씬 전부터 "업무용 대화를 조직의 지식으로 바꾸겠다" 는 목표를 붙들고 살아온 회사의 이야기라는 점에서 결이 다릅니다.
배경을 잠깐 짚고 갈 필요가 있습니다. 지금까지 AI와 일하는 방식은 대부분 싱글 플레이어(Single Player) 경험이었습니다. 한 사람이 채팅 창 하나를 열고 한 어시스턴트와 일대일로 작업을 끝내는 구조입니다. 이 전제를 바꾼 것이 Anthropic의 Claude Tag로, Slack 채널에 Claude를 팀원처럼 합류시켜 채널의 누구나 @Claude를 멘션해 작업을 위임하고 그 결과를 함께 보는 방식입니다. 이 제품과 시리즈 1편의 네 가지 교훈은 커뮤니티에 이미 정리해 둔 글이 있으니 함께 읽으시면 맥락이 더 선명해집니다.
Claude Tag와 멀티플레이어 에이전트 개념에 관해서는 다음 글을 참고해주세요:
Jaime DeLanghe는 2017년 검색과 머신러닝을 담당하며 Slack에 합류했고, 그때부터 지금까지 같은 목표를 좇아 왔습니다. 업무 현장의 대화를 조직의 자산, 즉 제도적 지식(Institutional Knowledge) 으로 바꾸는 일입니다. 그는 이 목표를 이루려면 사람들이 공개된 채널에서 일해야 한다고, 즉 대화와 결정과 진행 중인 작업이 회사의 누구나 읽고 검색할 수 있는 곳에 남아야 한다고 오랫동안 주장해 왔습니다. 최근 발표한 에세이 The Work is the Conversation에서는 같은 논리를 에이전트에게로 확장합니다. 작업 주변에서 오가는 대화야말로 에이전트가 쓸모 있어지기 위해 필요한 맥락이며, 수십 년 묵은 그 목표를 마침내 이룰 수단이라는 것입니다.
이 글에서는 원문이 제시한 여섯 가지 원칙을 순서대로 살펴보되, 각 원칙이 왜 필요했는지, Slack 내부에서 어떤 형태로 굴러가고 있는지, 그리고 이를 뒷받침하는 Agent Skills나 Model Context Protocol(MCP) 같은 기술적 토대가 무엇인지까지 함께 정리했습니다.
대화는 저절로 지식이 되지 않았다: 10년간의 실패와 달라진 조건
Slack 같은 협업 도구가 오랫동안 팔아 온 약속이 있습니다. 사람들이 함께 일하며 남기는 대화의 부산물이 시간이 지나면 조직의 지식으로 쌓인다는 약속입니다. Jaime DeLanghe의 진단은 냉정합니다. 그 약속은 실현된 적이 없습니다.
"Slack 초창기에 나온 연구 논문을 정말 많이 갖고 있는데, 그 논문들이 보여준 결론은 '아니오'였습니다. 대화는 지식이 되지 않습니다. 그렇게 되기를 바라지만, 실제로는 그냥 거기 널려 있는 잡다한 것들일 뿐이고 사람들은 여전히 같은 말을 반복해야 합니다."
"I have so many research papers from the early days at Slack that showed that, actually, no, conversation doesn't turn into knowledge. You wish it did, but really it's just a lot of stuff that just hangs out there and people still have to repeat themselves."
원인은 분명합니다. 그 방대한 부산물을 읽고 정리하는 일이 사람의 처리 능력 밖이었기 때문입니다. 채널 하나에 하루치 대화만 쌓여도 사람이 전부 따라 읽기 어려운데, 수백 개 채널에 몇 년치가 쌓인 조직에서 "그때 그 결정이 왜 그렇게 났더라" 를 되짚는 일은 사실상 불가능했습니다. 그래서 사람들은 검색을 포기하고 다시 물어봤고, 같은 논의가 반복됐습니다.
달라진 것은 이 작업이 이제 에이전트의 몫이 되었다는 점입니다. 에이전트는 사람보다 훨씬 빠른 속도로 방대한 텍스트를 읽을 수 있고, 시리즈 1편이 지적했듯 사람이라면 놓쳤을 관련 작업을 일상적으로 찾아냅니다. 여기서 중요한 발상의 전환이 하나 나옵니다. 대화 기록을 대화 기록으로 다루지 말고, 검색 가능한 지식 베이스(Knowledge Base)로 다루라는 것입니다.
원문은 이를 위한 세 가지 실천을 제시합니다.
공개 채널을 기본값으로(Default to public channels): 에이전트는 자신이 볼 수 있는 것에서만 배웁니다. 다이렉트 메시지(DM)나 비공개 스레드에서 내려진 결정은 에이전트에게 보이지 않고, 조직에게도 그대로 사라집니다.
기록이 아니라 이유를 물어라(Ask agents for the reasoning, not just the record): 무엇이 결정되었는지를 검색하는 대신, 에이전트에게 왜 그렇게 결정되었는지, 그리고 그 이후 맥락이 어떻게 바뀌었는지를 재구성해 달라고 요청하는 것입니다. 검색 엔진에게는 할 수 없던 질문이고, 에이전트를 검색 인터페이스가 아닌 분석가로 쓰는 방식입니다.
접점을 넓혀라(Widen the surface area): Slack과 Claude 같은 도구들이 회의, 이메일, 캘린더, 문서 저장소를 하나로 엮고 있습니다. 연결한 맥락이 많을수록 팀이 같은 말을 반복하는 일이 줄어듭니다.
세 번째 항목은 특히 MCP와 직결됩니다. Slack은 실시간 검색(Real-Time Search, RTS) API와 MCP 서버를 공개했는데, 이는 외부 에이전트가 Slack의 대화 맥락에 표준 프로토콜로 접근할 수 있게 된 첫 단추였습니다. Slack의 발표에 따르면 Anthropic, Google, OpenAI, Perplexity를 포함한 50개 이상의 파트너가 이 위에서 맥락 인지형 에이전트를 만들고 있으며, 제한 공개 이후 RTS 쿼리와 MCP 도구 호출이 모두 25배 늘었습니다. Jaime DeLanghe는 에세이에서 이 발표 직후 생태계가 빠르게 움직이는 것을 지켜봤다고 적었습니다.
여기서 짚어 둘 구조적인 차이가 하나 있습니다. RTS API는 필요한 정보만 질의해 가져오는 방식이라 고객 데이터를 외부 서버에 복사해 두지 않습니다. 대화 기록을 통째로 색인해 어딘가에 쌓아 두는 대신, 질문이 들어올 때마다 사용자 권한을 그대로 반영해 실시간으로 조회하는 구조입니다. 대화를 지식 베이스처럼 다루라는 원칙이 데이터 사본을 만들라는 뜻이 아니라는 점에서, 보안 검토를 통과해야 하는 조직에게는 중요한 설계 차이입니다.
더 알아보기: 대화를 맥락으로 다루기
The Work is the Conversation: Jaime DeLanghe가 직접 쓴 에세이로, 아래에서 인용하는 얇은 일과 두꺼운 일 구분이 여기서 나옵니다.
https://jaimedelanghe.medium.com/the-work-is-the-conversation-50a1d61f8f9e
Slack MCP 서버 및 실시간 검색 API 공개: 외부 에이전트가 Slack 맥락에 접근하는 표준 경로에 대한 Slack의 공식 발표입니다.
Effective context engineering for AI agents: 에이전트에게 어떤 맥락을 어떻게 넣어 줄 것인가를 다룬 Anthropic 엔지니어링 블로그입니다.
얇은 일과 두꺼운 일: 문서는 영수증일 뿐이다
원문 인터뷰에는 짧게만 언급되지만, Jaime DeLanghe의 에세이를 함께 읽으면 첫 번째 원칙의 근거가 훨씬 분명해집니다. 그는 지식 노동의 생산성을 문서, 덱, 이메일 스레드, 회의록, 풀 리퀘스트(Pull Request, PR), 보고서 같은 산출물의 개수로 재는 관행이 제조업과 농업에서 물려받은 낡은 척도라고 지적합니다.
"완벽한 제품 기획 문서(Product Brief)를 건네받았다고 해 봅시다. 촘촘하고, 잘 쓰였고, 빠진 것도 없습니다. 그러면 끝난 걸까요? 그것을 쓰는 일이 어려운 부분이었을까요? 아닙니다. 어려운 것은 그 주변의 모든 것이었습니다. 틀을 바꿔 놓은 세 번의 대화, 일정에 이의를 제기한 엔지니어, 가정을 무너뜨린 고객 통화, 실제 전략이 된 복도에서의 논쟁. 그 문서는 영수증일 뿐입니다."
"If you hand me a perfect product brief, tight, well-written, covers all the bases, are you done? Was writing it the hard part? No. The hard part was everything around it. The three conversations that changed the framing. The engineer who pushed back on the timeline. The customer call that blew up your assumptions. The hallway argument that turned into the actual strategy. The brief is just the receipt."
Slack 내부에서는 이를 얇은 일(Thin Work) 과 두꺼운 일(Thick Work) 이라는 표현으로 구분해 왔다고 합니다. 전통적으로는 문서, 스프레드시트, Figma 파일이 두꺼운 일이고 채팅은 가벼운 조율에 불과한 얇은 일로 취급되었습니다. 에세이의 주장은 이 구분이 정확히 거꾸로였다는 것입니다. 대화야말로 층이 겹겹이 쌓여 있고, 서로 모순되며, 시간에 따라 변하고, 어떤 문서도 온전히 담지 못하는 조직의 의도를 품고 있습니다. 문서는 그 어수선하고 살아 있던 과정에서 합의처럼 보이는 한 순간을 잘라낸 스냅샷일 뿐입니다.
이 관점이 에이전트 이야기와 만나는 지점이 바로 여기입니다. 에이전트가 쓸모 있어지려면 필요한 것은 정제된 문서가 아니라, 그 문서가 만들어지기까지 오간 정제되지 않은 대화라는 것입니다. 그리고 그 대화는 공개된 채널에 남아 있을 때만 에이전트가 읽을 수 있습니다.
핸드오프의 리듬: 월요일 아침 CPO의 받은 편지함
인간 에이전트 팀의 기본 박자는 핸드오프(Handoff)의 순환입니다. Claude가 Slack 안에서 초안 작성, 요약, 모니터링, 사전 준비 같은 생산 작업을 처리해 사람에게 넘기고, 사람은 검토하고 결정하고 방향을 다시 잡아 준 뒤 다음 단계를 에이전트에게 되돌려줍니다.
원문은 이 순환을 설명하기 위해 Jaime DeLanghe의 월요일 아침을 그대로 보여 줍니다.
"월요일 아침이고, 저는 방금 에이전트가 저를 위해 만들어 둔 일일 브리핑을 받았습니다."
"It's Monday morning, and I've just had my daily briefing that an agent has built for me."
브리핑과 함께 그의 검토를 기다리고 있는 것들은 다음과 같습니다. 지난주 제품 워크숍 요약본에 에스컬레이션이 필요한 항목이 표시되어 있고, 웹 전반의 AI 동향을 정리한 리포트가 있고, 그날 잡힌 회의별 사전 브리핑이 있고, 오래되어 손봐야 할 자기소개를 에이전트에게 맡겨 다시 쓴 결과물이 있습니다. 각 순환의 끝에서 사람은 에이전트의 작업을 검토하고 그에 근거해 결정을 내립니다.
주목할 점은 이 목록이 모두 "사람이 하기는 귀찮지만 판단은 사람이 해야 하는 일" 이라는 것입니다. 요약, 수집, 정리, 초안은 에이전트가, 우선순위와 결정은 사람이 가져가는 분업입니다. 원문이 제시하는 실천 항목도 이 분업을 그대로 반영합니다.
에이전트가 만든 브리핑으로 하루를 시작하기: 요약, 에스컬레이션, 회의 준비, 웹 동향 정리는 에이전트가 주도하고 사람이 검토하기에 적합한 작업입니다.
작업을 공유 채널에 묶어 두기: 모든 작업을 공유 채널에서 다루어 사람과 에이전트가 함께 분류할 수 있게 하되, 우선순위 결정은 사람이 이끕니다.
가벼운 신호를 실행 가능하게 만들기: Jaime DeLanghe의 채널에서는 이모지 리액션 하나가 항목을 목록에 추가하고, 에이전트가 그 작업을 집어 갑니다. 별도의 티켓 시스템이나 명령어를 외울 필요 없이, 이미 쓰고 있던 동작에 트리거를 붙인 것입니다.
세 번째 항목은 작지만 중요한 설계 결정입니다. 새로운 도구를 배우게 하는 대신 이미 몸에 익은 동작에 자동화를 얹으면 도입 저항이 거의 사라집니다. 이 패턴은 Claude Tag의 앰비언트(Ambient) 동작이나 Claude Code의 에이전트 팀(Agent Teams) 기능에서도 비슷한 형태로 구현되어 있습니다.
에이전트를 동료처럼 다루기: 역할이 분명해야 살아남는다
전문화된 Claude 에이전트를 여럿 두고 일하다 보면, 일대일 챗봇이라는 심상을 갖고 있는 사람에게는 상황이 혼란스럽게 느껴집니다. Jaime DeLanghe의 접근은 기술적이라기보다 사회적입니다.
"저는 에이전트를 일종의 동료라고 생각하기를 좋아합니다."
"I like to think that agents are kind of like coworkers."
사람 팀원에게 역할과 책임이 있듯 에이전트에게도 분명한 목표와 담당 영역이 있어야 합니다. 이 비유는 단순한 수사가 아니라 운영상의 판단 기준으로 이어집니다.
"그 에이전트의 가치가, 쓰는 사람들이 아주 분명하게 느끼고 이해하는 것이 아니라 위에서 시켜서 쓰는 것처럼 느껴진다면, 그게 무엇을 위한 물건인지 기억하기가 정말 어렵습니다."
"If the value of the agent feels mandated rather than very clearly felt and understood by the people using it, it's really hard to remember what the thing is for."
여기서 나오는 실천 항목 두 가지는 도입 단계의 조직이 특히 새겨 둘 만합니다.
반복적이고 정형적인 작업은 범용 에이전트로 보내기(Route routine, transactional tasks to a general agent): 사람들에게 전용 도구를 기억하라고 요구하는 대신, 헬프데스크 티켓 등록이나 지난주 지표를 상태 보고서로 옮기는 일처럼 반복되는 작업을 하나의 에이전트가 처리하도록 학습시키는 편이 낫다는 것입니다. 도구가 늘어날수록 "그건 어느 도구로 하더라" 라는 인지 부담이 늘어나는데, 이 부담이 도입 실패의 흔한 원인입니다.
가치는 강제되는 것이 아니라 느껴지는 것(Let value be felt, not mandated): 사람들이 그 에이전트가 무엇을 위한 것인지 설명하지 못한다면, 그 에이전트를 은퇴시킬 때가 된 것입니다. 도입한 자동화를 걷어내는 기준을 명시적으로 제시했다는 점에서 눈여겨볼 만한 항목입니다.
시리즈 1편은 여기에 기술적 뼈대를 더합니다. 에이전트의 역할은 스킬 파일(Skill Files)로 정의해 두면 전문화가 쉬워지고, 회사 안의 다른 사람들이 같은 유형의 에이전트를 빠르게 세울 수 있습니다. 또한 각 에이전트에게는 사람과 분리된 자격 증명(Credentials)과 지속적인 메모리(Memory)가 필요합니다. 데이터 분석을 맡은 에이전트에게는 BigQuery 접근 권한이, 품질 보증(QA)을 맡은 에이전트에게는 Playwright MCP 접근 권한이 필요한 식입니다.
더 알아보기: 에이전트에게 역할 부여하기
Equipping agents for the real world with Agent Skills: 스킬 파일로 에이전트의 역할과 절차적 지식을 정의하는 방법을 다룬 Anthropic 엔지니어링 글입니다.
Managed agents: 사람 계정에 묶이지 않은 에이전트 자격 증명과 격리 모델을 설명한 문서입니다.
Agent Skills 개요 문서: 스킬 파일의 구조와 작성 방법을 정리한 공식 문서입니다.
공개가 기본값, 비공개는 의도적으로
Slack은 창업 초기부터 공개 채널을 기본값으로 삼으라고 권해 왔습니다. 이유는 단순합니다.
"여러분은 공유된 이해를, 앞으로 이어질 모든 작업을 위한 공유된 맥락을 쌓고 있는 것입니다."
"You're building a shared understanding, a shared context for all of the work that's going to come next."
그의 권고는 맥락과 지식을 가둬야 할 구체적인 이유가 없다면 채널을 공개로 두라는 것입니다. 에이전트가 끌어다 쓸 정보가 많을수록 더 나은 팀원이 되기 때문입니다. 그리고 공개된 맥락은 복리로 쌓입니다. 새로 합류한 사람은 텅 빈 받은 편지함이 아니라 역사 위로 온보딩하고, 아무도 같은 말을 반복하지 않게 됩니다. 이제는 에이전트도 그 혜택을 받고, 축적된 맥락과 작업 기억이 다시 사람에게로 흘러 돌아옵니다.
실천 항목은 세 가지입니다.
평상시 업무는 공개된 곳에서: 민감하지 않은 프로젝트, 공지, 질의응답 채널을 공개로 두어 동료로서의 에이전트가 필요한 지식을 얻을 수 있게 합니다.
에이전트는 팀이 읽는 것을 읽는다: 비공개 채널은 그 채널을 보고해야 할 모든 에이전트에게 사각지대입니다. 비공개 설정의 비용을 접근 통제가 아니라 에이전트의 성능 저하로 환산해 보라는 관점입니다.
심리적 안전감이 경계를 정하게 하라: 진짜 민감한 자료를 분리하고 나면, 업무가 DM으로 숨어드는 주된 이유는 비밀 유지가 아니라 과정을 남에게 보이는 것에 대한 불편함입니다. 사람들은 거친 초안과 설익은 질문을 포함해 일상적인 업무를 공개된 곳에서 해도 괜찮다고 느낄 수 있어야 하고, 동료가 그것을 선의로 받아 줄 것이라 믿을 수 있어야 합니다.
마지막 항목에 붙은 문장이 이 섹션의 핵심입니다.
"신뢰를 줌으로써 신뢰를 얻습니다."
"You gain trust by giving trust."
시리즈 1편은 이 원칙을 조금 다른 각도에서 보완합니다. 문서 하나, 채널 하나씩 공개 여부를 판단하는 대신 Slack 워크스페이스와 회의록, 문서 라이브러리 전체에 적용되는 명확한 보안 경계(Security Boundary)를 소수만 정의하라는 것입니다. 경계 안에서는 사람이든 AI든 모든 팀원에게 맥락이 흐릅니다. 항목마다 판단하는 방식은 "이 채널은 공개여야 하나 비공개여야 하나" 같은 결정 피로를 매일 만들어내는 반면, 워크스페이스 수준의 경계 몇 개는 그 피로를 없앱니다.
물론 예외는 있습니다. 민감한 대화는 사람과 AI 사이에 비공개로 남아야 하며, 이를 위해 Claude Tag는 @Claude에게 다이렉트 메시지를 보내는 경로를, 그리고 Claude.ai와 Claude Cowork는 개인 MCP 커넥터를 통한 비공개 작업 경로를 제공합니다.
가능성을 보여주며 확산시키기: How I Slackbot 채널의 사례
새로운 업무 방식을 배우는 가장 빠른 길은 동료가 하는 것을 보는 것입니다. Jaime DeLanghe는 Slack의 모회사인 Salesforce에서 이 현상을 목격했습니다. How I Slackbot 이라는 전사 채널에서 직원들이 스킬, 디버깅 요령, 워크플로우 팁을 공유하는데, 그의 집계로는 수천 명이 참여하고 있다고 합니다. 이 채널은 공개가 기본값이기 때문에, 영업 프로세스에서 나온 요령 하나가 엔지니어링 프로세스를 다시 설계하는 결과로 이어지기도 합니다.
Slack 내부에서 제품 관리자(Product Manager, PM)들에게 Claude 사용을 확산시킨 과정도 비슷했습니다. 원문의 표현으로는 "상상할 수 있는 가장 자기조직적인 일" 이었습니다. PM 한 명이 개발자 경험(Developer Experience) 리드의 도움을 받아 환경을 세팅한 뒤, 자신이 무엇을 어떻게 했는지 보여주는 캔버스를 하나 작성했습니다. 다른 PM들이 그 형식을 복사했습니다. 팀들이 워크숍을 조직하고 각자의 git 저장소를 만들었습니다. 위에서 지시한 교육 프로그램이 아니라 한 사람의 기록이 템플릿이 되어 번진 것입니다.
실천 항목은 두 가지입니다.
전사 공유 채널을 하나 만들기(Stand up a company-wide show-and-tell channel): 직원들이 스킬, 디버깅 요령, 워크플로우 팁을 공유할 수 있는 공개된 장소를 하나 마련해, 한 직무에서 나온 요령이 다른 직무를 바꿀 수 있게 합니다.
남이 복사할 수 있는 기록을 권장하기(Encourage write-ups others can copy): "내가 무엇을 어떻게 했는가" 를 담은 짧은 문서 하나가 한 사람의 설정을 팀의 템플릿이나 스킬로 바꿉니다.
두 번째 항목은 앞서 나온 스킬 파일과 자연스럽게 이어집니다. 개인의 요령을 산문으로 적어 두면 다른 사람이 읽고 따라 하는 데서 그치지만, 같은 내용을 스킬 파일로 적어 두면 에이전트가 직접 실행할 수 있는 자산이 됩니다.
활동량이 아니라 결과를 측정한다
Slack 초창기부터 Jaime DeLanghe를 붙들고 있던 질문은 생산성을 어떻게 측정할 것인가였습니다. 그가 드는 예시는 자기 제품에 대한 것이라 더 뼈아픕니다.
"우리가 사람들이 메시지를 더 많이 보내기를 바라는 걸까요? 아마 아닐 겁니다. 메시지를 많이 보낸다는 것이 Slack에서 더 많은 것을 얻고 있다는 뜻은 아닐 수 있습니다. 메시지가 많다는 것은 사람들이 필요한 것을 찾지 못하고 있다거나, 하고 싶은 말을 한 번에 하지 못한다는 뜻일 수도 있습니다."
"Do we want people to send more messages? Maybe not. Sending messages might not actually mean that they're getting more out of Slack. More messages can mean people can't find what they need, or can't say what they mean the first time."
AI의 가치를 측정하는 문제도 형태가 꽤 비슷하고, 이 정도로 복잡한 대상에는 단순한 지표가 통하지 않습니다. 토큰 사용량은 불이 켜져 있다는 사실을 알려 줄 뿐이고, 그것을 아는 것도 중요하지만 충분하지는 않습니다. 에세이에서는 같은 이야기를 더 신랄한 비유로 표현합니다. 소비한 토큰 수로 AI 전환을 측정하는 것은 공장의 생산성을 전기 요금 고지서 맨 위 숫자로 재는 것과 비슷하다는 것입니다.
실천 항목 두 가지는 다음과 같습니다.
사용량 지표는 맥박 측정으로만 다루기(Treat usage metrics as a pulse check, not proof of value): 활동량은 도입이 일어나고 있다는 사실을 알려 줄 뿐, 그것이 효과를 내고 있다는 증명은 아닙니다.
스스로의 판단을 쓸 준비를 하기(Be ready to use your own judgment): 사람들이 이 도구를 쓰는 방식이 더 나은 사업 성과로 이어진다는 것을 깔끔하게 증명할 방법은 없습니다. Jaime DeLanghe의 표현대로 그 둘을 잇는 데는 여전히 "많은 믿음의 도약(a lot of leaps of faith)" 이 필요하며, 어떤 대시보드나 사용량 통계도 그것을 대신 증명해 주지 않습니다.
이 대목은 AI 도입 성과 보고를 준비해 본 사람이라면 익숙한 곤경일 것입니다. 에세이는 여기에 한 문장을 더 보탭니다. 기업들이 측정하지 못하고 있고 아직 아무도 대시보드를 만들지 못한 것은 정렬(Alignment), 즉 일을 하는 사람들이 자신이 무엇을 왜 하려는지, 그것이 목표를 달성할 것인지를 실제로 이해하고 있는가라는 질문입니다. 모두가 개별적으로는 생산적이지만 집합적으로는 교착 상태에 빠지는 상황을 그는 경계합니다.
일하는 방식 자체를 바꾸는 일, 그리고 팀 스포츠
인간 에이전트 팀을 도입하려는 조직에 Jaime DeLanghe가 주는 가장 큰 조언은 모든 워크플로우를 다시 상상하라는 것입니다.
"우리는 일하는 방식을 어떻게 바꿀지 알아내야 할 것입니다. 같은 종류의 일을 더 빨리 더 많이 하는 것이 아니라요. 그리고 그것은 팀 스포츠가 될 것입니다."
"We're going to have to figure out how to change the ways that we're working, not just do more of the same kind of work faster. And that is going to be a team sport."
에세이에서 그는 이 진단을 도입 실패율과 연결합니다. AI 파일럿의 90% 이상이 실패하는 이유는 기술이 문제여서가 아니라 회사가 변하지 못하기 때문이라는 것입니다. Slack 공동 창업자 Stewart Butterfield가 창업 초기에 쓴 글 We Don't Sell Saddles Here를 인용하며, 자신들이 파는 것은 기능이 아니라 일하는 방식의 변화이고 소프트웨어는 그 변화를 전달하는 수단일 뿐이라고 정리합니다.
그렇다면 무엇부터 해야 할까요. 원문의 마지막 조언은 의외로 소박합니다. 빨리 시작하되, 작게 시작하라(Start soon, but start small). 몇 사람을 Claude가 있는 공유 채널 하나에 모으고, 같은 자원 세트를 주고, 일하게 두라는 것입니다. Slack의 경험이 지침이 된다면, 그들이 만들어 낸 것은 알아서 번져 나갑니다.
시리즈 1편이 함께 짚는 것: 북극성과 신뢰의 축적
이번 편이 조직 문화와 습관에 초점을 맞췄다면, 시리즈 1편은 같은 문제를 팀 운영의 관점에서 다룹니다. 두 편을 함께 읽어야 그림이 맞춰지므로, 1편에서만 다루는 두 가지를 덧붙입니다.
첫째는 북극성(North Star) 입니다. 맥락과 역할이 갖춰진 팀에 야심 차고 폭넓은 목표를 글로 명시해 공유하면, 일부 에이전트는 시킨 일을 처리하는 데 그치지 않고 새로운 작업 흐름을 먼저 제안하기 시작합니다. Anthropic에서는 북극성을 언제나 사람이 설정하고, 그중 어떤 에이전트가 능동적으로 제안해도 되는지를 명시적으로 지정합니다. 1편이 드는 사례는 "제품 온보딩을 더 도움이 되게 만들자" 는 북극성을 가진 내부 도구 팀으로, 한 에이전트가 온보딩 흐름의 오류 메시지 문구 개선을 먼저 제안했고 그다음 주 온보딩 성공률이 측정 가능한 수준으로 올라갔습니다.
둘째는 신뢰를 쌓는 순서입니다. Anthropic의 팀들은 에이전트가 보여 준 신뢰도에 비례해 자율성을 부여하고, 그 범위를 의도적으로 넓혀 갑니다. 엔지니어들이 에이전트에게 500건의 버그 수정을 독립적으로 맡긴 사례가 있지만, 처음부터 그랬던 것은 결코 아닙니다. 새 동료가 합류했을 때와 마찬가지로 여러 번의 피드백 순환을 거쳐야 암묵지가 밖으로 드러납니다. 여기서 1편이 강조하는 실무 장치가 검증(Verification) 입니다. 코드에 테스트가 있듯 다른 산출물에도 검증 수단을 붙일 수 있고, 기술 문서라면 평가 기준표(Rubric)와 스타일 가이드를 적용하는 식입니다. 나아가 한 에이전트에게 작업을 시키고 다른 에이전트에게 그 작업을 검사하게 하는 수행자와 검증자(Doer-Verifier) 하네스 패턴도 널리 쓰입니다.
1편의 마지막 조언 하나는 이번 편의 측정 이야기와 맞닿아 있습니다. 에이전트가 독립적으로 일하기 시작하면, 사람의 주의를 희소 자원으로 취급하도록 에이전트를 코칭하라는 것입니다. 질문을 모아 한 번에 답할 수 있게 묶고, 사람을 빠르게 따라오게 하려고 핵심 맥락을 반복해 주고, 한 사람이 한 번에 보는 항목 수를 제한하는 식입니다. 어떤 팀은 아예 커뮤니케이션을 어떻게 묶고 무엇만 올릴지 결정하는 역할만 맡은 에이전트를 따로 두기도 하고, 어떤 팀은 하루에 에이전트가 처리할 작업량에 상한을 두어 사람이 그 결과를 의미 있게 검토할 수 있게 합니다.
멀티에이전트 시스템이 규모를 키울 때 나타나는 실패 양상에 관해서는 다음 글을 참고해주세요:
정리: 여섯 가지 원칙을 다시 읽으면
여섯 개 원칙을 나란히 놓고 보면 공통점이 하나 드러납니다. 어느 것도 모델의 성능에 관한 이야기가 아니라는 점입니다. 공개 채널, 역할 정의, 핸드오프 리듬, 확산 방식, 측정 기준은 모두 사람 조직을 운영하는 오래된 문제이고, 시리즈 1편도 같은 결론에 도달합니다. "이 패턴 중 어느 것도, 적어도 사람에게는 새롭지 않다. 에이전트는 그 기본기를 건너뛰지 않는 것을 더 중요하게 만들 뿐이다."
정리하면 이렇습니다. 대화를 지식 베이스로 다루고, 에이전트에게 이유를 묻고, 핸드오프를 하루의 리듬으로 만들고, 각 에이전트에게 설명 가능한 역할을 주고, 가치를 설명하지 못하는 에이전트는 은퇴시키고, 공개를 기본값으로 두고, 한 사람의 기록이 템플릿이 되게 하고, 사용량을 증거가 아닌 맥박으로 읽는 것입니다. 기술 도입 프로젝트가 아니라 조직 운영 방식의 재설계라는 것이 이 글의 일관된 메시지입니다.
Turning conversation into knowledge 원문 블로그
Building effective human-agent teams 시리즈 1편 블로그
The Work is the Conversation 에세이
https://jaimedelanghe.medium.com/the-work-is-the-conversation-50a1d61f8f9e
Claude Tag 출시 발표
더 읽어보기
-
Self-service data analytics in Slack: Anthropic 내부의 Claude Tag 배포 사례 (영문)
-
Anthropic, Slack에서 @Claude를 팀원처럼 호출하는 Claude Tag 기능 및 멀티플레이어 에이전트 협업 가이드 공개
-
멀티에이전트 시스템의 실패 패턴: AI 에이전트 군집의 쏠림, 담합, 목표 충돌에 대한 Anthropic의 연구
-
Anthropic이 제시하는, 신뢰할 수 있는 AI 에이전트 구축을 위한 실천 원칙: 에이전트의 4가지 구성 요소와 다층 방어 전략 (feat. Anthropic)
-
AI 에이전트 프로토콜 개발자 가이드: MCP부터 A2A, UCP, AP2, A2UI, AG-UI까지 (feat. Google)
이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다. 
이 글이 유용하셨다면 아래
쪽 좋아요
를 눌러주세요 — 파이토치 한국 사용자 모임
이 새로운 소식을 정리하고 공유하는 데 힘이 됩니다! 