슬랙 스레드에 @GitHub 한 줄이 붙는 순간, 그 대화는 더 이상 “알림 채널”이 아닙니다. 코딩 에이전트 세션의 입구가 됩니다.
핵심 한 줄: 2026-08-21 GitHub가 공개한 Slack 에이전틱 프리뷰(Slack Code 포함)를 켜기 전에, 쓰기 권한·클라우드 에이전트 정책·앱 신원 PR·추가 승인을 먼저 고정하세요. 편의 기능이 아니라 채팅 위 제어면입니다.
왜 중요한가
대부분의 팀은 이미 “이슈는 슬랙에서, 코드는 IDE/GitHub에서”로 나눕니다. 그 경계가 느슨해지면 생기는 실패 모드는 뻔합니다.
- 회의에서 나온 한 문장이 그대로 구현 지시가 된다.
- PR 작성자가 “나”가 아니라 Copilot 앱 신원이 된다.
- 예산·정책은 IDE에만 걸려 있고, 슬랙 경로는 비어 있다.
에이전트가 슬랙에서 계획을 세우고 diff를 보여 주며 코드를 밀어 넣는다면, 플랫폼 팀의 질문은 “신기한가”가 아니라 누가 깨울 수 있고, 무엇이 머지될 수 있는가입니다.
2026-08-21에 나온 것
GitHub Changelog(2026-08-21)에 따르면, Slack의 GitHub 연동이 Copilot CLI·Copilot 앱의 에이전틱 능력을 공개 프리뷰로 가져옵니다. @GitHub로 변경을 계획하고, 문제를 조사하고, 코딩 작업을 넘길 수 있습니다. GitHub는 에이전트용 채널 유형인 Slack Code의 런칭 파트너이기도 합니다.
Changelog·Docs가 그리는 흐름은 대략 이렇습니다.
- DM·채널·스레드에서
@GitHub로 세션 시작 - 대화 맥락 + 허용된 GitHub 컨텍스트로 조사·계획·구현
- Slack Code 채널에서 계획·diff·출력 미리보기(예: HTML 아티팩트)를 함께 보고 조향
- 원본 스레드에서 누구나 합류해 맥락 추가·방향 수정·세션 중단 가능
가용성: Copilot Business / Enterprise 조직. 사용량은 기존 Copilot entitlement에 잡히며, 기존 cloud agent 예산으로 관리할 수 있다고 명시되어 있습니다.
시작 조건(Changelog):
- 관리자가 Copilot cloud agent 정책을 켠다
- Slack용 GitHub 앱을 설치·업그레이드한다
- GitHub 계정을 연결한 뒤
@GitHub를 멘션한다
이전 Slack 연동·Teams와 비교
| 축 | 2025-10 Slack coding agent | 2026-08-21 Slack agentic + Slack Code | 2026-08-21 Teams shared agentic |
|---|---|---|---|
| 표면 | 스레드에서 PR 생성·백그라운드 작업 후 회신 | 협업 조향 + 전용 Code 채널 | 채널/스레드/DM에서 공유 세션 + code channel |
| 협업 | 주로 요청자 중심 | 스레드·Code 채널에서 다수가 조향 | 대화 참여자 모두가 질문·맥락·조향 가능 |
| 트리거 권한 | (당시 정책 기준) | Docs: write가 있어야 에이전트 작업 트리거; write 없는 사람은 컨텍스트 제공 | write 있는 사람만 변경 트리거; 나머지는 조향 |
| 거버넌스 포인트 | 정책 on/off | 앱 신원 PR + 추가 승인·예산 | cloud agent + cloud sandbox 정책/과금 분리 |
2025년 10월에도 Slack에서 Copilot coding agent로 PR을 만들 수 있었습니다. 이번 발표의 무게는 “슬랙에서 PR 가능” 자체가 아니라, 에이전트 루프를 팀이 같이 보는 Code 채널과 공유 컨텍스트에서의 신원·승인을 전면에 둔 점입니다.
같은 날 Teams changelog도 비슷한 문법입니다. @GitHub로 세션을 열고, 전용 code channel에서 진행을 보며, AI credit와 cloud sandbox 과금이 분리된다고 적혀 있습니다. 채팅 제품이 달라도 “대화 → 샌드박스 에이전트 → 아티팩트” 패턴은 수렴 중입니다.
신뢰 경계 체크리스트
Docs가 강조하는 사실을 운영 언어로 옮기면 아래와 같습니다.
-
트리거 = write
기본 저장소(또는 프롬프트에 지정한 저장소)에 write가 있어야 cloud agent가 실제로 작업합니다. write가 없어도 스레드에 의견을 남기면 컨텍스트로 쓰일 수 있습니다. “누구나 @하면 바로 푸시”가 아닙니다. -
공유 컨텍스트 PR = 앱 신원
그룹 DM·채널 같은 공유 맥락에서 만든 PR은 개인 계정이 아니라 Copilot 앱 신원으로 생성됩니다. -
추가 승인(기본 on)
ruleset으로 이미 승인 1개가 필요한 저장소라면, 사람 귀속이 아닌 Copilot PR에는 추가 승인 1개가 더 필요하다고 Docs에 명시되어 있으며, 기본 활성화입니다. Changelog도 저장소 관리자가 Copilot 앱 신원 PR에 추가 승인을 요구할 수 있다고 말합니다. -
정책·예산이 IDE 밖에 있는가
cloud agent 정책이 꺼져 있으면 슬랙 데모는 시작도 못 합니다. 켜져 있다면 예산이 슬랙 폭주를 막을 마지막 브레이크입니다.
처음 연동할 때 “스레드에서 바로 고쳐 줘”만 넣고 ruleset을 안 열어본 팀을 본 적이 있습니다. PR 작성자 칸에 앱이 뜨고 나서야, 승인 규칙이 사람 기준이라는 걸 깨달았습니다. 그다음부터는 슬랙 on 전에 ruleset 화면을 먼저 보는 버릇이 생겼습니다.
설정·프롬프트 예시
정책/승인 쪽은 UI·ruleset이 본체이고, 팀은 프롬프트 습관으로 반경을 줄입니다.
# Slack thread (writer only triggers work)
@GitHub Investigate flaky auth tests in org/api.
Scope: test/auth/** and CI workflow only.
Open a draft PR; do not merge. Summarize plan in the Code channel first.
저장소·브랜치를 명시하는 패턴(Docs 예시 문법에 맞춘 변형):
@GitHub Add a healthcheck endpoint in octo-org/octo-repo on branch=main.
Keep the change behind a feature flag. Stop after opening the PR.
플랫폼 체크리스트(문서화용):
## Slack → Copilot cloud agent gate
- [ ] Copilot Business/Enterprise + cloud agent policy ON
- [ ] GitHub Slack app installed/upgraded; accounts linked
- [ ] Default repo set; writers-only trigger understood by the team
- [ ] Rulesets: required reviews + Copilot app-identity extra approval verified
- [ ] Cloud agent budget alert configured
- [ ] “Stop the session” owner named in the Code channel
실무에서 쓰는 법
잘 맞는 작업
- 스탠드업에서 나온 “재현 가능한 작은 버그”
- 이미 합의된 문구/카피/문서 PR
- CI 실패 원인 조사 후 초안 PR까지
슬랙에 맡기지 말 것
- 시크릿·프로덕션 스키마·권한 모델 변경
- “대충 리팩터링해 줘”처럼 범위가 없는 요청
- write가 있는 인턴/외부 협력자가 아무 채널에서나 멘션하는 구조
운영 팁: 원본 스레드는 의도 합의, Code 채널은 실행 조향으로 역할을 나눕니다. 합의가 끝나기 전에 구현을 열면, 회의록이 PR이 됩니다.
시니어 엔지니어 관점
이 기능의 본질은 “슬랙이 IDE를 대체한다”가 아닙니다. 의도 수집 표면이 에이전트 루프에 붙는다는 쪽입니다.
그래서 설계 질문은 세 개로 줄어듭니다.
- 누가 깨우는가 (write + 정책)
- 무엇이 남는가 (앱 신원 PR, Code 채널 기록)
- 무엇이 멈추는가 (추가 승인, 예산, 세션 stop)
Slack Code 런칭 파트너 라인업(Anthropic, Cognition, GitHub, OpenAI, Vercel 등)을 보면, 채팅 벤더는 “에이전트 채널”을 공통 UX로 밀고 있습니다. 도구마다 UI는 다르지만, 거버넌스 체크리스트는 거의 같습니다.
Cursor에서 같이 쓰기
Cursor에 이미 클라우드 에이전트·구독형 웨이크가 있다면, 슬랙 연동은 대체재가 아니라 다른 입구입니다.
| 상황 | 추천 표면 |
|---|---|
| 레포 전체를 읽으며 긴 리팩터 / 테스트 루프 | Cursor (에디터·클라우드 에이전트) |
| 회의·장애 스레드에서 즉시 조사·초안 PR | Slack @GitHub → Code channel |
| 머지 직전 품질·스펙 정렬 | IDE/Cursor에서 사람이 최종 패스 |
Cursor에서 돌릴 때 팀에 남길 한 줄:
If the request started in Slack, open the PR diff locally in Cursor before approve.
Do not treat Code-channel green text as “reviewed.”
FAQ
Q. Individual/Pro만 있어도 쓰나요?
A. Changelog 기준 공개 프리뷰는 Business / Enterprise 조직입니다.
Q. write가 없으면 Mentions가 무시되나요?
A. Docs: write가 없으면 에이전트 작업 트리거는 못 하지만, 스레드 입력은 컨텍스트로 쓰일 수 있습니다.
Q. 내 이름으로 PR이 안 뜨면 버그인가요?
A. 공유 컨텍스트에서는 Copilot 앱 신원이 정상 동작입니다. ruleset의 추가 승인 규칙을 확인하세요.
Q. Teams와 뭐가 다르나요?
A. 같은 날 비슷한 공유 세션 모델입니다. Teams 쪽은 changelog에 cloud sandbox 과금 분리가 더 명시적으로 적혀 있습니다. 워크스페이스가 어디에 있느냐의 문제에 가깝습니다.
Q. 자동 머지까지 가나요?
A. 발표 내용은 계획·구현·PR·조향과 사람 승인 쪽에 무게가 있습니다. 추가 승인 옵션이 있는 이유가 그것입니다.
소스
- The new GitHub Copilot experience in Slack — GitHub Changelog (2026-08-21)
- Shared agentic work with GitHub Copilot in Microsoft Teams — GitHub Changelog (2026-08-21)
- Integrating Copilot cloud agent with Slack — GitHub Docs
- Using GitHub in Slack — GitHub Docs
- Slack Code: Where Your Team and Agents Build Together — Slack Blog
- Work with Copilot coding agent in Slack — GitHub Changelog (2025-10-28)
마무리
채팅에서 에이전트를 깨우는 UX는 앞으로 더 흔해질 겁니다. 남는 차별점은 모델 이름이 아니라, 깨우기 전에 걸어 둔 벽입니다. 오늘 프리뷰를 켠다면, 데모 스레드보다 ruleset·정책·예산 스크린샷을 먼저 팀에 공유하세요.