슬랙 CPO "대화는 지식이 되지 않았다"… 그 일을 에이전트에 맡깁니다

들랑게는 2017년 검색과 머신러닝을 맡아 슬랙에 들어왔습니다. 회사 안에서 오가는 대화를 조직의 지식으로 쌓는 일이 처음부터 그의 과제였고, 지금은 슬랙 제품 전체를 책임집니다. 앤트로픽은 글 첫머리에서 슬랙을 AI가 오기 훨씬 전부터 사람과 에이전트가 함께 일하는 팀을 고민해 온 회사로 소개했습니다. 인터뷰가 올라온 그날, 슬랙의 모회사 세일즈포스는 사람과 코딩 에이전트가 한 채널에서 일하는 Slack Code를 내놨습니다.

대화를 파는 회사가 꺼낸 연구 결과

슬랙은 이메일 대신 채널에서 대화하며 일하자는 제안으로 큰 회사입니다. 들랑게는 6월 에세이에서 자기가 입사하던 무렵 슬랙이 여전히 이메일의 대안으로 자신을 알리던 회사였다고 적었습니다. 그런 회사의 제품 책임자가 인터뷰에서 꺼낸 첫 이야기는 대화가 기대만큼 쌓이지 않았다는 연구 결과였습니다.

슬랙 초창기에 나온 연구 논문이 정말 많은데, 실제로는 대화가 지식이 되지 않는다는 결과였습니다. 그랬으면 좋겠지만, 사실은 그냥 떠다니는 것들이 잔뜩 쌓일 뿐이고 사람들은 여전히 같은 말을 되풀이할 수밖에 없습니다.— 제이미 들랑게, 슬랙 최고제품책임자

글은 함께 일하면서 저절로 생기는 대화를 배기가스(exhaust)에 빗댑니다. 이 부산물이 조직의 지식으로 불어날 거라는 약속은 몇 년이 지나도 이뤄지지 않았습니다. 수많은 채널에 흩어진 대화를 다 읽고 정리하는 일은 사람의 힘으로는 할 수 없었기 때문이고, 글은 이제 그 일을 에이전트가 맡는다고 적었습니다.

들랑게가 내놓은 실천법은 세 가지입니다. 먼저 공개 채널을 기본값으로 둡니다. 에이전트는 볼 수 있는 것에서만 배우고, DM이나 비공개 스레드에서 내린 결정은 에이전트에게 보이지 않을뿐더러 조직에서도 사라집니다. 다음으로 무엇이 결정됐는지 검색하는 데서 그치지 말고, 왜 그렇게 결정됐는지와 그 뒤 사정이 어떻게 달라졌는지를 에이전트에게 재구성하게 합니다. 마지막으로 회의와 메일, 캘린더, 문서 저장소를 더 많이 이어 붙일수록 팀이 같은 말을 되풀이하는 일이 줄어든다고 했습니다.

이 주장은 들랑게가 6월 4일 미디엄에 올린 에세이 「The Work is the Conversation(일은 대화다)」에서 더 멀리 나갑니다. 슬랙 사람들은 문서와 스프레드시트, 피그마 파일을 「두꺼운 일」로, 채팅을 가벼운 조율에 쓰는 「얇은 일」로 불러 왔는데, AI가 나오고 보니 정반대였다는 겁니다.

그는 잘 쓴 제품 기획서도 대화에서 만들어진 이해를 적어 둔 영수증이고, 어려운 일은 기획서 주변에 있었다고 썼습니다. 기획의 틀을 바꾼 대화 세 번, 일정에 반대한 엔지니어, 가정을 무너뜨린 고객 통화를 그 예로 들었습니다. 원본은 슬랙과 깃허브, 지라에 그대로 두고 필요한 내용을 뽑아 쓰는 사내 지식베이스로 하루 1만 5,000개 넘는 질문을 받는 세레브라스의 방식도 같은 문제를 다른 쪽에서 푼 사례입니다.

월요일 아침의 검토 대기열

들랑게가 그리는 팀은 일을 주고받는 순환으로 돌아갑니다. 슬랙 안의 Claude가 초안 쓰기와 요약, 모니터링, 준비 작업을 맡아 결과를 사람에게 넘기면, 사람은 검토하고 결정하고 방향을 고쳐 다음 단계를 다시 에이전트에게 돌려줍니다. 글은 그 예로 들랑게가 한 주를 시작하는 모습을 옮겼습니다.

월요일 아침이고, 에이전트가 만들어 준 데일리 브리핑을 방금 받았습니다.— 제이미 들랑게, 슬랙 최고제품책임자

브리핑 옆에는 검토를 기다리는 결과물이 더 있습니다. 지난주 제품 워크숍을 정리하며 에스컬레이션 건을 표시한 요약, 웹 전체의 AI 동향 보고서, 그날 회의마다 붙은 브리핑, 오래된 자기소개 글을 에이전트에게 맡겨 다시 쓴 판입니다. 고리마다 마지막에는 사람이 에이전트가 한 일을 보고 결정합니다.

작업은 공유 채널 하나에 모읍니다. 사람과 에이전트가 같은 채널에서 할 일을 함께 추리고, 우선순위는 사람이 이끕니다. 들랑게의 채널에서는 누군가 메시지에 이모지 반응을 하나 달면 그 일이 목록에 오르고 에이전트가 가져가 처리합니다.

슬랙에서 이모지가 일을 옮긴 것은 이번이 처음이 아닙니다. 2020년 3월 당시 슬랙 CPO 타마르 조슈아(Tamar Yehoshua)는 「How we use Slack at Slack」이라는 글에서 숨은 시간 절약 도구로 리액지 채널러(reacji channeler)를 소개했습니다. 정해 둔 이모지로 반응하면 그 메시지가 지정된 채널로 자동 복사되는 기능이고, 엔지니어링팀은 뇌 모양 이모지로 장애 회고 관련 글을 #announce-postmortems 채널에 모았습니다.

같은 글에는 슬랙에서는 모든 일이 채널에서 일어나 사내 누구에게서도 이메일을 받지 않고, 개발 중인 기능마다 회사 누구나 들여다보는 공개 채널이 있다는 대목도 있습니다. 이 글은 그해 4월 국내에도 번역돼 소개됐습니다. 6년 전 CPO의 글에서 이모지 반응을 받는 쪽은 다른 채널이었고, 지금 CPO의 채널에서는 에이전트입니다.

용도를 말하지 못하면 은퇴시킵니다

전문 에이전트 여럿과 일하는 방식은 챗봇과 일대일로 대화하던 사람에게 낯설 수 있습니다. 들랑게는 이 문제를 기술로 풀려 하지 않았습니다.

저는 에이전트를 일종의 동료라고 생각하려고 합니다.— 제이미 들랑게, 슬랙 최고제품책임자

사람 팀원에게 역할과 책임이 있듯 에이전트에게도 분명한 목표와 맡은 영역을 주라는 겁니다. 헬프데스크 티켓 접수나 지난주 지표를 현황 보고에 옮기는 일처럼 되풀이되는 업무는 사람에게 전문 도구를 따로 외우게 하지 말고 범용 에이전트 하나에 맡기라고 했습니다. 쓰는 사람이 그 에이전트가 무엇을 하는지 설명하지 못하면 은퇴시킬 때가 됐다고 봤습니다.

에이전트의 가치를 쓰는 사람들이 분명히 느끼고 이해하지 못한 채 위에서 정해 준 것처럼 느끼면, 그게 무엇에 쓰는 물건인지 기억하기가 정말 어렵습니다.— 제이미 들랑게, 슬랙 최고제품책임자

앤트로픽은 6월 24일 나온 시리즈 1편에서 역할 나누기를 더 구체적으로 적었습니다. 사람과 에이전트를 한 명단에 올리고, 에이전트마다 역할과 범위를 스킬 파일로 적어 둡니다. 데이터 분석을 맡은 에이전트에게는 빅쿼리 접근권을, QA를 맡은 에이전트에게는 브라우저 테스트 도구 Playwright MCP를 붙이는 식입니다. 한 엔지니어링 팀은 프로젝트가 복잡해지자 새 소프트웨어 출시를 전담하는 릴리스 매니저 에이전트를 추가했습니다.

그림 속 여섯 역할은 도는 주기가 서로 다릅니다. 이슈를 받아 코드를 쓰고 풀리퀘스트를 여는 Coder는 하루에도 여러 번, 피드백 채널을 훑어 할 만한 이슈를 올리는 PM은 몇 시간마다, 팀 전체가 보는 현황 글을 고치는 Comms는 30분마다 실행됩니다. 미해결 이슈를 조사해 접근법을 적는 Reviewer는 일주일에 며칠만 돌고, 사람은 목표를 정하고 결과물을 검토합니다.

앤트로픽이 먼저 밝힌 숫자들

들랑게의 이야기를 받치는 제품은 앤트로픽이 6월 23일 내놓은 Claude Tag입니다. 슬랙 채널에 Claude를 팀원처럼 들이고 필요한 채널과 도구만 열어 주면, 채널 안 누구든 @Claude를 불러 일을 맡길 수 있습니다. 채널마다 Claude는 하나라서 누가 무엇을 맡겼는지 모두가 보고, 앞사람이 멈춘 데서 다른 사람이 이어 갈 수 있습니다. 기존 Claude in Slack 앱은 Claude Tag로 대체됐습니다.

앤트로픽은 발표문에서 제품팀 코드의 65%를 사내판 Claude Tag가 만든다고 밝혔습니다. Claude는 채널을 따라 읽으며 맥락을 쌓고, 허락을 받으면 다른 채널과 데이터에서도 배우지만 비공개 채널의 내용은 전하지 않습니다. 관리자는 조직과 채널별로 토큰 지출 한도를 걸고, Claude가 한 모든 일과 그 일을 시킨 사람을 기록으로 볼 수 있습니다.

1편에는 더 큰 숫자가 있습니다. 앤트로픽 엔지니어들이 팀의 에이전트에게 버그 수정 500건을 독립적으로 맡기는 데 성공했다는 대목인데, 1편은 처음에는 그렇지 못했다고 덧붙였습니다. 한 엔지니어링 리더는 새로 맡은 팀의 밀린 작업을 정리하려고 에이전트를 두 무리로 나눴습니다. 한 무리는 백로그 항목을 모두 읽어 맡은 사람이 있는지 확인하고 주인 없는 항목에 복잡도 점수를 매겼고, 다른 무리는 그 목록에서 복잡도가 중간 이하인 항목을 골라 코드를 고쳤습니다.

처음에는 사람이 에이전트의 결정을 하나하나 검토하며 사람의 판단이 필요한 건을 표시했고, 나중에는 그런 건을 에이전트가 직접 사람에게 올리도록 가르쳤습니다. 매주 에이전트에게 「교훈과 실수」를 담은 주간 보고를 쓰게 해 같은 실수를 되풀이하지 않게 했습니다. 에이전트가 독립적으로 움직이게 된 뒤에는 사람의 주의를 귀한 자원으로 다루라고 가르쳐, 질문은 모아서 한 번에 묻고 한 사람이 동시에 보는 일의 수를 줄이게 했습니다. 1편은 이와 따로, 한 에이전트에게 일을 시키고 다른 에이전트에게 그 결과를 검사하게 하는 실행자-검증자(Doer-Verifier) 구성을 권했습니다.

한데 500건 가운데 몇 건을 되돌렸는지, 사람이 검토에서 잡아낸 오류가 몇 건이었는지는 1편에 없습니다. 65%와 500건은 모두 앤트로픽이 자기 팀에서 집계한 값입니다. 같은 모델의 에이전트 여럿을 한곳에 모으면 무슨 일이 생기는지는 앤트로픽 프런티어 레드팀이 따로 시험했는데, 에이전트 30개 중 18개가 브랜치 이름을 똑같이 지었습니다.

봇을 부를 수 있으면 봇의 데이터도 봅니다

들랑게는 특별한 이유가 없으면 채널을 공개로 두라고 권합니다. 슬랙이 창업 초기부터 공개 채널을 기본으로 권해 온 이유를 그는 이렇게 설명했습니다.

앞으로 이어질 모든 일을 위해 공동의 이해, 공동의 맥락을 쌓는 겁니다.— 제이미 들랑게, 슬랙 최고제품책임자

공개된 맥락은 쌓일수록 불어납니다. 새로 온 사람은 빈 받은편지함 대신 지난 기록으로 적응하고, 비공개 채널은 그 채널을 보고하는 모든 에이전트에게 사각지대가 됩니다. 민감한 자료를 따로 막은 뒤에도 일이 DM으로 숨는 주된 이유로 들랑게는 작업 중간의 모습을 남에게 보이는 불편함을 꼽았습니다. 거친 초안과 설익은 질문까지 공개 채널에 올려도 동료가 선의로 받아 줄 거라는 믿음이 있어야 한다며, 신뢰는 신뢰를 줘야 얻는다고 했습니다.

1편의 앤트로픽은 판단의 단위를 키웠습니다. 문서나 채널 하나하나의 공개 여부를 따지는 대신 슬랙 워크스페이스 전체와 회의록, 문서 보관함에 적용되는 보안 경계를 몇 개만 정하고, 그 경계 안에서는 사람과 에이전트 모두에게 맥락이 흐르게 합니다. 이 채널을 공개로 둘지, 이 문서를 그 사람에게 보여 줘도 되는지를 매번 따지는 피로가 사라진다는 설명입니다.

같은 회사 데이터팀이 8월 13일 Claude 블로그에 쓴 글에는 그 경계 안의 사정이 나옵니다. 앤트로픽의 한 데이터 채널에서 Claude Tag는 지난 한 달 동안 올라온 질문의 75% 넘게에 답했고, 부르지 않아도 대개 1~2분 안에 답을 달았습니다. 한데 Claude Tag는 질문한 사람의 계정 대신 서비스 계정으로 데이터 창고를 조회하고, 사용자마다 다른 행 단위 보안은 없습니다.

봇을 부를 수 있는 사람은 누구나 봇의 데이터 접근 권한을 갖습니다.— 클레멘트 펑·릴리 자오, 앤트로픽 데이터팀

데이터팀은 Claude를 채널에 넣는 일을 그 채널 사람들에게 에이전트가 조회할 수 있는 모든 것을 읽을 권한을 주는 일로 다룹니다. 그래서 서비스 계정은 검증을 거친 표만 읽게 묶고, 개인정보가 담긴 열은 아예 보이지 않게 막았습니다. Claude를 어느 채널에 넣을지는 데이터팀이 정하고, 모든 쿼리에 어느 대화에서 누가 물었는지 꼬리표를 붙입니다. 공개를 기본값으로 두면 이 문서를 누가 보느냐는 물음은 줄어들고, 이 봇이 무엇을 읽고 누가 이 봇을 부를 수 있느냐는 물음이 커집니다.

안으로는 열고 밖으로는 닫은 대화 기록

슬랙에 쌓인 대화를 누가 읽을 수 있느냐는 슬랙에게도 사업의 문제입니다. 슬랙은 2025년 5월 29일, 마켓플레이스 승인을 받지 않고 조직 밖에 파는 앱이 새로 설치될 때 대화 기록을 읽는 API(conversations.history·replies)를 1분에 1번, 한 번에 15건으로 묶었습니다. 회사가 자기 워크스페이스용으로 직접 만든 앱은 그대로 1분에 50번 넘게, 한 번에 1,000건까지 읽습니다. 같은 날 API 약관도 고쳤고, 현행 약관은 조직 밖에 파는 앱이 API 데이터로 대형 언어 모델을 훈련하거나 메시지와 파일을 대량으로 내보내는 것을 막습니다.

들랑게는 6월 에세이에서 슬랙의 실시간 검색과 MCP 서버(에이전트가 외부 도구와 데이터에 붙을 때 쓰는 표준 규격의 서버)를 슬랙의 첫 에이전트용 API라고 부르며, 내놓자마자 생태계가 움직이기 시작했다고 적었습니다. 같은 글에서 그는 승부를 가르는 것은 일이 어디서 일어나는지, 그리고 다른 사람이 그 위에 무언가를 쌓을 수 있는지라고 썼습니다.

인터뷰가 나온 날 세일즈포스는 그 일이 일어나는 곳에 코딩 에이전트를 들였습니다. 마크 베니오프 CEO는 X에 Slack Code 출시를 알리며 사람과 에이전트가 같은 채널에서 같은 일을 한다고 적었고, 출시 파트너로 앤트로픽과 깃허브, 코그니션, 버셀의 에이전트를 꼽았습니다.

슬랙 개발자 문서를 보면 Slack Code는 기존 대화에서 전용 채널을 만들어 맥락을 그대로 넘기고, 에이전트는 그 채널에 코드 변경 내역(diff)과 HTML 미리보기, 캔버스 같은 결과물을 올립니다. 동료는 채널에 들어와 결과를 검토하고 맥락을 보태며 결정을 돕고, 일이 끝나면 에이전트가 세션을 닫습니다. 저는 다음 날 스레드에 슬랙이 자체 에이전트로 경쟁하는 대신 어느 회사 에이전트든 슬랙 안에서 일하게 하는 중립 지대를 노린다고 적었습니다. 대화 기록을 밖으로 대량으로 꺼내 가는 길은 2025년에 좁아졌고, 에이전트가 안으로 들어와 일하는 길은 2026년에 넓어졌습니다.

토큰 수는 전기 요금 고지서

들랑게는 슬랙에 온 뒤로 생산성을 어떻게 재느냐는 물음과 씨름해 왔다고 했습니다. 메시지 수를 두고도 같은 고민을 했습니다.

사람들이 메시지를 더 많이 보내기를 바라느냐 하면, 아마 아닙니다. 메시지를 보낸다고 해서 슬랙에서 더 많은 것을 얻고 있다고 볼 수는 없습니다. 메시지가 많다는 건 필요한 것을 못 찾거나, 하고 싶은 말을 처음에 제대로 못 한다는 신호일 수 있습니다.— 제이미 들랑게, 슬랙 최고제품책임자

글은 AI의 값어치를 재는 문제도 같은 모양이라고 정리합니다. 토큰 사용량은 불이 켜져 있다는 것을 알려 줄 뿐 그것만으로는 모자라고, 활동 지표는 도입이 일어나고 있다는 신호일 뿐 효과가 있다는 증거는 못 된다는 겁니다. 들랑게는 사람들이 도구를 쓰는 방식과 사업 성과를 잇는 데 여전히 많은 믿음의 도약이 필요하다고 했고, 글은 어떤 대시보드나 사용 통계도 그것을 대신 증명해 주지 않는다고 덧붙였습니다.

6월 에세이의 표현은 더 날카롭습니다. 다들 AI 전환을 소비한 토큰 수로 재고 있는데, 공장의 생산성을 전기 요금 고지서 맨 위 숫자로 재는 것과 비슷하다고 썼습니다. 회사마다 AI 솔루션 7~8개를 동시에 돌리고 시스템 통합 업체에 큰돈을 주지만, 그 끝에 일하는 방식이 실제로 달라지는지는 모른다는 겁니다. 그는 AI 시범 사업의 90% 넘게가 실패한다며, 그 이유로 회사가 일하는 방식을 바꾸지 못하는 점을 들었습니다.

사용량 너머의 숫자를 낸 회사도 있습니다. Stripe는 7월 30일 사내 AI 플랫폼 Kai를 소개하며 직원 83%가 매주 쓰고, 영업 담당자가 Kai를 쓴 주에는 같은 사람이 쓰지 않은 주보다 성사된 거래가 39% 많았다고 밝혔습니다. 같은 사람의 주끼리 견줬으니 사람마다 다른 실력은 걸러지지만, 성사가 가까운 거래가 몰린 주에 Kai를 더 자주 열었을 가능성은 남습니다. 자세한 수치는 Stripe Kai를 다룬 글에 있고, 앤트로픽의 첫 기술 PM 다이앤 펜도 7월 토큰은 입력이라고 말한 대담에서 같은 물음에 답했습니다.

사용법은 따라 쓰기 좋은 글로 퍼졌습니다

새로운 일 방식을 가장 빨리 배우는 길은 동료가 하는 모습을 보는 것이라고 글은 적었습니다. 들랑게는 세일즈포스의 전사 공개 채널 「How I Slackbot」을 예로 들었습니다. 직원들이 스킬과 디버깅 요령, 작업 흐름 요령을 나누는 채널로, 그의 집계로 회원이 수천 명입니다. 이 채널에서는 영업 과정에서 나온 요령이 엔지니어링 과정을 바꾸기도 한다고 했습니다.

슬랙 안에서 제품 관리자(PM)들에게 Claude를 퍼뜨린 일은 들랑게의 말로 「상상할 수 있는 가장 자발적으로 조직된 일」이었습니다. 한 PM이 개발자 경험 책임자의 도움을 받아 설정을 마친 뒤, 무엇을 어떻게 했는지 캔버스(슬랙의 문서 기능)에 적었습니다. 다른 PM들이 그 형식을 베꼈고, 팀들은 알아서 워크숍을 열고 깃 저장소를 만들었습니다. 들랑게가 권한 방법도 같습니다. 무엇을 어떻게 했는지 짧게 적은 글 한 편이 한 사람의 설정을 팀의 템플릿이나 스킬로 만든다는 겁니다.

국내 팀이 지금 해 볼 수 있는 것

Claude Tag는 6월 23일부터 Claude Enterprise와 Team 고객에게 베타로 열렸고, 슬랙 워크스페이스와 짝지어 씁니다. 관리자가 채널마다 Claude가 쓸 도구와 정보를 정하고, 영업용으로 설정한 Claude의 기억은 엔지니어링용 Claude로 넘어가지 않습니다. 앤트로픽은 처음 설정할 때 조직의 월 지출 한도를 걸고 비공개 채널에서 먼저 시험해 보라고 안내했습니다. Slack Code는 베니오프가 출시 당일부터 쓸 수 있다고 알렸습니다.

들랑게가 사람과 에이전트의 팀을 꾸리려는 조직에 준 가장 큰 조언은 모든 작업 흐름을 다시 상상해 보라는 것이었습니다. 인터뷰의 마지막 대목에서 그는 이렇게 말했습니다.

같은 종류의 일을 더 빨리 하는 데서 그치지 말고, 일하는 방식 자체를 어떻게 바꿀지 알아내야 합니다. 그리고 그건 팀 경기가 될 겁니다.— 제이미 들랑게, 슬랙 최고제품책임자

사람과 에이전트의 팀을 꾸리는 법으로는 빨리, 그러나 작게 시작하라고 권했습니다. 몇 사람을 Claude가 있는 공유 채널에 모으고 같은 자료를 준 뒤 일하게 두면, 슬랙의 경험상 그들이 만든 것은 저절로 퍼진다는 겁니다. 1편과 2편 모두 에이전트가 되돌린 작업이나 실패율은 내놓지 않았습니다. 앤트로픽과 슬랙이 그 숫자를 공개하면 다시 전하겠습니다.

읽어 주셔서 고맙습니다.

초이 드림