코딩 에이전트는 보통 개인 IDE나 브라우저 탭에서 시작한다. 요청을 보낸 사람만 진행 상황과 프롬프트를 보고, 결과가 PR로 올라온 뒤에야 팀이 맥락을 따라잡는 경우가 많다. Slack은 8월 20일 작업별 전용 코드 채널을 만드는 Slack Code를 공개했고, GitHub는 다음 날 Slack 안에서 Copilot cloud agent를 쓰는 기능을 공개 미리보기로 내놓았다. 이제 대화에서 나온 문제를 그 자리에서 에이전트 작업으로 넘기고, 팀이 같은 채널에서 계획과 결과를 살필 수 있게 됐다.
이 변화는 단순히 Slack에 봇 하나가 추가된 일이 아니다. 에이전트가 읽는 맥락, 코드를 바꿀 수 있는 사람, 리뷰가 필요한 지점을 협업 도구의 규칙과 함께 다루게 된다는 뜻에 가깝다. 개인 자동화를 팀 자동화로 넓힐 때 무엇을 먼저 확인해야 하는지 살펴볼 만하다.
대화가 곧 작업 입력이 되는 구조
GitHub 문서에 따르면 Slack의 메시지, 스레드, DM에서 @GitHub를 호출해 cloud agent 세션을 시작할 수 있다. 에이전트는 대화 맥락을 이용해 조사, 계획, 코드 작성, 이슈와 PR 생성을 수행한다. GitHub는 이 작업이 보안 클라우드 샌드박스에서 비동기로 진행된다고 설명한다.
여기서 가장 중요한 제약은 스레드 전체가 입력이 된다는 점이다. GitHub 문서는 에이전트가 대화의 모든 메시지를 작업 판단에 사용하며, 그 맥락이 생성 산출물에 저장된다고 명시한다. 채널에서 자연스럽게 오가는 고객 정보, 내부 URL, 임시 접근 방법을 평소 대화처럼 적어 두었다면 에이전트 호출 순간에 의도치 않게 작업 재료가 될 수 있다.
따라서 편한 채널이라고 해서 바로 호출하기보다, 이 스레드가 에이전트에 전달해도 되는 맥락인지 먼저 묻는 절차가 필요하다. 맥락을 좁혀야 한다면 새 스레드를 열거나 GitHub 앱과의 DM을 쓰는 방법이 있다. 다만 DM은 개인 계정과 연결된 권한으로 이슈나 PR 같은 작업을 수행할 수 있으므로, 공개 채널보다 안전하다고 단정할 수는 없다.
공동 세션에서는 누가 실행하고 누가 조종하는가
공유 스레드나 채널에서 시작한 Copilot 세션은 개인 계정이 아니라 Copilot 앱의 정체성으로 PR 같은 산출물을 만든다. 반면 연결된 개인 계정 권한으로 동작하는 DM 세션도 있다. GitHub는 저장소에 쓰기 권한이 있는 사람만 변경 작업을 시작할 수 있고, 대화 참가자는 누구나 작업에 의견을 더할 수 있다고 안내한다. 외부 협업자와 게스트는 Slack에서 세션을 시작하거나 조종할 수 없다.
이 구분은 책임을 모호하게 만들 수도, 더 선명하게 만들 수도 있다. 공유 세션의 산출물이 앱 정체성으로 남으면 누가 요청을 시작했고 누가 검토했는지 PR과 대화 링크를 함께 남길 수 있다. 반대로 팀이 앱 계정을 사람 계정과 똑같이 신뢰하면 자동화의 출처만 바뀔 뿐 검토 공백은 남는다.
GitHub의 설명처럼 저장소 규칙이 이미 최소 한 건의 승인을 요구하는 경우, 공유 맥락에서 Copilot이 만든 PR에는 추가 승인이 기본으로 요구된다. 이 동작은 사람 검토를 대신하지 않는다. 하지만 에이전트 산출물에 대해 기존 보호 규칙을 유지할 수 있는 출발점은 된다. 실제 도입 전에는 작은 저장소에서 앱 정체성 PR이 어떤 규칙을 통과하거나 막히는지 확인하는 편이 낫다.
채널 하나에 작업 하나를 두는 이유
Slack Code는 에이전트 작업마다 전용 코드 채널을 만들고, 계획, 변경 사항, 미리보기, 상태를 그 안에 모으는 방식이다. GitHub 문서에서는 채널 하나가 한 번에 하나의 세션을 위한 공간이며, 완료 뒤 보관하더라도 기록은 검색과 열람이 가능하다고 설명한다. 원래 대화는 요구사항을 나눈 곳으로 남기고, 실행 중인 작업만 별도 공간으로 옮기는 구조다.
이 분리는 운영상 꽤 실용적이다. 여러 요청을 하나의 긴 스레드에 섞으면 에이전트가 어느 요구가 현재 우선인지 잘못 해석할 가능성이 커진다. 반대로 전용 채널 안에 대상 저장소, 브랜치, 완료 조건, 하지 말아야 할 변경을 짧게 적으면 사람에게도 작업 경계가 보인다. Slack은 자사 사용 사례에서 코드 채널의 70% 이상이 하루 안에 열리고 닫힌다고 밝혔지만, 이것은 Slack이 제시한 운영 수치일 뿐 모든 조직의 생산성 효과로 일반화할 근거는 아니다.
도입 전에 정해 둘 세 가지
첫째, 호출 가능한 대화의 기준을 정한다. 고객 데이터, 비밀값, 보안 사고 조사처럼 맥락 자체가 민감한 대화는 에이전트 호출 대상에서 제외하거나 별도 승인 절차를 둔다. 코드 채널을 만들기 전에 스레드 전체가 전달된다는 사실을 팀에 알려야 한다.
둘째, 시작 권한과 조종 권한을 구분해 본다. 쓰기 권한자는 세션 시작을 맡고, 기획자나 QA 담당자는 공유 채널에서 요구사항과 검증 기준을 보태는 방식이 가능하다. 이때 누가 최종 완료를 선언하는지까지 정해 두면, 많은 사람이 참여해도 책임이 흐려지지 않는다.
셋째, 에이전트가 만든 PR에는 기존보다 한 단계 분명한 검토 기준을 둔다. 테스트 실행 여부, 변경 파일 범위, 권한이나 의존성 변경 여부를 PR 템플릿이나 규칙으로 확인한다. 자동 생성된 설명만 읽고 병합하지 않도록, 원래 문제와 실제 diff가 맞는지도 사람이 확인해야 한다.
도구보다 작업 기록을 먼저 남길 시점
Slack Code와 Copilot 연동은 대화에서 코드까지 이어지는 시간을 줄일 수 있다. 동시에 대화가 입력 데이터가 되고, 앱 정체성이 산출물을 만들며, 작업 채널이 새로운 기록 단위가 된다. 이 흐름을 잘 쓰려면 에이전트에게 일을 더 많이 맡기는 것보다 어떤 대화를 넘길지, 누가 방향을 바꿀지, 어떤 PR을 멈출지를 먼저 합의해야 한다.
공개 미리보기 기능은 정책과 동작이 바뀔 수 있다. 그래서 처음부터 팀 전체 흐름을 바꾸기보다, 낮은 위험도의 버그 수정이나 문서 개선 한두 건으로 시작해 보길 권한다. 채널 기록과 PR 기록을 함께 돌아본 뒤에야 이 방식이 실제로 검토 시간을 줄였는지, 아니면 대화만 더 늘렸는지 판단할 수 있다.