AI가 데이터를 보지 않고도 안전을 검사할 수 있을까? OpenAI ZDR이 바꾸는 엔터프라이즈 AI

프로필 이미지
gwanhun1
7분 읽기조회 2
공유

exec-c3af0405-896a-4607-ad65-2f1e2e0e1111.png

기업이 AI를 도입할 때 가장 먼저 나오는 질문은 “모델이 얼마나 똑똑한가?”가 아닙니다.

우리가 보낸 프롬프트와 결과가 어디에 남고, 누가 볼 수 있으며, 사고가 났을 때 무엇을 증명할 수 있는가?

2026년 8월, 이 질문에 대한 두 가지 움직임이 거의 같은 방향을 가리키고 있습니다. 한국 과학기술정보통신부는 8월 24일 생성형 AI를 활용한 ICT 규제샌드박스 규제 신속 확인 서비스를 시작한다고 발표했습니다. 30개 기업을 대상으로 시범 운영한 뒤 8월 25일부터 희망 기업에 이용권을 제공하는 방식입니다. 대한민국 정책브리핑 보도자료

해외에서는 OpenAI가 8월 19일 **Zero Data Retention(ZDR)**을 유지하면서 여러 상호작용에 걸친 위험 패턴을 탐지하는 Private Safety Processing을 미리 공개했습니다. 적격 API 고객의 프롬프트와 응답을 처리 후 보존하지 않으면서, 자동화된 안전 시스템이 관련 상호작용을 함께 분석하겠다는 접근입니다. OpenAI 공식 발표

서로 다른 뉴스처럼 보이지만 본질은 같습니다.

AI의 경쟁력이 모델 성능만으로 결정되지 않고, 데이터·규제·안전·증거를 시스템 안에 어떻게 묶느냐로 이동하고 있습니다.

OpenAI의 발표를 정확히 읽기

OpenAI가 발표한 ZDR은 적격 API 고객의 프롬프트와 모델 응답을 요청 처리 뒤 보존하지 않는다는 약속입니다. 고객 콘텐츠는 OpenAI 직원의 검토 대상이 아니며, 엔터프라이즈 고객 데이터는 명시적으로 선택하지 않는 한 모델 학습에 사용되지 않는다고 설명합니다.

문제는 안전 모니터링입니다. 짧은 한 번의 요청만 보면 정상적인 질문처럼 보여도, 여러 요청을 연결하면 악용 의도가 드러날 수 있습니다. 에이전트가 긴 작업을 수행할 때도 위험은 한 번의 호출보다 여러 단계의 조합에서 나타납니다.

OpenAI가 미리 공개한 Private Safety Processing은 이 지점을 겨냥합니다.

  1. 고객 콘텐츠는 고객이 통제하는 인프라에 남거나, OpenAI 인프라에 저장하더라도 고객이 관리하는 키로 암호화됩니다.
  2. 자동화된 시스템은 관련 상호작용에서 위험 패턴을 찾습니다.
  3. OpenAI가 받는 것은 콘텐츠가 아니라 활동 유형을 나타내는 제한된 안전 신호입니다.
  4. 고객은 자신의 시스템에서 경고와 집행 결정을 조사하고, 필요할 때만 관련 정보를 공유할 수 있습니다.

다만 아직 모든 고객에게 제공되는 완성 기능은 아닙니다. OpenAI는 현재 초기 고객을 대상으로 테스트 중이며, 9월부터 롤아웃을 시작하고 기술 백서를 공개할 계획이라고 밝혔습니다. 따라서 “완전한 프라이버시가 해결됐다”고 쓰기보다, ZDR과 다중 상호작용 안전성의 충돌을 줄이려는 설계 미리보기라고 이해하는 편이 정확합니다.

왜 ‘대화를 보지 않는 안전성’이 필요한가

기존 안전 시스템은 대체로 한 번의 요청과 응답을 기준으로 판단합니다. 그러나 에이전트 시대에는 다음과 같은 긴 흐름이 일반적인 작업이 됩니다.

1 2 3 목표 입력 ↓ 검색 → 파일 읽기 → API 호출 → 결과 조합 → 재시도 → 외부 행동

각 단계만 보면 정상이어도 전체 흐름에서는 권한을 벗어난 행동이나 반복적인 안전장치 우회가 나타날 수 있습니다. 반대로 기업의 내부 문서, 고객 정보, 소스코드가 포함된 대화는 제공자가 원문을 장기간 보관해 분석하기 어렵습니다.

여기서 프라이버시와 안전성은 단순한 양자택일이 아닙니다. 중요한 것은 원문을 누가 볼 수 있는가어떤 신호를 안전 판단에 사용할 수 있는가를 분리하는 것입니다.

콘텐츠 자체와 안전 신호를 분리하면, 제공자는 위험 패턴을 감지하면서도 고객 데이터에 직접 접근하지 않는 구조를 만들 수 있습니다.

본문 중간 이미지: Private Safety Processing의 데이터 경계

아래 이미지는 이 글의 대표 이미지와 달리, 본문에서 설명한 처리 구조를 예시로 보여주는 용도입니다. 실제 OpenAI 내부 구현의 상세 도면이 아니라, 공식 발표 내용을 개발자 관점에서 단순화한 개념도입니다.

exec-cf2f55a5-5df0-4e7d-8700-aeb0a9c67e00.png

개발자가 봐야 할 핵심은 ‘암호화’보다 경계 설계다

프라이버시 관련 글은 쉽게 암호화 기술 소개로 흘러갑니다. 하지만 애플리케이션을 만드는 개발자가 먼저 정해야 할 것은 어떤 키 알고리즘을 쓸지보다 데이터의 경계입니다.

질문구현에서 필요한 결정
모델에 반드시 보내야 하는 데이터는 무엇인가?필드 최소화, 마스킹, 토큰화
여러 호출을 연결해야 하는가?작업 ID·세션 ID·보존 기간 정의
안전 검사를 위해 필요한 정보는 무엇인가?원문 대신 분류된 신호·메타데이터 사용
누가 결과를 조사할 수 있는가?고객 조직의 로그·키·권한으로 제한
사고가 나면 무엇을 증명할 것인가?입력 해시, 정책 버전, 도구 호출, 승인 기록

특히 에이전트는 “한 번의 API 요청”으로 끝나지 않습니다. 메모리, 도구 결과, 재시도 기록, 사람 승인까지 연결됩니다. ZDR을 선택했다고 해서 애플리케이션 내부의 로그가 자동으로 안전해지는 것은 아닙니다. 개발자가 별도로 다음을 설계해야 합니다.

  • 원문 로그와 운영 지표를 분리한다.
  • 민감한 필드는 저장 전에 마스킹하거나 토큰화한다.
  • 세션·작업 ID로 흐름을 추적하되 실제 개인정보와 직접 연결하지 않는다.
  • 오래 보관할 감사 이벤트와 즉시 폐기할 콘텐츠를 구분한다.
  • 모델 제공자의 보존 정책과 사내 로그 보존 정책을 한 표에서 관리한다.

한국의 규제 신속 확인 서비스가 중요한 이유

한국의 8월 24일 발표는 새로운 모델이나 GPU가 아니라, 규제를 확인하는 과정 자체에 생성형 AI를 넣는 시도입니다. 과기정통부는 ICT 규제샌드박스와 관련해 기업이 적용 가능한 규제를 더 빠르고 간편하게 확인할 수 있도록 서비스를 제공한다고 밝혔습니다.

이 서비스가 모든 법률 판단을 자동으로 대신한다는 의미는 아닙니다. 규제 문서와 적용 조건을 찾는 시간을 줄이고, 기업이 어떤 질문을 해야 하는지 구조화하는 보조 계층에 가깝습니다. 최종 판단과 책임은 여전히 담당 기관과 기업에 남습니다.

이 지점은 엔터프라이즈 AI의 전형적인 패턴이기도 합니다.

1 2 3 4 5 6 7 AI가 규정·문서·사례를 검색 ↓ 적용 가능성이 높은 조건을 요약 ↓ 담당자가 근거와 예외를 검토 ↓ 공식 절차·승인·기록으로 확정

AI가 규정을 “결정”하는 것이 아니라, 사람이 결정하기 위해 필요한 근거를 더 빨리 모으는 구조입니다. 이 구조를 지키지 않으면 규제 검색 서비스도 그럴듯하지만 책임질 수 없는 답변 생성기로 전락할 수 있습니다.

두 뉴스가 개발자에게 주는 공통 메시지

OpenAI의 ZDR과 한국의 규제 신속 확인 서비스는 서로 다른 제품이지만, 다음 세 가지 원칙을 공유합니다.

1. AI의 출력보다 데이터 사용 경로를 설명해야 한다

“정확도가 90%입니다”보다 “어떤 문서를 읽었고, 어떤 데이터를 저장하지 않았으며, 어떤 사람이 승인했는가”가 엔터프라이즈 도입에 더 중요해집니다. AI 기능의 설명 가능성은 모델의 추론을 전부 공개하는 일이 아니라 데이터와 행동의 경로를 추적 가능하게 만드는 일입니다.

2. 안전성은 모델의 부가 기능이 아니라 실행 아키텍처다

프롬프트 필터 하나로 끝나지 않습니다. 세션 연결, 도구 권한, 재시도, 외부 행동, 감사 로그를 함께 검사해야 합니다. 한국 과기정통부와 Anthropic도 AI 안전·보안 협력에서 모델과 자율 에이전트의 레드팀 평가를 별도 과제로 다루고 있습니다. 과기정통부·Anthropic 협력 발표

3. 통제권을 고객에게 넘기는 제품이 선택받는다

고객이 자신의 데이터·암호 키·로그·경고를 통제하고, 필요할 때만 제공자와 정보를 공유할 수 있어야 합니다. 이것은 보안팀만의 요구가 아니라, AI를 실제 업무와 민감한 데이터에 연결하기 위한 제품 조건입니다.

AI 서비스를 만들 때 확인할 8가지

  1. 모델 제공자의 데이터 보존·학습·검토 정책을 계약 단위로 확인했는가?
  2. ZDR이 적용되는 API·모델·기능 범위를 구분했는가?
  3. 에이전트의 여러 호출을 연결할 때 세션 식별자에 개인정보가 들어가지 않는가?
  4. 원문 콘텐츠, 임베딩, 캐시, 추적 로그의 보존 기간을 각각 정했는가?
  5. 모델이 호출할 수 있는 도구와 읽을 수 있는 데이터가 최소 권한으로 제한됐는가?
  6. 안전 경고가 발생했을 때 고객 조직이 자체 시스템에서 조사할 수 있는가?
  7. 자동화된 안전 판정의 오탐·누락을 사람이 이의 제기할 경로가 있는가?
  8. 규제·정책 문서가 바뀔 때 어떤 버전의 근거로 판단했는지 재현할 수 있는가?

결론: 다음 AI 경쟁은 ‘더 많이 아는 모델’이 아니라 ‘덜 노출하고 더 잘 증명하는 시스템’이다

OpenAI의 Private Safety Processing은 아직 미리보기 단계지만, 방향은 분명합니다. AI가 더 긴 작업을 수행할수록 안전 시스템도 여러 상호작용을 살펴야 합니다. 동시에 기업은 민감한 콘텐츠를 외부 제공자에게 장기간 맡기고 싶어 하지 않습니다.

한국의 규제 신속 확인 서비스도 같은 문제를 다른 층위에서 다룹니다. AI는 규제와 문서를 빠르게 탐색할 수 있지만, 최종 책임과 승인 경계는 시스템 밖으로 사라지지 않습니다.

앞으로의 AI 제품은 다음 세 가지를 동시에 만족해야 합니다.

1 2 3 필요한 데이터만 사용한다 위험한 행동은 멈추고 승인받는다 무엇을 했는지 나중에 증명할 수 있다

AI를 도입하는 개발자라면 모델 선택표보다 먼저 데이터 흐름과 권한 흐름을 그려보는 것이 좋습니다. 그 그림에 저장 위치, 암호 키, 안전 신호, 사람 승인, 감사 로그가 없다면 아직 엔터프라이즈 AI의 설계는 시작 단계에 머물러 있는 셈입니다.

출처

Hello world

댓글을 작성하려면로그인이 필요합니다.