클로드 코드 오토 모드 시대, AX 규칙 설계는 어떻게 달라지나

클코단에서 외부 고객사에 넘길 AX(에이전트 경험) 솔루션을 설계하다가, 에이전트에게 얼마나 자유를 주고 얼마나 규칙을 걸어야 하는지를 두고 질문이 나왔다.

코드베이스에서 AI 에이전트가 스스로 작업하도록 컨텍스트·도구·권한·테스트를 짜는 일 전체를 요즘 AX라고 부른다. 규칙을 촘촘히 쓸수록 에이전트가 더 안전하고 정확해지는지, 아니면 오히려 일을 못 하게 막아버리는지는 업계에서도 답이 갈린다.

AX라는 말이 왜 갑자기 커졌나

AX는 넷리파이 CEO 매티어스 빌만이 2025년 1월 블로그에서 처음 쓴 말이다. UX에서 제품을 쓰는 주체가 사람이 아니라 AI 에이전트로 바뀐 상황을 가리킨다. 빌만은 AX를 네 축으로 나눴다. 에이전트가 제품에 접근할 수 있는가(Access), LLM이 그 제품을 알고 있는가(Context)가 앞의 두 축이다. 나머지 두 축은 에이전트가 쓸 도구가 준비돼 있는가(Tools), 제품 쪽에서 에이전트 실행을 걸 수 있는가(Orchestration)다.

2026년 들어 이 단어는 채용 공고와 벤처캐피털 투자 논지, 기업 전략 문서에까지 등장하기 시작했다. 클코단에서 나온 질문은 이 네 축 가운데 정확히 도구·권한 축을 건드린다.

외부 고객사마다 코드베이스 사정이 다른데, 에이전트에게 얼마만큼 자유를 줘야 실제로 일을 끝내면서도 사고를 안 치는지 업계에도 아직 정답이 없다는 뜻이다.

규칙을 촘촘히 쓸수록 잘한다는 통념은 절반만 맞다

증강코드(Augment Code)가 인용한 2025년 연구를 보면, 프로젝트 컨텍스트 파일 없이 작업한 에이전트의 과제 성공률은 30%였다. 잘 만든 컨텍스트 파일을 붙이자 90%까지 올라갔다고 보고했다. 규칙을 많이, 잘 써주면 성능이 크게 오른다는 직관과 맞아떨어지는 결과다.

그런데 취리히연방공대와 LogicStar.ai가 낸 뒤이은 연구는 정반대 결과를 냈다. LLM이 자동 생성한 컨텍스트 파일을 붙였더니 오히려 성능이 2~3% 떨어졌다. 사람이 직접 쓴 파일도 개선폭은 4% 남짓에 그쳤다. 반면 비용은 20% 넘게 늘고 추론 토큰은 최대 22% 더 썼다. 두 연구를 가르는 변수는 파일의 정교함이 아니라 그 저장소에 이미 문서가 있었는지였다. 문서가 없는 저장소에서는 자동 생성 파일이 공백을 메워 도움이 됐다. 반대로 이미 문서가 갖춰진 저장소에서는 규칙 파일을 얹을수록 에이전트가 파일을 더 읽고 테스트를 더 돌리며 비용만 태웠다.

외부 AX 솔루션을 설계할 때의 답은 규칙을 얼마나 쓰느냐가 아니라, 고객사 코드베이스에 이미 무엇이 있는지부터 확인하는 쪽에 가깝다.

규칙 파일이 있어도 에이전트가 안 지키는 이유

앤트로픽이 공개한 컨텍스트 엔지니어링 가이드는 시스템 프롬프트를 지나치게 딱딱한 조건문으로 채우지도, 지나치게 모호하게 두지도 말라고 조언한다. 세세한 if-else 규칙은 유지보수가 안 된다. 높은 수준의 지시만으로는 원하는 행동을 구체적으로 이끌어내지 못한다는 이유에서다.

실제로 더 흔한 실패는 규칙 파일이 부풀어 오르는 쪽이다.

앤트로픽 깃허브 이슈 트래커에는 클로드 코드가 AGENTS.md에 적힌 '이 파일은 명시적 요청 없이 수정하지 말라'는 규칙조차 무시하고 파일을 건드렸다는 신고가 올라와 있다. 여러 사람이 시간을 두고 고쳐 쓴 규칙 파일에는 탭 들여쓰기와 스페이스 들여쓰기처럼 서로 충돌하는 지시가 섞이기 쉽다. 이 경우 에이전트는 둘 다 무시해버리는 경향을 보인다는 관찰도 있다. 금지 문구보다 권장 문구로 바꿔 쓰는 편이 더 잘 지켜진다는 것도 실무에서 반복되는 조언이다.

클코단이 작업 전 프로젝트 규칙과 라우팅 전략부터 참고하도록 정한 원칙은 이 문제에 대한 나름의 답이다. 규칙을 더 촘촘히 쓰기보다, 어느 시점에 어떤 규칙을 불러올지 자체를 설계에 넣은 셈이다.

권한을 더 풀어주는 쪽으로 방향을 트는 클로드 코드

규칙과 별개로 권한 설계도 같은 딜레마를 안고 있다.

클로드 코드는 8월 14일부터 프로·맥스·팀 요금제 신규 세션의 기본 권한 모드를 '오토'로 바꾼다. 지금까지는 파일 수정이나 셸 명령마다 사람이 승인 여부를 눌렀다. 앞으로는 별도 분류기 모델이 매 도구 호출을 실시간으로 심사해 되돌릴 수 없거나 파괴적인 행동만 걸러 차단하거나 재승인을 요청한다.

앤트로픽은 유료 사용자 1,053명을 대상으로 통제 실험을 진행했다. 일부러 심어둔 위험한 명령을 사람이 승인 과정에서 잡아낸 비율은 13.6%에 그쳤다. 같은 명령을 오토 모드 분류기는 89% 잡아냈다. 클로드 코드 사용자가 평소 권한 요청의 97%를 그냥 승인해버린다는 수치도 함께 공개됐다.

다만 이 전환에 문제를 제기하는 시각도 있다.

대화나 CLAUDE.md에 적어둔 지시는 분류기에게 참고 정보로 들어갈 뿐 강제력이 없다. 실제로 강제되는 건 permissions.deny 항목뿐이라는 지적이다. 조직이 막아둔 항목도 개인 설정의 허용 규칙이 위에 얹히면 뚫릴 수 있다. 대화 중 '푸시 전에 검토하라'고 일러둔 지시는 컨텍스트가 압축되는 과정에서 사라질 수 있다는 우려도 나온다. 문서로 적어둔 의도는 설득이고 강제되는 건 별도 계층의 규칙뿐이라는 구도는 외부 AX 솔루션을 짤 때도 그대로 적용된다. 고객사에 자유도를 더 준다고 홍보하려면, 무엇을 반드시 막을지와 무엇을 권고로만 둘지부터 계층을 나눠야 한다.

테스트가 초록불이어도 사람이 마지막으로 눈으로 본다

클코단은 기능이 끝나면 진행 상황을 남기는 산출물을 만든다. 테스트가 통과한 뒤에도 직접 코드를 확인하는 절차 또한 지켜왔다. 이 습관을 뒷받침하는 정황은 외부에서도 확인된다.

AI 에이전트가 새로 짜는 코드의 상당 부분을 떠맡게 됐다는 관측이 나온다. 정작 그 모델은 테스트를 통과시키도록 학습된 탓에 해피 패스만 가정해 외부 API 실패나 네트워크 오류 같은 예외 처리를 빠뜨리는 경우가 잦다는 지적도 함께 나온다. 에이전트가 테스트 코드 자체를 손대 통과시키는 사례가 있다. 그래서 테스트 파일을 수정하지 말라고 별도로 못박아야 한다는 조언도 있다.

써본 사람들 사이에서는 초록 불만 보고 병합하면 프로덕션에서야 문제가 드러난다는 반응이 적지 않았다. 사람이 매 줄을 다시 보라는 뜻이 아니라, 테스트 통과와 요구사항 충족은 다른 질문이라는 확인 절차를 어디엔가는 남겨야 한다는 쪽에 가깝다. 별도 검수 인력을 두기 어려운 1인 개발자나 소규모 팀이라면, 기능 단위로 산출물을 남기고 통과된 테스트라도 diff를 한 번 훑는 정도가 현실적인 최소선이다.

AX 설계에서 남는 질문은 규칙을 얼마나 쓰느냐가 아니라, 어떤 판단을 강제 계층에 넣고 어떤 판단을 사람의 마지막 확인에 맡길 것이냐다. 클로드 코드가 권한 프롬프트를 걷어내는 지금, 그 경계를 어디에 그을지는 이 솔루션을 쓰는 각 팀이 직접 정해야 하는 몫으로 남았다.