에이전트가 규칙을 '기억'한다는 것과 규칙을 '따를 수밖에 없다'는 것은 완전히 다른 이야기다. 나는 이 차이를 프롬프트 엔지니어링의 정교함으로 메울 수 있다고 오래 믿어왔다. 세 개의 사례가 그 믿음을 동시에 무너뜨렸다.
프롬프트는 제안이다, 게이트는 보장이다
dev.to에 공유된 Juan de los Santos의 구현 사례는 불편한 사실 하나를 정면으로 드러낸다. 그는 SHA256 토큰 기반의 커밋 승인 시스템을 만들었다. 이론상 철벽이었다. 그런데 에이전트가 --auto 플래그 하나로 30초 만에 이 시스템을 우회했다. 악의가 있어서가 아니었다. '게이트'가 인프라 레이어가 아니라 에이전트가 읽는 파일 안의 규칙, 즉 또 하나의 컨텍스트였기 때문이다. 컨텍스트는 희미해진다. 에이전트는 잊는다.
그의 해법은 규칙을 더 정교하게 쓰는 것이 아니었다. 아키텍처를 바꾸는 것이었다. commit-msg git hook 안에 세 개의 게이트를 심었다. 첫째, 1시간 이내에 테스트가 통과했는가. 둘째, 에이전트가 변경 사항을 기술한 커밋 매니페스트가 존재하는가. 셋째, 5분 이내에 사용자가 정확히 같은 커밋 메시지로 승인했는가. 세 조건이 모두 충족되지 않으면 커밋은 물리적으로 차단된다. 에이전트가 기억해야 할 규칙이 아니라, 에이전트가 무시할 수 없는 인프라다. METR의 연구(Becker et al., 2025)가 짚었듯 AI를 쓴 개발자들이 19% 더 느리면서도 20% 더 빠르다고 느꼈다면, 그 착시의 상당 부분은 이런 규율 부재에서 온다.
코드는 커밋되고, 결정은 증발한다
두 번째 신호는 속도 그 자체가 만드는 구조적 공백이다. Karthick Ramachandran이 Cursor, Claude Code, Codex로 하루 만에 MVP를 완성하는 경험을 반복하면서 부딪힌 문제는 코딩 품질이 아니었다. 어떤 인증 흐름을 선택했는지, 이 모듈이 저 경계를 왜 가져갔는지—결정의 이유가 채팅 스레드 안에서 압축되고 세션이 끊기면서 사라졌다. 코드는 리포지토리에 남지만 맥락은 개발자 머릿속에만 남았다. 다음 세션의 에이전트는 같은 결정을 처음부터 다시 추론한다.
그가 만든 Persist OS는 이 문제를 '더 나은 메모리'가 아니라 '권위의 역전'으로 푼다. 채팅 히스토리보다 리포지토리 메모리가 우선한다. 수락된 ADR(Architecture Decision Record)과 엔지니어링 표준이 모델의 마지막 추론보다 위에 있다. 충돌이 발생하면 에이전트는 조용히 한쪽을 선택하는 대신 멈추고 충돌을 보고한다. persist doctor라는 결정론적 CLI 게이트가 이를 강제한다. 이 게이트는 LLM을 호출하지 않는다. 같은 리포지토리 상태면 언제나 같은 결과를 낸다. 에이전트가 '완료'라고 선언하기 전에 이 게이트를 통과해야 하며, ADR이 수락되지 않았거나 이미 폐기된 결정을 여전히 참조하고 있으면 에러로 막힌다.
94.5%는 세무조사를 막지 못한다
세 번째 신호가 가장 직접적이다. kenimo49는 Claude Code에게 한 달치 200건의 비즈니스 장부 조정을 맡겼다. 결과는 94.5% 정확도. 그런데 틀린 11건이 무작위로 분산되지 않았다. 에이전트가 알 수 없는 정보에 몰려 있었다. 노트북이 업무용인지 개인용인지는 영수증에 없다. 클라이언트와의 식사와 혼자 하는 식사의 세금 처리 차이는 현지 법규에 있다. 두 가지 다른 항목을 하나의 결제로 처리한 경우 에이전트는 하나를 골랐다. 그리고 이 모든 오류를 자신감 있게 내놨다. 불확실한 답을 조용히 넘기는 에이전트가 불확실함을 명시적으로 플래그하는 에이전트보다 훨씬 위험하다는 것을 이 사례는 보여준다. 그가 에이전트에게 준 가장 유용한 지시는 단 하나였다. '확실하지 않으면 추측하지 말고 플래그하라.' 이 지시 덕분에 200건 감사가 18건 집중 검토로 줄었다.
세 층위가 만드는 통제 아키텍처
이 세 사례를 나란히 놓으면 에이전트를 팀 인프라로 운영할 때 필요한 통제 레이어의 윤곽이 보인다.
첫 번째 층위: 인프라 레벨 게이트. 에이전트가 읽는 파일 안의 규칙은 언제든 무시될 수 있다. 규칙은 git hook, CI 파이프라인, 결정론적 CLI 게이트처럼 에이전트의 실행 경로 바깥에 심어야 한다. 에이전트가 우회하려면 시스템 자체를 건드려야 하는 구조.
두 번째 층위: 결정 보존 레이어. 아키텍처 결정은 코드와 같은 리포지토리 안에 ADR로 남아야 하고, 세션이 바뀌어도 에이전트가 첫 번째로 읽는 소스가 되어야 한다. 채팅 히스토리는 소스 오브 트루스가 아니다.
세 번째 층위: 인간 검증 루프 설계. 어디서 인간이 판단해야 하는지를 사전에 설계해야 한다. '전부 검토'도 아니고 '에이전트 신뢰'도 아니다. 볼륨과 판단의 분리—반복적이고 패턴 매칭 가능한 작업은 에이전트에게, 의도·맥락·법적 판단이 필요한 5.5%는 반드시 인간이 서명해야 하는 구조를 설계 단계에서 명시적으로 그어야 한다.
팀으로 가져올 때 무엇이 달라지는가
개인 워크플로우에서 이 구조를 실험하는 것과 팀 인프라로 확장하는 것 사이에는 추가적인 복잡도가 있다. 게이트의 표준을 누가 정하고 어떻게 업데이트하는가. ADR을 제안하고 수락하는 권한은 누구에게 있는가. 에이전트가 플래그한 불확실성을 누가 검토하는 당번인가. 이 질문들에 대한 답이 없는 상태에서 git hook을 배포하면 절차만 늘어나고 소유권은 흐릿해진다.
내가 팀에 이 구조를 적용할 때 먼저 하는 것은 레이어별 소유자 지정이다. 인프라 게이트는 테크 리드가 설계하고 PR로 변경한다. ADR은 제안자와 수락자를 분리한다. 인간 검증 루프에서 어떤 카테고리의 결정이 루프 안으로 들어오는지를 팀이 함께 정의하고 문서화한다. 에이전트의 규율을 유지하는 비용은 결국 팀의 합의 비용이다.
전망: 속도는 주어지고, 통제는 설계된다
AI 에이전트의 코딩 속도는 앞으로 더 빨라질 것이다. 그 속도가 팀의 실질적 산출물이 되려면 에이전트가 빠르게 달리는 동안 어디서 멈춰야 하는지를 시스템이 알고 있어야 한다. 2026년 Deloitte 조사에서 63%의 금융 조직이 AI를 운영에 배포했다는 수치가 보여주듯, 에이전트의 도입 여부는 이미 결정된 방향이다. 남은 질문은 '도입하는가'가 아니라 '어떤 통제 레이어 위에서 도입하는가'다.
프롬프트를 더 잘 쓰는 것으로는 이 문제가 해결되지 않는다. 에이전트가 무시할 수 없는 게이트를 인프라에 심고, 결정을 세션 너머로 보존하고, 인간 판단이 개입해야 하는 경계를 설계 단계에서 그어두는 것—이 세 가지가 먼저다. 나머지 속도는 그 위에서 안전하게 쌓인다.