MCP·A2A·AGENTS.md 늘 때 회사가 먼저 정할 운영 표준 2026

Posted on by

2026년 5월 기준 MCP, A2A, AGENTS.md는 모두 AI 에이전트 운영을 편하게 만들지만, 회사 입장에서는 먼저 권한·로그·실패복구·문서 위치를 표준화해야 한다.

요즘 에이전트 도입 이야기를 하면 이름이 먼저 쏟아집니다. MCP, A2A, AGENTS.md, skills, subagents, harness, sandbox. 이름표만 보면 이제 AI가 알아서 도구를 붙이고, 에이전트끼리 일감을 나누고, repo 규칙까지 읽어서 깔끔하게 처리할 것 같습니다.

내 로컬 워크스페이스에서도 비슷한 문제가 먼저 나왔습니다. .claude/agents/에는 실제 운영 워크플로가 있고, .claude/skills/에는 단일 작업 스킬이 있고, 루트 AGENTS.md에는 Codex와 Claude Code가 지켜야 할 운영 규칙이 있습니다. 편해지긴 했는데, 규칙을 나누지 않으면 다음 질문이 바로 튀어나옵니다. “이 에이전트는 어디까지 실행해도 되지?”

이 글은 MCP나 A2A를 소개하는 글이 아닙니다. 회사에서 에이전트 표준이 늘어날 때, 도입 전에 먼저 정해야 할 운영 기준을 정리한 글입니다. 멋진 데모는 금방 만들 수 있지만, 사고가 났을 때 설명 가능한 운영표는 생각보다 늦게 만들어집니다. 그 늦음이 비쌉니다.

먼저 나눌 것

표준/파일 주로 푸는 문제 회사가 먼저 정할 것
MCP 에이전트가 도구와 데이터에 접근 서버별 권한, 승인, 로그, 비밀키 보관
A2A 서로 다른 에이전트가 작업을 주고받음 agent card, 인증, 위임 범위, 실패 시 인계
AGENTS.md repo 안에서 코딩 에이전트가 규칙을 읽음 위치, 우선순위, 금지 명령, 테스트 기준
Skills/Commands 반복 작업을 재사용 가능한 절차로 분리 입력·출력 계약, 검증 명령, 버전 관리
Harness/Sandbox 실행과 복구를 안정화 격리, 재시작, 상태 파일, 감사 로그

Anthropic의 Model Context Protocol은 AI 애플리케이션이 외부 도구와 데이터 소스에 연결되는 방식을 표준화하려는 흐름입니다. Google이 공개한 A2A는 서로 다른 에이전트가 통신하고 작업을 위임하기 위한 프로토콜입니다. AGENTS.md는 더 로컬한 층입니다. repo 안에서 에이전트가 어떤 규칙을 따라야 하는지 알려주는 문서입니다.

이 셋을 한 상자에 넣으면 운영 기준이 흐려집니다. MCP는 “무엇에 접근할 수 있나”를 묻고, A2A는 “누구에게 일을 넘길 수 있나”를 묻고, AGENTS.md는 “이 코드베이스에서는 어떻게 일해야 하나”를 묻습니다. 질문이 다르면 표준도 다르게 관리해야 합니다.

권한 등급표가 먼저다

OpenAI는 2026년 4월 Agents SDK 업데이트에서 MCP, AGENTS.md, skills, shell, apply patch, sandbox 같은 구성요소를 에이전트 실행 루프의 primitive로 설명했습니다. 이 조합은 강합니다. 파일을 읽고, 명령을 실행하고, 패치를 만들고, 외부 도구를 부를 수 있습니다.

강하다는 말은 회사 운영에서는 위험 등급을 붙여야 한다는 뜻입니다. MCP 서버가 문서를 읽는 것과 GitHub release를 만드는 것, 결제 API를 호출하는 것, 프로덕션 DB를 수정하는 것은 같은 “도구 사용”이 아닙니다. 그런데 설정 화면에서는 모두 MCP 서버 하나처럼 보일 수 있습니다.

등급 예시 기본 정책
Read-only 문서 검색, 코드 검색, 이슈 조회 기본 허용, 호출 로그 남김
Draft PR 초안, 문서 초안, 티켓 초안 허용, 사람 확인 후 반영
Mutating 이슈 상태 변경, 브랜치 push, 시트 쓰기 승인 필요
High-risk 배포, 결제, 고객 데이터 변경, 주문 기본 차단 또는 별도 승인

내가 운영 표준을 만든다면 MCP 서버 이름부터 권한이 보이게 둡니다. github-read, github-pr-draft, github-release-write처럼 이름만 봐도 위험도가 보이게 만드는 방식입니다. 귀여운 별칭은 문서 제목에만 두고, 실행 권한에는 최대한 건조한 이름을 쓰는 편이 안전합니다.

AGENTS.md는 길게 쓰는 문서가 아니다

AGENTS.md는 README의 에이전트 버전처럼 보이지만, 실제로는 실행 정책에 가깝습니다. AGENTS.md 공식 사이트는 이 파일을 AI 코딩 에이전트를 위한 개방형 형식으로 설명하고, 여러 도구가 같은 repo 규칙을 읽을 수 있게 하는 데 초점을 둡니다. OpenAI Codex도 repo 안의 AGENTS.md로 테스트 명령, 코드베이스 탐색법, 프로젝트 표준을 안내받을 수 있습니다.

여기서 흔한 실수는 루트 AGENTS.md에 모든 것을 밀어 넣는 것입니다. 회사 철학, 배포법, DB 규칙, 프론트 디자인 규칙, 보안 예외, 개인 취향까지 다 넣으면 에이전트는 매번 긴 문서를 들고 시작합니다. 사람도 회의 전에 80쪽 문서 받으면 표정이 멈춥니다. 에이전트도 컨텍스트가 무거워집니다.

위치 넣을 것 빼야 할 것
루트 AGENTS.md 공통 원칙, 금지 명령, 기본 테스트 팀별 긴 절차
하위 폴더 AGENTS.md 해당 모듈 실행법, 테스트, 스타일 전사 공통 철학
skill/runbook 반복 작업 절차, 검증, 예외 처리 한 번 쓰고 버릴 설명
automation config 스케줄, 입력, 실행 환경 일반 설명문

내 작업 폴더 기준으로도 이 분리가 중요했습니다. 루트에는 공통 행동 원칙이 있고, .claude/agents에는 실제 작업자, .claude/skills에는 단일 작업 절차, .claude/rules에는 블로그·트레이딩·위키 같은 도메인 규칙이 있습니다. Obsidian 작업은 앱 포커스를 건드리지 않는 no-focus 모드가 기본입니다. 이 구조가 좋은 이유는 멋져서가 아니라, 사고가 났을 때 어떤 규칙이 적용됐는지 추적하기 쉽기 때문입니다.

A2A는 에이전트 채팅방이 아니다

A2A를 처음 보면 에이전트들이 서로 대화하며 일을 나눠 하는 그림이 떠오릅니다. 하지만 실제 운영에서는 대화보다 계약이 먼저입니다. Google은 A2A를 에이전트 간 상호운용성을 위한 개방형 프로토콜로 설명하면서, agent card, capability, authentication, task 같은 개념을 다룹니다. 이 말은 에이전트가 아무에게나 일을 던지는 구조가 아니라, 자기 정체성과 능력, 접근 방법을 명시해야 한다는 뜻입니다.

회사에서 A2A를 검토한다면 agent card에 최소한 이 정보가 있어야 합니다.

항목 질문
identity 이 에이전트는 누구 소유인가
capability 어떤 작업만 할 수 있는가
input contract 어떤 입력을 받아야 하는가
output contract 결과를 어떤 형식으로 돌려주는가
auth 누가 호출할 수 있는가
escalation 실패하거나 위험할 때 누구에게 넘기는가

이 표 없이 A2A를 붙이면 협업 자동화가 아니라 책임 분산 장치가 됩니다. 특히 여러 팀이 만든 에이전트가 섞이면 같은 단어도 다르게 해석할 수 있습니다. “검토해줘”가 어떤 팀에는 코드리뷰이고, 어떤 팀에는 보안 승인이고, 어떤 팀에는 블로그 초안 검수일 수 있습니다. 자연어가 편한 만큼 계약은 더 딱딱해야 합니다.

로그와 감사 기준은 도입 전에 정한다

OpenAI의 “Running Codex safely” 글은 Codex 운영에서 접근 권한, 승인, 네트워크 제어, MCP 사용, telemetry 같은 통제를 강조합니다. 이 지점이 회사 도입의 핵심입니다. 에이전트가 일을 잘했는지보다 먼저, 무슨 일을 했는지 설명할 수 있어야 합니다.

로그는 많을수록 좋은 게 아닙니다. 너무 많이 남기면 개인정보와 비밀이 섞이고, 너무 적게 남기면 사고 때 아무것도 설명하지 못합니다. 그래서 로그도 등급을 나눠야 합니다.

로그 남길 내용 남기지 않을 내용
request log 작업 목적, 요청 시간, 승인자 고객 개인정보 원문
tool log 호출한 도구, 성공·실패, 결과 요약 비밀키, 토큰, 원문 dump
change log 수정 파일, diff 요약, 테스트 결과 불필요한 전체 파일 복사
approval log 누가 어떤 위험 작업을 승인했나 사적인 대화 전문

실무에서는 “실행 증거”와 “민감정보”를 분리하는 게 중요합니다. Gmail을 읽는 에이전트가 있다면 본문 전체를 로그로 남기는 게 아니라 발신자, 시간, 처리 결과 정도로 줄여야 합니다. 일정도 마찬가지입니다. 자동화가 똑똑해질수록 로그는 더 조심스러워져야 합니다.

실패복구 표준이 없으면 자동화가 오래 못 간다

에이전트 도입에서 자주 빠지는 부분이 실패복구입니다. 데모에서는 성공 경로만 보여줍니다. 실제 업무에서는 API rate limit, 인증 만료, 파일 충돌, 테스트 실패, 권한 거절, 네트워크 장애가 계속 나옵니다.

그래서 프레임워크보다 runbook이 먼저일 때가 많습니다. 실패했을 때 재시도할지, 중단할지, 사람에게 넘길지, 상태 파일을 어디서 복원할지 정해야 합니다. 단순한 프롬프트 자동화와 운영 가능한 하네스의 차이가 여기서 갈립니다.

기준 설명
single command 사람이 한 명령으로 다시 실행 가능해야 함
dry-run 실제 쓰기 전 미리보기 모드가 있어야 함
state file 중간 상태를 복원할 파일이 있어야 함
retry rule 몇 번 재시도하고 언제 멈출지 정해야 함
owner 실패 알림을 받을 사람이 정해져야 함

이 표는 화려하지 않습니다. 하지만 운영에서는 이런 표가 사고를 줄입니다. 에이전트가 천재처럼 보이는 날보다, 피곤한 날에도 같은 방식으로 멈추는 게 더 중요합니다. 자동화는 잘 달릴 때보다 멈출 때 성격이 드러납니다.

도입 순서

회사에서 MCP, A2A, AGENTS.md를 한꺼번에 검토한다면 순서는 이렇게 잡는 편이 안전합니다.

  1. repo별 AGENTS.md로 실행 규칙과 금지 명령을 먼저 표준화합니다.
  2. read-only MCP부터 붙여서 도구 접근 로그를 확인합니다.
  3. draft 작업만 에이전트에게 맡기고 사람 승인으로 반영합니다.
  4. skills와 commands를 만들어 반복 작업의 입력·출력 계약을 고정합니다.
  5. A2A는 agent card와 output contract가 있는 팀부터 시작합니다.
  6. mutating 작업은 승인 로그와 rollback 기준이 생긴 뒤에 엽니다.

이 순서를 거꾸로 가면 문제가 생깁니다. A2A로 에이전트끼리 일을 넘기게 해놓고, 각 에이전트의 권한과 로그, 실패복구가 없으면 멋진 분산 시스템이 아니라 분산된 책임 회피가 됩니다. 이름은 어렵고 책임은 흐릿한 시스템, 회사에서 제일 피곤한 조합입니다.

도입 전 체크리스트

질문 통과 기준
MCP 서버 목록이 권한 등급별로 나뉘어 있나 read-only, draft, mutating, high-risk가 구분됨
AGENTS.md가 계층별로 분리되어 있나 루트와 하위 폴더 역할이 다름
A2A agent card가 있나 identity, capability, auth, output contract가 있음
쓰기 작업에 승인 로그가 있나 누가 승인했는지 남음
실패 시 재실행 명령이 있나 single command와 state file이 있음
민감정보 로그 정책이 있나 원문 dump와 비밀키 저장을 차단함

이 표를 통과하지 못한 상태에서 에이전트를 많이 붙이면 생산성보다 운영 부담이 먼저 늘 수 있습니다. 반대로 이 표를 먼저 만들면 도구가 바뀌어도 기준은 남습니다. MCP 서버가 바뀌고, A2A 구현체가 바뀌고, 코딩 에이전트가 바뀌어도 회사는 같은 질문을 반복해서 물을 수 있습니다.

FAQ

MCP와 A2A는 무엇이 다른가?

MCP는 에이전트가 도구와 데이터에 접근하는 agent-to-tool 표준에 가깝고, A2A는 에이전트끼리 작업을 주고받는 agent-to-agent 표준에 가깝습니다. 회사 운영에서는 접근 권한과 위임 계약을 따로 관리해야 합니다.

AGENTS.md는 꼭 필요한가?

코딩 에이전트를 repo에서 안정적으로 쓰려면 필요합니다. 테스트 명령, 금지 명령, 파일 구조, PR 기준 같은 정보를 매번 말하지 않아도 되게 만드는 장치입니다. 다만 길수록 좋은 문서는 아닙니다.

MCP 서버를 많이 붙이면 생산성이 바로 오르나?

그럴 수도 있지만, 권한과 로그 없이 많이 붙이면 위험이 먼저 늘 수 있습니다. read-only 도구부터 시작하고, 쓰기 권한이 있는 MCP는 승인과 감사 로그를 붙인 뒤 열어야 합니다.

A2A는 언제 도입하는 게 맞나?

여러 에이전트가 서로 다른 팀, 시스템, 벤더에 걸쳐 작업을 주고받아야 할 때 검토할 만합니다. 단일 에이전트가 내부 도구 몇 개를 쓰는 수준이라면 MCP와 명확한 runbook만으로 충분할 수 있습니다.

제일 먼저 만들어야 할 문서는 무엇인가?

루트 AGENTS.md보다 더 먼저 필요한 것은 권한 등급표입니다. 어떤 작업이 read-only이고, 어떤 작업이 승인 필요이고, 어떤 작업은 금지인지 정해야 AGENTS.md와 MCP 설정도 일관되게 쓸 수 있습니다.

보안팀이 가장 먼저 봐야 할 항목은 무엇인가?

쓰기 권한이 있는 도구, 고객 데이터 접근, 비밀키 처리, 로그 보관 정책입니다. 에이전트가 어떤 모델을 쓰는지보다 먼저, 어떤 시스템에 접근하고 무엇을 남기는지를 봐야 합니다.

공식 출처

관련 글