AI 코딩 도구가 개발 속도를 바꾼 건 사실이다. 하지만 솔직히 말하자면, 우리 대부분이 경험한 AI의 진짜 한계는 '처음 80%'가 아니라 '나머지 20%'에 있다. 레이아웃 스캐폴딩, 컴포넌트 생성, 보일러플레이트 제거—이 영역에서 AI는 이미 충분히 빠르다. 문제는 그 다음이다. 인증 엣지 케이스, 배포 복잡도, API 비일관성, 실제 트래픽 아래서의 성능 저하. dev.to의 분석처럼, "AI가 생성한 프로젝트는 처음엔 인상적이지만 실제 사용자가 오면 유지보수가 어려워진다." 이 마지막 20%는 단순한 코드 생성 문제가 아니라 판단과 구조의 문제다.
그런데 최근 흥미로운 변화가 생겼다. Cursor가 에이전트 SDK를 공개하면서, 이 도구가 더 이상 IDE 안에만 머물지 않아도 되는 시대가 열렸다. Cursor Agents SDK는 데스크탑 앱을 구동하는 것과 동일한 하네스—컨텍스트 엔진, 워크스페이스 관리, 라우팅—를 프로그래밍 방식으로 제공한다. 주목할 수치가 있다. Endor Labs의 벤치마크에 따르면, GPT-4.5를 단독으로 실행했을 때 기능 정확도가 61.5%였지만, 같은 모델을 Cursor의 하네스 위에 올렸더니 87.2%까지 올랐다. 모델보다 하네스가 더 중요하다는 말이 단순한 마케팅 문구가 아닌 셈이다.
이 SDK의 실질적인 가치는 세 가지 방향으로 열린다. 첫째, CI/CD 파이프라인에서 에이전트를 직접 호출할 수 있다. PR이 열릴 때마다 코드 분석·리팩토링·브랜치 생성·PR 오픈까지 자동화하는 GitHub 에이전트가 대표적인 예다. 둘째, 헤드리스 인프라로서 엔드-투-엔드 워크플로우 자동화를 구성할 수 있다. 셋째, 핵심 프로덕트 안에 에이전트를 임베딩할 수 있다. npm install @cursor/sdk 한 줄로 시작해서, 기존엔 수주가 걸렸을 외부 서비스 연동을 Composio 같은 오케스트레이터와 결합하면 1,000개 이상의 툴에 즉시 접근할 수 있다.
하지만 SDK를 꺼내는 것만으로는 마지막 20% 문제가 해결되지 않는다. 이 지점에서 Tools·MCP·Skills라는 세 레이어 아키텍처를 이해하는 것이 결정적이다. dev.to의 Auth0 아티클이 이 구분을 명확하게 정리했다. Tool은 모델이 호출할 수 있는 단일 함수다. 언제 호출할지는 모델이 판단하고, 실제 실행은 호스트 애플리케이션이 담당한다. MCP(Model Context Protocol)는 AI 애플리케이션과 서비스 사이의 프로토콜 레이어다. USB-C처럼 어떤 클라이언트든 어떤 서버든 연결 가능하게 만드는 범용 커넥터 역할을 한다. 한 번 구축하면 모든 컴플라이언트 클라이언트에서 재사용할 수 있다는 점이 핵심이다. 그리고 Skill은 이 둘을 언제, 어떤 순서로, 어떤 조건 아래에서 사용할지를 정의하는 레시피다. 시스템 프롬프트, 워크플로우 로직, 툴 선택 전략을 하나로 묶어 복잡한 목표를 달성하게 한다.
이 세 레이어가 실무적으로 왜 중요한가. Tool만 있으면 에이전트는 '무엇을 할 수 있는지'는 알지만 '어떤 순서로, 어떤 조건에서 해야 하는지'를 모른다. MCP가 없으면 통합마다 별도의 함수 스키마를 작성해야 하고, 같은 기능을 클라이언트마다 재구현하는 낭비가 생긴다. Skill이 없으면 에이전트는 툴을 쥐고 있지만 도메인 판단력이 없다. Cursor SDK + Composio MCP + .cursor/skills/ 조합이 흥미로운 이유는, 이 세 레이어를 하나의 스택으로 연결하기 때문이다. 에이전트는 Skill로 목표를 이해하고, MCP로 외부 서비스에 연결하며, Tool을 통해 실제 액션을 실행한다.
그렇다면 이 구조가 마지막 20% 문제에 어떤 답을 주는가. 솔직히 말하면, 완전한 해답은 아니다. 인증 플로우의 보안성, 트래픽 급증 시 아키텍처 내구성, 6개월 후의 유지보수 가능성—이런 질문들은 여전히 개발자의 판단 영역이다. 하지만 구조가 달라지면 판단이 개입해야 할 지점이 달라진다. 반복적이고 예측 가능한 작업—브랜치 생성, 코드 리팩토링, PR 초안 작성, 외부 API 통합 검증—을 에이전트가 자동화하면, 개발자는 진짜 판단이 필요한 영역에 더 많은 에너지를 쓸 수 있다. AI가 속도를 가져가고, 사람이 맥락과 트레이드오프를 책임지는 하이브리드 구조가 현실적인 대안이 된다.
전망은 이렇다. IDE 안에서 AI를 쓰는 것은 이미 디폴트가 됐다. 다음 경쟁은 IDE 밖에서 시작된다. CI/CD에서 에이전트를 호출하고, 배포 파이프라인에 Skills를 심고, MCP로 프로덕션 서비스와 연결하는 팀이 마지막 20%에서 구조적 우위를 갖게 될 것이다. Cursor Agents SDK의 공개는 이 방향의 첫 번째 구체적인 신호다. 도구를 IDE 안에 가두지 않고, 프로덕션 워크플로우 전반으로 확장할 때—그때 비로소 AI 코딩 도구의 진짜 가치가 드러난다.