에이전트가 짠 코드를 아무도 안 보는 게 진짜 문제였어

슬랙이 8월 21일 **'슬랙 코드(Slack Code)'**를 공개했어. AI 코딩 에이전트를 팀 채널 안으로 직접 불러들이는 기능이야.

동작은 단순해. 대화 중에 에이전트를 태그하면 프로젝트 전용 코드 채널이 즉시 생성돼. 그 채널 안에서 에이전트가 작업하는 동안 팀원들은 같은 화면을 봐. 제안된 변경사항의 코드 diff, HTML 결과물의 실시간 미리보기, 그리고 에이전트가 세운 진행 계획이 탭으로 노출돼. 중간에 피드백을 남기면 에이전트가 반영하고, 다 되면 승인해. 작업이 끝나면 그 채널은 검색 가능한 기록으로 보관돼.

참여 파트너는 앤스로픽의 클로드 코드, 코그니션의 데빈, 깃허브 코파일럿, 버셀의 에이전트야. 오픈AI의 챗GPT도 창립 파트너로 이름을 올렸어. 모든 슬랙 요금제에서 기본 제공되지만, 각 파트너 에이전트에 대한 접근 권한은 사용자가 따로 갖고 있어야 해.

기능 목록만 보면 통합 하나 추가된 것 같아. 그런데 이 발표가 겨냥한 문제는 기능이 아니야. AI가 짠 코드를 아무도 제대로 보지 않는다는 것이야.

등장인물 정리 — 터미널의 고립, 그리고 슬랙의 계산

지금 코딩 에이전트는 대부분 터미널이나 IDE 안에서 돌아가. 클로드 코드도, 코덱스도, 커서도 그래. 이 구조에는 명확한 장점이 있어. 파일 시스템에 직접 접근하고, 명령을 실행하고, 결과를 보고 다시 고칠 수 있어. 개발자 한 명의 생산성 관점에서는 이보다 나은 배치가 없어.

문제는 그 다음이야. 에이전트가 몇 시간 동안 뭘 했는지는 그 개발자의 터미널 스크롤백에만 남아. 팀원은 결과물인 PR만 봐. 어떤 판단을 왜 했는지, 중간에 어떤 접근을 시도했다 버렸는지는 사라져. 코드 리뷰는 원래 "왜 이렇게 짰는지"를 묻는 절차인데, 에이전트가 짠 코드에서는 그 '왜'에 답할 사람이 없어.

이게 지금 많은 조직에서 실제로 벌어지는 일이야. PR의 양은 늘었는데 리뷰의 깊이는 얕아졌어. 리뷰어가 "AI가 짰겠지"라고 생각하는 순간 승인 버튼이 가벼워져. 그리고 몇 달 뒤 아무도 이해하지 못하는 코드베이스가 남아.

슬랙이 파고든 지점이 여기야. 에이전트의 작업 과정을 개인의 터미널에서 팀의 채널로 옮기면, 그 과정이 기본값으로 관찰 가능해져. 누군가 일부러 공유하지 않아도 팀이 볼 수 있는 상태가 되는 거야.

슬랙 쪽의 사업적 계산도 봐야 해. 슬랙은 세일즈포스 소유고, 지금 마이크로소프트 팀즈와의 경쟁에서 구조적으로 불리한 위치에 있어. 팀즈는 오피스·윈도우·엔트라와 묶여서 팔리고, 코파일럿이 그 위에 얹혀. 슬랙은 번들이 없어서 개별 제품으로 이겨야 해.

그래서 슬랙이 고른 전장이 개발 협업이야. 슬랙의 사용자 기반에서 엔지니어링 조직 비중이 높고, 이미 깃허브·지라 같은 개발 도구 연동은 슬랙이 오래 강했던 영역이거든. 자기가 이미 강한 곳에 새 워크플로를 얹는 전략이야.

모든 요금제에서 기본 제공한다는 결정도 이 맥락에서 읽혀. 프리미엄 기능으로 팔면 수익은 나지만 확산이 느려. 지금 슬랙에 필요한 건 매출보다 "AI 코딩은 슬랙에서 한다"는 습관이야. 대신 각 에이전트 이용료는 사용자가 파트너사에 따로 내. 슬랙은 판을 깔고 요금은 파트너가 받는 구조야.

파트너 구성도 뜯어볼 만해. 클로드 코드, 데빈, 깃허브 코파일럿, 버셀 에이전트, 그리고 챗GPT까지 — 서로 정면으로 경쟁하는 회사들이 같은 표면에 나란히 올라와 있어. 이건 슬랙이 특정 모델 회사와 독점 제휴를 맺지 않았다는 뜻이야. 세일즈포스가 앤스로픽·오픈AI 양쪽과 모두 관계를 유지해온 것과도 맞아떨어지고. 중립적인 플랫폼이라는 포지션은 마이크로소프트가 흉내 내기 어려운 지점이야. 팀즈에서 코파일럿과 클로드 코드를 동등하게 취급하는 그림은 상상하기 어렵거든.

다만 중립성에는 비용이 따라. 여러 에이전트를 지원하려면 각각의 인증·권한·출력 형식을 다 맞춰야 하고, 파트너가 제품을 바꿀 때마다 통합을 갱신해야 해. 슬랙이 이 유지보수를 얼마나 오래 감당할지가 이 기능의 수명을 결정해. 통합이 낡으면 사용자는 조용히 원래 도구로 돌아가.

실제로 어떻게 도는지 — 흐름 정리

단계 일어나는 일 누가 보나
1. 태그 대화 중 에이전트를 호출 원 채널 참여자
2. 채널 생성 프로젝트 전용 코드 채널이 자동 생성 초대된 팀원
3. 작업 diff·미리보기·계획이 탭으로 갱신 채널 전원 실시간
4. 개입 코멘트를 남기면 에이전트가 반영 채널 전원
5. 승인 결과물 확인 후 승인 권한 있는 사람
6. 보관 채널이 검색 가능한 기록으로 남음 이후 모든 사람

이 흐름에서 가장 과소평가된 단계가 6번이야. 나머지는 다른 도구에도 비슷한 게 있어. 실시간 diff는 IDE에도 있고, 미리보기는 배포 플랫폼에도 있어. 그런데 "에이전트가 이 코드를 왜 이렇게 짰는지"에 대한 대화가 검색 가능한 형태로 남는 것은 지금 대부분의 도구가 못 하는 일이야.

이게 중요한 이유는 시간이 지난 뒤에 드러나. 6개월 뒤 그 코드에서 버그가 나면, 지금은 git blame으로 커밋과 PR까지만 거슬러 올라가. 슬랙 코드 구조에서는 그 코드가 만들어지던 순간의 대화와 판단까지 남아. 조직의 기억이 한 층 깊어지는 셈이야.

세 번째로 볼 건 4번, 중간 개입이야. 지금 대부분의 에이전트 워크플로는 "요청하고 → 기다리고 → 결과를 본다"의 반복이야. 에이전트가 잘못된 방향으로 30분을 달려도 끝나야 알 수 있어. 계획과 진행이 실시간으로 노출되면 잘못된 방향을 초반에 끊을 수 있어. 이건 토큰 비용과 시간 양쪽에서 실질적인 절약이야.

반대로 가장 불확실한 단계는 3번이야. 실시간으로 diff와 계획이 흐르는 채널은 정보량이 많아. 에이전트 하나가 몇십 개 파일을 건드리는 작업이라면 채널이 순식간에 로그 스트림이 돼. 사람이 실제로 그걸 지켜볼 수 있는 분량인지, 아니면 결국 아무도 안 보고 넘어가는 알림이 될지가 이 제품의 실용성을 가를 거야. 관찰 가능하다는 것과 실제로 관찰된다는 건 다른 얘기거든.

각자의 이득 — 이 구조에서 누가 뭘 가져가나

엔지니어링 팀이 얻는 건 관찰 가능성이야. 특히 시니어 개발자나 테크리드 입장에서, 팀원들이 에이전트에게 뭘 시키고 있는지 파악할 방법이 지금은 사실상 없어. 채널에 노출되면 코칭이 가능해져. "그 프롬프트 말고 이렇게 물어봐"라는 개입이 실시간으로 들어갈 수 있어.

비개발 직군의 참여 경로도 열려. PM이나 디자이너가 HTML 미리보기를 보고 바로 "이 여백 좀 줄여줘"라고 코멘트를 다는 구조는 지금까지 없었어. 기존에는 개발자가 중간에서 통역을 해야 했고, 그 왕복이 며칠씩 걸렸지. 다만 이건 양날이야. 모든 사람이 코드 작업에 의견을 낼 수 있게 되면 결정이 느려질 수도 있어.

슬랙이 얻는 건 워크플로 잠금이야. 코딩이라는 고빈도 작업이 슬랙 안에서 일어나면 이탈이 어려워져. 채널 기록이 쌓일수록 그 가치는 커지고. 세일즈포스 관점에서는 슬랙이 단순 메신저에서 작업이 실제로 일어나는 곳으로 올라서는 그림이야.

파트너 에이전트 회사들이 얻는 건 유통이야. 앤스로픽·코그니션·깃허브·버셀 입장에서 슬랙의 기업 사용자 기반은 무시할 수 없는 채널이야. 특히 개발자 개인이 아니라 팀 단위 도입을 노리는 회사에게는 의미가 커. 다만 대가도 있어. 사용자와의 접점을 슬랙이라는 계층에 내주는 거거든. 에이전트가 슬랙 안에서 서로 갈아 끼워질 수 있는 부품이 되면, 차별화 압력이 커져.

보안·컴플라이언스 담당자에게는 복잡해. 좋은 점은 감사 추적이 생긴다는 거야. 지금까지 개발자가 개인 터미널에서 에이전트를 돌리면 조직은 사실상 아무것도 못 봐. 나쁜 점은 소스 코드와 관련 논의가 슬랙 워크스페이스에 더 많이 쌓인다는 거야. 데이터 보관 정책과 접근 권한 설계를 다시 봐야 하는 사안이야.

개발자 개인의 입장은 미묘해. 작업 과정이 노출되는 게 항상 반가운 건 아니야. 실패한 시도까지 팀 전체가 보는 환경은 심리적 부담이 될 수 있어. 조직 문화에 따라 이 기능이 협업 도구로 쓰일지 감시 도구로 쓰일지가 갈려.

신입 개발자와 온보딩 관점의 이득도 있어. 지금 주니어 개발자가 겪는 어려움 중 하나가 시니어의 판단 과정을 볼 기회가 줄었다는 거야. 예전에는 페어 프로그래밍이나 코드 리뷰 코멘트로 그 사고 과정을 배웠는데, 에이전트가 중간에 들어오면서 그 경로가 흐려졌어. 에이전트와 시니어가 주고받는 대화가 채널에 남으면, 그게 일종의 교재가 돼. 다만 이건 부수 효과지 이 제품이 겨냥한 목표는 아니야.

과거 유사 사례 — 챗옵스는 처음이 아니야

**깃허브의 챗옵스(ChatOps)**가 원형이야. 2013년경 깃허브는 사내 챗봇 허봇(Hubot)을 통해 배포·모니터링·인시던트 대응을 채팅방에서 처리하는 방식을 대중화했어. 핵심 아이디어가 지금 슬랙 코드와 같아. 작업을 대화가 일어나는 곳으로 가져오면 맥락이 자동으로 공유된다는 거야. 챗옵스는 실제로 자리를 잡았고, 지금도 많은 조직이 배포를 슬랙에서 해.

2016년 슬랙의 봇 붐은 반대 사례야. 슬랙이 앱 디렉터리와 봇 프레임워크를 밀면서 수많은 봇이 쏟아졌는데, 대부분 몇 주 안에 채널에서 조용해졌어. 이유는 분명했어. 당시 봇들은 대화형 인터페이스로 포장한 명령줄에 가까웠고, 그냥 원래 도구를 쓰는 게 빨랐거든. 채팅에 넣는다는 것 자체는 가치를 만들지 못했어.

이 두 사례의 차이가 슬랙 코드의 성패를 가늠하는 기준이야. 챗옵스가 성공한 건 배포라는 작업이 원래 여러 사람의 승인과 관찰을 필요로 했기 때문이야. 봇 붐이 실패한 건 개인 작업을 굳이 채팅으로 옮겼기 때문이고. AI 코딩은 어느 쪽에 가까울까. 혼자 짜는 작은 수정이라면 후자에 가깝고, 여러 사람이 결과를 확인해야 하는 기능 개발이라면 전자에 가까워.

마이크로소프트 팀즈와 코파일럿의 통합도 비교 대상이야. 마이크로소프트는 깃허브·비주얼스튜디오·애저를 모두 갖고 있어서 이론적으로 더 완결된 경로를 만들 수 있어. 그런데 실제로는 각 제품이 따로 놀아서 통합의 이점이 잘 드러나지 않았어. 슬랙이 파고들 틈이 여기에 있어. 소유하지 않은 대신 중립적일 수 있다는 것. 클로드 코드와 코파일럿을 같은 채널에서 나란히 쓸 수 있는 건 마이크로소프트가 하기 어려운 제안이야.

아틀라시안의 로보도 비슷한 방향을 시도해왔어. 지라·컨플루언스에 쌓인 조직 맥락을 AI가 활용하게 하는 접근인데, 성과는 아직 갈려. 공통된 어려움은 기존 도구의 관성이야. 개발자는 이미 익숙한 워크플로를 바꾸기 싫어해.

경쟁자 카운터 플레이

마이크로소프트는 팀즈와 깃허브를 더 촘촘히 엮는 쪽으로 대응할 가능성이 커. 이미 코파일럿 코딩 에이전트가 깃허브 안에서 이슈를 받아 PR을 내는 흐름을 갖고 있고, 여기에 팀즈 알림과 승인을 붙이면 비슷한 그림이 나와. 마이크로소프트의 강점은 번들과 기업 계약이야.

커서와 코그니션 같은 에이전트 회사들은 자체 협업 계층을 만들지, 슬랙 같은 배포 채널에 올라탈지 선택해야 해. 커서는 자체 웹 인터페이스와 팀 기능을 확장해왔고, 코그니션은 데빈을 여러 표면에 올리는 쪽이야. 자체 협업 계층을 만들면 통제권은 얻지만 사용자를 새로 모아야 하고, 남의 채널에 올라타면 유통은 얻지만 종속돼.

깃허브의 위치가 가장 흥미로워. 슬랙 코드의 파트너로 참여하면서 동시에 경쟁자이기도 해. PR·이슈·액션이라는 개발 워크플로의 중심을 갖고 있어서, 협업 계층을 슬랙에 내줄 이유가 없거든. 이번 참여는 사용자를 뺏기지 않으려는 방어적 성격이 강해 보여.

버셀 같은 배포 플랫폼의 참여도 눈여겨볼 만해. 미리보기가 채널에 뜨는 기능은 배포 인프라가 있어야 성립하거든. 코드를 짜는 것과 그 결과를 즉시 보여주는 것을 한 흐름으로 묶으면, 비개발자가 판단할 수 있는 지점이 크게 늘어. 이 조합이 잘 작동하면 "코드는 못 읽지만 결과는 볼 수 있다"는 사람들이 개발 과정에 실질적으로 참여하게 돼.

국내 협업 도구 시장에서도 같은 질문이 나올 거야. 국내 기업들은 슬랙과 팀즈 외에 자체 메신저를 쓰는 경우가 많은데, 코딩 에이전트를 그 안으로 끌어들이는 통합은 아직 거의 없어. 개발 조직이 큰 회사일수록 이 격차가 실무적으로 느껴질 가능성이 커.

슬랙 자신의 과거 제품 이력도 변수야. 슬랙은 캔버스·리스트·워크플로 빌더 같은 기능을 여러 차례 추가해왔는데, 실제로 조직에 정착한 것도 있고 잊힌 것도 있어. 공통점은 기존 도구를 대체할 만큼 낫지 않으면 결국 안 쓰인다는 거야. 슬랙 코드도 같은 시험대에 올라. IDE와 터미널을 대체하려는 게 아니라 그 옆에 붙는 협업 계층이라는 포지션이 명확한 건 유리한 조건이지만, 채널 하나가 늘어나는 비용을 감당할 만큼의 가치를 매일 증명해야 해.

그래서 뭐가 달라지는데

개발팀 리드라면 이 기능은 지금 겪고 있는 구체적인 문제 하나를 겨냥해. 팀원들의 에이전트 사용을 파악할 수 없는 상황 말이야. 도입을 검토한다면 시작점은 전면 도입이 아니라 한 프로젝트에서 시험해보는 거야. 특히 확인할 건 채널 소음이야. 에이전트의 진행 상황이 실시간으로 흐르면 알림 피로가 생길 수 있어.

개발자 개인이라면 당분간 터미널 기반 워크플로를 대체하지는 않을 거야. 혼자 빠르게 고치는 작업은 여전히 터미널이 빨라. 슬랙 코드가 맞는 건 여러 사람이 결과를 확인해야 하는 작업이야. 두 가지를 상황에 따라 나눠 쓰는 게 현실적이야.

PM이나 디자이너라면 실무적으로 가장 크게 바뀔 수 있는 직군이야. HTML 미리보기에 직접 코멘트를 다는 경로가 생기면 왕복 시간이 줄어. 다만 코드 변경의 파급을 모르는 상태에서 요청을 남기면 오히려 혼란이 커질 수 있어서, 팀 안에서 개입 범위를 정해두는 게 좋아.

보안·컴플라이언스 담당이라면 지금 확인해야 할 게 명확해. 코드 채널에 어떤 데이터가 남는지, 보관 기간이 어떻게 적용되는지, 외부 파트너 에이전트로 나가는 데이터의 범위가 어디까지인지. 각 파트너 에이전트에 대한 접근 권한을 사용자가 따로 가져야 한다는 구조는 에이전트별로 계약과 데이터 처리 조건이 다르다는 뜻이기도 해.

경영진이라면 이 발표의 함의는 도구가 아니라 조직이야. AI가 코드를 짜는 비중이 늘수록, 조직이 관리해야 할 대상이 '개발자의 산출물'에서 '에이전트의 작업 과정'으로 옮겨가. 그 과정을 볼 수 없으면 품질도 리스크도 관리할 수 없어. 슬랙 코드는 그 문제에 대한 하나의 답이고, 답이 이것 하나뿐인 건 아니야.

🥄 남은 궁금증 세 가지

— 그냥 슬랙에 봇 하나 더 붙인 거 아니야? 차이는 전용 채널과 기록이야. 기존 봇 연동은 알림을 채널에 던지는 수준이었는데, 이건 작업 표면 자체를 채널 안에 만들어. diff와 미리보기와 계획이 탭으로 붙고, 끝나면 그 전체가 검색 가능한 기록으로 남아. 다만 2016년 봇 붐이 조용히 사라진 전례가 있어서, 실제로 습관이 되는지는 지켜봐야 해.

— 우리 팀이 쓰는 에이전트가 목록에 없으면? 지금 공개된 파트너는 클로드 코드·데빈·코파일럿·버셀 에이전트, 그리고 챗GPT야. 여기 없는 도구를 쓴다면 당장은 해당이 안 돼. 슬랙이 개방형 연동을 어디까지 열지는 아직 명확하지 않아서, 도입을 검토 중이라면 이 부분을 먼저 확인하는 게 좋아.

— 모든 요금제 기본 제공이면 공짜야? 슬랙 쪽 기능은 그래. 다만 각 에이전트 이용료는 별도야. 클로드 코드든 데빈이든 코파일럿이든 해당 회사에 내는 요금이 그대로 붙어. 슬랙이 판을 깔고 파트너가 요금을 받는 구조라서, 실제 도입 비용은 몇 명이 어떤 에이전트를 얼마나 쓰느냐로 결정돼.

참고 자료

수치는 발표 시점 기준이라 바뀔 수 있어.