본문으로 건너뛰기

"에이전트" 태그로 연결된 3개 게시물개의 게시물이 있습니다.

모든 태그 보기

Claude 도구 API 정식 출시

· 약 7분

에이전트에게 "이 PDF 읽고 저 웹 포털에 대신 입력해 줘"를 시키는 데 필요한 조각이 셋인데, 그 셋이 같은 날 정식 출시됐습니다. 2026년 8월 20일입니다.

Anthropic이 computer use, Skills API, Files API 세 가지의 정식 출시를 발표했습니다. 각각 따로 보면 기능 추가인데, 셋을 붙여 놓으면 성격이 달라집니다.

세 조각이 각각 맡는 일

발표문이 든 예시가 구성을 잘 보여 줍니다. 보험 청구 처리 에이전트입니다. Files API에서 접수 문서를 읽고, 팀의 접수 절차를 담은 skill을 따라, browser use tool로 보험사 웹 포털에서 제출을 마치고, 확인서를 다시 파일로 저장합니다.

조각맡는 일
Files API에이전트가 읽고 쓰는 문서의 저장소
Skills API팀의 절차를 코드와 문서로 묶어 올려 두는 곳
computer use화면을 보고 클릭하고 입력하는 손
browser use tool웹 애플리케이션 전용 손

역할 분담이 사람의 업무 구조와 닮았습니다. 문서, 절차서, 그리고 소프트웨어를 조작하는 손입니다. 지금까지는 이 셋 중 손 쪽이 가장 불안했습니다.

computer use: 도구 식별자가 toolset으로 바뀌었다

여기가 실무에서 가장 먼저 걸리는 부분입니다. 도구 타입 문자열이 바뀌었습니다.

{
"type": "computer_toolset_20260801",
"name": "computer"
}

Claude API에서는 beta 헤더가 필요하지 않습니다. 이전 버전인 computer_20251124anthropic-beta: computer-20251124-api 헤더가 필요했고, 지금은 구형 모델용으로 남았습니다.

지원 모델이 갈립니다. computer_toolset_20260801claude-opus-5, claude-sonnet-5, claude-opus-4-8, claude-fable-5, claude-mythos-5에서 동작합니다. Opus 4.7과 4.6, Sonnet 4.6, Opus 4.5는 이전 computer_20251124를 써야 합니다.

파라미터에서 사라진 게 하나 있습니다. 화면 너비와 높이입니다. 이전 버전은 display_width_px 같은 값을 받았는데, computer_toolset_20260801은 받지 않습니다. 좌표를 돌려주는 스크린샷에서 직접 읽습니다. 기존 코드를 옮길 때 이 두 파라미터를 그대로 두면 거부됩니다.

이름이 tool에서 toolset으로 바뀐 이유는 안에 든 것이 하나가 아니기 때문입니다. member tool이 17개입니다.

분류member
화면 읽기screenshot, zoom
클릭left_click, right_click, middle_click, double_click, triple_click
포인터mouse_move, left_click_drag, left_mouse_down, left_mouse_up, cursor_position
스크롤scroll
키보드type, key, hold_key
대기wait

zoom이 눈에 띕니다. 지정한 영역을 원본 해상도로 다시 캡처합니다. 전체 화면 스크린샷은 축소되어 작은 글자를 놓치기 쉬운데, 그 문제를 영역 재촬영으로 풉니다. hold_keywait는 최대 300초까지 받습니다.

turn당 한 동작에서 여러 동작으로

베타에서 정식 출시로 오면서 가장 크게 바뀐 지점입니다. 이전에는 모델 호출 한 번에 동작 하나였습니다. 지금은 한 응답에 여러 tool_use 블록을 담습니다.

로그인 폼을 채우는 작업을 생각해 보면 차이가 큽니다. 아이디 칸 클릭, 입력, 비밀번호 칸 클릭, 입력, 로그인 클릭이면 모델 호출 5회였던 것이 1회가 됩니다. 지연과 비용이 함께 줄어듭니다.

대신 실패 처리 규칙을 알아야 합니다. 동작은 순서대로 실행되고 첫 실패에서 멈춥니다. 실행되지 않은 나머지 동작에는 이런 결과를 돌려줘야 합니다.

{
"type": "tool_result",
"tool_use_id": "toolu_01...",
"toolset_name": "computer",
"is_error": true,
"content": "Not executed: an earlier computer action in this turn failed."
}

toolset_name 필드가 모든 결과에 들어가야 합니다. 값은 "computer"입니다. 예전 방식으로 tool_use_idcontent만 채우면 통과하지 않습니다.

한 동작씩 진행하고 싶으면 병렬 도구 사용을 끕니다.

{
"tool_choice": { "type": "tool", "disable_parallel_tool_use": true }
}

화면 상태를 매 단계 확인해야 하는 작업이라면 이쪽이 안전합니다. 화면이 예상과 달라졌는데 나머지 클릭이 그대로 나가면 엉뚱한 곳을 누릅니다.

browser use tool은 여기서 한 겹 더 갑니다. 픽셀 좌표만 쓰는 것보다 웹 요소를 안정적으로 겨냥하도록 페이지 구조 분석을 더했습니다. 웹 애플리케이션만 다룰 거라면 이쪽이 맞습니다.

의료 쪽 이야기도 붙었습니다. computer use가 BAA 아래 HIPAA 규제 대상 워크로드에 쓸 수 있게 됐습니다.

Skills API: skill이 저장 객체가 됐다

Claude Code의 Skills를 다룬 적이 있는데, 그때는 로컬 디렉터리에 마크다운 파일을 두는 구조였습니다. 이제 API 층으로 올라와 저장되고 버전이 붙는 객체가 됐습니다.

skill은 지시문과 스크립트, 템플릿이 든 폴더입니다. 작업이 필요할 때만 Claude가 읽어 들이고, Claude의 코드 실행 sandbox 안에서 돕니다. 직접 호스팅할 서버가 없습니다.

엔드포인트 구성입니다.

POST /v1/skills # 생성 (multipart/form-data)
GET /v1/skills # 목록
GET /v1/skills/{skill_id} # 조회
DELETE /v1/skills/{skill_id} # 삭제
POST /v1/skills/{skill_id}/versions # 새 버전 업로드
GET /v1/skills/{skill_id}/versions # 버전 목록
GET /v1/skills/{skill_id}/versions/{version} # 버전 조회
DELETE /v1/skills/{skill_id}/versions/{version} # 버전 삭제

버전 참조에 latest 리터럴을 쓸 수 있습니다. latest_version_id 필드가 가리키는 곳으로 해석됩니다. 다만 skills-2025-10-02 beta 헤더를 붙인 요청은 버전을 Unix epoch 타임스탬프로 주소지정합니다. 예시가 "1759178010641129" 형태입니다. beta 경로와 정식 경로에서 버전 식별 방식이 다르니 여기서 한 번 헤맬 수 있습니다.

name 필드의 성격이 중요합니다. 첫 업로드의 SKILL.md frontmatter에 있는 name(없으면 그 폴더 이름)에서 kebab-case slug로 정해지고, 이후 바뀌지 않습니다. 나중 업로드도 같은 값으로 해석돼야 합니다. 이 slug가 마운트된 파일의 최상위 디렉터리 이름이 되고, 내려받을 때 아카이브 파일명이 됩니다.

skill의 출처는 네 종류로 구분됩니다.

source.type
custom사용자가 작성. 해당 workspace 전용
anthropicAnthropic 발행. 공유되며 읽기 전용
anthropic_exampleAnthropic 발행 예제
plugin설치된 플러그인에서 해석

요청에 붙이는 방법에서 혼동이 잘 생깁니다. Skills를 쓰려면 세 가지를 함께 넣습니다.

client.beta.messages.create(
model="claude-opus-5",
max_tokens=16000,
container={"skills": [{"skill_id": "skill_01...", "version": "latest"}]},
tools=[{"type": "code_execution_20260521", "name": "code_execution"}],
betas=["code-execution-2025-08-25", "skills-2025-10-02"],
messages=[...],
)

container에 skill을 얹고, 코드 실행 도구를 선언하고, beta 두 개를 붙입니다. skill이 sandbox 안에서 도니까 코드 실행 도구가 함께 필요합니다.

Managed Agents와 헷갈리지 않기

여기가 정말 자주 어긋나는 지점입니다. Skills는 Managed Agents가 아닙니다.

Managed Agents는 별개 표면입니다. POST /v1/agents로 에이전트 설정을 저장해 두고, 세션을 만들어 실행합니다. 세션마다 컨테이너가 workspace로 할당되고 에이전트 루프 자체를 Anthropic이 돌립니다. beta 헤더도 다릅니다. managed-agents-2026-04-01입니다.

반면 Skills로 문서를 만들게 하려면 위처럼 client.beta.messages.createcontainer와 코드 실행 도구를 얹으면 끝입니다. client.beta.agents나 세션 API를 쓰는 게 아닙니다. Skills가 Managed Agents 안에서도 쓰이기 때문에 문서를 훑다 보면 두 경로가 섞여 보입니다.

Files API: 한 번 올리고 ID로 부른다

성격은 단순합니다. PDF나 스프레드시트를 한 번 올려 두고, 이후 요청에서는 다시 보내지 않고 ID로 참조합니다.

POST /v1/files

beta 헤더는 files-api-2025-04-14입니다. 업로드할 때와, 그 파일을 참조하는 messages.create 양쪽에 모두 붙여야 합니다. 한쪽만 붙이면 실패합니다.

참조할 때는 content block 타입이 파일의 MIME 타입과 맞아야 합니다.

{
"type": "document",
"source": { "type": "file", "file_id": "file_01..." }
}

PDF와 텍스트는 document, 이미지는 image입니다.

정식 출시로 오면서 늘어난 것이 셋입니다. 파일 자동 만료가 들어왔고, rate limit이 5배로 올랐고, 조직당 저장 용량이 1TB가 됐습니다. 자동 만료는 편의 기능처럼 보이지만 실무에서는 정리 부담을 덜어 줍니다. 업로드해 둔 파일을 지우는 코드를 따로 관리하지 않아도 됩니다.

base64로 PDF를 매번 실어 보내는 방식과 비교하면 차이가 분명합니다. base64 경로는 요청 32MB, 600페이지 제한이 걸립니다. 같은 문서를 여러 번 물어볼 거라면 매 요청마다 그 크기를 다시 전송하는 셈입니다.

어디서 쓸 수 있나

플랫폼마다 갈립니다. 세 기능 모두 Claude 플랫폼에서 쓸 수 있습니다. Skills API와 Files API는 Microsoft Foundry에서도 접근됩니다. computer tool과 browser tool은 Google Cloud Vertex AI에 들어올 예정입니다.

computer use는 플랫폼별로 버전이 다릅니다. computer_toolset_20260801 전체 지원은 Claude API고, Claude Platform on AWS와 Bedrock, Google Cloud, Foundry는 이전 버전이 beta로 올라가 있습니다. 특정 클라우드에 묶여 있다면 도구 식별자와 모델을 같이 확인해야 합니다.

무엇이 실제로 달라지나

세 기능의 정식 출시를 하나로 묶으면, 에이전트가 API를 가진 시스템만 다루던 단계에서 벗어난다는 뜻입니다. 화면만 있는 소프트웨어, 예를 들어 사내 레거시 웹 콘솔이나 외부 기관 포털은 자동화 대상이 아니었습니다. 사람이 대신 클릭했습니다.

다만 ClaudeBleed 사례를 다루면서 봤듯이, 브라우저를 조작하는 권한은 그 자체로 공격 표면입니다. 화면을 보고 클릭하는 에이전트에게는 세션 쿠키가 붙은 브라우저가 그대로 열려 있습니다. 웹 포털에 자동 입력을 맡기기 전에, 그 에이전트가 어떤 페이지까지 갈 수 있는지 경계를 먼저 정해 두는 편이 좋습니다.

turn당 여러 동작이 묶이는 변화는 그래서 양면입니다. 비용과 지연이 줄지만, 잘못된 화면 판단 하나가 다섯 번의 클릭으로 번집니다. 되돌리기 어려운 작업에서는 disable_parallel_tool_use를 켜는 쪽이 낫다고 봅니다.

참고

Cloudflare Agents Week

· 약 4분

Cloudflare는 매년 몇 차례 "week"라는 이름으로 발표를 몰아서 내놓는데, 8월 3일부터 7일까지는 처음으로 에이전트가 주인공이었어요. 주간 회고 글 기준으로 발표를 훑으면, 개별 제품보다 그것들이 가리키는 방향이 더 흥미롭습니다.

Cloudflare OS: 에이전트를 사내 시스템에 붙이는 안전한 방법

가장 큰 화제는 Cloudflare OS였습니다. 이름과 달리 커널이 있는 운영체제가 아니라, 사내 시스템에 에이전트를 연결하는 워크스페이스 플랫폼입니다. Apache 2.0 라이선스로 GitHub에 공개됐습니다.

구조의 핵심은 권한 모델입니다. 에이전트는 권한 0에서 출발합니다. 사내 시스템(위키, 티켓, DB, 배포 도구) 각각의 앞에 Gatekeeper Worker라는 관문 코드를 두고, 에이전트는 그 관문이 허용하는 범위의 작업만 요청할 수 있습니다. "에이전트에게 사내 API 키를 통째로 주면 어디까지 뒤질지 모른다"는 공포를, 시스템별로 좁게 정의된 통로로 바꾸는 설계입니다.

인프라 회사가 사내 업무 계층까지 내려와 그걸 오픈소스로 풀었다는 점, 그리고 하필 "OS"라는 이름을 붙였다는 점 때문에 Hacker News에서 논쟁이 붙었습니다. 이름이야 어떻든, 에이전트 권한 문제를 프록시 계층으로 푸는 패턴 자체는 참고할 가치가 있습니다. 뒤에 나올 이야기지만, 이 패턴은 사내 DB에 에이전트를 붙일 때 그대로 필요해지는 물건입니다.

Wallets: 에이전트에게 용돈을 준다

Cloudflare Wallets는 문제 정의가 직관적이라 Fortune 같은 일반 매체까지 다뤘습니다. 에이전트는 은행 계좌를 못 만든다는 것입니다. 에이전트가 유료 API를 호출하고 리소스를 사려면 결국 사람의 카드가 어딘가에 물려 있어야 하는데, 그 카드에는 한도도 범위도 걸 수 없습니다.

Wallets의 구조는 위임입니다. 사람이 보유한 Account Wallet에 스테이블코인을 담아 두고, 에이전트마다 Virtual Wallet을 만들어 지출 한도, 허용 목록, 건당 최대 금액을 걸어 위임합니다. 결제 프로토콜로는 x402를 지원합니다. 8월 4일에는 cloudflare.pay 핸들 예약이 열렸고, 실제 지갑 인프라는 몇 달에 걸쳐 나온다고 합니다.

에이전트 지출 통제를 IAM처럼 다루는 첫 대형 시도라는 점에서, 실물이 나오면 다시 볼 가치가 있습니다.

나머지 발표들: 프로토콜 계층

한 주의 나머지를 채운 것은 프로토콜과 도구입니다.

  • WebMCP 프리뷰: 웹사이트가 자신을 MCP 서버로 노출하는 방식의 프리뷰. 에이전트가 화면을 스크래핑하는 대신 구조화된 인터페이스로 사이트와 대화합니다
  • MCPv2: MCP 프로토콜의 다음 버전 지원
  • Agent Access Model: 에이전트의 리소스 접근을 사람 사용자와 구분해 다루는 모델
  • Kitesurf: 에이전트 우선(agent-first) 브라우저

그리고 주가 끝난 뒤에도 같은 결의 발표가 이어졌습니다. 8월 14일에는 MCP 트래픽을 식별하고 보호하는 기능이 나왔습니다. 에이전트가 만드는 트래픽을 봇도 사람도 아닌 제3의 유형으로 인정하고 전용 보안 장치를 붙이기 시작한 것입니다.

관통하는 그림

발표를 나열하면 잡다해 보이지만, 겹쳐 놓으면 한 문장이 됩니다. 에이전트를 인터넷의 1급 시민으로 만들기 위한 인프라 계층을 선점하겠다는 것입니다.

사람 사용자에게는 이미 계정(신원), 결제 수단, 브라우저, 접근 제어가 있습니다. Cloudflare는 그 네 가지의 에이전트 버전을 한 주에 걸쳐 내놨습니다. Agent Access Model이 신원, Wallets가 결제, Kitesurf가 브라우저, Cloudflare OS와 Gatekeeper가 접근 제어입니다. CDN 회사의 신사업 나열이 아니라 계층 하나를 통째로 짜는 그림입니다.

DBA 관점에서 눈여겨볼 지점을 하나 꼽자면 Gatekeeper 패턴입니다. 에이전트에게 DB 접근을 열어 달라는 요청은 이미 현실에서 오고 있습니다(AlloyDB의 MCP 서버 때도 같은 이야기를 했습니다). 그때 계정과 권한을 직접 주는 대신, 좁게 정의된 관문 계층을 사이에 두는 설계가 표준이 될 가능성이 큽니다. 미리 그려 두면 요청이 왔을 때 당황하지 않을 수 있어요.

참고 자료

Slack의 Claude Tag

· 약 6분

무엇이 나왔나

2026년 6월 23일, Anthropic이 Slack 채널 안에서 한 명의 팀원처럼 일하는 Claude Tag를 베타로 공개했고, 쓰는 법은 단순해요. 채널에서 @Claude로 태그하고 할 일을 말로 던지면, Claude가 작업을 단계로 쪼개 도구를 써가며 처리한 뒤 같은 Slack 스레드에 결과를 보고해요. Anthropic은 이를 사람이 매번 묻는 챗봇이 아니라, 채널에 상주하며 문맥을 쌓는 팀원으로 설명해요.

지난 글에서 정리했듯 그동안 Claude Code의 무대는 터미널이었습니다. slash command가 skills로 통합되고, Opus 4.8이 수백 개의 subagent를 굴리는 식으로 위임의 단위가 커졌지만, 어디까지나 개발자의 CLI 안에서 벌어진 일이었습니다. Claude Tag는 그 흐름을 협업 도구로 끌어냅니다. 개발자가 아닌 사람도 매일 머무는 Slack 채널에서 같은 Claude를 부릅니다.

어떻게 동작하나

Claude Tag의 성격은 세 가지로 압축됩니다. 공유 정체성, 문맥 학습, 알아서 끼어드는 ambient 모드입니다.

채널마다 하나의 공유 Claude

기존 챗봇이 사람마다 별도의 1:1 대화였다면, Claude Tag는 채널 단위로 하나의 Claude가 모두를 상대합니다. 같은 채널에 있는 사람은 Claude가 지금 무슨 작업을 하는지 볼 수 있고, 앞사람이 멈춘 지점에서 대화를 이어받을 수 있습니다. 작업이 한 사람의 DM에 갇히지 않고 팀의 공동 작업으로 굴러간다는 뜻입니다.

채널을 따라가며 문맥을 쌓는다

Claude는 배정된 채널의 대화를 따라가며 일에 대한 문맥을 축적합니다. Anthropic의 표현으로는 "채널을 따라갈수록 그 일에 대해 점점 더 많이 알게 된다". 권한을 주면 다른 Slack 채널이나 연결된 데이터 소스에서도 사실을 끌어올 수 있습니다. 매번 처음부터 배경을 설명하지 않아도 된다는 게 핵심입니다. 단, 비공개 채널은 학습 대상에서 빠집니다.

ambient 모드는 먼저 끼어든다

ambient 동작을 켜면, Claude는 호출을 기다리지 않습니다. 연결된 채널과 도구를 살피다가 팀이 알면 좋겠다 싶은 정보를 먼저 꺼내고, 방치된 스레드나 멈춘 작업을 따라가 챙깁니다. 작업을 던져두면 사람이 다른 일을 하는 동안 비동기로 처리하고, 길게는 수 시간에서 며칠에 걸쳐 자율적으로 일을 진행하기도 합니다.

호출에서 보고까지의 흐름은 다음과 같습니다.

기존 Slack 통합과 뭐가 다른가

Claude Tag는 기존 "Claude in Slack" 앱을 대체합니다. 둘 다 Slack 안에서 Claude를 부른다는 점은 같지만, 동작 모델이 다릅니다.

기존 Claude in SlackClaude Tag
대화 단위사람별 1:1채널 단위 공유 Claude
문맥 유지세션 한정채널을 따라가며 지속 축적
능동성호출해야 응답ambient 모드로 먼저 제안
비동기 작업제한적수 시간~수일 자율 진행
권한 관리제한적관리자가 채널별 도구/데이터 범위 지정
작업 가시성개인 DM채널 구성원이 함께 관찰

가장 큰 차이는 정체성의 단위입니다. 기존 통합이 "제가 부르는 비서"였다면, Claude Tag는 "채널에 함께 있는 팀원"에 가깝습니다.

CLI 쪽 Claude Code와 비교하면 무대가 옮겨졌다는 점이 분명해집니다.

Claude Code (CLI)Claude Tag (Slack)
무대개발자 터미널팀 협업 채널
주 사용자개발자채널의 모든 구성원
호출터미널 세션@Claude 태그
협업개인 작업 위주다중 사용자 핸드오프
문맥프로젝트 파일/세션채널 대화/연결된 데이터

권한과 거버넌스

조직에 들이는 도구인 만큼 통제 장치가 함께 설계됐습니다. 관리자는 Claude가 채널별로 어떤 도구와 데이터에 접근할지 정하고, 용도에 따라 별도의 Claude 정체성을 분리해 만듭니다. 예를 들어 법무용 Claude가 쌓은 메모리는 엔지니어링 채널로 새어 들어가지 못합니다. 누적된 기억을 포함한 모든 것이 지정된 경계 안에 머뭅니다.

여기에 조직/채널별 토큰 지출 한도를 걸 수 있고, Claude의 활동과 요청자를 남기는 감사 로그도 제공됩니다. 데이터가 부서 경계를 넘지 않도록 막는 장치와 비용/이력을 추적하는 장치도 함께 들어갔습니다.

실무 활용과 한계/요금

Anthropic은 사내 활용 수치를 함께 내놨습니다. 자사 제품팀 코드의 65%를 내부판 Claude Tag가 작성한다는 것입니다. The Decoder에 따르면 용도는 엔지니어링에 그치지 않고 제품 지표 추적, 지원 티켓, 버그 진단까지 걸쳐 있습니다. 채널에 던지는 일상적인 요청을 Claude가 받아 처리하는 그림입니다.

엔진은 Opus 4.8입니다. 수백 개의 subagent를 굴리는 동적 워크플로우를 얹은 그 모델이, 이번에는 Slack 채널이라는 새 무대 위에서 돌아갑니다.

가용성과 요금 관련 사실은 다음과 같습니다.

항목내용
상태베타
제공 플랜Claude Enterprise / Claude Team
엔진Opus 4.8
기존 앱"Claude in Slack" 대체, 마이그레이션 기간 30일
비용 통제조직/채널별 토큰 지출 한도 설정
확장 계획Slack 외 다른 플랫폼으로 확대 예정

출시와 함께 적격 조직에는 도입용 크레딧이 지급됩니다. VentureBeat를 비롯한 일부 매체는 Enterprise 25,000달러, 일정 좌석 수 이상의 Team 2,500달러 수준으로 전했는데, 구체적 금액은 매체 보도이므로 실제 조건은 공식 안내로 확인하는 편이 안전합니다.

한계도 분명합니다. 우선 Enterprise와 Team 플랜에 묶인 베타라 아무나 바로 쓸 수 있는 기능이 아닙니다. 채널 대화를 따라가며 문맥을 쌓는 구조이므로, 어떤 채널에 들이고 어떤 데이터에 접근시킬지를 처음부터 신중하게 설계해야 합니다. ambient 모드로 먼저 끼어드는 동작은 편리한 만큼, 켜는 순간 Claude가 채널을 들여다보는 범위가 넓어진다는 뜻이기도 합니다. 도입에 앞서 권한 범위와 토큰 한도를 정해둘 필요가 있습니다.

정리

Claude Tag는 Claude를 터미널 밖으로 한 걸음 더 꺼냈습니다. Claude Code가 개발자의 CLI에 자리 잡고, Opus 4.8이 위임의 규모를 키웠다면, 이번에는 위임의 장소가 팀이 매일 머무는 협업 채널로 옮겨졌습니다.

요약하면 다음과 같습니다.

  • 채널에서 @Claude 태그로 호출하면 작업을 쪼개 처리하고 스레드에 보고합니다.
  • 채널마다 하나의 공유 Claude가 동작하고, 대화를 따라가며 조직 문맥을 쌓습니다.
  • ambient 모드를 켜면 먼저 정보를 꺼내고 멈춘 작업을 챙깁니다.
  • 관리자가 채널별 도구/데이터 범위와 토큰 한도를 통제합니다.
  • 현재 Enterprise/Team 베타이며, 엔진은 Opus 4.8이고, Slack 외 플랫폼으로 확대가 예고됐습니다.

비서를 부르는 단계에서 팀원을 합류시키는 단계로의 이동이에요. Slack에서 시작했지만, "다른 플랫폼으로 넓힌다"는 예고가 붙은 이상 Claude가 협업 도구 곳곳으로 번지는 흐름의 시작점으로 보는 게 맞아요.

참고 자료