에이전트는 돌고 있다. 그런데 무슨 일이 있었는지 아는가?
에이전트를 팀 워크플로우에 붙이고 나서 가장 먼저 받는 질문이 있다. "잘 되고 있어요?" 대부분의 팀이 이 질문에 대답하지 못한다. 로그는 있다. CI도 돌고 있다. AGENTS.md도 작성했다. 그런데 에이전트가 이번 세션에서 어떤 도구를 호출했고, 어떤 판단을 내렸고, 어떤 상태를 바꿨는지를 한 곳에서 꺼내 볼 수 없다. 이것이 거버넌스 부재가 만드는 가장 흔한 첫 번째 실패 패턴이다.
이번 주 dev.to에서 서로 다른 레이어를 건드리는 세 개의 신호가 동시에 올라왔다. Anthropic의 대규모 실증 연구, 저장소 계약 도구 Ota의 거버넌스 프레임, 그리고 MCP 런타임 레코드를 위한 Armorer 프로젝트. 세 신호는 출처도, 접근 각도도 다르지만 같은 방향을 가리킨다. 에이전트 거버넌스는 선언 문서가 아니라 실행 기록에서 시작된다.
Anthropic이 측정한 것, 그리고 측정하지 않은 것
Anthropicが 발표한 "Agentic coding and persistent returns to expertise" 연구는 약 40만 건의 Claude Code 인터랙티브 세션, 23만 5천 명을 대상으로 2025년 10월부터 2026년 4월까지 수집한 데이터를 분석했다. 핵심 발견은 명확하다. 도메인 전문성이 높은 사람일수록 에이전트가 프롬프트당 더 많은 작업을 수행한다. 전문가 세션은 초보자 세션 대비 Claude 액션 수가 약 2.4배, 텍스트 출력은 약 5배 많았다. 신호는 단순히 "코딩을 아느냐"가 아니라 "문제를 충분히 이해해서 에이전트를 조종할 수 있느냐"에서 왔다.
이 연구가 측정하지 않은 것이 중요하다. Anthropic의 스코프는 인터랙티브 세션 내 작업량과 성공 패턴이었다. 에이전트가 세션 간에 상태를 어떻게 이어받는지, 의사결정 이력이 어떻게 축적되는지, 거버넌스 규칙이 어떻게 작동하는지는 연구 범위 밖이다. 인간 쪽 변수는 측정됐다. 에이전트 쪽 인프라는 아직 실증의 대상이 아니다. 이 공백이 나머지 두 신호가 채우려는 영역이다.
저장소 자체가 거버넌스 계약이어야 한다
Ota 프로젝트(dev.to/otaready)가 제기하는 문제는 팀 대부분이 겪고 있지만 이름 붙이지 못한 것이다. README는 있다. AGENTS.md도 있다. CI 워크플로우도 정의되어 있다. 그런데 에이전트는 여전히 틀린 명령을 실행하고, 새 컨트리뷰터는 같은 곳에서 막힌다. 이것은 문서화 실패가 아니다. 거버넌스 실패다.
문서는 무엇이 일어나야 하는지 설명한다. 거버넌스는 저장소가 실제로 어떤 규칙으로 운영되는지를 선언한다. Ota는 이 간극을 ota.yaml 계약으로 채운다. 어떤 툴체인이 필요한지, 셋업 경로가 무엇인지, 에이전트가 실행해도 안전한 태스크는 무엇인지, 보호된 경로는 어디인지를 단일 권위 소스로 선언한다. ota tasks --safe --use, ota up --dry-run 같은 명령어가 있다는 것은 계약이 실행 가능한 형태로 존재한다는 의미다. 산문 설명과 실행 가능한 계약은 다른 카테고리다.
AI 에이전트가 이 문제를 만들어낸 것이 아니다. 가속시킨 것이다. 사람 팀은 사회적 복구 레이어가 있다. 동료에게 묻고, 비공식 관행을 기억하고, 명령이 "이상해 보인다"는 것을 알아챈다. 에이전트에게는 그 레이어가 없다. 저장소가 선언한 것이 전부다. 선언이 불완전하면 에이전트는 추론으로 메운다. 추론은 거버넌스가 아니다.
MCP는 에이전트에게 손을 줬다. 운영 레이어는 원장을 줘야 한다
Armorer Labs가 dev.to에 올린 짧은 글은 핵심을 바로 찌른다. MCP(Model Context Protocol)는 도구 연결을 깔끔하게 만들어줬다. 그런데 매니페스트(무엇이 존재하는가)와 런타임 레코드(에이전트가 실제로 무엇을 보고 무엇을 했는가)는 다르다.
런타임 레코드가 답해야 할 질문은 구체적이다. 이번 실행에서 어떤 MCP 서버가 연결되어 있었나? 어떤 도구 스키마가 노출됐나? 어떤 버전이 활성화됐나? 어떤 파라미터가 전달됐나? 어떤 상태가 변경됐나? 어떤 호출이 승인을 요청했나? Armorer와 Armorer Guard는 이 정보를 에이전트의 결정 기록 레이어로 쌓으려는 프로젝트다. "MCP는 에이전트에게 손을 줬다. 운영 레이어는 인간에게 원장을 줘야 한다." 이 한 문장이 MCP 거버넌스 문제를 가장 압축적으로 표현한다.
세 레이어, 하나의 결론
세 신호를 층위별로 정리하면 이렇다. Anthropic 연구는 인간-에이전트 루프에서 전문성이 멀티플라이어로 작동함을 실증했다(인간 레이어). Ota는 저장소 자체가 실행 계약을 선언해야 한다고 주장한다(저장소 계약 레이어). Armorer는 MCP 도구 실행의 런타임 기록이 없으면 사후 감사와 통제가 불가능하다고 지적한다(도구 실행 기록 레이어).
이 세 레이어가 함께 설계되지 않으면 어떤 일이 벌어지는지는 예측 가능하다. 전문성 높은 개발자가 에이전트를 잘 조종해도, 저장소 계약이 불명확하면 에이전트는 잘못된 경로로 실행된다. 저장소 계약이 있어도, MCP 도구 호출의 런타임 기록이 없으면 사고 발생 시 무슨 일이 있었는지 재구성할 수 없다. 각 레이어는 독립적으로도 가치 있지만, 세 개 중 하나만 빠져도 전체 거버넌스에 구멍이 생긴다.
팀에서 내일 당장 시작할 수 있는 것
거창한 거버넌스 프레임워크를 전사 도입하기 전에, 지금 당장 확인할 수 있는 세 가지 질문이 있다.
첫째, 에이전트가 이번 세션에서 어떤 도구를 호출했는지 단일 장소에서 꺼낼 수 있는가? 없다면 MCP 런타임 레코드 레이어가 없는 것이다.
둘째, 저장소에서 에이전트가 실행해도 안전한 태스크와 그렇지 않은 경로가 기계가 읽을 수 있는 형태로 선언되어 있는가? 산문 README만 있다면 계약 레이어가 없는 것이다.
셋째, 팀에서 에이전트 작업의 성과가 좋은 사람과 그렇지 않은 사람 사이에 어떤 차이가 있는지 측정하고 있는가? Anthropic 데이터는 전문성 격차가 에이전트 성과 격차로 직결됨을 보여준다. 이 격차를 모르면 온보딩 설계를 할 수 없다.
거버넌스는 제약이 아니라 에이전트를 더 빠르게 만드는 설계다
거버넌스라는 단어가 주는 인상은 속도를 늦추는 규제다. 실제로는 반대다. 저장소 계약이 명확할수록 에이전트가 추론에 쓰는 토큰이 줄고 실행 경로가 빨라진다. 런타임 레코드가 쌓일수록 사고 대응 시간이 단축되고 신뢰 범위를 넓힐 수 있다. 전문성 기반 위임이 설계될수록 에이전트의 자율 범위를 안전하게 늘릴 수 있다.
세 신호가 이번 주에 동시에 올라온 것은 우연이 아니다. 에이전트를 팀에 붙이고 운영하는 팀들이 각자의 실패 패턴에서 같은 결론에 수렴하고 있다는 수렴 신호다. 선언 문서는 첫 번째 단계다. 실행 기록이 쌓이기 시작할 때 거버넌스가 된다.