Claude Code Routines가 정식 공개됐다. PC가 꺼져 있어도 Anthropic의 웹 인프라에서 예약 작업이 돌아가고, GitHub 루틴과 API 워크플로를 스케줄 기반으로 자동 실행한다. 프로 요금제 기준 하루 5회, 엔터프라이즈는 25회. 숫자는 작아 보여도 방향은 명확하다. AI 코딩 에이전트가 '내가 켜놨을 때만 쓰는 도구'에서 '항상 돌아가는 인프라'로 전환되는 시점이다.
솔직히 말하면, 이 기능 자체는 반갑다. 반복적인 코드베이스 점검, 야간 배포 전 린트 자동화, 정기적인 의존성 업데이트 체크 같은 작업을 인간이 붙들고 있을 이유가 없다. 자동화 범위가 넓어지는 건 맞는 방향이다. 문제는 그 확장 속도가 팀의 거버넌스 설계 속도를 압도하고 있다는 점이다.
1주차엔 잘 돌아간다. 3주차에 터진다
dev.to에 올라온 한 글이 이 패턴을 정확하게 짚었다. 제목 자체가 진단이다: "Why Your AI-Assisted Code Breaks After Week One." 1주차엔 코드가 나온다. 테스트도 통과한다. 속도감이 실제처럼 느껴진다. 3주차에 의존성 하나를 바꾸거나 요구사항이 조금 달라지면, 갑자기 아무도 이 코드의 논리를 온전히 소유하지 못하고 있다는 걸 깨닫는다.
이 글이 지목한 실패 원인은 모델의 한계가 아니다. 워크플로우의 구조 문제다. "it runs"와 "I understand it well enough to change it safely" 사이의 간극—이 저자는 그걸 velocity debt라고 부른다. 코드는 빠르게 쌓이지만, 이해는 따라오지 못한다. Routines처럼 인간의 개입 없이 코드가 자동으로 생성·실행되는 구조에선 이 간극이 더 빠르게 벌어진다. 아무도 보지 않은 코드가 매일 밤 실행되고 있다면, velocity debt의 이자는 밤새 불어난다.
보안은 '나중에 고치면 된다'가 통하지 않는다
더 직접적인 경고는 GeekNews에서 공유된 실제 사례에서 나왔다. 의료기관 직원이 AI 코딩 에이전트로 환자 관리 시스템을 직접 제작했다. 결과는 참담했다. 모든 환자 데이터가 암호화 없이 인터넷에 노출됐고, 진료 대화 녹음이 두 개의 외부 AI 서비스로 자동 전송됐다. 접근 제어 로직은 클라이언트 사이드 JavaScript에만 존재했고, curl 명령 한 줄로 전체 데이터에 접근이 가능했다. 보고자가 30분 만에 읽기·쓰기 권한을 확보했다는 건, 아무나 할 수 있었다는 뜻이다.
이 사례에서 AI가 못한 게 무엇인지를 보면 더 섬뜩하다. 비밀번호 해싱이나 스키마 설계 같은 '기술적으로 어려운' 부분은 AI가 제법 처리했다. 실패한 건 운영 감각이 필요한 부분—서버 사이드 인증, 데이터 처리 계약, 규제 준수 같은 맥락적 판단들이다. AI는 "묻지 않은 것은 모른다." 경험 많은 개발자가 과거의 실패 경험으로 채우는 암묵적 지식이 프롬프트에는 담기지 않는다.
자동화 범위와 거버넌스 범위는 동기화돼야 한다
세 기사를 나란히 놓으면 하나의 인과 흐름이 보인다. 자동화 범위 확장(Routines) → 코드 품질 붕괴(velocity debt) → 보안 재앙(바이브 코딩 사례). 이건 별개의 세 이슈가 아니다. 자동화 속도를 올릴수록, 인간의 검증이 빠지는 지점이 늘어나고, 그 공백에서 품질과 보안이 동시에 무너지는 단일한 패턴이다.
테크 리드로서 Routines 기능을 팀에 도입할 때 내가 먼저 설계할 것들은 명확하다. 첫째, 자동 실행 범위를 읽기 전용 작업부터 시작한다. 린트, 정적 분석, 의존성 감사처럼 코드베이스를 변경하지 않는 작업을 먼저 자동화하고, 쓰기 작업은 PR 생성 수준에서 인간 승인 게이트를 반드시 붙인다. 둘째, CLAUDE.md에 암묵적 맥락을 명시적으로 문서화한다. "이 배열은 직접 변경하지 않는다", "이 엔드포인트는 3초 타임아웃이 있다", "이 데이터는 외부 서비스로 전송 불가" 같은 팀의 운영 상식을 AI가 읽을 수 있는 형태로 쌓아야 한다. 셋째, AI 생성 코드의 보안 검토는 별도 스텝으로 분리한다. 생성한 도구가 검증도 하는 구조는 blind spot을 만든다. 보안 취약점 스캔, 접근 제어 로직 리뷰는 AI가 아닌 인간이나 별도 자동화 도구가 담당해야 한다.
의료 사례의 진짜 교훈은 바이브 코딩을 한 그 직원을 탓하는 데 있지 않다. 기술 없는 사람도 쉽게 배포할 수 있는 도구가 생겼는데, 그 도구가 "이건 의료 데이터입니다, 규제를 확인하셨나요?"라고 묻지 않는다는 구조적 문제다. Routines가 "이 작업은 외부 데이터에 접근합니다, 접근 제어를 검토하셨나요?"라고 묻는 거버넌스 레이어 없이 실행 범위만 넓히는 방향으로 진화한다면, 이 사례는 반복될 것이다.
지금 당장 써먹을 수 있는 판단 기준
자동화 범위를 넓히기 전에 팀에게 물어볼 세 가지 질문이다. "이 작업이 잘못 실행됐을 때 누가 30분 안에 알아챌 수 있나?" 모니터링 없이 자동화하는 건 눈 감고 운전하는 것이다. "AI가 생성한 코드에서 보안 결정을 내린 부분을 팀원이 설명할 수 있나?" 설명 못 하는 코드는 소유하지 못한 코드다. "이 자동화에 암묵적 맥락이 있나?" 있다면 그건 프롬프트가 아니라 CLAUDE.md에 먼저 써야 한다.
Routines는 분명 좋은 도구다. 하지만 자동화가 넓어질수록, 거버넌스 설계의 책임은 더 좁고 명확하게 집중돼야 한다. 에이전트가 밤새 혼자 작업한 코드를 아무도 검토하지 않는 팀—그게 지금 속도를 올릴수록 가장 빠르게 가까워지는 미래다.