Slack Code: 코딩 에이전트가 팀 채널 안으로 들어왔다

코딩 에이전트에서 가장 중요한 것은 이제 코드를 얼마나 잘 쓰느냐가 아니다. 누가 에이전트가 무엇을 하는지 볼 수 있느냐가 더 중요하다. 이번 달 전까지 대부분의 팀에서 솔직한 답은 이랬다. 개발자 한 명이 비공개 터미널이나 브라우저 탭에서 보고 있다가, 나중에 에이전트가 실제로 무엇을 했는지 기억해내길 바라는 정도였다. 8월 20일 출시된 Slack Code는 그 답을 “프로젝트의 모든 사람이 기본적으로 본다”로 바꾸려는 지금까지 가장 큰 시도다.

나는 출시 발표, Slack의 후속 글, 관련 보도를 읽었다. 아래에서 돌아가는 모델은 이미 알고 있는 Claude Code, Devin, Copilot과 같다. 바뀌는 것은 작업이 일어나는 방이다. 그런데 이 차이가 대부분의 보도에서 다룬 것보다 훨씬 중요하다.

핵심 요점 - Slack Code는 “코드 채널”를 추가한다. 태그된 코딩 에이전트(Claude Code, Devin, GitHub Copilot, Vercel, 향후 ChatGPT)가 공개된 공간에서 일하고, 팀이 diff와 라이브 미리보기를 보며, 실제 반영 전에 사람이 승인하는 공유 프로젝트 공간이다. - 출시 첫날부터 모든 Slack 요금제에서 작동하지만 각 에이전트 접근 권한은 별도로 구매해야 한다. 작업이 끝나면 채널은 자동 보관되고 감사 로그가 남는다. - 진짜 변화는 감독 방식이다. 한 사람이 보는 비공개 세션에서 팀이 보는 공유 산출물로 에이전트 작업이 이동한다. 귀속과 검토의 빈틈을 줄이지만 방관자 효과, 형식적인 승인, 공격 표면이 된 채널 컨텍스트 같은 새 문제도 만든다. - 배포 전략이기도 하다. Slack은 1년 동안 에이전트 배관(MCP 서버, 실시간 검색, Slackbot MCP 클라이언트)을 만들었고 코드 채널은 그 배관을 사용자에게 보이게 하는 표면이다. - “배포 전에 사람이 승인한다”는 말을 보장된 결과가 아니라 설계 목표로 봐야 한다. 실제 검토 절차는 여전히 팀이 만들어야 한다.

무슨 일이 있었나

8월 20일 Slack은 무료 워크스페이스를 포함한 모든 요금제에 Slack Code를 출시했다. 출시 보도와 TechRepublic 기사에 따르면 작동 방식은 다음과 같다.

• 아무 Slack 대화에서든 코딩 에이전트를 태그한다. 버그 수정, 페이지 업데이트, 기능 개발 무엇이든 에이전트가 해당 작업용 전용 코드 채널을 만든다.

• 채널 안의 모든 사람은 에이전트가 작업에 사용하는 동일한 대화를 보고, 제안되는 코드 diff를 검토하고, 라이브 HTML 미리보기를 확인하고, 피드백을 남기며 에이전트가 이를 반영하는 과정을 본다. 마지막으로 완성된 작업을 승인한다. 사람의 승인 없이는 아무것도 배포되지 않는다.

• 작업이 끝나면 채널이 자동으로 보관되고 기록용 감사 로그가 남는다.

• 출시 파트너는 Anthropic의 Claude, Cognition의 Devin, GitHub Copilot, Vercel이며 OpenAI의 ChatGPT도 곧 추가될 예정이라고 발표됐다. Slack은 더 넓은 개발자 커뮤니티에 코드 채널 API를 열어 사용자 정의 에이전트도 참여하게 할 계획이다.

누가 채널에 들어오는지는 설정할 수 있다. Slack 제품 담당 부사장 Katie Steigman은 Reworked에 이렇게 말했다. “에이전트를 태그한 사용자만 코드 채널에 들어오게 할 수도 있고, 에이전트가 자신이 가진 컨텍스트를 바탕으로 누가 채널에 있어야 하는지 스스로 추론하도록 설정할 수도 있다.” Slack EVP 겸 총괄 Rob Seaman은 의도를 이렇게 표현했다. “AI는 팀이 실제로 일하는 방식의 일부가 될 때만 가치를 만든다.”

Slack Code는 2026년 8월 20일 모든 Slack 요금제에 출시됐다. 파트너 코딩 에이전트(Claude, Devin, Copilot, Vercel, 향후 ChatGPT)를 공유 “코드 채널”에 넣어 팀 전체가 에이전트의 대화, diff, 라이브 미리보기를 보고, 배포 전에 작업을 승인하며, 채널이 자동 보관될 때 감사 로그를 넘겨받는다. Slack 발표에 따른 내용이다.

감독이 비공개 세션 밖으로 나온다

기능 목록만 보면 가려지는 점이 있다. 오늘날 대부분의 에이전트 감독은 지친 사람 한 명이 유지하는 허구에 가깝다. 에이전트는 누군가의 IDE나 클라우드 샌드박스에서 실행되고, diff는 pull request로 도착하며, “검토”는 오후 5시에 그 개발자에게 남아 있던 집중력만큼 이루어진다. 추론 과정, 막힌 길, 제대로 된 결과가 나오기 전 세 번의 시도는 모두 사라진다. 에이전트 출력을 충분히 검토해 본 경험상 diff는 오히려 과정에서 가장 정보량이 적은 부분이다.

Slack Code의 실제 제안은 과정 자체를 산출물로 만들자는 것이다. 채널에는 에이전트가 작업할 때 사용한 대화, 중간 단계, 받은 피드백, 받은 승인이 남고, 마지막에는 전체가 검색 가능한 기록으로 보관된다. 이는 정말로 다른 감독 모델이다. 좋은 팀이 신입 엔지니어를 검토하는 방식에도 지금의 에이전트 검토보다 가깝다. 출력만 보는 것이 아니라 작업 과정을 보는 것이다.

누가 감독하는지도 달라진다. 제품 설명은 PM, 디자이너, 비기술 직군도 따라볼 수 있다는 점을 명시적으로 내세운다. 나는 대체로 찬성하지만 한 가지 유보가 있다. 지켜보는 사람이 가득한 방과 실제 검토자는 같은 것이 아니다. diff를 읽는 능력은 옆에 앉아 있다고 저절로 생기지 않고, “팀이 볼 수 있다”는 말이 조용히 “아무도 확인하지 않았다”로 바뀔 수 있다. 열 명이 보고 있었지만 승인 책임자가 아무도 없었다면 누가 책임지는가 같은 거버넌스 질문은 내가 에이전트 거버넌스 프레임워크에서 다루는 바로 그 문제다. Slack Code가 대신 답해주지는 않는다. 다만 문제를 보이게 만든다. 그게 정직한 첫 단계다.

Slack Code는 에이전트 감독을 비공개 세션에서 공유되고 보관되는 채널 기록으로 옮긴다. 대화, 중간 단계, 피드백, 승인이 검색 가능한 산출물로 남는다. Slack 제품 글에 따른 내용이다. 지켜보는 사람이 많은 방에서 누가 승인 책임을 갖는지는 여전히 고객이 정해야 한다.

공유 컨텍스트는 양날의 검이다

두 번째 큰 주장은 컨텍스트에 관한 것이다. Slack의 논리는 작업에 필요한 컨텍스트가 이미 채널에 있다는 것이다. 버그 보고, 사양 논의, 고객 불만이 있는 곳에서 에이전트가 일하게 해야지, 비공개 프롬프트에 복사해 붙여넣게 할 이유가 없다는 얘기다. 맞는 말이다. 그리고 Slack이 올해 내내 배포해 온 배관 위에 서 있다. MCP 서버와 실시간 검색 API는 2월에 정식 제공돼 에이전트가 워크스페이스 메시지와 파일에 거버넌스된 방식으로 접근할 수 있게 했고, 6월에는 Slackbot MCP 클라이언트가 뒤따랐다. 나는 MCP 서버 정리 글에서 팀 도구에 대한 MCP 접근이 왜 에이전트 컨텍스트의 유용한 절반인지 다룬 적이 있다. 채널 모델은 그 아이디어를 끝까지 밀어붙인 결과다.

하지만 공유 컨텍스트는 공유 노출이기도 하다. 채널을 읽는 에이전트는 그 안의 모든 것을 읽는다. 누군가 “잠깐만” 붙여넣은 자격 증명도, 고객이 보내온 외부 콘텐츠도 포함된다. 내가 아는 보안 연구자라면 모두 같은 말을 할 것이다. 에이전트가 읽을 수 있는 콘텐츠는 에이전트에게 지시할 수도 있는 콘텐츠다. 공유 채널은 비공개 세션보다 더 큰 프롬프트 인젝션 표면이다. 그건 단순한 사실이다. 쓰기 권한이 있는 에이전트를 바쁜 채널에 연결하기 전에 어떤 채널을 읽게 할지, 어떤 도구를 건드릴 수 있게 할지 의도적으로 정해야 한다. 설정 작업이 아니라 아키텍처 작업이다. 내가 에이전트형 아키텍처에서 설명한 트레이드오프와 같다. 능력이 커지면 영향 범위도 함께 커진다.

Slack Code의 컨텍스트 장점, 즉 작업 컨텍스트가 이미 있는 곳에서 에이전트가 일한다는 점은 Slack이 2026년 2월 정식 제공한 MCP 기반 워크스페이스 접근 위에 서 있다. Unite.AI 보도에 따른 내용이다. 같은 공유 컨텍스트는 프롬프트 인젝션과 자격 증명 노출 표면도 넓히지만 출시 자료는 이 트레이드오프를 다루지 않는다.

귀속과 검토, 화려하지 않은 진짜 장점

이번 출시에서 가장 덜 화려한 부분이 내가 실제로 돈을 낼 부분이다. 먼저 귀속이다. 코드 채널에서는 모든 에이전트 행동이 에이전트 자신의 아이덴티티 아래 기록되고, 이미 모든 사람의 신원을 아는 워크스페이스 안에 있으며, 프로젝트가 끝난 뒤에도 감사 로그가 남는다. 너무 기본적으로 들린다. 맞다. 기본이다. 동시에 대부분의 팀이 현재 에이전트 작업에 갖추고 있는 것보다 더 많은 귀속 인프라다. 지금은 “에이전트가 했다”와 “내가 했다”가 같은 git 이력에 섞여 버리는 경우가 많다. 규제 산업은 지난 1년간 정확히 이런 지루한 기능을 요구해 왔다.

다음은 검토다. 채널에서 diff와 라이브 미리보기를 보고, 에이전트가 피드백을 반영하고, 배포 전에는 강제 승인 게이트가 있다. 다만 빠진 부분을 보자. Slack 자료에는 사람이 작업을 승인한다고 쓰여 있지만, 내가 본 어떤 자료도 그 사람이 누구여야 하는지, 무엇을 보여줘야 하는지, 지정 검토자가 휴가 중이면 어떻게 되는지 명시하지 않는다. 승인 자체가 체크박스가 되면 승인 연극이 생긴다. 모두가 초록 버튼을 습관처럼 누른다. 여기서 가치를 얻는 팀은 승인을 실제 코드 소유자와 실제 diff 검토에 연결하고, 에이전트의 채널 출력은 검토 자체가 아니라 증거로 남기는 팀이다.

경쟁 상황도 중요하다. Reworked 보도가 지적하듯 Microsoft는 2025년 9월 Teams 스레드에 Copilot 코딩 에이전트를 넣었고, Block은 7월에 오픈소스 Buzz를 출시했다. 채팅 창은 에이전트 작업의 경쟁 표면이 되고 있다. Slack의 강점은 화려하지 않다. 팀이 이미 거기 있다. 협업 소프트웨어에서는 영리함보다 배포력이 이긴다. 거의 항상 그렇다.

Slack Code는 채널에서 각 에이전트에 별도 아이덴티티를 부여하고 보관된 프로젝트마다 감사 로그를 유지한다. TechRepublic 보도에 따른 내용이다. 하지만 승인 게이트, 즉 “배포 전에 사람이 작업을 승인한다”는 원칙은 검토자 신원이나 검토 기준을 명시하지 않는다. Reworked에 따르면 직접 비교할 제품은 Microsoft의 Teams Copilot 에이전트(2025년 9월)와 Block의 오픈소스 Buzz(2026년 7월)다.

지금 무엇을 해야 하나

팀이 Slack을 쓰고 코딩 에이전트도 쓴다면 세 가지를 해보자.

1. 이번 주: 위험이 낮고 요구사항이 명확한 작업 하나를 골라라. 문구 수정이나 재현 방법이 분명한 작은 버그 정도면 된다. 두세 명이 지켜보는 코드 채널에서 실행하라. 에이전트를 시험하는 것이 아니라 팀의 검토 행동을 시험하는 것이다. 실제로 누가 diff를 읽는지 보라.

2. 실제 코드가 배포되기 전에: 저장소별 에이전트 작업 승인자가 누구인지, 무엇을 확인해야 하는지 글로 정하라. 답이 “채널에 있는 사람 아무나”라면 검토 절차가 있는 것이 아니라 버튼만 있는 것이다.

3. 광범위하게 배포하기 전에: 에이전트가 어떤 채널을 읽을 수 있는지, 실행 환경이 어떤 자격 증명을 갖는지 범위를 제한하라. 채널 이력은 컨텍스트이고, 컨텍스트는 공격 표면이다. 좁게 시작하고 증거를 보고 넓혀라.

자주 묻는 질문

Slack Code란 무엇인가?

2026년 8월 20일 출시된 Slack 기능이다. 팀이 대화에서 파트너 코딩 에이전트(Claude Code, Devin, GitHub Copilot, Vercel, 향후 ChatGPT)를 태그할 수 있다. 에이전트는 작업 전용 “코드 채널”을 열고, 팀은 그 안에서 작업 과정을 보고 diff와 미리보기를 검토하며 배포 전 결과를 승인한다. 작업이 끝나면 채널은 자동 보관된다.

유료 Slack 요금제가 필요한가?

아니다. Slack Code는 무료 워크스페이스를 포함한 모든 요금제에서 사용할 수 있다. 다만 각 코딩 에이전트 접근 권한은 해당 벤더에서 별도로 구매해야 하므로 실제 비용은 이미 어떤 에이전트에 비용을 내고 있는지에 따라 달라진다.

Slack Code가 코드 리뷰를 대체하나?

아니다. 그렇게 취급하는 것이 가장 큰 위험이다. 검토를 공유되고 보관되는 채널 안으로 옮기고 승인 게이트를 추가하지만, 검토의 품질은 여전히 이름 있는 사람이 diff를 실제로 읽는 데 달려 있다. 소유자 없이 보이기만 하는 절차는 성실한 한 명이 보는 비공개 절차보다 더 나쁘다. 감독받는 것처럼 보이기 때문이다.

에이전트에게 채널 전체를 읽게 해도 안전한가?

채널 안에 무엇이 있느냐에 따라 다르다. 에이전트가 읽을 수 있는 것은 무엇이든 영향을 줄 수 있다. 붙여넣은 자격 증명과 전달된 외부 콘텐츠도 포함된다. 읽기 접근 범위를 좁히고, 에이전트 자격 증명은 최소 권한으로 유지하며, 채널 콘텐츠를 신뢰할 수 없는 입력으로 다뤄라. 에이전트 관점에서는 실제로 그렇다.

결론

Slack Code가 에이전트의 코드 작성 능력을 높여주지는 않는다. 애초에 그걸 위한 기능이 아니다. 팀이 이미 있는 공간에서 에이전트 작업을 기본적으로 보이게 하고, 누가 했는지 남기고, 검토할 수 있게 만든다. 대부분의 에이전트 배포에서 조용히 빠져 있는 세 가지다. 함정은 가시성이 감독과 같지 않다는 점이다. 채널은 기록과 게이트를 제공한다. 실제로 누군가 보고 있는지는 여전히 당신이 해결해야 한다. 에이전트 자체보다 팀이 승인자를 어떻게 설정하는지 보라. 여기서 실제 통제가 되거나 연극이 된다.

검토 통제권을 잃지 않고 팀 워크플로에 에이전트를 넣는 방법을 고민하고 있다면, 나는 이런 주제를 고객과 정기적으로 논의한다. 연락해 달라.

출처

• Salesforce, “Slack Code 소개: 팀을 위한 에이전트형 코딩”: https://www.salesforce.com/introducing-slack-code/ (2026년 8월 19일 게시, 2026년 8월 29일 확인)

• Slack, “Slack Code: 팀과 에이전트가 함께 만드는 공간”: https://slack.com/blog/news/slack-code-channels-for-agents (2026년 8월 28일 게시, 2026년 8월 29일 확인)

• Unite.AI, “Slack Code, AI 코딩 에이전트를 전용 프로젝트 채널에 배치”: https://www.unite.ai/slack-code-puts-ai-coding-agents-in-dedicated-project-channels/ (2026년 8월 20일 게시, 2026년 8월 29일 확인)

• TechRepublic, “Slack Code: AI 코딩 에이전트에 검토와 감독을 위한 공유 채널 제공”: https://www.techrepublic.com/article/news-slack-code-ai-coding-agents/ (2026년 8월 21일 게시, 2026년 8월 29일 확인)

• Reworked, “Slack Code, AI 코딩 에이전트를 공유 채널에 배치”: https://www.reworked.co/collaboration-productivity/slack-code-brings-collaborative-ai-coding-into-channels/ (2026년 8월 20일 게시, 2026년 8월 29일 확인)