"AI" 태그로 연결된 25개 게시물개의 게시물이 있습니다.

벤더가 "패치를 빨리 적용하세요"라고 말하는 건 새롭지 않아요. 그런데 그 이유가 "AI가 우리 패치를 분석해서 공격 방법을 알아낼 수 있어서"라면 성격이 다릅니다.

2026년 8월 18일 오라클이 Prepare Now: Apply Oracle Database Release Update Immediately Upon Availability를 냈습니다. 지원 중인 모든 릴리스, 19c와 Oracle AI Database 26ai를 포함해, 데이터베이스 자산 전체에 최신 분기 Release Update를 테스트하고 배포할 준비를 지금 하라는 내용입니다.

권고의 근거가 달라졌다​

주목할 부분은 요구 사항이 아니라 근거입니다. 오라클이 든 이유는 frontier AI 모델이 소프트웨어 취약점을 찾고 악용하는 장벽을 크게 낮추고 있다는 것입니다. 그 모델들이 하는 일로 네 가지를 꼽았습니다. 약점 식별, 소프트웨어 변경 분석, 보안 패치의 리버스 엔지니어링, 그리고 잠재적 공격 경로 개발입니다. 속도와 규모가 전례 없다고 표현했습니다.

이 목록에서 세 번째가 핵심입니다. 보안 패치의 리버스 엔지니어링입니다.

패치는 무엇이 잘못됐는지를 알려 줍니다. 코드의 어느 줄이 어떻게 바뀌었는지 보면 그 전에 무엇이 가능했는지 역산할 수 있습니다. 이걸 patch diffing이라고 부르고, 오래된 기법입니다. 새로운 건 그 작업의 비용입니다. 숙련된 분석가가 며칠 걸리던 일을 모델이 훨씬 빨리 해내면, 패치 공개와 실제 적용 사이의 구간이 그만큼 위험해집니다.

패치를 늦게 적용하는 쪽이 더 위험해지는 구조는 원래 있었습니다. 달라진 것은 그 위험이 커지는 속도입니다.

8월 CSPU의 물량​

같은 주에 나온 숫자가 이 권고의 배경을 보여 줍니다. Qualys 분석에 따르면 8월 Critical Security Patch Update는 943개 취약점을 다뤘습니다.

무인증 원격 악용이 가능한 것들이 제품군별로 이렇게 나왔습니다.

E-Business Suite에서 CVSS 9.8인 CVE-2026-60782와 CVE-2026-70926이 나왔습니다.

DBA 관점에서 궁금한 것은 Database 쪽 물량입니다. 943개 중 데이터베이스 제품군은 17개였습니다.

전체 943개에 비해 17개는 적어 보입니다. 하지만 Database Server의 최고 점수가 9.6이라는 게 중요합니다. 개수가 아니라 그 6개가 무엇인지가 판단 근거입니다.

월간 체제와 즉시 적용이 만나면​

오라클이 분기 패치를 버리고 월간 CSPU 체제로 옮긴 이야기를 다룬 적이 있습니다. 이번 권고를 그 흐름 위에 놓으면 실무 부담이 선명해집니다.

분기 체제에서는 1년에 네 번 패치 시기가 왔습니다. 한 번마다 테스트에 몇 주를 쓸 여유가 있었습니다. 월간 체제에서는 열두 번입니다. 여기에 "나오는 즉시 적용하라"가 붙으면, 테스트 기간을 얼마로 잡을지가 실질적인 문제가 됩니다.

권고와 현실 사이의 간격을 어떻게 좁힐지가 결국 각 조직의 판단입니다. 몇 가지 방향은 이렇습니다.

RU 종류를 구분하는 것이 먼저입니다. 오라클의 Release Update와 Release Update Revision은 성격이 다릅니다. 전체를 같은 절차로 다루면 열두 번을 감당하지 못합니다.

테스트 자동화의 범위를 다시 볼 필요도 있습니다. 회귀 검증을 사람이 도는 구조라면 월간 주기를 못 따라갑니다. 이 부분은 패치 정책 이전에 검증 파이프라인 문제입니다.

그리고 적용 순서를 노출도로 정하는 방법이 있습니다. 무인증 원격 악용이 가능한 구성요소를 앞에 두는 식입니다. 위 표에서 Fusion Middleware의 182개가 왜 먼저인지는 숫자가 설명합니다.

AI가 양쪽에서 일한다​

Anthropic의 Project Glasswing을 다룰 때는 AI가 핵심 인프라의 취약점을 찾아 주는 쪽 이야기였습니다. 이번 오라클 공지는 같은 능력의 반대쪽입니다.

두 사례를 나란히 놓으면 구도가 정리됩니다. 방어 측은 AI로 코드를 감사해 취약점을 미리 찾습니다. 공격 측은 AI로 패치를 분석해 이미 고쳐진 취약점을 역산합니다. 전자는 패치 이전, 후자는 패치 이후입니다. 그래서 패치 공개 시점이 양쪽의 경계선이 됩니다.

벤더가 이 판단을 공식 문서로 낸 것이 이번 공지의 의미라고 봅니다. "AI 때문에 패치 정책을 바꿉니다"를 제품 블로그에 적은 사례가 아직 흔하지 않습니다. 오라클이 자사 데이터베이스 고객 전체를 향해 그렇게 적었습니다.

실무에서 확인할 것​

Oracle Database Appliance를 쓰는 환경이라면 릴리스 19.32에 7월 Database Release Update와 19c, 26ai 클론 파일이 들어 있습니다. 계획, 테스트, 배포 일정을 지금 시작하라는 것이 공지의 요구입니다.

정리하면 확인 항목은 셋입니다. 현재 운영 중인 데이터베이스의 RU 수준이 어디인지, 다음 RU가 나올 때 테스트에 며칠을 쓸 계획인지, 그리고 그 며칠이 이번 공지의 논리에 비추어 감당할 만한 구간인지입니다.

마지막 항목이 답하기 어렵습니다. 패치 공개 후 며칠이 안전한지 아무도 숫자로 말해 주지 않으니까요. 저는 이 공지가 그 숫자가 줄어들고 있다는 신호로 읽혔어요.

참고​

• Prepare Now: Apply Oracle Database Release Update Immediately Upon Availability (Oracle Database Blog, 2026-08-18)
• Oracle Critical Patch Update, August 2026 Security Update Review (Qualys, 2026-08-19)
• August 2026 Critical Security Patch Update Released (Oracle Security Blog, 2026-08-18)
• Oracle Database Appliance 릴리스 정보

Claude Code 응답에서 제일 자주 걸러내고 싶은 게 뭘까요. 저는 "먼저 파일을 확인해 보겠습니다" 같은 예고 문장이었어요. v2.1.237에 그걸 기본으로 지워 주는 출력 스타일이 들어왔습니다.

이름은 Concise입니다. 변경 로그 한 줄은 이렇습니다.

Added built-in "Concise" output style: Claude leads with results, skips preamble/narration, works thoroughly

내장 스타일이 다섯 개가 됐다​

출력 스타일은 원래 Default에 Explanatory와 Learning 둘이 붙은 구성이었습니다. 지금은 Proactive와 Concise가 더해져 Default 외에 네 개입니다.

Concise를 두고 오해하기 쉬운 부분이 하나 있습니다. 짧게 답하라는 게 작업을 덜 하라는 뜻은 아닙니다. 공식 문서는 "doing the engineering work as thoroughly as in the Default style"이라고 적어 뒀습니다. 설명을 요청하면 그때는 길게 답합니다. 그리고 짧게 만들지 않는 예외가 정해져 있습니다. 오류 보고, 보안 경고, 파괴적 작업의 확인 문구는 내용을 온전히 유지합니다. 이 예외 목록이 있다는 게 스타일 설계에서 제일 중요한 부분이라고 봅니다. 짧게 쓰다가 위험 신호를 줄여 버리면 절약이 아니라 사고니까요.

Proactive는 성격이 좀 다릅니다. 톤이 아니라 행동 방침을 바꿉니다. auto mode보다 강한 자율 실행 지침인데, 권한 모드는 그대로 둡니다. 무엇을 물어보지 않고 실행할지는 여전히 권한 모드가 결정하고, Proactive는 "판단을 사용자에게 넘기지 말고 스스로 하라"는 쪽만 건드립니다.

스타일을 바꾸는 방법이 달라졌다​

여기서 한 번 헤맬 수 있습니다. /output-style 명령이 없어졌습니다. v2.1.73에서 deprecated 되고 v2.1.91에서 제거됐습니다. 지금은 두 가지 방법뿐입니다.

터미널에서는 /config를 실행해 Output style 항목에서 고릅니다. 선택 결과는 프로젝트 로컬 설정 파일에 저장됩니다.

.claude/settings.local.json

설정 파일을 직접 고쳐도 됩니다.

{
  "outputStyle": "Concise"
}

데스크톱 앱에서는 /config가 메뉴 대신 Settings 화면을 엽니다. 그래서 데스크톱에서는 위 필드를 직접 넣는 쪽이 확실합니다.

바꾼 뒤 바로 안 바뀐다고 당황하지 않아도 됩니다. 출력 스타일은 시스템 프롬프트의 일부이고, 시스템 프롬프트는 세션이 시작할 때 한 번 읽습니다. /clear를 실행하거나 새 세션을 열어야 적용됩니다.

CLAUDE.md와 어디서 갈라지나​

이게 문서에서 가장 값이 나가는 대목입니다. 둘 다 "Claude가 이렇게 행동하게 만드는 장치"인데 붙는 위치가 다릅니다.

출력 스타일은 시스템 프롬프트 끝에 붙습니다. CLAUDE.md는 시스템 프롬프트 뒤에 오는 user message로 들어갑니다. 이 차이가 실무에서 세 갈래 결과를 만듭니다.

첫째, 커스텀 출력 스타일은 기본 소프트웨어 엔지니어링 지침을 빼 버립니다. 변경 범위를 어떻게 잡고, 주석을 어떻게 쓰고, 작업을 어떻게 검증하라는 내장 지침 전체가 사라집니다. 그걸 유지하려면 frontmatter에 keep-coding-instructions: true를 넣어야 합니다. 기본값이 false라는 걸 모르고 커스텀 스타일을 만들면, 톤만 바꾸려던 게 코딩 행동까지 바꿔 버립니다.

둘째, 서브에이전트에는 적용되지 않습니다. 서브에이전트는 자기 시스템 프롬프트로 돕니다. 예외가 fork인데, fork는 부모의 시스템 프롬프트를 통째로 물려받기 때문입니다. Concise로 세션을 돌리면서 서브에이전트에게 요약을 맡겼는데 서브에이전트 응답이 장황한 이유가 여기 있습니다.

셋째, 프롬프트 캐시입니다. 시스템 프롬프트가 바뀌면 캐시 접두사가 깨집니다. 토큰 절약 가이드 글에서 모델과 effort를 세션 시작 시점에 고정하라는 권고를 다뤘는데, 출력 스타일도 같은 부류의 설정입니다. 세션 도중에 바꿀 값이 아닙니다.

커스텀 스타일은 파일 하나다​

내장 다섯 개로 부족하면 마크다운 파일을 만듭니다. 위치는 세 곳이고, 파일명이 스타일 이름이 됩니다. frontmatter에 name을 적으면 그쪽이 이깁니다.

~/.claude/output-styles/          # 사용자 전역
.claude/output-styles/            # 프로젝트

공식 문서 예시가 성격을 잘 보여 줍니다.

---
name: Diagrams first
description: Lead every explanation with a diagram
keep-coding-instructions: true
---

When explaining code, architecture, or data flow, start with a Mermaid diagram
showing the structure, then explain in prose.

프로젝트 스타일은 작업 디렉터리부터 저장소 루트까지의 모든 .claude/output-styles/에서 읽습니다. 같은 이름이 여러 층에 있으면 작업 디렉터리에 가까운 쪽이 이깁니다. 플러그인도 output-styles/ 디렉터리로 스타일을 배포할 수 있는데, 플러그인 전용 필드인 force-for-plugin: true를 켜면 사용자의 outputStyle 설정을 덮어쓰고 강제 적용됩니다. 플러그인을 깔았는데 응답 톤이 갑자기 변했다면 이 필드를 의심해 볼 만합니다.

frontmatter 필드는 네 개입니다.

토큰은 어느 쪽으로 움직이나​

방향이 둘로 갈립니다. 입력 토큰은 스타일 지침이 시스템 프롬프트에 붙는 만큼 늘어납니다. 다만 첫 요청 이후에는 프롬프트 캐시가 이 비용을 상당히 덮습니다. 출력 토큰은 스타일이 결정합니다. Explanatory와 Learning은 설계상 응답이 길어지고, Concise는 반대로 갑니다.

그러니 Concise의 절약 효과는 출력 쪽입니다. 응답 길이가 짧아지는 만큼 출력 토큰이 줄고, 그 짧은 응답이 다음 턴의 입력으로 다시 들어가니 대화가 길어질수록 차이가 누적됩니다. 반대로 Learning 스타일로 긴 세션을 돌리면 그 반대 방향으로 누적됩니다. 제가 지금 이 글을 쓰는 세션이 Learning 스타일인데, 확실히 응답 길이가 기본보다 깁니다.

같은 주에 들어온 나머지​

Concise만 있던 주가 아닙니다. v2.1.234에 실무에서 체감될 항목이 둘 붙었습니다.

사용량 한도 자동 재개입니다. claude.ai 사용량 한도가 초기화되면 세션을 자동으로 이어서 진행합니다. /config에서 켜고 끕니다. 장시간 작업을 돌려 두고 자리를 비우는 사용 방식이라면 이 항목 하나로 흐름이 달라집니다. Routines처럼 사람이 안 보는 동안 도는 작업과 결이 같습니다.

GitLab merge request 배지도 들어왔습니다. GitLab remote가 걸린 저장소에서 glab으로 인증돼 있으면 MR !N 형태로 draft, pending, green 상태를 상태줄에 표시합니다. GitHub PR 배지만 있던 자리에 GitLab이 붙은 셈입니다.

이후 버전도 흐름이 이어집니다. v2.1.238에는 커스텀, 프로젝트, 플러그인 출력 스타일이 세션 도중에 기본 목소리로 되돌아가던 버그 수정이 들어갔습니다. 출력 스타일 자체를 손보는 작업이 한 주 내내 계속됐다는 뜻입니다. v2.1.239에서는 사용량 한도 안내가 세션, 주간, 월간 중 무엇이 초기화되는지 구분해 알려 주게 바뀌었습니다.

어떤 스타일로 쓸까​

정답은 작업 성격에 달렸습니다. 제 기준으로는 이렇게 갈립니다.

익숙한 코드베이스에서 반복 작업을 돌릴 때는 Concise가 맞습니다. 무엇을 할지 이미 알고 있으니 예고가 필요 없습니다. 처음 보는 코드베이스를 파악하는 중이라면 Explanatory가 낫습니다. "왜 이 파일을 골랐나"가 정보이기 때문입니다. 새 기술을 배우려고 붙었다면 Learning이 값을 합니다. TODO(human) 표시가 남으면 직접 손을 대야 하고, 그 지점이 대개 판단이 필요한 자리입니다.

Proactive는 조심스럽습니다. 권한 모드를 안 건드린다지만 "묻지 말고 판단하라"는 지침 자체가 리스크입니다. 되돌리기 쉬운 작업에만 쓰는 쪽이 안전합니다.

그리고 이 다섯 개는 서로 배타적입니다. 한 세션에 하나만 걸립니다. 작업 성격이 바뀌면 /clear하고 다시 고르는 게 정석입니다.

참고​

• Claude Code CHANGELOG
• Output styles 공식 문서
• Permission modes 공식 문서

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

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

세 조각이 각각 맡는 일​

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

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

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

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

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

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

지원 모델이 갈립니다. computer_toolset_20260801은 claude-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개입니다.

zoom이 눈에 띕니다. 지정한 영역을 원본 해상도로 다시 캡처합니다. 전체 화면 스크린샷은 축소되어 작은 글자를 놓치기 쉬운데, 그 문제를 영역 재촬영으로 풉니다. hold_key와 wait는 최대 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_id와 content만 채우면 통과하지 않습니다.

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

{
  "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의 출처는 네 종류로 구분됩니다.

요청에 붙이는 방법에서 혼동이 잘 생깁니다. 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.create에 container와 코드 실행 도구를 얹으면 끝입니다. 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를 켜는 쪽이 낫다고 봅니다.

참고​

• computer use, Skills API, Files API 정식 출시 발표 (2026-08-20)
• computer use tool 공식 문서
• Skills API 레퍼런스

같은 작업을 시켰는데 어떤 날은 사용량이 순식간에 닳고 어떤 날은 널널했던 경험, 있으실 거예요. 저도 한도에 일찍 닿은 날마다 모델 탓을 했는데, Anthropic이 8월 14일에 낸 공식 가이드를 읽고 나니 범인은 따로 있었습니다. 프롬프트 캐시를 깨는 습관입니다.

요금의 실체는 캐시 히트율​

Claude Code는 매 턴마다 지금까지의 대화 전체를 모델에 보냅니다. 대화가 길어질수록 매 요청의 입력이 커지는 구조인데, 이게 감당되는 이유가 프롬프트 캐시입니다. 직전 요청과 같은 prefix는 캐시에서 읽고, 캐시 읽기 요금은 정상 입력 가격의 0.1배입니다. 반대로 캐시에 새로 쓰는 비용은 최대 2배입니다.

즉 20배짜리 요금 격차가 대화 내내 작동합니다. 캐시가 살아 있으면 긴 대화도 턴당 비용이 낮게 유지되고, 캐시가 깨지면 대화 전체를 정상 가격으로 다시 보내며 다시 캐시 쓰기 할증까지 뭅니다. Claude Code의 캐시 유효 시간은 1시간입니다(API 직접 호출 기본은 5분).

캐시를 깨는 행동들​

가이드가 지목하는 캐시 무효화 요인은 네 가지입니다.

여기서 실무 결론이 나옵니다. 모델과 effort는 세션 시작 시점이나 /clear 직후에 정하고, 대화 중간에는 건드리지 않는 것입니다. 긴 대화 한가운데서 /model을 바꾸면 그 시점까지의 대화 전체가 새 모델 기준으로 재처리되고 재캐싱됩니다. "이 질문만 가볍게 다른 모델로" 하려던 절약이 실제로는 가장 비싼 행동이 되는 역설입니다.

한 시간 자리를 비울 때도 마찬가지입니다. 돌아와서 이어 쓰면 만료된 캐시를 처음부터 다시 씁니다. 가이드는 장시간 중단 전에 /compact를 실행하라고 권합니다. 캐시가 아직 유효할 때 요약해 두는 쪽이 싸기 때문입니다.

문맥 관리 명령 셋의 역할 분담​

/clear, /compact, /rewind가 비슷해 보여도 캐시 관점에서 역할이 다릅니다.

• /clear: 새 작업을 시작할 때. 이전 작업의 문맥은 다음 작업에서 전부 "돈 내고 실어 나르는 짐"이 되므로, 작업 사이에는 비우고 시작합니다
• /compact: 문맥은 이어가야 하는데 대화가 너무 길어졌거나, 장시간 자리를 비우기 직전에
• /rewind: 마지막 몇 턴만 무르고 싶을 때. 캐시를 무효화하지 않는 것이 장점입니다

저처럼 한 세션에서 이 일 저 일 이어 하던 사람에게는 /clear가 제일 아픈 항목입니다. "혹시 아까 맥락이 필요할지 몰라서" 남겨 둔 문맥이 매 턴 입력 토큰으로 청구되고 있었으니까요.

입력을 줄이는 잔기술​

캐시 다음으로 효과가 큰 항목은 문맥에 들어오는 양 자체를 줄이는 것입니다.

파일은 @멘션으로 첨부합니다. src/main.py 읽어 봐라고 쓰면 모델이 Read 도구를 호출하는 왕복이 생기는데, @src/main.py로 멘션하면 파일이 첫 요청에 바로 첨부됩니다. 도구 호출 한 번과 그 결과 처리가 통째로 절약됩니다.

시끄러운 명령 출력은 서브에이전트로 격리합니다. 30,000자를 넘는 명령 출력은 자동으로 파일로 저장되고 미리보기만 문맥에 남습니다만, 그 미만의 장황한 출력(테스트 로그, 빌드 로그)은 고스란히 문맥을 차지합니다. 로그를 뒤져야 하는 작업은 독립 문맥에서 도는 서브에이전트에 맡기면 메인 세션이 가벼워집니다.

자주 쓰는 명령은 CLAUDE.md에 조용한 플래그와 함께 적어 둡니다. 예를 들어 테스트를 verbose로 돌리는 습관이 있다면, CLAUDE.md에 quiet 플래그가 붙은 명령을 기록해 모델이 처음부터 조용한 버전을 실행하게 하는 식입니다.

가이드가 제시한 우선순위는 이렇습니다. 불필요한 파일 읽기 방지, 긴 세션 분할, 모델/effort 고정, 명령 출력 최소화 순입니다.

이 가이드가 나온 맥락​

읽다 보면 이 가이드는 절약 팁 모음이라기보다 과금 구조 설명서에 가깝습니다. 에이전트형 코딩 도구의 비용은 "몇 마디 나눴나"가 아니라 "문맥 몇 토큰을 몇 번 실어 날랐나"로 결정되는데, 사용자 대부분은 전자로 체감합니다. 그 간극에서 "왜 벌써 한도냐"는 불만이 나오고, 이 문서는 거기에 대한 공식 답변으로 보입니다.

도구 쪽 기본값도 같은 방향으로 움직이고 있습니다. 최근 릴리스에서 서브에이전트 포크가 캐시를 상속하게 된 것도, 포크할 때마다 문맥을 다시 캐싱하는 비용을 없애는 변경입니다. 캐시를 아끼는 방향으로 도구가 정렬되고 있으니, 사용자 습관만 따라가면 됩니다.

오늘부터 바꿀 것 하나만 고르라면 저는 "작업 끝나면 /clear"를 고르겠어요. 제일 쉽고, 제일 큽니다.

참고 자료​

• Maximizing the value of your Claude Code sessions - Claude Blog, 2026-08-14
• Claude API 프롬프트 캐싱 문서

터미널 두 개에 Claude Code를 띄워 놓고 한쪽 결과를 복사해서 다른 쪽에 붙여넣던 시절이 있었어요. 이번 주 릴리스로 그 복붙이 공식적으로 필요 없어졌습니다.

2.1.232 changelog의 첫 두 줄이 핵심입니다. 서브에이전트 포크가 기본 활성화됐고, 프롬프트에서 @를 입력하면 다른 세션을 이름으로 직접 부를 수 있습니다. 따로 보면 각각 작은 기능인데, 합치면 "세션 하나 = 작업 하나"라는 전제가 무너집니다.

포크: 문맥을 통째로 물려받는 서브에이전트​

기존 서브에이전트의 약점은 기억상실이었습니다. 새 에이전트는 빈 문맥에서 출발하니, 지금까지 대화에서 쌓인 맥락을 프롬프트에 꾹꾹 눌러 담아 전달해야 했습니다. 전달이 부실하면 엉뚱한 결과가 돌아왔습니다.

subagent_type: "fork"로 뜨는 포크 에이전트는 부모의 대화 전체와 프롬프트 캐시를 상속합니다. 지금까지 읽은 파일, 내린 결정, 사용자가 준 피드백을 전부 아는 상태로 출발합니다. 캐시까지 물려받으니 그 문맥을 다시 처리하는 비용도 들지 않습니다.

함께 바뀐 기본값이 하나 더 있습니다. 대화형 세션에서 띄우는 에이전트는 이제 배경 실행이 기본입니다. 에이전트가 도는 동안 메인 세션이 멈춰 기다리지 않고, 끝나면 알림으로 결과가 돌아옵니다. 에이전트의 도구 호출 로그가 메인 문맥을 차지하지도 않습니다. 정리하면 "무거운 조사나 검증은 포크로 떼어 배경에서 돌리고, 메인은 계속 진행한다"가 이제 설정 없이 되는 기본 동작입니다.

@멘션: 세션끼리 직접 대화​

두 번째 변화는 세션 간 통신입니다. 프롬프트에 @를 입력하면 같은 머신에서 돌고 있는 다른 Claude 세션 목록이 뜨고, 이름을 고르면 그 세션으로 메시지가 갑니다. 내부적으로는 SendMessage 도구를 사용합니다.

이걸 받쳐 주는 손질도 같이 들어갔습니다.

• 이름이 정확히 하나의 살아 있는 세션과 일치하면 확인 절차 없이 바로 전달됩니다
• 한 머신의 대화형 세션들은 고유한 이름을 유지합니다. 이미 쓰는 이름으로 시작하면 자동으로 변형된 이름을 받습니다
• /config에 다른 세션에서 오는 메시지를 받을지(수락/보류/거부) 정하는 항목이 생겼습니다

블로그 작업으로 예를 들면 이렇게 됩니다. 포스트 A를 쓰는 세션과 포스트 B를 쓰는 세션을 나란히 띄워 두고, A 세션에서 @세션B 방금 정한 용어 표기를 너도 맞춰 줘라고 보내면 끝입니다. 사람이 두 터미널 사이에서 전서구 노릇을 할 필요가 없습니다. 지시는 각 세션에 직접 하되, 세션끼리 맞출 것은 세션끼리 맞추게 하는 구조입니다.

Opus 4.8 리뷰에서 "한 사람에게 맡기던 일을 한 팀에게 맡긴다"고 썼는데, 이번 릴리스는 그 팀에게 사내 메신저를 지급한 셈입니다. Dynamic Workflows가 한 세션 안의 수직 분업이라면, @멘션은 세션 사이의 수평 분업입니다.

2.1.233: worktree의 GitLab MR, cgroup 메모리 제한​

다음 날 나온 2.1.233에서 운영 관점의 항목 둘이 눈에 띕니다.

GitLab 지원 확대. --worktree 플래그와 claude agents 뷰가 GitLab merge request URL을 인식합니다(MR은 !N으로 표시). 2.1.232에서 이미 GitLab 토큰 계열(glpat- 등) 시크릿 마스킹과 GitLab 플러그인 마켓플레이스 지원이 들어왔으니, 이틀 사이에 GitLab 사용자 대접이 눈에 띄게 좋아졌습니다. GitHub 전용이라 망설이던 조직에는 신호가 될 만합니다.

Bash 도구 메모리 제한. Linux에서 CLAUDE_CODE_TOOL_MEMORY_LIMIT 환경변수로 Bash 명령에 cgroup 메모리 제한을 걸 수 있습니다(opt-in). 에이전트가 실행한 빌드가 폭주해 메모리를 삼키면 세션까지 같이 죽던 문제의 대응입니다. CI 러너나 공용 개발 서버에서 Claude Code를 돌리는 환경이라면 켜 둘 가치가 있습니다.

하나 더, 방향을 보여주는 항목이 있습니다. Opus 4.8과 그 이후 모델에서 todo/task 추적 도구(TodoWrite, TaskCreate 등)가 기본 비활성화됐습니다. 되살리려면 CLAUDE_CODE_ENABLE_TODO_TOOLS=1을 설정해야 합니다. 신형 모델은 할 일 목록을 도구로 관리시키지 않아도 작업을 놓치지 않는다는 판단이 깔린 변경입니다. 화면에서 todo 목록이 사라졌다면 버그가 아니라 이 변경입니다.

써 보고 느끼는 것​

이 글을 쓰는 세션도 뉴스 수집을 포크 에이전트 여섯에 나눠 맡기고, 결과를 메시지로 돌려받는 흐름으로 작업했습니다. 수집 에이전트들이 배경에서 도는 동안 메인 세션은 기존 포스트 목록을 정리했고, 끝난 에이전트부터 결과가 도착했습니다. 복붙도, 파일 경유도 없었습니다.

체감 요령을 남기면, 포크에는 "지금까지의 문맥이 필요한 일"을, 일반 서브에이전트에는 "문맥이 오히려 편견이 되는 일"(백지 검증, 독립 리뷰)을 맡기는 구분이 유효했습니다. 포크가 기본이 됐다고 전부 포크로 보낼 일은 아니에요. 문맥 상속은 힘이면서 동시에 선입견이니까요.

참고 자료​

• Claude Code CHANGELOG (2.1.232, 2.1.233) - Anthropic, 2026-08-13~14
• Claude Code 공식 문서

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 서버 때도 같은 이야기를 했습니다). 그때 계정과 권한을 직접 주는 대신, 좁게 정의된 관문 계층을 사이에 두는 설계가 표준이 될 가능성이 큽니다. 미리 그려 두면 요청이 왔을 때 당황하지 않을 수 있어요.

참고 자료​

• Agents Week 2026 회고 - Cloudflare Blog, 2026-08-07
• Cloudflare OS: an open platform for agents, apps, and work - Cloudflare Blog, 2026-08-04
• Announcing Cloudflare Wallets - Cloudflare Blog, 2026-08-04
• How Cloudflare detects MCP traffic and helps secure it - Cloudflare Blog, 2026-08-14

코딩 에이전트 도입 논의가 보안 검토에서 멈추는 조직, 많죠. 코드는 사내망 밖으로 못 나간다는 원칙과, 에이전트 세션은 벤더 클라우드에서 돈다는 현실이 부딪히는 지점이에요.

Anthropic이 8월 6일 퍼블릭 베타로 공개한 self-hosted environments는 정확히 그 지점을 겨냥합니다. 웹, 모바일, 데스크톱에서 시작하는 Claude Code 클라우드 세션의 실행 환경을 조직이 제공한 머신으로 바꿉니다. 저장소 체크아웃, 빌드 산출물, 시크릿, 세션이 만들거나 수정하는 모든 파일이 조직 인프라 안에 남습니다.

구조: runner라는 상주 프로세스​

동작 단위는 runner입니다. claude self-hosted-runner로 띄우는 장수(long-lived) 프로세스로, 세션 하나가 시작되면 runner 하나가 그 세션의 Claude Code 실행을 맡습니다. 운영 모드는 두 가지입니다.

CI 러너를 운영해 본 조직이라면 구조가 낯설지 않을 겁니다. GitHub Actions의 self-hosted runner와 개념이 같고, 이름도 같습니다. 사내 Kubernetes에 runner 풀을 두고 세션을 받는 그림이 자연스럽게 그려집니다.

기존 Remote Control과의 차이도 여기 있습니다. Remote Control은 특정 개인의 머신에 세션을 묶는 기능입니다. self-hosted environments는 조직 공용 인프라에 세션을 올리고, 권한 있는 누구든 쓸 수 있습니다. 개인의 원격 제어와 조직의 실행 기반이라는 층위 차이입니다.

무엇이 남고, 무엇이 나가나​

이 기능을 검토할 보안 담당자가 볼 핵심은 경계선입니다.

사내에 남는 것: 저장소 체크아웃, 빌드 산출물, 시크릿, 세션이 만들고 수정하는 파일 전부. 코드가 Anthropic의 실행 환경에 복제되지 않습니다.

여전히 Anthropic으로 가는 것: 대화 데이터입니다. 프롬프트, 응답, 도구 실행 결과는 모델 추론을 위해 전송되고, 세션 transcript는 여러 기기에서 이어 쓰기 위해 저장됩니다. 도구 실행 결과에는 코드 조각이 포함될 수 있으니, "코드가 한 줄도 안 나간다"는 이해는 정확하지 않습니다. 나가는 것은 모델이 보는 문맥이고, 남는 것은 파일시스템과 실행 환경입니다.

조건도 명확합니다. Team과 Enterprise 플랜 전용이고, ZDR(zero data retention) 계약 조직은 현재 쓸 수 없습니다. transcript 저장이 기능의 전제라서 생기는 제약으로 보입니다. 그리고 공식 문서가 셋업과 유지보수에 전담 엔지니어링 인력이 필요하다고 미리 말해 둡니다. 켜면 되는 토글이 아니라 운영해야 하는 인프라입니다.

어떤 조직에 의미가 있나​

이 기능이 풀어 주는 매듭은 두 종류입니다.

첫째, 컴플라이언스 매듭입니다. 소스코드의 물리적 위치를 통제해야 하는 조직(금융, 공공, 계약상 제약이 있는 곳)은 지금까지 클라우드 세션 자체가 선택지 밖이었습니다. 실행 환경이 사내로 들어오면 검토의 성격이 "코드를 외부에 두어도 되는가"에서 "대화 데이터 전송을 허용하는가"로 좁혀집니다. 후자는 이미 API 사용 승인과 같은 범주라 통과 경로가 있는 조직이 많습니다.

둘째, 환경 매듭입니다. 빌드에 사내 아티팩트 저장소, 내부 DNS, VPN 안쪽 서비스가 필요한 프로젝트는 벤더가 제공하는 격리 환경에서 애초에 빌드가 안 됩니다. runner가 사내망에 있으면 이 문제가 사라집니다.

베타답게 다듬는 중인 흔적도 보입니다. 바로 다음 릴리스(2.1.233)에서 runner의 세션 시작 시간을 줄이는 개선(working tree 재작성 없는 브랜치 생성, 서버 왕복 2회 제거)이 들어왔습니다.

개인 사용자에게는 당장 해당 없는 기능이지만, 방향은 기억해 둘 만해요. 에이전트가 개인 도구에서 조직 인프라로 올라가는 단계마다 이런 부품이 하나씩 채워지고 있고, self-hosted runner는 그중 꽤 큰 조각입니다.

참고 자료​

• Run Claude Code sessions on your own compute - Claude Blog, 2026-08-06
• Claude Code CHANGELOG

요즘 이런 도구가 쏟아진다​

최근 몇 달 사이 herdr, Orca, cmux, Claude Squad 같은 이름을 부쩍 자주 봐요. 전부 "AI 코딩 에이전트 여러 개를 한 번에 굴리는 도구"라는 소개를 달고 나오는데, Claude Code나 Codex를 하나만 돌려도 벅찬 터라 여러 개를 동시에 관리한다니 눈길이 갈 만해요.

그런데 목록을 훑다 보면 이상한 질문이 머리에 떠오릅니다. "저는 Ghostty를 쓰는데, herdr로 갈아타야 하나?" "tmux를 버리고 cmux를 깔아야 하나?" 저도 처음엔 그렇게 물었습니다. 결론부터 말하면 이건 잘못 세운 질문입니다. Ghostty와 herdr는 애초에 경쟁 관계가 아니며, 서로 다른 층에서 다른 일을 합니다.

이 글은 그 착각을 푸는 지도입니다. 도구를 나열하기보다, 이 도구들이 각각 어느 층에 사는지를 먼저 나눕니다. 층을 나누고 나면 "뭘 써야 하나"라는 질문이 "지금 제 환경에서 어느 층이 비어 있나"로 바뀝니다. 그게 훨씬 답하기 쉬운 질문입니다.

왜 다들 같은 칸에 있는 것처럼 보이나​

착각의 원인은 단순합니다. 이 도구들이 대부분 터미널에서 도는 CLI 형태라서, 겉보기에 다 비슷해 보입니다. 검은 화면에 글자가 흐르고, 키보드로 조작하고, 이름도 -mux로 끝나는 게 많습니다. 그래서 한 바구니에 담아 놓고 "이 중에 뭐가 제일 좋냐"를 따지게 됩니다.

하지만 실제로는 역할이 완전히 다릅니다. 어떤 건 화면을 그리는 일을 하고, 어떤 건 그 화면을 여러 칸으로 쪼개는 일을 하고, 어떤 건 그 칸 안에서 도는 에이전트들을 관리하는 일을 합니다. 모니터와 화면 분할기와 작업 반장을 놓고 "셋 중 뭐가 제일 좋냐"를 묻는 셈이라, 질문 자체가 성립하지 않습니다.

3개 층으로 나눈다​

정리하면 층은 세 개입니다. 위에서 아래로 갈수록 더 안쪽에서 돕니다.

1층은 터미널 에뮬레이터입니다. 화면에 글자를 그리는 앱이고, 폰트와 색과 렌더링 속도가 승부처입니다. Ghostty, iTerm2, Alacritty가 여기 있습니다. 이 층은 에이전트를 "관리"하지 않습니다. 그냥 잘 보여줄 뿐입니다.

한 칸 아래가 멀티플렉서입니다. 터미널 하나 안을 여러 세션으로 쪼개고, 터미널을 닫아도 세션을 살려 둡니다. SSH가 끊겨도 작업이 죽지 않게 하는 게 이 층의 존재 이유입니다. tmux가 사실상 표준이고, Zellij가 Rust로 다시 쓴 현대판입니다. 다만 창을 나눠 줄 뿐, 그 창 속 에이전트가 일하는 중인지 끝났는지는 알지 못합니다.

가장 안쪽 3층이 이번 글의 주인공입니다. 에이전트마다 별도의 작업 공간을 만들어 서로 부딪치지 않게 격리하고, 각 에이전트의 상태를 추적하고, 결과 diff를 보여줍니다. herdr, cmux, Orca, Claude Squad가 여기 있습니다.

3층이 왜 필요한지는 한 문장으로 설명됩니다. 코딩 에이전트는 작업 디렉토리를 통째로 자기 것으로 쓸 때 가장 잘 동작합니다. 그런데 에이전트 둘이 같은 디렉토리를 동시에 만지면 서로의 편집을 뭉개고, 빌드가 깨지고, git 상태가 엉킵니다. 이런 충돌을 피하려고 3층 도구들은 하나같이 git worktree로 각 에이전트에게 독립된 체크아웃을 줍니다.

1층과 2층: 바탕이 되는 도구​

3층 이야기로 넘어가기 전에, 바탕 두 층을 짧게 정리합니다. 이 층은 3층 도구와 경쟁하지 않고 함께 씁니다. 제가 즐겨 쓰는 Ghostty도 여기 있습니다.

Ghostty는 GPU로 화면을 그려서 빠르고, 설정이 간결합니다. 요즘 새로 나오는 에이전트 도구 중 일부는 아예 이 Ghostty의 렌더링 엔진을 자기 기반으로 삼으며, 뒤에 나올 cmux가 그렇습니다. 이 사실 하나만 알아도 "Ghostty와 cmux 중 뭘 쓰지"라는 질문이 왜 이상한지 감이 옵니다. cmux가 Ghostty 위에 지어졌으니, 둘 중 하나를 고르는 문제가 애초에 성립하지 않습니다.

3층: 에이전트 오케스트레이터​

이제 본론입니다. 3층 도구들을 순수 사양만 표로 정리했습니다. 어느 게 더 좋은지는 표 아래 산문으로 따로 풀었습니다. 도구마다 성격이 달라서 한 줄로 우열을 매기는 게 오히려 오해를 부릅니다.

표의 "상태 인지"는 tmux처럼 창만 나누는 데서 그치지 않고, 각 에이전트가 지금 일하는 중인지 끝났는지 입력을 기다리는지까지 도구가 안다는 뜻입니다. 이게 3층을 2층과 갈라 놓는 결정적 차입니다. herdr가 멀티플렉서라고 소개되면 tmux 대체품처럼 들리지만, 실제로는 에이전트 상태를 아는 멀티플렉서라 2층과 3층에 걸쳐 있습니다.

크게 두 갈래로 나뉩니다. 터미널 안에서 도는 가벼운 쪽(herdr, Claude Squad, dmux, cmux)과, 자체 창을 띄우는 무거운 데스크톱 쪽(Orca, Parallel Code, Emdash)입니다. 데스크톱 쪽은 내장 브라우저로 에이전트가 만든 화면을 바로 확인하거나, diff에 코멘트를 달아 에이전트에게 되돌려 주는 기능을 얹습니다. 대신 앱이 무겁고, 원격 리눅스 서버에서는 쓰기 어렵습니다. 표에 다 넣지는 않았지만 wmux(cmux의 Windows 포팅), Termdock(세션별 CPU/메모리 모니터), amux 같은 것도 같은 계보에 있습니다.

착각하기 쉬운 세 지점​

층을 나누고 나서도 개별 도구에서 헷갈리는 대목이 몇 개 남습니다.

첫째, cmux는 이름이 같은 도구가 둘입니다. 하나는 manaflow-ai가 만든 Ghostty 기반 macOS 앱이고, 다른 하나는 craigsc의 "tmux for Claude Code"라는 셸 스크립트입니다. 검색하면 둘이 섞여 나옵니다. 성격이 꽤 다르니 저장소 주소를 보고 구분하는 게 안전합니다.

둘째, Orca 같은 데스크톱 앱은 자체 터미널 렌더링을 내장합니다. 그래서 Orca를 쓰면 Ghostty를 거치지 않습니다. "Ghostty에서 Orca를 띄운다"기보다 "Orca가 Ghostty 자리를 대신한다"에 가깝습니다. 앞의 3층 도구들이 대부분 기존 터미널 위에 얹히는 것과 다른 지점입니다.

셋째, 가장 흔한 오해인데, 3층 도구가 없어도 병렬 작업은 이미 가능합니다. Claude Code에는 Agent Teams라는 기능이 내장되어 있어서, 서브에이전트를 병렬로 띄우고 각자 worktree에 격리합니다. 새 도구를 깔기 전에 이미 손에 있는 걸 먼저 써 보는 게 순서입니다.

제 환경이라면 이렇게 고릅니다​

여기부터는 사양 비교를 넘어 선택의 문제로 들어갑니다. 제 작업 환경은 두 갈래입니다. 로컬은 macOS에 Ghostty, 원격은 리눅스 서버에 SSH로 붙습니다. 층으로 나눠 놓으니 각 환경에서 뭘 얹을지가 명확해집니다.

로컬 macOS에서는 cmux(manaflow-ai)가 가장 자연스러운 후보입니다. 이미 쓰는 Ghostty의 렌더링을 그대로 두고 그 위에 사이드바와 알림만 얹는 구조라, 기존 환경을 버릴 필요가 없습니다. 오케스트레이터라기보다 여러 에이전트를 나란히 두는 최소한의 장치라서, Claude Code를 쓰던 방식을 강제로 바꾸지 않는 점도 저는 마음에 들어요.

원격 서버에서는 사정이 다릅니다. macOS 앱은 당연히 못 씁니다. 여기서는 herdr나, 이미 쓰고 있는 tmux 위에 Claude Squad를 얹는 쪽이 맞습니다. herdr는 SSH로 붙어서 세션을 유지하고 휴대폰에서 재접속하는 시나리오에 강합니다. 다만 tmux를 이미 손에 익혔다면 Claude Squad로 넘어가는 이행 비용이 더 낮습니다. 익숙한 2층 위에 3층만 얹는 그림이기 때문입니다.

솔직히 덧붙이면, 저는 지금 당장 급하지는 않다고 봅니다. 제 작업은 대부분 글을 쓰거나 문서를 다듬는 일이라, 에이전트를 다섯 개씩 병렬로 굴려야 하는 순간이 매일 오지는 않습니다. worktree 격리가 절실해지는 건 서로 독립적인 작업을 진짜로 동시에 여러 개 돌릴 때입니다. 그 순간이 오기 전까지는 Claude Code의 Agent Teams로 충분하고, 필요가 분명해지면 그때 로컬은 cmux, 원격은 herdr로 넘어가면 됩니다.

도구를 고르기 전에 층을 묻는다​

이 바닥은 변화가 빠릅니다. 이 글을 쓰는 지금(2026년 7월)에도 새 도구가 계속 나오고, 이름과 기능이 겹치고, 어제의 추천이 오늘 바뀝니다. 그러니 개별 도구 이름을 외우는 것보다, 새 도구를 만났을 때 "이건 몇 층 도구지"를 먼저 묻는 습관이 오래갑니다.

터미널을 바꾸고 싶은 건지, 세션 관리를 원하는 건지, 에이전트를 여러 개 굴리고 싶은 건지 생각해 봐야 해요. 이 세 가지는 서로 다른 문제이고 답도 다른 층에 있지만, 지도를 손에 쥐고 나면 쏟아지는 도구 목록이 위협이 아니라 그저 선택지로 보여요.

입력창이 더는 안 흔들린다​

Claude가 작업하는 동안 화면이 번쩍이고, 출력이 쏟아질 때 스크롤이 맨 위로 튀어 오르고, 긴 세션에서 메모리가 슬금슬금 차오르던 경험은 Claude Code를 오래 쓴 사람이면 익숙해요. Fullscreen 렌더링은 그 세 가지를 한 번에 잡으려고 나온 새 렌더링 경로로, 대화를 vim이나 htop처럼 터미널의 alternate screen buffer에 그려요.

/tui fullscreen 한 줄이면 켜집니다. 대화는 그대로 유지된 채 fullscreen으로 다시 뜹니다. 세션 중간에 켜도 맥락을 잃지 않습니다. Claude Code v2.1.89 이상에서 동작하는 리서치 프리뷰 기능입니다. (Fullscreen 렌더링 공식 문서)

주의: 이 글은 전부 리서치 프리뷰 기준입니다. 동작 방식, 키 바인딩, 설정 키 이름 모두 정식 출시 전에 바뀔 수 있습니다.

fullscreen은 창 최대화가 아닙니다​

먼저 오해부터 풀고 갑니다. 여기서 fullscreen은 터미널 창을 최대화한다는 뜻이 아닙니다. Claude Code가 터미널의 그리는 표면(drawing surface)을 vim처럼 통째로 가져간다는 뜻입니다. 창 크기와 무관하게, 작은 창에서도 똑같이 동작합니다.

기존 렌더러(classic)는 대화를 터미널의 native scrollback에 차곡차곡 쌓습니다. 매 업데이트마다 화면을 다시 그리면서 터미널로 많은 데이터를 흘려보냅니다. Fullscreen은 다릅니다. 지금 화면에 보이는 메시지만 렌더 트리에 둡니다. 터미널로 보내는 데이터량이 확 줄어듭니다.

깜빡임, 메모리, 스크롤 점프를 줄입니다​

세 가지 문제를 노립니다.

차이가 가장 크게 느껴지는 곳은 렌더링 처리량(throughput)이 병목인 터미널입니다. 공식 문서는 VS Code 통합 터미널, tmux, iTerm2를 콕 집습니다. 이런 환경에서 화면이 번쩍이거나 스크롤이 튀었다면 fullscreen이 정확히 그 증상을 겨냥합니다.

켜고 끄는 법​

가장 쉬운 방법은 대화 안에서 슬래시 명령을 실행하는 것입니다.

/tui fullscreen   # fullscreen 렌더링으로 전환 (대화 유지된 채 재시작)
/tui default      # classic 렌더러로 복귀
/tui              # 인자 없이 실행하면 현재 어떤 렌더러인지 출력

/tui 명령은 tui 설정을 ~/.claude/settings.json에 저장하고 그 값으로 다시 띄웁니다. 그래서 다음 세션에도 선택이 유지됩니다.

환경 변수로 켤 수도 있습니다. /tui 명령이 생긴 v2.1.110 이전 버전에서는 이쪽이 유일한 방법이었습니다.

CLAUDE_CODE_NO_FLICKER=1 claude

tui 설정과 CLAUDE_CODE_NO_FLICKER 환경 변수는 같은 의미입니다. /tui 명령은 재시작하는 프로세스에서 CLAUDE_CODE_NO_FLICKER를 지워, 새로 쓴 설정 값이 우선 적용되게 합니다.

fullscreen이 켜졌는지 확인하는 가장 직관적인 신호는 입력창입니다. 출력이 쏟아져도 입력창이 화면 하단에 고정돼 움직이지 않으면 fullscreen이 동작 중입니다. classic 렌더러에서는 입력창이 출력을 따라 위로 밀려 올라갑니다.

두 렌더러는 어디서 갈리나​

대화가 어디에 저장되느냐가 갈림길입니다. 그 한 가지 차이에서 검색/복사 동작이 전부 달라집니다.

대화가 alternate screen buffer에 살기 때문에, 터미널의 native scrollback에 의존하던 동작이 달라집니다.

마우스가 붙는다​

Fullscreen은 마우스 이벤트를 캡처해 Claude Code 안에서 처리합니다. classic 렌더러에는 없던 기능입니다.

입력창을 클릭하면 입력 중인 텍스트의 원하는 위치로 커서가 옮겨집니다. / 명령이나 @ 파일 목록에서는 제안 항목을 클릭으로 바로 고르고, 호버하면 해당 행이 강조됩니다. 권한 프롬프트나 /model//config 같은 select 메뉴도 클릭으로 선택할 수 있습니다(v2.1.187 이상). 접힌 tool 결과를 클릭하면 펼쳐서 전체 출력을 보고, 다시 클릭하면 접힙니다. URL이나 파일 경로는 Cmd(macOS)/Ctrl(Linux/Windows)를 누른 채 클릭하면 링크는 브라우저로, 파일 경로는 기본 앱으로 열립니다. v2.1.181부터는 키 없이 그냥 클릭해도 링크가 열리지 않는데, native 터미널 동작에 맞춘 변경입니다. 이 밖에 드래그로 선택하고 휠로 스크롤하며, 더블클릭은 단어, 트리플클릭은 줄 단위로 선택합니다.

선택한 텍스트는 마우스를 떼는 순간 클립보드에 자동 복사됩니다. 이 동작이 거슬리면 /config에서 Copy on select를 끕니다.

스크롤과 검색​

스크롤도 앱 안에서 처리합니다. 주요 단축키는 다음과 같습니다.

MacBook처럼 PgUp/PgDn 전용 키가 없는 키보드는 Fn과 방향키를 조합합니다. Fn+↑이 PgUp, Fn+↓가 PgDn입니다.

위로 스크롤하면 auto-follow가 멈춰, 새 출력이 다시 맨 아래로 끌어내리지 않습니다. Ctrl+End를 누르거나 맨 아래로 내리면 다시 따라가기 시작합니다.

검색은 transcript 모드에서 합니다. Ctrl+o로 일반 프롬프트와 transcript 모드를 오갑니다. transcript 모드는 less 스타일 탐색을 지원합니다.

터미널의 Cmd+f나 tmux 검색은 대화를 보지 못합니다. 대화가 native scrollback이 아니라 alternate screen buffer에 있기 때문입니다. 내용을 터미널로 다시 넘기려면 Ctrl+o로 transcript 모드에 들어간 뒤 [를 누릅니다. 전체 대화가 native scrollback에 평범한 텍스트로 다시 쓰이고, 그때부터 Cmd+f/tmux copy mode가 다시 통합니다.

tmux와 함께 쓸 때​

Fullscreen은 tmux 안에서도 동작합니다. 세 가지만 주의합니다.

첫째, 마우스 휠 스크롤은 tmux의 mouse mode가 필요합니다. ~/.tmux.conf에 아래 한 줄을 넣고 설정을 다시 읽습니다. 없으면 휠 이벤트가 Claude Code 대신 tmux로 갑니다.

set -g mouse on

둘째, iTerm2의 tmux 통합 모드(tmux -CC)와는 호환되지 않습니다. 이 모드에서는 alternate screen buffer와 마우스 추적이 제대로 동작하지 않고, 더블클릭이 터미널 상태를 깨뜨릴 수 있습니다. tmux -CC 세션에서는 fullscreen을 켜지 않는 편이 좋습니다. -CC 없는 일반 tmux는 문제없습니다.

셋째, tmux는 synchronized output을 지원하지 않아, Claude Code를 터미널에서 바로 실행할 때보다 redraw 중 깜빡임이 더 보일 수 있습니다. SSH 환경에서 특히 거슬리면 tmux 밖 별도 탭에서 실행하는 편이 낫습니다.

native 선택을 그대로 두고 싶다면​

마우스 캡처는 가장 흔한 마찰 지점입니다. SSH나 tmux 안에서 특히 그렇습니다. Claude Code가 마우스 이벤트를 가져가면 터미널의 native copy-on-select가 멈춥니다. 드래그로 만든 선택은 Claude Code 안에만 있고, 터미널의 선택 버퍼에는 없습니다.

한 번만 native 선택을 쓰고 싶으면 터미널별 지정 키를 누른 채 드래그합니다. Terminal.app은 Fn, iTerm2는 Option, VS Code/Cursor는 Shift입니다.

마우스 캡처 자체가 늘 거슬린다면, 깜빡임 제거와 일정한 메모리는 유지하면서 마우스 캡처만 끌 수 있습니다.

CLAUDE_CODE_NO_FLICKER=1 CLAUDE_CODE_DISABLE_MOUSE=1 claude

이렇게 하면 PgUp, PgDn, Ctrl+Home, Ctrl+End 키보드 스크롤은 그대로 살고, 선택은 터미널이 native로 처리합니다. 대신 클릭으로 커서 옮기기, tool 결과 펼치기, URL 클릭, 앱 안 휠 스크롤은 포기해야 합니다.

DBA/개발자가 지금 해 볼 것​

긴 작업을 자주 돌리는 사람일수록 효과가 큽니다. 대형 리팩터링이나 수십 개 파일을 훑는 세션에서 classic 렌더러는 출력이 쌓이며 메모리가 늘고 스크롤이 튀지만, fullscreen은 일정하게 버팁니다.

일단 /tui fullscreen을 실행하고, 출력이 쏟아질 때 입력창이 고정되는지 봅니다. 안 맞으면 /tui default로 즉시 돌아오면 됩니다. VS Code, tmux, iTerm2 사용자라면 우선순위를 높게 둘 만한데, 깜빡임/스크롤 점프가 가장 심하던 환경이라 체감 차이가 큽니다. tmux를 쓴다면 set -g mouse on을 먼저 넣어야 휠 스크롤이 tmux로 새어 나가지 않습니다. 마지막으로 검색 습관을 바꿔야 합니다. Cmd+f 대신 Ctrl+o로 transcript 모드에 들어가 /로 찾고, 내용을 터미널로 넘기려면 그 안에서 [를 누릅니다.

복귀 경로가 명확한 것도 저는 안심돼요. /tui default로 돌아가거나, 저장된 설정과 무관하게 classic 렌더러를 강제하려면 CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1을 둡니다. agent view나 claude attach로 여는 백그라운드 세션은 항상 fullscreen으로 뜬다는 점만 기억하면 됩니다.

정리​

Fullscreen 렌더링은 Claude Code의 TUI를 vim/htop 계열로 한 단계 올립니다. alternate screen buffer를 써서 깜빡임이 사라지고 메모리가 일정해지며 마우스가 붙는 대신, 검색/복사는 앱 안 동작으로 바뀝니다. 손에 익히는 데 며칠 걸리지만, 긴 세션을 자주 돌리는 사람에게는 그만한 값을 합니다.

아직 리서치 프리뷰라서 흔치 않은 터미널이나 특이한 설정에서는 렌더링 문제가 생길 수 있고, 그럴 땐 /feedback이나 claude-code GitHub 저장소로 터미널 이름/버전과 함께 알리면 돼요. 동작이 바뀔 여지도 남아 있지만, 한 줄(/tui fullscreen)로 켜고 한 줄(/tui default)로 끄는 비용이면 한 번 켜 보고 판단하기에 충분히 싸요.

무엇이 나왔나​

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 Tag는 "채널에 함께 있는 팀원"에 가깝습니다.

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

권한과 거버넌스​

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

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

실무 활용과 한계/요금​

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

엔진은 Opus 4.8입니다. 수백 개의 subagent를 굴리는 동적 워크플로우를 얹은 그 모델이, 이번에는 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가 협업 도구 곳곳으로 번지는 흐름의 시작점으로 보는 게 맞아요.

참고 자료​

• Introducing Claude Tag — Anthropic
• Anthropic's Claude Tag is learning your company, one Slack message at a time — TechCrunch
• Claude Tag embeds Anthropic's AI in Slack, already writes 65 percent of internal code — The Decoder
• Anthropic launches Claude Tag, replacing its Slack app with a persistent AI teammate — VentureBeat
• Anthropic launches Claude Tag, a tool that works like a virtual employee within Slack — Fortune