Slack의 Code API는 점점 커지는 문제를 해결하기 위한 실질적인 시도입니다. 자율 코딩 에이전트가 비공개 세션에서 작업한 뒤 무엇이, 왜 바뀌었는지 팀은 알 수 없게 되는 문제입니다. 에이전트를 일반 DM이나 비좁은 스레드에 억지로 끼워 넣는 대신, Code API는 에이전트가 필요한 담당자와 프로젝트 맥락, 작업 자료를 한데 모을 수 있는 전용 코드 채널을 만듭니다. 에이전트가 사람과 같은 협업 공간에서 공개적으로 작업하게 되면 팀이 자동화된 작업을 검토하고 승인하며 그 과정에서 배우는 방식도 달라집니다.
기술적으로 이 API는 채널 생성, 멤버 관리, 북마크, 코드 변경 사항(diff), 실행 업데이트, 보관을 위한 기본 기능을 제공합니다. 에이전트는 채널 이름을 지정하고 코드 미리 보기나 diff를 공유하며 로그와 테스트 결과를 첨부하고, 팀원들이 질문을 던질 수 있도록 단계별 계획을 게시할 수 있습니다. 또한 Slack은 에이전트의 작업에 워크스페이스 권한과 규정 준수 제어를 적용하므로 사람에게 적용되는 접근 규칙과 메시지 관리 정책이 에이전트에도 동일하게 적용됩니다. 이런 설계는 검색 가능한 감사 기록을 유지하면서 IT 부서가 관리해야 할 통합 지점을 줄여 줍니다.
초기 사용 현황에서 주목할 만한 점은 GitHub Copilot이 에이전트 세션의 약 30%에서 전용 코드 채널을 여는 것으로 알려졌다는 것입니다. 이는 에이전트 작업 중 상당수가 간단한 답변이 아니라 팀과 관련된 독립적인 작업 단위임을 시사합니다. 플랫폼 및 개발 도구 팀은 코드 채널을 승인 절차를 한곳에 모으고, 맥락을 공유하며, 조직의 지식을 되살리는 공간으로 활용할 수 있습니다. 제품 및 운영 책임자에게는 사람의 개입을 포함한 에이전트 거버넌스와 분산형 코드 소유권을 실제 환경에서 시험하는 기회가 됩니다.
하지만 에이전트 작업을 공개한다고 모든 문제가 해결되는 것은 아닙니다. 에이전트의 실행 과정을 공유 가능한 자료로 만들면 개발자 경험이 달라지고, 불필요한 정보가 쌓일 수 있으며, 채널이 복잡해지지 않고 유용하도록 세심한 UX 설계가 필요합니다. 공급업체와의 통합 방식도 바뀝니다. 마켓플레이스, 모델 제공업체, CI/CD 도구는 이제 여러 사람이 함께하는 워크플로를 고려해야 합니다. 팀이 실무적으로 따져 볼 점은 검토 주기 단축, 지식 공유, 책임 소재 명확화의 이점이 에이전트의 중간 결과물을 더 많이 공개하는 데 따르는 비용보다 큰지 여부입니다.