1장. Claude 생태계가 왜 뜨거운가

1.1 왜 지금 다들 Codex, Claude Code, Gemini CLI를 같이 보는가

이름이 너무 많아서 막힌다. Claude Code, Codex, Gemini CLI가 왜 한꺼번에 언급되는지부터 헷갈린다.

지금 시장은 모델 성능 하나로 설명되지 않는다. 2026년 3월 23일 기준 Sonnet 4.6과 Opus 4.6은 중요한 기준점이다. 하지만 현장의 체감 변화는 모델 숫자보다 "AI가 어디까지 실제 일을 이어서 할 수 있는가"에 더 가깝다. 바이브 코딩(vibe coding)이 자주 언급되는 이유도 같다. 자연어 코딩에서 끝나지 않고 테스트, 검토, 리팩터링, 문서화, 업무 자동화까지 번졌다.

그래서 OpenAI, Anthropic, Google을 함께 본다. 경쟁 축이 "누가 더 똑똑한가"에서 "누가 파일·테스트·Git·브라우저·외부 도구·장기 세션을 더 잘 묶는가"로 옮겼다.

Claude Code를 중심에 두는 이유도 같다. 파일, 규칙, 권한, 검증, 재사용, 원격 이어받기, 외부 도구 연결, 팀 운영이 한 자리에 모여 있다. Cowork까지 같이 보면 그 흐름이 코딩 밖 업무로 어떻게 넓어지는지도 보인다.

연구 자료도 같은 결론이다. METR의 Time Horizons와 HCAST는 에이전트가 처리할 수 있는 과업 길이가 빠르게 늘고 있다고 말한다. 다만 긴 과업과 실제 맥락에서는 설정과 검증이 여전히 병목이다. Anthropic의 2026 Agentic Coding Trends Report도 같다. 격차는 모델 지식이 아니라 "누가 더 빨리 위임 규칙과 검증 하네스를 익혔는가"에서 벌어진다.

여기서 말하는 하네스는 복잡한 이론이 아니다. 먼저 Claude가 일하는 작업장 정도로 보면 된다. 동료에게 일을 맡길 때 책상에 참고 자료를 놓고, 출입 가능한 서랍을 정하고, 체크 항목을 붙여 두는 것과 같다. 어떤 파일을 읽게 할지, 어디까지 수정할지, 무엇을 확인한 뒤 끝낼지, 결과를 어디에 남길지를 묶어 둔 바깥 구조다.

모델이 강해질수록 "틀린 답"보다 "너무 넓게 고침", "검증 없이 끝냄", "건드리면 안 되는 파일까지 건드림"이 더 큰 문제가 된다. 실무에서는 모델보다 작업 범위와 검증선을 먼저 설계한다.

하네스는 실수를 줄이는 작업장 설계 정도로 잡아 두면 충분하다.

International AI Safety Report 2026을 같이 보면 한 가지가 분명해진다. 능력 상승이 곧바로 무인 위임으로 이어지지 않는다. 실제 현업은 리소스 제약, 불완전한 정보, 예외, 승인 절차가 붙는다. 능력 곡선이 가파를수록 하네스와 검증 구조가 더 중요해진다.

최근 많이 언급되는 AI 2027도 이 지점을 강하게 밀어 올린 시나리오다. 다만 이 자료는 관측 보고서보다 강한 가정을 많이 쓴 시나리오다. 날짜를 외우기보다 "왜 업계가 하네스, 승인, 보안, 평가 루프를 더 많이 이야기하는가"를 읽는 참고 틀로 두는 편이 낫다.

이 장에서 먼저 잡아 둘 작업 표면은 네 가지다.

사무실에 빗대면 이렇다. Chat은 상담 창구, Projects는 공용 배경 자료 캐비닛, Cowork는 문서와 결과물이 오가는 실무 책상, Claude Code는 공구와 검수표가 놓인 개발 작업대. 같은 Claude라도 어디에 앉히느냐에 따라 잘하는 일이 달라진다.

처음에는 네 표면을 새 앱 네 개로 보지 말고, 같은 동료를 서로 다른 책상에 앉힌 것으로 보면 쉽다. 상담 창구에 앉히면 질문에 강하고, 문서 책상에 앉히면 초안에 강하고, 개발 작업대에 앉히면 수정과 검증에 강해진다.

뒤에서 나오는 Skill, Plugin, MCP는 네 작업면을 더 잘 굴리기 위한 보조 장치다. Anthropic 릴리스 노트 기준으로 2025년 하반기 이후 Claude는 다음 순서로 확장됐다.

기억과 대화 지속성이 강화되면서 Claude는 "한 번 질문하고 끝"에서 "이어지는 작업"으로 이동했다. 그 다음엔 브라우저 확장, 파일 생성·편집, 화면 이해가 붙어 채팅창 밖 자료까지 다루기 시작했다. 이후 반복 작업 묶기와 팀 배포 기능이 붙었다. 2026년 들어 Cowork와 Claude Code가 각각 비개발 업무와 개발 업무의 작업면으로 더 선명해졌다. 큰 흐름은 "질문 도구 → 작업 도구 → 팀 운영 도구"다.

좋은 답변을 하는 모델에서 작업을 맡길 수 있는 실행 시스템으로 넘어가고 있다는 뜻이다.

2026년 3월 24일 기준 Computer Use의 공식 상태도 같이 보자. 이 기능은 claude.ai 채팅창의 일반 표면이 아니다. 상용 API 쪽의 베타 실행 도구에 가깝다. 최신 공식 문서는 computer-use-2025-11-24를 Opus 4.6, Sonnet 4.6, Opus 4.5용 기준선으로 두고 zoom 같은 새 행동을 붙이면서도, 전용 샌드박스와 사람 감독을 기본 전제로 설명한다.

1.2 2025-2026 주요 타임라인

Anthropic 공식 릴리스 노트를 바탕으로 정리했다. 날짜보다 "어떤 종류의 변화가 붙었는가"를 읽으면 된다.

이 다섯 흐름만 잡혀도 뒤에 나오는 제품 구분이 훨씬 쉽게 읽힌다.

2025년 9월부터 2026년 3월까지 무엇이 달라졌는가

2025년 가을에는 브라우저 이해, 파일 생성·편집, 멀티탭 작업이 붙었다. Claude가 답변 모델에서 작업 보조 도구로 이동했다. 겨울에는 Skills와 Agent Skills 공개 표준, Excel 연동, 긴 대화 압축, 예약 실행 흐름이 붙었다. 2026년 1분기에는 Cowork 연구 미리보기, Claude Code Team 포함, 플러그인 장터, 관리자 제어, Enterprise 분석 기능, Excel/PowerPoint 추가 기능, Cowork 지속 세션이 이어졌다. 제품 묶음이 작업공간 운영체계에 가까워졌다.

Anthropic이 준 건 더 똑똑한 모델만이 아니다. 계속 맡길 수 있고 재사용 가능한 작업 체계를 단계적으로 공급했다. 다만 가능성이 넓어졌다는 말과 모든 조직이 그걸 바로 소화한다는 말은 다르다.

2026년 2월 업데이트가 방향을 또렷하게 보여 준다. Cowork에 예약 실행 작업(scheduled tasks)이 들어왔다. Customize 화면에 skills, plugins, connectors를 한곳에 모았다. 플러그인 장터(plugin marketplace)와 Team/Enterprise용 관리자 제어가 공개됐다. 셀프서브 Enterprise와 Enterprise 요금제용 분석 API(Analytics API for Enterprise plans)도 붙었다. 개인 팁을 넘어서 팀 배포와 조직 측정의 운영층까지 Anthropic이 직접 다루기 시작했다.

3월 업데이트도 같은 흐름이다. Cowork 지속 세션은 데스크톱에서 돌고 있는 작업을 휴대폰에서 이어받는 흐름에 가깝다. Excel과 PowerPoint 추가 기능은 대화 문맥과 skills를 더 자연스럽게 잇는다. 무료 사용자까지 대화 이력 기반 기억 기능이 확대된 것도 같은 축이다.

왜 OpenClaw를 같이 봐야 하는가

OpenClaw는 경쟁 제품이라서 보는 게 아니다. 사용자가 이미 어떤 작업 방식을 원하고 있었는지 먼저 보여 준 사례다. OpenClaw 공식 문서는 하나의 중앙 허브 위에 세션, 채널 연결, 스케줄, 원격 접근, 여러 skill과 에이전트 라우팅을 함께 올려 둔다. 답변 모델 하나를 더 잘 부르는 도구가 아니라, 계속 켜 두고 여러 채널에서 불러 쓰며 상태를 이어 가는 작업 시스템에 가깝다.

Anthropic도 같은 수요를 다른 방식으로 흡수하고 있다. OpenClaw를 따라 한 게 아니라, OpenClaw 같은 시스템이 먼저 드러낸 사용자 수요를 자사 제품 철학과 거버넌스 모델에 맞는 여러 표면으로 나눠 제품화했다고 보는 편이 실제 흐름에 가깝다.

짧게 말하면 OpenClaw는 "에이전트를 어디서나 붙들고 계속 일시키고 싶다"는 수요를 먼저 보여 줬다. Anthropic은 그 수요를 원격 이어받기, 외부 이벤트, 시간 기반 재호출, 원격 비동기 실행, 역할 패키징처럼 더 잘게 나눠 제품화하고 있다. OpenClaw를 같이 보는 건 특정 브랜드를 따라 하는 게 아니라, 왜 Claude가 최근 이런 기능을 연달아 붙이는지 읽는 비교 기준이다.

이 흐름은 Claude만의 이야기가 아니다. 다른 AI 제품들도 검색 결과를 문서, 시트, 슬라이드로 바로 넘기거나, 디자인 결과를 개발 환경으로 직접 보낸다. 이미지 생성 기능도 광고와 협업 도구 안으로 들어왔다. 업계 전체가 "답변 창"에서 "작업공간"으로 이동하고 있다.

1.3 왜 지금 뜨거운가: 다섯 가지 구조적 이유

시장은 "누가 말을 잘하느냐"보다 "누가 일을 덜 끊기게 하느냐"를 더 크게 본다.

이유 5. 커뮤니티가 이미 실무 패턴을 축적하고 있다

공개 커뮤니티 자료를 보면 반복 패턴이 비슷하다. .claude/ 폴더와 CLAUDE.md를 운영 매뉴얼처럼 키운다. plan 파일, spec 파일, worktree(분리 작업 디렉터리), 병렬 세션으로 컨텍스트 손실을 줄인다. Hook으로 검증을 강제하고 Skill로 반복 작업을 명령화한다. 비개발자도 회계, 마케팅, 디자인, 리서치 업무를 Claude 중심으로 다시 엮고 있다.

이제 생태계를 단순 데모로 보기 어렵다. 실무 운영 습관이 생겼고 Anthropic도 공식 문서에 그런 패턴을 반영하고 있다.

이유 6. 기능 경쟁이 아니라 인프라 경쟁이기도 하다

제품 화면만으로 시장을 읽으면 중요한 절반을 놓친다. 실제 경쟁은 모델과 UI만의 경쟁이 아니다. 누가 더 큰 데이터센터를 짓고, 더 많은 전력과 냉각을 확보하고, 더 빠른 칩과 네트워크를 표준으로 만들고, 더 넓은 개발 생태계를 자기 스택 위에 올리는가의 경쟁이다.

미국은 GPU와 클라우드, 모델 생태계를 중심으로 표준을 선점하려 한다. 중국은 자립형 반도체와 모델 스택을 강화한다. 각국 정부와 기업은 데이터센터와 전력 확보를 국가 전략으로 다룬다. 이 흐름을 이해하면 Claude가 단순 소프트웨어 기능 묶음이 아니라 더 큰 인프라 경쟁 위의 작업 표면이라는 점이 분명해진다.

실무자에게도 직접적이다. 예전에는 "어떤 SaaS를 도입할까"가 질문이었다. 이제는 "어떤 모델 제공자와 어떤 인프라 위에서, 어떤 규칙과 비용 구조로 계속 운영할까"가 더 중요하다. 같은 기능도 가격, 지연시간, 컨텍스트 길이, 데이터 처리 정책, 기업용 관리, 국가별 규제 대응이 다르면 도입 판단이 달라진다.

더 들어가면 핵심은 이것이다. 시장이 뜨거운 이유는 "누가 더 말을 잘하느냐"에서 "누가 일을 덜 끊기게 하느냐"로 경쟁이 옮겨갔기 때문이다. 검색이 조사에서 끝나지 않고 문서와 슬라이드로 이어진다. 문서가 자동화와 보고로 넘어간다. 기획 메모가 코드 작업과 검증으로 연결된다. 사용자는 겉으로 모델 이름을 비교하는 것 같아도, 실제로는 "더 적은 탭 전환으로 더 많은 일을 끝낼 수 있는가"를 몸으로 평가한다.

**token economy(토큰 경제학)**도 같이 볼 필요가 있다. 젠슨 황이 말하는 AI factory를 사용자 쪽에서 풀면, 모델 기업과 클라우드 기업은 더 많은 토큰을 더 싸고 빠르게 처리하는 공장을 짓고 있는 셈이다. 실무자는 그 공장에서 계산 자원을 빌려 쓴다. 앞으로는 "어떤 모델이 좋나"만큼 "어떤 팀이 토큰을 덜 낭비하며 더 많이 끝내나"도 중요하다. 같은 모델로도 어떤 조직은 짧은 브리프와 작은 세션으로 일하고, 어떤 조직은 긴 대화와 중복 문맥으로 일한다. 겉은 같아 보여도 생산성이 크게 다르다.

1.4 Claude 제품군을 한 장으로 이해하기

초보자가 가장 먼저 헷갈린다. "Claude는 그냥 웹 채팅창 아닌가?" 공식 지원 문서부터 다르다. Claude는 하나의 창이 아니다. 채팅, 모바일, 데스크톱, API, 그리고 그 위에 얹히는 Cowork와 Claude Code가 한 계열에 들어와 있다.

제품 경계의 가장 짧은 구분

기술 독자라면 "정확히 어디까지가 Claude Code고, 어디까지가 Cowork인가"가 먼저 궁금할 수 있다. 내부 구현은 공개되지 않았지만 사용자가 구분해야 하는 운영 경계는 분명하다.

이 책은 비공개 내부 아키텍처가 아니라 "사용자가 어디서 시작하고 무엇을 맡기는가"로 경계를 나눈다.

한국어 공식 지원 문서는 Claude 접근 표면을 한 번에 보여 준다. 초보자는 보통 Chat만 떠올린다. 하지만 Anthropic은 애초에 Chat, 모바일, Desktop, Console/API를 함께 놓고 설명한다. 같은 모델이어도 어디서 호출하느냐에 따라 사용자의 태도와 결과물이 달라진다. 웹 채팅에선 질문을 잘 만드는 사람이 유리하고, Desktop에선 파일을 잘 정리한 사람이 유리하고, API에선 자동화 흐름을 잘 설계한 사람이 유리하다. 모델은 같아도 경쟁력은 "어느 작업 표면 위에서 쓰는가"에서 갈린다.

Cowork는 단순히 "더 자동화된 채팅"이 아니다. 대화를 잘하느냐보다 폴더와 파일을 어떻게 설계했는지, 결과물을 어디에 남길지, 반복 작업을 어떤 규칙으로 넘길지가 더 중요해진다. Chat이 질문 중심 도구라면 Cowork는 맡김 중심 도구다. 공식 문서도 Cowork는 Claude Desktop 안에서 돌아가며 결과 형식과 폴더 구조를 먼저 정리할수록 잘 작동한다고 설명한다. Cowork를 잘 쓰려면 프롬프트를 길게 쓰는 법보다 context, projects, outputs, templates를 왜 나누는지부터 이해해야 한다.

Claude Code는 터미널 전용 개발자 도구가 아니다. 공식 문서는 Claude Code를 단일 표면이 아니라 여러 표면을 관통하는 공통 엔진으로 설명한다. Claude Code는 터미널, VS Code, Desktop, Web, JetBrains 위에서 같은 엔진으로 작동한다. 표면이 여러 개여도 규칙은 공유된다. CLAUDE.md, Skills, Hooks, MCP는 따로 노는 기능이 아니라 같은 엔진이 환경을 바꿔도 비슷하게 움직이게 만드는 운영 요소다. Claude Code를 새 IDE 하나로 이해하면 범위가 좁아진다.

주요 구성 요소

Remote Control / Channels / Scheduled Tasks는 Claude 작업이 "누가, 어떤 계기로 시작되는가"를 나누는 제어 층이다. 셋 다 비슷해 보여도 출발 버튼을 누르는 주체가 다르다.

• Remote Control: 사람이 멀리서 이어받는 방식
• Channels: 외부 시스템이 사건을 밀어 넣는 방식
• Scheduled Tasks: 시간이 자동으로 일을 시작시키는 방식

제품 선택의 가장 단순한 구분

이 기준은 단순하지만 오래 쓸 수 있다. 초보자는 "제일 강한 모델이 어디 있나"부터 찾는다. 하지만 실제 차이는 모델보다 작업면에서 먼저 갈린다. Chat에선 질문 품질, Cowork에선 폴더 구조와 템플릿, Claude Code에선 규칙 파일과 검증 루프가 결과를 좌우한다.

누가 어디서 먼저 효과를 보는가

직무별 첫 적용 지점으로 보면 더 빠르다.

좋은 첫 과제와 나쁜 첫 과제

초보자가 작은 성공 경험을 만들려면 첫 과제를 작게 고른다.

첫 과제는 "Claude가 얼마나 똑똑한가"를 시험하는 자리가 아니다. "우리 작업 구조가 얼마나 정리돼 있는가"를 확인하는 자리다. 작은 성공은 작은 작업에서 나온다. 회의록 정리, 버그 수정 계획, 파일명 통일, 주간 브리프 초안처럼 끝이 보이는 과제가 적합하다. 모든 기능을 켜기보다 작은 작업을 두 번 반복하면서 규칙 파일과 템플릿을 하나씩 만드는 편이 낫다.

제품 선택에서 가장 흔한 오해 세 가지

여기서 바로 멈춰야 하는 신호

첫 주에 아래가 보이면 새 기능을 더 켜기보다 표면 선택을 다시 점검한다.

1.5 Cowork와 Claude Code의 차이는 생각보다 크다

커뮤니티에서 가장 자주 나오는 오해는 이것이다. "Cowork는 Code보다 쉬운 버전인가?"

부분적으로만 맞다. 둘의 차이는 난이도가 아니라 작업 모델에 있다.

현재 제품 경계도 같이 알아 두자. 2026년 3월 기준 공식 도움말은 Cowork를 유료 플랜 대상의 연구 미리보기로 설명한다. Claude Desktop for macOS와 Windows x64를 기본 작업면으로 둔다. Cowork를 웹 어디서나 같은 방식으로 돌아가는 완전한 범용 작업면으로 먼저 기대하면 감각이 어긋난다. 실제 사용감은 로컬 파일, 데스크톱 앱, 그 위의 원격 이어받기 흐름에 가깝다.

둘은 대체재가 아니라 서로 다른 작업층이다. 고급 사용자는 둘을 함께 쓴다. 기획안, 브리프, 리서치 초안은 Cowork에서 만들고, 구현, 통합, 테스트, 배포, 코드 리뷰는 Claude Code에서 한다. 핵심 구분은 난이도가 아니라 위임 중심인지, 통제 중심인지다.

1.6 "핫하다"는 말의 실체

기술 제품이 뜬다는 건 단순 바이럴과 다르다. 사용자 행동이 바뀌고, 운영 습관이 바뀌고, 주변 도구 생태계가 붙고, 직무 분업이 재설계될 때 "핫하다"가 실체를 갖는다. Claude 생태계는 지금 이 네 조건을 거의 모두 충족한다.

1. 사용자 행동 변화

   프롬프트를 길게 쓰기보다 context file과 skill을 쌓기 시작. 하나의 세션이 아니라 여러 세션과 worktree를 병렬로 돌리기 시작. 결과물만 받는 게 아니라 계획-실행-검증 루프를 설계. 채팅을 잘하는 사람보다 작업공간을 설계하는 사람이 유리해지고 있다.

2. 운영 습관 변화

   CLAUDE.md를 협업 규약처럼 유지. Hook으로 lint, test, review를 강제. plan 파일, handoff 파일, work log를 남긴다. 모델 활용이 개인 요령을 넘어 팀 운영 자산으로 정리되고 있다.

3. 생태계 확장

   Anthropic 공식 skills/plugins 저장소, Agent Skills 오픈 스탠다드, MCP 서버, plugin marketplace, 서드파티 skill hub가 붙었다. 모델 하나보다 주변 운영층이 커졌다. Cowork 플러그인은 고정 데모가 아니라 sales, finance, legal, marketing, HR, engineering, design, operations, data analysis로 계속 확장되는 역할 라이브러리다.

4. 직무 분업 재설계

   마케팅, 세무, PM, 디자인, 보안, 연구, 콘텐츠 운영, 교육, 리서치에서 Claude를 보조 챗봇이 아니라 자동화 계층으로 다루기 시작. 이 단계에 오면 AI 활용은 툴 팁이 아니라 역할 재설계 문제가 된다.

공개 커뮤니티 사례를 보면 조사 결과가 메모에서 끝나지 않는다. 같은 흐름 안에서 브리프, 시트, 슬라이드, 보고서, 코드 작업으로 이어진다. 예전에는 조사, 정리, 시각화, 구현 사이에 복사와 전달이 많았다. 지금은 이 전달 비용을 줄이는 것이 제품 경쟁의 중심이다. 다만 커뮤니티 데모의 매끈한 흐름도 실제 업무에 넣으면 승인, 파일 정리, 예외 처리 때문에 자주 끊긴다. 이 장면은 완성된 미래가 아니라 "어디서 마찰을 줄일 수 있는지" 보여 주는 방향 신호다.

더 길게 보면 경쟁 무대는 모델 앱 하나가 아니라 기억, 규칙, 도구, 검증, 자동화를 한 레이어에 묶는 쪽이다. 검색은 문서로, 문서는 자동화로, 자동화는 협업과 권한 관리로 이어진다. 유리한 제품은 가장 똑똑한 대화창이 아니라 가장 덜 끊기는 작업 흐름이다.

1.7 이 장의 결론

다음 장부터는 그 시스템을 이루는 제품면과 용어를 더 세밀하게 본다.

1.8 장 끝 참고 출처

공식

• Release notes, 2025-09 ~ 2026-03
• Get started with Cowork
• Use plugins in Cowork
• Claude Code on the web
• Introducing Claude Sonnet 4.6
• What's new in Claude 4.6
• Use Claude for PowerPoint

커뮤니티 맥락

• 공개 X 스레드와 커뮤니티 실무 글 묶음

커뮤니티 사례는 실무 패턴을 보여 주는 데 유용하다. 다만 플랜 제한, 실험 기능 상태, UI 위치, 관리자 권한 같은 사실 정보는 공식 문서를 우선했다.