Skill·Sub-agent·MCP를 실제 개발 업무에 적용한다면 무엇이 달라질까?

AI를 잘 사용하는 개발자와 AI를 활용해 반복 가능한 개발 업무 시스템을 만드는 개발자의 차이는 프롬프트 작성 능력보다 업무를 구조화하는 능력에서 점점 더 커지고 있습니다.

1. 먼저 결론부터 말하면

앞서 소개한 영상의 핵심 방향에는 상당 부분 동의합니다. 특히 Skill을 "AI에게 일하는 방법을 알려주는 업무 SOP"로 보고, Sub-agent를 독립적인 업무를 수행하는 전문 작업자로 보는 접근은 최근 Anthropic이 공개한 Agent Skills 개념과도 상당히 잘 맞습니다.

Anthropic은 2025년 Agent Skills를 공개하면서 Skill을 단순한 프롬프트가 아니라 지침, 스크립트, 리소스 등을 디렉터리 단위로 묶어 에이전트가 필요할 때 발견하고 불러오는 구조로 설명했습니다. 또한 2025년 12월에는 Agent Skills를 플랫폼 간 이동성을 고려한 오픈 표준으로 발전시켰다고 밝혔습니다.

따라서 영상의 설명을 한 단계 발전시키면 다음과 같이 보는 것이 더 정확합니다.

즉, 프롬프트를 잘 쓰는 단계에서 업무 시스템을 설계하는 단계로 넘어가는 것이 핵심입니다.

2. 제가 가장 중요하게 보는 부분은 "무조건 Agent로 만들지 않는 것"

영상에서도 이 부분을 언급하고 있지만, 실제 개발 관점에서는 훨씬 더 중요하게 봐야 합니다.

AI Agent라는 단어가 유행하면서 많은 개발자가 다음과 같은 사고를 하기 쉽습니다.

하지만 Anthropic은 오히려 가장 단순한 구조에서 시작하고, 단순한 방법으로 충분하지 않을 때만 복잡성을 추가하라는 방향을 강조합니다. OpenAI 역시 단일 에이전트에 도구를 추가하는 방식으로 복잡도를 관리할 수 있으며, 프롬프트 템플릿으로 해결할 수 있는 문제라면 굳이 여러 에이전트로 나누지 않아도 된다고 설명합니다.

3. Skill은 "프롬프트 저장소"보다 훨씬 실무적인 개념이다

이 부분은 영상의 설명에 동의하면서도 조금 더 명확하게 정의하고 싶습니다.

단순 프롬프트는 보통 다음과 같습니다.

하지만 개발팀에서 실제로 필요한 것은 이것보다 훨씬 많습니다.

• 어떤 SQL을 대상으로 하는가?
• 실행 계획을 확인해야 하는가?
• 인덱스 존재 여부를 확인해야 하는가?
• 테이블 데이터 규모를 확인해야 하는가?
• 통계 업데이트 상태를 확인해야 하는가?
• 기존 기능의 결과가 변경되면 안 되는가?
• DELETE·UPDATE·DROP 등의 명령은 어떻게 제한할 것인가?
• 최종적으로 어떤 형식의 분석 결과를 만들어야 하는가?

이처럼 업무 규칙 + 참고자료 + 실행 방법 + 검증 방법 + 결과 형식까지 포함하기 시작하면 프롬프트보다는 Skill이라는 개념이 훨씬 적합해집니다.

Anthropic의 공식 설명에서도 Skill은 SKILL.md를 중심으로 필요한 추가 파일이나 실행 가능한 스크립트까지 포함할 수 있으며, 필요한 순간에 관련 내용을 단계적으로 로드하는 "progressive disclosure" 구조를 핵심 설계 원칙으로 설명합니다.

4. 개발자에게는 "Skill = 업무 표준화"라고 보는 것이 가장 유용하다

제가 개발팀에서 Skill을 도입한다면 다음과 같이 정의하겠습니다.

예를 들어 웹 개발팀이라면 다음과 같은 Skill이 충분히 의미가 있습니다.

이렇게 만들면 특정 개발자가 휴가를 가더라도 "그 사람이 머릿속으로만 알고 있던 작업 방식"의 일부를 조직의 AI 업무 자산으로 전환할 수 있습니다.

5. Sub-agent는 "전문가 캐릭터"가 아니라 Context 분리라고 봐야 한다

영상에서 가장 좋은 설명 중 하나가 바로 이 부분입니다. Sub-agent의 핵심은 "DB 전문가", "코드 전문가" 같은 캐릭터를 부여하는 것이 아닙니다.

중요한 것은 업무를 독립적인 컨텍스트에서 처리하도록 분리하는 것입니다.

Anthropic 역시 복잡한 작업에서 전문 Sub-agent가 독립적인 컨텍스트를 사용해 특정 영역을 깊게 조사하고, 최종적으로 압축된 결과를 메인 에이전트에 반환하는 구조를 설명하고 있습니다.

따라서 Sub-agent를 설계할 때는 "어떤 전문가인가?"보다 먼저 "이 작업은 독립적인 컨텍스트에서 수행할 가치가 있는가?"를 질문해야 합니다.

6. Multi-agent가 항상 좋은 것은 아니다

이 부분은 영상보다 해외 자료를 참고했을 때 더 명확해집니다.

Anthropic이 2025년 공개한 Multi-agent Research 시스템에서는 복잡하고 개방적인 연구 문제를 여러 방향으로 동시에 탐색하는 경우 Multi-agent 구조가 상당한 성능 향상을 보였다고 설명합니다. 내부 평가에서 Claude Opus 4를 리드 에이전트로 사용하고 Sonnet 4를 Sub-agent로 사용한 Multi-agent 시스템이 특정 연구 평가에서 단일 Claude Opus 4보다 90.2% 높은 성능을 보였다고 공개했습니다. 다만 동시에 일반적인 채팅보다 훨씬 많은 토큰을 사용하는 비용 문제가 있음을 명시했습니다.

따라서 이 수치를 "Multi-agent가 항상 90.2% 더 좋다"라고 해석하면 안 됩니다. 해당 수치는 특정한 내부 연구 평가와 특정한 연구 작업 유형에 대한 결과입니다.

7. OpenAI의 관점도 결국 "복잡성을 필요한 만큼만 추가"하는 방향이다

OpenAI의 공식 Agent 가이드 역시 Agent를 단순히 "여러 AI를 연결한 것"으로 설명하지 않습니다. 기본적인 Agent는 Model + Tools + Instructions라는 세 가지 요소로 구성되며, 단일 Agent로 충분한 경우에는 굳이 Multi-agent 구조를 도입하지 않는 것이 좋다고 설명합니다.

특히 OpenAI는 도구가 너무 많아서 문제가 발생하는 경우에도 단순히 Agent를 늘리기보다 먼저 도구의 이름, 파라미터, 설명을 명확하게 만드는 방법을 검토하고, 그래도 도구 선택이 어려울 때 Multi-agent를 고려하는 방향을 제시합니다.

8. MCP는 "AI의 두뇌"가 아니라 "외부 시스템과 연결되는 인터페이스"로 이해하는 것이 좋다

여기서 Skill과 MCP를 혼동하지 않는 것이 중요합니다.

Anthropic은 Skill이 MCP 서버와 결합해 외부 도구를 사용하는 복잡한 업무 절차를 가르치는 방식으로 발전할 수 있다고 설명합니다. 따라서 Skill과 MCP는 경쟁 관계라기보다 업무 지식과 외부 실행 환경을 결합하는 관계로 보는 편이 적절합니다.

9. 개발자에게 가장 강력한 조합은 "Skill + MCP + 검증"이라고 본다

개인적으로 개발팀에서 가장 현실적인 출발점은 거대한 Multi-agent 시스템이 아닙니다.

오히려 다음 구조가 훨씬 실용적입니다.

예를 들어 MSSQL 개발 업무라면 AI에게 단순히 "이 SQL을 튜닝해줘"라고 하는 것보다, 프로젝트의 SQL 튜닝 규칙을 Skill로 만들고 DB 조회 도구를 제한적으로 연결한 다음 실행 전후의 결과를 검증하는 구조가 훨씬 발전된 형태입니다.

10. 특히 "쓰기 권한"은 읽기 권한과 완전히 다르게 봐야 한다

Agent가 DB, Git, 파일 시스템, 사내 시스템에 연결되기 시작하면 가장 중요한 문제가 성능이 아니라 권한과 안전성이 됩니다.

Anthropic도 Agent의 자율성이 높아질수록 잘못된 의도를 해석하거나 의도하지 않은 행동을 수행할 위험이 증가하며, prompt injection 같은 공격이 Agent가 비용이 큰 행동을 수행하도록 유도할 수 있다고 설명합니다.

특히 운영 DB에 연결되는 AI Agent라면 DELETE, UPDATE, DROP, TRUNCATE, ALTER 등의 명령을 단순히 프롬프트로 금지하는 것만으로는 충분하지 않습니다. 실제 도구 계층에서 권한과 승인 절차를 분리하는 것이 더 안전합니다.

11. Agent 개발에서 Skill보다 더 중요한 것이 하나 있다: Eval

제가 이번 자료를 조사하면서 영상에 추가하고 싶은 가장 중요한 개념이 바로 Evaluation입니다.

Agent는 일반 프로그램과 달리 동일한 입력에서도 실행 경로가 달라질 수 있습니다. 도구를 호출하고, 중간 결과를 보고, 다음 행동을 결정하고, 실패하면 다른 방법을 선택할 수 있기 때문입니다.

Anthropic은 2026년 Agent 평가에 관한 별도의 기술 글을 공개하면서 Agent의 자율성과 다단계 도구 사용 때문에 전통적인 단순 테스트보다 체계적인 Evals가 중요하다고 설명합니다.

예를 들어 SQL Review Skill이라면 다음을 테스트할 수 있습니다.

• 명백한 N+1 쿼리를 발견하는가?
• 잘못된 JOIN 조건을 발견하는가?
• 불필요한 SELECT *를 지적하는가?
• 인덱스가 필요한 상황과 필요하지 않은 상황을 구분하는가?
• 실행 계획을 근거로 판단하는가?
• 기존 결과를 변경하는 위험한 튜닝을 제안하지 않는가?
• 실행하지 않은 SQL을 실행했다고 주장하지 않는가?

이것이 있어야 Skill이 단순한 문서가 아니라 테스트 가능한 개발 자산이 됩니다.

12. "AI가 알아서 판단한다"는 표현은 개발자라면 조심해야 한다

영상에서는 AI가 Skill이 필요한지 스스로 판단하고 호출하는 개념을 강조합니다. 실제 제품에서는 이러한 자동 선택이 가능하지만, 개발 시스템을 설계할 때는 이를 무조건 신뢰해서는 안 됩니다.

Skill의 name과 description 같은 메타데이터가 Agent의 Skill 선택에 중요한 역할을 한다는 점을 Anthropic도 명시하고 있습니다. 따라서 이름과 설명이 모호하면 잘못된 Skill이 선택될 가능성도 고려해야 합니다.

13. 제가 추천하는 2026년 개발팀의 AI 업무 구조

현재 공개된 Anthropic과 OpenAI의 자료를 종합하면, 개발팀에서 처음부터 거대한 Agent 시스템을 구축하기보다는 다음 단계가 현실적이라고 판단합니다.

특히 마지막 단계인 Eval과 Observability를 처음부터 고려하는 것이 중요합니다. Agent를 만든 다음 문제가 발생할 때만 확인하는 방식보다, 처음부터 성공 기준과 실패 기준을 정의하는 방식이 장기적으로 훨씬 유지보수하기 좋습니다.

14. 실제 웹 개발 프로젝트에 적용한다면?

예를 들어 ASP.NET MVC / ASP.NET Core / MSSQL 기반의 사내 시스템을 운영한다고 가정해 보겠습니다.

이 구조가 중요한 이유는 AI가 단순히 "SQL을 수정해주는 도구"에서 팀의 SQL 분석 방법을 알고 실제 시스템의 정보를 확인하며 검증 가능한 결과를 만드는 개발 보조 시스템으로 발전하기 때문입니다.

15. 특히 개발자는 "AI가 코드를 작성하는 것"보다 "AI가 개발 프로세스를 이해하는 것"을 목표로 해야 한다

현재 AI 코딩 도구의 발전을 보면 단순 코드 자동완성에서 벗어나 파일을 읽고, 명령을 실행하고, 코드를 수정하고, 장시간 작업을 수행하는 방향으로 발전하고 있습니다.

OpenAI도 2026년 Agents SDK 업데이트에서 파일 검사, 명령 실행, 코드 수정, 통제된 Sandbox 환경에서 장기 작업을 수행하는 기능을 강조하고 있습니다.

따라서 앞으로 개발자의 경쟁력은 단순히 "AI보다 코드를 잘 작성하는가"만으로 평가하기 어려워질 가능성이 높습니다.

물론 이것이 개발자가 코딩을 몰라도 된다는 의미는 아닙니다. 오히려 반대입니다. AI의 결과를 검증하려면 아키텍처, 데이터베이스, 보안, 테스트, 배포, 장애 대응에 대한 개발자의 판단력이 더 중요해집니다.

16. Skill과 Agent를 만들기 전에 먼저 해야 할 일

제가 개발자에게 가장 먼저 권하고 싶은 것은 Skill 파일을 만드는 것이 아닙니다.

본인의 업무 프로세스를 먼저 글로 적어보는 것입니다.

이 과정을 거쳐야 AI에게 업무를 맡길 수 있습니다. 그렇지 않으면 단순히 "AI에게 알아서 해달라"고 요청하는 수준에서 크게 벗어나기 어렵습니다.

17. 제가 보는 가장 현실적인 도입 순서

18. 영상 내용에 대한 최종 평가

19. 가장 중요한 한 가지

결국 이 구조가 완성되면 AI는 단순한 Chatbot이 아니라 개발팀의 업무 프로세스를 이해하고 반복적으로 수행하는 업무 실행 계층에 가까워집니다.

그리고 저는 이것이 2026년 현재 AI 개발 도구를 바라보는 가장 중요한 관점 중 하나라고 생각합니다. 단순히 더 강력한 모델을 선택하는 것보다, 좋은 업무 정의 → 적절한 Skill → 제한된 Tool → 필요한 경우 Sub-agent → 검증 가능한 결과를 만드는 것이 실제 조직에서 AI를 지속적으로 활용하는 데 더 중요합니다.

20. 실무 적용 체크리스트

21. FAQ

22. 출처 및 참고 자료

업데이트 및 면책

#AI에이전트 #AIAgent #AgentSkills #Skill #SubAgent #MCP #Claude #ChatGPT #OpenAI #Anthropic #AI개발 #AI코딩 #개발자동화 #개발자생산성 #MultiAgent #AgentWorkflow #PromptEngineering #ContextEngineering #Eval