Claude Code v2.1.305, 샌드박스 절충안과 함께 Linux 호환성 추가
Anthropic은 Linux 호환성 옵션을 포함한 Claude Code v2.1.305를 출시했으며, 이 옵션에는 명시적인 경고가 따른다. 명령어가 샌드박스의 파일 보호 기능을 우회할 수 있다는 것이다. 이번 릴리스는 제공업체 오류와 무인 재시도 문제도 해결한다. 이러한 변경 사항은 주요 모델 성능보다 실질적인 배포 문제를 앞세운다.
핵심적인 긴장은 유용한 자동화와 강제 가능한 경계 사이에 있다. 개발자는 환경 문제로 중단되지 않고 현실적인 작업을 완료할 수 있는 어시스턴트를 원한다. 보안팀은 호환성 설정이 바뀌었을 때 어떤 제한이 유지되는지 알아야 한다. 명령어가 성공했다는 사실만으로는 그 질문에 답할 수 없다.
GitHub Copilot은 문서에서도 구체적인 한계와 함께 실행 제어 기능을 설명하므로 유용한 비교 대상이 된다. 이는 제품들이 동일한 아키텍처를 공유한다는 주장이 아니라 운영 측면의 비교다. 코딩 에이전트를 평가하는 조직에 갈수록 구체적인 질문은 다음과 같다. 아무도 지켜보지 않을 때 소프트웨어는 어디까지 접근할 수 있는가?
Claude Code v2.1.305의 변경 사항
중요한 추가 기능은 명시된 보안 비용을 수반하는 호환성 설정이다.
릴리스 노트에 따르면, sandbox.allowNestedUserNamespaces는 Linux 명령어가 사용자 네임스페이스를 생성하도록 허용한다. 사용자 네임스페이스는 프로세스에 사용자 ID와 권한에 대한 분리된 관점을 제공한다. Anthropic은 브라우저 엔진인 Chromium과 관리자 계정 없이 실행되는 컨테이너 도구인 rootless Podman을 예로 든다. 또한 이 기능이 샌드박스 파일 보호 기능의 우회를 허용한다고 경고한다.
이번 릴리스는 무인 재시도 모드를 위한 CLAUDE_CODE_RETRY_WATCHDOG_USAGE_LIMIT_RECHECK_MS도 추가해 사용량 제한이 해제됐을 때 이를 더 일찍 감지할 수 있도록 했다. 또한 엔드포인트나 게이트웨이가 도구 검색을 거부할 때 Vertex, Bedrock 및 기타 제공업체에 영향을 미치던 v2.1.304 회귀 문제도 수정했다. 이제 Claude Code는 해당 기능 없이 재시도한다.
그 밖의 수정 사항에는 /effort 및 /autocompact의 모델 이름 매칭, worktree 동작, 더 명확한 전체 디스크 오류가 포함된다. worktree는 Git 저장소에 연결된 별도의 작업 디렉터리다. 이 변경 사항들은 새롭게 발표된 모델이 아니라 구성과 실행 신뢰성에 관한 것이다.
이 구분은 이번 업데이트의 의미를 판단할 때 중요하다. 이 세부 사항 중 어느 것도 모든 환경에서 더 나은 추론, 더 높은 코딩 정확도 또는 향상된 보안을 입증하지 않는다. 당장의 핵심은 자체적인 제한과 장애 조건을 지닌 인프라에 에이전트를 맞추는 일이다.
업그레이드 과정에서 이러한 추가 기능은 서로 다르게 다뤄져야 한다. 기존 게이트웨이를 통한 요청을 복구하는 수정은 망가진 동작을 해결한다. 명령어가 할 수 있는 일을 바꾸는 설정은 정책 결정이 필요하다. 둘을 모두 일상적인 편의 기능으로 취급하면 서로 다른 결과를 가리게 된다.
개발팀 관점에서 이는 고르지 않은 릴리스 평가를 만든다. 일부 변경 사항은 기존 워크플로가 다시 작동하는지 확인할 필요가 있다. 다른 변경 사항은 워크플로가 여전히 허용 가능한 경계 안에서 작동하는지 확인해야 한다. 같은 패키지에 포함됐더라도 이는 별개의 승인 기준이다.
공개된 노트는 변경 사항에 대한 Anthropic의 설명을 뒷받침한다. 하지만 독립적인 신뢰성 측정치나 완전한 보안 평가는 제공하지 않는다. 이 분석은 빌드를 테스트하거나 우회를 재현하거나 복구 시간을 측정하지 않았다.
따라서 가장 명확한 해석은 제한적이지만 유용하다. Claude Code v2.1.305는 실제 실행 환경의 마찰을 해결하는 동시에, 단순히 “이제 명령어가 작동한다”로 축소할 수 없는 결정을 드러낸다. 호환성에는 가치가 있지만, 그 가치에 붙는 조건도 중요하다.
플랫폼 팀이 호환성 결정을 떠안는다
공유 개발 환경을 책임지는 사람들은 가장 큰 의사결정 부담을 안게 된다.
개별 개발자는 로컬 실험을 개인적 필요에 비추어 판단할 수 있다. 플랫폼 팀은 같은 구성이 여러 저장소, 장비, 무인 작업 전반에 적용돼도 되는지 판단해야 한다. 허용 가능한 답은 해당 환경에 무엇이 있고 그 프로세스가 어떤 권한을 지니는지에 달려 있다.
브라우저 테스트 실패를 조사하도록 에이전트에 요청하는 가상의 팀을 생각해 보자. 이 조사에는 브라우저 실행, 출력 검사, 애플리케이션 코드 변경이 필요할 수 있다. 실행 제한이 브라우저를 막는다면 팀은 즉각적인 납품 문제에 직면한다. 호환성 예외는 눈에 보이는 장애물을 제거하므로 매력적으로 보일 수 있다.
덜 눈에 띄는 질문은 그 환경에서 접근 가능한 다른 모든 것에 관한 것이다. 일회용 장비에서의 테스트 실행은 민감한 파일 옆에서 실행되는 경우와 위험 프로필이 다르다. 따라서 같은 작업 설명도 실행 위치에 따라 서로 다른 구성을 정당화할 수 있다.
이 때문에 성공적인 시연은 정책 측면에서 제한적인 가치만 가진다. 특정 조건에서 특정 경로가 완료됐음을 입증할 뿐이다. 관련 없는 파일이 보호됐는지, 자격 증명이 불필요하게 노출됐는지는 입증하지 않는다. 이러한 질문에는 통과한 테스트 이상의 증거가 필요하다.
Anthropic의 이전 샌드박싱 아키텍처는 실행을 제한하면서 반복적인 승인 요청을 줄이는 방법으로 운영체제 제한을 제시했다. 그 근거는 자율성을 파일 시스템 및 네트워크 경계 모두와 연결한다. 이러한 배경은 해당 경계에 영향을 주는 변경 사항이 주의를 기울일 만한 이유를 설명한다.
조직 내 압력은 반대 방향으로 작용한다. 개발자는 차단된 명령어를 시간 손실로 경험한다. 보안 검토자는 약화된 제한을 노출 확대라고 본다. 플랫폼 책임자는 어느 한쪽이 다른 쪽에서 결과를 처리했다고 가정하지 않도록 하면서, 의도된 워크플로를 가능하게 하는 환경을 마련해야 한다.
명시적인 예외는 문서화되지 않은 우회책보다 관리하기 쉬울 수 있다. 검토자가 논의하고 기록할 구체적인 대상을 제공하기 때문이다. 그러나 눈에 잘 보인다고 해서 적절한 것은 아니다. 결정은 여전히 작업, 접근 가능한 리소스, 주변 통제 수단에 달려 있다.
따라서 즉각적인 대응은 워크로드별로 이뤄져야 한다. 새 옵션을 평가하는 팀에는 실제 실행 요건과 연결된 이유가 필요하다. 중단을 줄이고 싶다는 광범위한 선호만으로는 모든 개발 환경에 같은 변경을 적용할 충분한 근거가 되지 않는다.
이는 유용한 내부 문서의 형태도 바꾼다. 설정값만 기록하면 미래의 유지보수 담당자는 원래의 근거를 알 수 없다. 차단된 워크로드, 환경 가정, 책임자, 검토 조건을 기록하면 종속성이나 인프라가 변경될 때도 결정을 이해할 수 있다.
이 압력은 이론적이 아니라 운영상의 문제다. 초기 문제 해결 세션이 끝난 뒤에도 누군가는 구성을 책임져야 한다. 그렇지 않으면 제한된 이유로 도입된 예외가 그 근거가 된 워크로드가 사라진 뒤에도 오래 남을 수 있다.
샌드박스라는 명칭이 전체 경계를 설명하지는 않는다
보안 결정은 “샌드박스”라는 단어의 존재가 아니라 실제 동작에 달려 있다.
샌드박스는 프로그램의 주변 리소스 접근을 제한하는 실행 경계다. 이 용어는 모든 보호 대상 리소스나 프로세스를 구체적으로 규정하지 않는다. 그 의미는 구현, 구성, 그리고 실제 작업이 실행되는 경로에 달려 있다.
Claude Code의 현재 셸 샌드박스 문서는 셸 실행을 기본 파일 도구, hook, 외부 도구 서버와 구분한다. 또한 파일 제한과 네트워크 제한도 분리한다. 이러한 구분은 포괄적인 제품 명칭이 개별 제어 수단에 대한 이해를 대신하지 못하게 한다.
새 옵션은 이처럼 좁은 틀 안에서 평가해야 한다. Anthropic의 경고는 파일 보호에 관한 것이다. 모든 네트워크 제한이 사라진다거나, 모든 배포 환경이 취약해진다거나, 이 옵션이 보편적으로 활성화된다는 점을 입증하지는 않는다. 주장을 그 정도까지 확장하면 가용한 증거를 넘어선다.
경계 변경을 평가하는 유용한 방법은 이후에도 무엇을 강제할 수 있는지 묻는 것이다. 이 질문은 기능이 일반적으로 “안전한지”를 묻는 것보다 더 많은 정보를 준다. 모호한 전반적 평가 대신 구체적 리소스, 프로세스, 조건으로 논의를 이끈다.
예를 들어 한 조직이 코딩 에이전트 주변에 외부의 일회용 환경을 사용한다고 가정해 보자. 이 환경은 에이전트 자체 설정과 독립적인 제한을 제공할 수 있다. 그러한 제한이 충분한지는 별도의 평가가 필요하다. 내부 제어가 바뀌었다는 이유만으로 그 존재를 가정하거나 무시해서는 안 된다.
반대의 가정도 마찬가지로 취약하다. 무언가를 컨테이너라고 부른다고 해서 민감한 파일이 없거나 자격 증명에 광범위한 권한이 없다는 사실이 입증되지는 않는다. 검토자는 실제로 프로세스에 제공되는 리소스를 살펴봐야 한다. 아키텍처 명칭만으로는 이 질문에 답할 수 없다.
이것이 이번 릴리스의 핵심 절충안이다. 실행 호환성을 넓히면 에이전트가 정당한 작업을 완료하는 데 도움이 될 수 있다. 그 확장이 의존하던 경계를 약화한다면 환경을 새롭게 평가해야 한다. 이점과 비용은 같은 결정에 포함돼야 한다.
관련 증거에는 긍정적 동작과 부정적 동작이 모두 포함돼야 한다. 긍정적인 결과는 의도된 워크로드가 실행됨을 보여 준다. 부정적인 결과는 의도된 범위를 벗어난 작업이 계속 차단됨을 보여 준다. 후자가 없으면 호환성 검사는 격리에 관해 거의 말해 주지 못한다.
이러한 검사는 민감한 데이터 대신 무해한 테스트 리소스를 사용해야 한다. 목적은 제한을 확인하는 것이지 이를 조사하는 과정에서 사고를 만드는 것이 아니다. 통제된 테스트는 주장된 경계가 팀의 기대와 일치하는지 보여 줄 수 있다.
커뮤니케이션 문제도 있다. “샌드박스 활성화됨”은 편리한 상태 메시지이지만, 많은 세부 사항을 이진적 설명으로 압축한다. 배포 결정을 내리는 팀에는 확장된 설명이 필요하다. 어떤 프로세스가 적용 대상인지, 어떤 리소스가 제한되는지, 어떤 예외가 적용되는지 말이다.
그렇다고 샌드박싱이 도움이 안 되는 것은 아니다. 구체성이 필수적이라는 뜻이다. 명확히 설명되고 의도적으로 제한된 제어 수단은 독자가 각기 다르게 해석하는 광범위한 보장보다 더 유용하다.
제공업체 복구는 별도의 신뢰성 문제를 부각한다
에이전트는 코딩 능력이 중요해지기 전에 먼저 주변 서비스 계약에 맞아야 한다.
이번 릴리스의 제공업체 수정은 다른 경계, 즉 클라이언트와 요청을 받는 서비스 사이의 인터페이스에 관한 것이다. 게이트웨이는 그러한 요청을 라우팅하거나 관리하는 중개자다. 게이트웨이가 허용하는 기능은 클라이언트의 기대와 다를 수 있다.
기업 사용자에게 거부된 요청은 모델 자체를 사용할 수 있는 경우에도 모델 장애처럼 보일 수 있다. 실무적 결과는 같다. 유용한 추론이 시작되기도 전에 작업이 멈춘다. 원인을 진단하려면 서비스 가용성과 요청 호환성을 구분해야 한다.
이 구분은 대체 동작에 운영상 중요성을 부여한다. 선택적 기능이 자동으로 보편적인 가용성 요건이 되어서는 안 된다. 동시에 기능 없이 복구하는 경우에는 또 다른 질문이 생긴다. 성공한 요청 동안 어떤 기능이 계속 사용 가능했는지 운영자가 알 수 있는가?
가상의 에이전트는 요청이 조정된 뒤 작업을 완료할 수 있습니다. 사용자 입장에서는 복구가 반갑지만, 운영자 입장에서는 무엇이 변경되었는지도 기록으로 설명되어야 합니다. 그렇지 않으면 겉보기에는 일관되지 않은 동작을 나중에 조사하기 어려워질 수 있습니다.
이는 더 폭넓은 신뢰성 원칙이며, 이번 릴리스에 문서화되지 않은 로깅이 있다는 주장은 아닙니다. 복구와 관측 가능성은 함께 작동해야 합니다. 관측 가능성이란 시스템의 동작을 이해하기에 충분한 기록을 갖추는 것을 뜻합니다. 재시도의 원인과 결과가 보일 때 성공한 재시도를 더 신뢰할 수 있습니다.
무인 복구의 시점은 관련된 또 다른 문제를 낳습니다. 작업을 막았던 조건이 바뀐 뒤에도 작업이 멈춘 상태로 남아 있을 수 있습니다. 야간 실행에 의존하는 팀에 유용한 결과는 단순히 작업이 가능해졌다는 사실을 결국 알게 되는 것이 아니라, 작업이 완료되는 것입니다.
그러나 더 빠른 복구가 올바른 복구를 보장하지는 않습니다. 무인 에이전트는 작업 상태도 보존해야 하며, 이전 진행 상황에 대해 뒷받침되지 않는 가정을 해서는 안 됩니다. 운영자는 활동 자체를 성공의 증거로 여기기보다 재개된 실행의 결과를 평가해야 합니다.
GitHub의 agent firewall controls는 관리되는 실행에 대한 다른 제품의 접근 방식을 보여 줍니다. 해당 문서는 제한된 인터넷 액세스를 설명하고 한계도 명시적으로 밝힙니다. 방화벽은 네트워크 트래픽을 제어하지만, 파일, 권한 또는 애플리케이션 동작에 관한 모든 질문에 답하지는 않습니다.
이 비교는 신중한 결론을 뒷받침합니다. 코딩 에이전트는 점점 여러 독립적인 제어 체계를 갖춘 시스템 안에서 작동합니다. 요청 게이트웨이, 파일 시스템 제한, 네트워크 방화벽은 서로 다른 문제를 해결합니다. 한 경계에서의 성공이 다른 경계에서의 성공을 입증할 수는 없습니다.
이 때문에 실무적 평가는 코딩 시연보다 더 까다롭습니다. 구매자는 에이전트가 실제 인프라를 통해 대표적인 작업을 완료할 수 있는지 평가해야 합니다. 또한 복구 경로가 조직에서 요구하는 제한과 기록을 유지한다는 증거도 필요합니다.
동작을 설명해야 하는 부담은 공급업체에, 현실적인 조건을 시험해야 하는 부담은 고객에게 있습니다. 운영 인프라가 거부할 가정을 통과 시연이 숨길 때 어느 쪽도 이득을 얻지 못합니다.
이 릴리스가 입증하지 않는 것
문서화된 수정은 의도된 변경의 증거이지, 모든 환경에서 성공적으로 배포되었다는 증거는 아닙니다.
공개된 릴리스 자료는 추가 사항과 수정 사항을 보도할 근거를 제공합니다. 그러나 모든 Linux 구성, 게이트웨이 정책 또는 워크로드에서 그 효과가 입증되지는 않습니다. 이러한 환경은 운영상 중요한 차이를 보일 수 있으므로, 이 한계는 분명히 남아 있어야 합니다.
인용된 자료에는 무인 작업 완료율이 얼마나 개선되는지 보여 주는 독립 벤치마크가 없습니다. 또한 여기에는 새 호환성 옵션의 모든 영향을 규정하는 재현된 보안 평가도 없습니다. 따라서 성능 향상이나 보편적인 심각도 등급을 부여하는 일은 근거가 부족합니다.
가장 강한 회의적 해석은 증거의 품질에 관한 것입니다. 설정이 명확히 문서화되어도 로컬 검증이 필요할 수 있습니다. 공급업체는 모든 고객 구성을 포괄하지 않더라도 수정 사항을 정확히 설명할 수 있습니다. 이러한 가능성은 테스트를 정당화하지만, 릴리스가 실패했다고 가정할 근거는 되지 않습니다.
구성 범위는 또 다른 복잡성을 더합니다. Claude Code의 settings precedence 문서는 개인, 프로젝트, 관리형 소스를 구분합니다. 한 파일에서 보이는 값이 반드시 실제 적용되는 구성을 설명하지는 않습니다. 검토자는 평가 중인 세션에서 실제로 무엇이 로드되는지 이해해야 합니다.
이는 팀이 결과를 비교할 때 중요합니다. 개발자는 동일한 구성을 테스트했다고 믿을 수 있지만, 환경마다 설정을 다르게 해석할 수 있습니다. 차이를 모델 동작 탓으로 돌리기 전에 검토자는 그러한 결론을 뒷받침할 만큼 실행 조건이 충분히 일치하는지 확인해야 합니다.
기본값에 대한 주장에도 같은 주의가 필요합니다. 새 설정이 존재한다고 해서 그것이 모든 곳에서 활성화되었다는 뜻은 아닙니다. 릴리스 경고 역시 특정 조직이 현재 민감한 파일을 노출하고 있음을 입증하지 않습니다. 그러한 주장을 하려면 해당 조직의 배포 환경에 관한 증거가 필요합니다.
공정한 평가는 긍정적인 사례를 유지합니다. 호환성 개선은 유용한 작업을 가로막는 정당하지 않은 장벽을 제거할 수 있습니다. 더 명확한 복구 동작은 피할 수 있는 중단을 줄일 수 있습니다. 어느 이점도 모든 배포 환경이 모든 옵션을 채택해야 한다거나 모든 불확실성이 사라졌다고 주장할 필요는 없습니다.
구매자에게 실질적인 위험은 이러한 구분을 하나의 승인으로 압축하는 데 있습니다. 업그레이드 결정과 예외 결정은 별도의 판단이 필요합니다. 전자는 새 버전의 동작에 관한 것이고, 후자는 조직이 부여하기로 선택한 권한에 관한 것입니다.
개발자에게는 문제 해결이 성공한 뒤 맥락을 잃을 위험이 있습니다. 막혔던 명령이 실행되기 시작하면 변경 사항을 문서화해야 할 즉각적인 동기는 약해집니다. 그러나 향후 유지보수 담당자는 작동 중인 구성이 그 문제의 원인을 더 이상 드러내지 않기 때문에 სწორედ 그 설명이 필요합니다.
팀은 이러한 결정을 technical knowledge base와 함께 보존할 수 있습니다. 유용한 기록에는 관찰된 동작, 가정, 해결되지 않은 질문이 포함됩니다. 누군가의 기억에 의존하지 않고도 미래의 검토자가 결정을 재구성할 수 있도록 해야 합니다.
적절한 결론은 조건부입니다. 이 릴리스는 영향을 받는 워크플로와 비교해 평가할 가치가 있는 변경 사항을 제공합니다. 이러한 변경이 더 광범위한 배포를 정당화하는지는 에이전트가 실제로 작동할 환경에서 나온 증거에 달려 있습니다.
Claude Code v2.1.305 이후 주목할 점
다음으로 유용한 신호는 재현 가능한 경계 테스트, 복구 증거, 구성 가시성입니다.
첫 번째 신호는 현실적인 조건에서 Linux 호환성 옵션을 문서화하여 테스트하는 것입니다. 중요한 결과는 성공적인 실행과 남아 있는 제한에 대한 증거를 함께 제시합니다. 보고서는 환경을 식별하고 관찰된 동작과 샌드박스 작동 방식에 관한 가정을 구분해야 합니다.
정당한 워크로드가 실행되는 동안 독립적으로 강제되는 경계가 계속 유지된다면, 통제된 도입의 근거가 강화될 것입니다. 검토자가 무엇이 여전히 보호되는지 판단할 수 없다면 신뢰는 제한된 수준에 머물러야 합니다. 브라우저 테스트 하나가 통과했다고 해서 보안 문제를 해결할 수는 없습니다.
가장 유용한 보고서는 에이전트 내부의 제한과 주변 인프라도 구분할 것입니다. 이러한 구분은 독자가 각 보호 기능을 어느 구성 요소가 제공하는지 이해하는 데 도움이 됩니다. 그렇지 않으면 성공적인 결과가 동일한 외부 통제 장치가 없는 배포 환경에 잘못 일반화될 수 있습니다.
두 번째 신호는 영향을 받는 공급자 및 무인 워크플로에서 나오는 증거입니다. 팀은 일반적인 게이트웨이 규칙 아래에서 완료된 대표 작업을 찾아야 합니다. 또한 복구 기록이 예상치 못한 동작을 운영자가 조사할 수 있을 만큼 명확하게 발생한 일을 설명하는지도 살펴봐야 합니다.
일관된 완료는 테스트된 조건에서 Anthropic의 신뢰성 주장을 뒷받침할 것입니다. 더 광범위한 권한이나 설명되지 않은 구성 변경이 반복적인 실패를 해결하는 데 필요하다면, 배포 결과에 대한 신뢰는 약화될 것입니다. 어느 결과든 업데이트가 더 좋아진 것 같다는 일반적인 보고보다 더 많은 정보를 제공합니다.
세 번째 신호는 실제 적용 구성에 대한 더 명확한 가시성입니다. 경계를 바꾸는 예외를 드러내는 향후 문서 또는 인터페이스 변경은 이러한 결정을 더 쉽게 감사할 수 있게 합니다. 범위와 결과를 명시적으로 설명하면 서로 다른 팀이 같은 상태를 다르게 해석할 가능성도 줄어듭니다.
호환성 설정을 더 쉽게 이해하고 검토할 수 있게 되면 이러한 절충은 더 관리하기 쉬워집니다. 명확한 책임자 없이 예외가 쌓이면 운영 복잡성이 커집니다. 이는 Anthropic의 다음 릴리스에 대한 예측이 아니라 관찰 기준입니다.
이러한 신호는 배포 결정을 바꾸는 증거에 주의를 집중하게 합니다. 관련 없는 모델 발표를 실행 신뢰성의 대리 지표로 사용하는 일을 피합니다. 코딩 능력이 향상되더라도 파일 액세스, 게이트웨이 동작 또는 무인 복구에 대한 불확실성이 저절로 해소되지는 않습니다.
Claude Code v2.1.305를 고려하는 팀이라면, 업데이트가 중요한 이유가 되는 워크로드부터 시작하십시오. 기대하는 이점이 수정된 요청 경로, 재개된 자동화 또는 실행 예외와 관련되는지 확인하십시오. 그런 다음 일반적인 제품 시연이 아니라 실제 환경을 기준으로 그 이점을 평가하십시오.
대표 작업을 선택하고 릴리스를 평가하기 전에 성공을 정의하십시오. 예상 출력, 허용된 리소스, 계속 차단되어야 하는 동작을 기록하십시오. 호환성 결정은 업그레이드 결정과 분리하고, 다른 검토자가 둘 다 이해할 수 있을 만큼 충분한 증거를 보존하십시오. 예외가 필요하다면 워크로드와 연결된 이유 및 책임자를 지정하십시오. 증거가 불완전하게 남아 있다면, 성공적인 실행을 광범위한 보증으로 바꾸지 말고 그 불확실성을 보존하십시오. Claude Code v2.1.305를 구체적인 질문에 답할 기회로 활용하십시오. 이 에이전트가 팀이 설명하고 검증할 수 있는 경계 안에서 의도한 작업을 완료할 수 있는가?
