진짜 문제는 능력이 아니라 마찰이다
12개의 미완성 초안. 개발자라면 누구나 한 번쯤 공감할 숫자다. 아이디어는 있었고, 기술도 있었고, 쓰고 싶은 마음도 있었다. 그런데 결국 발행되지 않았다. 왜일까? dev.to의 한 개발자가 솔직하게 털어놓은 이유는 간단했다. "능력이 없어서가 아니라, 마찰이 너무 많아서." 리서치, 탭 전환, 포맷팅, 태그 선택, 시리즈 배정—하나하나는 쉬운 일이지만, 이 단계들이 쌓이면 뇌는 더 즉각적인 보상이 있는 일로 탈출한다. 버그 하나를 더 고치거나, 다른 사람이 이미 완성한 아티클을 읽는 쪽으로.
MCP가 바꾼 것: 속도가 아니라 심리
이 개발자가 선택한 해법은 Claude와 dev.to API를 연결하는 MCP 서버(devto-mcp)를 직접 구축하는 것이었다. 흥미로운 점은, 그가 가장 먼저 언급한 변화가 '속도'가 아니라는 것이다. "스스로를 설득해서 포기하는 일이 멈췄다"는 표현이 핵심이다. 아이디어가 떠오르는 순간 Claude Code에 "이 주제로 dev.to에 이미 뭐가 있어?"라고 물으면 30초 안에 토픽 맵이 나온다. 빈 페이지 앞에서 막히던 그 순간—리서치 공백이 글을 죽이던 바로 그 지점—이 대화로 대체된다.
실제 워크플로우는 이렇게 작동한다. 아이디어 탐색(search_articles), 기존 시리즈와의 적합성 확인(list_series), 드래프트 생성(create_draft), 반복 수정(update_article), 최종 발행(publish_article)—이 모든 단계가 하나의 대화 스레드 안에서 완결된다. 탭 전환 없이, 컨텍스트 손실 없이. 그 결과 그는 지난 한 달 동안 지난 1년보다 더 많이 발행했다고 밝혔다.
그런데 MCP를 많이 연결할수록 생기는 역설
MCP의 가능성이 명확해지면서, 개발자들은 자연스럽게 더 많은 MCP 서버를 연결하기 시작했다. 그런데 여기서 구조적인 역설이 발생한다. Claude Code에 MCP 서버 3개만 연결해도, 실제로 사용하지 않는 도구 스키마까지 매 대화마다 컨텍스트 윈도우에 로드된다. 긱뉴스에 공개된 mcp-optimizer 프로젝트에 따르면, 이 토큰 낭비는 대화당 6,500토큰 이상에 달한다. MCP로 마찰을 제거하려 했더니, MCP 자체가 새로운 비용 마찰을 만든 셈이다.
mcp-optimizer는 이 문제를 4단계로 해결한다. mcp-doctor로 서버 상태를 진단하고, mcp-audit으로 실제 사용 패턴을 분석한 뒤, mcp-optimize로 프로젝트별 필요한 서버만 선택적으로 로드한다. 가장 흥미로운 단계는 mcp-to-skills—MCP 도구를 필요할 때만 활성화되는 로컬 스킬로 변환해, 상시 로드 비용 자체를 없애는 접근이다. MCP 생태계가 성숙해질수록, 이런 '메타 최적화 레이어'의 중요성은 커질 수밖에 없다.
AX 관점에서 읽는 MCP의 본질
이 두 사례를 『IT 트렌드 2026』이 제시하는 AX(AI Transformation) 프레임으로 다시 읽으면, 더 넓은 맥락이 보인다. AX의 핵심은 "AI를 얼마나 잘 붙였는가"가 아니라, AI가 판단하고 실행하는 과정을 어떻게 통제 가능한 구조로 만드느냐에 있다. MCP는 바로 그 실행 구조의 핵심 인터페이스다. 에이전트가 외부 시스템—데이터베이스, API, 파일 시스템—과 연결되어 실제로 행동할 수 있게 하는 것이 MCP의 역할이고, devto-mcp 사례는 그 구조가 개인 워크플로우 수준에서 어떻게 구현되는지를 가장 구체적으로 보여주는 예시다.
중요한 것은, 에이전트가 '답변하는 AI'에서 '실행하는 AI'로 전환되는 순간 새로운 설계 책임이 생긴다는 점이다. devto-mcp가 publish_article을 create_draft와 의도적으로 분리한 설계—"발행은 항상 명시적인 한 마디가 필요하다"—는 사소해 보이지만, 에이전트 UX의 핵심 원칙인 '예측 가능성과 사용자 통제권'을 실현한 디테일이다. AI가 실행 권한을 가질수록, 중간 확인 지점의 설계는 선택이 아닌 필수가 된다.
프론트엔드 개발자에게 주는 시사점
이 흐름이 프론트엔드 개발자에게 의미하는 바는 세 가지로 압축된다.
첫째, 워크플로우 설계가 개발 역량이 된다. devto-mcp를 만든 개발자는 새로운 기술을 배운 게 아니라, 자신의 마찰 지점을 정확히 진단하고 MCP로 연결하는 설계를 한 것이다. 어떤 컨텍스트 스위칭이 가장 큰 마찰인지 파악하고, 그것을 대화 안으로 끌어오는 능력—이것이 AI 시대의 개발 생산성 변수다.
둘째, MCP 연결은 설계가 필요하다. mcp-optimizer 사례가 보여주듯, 무분별하게 MCP 서버를 늘리는 것은 새로운 비용 문제를 낳는다. 프로젝트별로 필요한 도구만 활성화하고, 컨텍스트 윈도우를 의도적으로 관리하는 전략이 필요하다. 이는 컴포넌트 번들 사이즈를 관리하는 것과 같은 감각이다—필요한 것만 로드하고, 나머지는 lazy하게.
셋째, '발행 가능한 상태'를 설계에 포함시켜야 한다. 에이전트가 작업을 수행할 때, 최종 실행 전 사용자 확인을 요구하는 게이트를 명시적으로 설계하는 것—이것은 UX 원칙이자 신뢰 설계의 기본이다.
전망: MCP 생태계의 다음 단계
MCP는 지금 빠르게 성숙 중이다. devto-mcp 같은 단일 서비스 연결에서 시작해, 여러 에이전트가 서로 협업하는 A2A(Agent-to-Agent) 구조로 확장되는 흐름이 이미 가시화되고 있다. 그 과정에서 mcp-optimizer 같은 메타 레이어—MCP를 관리하는 MCP—가 개발 툴체인의 표준 구성요소로 자리 잡을 가능성이 높다.
하지만 기술이 아무리 발전해도, 핵심 질문은 변하지 않는다. "이 연결이 실제 사용자의 마찰을 제거하는가?" devto-mcp의 저자가 12개의 초안을 발행으로 이끈 것은, 그 질문에 자신만의 정직한 답을 찾았기 때문이다. AI 에이전트와 MCP가 워크플로우에 깊이 들어올수록, 도구를 선택하는 능력보다 마찰을 진단하는 감각이 더 중요한 역량이 될 것이다.