에이전트 확장 3계층
한 줄 정의
에이전트 확장 3계층은 Skill, MCP, Tool Calling을 경쟁 기술이 아니라 서로 다른 책임을 맡는 상보적 층으로 구분하는 프레임이다.
핵심 요지
- Skill은 절차적 지식, MCP는 외부 시스템 연결, Tool Calling은 로컬에서 실행되는 손에 가깝다.
- 실제 workflow는 셋 중 하나만 고르기보다 셋을 조합하는 경우가 많다.
- 가장 흔한 실수는 기능 문제가 아닌데 Skill로 밀어 넣거나, 절차 문제인데 MCP로만 해결하려는 식의 층위 오판이다.
상세
이 프레임은 “무엇을 추가해야 agent가 더 잘 일하는가”를 세 질문으로 분해한다. 첫째, 이미 도구는 있는데 어떻게 일해야 하는지만 부족한가? 그렇다면 Skill이 맞다. 둘째, GitHub·Jira·Slack처럼 인증과 상태가 있는 외부 시스템에 닿아야 하는가? 그렇다면 MCP가 맞다. 셋째, 포맷 파서나 계산기처럼 작은 결정적 기능이 로컬에서 바로 실행되면 충분한가? 그렇다면 Tool Calling이 맞다.
실무에서는 세 층이 함께 붙는다. 예를 들어 버그 수정 workflow라면 Skill이 재현·수정·검증·PR 작성 순서를 고정하고, MCP가 GitHub나 이슈 트래커 접근을 맡고, built-in tool이 파일 수정과 테스트 실행을 맡는다. 이 관점은 Claude Code 오케스트레이션이나 OpenCode 같은 도구를 볼 때 특히 유용하다. 기능이 없어서 막힌 것인지, 절차가 없어서 헤매는 것인지, 외부 연결이 없는 것인지를 분리해서 볼 수 있기 때문이다.
후속 raw는 여기서 한 단계 더 나아가, 세 층을 단순 기능 분류가 아니라 보안 경계와 결합해야 한다고 강조한다. Skill은 passive하고 canonical해야 하며, 언제 실행할지는 agent가 결정해야 한다. MCP는 agent마다 중복 구현하지 말고 중앙집중화해 audit과 credential rotation을 쉽게 해야 한다. 또한 reader·orchestrator·critic·resolver처럼 역할을 분리해 least privilege를 적용하면, untrusted input과 실제 write action 사이에 안전한 간격을 둘 수 있다.
다만 이 영역은 도구 문법과 제품 경계가 빠르게 변한다. 그래서 이 노트는 개념 프레임은 유지하되, 특정 제품의 지원 범위나 token 비용 판단은 적용 전 다시 확인하는 편이 안전하다.
예시
- PR 리뷰 스타일 통일: 새 API보다 Skill이 우선이다.
- GitHub 이슈 읽기·PR 열기: 인증과 상태가 필요하므로 MCP가 우선이다.
- CSV 정규화나 diff 요약기: 작고 결정적인 로컬 tool이 우선이다.
충돌
현재 확인된 충돌 없음.