혼자 Agent에게 시키는 시대가 끝난다: Slack Code로 만드는 Human + AI 개발팀

혼자 Agent에게 시키는 시대가 끝난다: Slack Code로 만드는 Human + AI 개발팀

AI Coding Agent를 쓰는 모습은 지금까지 꽤 개인적이었다.

개발자가 자기 Terminal이나 IDE를 열고 Agent에게 일을 맡긴다.

Developer
   ↓
Claude Code / Codex / Copilot
   ↓
Repository 분석
   ↓
코드 수정
   ↓
결과 확인

빠르다.

하지만 팀 개발로 넘어가면 묘한 문제가 생긴다.

Agent에게 무엇을 요청했는지 다른 팀원은 모른다.

어떤 전제를 주었는지도 모른다.

Agent가 왜 그런 구현을 선택했는지도 모른다.

PM이나 디자이너가 뒤늦게 결과를 보고 말한다.

"이 요구사항은 그 뜻이 아닌데요?"

개발자는 다시 Agent에게 요청한다.

"방금 만든 거 수정해줘."

그리고 그 결과를 다시 팀에 공유한다.

AI를 도입했는데도 협업 구조는 여전히:

사람
 ↓
Agent
 ↓
사람
 ↓
팀

이다.

Agent와 팀 사이에 한 명의 개발자가 통역사처럼 끼어 있는 구조다.

2026년 8월 20일 Slack이 발표한 Slack Code가 흥미로운 이유가 여기에 있다.

Slack Code가 바꾸려는 것은 코드를 생성하는 모델이 아니다.

Agent와 사람이 일하는 공간 자체다.

기존의:

1 Human
+
1 Agent

구조를

PM
Designer
Developer
QA
        │
        ▼
   Code Channel
        ▲
        │
     AI Agent

로 바꾸려는 시도다.

Slack은 이를 아예 “single-player에서 multiplayer로” 이동하는 방식으로 설명하고 있다.

---

1. 문제는 Agent의 성능이 아니라 Context가 숨어 있다는 것이다

예를 들어 결제 화면에 문제가 발견됐다.

Slack 채널에서는 이미 대화가 진행되고 있다.

PM

결제 완료 버튼을 누르면
가끔 로딩이 끝나지 않는 것 같아요.

QA가 추가한다.

QA

iOS 26에서 재현됐고
네트워크가 느릴 때 빈도가 높습니다.

개발자가 답한다.

Developer

Session refresh하고
Payment request가 겹치는 것 같네요.
확인해볼게요.

여기까지는 팀 전체가 Context를 공유한다.

그런데 개발자가 Claude Code나 다른 Coding Agent를 개인적으로 실행하는 순간 Context가 갈라진다.

Slack

PM
QA
Developer
Product Context

그리고 별도의:

Agent Session

Developer
Agent
Repository Context

가 생긴다.

문제는 두 Context가 자연스럽게 만나지 않는다는 것이다.

그래서 개발자가 Agent에게 다시 설명한다.

결제 완료 화면에서
느린 네트워크 환경에서
Session Refresh와 Payment Request가
겹치는 문제가 있는 것 같아.

관련 코드 조사해줘.

Agent가 구현한다.

팀은 그 과정을 보지 못한다.

---

2. Slack Code는 이 경계를 없애려 한다

Slack Code의 핵심 개념은 Code Channel이다.

Slack은 Code Channel을 사람과 AI Agent가 특정 작업을 함께 처리하기 위해 만들어지는 임시 전용 채널로 설명한다.

일반 Thread보다 큰 작업을 분리하면서도 원래 팀 대화의 Context와 연결하는 구조다.

전체 흐름은 이런 식이다.

기존 Project Channel

#mobile-payment
        │
        │ Agent Mention
        ▼
┌──────────────────────────┐
│ Code Channel             │
│                          │
│ PM                       │
│ Designer                 │
│ Developer                │
│ QA                       │
│ AI Agent                 │
│                          │
│ Plan                     │
│ Code Diff                │
│ Preview                  │
│ Comments                 │
└────────────┬─────────────┘
             │
             ▼
            PR
             │
             ▼
        Test / CI
             │
             ▼
        Human Review

Agent를 Slack에 넣었다기보다 Agent 작업을 팀이 볼 수 있는 공간으로 꺼낸 것에 가깝다.

---

3. Code Channel은 그냥 Slack Channel 하나를 더 만드는 기능이 아니다

일반 채널에서 Agent와 긴 작업을 하면 금방 복잡해진다.

#ios

일상 질문

배포 이야기

QA 이야기

Agent reasoning

Agent 결과

코드

추가 수정

다른 사람 메시지

모든 것이 섞인다.

반대로 Agent와 개인 DM을 사용하면 팀 Context가 사라진다.

그래서 Slack Code는 중간을 선택했다.

Main Channel
    │
    │ 큰 작업 발견
    ▼
Code Channel 생성
    │
    ├─ 필요한 사람만 참여
    ├─ Agent 참여
    ├─ 작업 Context 집중
    ├─ Artifact 축적
    └─ 완료 후 정리

즉 Code Channel은 Task Boundary 역할을 한다.

---

4. 실제 사용도 생각보다 단순하다

Slack 공식 가이드 기준으로 Code Channel은 Agent를 Mention하면서 시작하거나 Agents & tools에서 직접 만들 수 있다.

예를 들어:

@claude

결제 완료 화면에서 발생하는
무한 로딩 문제를 조사해줘.

현재 대화 내용을 참고하고
Session Refresh와 Payment Request가
동시에 실행되는지 먼저 확인해.

바로 수정하지 말고
원인과 수정 계획부터 보여줘.

Agent가 지원하는 경우 Code Channel이 생성된다.

#code-fix-payment-loading

같은 전용 공간에서 작업을 이어간다.

Code Channel 이름도 초기 요청을 기반으로 Agent가 자동으로 정할 수 있다.

---

5. 여기에 개발자만 들어갈 필요가 없다

이 부분이 Slack Code에서 가장 중요한 변화 중 하나다.

Code Channel에는:

Developer

+

Agent

만 들어가는 것이 아니다.

필요하면:

PM

Designer

Developer

QA

Security

Agent

가 같이 들어온다.

Slack 역시 Code Channel은 개발자만을 위한 기능이 아니라고 설명한다.

코드를 모르는 사람도 Agent가 만드는 결과와 Preview를 확인하고 피드백할 수 있다.

---

6. 요구사항이 Agent에게 번역되는 과정이 사라진다

기존에는 이런 식이다.

PM

"버튼이 좀 더 눈에 띄면 좋겠어요."

↓

Developer 해석

"Primary CTA 색과 Contrast를 변경하면 되겠군."

↓

Agent Prompt

"CheckoutButton primary style 수정해줘."

세 번의 전달 과정이 있다.

Slack Code에서는 PM이 같은 공간에서 말할 수 있다.

PM

완료 버튼이 비활성화된 것처럼 보여요.
현재 디자인 시스템은 유지하면서
조금 더 눈에 띄게 해주세요.

Designer:

기존 Primary Button Token은 유지하고
높이와 주변 여백부터 조정해보는 게 좋겠어요.

Developer:

Button API는 변경하면 안 돼.
Checkout 화면에서만 해결해줘.

Agent:

현재 제약을 기준으로
변경 범위를 먼저 정리하겠습니다.

Agent가 팀 대화를 그대로 작업 Context로 사용할 수 있는 구조가 된다.

Slack이 강조하는 Shared Context의 의미가 바로 여기에 있다.

---

7. Agent에게 처음부터 코드를 작성시키지 않는 것이 좋다

팀 Agent Workflow에서는 오히려 이 단계가 중요하다.

나쁜 시작:

@agent

이거 고쳐줘.

좋은 시작:

@agent

현재 대화와 Repository를 확인하고

1. 문제를 재현할 조건
2. 관련 코드
3. 가능한 원인
4. 수정 범위
5. 필요한 테스트

를 먼저 정리해줘.

아직 코드는 수정하지 마.

↓

팀이 Plan을 본다.

↓

PM

1번 조건 맞습니다.

QA

추가로 Background 복귀 직후에도
발생한 적이 있습니다.

Developer

PaymentCoordinator public API는
변경하지 않는 방향으로 진행해줘.

↓

Agent가 구현한다.

이 방식이면 Agent의 첫 번째 추측이 곧바로 코드가 되는 것을 줄일 수 있다.

---

8. Human + AI 개발팀에서 사람이 맡아야 할 역할도 명확해진다

Agent가 코딩한다고 사람의 역할이 줄어드는 것만은 아니다.

오히려 분리가 더 명확해진다.

Human

Goal
Constraint
Product Context
Architecture Decision
Risk Decision
Final Approval

Agent:

Repository Exploration
Implementation
Mechanical Refactor
Test Generation
Alternative Investigation
Artifact Generation

그리고 Compiler와 CI:

Build
Test
Lint
Static Analysis

를 담당한다.

---

9. 전체 역할을 이렇게 보면 깔끔하다

PM / Designer / QA

"What & Why"
      │
      ▼
Developer

Architecture / Constraint
      │
      ▼
AI Agent

Explore / Implement
      │
      ▼
Build / Test / CI

Verify
      │
      ▼
Human Reviewer

Approve

Slack Code는 이 모든 역할이 같은 Context에서 만날 수 있도록 하는 Collaboration Layer다.

---

10. Code Channel 안에는 결과물도 따로 모인다

Slack Code에는 Artifacts 개념이 있다.

공식 가이드에서는 Agent에 따라 다음과 같은 Artifact를 표시할 수 있다고 설명한다.

Code

Canvas

HTML View

Files & Links

즉 긴 Thread에서 결과물을 찾아다니지 않아도 된다.

---

11. 코드도 Slack 안에서 Diff 형태로 본다

예를 들어 Agent가 코드 변경을 만들었다.

Code Channel에서:

Artifacts

↓

Code

를 열면 Agent가 생성하거나 수정한 Code Diff를 확인할 수 있다.

단순히:

Agent:

"수정했습니다."

로 끝나는 것이 아니다.

---

12. Line Comment도 가능하다

Slack Code의 Code Artifact에서는 코드 라인에 직접 Comment를 달 수 있다. 여러 Comment를 모아서 하나의 Review처럼 제출하는 방식도 지원한다.

예:

func refreshSession() async {
    ...
}

Developer:

이 부분은 PaymentCoordinator가 아니라
SessionCoordinator에서 책임지는 게 맞습니다.

QA:

Background 복귀 Case도
Test에 포함해주세요.

Agent는 다시 수정한다.

이 순간부터 Slack Thread가 단순 대화가 아니라 Agent Review Interface가 된다.

---

13. Designer와 PM에게는 HTML Preview가 더 중요할 수 있다

모든 사람이 Diff를 읽지는 않는다.

UI 작업에서는:

Code Diff

보다:

Live HTML Preview

가 더 이해하기 쉽다.

Slack Code는 Agent가 생성한 HTML View 같은 Artifact도 표시할 수 있도록 설계돼 있다.

그래서 비개발자도:

"버튼이 너무 아래에 있어요."

"이 상태에서는 안내 문구가 먼저 보여야 해요."

"모바일에서는 두 줄로 내려가면 안 돼요."

처럼 바로 의견을 줄 수 있다.

---

14. 여기서 중요한 변화가 하나 생긴다

과거의 AI Coding:

Agent Output

→ Developer가 해석

→ 팀에 설명

Slack Code:

Agent Output

→ 팀이 직접 확인

이다.

개발자가 AI 결과를 다시 번역해주는 비용이 줄어든다.

---

15. Agent 상태도 Channel에 표시된다

Agent에게 큰 Task를 맡기면 사람들이 반복해서 묻게 된다.

지금 하고 있어?

끝났어?

뭔가 막혔어?

Slack Code는 Code Channel마다 Agent Status를 표시한다.

현재 공식 가이드의 상태는 다음과 같다.

Working

Idle

Needs attention

Done

Inactive

Archived

예를 들어:

Working

이면 Agent가 작업 중이다.

Needs attention

이면 사람이 개입해야 한다.

---

16. 이게 팀 단위 Agent Observability가 된다

개인 Coding Agent에서는 개발자 한 명이 Agent 상태를 본다.

Slack Code에서는:

Agent A

Working

Agent B

Needs attention

Agent C

Done

을 팀이 공유한다.

Agents & tools → Code channels에서도 여러 Code Channel 상태를 한꺼번에 확인할 수 있다.

---

17. Agent가 이상하게 가면 Stop하면 된다

Agent가 처음부터 잘못된 방향으로 작업하고 있는데:

어차피 돌고 있으니까
끝날 때까지 기다리자.

할 필요도 없다.

Slack은 2026년 Agent UX 개선과 함께 native Stop 버튼을 제공한다.

Code Channel에서는 Agent의 Working... 상태에서 Agent 작업을 중지하고 새로운 Prompt로 방향을 바꿀 수 있다.

예:

Agent

전체 Authentication Layer Refactor 시작

Developer:

STOP

이번 PR 범위가 너무 커.

Session Refresh 충돌만 수정하고
Public API 변경은 하지 마.

Agent 비용뿐 아니라 잘못된 Diff가 커지는 것도 막는다.

---

18. Code Channel은 영구 Project Channel이 아니다

이 부분도 구조적으로 좋다.

#ios
#backend
#product

같은 Channel은 계속 유지된다.

하지만:

#code-fix-payment-race

는 특정 Task를 위한 임시 공간이다.

작업이 끝나면 Close하거나 Archive할 수 있고, 일정 기간 활동이 없으면 Sidebar에서도 자동으로 정리된다. Slack 공식 가이드에서는 7일 동안 활동이 없으면 Code Channel이 Sidebar에서 자동 제거될 수 있다고 안내한다.

---

19. 그렇다고 Context가 사라지는 것은 아니다

중요한 부분이다.

Temporary라는 것은:

작업 끝나면 기록 삭제

라는 의미가 아니다.

Archive된 Channel의 대화는 다시 확인하고 검색할 수 있다.

따라서:

왜 이렇게 구현했지?

라는 질문이 몇 달 뒤 생기면:

PR

+

Code Channel

을 같이 볼 수 있다.

---

20. 이 구조는 일종의 Decision Log 역할도 한다

Git에는:

무엇을 바꿨는가

가 남는다.

PR에는:

어떻게 리뷰했는가

가 남는다.

Code Channel에는:

왜 이렇게 만들었는가

에 가까운 Context가 남는다.

예:

PM

이 상태에서는 결제를
다시 실행하면 안 됩니다.

Developer

그래서 Retry보다
Pending 상태 복구 방식을 사용하겠습니다.

Agent

그 정책에 맞춰
PaymentCoordinator를 변경하겠습니다.

이런 흐름은 Commit Message만으로 남기기 어렵다.

---

21. 하지만 Slack을 Source of Truth로 만들면 안 된다

여기서 경계를 잘 잡아야 한다.

Slack

= Collaboration Context

이지:

Slack

= Source Code Source of Truth

는 아니다.

최종 코드는 Git Repository에 있어야 한다.

최종 검증은 CI에 있어야 한다.

Requirement도 중요하다면 Issue나 공식 문서에 남겨야 한다.

---

22. 추천 구조는 이렇다

Slack

Discussion
Agent Collaboration
Context

↓

Git / PR

Code Change
Review

↓

CI

Build
Test
Lint
Security

↓

Issue / Spec

Product Decision

각 시스템의 역할을 유지한다.

---

23. Agent가 “테스트 통과”라고 말하는 것도 검증이 아니다

Code Channel에서 Agent가:

테스트가 모두 통과했습니다.

라고 보고했다.

그걸 그대로 믿고 Merge하면 안 된다.

최종 Source of Truth는:

CI

Exit Code
Test Report
Build Result

여야 한다.

지난 Agent Workflow 글에서 반복해서 등장하는 원칙과 같다.

AI

판단 / 실행

Deterministic Tool

검증

이다.

---

24. 그래서 Slack Code의 이상적인 끝은 PR이다

예를 들어:

Product Conversation
        │
        ▼
Code Channel
        │
        ▼
Plan
        │
        ▼
Implementation
        │
        ▼
Team Feedback
        │
        ▼
PR
        │
        ▼
CI
        │
        ▼
Human Review
        │
        ▼
Merge

Slack 안에서 모든 개발 Pipeline을 끝내려고 할 필요는 없다.

Slack은 Intent에서 PR까지의 Collaboration Layer가 되는 편이 더 자연스럽다.

---

25. Quick Action도 이런 연결을 위해 존재한다

Code Channel에서는 Agent가 제공하는 기능에 따라 Message 입력창 위에 Quick Action이 나타날 수 있다.

예를 들어:

Create Pull Request

Open in Compiler

Documentation

같은 동작이다.

Agent별로 제공 기능은 다를 수 있다.

---

26. Slack Code를 가장 잘 쓰는 Task는 따로 있다

모든 개발 요청을 Code Channel로 만들 필요는 없다.

예:

이 함수가 뭐 하는 거야?

같은 작은 질문은 그냥 DM이나 Thread면 충분하다.

Slack 역시 Code Channel을 하나의 Thread에 넣기엔 큰, 독립적인 작업 단위에 적합한 것으로 설명한다.

---

27. Code Channel이 잘 맞는 Task

예를 들면:

Bug Investigation

Feature Prototype

UI 개선

작은 Migration

Dependency Upgrade

Test Coverage 개선

Documentation + Code 변경

처럼 여러 번 대화와 검토가 필요한 작업이다.

---

28. Bug Investigation에 특히 잘 맞는다

실제 예를 하나 만들어보자.

Project Channel:

#mobile-app

QA:

로그인 후 앱을 Background로 보냈다가
다시 돌아오면 가끔 로그아웃됩니다.

Developer:

@claude

이 내용을 기준으로 Code Channel 만들어서
원인 조사해줘.

먼저 수정하지 말고
Session lifecycle과 token refresh 흐름부터 분석해.

↓

Code Channel:

#code-investigate-session-expiry

Agent:

가능성이 높은 경로 3개를 찾았습니다.

1. ScenePhase 복귀 시 refresh 중복
2. refresh token race
3. stale credential overwrite

QA:

2번 상황은 느린 Wi-Fi에서
재현 빈도가 높은 것 같습니다.

Developer:

2번부터 재현 Test 만들어줘.

Agent가 테스트와 수정안을 만든다.

이게 Slack Code가 말하는 Multiplayer Agent Workflow에 가깝다.

---

29. Feature 개발에서도 쓸 수 있다

PM:

프로필 화면에서
닉네임 수정 기능이 필요합니다.

Designer:

별도 화면은 만들지 않고
현재 Profile 화면에서 inline edit로 갑시다.

Developer:

@agent

현재 Profile Architecture를 확인해서
변경 범위와 API 영향을 정리해줘.

Agent가 Plan을 만든다.

팀이 보고 수정한다.

그 다음 구현한다.

---

30. 요구사항이 처음부터 완벽할 필요도 없다

기존 AI Prompt 문화에서는:

완벽한 Prompt

를 먼저 작성하려고 한다.

하지만 팀 Collaboration에서는 오히려:

Initial Intent

↓

Team Discussion

↓

Agent Plan

↓

Human Correction

↓

Implementation

이 자연스럽다.

Agent가 Conversation Loop 안으로 들어오기 때문이다.

---

31. 이게 Prompt Engineering보다 중요한 변화일 수도 있다

혼자 Agent를 쓸 때:

Prompt 품질

이 중요하다.

팀 Agent에서는:

Context 품질

+

Feedback 속도

+

Decision Visibility

가 더 중요해질 수 있다.

완벽한 500줄 Prompt 하나보다:

PM Context

Designer Feedback

Developer Constraint

QA Evidence

가 같은 공간에 존재하는 것이 더 좋은 결과를 만들 수 있다.

---

32. Agent에게도 “회의 참석”과 비슷한 효과가 생긴다

기존 Agent는 개발자에게 전달받은 정보만 안다.

Team
 ↓
Developer
 ↓
Agent

Slack Code에서는:

Team Conversation
       │
       ▼
      Agent

가 된다.

물론 Agent가 모든 Slack 데이터를 무제한으로 읽는다는 뜻은 아니다.

Agent가 접근할 수 있는 범위는 Slack App의 권한과 Channel 접근 범위에 따라 결정된다.

---

33. 그래서 보안에서는 Scope가 매우 중요하다

Slack에서 Agent를 추가할 때 가장 먼저 볼 것은:

이 Agent가 무엇을 할 수 있는가?

다.

Slack 공식 보안 가이드에서도 AI App이 사용할 수 있는 정보와 행동은 App Scope와 API Permission에 따라 달라진다고 설명한다.

예:

Messages Read

Files Read

Channel Access

External Service

Repository Access

등을 확인해야 한다.

---

34. Agent를 모든 Channel에 넣는 것도 좋은 방식이 아니다

예:

#company-secret

#security-incident

#hr-private

#production

에 Coding Agent를 무조건 추가하는 것은 피하는 것이 좋다.

추천은:

Agent

필요한 Channel에만 추가

이다.

Slack에서 Agent의 Channel 데이터 접근 역시 해당 App을 Conversation에 추가하는 방식과 연결된다.

---

35. Public과 Private Code Channel도 구분해서 쓴다

Code Channel은 Public 또는 Private으로 만들 수 있다.

예:

UI Prototype

→ Public

일반 Bug Fix

→ Team Public

Security Issue

→ Private

미공개 Product Feature

→ Private

정도로 정책을 정할 수 있다.

---

36. 팀에서도 Risk Tier를 만들어두면 편하다

예:

LOW

Documentation
UI Copy
Small Style Fix

MEDIUM

Business Logic
API
Database

HIGH

Authentication
Payment
Security
Production

그리고 Code Channel 운영 규칙을 다르게 한다.

---

37. Low Risk

Agent 구현

↓

Developer Review

↓

CI

↓

Merge

---

38. Medium Risk

Agent Plan

↓

Developer 승인

↓

구현

↓

CI

↓

Reviewer

---

39. High Risk

Agent Investigation

↓

Human Architecture Decision

↓

Agent Implementation

↓

Security Review

↓

CI

↓

Human Approval

Slack Code라고 모든 권한을 Agent에게 주는 것이 아니다.

---

40. 팀용 Prompt Template을 만들어두면 더 좋아진다

매번:

알아서 해줘.

라고 하지 않는다.

예:

이 Code Channel의 대화를 Context로 사용해.

작업 순서:

1. 요구사항 정리
2. Repository에서 관련 코드 확인
3. 영향을 받는 영역 보고
4. 구현 계획 작성
5. 사람 승인 대기
6. 승인 후 구현
7. 필요한 Test 생성
8. 변경사항 요약

주의:

- 외부 Dependency를 임의로 추가하지 마.
- Public API 변경이 필요하면 먼저 보고해.
- 실제 실행하지 않은 Test를 통과했다고 말하지 마.

이 정도만 있어도 팀 Workflow가 안정적이다.

---

41. Repository Policy와 Slack Prompt는 분리한다

Slack에 모든 Architecture Rule을 적을 필요는 없다.

Repository:

AGENTS.md

Architecture
Naming
Dependency
Testing

Slack Code:

현재 Goal

Product Context

이번 Task의 Constraint

로 나눈다.

Agent는 두 Context를 함께 사용한다.

---

42. 가장 좋은 구조는 이렇다

Repository

Stable Context
─────────────────
Architecture
Coding Rule
Test Policy

+

Slack Code

Dynamic Context
─────────────────
요구사항
팀 대화
제품 결정
현재 이슈

↓

AI Agent

Stable Context와 Dynamic Context를 분리하는 것이다.

---

43. Slack 대화를 전부 Agent Context에 넣는 것도 좋지 않다

Channel에는 Noise가 많을 수 있다.

농담

과거 이슈

관련 없는 기능

이미 폐기된 결정

그래서 중요한 결정은 명확하게 표시한다.

예:

결정:

이번 수정에서는 API Contract를 변경하지 않는다.

또는:

Acceptance Criteria:

1. 느린 네트워크에서도 중복 결제 없음
2. Background 복귀 후 Session 유지
3. 기존 Payment API 변경 없음

Agent에게 Context가 훨씬 명확해진다.

---

44. Slack Canvas와 같이 쓰기도 좋다

Code Channel Artifact에는 Canvas가 포함될 수 있다.

예를 들어 Agent가:

Implementation Plan

Risk

Affected Files

Test Cases

를 Canvas로 만들게 할 수 있다.

팀은 Code Diff와 별도로 설계 요약을 본다.

---

45. 추천 Artifact 구성

큰 Feature라면:

PLAN

CODE

PREVIEW

VALIDATION

네 가지를 분리하면 좋다.

---

46. PLAN

Goal

Affected Modules

Architecture

Risk

Test Strategy

---

47. CODE

실제 Diff.

Files Added

Files Changed

Dependencies

---

48. PREVIEW

UI 작업이라면:

HTML

Screenshot

Prototype

---

49. VALIDATION

Slack 메시지가 아니라 실제 도구 결과를 연결한다.

CI Run

Unit Test

Lint

Build

Security Scan

이다.

---

50. 비개발자에게는 Preview와 Goal만 보여주면 된다

PM이나 Designer에게:

43개 파일 Diff

를 읽게 할 이유는 없다.

Role별로 보는 Artifact가 달라야 한다.

PM

Goal / Behavior

Designer

Preview

Developer

Diff / Architecture

QA

Acceptance Criteria / Test

Security

Dependency / Permission

이다.

이것이 진짜 Human + AI Team에 가깝다.

---

51. 현재 어떤 Agent를 사용할 수 있을까

2026년 8월 24일 기준 Slack 공식 Help 문서에서 Slack Code Code Channel을 지원하는 Agent는 다음과 같다.

Claude — Anthropic

Devin — Cognition

GitHub Copilot

Vercel

Slack의 발표에는 OpenAI도 Launch Partner로 포함됐지만 현재 공식 Availability에는 OpenAI/ChatGPT는 곧 제공 예정으로 명시돼 있다.

따라서 현시점에:

Slack Code에서
@codex로 Code Channel을
바로 만들 수 있다.

고 단정하면 안 된다.

---

52. 다만 Slack과 Coding Agent의 연결 범위는 더 넓다

Slack은 이전부터:

Claude Code

Codex

Cursor

GitHub Copilot

등 Coding Agent와 Slack의 연결 사례를 공개해왔다.

즉:

Coding Agent in Slack

이라는 큰 흐름과

Slack Code의 현재
공식 Code Channel 지원 Agent

는 구분해서 보는 것이 정확하다.

---

53. Agents & tools도 중요한 변화다

Agent가 늘어나면 또 다른 문제가 생긴다.

Agent DM

Agent Thread

Code Channel

Slackbot

다른 Agent

가 흩어진다.

Slack은 이를 위해 Agents & tools를 새로운 Agent 중심 Landing Page로 만들고 있다.

여기에서:

Agent 발견

Agent Session

Code Channel

현재 상태

를 확인한다.

---

54. 결국 Slack 자체가 Agent Control Surface로 변하는 셈이다

기존 Slack:

People
  ↕
People

지금:

People
  ↕
People

+

People
  ↕
Agents

다음:

Human Team
    │
    ▼
Slack
    │
    ├─ Agent
    ├─ Agent
    └─ Agent

로 갈 수 있다.

Slack이 Agent를 또 하나의 Sidebar 도구가 아니라 Workspace의 참여자로 넣으려는 이유다.

---

55. 그렇다면 IDE는 중요하지 않아지는가

그렇지 않다.

개발자가 실제로 깊은 코드를 확인할 때는 여전히:

Xcode

Android Studio

VS Code

Cursor

Terminal

이 더 좋다.

Slack Code의 역할은 IDE를 대체하는 것이 아니다.

IDE

Individual Deep Work

Slack Code

Shared Agent Work

라고 나누는 편이 정확하다.

---

56. 개발자 혼자 하는 Debug까지 전부 Slack에서 할 필요도 없다

예를 들어:

Compiler Error 하나 수정

함수 Rename

작은 Unit Test

까지 Code Channel로 만들면 오히려 복잡하다.

개인 Agent Session이 더 빠르다.

반대로:

여러 역할의 의견이 필요함

Product Context가 중요함

Agent가 오래 작업함

여러 단계의 Review가 필요함

결과를 팀이 같이 봐야 함

이면 Code Channel이 잘 맞는다.

---

57. 그래서 Agent 작업을 두 종류로 나누면 좋다

SOLO AGENT TASK

개인 작업.

MULTIPLAYER AGENT TASK

팀 작업.

---

58. Solo Agent Task

Small Refactor

Local Debug

Code Explanation

Test 하나 추가

반복 작업

↓

IDE / Terminal

---

59. Multiplayer Agent Task

Feature

Product Bug

Prototype

Cross-team Change

UX 변경

Architecture 논의

↓

Slack Code

이 정도가 실용적이다.

---

60. Team Workflow를 하나 정해두면 좋다

예를 들어:

DISCUSS

↓

START CODE CHANNEL

↓

PLAN

↓

HUMAN CHECK

↓

IMPLEMENT

↓

TEAM FEEDBACK

↓

PR

↓

CI

↓

HUMAN MERGE

이다.

Agent가 들어왔다고 기존 Software Engineering Discipline이 사라지는 것이 아니다.

---

61. 오히려 Human Gate가 더 중요해질 수 있다

Agent는 코드를 만드는 속도가 빠르다.

그래서 잘못된 방향으로 가는 속도도 빠르다.

팀원이 중간에 개입할 수 있다는 점은 Slack Code의 중요한 장점이다.

PM

요구사항 수정

Developer

Architecture 제한

Designer

UI Feedback

QA

재현 조건 추가

가 구현 완료 후가 아니라 작업 중간에 들어갈 수 있다.

---

62. 개발자가 Agent의 Prompt Manager가 되는 구조도 피할 수 있다

나쁜 AI 팀 구조:

PM
   ↓
Developer
   ↓
Agent
   ↓
Developer
   ↓
PM

개발자가 계속 Relay 역할을 한다.

좋은 구조:

        PM
         │
Designer ─┼─ Developer
         │
        QA
         │
         ▼
      Agent

단 개발자는 여전히 Architecture와 Engineering 품질에 책임을 가진다.

---

63. 이것이 개발자를 없애는 구조는 아니다

오히려 개발자의 역할이:

Prompt 전달

에서:

Architecture

Constraint

Risk

Integration

Verification

Review

로 이동한다.

Code Generation을 Agent가 담당해도 Software Engineering 판단은 그대로 필요하다.

---

64. Slack Code를 팀에 처음 도입한다면 이렇게 시작하는 편이 좋다

처음부터 모든 Feature를 Agent에게 맡기지 않는다.

1단계

작은 Product Bug

하나를 고른다.

---

2단계

PM + Developer + QA만 참여한다.

---

3단계

Agent에게 먼저 Plan만 요청한다.

---

4단계

사람이 Plan을 수정한다.

---

5단계

구현하게 한다.

---

6단계

Code Artifact와 Preview를 Review한다.

---

7단계

PR + CI로 넘긴다.

이 과정을 몇 번 반복한다.

---

65. 반복되는 문제가 보이면 팀 규칙으로 만든다

예:

Agent가 계속 외부 Package를 추가한다.

그때마다:

이번에는 Package 추가하지 마.

라고 하지 않는다.

Repository Policy에:

새 외부 Dependency는
사람 승인 없이 추가하지 않는다.

를 넣는다.

---

66. Slack Code 전용 팀 규칙도 만들 수 있다

예:

# Code Channel Rules

1. Agent에게 구현 전에 Plan을 요청한다.

2. Public API 변경은
   Developer 승인 후 진행한다.

3. External Dependency 추가는
   별도 승인한다.

4. Payment / Auth 변경은
   Security Reviewer를 추가한다.

5. 테스트 통과 여부는
   CI 결과를 기준으로 판단한다.

6. 최종 Merge는 사람이 한다.

팀 Agent Workflow가 훨씬 일관된다.

---

67. 이것이 중요한 이유는 Agent 수가 늘어나기 때문이다

Agent가 하나라면:

Developer
 ↓
Agent

로 충분하다.

하지만 앞으로:

Coding Agent

Design Agent

QA Agent

Security Agent

Release Agent

가 생기면 사람도 어떤 Agent가 무엇을 하고 있는지 관리하기 어려워진다.

Slack이 Code Channel과 Agents & tools를 만드는 방향은 이런 미래와 잘 맞는다.

---

68. 결국 Channel이 새로운 Agent Workspace가 될 수 있다

지금까지 Agent Workspace는:

Terminal Session

Browser Tab

IDE Chat

이었다.

Slack Code가 제안하는 Workspace는:

Conversation

+

People

+

Agent

+

Artifact

+

Feedback

+

History

다.

단순 Chat UI보다 훨씬 넓은 개념이다.

---

69. 특히 원격 팀에서는 더 의미가 있다

같은 사무실이라면 Agent 작업을 옆자리 개발자에게 바로 보여줄 수 있다.

Remote Team에서는 그렇지 않다.

Slack Code라면:

서울 개발자

미국 PM

유럽 Designer

AI Agent

가 같은 Task Space에 들어올 수 있다.

Agent가 비동기 협업의 또 하나의 참여자가 된다.

---

70. 가장 큰 변화는 “Prompt가 팀 자산이 된다”는 것이다

개인 Agent Session의 Prompt는 대부분 사라진다.

좋은 Architecture 설명이나 중요한 Product Context가 있었어도 개인 Session에 묻힌다.

Code Channel에서는:

Requirement

Agent Prompt

Correction

Decision

Result

가 모두 팀 Context가 된다.

이건 생각보다 큰 차이다.

---

71. Agent에게 어떤 설명을 해야 결과가 좋아지는지도 공유된다

예를 들어 한 개발자가 발견한다.

Agent에게 바로 수정시키지 말고
먼저 Dependency Graph를 만들게 하면
결과가 더 좋다.

개인 Session이었다면 개인 노하우다.

Code Channel이라면 팀 전체가 본다.

다음 개발자가 같은 Pattern을 재사용할 수 있다.

---

72. 좋은 Workflow는 결국 Template이 된다

반복하다 보면:

Bug Investigation

Feature Implementation

Dependency Upgrade

UI Prototype

마다 좋은 Prompt 흐름이 생긴다.

예:

Bug Investigation

1. Reproduction
2. Evidence
3. Root Cause
4. Plan
5. Approval
6. Fix
7. Regression Test

이걸 팀 Template으로 만든다.

---

73. 그 순간 Agent 사용법이 개인 Skill에서 조직 시스템으로 바뀐다

처음:

AI 잘 쓰는 개발자 한 명

이었다.

이후:

팀 전체가 사용하는
Agent Workflow

가 된다.

이 차이가 중요하다.

AI 도입에서 가장 어려운 것은 모델을 구매하는 것이 아니라 좋은 사용법을 팀 전체에 확산시키는 것이기 때문이다.

---

74. Slack Code가 흥미로운 이유도 여기에 있다

Claude나 Copilot이 더 좋은 코드를 생성한다는 이야기가 아니다.

Slack Code의 변화는:

Agent Intelligence

보다

Agent Collaboration

에 가깝다.

Agent의 지능은 각 Agent 회사가 만든다.

Slack은 그 Agent가 사람과 어떻게 함께 일할지를 만들고 있다.

---

75. 그래서 Agent 시대 Collaboration Stack은 이런 모습이 될 수 있다

                    TEAM
                     │
                     ▼
                  Slack
                     │
              ┌──────┴──────┐
              ▼             ▼
         Conversation    Code Channel
                             │
                ┌────────────┼────────────┐
                ▼            ▼            ▼
              Human        Agent       Artifact
                │            │            │
                └────────────┼────────────┘
                             ▼
                            Git
                             │
                             ▼
                             CI
                             │
                             ▼
                         Human Gate
                             │
                             ▼
                           Merge

상당히 자연스러운 구조다.

---

76. Slack Code를 사용할 때 가장 피해야 하는 것

첫 번째:

모든 일을 Code Channel로 만들기

---

두 번째:

Agent가 말한 Build/Test 결과를
검증 없이 믿기

---

세 번째:

Agent를 모든 Channel에 추가

---

네 번째:

Team Context와 Secret을
구분하지 않기

---

다섯 번째:

Agent가 만든 PR을
사람 Review 없이 Merge

---

여섯 번째:

Slack을 Git이나 CI의
대체재로 사용

이다.

---

77. 추천 팀 구성은 의외로 단순하다

작은 팀이라면:

PM

Developer

QA

Agent

정도면 충분하다.

Designer가 필요한 Task에만 들어온다.

Security Reviewer가 필요한 Task에만 들어온다.

모든 사람을 모든 Code Channel에 초대할 필요는 없다.

---

78. Agent도 Task에 맞게 선택한다

Slack Code가 특정 Agent 하나를 표준으로 강제하는 구조는 아니다.

현재 공식 지원 Agent 범위 안에서도 각각 역할과 강점이 다르다.

중요한 것은:

우리 팀 최고의 Agent는 무엇인가?

보다:

이 Task에 어떤 Agent가 적합한가?

를 보는 것이다.

---

79. 앞으로 더 중요한 것은 Agent Switching보다 Context Portability일 수 있다

Agent A에서 시작한 팀 작업을 Agent B가 이어받아야 하는 상황도 생길 수 있다.

그때 개인 Session 안에만 Context가 있으면 어렵다.

하지만:

Code Channel

Requirement

Decision

Artifacts

Review

가 남아 있으면 다른 Agent가 들어와도 Context를 재구성하기 쉬워진다.

이 부분은 Slack Code의 현재 기능을 넘어선 향후 Agent Collaboration에 대한 Architecture 관점의 해석이다.

---

80. 결국 Multiplayer Agent의 핵심은 사람이 중심에 남는 것이다

Agent가 팀원이 된다고 해서:

AI가 프로젝트를 알아서 진행

하는 것이 목표는 아니다.

좋은 구조는:

Human

Direction

↓

Agent

Execution

↓

Human + Tools

Verification

이다.

Slack 역시 Slack Code를 소개하면서 Agent가 깊은 작업을 맡더라도 사람이 작업의 중심에서 함께 방향을 잡는 구조를 강조하고 있다.

---

81. 마무리

Coding Agent의 첫 번째 시대는 개인 생산성이었다.

Developer

+

AI

였다.

좋은 Prompt를 만들고,

Agent에게 Repository를 설명하고,

많은 코드를 만들었다.

하지만 Software는 원래 혼자 만드는 일이 아니다.

실제 제품에서는:

PM

Designer

Developer

QA

Security

Reviewer

가 서로 다른 Context를 가지고 있다.

Agent가 개발자 개인 Terminal 안에만 존재하면 이 Context를 모두 개발자가 전달해야 한다.

그래서 AI가 빨라져도 새로운 병목이 생긴다.

Team

↓

Developer

↓

Agent

개발자가 사람과 Agent 사이의 Router가 되는 것이다.

Slack Code가 바꾸려는 것이 바로 이 구조다.

            PM
             │
Designer ─ Developer ─ QA
             │
             ▼
        Code Channel
             │
             ▼
            Agent

Agent가 팀 대화 안으로 들어온다.

사람들은 같은 공간에서:

Plan을 보고

잘못된 전제를 수정하고

Preview를 보고

코드에 Comment하고

Agent를 중지하고

방향을 다시 잡는다.

그리고 결과는 다시:

Git

CI

Human Review

라는 기존 Software Engineering Pipeline으로 넘긴다.

따라서 Slack Code를 가장 잘 사용하는 방법은 Slack 안에서 개발을 전부 끝내는 것이 아니다.

오히려:

Slack Code

Shared Intent
Shared Context
Shared Agent Work

를 담당하고,

Repository

Source of Truth

CI

Verification

Human

Final Decision

을 담당하게 만드는 것이다.

한 문장으로 정리하면 이렇다.

AI Coding의 다음 단계는 Agent를 더 많이 띄우는 것이 아니라, 사람과 Agent가 같은 Context를 보고 함께 방향을 잡는 Multiplayer Development다.

개발자 한 명이 Agent에게 일을 시키고 결과를 팀에 전달하던 방식에서,

팀이 같이 문제를 정의하고

Agent가 작업하고

팀이 중간에 방향을 수정하고

도구가 결과를 검증하고

사람이 최종 승인하는 구조

로 넘어가는 것.

Slack Code는 그 변화를 꽤 명확하게 보여주는 제품이다.

---

참고 자료

• Slack — Slack Code: Where Your Team and Agents Build Together
  2026년 8월 20일 공개된 Slack Code 공식 발표. 개인 Agent Session을 Code Channel이라는 공유 작업 공간으로 옮기고 사람과 Agent가 Plan·Code·Review를 함께 수행하는 방향을 설명한다.
• Slack Help — Build with AI as a team using Slack Code
  Code Channel 생성, Public/Private 설정, Agent 상태, Artifacts, Code Diff Comment, Stop 기능, Quick Action, Archive와 현재 지원 Agent 등 실제 사용법을 설명하는 공식 문서.
• Slack Help — Work with AI agents in Slack
  Agent를 Channel에 추가하고 Mention하는 방법, Agents & tools, App Scope 및 AI App의 데이터 접근 범위 등 일반적인 Agent 운영 방식을 설명한다.
• Slack — The Rise of Software Engineering Agents in Slack
  Claude Code·Codex·Cursor·GitHub Copilot 등 Coding Agent가 Slack의 Shared Context를 활용하는 전체 Agentic Engineering 방향을 설명한다.
• Slack — Slack updates and changes, August 2026
  Slack Code와 함께 새 Agents & tools Landing Page, Agent Message와 Reasoning 표현 개선, Named Thread, Native Stop Button 등 2026년 8월 Agent UX 변경사항을 확인할 수 있다.

핵심 참고 포인트

2026년 8월 24일 현재 Slack Code는 Claude, Devin, GitHub Copilot, Vercel을 Code Channel 지원 Agent로 명시하고 있다. 발표에는 OpenAI도 파트너로 참여했지만 Slack 공식 발표 기준 OpenAI/ChatGPT의 Code Channel 지원은 아직 향후 제공 예정이다. 따라서 Slack의 일반적인 Codex 연동과 Slack Code의 현재 지원 Agent 범위는 구분해서 보는 것이 정확하다.

Code Channel은 일반 Thread를 대체하는 영구 채널이 아니라 사람과 Agent가 하나의 비교적 큰 Task를 함께 처리하는 임시 작업 공간이다. 사람을 추가하고, Public/Private 범위를 정하고, Code·Canvas·HTML·Files 같은 Artifact를 확인하며 Code Diff에 직접 Comment할 수 있다. Agent가 길게 작업할 때는 Working, Needs attention, Done 같은 상태도 확인할 수 있다.

실무적으로는 Slack Code를 Git·CI 대신 사용하는 것보다 Slack = Shared Context와 Collaboration, Git = Source of Truth, CI = Deterministic Validation, Human = Final Approval로 역할을 분리하는 것이 가장 안정적이다. Agent를 팀 대화 안으로 가져오되 Software Engineering의 기존 검증 체계를 그대로 유지하는 것이 핵심이다.