같은 주에 세 개의 신호가 울렸다
한 주 사이에 눈에 띄는 세 가지 흐름이 동시에 등장했다. GitHub Copilot이 MCP(Model Context Protocol)를 공식 지원하기 시작했고, 개발자가 Scrum 보드를 IDE 안에 직접 심어버린 사례가 나왔으며, AI가 아이디어 한 줄을 Notion 칸반 보드와 GitHub 이슈로 즉각 변환하는 백로그 매니저도 공개됐다. 각각은 독립적인 도구처럼 보이지만, 이 세 가지는 같은 방향을 가리키고 있다. 개발자의 작업 맥락이 에디터 안에서 완결되어야 한다는 것.
핵심 이슈: MCP가 에디터를 허브로 만든다
GitHub Copilot의 MCP 지원은 단순한 기능 추가가 아니다. MCP는 AI 에이전트가 외부 서버—데이터베이스, API, 커스텀 도구—와 표준화된 방식으로 연결되는 개방형 프로토콜이다. Copilot이 이 프로토콜을 품으면서, VS Code는 사실상 AI 에이전트의 허브로 탈바꿈하기 시작했다.
실질적인 문제는 이랬다. 새 채팅을 열 때마다 AI는 백지 상태로 시작한다. 지난주 인증 플로우에서 내린 결정, 팀이 Redux 대신 Zustand를 쓰기로 한 맥락, 빌링 모듈의 유럽 세금 코드 특수 처리—매 세션마다 처음부터 다시 설명해야 했다. dev.to에 공개된 ContextForge 사례는 이 문제를 정면으로 겨냥한다. MCP 서버를 통해 Copilot에 영구 메모리를 심는 것이다. 프로젝트 루트에 .mcp.json 파일 하나를 추가하면, 아키텍처 결정 사항과 네이밍 컨벤션, 디버깅 노트가 세션을 넘어 누적된다. RAM과 하드드라이브의 차이—컨텍스트 윈도우가 아무리 넓어도 세션이 끝나면 사라지지만, 영구 메모리는 프로젝트 지식 자산으로 쌓인다.
맥락 해석: 컨텍스트 스위칭은 생산성의 진짜 적이었다
여기서 주목할 것은 기술 스펙이 아니라 왜 지금 이 흐름이 수렴하는가다.
개발자의 작업 방해 비용은 단순히 전환에 걸리는 시간이 아니다. 집중 상태로 다시 진입하는 데 걸리는 시간, 맥락을 재구성하는 인지 부하, 그리고 '아, 뭐 하려고 했더라'는 순간의 작업 손실이 함께 청구된다. Jira나 Asana 같은 기존 PM 툴이 개발자에게 외면받는 이유가 바로 여기 있다. Lasimban(나침반이라는 뜻의 일본어에서 따온 이름)이라는 Scrum 보드 프로젝트가 이를 잘 보여준다. dev.to에 공개된 이 프로젝트의 핵심은 화려한 기능이 아니다—스프린트 시작 시 돛단배 애니메이션, 태스크 완료 시 스파클 이펙트, PBI 완료 시 폭죽 같은 마이크로 인터랙션도 흥미롭지만, 진짜 설계 철학은 MCP를 통해 에디터 안에서 Scrum 보드를 직접 조작하는 데 있다. "현재 스프린트 상태 요약해줘", "가장 남은 태스크 많은 PBI가 뭐야", "LSMB-42 완료 처리해줘"—브라우저를 열지 않아도 된다.
세 번째 사례인 AI 백로그 매니저는 한 단계 더 나아간다. Gemini 2.5 Flash와 MCP를 결합해 "농촌 클리닉용 태양광 모니터링 시스템"이라는 문장 하나를 5초 안에 Notion 칸반 보드와 GitHub 이슈로 분해한다. 아이디어에서 실행 가능한 태스크로의 전환—그 마찰 자체를 AI가 흡수한다.
시사점: 에디터는 이제 '운영 체제'다
이 세 흐름이 동시에 등장한다는 것은 MCP가 단순한 플러그인 규격을 넘어 에디터 중심 AI 생태계의 공통 언어로 자리잡고 있다는 신호다. Cursor, Claude Code, GitHub Copilot이 같은 MCP 서버를 공유하고, 동일한 메모리와 프로젝트 컨텍스트를 참조할 수 있다는 것—이건 도구들 사이의 칸막이가 허물어지는 것을 의미한다.
프론트엔드 개발자 관점에서 이 흐름이 특히 의미 있는 이유는 DX(개발자 경험)의 정의가 바뀌고 있어서다. 과거의 DX 최적화는 빌드 속도나 HMR 성능 같은 툴링 레이어의 문제였다. 지금은 AI와의 협업 마찰, 프로젝트 지식의 영속성, 태스크 관리의 에디터 통합 같은 워크플로우 레이어가 DX의 핵심 변수가 됐다. 에디터가 코드 편집기를 넘어 프로젝트의 신경계—기억, 계획, 실행을 통합하는 운영 체제—가 되고 있다.
전망: 표준 전쟁이 아니라 생태계 경쟁이 온다
앞으로의 경쟁은 어떤 에디터가 더 좋은 자동완성을 제공하느냐가 아니다. 어떤 에디터가 더 풍부한 MCP 생태계를 품느냐의 싸움이 될 것이다. 기억, 태스크 관리, 문서, 모니터링, 배포 파이프라인—이 모든 것이 MCP 서버로 에디터 안에 연결되는 세계에서, 개발자가 컨텍스트 스위칭에 쓰는 시간은 점점 0에 수렴할 것이다.
단, 주의할 점이 있다. MCP 서버가 늘어날수록 토큰 소비와 지연 시간 관리가 새로운 복잡성으로 등장한다. Lasimban이 SSE 대신 Stateless HTTP를 선택하고, 응답을 JSON이 아닌 Markdown으로 반환하도록 설계한 것은—LLM이 구조화된 데이터보다 자연어 형식의 텍스트를 더 잘 요약한다는 실용적 판단이다. 이런 세부 설계가 에디터 중심 AI 생태계의 품질을 좌우할 것이다.
에디터 밖으로 나가지 않아도 되는 개발자 경험. 그 세계가 MCP를 통해 조용하지만 빠르게 실현되고 있다.