사내 AI 도입, 보안 검토서는 뭘 검증해야 하나?
보안 검토는 "암호화됩니다", "학습에 안 씁니다" 같은 문구를 그대로 승인 사유로 옮겨 적는 작업이 아니다. 플랜·모델·엔드포인트별로 보관 기간, 학습 사용 여부, 삭제 소요 시간, 감사 로그 범위를 직접 확인하고 숫자로 남기는 작업이다. 2026년 기준으로 같은 사업자라도 API와 웹 서비스, 개인 요금제와 기업 요금제, 모델에 따라 조건이 갈리기 때문에 "한 번 확인하고 끝"이 되지 않는다.
핵심 정리
- OpenAI API는 기본적으로 모델 학습에 입력을 쓰지 않지만, 악용 모니터링 로그는 최대 30일 보관된다 OpenAI.
- GitHub Copilot은 Business·Enterprise 고객 데이터를 학습에 쓰지 않지만, Free·Pro 등 개인 요금제는 설정에 따라 학습에 쓰일 수 있어 사내 테스트에 개인 계정을 섞으면 안 된다 GitHub.
- Copilot에서 Anthropic 모델을 쓰면 안전성 분류기 운영을 위해 보관 조건이 달라지므로 "Copilot은 무보관"이라고 통째로 쓰면 틀린다.
- 인증(SOC 2, ISO 27001 등) 보유는 출발점이지 종료점이 아니며, DPA의 하위처리자·사고 통지·삭제 조항을 따로 봐야 한다 OpenAI.
- 선언문 대신 거부율·오탐률·삭제 소요시간·비용을 100건 단위로 실측해서 문서에 남기는 쪽이 재현 가능하다.
이번 실험에서 검증하려 한 것은 단순했다. "공식 문서에 적힌 보관·학습 조건이 실제 파일럿 운영 조건과 일치하는가", 그리고 "그 조건을 승인 문서에 재현 가능한 형태로 옮길 수 있는가"였다. 검증 대상은 OpenAI API 기반 내부 도구 하나, GitHub Copilot Business 하나로 좁혔다.
파일럿 범위는 어떻게 정했나?
데이터 경계부터 정했다. 소스코드, API 키, 고객정보, 내부 설계문서는 프롬프트에 넣지 않는 조건으로 시작했고, 공개 저장소 3개와 합성 코드만 입력 대상으로 썼다. 이 원칙은 이후 민감도 등급을 올릴 때마다 "제품별 보관·학습·하위처리자 조건이 확인된 단계까지만" 넘어가는 식으로 운영했다.
구체적으로는 Copilot Business에서 공개 테스트 저장소 3개를 대상으로 자동완성 100건, 채팅 50건을 실행했다. 이와 별도로 비밀정보(더미 API 키 패턴) 포함 프롬프트 10건, 내부 코드처럼 보이는 합성 프롬프트 10건을 넣어 차단 여부를 확인했다. 입력 조건·건수·성공 기준을 미리 문서에 적어두니, 나중에 결과를 다른 팀원이 재현할 수 있었다는 점이 실무적으로 제일 쓸모 있었다.
실제로 어떤 조건을 확인했나?
공식 문서 기준으로는 OpenAI API가 2023년 3월 1일 이후 전송 데이터를 학습에 쓰지 않지만 모니터링 로그는 최대 30일 보관되고, 적격 고객은 Zero Data Retention을 신청할 수 있되 모든 엔드포인트에 동일 적용되지 않는다 OpenAI. 이번 내부 도구는 Zero Data Retention 신청 전이었기 때문에, 문서에는 "ZDR 미적용, 모니터링 로그 최대 30일"이라고 그대로 적었다.
Copilot 쪽은 Business 플랜이므로 학습 미사용 조건은 충족했지만, 사용 모델을 고정하지 않은 상태라 "Anthropic 계열 모델 선택 시 보관 조건 재확인 필요"라는 각주를 달았다. 관리자 콘솔에서는 조직 단위 정책, 텔레메트리, 라이선스 관리 API가 제공돼 누가 어떤 IDE·모델로 접근했는지는 추적할 수 있었다 GitHub. 다만 감사 로그 보관 기간은 조직 설정값이라 "기본값 그대로 두면 안 된다"는 걸 이번에 처음 알았다.
100건 테스트에서 무엇이 걸렸나?
결과만 말하면, 비밀정보 패턴 10건 중 완성을 멈춘 사례가 전부는 아니었고 내부 코드처럼 보이는 합성 프롬프트 10건 중 일부는 자동완성이 그대로 진행됐다. 이건 우리 테스트 환경에 한정된 관측치이고, Copilot의 일반 차단율을 대표하지 않는다. 그래도 "DLP·비밀정보 탐지는 켜져 있다고 믿지 말고 직접 찔러봐야 한다"는 결론은 분명했다.
응답 시간은 자동완성 100건 평균 체감상 1~2초대였고, 채팅 50건 중 명백한 오답(존재하지 않는 API를 생성 코드에 포함)은 소수 있었다. 비용 쪽은 Copilot Business 라이선스 월 비용과 별개로, OpenAI API 쪽 사용량 과금이 토큰 단위로 붙어서 파일럿 2주 동안의 청구서를 따로 캡처해 문서에 첨부했다. 숫자를 정확히 공개하기보다, "청구서를 캡처해서 보안 검토 문서에 같이 붙여라"는 절차 자체가 다음 검토 때 비교 기준이 됐다는 점이 더 중요했다.
계약서까지 확인해야 승인이 끝나나?
끝나지 않는다. SOC 2 Type 2, ISO/IEC 27001·27017·27018·27701 같은 인증은 OpenAI가 공개적으로 제시하고 있고, ChatGPT Business·Enterprise 및 API 고객과 DPA 체결도 가능하다 OpenAI. 하지만 인증 보유 자체는 "이 사업자가 일반적인 보안 체계를 갖췄다"는 증명이지, 우리 조직의 데이터 처리 조건을 보장하지 않는다. 그래서 DPA의 처리자·하위처리자 목록, 사고 통지 기한, 삭제 요청 처리 절차를 법무·보안 담당자와 따로 읽었다.
암호화도 마찬가지다. 저장 시 AES-256, 전송 시 TLS 1.2 이상이라는 설명은 출발점일 뿐이고 OpenAI, 키 관리 주체가 누구인지, 접근 권한이 어떤 역할에 묶여 있는지, 삭제 요청 후 실제 삭제까지 얼마나 걸리는지는 별도 항목으로 물어야 확인되는 내용이었다. 이번 파일럿에서는 삭제 요청 실측 테스트까지는 진행하지 못했고, 이는 다음 라운드 과제로 남겼다.
이 검토로 어디까지 보장되나?
여기서부터는 한계다. 이번 실험은 OpenAI API와 GitHub Copilot Business, 특정 리전·특정 모델 조합에서 확인한 결과이고, 다른 제품(사내에서 검토 중인 AI 이미지 생성 도구 등)은 업로드 이미지, 얼굴·인물 사진, 제품 설계도의 보관·학습 사용 여부를 별도로 확인해야 한다. 이미지 생성 API와 웹 서비스는 동일 사업자라도 보관·옵트아웃 조건이 다를 수 있어, 이번 코드 중심 검토 결과를 그대로 이미지 도구에 적용하면 안 된다.
또한 공식 문서는 제품 개정이 잦아서, "확인일" 없이 적힌 보안 검토서는 몇 달 뒤엔 근거가 흔들린다. 이번 문서에는 확인일, 제품 플랜, 모델명, IDE/API 방식, 리전, 보관 설정, 참고한 문서 버전을 전부 적었고, "현재 공개 문서 기준"이라는 범위를 명시해 다음 검토자가 재확인할 지점을 남겼다.
다음엔 뭘 다르게 할까?
이번 라운드에서 가장 아쉬웠던 건 삭제 요청 실측을 못 한 것과, 비밀정보 차단 실패 사례를 재현 가능한 로그 형태로 저장하지 못한 점이다. 다음 파일럿에서는 삭제 요청 후 실제 반영 시점을 캘린더에 찍어 기록하고, 차단 실패 10건을 스크린샷이 아니라 API 응답 로그 원문으로 보관할 계획이다. 선언문 기반 보안 검토서보다 시간은 더 들지만, 다음 담당자가 같은 결론을 다시 검증할 수 있다는 점에서 이 번거로움은 아직까진 감수할 만했다.