에이전트를 팀에 도입하는 논의는 대부분 '어떤 도구를 쓸 것인가'로 시작한다. Cursor냐, Copilot이냐, Claude Code냐. 그런데 정작 중요한 질문은 따로 있다. 에이전트가 실제로 무언가를 하려는 순간, 누가 혹은 무엇이 그것을 검증하는가. 도구 선택보다 훨씬 앞서 설계해야 할 문제다.
최근 세 가지 흐름이 이 질문을 서로 다른 각도에서 조명하고 있다. velog에 올라온 GitHub Kanban 기반 AI 워크플로우 사례, dev.to의 'Agent Governance as Code' 프레임워크, 그리고 실행 경계에 암호화 증명을 도입하는 오픈소스 프로젝트 Actenon Kernel. 각각 개인 프로젝트, 팀 코드베이스, 시스템 아키텍처 레벨에서 같은 문제를 다룬다. 에이전트에게 자유를 주되, 통제 불가능한 상태로 두지 않는 법.
Kanban을 에이전트 상태 머신으로 쓰기
첫 번째 사례가 흥미로운 이유는 별도 인프라 없이 GitHub 기존 도구만으로 에이전트 워크플로우를 구성했기 때문이다. 핵심 아이디어는 단순하다. Kanban 컬럼 = 현재 책임 소재. Backlog → Plan Review → Dev Ready → Dev Review → QA Ready → QA Review → Ready To Deploy → Done. 각 컬럼은 '지금 이 작업에 대해 누가 공을 갖고 있는가'를 명시한다.
Design Agent가 설계안을 만들면 Issue는 Plan Review로 이동한다. 사람이 승인하기 전까지 Dev Agent는 손대지 않는다. Dev Agent가 구현을 마치면 Dev Review로 넘어간다. 역시 사람이 확인해야 QA Agent가 실행된다. QA가 통과해도 사람이 직접 화면을 확인해야 Done이 된다. 에이전트는 각 단계에서 정해진 일을 할 뿐, 다음 단계로 스스로 진행하지 않는다.
테크 리드 입장에서 이 구조의 실용적 가치는 명확하다. 새로운 대시보드나 전용 플랫폼 없이, 팀이 이미 쓰는 GitHub 위에 에이전트 워크플로우를 올릴 수 있다. 도입 비용이 낮고, 상태가 코드 변경 이력과 같은 위치에 기록된다. 온보딩도 쉽다. GitHub 쓸 줄 아는 개발자라면 워크플로우를 바로 읽을 수 있다.
린터처럼 설계하는 에이전트 정책
Kanban이 '흐름'을 관리한다면, dev.to에서 제안된 Agent Governance as Code 프레임워크는 '규칙'을 코드처럼 관리한다. 발상 자체가 명쾌하다. ESLint가 사람이 작성한 코드를 감사하듯, 에이전트가 작성한 코드와 행동도 정책 레이어가 감사해야 한다는 것.
구조는 네 레이어로 나뉜다. Layer 1: AGENTS.md — 자연어로 작성된 규칙 파일. 에이전트와 사람 모두 읽는다. 리포지토리 안에 살기 때문에 PR로 변경 이력을 추적할 수 있다. Layer 2: AGENTS.policy.json — CI/CD와 자동화 훅이 프로그래밍적으로 읽는 머신 리더블 제약 조건. Layer 3: agent-guard.sh — 프리커밋이나 CI 게이트에서 실행되는 런타임 강제 스크립트. Layer 4: PR 체크리스트 — 최종 사람 승인과 감사 트레일.
AGENTS.md의 구조가 특히 주목할 만하다. 에이전트가 시작할 수 있는 전제 조건(이슈 상태, 도메인 권한, 릴리즈 프리즈 여부), 절대 건드리면 안 되는 파일 목록(인증 레이어, 스키마 마이그레이션, 시크릿, CI/CD 파이프라인 정의), 금지된 Git 명령어(git add -A, git push --force 등)를 명시적으로 선언한다. 에이전트에게 '하면 안 되는 것'을 프롬프트가 아니라 버전 관리되는 정책 파일로 정의하는 것. 이 차이가 크다.
모노레포 환경에서는 패키지별로 AGENTS.md를 둘 수 있고, 충돌 시 가장 제한적인 규칙이 우선 적용된다. 인프라 패키지 에이전트는 웹 패키지 에이전트보다 훨씬 엄격한 규칙 아래 동작한다. 팀 규모가 커지고 코드베이스가 복잡해질수록 이런 계층적 정책 설계가 필수가 된다.
프롬프트가 아니라 실행 경계가 마지막 방어선이다
세 번째 관점은 가장 급진적이다. Actenon Kernel 프로젝트는 에이전트 안전 문제의 진짜 순간이 어디인지를 정확히 짚는다. 프롬프트를 아무리 잘 써도, 에이전트가 실제로 무언가를 실행하려는 순간 그 프롬프트는 더 이상 통제 수단이 아니다. 통제 수단은 실행 경계(execution boundary)다.
시나리오를 생각해보자. 에이전트가 환불 API를 호출한다. 정상적인 경우라면 문제없다. 그런데 프롬프트 인젝션으로 오염됐거나, 단순히 잘못된 판단을 했거나, 같은 작업을 두 번 반복한다면? API는 그냥 실행된다. IAM이 해당 에이전트에게 환불 권한을 부여했기 때문이다. IAM은 '누가 접근할 수 있는가'를 답하지만, '지금 이 정확한 파라미터로 이 정확한 액션이 허용되는가'는 답하지 않는다.
Actenon의 접근은 실행 직전에 암호화 증명을 요구하는 것이다. 해당 증명은 액션 이름, 파라미터, 대상 리소스, 만료 시간, 리플레이 방지 정보를 모두 바인딩한다. 증명이 없거나, 만료됐거나, 파라미터가 다르거나, 리플레이 시도라면 사이드 이펙트 함수 자체가 실행되지 않는다. 모델이 올바르게 동작할 것이라는 신뢰 대신, 실행 가능 여부를 결정론적으로 만드는 것이다.
MCP(Model Context Protocol)가 에이전트의 도구 접근을 쉽게 만들수록 이 레이어의 중요성은 올라간다. 파일시스템, 데이터베이스, 배포 파이프라인, 결제 시스템에 에이전트가 쉽게 닿을 수 있다는 것은 편리함과 동시에 폭발 반경이 넓어진다는 의미다.
세 레이어를 하나의 설계로 묶기
이 세 가지 접근은 서로 다른 레벨에서 같은 원칙을 구현한다. Kanban 상태 머신은 워크플로우 레벨에서 에이전트의 행동 순서와 사람 개입 지점을 설계한다. Agent Governance as Code는 코드베이스 레벨에서 에이전트의 허용 범위와 금지 행동을 정책 파일로 버전 관리한다. 실행 경계 + 암호화 증명은 시스템 레벨에서 개별 액션의 실행 가능 여부를 결정론적으로 제어한다.
팀 리빌딩 관점에서 현실적인 도입 순서를 제안하자면 이렇다. 먼저 GitHub Kanban 기반 워크플로우로 에이전트 역할과 사람 개입 지점을 명시화한다. 비용이 가장 낮고 팀 전체가 공유하는 시각적 구조를 만들 수 있다. 다음으로 AGENTS.md를 리포지토리에 추가한다. 에이전트가 건드릴 수 없는 영역을 명문화하는 것만으로도 '에이전트가 왜 이걸 했는가'를 추적하는 디버깅 비용이 크게 줄어든다. 결제, 배포, IAM 변경처럼 되돌리기 어려운 액션에 에이전트가 접근하는 시스템이라면, 실행 경계 레이어를 별도로 설계해야 한다.
결국 핵심 명제는 단순하다. 에이전트를 팀에 풀기 전에 경계를 먼저 설계하라. 경계 없는 에이전트는 빠르게 움직이는 것처럼 보이지만, 팀이 치르는 수습 비용은 그 속도를 금방 상쇄한다. 프롬프트를 정교하게 쓰는 것은 에이전트를 잘 부리는 방법이지, 통제하는 방법이 아니다. 통제는 워크플로우 설계, 정책 파일, 실행 경계—세 레이어가 함께 만드는 것이다.