2023년 4월, 삼성전자 DX부문에서 일이 하나 터졌습니다. 일부 직원이 사내 소스코드와 회의 내용을 챗GPT에 그대로 붙여 넣은 사실이 알려진 것입니다. 회사는 곧바로 사내망과 회사 기기에서 생성형 AI를 쓰지 못하게 막았습니다. 어기면 최대 해고까지 갈 수 있다고 경고했습니다. 그때 회사가 내놓은 설명이, 이 글의 출발점입니다.
생성 AI에 입력된 내용은 외부 서버에 전송·저장된 뒤 AI 학습에 활용되므로 한번 업로드된 내용은 회수, 삭제가 불가능해 회사의 중요 정보가 타인의 질문에 대한 답변으로 활용될 수 있는 등 심각한 보안 위험이 있다.
— 삼성전자 사내 공지 (AI타임스, 2023)
이 대목에서 대부분의 실무자는 둘 중 하나로 갈립니다. 무서우니까 아무것도 안 넣거나, 급하니까 그냥 다 붙여 넣거나. 그런데 정보가 새는 게 겁나서 회사명, 고객명, 수치, 서버 경로를 전부 지우고 나면 이번엔 다른 문제가 생깁니다. 답이 쓸모없어지는 겁니다. AI가 맥락을 잃어버려서 엉뚱한 소리를 하거든요. 그러니까 진짜 어려운 지점은 '지우느냐 마느냐'가 아니라, 기밀은 빼면서도 AI가 답하는 데 필요한 구조는 남기는 것입니다. 그 경계선을 어떻게 긋는지, 지금부터 여섯 단계로 만들어 보겠습니다.
1단계 — 무엇이 '식별 정보'이고 무엇이 '구조'인지 가른다
먼저, 붙여 넣으려는 내용을 두 종류로 갈라 봅니다.
하나는 식별 정보입니다. 이것만 봐도 우리 회사, 고객, 제품이 누군지 딱 짚이는 부분이죠. 회사명, 고객사명, 실명, 사번, 서버 주소, API 키, 실제 매출 수치 같은 것들입니다.
다른 하나는 구조입니다. AI가 문제를 이해하려면 반드시 있어야 하는 뼈대예요. 코드가 어떤 순서로 흘러가는지, 데이터끼리 어떻게 연결되는지, 어떤 조건에서 무슨 판단을 내리는지, 또는 어떤 의사결정의 뼈대가 깔려 있는지 같은 것입니다.
원칙은 딱 하나입니다. 식별 정보는 바꾸고, 구조는 남깁니다. 소스코드로 예를 들어 볼게요. prod-db.aurora.internal이라는 실제 DB 주소는 식별 정보라서 지워야 합니다. 반면에 'DB에 연결한 다음, 결과를 저장해 두지 않고 매번 새로 조회한다'는 흐름은 구조입니다. 이건 남겨 둬야 AI가 버그를 잡아 줍니다.
확인: 지우려는 항목마다 두 가지를 물어보세요. "이걸 남기면 우리 회사가 누군지 드러나나?"에 '예'면 식별 정보입니다. "이걸 지우면 AI가 문제를 못 알아보나?"에 '예'면 구조입니다. 둘 다 '예'인 항목이 가장 골치 아픈데, 그건 4단계에서 따로 다룹니다.
2단계 — 치환 사전을 먼저 만든다
마스킹이 실패하는 이유는 대부분 하나입니다. 그때그때 생각나는 대로 지우기 때문입니다. 같은 고객사를 어떤 줄에선 '고객사'라 쓰고 다른 줄에선 '거래처'라 쓰면, AI는 이 둘을 서로 다른 회사로 착각합니다. 그래서 본문에 손대기 전에 먼저 치환 사전을 따로 적어 둡니다. 어떤 값을 어떤 말로 바꿀지 미리 정해 놓는 표입니다.
| 실제 값 | 치환어 |
|---|---|
| 오로라전자(고객사) | 고객사A |
| prod-db.aurora.internal | DB_HOST |
| 결제 API 키 sk-live-9f2… | API_KEY |
| 김미정 대리 | 담당자1 |
| 매출 240억 | 매출 N |
치환어를 지을 때는 요령이 있습니다. 특정 사람이 아니라 역할을 가리키게 짓는 겁니다. '김미정 대리' 대신 '담당자1'처럼요. 그리고 같은 실제 값은 처음부터 끝까지 똑같은 치환어로 바꿉니다. 이 사전은 나중에 AI가 준 답을 실제 값으로 되돌릴 때 다시 씁니다. 그러니 버리지 말고 손 닿는 곳에 놔두세요.
확인: 사전을 다 만들었으면, 왼쪽 '실제 값' 칸을 손으로 가리고 오른쪽 치환어만 읽어 보세요. 그것만 봐서는 우리 회사가 전혀 떠오르지 않으면, 사전이 제 역할을 한 겁니다.
3단계 — 값은 바꾸고 구조는 그대로 둔다 (코드)
사전이 준비됐으면, 이제 붙여 넣을 내용에 기계적으로 적용하기만 하면 됩니다. 아래는 이해를 돕기 위한 가상의 예입니다.
원본입니다. 이대로 붙여 넣으면 정보가 샙니다.
def calc_yield(wafer_id):
conn = connect("prod-db.aurora.internal", pw="Sx9!kLm")
rows = conn.query(f"select * from aurora_line3 where id={wafer_id}")
return sum(r.ok for r in rows) / len(rows)
치환한 뒤입니다. 안전해졌지만 버그는 고스란히 남아 있습니다.
def calc_yield(item_id):
conn = connect("DB_HOST", pw="DB_PW")
rows = conn.query(f"select * from TABLE_A where id={item_id}")
return sum(r.ok for r in rows) / len(rows)
주소도, 비밀번호도, 테이블 이름도 다 사라졌습니다. 그런데도 rows가 비었을 때 0으로 나눠서 터지는 문제나, f-string으로 SQL을 만들어서 생기는 인젝션 위험 같은 구조적 결함은 그대로 남아 AI가 정확히 짚어 줍니다.
한솔 블로그도 코드를 넣을 때 변수명·경로명·DB명을 바꾸라고 권합니다.
확인: 치환한 코드를 다시 돌려 볼 수는 없습니다. 대신 문제의 '모양'이 원본과 같은지 눈으로 대조하세요. 반복문, 조건 분기, 예외 처리 흐름 말입니다. 모양이 같으면 AI도 같은 진단을 내립니다.
4단계 — 구조 자체가 기밀이면 추상화 레벨을 올린다
1단계에서 물었던 두 질문에 둘 다 '예'가 나온 항목, 기억하시죠. '남겨도 특정되고, 지우면 못 알아보는' 것들입니다. 주로 경영 정보가 여기 걸립니다. 신사업 계획이나 매출 급감 같은 건 치환어로 가려도, 몇 개를 조합하면 어느 회사인지 드러나 버립니다.
이럴 때는 값을 바꾸는 걸로는 부족합니다. 대신 질문의 눈높이 자체를 개념 수준으로 끌어올립니다.
원본입니다. 너무 구체적이라 위험합니다.
우리는 3분기 화장품 매출이 전년 대비 40% 줄어서, 내년에 반려동물 사료 사업에 200억을 투자하려 합니다. 검토할 리스크는?
추상화한 뒤입니다. 같은 판단을 얻으면서도 안전합니다.
성숙기 소비재 기업이 주력 카테고리 매출이 크게 꺾인 상황에서 인접한 신규 카테고리로 진출하려 합니다. 초기 투자를 결정하기 전에 반드시 점검해야 할 리스크를 알려 주세요.
어떤 산업인지, 얼마나 줄었는지, 얼마를 넣는지가 다 사라졌습니다. 그런데 '주력이 꺾였으니 옆 분야로 넘어간다'는 의사결정의 뼈대는 그대로 남았죠. 그래서 돌아오는 답은 우리 상황에 바로 갖다 쓸 수 있습니다. 한솔 블로그가 미공개 경영 정보는 수치를 빼고 방향성이나 개념 수준으로 물으라고 한 것과 같은 방식입니다.
확인: 추상화한 질문을 같은 업계의 다른 회사 사람이 봐도 자연스럽게 쓸 수 있으면 성공입니다. 반대로 '우리 회사에서만 나올 법한 질문'이라는 느낌이 남아 있으면, 아직 덜 지운 겁니다.
5단계 — 답을 받은 뒤 사전으로 되돌린다
마스킹의 마지막 함정은 '적용' 단계에서 터집니다. AI가 DB_HOST, 고객사A 같은 치환어로 답을 줬을 때, 이걸 실무에 반영하려면 2단계 사전을 거꾸로 대입해 실제 값으로 옮겨야 합니다. 이 되돌리기를 건너뛰면 어떻게 될까요. 엉뚱한 곳을 고치거나, 반대로 DB_HOST 같은 치환어가 실제 코드에 그대로 박히는 사고가 납니다.
국정원이 공공기관용으로 낸 가이드라인도 바로 이 지점을 짚습니다.
확인: 되돌린 결과물을 검색해서 _HOST, 고객사A, 담당자1 같은 치환어가 한 글자도 안 남았는지 보세요. 하나라도 남아 있으면 아직 반영이 안 끝난 겁니다.
6단계 — 설정은 백스톱으로 켠다 (마스킹의 대체가 아니라 보완)
여기까지가 유출을 막는 본선입니다. 설정은 그 위에 하나 더 까는 안전망이에요. 실수했을 때를 대비하는 겁니다. 챗GPT에서는 설정 > 데이터 제어 > '모두를 위한 모델 개선' 토글을 끄면 이후 대화가 학습에 쓰이지 않습니다. 한 번만 쓰고 기록조차 남기기 싫다면, 화면 오른쪽 위의 임시 채팅(Temporary Chat)으로 시작하면 됩니다.

다만 분명히 해 둘 게 있습니다. 이건 어디까지나 보완일 뿐입니다. 삼성 사례의 핵심은 '학습에 쓰였다'가 아니라, 애초에 기밀이 외부 서버로 나갔다는 것입니다. 그리고 설정은 그 전송 자체를 막지 못합니다. 설정을 켰다고 안심하고 원본을 그대로 붙여 넣는 순간, 앞의 다섯 단계가 통째로 무의미해집니다.
확인: 임시 채팅에서는 왼쪽 대화 목록에 이 대화가 안 나타납니다. 그리고 데이터 제어 화면의 토글이 꺼짐(회색) 상태여야 합니다. 이 두 가지가 보이면 백스톱이 제대로 걸린 겁니다.
마지막으로 습관 하나만 붙여 두면, 절차 전체가 단단해집니다. 붙여 넣기 버튼을 누르기 바로 직전, 완성된 프롬프트를 경쟁사 직원의 눈으로 한 번 읽어 보는 것입니다. 회사, 고객, 제품, 핵심 수치 중에 하나라도 짚어낼 수 있으면 아직 덜 지운 겁니다. 반대로 아무것도 특정할 수 없는데 질문의 뼈대는 살아 있으면, 그대로 보내도 됩니다. 이 30초가, 회수도 삭제도 안 되는 단 한 번의 붙여 넣기로부터 당신을 지켜 줍니다.
출처 · 참고
참고 문헌
- AI타임스 (2023). 삼성, 챗GPT 데이터 유출 후 임직원 AI 사용 금지. https://www.aitimes.com/news/articleView.html?idxno=150837
- 이로운넷 (2023). 공공기관의 '챗GPT 등 생성형 AI 활용 보안 가이드라인' 나왔다 (국가정보원). https://www.eroun.net/news/articleView.html?idxno=34185
- 한솔 블로그 (한솔PNS). 회사 기밀 유출 없이 챗GPT 안전하게 활용하는 법. https://blog.hansol.com/1082
- 피카부랩스 블로그. ChatGPT에 회사 자료를 올려도 괜찮을까요? 데이터 유출을 막는 방법. https://peekaboolabs.ai/blog/chatgpt-data-security-tips
이미지 출처