Claude Code v2.1.304, 권한 결정을 더 명확하게 하다
Anthropic의 Claude Code v2.1.304는 자동화 작업을 위한 안내형 설정을 확장하는 동시에 더 명확한 권한 경계를 추가한다. 이 변화는 실질적인 긴장 관계를 다룬다. 개발자는 중단을 줄이길 원하지만, 팀은 여전히 누가 어떤 작업을 승인했는지 파악해야 한다.
이번 업데이트는 확장 기능, 승인 결정, 배포 설정 등 AI 코딩 어시스턴트를 둘러싼 작동 구조에 주목한다. 핵심은 새로운 코딩 성능 지표를 발표하는 데 있지 않고, 이 구조를 더 쉽게 점검할 수 있게 만드는 데 있다.
GitHub Copilot도 위임 작업과 실행 제어를 결합한다는 점에서 유용한 비교 대상이다. 이런 제품들에서 실질적인 질문은 에이전트가 작업을 완료했는지에만 그치지 않는다. 팀은 작업 중 어떤 경계가 유지됐는지도 알아야 한다.
Claude Code v2.1.304의 변경 사항
10월 19일자 Anthropic의 릴리스 노트에는 여러 관련 기능이 설명돼 있다. 먼저 실행된 플러그인이 모드의 훅을 건너뛸 경우, 트랜스크립트 알림이 해당 이벤트와 플러그인을 식별한다. 모드는 확장 기능이며, 훅은 이벤트로 실행되는 콜백이다.
이제 모드의 tool.check 응답은 decider: "person"을 허용한다. 권한 대화상자 또는 호스트 콜백만 해당 요청을 승인할 수 있다. 누구에게도 요청할 수 없는 경우 Claude Code는 모드가 제시한 이유와 함께 요청을 거부한다.
해당 이벤트에는 읽기 전용 도구 호출 여부를 나타내는 e.isReadOnly도 추가됐다. 한편 /auto-mode-setup은 프로젝트 정보와 최근 세션을 읽어 자동 모드를 맞춤 설정한다. 이제 Bedrock, Vertex, Foundry, Claude apps gateway, 텔레메트리가 비활성화된 세션을 지원한다.
또 다른 기능인 /claude-api managed-agents-secure는 설정을 변경하지 않고 Managed Agents 에이전트의 설정을 Anthropic이 공개한 보안 지침과 비교한다. Managed Agents는 Anthropic의 호스팅 에이전트 인프라다. 이러한 명령 이름은 업데이트를 이해하기 위해 필요한 작업이 아니라 제품 기능을 설명한다.
공통된 주제는 결정, 실행, 구성에 관한 정보를 더 명시적으로 제공한다는 점이다.
이 기능들은 에이전트 워크플로의 서로 다른 시점을 다룬다. 일부는 작업 전의 결정과 관련되고, 다른 일부는 작업 후 확인할 수 있는 설명이나 전체 세션을 둘러싼 설정과 관련된다.
이 구분은 중요하다. 릴리스는 모든 기본 집행 규칙을 바꾸지 않고도 가시성을 개선할 수 있기 때문이다. 더 명확한 설명은 동작을 조사하는 데 도움이 되지만, 독자는 모든 진단 기능 추가를 새롭게 집행되는 제한으로 해석해서는 안 된다.
가용성에도 같은 주의가 필요하다. 안내형 설정 기능에 더 폭넓게 접근할 수 있다고 해서 모든 모델, 조직 정책, 배포 구성에서 동일한 동작이 보장되는 것은 아니다. 이러한 조건은 별도의 문서 확인이 필요하다.
따라서 개발자에게 유용한 해석은 구체적이다. 이번 업데이트는 선택된 경계에서 더 많은 세부 정보를 드러낸다. 모든 확장 기능, 통합, 환경을 포괄하는 일괄적인 보장을 제공하지는 않는다.
예상치 못한 승인을 조사하는 가상의 팀을 생각해 보자. 이 팀은 제안된 작업, 정책 결정, 그 결정을 담당한 구성 요소를 분리해야 한다. 그렇지 않으면 성공적으로 완료된 작업이 불명확한 승인 경로를 감출 수 있다.
이러한 구분에 초점을 맞춘 릴리스는 눈에 띄는 벤치마크가 없어도 주목할 가치가 있다. 운영 소프트웨어에서는 어떤 일이 왜 발생했는지 설명하는 것이 정상 경로를 더 빠르게 만드는 것만큼 중요할 수 있다.
다음 질문은 이 추가 정보를 효과적인 업무 관행으로 전환해야 하는 주체가 누구냐는 것이다. 그 책임은 확장 기능과 공유 개발 환경을 유지하는 사람들에게 크게 돌아간다.
확장 기능 작성자가 마주하는 더 명확한 승인 계약
AI 코딩 어시스턴트는 단일 구성 요소만으로 작동하는 경우가 드물다. 개발자는 프로젝트 규칙, 확장 기능, 외부 도구, 애플리케이션별 승인 처리를 추가할 수 있다. 각 계층은 기대와 실제 동작이 엇갈릴 수 있는 또 하나의 지점을 만든다.
Anthropic의 권한 규칙은 이미 도구 유형을 구분하고 관리형 정책을 지원한다. 문서는 또한 권한 결정을 작업이 실행되는 환경을 제한하는 샌드박싱과 구분한다.
이 구분은 필수적인 맥락을 제공한다. 승인은 정책에 따라 작업을 진행해야 하는지에 답한다. 실행 경계는 실행 중인 작업이 접근할 수 있는 범위를 제한한다. 어느 질문도 다른 질문에 완전히 답하지는 않는다.
확장 기능 작성자는 결정의 결과만큼 그 결정의 의미도 신중하게 전달해야 한다.
확장 기능 유지관리자에게 이진적인 성공 결과는 설명이 부족할 수 있다. 도구는 사람이 승인했기 때문에, 기존 규칙이 허용했기 때문에, 또는 다른 메커니즘이 요청을 처리했기 때문에 실행될 수 있다.
이러한 경로는 개발 프로세스를 검토하는 기업에 서로 다른 의미를 갖는다. 워크플로가 사람의 검토를 약속한다면, 자동 완료만으로는 그 약속이 지켜졌음을 입증할 수 없다.
이는 구체적인 유지보수 부담을 만든다. 확장 기능 문서, 인터페이스 라벨, 오류 메시지는 동일한 승인 계약을 설명해야 한다. 그렇지 않으면 사용자는 중단된 작업 중의 동작을 통해 정책을 추론해야 한다.
유용한 가상 사례로 내부 배포 통합을 들 수 있다. 조직은 자동화된 준비 작업은 허용하되, 게시 작업은 권한을 가진 운영자에게만 맡길 수 있다. 이 통합 기능은 어시스턴트 안에 포함되더라도 그 구분을 유지해야 한다.
중요한 결과는 이해 가능한 성공뿐 아니라 이해 가능한 실패다. 차단된 워크플로는 어떤 결정이 아직 해결되지 않았는지 설명해야 한다. 이런 설명이 없으면 사용자는 의도적인 경계를 통합 기능의 오류로 오해할 수 있다.
애플리케이션 개발자에게 인터페이스 역시 정책 설계의 일부가 된다. 호스트 애플리케이션, 즉 어시스턴트를 내장하는 소프트웨어는 사용자가 이해할 수 있는 방식으로 승인 요청을 제시해야 한다.
대상이나 결과를 생략한 승인 화면은 표면적인 상호작용 요건을 충족할 수 있지만, 실질적인 감독은 거의 제공하지 못한다. 결정을 내리는 사람은 실제 작업을 평가할 수 있는 충분한 맥락이 필요하다.
이 압력은 공유 기본값을 유지하는 플랫폼 팀에도 미친다. 이들은 허용된 작업, 필수 검토, 검토자 부재에 관한 일관된 용어를 마련해야 한다. 그렇지 않으면 각 프로젝트가 호환되지 않는 가정을 발전시키게 된다.
여기에는 정밀성이 생산성을 높인다는 논거도 있다. 명확한 경계는 실패가 우발적인지, 예상된 것인지, 복구 가능한지 재구성하는 데 드는 시간을 줄인다. 또한 지원 논의가 추측에 덜 의존하게 만든다.
따라서 기업 구매자에게 확장 기능의 품질에는 구성 요소가 자신의 권한을 얼마나 잘 설명하는지도 포함된다. 기능의 폭만으로는 팀이 해당 구성 요소를 예측 가능하게 운영할 수 있는지 알기 어렵다.
이번 릴리스의 더 넓은 의미는 평가 기준의 변화에 있다. 확장 기능은 주변 워크플로가 기대되는 승인을 제공할 수 없는 상황을 포함해, 의사결정 동작으로 평가돼야 한다.
자동 모드가 논의를 환경적 맥락으로 옮기다
자동 모드는 일상적인 사람의 개입을 줄인 상태에서 작업을 평가하는 Claude Code의 권한 모드다. 제안된 작업을 평가하는 시스템인 분류기가 무엇을 진행할지 결정하는 데 참여한다.
Anthropic은 2026년 3월 24일 자동 모드를 도입했다. 7월 10일 업데이트에서는 모든 사용자에게 정식 제공되기 시작했다고 밝혔다. 따라서 10월 릴리스는 초기 출시가 아니라 기존 기능에 관한 것이다.
Anthropic은 자동화된 평가가 위험한 작업을 허용하거나 무해한 작업을 차단할 수 있음을 인정한다. 또한 부족한 환경 맥락과 모호한 의도가 이런 결정에 영향을 줄 수 있다고 설명한다.
자동화의 가치는 시스템이 작업을 둘러싼 환경을 얼마나 정확히 이해하느냐에 부분적으로 달려 있다.
명령의 의미는 텍스트만으로 결정되지 않는다. 같은 작업이라도 일회성 개발 작업 공간과 공유 운영 시스템에서는 서로 다른 결과를 초래할 수 있다.
이 점은 환경 지식을 외형적인 설정 선호가 아니라 실질적인 문제로 만든다. 어시스턴트는 무엇이 중요한지에 관한 맥락이 필요하고, 관리자는 제공된 맥락이 최신 상태로 유지된다는 확신이 필요하다.
앞서 설명한 더 폭넓은 설정 가용성은 승인된 접근 경로가 직접 연결과 다른 조직에서 가장 중요하다. 요청을 중개하는 라우팅 모델인 클라우드 게이트웨이는 종종 이러한 구성의 일부다.
그렇더라도 승인된 경로를 통한 접근이 모든 운영상 질문을 해결하는 것은 아니다. 팀은 연결성, 기능 가용성, 정책 집행, 설정 결과의 유용성을 구분해야 한다.
예시로 애플리케이션 코드와 운영 스크립트를 모두 포함한 저장소를 생각해 볼 수 있다. 개발자의 결함 조사 요청은 둘 다 읽는 것을 정당화할 수 있다. 그렇다고 해서 해당 스크립트가 지원하는 모든 작업에 대한 권한이 자동으로 생기는 것은 아니다.
그에 따른 긴장은 분명하다. 프로젝트 지식이 많아지면 관련성을 개선할 수 있지만, 추가 맥락은 정확성과 권한을 해석해야 할 자료도 늘린다.
최근 세션은 일시적인 우회 방법을 설명할 수 있다. 프로젝트 문서는 더 이상 존재하지 않는 환경을 언급할 수 있다. 이런 가능성은 시간이 지나도 설정 품질을 평가해야 하는 이유다.
바로 이 지점에서 “중단 감소”라는 표현에는 의미 있는 기준이 필요하다. 팀은 피할 수 있는 질문은 줄어드는 동시에 중요한 결정은 계속 가시적으로 유지되는지 살펴야 한다.
질문을 덜 하지만 더 많은 작업을 수동 복구로 보내는 워크플로가 반드시 생산성을 개선한 것은 아니다. 중단은 승인 단계에서 조사 단계로 옮겨졌을 뿐이다.
이 시점은 이번 릴리스가 운영 관점에서 읽힐 가치가 있는 이유도 설명한다. 권한 모드가 널리 제공되기 시작하면, 다음 질문은 실제 배포 구성 전반에서의 적합성, 명확성, 일관성에 관한 것이 된다.
Anthropic의 노트는 확장된 설정이 결정 품질을 얼마나 개선하는지 입증하지는 않는다. 여기에는 정확도 향상을 수치화하거나 검토 시간 감소를 추정할 근거가 없다.
구매자에게는 하나의 집중된 평가 질문이 남는다. 이 설정이 어시스턴트가 일상적인 개발 작업과 즉각적인 작업 범위를 넘어 결과를 초래하는 운영 작업을 구분하는 데 도움이 되는가?
그 답을 얻으려면 의도한 환경 내부에서 관찰해야 한다. 가용성은 기능에 접근할 수 있음을 보여주고, 운영 증거는 그 기능이 팀에 도움이 되는지를 보여준다.
Copilot은 실행 제어가 여전히 별도의 질문인 이유를 보여준다
GitHub의 에이전트 안전성 문서는 Copilot의 클라우드 에이전트가 임시적이고 방화벽으로 보호된 환경에서 작동한다고 설명한다. 임시적이라는 것은 일시적이라는 뜻이며, 방화벽은 네트워크 트래픽을 제한한다.
같은 문서는 Copilot CLI를 활성 모드에 따라 권한 프롬프트가 달라지는 로컬 명령줄 환경으로 설명한다. 이는 하나의 제품군 안에서도 서로 다른 실행 구성이다.
이 비교가 유용한 이유는 흔한 구매 실수를 드러내기 때문이다. 제품 이름만으로는 모든 세션을 둘러싼 모든 경계를 알 수 없다.
공급업체가 함께 패키징하더라도 권한 처리와 실행 격리는 별도로 평가할 필요가 있다.
이는 보안 순위가 아니라 아키텍처 비교다. 여기서 검토한 문서는 어느 공급업체가 모든 배포 환경에서 보편적으로 더 안전하다고 선언할 근거를 제공하지 않는다.
대신 경쟁 압력의 핵심은 벤더가 자율성과 통제의 관계를 얼마나 명확하게 설명하는지에 있다. 구매자는 실제 업무에 적용할 수 있을 만큼 정확한 설명을 필요로 한다.
클라우드 코딩 워크플로에서는 임시 환경이 특정 검토 프로세스를 지원할 수 있다. 로컬 워크플로에서는 주변 장비와 사용 가능한 리소스가 다른 운영 맥락을 만든다.
승인 시스템은 그러한 맥락 안에서 평가해야 한다. 어떤 작업이 허용되었다는 사실만으로는, 그것이 어디서 실행됐고 어떤 리소스를 사용할 수 있었는지 모르면 큰 의미가 없다.
가상의 의존성 업데이트를 생각하면 이 구분은 구체적으로 드러난다. 패치를 준비하고, 프로젝트 테스트를 실행하며, 패키지를 배포하는 일은 서로 연관돼 있지만 그 결과는 서로 다르다.
유용한 에이전트 워크플로는 작업 전반에 걸쳐 이러한 차이를 유지한다. 최초 요청이 일상적으로 들린다는 이유만으로 관리자가 모든 단계가 같은 권한을 상속받았다고 가정하도록 해서는 안 된다.
이는 엔지니어링 리더를 위한 실용적인 비교 프레임워크를 만든다. 이들은 제품이 권한을 어떻게 표현하는지, 어떤 실행 환경을 사용하는지, 검토를 위해 어떤 증거가 남는지를 살펴볼 수 있다.
이 질문들은 평가가 실제 책임 범위에 계속 연결되도록 돕는다. 한 개발자가 패치를 담당할 수 있는 반면, 다른 팀은 배포 자격 증명이나 네트워크 정책을 담당할 수 있다.
제품이 이러한 책임 경계를 넘을 때는 인수인계 과정이 이해 가능하게 유지돼야 한다. 그렇지 않으면 표면적인 편의성 때문에 조직은 누가 그 결과를 수용했는지 불분명해질 수 있다.
벤더에게는 문서화 과제도 있다. 마케팅은 흔히 연속적인 경험을 설명하지만, 운영 책임은 여러 시스템과 담당자에게 나뉘어 있다.
가장 설득력 있는 제품 설명은 사용자가 이를 역추적해 분석하지 않아도 이러한 분리를 드러낸다. 이는 조직이 로컬과 클라우드 개발을 모두 지원할 때 특히 중요하다.
Claude Code 권한 변경 사항에서는 이러한 비교가 분석의 현실성을 유지해 준다. 더 명시적인 승인 의미 체계는 그 범위 안에서 가치가 있지만, 인프라 통제에는 여전히 독립적인 주의가 필요하다.
따라서 경쟁의 핵심 질문은 어느 어시스턴트가 더 적은 질문을 하는가보다 넓다. 어려운 작업이나 예상치 못한 작업 이후 팀이 자신의 결정을 설명하도록 돕는 제품이 무엇인지도 포함된다.
구성 비교만으로는 배포를 인증할 수 없다
Anthropic의 배포 보안 가이드는 네트워크 제한, 자격 증명 처리, 도구 선택, 승인, 예산 및 모니터링을 다룬다. 이 가이드의 폭넓은 범위는 구성이 별도의 검토를 받아야 하는 이유를 보여준다.
구성 비교는 배포 상태와 문서화된 권장 사항 사이의 차이를 찾는 데 도움이 될 수 있다. 이는 설정이 합리적으로 보인다는 비공식적인 보증보다 검토자에게 더 구체적인 출발점을 제공한다.
비교 보고서는 보안 결정을 지원하지만, 배포된 애플리케이션 전체의 안전성을 확립하지는 않는다.
이 구분은 구성 자체의 범위에서 비롯된다. 설정은 선택된 통제를 설명하지만, 애플리케이션의 동작은 구현, 통합, 운영 관행 및 접근 가능한 리소스에도 좌우된다.
Anthropic의 샌드박스 경계 문서는 이 한계를 명시한다. 모델 동작은 보안 통제가 아니며, 맞춤 도구와 자체 호스팅 인프라에는 별도의 책임이 남는다고 설명한다.
이 가이드는 에이전트가 읽는 자료에 삽입된 악의적 지시를 뜻하는 프롬프트 인젝션도 다룬다. 에이전트가 답변이나 도구 출력으로 정보를 노출할 수 있다고 경고한다.
이러한 맥락은 독자가 새 비교 기능에서 무엇을 추론해야 하는지를 제한한다. 권장 사항과의 일치는 점검된 설정에 관한 증거일 뿐, 가능한 모든 워크플로를 포괄하는 증명은 아니다.
가상의 내부 도구는 그 차이를 보여준다. 구성은 적절해 보일 수 있지만, 도구 자체가 의도한 비즈니스 목적보다 더 광범위한 요청을 수락할 수 있다.
또 다른 예는 운영 책임에 관한 것이다. 보고서는 검토가 필요한 설정을 식별할 수 있지만, 해당 권장 사항이 적합한지 결정할 권한을 가진 사람이 조직 내에 여전히 필요하다.
일부 차이는 의도적인 요구 사항을 반영할 수 있다. 다른 차이는 간과된 기본값을 반영할 수 있다. 유용한 검토는 이 경우들을 구분하고, 모든 차이가 같은 의미를 지닌다고 가정하지 않으면서 근거를 기록한다.
커뮤니케이션 위험도 있다. 간결한 결과는 이를 둘러싼 단서보다 회사 내부에서 더 멀리 전파될 수 있다. 구매자는 범위가 한정된 비교를 일반적인 인증 주장으로 바꾸지 않아야 한다.
같은 분석적 엄격함은 읽기 전용 구분에도 적용된다. 구성을 변경하지 않는 작업도 신중한 해석과 후속 결정을 요구하는 결과를 낼 수 있다.
조달팀에게 관련 증거에는 비교의 적용 범위와 한계가 포함된다. 어떤 설정을 점검했고 배포의 어느 부분이 그 점검 범위 밖에 남는지 물어야 한다.
개발자에게 유용한 결과는 실행 가능한 설명이다. 하나의 발견 사항은 구성 선택을 그것이 영향을 미치는 기능 또는 노출과 연결해야 한다.
보안팀에게 비교는 검토 산출물로 활용될 수 있다. 발견 사항, 담당자 및 최종 결정이 계속 연결돼 있을 때 그 가치는 커진다.
여기서 기술 지식 관리가 중요해진다. 검색 가능한 기술 기록은 팀이 구성 선택의 근거를 이를 뒷받침한 문서와 함께 보존하도록 돕는다.
이 중 어느 것도 새 비교 기능이 효과가 없다는 뜻은 아니다. 이는 이를 평가하기 위한 올바른 기준을 제시한다. 즉, 유용한 적용 범위, 명확한 한계, 그리고 책임 있는 결정을 뒷받침하는 발견 사항이다.
감독이 개선되는지 보여줄 세 가지 신호
향후 몇 달 동안 독자는 이러한 기능을 관찰 가능한 결과와 연결하는 증거를 살펴봐야 한다. 가장 유용한 신호는 확장 기능 동작, 환경 설정 및 구성 검토와 관련된다.
더 나은 감독은 단순히 더 많은 설정이나 더 긴 기록이 아니라, 더 명확한 결정과 더 적은 설명되지 않은 결과를 만들어야 한다.
첫 번째 신호는 필수적인 인간 검토에 관한 공개적이고 재현 가능한 증거다. 확장 기능 예시와 집중 테스트는 성공적인 승인 처리와 미해결 요청을 구분할 수 있게 해야 한다.
증거에는 주변 워크플로에 검토자가 없는 무인 상황도 포함돼야 한다. 이러한 경우는 통합이 운영 압박 속에서도 명시된 계약을 유지하는지 보여준다.
일관된 결과는 명시적인 결정 의미 체계가 예측 가능성을 높인다는 근거를 강화할 것이다. 상충하는 동작은 조사가 필요한 더 좁은 구현 문제를 드러낼 것이다.
독자는 제품 동작과 통합 동작도 구분해야 한다. 특정 확장 기능의 실패가 기본 플랫폼 전반의 보편적 실패를 자동으로 입증하는 것은 아니다.
두 번째 신호는 새로 나열된 액세스 방식 전반의 문서화된 설정 품질이다. 사용 가능 여부는 출발점일 뿐이며, 유용한 증거는 실제 개발 업무에서 무엇이 달라졌는지 설명해야 한다.
설득력 있는 평가는 설정을 구체적인 결정과 연결한다. 어떤 일상적인 질문이 불필요해졌는지, 어떤 중대한 작업은 계속 적절한 검토를 받았는지를 설명해야 한다.
어시스턴트가 단지 더 빨라진 것처럼 느껴졌다고 말하는 보고서는 제한적인 지침만 제공한다. 작업 구성, 프로젝트 맥락 및 주변 정책 모두가 그러한 인상에 영향을 줄 수 있다.
명확한 예시는 환경적 맥락이 실용적인 자동화를 개선한다는 주장을 강화할 것이다. 프로젝트 경계를 둘러싼 반복적인 혼란은 그 주장을 약화시키고 문서화 또는 설정의 공백을 가리킬 것이다.
세 번째 신호는 시간이 지나도 구성 발견 사항이 얼마나 유용한지다. 검토자는 투명한 적용 범위, 이해하기 쉬운 설명, 권장 사항과 강제된 통제 사이의 명확한 구분을 살펴봐야 한다.
의미 있는 보고서는 조직이 무엇을 왜 변경할지 결정하도록 돕는다. 충분한 범위 정보가 없는 안심시키는 라벨은 그 결정에 덜 기여한다.
발견된 문제를 의도적으로 해결한 증거는 비교 기능의 운영상 가치를 뒷받침할 것이다. 발견 사항이 반복적으로 오해된다면 비교 자체가 정확히 작동하더라도 커뮤니케이션 문제를 드러낼 것이다.
이러한 신호는 어느 어시스턴트가 개발을 지배할지 예측할 필요가 없다. 더 즉각적인 질문, 즉 위임된 작업이 실제로 감독하기 쉬워지는지에 관한 것이다.
Claude Code v2.1.304는 감독 문제가 해결됐다고 주장하지 않으면서도 팀이 살펴볼 구체적인 동작을 제공한다. 그 중요성은 확장 기능, 애플리케이션 및 배포 관행이 이러한 구분을 얼마나 일관되게 유지하는지에 달려 있다.
다음 검토에서는 대표적인 워크플로를 선택하고 요청부터 결과까지 그에 따른 중대한 결정을 추적하라. 누가 권한을 가졌는지, 어떤 정보가 승인을 뒷받침했는지, 이후 어떤 증거가 남았는지 식별하라. 이러한 관찰을 조직이 의도했던 강제 경계와 비교하라. 다른 검토자가 나중에 그 근거를 이해할 수 있도록, 미해결 질문은 관련 프로젝트 문서에 연결해 두라. 이 작업은 기능 수에 의존하지 않고 이번 릴리스에 대한 실용적인 평가 기준을 제공한다. 엔지니어링 팀에 대한 질문은 구체적이다. 책임자는 어시스턴트가 왜 진행했는지, 왜 멈췄는지, 그리고 그 설명 중 어떤 부분을 실제로 검증했는지 설명할 수 있는가?
