AI 에이전트가 코드를 작성할 수 있다면, 잘못된 코드도 작성할 수 있습니다. 도구를 호출할 수 있다면, 잘못된 인자로 잘못된 도구를 호출할 수도 있습니다. 해결책은 더 스마트한 프롬프트가 아닙니다. 그것은 모델의 출력과 이를 실행하는 기계 사이의 격리 경계입니다. CubeSandbox는 바로 그 경계를 위해 구축된 시스템 중 하나이며, 이것이 무엇을 하는지, 다른 접근 방식과 어떻게 비교되는지, 그리고 에이전트가 실제 API와 실제 데이터에 접근하기 시작할 때 어디에 적합한지 이해하는 것이 중요합니다.
TL;DR (핵심 요약)
CubeSandbox는 AI 에이전트 코드를 실행하기 위한 오픈 소스 하드웨어 격리 샌드박스 서비스로, Tencent Cloud에서 제공합니다. 각 샌드박스는 KVM을 통해 자체 게스트 OS 커널을 가지며, 약 60ms 만에 시작되고, 5MB 미만의 메모리 오버헤드를 사용합니다. Apache 2.0 라이선스를 따르며 E2B SDK와 즉시 호환됩니다.
소개
에이전트 시스템은 이제 프로덕션 환경에서 코드를 작성하고 실행합니다. 코딩 에이전트는 Python 스크립트를 생성하고 실행합니다. 연구 에이전트는 페이지를 스크랩하고 파싱하여 그 결과를 다음 단계로 전달합니다. 데이터 에이전트는 CSV를 로드하고 모델이 런타임에 결정한 변환을 실행합니다. 이 코드 중 어느 것도 실행되기 전에 사람의 검토를 거치지 않았습니다. 이것이 에이전트 샌드박싱이 해결하는 핵심 문제입니다. 즉, 신뢰할 수 없는, 모델이 생성한 명령을 호스트, 파일 시스템, 자격 증명 또는 네트워크에 노출하지 않고 실행해야 합니다.
에이전트의 자율성이 커질수록 이 문제는 더욱 중요해집니다. SQL 쿼리에 대해 잘못된 모델은 성가실 뿐입니다. 그러나 `rm -rf`에 대해 잘못된 모델이나 스크랩된 웹 페이지 내에 주입된 명령을 따르는 모델은 보안 사고로 이어질 수 있습니다. 샌드박싱은 명확한 경계를 설정합니다. 에이전트는 일회용의 격리된 환경 내에서 원하는 대로 할 수 있으며, 그 어떤 것도 외부로 유출되지 않습니다.
두 번째, 조용한 문제가 있습니다. 에이전트는 단순히 코드를 실행하는 것이 아니라 API와 도구를 호출합니다. 샌드박스 내부에서 에이전트가 결제 API나 내부 서비스에 접근하는 것을 신뢰하기 전에, 해당 API가 올바르게 작동하는지, 그리고 에이전트가 예상대로 호출하는지 확인해야 합니다. 바로 이 지점에서 API 툴링이 런타임 격리만큼 중요해집니다. Apidog와 같은 플랫폼은 에이전트가 호출할 엔드포인트를 모의(mock)하고 테스트할 수 있게 해주므로, 자율 시스템이 샌드박스 환경에서 작동하기 전에 계약을 검증할 수 있습니다. 에이전트 아키텍처에 대해 이미 생각하고 있다면, 에이전트 AI 아키텍처에 대한 저희 가이드가 이러한 실행 및 도구 계층이 어떻게 통합되는지 다루고 있습니다.
이 기사의 나머지 부분에서는 CubeSandbox가 무엇인지, AI 에이전트가 왜 샌드박스를 필요로 하는지, 격리 모델이 어떻게 다른지, 그리고 이것이 에이전트가 의존하는 API를 테스트하는 것과 어떻게 연결되는지 설명합니다.
CubeSandbox란 무엇인가요?
CubeSandbox는 AI 에이전트 코드 실행을 위한 보안 샌드박스 시스템으로, Tencent Cloud가 2026년 4월 Apache 2.0 라이선스로 오픈 소스화했습니다. GitHub 태그라인은 이를 "AI 에이전트를 위한 즉각적이고, 동시적이며, 안전하고, 경량의 샌드박스"라고 간단히 설명합니다. 단순히 SDK가 아닙니다. 주로 Rust로 작성된 완전한 샌드박스 서비스 스택으로, 직접 배포할 수 있습니다.
아키텍처는 RustVMM과 KVM을 기반으로 하며, 이는 많은 클라우드 하이퍼바이저에서 사용되는 동일한 Linux 커널 가상화 계층입니다. 프로젝트 문서 및 공식 발표에 따르면, 이 시스템은 여러 구성 요소로 나뉩니다:
- CubeAPI: E2B 샌드박스 인터페이스를 미러링하는 REST 게이트웨이.
- CubeMaster: 노드 전반에 걸쳐 샌드박스를 스케줄링하는 클러스터 오케스트레이터.
- CubeHypervisor 및 CubeShim: 각 마이크로VM을 부팅하고 관리하는 KVM 가상화 계층.
- Cubelet 및 CubeProxy: 샌드박스를 실행하고 라우팅하는 노드 수준 에이전트.
- CubeVS: eBPF 기반 네트워크 계층으로, 커널 수준에서 샌드박스 간 네트워크 격리를 강제합니다.
주요 특징은 각 샌드박스가 자체 전용 게스트 OS 커널을 갖는다는 것입니다. 이는 호스트 커널을 공유하는 컨테이너와는 다른, 더 강력한 격리 모델입니다. Tencent가 발표한 수치에 따르면, 단일 동시성에서 콜드 스타트 시간은 약 60ms (50개 동시 생성 시 P95는 약 90ms로 평균 67ms)이며, 인스턴스당 5MB 미만의 메모리 오버헤드를 가지며, 단일 대형 호스트에서 수천 개의 샌드박스를 실행할 수 있습니다. 보도 자료에서는 96-vCPU 서버가 2,000개 이상의 동시 샌드박스를 지원한다고 언급합니다. Tencent는 CubeSandbox가 자체 인프라 내에서 대규모로 실행되었으며, MiniMax가 이종 환경에서 대규모 에이전트 기반 강화 학습 훈련에 사용했다고 밝힙니다.
샌드박스 상태를 체크포인트하고 복원하기 위한 이벤트 수준 스냅샷 롤백과 같은 일부 고급 기능은 아직 개발 중인 것으로 설명됩니다. 미래 지향적인 항목은 출시가 보장된 것이 아닌 로드맵으로 간주하고, 현재 상태는 저장소를 확인하십시오. 공급업체 자체 수치 외의 공개 벤치마크 방법론은 제한적이므로, 자신의 워크로드에 대해 성능 주장을 검증해야 합니다.
정확한 세부 정보는 CubeSandbox GitHub 저장소와 공식 문서 사이트에서 확인할 수 있습니다.
AI 에이전트가 샌드박스를 필요로 하는 이유
"보안"은 너무 모호해서 이에 대비한 설계를 하기가 어렵기 때문에 위협에 대해 구체적으로 파악하는 것이 도움이 됩니다. 팀이 샌드박싱으로 향하게 만드는 세 가지 실패 모드가 있습니다.
위험한 생성 코드. 모델은 올바르다고 믿는 코드를 생성합니다. 때로는 그렇지 않습니다. 잘못된 디렉토리를 삭제하거나, 무한 루프에서 메모리를 소모하거나, 없어야 할 곳에 파일을 씁니다. 이 중 어떤 것도 악의적인 것은 아니지만, 단순히 잘못된 것이며, 호스트 접근 권한이 있는 잘못된 코드는 위험합니다. 에이전트에게 영향 반경(blast radius) 개념을 주지 않으면, 에이전트는 이를 알 수 없습니다.
신뢰할 수 없는 도구 호출. 에이전트는 런타임에 모델이 결정한 바에 따라 도구와 API를 호출합니다. 문서, 웹 페이지 또는 도구 응답에 숨겨진 프롬프트 주입에 의해 모델이 조종된다면, 파괴적인 도구를 호출하거나, 공격자가 제어하는 인수를 전달하거나, 의도하지 않은 방식으로 호출을 연결할 수 있습니다. 모델은 여기서 신뢰할 수 있는 행위자가 아닙니다. 모델은 컨텍스트 창에 도달하는 모든 텍스트를 해석하는 역할을 합니다. AI 에이전트가 새로운 API 소비자로서의 역할에 대한 저희 글에서 이 문제를 더 깊이 다루고 있으며, 자율 호출자와 함께 기존 API 신뢰 가정이 왜 깨지는지 설명합니다.
데이터 유출. 이것은 사람들이 과소평가하는 부분입니다. 네트워크 액세스 및 비밀 정보에 접근할 수 있는 에이전트는 데이터 유출 채널로 변할 수 있습니다. 악성 지침은 에이전트에게 API 키를 포함하는 환경 변수를 읽어 외부 엔드포인트에 POST하도록 지시합니다. 송신 필터링(egress filtering) 및 자격 증명 격리 없이는, 데이터가 정문으로 걸어 나가기 때문에 샌드박스 경계는 의미가 없습니다. 이것이 CubeSandbox가 커널 수준 격리를 eBPF 기반 송신 필터링(CubeVS를 통해)과 결합하는 이유입니다. 네트워크가 완전히 개방되어 있다면 프로세스 격리만으로는 충분하지 않습니다.
공통점: 에이전트의 행동은 에이전트가 수집한 신뢰할 수 없는 데이터에 의해 부분적으로 제어되기 때문에, 에이전트가 올바르게 행동할 것이라고 가정할 수 없습니다. 샌드박스를 사용하면 모델이 신뢰할 수 있는지에 대한 추론을 중단하고, 어떤 상황에서도 유지되는 경계에 대해 추론을 시작할 수 있습니다. 이러한 동작을 프로덕션에 도달하기 전에 탐색하는 실질적인 방법에 대해서는 API를 호출하는 AI 에이전트를 테스트하는 방법을 참조하십시오.
에이전트 샌드박스 작동 방식: 격리 모델
모든 샌드박스가 동일한 방식으로 격리되는 것은 아니며, 그 차이는 보안 및 성능 모두에 중요합니다. 에이전트 생태계에서 볼 수 있는 네 가지 광범위한 접근 방식이 있습니다.
프로세스 수준 격리. seccomp 필터, 권한 축소(dropped capabilities), 네임스페이스 및 cgroup을 사용하여 코드를 제한된 OS 프로세스로 실행합니다. 이것은 가장 가볍고 약한 옵션입니다. 호스트 커널을 공유하므로, 커널 익스플로잇은 호스트 손상으로 이어집니다. 대부분 신뢰하는 코드에는 괜찮지만, 임의의 모델 출력에는 취약합니다.
컨테이너. Docker 스타일 컨테이너는 네임스페이스 및 리소스 제한을 추가하며, 운영적으로 익숙합니다. 그러나 컨테이너는 설계상 호스트 커널을 공유합니다. 컨테이너 탈출 취약점은 실제적이고 반복적인 버그 클래스이며, "공유 커널 컨테이너 내의 신뢰할 수 없는 코드"는 알려진 약점입니다. 많은 팀이 쉬운 이유로 여기서 시작하지만, 격리 한계에 부딪힙니다.
마이크로VM. 마이크로VM은 하드웨어 가상화(KVM) 내에서 최소한의 게스트 커널을 부팅합니다. 에이전트의 코드는 자체 커널에 대해 실행되므로, 커널 수준 익스플로잇은 호스트가 아닌 일회용 VM에 국한됩니다. Firecracker는 서버리스 워크로드에 이 모델을 대중화했으며, CubeSandbox는 이 범주에 속하며, RustVMM과 KVM을 사용하여 샌드박스별 게스트 커널을 제공합니다. 과거의 트레이드오프는 시작 시간이었습니다. 마이크로VM은 컨테이너보다 부팅이 느렸습니다. 최신 구현은 스냅샷 및 리소스 사전 프로비저닝으로 이를 해결하며, CubeSandbox가 100ms 미만의 시작 시간을 보고하는 방식이 바로 이렇습니다.
애플리케이션 커널. gVisor는 다른 경로를 택합니다. 사용자 공간에서 시스템 호출을 가로채고 자체적으로 Linux와 유사한 인터페이스를 구현하여, 워크로드가 호스트 커널과 직접 통신하지 않도록 합니다. 전체 VM 없이 강력한 격리 계층을 제공하지만, 시스템 호출 호환성 및 성능에 약간의 트레이드오프가 있습니다.
다음은 에이전트에 중요한 차원에서 이러한 접근 방식들이 어떻게 비교되는지에 대한 요약입니다:
| 접근 방식 | 격리 강도 | 콜드 스타트 | 오버헤드 | 커널 공유 | 예시 |
|---|---|---|---|---|---|
| 프로세스 + seccomp | 낮음 | 즉시 | 최소 | 공유 호스트 커널 | 제한된 서브프로세스, nsjail |
| 컨테이너 | 중간 | ~수십 ms | 낮음 | 공유 호스트 커널 | Docker, containerd |
| 마이크로VM | 높음 | ~50–150ms | 낮음–중간 | 전용 게스트 커널 | CubeSandbox, Firecracker |
| 애플리케이션 커널 | 높음 | ~수십 ms | 낮음–중간 | 사용자 공간에서 가로챔 | gVisor |
| 호스팅 샌드박스 API | 높음 (관리형) | 가변 | 관리형 | 관리형 | E2B, 호스팅 서비스 |
단 하나의 승자는 없습니다. 올바른 선택은 코드의 신뢰도, 콜드 스타트의 필요 속도, KVM 실행 가능 여부, 그리고 인프라를 직접 운영할 것인지 또는 서비스로 소비할 것인지에 따라 달라집니다.
전반적인 환경에서 CubeSandbox
CubeSandbox의 포지셔닝은 명확합니다. 컨테이너처럼 느껴질 만큼 빠른 콜드 스타트를 제공하는 하드웨어 수준 격리를, 서비스 형태로 대여하는 것이 아니라 직접 실행하는 형태로 배포합니다. 이는 세 가지 참조점과 직접적인 개념적 비교를 가능하게 합니다.
컨테이너와 비교. 컨테이너는 호스트 커널을 공유하지만, CubeSandbox는 각 샌드박스에 자체 커널을 제공합니다. 임의의 에이전트 생성 코드의 경우, 이것이 바로 보안상의 강점입니다. 비용은 KVM 지원 x86_64 Linux 호스트(베어 메탈 서버, 중첩 가상화를 지원하는 클라우드 VM 또는 로컬 작업용 WSL 2)가 필요하다는 것입니다. 플랫폼이 KVM을 노출할 수 없다면, 마이크로VM 기반 격리를 사용할 수 없으며, gVisor와 같은 사용자 공간 접근 방식이나 호스팅 API가 더 적합할 수 있습니다.
Firecracker와 비교. Firecracker는 서버리스를 위한 잘 알려진 마이크로VM이며, 그 자체로 빌딩 블록이지 에이전트 샌드박스 제품은 아닙니다. CubeSandbox 또한 KVM/RustVMM 기반이지만, 스택의 더 높은 계층에서 작동합니다. 즉, 오케스트레이터, E2B 호환 API 게이트웨이, eBPF 네트워크 격리를 제공하여, 샌드박스 서비스를 조립하는 것이 아니라 배포하는 형태입니다. 기본 요소가 필요하다면 Firecracker를, 에이전트 형태의 API를 가진 샌드박스 서비스가 필요하다면 CubeSandbox가 그 목적에 부합합니다.
E2B 및 호스팅 샌드박스와 비교. E2B는 관리형 서비스로 격리된 샌드박스를 제공합니다. API를 호출하면 인프라 관리는 다른 사람의 문제가 됩니다. CubeSandbox의 주목할 만한 설계 선택은 E2B SDK 호환성입니다. 문서는 이를 즉시 교체 가능한 드롭인(drop-in)으로 설명합니다. `E2B_API_URL`을 자체 호스팅 Cube 인스턴스를 가리키도록 설정하면 기존 코드가 계속 작동합니다. 이는 실제 결정을 "어떤 샌드박스"가 아니라 "관리형 서비스 대 자체 호스팅 인프라"로 바꾸며, 데이터 상주, 대규모 비용, 운영 소유권이 결정 요소가 됩니다. 또한 Tencent의 발표에 따르면 OpenAI Python SDK를 기본적으로 지원합니다.
솔직한 요약: CubeSandbox는 에이전트 샌드박스 분야에서 강력한 격리, 빠른 시작, 자체 호스팅, E2B 호환이라는 명확한 테마를 가진 신뢰할 수 있는 진입자입니다. 또한, 새로 나왔고 대부분 공급업체에 의해 문서화되었으므로 독립적인 벤치마크는 부족합니다. 커밋하기 전에 워크로드에 대해 프로토타입을 만들고 콜드 스타트, 밀도, 격리 동작을 측정하십시오.
이것이 에이전트가 호출하는 API 및 도구를 테스트하는 것과 어떻게 연결되는가
런타임 격리는 "코드가 나쁘면 어떻게 될까"라는 질문에 답합니다. 그러나 "에이전트가 호출하는 API가 나쁘거나, 에이전트가 잘못 호출하면 어떻게 될까"라는 질문에는 답하지 않습니다. 이들은 다른 문제이며, 둘 다 해결해야 합니다.
여행 예약을 하는 샌드박스 에이전트를 상상해 보세요. 코드는 CubeSandbox 내에서 안전하게 실행됩니다. 하지만 에이전트는 여전히 항공 API, 결제 API 및 내부 여정 서비스를 호출합니다. 이 중 하나라도 잘못된 응답을 반환하면, 에이전트는 루프에 빠지거나, 복구를 환각하거나, 하위 시스템으로 잘못된 데이터를 전달할 수 있습니다. 잘못된 멱등성 키(idempotency key)로 결제 API를 호출하면 격리만으로는 해결할 수 없습니다. 돈은 여전히 움직입니다. 샌드박스는 호스트를 에이전트로부터 보호합니다. 그러나 실제 서비스에 실제 호출을 하는 혼란스러운 에이전트로부터 시스템을 보호하지는 못합니다.
따라서 실제로 유효한 워크플로우는 두 가지 계층이 함께 작동합니다:
- 모델이 생성한 코드와 도구 호출이 호스트를 손상시키거나 데이터를 유출할 수 없도록 실행을 격리합니다. 이것이 CubeSandbox 계층입니다.
- 샌드박스 실행 전과 실행 중에 에이전트가 접근할 수 있는 모든 API 및 도구의 계약을 검증합니다. 이것이 API 툴링 계층입니다.
두 번째 계층의 경우, 에이전트가 동작을 테스트하는 동안 제어된 스탠드인(stand-in)과 통신하도록 종속성을 모의(mock)하고, 그런 다음 스키마 적합성, 오류 처리, 인증 및 엣지 케이스에 대해 실제 엔드포인트를 테스트합니다. Apidog를 사용하면 확정적이고 스키마에 정확한 응답을 반환하는 모의 서버를 구축하고, 샌드박스 에이전트를 여기에 연결하여 프로덕션에 영향을 주지 않고 에이전트가 성공 및 실패 경로 모두에 어떻게 반응하는지 관찰할 수 있습니다. 준비가 되면, 동일한 시나리오를 실제 API에 대해 실행하여 계약이 유효한지 확인합니다. 샌드박스 테스트에 대한 저희 설명서는 격리되고 통제된 환경에 대한 일반적인 테스트 관행을 다루고 있으며, 이는 여기에 직접 적용됩니다.
이러한 조합이 중요한 이유는 에이전트가 계약 변경(contract drift)을 증폭시키기 때문입니다. 사람은 API 응답이 이상할 때 알아차립니다. 에이전트는 종종 그렇지 않습니다. 응답을 그대로 받아들이고 이에 따라 행동합니다. 모의 및 테스트로 검증된 엄격한 API 계약은 자율 호출자가 하나의 잘못된 응답을 연쇄적인 문제로 확대시키는 것을 방지합니다. 에이전트가 Model Context Protocol(모델 컨텍스트 프로토콜)을 사용한다면, Apidog로 MCP 서버 테스트는 동일한 원칙을 도구 계층으로 확장합니다. 그리고 에이전트 소비자를 위한 API를 설계하는 경우, AI 에이전트를 위한 API 설계는 자율 호출을 예측 가능하게 만드는 계약 패턴을 다룹니다.
실제 사용 사례
격리 및 계약 접근 방식의 가치가 나타나는 몇 가지 패턴:
코딩 에이전트 및 코드 인터프리터. 모델은 질문에 답하거나, 데이터를 변환하거나, 차트를 생성하기 위해 코드를 작성하고 실행합니다. 이것은 전형적인 샌드박스 사용 사례이며 E2B 호환 API가 직접적으로 목표로 하는 것입니다. CubeSandbox의 샌드박스별 커널은 코드가 완전히 임의적이고 실행할 때마다 변경되기 때문에 중요합니다.
멀티테넌트 에이전트 플랫폼. 많은 고객의 에이전트가 공유 인프라에서 코드를 실행하는 경우, 테넌트 간 컨테이너 수준 격리는 위험합니다. 샌드박스별 하드웨어 격리는 한 테넌트의 에이전트가 악의적일지라도 유지되는 테넌시 경계를 제공합니다. 보고된 밀도(호스트당 수천 개의 샌드박스)는 VM당 하나의 테넌트 방식이 아닌 이 방식을 실행 가능하게 만듭니다.
에이전트 기반 RL 및 훈련 루프. 강화 학습으로 에이전트를 훈련하는 것은 수많은 수명이 짧고 신뢰할 수 없는 롤아웃을 실행하는 것을 의미합니다. Tencent는 MiniMax가 이종 환경에서 바로 이러한 목적으로 CubeSandbox를 사용했다고 언급합니다. 빠른 콜드 스타트와 인스턴스당 낮은 오버헤드는 훈련 실행이 가능한지 아닌지를 결정하는 차이점입니다.
도구 사용 연구 및 데이터 에이전트. 에이전트는 외부 콘텐츠를 가져오고, 파싱하고, 다운스트림 API를 호출합니다. 가져온 콘텐츠는 신뢰할 수 없으므로(프롬프트 주입 위험), 파싱 및 생성된 코드는 샌드박스에 있어야 하며, 다운스트림 API는 먼저 모의(mock)에 대해 실행되어야 합니다. 이것이 격리와 API 계약 테스트를 결합하는 것이 가장 효과적인 지점입니다.
신뢰할 수 없는 플러그인 또는 확장 프로그램 실행. 사용자가 에이전트가 실행하는 도구 또는 코드를 제공할 수 있다면, 정의상 타사 신뢰할 수 없는 코드를 실행하는 것입니다. 실행당 마이크로VM 경계는 적절한 자세이며, 서버리스 플랫폼이 Firecracker를 채택할 때 사용했던 것과 동일한 논리입니다.
결론
에이전트 샌드박싱은 에이전트가 사람의 검토 없이 코드를 실행하고 도구를 호출하기 시작한 순간부터 더 이상 선택 사항이 아니었습니다. CubeSandbox는 그 문제의 격리 절반에 대한 구체적이고 공개적인 해답입니다.
핵심 요약:
- CubeSandbox는 실제적이고 구체적입니다: Tencent Cloud의 Apache 2.0 오픈 소스 AI 에이전트용 샌드박스로, RustVMM과 KVM을 기반으로 하며 샌드박스별 게스트 커널을 제공합니다.
- 격리 모델이 핵심입니다: 샌드박스당 전용 커널은 임의의 모델 생성 코드에 대한 컨테이너 격리보다 강력하며, 100ms 미만의 콜드 스타트와 5MB 미만의 오버헤드가 보고됩니다.
- E2B 호환성은 전환 비용을 낮춥니다: E2B를 사용하고 있다면, 문서화된 즉시 교체 가능한 경로는 선택을 재작성이 아닌 관리형 대 자체 호스팅으로 재구성합니다.
- 공급업체 수치를 출발점으로 삼으십시오: 성능 및 밀도 주장은 주로 Tencent에서 나오므로, 자신의 워크로드에 대해 벤치마크를 수행하고, 출시된 기능과 개발 중인 기능을 저장소에서 확인하십시오.
- 격리는 필요하지만 충분하지 않습니다: 샌드박스는 호스트를 에이전트로부터 보호하지만, 혼란스러운 에이전트가 호출하는 API를 보호하지는 않습니다.
- 런타임 격리와 API 계약 테스트를 결합하십시오: 에이전트가 도달할 수 있는 모든 엔드포인트를 모의(mock)하고 테스트하여 하나의 잘못된 응답이 연쇄 반응을 일으키지 않도록 하십시오.
에이전트가 소유하거나 의존하는 API를 호출하는 경우, 격리 계층과 함께 계약 계층을 설정하십시오. Apidog를 다운로드하여 샌드박스 에이전트가 접근하는 서비스를 모의(mock)하고, 자율 시스템이 프로덕션에서 이를 구동하기 전에 스키마, 인증 및 오류 동작을 테스트하십시오.