MCP를 써야 하나요? CLI를 쓰는게 더 낫나요? 둘 다입니다.
TMT이제 그만 다투고 받아들입시다. 둘 다 쓰면 됩니다.
curl https://cli.sentry.dev/install -fsS | bash
sentry auth login
claude mcp add sentry -- sentry mcpSentry가 이번에 두 방식을 잇는 통합 경험을 내놓았습니다. 샌드박스를 쓸 수 있는 에이전트라면 지금은 이 방식이 맞다고 봅니다.
아마 바로 "왜요?"라고 물으실 겁니다. CLI가 더 낫다고 생각하실 테니까요(참고로 그렇지 않습니다). 이유는 몇 가지인데 뒤에서 하나씩 풀어 보겠습니다. 간단히 말하면 이렇습니다.
- 인증을 공유하고 인증 흐름을 직접 쥐고 있으면 쓸모 있는 상황이 있습니다(물론 한계도 있습니다!).
- CLI는 MCP가 못 하는 일을 할 수 있지만, 에이전트용 도구로는 여전히 MCP가 낫습니다.
- MCP 구현은 아직 곳곳마다 다르고, MCP가 CLI를 완전히 대신할 날이 올 거라고는 보지 않습니다.
각각을 조금 깊이 들어가서 저희가 왜 이렇게 판단했는지, 내부에서는 어떻게 돌아가는지 설명하겠습니다.
인증 공유
이건 대체로 단순합니다. 이번 브리지에서 얻는 가장 큰 이점이기도 합니다.
sentry mcp이 명령이 하는 일은 사실 MCP 서버를 stdio 모드로 띄우는 것뿐입니다. 다른 점은 CLI의 자격 증명을 함께 쓰도록 심(shim)을 하나 끼워 넣는다는 것입니다. 사실 저희는 예전부터 안에서 이렇게 하고 있었는데, 지금까지는 드러나지 않았고 이제 겉으로 드러냈습니다. 그래서 평소 CLI로 로그인하듯(보통은 디바이스 코드 방식으로) 인증하면 그 인증이 MCP에도 그대로 이어집니다.
이렇게 하려면 CIMD/DCR을 건너뛰어야 해서 토큰 헤더를 따로 둡니다. Sentry의 MCP 서버는 저희 OAuth 제공자 앞에 놓인 별도 프록시 서비스입니다(그 위에 자체 기능을 얹고 CIMD/DCR을 더합니다). 그래서 여기에 베어러 토큰을 보내면 서버는 그 규칙을 따른 요청으로 받아들입니다. 저희는 대신 인증을 아예 건너뛰는 토큰 유형을 쓸 수 있게 했습니다(Bearer 대신 Sentry-Bearer).
아주 간단한 방식이지만, 인증 흐름을 저희가 직접 다루니 MCP에서 그동안 생기던 인증 버그가 더는 나오지 않는다는 점이 가장 큽니다. 그렇다고 완벽한 해법은 아닙니다.
MCP가 주는 큰 장점 하나는 인증을 한곳에서 처리한다는 점입니다. 덕분에 조직 단위 인증 같은 기능도 얹을 수 있습니다. 업스트림 클라이언트가 토큰 처리(저장 같은)와 인증 흐름을 직접 지원하기도 쉬워집니다.
실제로는 이런 흐름이 아직 꽤 엉성하지만, 한곳에서 처리하지 않으면 저희가 이번에 한 것처럼 저마다 따로 만든 방식이 생겨납니다. Sentry 정도면 괜찮을 수도 있습니다. 매일 쓰는 도구이고, 개발 과정에서 손이 자주 가는 편이니까요. 하지만 이게 이 문제의 장기적인 답이라고는 생각하지 않습니다.
할 수 있는 일이 다르다
저희 CLI와 MCP 서버는 안쪽에서 많은 부분을 같이 쓰지만, 기본으로 할 수 있는 일이 서로 달라서 어느 한쪽이 다른 쪽을 대신할 수 없습니다. 예를 두 가지 들어 보겠습니다.
먼저 CLI에는 파일 시스템이 있습니다. 저희 같은 분야에서는 이게 엄청난 힘이 됩니다. 세션 리플레이(순서대로 일어난 수많은 이벤트)를 두고 이것저것 물어보고 싶다고 해 봅시다. 서버에 검색 엔드포인트를 몇 개 열어 줄 수는 있지만, 그 검색 과정에 추론을 끼워 넣을 수는 없습니다.
그보다는 원본 이벤트 로그를 열어 주고, 에이전트가 그걸 어떻게 다뤄야 하는지 맥락을 알려 준 다음, 필요할 때마다 토큰을 아끼며 데이터를 가져오게 하는 편이 낫습니다. 이벤트를 몇 덩어리씩 가져오고, grep으로 뒤지고, 페이지를 넘겨 가면서요.
똑같은 동작을 서버에 (아주 비효율적으로) 만들어 넣지 않는 한 MCP로는 이렇게 할 수 없습니다. 그럴 만한 가치가 없으니 다들 미리 집계해 두거나 검색 API를 쓰는 쪽으로 가는 겁니다. 앞으로는 제한된 API보다 샌드박스가 늘어날 겁니다.
반대로 에이전트는 기본적으로 CLI가 있는지조차 모릅니다. MCP는 하네스에 기본으로 들어 있다는 게 장점입니다. 스티어링(steering)도 도구 호출도 하네스가 기본으로 지원합니다. 따로 알려 주지 않아도, 쓰는 법을 설명하지 않아도 에이전트가 알아서 기능을 찾고 쓰는 법도 스스로 익힙니다.
반면 CLI를 쓰게 하려면 먼저 CLI가 있다고 알려 줘야 하고, 에이전트는 그다음에야 사용법과 쓸 수 있는 명령을 찾아봅니다. 앞서 말한 인증의 한계와 같은 이야기입니다. 이미 잘 알려진 동작을 버리고 매번 따로 만든 동작을 쓰게 되는 것이죠.
두 가지를 함께 쓰면 재미있는 일을 할 수 있다고 봅니다. MCP 서버를 CLI에서 띄웠다는 걸 저희가 알 수 있으니, MCP 서버가 그에 맞게 동작을 바꿀 수 있습니다. CLI를 어떻게 쓰면 되는지 알려 주는 스티어링을 넣어 주는 식으로요.
예를 들어 get_session_replay라는 도구가 있다면, 이제 그 도구의 응답에서 자세한 내용은 CLI로 가져오라고, 그리고 어떻게 해야 효율적인지까지 알려 줄 수 있습니다. 연결 방식에 따라 달라지는 이런 스티어링은 아직 만들지 않았지만, 헤드리스 도구를 최대한 잘 쓰이게 하려는 지금 저희가 가장 먼저 생각하고 있는 일입니다.
제각각인 MCP
MCP를 조금이라도 구현해 보셨다면 스펙이 얼마나 복잡하고 방대한지, 주요 하네스조차 구현이 꽤 다르다는 걸 겪어 보셨을 겁니다.
그중 가장 중요하면서도 아직 흔한 차이가 도구 검색입니다. 요즘 주요 하네스 상당수는 도구를 지연 로딩(deferred tool calling)합니다. 처음부터 모든 도구를 불러오지 않는다는 뜻입니다. 이게 중요한 이유는 최적화 방법이 달라지기 때문입니다. 도구를 훨씬 많이 넣어도 되고, 스티어링 방식을 바꿀 수도 있습니다.
그런데 잠깐, 검색은 어떻게 될까요? 하네스마다 검색을 어떻게 구현할까요? 지연 로딩도 검색도 지원하지 않는 클라이언트는요?
가장 눈에 띄는 차이가 이것이고 조금씩 나아지고는 있지만, MCP 스펙의 상당 부분은 사실상 아무도 쓰지 않습니다. 일부는 이미 폐기됐고 일부는 앞으로 폐기될 게 분명하지만, 도구 호출 말고 다른 동작을 생각해 보려는 순간 난감해집니다.
딱 맞는 예가 instructions 메타데이터입니다. 제가 알기로는 비교적 최근에 생긴 것으로, MCP 서버를 어떻게 쓰면 되는지 모델에게 기본 방향을 일러 줄 수 있습니다. 이건 정말 엄청나게 중요한데도, 최신 하네스들 사이에서조차 지원 여부가 제각각입니다.
최근 예를 하나 더 들면 MCP Events가 있습니다. 좋은 아이디어 같지만 지금은 거의 쓸 수가 없습니다. 아예 구현되지 않았거나, 구현됐어도 특정 분야에 너무 맞춰져 있어서 MCP 서버를 만드는 쪽에서 고객이 쓰는 기능을 여기에 기대기가 어렵습니다.
결국 MCP는 복잡한 정체성 혼란을 겪고 있고, 저는 이게 이런 문제들 대부분의 뿌리라고 봅니다. 최신 하네스들은 MCP로 자기 생태계에 들어오기를(자기 하네스 위에 무언가를 만들기를) 바라는데, 그 방식이 아주 정해져 있습니다. 그런데 그 정해진 방식이 사용자가 자연스럽게 기대하는 동작과 다를 수도 있고, 벤더가 원하는 연동 방식과 다를 수도 있습니다.
잘 모르신다면 한번 살펴볼 만한 게 있습니다. Claude Desktop이나 T3 Code가 어떻게 돌아가는지 보세요. 둘 다 사실상 대부분 MCP 서버이고, 최신 하네스 위에 올라가 있습니다.
시간이 지나면 알게 될 겁니다
저희에게도 새로운 실험이지만, 지금까지의 실험이 다 그랬듯 오늘의 한계를 피해 가려고 만든 것입니다. 그런 한계는 몇 달 만에 사라지거나 바뀌기 일쑤라 늘 맞춰 가야 합니다. 에이전트 시대에 사업을 하려면 받아들여야 하는 일입니다.
새 방식을 써 보신다면 의견을 꼭 들려주세요. 저희는 지금 온보딩에서 플러그인 대신 CLI로 시작하도록 권하는 쪽으로 바꾸고 있습니다. 저희가 내놓을 수 있는 방식 중 타협이 가장 적고 사용자에게 가장 편하다고 보기 때문입니다.
