**서론**
최근 슬랙 코드라는 것을 보게 되었습니다. 이번에는 간단히 “그게 대체 뭔데요?”라는 질문으로 조사했습니다.
Slack Code는 슬랙이 2026년 8월 20일(미국 시간)에 발표한 것으로, Anthropic의 Claude, Cognition의 Devin, GitHub의 GitHub Copilot, Vercel의 에이전트와 함께 미국 OpenAI의 ChatGPT도 곧 지원될 예정입니다.
Slack 코드의 핵심은 “코드 채널”입니다.
Slack 코드의 작동 방식은 간단합니다. 대화 중에 코딩 에이전트에게 언급하면 해당 작업에 대한 전용 채널이 자동으로 생성되고 팀 멤버가 참여할 수 있습니다. 이 채널은 “코드 채널”이라고 불리며, Slack 공식은 “팀원들과 함께 AI 에이전트와 프로젝트를 진행하기 위한 전용 및 일시적인 공간”으로 정의하고 있습니다.
채널 내에는 에이전트와의 대화, 작업 계획, 코드의 차이점, 그리고 동작 미리보기 등이 묶음으로 표시됩니다. 작업이 끝나면 자동으로 아카이빙되어 기록은 감사 로그처럼 검색 가능 상태로 남아 있습니다. “끝나면 사라지는” 대신 “끝나면 정리되지만 나중에 추적할 수 있는” 방식으로 설계되었습니다.
생산할 수 있는 것은 코드에만 국한되지 않습니다. 웹 페이지 업데이트, 버그 수정, 신 기능 또는 프로토타입 제작 등이 예시로 언급되었으며, 코드뿐만 아니라 Canvas 문서나 HTML 형식의 자료 등도 결과물로 취급될 수 있습니다.
엔지니어 외 일반 사용자도 루프에 포함하는 설계를 의미한다.
흥미로운 점은 Slack Code가 예상하는 사용자 유형입니다. 개발자뿐만 아니라 제품 관리자나 디자이너를 개발 프로세스에 참여시키고, 터미널이나 개발 환경을 직접 조작하지 않아도 사용자 문제를 설명하고, 제품상의 배경을 보완하며, 결과물을 확인하고 수정 요청을 할 수 있습니다.
구체적인 과정은 다음과 같습니다. 예를 들어, 영업 담당자가 웹 페이지의 오타를 발견한 경우를 들 수 있습니다. 슬랙에서 담당 에이전트에게 수정 요청을 하고, 자동 생성된 코드 채널로 담당자를 불러와 AI가 제시한 변경 사항과 미리보기를 확인한 후, 엔지니어의 안전성 및 영향 범위 검토를 거쳐 문제가 없으면 다음 개발 단계로 진행합니다. 다만, 이는 AI 에이전트를 최종 의사 결정자로 하는 것이 아니라, AI의 작업이 어디에서 이루어지고 어떤 변경 사항이 제안되는지, 더 많은 관계자들이 확인하기 쉽도록 하는 시스템이라는 점을 명시하고 있습니다. 에이전트에게 맡기는 것이 아니라, 단순히 ‘시각화’가 목표라는 점으로 정리됩니다.
비용의 함정
요금 측면에서는 주의가 필요합니다. 어떤 Slack 플랜을 사용하든 가능하지만, 각 파트너의 에이전트 이용권은 별도로 필요합니다. 즉, Slack 측의 추가 요금은 없더라도 Claude, Devin, GitHub Copilot, Vercel의 에이전트를 실제로 작동시키려면 각각 별도의 계약이 필요합니다. Claude 등에는 각각 별도 계약이 필요하며, 필요한 플랜도 다르기 때문에 “Slack Code는 무료”라는 제목만으로는 실질적인 도입 비용을 제대로 파악하지 못할 수 있습니다.
참고로 Slack에서 Claude를 이용하는 경우, Slack 내의 @Claude 사용이 2026년 8월 3일에 레거시 Slack 앱에서 Claude Tag로 통합된 이력이 있으며, Slack Code에서의 이용 또한 이 새로운 사용 방법이 전제되고 있습니다.
배경에 있는 기술 기반과 사내 실적
Slack 코드라는 UI의 기반 기술은 슬랙이 2026년 상반기부터 단계적으로 구축해 온 MCP 서버와 에이전트 플랫폼 위에 구축되어 있다는 설명이 있었습니다.
내부 측정값도 공개되어 있으며, 코드 채널의 70% 이상이 아이디어부터 PR 병합까지 1일 이내에 종료된다고 합니다 (2026년 8월 기준).
발표 시 언급된 코멘트와 입장을 정리합니다.
발표에 앞서 슬랙 임시 CEO 로브 시먼 氏は、향후 개발에 있어 제약은 “코드 자체”가 아닌 아이디어, 선호도, 판단, 그리고 제작 부분으로 옮겨갈 것이라는 취지의 발언을 남겼습니다. 코드 작성 속도가 병목 현상이었던 시대부터 무엇을 만들어야 할지를 판단하는 속도가 병목 현상되는 시대에 접어들도록 하는 것을 의식한 발언으로 해석했습니다.
경쟁사와의 관계를 설명하자면, Slack에서 코딩 에이전트를 호출하는 자체 기능은 이미 선례가 존재합니다. Anysphere의 Cursor는 2025년부터 "@Cursor"으로 멘션하면 스레드의 문맥을 읽고 작업하며 GitHub에 풀 리퀘스트를 생성하는 연동 기능을 제공합니다. OpenAI 또한 "Codex"를 통해 Slack에서 작업을 시작할 수 있도록 지원합니다. Microsoft는 2026년 6월 Microsoft Build 2026에서 Teams의 채팅이나 채널 내에서 GitHub Copilot, Cursor, Linear, Atlassian의 Rovo와 같은 에이전트가 대화의 문맥을 따라 작업하는 기능을 발표했습니다. 업무 채팅을 AI 에이전트의 실행 장소로 활용하는 흐름은 Slack Code 단일 움직임이라는 관점보다 업계 전체의 트렌드라는 시각으로 해석하는 것이 적절합니다.
알려주신 정보가 부족하여 번역할 일본어 게시글의 본문 청크 20/25 내용을 제공해주셔야 합니다. 해당 내용을 알려주시면 100% 한국어 번역본을 제공해 드리겠습니다.
좋은 점만 있는 것은 아닙니다. 현재 시점에서는 GitHub의 풀 리퀘스트 리뷰를 완전히 대체할 수 없으며, 코드 라인에 대한 주석이 영구적으로 유지되지 않는 등 리뷰 기록 측면에서는 약하다는 지적이 있습니다. 꼼꼼한 코드 리뷰 문화를 가진 팀의 경우에는 기존 PR 리뷰 흐름과 병행하는 방식으로 고려하는 것이 더 적절할 것입니다.
규정 준수 측면의 우려도 제기되었습니다. 엔지니어 외의 사람이 코드에 접근하여 에이전트를 호출할 수 있게 된다는 것은 강력한 기능이지만 동시에 위험을 수반하며, 프로덕션 환경에 대한 인간 승인 게이트는 도움이 되겠지만, 누가 어떤 채널에서 에이전트를 태그할 수 있는지는 정책상의 결정 사항으로 규정되어 있습니다. 이는 저 또한 동의하는 부분으로, “누구나 에이전트를 호출할 수 있다”는 것과 “누구나 프로덕션에 영향을 줄 수 있다”는 것은 별개의 문제로서, 권한 설계를 처음부터 고려해야 합니다.
마무리하며
Slack 코드를 보면서 느낀 것은, 이것이 새로운 코드 생성 AI의 발표가 아니라 “AI 에이전트의 작업을 인간에게 언제 보여줄 것인가”라는 즉, Human in the Loop의 인터페이스 설계에 관한 이야기라는 점입니다. 이전에 이 note에서 LLMOps와 HITL의 역할 분담에 대해 언급했었지만, Slack Code는 바로 그 “HITL을 어디에 배치할 것인가”라는 논점에 Slack이라는 채팅 툴의 관점에서 하나의 해결책을 제시한 사례라고 생각합니다.
에이전트의 능력 자체는 Claude나 Devin과 같은 기존의 것을 활용하는 설계로 되어 있기 때문에, Slack Code의 가치는 “모델의 지능”이 아닌 “팀의 워크플로우에 어떻게 통합할 수 있는가”에 있습니다. 앞으로 유사한 “에이전트 작업의 시각화 레이어”가 다른 챗봇이나 프로젝트 관리 툴에도 확산될지 주목해 볼 필요가 있습니다.
출처: note 원문
번역: Gemma 3(.44) 초벌 + 교정 15청크
원문 보기 | 출처: note.com