AI 에게 일을 맡겼더니 되레 더 많은 일이 생겼다면, 문제는 AI가 아니라 결정권의 경계다. Drewgent가 처음 자동화를 도입했을 때 기록은 냉정했다: 0승 8패. 여덟 번의 자동화 시도가 모두 실패했고, 패배의 원인은 거의 비슷했다. AI가 ‘할 수 있을 것’ 같은 일을 대신 처리하다가, 본질적으로 인간의 판단이 필요한 지점을 건드린 것이다. 이 패배들이 증명한 결론 하나가 지금의 Tiered Autonomy 시스템을 만들었다. 단순한 자율도, 단순한 승인도 아니다. 일의 성격에 따라 AI의 권한을 층으로 나누는 것이다.

가장 낮은 층은 Tier 1이다. 맞춤법, 주석, 오타 수정처럼 후폭풍이 거의 없는 일이다. 여기서는 인간에게 묻지 않는다. 할 일을 하고 기록만 남기면 된다. 그다음 Tier 2는 기존 패턴 안에서 이루어지는 작업이다. 예를 들어 정해진 컨벤션에 따라 config를 고치거나, 이미 합의된 스킬 구조를 따르는 패치가 여기 해당한다. 자율적으로 실행하지만 provenance, 즉 ‘왜 이렇게 했는지’를 반드시 남긴다. 기계가 판단한 일이라도 그 맥락을 추적할 수 있어야 한다는 뜻이다.

문제는 Tier 3부터 시작된다. 구조를 바꾸는 일, 새로운 메커니즘을 도입하는 일, customize 레이어를 건드리는 일이다. AI는 여기서 독단적으로 실행하지 않는다. 대신 몇 가지 옵션을 들이대고 ‘내 추천은 이것’이라고 말한 뒤 인간의 승인을 기다린다. 마지막 Tier 4는 아키텍처와 방향 자체를 다룬다. P-layer 구조를 바꾸거나 전략을 전환하는 일은 AI가 제안만 하고 결정은 인간이 한다. 이 네 층의 핵심은 단순하다. 위험할수록 AI의 손을 떼고, 인간의 머리를 들이민다.

이 구조는 Ponytail 원칙과 맞닿아 있다. “이 코드가 정말 필요한가?”라는 질문에서 시작하는 Ponytail은 표준 라이브러리, 네이티브 기능, 이미 설치된 의존성을 먼저 확인하고, 그래도 필요할 때 최소한의 코드만 작성하라고 말한다. Tiered Autonomy도 같은 정신이다. 불필요한 결정을 AI에게 넘기지 말고, 이미 검증된 영역에서는 번거로운 승인 절차를 없애라는 것이다. 둘 다 결국 taste, 즉 ‘무엇이 중요한지 아는 감각’의 문제다. 중요한 일과 중요하지 않은 일을 구분하지 못하면, AI든 인간이든 똑같이 엉망을 만든다.

0승 8패의 기록은 사실 부끄러운 일만은 아니다. 그 여덟 번의 실패가 있었기 때문에 Drewgent는 자동화의 범위를 제대로 그을 수 있었다. 지금은 Tier 1과 2에서 AI가 빠르게 움직이고, Tier 3과 4에서 인간의 판단이 들어가는 균형이 잡혀 있다. AI에게 주도권을 빼앗기지 않으려면 AI를 억제하는 것이 아니라, 언제 개입해야 하는지 명확히 합의해야 한다. 결국 자율화는 권한을 나누는 디자인이지, 모든 일을 맡기는 기술이 아니다.