작은 팀이 AI 코딩 도구에 GitHub 이슈, 로그 검색, 테스트 실행, PR 요약 권한을 붙였다고 해봅시다. 처음에는 생산성이 올라갑니다. 이슈를 읽고, 관련 파일을 찾고, 테스트를 돌리고, PR 설명까지 정리해주기 때문입니다.
하지만 곧 새로운 질문이 생깁니다. AI가 어떤 로그를 읽어도 되는지, 테스트 실패 후 어디까지 자동 수정해도 되는지, migration을 만들 때 멈춰야 하는지, PR 요약에 내부 장애 정보를 포함해도 되는지 정해야 합니다.
이 순간 개발 환경은 단순 IDE가 아닙니다. AI가 컨텍스트를 읽고, 도구를 호출하고, 권한 경계에서 멈추고, 실행 기록과 산출물을 남기는 Agent Runtime에 가까워집니다.
개발 환경이라고 하면 보통 IDE를 떠올립니다. VS Code, IntelliJ, WebStorm, Cursor 같은 도구들입니다. 여기에 터미널, Git, 패키지 매니저, 브라우저, DB 클라이언트, 배포 도구가 붙습니다.
기존 개발 환경의 중심은 사람이었습니다. 사람이 IDE에서 코드를 읽고, 터미널에서 명령을 실행하고, 로그를 해석하고, 배포 버튼을 누르고, PR을 작성했습니다. AI 코딩 도구가 들어오면서 이 전제가 흔들립니다.
MCP는 LLM 애플리케이션이 외부 데이터와 도구를 표준화된 방식으로 연결하는 protocol입니다. A2A는 서로 다른 AI agent system이 공통의 communication model로 협업하도록 설계된 open standard입니다.
여기까지가 공식 specification에서 확인할 수 있는 사실입니다. 이 글의 해석은 MCP와 A2A 자체가 곧바로 완성된 개발 플랫폼이라는 뜻이 아니라, 개발 환경이 IDE 기능 묶음에서 agent 실행 환경 설계로 확장된다는 신호로 보자는 것입니다.
| 기준 | 내용 |
|---|---|
| 분석 기준일 | 2026-05-10 |
| 주요 참고자료 | Model Context Protocol Specification, A2A Protocol Specification, OpenAI Agents SDK |
| 글의 목적 | AI 개발 도구의 다음 구조를 시스템 설계 관점으로 이해하기 |
| 핵심 질문 | 도구 연결과 멀티 에이전트 협업은 개발 환경을 어떻게 바꾸는가 |
핵심 요약
- MCP는 LLM 애플리케이션과 외부 데이터·도구를 연결하는 표준화된 방식이며, Resources, Prompts, Tools를 핵심 구성 요소로 둡니다.
- MCP Prompts는 서버가 prompt template을 제공하고, 클라이언트가 이를 발견해 사용자 주도 명령처럼 사용할 수 있는 구조를 설명합니다.
- A2A specification은 독립적인 AI agent system 간 communication과 interoperability를 위한 open standard이며, Agent Card, Task, Message, Artifact 같은 개념을 사용합니다.
- OpenAI Agents SDK Tracing, Guardrails, Human-in-the-loop은 agent runtime이 관측, 승인, 검증 구조를 포함해야 함을 보여줍니다.
- 앞으로 개발 환경은 사람이 IDE에서 모든 일을 직접 수행하는 구조에서 사람이 agent runtime을 설계하고 감독하는 구조로 이동할 가능성이 큽니다.
IDE 중심 개발 환경의 한계
기존 IDE는 사람이 코드를 작성하기 좋은 환경입니다. 자동완성, 검색, 리팩터링, 디버깅, 테스트 실행, Git 연동을 제공합니다. 하지만 기본 전제는 여전히 "사람이 중심"입니다.
AI 코딩 도구가 들어오면 이 전제가 흔들립니다. AI는 단순 자동완성보다 더 많은 일을 합니다. 코드베이스를 탐색하고, 파일을 수정하고, 테스트를 실행하고, 오류를 고치고, 결과를 요약합니다.
Claude Code 공식 문서도 Claude Code를 agentic coding environment로 설명하며, 사용자가 원하는 것을 설명하면 Claude가 탐색하고 계획하고 구현한다고 설명합니다.
이제 개발 환경은 이런 질문을 해야 합니다.
AI는 어떤 파일을 읽을 수 있는가?AI는 어떤 도구를 호출할 수 있는가?AI는 어떤 명령을 실행할 수 있는가?AI가 만든 결과는 어디에 artifact로 남는가?AI의 판단과 도구 호출은 어떻게 trace되는가?사람은 어느 지점에서 승인해야 하는가?이 질문은 IDE 기능만으로는 충분히 다루기 어렵습니다. 그래서 필요한 개념이 Agent Runtime입니다.
Agent Runtime이란 무엇인가
Agent Runtime은 AI가 작업을 수행하기 위해 필요한 실행 환경입니다. 단순히 모델 API를 호출하는 코드가 아닙니다.
Agent Runtime =Model+ Context+ Tools+ Permissions+ Guardrails+ State+ Tracing+ Artifacts+ Human Approval기존 개발 환경과 비교하면 이렇습니다.
| 구분 | IDE 중심 개발 | Agent Runtime 중심 개발 |
|---|---|---|
| 주 실행자 | 사람 | 사람 + AI agent |
| 컨텍스트 | 사람이 읽음 | AI가 선별적으로 읽음 |
| 도구 실행 | 사람이 클릭/명령 실행 | AI가 tool call |
| 권한 | 사람 계정 기준 | agent별 권한 필요 |
| 검증 | 사람이 테스트 실행 | AI 실행 + 사람 승인 |
| 기록 | Git/PR 중심 | trace, tool log, artifact 추가 |
| 산출물 | 코드 변경 | 코드 + 보고서 + evidence |
Agent Runtime은 "AI가 개발 작업을 할 수 있게 만드는 운영 환경"입니다. 이 관점에서 MCP와 A2A는 중요합니다.
MCP: 도구와 컨텍스트를 연결하는 표준
MCP는 Model Context Protocol의 약자입니다. 공식 specification은 MCP를 LLM 애플리케이션과 외부 데이터 소스 및 도구를 통합하기 위한 open protocol로 설명합니다.
개발자 관점에서 MCP를 쉽게 말하면 이렇습니다.
AI 도구가 매번 제각각 방식으로 외부 도구를 붙이지 말고,공통 규격으로 컨텍스트와 도구를 제공하자.예를 들어 AI 코딩 도구가 다음을 사용해야 한다고 해봅시다.
GitHub IssueJira Ticket프로젝트 문서DB schema로그 검색테스트 실행코드 검색배포 상태각 도구마다 따로 붙이면 복잡합니다. MCP는 이런 것들을 LLM client와 server 사이에서 정해진 방식으로 노출하는 구조를 제공합니다.
MCP Resources, Prompts, Tools
MCP를 개발 워크플로우 관점으로 보면 세 가지가 핵심입니다.
| MCP 구성 요소 | 의미 | 개발 워크플로우 예시 |
|---|---|---|
| Resources | AI가 참고할 컨텍스트와 데이터 | README, API schema, 로그, 이슈 |
| Prompts | 사용자가 선택할 수 있는 작업 템플릿 | 코드 리뷰 요청, 테스트 생성, PR 요약 |
| Tools | AI가 실행할 수 있는 함수 | 파일 검색, 테스트 실행, 이슈 조회 |
Resources
이 계층은 AI가 읽을 수 있는 컨텍스트를 다룹니다. 코드베이스 전체를 무작정 넣는 것이 아니라 필요한 데이터를 구조적으로 노출하는 개념에 가깝습니다.
resource://project/architectureresource://project/api-schemaresource://logs/recent-errorsresource://issues/current-sprintresource://docs/coding-conventionPrompts
MCP의 prompt 기능은 서버가 prompt template을 클라이언트에 노출하고, 클라이언트가 이를 발견해 인자를 넣어 사용할 수 있게 하는 구조를 설명합니다.
개발팀에서는 이런 식으로 쓸 수 있습니다.
/review-api-change/write-regression-test/analyze-prod-log/summarize-pr/refactor-component중요한 점은 이 명령들이 단순 프롬프트가 아니라 팀의 작업 규칙과 연결될 수 있다는 것입니다.
Tools
마지막 계층은 AI가 실행할 수 있는 함수입니다.
search_code()read_file()run_tests()query_logs()create_pr_summary()get_issue()적용해 보면, MCP를 붙인다는 것은 생산성을 올리는 일이면서 동시에 권한을 설계하는 일입니다. tool은 외부 시스템 접근이나 코드 실행 경로가 될 수 있으므로 사용자 동의, 데이터 프라이버시, tool safety를 함께 다뤄야 합니다.
A2A: 에이전트 간 협업 프로토콜
MCP가 AI와 도구의 연결에 가깝다면, A2A는 AI와 AI의 연결에 가깝습니다.
A2A 공식 specification은 A2A Protocol을 독립적이고 내부가 불투명할 수 있는 AI agent system 간 communication과 interoperability를 위한 open standard로 설명합니다. 또한 agent가 서로의 내부 상태, 메모리, 도구에 접근하지 않고도 사용자 목표 달성을 위해 정보를 안전하게 교환하도록 돕는다고 설명합니다.
A2A의 핵심 개념은 다음과 같습니다.
| 개념 | 의미 |
|---|---|
| Agent Card | agent의 능력, endpoint, 권한 요구사항을 설명하는 메타데이터 |
| Message | client와 agent 사이의 통신 단위 |
| Task | agent가 처리하는 stateful 작업 단위 |
| Artifact | task 결과로 생성되는 산출물 |
| Part | message나 artifact 안의 최소 콘텐츠 단위 |
개발 워크플로우로 바꾸면 이렇게 볼 수 있습니다.
- Planner Agent
- Coder Agent
component artifact - Test Agent
test report artifact - Reviewer Agent
review artifact - Release Agent
release note artifact
A2A가 중요한 이유는 앞으로 AI 작업이 하나의 agent 안에서 끝나지 않을 가능성이 높기 때문입니다.
Agent Runtime의 핵심 구성 요소
Agent Runtime을 개발 환경으로 본다면 다음 구성 요소가 필요합니다.
| 구성 요소 | 역할 |
|---|---|
| Context Manager | AI에게 줄 문서, 코드, 로그를 선별 |
| Tool Gateway | AI가 호출할 도구를 관리 |
| Permission Layer | 파일/명령/외부 API 권한 제한 |
| Guardrail Engine | 위험 입력·출력·도구 호출 차단 |
| State Store | 작업 상태, session, task 관리 |
| Trace Store | LLM 호출, tool call, 승인 기록 저장 |
| Artifact Store | 결과물, 보고서, 테스트 결과 저장 |
| Human Approval UI | 사람 승인/거절 지점 제공 |
OpenAI Agents SDK Tracing은 agent run 중 LLM generation, tool call, handoff, guardrail, custom event 등을 기록한다고 설명합니다. Human-in-the-loop 문서는 tool call이 approval을 요구할 때 run이 멈추고, pending approval을 사람이 approve 또는 reject한 뒤 재개하는 구조를 설명합니다.
Trace 없이는 디버깅할 수 없다.Approval 없이는 위험한 실행을 막을 수 없다.Artifact 없이는 결과를 검증할 수 없다.개발 워크플로우는 어떻게 바뀌는가
기존 개발 워크플로우는 대략 이랬습니다.
요구사항 확인→ 코드 작성→ 테스트→ 리뷰→ 배포AI Agent Runtime이 들어오면 흐름이 바뀝니다.
요구사항 계약→ 컨텍스트 구성→ agent 작업 계획→ 도구 호출→ 코드 변경→ 자동 검증→ evidence 제출→ 사람 승인→ PR merge| 단계 | 기존 방식 | Agent Runtime 방식 |
|---|---|---|
| 요구사항 | 사람이 읽고 이해 | 작업 계약서로 구조화 |
| 코드 탐색 | 사람이 검색 | agent가 context 탐색 |
| 구현 | 사람이 작성 | agent가 수정, 사람이 검토 |
| 테스트 | 사람이 실행 | agent 실행 + 결과 제출 |
| 리뷰 | 사람이 diff 확인 | diff + evidence + trace 확인 |
| 배포 | 사람이 실행 | 승인 게이트 후 실행 |
사람의 역할은 사라지지 않습니다. 직접 실행자에서 작업 시스템 설계자이자 승인자로 바뀝니다.
실무 아키텍처 예시
팀에서 바로 적용할 수 있는 단순 Agent Runtime 구조는 다음과 같습니다.
AI_GUIDE · TASK_CONTRACT · Docs · Logs
Code Search · Test Runner · Issue · Log Query
read/test 허용 · write 승인 · secret/deploy 차단
secret check · dangerous command check · output validation
tool calls · approvals · failures
code diff · VERIFY_REPORT · PR summary
처음부터 플랫폼으로 만들 필요는 없습니다. 초기에는 문서와 PR 템플릿으로 시작하면 됩니다.
AI_GUIDE.mdTASK_CONTRACT.mdVERIFY_REPORT.mdPR_TEMPLATE.md그다음 적용 단계에서 MCP server를 붙이고, 승인 게이트를 추가하고, trace를 저장하면 됩니다.
최소 Agent Runtime부터 시작하기
최소 Agent Runtime은 별도 플랫폼이 아니라 세 가지 파일, 세 가지 명령, 세 가지 승인 규칙으로 시작할 수 있습니다.
| 구성 | 최소 기준 | 이유 |
|---|---|---|
| 파일 | AI_GUIDE.md, TASK_CONTRACT.md, VERIFY_REPORT.md | 컨텍스트, 작업 범위, 완료 증거를 분리한다. |
| 명령 | lint, typecheck, test | AI가 "완료"라고 말하기 전에 실행 증거를 남긴다. |
| 승인 규칙 | dependency 변경, migration, 배포 명령 | 되돌리기 어렵거나 운영 영향을 줄 수 있는 작업을 멈춘다. |
예시로 바꾸면 다음 정도가 첫 단계입니다.
minimum_agent_runtime: context: required_files: - AI_GUIDE.md - TASK_CONTRACT.md tools: allow: - npm run lint - npm run typecheck - npm test require_approval: - npm install - npm run db:migrate - npm run deploy evidence: required_artifacts: - VERIFY_REPORT.md - PR summary이 정도만 있어도 AI 작업은 대화창 안의 즉흥 실행에서 리뷰 가능한 runtime 이벤트로 바뀝니다.
보안과 권한 리스크
Agent Runtime은 강력합니다. 강력하다는 것은 위험하다는 뜻이기도 합니다.
주의해야 할 리스크는 다음과 같습니다.
| 리스크 | 설명 | 대응 |
|---|---|---|
| Secret 노출 | .env, token, key 접근 | deny path, secret scanner |
| 위험 명령 실행 | 삭제, 배포, migration | approval gate |
| 과도한 컨텍스트 제공 | 불필요한 데이터 노출 | context minimization |
| 잘못된 tool 설명 | tool이 실제로 하는 일과 설명 불일치 | trusted server만 허용 |
| trace 민감 정보 저장 | 로그와 trace에 비밀정보 포함 | masking, retention policy |
| agent 간 정보 전파 | 다른 agent로 민감 정보 전달 | task scope 제한 |
Agent Runtime을 설계할 때는 처음부터 보안 계층을 넣어야 합니다.
도구를 연결하기 전에 권한을 설계한다.권한을 열기 전에 승인 조건을 만든다.승인 조건을 만들기 전에 금지 영역을 정의한다.적용 로드맵
1단계: 문서 기반 Runtime
처음에는 문서 기반 runtime만으로도 충분한 경계를 만들 수 있습니다.
AI_GUIDE.mdTASK_CONTRACT.mdVERIFY_REPORT.mdPR_TEMPLATE.md목표는 AI 작업을 대화창 안의 임시 작업에서 리뷰 가능한 작업 단위로 바꾸는 것입니다.
2단계: 도구 제한
그다음에는 도구를 위험도 기준으로 나눕니다.
허용:- 파일 읽기- 코드 검색- lint- typecheck- unit test 승인 필요:- 파일 수정- dependency 변경- migration 작성 금지:- secret 접근- production 배포- DB 직접 변경3단계: MCP 도입
반복되는 도구 연결을 MCP server로 분리합니다.
docs serverissue serverlog servertest servercode search server이때 tool별 승인 조건도 함께 설계합니다.
4단계: Trace 저장
저장해야 할 최소 기록은 다음과 같습니다.
사용한 컨텍스트호출한 도구실패한 명령생성한 diff사람 승인 여부검증 결과5단계: Multi-Agent 협업
역할을 나누면 agent 간 task와 artifact 경계를 더 명확히 둘 수 있습니다.
Planner AgentCoder AgentTest AgentReviewer AgentRelease Note Agent이 단계부터 A2A 같은 개념이 중요해집니다. A2A는 agent가 서로의 내부 도구나 메모리에 접근하지 않고도 capability discovery, modality negotiation, collaborative task management를 수행하도록 하는 방향을 제시합니다.
체크리스트
Agent Runtime을 설계할 때는 아래 항목을 순서대로 확인합니다.
[ ] AI가 읽을 수 있는 컨텍스트 범위를 정의했다.[ ] AI가 읽으면 안 되는 파일과 데이터가 정의되어 있다.[ ] AI가 호출할 수 있는 도구 목록이 있다.[ ] 각 도구별 권한 수준이 정의되어 있다.[ ] 승인 없이 실행 가능한 명령과 승인 필요한 명령이 나뉘어 있다.[ ] secret, production, DB 변경은 기본 차단되어 있다.[ ] AI 작업의 상태를 기록할 방법이 있다.[ ] AI tool call과 실패 기록을 추적할 수 있다.[ ] 작업 결과가 artifact로 남는다.[ ] PR에서 evidence를 확인할 수 있다.[ ] 멀티 에이전트 협업 시 task와 artifact 경계가 정의되어 있다.마무리
MCP와 A2A는 단순히 새로운 AI 기술 키워드가 아닙니다.
MCP는 AI가 외부 도구와 컨텍스트를 다루는 방식을 표준화하려는 흐름입니다. A2A는 AI 에이전트들이 서로를 발견하고, task를 주고받고, artifact를 생성하며 협업하는 방식을 표준화하려는 흐름입니다.
이 두 흐름이 가리키는 방향은 분명합니다. 개발 환경은 더 이상 IDE만으로 설명되지 않습니다.
| 묶음 | 포함 요소 |
|---|---|
| 사용자 작업면 | IDE, CLI |
| agent 실행면 | LLM, MCP Server, Tool Gateway |
| 통제 계층 | Permission Layer, Guardrails, Human Approval |
| 관측 계층 | Trace Store, Artifact Store |
| 협업 계층 | A2A Agent Network |
이 전체를 묶으면 Agent Runtime입니다.
과거의 개발 환경:사람이 IDE에서 코드를 작성한다. 현재의 개발 환경:사람이 AI와 함께 코드를 수정한다. 다음 개발 환경:사람이 Agent Runtime을 설계하고 감독한다.이제 개발자는 코드뿐 아니라 AI가 코드를 다루는 방식까지 설계해야 합니다.
요약 카드
이 글의 핵심을 실행 관점으로 압축하면 다음과 같습니다.
한 줄 요약:MCP와 A2A 이후 개발 환경은 IDE가 아니라 Agent Runtime 중심으로 이동한다. 핵심 개념:MCP Resources, Prompts, Tools / A2A Agent Card, Task, Message, Artifact 가장 큰 리스크:도구를 먼저 연결하고 권한·승인·trace를 나중에 생각하는 것 지금 바로 할 일:AI가 호출할 수 있는 도구 목록과 승인 필요 도구 목록을 분리한다.
댓글
GitHub 계정으로 로그인하면 댓글을 남길 수 있습니다. 댓글은 GitHub Discussions를 통해 운영됩니다.