스킬 vs 서브 에이전트: 에이전트 시스템 설계의 선택 기준
에이전트 기반 AI 시스템을 설계할 때 가장 흔히 마주치는 질문 중 하나는 "이 기능을 스킬(Skill)로 구현해야 할까, 아니면 서브 에이전트(Sub-Agent)로 분리해야 할까?"다. Azure 리드 엔지니어 Kishorekumar Pattabiraman은 이 선택이 단순한 구현 방식의 차이가 아니라, 시스템 전체의 아키텍처 복잡도와 운영 효율성에 직접적인 영향을 미친다고 강조한다. 명확한 기준 없이 설계를 진행하면 불필요하게 복잡한 구조가 만들어지거나, 반대로 과도하게 단순화되어 확장성을 잃는 문제가 생긴다.
스킬과 서브 에이전트의 역할 구분
스킬(Skill) 은 에이전트가 호출하는 단일 기능 단위로, 특정 작업을 수행하는 함수나 API 호출에 가깝다. 재사용 가능하고, 입출력이 명확하며, 독립적으로 테스트 가능한 것이 특징이다. 반면 서브 에이전트(Sub-Agent) 는 자체적인 판단 로직과 상태를 가지는 독립적인 에이전트로, 복잡한 다단계 작업을 자율적으로 처리할 수 있다.
선택의 핵심 판단 기준은 다음과 같다.
- 재사용성: 여러 에이전트나 워크플로우에서 동일한 기능이 반복적으로 필요하다면 스킬로 추출하는 것이 유리하다.
- 단순성: 작업의 흐름이 선형적이고 조건 분기가 단순하다면 스킬 수준으로 충분하다. 서브 에이전트를 도입하면 오히려 오버엔지니어링이 된다.
- 자율성과 복잡도: 작업이 내부적으로 여러 단계를 거치고, 중간 결과에 따라 행동이 달라지는 복잡한 판단이 필요하다면 서브 에이전트가 적합하다.
// 스킬 수준: 단순 API 호출을 래핑한 재사용 가능한 함수
public String fetchWeatherData(String city) {
return weatherApiClient.get("/weather?city=" + city);
}
// 서브 에이전트 수준: 자체 판단 로직 포함
public TravelPlan planTrip(String destination) {
String weather = fetchWeatherData(destination);
List<String> activities = recommendActivities(weather);
return bookingAgent.createPlan(destination, activities);
}
장기적인 유지보수성을 고려한 설계 전략
가장 경계해야 할 패턴은 "일단 서브 에이전트로 분리하면 유연하겠지"라는 막연한 판단으로 컴포넌트를 과도하게 세분화하는 것이다. 서브 에이전트가 늘어날수록 에이전트 간 통신 비용, 상태 동기화 복잡도, 디버깅 난이도가 함께 증가한다. 유지보수 관점에서는 필요한 시점에 분리하는 것(Just-in-Time decomposition) 이 처음부터 복잡하게 설계하는 것보다 훨씬 효과적이다.
또한 스킬은 인터페이스 계약이 명확할수록 팀 간 협업이 쉬워진다. 입력/출력 스펙을 문서화하고 버전 관리를 철저히 하면, 여러 에이전트가 같은 스킬을 안전하게 공유할 수 있다. 반면 서브 에이전트는 도메인 경계를 기준으로 나누는 것이 바람직하며, 마이크로서비스 설계 원칙과 유사하게 높은 응집도, 낮은 결합도를 목표로 해야 한다.
정리
- 스킬은 단순하고 재사용 가능한 기능 단위, 서브 에이전트는 자율적 판단이 필요한 복잡한 작업 단위로 구분한다.
- 컴포넌트 선택은 아키텍처 복잡도와 운영 효율성에 직결되므로, 재사용성·단순성·유지보수성을 기준으로 판단해야 한다.
- 초기부터 과도하게 분리하지 말고, 실제 필요가 생기는 시점에 서브 에이전트로 전환하는 점진적 접근이 장기적으로 유리하다.