MCP에 툴 50개 꽂고 계신가요, 프론티어는 이미 떠났어요

MCP는 이미 프론티어에서 밀려나고 있어요

Poolside AI 창업자 Eiso Kant가 최근 인터뷰에서 이렇게 말했어요. “MCP랑 툴 콜은 멍청한 접근이에요.” 표현은 세지만, 현장에서 몇 년째 프론티어 모델을 훈련해 본 사람만이 볼 수 있는 관점이에요.

작업이 단순하고 API가 명확할 때 툴 콜은 제 몫을 합니다. 날씨 조회, 캘린더 이벤트 생성, DB에서 로우 하나 읽어오기 같은 일들은 툴 하나에 잘 매핑돼요.

문제는 롱호라이즌이에요. 여러 단계를 거치며 상태가 바뀌고, 중간에 파일을 읽고, 그 결과로 다른 바이너리를 호출하고, 실패하면 롤백까지 해야 하는 흐름. 시스템 프롬프트에 툴 50개를 욱여넣는 순간, 컨텍스트는 너덜너덜해지고 각 툴의 사용법을 매번 다시 떠올리게 됩니다.

Kant가 제시하는 대안은 단순해요. “여기 VM이 있어요. 이 바이너리들이 깔려 있고, 이 폴더에 메모리를 쓸 수 있어요. 나머지는 코드로 처리하세요.” 툴을 따로 정의하지 않아요. 환경을 주고, 모델이 직접 코드를 짜서 시스템과 대화하게 만드는 방식이에요.

지금 이 전환이 일어나는 이유

에이전트가 맡는 일이 급격히 복잡해졌기 때문이에요.

작년까지만 해도 “PR 리뷰하고 코멘트 달기”가 야심찬 태스크였죠. 지금은 “이슈 읽기 → 코드베이스 파악 → 관련 파일 수정 → 테스트 실행 → 스택 트레이스 보고 재수정 → PR 생성”이 기본입니다. SWE-bench 상위권 모델들이 실제로 이 일을 하고 있어요.

이걸 툴 콜로 조립하면 어떻게 될까요. read_file, write_file, run_bash, run_tests, list_directory, search_code, git_commit… 툴이 20개를 넘기 시작하면 매 스텝마다 “어떤 툴을 어떤 파라미터로 부를지”를 고르는 데 토큰을 허비해요. 정작 문제 해결에 쓸 여력이 줄어듭니다.

VM 네이티브 방식은 다르게 갑니다. 셸이 있고 Python이 있고, 필요하면 pip install로 라이브러리를 깔고, find로 파일을 찾고, sed로 고쳐요. 사람 엔지니어가 새 프로젝트에 들어가 첫날에 하는 방식 그대로예요.

결정적으로, 이 방식은 사전에 정의되지 않은 도구도 곧바로 쓸 수 있어요. 툴 콜은 시스템 프롬프트에 올라간 것만 부를 수 있지만, 셸이 있으면 어제 나온 CLI도 금방 배워 바로 적용합니다.

3년 전엔 아무도 안 믿었던 베팅

여기서 눈에 띄는 점은, Kant가 이런 역발상 베팅에 익숙하다는 사실이에요.

2015년 그는 이전 회사 Sourced에서 코드 위에 언어 모델을 훈련시키겠다며 4~5년, 1,200만 달러를 쏟았어요. 아무도 관심 없던 시기였고, Transformer 이전이라 스케일링을 밀어붙이지 못해 실패했죠.

2022년 Poolside를 시작하며 그는 다시 두 가지에 걸었어요. 첫째, 능력은 복리로 쌓일 것이다. 둘째, RL(강화학습)이 LLM 성능을 끌어올리는 최대 드라이버가 될 것이다.

그때 OpenAI, Google, Anthropic 어디에서도 RL을 정답으로 말하지 않았어요. 지금은 o1, Claude 3.7 Sonnet, DeepSeek-R1 모두 RL 기반이죠. 3년이 지나 그의 판단이 맞았다는 게 드러났어요.

그래서 그가 지금 “MCP는 끝났다”고 할 때, 가볍게 넘기기 어려워요. 아무도 안 보던 타이밍에 판을 읽어낸 이력이 있으니까요.

국내 빌더가 지금 봐야 할 신호

한국에서 실제로 에이전트를 붙이고 있는 도메인을 떠올려 봐요.

토스에서 이상거래 하나를 판단할 때, 계좌 히스토리 조회 → 기기 정보 확인 → 최근 로그인 지역 비교 → 유사 패턴 검색 → 필요하면 외부 신용 정보 조회로 이어져요. 이걸 툴 콜 10개로 오케스트레이션할 것인지, 판단 로직을 코드로 짜 VM 안에서 굴릴 것인지. 확장성은 어느 쪽에 있을까요.

당근 커뮤니티 모더레이션도 같아요. 게시글 텍스트, 이미지, 작성자 히스토리, 유사 신고 이력을 조합해 판단해야 하죠. 각 소스마다 툴을 정의하는 것보다 “데이터 접근권한을 주는 환경을 열어둘 테니, 필요한 걸 직접 뽑아 써”가 훨씬 유연합니다.

우아한형제들 라이더 매칭도 마찬가지예요. 실시간 위치, 주문 우선순위, 라이더 상태, 예상 픽업 시간을 매초 갱신합니다. 이런 시스템에 에이전트를 붙일 거라면, 미리 정한 툴 셋보다 시뮬레이션 환경을 코드로 조작하는 편이 자연스러워요.

물론 반론도 있어요. VM에 코드 실행권을 주면 보안, 샌드박싱, 리소스 격리 이슈가 바로 떠오릅니다. 툴 콜은 적어도 호출 가능 범위가 명시적이라 감사가 쉬워요. Kant도 인터뷰에서 이 부분은 깊게 파지 않았어요. 그러니 지금은 방향을 가늠할 신호일 뿐, 답안지는 아니에요.

오픈 웨이트를 넘어 오픈 리서치로

또 하나 짚어둘 점. Kant는 오픈 소스 논의에서 “웨이트를 여는 것보다 리서치를 여는 게 더 의미 있다”고 말해요.

이게 왜 중요할까요. 웨이트만 받으면 모델을 파인튜닝하거나 로컬에 띄울 수는 있어요. 하지만 왜 이런 결과가 나왔는지, 어떤 실험이 실패했고 어떤 결정이 분기점을 만들었는지는 알 수 없죠. 재현이 안 되면 그 위에 무언가를 쌓기 어렵습니다.

Poolside는 최근 프론티어 모델을 내면서 훈련 방법론 리포트를 함께 공개하고 있어요. Optimizer의 epsilon 값을 왜 논문들처럼 크게 잡을 필요가 없었는지 같은 구체 발견까지 담아냅니다.

한국에서 도메인 파인튜닝을 고민하는 팀에게 이건 이런 뜻이에요. “블랙박스 API에 프롬프트만 잘 쓰는 시대”에서 “훈련 레시피를 읽고 우리 도메인에 맞게 재적용하는 시대”로 넘어오고 있다는 신호. 조달 관점에서도, 훈련 방법론을 공개하는 랩과 그렇지 않은 랩 사이에는 감사 가능성에서 큰 차이가 나요.

이번 주에 해볼 것

지금 쓰는 에이전트 스택을 한 번 열어봐요. 시스템 프롬프트나 툴 레지스트리를 확인해 보세요.

툴 정의가 10개를 넘고, 그 에이전트가 여러 단계를 거치는 롱호라이즌 태스크를 맡고 있다면, 프론티어가 떠나고 있는 패턴 위에 시스템을 올려놓았을 가능성이 큽니다.

이번 주에 실험 하나. 지금 툴 콜 10개로 조립한 워크플로우 중 가장 복잡한 걸 하나 골라 “이 작업을 하는 Python 스크립트를 짜고 실행해” 한 줄로 바꿔 보세요. Docker 컨테이너 하나 띄우고, 필요한 바이너리를 넣고, 파일 시스템 접근 권한을 주세요.

두 방식의 성공률, 실행 시간, 그리고 무엇보다 코드 라인 수를 비교해 보세요. 툴 정의에 들어가던 수백 줄이 컨테이너 설정 몇 줄로 압축되는 걸 보게 될 거예요.

Kant가 3년 전 RL에 걸었을 때 많은 사람이 웃었죠. 지금 VM 네이티브 에이전트도 비슷한 위치에 있어요. 지금 실험해 두면, 6개월 뒤 프론티어가 이쪽으로 완전히 넘어왔을 때 이미 그 위에서 프로덕트를 돌리고 있을 거예요.