AX LABS
← 블로그 에이전트 제품 설계

AI 에이전트를 팀원으로 쓰는 법 — Slack CPO가 공개한 5가지 원칙

대화가 지식이 되게 하는 운영 원칙을 실무 체크리스트와 브리핑 프롬프트로 옮겼습니다

AI 에이전트를 팀원으로 쓰는 법 — Slack CPO가 공개한 5가지 원칙

회사에서 오간 대화는 저절로 지식이 되지 않는다. 이 말을 한 사람이 다름 아닌 Slack의 CPO다.

Anthropic이 지난주 공개한 제이미 델랑헤(Jaime DeLanghe) 인터뷰에서 그는 이렇게 말한다. "초기 Slack 시절의 연구 자료가 산더미처럼 있는데, 결론은 '아니, 대화는 지식으로 바뀌지 않는다'였다. 그냥 잔뜩 쌓여 있을 뿐이고, 사람들은 여전히 같은 설명을 반복해야 했다." 대화가 가장 많이 쌓이는 회사조차 그 대화를 자산으로 만들지 못하고 있었다는 고백이다.

에이전트가 이 오래된 문제의 답이 됐다. 쌓여만 있던 기록을 읽고, 묻고, 꺼내 쓸 수 있는 존재가 생겼기 때문이다. 다만 델랑헤의 결론은 도구 이야기가 아니라 운영 이야기다. 이 글은 인터뷰에 담긴 다섯 원칙을 전부 정리하고, 마지막에 이번 주에 바로 적용할 수 있는 체크리스트와 프롬프트를 붙였다.

원칙 1 — 대화 로그를 지식 베이스로 취급한다

에이전트 이전에도 검색은 있었다. 달라진 것은 질문의 수준이다. 기록에서 "무엇이 결정됐는가"를 찾는 것은 검색으로도 됐다. 에이전트는 "왜 그렇게 결정됐는가" — 결정의 근거와 그 앞의 논쟁까지 — 를 꺼내준다. 재논의를 시작하기 전에 지난번에 왜 그 길을 접었는지부터 확인할 수 있게 된 것이다.

여기에 연결 범위가 품질을 결정한다. Slack 대화만이 아니라 회의록, 이메일, 캘린더, 문서 저장소까지 에이전트가 읽는 표면을 넓힐수록 답이 좋아진다. 우리 식으로 옮기면, 에이전트에게 물어볼 가치는 에이전트가 읽을 수 있는 맥락의 넓이에 비례한다.

원칙 2 — 준비와 실행은 에이전트, 판단은 사람

델랑헤가 묘사하는 자신의 월요일 아침은 구체적이다. 출근하면 에이전트가 만들어 둔 데일리 브리핑이 기다린다. 지난주 프로덕트 워크숍 요약에는 에스컬레이션이 필요한 항목이 플래그로 표시돼 있고, 웹에서 수집한 AI 개발 동향 정리, 당일 회의 각각의 사전 준비 자료가 붙어 있다. 주말 사이 수정을 지시해 둔 소개문 초안도 고쳐져 올라와 있다.

① 에이전트가 준비브리핑 · 요약 · 초안② 사람이 검토·결정우선순위와 방향③ 에이전트가 실행티켓 · 문서 · 후속 작업④ 공개 채널에 축적다음 준비의 재료판단이 필요한 지점만 사람이 잡는다Slack CPO의 월요일 아침이 이 사이클로 돌아간다

이 사이클에서 사람이 하는 일은 검토와 우선순위 결정이다. 준비도 실행도 에이전트가 맡지만, 무엇을 먼저 할지와 어디로 갈지는 공유 채널에서 사람이 정한다. Slack 팀은 이 핸드오프를 더 가볍게 만들기 위해 이모지 반응 하나로 해당 메시지가 태스크 목록에 등록되고 에이전트가 집어 가게 만들었다. 위임의 단위를 "지시문 작성"에서 "리액션 한 번"까지 낮춘 것이다.

원칙 3 — 에이전트마다 존재 이유를 한 줄로 말할 수 있어야 한다

델랑헤는 에이전트를 동료처럼 생각한다고 말한다. 이 은유의 실무적 의미는 채용과 평가다. 동료라면 역할 정의 없이 뽑지 않고, 성과 없이 자리를 유지하지 않는다.

"에이전트의 가치가 위에서 내려온 지시로 느껴질 뿐, 쓰는 사람들에게 분명하게 체감되고 이해되지 않는다면 — 그게 뭘 위한 물건인지 기억하는 것조차 어려워진다."

그래서 Slack의 기준은 단순하다. 헬프데스크 티켓 작성이나 지난주 지표를 상태 보고로 정리하는 반복적·거래적 업무는 범용 에이전트에게 넘기고, 특화 에이전트에는 구체적 목표와 담당 영역을 준다. 그리고 팀이 "이 에이전트가 왜 있는가"를 설명하지 못하면 은퇴시킨다. 에이전트 수가 늘어나는 것은 성과가 아니다. 존재 이유를 말할 수 있는 에이전트만 남기는 것이 성과다.

원칙 4 — 기본값은 공개 채널, 비공개는 예외

다섯 원칙 중 가장 구조적인 대목이다. 에이전트는 팀이 읽을 수 있는 것만 읽는다. 업무가 DM과 비공개 채널로 옮겨가는 만큼, 원칙 1에서 만든 지식 베이스에 구멍이 뚫린다.

공개 채널팀 전체가 읽는다새 팀원도 과거를 읽는다에이전트가 읽는다DM · 비공개 채널초대된 사람만 읽는다새 팀원은 못 읽는다에이전트도 못 읽는다에이전트는 팀이 읽을 수 있는 것만 읽는다DM으로 옮겨진 업무는 지식 베이스에서 빠진다

흥미로운 것은 델랑헤의 진단이다. 진짜 민감한 자료를 제외하면, 업무가 DM으로 숨는 주된 이유는 보안이 아니라 심리다. 완성되지 않은 중간 상태를 보이고 싶지 않은 것이다. 그래서 이 원칙은 채널 설정 문제가 아니라 문화 문제가 된다. 거친 초안과 절반쯤 다듬어진 질문을 공개된 곳에 꺼내도 동료들이 선의로 받아 준다는 확신 — 델랑헤의 표현으로는 "신뢰는 신뢰를 줘야 얻는다" — 이 있어야 기본값이 유지된다.

부수 효과도 크다. 공개 채널에 쌓인 맥락은 에이전트만이 아니라 새로 합류한 팀원의 온보딩 자료가 된다. 에이전트를 위해 만든 구조가 사람에게도 좋은 구조였던 셈이다.

원칙 5 — 확산은 지시가 아니라 시연으로

Slack의 모회사 Salesforce에는 "How I Slackbot"이라는 전사 공개 채널이 있다. 수천 명이 모여 각자의 에이전트 활용법, 디버깅 팁, 워크플로 트릭을 공유한다. 영업 조직에서 나온 요령이 엔지니어링 프로세스를 바꾸는 일이 여기서 일어난다.

Slack 내부의 확산 경로도 같은 모양이었다. PM 한 명이 Claude 활용법을 문서로 정리하자 다른 PM들이 그 포맷을 그대로 베꼈고, 팀 단위 워크숍이 열렸고, 결국 팀이 직접 쓰는 저장소까지 만들어졌다. 전사 공지가 아니라 "내가 이렇게 했다"는 짧은 후기 하나가 확산의 단위였다.

측정 — 토큰 사용량은 맥박이지 성적표가 아니다

도입 성과를 어떻게 재느냐는 질문에 델랑헤는 지표의 층위를 나눈다.

업무 결과 — 실제 가치대시보드가 아니라 쓰는 사람의 판단으로 확인활동 지표 — 채택 확인메시지 수 증가가 곧 가치는 아니다토큰 사용량 — 가동 확인불이 켜져 있다는 뜻일 뿐, 증명이 아니다아래 두 층은 조건이고, 증명은 맨 위에서만 나온다

토큰 사용량은 "불이 켜져 있다"는 확인일 뿐이다. 활동 지표도 마찬가지다. "사람들이 메시지를 더 많이 보내길 원하는가? 아닐 수도 있다. 메시지가 늘었다는 것은 필요한 것을 못 찾고 있거나, 한 번에 뜻을 전달하지 못하고 있다는 신호일 수도 있다." 사용량과 사업 성과를 잇는 데는 상당한 믿음의 도약이 필요하다는 것을 인정하면서, 그는 최종 판정을 대시보드가 아니라 쓰는 사람의 판단에 둔다. 도입 보고서를 토큰 그래프로 채우고 있다면 맨 아래 층만 재고 있는 것이다.

이번 주에 시작하는 적용 체크리스트

다섯 원칙을 실행 항목으로 옮기면 이렇게 된다.

# 할 일 대응 원칙
1 공개 채널을 기본값으로 선언하고, 비공개 개설에는 사유를 적게 한다 원칙 4
2 데일리 브리핑 에이전트 하나를 세운다 (아래 프롬프트) 원칙 2
3 운영 중인 에이전트마다 "존재 이유 한 줄"을 적는다 — 못 적으면 은퇴 후보 원칙 3
4 전사 show-and-tell 채널을 열고 "내가 이렇게 했다" 후기를 주 1회 올린다 원칙 5
5 전사 동시 도입 대신, 팀 하나의 공유 채널에서 시작해 효과로 번지게 한다 전체

2번의 브리핑 에이전트는 델랑헤의 월요일 아침 구성을 그대로 옮긴 지시문으로 시작하면 된다.

매일 아침 8시 30분, 아래 구성으로 브리핑을 만들어 #팀-브리핑 채널에 올려줘.

1. 어제 주요 채널에서 결정된 사항 — 결정 내용만이 아니라 왜 그렇게 정했는지 근거까지
2. 응답이 필요한데 24시간 넘게 멈춰 있는 스레드 (에스컬레이션 표시)
3. 오늘 회의 각각의 사전 준비 — 관련 스레드·문서 요약과 지난 논의에서 남은 쟁점
4. 우리 도메인 관련 외부 동향 2~3건 (출처 링크 포함)

확실하지 않은 내용은 추측하지 말고 원본 스레드 링크를 달아줘.

도구 문제가 아니라 일하는 방식 문제다

인터뷰의 마지막 문장이 다섯 원칙 전체를 요약한다. "같은 종류의 일을 더 빨리 하는 게 아니라, 일하는 방식 자체를 바꿔야 한다. 그리고 그것은 팀 스포츠다."

공개 채널 기본값, 핸드오프 사이클, 에이전트의 존재 이유, 시연 중심 확산 — 전부 라이선스 구매로 얻어지는 것이 아니라 조직이 합의해야 만들어지는 것들이다. 어느 팀의 어떤 업무부터 이 사이클에 올릴지, 그 설계가 우리가 하는 일이다. AX Ops 방법론 →

참고

함께 읽으면 좋은 글