사용자가 당신의 제품을 처음 만나는 방식이 조용히 바뀌고 있다. 예전에는 Google에서 검색하고, 홈페이지를 훑고, CTA 버튼을 클릭하는 흐름이 당연했다. 지금은 Claude나 ChatGPT에 "내 상황에 맞는 인보이스 툴 찾아줘"라고 물으면 AI가 두세 개의 제품을 골라 답해준다. 당신의 히어로 섹션은 한 번도 노출되지 않고, 정성껏 A/B 테스트한 버튼은 한 번도 클릭되지 않는다. dev.to의 'Is UI Dead?' 아티클이 정확히 짚은 장면이다. 이건 먼 미래 이야기가 아니다. 이미 일어나고 있는 구조 변화다.
핵심은 이것이다. AI 에이전트는 웹사이트를 탐색하지 않는다. API를 호출하고, 스키마를 읽고, 기능을 실행한다. 에이전트가 당신의 제품을 발견하고 호출할 수 없다면, 에이전트 레이어에서 당신의 제품은 존재하지 않는 것과 같다. 'Is UI Dead?' 아티클이 제안하는 개념인 '에이전트 접근 가능한 설계(agent-accessible design)'는 결국 이런 질문으로 귀결된다. "AI가 내 제품의 기능을 발견하고, 올바르게 호출하고, 의미 있는 결과를 200ms 안에 받을 수 있는가?"
이 질문에 "그렇다"고 답하려면 팀의 멘탈 모델부터 바꿔야 한다. 지금 대부분의 로드맵은 여전히 "어떤 페이지를 만들 것인가"로 구성된다. 피처 → 스크린 → 유저 플로우 → UI 컴포넌트. 이 구조는 마우스와 손가락으로 브라우저를 탐색하는 사람을 위한 것이다. 에이전트를 위한 설계는 다르다. 페이지 대신 기능(capability)을 단위로 생각해야 한다. /invoices/new라는 폼 페이지가 있다면, 그것과 대응하는 POST /invoices라는 호출 가능한 API 엔드포인트가 있어야 한다. 모든 사용자 플로우에는 기계가 접근할 수 있는 대응 기능이 있어야 한다는 뜻이다.
그 다음 문제는 발견 가능성이다. 에이전트 인터페이스에서 발견 가능성은 웹에서의 SEO와 같다. OpenAPI 스펙을 공개하되, 개발자가 아닌 LLM이 읽는다고 가정하고 description을 써야 한다. POST /txn이 아니라 "인증된 사용자가 한 계좌에서 다른 계좌로 금융 거래를 생성합니다. 이체 권한이 필요합니다."처럼. 그리고 이 모든 것의 기반이 되는 프로토콜이 Model Context Protocol(MCP)이다. Anthropic이 도입하고 업계 전반에서 채택 중인 이 표준은, HTTP가 웹의 기반이 된 것처럼 에이전트 인터페이스의 상호운용성을 가능하게 하는 인프라 레이어다.
MCP를 실제 Next.js 프로젝트에 도입하는 일은 생각보다 현실적이다. dev.to의 'Per User OAuth in a Next.js MCP Server' 아티클은 공유 API 키로 인한 보안 문제를 해결하는 구체적인 패턴을 보여준다. 핵심 인사이트는 간단하다. Next.js의 Route Handler는 요청 컨텍스트 안에서 실행되므로 세션에 완전히 접근할 수 있다. MCP 서버 인스턴스를 이 핸들러 안에서 생성하면, 각 툴 클로저가 실행 전에 해당 사용자의 인증 토큰을 캡처한다. Alice와 Bob이 동시에 /api/mcp를 호출해도 각자의 레포지토리만 볼 수 있는 이유다. 글로벌 상태도, 공유 크리덴셜도 없다. 요청 단위로 완전히 격리된다.
구현 패턴을 정리하면 이렇다. NextAuth를 통해 OAuth 액세스 토큰을 세션 쿠키에 저장하고, /api/mcp Route Handler 안에서 auth()로 세션을 읽어 인증된 사용자 컨텍스트를 확보한다. MCP 핸들러 인스턴스는 이 핸들러 내부에서 생성되며, 모든 툴 등록은 session을 클로저로 캡처한다. 토큰 만료나 SSE 기반 상태 유지 세션이 필요하다면 Redis를 추가하면 된다. 기존 REST API를 MCP 툴로 래핑하는 것은 얇은 어댑터 레이어를 추가하는 수준이지, 전체를 다시 짜는 일이 아니다.
그런데 여기서 한 가지 더 주목할 변화가 있다. 에이전트 레이어가 중요해질수록, 코드를 쓰기 전에 스펙을 먼저 설계하는 일의 가치가 극적으로 높아진다. dev.to의 'From Idea to Specs' 아티클에서 HandyFEM을 개발한 Constanza Diaz가 보여준 접근법이 시사점이 크다. Claude.ai를 코드 생성기가 아닌 사고 파트너로 쓰며 스펙을 먼저 작성하고, 그 스펙이 AI 코드 생성의 프롬프트가 되는 흐름이다. shadcn/ui 컴포넌트의 모든 변형, 상태, 접근성 요구사항, 색상 토큰, Supabase 쿼리 로직을 스펙 문서로 먼저 정의하고, 그것을 Claude에 넘겨 첫 시도에 붙여넣기 가능한 코드를 얻는 방식이다. 스펙은 오버헤드가 아니라 작업 그 자체라는 통찰은, 에이전트와 AI 툴이 주도하는 개발 환경일수록 더 강하게 작동한다.
세 흐름을 묶으면 하나의 실무 방향이 보인다. 에이전트 시대의 프론트엔드 개발자는 세 가지를 동시에 설계해야 한다. 첫째, 사람이 보는 UI와 에이전트가 호출하는 API 기능(capability)을 쌍으로 설계할 것. 둘째, MCP 툴의 인증 격리와 발견 가능성을 처음부터 아키텍처에 포함할 것. 셋째, 스펙을 먼저 쓰고 AI에게 구현을 위임하는 순서를 습관화할 것. UI가 죽은 것이 아니다. UI의 역할이 진입점에서 확인·수정의 인터페이스로 이동하고 있을 뿐이다. 그 이동을 먼저 설계에 반영하는 팀이, 에이전트 레이어에서도 사용자를 만나게 될 것이다.