Claude Code v2.1.314, 자동화 작업에 더 엄격한 경계 추가

Anthropic은 10월 30일 Claude Code v2.1.314를 출시하며, 권한 모드 전반에 적용되는 파일 쓰기 제한과 엔터프라이즈 라우팅 제어 기능을 추가했다. 이번 업데이트는 유휴 상태의 대화 요약 기능도 VS Code와 Claude Desktop의 Code 탭으로 확장한다. 이러한 변화는 실질적인 긴장을 다룬다. 개발자는 코딩 에이전트가 계속 작업하기를 원하지만, 관리자는 자동화된 작업 중에도 유효한 경계가 필요하다.

이번 릴리스는 에이전트 접근 권한, 클라우드 연결, 긴 개발 세션을 관리하는 팀에 새로운 과제를 제시한다. 에이전트에 작업 진행 권한을 부여했다고 해서 어떤 파일을 변경해야 하는지, 또는 어떤 인프라로 요청을 보내야 하는지가 결정되는 것은 아니다. 그러한 판단에는 모델이 작업을 해석하는 방식 밖에서 작동하는 제어가 필요하다.

GitHub Copilot은 로컬 샌드박싱 역시 자동화된 실행과 무제한적인 머신 접근을 분리한다는 점에서 유용한 비교 대상이다. Anthropic의 업데이트도 이러한 운영 논의의 맥락에서 볼 수 있다. 그 의미는 코딩 능력 향상 발표 자체보다는 권한, 복구, 대화 관리가 상호작용하는 방식에 있다.

Claude Code v2.1.314의 변경 사항

이번 업데이트는 작업 위치와 중단된 작업의 지속 방식을 제어하는 기능을 추가한다.

공식 릴리스 노트에 따르면, permissions.blockWritesOutsideWorkingDirectories는 모든 권한 모드에서 작업 디렉터리 밖의 경로에 대해 Write, Edit, NotebookEdit를 거부하도록 한다. 게이트웨이는 페일오버 상황을 포함해 선택적으로 업스트림 groups 제한을 추가한다. Bedrock 통합에는 일치한 텍스트를 기록하지 않으면서 작동한 필터를 식별하는 guardrail_trace도 추가됐다.

이러한 변경은 서로 다른 경계를 다룬다. 파일 제한은 로컬 수정에 관한 것이다. 게이트웨이 라우팅은 모델 요청이 이동하는 위치에 관한 것이다. 필터 추적은 관리자가 사후에 확인할 수 있는 정보에 관한 것이다. 이를 별도의 제어 기능으로 다루면 가치와 한계를 모두 이해하기 쉬워진다.

작업 디렉터리는 세션에서 허용된 작업 공간에 포함된 폴더다. 새 설정은 지정된 파일 도구에 대해 이 경계에 명시적 의미를 부여한다. 작업을 완료하라는 지시만으로는 이 범위가 자동으로 확장되지 않는다.

저장소와 다른 프로젝트가 들어 있는 인접 폴더를 포함하는 예시 유지보수 작업을 생각해 볼 수 있다. 제안된 변경은 두 폴더에 걸쳐 기술적으로 타당할 수 있다. 하지만 에이전트가 이를 수행해야 하는지는 변경 사항의 빌드 가능 여부와 별개의 권한 부여 문제다.

따라서 디렉터리 경계는 정당한 작업을 중단시킬 수 있다. 이 중단은 유용한 정보다. 작업 공간을 의도적으로 확장해야 하거나, 제안된 수정이 할당 범위를 벗어났다는 뜻이기 때문이다. 인접 파일을 조용히 사용 가능한 것으로 취급하면 이러한 결정을 숨기게 된다.

게이트웨이 변경은 인프라에도 같은 일반 원칙을 적용한다. 업스트림은 게이트웨이가 모델 요청을 보내는 공급자 연결이다. 개발자가 게이트웨이에 접근할 수 있다고 해서 그 뒤에 있는 모든 업스트림을 사용할 권한까지 갖는 것은 아니다.

장애 발생 후 다른 연결로 전환하는 페일오버에서는 이 구분이 특히 중요해진다. 복구는 접근 요구사항을 유지해야 한다. 그렇지 않으면 서비스가 사용할 수 없게 되는 순간이 곧 라우팅 정책이 바뀌는 순간이 된다.

유휴 압축은 다른 방향에서 연속성을 다룬다. 압축은 대화 기록을 요약해 더 긴 작업 컨텍스트를 더 짧은 표현으로 대체한다. 이번 릴리스는 긴 대화가 사용되지 않은 채 남아 있을 때 지원되는 에디터와 데스크톱 세션으로 이 동작을 확장한다.

이 기능들을 코드 품질 향상의 증거로 해석해서는 안 된다. 명시된 목적은 운영에 있다. 즉, 작업을 제한하고, 라우팅 요구사항을 유지하며, 진단을 개선하고, 세션을 더 쉽게 이어갈 수 있게 하는 것이다. 실질적 가치는 이러한 동작이 현실적인 워크로드에서도 유지되는지에 달려 있다.

관리자는 자동화 이면의 결정을 떠안게 된다

실행의 자율성이 높아질수록 명시적인 관리 결정의 중요성도 커진다.

개발자는 일반적으로 즉각적인 작업을 기준으로 코딩 어시스턴트를 평가한다. 관련 파일을 찾았는가, 요청한 변경을 했는가, 결과를 설명했는가를 본다. 관리자는 그 작업을 둘러싼 조건까지 고려해야 한다.

이러한 조건에는 작업 공간 범위, 공급자 적격성, 조직 설정, 장애 처리 방식이 포함된다. 패치가 성공했다고 해서 승인된 연결을 사용했다는 답이 되지는 않는다. 세션이 완료됐다고 해서 모든 시도된 작업이 정책 범위 안에 있었다는 뜻도 아니다.

게이트웨이 아키텍처는 책임 분담을 설명한다. Anthropic은 이를 기업 로그인 체계를 통해 개발자를 클라우드 모델 공급자와 연결하는 자체 호스팅 서비스로 설명한다. 게이트웨이는 업스트림 자격 증명을 보유하고 접근 제어와 관리형 설정을 적용한다.

ID 공급자, 즉 IdP는 로그인 신원과 그룹 멤버십을 제공하는 기업 시스템이다. 그룹 기반 라우팅은 이 신원 정보를 요청 경로의 일부로 만든다. 따라서 그 유용성은 조직이 의미 있는 그룹을 유지하는지에 달려 있다.

예를 들어, 실험적 엔지니어링 팀과 제한된 고객 프로젝트를 담당하는 직원을 분리하는 엔터프라이즈를 상상해 볼 수 있다. 두 팀 모두 같은 코딩 인터페이스를 사용한다. 그러나 작업에 서로 다른 내부 요구사항이 수반되므로 허용된 공급자 연결은 다르다.

이는 문서화된 고객 배포 사례가 아니라 예시 시나리오다. 공유 인터페이스가 별도의 접근 규칙 필요성을 없애지 않는 이유를 보여 준다. 관리자는 여전히 조직의 결정을 시스템이 강제할 수 있는 설정으로 옮겨야 한다.

이 과정은 유지보수 작업을 만든다. 그룹 이름은 바뀌고, 직원은 이동하며, 공급자 배포 환경은 발전하고, 임시 접근 예외는 누적된다. 라우팅 기능은 메커니즘을 제공할 뿐, 어떤 조직 경계를 강제해야 하는지는 결정하지 않는다.

즉각적인 부담은 플랫폼 엔지니어링과 개발자 인프라 팀에 돌아간다. 이들은 일상적인 워크플로는 편리하게 유지하면서 예외가 의도적으로만 발생하도록 해야 한다. 보안 팀은 모든 지원 조사를 대화 내용에 대한 무제한 접근으로 바꾸지 않으면서도 장애를 이해할 만큼의 가시성이 필요하다.

개발자도 영향을 받는다. 이전에는 계속되던 요청이 이제 디렉터리 경계에서 멈출 수 있다. 동료에게 제공되는 공급자 연결이 자신에게는 제공되지 않을 수도 있다. 의도적인 제한이 임의적인 제품 장애처럼 보이지 않으려면 명확한 설명이 중요하다.

실질적인 대응은 예상치 못한 동작을 진단하기 전에 예상 동작을 정의하는 것이다. 팀은 어떤 폴더가 작업에 속하는지, 어떤 공급자 연결이 특정 그룹에 속하는지 알아야 한다. 이러한 기대가 없으면 정확한 강제조차 해석하기 어려워질 수 있다.

이는 도입 논의의 일부를 운영 책임으로 옮긴다. 누군가는 정책을 소유하고, 그 결과를 설명하며, 변경 사항을 검토해야 한다. 최신 클라이언트를 설치하면 기능은 제공되지만, 그러한 조직적 작업이 완료되는 것은 아니다.

파일 권한과 샌드박싱은 서로 다른 경계를 보호한다

파일 도구에 대한 제한은 셸 프로세스 주변의 보호와 별도로 평가해야 한다.

쓰기 제한의 표현은 중요하다. Anthropic은 특정 편집 도구를 명시하고, 해당 경계가 모든 권한 모드에 적용된다고 말한다. 이는 가능한 모든 쓰기에 대한 보편적 주장이 아니라 해당 도구에 대한 유의미한 주장을 확립한다.

셸 명령도 파일을 수정할 수 있다. 스크립트, 의존성 설치 도구, 개발 도구가 시작한 프로세스도 마찬가지다. 파일 시스템 보호를 평가하는 조직은 각 제어가 실제로 어떤 실행 경로를 다루는지 이해해야 한다.

Anthropic의 Bash sandbox 문서는 셸 명령과 그 하위 프로세스 주위의 운영체제 경계를 설명한다. 또한 이 경계를 권한 결정과 구분한다. 샌드박스는 셸 실행을 다루며, 다른 도구에는 각자 적용 가능한 제어가 필요하다.

실무에서는 구분이 간단하다. 권한 처리는 작업의 진행 여부를 결정한다. 격리는 실행 중인 프로세스가 접근할 수 있는 리소스를 제한한다. 둘 다 안전성에 영향을 주지만, 서로 다른 지점에서 작동한다.

이러한 분리는 단일 설정으로 설명한 Claude Code 권한에 대해 오해의 소지가 있는 결론을 방지하는 데 도움이 된다. 거부된 Edit 요청은 해당 제한이 작동했음을 보여 준다. 세션에서 사용할 수 있는 모든 스크립트나 외부 통합의 동작을 입증하는 것은 아니다.

마찬가지로 성공한 셸 명령이 반드시 파일 도구 규칙과 모순되는 것은 아니다. 관련 질문은 실행 환경, 적용되는 샌드박스 정책, 허용된 경로에 관한 것이다. 이러한 세부 사항이 관찰된 동작이 의도한 경계와 일치하는지를 결정한다.

따라서 유용한 평가는 직접 편집과 명령 기반 수정을 구분해야 한다. 또한 일반적인 작업과 재개된 작업, 대체 실행 환경도 구분해야 한다. 이는 이 글을 위해 수행된 테스트에 대한 주장이 아니라 제안된 평가 범주다.

경쟁 환경은 이 점을 더욱 부각한다. GitHub는 2026년 10월 7일 로컬 샌드박싱이 정식 출시됐다고 발표했다. 설명에 따르면 지원되는 Copilot 환경에서 제한된 파일 시스템, 네트워크, 자격 증명 접근을 제공한다.

GitHub는 샌드박스 정책이 사용하는 모델과 독립적으로 적용된다고도 말한다. 이는 실행 시스템에 강제 기능을 위치시킨다는 점에서 유용한 비교다. 모델을 선택하는 것과 해당 모델이 사용할 수 있는 리소스를 정의하는 것은 별개의 제품 결정이다.

이 발표들이 Claude Code와 Copilot 사이의 동일한 적용 범위를 입증하는 것은 아니다. 환경, 기본값, 지원되는 통합이 다르다. 공정한 비교는 기능 이름을 맞추는 대신 작업의 실제 실행 경로를 살핀다.

구매자에게는 포괄적인 레이블보다 구체적인 질문이 더 유용하다. 어떤 프로세스가 자격 증명을 받는가? 어떤 도구가 격리 안에서 실행되는가? 누가 정책을 완화할 수 있는가? 작업이 차단된 뒤에는 무엇이 일어나는가?

개발자에게는 예측 가능성이 이점이다. 명시적인 경계는 장애가 작업 변경, 구성 수정, 접근 요청 중 무엇을 필요로 하는지 이해하기 쉽게 만든다. 에이전트 안전성에 대한 모호한 가정은 이러한 가능성을 한데 얽히게 한다.

따라서 이번 릴리스에 대한 가장 강력한 해석은 구체적이다. Anthropic은 지정된 도구에 대해 또 하나의 강제 가능한 경계를 추가한다. 전체 작업 공간을 평가하려면 여전히 주변 실행 환경을 이해해야 한다.

게이트웨이 복구는 접근 규칙을 유지해야 한다

복구는 원래 요청에 연결된 조건을 준수할 때에만 유용하다.

공급자 장애는 어려운 운영상의 선택을 만든다. 다른 연결을 통해 작업을 계속하면 생산성을 유지할 수 있다. 그러나 정보가 이동하는 위치, 적용되는 자격 증명, 요청에 적용되는 조직 규칙이 바뀔 수도 있다.

업스트림 그룹 제한은 이 문제의 일부를 다룬다. 페일오버를 포함한다는 점은 라우팅이 바뀔 때도 접근 요구사항이 계속 중요하다는 뜻이다. 핵심 원칙은 서비스 연속성과 함께 권한 부여의 연속성도 유지하는 것이다.

내부 팀의 선호 연결에 적합한 요청을 가정해 보자. 해당 연결을 사용할 수 없게 되었지만, 다른 구성된 업스트림은 정상 상태로 남아 있다. 가용성만으로 개발자가 대체 경로를 사용할 수 있다고 판단해서는 안 된다.

이 예시는 실제 운영 장애를 보도하는 것이 아니라 정책상의 질문을 설명하기 위한 것이다. 예상 결과는 조직의 구성에 따라 달라진다. 적격한 대안이 없다면 의도적으로 거부하는 것이 올바른 결과일 수 있다.

이는 관리자가 인정해야 할 절충점을 만든다. 더 엄격한 라우팅 제한은 복구 경로의 수를 줄일 수 있다. 팀은 제한 없는 장애 조치와 범위가 좁은 공급자 접근이 항상 동일한 가용성을 제공한다고 가정할 수 없다.

Anthropic의 gateway configuration 문서도 정책 결정의 기반이 되는 ID 시스템을 강조한다. 그룹 매칭은 제공된 클레임에 따라 달라지며, 문서화된 매칭 규칙에는 대소문자 구분이 포함된다. 게이트웨이는 접근 권한을 평가할 때 이러한 ID 입력값을 사용한다.

클레임은 로그인 토큰에 포함되는 ID 정보의 한 조각이다. 따라서 잘못되었거나 불완전한 그룹 정보는 라우팅 문제가 될 수 있다. 클라이언트 경험만으로 원인이 ID 구성에 있는지, 공급자 가용성에 있는지 드러나지 않을 수 있다.

이 지점에서 진단 기능이 중요해진다. 지원 팀은 접근 결정과 연결 장애를 구분해야 한다. 그렇지 않으면 문제 해결 과정에서 불필요한 구성 변경이 발생하거나 권한을 확대해야 한다는 압박으로 이어질 수 있다.

Bedrock 추적 기능 추가는 선택적 가시성의 또 다른 예를 제공한다. 트리거된 필터를 식별하면 일치한 텍스트를 공개하지 않으면서 거부된 요청을 설명하는 데 도움이 될 수 있다. 이는 운영자에게 기본 문구를 자동으로 노출하지 않고도 설명의 범주를 제공한다.

이는 제한적인 진단 약속이다. 필터 식별자가 거부가 올바르다는 점을 입증하지는 않는다. 또한 특정 엔지니어링 워크플로에 맞게 필터가 적절히 구성되었는지도 보여주지 않는다.

관리자는 이의가 제기된 결과를 조사하기 위해 승인된 재현 절차가 여전히 필요할 수 있다. 개발자에게는 정당한 작업이 반복적으로 실패할 때 이를 보고할 방법이 필요하다. 로그가 더 많은 정보를 제공하게 되더라도 이러한 조직적 절차는 여전히 필요하다.

더 넓게 보면 개인정보 보호 측면에서도 구분할 점이 있다. 이 추적에서 일치한 텍스트를 생략한다고 해서 다른 모든 로그 또는 모니터링 시스템의 내용까지 보장되는 것은 아니다. 팀은 한 기능의 보장을 전체 환경으로 확대 해석하지 말고 전체 배포 환경을 평가해야 한다.

운영상 목표는 설명 가능한 결과다. 요청은 적격한 연결에 도달하거나, 관련 제약을 식별하는 실패를 반환해야 한다. 이러한 명확성 없이 재시도를 반복하면 근본적인 결정은 해결되지 않은 채 시간만 소모된다.

유휴 압축은 전체 기록 대신 더 짧은 작업 컨텍스트를 제공한다

대화 요약은 중요한 결정을 보존할 때에만 연속성을 높인다.

에디터 및 데스크톱 확장 기능은 대화 관리를 많은 개발자가 작업하는 환경에 더 가깝게 가져온다. 누군가 회의에 참석하거나 변경 사항을 검토하거나 프로젝트를 전환하는 동안 대규모 세션은 유휴 상태로 남아 있을 수 있다. 다시 돌아오면 유지된 컨텍스트와 처리 오버헤드에 관한 의문이 생긴다.

토큰은 모델이 처리하는 텍스트 단위다. 이번 릴리스는 최소 200,000토큰에 도달한 대화에 유휴 압축을 적용한다고 설명한다. 프롬프트 캐시는 재사용 가능한 처리된 컨텍스트를 저장하며, 이 캐시가 만료되면 긴 대화를 다시 전송할 때 운영상 결과가 달라진다.

Anthropic의 idle compaction settings는 추가적인 적용 조건을 설명한다. 여기에는 자동 압축 활성화, 1시간 프롬프트 캐시, 기능 플래그 접근 권한, 충분한 대화 크기, 유휴 기간 중 컴퓨터가 켜져 있는 상태가 포함된다.

이러한 조건은 비활성 상태만으로 요약이 보장되지는 않기 때문에 중요하다. 세션을 비교하는 개발자는 자신의 환경과 설정을 고려해야 한다. 관찰된 차이가 자동으로 일관성 없는 동작을 의미하지는 않는다.

근본적인 절충점은 정보 압축이다. 짧은 요약은 작업의 주요 방향을 담을 수 있지만 원래 대화의 세부 사항은 빠질 수 있다. 이 생략이 중요한지는 다음 작업에 무엇이 필요한지에 달려 있다.

예시로 마이그레이션 논의를 생각해 보자. 대화에는 선택한 접근 방식, 기각된 대안, 호환성 예외, 그리고 이례적인 동작을 유지해야 하는 이유가 포함된다. 요약은 선택된 접근 방식은 유지하면서 예외를 덜 정확하게 표현할 수 있다.

이 시나리오의 위험은 의사결정 충실도와 관련된다. 매끄러운 대화 이어가기는 어시스턴트가 모든 중요한 제약을 보존했다는 충분한 증거가 아니다. 핵심 질문은 다음 행동이 여전히 승인된 기술적 결정을 따르는지다.

이는 Anthropic의 구현이 그러한 세부 사항을 잃는다는 뜻은 아니다. 공개된 기능 설명은 이 질문에 답하는 벤치마크를 제공하지 않는다. 정확한 과거 컨텍스트에 의존하는 팀에게는 여전히 평가 과제다.

문서는 유휴 압축을 비활성화하는 방법을 제공한다. 이는 적용 가능한 설정의 범위 안에서 사용자가 세션 동작을 선택할 수 있게 한다. 또한 팀이 혼란을 통해 발견하기보다 이 절충점을 명시적으로 논의할 수 있게 한다.

복잡한 작업에서 지속 가능한 프로젝트 기록은 대화 컨텍스트와 다른 목적을 수행한다. 검토된 요구사항, 아키텍처 결정 또는 미해결 차단 요소는 단일 채팅을 넘어 접근 가능해야 한다. 요약이 변경 승인 이유의 유일한 기록이 되어서는 안 된다.

searchable knowledge base는 기술 문서를 나중에 참조할 수 있도록 유지해 이러한 분리를 지원할 수 있다. 유용한 원칙은 특정 메모 작성 워크플로와 무관하다. 권위 있는 결정은 일시적인 대화 상태 밖에 보존해야 한다.

Claude Code v2.1.314에서 즉각적인 질문은 실제 엔지니어링 작업에서 복귀한 세션이 어떻게 동작하는가다. 관련 관찰 사항에는 유지된 제약, 필요한 재진술, 재개된 작업이 검토된 요구사항과 계속 일치하는지가 포함된다.

이번 릴리스는 해당 기능에 측정된 생산성 향상을 부여할 근거를 제공하지 않는다. 그 가치는 대화 크기, 업무 중단 패턴, 작업 복잡도에 따라 달라진다. 더 짧은 작업 컨텍스트는 도움이 될 수 있지만, 그 품질이 다음 편집에서도 그 도움이 유지되는지를 결정한다.

업데이트 후 주시할 사항

가장 강력한 근거는 경계의 일관성, 복구 가능한 실패, 충실한 세션 연속성에서 나올 것이다.

첫 번째 신호는 지원되는 권한 모드 전반의 디렉터리 강제 적용이다. 후속 문서와 재현 가능한 보고서는 새로운 파일 도구 제한이 일반 및 재개된 워크플로에서 어떻게 작동하는지 명확히 해야 한다. 일관된 결과는 설정에 명시된 적용 범위에 대한 신뢰를 높일 것이다.

설명되지 않는 예외의 증거는 그 신뢰를 약화시킨다. 보고서는 명명된 편집 도구와 셸 실행 또는 외부 통합을 구분해야 한다. 이러한 구분이 없으면 유용한 관찰도 전체 보호 모델에 대한 부정확한 주장으로 바뀔 수 있다.

두 번째 신호는 장애 발생 시 게이트웨이 동작이다. 관리자는 업스트림을 사용할 수 없게 되었을 때 접근 제한이 이해 가능한 상태로 유지되는지 살펴봐야 한다. 권한이 없는 대안을 통한 명확한 거부는 이번 릴리스의 정책 보존 목표를 뒷받침한다.

예상치 못한 라우팅이나 모호한 재시도 동작은 반대 방향을 가리킨다. 조직은 실패하는 계층을 식별해야 하므로 진단 품질이 중요하다. ID 정보, 라우팅 구성, 공급자 가용성, 콘텐츠 필터링에는 서로 다른 대응이 필요하다.

세 번째 신호는 유휴 압축 후 재개된 대화의 품질이다. 의미 있는 관찰은 어시스턴트가 작업 요구사항과 이전 결정을 유지하는지다. 반복적인 수정이 뒤따르는 짧은 컨텍스트는 실질적 이점을 줄일 것이다.

유용한 보고서는 민감한 대화 내용을 노출하지 않으면서 작업과 누락된 제약을 설명한다. 속도나 편의성에 관한 일반적인 인상은 이러한 근거를 보완할 수 있다. 그러나 특정 변경에 필요한 정보를 요약이 보존했다는 점을 입증할 수는 없다.

이 신호들은 운영상의 기준을 공유한다. 시스템은 자신의 경계와 적응 과정을 이해할 수 있게 해야 한다. 개발자는 언제 접근이 거부되었는지, 언제 라우팅이 제한되었는지, 언제 이전 컨텍스트가 요약되었는지 알아야 한다. 관리자는 조사에 필요한 그에 상응하는 근거를 확보해야 한다.

이 기준은 이번 릴리스를 균형 있게 바라보는 데도 도움이 된다. Claude Code 엔터프라이즈 제어 기능은 준비 상태에 관한 광범위한 주장보다 구체적인 워크플로를 통해 평가할 가치가 있다. 기능은 문서화된 범위 안에서 유용할 수 있으나, 다른 배포 관련 질문을 미해결 상태로 남길 수 있다.

Claude Code v2.1.314를 고려하는 조직은 대표적인 엔지니어링 작업과 명확히 명시된 기대치부터 시작해야 한다. 승인된 작업 공간, 적격한 공급자 연결, 세션이 유지해야 하는 기술적 결정을 식별하라. 그런 다음 실제 동작이 이러한 기대에 부합하는지 평가하라.

평가는 일상 업무와 가깝게 유지해야 한다. 즉, 저장소 변경, 공급자 중단, 휴식 후 긴 대화로의 복귀를 포함한다. 의도된 강제 적용과 장애를 구분할 수 있을 만큼의 맥락과 함께 예상치 못한 결과를 기록하라. 나중의 검토자가 동일한 기준에 따라 행동을 비교할 수 있도록 승인된 요구사항을 지속 가능한 문서에 보존하라. 이러한 관찰을 활용해 더 광범위한 도입이 정당한지, 어떤 구성 관련 질문이 남아 있는지 결정하라. 유용한 질문은 구체적이다. 업데이트된 에이전트가 팀이 의존하는 경계와 결정을 보존하면서 승인된 작업을 완료하는가?