MCP의 두 번째 물결: 개발자가 아닌 LLM을 위한 설계

초기 MCP 구현들이 기존 API를 얇게 래핑하는 데 그쳐 LLM이 멀티스텝 작업을 매 대화마다 재발견해야 하는 비효율 문제를 지적한다. LLM은 개발자와 달리 과거 코드를 재사용하지 않고 장기 상태도 유지하지 않는다. 의도 기반 도구(intention-based tools)를 설계해 단일 도구가 완전한 워크플로우를 내부 처리하도록 바꾸는 것이 핵심 해결책이다.

핵심 포인트

MCP 1세대 함정: 기존 API를 1:1 래핑 → LLM이 상태 관리·멀티스텝 오케스트레이션을 매 대화마다 재발견해야 해 불일관한 결과 초래.
LLM-개발자 근본 차이: LLM은 과거 코드 재사용 없음, 장기 상태 없음, 매 대화가 리셋 — API 단위 도구는 이 특성을 무시.
의도 기반 도구: create_project + add_env + deploy + add_domain 4개 → 단일 deploy_project 도구로 통합, 내부에서 완전한 워크플로우 처리.
도구 설계 4원칙: 수동 테스트 먼저(코딩 전 워크플로우 직접 실행), 맞춤형 키트 취급(API 미러 X), 결정론적 코드 사용(LLM은 추론 전담), 현실적 시나리오로 첫 시도 성공 검증.
기술 상태 코드 대신 대화형 피드백: LLM이 결과를 해석하기 쉽도록 자연어 업데이트 반환.

상세 정리

MCP 1세대 패턴: 기존 REST API를 그대로 래핑 — create_project, add_env, deploy, add_domain 각각 별개 도구 노출.
불일관성 원인: LLM이 각 단계를 매 대화에서 다시 발견 → 단계 누락, 순서 오류, 비효율적 재시도 발생.
LLM의 상태 모델: 과거 실행 기억 없음, 장기 컨텍스트 없음 → 각 대화가 상태 없는 첫 실행으로 시작.
의도 기반 설계 예시: "프로젝트 배포" 한 마디로 repo 설정, 환경 변수 추가, 배포, 도메인 구성을 단일 도구가 원자적 처리.
수동 테스트 먼저: 도구 코딩 전에 실제 워크플로우를 손으로 걸어보며 LLM 관점에서 필요한 정보 파악.
결정론적 코드 원칙: LLM을 추론(what to do) 에만 투입하고, 실행(how to do)은 결정론적 코드로. 비결정론을 LLM에 맡기면 재현성 저하.
반환값 최적화: HTTP 상태 코드(200, 404)보다 "프로젝트 배포 완료, 도메인 example.com 연결됨" 같은 자연어 피드백이 LLM 해석에 적합.
첫 시도 성공 기준: 복잡한 멀티스텝 워크플로우가 첫 LLM 호출에서 성공하는지로 도구 품질 검증.