ChatGPT 내부에서 여러분의 코드를 찾는 방법 — 모든 엔지니어링 리더가 이번 주에 실행해야 할 Tiger Team Method

월요일 아침에 실행할 수 있는 10분짜리 테스트가 있습니다. 이 테스트는 여러분의 엔지니어들이 독점적인 소스 코드 (Proprietary source code)를 ChatGPT에 붙여넣고 있는지 알려줄 것입니다. 비용은 들지 않습니다. 조달 절차도, 보안 검토도, 컨설턴트도 필요하지 않습니다. 만약 테스트 결과가 양성(Positive)으로 나온다면, 여러분은 규제 기관이 아직 발견하지 못한 공개된 감사 결과(Open audit finding)를 보유하게 된 것입니다. 만약 음성(Negative)으로 나온다면, 다음 감사 결과를 방지할 플랫폼을 출시할 수 있는 짧은 기회를 얻게 됩니다. 이 테스트가 바로 Tiger Team Method입니다. 플랫폼은 클라우드(Cloud)와 DevOps가 이미 효과가 있음을 증명한 아키텍처적 해답입니다. 이 포스트는 두 가지 모두를 다루며, 2014년 클라우드 전환을 승리로 이끌었던 운영 플레이북(Operator playbook)이 왜 2026년 AI 거버넌스 (AI governance) 전환을 승리로 이끌 동일한 플레이북인지 설명합니다. 인간의 역학 관계는 동일하며, 레이어(Layer)만 다를 뿐입니다.

Tiger Team Method

여러분의 코드베이스 (Codebase)에서 독특한 내부 산출물 (Internal artifact)을 추출하십시오. 여러분의 엔지니어링 조직 외부의 사람이라면 결코 만들어내지 않을 함수 이름 (Function name), 여러분의 팀에 특화된 변수 명명 규칙 (Variable naming convention), 여러분의 스타일 가이드 (Style guide)가 강제하는 주석 패턴 (Comment pattern), 또는 여러분의 ADR(Architecture Decision Records)에 등장하는 내부 약어 (Internal acronym) 등이 있습니다. 특이할수록 좋습니다.

calculate_total이 아니라 calculate_loyalty_tier_uplift를 선택하십시오. Calculator가 아니라 RiskWeightedExposureCalculator를 선택하십시오. 규제 대상인 의료 환경이라면 riskAdjustedMemberScore 또는 HEDIS_gap_closure_engine과 같은 내부 약어를 선택하십시오. 이러한 산출물은 보험사(Payer)나 의료 제공자(Provider) 시스템 내부에만 존재하며, 공개된 학습 데이터 (Public training data)에 우연히 나타날 일이 없는 종류의 것입니다.

시크릿 창 (Private window)에서 ChatGPT를 여십시오. 로그인은 하지 마십시오. 세 가지 쿼리 (Queries)를 실행합니다:

1. "[여러분의 함수 시그니처(Function signature)]를 어떻게 구현하나요?"
2. "Python 서비스에서 [여러분의 내부 클래스 이름(Internal class name)]이 무엇을 하는지 설명해 주세요."
3. "에러 처리 (Error handling)를 포함한 [여러분의 내부 약어(Internal acronym)]의 작동 예시를 보여주세요."

Claude, Gemini, 그리고 여러분의 엔지니어들이 접근할 수 있는 다른 모든 공개 모델 (Public model)에 대해 동일한 세 가지 쿼리를 반복하십시오. 응답에서 두 가지 패턴을 찾아보십시오.

첫째, 모델이 일반적인 대응어가 아닌, 여러분의 내부 코드베이스에 있는 구체적인 명칭과 패턴을 포함하여 여러분의 정확한 내부 용어 (Internal terminology)를 사용하는 코드를 반환합니까? 둘째, 공개적인 흔적이 전혀 없어야 할 산출물 (Artifact)에 대해 모델이 의심스러운 확신을 보입니까? 즉, 여러분의 내부 클래스가 실제 운영 시스템 (Production system)에서 동작하는 방식과 일치하는 세부 사항을 통해 해당 클래스가 무엇을 '하는지' 설명합니까? 이 중 어떤 신호라도 나타난다면 이는 긍정적인 Tiger Team 결과입니다. 모델이 여러분의 코드 파편을 보았다는 뜻입니다. 그런 일이 일어날 수 있는 유일한 방법은 여러분의 엔지니어 중 한 명이 코드를 붙여넣었을 때뿐입니다. 데이터 유출 (Exfiltration)은 이미 발생했습니다. 이후 여러분이 무엇을 하느냐에 따라, 나머지 유출 사례를 자체 감사 (Audit)를 통해 발견할지, 아니면 규제 기관 (Regulator)을 통해 발견할지가 결정됩니다.

이 방법론에 이름이 붙은 이유는 모든 엔지니어링 조직 내에서 명명된 프로세스로 다뤄질 가치가 있기 때문입니다. Tiger Team은 5인으로 구성된 상설 감사 팀입니다. 플랫폼 (Platform) 팀에서 1명, 보안 (Security) 팀에서 1명, 가장 큰 두 제품 조직 (Product orgs)에서 각각 1명씩, 그리고 CTO실에서 1명으로 구성됩니다. 이들은 분기별로 테스트를 수행하며, 그 결과를 경영진 (Executive leadership team)에게 보고합니다. 결과물은 단 한 페이지짜리 메모입니다. 이것이 프로세스의 전부입니다. 기술적 복잡성은 제로입니다. 조직적 복잡성은 여러분에게 조사할 규율 (Discipline)이 있느냐에 달려 있습니다.

연구가 이미 보여주는 것

세 가지 조사 결과가 이 문제의 규모를 규정합니다. 이 중 어느 것도 추측이 아닙니다. 세 가지 모두 경영진이 이사회 보고서 (Board deck)에 아무런 조건 없이 인용할 수 있는 연구 자료를 근거로 합니다.

IBM의 2025 데이터 유출 비용 보고서 (2025 Cost of a Data Breach Report)에 따르면, 다섯 개 조직 중 하나는 섀도 AI (Shadow AI)로 인한 유출을 경험했습니다. 평균적인 섀도 AI 유출 비용은 유사한 표준 유출보다 67만 달러 더 높았습니다. 이로 인해 섀도 AI는 2025년 데이터셋에서 세 번째로 비용이 많이 드는 유출 요인이 되었으며, 이전 해의 주요 원인이었던 보안 기술 부족 (Security skills shortages)을 밀어냈습니다. 섀도 AI 유출의 65%는 고객의 개인정보 (PII)를 노출시켰으며, 이는 글로벌 평균인 53%보다 높습니다. AI 관련 유출을 겪은 조직의 97%는 AI 접근 제어 (AI access controls)가 부족한 상태였습니다.

AI 거버넌스 정책 (AI governance policy)을 보유한 조직은 37%에 불과합니다. 직원이 기밀 데이터를 공개 AI 도구에 업로드하는 것을 방지할 수 있는 기술적 제어 (technical controls)를 갖춘 조직은 17%뿐입니다. 302명의 사이버 보안 리더를 대상으로 한 설문 조사를 바탕으로 한 Gartner의 2025년 11월 분석에 따르면, 2030년까지 전 세계 기업의 40% 이상이 승인되지 않은 AI 도구와 관련된 보안 또는 컴플라이언스 (compliance) 사고를 겪을 것으로 예측됩니다. 설문에 참여한 사이버 보안 리더의 69%는 이미 직원들이 업무 중에 공개 생성형 AI (GenAI) 도구를 사용하고 있다는 증거를 확보했거나 그렇게 의심하고 있습니다. 예측의 핵심은 대부분의 기업에서 사고가 발생할지 여부가 아니라, 제때 승인된 대안을 구축한 60%에 속할 것인지 아니면 사고를 겪게 될 40%에 속할 것인지의 문제입니다. Netskope의 생성형 AI에 관한 클라우드 및 위협 보고서 (Cloud and Threat Report on Generative AI, 2025)에 따르면, 생성형 AI 도구로 전송되는 프롬프트 (prompts)는 1년 만에 6배 증가하여 조직당 월 3,000개에서 18,000개로 늘어났으며, 상위 25%에 해당하는 조직은 월 70,000개 이상을 전송하고 있습니다. 생성형 AI 도구로 유입되는 데이터 양은 같은 기간 동안 30배 증가했습니다. 현재 조직들은 직원들이 생성형 AI 프롬프트에 민감한 데이터를 포함하려는 시도를 월평균 223건 감지하고 있습니다. 이러한 궤적은 둔화되지 않고 오히려 가속화되고 있습니다. 수백 개의 기업에서 발생하는 수백만 건의 AI 상호작용 사용 패턴 분석을 바탕으로 한 Cyberhaven의 2026 AI 도입 및 리스크 보고서 (AI Adoption & Risk Report)에 따르면, 모든 AI 상호작용의 39.7%에 민감한 데이터가 포함되어 있으며, ChatGPT 사용의 32.3%는 개인 계정을 통해 발생합니다. 이는 SSO (Single Sign-On), 중앙 집중식 로깅 (centralized logging), 기업 보유 정책 (enterprise retention policies), 그리고 기존의 데이터 유출 방지 (DLP, data loss prevention) 스택이 적용할 수 있는 모든 제어 수단을 우회합니다. AI 도구로 유입되는 민감한 데이터 범주 중 소스 코드 (source code)는 전체 민감 데이터 입력의 18.7%를 차지하는 단일 최대 범주입니다. AI 도구로 유입되는 기업 데이터 중 민감한 데이터가 차지하는 비율은 2년 전 10.7%에서 작년 27.4%로, 현재는 34.8%로 성장했습니다. 직원들은 3일마다 AI 도구에 민감한 데이터를 입력하고 있습니다.

이미 알고 계신 이름 있는 사고들은 이 그림의 가시적인 부분에 불과합니다. Samsung Electronics는 2023년 4월 20일 이내에 세 차례에 걸쳐 반도체 소스 코드와 회의록이 ChatGPT로 유출되는 사고를 겪었으며, 이는 전사적인 사용 금지로 이어졌습니다. JPMorgan Chase, Apple, Amazon 또한 2023년 초 유사한 사고 이후 각각 전사적으로 ChatGPT 사용을 제한했습니다. 특히 Amazon의 법무팀은 ChatGPT의 결과물이 "우리가 이미 제작한 기존 자료와 밀접하게 일치한다"라고 직원들에게 서면으로 경고하기도 했습니다. 이 네 조직과 귀하의 조직 사이의 차이점은, 그들은 자신들의 사고를 발견했다는 점입니다. Cyberhaven의 수치들은 거의 모든 기업에서 동일한 패턴이 발생하고 있음을 보여줍니다.

당신은 이 영화를 이미 본 적이 있습니다. 2010년에서 2022년 사이에 클라우드(Cloud) 또는 DevOps 전환을 이끌었던 사람이라면 누구나 이 패턴이 세 번 또는 네 번 전개되는 것을 이미 목격했을 것입니다. 그 형태는 불변합니다. 새로운 기술이 등장합니다. 개발자들은 그것을 사용하고 싶어 합니다. 공식적인 답변은 "아직 안 됩니다, 보안 팀의 검토가 완료되지 않았습니다"입니다. 개발자들은 어쨌든 개인 신용카드나 개인 계정을 사용하여 이를 사용하며, 조직은 감사(Audit) 중에 이 도입 사실을 발견하게 됩니다. 플랫폼 팀은 결국 승인된 대안을 출시합니다. 안전하지 않은 경로가 더 이상 쉬운 경로가 아니게 되면, 전환이 완료됩니다.

저는 여기서 다 열거할 수 없을 만큼 많은 기업 규모의 클라우드 및 DevOps 전환을 이끌어 왔습니다. 아래의 네 가지 사례는 현재의 AI 시점과 가장 직접적으로 매칭되는 사례들입니다. 메커니즘은 다르지만, 인간의 역학(Human dynamics)은 다르지 않습니다. 다음에 이어지는 내용은 이론이 아닙니다. 제가 Fortune 50대 기업 중 4곳에서 시간 순서대로 목격한 실제 사례이며, 당시의 특정 플랫폼과 결과가 문서화되어 있습니다.

Pearson, 2012–2014 — Nibiru 플랫폼
Pearson의 개발자들은 개인 신용카드로 AWS 계정을 생성하고 있었습니다. 보안 팀은 AWS가 검토되지 않았다는 이유로 AWS 사용을 금지했습니다. 하지만 그 금지는 준수(Compliance)를 전혀 이끌어내지 못했습니다. 엔지니어들은 개의치 않고 AWS를 사용했고, 조직은 무엇이 어디에서 실행되고 있는지에 대한 가시성(Visibility)을 전혀 확보하지 못했습니다.

우리는 해당 카테고리에 이름이 붙기 전부터 AWS 상의 실질적인 IaaS/IaC 계층 역할을 했던 셀프 서비스 플랫폼인 Nibiru를 구축했습니다. 이는 Puppet 구성 관리 (Configuration Management), Zabbix 모니터링 (Monitoring), Route 53 DNS, 그리고 LDAP 기반 인벤토리 (Inventory) 위에 Flask 웹 UI와 REST API를 구축한 것이었으며, 암호화 (Encryption), 네트워크 제어 (Network Controls), 명명 표준 (Naming Standards), 그리고 감사 로깅 (Audit Logging)이 배포 표면 (Deployment Surface) 자체에 내장되어 있었습니다. 기존의 전통적인 IT 방식을 통해 12~18개월이 소요되던 프로비저닝 (Provisioning)이 Nibiru를 통해 단 몇 분으로 단축되었습니다. 이 플랫폼은 가드레일 (Guardrail) 역할을 했습니다. 승인된 경로가 안전하지 않은 경로보다 더 빨랐기 때문에 금지 조치는 불필요해졌습니다. Gene Kim이 우리가 무엇을 하고 있는지 확인하기 위해 현장을 방문하기도 했습니다. 엔지니어들은 누군가 강제해서가 아니라, 플랫폼을 통한 경로가 엄격하게 더 나았기 때문에 개인 AWS 계정 사용을 중단했습니다.

Aetna, 2014–2017 — Utopia 플랫폼. 동일한 플레이북을 컨테이너 계층에 적용했습니다. 다만 이 싸움은 플랫폼이 무엇 위에서 실행되는가가 아니라, 플랫폼이 어디에서 실행되는지에 관한 것이었습니다. Aetna의 엔터프라이즈 IT 및 보안 조직은 소비자 비즈니스를 AWS에서 완전히 제외하여 Aetna 자체 데이터 센터로 되돌리기를 원했습니다. Aetna의 CISO가 저에게 전화를 걸어 플랫폼이 DDoS 공격을 받으면 어떻게 할 것이냐고 물었을 때, 저는 "오토스케일링 (Autoscale) 할 겁니다. 당신은 무엇을 할 건가요?"라고 답했습니다. 우리는 Mesosphere와 SaltStack 기반으로 Utopia를 구축했으며, 컨테이너 보안을 위한 Twistlock과 SAST (정적 애플리케이션 보안 테스트)를 위한 Checkmarx를 배포 표면에 통합했습니다. 이 플랫폼은 레거시 코어 (Legacy Core)의 보안 결함 밀도가 5%인 것에 비해, 소비자 코드 베이스에서 0.05%의 보안 결함 밀도를 달성했습니다. 그 수치는 정치로는 이길 수 없었던 논쟁에서 승리했습니다. 클라우드 네이티브 (Cloud-native) 및 컨테이너화된 플랫폼이 우리가 후퇴하라고 요구받던 온프레미스 (On-prem) 스택보다 측정 가능한 수준으로 더 안전하다는 것을 증명했기 때문입니다. CISO는 마지못해 물러난 것이 아니라, 전사적으로 Docker 사용을 명령했습니다. 그리고 Aetna는 업계에서 Twistlock을 가장 공개적으로 참조하는 사례 중 하나가 되었습니다. 이 플랫폼은 거버넌스 (Governance)의 모습을 바꾸어 놓았습니다. 안전한 경로와 빠른 경로가 동일한 경로가 되었고, 데이터가 이를 증명했습니다.

Liberty Mutual, 2016–2017 — Fusion 플랫폼: 제가 합류했을 당시 Liberty Mutual의 소비자 사업부(Consumer business unit)는 Docker 마이그레이션에 어려움을 겪고 있었습니다. 우리는 Chef와 Docker Datacenter를 기반으로 Fusion을 구축했으며, 그 중심에는 선언적(declarative)인 Fusionfile이 있었습니다. 팀들이 필요한 사항(업스트림/다운스트림 사이드카, 데이터 레이어 컴포넌트, 배포 전/후 훅)을 선언하면 플랫폼이 나머지 과정을 처리했습니다. 2017년까지 이 플랫폼은 컨테이너 기반의 300개 이상의 서비스와 하루 수백 건의 배포 규모로 확장되었으며, 해당 팀은 자신들의 Docker 컨퍼런스 발표인 'All Roads Lead to the Cloud: Liberty Mutual's Journey with Docker EE'를 통해 플랫폼이 구동되는 Jenkins 기반 파이프라인과 Docker Datacenter 기반 구조를 설명했습니다. Fusionfile 패턴은 오늘날 우리가 사용하는 모든 "설정 파일에 필요한 것을 선언하는" 시스템의 아키텍처적 조상이었습니다. 여기에는 현대적인 AI 엔지니어링 플랫폼을 구동하는 저장소별 ADR(Architecture Decision Record) 및 코드 맵 매니페스트(code-map manifest) 패턴도 포함됩니다. 저는 이러한 계보를 'What Is an AI Engineering Platform? (2026 Guide)'에서 자세히 다루었습니다.

Comcast, 2019–2022 — SEED 플랫폼과 거버넌스 논쟁: Comcast는 이 글의 핵심적인 중심축입니다. 왜냐하면 Comcast의 사례는 오늘날 모든 기업이 AI와 관련하여 처한 상황과 가장 직접적으로 매핑되는 실제 거버넌스 이야기이기 때문입니다. 제가 그곳에 있을 당시 열린 내부 클라우드 서밋(internal cloud summit)에서, Comcast의 한 부사장(VP)은 장내에 다음과 같이 말했습니다. "우리 AWS 지출의 80%가 EC2에 사용되는데, 그 EC2 인스턴스의 80%가 활용률 1%로 방치되어 있습니다." 이 단 한 마디의 문장은 수치화된 거버넌스의 실패를 보여주었습니다. 이는 모든 팀에게 AWS를 부여한 뒤 스스로 해결하도록 내버려 둔 엔지니어링 조직의 재무적 특징이었습니다. 규모가 커진 상태에서의 국소적 최적화(Local optimization at scale)였습니다. 수백 개의 팀이 각자 자신만의 Terraform을 작성하고, 각자 자신만의 EC2 플릿(fleet)을 가동하며, 각자 고립된 상태에서 동일한 결정을 내렸고, 통합 청구서(consolidated bill)는 팀도 중앙 아키텍처 부서도 관심을 두지 않았던 그 실태를 그대로 보여주고 있었습니다. 상황은 나아지기 전에 더 악화되었습니다.

Comcast의 시니어 아키텍처 리더십은 Accelerate를 읽고 표준화된 CI/CD 툴링 (tooling)의 가치에 확신을 가졌으며, 전사적으로 Concourse 사용을 의무화했습니다. 모든 엔지니어링 조직은 Concourse로 전환하라는 지시를 받았습니다. 이 명령은 상상할 수 있는 가장 값비싼 형태의 로컬 최적화 (local optimization)를 초래했습니다. 수백 개의 팀이 각각 몇 달 동안 Concourse YAML을 작성했습니다. 당시 Concourse에는 공유 라이브러리 (shared libraries) 개념이 없었기 때문에, 파이프라인 (pipeline)당 수천 줄에 달하는 코드를 작성하며 고립된 상태에서 동일한 패턴을 재발명했습니다. 저는 엔지니어들이 자신들의 CI/CD를 구축하는 데 3개월을 보냈다고 자랑스럽게 말하는 팀들의 파이프라인을 차례차례 검토했습니다. 3개월입니다. 팀당 말이죠. 수백 개의 팀에 걸쳐 말입니다. 결국 동일한 파이프라인의 변형들을 만들어내기 위해서였습니다. SEED는 이 모든 것보다 앞서 있었습니다. 우리는 전사적인 Concourse 의무화가 내려지기 전에 이를 구축했습니다 — 자체적인...