매주 하나씩 AI 도구가 사라진다. Amazon Q Developer는 모바일 콘솔 앱 지원을 종료했고, GitHub는 GPT-5.2 계열 모델의 deprecated 일정을 공지했다. 이름이 바뀌고, 번들링되고, 조용히 가격이 오르고, 어느 날 'please migrate before June' 메일이 날아온다. 이게 일회성 노이즈라고 생각하면 오판이다. 이건 AI 툴링 시장의 구조적 특성이다.
문제는 도구가 교체된다는 사실 자체가 아니다. 팀이 도구를 중심으로 워크플로우를 설계해놨다는 게 문제다. dev.to에 올라온 한 엔지니어링 분석이 이 지점을 정확히 짚는다: 도구는 조달 사이클 안에서 교체되지만, 습관은 온보딩 문서, PR 규범, 인시던트 대응 절차에 박혀서 훨씬 오래 남는다. 그리고 많은 팀이 그 습관을 특정 AI 도구의 UI와 묶어버린다.
가장 흔한 실수는 워크플로우 문서에 모델 이름을 박아넣는 것이다. "리팩토링은 Claude X, 테스트 생성은 GPT Y, AWS 질문은 Amazon Q." 선호도로서는 괜찮다. 아키텍처로서는 틀렸다. 모델 이름은 버전이 달린 구현 세부사항이다. 아키텍처의 단위가 되어야 하는 건 capability(역량) 다. '마이그레이션 플랜에서 롤백 누락을 체크한다', '로그에서 인시던트 타임라인을 요약한다', '머지 전 의존성 리스크를 분류한다'—이런 역량 정의는 어떤 모델이 이를 수행하는지와 무관하게 살아남는다.
그렇다면 뭐가 안정적이어야 하나? 엔지니어링 계약(engineering contract)이다. DB 마이그레이션 워크플로우를 예로 들면: AI가 마이그레이션 플랜 초안을 작성하되, 반드시 롤백 단계를 포함해야 하고, 락킹 리스크를 명시해야 하고, 예상 실행 시간과 영향 범위를 적어야 한다. 인간 오너가 실행 전 승인해야 하며, 최종 아티팩트는 채팅 히스토리가 아닌 레포지토리에 남아야 한다. 이 계약은 어떤 AI 도구가 바뀌어도 유효하다.
이 '계약'을 런타임에서 강제하는 구체적인 방법이 최근 커뮤니티에서 두 가지 형태로 구현되고 있다. 첫 번째는 Claude Hooks다. dev.to의 한 상세 분석이 실제 사고를 기반으로 이를 설명한다. GovForge 프로젝트에서 자동화된 서브에이전트가 main 브랜치에 직접 푸시를 감행했다. 규칙은 AGENTS.md에도, Constitution 문서에도, 유저 메모리에도 명시되어 있었다. 그럼에도 위반이 발생했다. 이유는 하나—그 규칙들은 '의도의 위치'일 뿐 '실행의 위치'가 아니었기 때문이다.
해결책은 PreToolUse 훅에 등록된 스크립트였다. Bash 도구가 호출될 때마다 훅이 JSON 페이로드를 받아 허용/차단을 판단하고, 차단 시 exit code 2를 반환한다. Claude Code 하네스는 이 코드를 hard refusal로 처리하고, stderr 메시지를 에이전트에게 그대로 전달한다. 에이전트는 왜 막혔는지 읽고 다음 턴에서 올바른 브랜치를 만들어 PR을 연다. 문서가 할 수 없는 것을 코드가 한다. 주목할 점은 이 320줄짜리 가드가 단순한 git push origin main 감지가 아니라 refspec 재작성, 암묵적 push.default, --all/--mirror 플래그, 중첩 셸 우회까지 닫는다는 것이다. 통제 구조를 설계할 때 '나이브한 구현'이 얼마나 빨리 뚫리는지를 보여주는 사례다.
두 번째 구현 형태는 CI 단계의 계약 검증이다. 한 개발자가 공개한 agent-contract-tests는 에이전트 운영 규칙을 YAML로 레포에 직접 기술하고, CI가 이를 검증하는 구조다. 특정 에이전트가 어떤 도구에 접근할 수 있는지, 어떤 에이전트 간 호출이 허용되는지, 민감한 액션에 필수 증거 필드가 있는지를 파이프라인이 체크한다. 설정이 현실과 어긋나면 CI가 실패한다. 런타임 임포트로 에이전트 러너 내부에서도 같은 규칙을 강제할 수 있다. 프레임워크도 아니고 샌드박스도 아닌, 얇고 명시적인 계약 레이어다.
두 접근 모두 같은 원칙에서 출발한다: 아티팩트는 도구 바깥에 살아야 한다. 채팅 히스토리는 시스템 오브 레코드가 아니다. 더 나은 자동완성이 달린 스크래치패드일 뿐이다. AI 도구는 그냥 사라지지 않는다—변이한다. 메모리 포맷이 바뀌고, 컨텍스트 윈도우가 달라지고, 엔터프라이즈 보존 설정이 조용히 변경된다. 프롬프트, 생성된 플랜, 테스트 출력, 운영 결정—이것들이 생산 환경, 컴플라이언스, 인프라에 영향을 미친다면 레포, PR 코멘트, 런북, 감사 로그에 남겨야 한다.
팀 리드로서 내가 지금 당장 적용 가능한 체크리스트로 정리하면 이렇다. 워크플로우 문서에서 모델 이름을 지우고 역량 단위로 재작성할 것. 각 AI 활용 워크플로우에 '누가 승인하는가, 아티팩트가 어디에 남는가'를 명시할 것. Claude Code를 쓴다면 AGENTS.md의 규칙 중 가장 중요한 것 하나를 골라 PreToolUse 훅으로 강제할 것. CI에 에이전트 설정 검증 단계를 추가할 것. 이 네 가지는 어떤 AI 도구가 오고 가도 유효하다.
전망은 명확하다. 벤더들은 계속 빠르게 움직일 것이다. 모델 비용, 안전 요구사항, 파트너십, 엔터프라이즈 통제 정책이 계속 바뀐다. 그 속도에 워크플로우가 끌려다니는 팀과, 도구를 교체 가능한 컴포넌트로 설계해둔 팀의 차이는 6개월 뒤에 선명하게 갈린다. 가장 매력적인 데모를 가진 에이전트에 베팅한 팀이 아니라, 승인 게이트와 아티팩트 영속성과 명시적 계약으로 워크플로우를 구조화한 팀이 다음 도구 교체를 조용히 넘긴다. 어드보케이트한 한 분석의 표현을 빌리자면: 도구가 아닌 워크플로우를 성숙시키는 것, 그게 AI 툴링이 어른이 되는 방식이다.