8강에서 AI가 작성한 답변을 그대로 외부로 보내는 위험을 다뤘다면, 보안은 그보다 한 단계 앞에 있는 문제입니다. 자동화 흐름은 여러 도구와 계정을 연결합니다. n8n, Make, Zapier, Google Apps Script, ChatGPT·Claude·Gemini 같은 서비스가 서로 데이터를 주고받는 구조가 되기 때문에, 한 번 잘못 연결하면 사람이 수동으로 처리할 때보다 더 빠르고 넓게 문제가 퍼질 수 있습니다.

자동화는 편리하지만, 권한과 데이터가 함께 이동합니다. 그래서 “잘 작동하는가”만큼 “어떤 정보가 어디로 넘어가는가”를 반드시 확인해야 합니다.

1. 자동화에서 자주 다루는 민감 정보

AI 자동화에서 민감 정보는 생각보다 자주 등장합니다. 고객 문의를 요약하는 흐름만 만들어도 이름, 이메일, 전화번호, 주문번호, 주소, 상담 내용이 포함될 수 있습니다. 내부 보고서를 자동 요약할 때는 매출, 계약 조건, 인사 정보, 프로젝트 일정, 미공개 전략 문서가 들어갈 수 있습니다.

특히 아래 정보는 자동화 흐름에서 별도 관리가 필요합니다.

- API Key, Access Token, Webhook URL

- 고객 이름, 이메일, 전화번호, 주소

- 주문 내역, 결제 내역, 환불 정보

- 계약서, 견적서, 세금계산서, 인보이스

- 내부 문서, 회의록, 사업 전략 자료

- 직원 정보, 급여 정보, 평가 자료

- 계정 ID, 비밀번호, 인증 코드

- 카드번호, 계좌번호 등 결제 관련 정보

민감 정보의 기준을 너무 좁게 잡으면 위험합니다. “이름만 있으니 괜찮다”가 아니라, 다른 정보와 결합했을 때 개인을 식별할 수 있는지도 봐야 합니다. 예를 들어 이름, 회사명, 문의 내용이 함께 있으면 단순 텍스트가 아니라 고객 상담 기록이 됩니다.

2. API Key를 코드나 공개 문서에 넣으면 안 되는 이유

API Key는 서비스에 접속할 수 있는 열쇠입니다. ChatGPT API, Google API, Slack API, Notion API, 결제 서비스 API를 연결할 때 발급받는 키나 토큰이 여기에 해당합니다.

문제는 API Key가 노출되면, 누군가가 해당 계정 권한으로 요청을 보낼 수 있다는 점입니다. 비용이 발생하는 API라면 과금 피해가 생길 수 있고, 데이터 조회 권한이 있다면 내부 정보가 유출될 수 있습니다. 메시지 발송 권한이 있다면 고객에게 잘못된 알림이 대량 발송될 수도 있습니다.

특히 피해야 할 방식은 다음과 같습니다.

- Google Docs, Notion, 공개 위키에 API Key를 그대로 적어두기

- GitHub 공개 저장소에 키가 포함된 코드 업로드

- 스프레드시트 셀에 토큰을 평문으로 저장

- 팀 채팅방에 API Key를 그대로 공유

- 화면 캡처 이미지에 키가 보이는 상태로 업로드

- 테스트용 키라고 생각하고 계속 운영에 사용

n8n, Make, Zapier는 보통 각 서비스 연결 정보를 별도 커넥션 또는 Credential 형태로 저장합니다. 이런 기능을 쓰는 이유가 있습니다. 자동화 흐름 안에 키를 직접 적어두면 복사, 공유, 내보내기, 캡처 과정에서 쉽게 노출됩니다.

Google Apps Script를 사용할 때도 스크립트 안에 키를 그대로 넣는 방식은 피하는 편이 안전합니다. Apps Script에는 Script Properties 같은 저장 방식을 사용할 수 있지만, 이 역시 접근 권한을 가진 사람이 누구인지 함께 관리해야 합니다.

3. 고객 개인정보 자동 처리 시 주의할 점

고객 정보를 자동으로 처리할 때는 “필요한 정보만 가져오는가”가 첫 기준입니다. 문의 분류에 고객 주소가 필요 없다면 주소를 AI에게 보낼 이유가 없습니다. 환불 가능 여부를 확인하는 자동화라면 주문번호와 상태값은 필요할 수 있지만, 전체 상담 이력이나 결제 세부정보까지 매번 보낼 필요는 없습니다.

자동화 흐름을 만들 때는 입력 데이터를 줄이는 습관이 중요합니다.

예를 들어 고객 문의를 AI로 분류하는 경우, 아래처럼 구분해볼 수 있습니다.

- 필요한 데이터: 문의 제목, 문의 본문, 접수 채널, 접수 시간

- 상황에 따라 필요한 데이터: 주문번호, 상품명, 고객 등급

- 가능하면 제외할 데이터: 전화번호, 주소, 결제수단, 주민등록번호 등 고유식별정보

또 하나 중요한 점은 저장 기간입니다. 자동화 도구는 실행 기록을 남깁니다. n8n의 execution log, Make의 scenario history, Zapier의 task history, Apps Script의 실행 로그 등에는 입력값과 출력값이 남을 수 있습니다. 여기에 개인정보가 그대로 들어가면, 원래 시스템보다 더 많은 장소에 개인정보가 복제되는 결과가 됩니다.

고객 정보가 포함된 자동화는 다음 질문을 통과해야 합니다.

- 이 정보가 자동화 목적에 꼭 필요한가

- AI에게 보내지 않고도 처리할 수 있는가

- 일부만 가리거나 요약해서 보낼 수 있는가

- 실행 로그에 남아도 되는 정보인가

- 접근 가능한 팀원이 최소화되어 있는가

- 삭제 요청이 들어왔을 때 어디에서 지워야 하는지 파악 가능한가

4. 외부 AI 서비스에 보내면 안 되는 데이터

ChatGPT, Claude, Gemini 같은 외부 AI 서비스는 문장 이해와 요약, 분류, 초안 작성에 유용합니다. 하지만 모든 데이터를 그대로 보내도 된다는 뜻은 아닙니다.

외부 AI 서비스에 보내기 전에는 데이터 성격을 먼저 나눠야 합니다. 공개되어도 큰 문제가 없는 데이터인지, 내부용 데이터인지, 고객 개인정보인지, 법적·계약상 보호가 필요한 데이터인지 구분해야 합니다.

대체로 아래 데이터는 외부 AI 서비스에 그대로 보내지 않는 쪽이 안전합니다.

- 주민등록번호, 여권번호, 운전면허번호 등 고유식별정보

- 카드번호, 계좌번호, 결제 인증 정보

- 비밀번호, 인증 코드, 복구 코드

- API Key, Access Token, Secret Key

- 비공개 계약서 원문

- 미공개 재무 자료, 투자 자료, 인수합병 관련 자료

- 고객 상담 전문 중 민감한 개인정보가 포함된 내용

- 의료, 법률, 노무 등 민감도가 높은 상담 원문

- 회사 내부 보안 정책, 시스템 구조, 취약점 정보

실무에서는 “원문 전체를 보내는 방식”보다 “필요한 부분만 추출해서 보내는 방식”이 안전합니다. 예를 들어 고객 문의를 분류하려면 전화번호와 주소를 제거하고, 문의 내용만 보내는 구조로 바꿀 수 있습니다. 주문 관련 판단이 필요하다면 주문번호 자체보다 “배송 완료”, “결제 완료”, “환불 요청” 같은 상태값만 보내는 방식도 가능합니다.

AI에게 보내기 전 익명화 또는 마스킹을 거치는 것도 좋은 방법입니다. 다만 완전한 익명화는 생각보다 어렵습니다. 이름을 지워도 회사명, 직책, 사건 내용이 조합되면 특정인을 추정할 수 있습니다. 그래서 “마스킹했으니 무조건 안전하다”가 아니라, 재식별 가능성까지 확인해야 합니다.

5. 권한을 최소화해야 하는 이유

자동화 계정에는 필요한 권한만 부여해야 합니다. 이것을 최소 권한 원칙이라고 부릅니다. 자동화가 스프레드시트 한 개만 읽으면 되는데 Google Drive 전체 접근 권한을 주는 것은 위험합니다. 특정 Slack 채널에 알림만 보내면 되는데 워크스페이스 전체 메시지를 읽을 수 있게 하는 것도 과합니다.

권한을 넓게 주면 처음에는 편합니다. 설정 오류가 줄고, 연결도 빨리 됩니다. 하지만 문제가 생겼을 때 피해 범위가 커집니다. 자동화 시나리오 하나가 잘못되었을 뿐인데 모든 문서에 접근하거나, 모든 고객 데이터를 수정할 수 있다면 운영 리스크가 지나치게 커집니다.

도구별로 표현은 다르지만 확인할 기준은 비슷합니다.

- 읽기 권한만 필요한가, 쓰기 권한도 필요한가

- 특정 폴더만 접근하면 되는가, 전체 드라이브 접근이 필요한가

- 특정 채널만 쓰면 되는가, 전체 워크스페이스 권한이 필요한가

- 고객 데이터 조회만 필요한가, 수정·삭제 권한도 필요한가

- 관리자 권한이 꼭 필요한가, 일반 사용자 권한으로 가능한가

API Key를 만들 때도 마찬가지입니다. 가능하다면 읽기 전용 키, 특정 리소스 전용 키, 제한된 범위의 토큰을 사용하는 편이 좋습니다. 서비스에 따라 세부 권한 설정을 지원하지 않는 경우도 있지만, 지원한다면 처음부터 좁게 잡는 것이 안전합니다.

6. 자동화 계정과 개인 계정을 분리하는 방법

입문 단계에서 자주 나오는 실수가 개인 계정으로 모든 자동화를 연결하는 것입니다. 개인 Gmail, 개인 Slack 계정, 개인 Notion 권한, 개인 Google Drive 권한을 그대로 자동화에 연결하면 처음에는 빠르게 만들 수 있습니다. 하지만 운영 단계로 넘어가면 문제가 생깁니다.

개인 계정에 의존하면 담당자가 퇴사하거나 역할이 바뀌었을 때 자동화가 멈출 수 있습니다. 비밀번호 변경, 2단계 인증 재설정, 계정 잠금, 권한 회수 같은 상황에서도 흐름이 끊깁니다. 더 큰 문제는 책임과 기록이 불분명해진다는 점입니다. 자동화가 보낸 메시지인지, 개인이 직접 보낸 메시지인지 구분하기 어려워질 수 있습니다.

가능하면 자동화 전용 계정을 따로 두는 편이 좋습니다.

예시는 다음과 같습니다.

- automation@회사도메인

- bot@회사도메인

- ops-automation@회사도메인

- no-reply@회사도메인

이 계정은 개인 업무용으로 쓰지 않고, 자동화 연결과 시스템 알림에만 사용합니다. 접근 권한은 필요한 담당자에게만 부여하고, 비밀번호와 2단계 인증 관리 방식도 조직 기준에 맞춰야 합니다.

Google Workspace, Slack, Notion, Airtable, CRM, 고객지원 도구 등을 연결할 때는 개인 계정이 아니라 자동화 전용 계정 또는 서비스 계정 개념을 우선 검토하는 것이 좋습니다. 단, 서비스마다 계정 정책과 요금 정책이 다르므로 조직의 이용 약관과 보안 정책에 맞는지 확인해야 합니다.

7. 보안 검수 없이 자동화를 운영하면 생기는 문제

자동화는 한 번 만들어두면 계속 실행됩니다. 그래서 작은 실수도 반복됩니다. 사람이 한 번 잘못 보낸 이메일은 한 건으로 끝날 수 있지만, 자동화 흐름이 잘못되면 수십 건, 수백 건이 같은 방식으로 처리될 수 있습니다.

보안 검수 없이 운영할 때 자주 생기는 문제는 다음과 같습니다.

- 고객 개인정보가 외부 AI 서비스로 불필요하게 전송됨

- API Key가 문서나 로그에 남아 외부에 노출됨

- 테스트용 자동화가 실제 고객에게 메시지를 발송함

- 개인 계정 권한으로 내부 문서 전체를 읽는 흐름이 만들어짐

- 실행 로그에 민감 정보가 장기간 보관됨

- 퇴사자 계정과 연결된 자동화가 계속 작동하거나 갑자기 중단됨

- 권한이 과도한 토큰이 유출되어 피해 범위가 커짐

- 고객 삭제 요청이 들어왔을 때 복제된 데이터 위치를 찾지 못함

운영 전에는 최소한의 점검표를 두는 것이 좋습니다. 복잡한 보안 문서를 처음부터 만들 필요는 없지만, 자동화마다 아래 항목은 확인해야 합니다.

- 이 자동화가 다루는 민감 정보는 무엇인가

- 외부 서비스로 전송되는 데이터는 무엇인가

- AI에게 보내는 원문에 개인정보가 포함되어 있는가

- API Key와 토큰은 어디에 저장되어 있는가

- 실행 로그에는 어떤 값이 남는가

- 자동화 계정은 개인 계정과 분리되어 있는가

- 권한은 필요한 범위로 제한되어 있는가

- 오류 발생 시 누가 확인하고 중지할 수 있는가

- 테스트 환경과 실제 운영 환경이 구분되어 있는가

AI 자동화의 보안은 거창한 기술 문제만은 아닙니다. 대부분의 사고는 “편해서”, “임시로”, “나중에 바꾸려고” 만든 설정에서 시작됩니다. 입문 단계일수록 처음부터 단순한 원칙을 지키는 편이 장기적으로 안전합니다.

API Key는 공개된 곳에 두지 않고, 고객 정보는 필요한 만큼만 쓰고, 외부 AI에는 민감한 원문을 그대로 보내지 않으며, 권한은 최소화하고, 자동화 계정은 개인 계정과 분리합니다. 이 기준만 지켜도 많은 위험을 줄일 수 있습니다.

자동화의 목표는 업무를 빠르게 만드는 데 있지만, 빠르기만 한 자동화는 운영에 적합하지 않습니다. 민감한 데이터를 다루는 흐름이라면 “작동 여부”와 함께 “노출 가능성”, “권한 범위”, “로그 보관”, “중지 방법”까지 같이 확인해야 합니다. 보안은 자동화를 다 만든 뒤 붙이는 부가 기능이 아니라, 흐름을 설계할 때 함께 넣어야 하는 기본 조건입니다.