보안 검토를 위한 한 장

이 장에서 배우는 것 데이터가 어디에 갇혀 있고, 밖으로 나가는 길이 몇 개이며, 각각을 무엇으로 잠그는지. 도입 심사에 그대로 낼 수 있는 형태로 정리합니다.

왜 한 장이 필요한가

멤버 역할은 멤버와 역할에, 자료 범위는 드라이브에, 도구 권한은 도구 켜고 끄기에 있습니다. 각각은 잘 설명되어 있지만 보안 검토자는 그걸 한 장으로 보고 싶어 합니다.

이 장은 그 한 장입니다.

경계는 다섯 개입니다

graph TD
  A["1. 계정 — 누가 들어오나"] --> B["2. 워크스페이스 — 데이터 격리 단위"]
  B --> C["3. 대화 — 누가 이 대화를 보나"]
  B --> D["4. 자료 — 무엇을 재료로 쓰나"]
  B --> E["5. 밖으로 나가는 길 — 도구 · 채널 · API · 시스템"]

경계	무엇을 정하나	어디서	누가
계정	워크스페이스에 들어올 사람	멤버 화면 초대	owner · admin
워크스페이스	데이터가 섞이지 않는 단위	워크스페이스 생성	누구나(본인 소유)
대화	이 스레드를 볼 사람	그룹 공개 범위	owner · admin
자료	답변의 재료가 될 파일	드라이브 폴더	올리는 사람
나가는 길	실행 가능한 도구·경로	도구 설정 · 채널 · API 키 · 시스템	owner · admin (시스템은 owner만)

2. 워크스페이스가 가장 강한 통제입니다

이게 이 장에서 제일 중요한 문장입니다.

워크스페이스는 데이터가 섞이지 않는 단위입니다. 다른 워크스페이스의 대화·자료·도구는 서로 보이지 않습니다.

따라서 민감도가 다른 업무는 워크스페이스를 나누는 것이 가장 확실한 통제입니다. 같은 워크스페이스 안에서 권한을 잘게 나누는 것보다 훨씬 단순하고 설명하기 쉽습니다.

상황	권장
인사·법무 자료를 다룸	별도 워크스페이스
외부 고객 응대(위젯·채널)	별도 워크스페이스
운영 시스템에 닿는 도구	별도 워크스페이스
일반 업무	하나로 충분

두 번째 줄이 특히 그렇습니다. 외부 입력이 들어오는 워크스페이스와 사내 자료가 있는 워크스페이스를 분리하면 프롬프트 인젝션의 사고 경로가 구조적으로 끊깁니다.

3. 대화가 보이는 범위

종류	누가 보나
비공개 대화	만든 사람만
전체 공개 그룹	워크스페이스 멤버 전원
선택된 멤버 그룹	지정한 부서 또는 개인만

"비공개"의 범위를 정확히 이해해야 합니다. 다른 멤버에게 안 보인다는 뜻이지, 워크스페이스 소유자가 데이터베이스 수준에서 접근할 수 없다는 뜻은 아닙니다. 개인 사생활 용도가 아니라 업무상 정리되기 전의 초안을 두는 자리로 보세요.

4. 자료의 범위

드라이브에 올린 파일은 그 워크스페이스의 답변 재료가 됩니다. 검색은 권한을 모릅니다.

text

올리기 전 확인:  □ 이 워크스페이스의 모든 멤버가 봐도 되는 파일인가  □ 개인정보가 포함되어 있나 — 있다면 보관 근거와 기간이 있나  □ 계약상 반출 제한이 있나

"봐도 되는 사람"과 "물어보면 답에 딸려 나올 사람"은 같습니다. 이 한 줄이 드라이브 정책의 전부입니다.

5. 밖으로 나가는 길

여기가 검토자가 가장 오래 보는 부분입니다. 길은 네 종류입니다.

도구

도구 켜고 끄기에서 워크스페이스별로 켭니다. 판단 기준은 도구는 권한이다와 같습니다.

text

읽기 도구        →  대체로 안전 (읽는 대상이 민감하지 않다면)되돌릴 수 있는 쓰기 →  기록만 남기면 됨되돌릴 수 없음     →  메일 발송 · 결제 · 삭제 · 대외 게시 → 사람 승인

밖에서 안으로 — 채널 · 위젯 · 이메일

경로	누가 보낼 수 있나
채널	연결한 외부 서비스의 사용자
채팅 위젯	웹사이트 방문자 누구나
이메일 에이전트	그 주소를 아는 누구나

아래 두 줄이 통제의 초점입니다. 신원 확인 없는 입력이 에이전트에 직접 닿습니다. 이 워크스페이스에 사내 자료와 쓰기 도구를 함께 두지 마세요. 그리고 AI 기본법의 사전 고지·표시 의무가 여기서 발생합니다.

API 키

API 키로 외부에서 부르기의 키는 그 워크스페이스의 권한을 그대로 가집니다.

text

□ 용도마다 별도 키 (하나를 여러 곳에 쓰면 회수할 때 전부 멈춤)□ 키는 환경변수·비밀 관리 시스템에. 코드·프롬프트에 두지 않음□ 사용량 화면에서 키별 소비를 주기적으로 확인□ 담당자가 바뀌면 회수 절차

시스템

시스템은 회사 컴퓨터 한 대가 워크스페이스에 붙는 것입니다. 그래서 등록·정책 변경은 owner만 할 수 있습니다. 가장 무거운 권한이므로 admin에게도 열려 있지 않습니다.

도입 심사 체크리스트

그대로 복사해서 쓰세요.

text

[격리]  □ 민감 업무를 별도 워크스페이스로 분리했는가  □ 외부 입력(위젯·채널·메일)이 사내 자료와 같은 워크스페이스에 있지 않은가[접근]  □ owner 1명 + admin 1~2명 구성인가 (owner 단독은 위험)  □ 퇴사·이동 시 멤버 제거 절차가 있는가  □ 대화 그룹 공개 범위가 부서 기준으로 설정되어 있는가[자료]  □ 드라이브에 올린 파일의 반출 가능 여부를 확인했는가  □ 개인정보 포함 파일의 보관 근거와 기간이 정해져 있는가  □ 대화·파일이 모델 학습에 쓰이는지 확인했는가 (개인 계정 병행 사용 포함)[실행]  □ 되돌릴 수 없는 도구에 사람 승인이 걸려 있는가  □ 켜져 있는 도구 중 실제로 안 쓰는 것을 껐는가  □ MCP 서버 자격증명이 최소 권한으로 발급되었는가[외부 노출]  □ API 키가 용도별로 분리되어 있는가  □ 위젯·이메일 사용 시 AI 고지 문구가 노출되는가[기록]  □ 승인 이력이 남고 있는가 (→ 감사 기록)  □ 사용량을 주기적으로 확인하는 사람이 있는가

심사에서 반드시 나오는 세 가지

위 목록으로 대부분 답이 되지만, 대기업 심사에서는 거의 항상 이 셋을 따로 묻습니다. 각각 전용 화면이 있습니다.

질문	어디서 답하나
"개인정보가 모델로 나갑니까?"	데이터 마스킹 — 나가기 전에 토큰으로 바꿉니다
"누가 무엇을 조회했는지 남습니까?"	감사 로그 — 질의와 근거 문서가 남습니다
"사내 계정 체계로 로그인됩니까?"	SSO와 부서 동기화 — IdP 그룹이 부서가 됩니다

세 번째에서 막히면 나머지는 검토조차 안 됩니다. 별도 비밀번호를 만들어야 한다는 것 자체가 통과 조건에 걸리는 회사가 많습니다.

그리고 실행 권한을 사람 승인으로 좁히는 장치가 승인 대기와 작업자 권한입니다 — "되돌릴 수 없는 도구에 사람 승인"의 실제 구현입니다.

정기 점검 — 분기 1회

text

□ 멤버 목록 (퇴사자 남아 있나)□ 켜져 있는 도구 (3개월간 한 번도 안 쓴 것)□ API 키 (쓰는 곳이 사라진 키)□ 드라이브 (오래된 민감 파일)□ 시스템 (연결이 끊긴 채 남아 있는 자리)

자주 하는 오해

"권한을 잘게 나누면 안전해지지 않나요?"

어느 선을 넘으면 반대가 됩니다. 개인마다 예외를 만들기 시작하면 반년 뒤에 아무도 현재 상태를 설명하지 못합니다. 워크스페이스로 크게 나누고, 그 안은 부서 단위로 하는 편이 검토하기도 유지하기도 낫습니다.

"비공개 대화면 아무도 못 보는 것 아닌가요?"

다른 멤버에게 안 보인다는 뜻입니다. 데이터베이스 수준의 접근이나 법적 요구에 의한 제출까지 막아주지는 않습니다. 개인 사생활 정보는 애초에 넣지 마세요.

확인

1. 민감도가 다른 업무를 다룰 때 가장 확실한 통제는?

답

워크스페이스를 나누는 것입니다. 워크스페이스는 데이터가 섞이지 않는 단위라, 같은 워크스페이스 안에서 권한을 잘게 나누는 것보다 단순하고 설명하기 쉽습니다.

2. 채팅 위젯과 이메일 에이전트를 쓸 때 왜 워크스페이스를 분리합니까?

답

신원 확인 없는 외부 입력이 에이전트에 직접 닿기 때문입니다. 사내 자료와 쓰기 도구가 같은 워크스페이스에 있으면 프롬프트 인젝션의 사고 경로가 완성됩니다. 분리하면 그 경로가 구조적으로 끊깁니다.

3. 시스템 등록이 admin에게도 열려 있지 않은 이유는?

답

회사 컴퓨터 한 대를 워크스페이스에 붙이는, 가장 무거운 권한이기 때문입니다. 그 컴퓨터에서 할 수 있는 일 전체가 워크스페이스로 들어오므로 owner만 등록·정책 변경을 할 수 있습니다.

마지막으로 잘 안 될 때 무엇부터 보는지 정리합니다 → 문제 해결