한번은 서버의 데몬 로그를 열었다가 일부 비밀 값이 로그에 섞여 있는 것을 발견했습니다. 그래서 우리는 KEY= 와 TOKEN= 패턴을 매칭하는 짧은 명령어를 사용하여 이를 먼저 삭제(scrub)하고 각각을 redacted라는 단어로 교체하기로 결정했습니다. 우리는 그것으로 끝이라고 생각했습니다.

하지만 텍스트가 출력되었을 때, 두 개의 실제 키 값이 트랜스크립트(transcript)에 그대로 앉아 있었습니다. 유출된 것들의 이름은 ANTHROPIC_API_KEY_FALLBACK= 와 CLAUDE_CODE_OAUTH_TOKEN_BAD=였습니다. 이들의 이름은 KEY= 또는 TOKEN=이 아니라 _FALLBACK= 와 _BAD=로 끝나기 때문에, 패턴이 이들을 잡아내지 못했습니다.

비밀이 어떤 해커에게 유출된 것이 아니었습니다. 그것은 우리가 그 순간 "외부"라고 간주하지 않았던 곳, 즉 우리 자신의 트랜스크립트로 유출되었습니다. 비록 그것이 정확히 외부임에도 불구하고 말입니다. 로그에 출력된 비밀은 즉시 유출된 것으로 간주해야 하며, 키를 교체(rotate)해야 합니다.

여기서 얻는 교훈은 명령어가 잘못 작성되었다는 것이 아닙니다. 데이터는 당신이 이미 지켜보고 있는 지점이 아니라, 당신이 라벨을 붙이는 것을 잊어버린 틈새에서 유출된다는 것입니다.

파트 1: 3단계 방어 체계: 데이터는 아래로 흐를 수 있지만, 위로는 절대 흐를 수 없다

우리 모두가 매일 사용하는 AI는 지식 베이스를 타인의 클라우드(cloud)에 보관합니다. 당신이 무언가를 물어보면 모델은 세상의 광범위한 지식을 바탕으로 답변합니다. 거기에는 문제가 없습니다. 공공 지식이 당신에게 아래로 흐르는 것은 괜찮습니다.

문제는 데이터가 반대 방향으로 흐를 때 시작됩니다. 당신이 개인 데이터를 위로 입력하는 순간, 모델은 단순히 답변을 위해 그것을 읽는 것에 그치지 않습니다. 그 데이터 조각은 이미 당신의 기계를 떠나 타인의 시스템에 살고 있습니다. 그렇다면 무엇을 위로 보내도 안전하고 무엇이 그렇지 않은지 어떻게 알 수 있을까요? 우리가 사용하는 접근 방식은 데이터를 세 가지 계층으로 나누는 것입니다.

가장 바깥쪽 계층은 클라우드(cloud)이며, 모델이 이미 가지고 있는 세상의 지식입니다. 일반적인 것들을 자유롭게 물어보세요. 당신의 데이터는 그곳에 없습니다.

중간 계층은 공유 가능한 업무 데이터입니다: 공개 문서, 이미 공개된 프로젝트 컨텍스트(context) 등이 해당됩니다. 이것이 클라우드로 흐른다 해도 여전히 허용 가능한 범위입니다.

내부 계층은 비밀 정보(secrets)입니다: 금융 데이터, 건강 데이터, 고객 데이터, 자격 증명(credentials) 등이 해당됩니다. 이 계층에는 단 하나의 규칙이 있습니다. 절대로 외부 계층으로 흘러나가서는 안 된다는 것입니다. 끝입니다.

이러한 계층 구조의 핵심은 단방향 흐름(one-way flow)에 있습니다. 외부 계층의 지식은 아래로 흘러 내려가 당신의 작업을 얼마든지 도울 수 있지만, 내부 계층에 있는 것은 절대로 다시 위로 흘러 올라가지 않습니다. 방향을 이렇게 설정하고 나면, "이것을 AI에게 입력해도 될까?"와 같은 까다로운 질문이 훨씬 쉬워집니다. "이것이 어느 계층에 속하는가?"라는 질문으로 바뀌기 때문입니다.

파트 2: 당신이 생각하지 못하는 유출

가장 명백한 유출은 비밀 텍스트를 AI 채팅창에 직접 붙여넣는 것입니다. 대부분의 사람들은 이미 이에 대해 대비하고 있습니다. 더 교묘한 유출은 당신이 결코 볼 수 없는 자동화된 "처리(processing)" 단계에서 발생합니다.

우리 에이전트가 실제로 실행하는 메모리 시스템인 Graphiti를 예로 들어보겠습니다. 에이전트가 작업 청크(chunk)를 기록할 때마다, 소형 모델(small model)이 해당 청크의 원본 내용을 읽어 사실(facts)을 추출합니다. 그 "추출을 위한 읽기" 단계가 바로 데이터가 기기를 떠나는(egress) 지점입니다. 우리가 실제로 실행하는 스택에서는 그 소형 모델이 클라우드에서 읽기 작업을 수행하므로, 당신이 단지 "기억해 줘"라고 말했을 뿐임에도 불구하고 그 순간 당신의 원본 콘텐츠는 이미 위로 올라가 버린 상태가 됩니다. 당신은 무엇도 보내려 의도하지 않았습니다. 이것이 바로 우리가 "어떤 모델이 읽기를 수행하며, 어디에서 실행되는가"를 내부 계층의 문제로 취급하는 이유입니다.

마지막은 서두에서 언급한 유출된 키와 같은 로그(logs) 및 트랜스크립트(transcripts)입니다. 데이터가 범죄자에게 탈취되는 것이 아닙니다. 단지 당신이 외부 계층으로 분류하지 않았던 곳에 데이터가 쌓이게 될 뿐이며, 실제로는 그곳이 외부 계층임에도 불구하고 말입니다. 해당 로그를 읽을 수 있는 사람이라면 당신의 내부 계층에 있는 모든 것을 볼 수 있습니다.

파트 3: 단순한 의도가 아닌, 실질적인 방어 체계 구축하기

본능에 의존하는 판단은 방어로 간주되지 않습니다. 다음 세 가지 요소가 이를 실질적인 방어 체계로 바꿔줍니다.

설계 단계에서 레이어별로 데이터를 분리하세요, 사후에 처리하지 마십시오. 실제 개인 데이터를 보유하는 시스템을 구축하며 배운 점은, 데이터의 종류마다 규칙이 다르기 때문에 목적별 데이터 분리는 첫날부터 구조적(structural)이어야 한다는 것입니다. 어떤 데이터는 소유자가 동의를 철회하는 즉시 삭제해야 할 수도 있습니다. 반면 어떤 데이터는 법적으로 5~7년 동안 보관해야 할 수도 있습니다. 이 모든 것을 한데 모아두면, 삭제해야 하는 순간 전체 데이터 더미가 무너져 버립니다.

'Fail closed(실패 시 차단)' 방식으로 설정하세요. 데이터 조각이 어디로 흘러갈지 증명할 수 없다면, 그것이 외부 레이어(outer layer)로 흘러갈 것이라고 가정하고 차단하십시오. "아직 아무 문제도 발생하지 않았다"는 이유로 그냥 통과시켜 주지 마십시오. 이는 접근 제어(access control)와 동일한 규칙입니다. 권한이 있는 사람을 확인할 수 없다면, 먼저 거부하십시오. 추측하여 문을 열어주는 것보다 훨씬 안전합니다.

데이터를 외형이 아닌 본질에 따라 필터링하세요. 유출된 키(key) 사례로 돌아가 봅시다. 근본 원인은 "이 변수는 비밀이다"라는 의미가 아니라, KEY=라는 문자 패턴으로 필터링했기 때문이었습니다. 사물을 실제 본질에 따라 분류하기 시작하면, _FALLBACK과 같은 이상한 이름도 더 이상 그물망을 빠져나갈 수 없습니다.

이 세 가지 레이어가 자동으로 강제되도록 만드는 실제 배선(wiring) 작업은 현재 저희가 공개를 보류하고 있는 구현 단계의 또 다른 부분입니다. 하지만 위의 세 가지 원칙은 특별한 도구 없이도 오늘 바로 사용할 수 있습니다.

4부: 어떤 도구에도 적용 가능한 질문 하나

새로운 AI 도구를 업무에 연결하기 전에, 짧은 질문 하나를 던지십시오: "내가 입력하는 텍스트는 어디로 가며, 그것은 어느 레이어에 속하는가?" 만약 도구가 이에 답할 수 없다면, 아직 내부 레이어(inner layer)의 어떤 데이터도 입력하지 마십시오. 이 질문은 단순한 채팅부터 백그라운드에서 조용히 작동하는 메모리 시스템(memory system)에 이르기까지 모든 것에 적용됩니다. 이미 매일 사용하고 있는 도구들에 이 질문을 시도해 보십시오.

실제 업무 경험을 바탕으로 작성되었습니다. 전체 버전(및 태국어판)은 productize.life에서 확인하실 수 있습니다.