For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/ko/articles/claude-cowork-mobile-web-agent-harness.md.
Claude Cowork의 모바일 및 웹 지원은 단순한 제품 인터페이스 업데이트가 아닙니다. 이는 에이전트 작업이 지속적이고, 크로스 디바이스이며, 비동기적이고, 도구를 사용하는 방향으로 변화하고 있음을 보여줍니다. 이러한 변화는 에이전트 하네스를 더...

Anthropic의 Claude Cowork 업데이트는 처음에는 단순해 보입니다. Cowork가 데스크톱을 넘어 웹과 모바일에서도 사용 가능해진 것입니다. 그러나 실제 신호는 하나의 새로운 인터페이스보다 더 큽니다.
에이전트가 사용자가 자리를 비운 후에도 계속 작업할 수 있게 되면, 제품은 더 이상 단순한 채팅 창이 아닙니다. 지속적인 작업 스레드가 됩니다. 사용자는 데스크톱에서 작업을 시작하고, 휴대폰에서 진행 상황을 확인하며, 다른 기기에서 설명을 요청받고, 나중에 돌아와 결과물을 검토할 수 있습니다.
이러한 변화는 Claude Cowork, Claude Code, Codex, Cursor, GitHub Copilot, NxCode 또는 내부 에이전트를 사용하는 팀에게 중요합니다. 더 이상 "모델이 작업을 해결할 수 있는가?"라는 질문만이 아닙니다. 더 나은 질문은 "모델을 둘러싼 시스템이 컨텍스트, 도구, 상태, 권한, 로그, 검증 및 인간 검토를 통제할 수 있는가?" 입니다.
Claude Cowork가 데스크톱 중심의 워크플로우에서 웹과 모바일 경험으로 확장되고 있습니다. 사용자는 컴퓨터에서 작업을 시작하고, Claude가 백그라운드에서 계속 작업하도록 두고, 휴대폰에서 상태를 확인한 후, 나중에 돌아와 결과물을 검토할 수 있습니다.
이것은 사고 모델을 변화시킵니다.
챗봇은 다음 메시지를 기다립니다. 코드 완성 도구는 다음 줄을 제안합니다. 백그라운드 에이전트는 사용자가 자리를 비운 후에도 계속 작업합니다. 이는 팀이 모든 거버넌스를 하나의 데스크톱 세션이나 하나의 가시적인 터미널 창에 배치할 수 없음을 의미합니다.
Anthropic의 Cowork 제품 페이지는 또한 통제를 강조합니다. 사용자는 폴더와 도구를 선택할 수 있으며, 기업 관리자는 접근 권한과 권한을 구성할 수 있습니다. 이는 교차 기기 작업이 실수로 모든 휴대폰 터치를 광범위한 권한 부여로 바꾸지 않는 경우에만 유용하기 때문에 중요합니다.
엔지니어링 팀에게 교훈은 "모든 작업을 모바일로 옮기라"는 것이 아닙니다. 교훈은 위임된 작업이 지속 가능해지고 있다는 것입니다. 작업은 탭, 기기, 회의, 알림 및 인간의 컨텍스트 전환을 넘어 계속됩니다. 운영 모델은 첫 프롬프트 이후에도 작업이 계속될 수 있다고 가정해야 합니다.
에이전트 하네스는 요청을 통제된 작업으로 전환하는 모델 주변의 시스템입니다.
여기에는 다음이 포함됩니다:
약한 하네스 안의 강력한 모델은 여전히 심각하게 실패할 수 있습니다. 잘못된 파일을 읽거나, 잘못된 도구를 사용하거나, 큰
안전하지 않은 변경을 하거나, 검토할 수 없을 만큼 매끄럽지만 검증되지 않은 결과를 생성합니다.
Claude Cowork의 모바일 및 웹 확장으로 인해 이러한 제어 장치가 더욱 가시화되고 있습니다. 작업은 데스크톱에서 시작되어 클라우드에서 계속되고, 모바일에서 승인을 요청하며, 검토 준비가 된 파일이나 메시지로 마무리될 수 있습니다. 이러한 흐름에는 단순히 기기가 아닌 작업과 함께 이동하는 상태와 권한이 필요합니다.
AWS는 Amazon Bedrock AgentCore를 통해 클라우드 측면에서 관련 아이디어를 추진하고 있습니다. 해당 제어 모델은 오케스트레이션, 도구 실행, 컨텍스트 관리, 상태 유지, 장애 복구 및 격리된 세션에 중점을 둡니다. Lilian Weng의 제어 공학에 관한 글은 연구 관점에서 같은 방향을 제시합니다. 더 나은 에이전트 동작은 더 강력한 모델 가중치뿐만 아니라 더 나은 환경, 피드백 루프, 평가, 도구 및 프레임워크에서 비롯됩니다.
실질적으로, 제어 장치는 팀이 '좋은 에이전트 작업'이 무엇인지 정의하는 곳입니다.
기기 간 에이전트는 명확한 가치를 지닙니다.
제품 관리자는 기차에 탑승하기 전에 고객 조사 브리핑을 요청할 수 있습니다. 엔지니어는 로그 조사를 시작하고, 노트북을 닫고, 휴대폰에서 좁은 범위의 후속 조치를 승인할 수 있습니다. 창업자는 투자자 업데이트를 위임하고 나중에 초안을 검토할 수 있습니다.
하지만 위험성도 마찬가지로 명확합니다. 백그라운드에서 계속 실행되는 작업은 사용자가 화면에서 시선을 떼고 난 후에도 도구, 파일, 연결된 앱 및 컨텍스트를 계속 사용할 수 있습니다.
팀은 다섯 가지 유형의 권한을 분리해야 합니다.
| 권한 유형 | 예시 | 기본 규칙 |
|---|---|---|
| 로컬 컨텍스트 읽기 | 저장소 파일, 문서, 노트 | 범위가 지정된 폴더만 허용 |
| 연결된 앱 읽기 | Slack, 이메일, 캘린더, CRM | 커넥터별 승인 사용 |
| 로컬 아티팩트 쓰기 | 초안, 브랜치, 스프레드시트 | 검토 가능한 diff만 허용 |
| 외부 커뮤니케이션 | 이메일 발송, Slack 게시, 티켓 제출 | 사람의 확인 필요 |
| 파괴적 또는 프로덕션 작업 | 파일 삭제, 비밀 키 순환, 배포 | 명시적 승인 및 로그 필요 |
모바일 액세스는 검토를 더 빠르게 만들어야지, 더 약하게 만들어서는 안 됩니다. 휴대폰은 작업 상태 확인, 설명 요청, 좁은 범위의 다음 단계 승인에 유용합니다. 대규모 코드 diff 검토, 프로덕션 마이그레이션 승인, 청구 변경 승인, 고객 데이터에 대한 광범위한 액세스 권한 부여에는 적합하지 않습니다.
간단한 운영 규칙이 잘 작동합니다.
모바일은 방향을 제시할 수 있지만, 중요한 승인은 증거가 보이는 곳에서 이루어져야 합니다.
모든 위임된 작업에는 서면 경계가 필요합니다.
적절한 범위에는 다음이 포함되어야 합니다.
이러한 경계가 없으면 백그라운드 에이전트는 도구가 부착된 장기 실행 프롬프트에 불과합니다. 이는 안전한 운영 모델이 아닙니다.
검토자는 에이전트가 무엇을 했는지 추측할 필요가 없어야 합니다.
코드 작업의 경우 최종 보고서에는 다음이 포함되어야 합니다.
연구 과제의 경우 최종 보고서에는 다음이 포함되어야 합니다:
목표는 에이전트의 작업을 감사 가능하게 만드는 것입니다. 정제된 답변만으로는 충분하지 않습니다.
모든 작업에 동일한 모델, 컨텍스트 창 또는 예산이 필요한 것은 아닙니다.
위험이 낮은 요약, 이슈 분류, 형식 지정 및 결정론적 변환에는 종종 저비용 모델을 사용할 수 있습니다. 까다로운 디버깅, 아키텍처 계획, 마이그레이션 및 보안 관련 작업은 더 강력한 모델과 엄격한 검토가 필요할 수 있습니다.
실용적인 라우팅 정책은 다음과 같을 수 있습니다:
| 작업 유형 | 권장 모델 전략 | 검토 수준 |
|---|---|---|
| 형식 지정 또는 정리 | 저비용 모델 | 가벼운 검토 |
| 요약 또는 분류 | 저비용 모델 | 점검 |
| 소규모 코드 수정 | 위험에 따라 중/고급 모델 | 차이점 + 테스트 검토 |
| 아키텍처 변경 | 강력한 모델 | 인간 검토 필수 |
| 보안 또는 운영 작업 | 강력한 모델 + 엄격한 제어 | 인간 승인 필수 |
| 외부 고객 커뮤니케이션 | 강력한 모델 또는 인간 주도 | 발송 전 승인 필요 |
핵심은 항상 가장 저렴한 모델을 사용하는 것이 아닙니다. 위험 수준에 맞는 올바른 모델을 사용하는 것입니다.
지속형 에이전트는 모든 것을 저장하고 싶은 유혹을 만듭니다. 이는 위험합니다.
팀은 다음과 같은 안정적이고 재사용 가능한 정보를 저장해야 합니다:
팀은 다음을 저장하지 않아야 합니다:
좋은 메모리는 워크플로우 신뢰성을 향상시킵니다. 나쁜 메모리는 어제의 추측을 내일의 숨겨진 명령어로 만듭니다.
데모나 소셜 미디어 클립을 통해서만 에이전트를 평가하지 마십시오.
지난 한 달간의 실제 작업을 선택하십시오. 버그, 리팩터링, 문서 편집, 데이터 정리, 지원 조사 및 릴리스 확인을 포함하세요. 각 에이전트를 동일한 시간 예산으로 실행하고 결과를 비교하십시오.
측정 항목:
팀의 로컬 벤치마크는 일반적인 리더보드보다 더 가치 있습니다. 이는 해당 팀이 실제로 수행하는 작업을 반영하기 때문입니다.
유용한 제어 장치가 반드시 대규모 플랫폼 프로젝트로 시작할 필요는 없습니다. 최소 버전은 저장소 지시 파일, 작업 템플릿, 검증 체크리스트 및 검토 규칙으로 구축할 수 있습니다.
다음과 같은 작업 템플릿을 사용하세요:
목표:
허용된 컨텍스트:
허용된 도구:
금지된 작업:
검증 명령어:
예상 결과물:
인간 승인이 필요한 경우:
중단 조건:
아이디어를 한 문장으로 입력하면 We0 AI가 쇼케이스 사이트, 페이지, CMS를 생성하고 출시 후 고객과 트래픽 확보를 돕습니다.
무료 등록을 위한 하나의 완전한 프로젝트 생성
하나의 완전한 생성 흐름을 시도하고 첫 번째 프로젝트 초안을 빠르게 보는 데 가장 적합합니다.
그런 다음 작업 유형을 워크플로우에 매핑합니다.
이 템플릿은 간단하지만, 팀이 권한 부여와 검증을 가시화하도록 강제합니다.
We0 AI 스타일 워크플로우의 경우, 제어 장치는 팀이 지침을 정의하고, 반복 가능한 검사를 실행하고, 에이전트 출력을 비교하고, 검토를 위한 충분한 컨텍스트를 보존하는 데 도움을 주어야 합니다. 목표는 속도를 늦추는 것이 아닙니다.
도입. 목표는 위임을 충분히 신뢰할 수 있을 정도로 예측 가능하게 만드는 것입니다.
Claude Cowork, Claude Code, Codex, GitHub Copilot, Cursor 또는 내부 에이전트를 "분위기"로 비교하지 마십시오.
실제 작업을 사용하고 다음 다섯 가지 질문을 하십시오:
각 작업을 두 번 이상 실행하십시오. 에이전트는 확률적입니다. 한 번의 인상적인 실행이 신뢰성을 증명하지 않으며, 한 번의 나쁜 실행이 시스템이 쓸모없다는 것을 증명하지 않습니다.
또한 검토 부담을 측정하십시오. 에이전트가 수동으로 작업을 수행하는 것보다 확인하는 데 더 오래 걸리는 대규모 결과물을 생성한다면 도움이 되지 않습니다. 유용한 에이전트는 확신 있는 결정에 도달하는 비용을 줄입니다. 단순히 더 많은 출력을 생성하지 않습니다.
Claude Cowork 모바일 및 웹은 더 넓은 변화의 일부입니다.
AWS는 에이전트 하니스를 관리형 클라우드 인프라로 전환하고 있습니다. GitHub Copilot 클라우드 에이전트는 백그라운드 코딩 및 풀 리퀘스트 워크플로를 지원합니다. Claude Code, Codex, Cursor 및 내부 에이전트는 모두 팀을 비동기식 도구 사용 작업으로 밀어붙이고 있습니다. 하니스 엔지니어링에 대한 연구 논의는 또한 더 나은 에이전트 시스템이 더 강력한 환경, 도구, 피드백 루프 및 평가에 의존할 것임을 시사합니다.
이들은 서로 다른 제품 이야기이지만, 동일한 운영 현실을 가리킵니다: AI 제품이 시스템이 되고 있다는 것입니다.
필요한 것:
"프롬프트 붙여넣고 답변 얻기"의 시대는 끝나지 않았습니다. 그러나 진지한 팀에게는 더 이상 최전선이 아닙니다.
다음은 실용적인 30일 출시 계획입니다.
팀이 사용하는 모든 에이전트 도구를 나열하십시오.
각 도구에 대해 다음을 기록하십시오:
이를 통해 팀은 명확한 기준점을 얻을 수 있습니다.
작업을 낮음, 중간, 높음 위험으로 나누십시오.
이 정책은 문서화되어야 합니다. 작업 범주가 명확하지 않은 경우, 팀이 달리 결정할 때까지 중간 또는 높은 위험으로 취급하십시오.
지난달의 실제 작업 약 20개를 선택하십시오.
포함:
현재 워크플로와 적어도 하나의 대체 에이전트 설정을 실행하십시오. 완료, 검토 시간, 비용, 실패 및 예상치 못한 사항을 추적하십시오.
다음을 추가 또는 개선하십시오:
작업이
확인할 수 없는 경우, 명확한 인간 소유자 없이 위임해서는 안 됩니다.
모바일 접근은 광범위한 권한이 아닌 제한된 통제를 중심으로 설계되어야 합니다.
안전한 모바일 워크플로우를 통해 사용자는 다음을 수행할 수 있어야 합니다:
다음과 같은 행위는 함부로 허용해서는 안 됩니다:
이는 모바일 제어가 나쁘다는 의미가 아닙니다. 모바일 제어는 작은 화면에서 책임감 있게 내릴 수 있는 종류의 결정으로 범위가 제한되어야 한다는 뜻입니다.
Claude Cowork의 모바일 및 웹 지원이 중요한 이유는 에이전트 제품의 방향성을 보여주기 때문입니다. AI 작업은 지속적이고, 크로스 디바이스이며, 비동기적이고, 도구를 사용하는 방식이 될 것입니다.
에이전트를 단순히 더 똑똑한 자동 완성 기능으로만 취급하는 팀은 이러한 변화를 놓칠 것입니다. 에이전트를 완전히 신뢰할 수 있는 동료로 취급하는 팀은 피할 수 있는 위험을 초래할 것입니다.
더 안전한 경로는 통제된 위임입니다: 좁은 작업 범위, 명시적 권한, 지속적인 로그, 결정론적 검증, 모델 라우팅, 적절한 시점의 인간 검토입니다.
Claude Cowork는 Anthropic의 에이전트 작업 제품으로, 사용자가 최종 결과를 검토하는 동안 Claude가 파일, 도구 및 워크플로우 전반에 걸쳐 작업을 처리할 수 있게 합니다. 웹 및 모바일 지원으로 워크플로우를 더 지속적이고 크로스 디바이스로 만듭니다.
모바일 접근이 중요한 이유는 사용자가 에이전트와 상호작용하는 방식을 변화시키기 때문입니다. 하나의 데스크톱 세션에 머무는 대신, 사용자가 다른 기기에서 진행 상황을 확인하거나, 질문에 답변하거나, 상태를 검토하는 동안 작업이 백그라운드에서 계속될 수 있습니다.
에이전트 하네스는 모델 주변의 시스템으로, 컨텍스트, 도구, 상태, 권한, 검증, 로그 및 인간 검토를 관리합니다. 모델 응답을 통제된 작업으로 전환하는 역할을 합니다.
모바일 승인은 요구 사항 명확화나 진행 상황 확인과 같은 좁고 위험이 낮은 결정에 대해 안전할 수 있습니다. 대규모 코드 변경, 프로덕션 작업, 고객 데이터, 외부 메시지 또는 파괴적 작업에 대한 전체 검토를 대체해서는 안 됩니다.
데모 대신 실제 내부 작업을 사용하세요. 완료율, 검토 부담, 비용, 안전성, 롤백 복잡성, 소스 증거 및 에이전트를 적절한 시점에 중단하거나 리디렉션할 수 있는지 여부를 비교하세요.
좋은 템플릿에는 목표, 허용된 컨텍스트, 허용된 도구, 금지된 작업, 검증 명령, 예상 아티팩트, 필수 승인 지점 및 중단 조건이 포함되어야 합니다.
작업마다 위험과 복잡성 수준이 다릅니다. 간단한 요약에는 가장 비싼 모델이 필요하지 않을 수 있지만, 아키텍처 변경, 디버깅, 마이그레이션 및 보안에 민감한
작업에는 더 강력한 모델과 엄격한 검토가 필요할 수 있습니다.
가장 큰 위험은 사용자가 주의를 기울이지 않게 된 후에도 에이전트가 계속해서 도구, 컨텍스트 또는 권한을 사용할 수 있다는 점입니다. 따라서 범위 제한 액세스, 로그, 검토 가능한 아티팩트, 승인 게이트가 필수적입니다.
Claude Cowork의 모바일 및 웹 지원은 단순한 제품 인터페이스 업데이트가 아닙니다. 이는 에이전트 작업이 지속적이고, 교차 기기이며, 비동기적이고, 도구를 사용하는 방식으로 변하고 있음을 보여줍니다.
이러한 변화는 에이전트 하네스를 더욱 중요하게 만듭니다. 팀은 더 명확한 작업 범위, 더 엄격한 권한, 지속적인 로그, 모델 라우팅, 결정론적 검증, 적절한 시점의 인간 승인이 필요합니다.
다음 좋은 단계는 모든 새로운 에이전트 기능을 쫓는 것이 아닙니다. 소규모 내부 벤치마크를 구축하고, 위험 수준을 정의하며, 위임된 작업을 검토 가능하게 만드는 것입니다.
가장 강력한 에이전트 워크플로우는 가장 많은 자율성을 가진 것이 아닙니다. 가장 명확한 경계, 최고의 증거, 가장 안전한 검토 경로를 가진 것입니다.
한 문장에서 시작해 몇 분 안에 완전한 웹사이트를 받아보세요.