AI 코워커, 로컬 퍼스트 에이전트, 그리고 지식 노동의 미래
Latent Space 팟캐스트 — Felix Rieseberg (Anthropic, Claude Cowork) 에피소드 완전 분석
출처: Latent Space - The AI Engineer Podcast
에피소드 제목: “Why Anthropic Thinks AI Should Have Its Own Computer”
게스트: Felix Rieseberg (Anthropic, Member of Technical Staff, Claude Cowork 리드)
진행: Alessio (Kernel Labs 공동창업자), Swix (Latent Space 에디터)
공개일: 2026년 3월 18일
유튜브: https://www.youtube.com/watch?v=ZpZ7lFoWaT8
글: https://www.latent.space/p/felix-anthropic
들어가며: 왜 이 대화가 중요한가
2026년 3월, Anthropic의 Claude Cowork를 이끄는 Felix Rieseberg가 AI 엔지니어 커뮤니티의 대표적인 팟캐스트인 Latent Space에 출연했다. 단순한 제품 홍보가 아니라, Anthropic이 에이전트 시대의 소프트웨어를 어떻게 바라보는지에 대한 깊은 철학적·기술적 논의가 담긴 이 대화는 AI 업계의 많은 관찰자들에게 주목을 받았다. 특히 “Anthropic의 Cowork 책임자가 향후 2년간의 에이전트 플랫폼 전략 전체를 VM과 샌드박싱에 대한 엔지니어링 철학으로 포장해 발표했다”는 평가가 나올 만큼, 대화 곳곳에 경쟁사에 대한 전략적 시사점이 담겨 있었다.
Felix Rieseberg는 단순한 PM이 아니다. 그는 Microsoft에서 Electron을 공동 개발했고, Slack 데스크톱 앱 구축에 참여했으며, JavaScript 위에서 Windows 95를 실행하는 프로젝트를 만든 인물이다. Notion에서 웹 인프라·데스크톱 팀을 이끌다 Anthropic으로 합류한 그는, 데스크톱 소프트웨어와 크로스플랫폼 기술에 대한 깊은 이해를 바탕으로 Claude Cowork를 설계하고 있다.
1장. Claude Cowork란 무엇인가
Claude Cowork를 한 마디로 정의하면 “Claude Code의 사용자 친화적 버전”이다. 그러나 Felix는 이 정의가 오해를 낳기 쉽다고 강조한다. “사용자 친화적”이라는 말이 보통 “기능이 축소된 버전”을 의미하는 것과 달리, Cowork는 Claude Code 위에 추가적인 기능과 편의성을 얹은 상위 집합(superset)에 가깝다는 것이다.
Cowork의 탄생 배경은 흥미롭게도 “사고”였다. Anthropic 팀이 Claude Code 사용 패턴을 분석하던 중 2025년 12월경부터 기묘한 현상을 발견했다. 터미널 환경에 익숙하지 않은 비개발자들이 Claude Code를 사용하기 시작한 것이다. 그것도 코딩 목적이 아니라, 경비 처리, 영수증 정리, 지식 베이스 구축, Obsidian 연동 같은 일반 업무에 활용하고 있었다. 개발자들조차 코딩이 아닌 일반 업무에 Claude Code를 사용하는 경향이 나타났다.
이 관찰에서 Anthropic이 도출한 결론은 두 가지였다. 첫째, 에이전트 기반의 업무 자동화에 대한 수요는 개발자를 훨씬 넘어선다. 둘째, 터미널에 익숙하지 않은 사람들에게도 이 능력을 제공할 수 있는 별도의 제품이 필요하다. 그렇게 Claude Cowork가 기획되었다.
2장. 10일 만에 제품을 만든다는 것의 진짜 의미
Cowork는 단 10일 만에 만들어졌다고 알려져 있다. 이 수치는 종종 과장이나 마케팅으로 오해받지만, Felix는 이를 정확하게 문맥화했다. 10일이라는 기간은 Anthropic이 이미 18개월 이상 내부에서 쌓아온 프로토타입들과 인프라 위에서 가능한 숫자였다. 마치 React나 기타 프레임워크 없이 웹사이트를 밑바닥부터 짜는 게 아닌 것처럼, Cowork 역시 기존의 Claude Code, VM 인프라, 내부 프로토타입들을 조합해 완성된 것이다.
더 놀라운 사실은, Cowork가 실질적으로 자기 자신을 만들었다는 점이다. Anthropic의 Claude Code 헤드 Boris Cherny는 “Cowork의 전체 코드가 Claude Code로 작성되었다”고 밝혔다. 개발팀은 각자 3~8개의 Claude 창을 동시에 관리하며, 코드 작성·버그 확인·아이디어 도출 등 역할을 분담시켰다. 인간은 아키텍처 결정과 방향 설정에 집중하고, AI가 구체적인 구현을 담당한 것이다. Felix의 표현을 빌리자면, “코드를 한 줄씩 작성하는 데보다 제품과 아키텍처 결정에 더 많은 시간을 썼다.”
이는 Anthropic 내부 문화의 변화를 반영한다. Felix는 과거에는 PM이 잠재 고객을 만나 저대역폭 방식으로 문제를 파악하고, 스펙을 작성하고, 디자인하고, 실행하는 순서를 밟았다고 설명했다. 이제 Anthropic은 “메모조차 쓰지 말고 그냥 모든 후보를 다 만들어라”라는 방식으로 전환했다. 실행 비용이 극적으로 낮아진 세계에서, 아이디어의 검증은 논의가 아니라 실제 빌드로 이루어진다.
3장. 왜 로컬 컴퓨터가 중요한가 — 실리콘밸리가 놓치고 있는 것
대화의 핵심 주제 중 하나는 로컬 컴퓨터의 가치다. Felix는 실리콘밸리가 전반적으로 로컬 컴퓨터를 과소평가하고 있다고 주장한다. 그의 논거는 단순하면서도 강력하다: “우리가 여전히 MacBook을 쓰는 이유가 뭔가? iPad나 Chromebook 대신?” 클라우드 퍼스트 세계에서도 사람들은 로컬 머신의 능력을 포기하지 않는다. 그 이유가 바로 Cowork의 설계 철학에 녹아 있다.
Felix가 그리는 Claude는 하나의 에이전트 존재(entity)다. 그리고 이 존재가 사용자에게 진정으로 유용하려면, 사용자가 접근할 수 있는 모든 도구에 Claude도 접근할 수 있어야 한다. 그렇지 않으면 Claude는 복잡한 방식으로 손발이 묶인 채 일하게 된다.
클라우드 우선 접근법에는 두 가지 근본적인 문제가 있다고 Felix는 지적한다. 첫째, 사용자는 다른 서비스 하나하나에 권한을 부여하고 그 권한 목록을 최신 상태로 유지하는 일이 매우 번거롭다. 둘째, 사용자의 모든 업무 데이터를 클라우드로 끌어올리는 것에 대한 저항감이 아직 크다. 예컨대 사용자의 Chrome 쿠키를 복호화해 클라우드로 올리는 건 기술적으로 쉽지만, 은행 같은 사이트가 두 다른 위치에서 동일 인증을 감지하면 계정을 잠글 것이다. 인프라가 아직 에이전트 시대를 따라가지 못하고 있다.
따라서 가장 자연스러운 해법은 Claude를 사용자가 실제로 일하는 곳, 즉 로컬 컴퓨터에 두는 것이다. 이것이 로컬 퍼스트(local-first) 에이전트 철학의 핵심이다.
4장. VM: 안전의 경계이자 능력의 해방구
Cowork의 가장 강력한 기술적 결정은 경량 가상머신(VM) 위에서 Claude Code를 실행하는 것이다. 이 VM은 macOS에서는 Apple Virtualization Framework를, Windows에서는 WSL2와 동일한 Host Compute System을 사용한다. Felix는 Apple Virtualization Framework를 보고 “이게 다야?”라고 놀랐다고 표현할 만큼, 공개 API 수준에서는 단순하면서도 매우 잘 최적화되어 있다.
VM을 사용하는 이유는 표면적으로는 안전(safety)과 보안(security)이지만, Felix는 그 너머의 이점을 강조한다. Claude에게 독립적인 컴퓨터를 주는 것 자체가 좋은 아이디어라는 것이다. 비유를 들면, 개발자에게 컴퓨터 대신 이메일로만 코드를 주고받으라고 한다면 일이 되겠는가? Claude도 마찬가지다. VM 위에서 Claude는 Python, Node.js 등 필요한 것을 자유롭게 설치하고 스크립트를 실행할 수 있다. 법무팀에 “Homebrew를 설치해도 되나요?”라고 물을 필요가 없다.
VM은 또한 “모든 명령을 일일이 승인하거나, 위험하게 권한을 건너뛰거나” 하는 양자택일의 딜레마를 해소한다. 샌드박싱이 중간 지점을 만들어준다. Claude가 VM 안에서 Python 스크립트를 실행하더라도, 그것이 사용자의 호스트 시스템에 직접 영향을 미치지 않는다. 네트워크 진입·출력(ingress/egress) 제어는 사용자가 평이한 언어로 정책을 정의할 수 있으며, IT 부서가 Claude의 컴퓨터와 사용자의 컴퓨터를 분리해 관리할 수 있어 기업 환경에서도 적용 가능하다.
VM의 단점도 솔직하게 인정된다. 시작이 느리고(10초 내외를 목표로 하지만 체감상 더 느리게 느껴질 수 있다), 디스크 이미지가 커 보일 수 있다(실제로는 빈 공간을 압축해 저장하므로 표시와 다르다). 그러나 이 트레이드오프는 Claude의 능력을 대폭 확장하기 위한 의도적인 선택이다.
5장. 아키텍처의 세 기둥: VM + Chrome + 시스템 프롬프트
Cowork의 아키텍처를 이해하는 데 중요한 세 가지 요소가 있다.
첫째는 앞서 설명한 VM이다. 이것이 Claude에게 독립적인 실행 환경을 제공한다. 둘째는 Claude in Chrome, 즉 브라우저 통합이다. MCP 커넥터들을 일일이 설정하는 것이 갈수록 부담스러워지는 현실에서, Claude와 Chrome의 긴밀한 통합은 사용자가 자연어로 지시만 내리면 브라우저 수준의 작업을 대신 처리해준다. DOM을 디버깅하고, 페이지를 실제로 보면서 작업하는 Claude는 그냥 지시만 받는 Claude와는 차원이 다르다. 셋째는 시스템 프롬프트다. Cowork와 Claude Code의 차이 중 많은 부분은 사실 시스템 프롬프트 안에 있다. 사용자의 업무 컨텍스트를 추론해 시스템 프롬프트에 반영하고, 계획 도구(planning tool)와 사용자 질문 도구(ask user question tool)를 적극 활용하도록 지시하는 것이 Cowork의 “마법”의 상당 부분을 차지한다.
6장. Claude Code와의 차이: 평가 지표가 다르다
많은 사람들이 Cowork와 Claude Code가 어떻게 다른지 궁금해한다. Felix의 대답은 명확하다: 두 제품은 서로 다른 기준으로 평가된다.
Claude Code는 전형적인 소프트웨어 개발 작업(SWE 벤치마크)에 최적화되어 있다. 반면 Cowork는 일반 지식 노동, 즉 금융, 법무, 개인 재무 관리, 일정 조율 같은 작업에서의 성능을 기준으로 평가한다. Felix가 자주 드는 예시는 “모기지 관리”나 “가족 여행 계획”이다.
이 평가 철학의 차이는 시스템 프롬프트 설계에도 반영된다. Cowork는 더 긴 시간 지평의 작업을 다루고, 작업이 길어질수록 모호성이 커지기 때문에, 계획 도구와 “사용자에게 질문하기” 도구를 매우 적극적으로 활용하도록 설계되어 있다. 4시간 동안 작업하다가 엉뚱한 결과를 가져오는 일을 방지하기 위해, Cowork는 작업 전에 충분히 질문하고 계획을 수립한다.
Swix가 Cowork에서 느끼는 “9단계 계획을 제시하고, 사용자가 피드백을 주면 그 계획대로 실행하는” 경험은 부분적으로 이 시스템 프롬프트 설계의 산물이다. 다만 Felix는 앞으로 모델이 더 강력해지면 이런 세밀한 스캐폴딩의 필요성이 줄어들 것이라고 솔직하게 인정한다.
7장. 스킬(Skills): 마크다운 파일이 MCP를 이기는 이유
Anthropic의 Skills 시스템은 단순해 보이지만, 그 탄생 배경에는 놀라운 통찰이 담겨 있다. 내부 팀이 데이터 웨어하우스 연동 프로토타입을 만들 때, MCP 서버를 따로 구축하는 대신 마크다운 파일 하나에 “여기에 엔드포인트가 있고, API는 이렇게 생겼다. 나머지는 알아서 해”라고 써서 Claude에게 건넸다. 그게 너무 잘 작동해서, 팀은 이 패턴을 계속 시도하기 시작했고, 그것이 Skills 전체 시스템으로 발전했다.
Skills의 핵심 가치는 세 가지다. 첫째, 파일 기반(file-based)이라 이식성이 뛰어나다. 마크다운 텍스트이므로 복사·공유가 쉽고, 특정 플랫폼에 종속되지 않는다. 둘째, 구조가 없어 진입 장벽이 낮다. 어떤 튜토리얼도 필요 없다. Claude에게 설명하듯 써 주면 된다. 셋째, 극도로 개인화할 수 있다. 사용자의 특정 워크플로에 맞춘 스킬은 매우 좁고 구체적일수록 강력하다.
Felix는 MCP에 대해 미묘한 입장을 취한다. MCP 자체는 나쁜 아이디어가 아니지만, 현재의 MCP 생태계는 통합이 어렵고 절반은 제대로 동작하지 않는다는 현실적 문제가 있다. Skills는 이 복잡성을 우회하는 실용적 해법이다. 모델이 마크다운 설명만으로도 API가 어떻게 작동하는지 추론할 수 있을 만큼 똑똑해졌기 때문에 가능한 것이다.
Cowork가 Skills의 “플러그인” 형식을 지원하며, Claude Code와 동일한 포맷을 사용한다는 점도 중요하다. GitHub 레포 전체를 스킬 마켓플레이스로 추가하는 것도 가능하다.
8장. 실제 사용 사례: 유튜브 업로드부터 세금 신고까지
Swix는 자신이 Cowork를 실제로 어떻게 사용하는지 라이브 데모로 보여주었다. 처음에는 Zoom 녹화본을 수동으로 다운로드해 YouTube에 업로드하는 번거로운 과정을 Cowork에 맡겼다. 비디오의 개별 프레임을 분석해 제목을 자동으로 생성하고, YouTube 업로드까지 자동화했다. 이것이 가능해지자 “Zoom 다운로드 자체도 Cowork에 맡기면 되지 않나?”라는 생각으로 이어졌고, 연쇄적으로 업무 범위를 확장했다.
더 인상적인 것은 스킬 자기 생성 기능이다. Swix는 Cowork에게 반복적인 워크플로를 스킬로 만들어달라고 요청했고, Cowork는 스스로 스킬 파일을 작성해 재사용 가능한 자동화로 패키징했다. 나아가 하나의 스킬이 너무 복잡해지자 세 개의 서브 스킬로 분리하고 상위 스킬이 이를 오케스트레이션하는 구조를 만들기도 했다.
Felix 자신도 Cowork를 개발하면서 자연스럽게 코딩 작업에 활용하고 있다고 인정했다. 내부 크래시 보고 대시보드에서 수정 가능한 버그와 OS 수준의 문제를 자동으로 분류하고, 수정 가능한 버그 각각에 대해 마크다운 프롬프트 파일을 작성한 뒤, Claude Code의 원격 작업 기능으로 각 프롬프트를 별도 인스턴스에서 병렬 처리하는 워크플로를 만들었다. 회의를 하러 가면 돌아왔을 때 버그들이 수정되어 있다.
Cowork의 대표적인 “입문 사례”로 알려진 것은 “바탕화면 정리”다. 출시 직후 트위터에서 가장 많이 공유된 사용 사례로, 기술적으로는 단순하지만 사람들이 평소 미루던 일을 AI가 대신 처리해준다는 심리적 만족감이 컸다. Swix는 라이브 데모에서 다운로드 폴더 정리를 시도했고, 계획 수립과 사용자 확인 요청이 아름답게 제시되는 것을 확인할 수 있었다.
9장. 평가(Evals)란 무엇인가 — Anthropic식 정의
“Eval”이라는 말은 업계에서 매우 모호하게 쓰인다. Felix는 Anthropic이 어떻게 Eval을 운영하는지 명확하게 설명했다. 전체 대화 기록(transcript), 즉 Claude에게 최종적으로 전달된 모든 도구 호출 포함한 내용을 가져와서, 특정 파라미터를 변경했을 때 출력이 어떻게 달라지는지 측정하는 것이다. 파일 출력물과 채팅창에서 보이는 토큰 출력물 모두를 측정 대상으로 삼는다.
이 평가는 훈련(training)에도 활용되고, 스캐폴딩 레이어의 튜닝에도 활용된다. Cowork는 스캐폴딩 영역에 주로 위치하지만, 일부 훈련에도 반영된다. 중요한 것은, Cowork의 평가 기준이 Claude Code의 평가 기준과 다르다는 점이다. 같은 모델을 사용하더라도, 시스템 프롬프트와 도구 구성에 따라 특정 방향으로 성능이 최적화된다.
10장. 스캐폴딩 vs. 모델 능력 — 언제 무엇에 투자해야 하나
Felix가 고민하는 가장 큰 질문 중 하나는 스캐폴딩에 얼마나 투자해야 하는가이다. 현재 모델은 사용자가 실제로 활용하는 것보다 훨씬 더 강력하다. 이 “모델 잉여(model overhang)” 상황에서 병목은 지능이 아니라 도구 접근성이다.
그러나 스캐폴딩을 정교하게 만들수록, 다음 모델이 출시되면 그 스캐폴딩이 무의미해질 수 있다. Felix의 개인적 성향은 점점 더 “스캐폴딩 교정에 너무 투자하지 말고, 최대한 많은 능력을 제공하고 안전하게 만든 뒤 다음 모델 출시를 기다리는” 쪽으로 기울고 있다. 특정 유스케이스에 매우 특화된 AI 애플리케이션들이 단기적으로는 인상적으로 보일 수 있지만, 모델이 일반화 능력을 갖추면서 그 차별점이 사라질 위험이 있다.
이 논점은 Claude의 API를 이용해 특화 도구를 만드는 스타트업들에게 중요한 경고이기도 하다. 스캐폴딩이 제품의 핵심이라면, 그 스캐폴딩이 곧 Anthropic의 기본 기능으로 흡수될 수 있다. Felix는 이를 엔지니어링 실용주의로 표현했지만, 시장은 이를 플랫폼 리스크로 경험할 것이다.
11장. 어떤 AI 카테고리가 살아남을 것인가
Swix는 어떤 AI 기반 산업이 살아남을지 물었다. Felix는 단정적인 예측을 피하면서도 의미 있는 프레임을 제시했다. 코딩 분야에서는 모두가 “스택을 올라가야(moving up the stack)” 한다고 말한다. 단순히 토큰을 코드로 변환하는 것 이상의 가치를 제공해야 한다는 뜻이다. 기업 검색(enterprise search) 분야도 마찬가지다. Cowork 같은 에이전트가 모든 작업을 담당하게 되면, 검색 그 자체는 전체 워크플로에서 너무 작은 부분이 되어 독립적인 비즈니스로 성립하기 어려워진다.
Felix의 관점은 “특정 작업에 대한 계획과 전용 도구에서 에이전트가 가치를 창출하고 있고, 최종 고객이 그 스타트업을 신뢰한다면 지속 가능하다”는 것이다. 하지만 모델이 특화 없이도 그 작업을 잘하게 된다면, 그 방어선이 무너진다.
12장. 주니어 일자리와 노동 시장의 충격
Anthropic은 AI가 노동 시장에 미치는 영향에 대해 솔직하다는 평가를 받는다. Felix도 이 주제를 회피하지 않았다. 우리가 “자동화할 만한 사소한 작업”이라고 부르는 것들이, 다른 많은 산업에서는 주니어·엔트리레벨 직원에게 주어지던 업무다. 이 사람들이 직업을 얻고 성장하는 과정이 위협받고 있다는 점을 Anthropic은 진지하게 우려한다.
Swix는 흥미로운 대안을 제시했다. 주니어 엔지니어의 초기 몇 년을 AI로 시뮬레이션하는 것이다. 3개월이 걸릴 분산 시스템 학습 프로젝트를 1주일 안에 고밀도로 압축해 경험하게 한다. 실제 제품은 아니지만, 피드백 루프와 학습 경험은 실제다. 마치 대학이 비용을 내고 배우는 공간인 것처럼, 이런 AI 시뮬레이션 훈련 프로그램이 미래의 신입 교육을 대체할 수 있다는 것이다.
Felix는 워털루 대학교(University of Waterloo) 졸업생들이 다른 학교 신입보다 훨씬 더 준비가 잘 되어 있다는 관찰을 공유했다. 그 이유는 교육 커리큘럼 안에 1년 이상의 실습 인턴십이 포함되어 있기 때문이다. 이론이 아니라 실제로 제품을 만들고 팀 안에서 일하는 경험이 신입을 더 빠르게 성장시킨다. AI 시뮬레이션 훈련이 이와 유사한 역할을 할 수 있다.
반면 시니어 엔지니어들은 AI로 더 생산적이 되고 있다. 이미 노련한 엔지니어들이 AI를 도구로 활용해 더 많은 가치를 창출하고 있다. 젊은 세대가 AI를 더 혁신적으로 사용하는 경향도 있다. 문제는, 생산성이 향상되더라도 필요한 인력의 수 자체가 줄어들 수 있다는 점이다.
Anthropic은 이 문제를 사회적 차원에서 충분히 논의되어야 한다고 생각하며, 경제학자와 정부가 더 깊이 관여해야 한다는 입장이다.
13장. 점진적 이륙 vs. 빅뱅 이륙
많은 사람들이 AI 가속화의 자기 강화 루프가 시작되는 “빅뱅 모멘트”를 기다리고 있다. Felix는 그 시점이 4년 후인지 1년 후인지 불확실하지만, 확실성이 어느 정도 존재한다면 지금 대비해야 한다는 입장이다. Swix의 표현에 따르면, 그 이륙의 상징적 순간은 “Cowork가 텐서보드와 가중치를 보면서 모델을 학습시키는 때”일 것이다.
현재 Anthropic이 취하는 전략은 단발의 변혁이 아닌, 점진적인 능력 이전이다. 사용자를 질문-응답 패러다임에서 조금씩, 점점 더 큰 작업을 위임하는 방향으로 이끌어가는 것이다.
14장. 비전(Vision)과 컴퓨터 사용의 1년 전과 후
Computer Use는 1년 전 출시 당시 느리고 불안정하다는 평가가 많았다. Felix도 처음에는 매우 실망스러웠다고 인정했다. 그러나 1년이 지난 지금, 그 발전 속도가 놀랍다. 브라우저가 Claude에게 “눈”을 제공하는 것이 핵심이다. DOM을 디버깅하고, 실제로 작업하고 있는 것을 보면서 일하는 Claude는 텍스트만 주고받는 Claude와 질적으로 다르다.
Felix는 MCP 서버들을 직접 설치해 사용하다가 이제는 거의 사용하지 않는다고 밝혔다. 대신 Claude에게 스크립트를 직접 작성하게 한다. Claude가 직접 Apple Script를 작성하고 실행하는 것이 서드파티 MCP 도구보다 더 커스텀화되고 신뢰할 수 있다는 경험에서 나온 결론이다.
15장. Claude에게 자기 컴퓨터를 줘야 하는가
이 에피소드에서 가장 철학적인 논의 중 하나가 “Claude가 자신의 컴퓨터를 가져야 하는가”였다. Felix가 초기에 꿈꿨던 아이디어 중 하나는 화면에 두 번째 커서를 만드는 것이었다. 그러나 이것은 현실적으로 매우 어렵다. 운영체제의 모든 UX 모델이 “하나의 것이 작업하고 있다”는 가정 위에 구축되어 있기 때문이다.
그렇다면 Claude의 “컴퓨터”는 어떤 형태여야 할까? 세 가지 옵션이 있다. 첫째, 사용자 컴퓨터 위에 VM을 만들고 사용자가 가끔 들여다본다. 둘째, 사용자가 자리를 비울 때 Claude가 호스트 컴퓨터를 잠시 점령한다. 셋째, 완전히 별도의 클라우드 컴퓨터를 Claude에게 준다.
이 질문의 핵심에는 개인 데이터와의 친밀도 문제가 있다. 사용자는 일부 정보를 공유하는 데 매우 편안하지만, 다른 정보에 대해서는 매우 불편하다. 이 경계는 기술적 문제가 아니라 친밀감(intimacy)의 문제이며, 어떤 제품도 이를 무시하고 성공할 수 없다.
16장. Electron, Chromium, 그리고 데스크톱 소프트웨어의 교훈
Felix는 Electron의 공동 유지보수자로서, 왜 Electron이 이렇게 중요한 기반이 되었는지에 대한 깊은 인사이트를 공유했다. 핵심은 Chromium이다. 운영체제가 제공하는 웹뷰(WKWebView 등)를 사용하면 렌더링 버그가 생겼을 때 사용자에게 “최신 OS로 업데이트하라”고밖에 할 수 없다. Electron은 Chromium을 앱 안에 직접 내장함으로써 이 문제를 우회한다.
Chromium이 왜 특별한가? Unreal Engine이 텍스트 렌더링에 Chromium을 사용할 정도로, Chromium은 세상의 모든 다양한 GPU 드라이버, OS 버전, 하드웨어 설정에서 “빨간 픽셀을 빨간 픽셀로 표시”하는 것을 보장하는 엔지니어링의 결정체다. 24시간 안에 버그를 수정하는 구글의 역량과 함께, 이것이 Electron을 대체하기 어려운 이유다.
Tauri에 대해서는 “작은 앱이라면 Tauri가 기본값이 되어야 한다”고 말하면서도, 대규모 사용자 기반을 가진 앱에서는 OS 웹뷰의 한계가 크다는 현실을 인정했다. Slack이 초기에 macOS 시스템 웹뷰를 사용하다 Electron으로 전환한 것이 그 대표적 사례다.
미래의 질문은 모델이 Electron 앱을 Swift 같은 네이티브 언어로 완벽하게 재현할 수 있는 수준에 도달하는지다. Felix는 현재 모델들이 Electron 앱의 기능을 Swift로 복제하는 것은 할 수 있지만, 성능 최적화와 메모리 효율까지 완벽하게 구현하는 수준에는 아직 이르지 못했다고 본다.
17장. 멀티플레이어 에이전트: 미래의 협업
“두 사람의 Cowork가 서로 대화할 수 있는가?”라는 질문은 미래 에이전트 협업의 핵심을 건드린다. Felix는 이 방향에 대해 개방적이면서도 신중한 입장을 취했다.
현재 가장 현실적인 방향은 에이전트들에게 인간이 사용하는 것과 동일한 협업 도구를 주는 것이다. Gmail 계정, Slack 핸들을 부여하면, 에이전트들이 인간이 소통하는 방식으로 서로 소통할 수 있다. Anthropic의 재무 팀은 이미 Claude가 Google Docs에 댓글을 남기는 방식으로 협업하고 있다.
또 다른 흥미로운 가능성은 스킬 공유다. “내 Cowork가 이 작업을 위한 스킬을 갖고 있는데, 당신의 Cowork가 그 스킬을 가져갈 수 있을까?” Felix가 Bluetooth LE를 통해 인접한 두 컴퓨터가 자동으로 스킬을 공유하는 아이디어를 내부에서 제안했을 때, 동료들의 반응은 “쿨하지만 너무 소름 돋는다(creepy)”였다고 한다.
Swix가 언급한 개념 — 일종의 작업 대기열(queue)에 에이전트 작업을 제출하고, 다른 사람의 에이전트가 검토·승인하는 구조 — 은 조직의 미래 모습을 흥미롭게 그려준다. 영업팀 에이전트가 개발팀 에이전트에 작업을 요청하고, 마케팅·제품 에이전트와 연결되는 구조. 일부 결정은 자동 승인되고, 일부는 인간의 검토를 요청하는 방식.
18장. 스킬의 이식성과 개인화의 딜레마
스킬이 파일 기반이라는 점은 이식성을 보장하지만, 개인화(personalization)와 이식성(portability) 사이에는 해결되지 않은 긴장이 있다. 항공편 예약 스킬을 예로 들면, “저렴한 항공편이 좋다”는 보편적 요소와 “이 좌석, 이 공항, 이 시간대를 선호한다”는 개인적 요소가 혼재한다. 이 두 요소를 깔끔하게 분리하고 조합하는 스킬 포맷은 아직 존재하지 않는다.
Felix는 한 가지 단순한 해법으로 문자열 보간(string interpolation)을 언급했다. 스킬 파일에 {username}, {phone_number} 같은 변수를 두고 개인 설정으로 채우는 방식이다. 이것이 가장 투박한 해법이기에 아직 구현하지 않았지만, 이 방향의 해결책이 나오면 스킬의 가치가 폭발적으로 높아질 것이라고 본다.
19장. Anthropic Labs: 아직 세상에 없는 것들
Anthropic 내부에는 Claude Code와 별개로, 극단적으로 실험적인 아이디어를 탐구하는 Labs 팀이 있다. Felix의 설명에 따르면, Labs 팀은 최근 더 커졌으며, “아직 공개되지 않은, 매우 파격적이고 아마 절반은 망가진(half-broken)” 것들을 만들고 있다. Labs 팀의 원칙은 “다른 누구도 작업할 이유가 없는 것만 작업한다”는 것이다.
Felix 자신은 공개 전에 작업 내용을 모호하게 흘리는 것을 싫어하지만, 앞으로 Cowork에서 출시될 기능들이 외부 관찰자들에게 “그래, 당연히 그래야지”처럼 느껴질 것이라고 자신한다. 지나치게 특화되거나 너무 구체적인 것을 만드는 것이 아니라, 보편적으로 유용하고 자명한 것들을 찾아나가는 것이 Anthropic의 방향이라는 것이다.
20장. Cowork의 미래 로드맵
Felix가 앞으로의 방향으로 제시한 세 가지 축은 다음과 같다.
첫째, 사용자의 컴퓨터에서 Claude를 더 효과적으로 만드는 것이다. “당신의 컴퓨터에서” vs. “VM에서” vs. “클라우드 어딘가에서”의 의미를 계속 탐구하며, 최적의 형태를 찾아간다. Remote Control 기능(스마트폰에서 Cowork를 제어하는 기능)도 곧 추가될 예정이다.
둘째, 사용자를 질문-응답 패러다임에서 더 크고 긴 작업 위임으로 이끄는 것이다. 규모(scope)와 시간(time) 모두에서 Claude가 더 독립적으로, 더 오래 작업할 수 있도록 투자한다.
셋째, 수직 산업에 대한 깊이다. 금융, 법무 등 특화 분야에서 Claude를 더욱 효과적으로 만드는 전담 팀이 이미 존재하며, Excel 파일 출력 지원 같은 구체적 기능도 이미 제공되고 있다.
결론: 지식 노동의 재정의
이 에피소드가 전달하는 가장 핵심적인 메시지는, AI의 다음 단계가 더 나은 채팅봇이 아니라 신뢰할 수 있는 작업 실행자라는 것이다. 사람들은 AI에게 질문하는 것에서 벗어나, 점점 더 큰 작업을 위임하는 방향으로 이동하고 있다. 이 전환을 가능하게 하는 것은 더 나은 모델만이 아니다. 안전한 샌드박스, 재사용 가능한 스킬, 기존 워크플로와의 통합, 그리고 작업 범위와 자율성에 대한 사용자의 신뢰가 함께 필요하다.
Felix Rieseberg의 여정 — Microsoft에서 Electron을 만들고, Slack 데스크톱을 구축하고, JavaScript로 Windows 95를 실행하고, 이제 Claude에게 자신의 컴퓨터를 주는 — 은 한 가지 일관된 테마로 이어진다. 소프트웨어의 가장 중요한 혁신은 항상 인터페이스 레이어에서 일어났다. 그리고 지금 우리는 그 인터페이스 레이어가 다시 한번 근본적으로 바뀌는 순간을 목격하고 있다.
참고 링크
- 에피소드 전문: https://www.latent.space/p/felix-anthropic
- 유튜브: https://www.youtube.com/watch?v=ZpZ7lFoWaT8
- Felix Rieseberg 블로그: https://felixrieseberg.com
- Claude Cowork: https://claude.ai (Claude Max 구독 필요, macOS)
- 관련 분석: https://shellypalmer.com/2026/03/the-recursive-advantage/
작성 기준: 2026년 3월 21일 / 팟캐스트 공개일: 2026년 3월 18일