Slack Code 코드 채널 뜯어보기 — 파트너 에이전트 구성과 Slack 에이전트 API

mini_knows·2026년 8월 23일

AI코딩에이전트 AI트렌드 Slack Code claudecode slackapi 코드채널

AI 트렌드·이슈

목록 보기

81/120

안녕하세요, 미니지식공간입니다.

Slack Code가 2026년 8월 20일 공개됐고, 코드 채널(code channel)이라는 새로운 대화 단위가 함께 도입됐다. 이 글은 제품 소개보다 실행 구조 쪽에 무게를 두고, 코드 채널이 어떤 흐름으로 동작하는지와 Slack 에이전트 API가 그 아래에서 무엇을 담당하는지를 공식 문서 기준으로 본다.

TL;DR

코드 채널은 에이전트 멘션으로 생성되고 작업 종료와 함께 아카이브되는 일회성 프로젝트 채널이다.

에이전트는 새 아이덴티티를 받지 않는다. 호출한 사용자의 ACL을 그대로 쓴다(Slack 발표 및 브리핑 발언).

코드 채널 API는 아직 파트너 전용이다. 지금 직접 붙일 수 있는 것은 기존 Slack 에이전트 API다.

1. 릴리스 개요

항목	값
제품명	Slack Code (코드 채널)
발표일	2026-08-20
주체	Slack, 세일즈포스 자회사
요금제	모든 Slack 플랜
별도 조건	각 파트너 에이전트 접근 권한 필요
런치 파트너	Anthropic Claude, Cognition Devin, GitHub Copilot, Vercel
ChatGPT	Slack 블로그는 곧, 세일즈포스 페이지는 파트너 목록 포함 → 확인 필요
코드 채널 API	파트너 사용 중, 일반 개발자 개방 시점 미공개 → 확인 필요

출처: Slack 블로그(2026-08-20), Salesforce 발표 페이지(2026-08-20)

2. 코드 채널의 실행 흐름

발표 자료에 서술된 순서를 정리하면 이렇다.

아무 대화에서든 코딩 에이전트를 멘션한다.
에이전트가 그 작업 전용 코드 채널을 만들고 관련된 사람을 끌어온다. 이때 에이전트가 채널로 가져가는 것은 그 작업을 촉발한 대화의 맥락뿐이다.
채널 안에서 대화, 계획(plan), 코드 diff, 라이브 HTML 프리뷰가 각각 탭으로 분리돼 표시된다.
팀원 누구나 도중에 끼어들어 방향을 바꾸거나 에이전트를 멈출 수 있다.
작업이 끝나면 채널이 스스로 아카이브된다. 기록은 감사 로그로 남고 검색 가능한 상태로 유지된다.

프로덕션 배포처럼 되돌리기 어려운 작업은 에이전트가 결과물을 묶어 담당자 승인을 요청하는 경로로 빠진다. 별도 승인 시스템을 거치지 않고 채널 안에서 처리된다는 것이 발표의 설명이다.

3. 권한 모델: 새 서비스 계정을 만들지 않는다

에이전트 플랫폼을 붙일 때마다 서비스 아이덴티티를 새로 발급하고 권한을 따로 관리하는 것이 통상적인 부담이었다. Slack Code는 그 지점을 없앴다고 주장한다.

코드 채널의 에이전트는 Slack의 기존 보안 모델, 권한, 관리자 제어를 상속한다. 새 인프라도 새 아이덴티티도 없다(세일즈포스 발표 페이지).
모든 동작은 사용자를 대신해 그 사용자의 ACL로 수행된다. Slack 안에서도, 연결된 외부 시스템에서도 동일하다. god 권한이나 봇 레벨 권한은 없다(Rob Seaman, VentureBeat 브리핑).
에이전트가 만드는 산출물은 표준 PR이므로 기존 릴리스 게이트와 리뷰 절차가 그대로 적용된다.

직함 표기가 출처마다 다르다. 세일즈포스 페이지는 Rob Seaman을 EVP·GM of Slack으로, VentureBeat는 Slack 임시 CEO로 적었다.

4. 내 에이전트를 붙이려면 지금 무엇을 쓰나

코드 채널 API는 현재 런치 파트너가 사용 중이고, 일반 개발자 개방은 곧이라고만 안내됐다. 시점은 공개되지 않았다. 따라서 지금 사내 에이전트를 Slack에 올리려면 기존 Slack 에이전트 API를 쓰게 된다.

앱 설정에서 Agents 기능을 켜면 assistant:write 스코프가 자동 추가되고, 이벤트 구독에서 app_home_opened, app_context_changed, message.im을 켠다. 새 앱은 agents.sessions.setStatus / agents.sessions.rename을 쓰는 것이 권장되며, 구형 assistant.threads.* 메서드는 호환 브리지로 동작하지만 폐기 예정이다.

아래는 Slack 공식 문서 Developing an agent의 응답 루프 예제에서 상태 전환과 스트리밍 부분만 발췌한 것이다.

app.event('app_mention', async ({ event, client }) => {
  const channel = event.channel;
  const threadTs = event.thread_ts ?? event.ts;

  // 1. 즉시 상태를 processing으로 - 로딩 UX 표시
  await client.agents.sessions.setStatus({
    channel_id: channel,
    thread_ts: threadTs,
    status: 'processing'
  });

  // 2. plan 모드로 스트림 시작
  const stream = await client.chat.startStream({
    channel,
    thread_ts: threadTs,
    task_display_mode: 'plan'
  });

  // 3. 작업 계획을 먼저 보여준다
  await client.chat.appendStream({
    channel,
    ts: stream.ts,
    chunks: [
      { type: 'task', id: 'search', text: 'Search workspace', status: 'in_progress' },
      { type: 'task', id: 'build',  text: 'Build context',    status: 'pending' },
      { type: 'task', id: 'compose', text: 'Compose response', status: 'pending' }
    ]
  });

  // ... 중략: 컨텍스트 수집과 LLM 호출 ...

  await client.chat.stopStream({ channel, ts: stream.ts, text: parsed.summary, blocks });

  // 4. 반드시 active로 되돌린다 - 안 하면 1시간 뒤 타임아웃까지 processing 유지
  await client.agents.sessions.setStatus({
    channel_id: channel,
    thread_ts: threadTs,
    status: 'active'
  });
});

agents.sessions.setStatus는 메시지를 보냈다고 로딩 상태가 자동으로 풀리지 않는다는 점이 함정이다. 문서는 완료 시 status: "active"를, 사용자 개입이 필요하면 status: "suspended"를 명시하라고 적고 있다. 그대로 두면 1시간 타임아웃까지 세션이 processing으로 남는다.

스트리밍 자체는 아래 세 메서드가 담당한다. 문서 기준 파라미터만 옮기면 이렇다.

// chat.startStream
{ "channel": "D12345678", "thread_ts": "1503435956.000248",
  "task_display_mode": "plan",
  "chunks": [{ "type": "markdown_text", "markdown_text": "Let me help you with that!" }] }

// chat.appendStream
{ "channel": "D12345678", "message_ts": "1503435956.000247",
  "thread_ts": "1503435956.000248",
  "chunks": [{ "type": "markdown_text", "markdown_text": "Here is what I found..." }] }

// chat.stopStream
{ "channel": "D12345678", "message_ts": "1503435956.000247",
  "thread_ts": "1503435956.000248",
  "chunks": [{ "type": "markdown_text", "markdown_text": "Hope this helps!" }] }

Block Kit 블록은 chat.stopStream에서만 사용할 수 있다. startStream과 appendStream에서 쓰면 블록이 쪼개지기 때문에 문서가 막아 두었고, 스트리밍 메시지에서는 언펄(unfurl)도 비활성화된다. 또한 Agents 기능이 켜진 앱은 워크스페이스 게스트가 사용할 수 없다.

5. 발표에 나온 숫자를 읽는 법

Slack: 코드 채널의 70% 이상이 하루 안에 생성·종료된다 → Slack 자사 발표, 내부 사용 기준.
Cognition: 최근 몇 달간 내부 머지 PR 수가 10배, 헤드카운트는 40% 증가 → Cognition 측 주장(Jeff Wang, VentureBeat 브리핑).
반대편 데이터: 가트너는 2025년 6월 25일 자료에서 2027년 말까지 에이전틱 AI 프로젝트의 40% 이상이 취소될 것으로 전망했다(VentureBeat 인용).

세 숫자 모두 성격이 다르다. 앞의 둘은 이해관계자의 자체 집계이고, 마지막은 제3자의 예측이다. 도입 근거로 삼기 전에 각자 자기 조직의 PR 리드타임을 기준선으로 재보는 편이 낫다.

6. 도입 전 체크리스트

쓰려는 파트너 에이전트(Claude, Devin, Copilot, Vercel)의 좌석·권한이 이미 확보돼 있는가.
사내 자체 에이전트를 붙일 계획이라면 코드 채널 API 개방 시점을 확인했는가.
코드 채널이 아카이브된 뒤 남는 감사 로그의 보존 정책이 사내 규정과 맞는가.
에이전트가 사용자 ACL로 동작한다는 전제가 성립하려면, 사용자 권한 자체가 과도하지 않아야 한다.
PR 머지 게이트를 그대로 둘 것인지, 어느 범위까지 자동화할 것인지 먼저 합의했는가.

자주 묻는 질문

Q. Slack Code를 쓰려면 유료 플랜이 필요한가?
발표에 따르면 Slack Code는 모든 Slack 플랜에서 제공된다. 다만 파트너 에이전트 접근 권한은 별도로 확보해야 한다.

Q. 기존에 만든 Slack 앱 코드를 고쳐야 하나?
코드 채널 때문에 고칠 필요는 없다. 다만 에이전트 앱이라면 assistant.threads.setStatus·setTitle이 agents.sessions.setStatus·rename으로 대체됐고 구형 메서드는 폐기 예정이므로, 이 마이그레이션은 별도로 챙기는 편이 좋다.

Q. 코드 채널 API를 지금 바로 쓸 수 있나?
아니다. 현재는 런치 파트너가 사용 중이고 일반 개발자 개방은 곧이라고만 안내됐다. 정확한 시점은 확인이 필요하다.

마무리

Slack Code는 모델 경쟁이 아니라 실행 위치 경쟁에 가깝습니다. 에이전트를 개인 터미널에서 팀 채널로 옮기고 그 대가로 가시성과 감사 기록을 얻는 구조이며, 개발자 입장에서 실질적인 분기점은 코드 채널 API가 열리는 시점입니다. 그전까지는 기존 에이전트 API로 만든 앱이 Slack 안에서 얼마나 매끄럽게 도는지가 준비의 척도가 되겠습니다.

에이전트를 어디서 실행할 것인가라는 같은 축의 이전 글로 Claude Code 셀프호스팅 환경 정리와 DeepSeek Harness(dsh) 플러그인 구조도 함께 참고하실 만합니다.