엔터프라이즈 AI 보안 평가: 모든 구매자가 답할 수 있어야 하는 질문

엔터프라이즈 AI 보안은 빠르게 발전하고 있지만, 대부분의 조직은 여전히 공급업체의 주장을 엄밀하게 평가하는 데 어려움을 겪고 있습니다. F5, AWS, Microsoft와 공동으로 작성한 이 NSS Labs 연구 보고서는 보안 책임자와 기업 구매 담당자가 확신을 갖고 타당한 근거에 기반한 AI 보안 결정을 내리는 데 필요한 구체적인 공급업체 질문, 주의해야 할 위험 신호, 평가 기준을 제시합니다.

요약

엔터프라이즈 AI 보안에는 구매자 측의 문제가 있습니다. 조직들은 AI 보안이 중요하다는 사실을 알고 있지만, 대부분은 공급업체의 주장을 평가하고, 실질적인 보안 통제와 피상적인 통제를 구분하며, 실제 환경에서 입증된 증거를 바탕으로 공급업체에 책임을 묻기 위한 신뢰할 수 있는 프레임워크를 갖추지 못하고 있습니다.

NSS Labs가 F5, AWS, Microsoft와 협력하여 개발한 2부작 시리즈의 두 번째 보고서인 이 문서는 문제를 정의하는 데서 나아가 구매자가 이에 대응할 수 있도록 지원하는 데 초점을 맞춥니다. 1부에서는 AI 모델만 보호하는 것으로는 충분하지 않은 이유를 설명했다면, 2부에서는 이를 토대로 7가지 핵심 역량 영역에 걸친 실질적인 평가 기준을 제시합니다.

핵심 주장은 다음과 같습니다. AI 보안 구매 결정은 단순한 기술적 결정이 아니라 거버넌스에 관한 결정입니다. 구매자는 아키텍처 다이어그램이 아닌 측정 가능한 증거를 요구해야 합니다. 즉, 탐지 효과, 운영 성능, 감사 요건 및 프레임워크 부합성에 대한 정량적 기준선을 마련하고, 이를 고립된 테스트 시나리오가 아닌 실제 환경에서 검증해야 합니다.

이 백서에서는 입력 위협 및 명령 제어, 출력 및 데이터 유출 위험, 성능 저하 상황에서의 시스템 복원력, 정책/필터 거버넌스, 에이전트형 AI 및 위임된 권한, 관측 가능성 및 포렌식, 통합 및 상호 운용성이라는 7가지 역량 영역을 살펴봅니다. 각 섹션에서는 핵심 위험과 함께 구매자가 공급업체에 제기해야 할 구체적인 질문, 효과적인 솔루션의 특성, 주의 깊게 살펴봐야 할 명확한 위험 신호를 제시합니다.

이 보고서는 두 가지 분명한 지침으로 마무리됩니다. 구매 전에 독립적인 검증을 요구하고, 이를 일회성 점검이 아닌 지속적인 관행으로 삼으십시오. 실질적인 테스트를 거부하는 공급업체는 강점이 아니라 미성숙함을 드러내는 것입니다.

결론적으로, 다음 세 문장을 진지하게 받아들여야 합니다. AI 보안 솔루션 구매는 장기적인 결과를 수반하는 거버넌스 차원의 의사결정입니다. 처음부터 까다로운 질문을 던지는 기업일수록 위험을 관리하고 예방 가능한 실패를 피하는 데 더 유리합니다. 또한 AI 보안은 참신함이나 추상적인 개념만으로 성공할 수 없으며, 오직 책임성, 투명성, 체계적인 평가를 통해서만 성공할 수 있습니다.

목차

소개: 인지에서 평가까지

정량적 평가 기준 수립

핵심 역량 영역 및 구매자가 반드시 물어봐야 할 질문

구매자가 구매 전에 반드시 요구해야 할 사항

독립적인 검증 준비

결론: 주장에 그치지 않고 책임 있는 이행으로

1부 다운로드: 모델을 넘어선 AI 보안: 기업이 주목해야 할 사항과 그 이유

소개: 인지에서 평가까지

AI가 다양한 형태로 기업 시스템에 더욱 깊숙이 도입되면서 새로운 공격 표면이 생겨나고 있으며, 이에 따라 기업은 AI 보안 위험을 고려해야 하는 상황에 놓였습니다. 이사회, 규제 기관, 경영진은 AI 시스템이 공격 표면을 확대할 뿐만 아니라 운영, 법률 및 평판 측면에서 새로운 유형의 위험 노출을 초래한다는 점을 인식하기 시작했습니다. 그 결과, 이러한 위험을 줄이기 위한 AI 보안 제품이 이제 기업 보안팀의 최우선 관심사로 떠오르고 있습니다.

그러나 이러한 인식이 곧 대비 태세를 보장하는 것은 아닙니다. 기업들은 AI 보안의 중요성을 점점 더 인정하고 있지만, 이 신흥 분야에서 활동하는 공급업체들의 주장을 효과적으로 평가하는 데 어려움을 겪는 경우가 많습니다. 용어는 일관되지 않고, 시연은 대개 제한된 범위에 그치며, 보안에 대한 확신도 실제 환경에서 얻은 증거보다는 아키텍처에 근거하는 경우가 많습니다. 따라서 구매자는 실질적인 통제 조치와 피상적인 조치를 구분하거나 실제 보안 적용 범위가 얼마나 효과적인지 판단할 명확한 방법 없이 의사 결정을 내려야 합니다.

“이 영역의 문제는 명백히 악의적인 프롬프트 없이 발생하는 경우가 많으며, 그보다는 신뢰할 수 없는 콘텐츠가 AI 컨텍스트에 유입되는 방식에서 비롯됩니다.”

NSS Labs는 이전 백서인 「모델을 넘어선 AI 보안(AI Security Beyond the Model)」에서 AI 모델 자체를 보호하는 것만으로는 충분하지 않은 이유와 기업의 AI 보안을 시스템 차원 및 거버넌스 차원의 과제로 다뤄야 하는 이유를 설명했습니다. 실질적인 보안 문제는 데이터가 검색되고, 도구가 호출되며, 자동화된 의사결정이 실행되는 등 모델을 둘러싼 시스템에서 발생합니다.

본 백서는 이러한 토대를 바탕으로 문제를 이해하는 단계에서 잠재적 솔루션을 평가하는 단계로 나아가며, 기업 구매 담당자가 AI 보안 공급업체 후보를 선정할 때 더 적절한 질문을 구성할 수 있도록 지원합니다. 『AI Security Beyond the Model』의 관점에 따라, 본 백서는 모델 보안/책임 있는 AI가 모델 자체의 내재적 위험을 줄일 수는 있지만 기업의 상호작용 위험까지 단독으로 관리할 수는 없다는 점을 인식하면서, 런타임 가드레일(정책을 집행하고 데이터를 보호하며 감사 증거를 생성하는 모델 외부의 통제 수단)에 중점을 둡니다. AI 시스템이 기업 워크플로에 통합됨에 따라 보안 관련 의사결정은 거버넌스, 위험 관리 및 규제 책임과 점점 더 밀접하게 맞물리고 있습니다. 조직은 AI 시스템의 작동 방식뿐만 아니라 위험이 어떻게 통제되고 모니터링되며 감사되는지도 설명할 수 있어야 합니다.

다음 섹션에서는 AI 보안의 핵심 역량 영역을 평가 기준의 관점에서 재구성합니다. 특정 기술이나 아키텍처를 제시하기보다는, 구매자가 프로덕션 환경을 위한 AI 보안 통제를 선택할 때 무엇을 이해하고 테스트하며 그 선택의 타당성을 입증할 수 있어야 하는지에 중점을 둡니다.

정량적 평가 기준 수립

AI 보안을 평가하려면 정성적인 주장을 넘어 측정 가능한 검증이 필요합니다. 구매자는 공급업체를 객관적으로 비교할 수 있도록 기본 기대 수준을 설정해야 합니다.

탐지 효과: 공급업체는 공신력 있는 독립 시험 기관의 표준화된 시험 프레임워크와 방법론을 기준으로 탐지 역량을 입증해야 합니다. 조직은 알려진 공격 패턴에 대해 측정 가능한 정확도를 요구해야 하며, 공급업체는 시험 방법론, 탐지 범위의 한계, 오탐과의 상충 관계를 공개해야 합니다. 민감한 데이터 노출 방지 기능은 정형 데이터 유형과 맥락상 민감한 정보를 구분해야 하며, 서로 다른 기반 모델과 프롬프트 복잡도 수준에서도 일관된 탐지 정확도를 유지해야 합니다.

운영 성능: 구매자는 보안과 사용 편의성 간의 균형을 고려해 지연 시간 임계값을 설정해야 합니다. 시스템은 격리된 테스트 환경이 아니라 실제 운영 규모의 부하에서 성능을 입증해야 합니다. 오탐률도 중요합니다. 오탐이 지나치게 많으면 경고 피로가 누적되고 섀도 AI 도입을 부추길 수 있습니다. 공급업체는 유의미한 기간에 걸친 실제 운영 환경의 지표를 제공할 수 있어야 합니다.

감사 요구 사항: 규제 준수를 위해서는 수개월 후에도 사고를 재구성할 수 있을 만큼 상세한 종합 로그가 필요합니다. 이벤트는 지연을 최소화하여 표준 형식으로 SIEM에 전송되어야 합니다. 보존 요건은 산업 및 사용 사례에 따라 달라집니다.

프레임워크 부합성: 공급업체는 공인된 독립 시험 기관이 수립한 프레임워크에 맞춰 통제 항목을 매핑해야 합니다. 구매자는 공급업체가 표준화된 테스트 세트와 실제 운영 트래픽 샘플을 바탕으로 이러한 역량을 입증하도록 요구해야 합니다. 독립적인 제3자 검증은 통제의 효과를 뒷받침하는 신뢰할 수 있는 근거를 제공합니다.

핵심 역량 영역 및 구매자가 반드시 확인해야 할 질문

가장 기본적인 수준에서 모델 보안 안전장치는 악의적인 프롬프트를 차단하고, 허용되지 않는 콘텐츠를 필터링하며, 간단한 사용 규칙을 적용할 수 있습니다. 이러한 기능은 필수적이지만, 기업에 큰 영향을 미치는 많은 AI 장애는 규칙의 부재가 아니라 맥락, 복원력, 가시성의 부족에서 비롯됩니다.

예를 들어, AI 시스템이 정의된 모든 콘텐츠 정책을 준수하면서도 정보의 집계, 추론 또는 부적절한 맥락 결합을 통해 민감한 정보를 노출할 수 있습니다. 마찬가지로, 시스템이 정상적인 상황에서는 올바른 규칙을 적용하더라도 부하가 발생하거나 부분적인 서비스 중단 또는 종속성 장애가 생기면 예측할 수 없는 방식으로 작동하지 않을 수 있습니다.

입력 위협, 명령어 제어 및 회피 탐지

대부분의 AI 보안 통제는 "프롬프트를 필터링"하거나 "악성 입력을 차단"한다고 내세우지만, 이러한 관점은 문제를 지나치게 단순화하는 경우가 많습니다. 대부분의 AI 시스템에서 위험은 사용자가 시스템에 직접 입력하는 내용뿐만 아니라, 이후 시스템이 처리하는 콘텐츠에 포함된 지시에서도 발생합니다. 이러한 콘텐츠에는 문서, 웹 페이지, 티켓, 이메일 또는 지식 베이스 등이 있으며, 그 내용이 신뢰할 수 있는 맥락으로 취급되려면 충분한 신뢰성이 확보되어야 합니다.

저자

Bob Walder - NSS Labs 수석 애널리스트
lan Foo - NSS Lab 최고기술책임자(CTO) 겸 제품 담당 수석부사장

기여자

이 연구는 업계 전반의 보안, 클라우드 및 AI 분야 리더들과 협력하여 수행되었습니다.

Cameron Delano - 수석 솔루션 아키텍트, F5
Jeanette Hurr - 글로벌 솔루션 아키텍트, F5
Riggs Goodman III - 수석 솔루션 아키텍트, AI 보안 및 개인정보 보호, AWS
Raj Bagwe - 수석 솔루션 아키텍트, AWS
Zachary Riffle - 보안 아키텍트, Microsoft

SecureIQ Lab 보고서 썸네일
독립 테스트 결과 | 2026년 3월 19일

그 증거를 확인할 준비가 되셨나요?

독립적인 제3자 연구소 SecureIQLab이 수행한 20,000건의 실제 공격 테스트에서 F5 AI Guardrails가 어떤 성능을 보였는지 확인해 보세요.

구매자는 시스템이 런타임에 시스템 지침, 개발자의 의도, 검색된 콘텐츠, 사용자 입력을 어떻게 구분하는지 확인해야 합니다. 검색 증강 생성(RAG)을 사용하는 아키텍처에서는 이러한 구분이 매우 중요합니다. 검색된 콘텐츠가 암묵적으로 시스템 정책을 재정의할 수 있다면, 명백히 악의적인 쿼리가 제출되지 않더라도 시스템은 간접 프롬프트 인젝션에 취약합니다.

기업은 다음과 같은 질문에 대해 명확한 답변을 기대해야 합니다:

  • 시스템은 정책상 금지된 요청과 지시를 얼마나 효과적으로 탐지하고 평가하여 차단할 수 있습니까?
  • 시스템은 입력 프롬프트를 통해 의도된 시스템 동작을 무시하도록 유도하는 시도를 얼마나 효과적으로 탐지하고 방지할 수 있나요?
  • 시스템은 의도가 불분명한 모호하거나 경계선상에 있는 프롬프트를 얼마나 잘 처리하면서도 정상적인 사용에 미치는 지장을 최소화할 수 있습니까?
  • 시스템은 제출된 콘텐츠에 포함된 지시가 의도치 않은 방식으로 모델에 영향을 미치는 것을 얼마나 효과적으로 방지할 수 있나요?
  • 시스템은 비정상적인 형식 지정, 인코딩 또는 프롬프트 변형을 통해 통제를 우회하려는 시도에 얼마나 효과적으로 대응할 수 있나요?
  • 시스템은 쉽게 우회할 수 있는 경로를 만들지 않으면서 안전성과 역할 기반의 정당한 사용 사례(예: 교육 시뮬레이션, 레드팀 활동, 창작 작업) 간의 균형을 얼마나 잘 유지합니까?
  • 시스템은 사용자(또는 외부 콘텐츠)가 시스템/에이전트 지침, 라우팅 규칙, 도구 사용 제약 조건 또는 기타 "상위 우선순위" 통제에 영향을 미치거나 이를 무시하지 못하도록 얼마나 효과적으로 방지합니까?
  • 시스템이 모델 사용을 효과적으로 탐지, 식별 및 규제하여 악의적이거나 과도한(정책 범위를 벗어난) 사용과 비용 발생을 방지할 수 있습니까?
  • 시스템은 지침 간 충돌이 발생했을 때 어떤 지침 출처가 우선 적용되었는지(시스템, 개발자, 검색, 사용자) 로그에 표시할 수 있습니까?

실제로 이 영역의 문제는 명백히 악의적인 프롬프트 없이 발생하는 경우가 많으며, 신뢰할 수 없는 콘텐츠가 AI 컨텍스트에 유입되는 방식에서 비롯되기도 합니다. 공격자는 나중에 복잡한 다중 소스 검색 파이프라인을 통해 AI 시스템에 수집될 문서(예: 정책 문서, 내부 위키 페이지 또는 고객 지원 문서)에 숨겨진 지침을 삽입할 수 있습니다. 모델이 해당 콘텐츠를 검색하면 이렇게 삽입된 지침을 신뢰할 수 없는 입력이 아니라 권위 있는 지침으로 받아들일 수 있습니다. 내부 콘텐츠를 광범위하게 편집할 수 있는 기업 환경에서는 이러한 형태의 간접 프롬프트 인젝션을 탐지하기가 특히 어려울 수 있습니다.

“이 영역의 문제는 명백히 악의적인 프롬프트 없이 발생하는 경우가 많으며, 신뢰할 수 없는 콘텐츠가 AI 컨텍스트에 유입되는 방식으로 인해 나타납니다.”

예를 들어, 변경된 단일 정보 소스가 위험 신호를 일으켜 심각한 피해가 즉시 발생하지 못하게 하는 것은 반드시 필요한 일도 아니며, 위협 행위자의 관점에서도 꼭 바람직한 일은 아닙니다. 그보다는 여러 데이터 소스를 조금씩 변경하는 것이 더 나은 전략일 수 있습니다. 이렇게 하면 시간이 지남에 따라 응답 제약이 완화되거나, 내부 워크플로가 노출되거나, 시스템 정책보다 공격자가 제어하는 컨텍스트가 우선시되는 등 시스템 동작에 미묘하지만 지속적인 변화가 나타날 수 있습니다. 그 결과 민감한 데이터가 더 큰 규모로 유출될 수 있습니다.

따라서 구매자는 AI 보안 통제가 검색된 모든 콘텐츠를 잠재적인 위협으로 간주하는지, 그리고 지침의 출처와 관계없이 지침 간 경계가 일관되게 적용되는지 평가해야 합니다.

효과적인 솔루션은 사용자 입력과 검색된 콘텐츠를 높은 정확도로 구분합니다. 사용자 프롬프트에 지시 재정의 시도가 나타나면 시스템이 이를 차단하고, 정상적인 지원 문서에 유사한 문구가 포함된 경우에는 적절하게 처리합니다. 탐지는 키워드가 아닌 의미론적 의도를 기반으로 이루어지며, 인코딩 조작이나 역할극 시나리오를 통해 난독화된 공격도 포착합니다. 공급업체는 다중 소스 검색을 사용하는 조직의 실제 RAG 아키텍처에서 탐지 기능을 입증해야 합니다. 시스템은 유의미한 기간에 걸친 탐지율, 오탐률 및 지연 시간 등의 운영 환경 지표를 제공해야 합니다.

위험 신호는 다음과 같습니다. 일반적인 프롬프트 필터링에 의존하는 경우, "모델이 알아서 처리한다"는 모호한 설명만 제시하는 경우, 적대적 조건에서 지시 경계가 강제 적용됨을 입증하지 못하는 경우, 유의미한 기간에 걸친 운영 지표를 제공하지 못하는 경우, 사내 RAG 아키텍처를 사용한 탐지 성능을 입증하지 못하는 경우, 그리고 의미적 의도 분석 없이 키워드만으로 탐지하는 경우입니다.

입력 무결성은 악의적인 표현을 차단하는 것이 아니라, 역동적이고 신뢰할 수 없는 환경에서도 정책의 권한을 유지하는 것입니다.

출력 및 데이터 유출 위험 관리

AI가 생성한 출력은 상당한 위험을 초래할 수 있습니다. 비인간 에이전트가 답변을 작성하기 위해 여러 시스템에서 데이터를 가져왔을 수 있으며, 그 답변을 통해 외부 사용자에게 원래 의도했던 것보다 더 많은 정보가 노출될 수 있기 때문입니다. 심각한 영향을 미치는 많은 사고는 명시적으로 금지된 콘텐츠가 아니라, 특정 시점과 맥락에서 특정 사용자에게 공개되어서는 안 되는 정보가 미묘하게 노출되는 데서 발생합니다.

공격자나 권한이 없는 사용자는 겉보기에는 무해하고 개별적으로는 허용된 데이터만 반환하지만, 종합하면 민감한 정보를 추론하거나 재구성할 수 있는 일련의 질문을 할 수 있습니다. 예를 들어 내부 티켓 관리 및 문서화 시스템에 연결된 AI 어시스턴트가 운영 문제, 담당자의 역할 또는 시스템 구성을 요약하는 과정에서 내부 아키텍처나 규제 대상 데이터를 간접적으로 노출할 수 있습니다. 이러한 문제는 키워드 필터로 탐지하기가 어렵습니다. 위험은 정보의 집계와 맥락에서 발생하기 때문입니다. 구매자는 출력 제어 기능이 누적 노출을 고려하는지, 그리고 시스템이 응답이 제한된 이유를 설명할 수 있는지 평가해야 합니다. 이는 거버넌스와 감사 가능성을 위한 필수 요건입니다.

구매자는 다음과 같은 질문에 대해 명확한 답변을 기대해야 합니다:

  • AI 보안 통제는 출력에 어떤 키워드나 문구가 나타나는지만 보는 대신, 맥락상 실제로 어떤 정보가 노출되고 있는지를 어떻게 판단하나요?
  • 시스템이 공개 정보, 내부 정보, 규제 대상 데이터를 구분할 수 있습니까?
  • 사용자 요청이 정당해 보이거나 모호한 경우에도 시스템은 모델이 응답에서 민감한 데이터를 노출하지 않도록 얼마나 효과적으로 방지합니까?
  • 보호 기능은 어떤 유형의 민감한 데이터(예: 개인 데이터, 금융 데이터, 기업 기밀 정보)를 대상으로 하며, 조직에 맞게 어떻게 조정할 수 있습니까?
  • 제어 기능이 사용자 역할, 관할권 또는 데이터 출처에 따라 달라지나요?
  • 시스템이 출력이 차단되거나 수정된 이유를 설명할 수 있나요?
  • 시스템이 요청과 응답 모두에 대해 거부, 민감 정보 삭제, 안전한 변환 등의 통제 조치를 적용하고 감사 증적을 남길 수 있습니까?
  • 모델이 민감한 데이터를 출력하지 못하도록 시스템에서 어떤 조치를 취할 수 있습니까(차단, 마스킹, 변환, 경고, 추가 검토/승인 요구)?
  • 시스템은 모델이 데이터를 간접적으로 공개하도록 속이려는 프롬프트 조작 및 우회 전략(예: 실제 정보가 포함된 "예시", "템플릿", "테스트 데이터" 또는 "요약"을 요청하는 방식)을 얼마나 효과적으로 방지합니까?
  • 시스템이 세션 간 또는 테넌트 간 데이터 유출을 방지하고 탐지하여, 한 사용자의 세션, 컨텍스트 또는 검색된 데이터 소스의 정보가 다른 사용자의 응답에 나타나지 않도록 보장할 수 있습니까?
  • 시스템은 모델이 시스템 프롬프트, 내부 지침, 비공개 정책 또는 운영 구성 세부 정보를 노출하지 못하도록 얼마나 효과적으로 방지합니까?
  • 시스템은 학습 데이터, 시스템 컨텍스트, 로그, 커넥터 또는 검색된 콘텐츠에 존재할 수 있는 자격 증명이나 비밀 정보(예: API 키 또는 토큰)의 노출을 얼마나 효과적으로 방지합니까?
  • 시스템은 특히 사용자가 모델을 도발하는 극단적인 상황에서 모델이 유해하거나 비하적이거나 편향성이 강한 결과를 생성하지 못하도록 얼마나 효과적으로 방지합니까?
  • 시스템은 모델이 저작권으로 보호되는 긴 구절을 그대로 출력하거나 그 밖의 방식으로 보호 대상 콘텐츠를 복제하지 못하도록 얼마나 효과적으로 방지할 수 있나요?
  • 모델이 사내 콘텐츠(예: 문서, 위키 또는 티켓 관리 시스템)에 연결된 경우, 시스템은 사용자의 열람 권한을 벗어나는 제한된 내부 자료를 모델이 재현하지 못하도록 방지할 수 있나요?
  • 시스템은 모델이 사용자에게 유해한 작업 절차를 단계별로 안내하거나 보안 취약점 또는 안전하지 않은 시스템 동작을 초래할 수 있는 실행 가능한 결과물(예: 스크립트, 명령어 또는 코드)을 생성하지 못하도록 얼마나 효과적으로 방지할 수 있습니까?

AI 시스템이 실시간 기업 데이터 소스에 연결되면 이러한 위험이 크게 증가하며, AI 시스템이 여러 소스의 정보를 하나의 응답으로 통합할 때 출력과 관련된 문제가 발생할 수 있습니다.

출력 제어를 평가하려면 성숙한 솔루션이 맥락에 따른 데이터 노출을 어떻게 처리하는지 이해해야 합니다. 맥락 인식 시스템은 단순히 키워드만이 아니라 의미론적 의미를 이해합니다. 따라서 구조화된 개인 식별 정보(PII)는 차단하되, 공개 정보는 맥락에 따라 허용해야 합니다. 역할 기반 적용을 통해 권한 수준에 따라 사용자별로 동일한 쿼리에 대해 서로 다른 출력이 표시되도록 해야 합니다. 시스템은 개별적으로는 무해한 질문들이 모여 민감한 정보를 드러내는 세션 간 누적 노출을 감지해야 합니다. 차단 결정에는 구체적인 정책 참조, 데이터 유형 및 권한 요구 사항이 포함되어야 합니다. 기존 데이터 분류 정책과 통합하면 중복 구성을 없앨 수 있습니다.

위험 신호는 다음과 같습니다. 키워드에만 의존하는 필터링, 불투명한 정책 적용 결정, 역할 기반 정책 적용을 입증하지 못하는 시스템(예: 사용자의 권한 수준과 관계없이 동일한 쿼리에 동일한 결과를 반환함), 특정 결과가 차단된 이유를 공급업체가 사람이 이해할 수 있는 방식으로 설명하지 못하는 경우, 감사 추적 기록의 부재입니다. 기업은 출력 제어가 맥락과 의도, 책임성을 바탕으로 작동한다는 증거를 확인해야 합니다.

복원력, 견고성, 장애 및 성능 저하 처리

기업은 일반적인 네트워크 환경에서의 효과를 기준으로 보안 통제를 평가하는 데 익숙하지만, AI 보안에는 다른 관점이 필요합니다. 가장 심각한 장애 중 일부는 시스템이 직접 공격받을 때가 아니라, 대규모 처리량, 복잡성, 종속성 장애 또는 예기치 않은 상호작용 패턴으로 인해 시스템에 과부하가 걸릴 때 발생합니다.

다음과 같은 핵심 질문을 고려해야 합니다:

  • 비정상적으로 길거나 복잡한 사용자 상호작용(예: "마라톤" 세션) 중에도 시스템이 가용성과 응답성을 얼마나 잘 유지하나요?
  • 장시간 실행되는 세션이나 여러 단계로 구성된 에이전트 워크플로 전반에 걸쳐 통제 조치가 일관되게 적용되나요?
  • 시스템은 반복적이거나 형식이 잘못되었거나 무의미한 입력이 갑자기 대량으로 유입될 때 리소스 고갈이나 서비스 성능 저하를 어떻게 방지하나요?
  • AI 보안 통제 기능이 저하되면 어떻게 되나요?
  • 정책 검사가 시간 초과될 수 있으며, 이 경우 적용이 허용 우선(fail-open)으로 처리되나요, 아니면 차단 우선(fail-closed)으로 처리되나요?
  • 종속성 장애 발생 시 시스템은 보안과 가동 시간을 어떻게 조율하며, 이러한 동작을 설정하고 감사할 수 있나요?

실제 환경의 AI 시스템은 사용량 급증, 업스트림 서비스 중단, 느린 ID 공급자 또는 검색 서비스 성능 저하 등 다양한 조건에서 작동합니다. 이러한 상황에서는 정책 집행 구성 요소가 완전히 중단되기보다 부분적으로 실패할 수 있습니다. 예를 들어 정책 평가 서비스가 시간 초과되거나 응답성을 유지하기 위해 분류 단계가 생략될 수 있습니다. 이러한 장애를 신중하게 처리하지 않으면 시스템이 운영자에게 알리지 않은 채 기본적으로 허용적인 동작을 취할 수 있으며, 에이전트형 워크플로에서는 적절한 검증 없이 작업이 진행될 수 있습니다. 이는 가정에 불과한 극단적 사례가 아니라 분산 시스템에서 흔히 발생하는 장애 유형입니다. 따라서 구매자는 종속 서비스의 성능이 저하될 때 AI 보안 통제가 어떻게 작동하는지, 그리고 장애 시 동작이 예측 가능하고 가시적이며 기업의 위험 허용 수준에 부합하는지를 시연하도록 요구해야 합니다.

“복원력 있는 시스템은 문제가 발생했을 때 무조건 모든 것을 차단해서도 안 되며, 안전하지 않은 동작을 아무런 경고 없이 허용해서도 안 됩니다.”

복원력 있는 시스템은 문제가 발생했을 때 모든 것을 무조건 차단하거나 안전하지 않은 동작을 묵인해서는 안 됩니다. 대신 예측 가능한 방식으로 성능을 낮추고, 오류를 명확히 알리며, 상황이 악화되더라도 적절한 보호 기능을 계속 제공해야 합니다.

잘 설계된 시스템은 모든 종속성에 대해 명시적인 장애 모드를 문서화해야 합니다. 서비스가 시간 초과되면 시스템은 적절하게 실패를 처리하고, 이벤트를 기록하며, 보안 팀에 알림을 보내고, 사용자에게 명확한 메시지를 표시해야 합니다. 스트레스 테스트 상황에서도 탐지 정확도는 높은 수준을 유지하고, 지연 시간은 허용 가능한 임계값 이내여야 하며, 요청이 보안 검사를 우회할 수 없어야 합니다. 성능 저하는 조용히 발생하는 것이 아니라 알림과 함께 예측 가능한 방식으로 진행되어야 하며, 서킷 브레이커는 통제 불능 상태의 프로세스를 신속하게 종료해야 합니다. 공급업체는 정책 집행의 가용성 목표와 장애 발생 시 동작을 설명할 수 있어야 하며, 정책 집행이 업무 수행에 필수적인 경우 구매자는 계약상 이행 약정을 요구할 수 있습니다.

위험 신호는 다음과 같습니다. 장애 모드를 설명하지 못하는 경우, 스트레스 테스트가 부족하거나 "실제 운영 환경에서는 시스템에 장애가 발생한 적이 없다"고 장담하는 경우, 경고 없이 성능이 저하되는 경우, 폭주 프로세스를 차단할 회로 차단기가 없는 경우, 스트레스 테스트 중에도 탐지 정확도가 높게 유지됨을 입증하지 못하는 경우, 그리고 성능 저하 시 요청이 보안 검사를 우회할 수 있도록 허용하는 시스템.

정책/필터의 효과 및 거버넌스 정합성

기술적으로 정교하더라도 운영 측면에서 부합하지 않는 AI 보안 통제는 최전선인 비즈니스 현장에 적용되면 제대로 유지되기 어렵습니다. 엔터프라이즈 환경에서 정책 결정은 일반적으로 양자택일식이거나 고정된 것이 아니며, 궁극적으로는 거버넌스 차원의 결정입니다.

구매자는 다음 사항을 확인해야 합니다:

  • 정책은 어떻게 정의되고, 승인되며, 버전 관리되고, 감사됩니까?
  • 정책의 적용 범위를 역할, 데이터 민감도, 지역 또는 비즈니스 맥락에 따라 지정할 수 있나요?
  • 시스템이 해당 결정이 내려진 이유를 설명할 수 있나요?
  • 시스템은 조직별 규정 준수 방침(업계 규정, 내부 정책, 허용 가능한 사용에 대한 제약)을 반영하는 정책을 얼마나 효과적으로 지원할 수 있으며, 이러한 정책은 시간이 지나도 어떻게 유지·관리됩니까?
  • 시스템은 법적 위험이나 규정 준수 위험을 초래할 수 있는 응답(예: 관련 규칙/표준을 위반하는 조언 또는 지침)을 방지하는 데 얼마나 효과적으로 기여합니까?

정책 실패는 의도가 잘못되어서라기보다 기술적 통제와 비즈니스 현실 사이의 괴리에서 발생하는 경우가 많습니다. 예를 들어, AI 시스템이 특정 데이터 범주에 대한 접근을 올바르게 차단하더라도 정상적인 비즈니스 업무 흐름까지 방해하는 방식으로 작동하면, 사용자가 승인되지 않은 도구를 통해 통제를 완전히 우회할 수 있습니다. 반대로 정책이 지나치게 느슨하게 정의되면 규제 또는 계약상 의무를 위반하는 상황에서 민감한 정보가 노출될 수 있습니다. 시간이 지나면서 불만을 해소하기 위한 임시방편식 조정은 정책의 무결성과 책임성을 약화시킬 수 있습니다. 따라서 구매자는 AI 보안 플랫폼이 문서화된 승인 절차, 버전 이력, 통제 결과 검토 기능을 포함한 체계적인 정책 거버넌스를 지원하는지 평가해야 합니다. 이러한 규율이 없으면 정책의 정확성은 주관적인 판단에 좌우되며, 보안 사고 발생 후 그 타당성을 입증하기 어려워집니다.

“기술적으로 정교하더라도 운영 현실과 맞지 않는 AI 보안 통제는 현장에서 제대로 작동하기 어렵습니다.”

과도한 규제 집행은 업무에 차질을 빚게 하고 불만을 느낀 사용자가 승인되지 않은 '섀도 AI' 시스템을 도입하도록 부추길 수 있는 반면, 규제 집행이 미흡하면 규제 및 평판 리스크가 발생할 수 있습니다. 두 상황 모두 모델의 실패가 아니라 거버넌스의 문제를 보여줍니다.

효과적인 정책 관리를 위해서는 정책을 코드로 취급하고 버전 관리, 승인 워크플로 및 감사 추적 기능을 적용해야 합니다. 정책을 변경하려면 프로덕션에 배포하기 전에 보안, 법무 및 비즈니스 이해관계자의 승인을 문서화하여 받아야 합니다. 모든 정책 집행 결정은 구체적인 정책 조항, 버전, 섹션 및 권한 부여 로직까지 추적할 수 있어야 합니다. 가능한 경우, 오탐 추세, 영향이 큰 차단 사례, 그리고 가능한 경우 조정 권장 사항 등의 정보를 제공하는 시스템 대시보드의 데이터를 기반으로 정책을 개선해야 합니다.

위험 신호는 다음과 같습니다. 불투명한 의사 결정, 임시방편식 조정 또는 책임 소재가 불분명한 상태에서 정책이 "스스로 학습한다"는 주장, 정책 변경에 대한 버전 관리 및 승인 워크플로의 부재, 특정 정책 조항으로 추적할 수 없는 집행 결정, 그리고 문서화된 해결 규칙이 없는 정책 간 충돌입니다.

SecureIQ Lab 보고서 썸네일
독립 테스트 결과 | 2026년 3월 19일

그 증거를 직접 확인해 보시겠어요?

독립적인 제3자 연구소 SecureIQLab이 수행한 20,000건의 실제 공격 테스트에서 F5 AI Guardrails가 어떤 성능을 보였는지 확인해 보세요.

에이전틱 AI, 도구 호출 보안 및 위임된 권한

AI 시스템이 수동적인 지원을 넘어 사용자와 다른 시스템을 대신해 행동하기 시작하면서, 위임된 권한이라는 새로운 유형의 위험이 대두되고 있습니다. 에이전트형 AI 시스템은 다른 도구를 호출하고, 레코드를 수정하며, 기계적인 속도로 복잡한 워크플로를 실행할 수 있습니다.

에이전틱 AI 보안을 평가하는 구매자는 다음과 같은 몇 가지 핵심 통제 영역을 검토해야 합니다:

  • 시스템이 자율적으로 수행할 수 있는 작업은 무엇인가요?
  • 권한은 어떻게 제한되나요?
  • 에이전트가 사용자를 대신해 행동할 권한을 위임받았을 때, 시스템은 에이전트에게 허용되거나 허용되지 않는 작업을 얼마나 효과적으로 통제하나요?
  • 명확한 한계가 없으면 작은 오류도 여러 시스템에 걸쳐 빠르게 확산될 수 있는데, 위험 수준이나 상황에 따라 자율성을 단계별로 설정할 수 있는가?
  • 시스템이 외부 도구 및 에이전트와 상호작용하거나 이를 활용할 수 있을 때, 시스템 제어 장치는 프롬프트가 시스템을 의도된 범위를 벗어난 행동으로 유도하는 것을 얼마나 효과적으로 방지합니까(사용자가 "정중하게 요청하는" 경우에도)?
  • 시스템은 에이전트가 목표를 달성하지 못한 채 계속 행동하는 재귀적 루프나 "폭주" 동작을 효과적으로 방지하거나 억제합니까?
  • 시스템은 무단 도구 사용, API/작업 권한 확대, 과도한 자율성 또는 반복 실행, 안전하지 않은 도구 간 연계 실행을 얼마나 효과적으로 방지합니까?
  • 멀티 에이전트 아키텍처에서 한 에이전트가 검색하거나 생성한 민감한 데이터가 관련 작업을 수행하는 후속 에이전트나 도구에 불필요하게 전달되지 않도록 시스템이 얼마나 효과적으로 방지합니까?
  • 다중 에이전트 아키텍처에서는 권한이 시스템 경계를 넘어 올바르게 전파되는 것이 매우 중요합니다. 시스템은 에이전트 체인 전반에서 ID 컨텍스트를 얼마나 효과적으로 유지하여, 다운스트림 에이전트와 도구가 상승된 시스템 권한이 아닌 원래 사용자의 권한 범위 내에서만 엄격하게 작동하도록 보장합니까?

적절한 제약 없이 자동화를 구현하기 위해 AI 시스템에 광범위한 도구 접근 권한을 부여하면 위임된 권한이 제대로 통제되지 않는 경우가 많습니다. 예를 들어 지원 문제 해결을 담당하는 AI 에이전트가 데이터베이스를 조회하고, 레코드를 업데이트하며, 사용자에게 알림을 보낼 수 있다고 가정해 보겠습니다. 이때 지시를 잘못 해석하거나 예상치 못한 맥락에 놓이면 데이터를 잘못 수정하거나 고객에게 너무 이른 시점에 안내를 보낼 수 있습니다. 이러한 작업은 기계적인 속도로 이루어지므로 사람이 개입해 감독하기 전에 오류가 확산될 수 있습니다. 복잡한 워크플로에서는 위험도가 낮은 개별 작업들이 결합되어 큰 영향을 미치는 결과를 초래할 수 있습니다. 구매자는 AI 보안 통제가 최소 권한 원칙을 적용하고, 민감한 작업에 대해 확인을 요구하며, 자율성을 동적으로 제한하거나 철회할 수 있는 메커니즘을 제공하는지 평가해야 합니다. 에이전트형 행동을 거버넌스 문제로 다루는 것은 드러나지 않는 권한 확대를 방지하는 데 필수적입니다.

“ID 컨텍스트를 유지하면 에이전트가 시스템 수준 권한이 아닌 사용자 권한을 상속받게 됩니다.”

잘 설계된 시스템에서는 아키텍처 제어를 통해 이러한 위험을 완화합니다. 적절히 제약된 시스템은 명확히 문서화된 권한 경계를 바탕으로 도구별 최소 권한 원칙을 적용합니다. 단계적 자율성 체계에서는 중간 수준의 영향을 미치는 작업에 사용자 확인을, 영향이 큰 작업에 사람의 승인을 요구해야 합니다. 또한 ID 컨텍스트를 유지하여 에이전트가 시스템 수준 권한이 아닌 사용자 권한을 상속하도록 해야 합니다. 사용자가 민감한 작업을 요청할 경우 에이전트는 권한이 부여된 정보만 가져오고 무단 접근은 차단해야 합니다. 서킷 브레이커는 통제 불능 상태로 반복되는 루프를 즉시 중단해야 하며, 모든 에이전트 작업은 판단 근거, 권한 확인, 결과와 함께 빠짐없이 기록되어야 합니다.

이러한 통제는 시스템이 에이전트의 특정 도구 호출이나 작업 수행을 기술적으로 차단하는 아키텍처적 제약과, 에이전트가 해당 작업을 수행할 수는 있지만 수행하지 않도록 지시하는 행동적 제약 사이의 중요한 차이를 보여줍니다. 보안에 중요한 경계에는 가능한 한 행동 지침에만 의존하기보다 아키텍처적 통제를 적용해야 합니다.

위험 신호는 다음과 같습니다. 취약한 에이전트 거버넌스의 경고 신호로는 모든 도구에 대한 포괄적 접근 권한을 부여하거나 오용 방지를 모델 정렬에만 의존하는 경우, 도구별 권한 경계가 문서화되어 있지 않은 경우, 에이전트가 사용자의 권한을 상속하도록 보장하는 ID 컨텍스트를 유지하지 못하는 경우, 체인 분석을 통해 안전하지 않은 작업 순서를 탐지하지 못하는 경우, 그리고 추론 및 권한 확인 없이 에이전트의 작업을 불완전하게 기록하는 경우 등이 있습니다.

관측 가능성, 감사 및 포렌식

AI 시스템에서 문제가 발생했을 때는 그 문제가 어떻게, 왜 발생했는지 입증하고, 가능하다면 이를 재현할 수 있어야 합니다.

구매자는 입력, 컨텍스트, 정책, 출력, 작업, 호출된 도구, 액세스한 데이터를 포함해 AI 상호작용의 전 과정을 재구성할 수 있는지 확인해야 합니다. 효과적인 시스템은 지속적인 모니터링과 알림 기능도 지원하여, 보안 팀이 사고가 확대되기 전에 비정상적인 동작, 안전하지 않은 작업 흐름 또는 예기치 않은 에이전트 간 상호작용을 탐지할 수 있도록 해야 합니다. 시스템의 동작 방식에 대한 가시성이 충분하지 않으면 사고 대응은 추측에 의존하게 되고 거버넌스 활동의 신뢰성도 떨어집니다.

AI 관련 사고가 발생하면 조직은 설명이 아니라 증거를 제시해야 할 수 있습니다. 입력, 검색된 컨텍스트, 적용된 정책, 출력 및 조치에 대한 상세한 기록이 없으면 사고 대응 팀은 사실이 아닌 추정에 근거해 사건을 재구성할 수밖에 없습니다. 이는 비결정성으로 인해 동작을 재현하지 못할 수 있는 AI 시스템에서 특히 문제가 됩니다. 예를 들어 규제 기관이나 내부 감사인은 특정 정보가 공개된 이유 또는 자동화된 조치가 수행된 이유를 물을 수 있지만, 엔드투엔드 관찰 가능성이 없으면 조직은 의도, 비례성 또는 통제의 효과를 입증할 수 없습니다. 따라서 구매자는 AI 보안 플랫폼이 사고 대응, 규정 준수 보고 및 사고 후 학습을 지원하는 데 필요한 수준의 가시성을 제공하는지 평가해야 합니다.

포괄적인 로깅을 통해 원본 프롬프트, 출처가 포함된 검색 컨텍스트, ID/권한 부여 컨텍스트, 평가된 정책과 해당 버전, 모델 출력, 적용된 수정 사항, 최종 사용자 응답 및 후속 작업을 포함하여 요청의 전체 과정을 재구성할 수 있어야 합니다. AI 보안 이벤트는 지연을 최소화하면서 SIEM 시스템과 통합되어 네트워크 트래픽 및 인증 이벤트와의 상관관계를 분석할 수 있어야 합니다. 중대한 위반이 발생하면 즉각적인 대응에 필요한 충분한 컨텍스트와 함께 신속하게 경고를 트리거해야 하며, 여기에는 추세 분석을 통해 보안, 성능 및 품질 지표를 추적할 수 있는 통합 대시보드가 포함되어야 합니다.

GRC 관점에서 관찰할 수 없는 시스템은 거버넌스의 적용을 받을 수 없습니다.

통합 및 상호 운용성

독립적으로 운영되는 AI 보안 통제는 가시성의 공백을 초래하고 공조 대응을 방해합니다. 심층 방어 아키텍처에는 텔레메트리를 공유하고 여러 보안 계층에 걸쳐 정책 집행을 조율하는 통제가 필요합니다.

ID 및 액세스 관리: 권한 부여 경계는 사용자 인증부터 데이터 검색을 거쳐 최종 출력에 이르기까지 적용되어야 합니다. 조직은 시스템이 ID 공급자와 어떻게 통합되는지, 역할 변경 사항이 적절히 전파되는지를 평가해야 합니다. AI 에이전트가 사용자를 대신해 작업할 때 시스템은 추적 가능한 권한 체계와 함께 권한 부여 컨텍스트를 유지해야 하며, 액세스 정책은 중복 구성 없이 기존 RBAC 모델을 상속해야 합니다. 검색 계층에서는 요청한 사용자의 권한 수준에 따라 문서를 필터링하여 최소 권한 원칙을 적용해야 합니다.

SIEM 통합: AI 보안 이벤트는 광범위한 보안 텔레메트리와 연계되어야 합니다. 이를 위해 시스템은 OCSF 또는 CEF와 같은 표준 형식으로 이벤트를 지연을 최소화하여 SIEM 플랫폼에 전송해야 합니다. 독점 로그 형식은 네트워크 트래픽, 인증 이벤트 및 데이터 액세스 패턴과의 연계를 방해합니다. 조직은 AI 보안 이벤트를 기반으로 사용자 지정 탐지 규칙을 만들 수 있는지, 그리고 경고가 기존 인시던트 대응 워크플로와 통합되는지 확인해야 합니다.

컴플라이언스 프레임워크 연계: 솔루션은 구체적인 통제 범위와 감사 증적을 바탕으로 통제 항목을 기존 프레임워크에 매핑해야 하며, 컴플라이언스 보고서는 특정 규제 요건에 맞게 사용자 지정할 수 있어야 합니다. 구체적인 통제 항목 매핑이 없는 포괄적인 컴플라이언스 준수 주장은 충분하지 않습니다.

API 및 자동화 지원: 현대적인 보안 운영에는 프로그래밍 방식의 제어가 필요하며, 시스템은 코드형 정책 워크플로와 코드형 인프라 통합을 지원해야 합니다. 문서화되지 않았거나 자주 변경되는 API는 통합의 안정성을 저해합니다.

구매자가 구매 전에 요구해야 할 사항

기업은 아키텍처 다이어그램과 화려한 마케팅 자료보다는 증거를, 그럴듯한 시연보다는 재현 가능성을, 자체 주장보다는 독립적인 검증을 요구해야 합니다.

구매자는 공급업체가 한계를 명확히 설명하고, 현실적인 테스트를 지원하며, 면밀한 검토를 견딜 수 있는 자료를 제공할 것을 기대해야 합니다.

테스트하거나 설명할 수 없는 보안 통제 수단에 비즈니스 핵심 AI 시스템의 보호를 맡겨서는 안 됩니다.

독립 검증 준비

AI 보안을 평가하는 일은 어렵지만, 그렇다고 검증이 없어도 되는 것은 아닙니다. 독립적인 테스트는 기업이 통제 수단과 기능이 명시된 대로 작동한다고 확신할 수 있는 몇 안 되는 방법 중 하나입니다.

구매자는 적대적 입력, 성능 저하 시나리오, 거버넌스 요구사항 등 실제 환경을 반영한 검증 방식을 기대해야 합니다. 의미 있는 검증에 참여하려 하지 않는 공급업체의 태도는 강점이 아니라 미성숙함을 드러냅니다.

또한 검증을 일회성 절차로 간주해서는 안 됩니다. 초기 평가에서 우수한 성능을 보인 AI 보안 통제도 위협이 진화하고 모델 기능이 발전하며 새로운 공격 기법이 등장함에 따라 성능이 저하될 수 있습니다. 위협 환경은 빠르게 변화하며, AI 보안 사고에는 이전에 관찰된 적 없는 공격 방식이 사용될 수도 있습니다. 따라서 조직은 초기 테스트와 더불어 지속적인 검증 요건을 수립해야 합니다.

위협 인텔리전스 통합: 조직은 위협 인텔리전스 공급업체와 보안 연구 기관이 새롭게 공개한 취약점을 반영하는 공급업체의 업데이트 주기를 평가해야 합니다. 공급업체는 과거 학습 데이터에만 의존하지 않고 최근 공개된 공격을 탐지할 수 있음을 입증해야 합니다. 위협 인텔리전스를 자동으로 수집하면 수동 검토 절차보다 더 빠르게 대응할 수 있습니다.

모델 발전 호환성: 파운데이션 모델의 기능은 빠르게 발전하므로 보안 통제도 이에 맞춰 조정되어야 합니다. 조직은 다양한 파운데이션 모델에 대한 모델별 탐지 효과 데이터를 요청하고, 사각지대를 감출 수 있는 정량적 근거 없는 포괄적인 주장에 주의해야 합니다. 공급업체는 새 모델 버전의 인증 일정과 인증 공백 기간에 적용할 임시 완화 조치를 명확히 제시해야 합니다.

구매자 주도 검증: 조직은 공급업체의 검증에만 의존하지 말고 통제 조치를 지속적으로 테스트해야 합니다. 구매자는 정기적인 레드팀 훈련, 지속적인 자동 우회 테스트, 프로덕션 환경에서의 정책 변경 A/B 테스트를 수행할 수 있는 계약상 권리를 협상해야 합니다. 고객의 테스트를 제한하거나 세분화된 원격 측정 데이터를 제공하지 않는 공급업체는 성숙도가 부족하다는 신호입니다.

조직은 위협 환경의 변화에 따라 효과를 유지하기 위해 검증을 일회성 평가가 아닌 지속적인 협력 과정으로 간주해야 합니다. 이러한 관행이 없다면 잘 설계된 통제조차도 결국 새롭게 등장하는 공격 기법에 충분히 대응하지 못할 수 있습니다.

결론: 주장에 그치지 않고 책임 있는 실천으로

AI 보안 솔루션 도입은 단순한 기술적 결정이 아니라 장기적인 결과를 수반하는 거버넌스 차원의 결정입니다.

처음부터 까다로운 질문을 던지는 기업은 위험을 관리하고, 의사결정의 타당성을 입증하며, 예방 가능한 실패를 피하는 데 더 유리합니다.

AI 보안의 성공은 참신함이나 추상성에 달린 것이 아니라, 책임성, 투명성, 체계적인 평가에 달려 있습니다.

© 2026 NSS Labs®. 모든 권리 보유. NSS Labs(이하 "당사")의 명시적인 서면 동의 없이 본 간행물의 어떠한 부분도 복제, 복사 또는 스캔하거나, 검색 시스템에 저장하거나, 이메일로 전송하거나, 그 밖의 방식으로 배포 또는 전송할 수 없습니다.