두 가지 실패가 같은 방향을 가리킨다
최근 두 가지 보고가 AI-First 워크플로우를 설계하는 입장에서 꽤 불편한 질문을 동시에 던졌다. 하나는 기술적 실패다. Microsoft Copilot에서 Word 문서를 매개로 자가 전파하는 AI 웜이 공개 시연됐다(geeknews). 다른 하나는 조직적 실패다. 컨설팅 업체 Hermit Tech가 1년 반 동안 관찰한 AI 프로젝트의 성공률은 0%였고, 그 이면에는 실패를 숨기도록 설계된 인센티브 구조가 있었다(geeknews). 기술은 뚫렸고, 조직은 스스로를 속이고 있다. 두 사례 모두 "AI 도입 전 위험 설계"가 빠져 있다는 점에서 같은 문제를 가리킨다.
기술 실패: Copilot 웜이 드러낸 신뢰 경계의 붕괴
Copilot AI 웜의 작동 방식은 단순하지만 파괴적이다. 외부 Word 문서에 흰색 소형 글꼴로 숨긴 명령—이른바 교차 도메인 프롬프트 주입(XPIA)—을 삽입하면, Copilot은 서식을 제거한 뒤 그 명령을 읽는다. 결과 문서의 재무 수치를 바꾸고, 공격 프롬프트 전체를 결과 문서 하단에 복사한다. 이 문서가 다음 작업의 자료로 사용되면 공격이 다시 실행된다. 원본 악성 문서는 더 이상 필요 없다.
핵심은 공격자가 피해자의 Microsoft 365 테넌트 접근 권한조차 필요 없다는 점이다. SharePoint, Teams, Outlook으로 문서를 공유하거나 Work IQ가 OneDrive에서 관련 자료로 선택하게 만들면 된다. 감염 문서는 정상적인 내부 승인 문서처럼 유통되고, 편집 내역에도 이상이 없어 보인다. 조직의 정보 기반 자체가 조용히 오염된다.
Microsoft는 144일간의 조정 기간 동안 특정 페이로드 차단과 모델 업그레이드(GPT-5.5, GPT-5.6)를 배포했지만, 변형된 페이로드로 전체 공격 체인이 공개 시점에도 재현됐다. 연구자들이 지적하듯, 이건 단일 패치로 해결되는 버그가 아니다. LLM이 외부 콘텐츠와 사용자 지시를 같은 컨텍스트 창에서 처리하는 구조적 한계다. 탐지기를 앞단에 추가해도 탐지기 자체가 또 다른 LLM이 되는 'LLMs all the way down' 문제가 남는다.
조직 실패: 실패를 숨기도록 설계된 인센티브
Hermit Tech의 관찰은 기술 문제보다 어쩌면 더 다루기 어렵다. 실패를 공개할 유인이 없는 구조가 만들어졌기 때문이다. 경영진은 AI 투자를 의심하면 자리를 잃고, 직원은 AI를 쓰지 않은 작업도 AI 성과로 포장한다. 일부 조직은 토큰 소비량을 실적 지표로 삼아, 엔지니어들이 LLM이 스스로 프롬프트를 반복하도록 만들어 사용량을 채운다. Copilot 라이선스를 구매한 것 외에 별다른 작업이 없는데도 AI 생산성 향상을 발표하는 상장사도 있다.
이 조정 문제(coordination problem)가 무서운 이유는 자기강화 구조이기 때문이다. 누구 한 명이 과장된 성과를 부정하면 동료를 거짓말쟁이로 만든 것이 되어 해고된다. 그 자리는 다시 기존 입장을 따를 사람으로 채워진다. Fortune 500 기업의 임원이 "고객 경영진이 100배 생산성 향상을 주장하는 상황에서 공급업체가 이를 부정하면 계약이 취소된다"고 말하는 상황이다. 모두가 동시에 인정하면 바뀌겠지만, 그것을 조율할 수단이 없다.
테크 리드가 지금 당장 해야 할 설계
두 실패를 겹쳐 보면 AI-First 워크플로우에서 빠진 것이 보인다. 기술 낙관론과 조직 도입 계획은 있는데, 실패 패턴 설계가 없다. 내일 당장 팀에 적용할 수 있는 것 세 가지를 짚는다.
첫째, 외부 문서를 Copilot 컨텍스트에 넣기 전 신뢰 등급을 분류하라. Copilot AI 웜 연구자들이 권고한 완화책은 간단하다. 외부 출처 문서를 신뢰하지 않는 자료로 취급하고, Copilot 생성·편집 전에 첨부 문서를 먼저 검토하며, 결과 문서를 공유 전에 세밀하게 확인한다. 이걸 팀 규칙이 아닌 워크플로우 단계로 박아야 한다. 구두 가이드라인은 바쁠 때 무너진다.
둘째, AI 도입 성과 지표를 설계할 때 조작 가능성을 먼저 따져라. 토큰 소비량, AI 사용 횟수 같은 지표는 측정하기 쉬운 만큼 조작하기도 쉽다. Hermit Tech가 관찰한 것처럼, 지표가 잘못 설계되면 팀원들은 결과가 아니라 지표를 최적화하기 시작한다. "AI를 사용했는가"가 아니라 "AI를 사용한 결과 무엇이 달라졌는가"로 평가 기준을 잡아야 한다. Mitsubishi 고객지원 사례처럼, 시스템 지표에 성공으로 잡혀도 고객은 다시 사지 않는다.
셋째, AI가 생성하거나 편집한 문서에 출처 메타데이터를 보존하라. Copilot 웜 연구에서 가장 인상적인 제안은 프롬프트 주입 차단보다 추적 가능성 설계였다. 생성 문서에 원본 자료의 출처와 모델이 수행한 편집 내역을 메타데이터로 보존하면, 주입 자체를 막지는 못해도 사후 탐지와 대응이 가능해진다. 이건 보안 요구사항인 동시에 AI-First 팀의 품질 관리 인프라 문제다.
전망: 구조적 취약점은 패치로 해결되지 않는다
Microsoft가 144일 동안 패치를 배포하고도 공격이 재현됐다는 사실은 중요한 신호다. 이건 Microsoft만의 문제가 아니다. LLM이 유용하려면 공격자가 통제할 수 있는 정보를 처리해야 하고, 그 정보는 신뢰할 수 있는 지시와 같은 컨텍스트 창에 들어간다. 연구자들의 결론대로, 의도와 해석을 안정적으로 분리하는 장치가 현재 LLM 구조에는 없다.
AI 광풍의 조직적 실패도 마찬가지다. 인센티브 구조가 실패를 숨기도록 설계돼 있는 한, 패치(관리 지침, 교육 프로그램, 평가 제도 개선)는 표면만 건드린다.
테크 리드 입장에서 현실적인 결론은 하나다. AI 도구를 도입하기 전에, 그 도구가 실패하는 방식을 먼저 설계하라. 어떤 공격 벡터가 존재하는지, 어떤 지표가 조작될 수 있는지, 어떤 실패가 조직 안에서 숨겨질 수 있는지—이 세 가지 질문에 답이 없다면 도입 계획은 절반짜리다. AI의 잠재력에 낙관적인 것과, 그 리스크를 냉정하게 설계하는 것은 모순이 아니다. 오히려 그 둘을 동시에 가져가는 팀만이 AI-First 워크플로우를 실제로 굴릴 수 있다.