보고서에서 이름과 금액을 가린 뒤 외부 AI에 붙여 넣으면 안전해졌다고 느끼기 쉽습니다. 그러나 가린 작업이 입력 뒤에 이뤄졌다면, 원본 자료는 이미 조직 밖의 도구로 전달됐을 수 있습니다. 결과물에서 정보를 제거하는 일과 자료의 외부 반출을 막는 일은 다른 통제입니다.
CTO와 개발 리드가 요구사항 단계에서 먼저 정할 질문은 “이 문서가 민감한가”만이 아닙니다. 이 자료가 외부 AI 도구에 들어가는 순간부터 어떤 경로를 거치고, 무엇이 어디에 남는가를 함께 확인해야 합니다.
외부 반출이 허용되지 않는 업무라면 인터넷 연결 없이 동작하는 도구나 내부 환경에서 처리하는 방식을 검토할 수 있습니다. 다만 이 선택은 보안 문제 하나를 해결하는 대신, 외부 서비스가 제공하던 갱신과 운영 부담 일부를 조직이 맡게 할 수 있습니다. 보안 경계를 지키는 비용도 요구사항에 들어가야 하는 이유입니다.
실패는 자료를 지운 뒤가 아니라 넣기 전 판단에서 갈린다
외부 AI 사용 기준을 파일 형식이나 개인정보 유무만으로 정하면 경계가 흔들립니다. 같은 PDF라도 공개된 제품 안내문일 수 있고, 계약 조건·내부 운영 정보·고객 식별 정보가 섞인 문서일 수도 있습니다. 이름이 없더라도 공개 전 사업 계획, 내부 시스템 구성, 특정 거래 관계를 드러내는 정보처럼 외부 반출을 제한해야 할 내용이 있을 수 있습니다.
따라서 자료를 “민감하다” 또는 “민감하지 않다”로만 나누기보다, 업무 목적과 반출 가능 범위를 함께 정하는 편이 낫습니다. 요구사항 문서에는 다음처럼 세 범주를 둘 수 있습니다.
- 외부 입력 허용 자료: 이미 공개됐거나 조직의 규정상 외부 처리 범위가 분명한 자료
- 조건부 입력 자료: 필요한 항목만 추출하거나 식별 정보를 제거한 뒤, 업무 목적을 유지할 수 있는 자료
- 외부 입력 금지 자료: 원본 반출이 제한되거나, 일부 항목을 지워도 문맥상 대상이나 업무 내용이 추정될 가능성이 큰 자료
이 분류에서 중요한 것은 “나중에 지우겠다”는 계획이 아닙니다. 먼저 원본이 외부로 나가는지 판단하고, 허용하지 않는다면 입력 이전에 자료를 제외하거나 필요한 정보만 별도로 구성해야 합니다.
업무 책임자는 어떤 정보가 빠져도 업무 목적이 유지되는지 판단하고, 개발 책임자는 필요한 정보만 입력하도록 화면과 흐름을 설계하며, 보안·법무 담당자는 조직 규정과 계약 조건을 확인할 수 있습니다. 누가 어느 결정을 맡는지 정하지 않으면, 현장에서는 사용자가 매번 혼자 선을 그어야 합니다.
도구의 안전성과 자료 반출 가능성은 별개로 확인한다
“이 자료를 넣어도 되는가”와 “이 도구가 자료를 어떻게 다루는가”는 같은 질문이 아닙니다.
전자는 조직이 정해야 할 반출 기준입니다. 후자는 선택하려는 도구의 처리 조건을 확인하는 일입니다. 자료가 비교적 덜 민감해도 도구의 보존·삭제·관리 조건이 맞지 않을 수 있고, 반대로 도구 설정이 적절해 보여도 조직 규정상 외부 반출 자체가 허용되지 않을 수 있습니다.
외부 AI 도구를 검토할 때는 기능 시연보다 먼저 자료의 흐름을 끊어서 확인해야 합니다.
-
입력과 전송
사용자가 붙여 넣는 텍스트, 업로드하는 파일, 생성 결과에 포함되는 내용 가운데 무엇이 외부 서비스로 전달되는지 확인합니다. 업무자는 화면에 보이는 입력란만 보는 경향이 있지만, 요구사항에는 어떤 자료를 입력 대상으로 삼는지부터 적어야 합니다. -
처리와 접근
전달된 자료를 누가 어떤 권한으로 다룰 수 있는지, 조직 관리자가 사용 범위와 계정을 관리할 수 있는지 확인합니다. 이 단계는 제품의 일반 설명이 아니라, 도입하려는 환경과 계약 조건에서 확인해야 합니다. -
저장과 보존
대화 기록, 업로드 파일, 프롬프트, 생성 결과가 보존 대상인지와 사용자가 삭제할 수 있는 범위를 구분해 봐야 합니다. 사용자가 화면에서 대화를 지웠다는 사실만으로 모든 처리 흔적의 상태를 판단하기는 어렵습니다. -
학습 또는 개선 목적 사용
입력 자료나 대화 내용이 모델 개선, 품질 확인, 안전성 검토 등에 쓰일 수 있는지 확인합니다. 이 항목은 “학습에 쓰지 않는다”는 문구 하나를 확인하는 데서 끝내기보다, 조직이 선택한 설정과 계약 조건이 무엇인지 기록할 필요가 있습니다. -
삭제와 종료
프로젝트가 끝났을 때 무엇을 누가 삭제할 수 있는지 정합니다. 업무자가 만든 중간 파일, 조직이 보관해야 하는 결과물, 외부 도구 안에 남을 수 있는 대화·파일을 구분하지 않으면 종료 시점의 책임도 흐려집니다.
이 다섯 단계에 답하지 못하는 상태라면, 도구의 기능이 좋아도 사용 범위를 확정하기 어렵습니다. NIST의 생성형 AI 위험관리 프로필도 조직의 요구사항, 위험 허용 수준, 보유 자원과 우선순위에 맞춰 위험관리 방식을 정해야 한다고 설명합니다. 모든 조직에 같은 허용 목록이나 같은 배포 방식이 맞는 것은 아닙니다.
조기 신호는 설정을 모르는 상태와 설명할 수 없는 예외다
보안 실패는 거대한 기술 결함에서만 시작되지 않습니다. 요구사항 단계에서 놓친 항목은 대개 사용 중의 애매한 질문으로 먼저 드러납니다.
예를 들어 다음 상태는 외부 AI 사용 범위를 다시 점검할 신호가 될 수 있습니다.
- 자료를 넣어도 되는 이유를 “이름을 가렸기 때문”이라고만 설명한다.
- 입력 자료의 범위는 정했지만, 해당 도구의 데이터 처리 설정은 확인하지 않았다.
- 업무 목적에 필요한 최소 정보가 무엇인지 합의되지 않았다.
- 작업이 끝난 뒤 삭제할 파일과 보존할 결과물을 구분하지 않았다.
- 외부 도구를 쓸 수 없는 업무에서 수작업 부담이 커졌지만, 내부 대안의 운영 책임자는 정하지 않았다.
- 자동화 결과가 잘못됐을 때 누가 확인하고 고칠지 정해지지 않았다.
이 신호는 특정 사용자가 주의를 덜 기울였다는 뜻으로만 볼 일이 아닙니다. 대개는 자료 범위, 도구 설정, 종료 절차, 예외 처리 기준이 하나의 요구사항으로 연결되지 않았다는 뜻에 가깝습니다.
특히 “조건부 입력 자료”는 설명 가능한 경계가 있어야 합니다. 어떤 항목을 빼고, 어떤 정보만 남기며, 왜 그 정도면 업무 목적을 달성할 수 있는지를 팀이 말로 설명할 수 없다면 외부 입력을 보류하는 편이 안전합니다.
오프라인 구현의 실패는 개발보다 유지에서 나타난다
외부 반출이 불가능한 자료를 처리해야 한다면, 인터넷 없이 동작하는 도구나 내부 환경에서 처리하는 방식을 검토할 수 있습니다. 이때 흔한 오해는 오프라인 도구를 만들면 보안 요구와 업무 효율을 모두 해결한다는 생각입니다.
한 비연결 환경의 문서 검사 사례에서는 맞춤법과 띄어쓰기 검사를 위해 별도 사전과 규칙을 관리해야 했습니다. 초기에는 오류를 찾아내는 데 성공했지만, 업무 문서에 반복 등장하는 시스템명과 표현이 오류로 잡히고, 이를 되돌리고 사전을 수정하는 일이 늘었습니다. 도구 자체의 처리 실패보다, 외부 서비스가 대신 제공하던 갱신 부담을 내부에서 계속 떠안게 된 점이 사용 중단의 이유가 됐습니다.
여기서 얻을 수 있는 판단은 명확합니다. 오프라인 구현은 개발 완료 시점의 기능만 비교해서는 안 됩니다. 다음 책임을 누가 맡을지 요구사항에 넣어야 합니다.
- 규칙과 사전을 누가 수정하고 갱신하는가
- 새 문서 양식이나 새 업무 용어가 들어올 때 무엇을 다시 시험하는가
- 오탐과 누락을 누가 접수하고 수정 우선순위를 정하는가
- 자동 수정이 틀렸을 때 사용자가 검토하고 되돌릴 수 있는가
- 도구가 사용되지 않더라도 유지해야 하는 최소 관리 업무는 무엇인가
오프라인 도구가 검토할 가치가 큰 경우는 외부 반출이 제한된 자료를 반복 처리하고, 업무 규칙이 비교적 명확하며, 사람이 결과를 검토할 수 있을 때입니다. 반대로 문서 표현과 업무 규칙이 자주 바뀌고, 사전·규칙을 관리할 담당자를 확보하기 어렵다면 범위를 좁힌 보조 도구부터 검토하는 편이 현실적일 수 있습니다.
여기서 “오프라인”은 특정 생성형 AI 모델을 내부에 설치한다는 뜻으로 한정되지 않습니다. 정해진 항목 비교, 규칙 검사, 누락 탐지처럼 업무 범위가 좁다면 규칙 기반 처리나 기존 내부 시스템의 조합이 더 맞을 수 있습니다. 구현 방식은 유행하는 기술 이름보다 처리 대상과 유지 책임을 기준으로 골라야 합니다.
요구사항 회의에서 제품 비교보다 먼저 정할 항목
외부 AI 도입 논의가 모델 성능이나 제품 기능 비교로 시작되면, 정작 중요한 반출 기준과 운영 책임이 뒤로 밀릴 수 있습니다. 다음 질문은 제품 선정 이전에 문서로 남길 만합니다.
- 이 업무에서 외부로 나가면 안 되는 정보는 무엇이며, 최종 판단자는 누구인가?
- 원본 전체가 필요한가, 아니면 필요한 항목만 추출해도 목적을 달성할 수 있는가?
- 입력 자료, 대화 기록, 업로드 파일, 생성 결과는 각각 어떻게 다룰 것인가?
- 데이터 사용 설정과 보존·삭제 조건은 누가 확인하고 변경 이력을 관리하는가?
- 외부 반출이 불가능할 때 수작업을 유지할지, 내부 도구를 만들지 어떤 기준으로 결정할 것인가?
- 내부 도구를 만든다면 사전, 규칙, 문서 양식 변화와 오류 수정은 누가 맡는가?
- 자동화 결과가 틀렸을 때 업무 담당자가 확인하고 되돌릴 수 있는가?
다음 회의에서는 후보 도구의 기능표보다 먼저 실제 업무 자료 하나를 놓고 이동 경로를 그려보는 편이 좋습니다. 누가 입력하는지, 어떤 정보가 전달되는지, 무엇을 남기고 무엇을 지우는지, 외부로 보낼 수 없다면 어떤 관리 부담을 내부가 맡는지를 적어보십시오. 그 경로가 정리돼야 외부 AI의 허용 범위와 오프라인 구현의 투자 가치가 함께 보입니다.
