에이전트를 팀에 붙이는 속도는 빨라졌다. LG유플러스는 Microsoft Copilot을 전사 표준 도구로 도입한 지 한 달 만에 임직원 이용률 80%를 넘겼다. 누적 프롬프트 44만 건, 1인당 평균 86회 활용. 데이터 분류 업무는 Claude 모델을 연동해 처리 시간을 90% 줄였다. 수치만 보면 성공 사례다. 그런데 이 숫자가 반갑기보다 먼저 드는 질문이 있다. 도입 이후 팀에서 실제로 무슨 일이 벌어지고 있는가.
IBK기업은행의 실험은 그 질문에 다른 각도의 단서를 준다. 253개 팀, 731명의 현업 직원이 직접 AI 에이전트를 기획하고 구현했다. 외화송금 서류 점검, 여신심사, 생산적금융 지원 대상 발굴—전산 부서가 아니라 실제 업무 현장의 사람들이 문제를 정의하고 에이전트를 만들었다. 여기서 핵심은 현업 직원이 AI 활용의 주체가 됐다는 사실이다. 기존의 '현업이 요구사항 전달 → 전산 부서가 개발 → 현업이 사용'이라는 사이클이 깨졌다. 속도와 현장 밀착성은 분명히 올라간다.
그런데 기업은행은 우수 에이전트를 곧바로 전면 적용하지 않겠다고 밝혔다. 보안, 데이터 접근 권한, 결과 검증 절차, 책임 구조—이 모든 것을 먼저 설계하겠다는 것이다. 여신심사나 외환 거래처럼 고객의 권리에 직접 영향을 주는 영역에서 AI 결과를 직원이 최종 확인하는 절차가 없으면 실제 업무에 붙일 수 없다는 판단이다. 속도를 낸 뒤 거버넌스를 설계하겠다는 게 아니라, 거버넌스 없이는 속도를 내지 않겠다는 입장이다. 이 선택이 맞다.
왜 그렇게 확신하냐고? Claude Code의 자기증식 에이전트 실험 사례를 보면 된다. 일본 개발자 커뮤니티 Qiita에서 논의된 이 실험은 '메타 스킬'—다른 스킬을 생성하는 스킬—을 심은 뒤 에이전트가 스스로 능력을 확장하도록 설계한 것이다. 아이디어는 매력적이다. 개발자 한 명이 씨앗 스킬 하나를 심으면, 에이전트가 알아서 생태계를 키운다. 실제로 어떻게 됐는가. 6개월 운영 결과를 직접 문서화한 개발자의 보고는 세 가지 실패 패턴으로 요약된다.
첫째, 능력 팽창(Capability Creep). 메타 스킬의 최적화 목표가 '완전성'으로 설정되자 에이전트는 실제로 필요하지 않은 도메인의 스킬까지 생성했다. 두 달 만에 쓰지도 않는 분산 시스템 패턴, 한 번도 사용한 적 없는 도구의 설정 형식까지 스킬 목록에 쌓였다. 둘째, 의미 드리프트(Semantic Drift). 스킬이 스킬을 낳을수록 원래 스펙에서 멀어진다. 3세대 스킬은 요약의 요약을 읽은 것처럼 원본 의도를 잃었다. 심지어 이미 deprecated된 라이브러리를 참조하는 스킬도 생성됐다. 셋째, 디버그 불가능성. 수작업으로 작성한 스킬이 실패하면 원인을 찾을 수 있다. 자동 생성 스킬이 자동 생성 스킬에서 실패하면 추적에 4배 이상의 시간이 걸렸다.
이 사례에서 주목할 것은 실패 자체가 아니다. 일본 개발자 커뮤니티가 내린 처방이다. 그들의 답은 '제한된 자기개선(bounded self-improvement)'이었다. 스킬이 자식 스킬을 낳을 수 있지만, 자식 스킬은 샌드박스 안에서만 작동하고 손자 스킬은 생성이 원천 차단된다. 생성 깊이 2레벨 이후는 명시적 비활성화. 이는 단순한 기술 설계가 아니라 거버넌스 철학이다. 시스템이 예외적 상황에서 확장되는 것이 아니라 안전하게 축소되도록 설계해야 한다는 관점.
세 사례를 나란히 놓으면 패턴이 보인다. 도입 속도는 문제가 아니다. LG유플러스가 한 달 만에 80%를 찍은 것은 도입 전 사내 전용 환경 구축과 내부 데이터 연동이 선행됐기 때문이다. IBK기업은행이 731명의 현업 직원을 에이전트 빌더로 전환하면서도 즉각 배포를 보류한 것은 금융 도메인의 책임 구조를 먼저 설계하겠다는 판단 때문이다. Claude Code 자기증식 실험에서 실패를 겪은 개발자가 채택한 것도 결국 생성 깊이 제한과 수동 승인 게이트였다.
에이전트를 팀에 붙이면 두 종류의 변화가 생긴다. 하나는 측정 가능한 변화—처리 시간 단축, 사용률, 프롬프트 횟수. 다른 하나는 측정이 늦게 되는 변화—역할 경계의 모호함, 결과물 출처의 불투명성, 팀원의 검증 능력 저하. 첫 번째 변화에 성공했다고 두 번째 변화를 방치하면, 에이전트는 협업자가 아니라 시스템 안에 조용히 쌓이는 부채가 된다.
실용적으로 정리하면 이렇다. 지금 당장 팀에 에이전트를 붙이는 것을 막을 이유는 없다. 단, 붙이는 순간 세 가지를 함께 설계해야 한다. 에이전트가 자율적으로 할 수 있는 것의 범위, 그 결과물을 사람이 검증하는 시점과 절차, 에이전트가 만든 산출물의 추적 가능한 기록. 이 세 가지 없이 켜는 에이전트는 빠르게 켜지고, 조용히 망가진다.
2026년 4분기 이전에 비관리형 AI 스킬 전파로 인한 첫 프로덕션 장애 사례가 공개될 것이라는 전망이 이미 개발자 커뮤니티에서 나오고 있다. 그 장애 리포트를 사후에 읽을 것인가, 아니면 지금 거버넌스를 설계해서 그 목록에서 이름을 빼놓을 것인가. 에이전트를 켠 뒤의 설계가, 켜는 결정만큼 중요한 이유다.