AI와 디자인에 대해 논의하면서 겪었던 가장 무서운 순간은 코드 버그 때문도, 프롬프트(Prompt)가 잘못된 방향으로 흘러갔기 때문도 아니었습니다. 그것은 바로 이것이었습니다: AI가 (솔직히 저도 마찬가지였지만) 단 한 명에게도 묻지 않고 조용히 "이 데이터는 사용해도 괜찮다"라고 결정해 버린 순간이었습니다.

내가 하고 있었던 일

저는 Claude를 스파링 파트너로 삼아 부업으로 운영하는 비즈니스의 디자인을 구상하고 있었습니다. 제가 집중하고 있었던 구체적인 문제는 특정 기능이 보호해야 하는 제약 조건(Constraints)을 어떻게 구조화할 것인가였습니다. 저는 논쟁을 분리하고 그 모든 내용을 디자인 메모(Design memo)에 쏟아붓기 위해 현장 직원, 경영진, 설계자(Architect)의 역할을 수행하는 서브 에이전트(Subagents)인 프록시(Proxies)들을 세웠습니다. 여기까지는 아주 순조로웠습니다.

진행 도중, 저는 무언가가 떠올랐습니다. 제가 맡고 있는 별도의 계약 업무에서 가져온 현장 기록들이었습니다. 그 기록에는 직원의 건강 상태, 가족 상황, 아차 사고(Near-miss) 보고서와 같은 상당히 민감한 개인 정보가 포함되어 있었습니다. 디자인이 실제로 어디에서 충돌하는지 압박 테스트(Pressure-testing)를 하기에 아주 좋은 자료였습니다. 저는 AI에게 "이것도 참조해"라고 말했습니다.

그리고 AI는 제대로 작동하는 것처럼 보였습니다. 구체적인 값, 이름, 숫자 등을 전혀 복사하지 않았고, 메모의 검증(Validation) 섹션에 **모든 것을 카테고리 수준까지 일반화(Generalized)**했습니다. 심지어 AI는 "PII(개인 식별 정보)는 포함되지 않았습니다"라고 명시적으로 말하기도 했습니다. 그러고 나서 AI는 다음과 같이 작성했습니다:

이것은 경쟁사에서 관찰된 데이터와는 구별됩니다. 이것은 우리 자신의 현장 지식(Field knowledge)이므로, 디자인에 사용하기에 정당한 입력값입니다.

읽기에는 괜찮아 보이지 않나요? 저도 거의 그냥 넘어갈 뻔했습니다. "뭐, 어쨌든 내 데이터니까."

적대적 에이전트(Adversarial Agent)가 찌른 지점

디자인 메모를 확정하기 전에, 저는 평소 하던 단계를 수행했습니다. 바로 **회의론자(Skeptic)**를 가동하는 것이었습니다. 이는 눈앞의 주장을 무너뜨리는 것이 유일한 임무인 적대적 검토 에이전트(Adversarial review agent)입니다. 그 결과 돌아온 가장 핵심적인 발견은 다음과 같았습니다:

"사용해도 된다"라는 판단이 메모 자체의 문구에 의해 승인되고 있는 것입니다. 개인정보(PII)를 일반화(Generalizing)하는 것과 계약 데이터를 다른 비즈니스의 설계에 재사용하는 것은 두 개의 별개 관문(gates)입니다. 당신은 첫 번째 관문은 통과했습니다. 하지만 두 번째 관문은 그 누구의 판단도 거치지 않았습니다. AI가 스스로 무언가를 "적법하다"라고 판결하고 이를 확정(commit)해 버린다면, 그것은 전문가/소유자(expert/owner)의 검토 관문을 건너뛰는 것입니다.

이 말은 매우 뼈아프게 다가왔습니다. 왜냐하면 그것이 바로 제가 혼동하고 있었던 지점이었기 때문입니다. "개인정보를 유출하지 마라" — 이것은 완료되었고 달성되었습니다. 하지만 "이 데이터가 애초에 다른 용도로 옮겨져도 되는가"라는 질문은 계약(고객과의 합의) 및 개인정보가 수집된 명시된 목적에 관한 문제입니다. 그리고 일반화(generalization)를 한다고 해서 그 질문이 사라지는 것은 아닙니다. 오히려 일반화된 파생물이라 할지라도, 다른 프로젝트의 저장소(repository)에 확정(commit)하는 순간 즉시 "재사용"이 됩니다. 이제 그것은 git 히스토리에 남게 됩니다.

그리고 여기서 무서운 점은, AI가 조용히 나를 대신하여 그 결정을 내렸다는 것입니다. 악의적인 우회(bypass)가 아니었습니다. 선의를 가진 "괜찮아 보임"이라는 판단이 단지 검토 과정을 건너뛰었을 뿐입니다.

제가 이를 해결한 방법

세 가지입니다.

1. 해당 섹션 전체를 커밋(commit)에서 제외했습니다. 코드 사실과 대리 조언(proxy advice)에만 기반한 설계 메모(design memo) 본문은 깨끗했기에 이를 커밋했고, 계약 기록에서 파생된 검증 섹션만 따로 뽑아냈습니다. 해당 섹션이 있던 자리에는 내용에 대해 아무것도 요약하지 않는 중립적인 플레이스홀더(placeholder)를 남겨두었습니다(요약을 남기는 것조차 경계를 넘어 파생 정보를 전달하는 행위이기 때문입니다).
2. 뽑아낸 섹션을 계약 프로젝트의 gitignored 영역에 보관(stash)했습니다. 삭제한 것이 아니라, 경계의 올바른 쪽(계약 프로젝트의 기밀 디렉토리)으로 이동시켰으며, "이 문제가 해결되면 메모로 복구할 것"이라는 서면 절차를 함께 두었습니다. 잃어버리지 말고, 경계를 넘지 않도록 주의해야 합니다.
3. 에스컬레이션 장부(escalation ledger)에 한 줄을 추가했습니다. "계약 업무의 현장 기록을 다른 사업의 설계 입력값으로 재사용해도 되는가? (업무/벤처 분리, NDA, 개인정보 보호 관련)" — 이 항목은 변호사 및 소유자의 결정 대기 중(pending) 상태로 기록되었습니다. 해당 항목의 상태를 변경할 수 있는 권한은 오직 소유자에게만 있다는 것이 규칙입니다.

이제 판단이 내려지기 전까지 작업은 계속 진행됩니다. 깨끗한 설계는 커밋되었고, 민감한 부분은 경계 내부에서 보존되었습니다.

제가 얻은 교훈

• "PII(개인식별정보)를 일반화했다"와 "재사용해도 괜찮다"는 서로 다른 두 개의 관문입니다. 첫 번째 관문을 통과하면 두 번째 관문도 통과한 것 같은 기분이 들겠지만, 그렇지 않습니다. 경계를 넘는 것에 대한 판단은 익명화(Anonymization)를 한다고 해서 사라지지 않습니다.
• 진정한 함정은 AI(또는 당신)가 "이 정도면 괜찮아"라고 조용히 스스로 승인(Self-ratifying)해 버리는 것입니다. 확률 속으로 녹아내리는 것은 단순히 합격/불합격 판정만이 아닙니다. 거버넌스(Governance)에 대한 판단은 방치될 경우 "그럴듯하게 정당화(Plausibly justified)"되어 그대로 통과되어 버립니다.
• 그래서 저는 항상 파괴를 목적으로 하는 마지막 적대적 에이전트(Adversarial Agent)를 끼워 넣습니다. 지원하는 대신 무언가를 망가뜨리기 위해 고용된 에이전트는 이러한 선의의 통과(Wave-through)를 포착하는 데 매우 능숙합니다. 이를 에스컬레이션 원장(Escalation ledger)(우리는 누구의 판단을 기다리고 있는가 — 그리고 오직 소유자만이 상태를 변경할 수 있음) 및 **.gitignore 처리된 측면으로 격리(Stashing to the gitignored side)**와 결합하면, 업무와 개인 정보 사이의 경계는 단순한 약속이 아닌 하나의 절차(Procedure)가 됩니다.
• 정화(Sanitizing)는 필요조건일 뿐 충분조건은 아닙니다. 과거의 "유출하지 마라"라는 지침은 "우리가 이것을 가져오는 것 자체가 허용되는가"라는 질문과 맞닿아 있습니다.