거버넌스 없는 에이전트는 팀 리스크다
AI 에이전트를 프로덕션에 올리는 팀이 늘고 있다. 그런데 대부분의 팀이 놓치는 게 있다. LangChain이든 CrewAI든 AutoGen이든, 이 프레임워크들은 에이전트를 어떻게 만드는가를 해결한다. 정작 어떻게 다스리는가는 팀 몫으로 남겨둔다. 에이전트가 한 명일 때는 괜찮다. 세 명이 되는 순간 문제가 시작된다. A가 쓴 파일을 B가 덮어쓴다. 내부 전략 문서가 외부 플랫폼에 올라간다. 두 에이전트가 같은 질문에 반대 결론을 낸다. 프레임워크는 이 문제를 해결해주지 않는다.
파일 5개로 세 에이전트를 운영하는 방법
dev.to에 공개된 실제 운영 사례는 이 문제를 놀랍도록 단순하게 풀었다. 전략·아키텍처·정찰을 담당하는 세 에이전트를 파일 5개로 통제한다.
- AGENTS.md: 행동 경계를 세 가지 색으로 구분한다. 초록(파일 읽기·코드 작성·테스트)은 승인 불필요, 노랑(외부 포스팅·PR)은 실행 후 통보, 빨강(헌법 수정·타 에이전트 작업공간 접근)은 중단 후 에스컬레이션. 핵심 설계 원칙은 하나다. 경계는 에이전트가 할 수 있는 것이 아니라 잘못될 수 있는 것을 기준으로 정의한다.
- CONSTITUTION.md: 팀 밖으로 절대 나가면 안 되는 다섯 가지(크리덴셜, 장기 전략, 아키텍처 블루프린트, 운영자 개인정보, 내부 커뮤니케이션 로그). 30초 안에 읽을 수 있는 분량으로 유지한다. 에이전트는 매 시작 시 이 파일을 읽는다.
- EXTERNAL_COMMS_POLICY.md: 외부 액션 전 다섯 가지 질문 체크리스트. 실제로 영어 플랫폼에 중국어 글이 올라가는 실수를 이 파일이 잡아냈다.
- 메시지 채널 규칙:
messages/디렉토리에 읽지 않은 것(new/)과 아카이브(read/)를 분리하고, 파일명 컨벤션을 강제한다. 컨텍스트 윈도우가 매 세션 초기화되는 에이전트에게 파일시스템이 유일한 영속 메모리라는 점을 감안하면, 이건 사소한 규칙이 아니다. - 역량 배지 시스템: 검증된 액션마다 배지를 부여하고, 성공·실패·학습을 기록한다. 7일간 배지가 없으면 자기감사가 트리거된다.
이 패턴의 본질은 권한 제어가 아니다. 올바른 행동을 가장 쉬운 행동으로 만드는 것이다.
AI가 생성한 코드, 품질 게이트는 파이프라인이 책임진다
에이전트가 코드를 생성하는 팀이라면 거버넌스의 절반은 행동 경계고, 나머지 절반은 코드 품질 자동화다. 아키텍처 에이전트가 Flask 앱을 뚝딱 만들어냈을 때, 그 코드 안에 하드코딩된 크리덴셜이나 shell=True 서브프로세스 호출이 숨어 있다면? 사람이 리뷰하기 전에 파이프라인이 먼저 잡아야 한다.
dev.to의 Bandit SAST 실무 사례는 이 문제에 대한 현실적인 답을 보여준다. Python 전용 SAST 도구인 Bandit은 설치가 가볍고 CLI 실행이 단순하며, GitHub Actions와의 통합이 쉽다. 데모 Flask 앱에서 잡아낸 취약점 목록은 AI 생성 코드에서 흔히 발생하는 패턴과 정확히 겹친다. 하드코딩 패스워드, shell=True 명령 인젝션 위험, MD5 약한 해시, 디버그 모드 노출. 이건 AI가 특별히 나쁜 코드를 짜서가 아니라, 빠르게 작동하는 코드를 짤 때 보안 컨텍스트가 후순위로 밀리기 때문이다.
GitHub Actions 워크플로우 한 개로 모든 푸시와 PR에서 자동 스캔이 돌아간다. 에이전트가 코드를 올리는 속도만큼 탐지도 빨라진다.
최소 거버넌스 스택: 오늘 당장 실행 가능한 조합
두 사례를 조합하면 AI-First 팀의 최소 거버넌스 스택이 나온다.
| 레이어 | 도구/파일 | 역할 |
|---|---|---|
| 행동 경계 | AGENTS.md |
에이전트가 매 시작 시 읽는 색깔 존 경계 |
| 정보 보호 | CONSTITUTION.md |
절대 외부로 나가면 안 되는 레드라인 |
| 외부 통신 | EXTERNAL_COMMS_POLICY.md |
외부 액션 전 5문항 체크리스트 |
| 코드 품질 | Bandit + GitHub Actions | 매 PR마다 SAST 자동 스캔 |
| 추적·학습 | 배지 시스템 | 성공/실패 기록과 자기감사 트리거 |
핵심은 이 스택이 복잡한 시스템이 아니라는 점이다. 파일 다섯 개와 CI 워크플로우 파일 하나. 도구를 더 사는 게 아니라 설계를 파일시스템에 심는 것이다.
팀 리더가 먼저 물어야 할 질문
에이전트 거버넌스를 설계할 때 내가 팀에 던지는 질문은 하나다. "에이전트가 지금 당장 잘못된 행동을 하면, 우리 시스템이 그걸 막을 수 있는가?" 대부분의 팀이 "아마도" 또는 "사람이 리뷰할 때 잡겠지"라고 답한다. 그건 거버넌스가 아니라 기도다.
AGENTS.md 한 파일이 에이전트의 행동 경계를 명문화하고, Bandit이 CI에서 보안 취약점을 자동으로 잡아낸다면, 팀은 에이전트 속도를 그대로 유지하면서 리스크를 구조적으로 줄일 수 있다. 학습 곡선도 낮다. Bandit은 pip install bandit 한 줄이고, AGENTS.md는 마크다운 파일이다.
거버넌스는 나중에 추가하는 기능이 아니다. 에이전트를 팀 인프라로 올리기 전에 파일시스템에 먼저 심어야 하는 설계 패턴이다. 그리고 그 시작은 생각보다 훨씬 단순하다.