Part 8. 회사에서 안전하게 쓰기 - 보안과 디버깅
Part 8. 회사에서 안전하게 쓰기 - 보안과 디버깅
많이 쓰는 사람보다 오래 살아남는 사람은 따로 있다. 바로 안전하게 쓰는 사람이다. ChatGPT를 업무에 붙이면 속도는 금방 오른다. 하지만 검증 없이 붙이면 속도만 빨라지고 사고도 빨라진다. 초안은 10분 만에 나왔는데, 잘못된 수치가 임원 보고에 들어가고, 고객 정보가 개인 계정 채팅창으로 넘어가고, 다른 프로젝트 문맥이 섞여 엉뚱한 답이 나오면 그때부터 절약한 시간이 모두 이자로 돌아온다.
모델이 더 많은 일을 대신할수록, 실무자의 경쟁력은 단순히 잘 시키는 능력이 아니라 어디까지 맡기고 어디서 멈추게 할지 아는 통제력에서 갈린다. 이번 장의 목표는 단순하다. 회사에서 ChatGPT를 겁먹고 안 쓰는 상태에서 벗어나, 안전하게 검증하며 쓰는 상태로 넘어가는 것이다. 보안, 환각 검증, 이상 응답 디버깅, Memory와 Projects의 격리, 법과 거버넌스까지 하나의 체계로 묶어 보자.
잘 쓰는 사람의 마지막 조건은 안전이다
업무에서 AI를 잘 쓴다는 말은 멋진 답변을 많이 뽑는다는 뜻이 아니다. 실제로는 세 가지를 동시에 해내는 뜻에 가깝다. 첫째, 민감한 정보를 지킨다. 둘째, 중요한 사실은 검증한다. 셋째, 이상한 결과가 나오면 이유를 추적해 바로잡는다.
이 세 가지가 빠지면 ChatGPT는 생산성 도구가 아니라 고급 자동완성기가 된다. 보기 좋게 써 주지만, 책임은 결국 사람이 지게 된다. 반대로 이 세 가지가 갖춰지면 ChatGPT는 믿고 함께 일할 수 있는 워크스페이스가 된다. 속도는 AI가 올리고, 신뢰는 사람이 지키는 구조다.
회사 정보는 어디까지 넣어도 되는가
많은 직장인이 가장 먼저 막히는 질문이 이것이다. 어디까지 넣어도 괜찮을까. 이 질문에는 멋진 정답보다 실무적인 기준표가 더 유용하다.
| 구분 | 예시 | 기본 원칙 |
|---|---|---|
| 녹색 | 공개된 보도자료, 이미 공개된 제품 설명, 일반적인 업무 상황, 익명화된 가상 예시 | 넣어도 된다 |
| 노란색 | 내부 문서의 구조, 비식별화한 회의 요약, 범주화한 성과 수치, 고객 사례를 익명 처리한 초안 | 최소화·마스킹 후 조건부 사용 |
| 빨간색 | 고객 개인정보, 주민등록번호, 계좌번호, 계약서 원문, 미공개 재무 수치, 소스코드, API 키, 인사평가 내용, 법률 검토 원문 | 외부 AI에 직접 입력하지 않는다 |
핵심은 정보의 내용이 아니라 통제 가능성이다. 공개 정보는 문제가 적다. 하지만 한 번 외부 서비스로 넘어간 뒤 회수하기 어려운 정보라면, 편하다는 이유만으로 넣으면 안 된다. 개인용 서비스와 관리형 업무용 워크스페이스는 데이터 통제와 관리자 기능에서 차이가 있을 수 있으므로, 회사에서는 계정 유형과 정책을 먼저 확인해야 한다.12
실무에서는 알맹이와 구조를 분리하는 습관이 가장 강력하다. 예를 들어 계약서 원문을 통째로 붙여 넣는 대신, 계약 검토 체크리스트를 만들어 달라고 요청한다. 실적 숫자를 그대로 넣는 대신, 전년 대비 감소 원인 분석 보고서의 목차와 논리 구조를 먼저 설계하게 한다. 고객 이름을 넣는 대신, 업종·규모·문제 유형만 남기고 익명화한다.
이 원칙을 기억하면 된다. 회사의 비밀은 넣지 말고, 회사의 문제를 푸는 틀은 요청하라.
안전한 입력을 만드는 3단계
민감한 데이터를 다루는 직무일수록 입력 단계에서 사고가 난다. 따라서 프롬프트를 잘 쓰는 것보다 먼저, 프롬프트를 안전하게 바꾸는 기술이 필요하다.
고유명사는 역할명으로 바꾼다. 회사명, 고객명, 프로젝트명, 직원명은 업종, 고객군, 부서 역할 같은 일반 표현으로 치환한다.
정확한 숫자는 범위와 방향으로 바꾼다. 예를 들어 매출 18.7% 감소 대신 전년 대비 두 자릿수 감소처럼 표현한다.
원문 투입 대신 템플릿 요청으로 바꾼다. 문서를 대신 써 달라고 하기보다 내가 값을 채울 수 있는 목차, 체크리스트, 질문 목록을 먼저 받는다.
예를 들어 위험한 요청은 이렇다. 신규 고객 A사의 불만 메일 전문을 붙여 넣고 회신을 써 달라고 하는 방식이다. 안전한 요청은 이렇게 바뀐다. 중견 B2B 고객이 배송 지연과 커뮤니케이션 부족에 불만을 제기한 상황이다. 구체적 회사명과 주문 정보는 보안상 제외한다. 차분하고 책임감 있는 회신 구조와 문장 템플릿을 제안해 달라.
이렇게 바꾸면 AI는 여전히 큰 도움을 준다. 다만 회사의 속살은 보여 주지 않고, 일의 뼈대만 같이 세우게 된다.
환각은 실수라기보다 작업 방식의 문제다
모델이 좋아질수록, 틀린 말도 더 그럴듯하게 들릴 수 있다. 문장이 매끈하고 구조가 좋아졌다고 해서 사실이 맞는 것은 아니다. 그래서 환각은 단순히 "AI가 한 번 실수했다"라고 보기보다, 사용자가 어떤 작업을 검증 없이 넘겼는지의 문제로 보는 편이 더 실무적이다.
직장인이 특히 조심해야 하는 영역은 네 가지다. 법률 문구, 숫자와 통계, 정책과 규정, 출처와 인용이다. 이 네 가지는 보기 좋게 틀리기 가장 쉬운 영역이다.
환각을 식별하는 신호
환각은 대개 허술하게 틀리지 않는다. 오히려 너무 매끈해서 위험하다. 다음 신호가 보이면 한 번 더 의심해야 한다.
지나치게 구체적인 날짜, 조항 번호, 판례명, 통계 수치가 출처 없이 나온다.
실제 회사 문맥을 모를 텐데도 내부 사정을 아는 듯 단정적으로 말한다.
질문보다 더 많은 사실을 아는 척한다.
인용문처럼 보이는데 원문 링크나 문서명을 확인할 수 없다.
맞는 말과 틀린 말이 한 문단 안에 자연스럽게 섞여 있다.
예를 들어 이런 답은 위험하다. 개인정보보호법 몇 조에 따라 이 경우는 명백히 위법입니다라고 말하는데, 조문 확인이 안 된다. 또는 경쟁사 점유율을 소수점까지 제시하는데 출처가 없다. 이런 순간에 필요한 태도는 감탄이 아니라 멈춤이다.
직장인을 위한 검증 루틴
검증은 거창한 감사 절차가 아니다. 보고서 한 장, 메일 한 통, 회의 메모 하나에도 적용할 수 있는 짧은 루틴이면 충분하다.
첫째, 답변에서 실제로 틀리면 위험한 문장을 표시한다. 숫자, 정책, 법률, 인용, 고객명, 일정이 여기에 해당한다.
둘째, ChatGPT에게 자기검토를 시킨다. 방금 답변에서 사실 주장만 따로 뽑고, 각 주장에 필요한 근거 유형과 확신 수준을 표시하라고 하면 된다. 처음 답을 생성할 때보다, 자기 답을 감사하라고 시킬 때 불확실성을 더 잘 드러내는 경우가 많다.
셋째, 원본 체계를 확인한다. 회사 내부 정책이면 사내 문서, 법률이면 국가법령정보센터, 수치면 원 데이터나 공식 보고서, 고객 정보면 CRM이 기준이 된다. AI 답변끼리 비교하지 말고 원본과 비교해야 한다.
넷째, 고위험 문서는 사람 승인 단계를 남긴다. 채용 평가, 계약 검토, 재무 전망, 대외 발표문, 보도자료는 반드시 사람의 이름이 붙는 최종 검토를 거친다. AI가 초안을 만들더라도 결재는 사람이 한다.
다섯째, 검증 후 살아남은 좋은 출력만 템플릿으로 저장한다. 잘 나온 초안이 바로 자산이 되는 것이 아니라, 검증까지 통과한 초안만 자산이 된다.
답이 이상할 때 디버깅하는 5단계
실무에서 더 자주 벌어지는 문제는 완전히 틀린 답보다 미묘하게 이상한 답이다. 너무 장황하다, 우리 회사 톤이 아니다, 이전 프로젝트 내용이 섞였다, 숫자를 이상하게 해석했다, 할 수 없는 일을 된다고 말한다. 이럴 때는 감으로 다시 묻기보다 단계적으로 디버깅해야 한다.
1단계. 증상을 먼저 이름 붙인다
'답이 별로예요'는 디버깅이 안 된다. 대신 증상을 정확히 적는다. 예를 들면 이런 식이다. 사실 오류가 있다. 톤이 과장됐다. 고객 A와 고객 B 문맥이 섞였다. 표는 맞는데 해석이 틀렸다. 외부 규정을 인용하면서 출처가 없다.
증상을 붙이면 문제의 위치가 보인다. 사실 오류인지, 스타일 문제인지, 컨텍스트 오염인지, 도구 사용 문제인지가 갈린다.
2단계. 컨텍스트를 줄여 본다
대화가 길어질수록 모델은 좋은 기억만 쌓는 것이 아니라 잡음도 함께 쌓는다. 관련 없는 파일, 예전 지시, 이전 대화의 잘못된 전제, 메모리 설정이 모두 영향을 줄 수 있다. 그래서 이상한 답이 나오면 새 대화나 새 프로젝트에서 최소 입력만 넣고 다시 돌려 본다.
같은 요청을 짧은 프롬프트와 필요한 파일 하나만으로 다시 실행했는데 결과가 좋아졌다면, 문제는 모델 성능이 아니라 문맥 과잉이었을 가능성이 크다.
3단계. 입력을 네 조각으로 다시 쪼갠다
많은 실패는 프롬프트가 길어서가 아니라 섞여 있어서 생긴다. 목표, 배경, 제약, 출력형식이 한 문장에 엉켜 있으면 모델은 가장 눈에 띄는 부분만 잡고 달린다.
따라서 프롬프트를 다시 쓸 때는 네 조각으로 분리한다. 무엇을 만들지, 무엇을 참고할지, 무엇을 하면 안 되는지, 어떤 형식으로 낼지를 따로 적는다. 이 단계를 거치면 이상하게 장황한 답이나 엉뚱한 형식 문제는 꽤 많이 사라진다.
4단계. 모델과 도구를 분리해서 본다
문제가 프롬프트가 아니라 모델 선택이나 도구 사용일 수도 있다. 빠른 초안에는 가벼운 모델이 어울리지만, 규정 비교나 리스크 검토에는 더 신중한 모델이 안정적일 수 있다. 또 웹 검색, 커넥터, 파일 분석이 켜져 있으면 외부 자료나 연결된 데이터의 품질 문제까지 함께 들어온다.
즉, 답이 이상하면 이렇게 나눠 봐야 한다. 모델이 문제인가, 검색이 문제인가, 파일이 문제인가, 메모리가 문제인가. 네 갈래로 쪼개면 원인이 보인다.
5단계. 수정 사항을 자산화한다
디버깅의 마지막은 다시 잘 되게 만드는 것이 아니라, 같은 실패를 반복하지 않게 만드는 것이다. 따라서 고친 프롬프트, 금지 규칙, 검증 질문, 추천 모델 조합을 Project 지침이나 팀 템플릿에 반영해야 한다.
예를 들어 숫자 해석이 자주 틀리면 수치가 포함된 출력에는 계산 근거와 가정 목록을 반드시 붙이게 한다. 고객 문맥이 섞이면 프로젝트를 분리한다. 톤이 흔들리면 금지 표현 목록과 예시 문장을 넣는다. 디버깅은 수리로 끝나면 손해고, 규칙으로 남아야 이익이다.
Memory와 Projects는 편의 기능이 아니라 통제 수단이기도 하다
많은 사람이 Memory를 편리한 기억 기능 정도로만 생각한다. 하지만 회사에서 보면 이건 단순한 편의가 아니라 데이터 경계의 문제다.
Memory는 사용자의 선호와 반복 정보를 반영해 응답을 개인화하는 기능이고, Projects는 대화와 파일, 지침을 묶어 장기 작업을 관리하는 작업 공간이다.34 이 차이를 이해하면, 무엇을 개인 기본값으로 둘지와 무엇을 특정 프로젝트 안에 가둘지를 구분할 수 있다.
실무적으로는 이 차이가 매우 크다. 영업 제안 작업과 채용 작업을 한 덩어리로 쓰면, 말투나 문서 구조가 섞이는 정도로 끝나지 않는다. 고객 관련 맥락이 다른 작업에 영향을 줄 수도 있다. 반대로 프로젝트를 분리하면 최소한 맥락 오염 가능성을 크게 줄일 수 있다.
기억해야 할 포인트는 세 가지다.
민감한 업무는 하나의 거대한 대화보다 프로젝트 단위로 나누는 편이 낫다.
개인 선호와 프로젝트 맥락은 분리해서 관리할수록 안정적이다.
프로젝트를 나누는 기준은 팀명이 아니라 데이터 경계다.
예를 들면 이런 식이다. 고객사별, 채용 포지션별, 분기 전략별, 법무 검토별로 프로젝트를 나눈다. 반대로 '모두의 메모'처럼 하나의 거대한 프로젝트에 쌓는 방식은 편해 보여도 결국 섞인다.
계정과 설정에서 먼저 막아야 할 것들
보안은 사용자의 의지만으로 지키기 어렵다. 잘못 붙여 넣는 사람을 탓하기 전에, 애초에 실수해도 크게 번지지 않는 환경을 만드는 편이 낫다. 기업용 워크스페이스를 쓴다면 관리자 기능, 접근 통제, 사용 정책, 교육이 함께 가야 한다.12
회사에서 최소한 갖춰야 할 기본값은 이렇다.
업무용 AI는 개인 계정보다 관리형 계정으로 통일한다.
가능하면 SSO와 MFA를 적용해 누가 쓰는지 식별 가능하게 만든다.
데이터 보존 정책과 삭제 기준을 정한다.
민감 정보 업로드 금지 규칙을 문서화한다.
커넥터는 최소 권한으로 연결하고, 정말 필요한 사람에게만 연다.
승인된 사용 경로를 충분히 편하게 만들어 그림자 AI를 줄인다.
특히 커넥터와 웹 검색은 생산성을 크게 올리지만, 동시에 데이터 노출 면적도 넓힌다. 메일, 드라이브, 캘린더, 슬랙, 깃허브 같은 연결은 생각보다 많은 문맥을 모델에 건넨다. 그래서 권한은 넓게 열어 두고 주의해서 쓰자는 방식보다, 기본은 좁게 열고 필요할 때만 확장하는 방식이 훨씬 안전하다.
개인정보보호법 관점에서의 실무 기준
한국에서 직장인이 가장 먼저 의식해야 할 법적 축은 개인정보보호법이다. 중요한 것은 법 조문을 외우는 일이 아니라, 생성형 AI에 개인정보를 넣는 순간 어떤 책임이 생기는지 아는 것이다.
실무 규칙으로 바꾸면 네 문장으로 정리된다. 첫째, 목적이 불분명하면 넣지 않는다. 둘째, 실명 대신 가명이나 역할명으로 바꾼다. 셋째, 주민등록번호·계좌번호·카드번호·건강정보처럼 고위험 식별자는 제거한다. 넷째, 가능하면 회사가 승인한 관리형 환경을 쓴다.5
특히 인사, 고객지원, 영업, 재무 부서는 개인정보와 민감 정보가 섞여 있는 경우가 많다. 그래서 이 부서들은 AI를 더 늦게 쓸 부서가 아니라, 더 구조적으로 써야 할 부서다. 입력 전 마스킹 템플릿, 승인된 용도 목록, 검토 로그가 있어야 안심하고 빨리 갈 수 있다.
AI 기본법 관점에서 회사가 준비해야 할 것
한국의 「인공지능 발전과 신뢰 기반 조성 등에 관한 기본법」은 2026년 1월 22일부터 시행됐다.6 실무자가 이 법을 볼 때 중요한 점은 "우리 회사가 AI를 쓰고 있는가"보다 "어떤 영역에서 어떤 통제 아래 쓰고 있는가"를 묻는 습관이다.
특히 사람의 권리나 기회에 큰 영향을 미칠 수 있는 영역일수록 더 조심해야 한다. 채용, 금융, 교육, 의료, 공공 서비스처럼 결과의 파급력이 큰 영역에서는 AI를 보조 도구로 쓰더라도 인간 검토, 기록, 설명 가능성을 남기는 쪽이 안전하다.67
실무적으로 기업이 준비해야 할 질문은 다음과 같다. 우리 회사의 AI 사용 중 생성형 AI에 해당하는 것은 무엇인가. 고객이나 사용자가 AI 사용 사실을 알아야 하는 지점은 어디인가. 중요한 의사결정을 보조하거나 자동화하는 업무가 있는가. 그 과정에 인간 검토가 실제로 작동하는가. 문제가 생겼을 때 기록과 설명이 가능한가.
결국 법 대응의 핵심은 문서 한 장 추가가 아니라 운영 체계다. 누가 쓰고, 무엇을 쓰고, 어디까지 맡기고, 누가 마지막에 확인하는지가 정리돼 있어야 한다.
사내에서 ChatGPT 도입을 제안하는 법
보안팀이나 법무팀이 AI 도입을 막는다고 느끼는 경우가 많다. 하지만 실제로는 반대인 경우가 많다. 대개는 쓰지 말자는 것이 아니라, 무엇을 어떻게 통제할지 정리되지 않았기 때문에 멈춰 있는 것이다.
따라서 사내 제안서는 생산성 자랑으로 시작하면 설득이 약하다. 대신 통제 가능한 도입안으로 보여 줘야 한다. 좋은 제안서는 보통 여섯 가지를 담는다.
현재 이미 발생 중인 그림자 AI 사용 현황
승인된 사용 사례와 금지 사용 사례
계정, 인증, 보존, 로그, 권한에 대한 관리 방안
개인정보와 기밀 정보 입력 기준
인간 검토와 검증 절차
시범 도입 범위와 측정 지표
포인트는 간단하다. 금지보다 우회가 쉽지 않게 만드는 것이다. 승인된 경로가 느리고 복잡하면 사람들은 결국 개인 계정과 다른 도구로 돌아간다. 그래서 보안이 강한 조직일수록 오히려 승인된 사용 경로를 더 쉽게 만들어야 한다.
예를 들어 시범 도입은 이렇게 짤 수 있다. 마케팅팀과 HR팀 두 부서만 대상으로, 공개 자료 요약·초안 작성·회의록 정리 세 가지 용도만 허용한다. 고객 개인정보, 평가 원문, 계약서 원문은 금지한다. 모든 출력물은 팀장 검토 후 외부 발송한다. 한 달 동안 시간 절감, 재작업률, 정책 위반 건수, 사용자 만족도를 측정한다. 이 정도만 해도 매우 설득력 있다.
팀 단위 AI 거버넌스는 거창한 위원회보다 운영 규칙에 가깝다
거버넌스라고 하면 대단한 조직도부터 떠올리기 쉽다. 하지만 현장에서는 그렇게 시작하면 대부분 멈춘다. 오히려 필요한 것은 작고 단단한 운영 규칙이다.
팀 단위 거버넌스는 보통 다음 다섯 층으로 만들면 된다.
정책: 무엇을 해도 되고 무엇을 하면 안 되는지 짧고 명확하게 적는다.
역할: 누가 승인하고, 누가 운영하고, 누가 사고를 보고받는지 정한다.
기술 통제: 계정, 권한, 보존, 모니터링, 차단 기준을 붙인다.
검증: 어떤 출력이 사람 검토를 반드시 거쳐야 하는지 정한다.
학습: 분기마다 실패 사례와 좋은 사례를 업데이트한다.
여기서 중요한 것은 책임의 공백을 없애는 일이다. 예를 들어 팀 공유 GPT가 있다면 소유자가 있어야 하고, 지식 문서를 올린 사람이 최신성을 책임져야 하며, 문제가 생겼을 때 누가 끄고 고치는지도 정해져 있어야 한다. 아무나 쓰는 도구는 편하지만, 아무도 책임지지 않는 도구가 되기 쉽다.
또 하나 중요하다. AI 정책은 장문의 금지 문서보다 짧은 의사결정 카드가 더 잘 먹힌다. 예를 들면 이런 질문 카드다. 이 입력에는 개인정보가 있는가. 이 답변이 틀리면 금전·법률·평판 피해가 있는가. 검증 가능한 원본이 있는가. 프로젝트 격리가 필요한가. 이 네 질문만 습관이 돼도 사고가 크게 줄어든다.
안전하게 쓰는 팀이 결국 더 빨리 간다
많은 조직이 처음에는 안전 규칙을 속도 저하 장치로 느낀다. 하지만 실제로는 반대다. 규칙이 없으면 매번 어디까지 써도 되는지 묻느라 느려지고, 사고가 나면 전면 중단으로 더 느려진다. 반대로 입력 기준, 검증 루틴, 프로젝트 분리, 승인 절차가 정리된 팀은 같은 실수를 반복하지 않는다.
즉, 안전은 브레이크가 아니라 핸들이다. 브레이크만 있는 차는 못 달리고, 액셀만 있는 차는 오래 못 간다. 빨리 퇴근하는 사람은 무작정 맡기는 사람이 아니라, 어디까지 맡겨도 안전한지 아는 사람이다.
이 장의 핵심 체크리스트
마지막으로 현장에서 바로 적용할 수 있게 핵심만 짚어 보자.
회사 정보는 공개 가능 정보, 조건부 정보, 금지 정보로 나눠서 본다.
민감한 업무는 내용보다 구조를 요청하는 방식으로 바꾼다.
숫자, 법률, 인용, 정책은 반드시 검증한다.
답이 이상하면 증상 정의, 컨텍스트 축소, 입력 재구성, 모델·도구 분리, 규칙 반영 순으로 디버깅한다.
전역 설정보다 프로젝트 단위 분리가 필요한 업무를 먼저 구분한다.
개인정보보호법과 AI 기본법 관점에서 최소화, 기록, 인간 검토를 준비한다.
팀 거버넌스는 금지 문서보다 운영 규칙과 책임자 지정이 중요하다.
잘 쓰는 사람의 마지막 조건은 많이 쓰는 사람이 아니라, 안전하게 검증하며 쓰는 사람이다. 이제 이 기준이 몸에 붙으면 ChatGPT는 더 이상 불안한 실험 도구가 아니다. 회사 안에서도 믿고 꺼내 쓰는 생산성 인프라가 된다.
참고
2Managing workspace settings in ChatGPT Enterprise
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.