Claude 기본 커넥터 vs Composio: AI 에이전트의 도구 품질이 결과를 바꾸는 이유

"굳이 왜 쓰는 거예요?" Claude 커넥터가 있는데 Composio를 쓰는 이유

MCP 커넥터를 대신하는 새로운 레이어의 제품을 발견했습니다. Composio라는 서비스인데, Claude에 기본으로 달려 있는 커넥터 대신 이걸 쓰면 수백 개의 앱에 대한 MCP 서버를 클라우드에서 바로 연결할 수 있어요.

이걸 쓰기 시작하고 나서 좋다고 생각해서, 주변에 사람들을 만날 때마다 알리기 시작했습니다. 얘기를 하다가 자연스럽게 이런 질문을 받았어요.

"Slack도 있고, Gmail도 있고, 캘린더도 있는데… 기존 커넥터 대신 Composio를 쓰면 뭐가 다른 거예요?"

Claude에는 이미 꽤 많은 기본 커넥터가 내장되어 있거든요. Slack, Gmail, Google Calendar, Google Drive, Fireflies — 자주 쓰는 서비스는 대부분 클릭 한 번으로 연결됩니다. 저도 처음에는 기본 커넥터만으로 충분할 거라 생각했습니다.

써보니까 세 가지 지점에서 차이가 드러나더라고요.

같은 API인데 도구가 12개 vs 25개: MCP 서버 설계 품질이 만드는 차이

직접 비교해봤습니다.

같은 API를 보고 만들었는데, 도구 수와 세분화 수준이 이렇게 다릅니다.

"도구가 많으면 뭐가 좋은데?"라는 질문이 자연스럽게 따라옵니다.

사람이 쓸 때는 사실 별 차이가 없어요. "Airtable에서 이 테이블 조회해줘"라고 하면 12개든 25개든 결과는 비슷하게 나옵니다. 차이가 드러나는 건 AI 에이전트가 도구를 골라서 쓸 때입니다.

MCP 서버에서 각 도구는 이름과 설명을 갖고 있습니다. AI 에이전트는 이 설명을 읽고, 지금 해야 하는 작업에 가장 적합한 도구를 선택해요. 도구가 12개라는 건 하나의 도구가 여러 가지 작업을 겸하고 있다는 뜻이고, 25개라는 건 각 작업에 맞는 전용 도구가 있다는 뜻입니다.

공구함을 떠올리면 이해가 빠릅니다. "드라이버 1개"가 있는 공구함과 "십자 드라이버 + 일자 드라이버 + 정밀 드라이버 + 전동 드라이버"가 있는 공구함. 사람은 아무 드라이버나 집어서 손목 힘으로 조절하면 되잖아요. AI는 도구 설명서를 읽고 골라 씁니다. "이 나사는 M2 정밀 나사입니다"라는 설명과 "정밀 드라이버: M1~M3 정밀 나사 전용"이라는 도구가 매칭될 때, AI는 정확하게 작동해요. 반대로 "드라이버: 모든 나사에 사용 가능"이라고만 되어 있으면 AI가 선택할 근거가 없습니다.

실제로 이 차이를 직접 보여드리니까 반응이 바로 나왔어요. 같은 API를 보고도 누구는 12개짜리 도구 호출로 만들고, 누구는 25개짜리로 더 세분화해서 만든다는 겁니다. 그 차이가 실사용에서 커요.

Anthropic 엔지니어들이 MCP에 대해 나눈 대담에서도 비슷한 논점이 나왔습니다. MCP 서버의 도구 설계 품질이 에이전트의 실행 정확도를 좌우하고, 앞으로 이 품질이 B2B SaaS 벤더를 평가하는 새로운 축이 될 수 있다는 점이에요. 사용자 입장에서는 보이지 않는 차이입니다. UI가 예쁜지, 기능이 많은지는 바로 보이지만 MCP 서버가 잘 설계되어 있는지는 실제로 에이전트를 붙여봐야 드러나거든요.

Claude 기본 커넥터에 LinkedIn이 없는 이유 : API 심사라는 벽

연결 자체가 불가능한 서비스도 있습니다.

Claude 기본 커넥터 목록에 LinkedIn은 없어요. Composio에는 LinkedIn 도구가 22개 있습니다. 게시글 작성, 댓글 관리, 회사 페이지 팔로워 통계, 게시글별 인게이지먼트 분석까지 가능합니다.

LinkedIn API의 접근 구조 때문에 이런 차이가 생겨요. LinkedIn API는 권한이 3개 계층으로 나뉘어 있습니다.

두 번째 계층부터가 문제예요. 법인 등록된 조직만 신청할 수 있고, 앱의 전체 기능을 시연하는 화면 녹화까지 제출해야 심사를 통과합니다. LinkedIn 공식 문서에도 "현재 Community Management API는 법인 등록된 조직의 상업적 사용 사례에만 제공된다"고 명시되어 있어요. 개인이 직접 MCP 서버를 만들어서 LinkedIn에 연결하려면 이 심사를 혼자 통과해야 하는데, 법인이 아니면 신청 자체가 불가능합니다.

Composio는 이 심사를 이미 통과해놓은 상태예요. 사용자는 Composio라는 승인된 플랫폼을 통해 LinkedIn API에 접근하는 구조입니다. 이전 글에서 설명한 "대리 출입증"이 여기서도 작동하는 거죠.

다만 Composio의 LinkedIn 22개 도구 전부가 작동하는 건 아닙니다. 직접 테스트해보니 회사 정보 조회나 특정 게시글 콘텐츠 가져오기 등 일부 도구에서 403 에러가 나왔어요. LinkedIn API 자체가 스코프별로 제한이 걸려 있어서, OAuth 토큰에 해당 스코프가 포함되지 않으면 도구가 있어도 작동하지 않습니다.

B2B 세일즈 비유로 풀어보면 이해가 쉬워요. Composio LinkedIn은 "쇼룸 운영"은 잘 돼요. 콘텐츠 발행하고, 어떤 게시글에 반응이 높았는지 분석하고, 팔로워 추이를 보는 것까지는 문제없이 작동합니다. 반면 "콜드콜"에 해당하는 영역 — 이름으로 사람을 검색하거나, DM을 보내거나, 연결 요청을 보내는 것 — 은 API 레벨에서 막혀 있어요. 그래도 0개보다는 낫습니다. Claude 기본 커넥터로는 LinkedIn을 아예 연결할 수 없고, 개인이 직접 만들려면 법인 심사에서 막힙니다.

모바일에서 Salesforce를 부를 수 없었던 이유 : 로컬 MCP 서버의 한계

세 번째 차이는 사용 환경 문제입니다.

제가 Composio를 처음 찾게 된 계기가 이거였거든요. Salesforce MCP 서버와 인블로그 MCP 서버를 직접 만들어서 쓰고 있었는데, 둘 다 로컬에서 돌아갑니다. 데스크탑 앱에서는 잘 되는데, 웹 브라우저에서 claude.ai를 열거나 모바일에서 Claude를 열면 도구를 찾을 수 없다고 해요. 로컬 서버는 데스크탑 앱에서만 연결되니까요.

처음에는 "아 맞다, 데스크탑이 아니네" 하고 넘어갔습니다. 그런데 반복되면 문제가 돼요. 미팅이 끝나고 카페에서 모바일로 "오늘 미팅 Salesforce에 Activity 넣어줘"를 하고 싶은데, 그때마다 노트북을 꺼내야 합니다. 결국 "나중에 해야지" 하다가 잊어버리고, CRM 데이터가 빠지기 시작하거든요. 50명 세일즈팀 기준 CRM 수동 입력에 연간 6,000시간이 소요되는데, "디바이스 때문에 자동화가 안 되는" 상황까지 더해지면 구조적 비효율이 겹겹이 쌓입니다.

이 문제를 해결하려면 로컬 MCP 서버를 클라우드로 올려야 해요. Cloudflare Workers로 마이그레이션을 계획하고 있었습니다. Salesforce도 올려야 하고, 인블로그도 올려야 하고, 서비스가 늘어날수록 관리할 서버도 비례해서 늘어나요. 그 작업을 시작하려던 시점에 Composio를 발견했고, 하루 만에 10개 앱을 연결했습니다. Cloudflare 마이그레이션 자체가 불필요해진 거예요.

Composio는 수백 개의 앱에 대한 MCP 서버를 클라우드에서 운영합니다. 사용자가 서버를 배포하거나 관리할 필요가 없어요. 연결만 하면 됩니다. 모바일이든 웹이든 데스크탑이든, 어디서 Claude를 열든 같은 도구를 같은 방식으로 쓸 수 있습니다.

품질이 떨어지는 것도 아닙니다. Composio를 경유해서 Salesforce에 복잡한 SOQL 쿼리를 날려봤는데, 직접 만든 MCP 서버를 쓸 때와 결과가 동일했습니다. 로컬 서버를 거치든 Composio를 거치든, 뒷단에서 Salesforce API를 호출하는 구조는 같으니까요.

다만 한 가지 예외를 발견했습니다. Composio의 Salesforce 업데이트 도구(SALESFORCE_UPDATE_RECORD)가 내부적으로 Salesforce UI API를 사용하는데, UI API는 Event와 Task 오브젝트를 지원하지 않아요. 미팅 기록이나 통화 기록을 수정하려고 하면 "Object Event is not supported in UI API"라는 에러가 나옵니다. 생성은 REST API를 경유하기 때문에 문제없이 되지만, 이미 만든 Activity의 필드를 수정할 때만 직접 만든 MCP 서버로 폴백해야 했습니다.

무료 플랜에서 월 2만 콜까지 가능하다는 것도 큰 장점이에요. 개인이나 소규모 팀이 쓰기에는 이 한도를 채우기 어렵습니다. 추가로 워크벤치(Workbench) 기능이 있는데, 여러 도구를 병렬로 한꺼번에 호출할 수 있는 가상 작업 공간입니다. Claude에서 도구를 하나씩 순차 호출하는 것보다 복잡한 작업에서 체감할 수 있는 속도 차이가 생깁니다.

Claude 기본 커넥터로 충분한 경우와 그렇지 않은 경우: 도구 품질이 에이전트 성능을 결정하는 이유

세 가지 차이를 봤으니, 현실적인 판단 기준을 정리하겠습니다.

Claude 기본 커넥터로 충분한 경우가 있어요. 연결하려는 서비스가 이미 기본 커넥터 목록에 있고, 데스크탑에서만 작업하고, 도구 세분화가 결과에 큰 영향을 미치지 않는 단순한 워크플로우라면 기본 커넥터로 충분합니다. Slack 메시지 읽고, Gmail 검색하고, Google Calendar에서 일정 확인하는 수준이라면 굳이 Composio를 추가할 이유가 없어요.

Composio가 필요한 경우는 이렇습니다.

1. 기본 커넥터에 없는 서비스를 연결해야 할 때가 첫 번째입니다.

   LinkedIn, Confluence, Airtable 고급 기능 등이 여기에 해당해요.

2. 모바일이나 웹에서도 같은 도구를 써야 할 때가 두 번째입니다.

   로컬 MCP 서버의 디바이스 종속을 벗어나려면 클라우드 호스팅이 필요하고, Composio가 이 역할을 합니다.

3. 에이전트가 여러 서비스를 오가며 복잡한 판단을 해야 하는 워크플로우일 때가 세 번째입니다.

   도구가 세분화되어 있을수록 에이전트가 정확한 도구를 선택할 확률이 올라갑니다.

참고로, 두 가지를 동시에 쓸 수도 있어요. Composio와 Claude 기본 커넥터가 동시에 연결되어 있어도 충돌하지 않습니다. Composio가 안정적으로 동작하는 것이 확인되면 중복되는 기본 커넥터를 하나씩 끄면 됩니다. 저도 아직 전부 전환하지는 않은 상태입니다.

이 판단 기준 뒤에 더 큰 논점이 있습니다. MCP 서버의 도구 설계 품질이 AI 에이전트의 실행 정확도를 결정한다는 거예요. 같은 Salesforce API를 보고 MCP 서버를 만들더라도, 도구를 어떻게 쪼개고 설명을 어떻게 작성하느냐에 따라 에이전트가 맞는 도구를 고르는 확률이 달라집니다. 사용자가 직접 체감하기 어려운 영역이지만, 워크플로우가 복잡해질수록 누적되는 차이예요.

B2B SaaS를 평가할 때 "UI가 얼마나 직관적인가"는 오래된 기준입니다. AI 에이전트 시대에는 여기에 하나가 추가돼요. "이 제품의 MCP 서버가 얼마나 잘 설계되어 있는가." Salesforce가 Headless 360을 발표하면서 "UI 클릭이 필요한 플랫폼은 Agentic Enterprise에 준비되지 않았다"고 선언한 것도 이 맥락이에요. 에이전트가 도구를 소비하는 시대에는 도구의 품질이 곧 제품의 품질입니다.

지금 쓰고 있는 AI 도구의 MCP 커넥터가 몇 개 연결되어 있는지, 그 도구들이 얼마나 세분화되어 있는지 한번 확인해 보시기 바랍니다.