Anthropic과 METR의 임베디드 평가 완전 분석|제3자 AI 안전성 평가와 Notion AI 위험

目錄

首頁 » 디지털 도구로 브랜드 만들기 » AI로 업무 자동화 » Anthropic과 METR의 임베디드 평가 완전 분석|제3자 AI 안전성 평가와 Notion AI 위험

다른 언어:繁體中文|日本語|English

Anthropic은 2026년 10월 15일, 비영리 연구기관 METR의 연구원 6명이 회사 내부에서 활동할 수 있도록 하고, 내부 위험 평가팀과 거의 동등한 수준의 시스템 접근 권한을 부여했으며, AI 안전성 연구 결과를 독립적으로 발표할 수 있도록 했다고 밝혔습니다. 이 제도는 「임베디드 평가(Embedded Evaluation)」라고 불리며, 제3자 연구자가 기업이 외부에 공개하는 테스트 보고서에만 의존하지 않고 모델 개발 과정과 안전 관리 절차를 직접 검토할 수 있도록 하는 것을 목표로 합니다.

AI 업계에서 이는 주목할 만한 감독 제도 실험입니다. Claude와 같은 모델이 장시간 작업을 수행하고, 외부 도구를 사용하며, 복잡한 업무 흐름을 처리할 수 있게 되면서 안전성을 모델 테스트 점수만으로 판단하기는 어려워졌습니다. 다만 METR이 연구 결과를 독자적으로 발표할 수 있다고 해도 Anthropic의 모든 내부 자료를 제한 없이 열람할 수 있는 것은 아닙니다. 일부 정보는 회사의 요구에 따라 삭제해야 할 수도 있어, 완전히 독립적인 감사 제도로 발전하기까지는 아직 갈 길이 남아 있습니다.

이러한 변화는 Notion AI와 AI Agent 같은 일상적인 업무 도구와도 관련이 있습니다. AI가 기업 지식 베이스를 검색하고, 문서를 작성하고, 데이터베이스를 수정하며, 커넥터를 통해 다른 서비스까지 조작할 수 있게 되면 모델 자체의 안전성은 전체 위험을 결정하는 여러 요소 중 하나에 불과합니다. 데이터 처리 정책, 에이전트의 권한, 워크스페이스 관리 방식 역시 최종적인 위험 수준에 영향을 미칩니다.

Anthropic과 METR은 어떤 협력을 시작했을까? 외부 연구자에게 내부 평가 접근 권한 부여

METR의 정식 명칭은 Model Evaluation and Threat Research로, 최첨단 AI 모델의 능력과 위험, 평가 방법을 연구하는 비영리 기관입니다. 양측은 이전부터 Anthropic의 모델 위험 보고서를 검토하는 과정에서 협력해 왔습니다. 이번에 발표된 새로운 협력 방식은 METR이 기존의 비교적 제한적인 외부 검토를 넘어 Anthropic의 내부 안전성 평가 업무에 더욱 가까이 참여할 수 있도록 한다는 점에서 차이가 있습니다.

Anthropic이 10월 15일 발표한 공식 공지에 따르면, METR 연구원 6명에게 회사가 제공하는 장비와 사무 공간, 내부 위험 평가팀과 대체로 동등한 수준의 도구 및 시스템 접근 권한이 주어졌습니다. Anthropic은 직원들에게도 공유가 제한된 정보를 제외하고는 이 연구자들을 모델 위험 관련 업무에 참여하는 내부 동료처럼 대하며, 필요한 정보와 연구 배경을 공유하도록 권장했습니다.

임베디드 평가와 일반적인 AI 모델 테스트는 무엇이 다를까?

기존의 제3자 AI 평가는 대부분 모델의 출력 결과를 살펴보는 방식으로 진행됐습니다. 연구자가 질문이나 테스트 작업을 설계한 뒤 모델이 지시를 준수하는지, 위험한 콘텐츠를 생성하는지, 다양한 상황에서 비정상적인 행동을 보이는지 관찰하는 것입니다. 이러한 테스트는 특정 조건에서 모델의 성능을 비교하는 데 적합합니다. 그러나 문제가 학습 과정이나 내부 모니터링, 모델 출시 결정과 관련되어 있다면 외부 연구자는 제한된 자료를 바탕으로 추정할 수밖에 없는 경우가 많습니다.

예를 들어 어떤 모델이 공개 안전성 테스트에서는 좋은 성적을 거뒀지만, 회사 내부에서 작업을 수행할 때 모니터링 시스템을 우회하거나 승인되지 않은 작업을 시도한 적이 있을 수 있습니다. 기업이 이러한 사건을 자발적으로 공개하지 않는다면 외부 연구자가 실제로 이런 실패가 발생했는지 판단하기는 어렵습니다. 해당 사건이 어떻게 발견됐고, 어떤 방식으로 수정됐으며, 같은 문제가 다시 발생할 가능성이 있는지도 파악하기 어렵습니다.

임베디드 평가는 이러한 정보 격차를 줄이려는 시도입니다. 연구자는 모델을 테스트하는 데 그치지 않고 보호 조치가 어떻게 설계됐는지, 모니터링 시스템이 정상적으로 작동하는지, 기업이 이미 알려진 안전성 사고를 어떻게 처리하는지도 살펴볼 기회를 얻습니다. 따라서 평가는 특정 테스트의 성공률을 넘어 모델 개발과 배포 과정 전반으로 확대될 수 있습니다.

다만 직원과 비슷한 수준의 권한을 얻었다고 해서 모든 자료를 볼 수 있는 것은 아닙니다. Anthropic은 고객 데이터, 법적 비밀유지 특권으로 보호되는 정보, 일부 모델 아키텍처의 세부 사항 등 특정 정보에 대한 접근 제한을 유지하고 있습니다. 따라서 METR이 실제로 어떤 문제를 연구할 수 있는지는 협력 조건과 확보할 수 있는 정보의 범위에 따라 달라집니다.

Anthropic이 구축하는 3단계 제3자 AI 안전성 평가 제도

Anthropic은 현재 개발 중인 3단계 외부 평가 제도도 함께 공개했습니다. 연구 범위와 협력 관계의 성숙도에 따라 서로 다른 수준의 정보 접근 권한을 단계적으로 제공하겠다는 구상입니다. 세 단계의 가장 큰 차이는 연구자가 얼마나 많은 내부 자료에 접근할 수 있는지, 연구 결과를 발표할 때 Anthropic의 동의가 필요한지에 있습니다.

평가 단계정보 접근 범위연구 결과 발표 권한현재 협력 현황
1단계특정 위험 사안에 관한 제한적인 정보 제공발표하려면 Anthropic의 동의 필요SecureBio
2단계1단계보다 더 많은 내부 정보에 접근 가능사전 동의는 필요 없지만 특정 정보 삭제 제한을 준수해야 함구축 중인 협력 단계
3단계내부 위험 평가팀과 거의 동등한 접근 권한 확보독립적인 연구 발표가 가능하지만 민감한 정보에 대한 제한은 유지METR

현재 3단계 접근 권한을 확보한 사실이 공개된 평가 기관은 METR입니다. 또 다른 비영리 기관인 SecureBio는 Anthropic의 2026년 8월 위험 보고서에 포함된 화학·생물학 무기 관련 내용을 검토하고 있으며, 이는 1단계 협력에 해당합니다. Anthropic은 Accenture 등 외부 팀과도 평가 협력을 진행하고 있지만, 그렇다고 모든 협력 기관이 METR과 같은 접근 권한을 갖고 있다고 판단할 수는 없습니다.

이러한 단계별 제도는 AI 안전성 평가가 직면한 현실적인 문제를 반영합니다. 기업은 외부 연구자에게 충분한 증거를 제공해야 하지만, 동시에 고객 데이터와 영업비밀, 악용될 가능성이 있는 기술적 세부 정보가 외부로 유출되는 것도 방지해야 합니다. 단계별 접근 권한은 이 두 가지 요구 사이에서 실행 가능한 협력 방식을 찾기 위한 장치입니다.

METR은 AI 안전성 보고서를 독립적으로 발표할 수 있을까? Anthropic의 정보 제한은 여전히 존재

외부 평가의 독립성은 연구자가 해당 기업의 직원인지 아닌지만으로 판단할 수 없습니다. 연구 범위를 누가 결정하는지, 기업과 다른 의견을 공개할 수 있는지, 기업이 불리한 결과의 발표를 막을 권한을 갖고 있는지도 확인해야 합니다.

Anthropic이 공개한 새로운 협력 조건에 따르면, METR은 모델 위험과 내부 사고, 안전 조치에 관한 분석을 자체적으로 발표할 수 있습니다. Anthropic은 더 이상 연구 결과의 발표를 전면적으로 거부할 권한을 갖지 않습니다. METR이 회사의 위험 판단을 비판하더라도 원칙적으로 Anthropic의 사전 동의를 받을 필요가 없습니다. 이는 연구 결과를 공개하려면 기업의 승인을 받아야 했던 전통적인 협력 방식보다 분명히 진전된 형태입니다.

Anthropic은 보고서 발표를 전면적으로 거부할 수 없지만 민감한 정보의 삭제를 요구할 수 있다

독립적인 발표에도 여전히 제한은 존재합니다. Anthropic은 고객 데이터, 법적으로 비밀이 보호되는 정보, 특정 기밀 지식재산 등 사전에 정의된 범주에 해당하는 정보를 삭제하도록 METR에 요구할 수 있습니다. 어떤 내용이 제한 대상에 해당하는지에 대한 최종 판단권도 Anthropic이 보유합니다.

METR은 자신들이 확보한 정보의 범위와 연구에 적용된 제한 사항, Anthropic이 제시한 삭제 사유에 동의하는지 여부를 공개적으로 설명할 수 있습니다. 그러나 이러한 설명을 위해 접근이 제한된 원본 자료를 직접 공개할 수는 없습니다.

이러한 구조에서는 한 가지 문제가 발생할 수 있습니다. 특정 안전성 위험을 뒷받침하는 증거가 기업의 기밀 정보와 관련되어 있다면, 외부 연구자가 독립적인 결론을 내리더라도 그 결론을 뒷받침하는 자료를 모두 공개하지 못할 수 있습니다. 독자는 연구자가 문제를 발견했는지 알 수는 있지만, 모든 증거를 직접 검증하지는 못할 수도 있습니다.

반면 기업에 모델 아키텍처 전체나 고객 기록, 내부 보호 조치의 세부 사항을 모두 공개하라고 요구하는 것 역시 반드시 합리적인 것은 아닙니다. 일부 정보는 외부로 유출될 경우 공격 위험을 높일 수 있기 때문입니다. 따라서 성숙한 외부 평가 제도에는 모든 정보를 무조건 공개하도록 요구하는 대신 명확한 비밀유지 범위, 추적 가능한 정보 제한 절차, 이견을 해결할 수 있는 장치가 필요합니다.

제3자 연구와 법적 안전성 감사 사이에는 여전히 차이가 있다

Anthropic은 과거 임베디드 평가를 은행 감독 제도에 비유한 적이 있습니다. 대형 은행이 보유한 내부 위험 정보는 일반적으로 외부인이 파악할 수 있는 정보보다 훨씬 상세합니다. 따라서 감독기관은 담당자를 금융기관에 상주시켜 위험 관리 체계를 지속적으로 점검하기도 합니다.

그러나 METR은 정부 규제기관이 아니며, 이번 협력도 법률에 따라 강제적으로 시행되는 상주 감사가 아닙니다. 연구자가 확보한 권한은 양측의 합의에 따른 것으로, 법적인 조사권이나 제재권을 부여받은 것은 아닙니다. 또한 METR이 Anthropic 내부에서 활동하게 됐다는 사실을 Claude가 포괄적인 안전 인증을 통과했다는 의미로 받아들여서도 안 됩니다.

평가의 신뢰성을 판단할 때는 연구 자금과 협력 관계, 정보 접근 과정이 기업의 영향을 받는지도 고려해야 합니다. AI 기업이 언제든 협력을 종료하거나 특정 증거에 대한 접근을 제한할 수 있고, 연구자가 정말 중요한 안전성 사고를 조사하지 못하도록 한다면 최종 보고서가 수정되지 않았더라도 연구 자체의 검토 범위가 충분하지 않을 수 있습니다.

2026년 10월 13일 Reuters의 조사 보도에서도 주요 AI 기업과 외부 평가 기관 사이에 연구 결과의 공개 권한, 영업비밀 보호, 기업 간 협력 제한을 둘러싼 의견 차이가 여전히 존재한다고 지적했습니다. Anthropic이 제시한 현재의 제도는 이러한 문제를 해결하려는 하나의 시도입니다. 독립성을 장기적으로 유지할 수 있을지는 후속 연구와 실제 운영 결과를 통해 검증해야 합니다.

METR의 최신 연구에서 무엇이 밝혀졌을까? Anthropic의 AI 모니터링 시스템에는 여전히 한계가 있다

Anthropic이 임베디드 평가 제도를 발표한 지 얼마 지나지 않은 2026년 10월 20일, METR은 또 다른 연구 보고서를 발표했습니다. 이 연구는 Anthropic의 2026년 8월 위험 보고서에 포함된 「중대한 위험이 따르는 상황에서의 모델 정렬 실패(Misalignment in high-stakes settings)」 관련 내용을 검토한 것입니다.

이 보고서는 외부 연구자가 기업의 안전성 판단에 어떻게 의문을 제기할 수 있는지 이해하는 데 도움이 됩니다. 다만 먼저 연구 시점의 차이를 명확히 해야 합니다. METR은 이번 연구가 이전 협력 조건에 따라 진행됐으며, 연구 기간에는 10월 15일 발표된 임베디드 평가 접근 권한을 확보하지 못했다고 분명히 밝혔습니다. 따라서 이 보고서를 새로운 제도의 첫 번째 평가 성과로 볼 수는 없습니다.

이전 조건에서는 Anthropic이 보고서 발표를 거부하거나 내용 삭제를 요구할 권한을 갖고 있었습니다. 그러나 METR에 따르면 최종적으로 삭제된 내용은 없었으며, 발표 심사 과정에서 연구 결론이 수정되지도 않았습니다. 피드백에 따라 일부 표현과 실험 방법만 조정됐습니다.

METR은 현 단계의 재앙적 위험이 낮다는 결론에는 동의하지만 그 이유에 대해서는 의견이 다르다

Anthropic의 원래 보고서는 2026년 7월 15일 기준으로, 보고서에 포함된 모델의 정렬 실패 행동으로 인해 재앙적인 피해가 발생할 위험이 낮다고 평가했습니다. 여기서 모델의 정렬 실패란 주로 AI의 행동이나 목표가 의도한 방향에서 벗어나 특정 상황에서 심각한 결과를 초래할 수 있는 상태를 뜻합니다.

METR은 현재 위험이 낮다는 결론에는 대체로 동의합니다. 그러나 그 주된 이유는 평가 대상 모델의 능력이 아직 제한적이기 때문이며, 기존 안전성 학습이나 보호 조치가 충분히 신뢰할 만하다는 사실에서 비롯된 결과로 직접 해석해서는 안 된다고 봅니다.

다시 말해 현재 모델이 특정한 재앙적 결과를 초래할 정도의 능력을 아직 보여주지 않았다는 판단과, 기업이 그런 결과를 안정적으로 방지할 수 있는 안전장치를 이미 구축했다는 판단은 서로 다릅니다. 앞으로 모델의 능력이 계속 향상된다면 지금까지 효과적으로 보였던 보호 조치가 여전히 제대로 작동할 수 있을지 더 많은 실증 연구가 필요합니다.

METR은 또한 Anthropic의 현행 위험 평가 방법만으로는 위험이 실제로 높아졌을 때 중요한 모델 정렬 실패 행동을 모두 신뢰성 있게 식별하기 어렵다고 판단했습니다. 이러한 비판은 위험에 관한 증거와 평가 방법을 대상으로 한 것이지, Claude가 일반적인 사용 환경에서 재앙적인 사고를 일으킨다는 사실을 METR이 입증했다는 뜻은 아닙니다.

모델이 안전성 테스트를 통과했다고 해서 실제 환경에서도 효과적으로 모니터링할 수 있는 것은 아니다

METR이 모니터링 시스템에 제기한 의문은 특히 주목할 만합니다.

많은 AI 안전성 테스트는 특정 작업을 설정하고 모델이 자신의 행동을 숨기거나 모니터링을 회피하려는지, 기존 안전 요구 사항을 위반하는지 관찰합니다. 그러나 실제 배포 환경에서 모델이 반드시 테스트에서 설계한 방식대로 행동하는 것은 아닙니다. 때로는 의도적으로 작업을 숨길 필요조차 없습니다. 모니터링 시스템이 유해한 행동을 정상적인 작업의 일부라고 오인하게 만드는 것만으로도 원래 의도했던 보호 조치를 우회할 수 있기 때문입니다.

따라서 METR은 일부 기존 테스트가 실제 모니터링 시스템을 우회하는 모델의 능력을 충분히 반영하지 못한다고 판단했습니다. 이전에 발생한 사건들 역시 일부 안전성 주장의 근거를 약화시켰다고 봅니다. 연구팀은 Anthropic에 모니터링 시스템을 대상으로 더욱 포괄적인 엔드투엔드 적대적 테스트를 실시하고, AI가 기업 내부의 안전 관련 의사결정에 영향을 미칠 수 있는 상황까지 위험 평가 범위를 확대할 것을 권고했습니다.

METR은 이 연구 보고서에서 삭제된 일부 내부 정보가 연구자의 모델 위험 및 모니터링 능력에 대한 판단에 영향을 줄 만큼 중요한 내용이었다고도 지적했습니다. 이에 따라 Anthropic이 적절한 처리를 거친 증거를 더 많이 공개할 것을 제안했습니다.

이러한 결과는 외부 평가의 실제 가치도 보여줍니다. 연구자가 기업의 기존 위험 판단을 뒤집지 않더라도 증거가 부족한 부분을 찾아내거나, 기존 테스트에서 다루지 않았던 실패 상황을 지적할 수 있기 때문입니다.

AI Agent에는 왜 더 심층적인 안전성 평가가 필요할까? 위험은 도구와 권한으로 확대되고 있다

METR이 연구하는 위험 중 일부는 최첨단 모델이 초래할 수 있는 재앙적인 상황에 관한 것으로, 일반 기업이 AI를 사용할 때 마주하는 데이터 유출이나 작업 오류와 완전히 같지는 않습니다. 그러나 두 경우에는 공통적인 문제가 있습니다. 테스트 환경에서 모델이 정상적으로 작동했다고 해서 복잡한 업무 흐름에 투입된 뒤에도 예상대로 행동한다고 보장할 수 없다는 점입니다.

AI가 글을 생성하거나 문서를 정리하고 질문에 답하는 용도로만 사용될 때는 일반적으로 출력 내용을 살펴보는 것만으로 오류를 발견할 수 있습니다. 그러나 현재 AI Agent는 도구를 호출하고 외부 데이터를 읽으며, 기록을 수정하거나 여러 단계로 이루어진 작업을 수행할 수 있습니다. 일부 작업은 사람이 매번 확인하지 않아도 완료될 수 있습니다.

따라서 위험 관리는 모델의 답변을 넘어 전체 실행 과정으로 확대되어야 합니다.

프롬프트 인젝션으로 AI Agent가 외부 데이터를 작업 지시로 오인할 수 있다

프롬프트 인젝션(Prompt Injection)은 에이전트형 AI에서 흔히 나타나는 보안 위험 중 하나입니다. 일반적으로 모델이 외부 데이터를 처리할 때 그 안에 포함된 신뢰할 수 없는 내용을 따라야 할 지시로 잘못 인식하면서 발생합니다.

예를 들어 어떤 AI Agent가 고객 이메일을 읽고 할 일을 정리한 다음, 업무 진행 상황을 Notion에 동기화하는 역할을 맡았다고 가정해 보겠습니다. 정상적인 상황에서 이메일 내용은 분석해야 할 데이터일 뿐입니다. 하지만 이메일에 다른 고객의 파일을 검색하거나, 기존 규칙을 무시하거나, 정보를 외부 이메일 주소로 전달하라는 문구가 섞여 있다면 모델은 해당 내용에 정당한 작업 권한이 부여되지 않았다는 사실을 구별해야 합니다.

시스템이 데이터와 지시를 구분하지 못한다면 에이전트는 본래 정당한 업무를 수행하는 과정에서 사용자 의도에 맞지 않는 작업까지 실행할 수 있습니다.

이러한 문제는 프롬프트에 AI가 안전 규칙을 준수하도록 요구하는 것만으로는 완전한 보호 체계를 구축할 수 없다는 사실도 보여줍니다. 외부 콘텐츠가 여전히 모델의 판단에 영향을 미칠 수 있기 때문에 도구 자체에서 실행 가능한 작업을 제한하고, 위험도가 높은 작업에는 추가 검증 절차를 마련해야 합니다.

AI Agent의 권한이 지나치게 크면 일반적인 오류도 데이터 보안 사고로 이어질 수 있다

OWASP는 대규모 언어 모델 애플리케이션의 위험 분류에서 「과도한 에이전시(Excessive Agency)」를 중요한 문제로 제시합니다. 이는 주로 지나치게 많은 기능과 과도한 권한, 너무 높은 자율성과 관련이 있습니다.

예를 들어 데이터 정리만 필요한 에이전트에게 문서 삭제, 재무 데이터 수정, 외부 이메일 발송 권한까지 모두 부여했다면, 단순히 모호한 지시를 받았을 뿐인데도 원래 작업 범위를 넘어서는 영향을 초래할 수 있습니다.

문제가 반드시 모델의 악의적인 행동에서 비롯되는 것은 아닙니다. 데이터 출처가 잘못됐거나 모델이 요구 사항을 오해했을 수도 있고, 외부 콘텐츠가 조작됐을 수도 있습니다. 사건의 영향을 확대하는 진짜 원인은 시스템이 에이전트에 영향력이 큰 작업을 직접 실행하도록 허용하면서 적절한 확인 절차를 마련하지 않았다는 데 있습니다.

따라서 에이전트가 어떤 도구를 사용할 수 있는지, 각 도구에 어떤 권한이 있는지, 어떤 작업에 사람의 승인이 필요한지를 안전성 평가에 포함해야 합니다. 실제 운영 데이터 수정, 기록 삭제, 외부 정보 전송과 같은 작업에서는 권한 제한을 모델 스스로의 판단에 전적으로 맡기지 말고, 실제 작업을 수행하는 도구나 후속 시스템에서 강제로 적용하는 것이 바람직합니다.

Anthropic의 제3자 안전성 평가는 Notion AI 사용자에게 어떤 영향을 미칠까?

Notion AI는 Anthropic과 OpenAI 등을 포함한 여러 모델 공급업체와 추론 서비스 제공업체를 활용해 기능을 제공합니다. 따라서 모델 공급업체의 안전 거버넌스는 Notion의 AI 서비스와도 관련이 있습니다.

그러나 모델 안전성, 데이터 개인정보 보호, 워크스페이스 권한은 서로 다른 차원의 문제입니다. Anthropic이 METR의 평가를 수용했다는 사실은 모델 공급업체 중 한 곳이 모델 위험을 어떻게 관리하는지 이해하는 참고 자료가 될 수 있습니다. 그렇다고 METR이 Notion의 서비스 아키텍처까지 검토했다고 판단할 수는 없으며, METR이 Notion 고객의 워크스페이스 콘텐츠에 접근할 수 있게 됐다는 의미도 아닙니다.

실제로 Notion AI를 사용하는 팀은 모델 안전성 연구에 관심을 갖는 것과 함께 데이터가 어떤 처리업체에 전달되는지, 워크스페이스 콘텐츠가 어떤 방식으로 검색·조회되는지, 에이전트가 작업에 필요한 수준을 넘어서는 권한을 가지고 있지는 않은지도 확인해야 합니다.

Notion AI가 고객 데이터를 모델 학습에 사용하지 않아도 데이터 전송과 처리는 필요할 수 있다

Notion의 공식 AI 보안 설명에 따르면, 기본적으로 고객의 워크스페이스 데이터나 개인정보는 모델 학습에 사용되지 않습니다. 관련 AI 하위 처리업체 역시 계약상 고객 데이터를 무단으로 모델 학습에 사용하는 것이 금지되어 있습니다. Notion에는 사용자가 자발적으로 참여해야 하는 별도의 데이터 공유 프로그램도 있으므로 적용 조건을 개별적으로 확인해야 합니다.

하지만 Notion AI가 워크스페이스와 관련된 질문에 답할 때는 필요한 콘텐츠를 검색하고, 요청을 처리하는 데 필요한 정보를 모델 서비스 제공업체에 전달할 수 있습니다. 따라서 「모델 학습에 데이터를 사용하지 않는다」는 말이 「데이터가 전혀 전송되지 않는다」는 뜻은 아닙니다.

데이터 보관 기간도 요금제에 따라 다릅니다. Notion이 현재 공개한 보안 문서에 따르면, Enterprise 워크스페이스의 기본 대규모 언어 모델 제공업체에는 데이터 무보관(Zero Data Retention) 방식이 적용됩니다. 다른 요금제에서는 모델 제공업체가 데이터를 최대 30일 동안 보관할 수 있습니다. 이러한 규정은 주로 모델 제공업체의 데이터 처리에 관한 것이며, Notion 워크스페이스나 채팅 기록, 검색 인덱스의 저장 정책과 직접적으로 동일하게 볼 수는 없습니다.

고객 계약서나 개인정보, 기타 민감한 정보가 관련되어 있다면 현재 사용하는 기능과 요금제, 관련 데이터 처리 약관을 바탕으로 실제 상황을 확인해야 합니다. 모델 제공업체의 안전성 관련 설명만으로 판단해서는 안 됩니다.

Notion AI와 Custom Agents의 권한은 어떻게 다를까?

Notion 공식 문서는 일반 Notion AI와 Custom Agents의 권한 구조를 상당히 명확하게 구분하고 있습니다.

일반 Notion AI는 현재 사용자의 접근 권한에 따라 검색을 수행하며, 원칙적으로 해당 사용자가 원래 볼 수 있는 콘텐츠에만 접근할 수 있습니다. 반면 Custom Agents는 독립적인 리소스 권한을 갖고 있어 생성 시 접근이 허용된 특정 페이지와 데이터베이스, 외부 애플리케이션을 이용할 수 있습니다.

비교 항목일반 Notion AICustom Agents
권한 기준현재 사용자의 개인 접근 권한에이전트 자체에 부여된 리소스 권한
데이터 접근원칙적으로 사용자가 볼 수 있는 콘텐츠로 제한에이전트에 명시적으로 권한이 부여된 리소스에 접근 가능
작업 방식주로 사용자의 요청에 따라 실행설정 및 트리거 조건에 따라 자동 실행 가능
여러 사용자 간 협업각 사용자의 권한에 따라 작동여러 사용자가 동일한 에이전트를 공유 가능
주요 위험데이터 처리, 답변 오류, 사용자 권한 관리에이전트에 대한 과도한 권한 부여, 간접적인 정보 접근, 자동 작업 오류

Custom Agents는 부서 간 데이터를 함께 활용해야 하는 상황에 적합하게 설계되어 있습니다. 예를 들어 프로젝트 구성원이 공용 에이전트를 통해 진행 상황을 조회하거나, 에이전트가 서로 다른 데이터베이스의 업무 정보를 통합하는 경우가 있습니다.

하지만 이러한 구조에는 쉽게 놓칠 수 있는 권한 문제도 존재합니다. Notion 공식 문서에서는 사용자가 특정 페이지에 직접 접근할 권한이 없더라도, 그 페이지를 읽을 수 있는 Custom Agent의 사용 권한을 받았다면 에이전트의 답변을 통해 관련 정보를 얻을 수 있다고 명시하고 있습니다. 에이전트에 쓰기 권한까지 있다면 사용자가 직접 편집할 수 없는 리소스를 에이전트를 통해 수정할 수도 있습니다.

이는 Custom Agents의 권한 설계상 특징이며, Notion에서 새로운 데이터 유출 사고가 발생했다는 뜻은 아닙니다. 그러나 에이전트를 공유할 때는 이러한 특성을 신중하게 확인해야 합니다.

예를 들어 어떤 에이전트가 회사 내부의 견적과 예산, 고객 데이터를 읽을 수 있고 모든 프로젝트 구성원이 이 에이전트를 사용할 수 있다고 가정해 보겠습니다. 원본 데이터베이스 자체의 공유를 제한했더라도 에이전트를 통해 또 다른 정보 접근 경로가 만들어질 수 있습니다.

따라서 특정 구성원에게서 원본 페이지 접근 권한을 제거했다고 해서 간접적인 정보 취득까지 완전히 막을 수 있는 것은 아닙니다. 해당 구성원이 어떤 에이전트를 사용할 수 있는지, 그 에이전트가 여전히 관련 리소스에 접근할 권한을 가지고 있는지도 확인해야 합니다.

Notion에서 AI 위험 관리 프로세스를 어떻게 구축할까? 데이터 권한과 작업 기록부터 시작

프리랜서나 소규모 팀, 기업 모두 Anthropic과 같은 규모의 AI 안전성 평가 제도를 구축할 필요는 없는 경우가 많습니다. 더 현실적인 방법은 현재 사용 중인 AI 도구가 어떤 데이터에 접근할 수 있고, 어떤 작업을 수행할 수 있으며, 오류가 발생했을 때 해당 작업을 중지하거나 복구할 수 있는지부터 확인하는 것입니다.

이러한 점검을 위해 AI를 전면적으로 비활성화하거나 복잡한 관리 시스템을 새로 구축할 필요는 없습니다. 기존 Notion 워크스페이스에서 사용 중인 서비스 목록과 권한, 위험 기록을 정리하는 것만으로도 향후 정기적인 검토를 위한 기반을 마련할 수 있습니다.

AI가 접근할 수 있는 데이터를 먼저 파악하고 공급업체의 처리 정책을 확인한다

워크스페이스에는 일반 메모와 공개 자료, 고객 계약서, 재무 기록, 아직 공개되지 않은 기획안 등이 함께 저장되어 있는 경우가 많습니다. 하지만 이러한 데이터가 모두 같은 수준으로 AI 처리에 적합한 것은 아닙니다.

먼저 데이터의 성격에 따라 AI로 직접 처리해도 되는 콘텐츠, 비식별화가 필요한 콘텐츠, 계약이나 내부 정책에 따라 승인되지 않은 서비스에서 처리할 수 없는 콘텐츠를 구분할 수 있습니다. 분류를 마친 뒤에는 각 AI 기능에서 실제로 사용하는 공급업체와 데이터 보관 방식, 적용 약관을 확인합니다.

특히 여러 플랫폼을 연결한 업무 흐름에서는 데이터가 Notion과 모델 서비스 제공업체, 커넥터, 다른 자동화 플랫폼을 거쳐 전달될 수 있습니다. 따라서 한 공급업체의 개인정보 처리방침만 확인해서는 충분하지 않습니다.

Custom Agents와 커넥터의 권한을 점검해 과도한 접근 허용을 방지한다

데이터 현황을 파악한 뒤에는 현재 활성화된 에이전트와 외부 커넥터를 확인해야 합니다.

Custom Agents의 경우 Tools and Access 설정에서 에이전트가 어떤 페이지와 데이터베이스, 외부 애플리케이션에 접근할 수 있는지 확인할 수 있습니다. 이어서 누가 해당 에이전트를 사용할 수 있는지, 데이터를 읽거나 수정하고 외부로 전송할 권한이 실제로 필요한지도 점검해야 합니다.

에이전트가 프로젝트 요약을 생성하는 역할만 한다면 일반적으로 데이터베이스 편집 권한을 부여할 필요가 없습니다. 특정 고객에 관한 업무만 처리한다면 워크스페이스 전체에 대한 접근 권한을 허용하는 것도 피해야 합니다.

더 이상 사용하지 않는 커넥터나 종료된 프로젝트, 퇴사한 구성원에게 접근 권한이 남아 있는지도 확인해야 합니다. Notion Enterprise 관리자는 실제로 활성화된 기능에 따라 Agent Directory와 콘텐츠 검색, 감사 로그를 통해 에이전트 활동을 관리할 수도 있습니다.

AI Agent의 실패 상황을 모의 테스트해 오류를 차단하고 복구할 수 있는지 확인한다

권한 설정을 마친 뒤에는 테스트 데이터를 활용해 흔히 발생할 수 있는 실패 상황을 재현할 수 있습니다. 예를 들어 에이전트가 접근해서는 안 되는 페이지를 읽거나, 잘못된 정보를 바탕으로 데이터베이스를 수정하거나, 외부 문서에 포함된 유도 문구 때문에 불필요한 작업을 수행하는 상황입니다.

테스트할 때는 에이전트가 마지막에 자신의 행동을 어떻게 설명했는지만 볼 것이 아니라 실제 실행 결과를 확인해야 합니다. 중요한 데이터를 수정하기 전에 사람의 승인을 받도록 설계했다면, 에이전트가 작업을 실행하기 전에 실제로 멈추는지 확인해야 합니다. 수정을 완료한 뒤에야 동의 여부를 묻는 방식이어서는 안 됩니다.

쓰기 또는 삭제 권한이 있는 자동화 프로세스에서는 버전 기록이나 백업, 기타 방법을 통해 데이터를 복구할 수 있는지도 확인해야 합니다. 이상 상황이 발생했을 때 누가 에이전트를 비활성화하고, 기록을 확인하며, 후속 영향을 처리할 것인지도 정해 두어야 합니다.

AI 위험 관리 대장을 만들어 서비스와 에이전트 권한을 정기적으로 점검한다

서비스 도입 전 테스트뿐 아니라 지속적으로 사용하는 AI 도구에 대한 정기적인 검토도 필요합니다. 모델과 공급업체, 플랫폼 기능은 업데이트될 수 있으며, 처음에는 적절했던 권한도 프로젝트 종료나 인력 변동, 새로운 연동 서비스 추가로 인해 더 이상 적합하지 않을 수 있습니다.

Notion에 간단한 「AI 위험 관리 대장」을 만들어 현재 사용 중인 AI 서비스와 데이터 범위, 권한 상태를 기록할 수 있습니다.

항목권장 기록 내용
AI 서비스 이름Notion AI, Custom Agent 또는 기타 AI 도구
모델 및 공급업체사용 중인 모델과 관련 서비스 제공업체
접근 가능한 데이터페이지, 데이터베이스, 고객 데이터 또는 외부 데이터 소스
작업 권한읽기, 생성, 수정, 삭제 또는 외부 전송
데이터 민감도공개, 내부용, 기밀 또는 기타 분류
외부 안전성 평가공개된 제3자 연구와 평가 범위
위험 및 대응 상태발견된 문제, 개선 방법 및 담당자
마지막 점검 날짜권한과 설정을 마지막으로 확인한 날짜

개인 워크스페이스라면 민감한 페이지와 불필요한 접근 권한부터 정리할 수 있습니다. 여러 사람이 협업하는 팀에서는 공유 에이전트를 통한 간접적인 정보 접근에 추가로 주의해야 합니다. 실제 운영 데이터를 자동으로 수정하는 업무 흐름이라면 활성화하기 전에 실패 상황에 대한 테스트도 진행하는 것이 좋습니다.

Anthropic의 임베디드 평가가 AI 업계의 새로운 표준이 될 수 있을까?

Anthropic과 METR의 협력은 기존의 공개 모델 테스트보다 한층 심층적인 외부 감독 방식을 제시합니다. 연구자는 모델 개발 및 위험 관리 과정에 더 가까이 접근하고, 확보한 증거를 바탕으로 독립적인 결론을 내릴 수 있습니다. 이는 AI 기업과 외부 사이의 정보 격차를 줄이는 데 도움이 됩니다.

다만 이 제도가 장기적으로 효과를 발휘할 수 있을지는 앞으로 진행될 실제 연구에 달려 있습니다. 외부에서는 평가자가 구체적으로 어떤 시스템을 점검했는지, 접근 제한 때문에 검증하지 못한 문제는 무엇인지, 연구 결과가 부당한 간섭 없이 공개될 수 있는지 알아야 합니다. 보고서에 모든 내부 세부 정보를 공개할 수 없더라도 연구 방법과 범위, 증거의 한계를 가능한 한 설명함으로써 독자가 연구 결론이 어떤 상황에 적용되는지 판단할 수 있도록 해야 합니다.

METR이 10월 20일 발표한 검토 결과는 이미 제3자 연구가 어떤 역할을 할 수 있는지 보여줬습니다. 연구자가 기업의 전반적인 위험 판단을 반드시 뒤집는 것은 아니지만, 테스트 방법의 부족한 부분과 모니터링 시스템의 사각지대, 추가로 공개해야 할 내부 정보가 무엇인지 지적할 수 있습니다. 새로운 임베디드 평가 제도가 더욱 충분한 증거를 제공할 수 있을지는 새로운 조건에 따라 진행된 연구 결과가 나와야 확인할 수 있습니다.

AI 서비스를 도입하는 기업이나 조직도 앞으로 안전성 보고서를 읽을 때 모델 공급업체가 자체적으로 발표한 테스트, 외부 기관에 의뢰해 진행한 평가, 정식 규제 효력을 갖는 감사를 구분해야 합니다. 이 세 가지가 제공할 수 있는 보증 수준은 서로 다르므로 제3자가 참여했다는 이유만으로 동일한 수준의 안전성 검토를 거쳤다고 판단해서는 안 됩니다.

결론: 제3자 AI 안전성 평가는 정보 격차를 줄일 수 있지만 실제 사용에서는 권한 관리가 필요하다

Anthropic이 METR 연구자들에게 내부 위험 평가팀과 거의 동등한 수준의 접근 권한을 부여하면서 제3자 AI 안전성 평가를 위한 새로운 협력 모델이 제시됐습니다. 공개 테스트와 기업 보고서만을 근거로 판단하던 기존 방식과 비교하면, 이제 연구자는 개발 과정과 내부 사고, 안전 조치를 더 깊이 검토할 기회를 얻게 됐습니다. 다만 정보 접근과 공개에는 여전히 제한이 있으며, 제도의 독립성은 지속적으로 지켜볼 필요가 있습니다.

METR의 최신 연구는 현 단계의 모델 위험이 낮다고 해서 기업이 미래의 더 강력한 모델에 대응할 수 있는 보호 조치를 충분히 마련했다는 의미는 아니라는 점도 일깨워 줍니다. AI의 능력과 배포 방식이 계속 변화하는 만큼, 기존 모니터링 방법이 여전히 효과적인지는 새로운 테스트와 실제 증거를 통해 확인해야 합니다.

Notion AI 사용자에게 공급업체가 외부 안전성 평가를 받는지 여부는 서비스 선택 시 고려할 수 있는 요소입니다. 하지만 일상적인 업무에서는 데이터가 어떻게 처리되는지, 에이전트가 어떤 권한을 가지고 있는지, 잘못된 작업을 차단하거나 복구할 수 있는지를 확인하는 것이 더욱 중요합니다. 특히 Custom Agents와 여러 플랫폼을 연결한 자동화를 사용할 때는 원본 데이터와 에이전트 자체의 공유 설정을 함께 점검해야 합니다. 이를 통해 원래 접근이 제한된 정보가 에이전트의 권한 때문에 간접적으로 노출되는 상황을 방지할 수 있습니다.

외부 연구는 모델 공급업체의 안전 조치를 검증하는 데 도움이 될 수 있습니다. 그러나 워크스페이스에서 어떤 데이터에 대한 접근을 허용하고, AI가 어떤 작업을 자동으로 수행하도록 할 것인지는 실제 업무상 필요성과 데이터의 민감도에 따라 결정해야 합니다.

자주 묻는 질문(FAQs)

METR은 어떤 기관이며 Anthropic과 협력하는 목적은 무엇인가요?

METR은 최첨단 AI 모델의 능력과 위험을 연구하는 비영리 기관입니다. Anthropic은 METR 연구원 6명에게 내부 위험 평가팀과 거의 동등한 수준의 접근 권한을 부여해 모델 위험과 보호 조치, 내부 안전 관리 과정을 검토할 수 있도록 했습니다.

임베디드 평가와 일반적인 AI 안전성 테스트는 무엇이 다른가요?

일반적인 외부 테스트는 주로 모델의 출력 결과를 통해 행동을 관찰합니다. 반면 임베디드 평가는 일부 내부 사고와 모니터링 체계, 개발 과정까지 살펴볼 수 있어 안전성 보고서의 근거가 되는 증거를 검증하는 데 도움이 됩니다.

METR은 Anthropic의 동의 없이 연구 결과를 공개할 수 있나요?

2026년 10월 발표된 새로운 조건에 따르면 METR은 원칙적으로 연구 결과를 독자적으로 발표할 수 있습니다. 다만 고객 데이터와 법적 비밀유지 대상 정보, 일부 모델 아키텍처 등에는 여전히 제한이 있으며, Anthropic은 특정 민감한 내용의 삭제를 요구할 수 있습니다.

METR이 10월 20일 발표한 연구는 새로운 임베디드 평가 제도의 성과인가요?

아닙니다. METR은 해당 보고서가 이전 협력 조건에 따라 작성됐으며, 연구 당시에는 10월 15일 발표된 임베디드 평가 접근 권한을 확보하지 못했다고 밝혔습니다. 따라서 두 가지 진행 상황은 구분해서 이해해야 합니다.

METR의 최신 보고서는 Anthropic의 모델 위험을 어떻게 평가했나요?

METR은 특정한 재앙적 정렬 실패 위험이 현재 낮다는 판단에는 대체로 동의했습니다. 그러나 주된 이유는 모델의 능력이 아직 제한적이기 때문이며, 현행 모니터링과 위험 테스트만으로는 미래의 더 강력한 모델도 안정적으로 통제할 수 있다고 입증하기에 충분하지 않다고 봅니다.

METR이 Anthropic 내부에서 활동하게 된 것은 Claude가 안전 인증을 통과했다는 뜻인가요?

아닙니다. 이는 Anthropic과 제3자 연구자 사이의 자발적인 협력이며, 정부가 법률에 따라 실시하는 감사가 아닙니다. Claude나 Anthropic의 모델을 사용하는 다른 제품에 대한 포괄적인 안전 인증을 의미하지도 않습니다.

Notion AI가 워크스페이스 데이터를 모델 학습에 사용하지 않는다면 데이터가 전혀 전송되지 않는다는 뜻인가요?

아닙니다. Notion AI가 질문에 답하는 과정에서 워크스페이스 콘텐츠를 검색하고 필요한 정보를 모델 서비스 제공업체에 전달해 처리할 수 있습니다. 데이터가 학습에 사용되는지, 어떻게 전송되는지, 얼마나 오래 보관되는지는 각각 적용 정책을 확인해야 합니다.

Notion AI와 Custom Agents의 권한은 어떻게 다른가요?

일반 Notion AI는 원칙적으로 현재 사용자의 페이지 접근 권한에 따라 작동합니다. 반면 Custom Agents는 독립적으로 부여된 리소스 권한을 가집니다. 따라서 사용자가 공유 에이전트를 통해 자신은 직접 열람할 수 없는 정보를 간접적으로 얻을 가능성이 있습니다.

Notion Custom Agents의 데이터 유출 및 잘못된 작업 실행 위험을 줄이려면 어떻게 해야 하나요?

민감한 데이터를 파악하고 에이전트와 커넥터의 접근 범위를 축소해야 합니다. 삭제와 외부 정보 전송, 중요한 수정 작업에는 사람의 승인 절차를 마련하고, 테스트 데이터를 사용해 프롬프트 인젝션과 잘못된 데이터 입력, 복구 과정을 점검하는 것이 좋습니다.

AI 안전성 평가 보고서에서는 어떤 정보를 확인해야 하나요?

평가자가 어떤 증거에 접근할 수 있었는지, 테스트가 어떤 모델과 상황을 다뤘는지, 보고서 발표에 제한이 있었는지, 해결되지 않은 문제는 무엇인지 확인해야 합니다. 제3자가 평가에 참여했다는 이유만으로 포괄적인 안전성이 보장된다고 판단해서는 안 됩니다.

SUPPORT FENGNIII

喜歡這篇文章嗎?

如果這篇內容對你有幫助,可以透過小額贊助支持本站持續整理更多日文、韓文、旅行與數位工具內容。

小額支持本站

付款將由藍新金流安全處理