적절한 추상화 계층(abstraction layer)을 선택하는 것은 소프트웨어 분야에서 새로운 문제가 아닙니다. 함께 묶여야 할 중복 사항들을 통합할 수 있을 만큼 충분히 추상적이면서도, 사용자가 지나치게 추상화된 MiddlewareManagerAbstractFactoryProvider를 사용하기 위해 불필요한 수고를 하게 만들 정도로 과도하게 나아가지 않는 적절한 균형을 찾기 위해 실험적인 재구조화를 거치는 것은 흔한 일입니다. 정확히 이 문제, 즉 '어느 정도의 추상화 수준이 충분한가?'에 대해서는 책 한 권이 통째로 쓰여지거나 학부 과정의 주제가 되기도 합니다.

이제 우리는 AI 에이전트가 작업을 수행하도록 돕는 방식에서도 이와 유사한 상황을 마주하고 있습니다. 해당 기능을 위해 MCP가 필요할까요? 아니면 스킬(Skill)이 필요할까요? 단순한 CLI 도구로도 충분할까요? 그 답은 몇 가지 질문에 달려 있습니다.

참고: 더 자세한 맥락을 원하시면, 지난 목요일 Nikita Kothari가 진행한 AIE World's Fair 강연인 "MCPs, CLIs, and Skills: Choosing the Right Tooling Layer for Agentic Development"를 확인해 보세요.

모든 MCP를 사용하는 방식: 슈퍼 에이전트(Super-Agent) 접근법

한 가지 옵션은 접근이 필요할 수 있는 모든 가능한 MCP를 시작 시점에 로드하는 것입니다. 이는 발견 가능성(discoverability) 측면에서 장점이 있습니다. 에이전트가 무엇을 해야 할지 확실하지 않고, 에이전트가 가능한 한 자율적으로 작동하기를 원한다면, 모든 도구 설명(tool descriptions)에 대한 접근 권한을 부여함으로써 에이전트가 유연하게 작동하고 필요에 따라 소스와 도구들을 결합할 수 있게 할 수 있습니다. 또한 에이전트가 가지를 치고 병렬로 작업하여 여러 소스에서 동시에 데이터를 수집하는 것도 가능하게 합니다.

하지만 여기에는 교묘한 함정이 있습니다. MCP 서버 스키마(schemas)가 컨텍스트 윈도우(context window)를 집어삼킬 수 있다는 점입니다. Nikita는 5개의 MCP 서버에서 제공하는 55개 도구의 MCP 스키마가 약 16,500개의 토큰을 차지하며, 이 토큰들이 컨텍스트 내에 지속적으로 상주하게 되는 사례를 언급했습니다.

스킬(Skills)과 CLI: 개발자 접근법

이것은 이전 접근 방식과는 완전히 반대되는 극단에 있는 방식입니다. 에이전트에게 필요한 모든 스킬(Skills)을 인지시키고, 이를 사용하여 어떤 CLI 도구를 어떻게 사용할지 지시하는 것입니다. 컨텍스트(Context)와 속도 측면에서 CLI 도구는 MCP 도구에 비해 엄청난 이점을 가집니다. MCP 서버로의 추가적인 네트워크 호출이 필요 없으며, 컨텍스트를 거의 차지하지 않고, CLI 도구의 출력값은 상당히 예측 가능합니다. 또한, 에이전트가 로컬에서 실행 중이라면 해당 환경에 익숙하다는 이점이 있으며, 상황이 막혔을 때 직접 개입하여 도움을 줄 수도 있습니다.

여기서의 단점은 보안입니다. CLI 도구는 에이전트가 사용하기에 가장 위험도가 높은 도구 중 하나입니다. 정의상 CLI 도구에 접근할 수 있다면 셸(Shell) 자체에도 접근할 수 있기 때문입니다. 이것이 관리 불가능한 위험은 아닙니다. 주의 깊은 샌드박싱(Sandboxing)과 권한 관리에 신경을 쓴다면 위험을 관리할 수 있습니다. 또한, 어떤 종류의 자격 증명(Credential) 문제를 떠안게 될지도 인지해야 합니다. 에이전트가 어떤 자격 증명 파일에 접근할 수 있는지, 그리고 해당 자격 증명의 역할(Role)이 에이전트의 작업에 적절한지를 반드시 파악해야 합니다.

둘 다 사용하면 안 될까: 하이브리드 접근 방식 (The Hybrid Approach)

MCP 서버와 도구가 너무 많아서 컨텍스트를 과도하게 점유해 문제가 될 정도라면, 위의 두 방식을 결합할 수 있습니다. 즉, 토큰 팽창(Token bloat)을 방지하기 위해 MCP 도구 사용을 스킬(Skills)로 묶는 것입니다. 현대적인 클라이언트들은 스키마(Schema)가 충분히 크다면 반드시 전체를 컨텍스트에 포함시키지는 않습니다. 이들은 캐싱(Caching)과 압축/인덱싱(Compaction/Indexing)을 혼합하여, 최소한의 정보만 주입한 뒤 실제 도구 스키마는 필요할 때 로드하는 방식을 취합니다. 만약 프로세스를 어떤 도구가 필요하고 어떻게 사용하는지를 정확히 설명하는 스킬로 래핑(Wrap)한다면, 클라이언트는 해당 도구들의 스키마만을 더 완전하게 풀어낼 수 있어 컨텍스트를 절약하고 로딩 시간도 약간 단축할 수 있습니다. 약간의 추가 설정 작업이 필요하더라도 이것이 종종 최선의 선택이 됩니다.

상황에 따라 다릅니다 (It Depends)

그렇다면 어떤 것을 올바른 선택으로 고수해야 할까요? 우리는 유서 깊은 컴퓨터 과학(Computer Science) 질문으로 시작하여, 유서 깊은 컴퓨터 과학적 답변으로 끝을 맺고 있습니다. 바로 "상황에 따라 다르다(it depends)"입니다. 환경이 어떠한지, 어떤 종류의 작업을 완수하려고 하는지, 필요한 기능에 대한 CLI(Command Line Interface) 도구가 있는지, 그리고 조직의 인증(Auth) 및 거버넌스(Governance) 요구사항이 무엇인지에 따라 달라집니다. MCP(Model Context Protocol)는 확실히 더 안전하고 거버넌스 관리가 용이합니다. CLI는 확실히 더 빠르고 신뢰할 수 있습니다. 귀하의 사용 사례(Use case)에 대한 정답은 아마도 그 중간 어디쯤에 있을 것입니다. 여기서 얻을 수 있는 주요 시사점은 실제로 매우 훌륭한 스킬(Skills)을 작성하고 유지 관리할 수 있는 능력이 엄청난 이점이라는 점일 것입니다.

이 주제에 대해 더 자세히 조사하고 싶다면, Firecrawl 블로그에서 각 접근 방식의 차이점, 장점 및 단점에 대해 훨씬 더 포괄적인 심층 분석(Deep dive)을 제공하고 있습니다.