당신의 홈페이지는 더 이상 첫인상이 아닙니다. AI 에이전트(AI agent)가 그 역할을 대신할 수도 있습니다.

이런 상황을 상상해 보세요: 한 사용자가 프리랜서 비즈니스를 위한 최고의 인보이스(invoicing) 도구를 찾고 싶어 합니다. 3년 전이라면, 그들은 브라우저를 열고, Google에서 "최고의 인보이스 소프트웨어"를 검색하고, 5개의 링크를 클릭하고, 5개의 홈페이지를 훑어본 뒤, 아마도 체험판에 가입했을 것입니다.

오늘날 그들은 ChatGPT, Claude, 또는 맞춤형 AI 어시스턴트(AI assistant)를 열고 이렇게 묻습니다: "내 나이지리아 은행과 연동되고, 자동으로 알림을 보내며, 무료 티어(free tier)가 있는 인보이스 도구를 찾아줘."

AI가 답변합니다. 두세 개의 제품을 골라줍니다. 심지어 가입 절차를 시작할 수도 있습니다.

당신의 홈페이지는 방문되지 않았습니다. 당신의 아름다운 히어로 섹션(hero section)은 보이지 않았습니다. 당신이 정성스럽게 A/B 테스트를 거친 CTA 버튼은 클릭되지 않았습니다.

이것은 가설이 아닙니다. 이것은 에이전틱 웹(agentic web)이며, 대부분의 엔지니어링 및 제품 팀은 여전히 에이전트가 대체하고 있는 인터페이스만을 위해 제품을 만들고 있습니다.

브라우저는 인터페이스가 아니었습니다. 주의력(Attention)이 인터페이스였습니다.

우리는 전달 메커니즘(delivery mechanism)을 실제 목표와 혼동했습니다. 브라우저는 사용자가 자신의 문제를 해결해 줄 제품으로 주의력을 향하게 하는 통로(pipe)였을 뿐입니다. 우리는 통로를 최적화했습니다 — 더 빠른 로딩 시간, 더 예쁜 애니메이션, 더 매끄러운 온보딩(onboarding) 흐름 — 그리고 사용자들이 계속해서 동일한 통로를 사용할 것인지 묻는 것을 잊었습니다.

그들은 그러지 않을 것입니다.

AI 어시스턴트는 모든 제품의 _상위_에 위치하는 주변부 인터페이스 계층(ambient interface layer)이 되었습니다. 사용자는 AI와 먼저 상호작용하고, AI는 사용자를 대신하여 당신의 제품과 상호작용합니다. 브라우저는 여전히 존재합니다. 화면도 여전히 중요합니다. 하지만 브라우저는 점점 더 폴백(fallback) — 즉, AI가 사용자가 무엇을 사용할지 이미 결정한 후에 사용자가 가는 장소 — 가 되어가고 있습니다.

이것은 UI의 죽음이 아닙니다. 대부분의 팀이 대비하지 못하고 있는 새로운 기본 인터페이스의 탄생입니다.

"에이전틱 우선(Agentic-First)"이 실제로 의미하는 것

에이전틱 시스템(agentic system)은 단순한 챗봇이 아닙니다. 그것은 다음과 같은 능력을 갖춘 AI입니다:

• 계획 (Plan): 다단계 작업 수행 ("도구를 찾고, 가격을 비교하고, 계정을 생성한 뒤, 프로젝트를 설정하라")
• 도구 호출 (Call tools): 정보 수집 및 실행을 위해 API, 데이터베이스, 서비스 등을 호출
• 관찰 (Observe): 각 작업의 결과를 관찰하고 그에 따라 다음 단계를 조정
• 자율적 행동 (Act autonomously): 사용자에게 아무것도 클릭하라고 요청하지 않고 스스로 행동

사용자가 AI 에이전트(AI agent)에게 작업을 위임할 때, 에이전트는 귀하의 웹사이트를 브라우징하지 않습니다. 에이전트는 귀하의 API를 호출합니다. 귀하의 스키마(schema)를 읽습니다. 귀하의 기능(capabilities)을 호출합니다. 만약 귀하의 제품이 에이전트가 발견하고 사용할 수 있는 방식으로 이러한 기능들을 노출하지 않는다면, 귀하의 제품은 에이전트 계층(agentic layer)에서 존재하지 않는 것이나 다름없습니다.

이것이 고객 획득(customer acquisition), 유지(retention), 경쟁적 포지셔닝(competitive positioning)에 어떤 의미를 갖는지 생각해 보십시오. 향후 5년 동안 승리할 제품은 반드시 최고의 UI를 가진 제품은 아닐 것입니다. 그들은 설계 단계부터 에이전트 접근이 가능하도록(agent-accessible by design) 만들어진 제품들일 것입니다.

문제점: 우리는 여전히 페이지 단위로 생각한다

대부분의 제품 및 엔지니어링 팀은 다음과 같은 멘탈 모델(mental model)을 중심으로 업무를 구성합니다:

• 기능(Feature) → 화면(Screen) → 사용자 흐름(User flow) → UI 컴포넌트(UI component)
• 로드맵(Roadmap) = 새로운 페이지 또는 상호작용(interactions)의 목록
• "완료(Done)"란 "시각적으로 완성되었고 클릭이 가능함"을 의미

이 모델은 마우스와 손가락으로 브라우저를 탐색하는 인간을 위해 구축되었습니다. 에이전트 인터페이스(agentic interfaces) 관점에서는 근본적으로 잘못되었습니다.

에이전트는 탐색하지 않습니다. 클릭하지 않습니다. 귀하의 마케팅 문구를 읽거나 온보딩(onboarding) 영상을 시청하지도 않습니다. 에이전트는 **함수를 호출(calls a function)**하고, 구조화된 응답(structured response)을 읽으며, 귀하의 제품이 사용자의 의도(intent)를 충족할 수 있는지 결정한 뒤, 작업을 진행하거나 귀하의 경쟁사로 넘어갑니다.

질문은 다음과 같이 변화합니다:

"홈페이지가 전환 최적화(conversion-optimized)되어 있는가?"

에서:

_"AI 에이전트가 내 제품이 무엇을 하는지 발견하고, 올바르게 호출하며, 200ms 이내에 의미 있는 결과를 얻을 수 있는가?"로 말입니다.

대부분의 팀은 이에 대해 "예"라고 답하지 못합니다. 그들이 형편없는 엔지니어라서가 아니라, 한 번도 이런 방식으로 생각하도록 요구받은 적이 없기 때문입니다.

팀이 수행해야 할 세 가지 변화

1. 페이지가 아닌 기능(Capabilities) 단위로 생각하라

페이지는 인간의 시각적 경험을 위한 컨테이너입니다. 기능(Capability)은 제품이 수행할 수 있는 동작이며, 호출 가능하고(callable), 문서화되었으며(documented), 관리 가능한(governable) 단위로 노출됩니다.

제품을 기능 그래프(capability graph)로 매핑하기 시작하십시오:

사용자 접점의 모든 흐름(flow)은 그에 상응하는 기계 접근 가능 기능(machine-accessible capability)을 가져야 합니다. 그렇지 않다면 에이전트는 이를 사용할 수 없습니다.

2. 에이전트가 발견할 수 있는 동작을 노출하라

발견 가능성(Discoverability)은 웹에서의 SEO가 그러하듯, 에이전트 인터페이스(agentic interfaces)에 있어 매우 중요합니다. 에이전트가 당신의 제품이 무엇을 하는지, 어떻게 사용하는지 발견할 수 없다면, 홈페이지의 검색 순위가 아무리 높더라도 당신은 보이지 않는 존재가 됩니다.

이는 다음을 의미합니다:

• 에이전트가 호출하기를 원하는 모든 API 엔드포인트에 대해 OpenAPI (Swagger) 명세(spec)를 게시하십시오. 단순히 구문(syntax)만 설명하는 것이 아니라, 의도(intent)를 설명하는 명확한 operationId 이름과 description 필드를 포함해야 합니다.
• 개발자가 아닌 에이전트를 위한 설명을 작성하십시오. 개발자는 POST /txn을 보고 의도를 추론합니다. 하지만 LLM(대규모 언어 모델)에는 다음과 같은 설명이 필요합니다: "하나의 계좌에서 다른 계좌로 새로운 금융 거래를 생성합니다. 이체 권한이 있는 인증된 사용자가 필요합니다."
• 기능의 버전을 명시적으로 관리하십시오. 운영 환경에서 당신의 API에 의존하는 에이전트들이 파괴적 변경(breaking changes)으로 인해 당황하는 일이 없어야 합니다. API 계약(contract)을 UI 디자인 시스템을 다루는 것과 동일한 엄격함으로 다루십시오.
• 구조화되고 의미론적인(semantic) 응답을 반환하십시오. GET /products를 호출하고 HTML 덩어리(blob)를 받는 에이전트는 결과를 파싱할 수 없습니다. 필드 이름이 잘 지정된 깨끗한 JSON을 반환하십시오.

3. MCP를 학습하라 — 이것이 에이전트 웹의 인터페이스 프로토콜이다

Anthropic이 도입하고 현재 업계 전반에서 널리 채택되고 있는 **Model Context Protocol (MCP)**는 AI 에이전트가 외부 도구를 구조화되고 관리된 방식으로 발견하고 호출할 수 있게 해주는 표준입니다. 이는 HTTP가 웹에 그러했듯, 상호 운용성(interoperability)을 가능하게 하는 기초적인 프로토콜로서 에이전트 인터페이스의 근간이 됩니다.

MCP 서버는 제품의 기능을 도구 (tools) 로 노출합니다. 이는 이름이 지정되고 문서화된 함수로서, 입력 스키마 (input schemas) 및 출력 계약 (output contracts)을 포함하며, MCP 호환 에이전트 (Claude, function calling 기능이 있는 GPT-4o, 커스텀 LangChain 에이전트 등)가 네이티브하게 호출할 수 있습니다. 스크래핑 (scraping)도, 브라우저 자동화 (browser automation)도, 프롬프트 엔지니어링 (prompt engineering)을 위한 복잡한 기술도 필요하지 않습니다.

// 예시: MCP를 통해 송장 생성 기능을 노출함
{
  name: "create_invoice",
...

이러한 정의를 통해, 어떤 AI 에이전트라도 create_invoice가 무엇을 하는지 이해하고, 처음부터 올바르게 호출하며, 인간의 클릭 없이도 사용자에게 결과를 제시할 수 있습니다. 이것이 바로 작동하는 에이전트 인터페이스 (agentic interface)입니다.

MCP 지원을 구축하는 실질적인 방법:

1. 기존 REST API를 MCP 도구로 래핑 (wrap) 합니다 — 이는 재작성이 아닌 얇은 어댑터 계층 (adapter layer) 작업입니다.
2. MCP 서버를 호스팅합니다 (개발 중에는 로컬에서, 운영 환경에서는 사이드카 (sidecar) 또는 서비스로).
3. 신흥 MCP 디렉토리 및 에이전트 플랫폼에 등록하여 도구가 발견될 수 있도록 합니다.
4. 범위가 제한된 인증 (scoped authentication)을 구현합니다 — 에이전트는 최소 권한 원칙 (least-privilege)에 따른 토큰을 요청해야 하며, 결코 전체 관리자 권한을 가져서는 안 됩니다.
5. 감사 가능성 (auditability)과 디버깅을 위해 모든 에이전트 호출을 트레이스 ID (trace IDs)와 함께 기록합니다.

UI는 죽지 않았다 — 하지만 그 역할은 변하고 있다

미묘한 차이가 중요하므로 정확하게 짚고 넘어가겠습니다.

UI는 죽지 않습니다. 시각적 인터페이스 (visual interfaces)가 사라지는 것도 아닙니다. 화면이 없어지는 것도 아닙니다.

변하고 있는 것은 사용자 여정 (user journey)에서 UI가 담당하는 역할입니다. 수십 년 동안 UI는 진입점 (entry point), 결정 표면 (decision surface), 그리고 상호작용 계층 (interaction layer) 역할을 동시에 수행해 왔습니다. 에이전트 웹 (agentic web)에서 UI는 주로 확인 및 검토 계층 (confirmation and review layer) 이 됩니다. 즉, 사용자가 에이전트가 수행한 작업을 감사하고, 설정을 구성하며, 출력을 검토하고, 인간의 판단이 필요한 예외 상황을 처리하기 위해 방문하는 장소가 되는 것입니다.

이메일 클라이언트가 어떻게 진화했는지 생각해 보십시오. 2005년에는 모든 이메일을 직접 읽고 수동으로 조치했습니다. 2025년이 된 지금, AI는 스팸을 필터링하고, 답장 초안을 작성하며, 스레드를 요약하고, 당신을 대신해 회의 일정을 잡습니다. 당신은 주요 작업을 수행하기 위해서가 아니라, 검토하고 확인하기 위해 이메일 클라이언트를 엽니다. 당신의 UI는 여전히 존재합니다. 다만 그 역할이 하류(downstream)로 이동했을 뿐입니다.

핀테크 앱, 이커머스 플랫폼, SaaS 도구, 생산성 소프트웨어 등 모든 제품 카테고리에서 동일한 전환이 일어나고 있습니다. 에이전트(Agent)가 작업을 수행하고, UI는 그 결과를 보여줍니다. 두 가지 모두를 위해 설계하십시오.

오늘날 개발자에게 이것이 의미하는 바

프론트엔드 개발(Frontend development)에 대해 알고 있는 모든 것을 버릴 필요는 없습니다. 다만 여러분의 멘탈 모델(Mental model)을 확장해야 합니다. 여기 구체적인 시작점이 있습니다:

이번 주:

• 제품의 API 커버리지(API coverage)를 감사하십시오. UI에서 할 수 있는 일 중 대응하는 API 엔드포인트(Endpoint)가 없는 것은 무엇입니까?
• MCP 명세(Specification)를 읽으십시오(내용이 짧습니다). 해당 문맥에서 도구(Tool), 리소스(Resource), 프롬프트(Prompt)가 무엇을 의미하는지 이해하십시오.

이번 달:

• 가장 많이 사용되는 세 가지 기능에 대해 에이전트가 읽을 수 있는 설명(Agent-readable descriptions)을 포함한 OpenAPI 문서를 작성하십시오.
• 가장 중요한 다섯 가지 사용자 작업을 호출 가능한 도구(Callable tools)로 노출하는 최소한의 MCP 서버를 구축하십시오.
• 테스트하십시오: Claude 또는 GPT-4o 에이전트에게 여러분의 MCP 서버에 대한 접근 권한을 주고, 실제 사용자 작업을 처음부터 끝까지(End-to-end) 완료하도록 요청하십시오.

이번 분기:

• 팀을 위한 "에이전트 중심 API 계약(Agentic API contract)" 표준을 정의하십시오. 이는 새로운 기능이 출시되기 전에 반드시 충족해야 하는 체크리스트입니다(구조화된 응답, 문서화된 기능, MCP 등록).
• 접근성(Accessibility)이나 모바일 반응형(Mobile responsiveness)과 나란히, 제품 백로그(Product backlog)에 에이전트 가독성(Agent-readability)을 일급 수용 기준(First-class acceptance criterion)으로 추가하십시오.

경쟁의 현실

이러한 변화를 지연시키는 제품 팀들에게는 불편한 진실이 있습니다.

사용자들이 에이전트 (Agent)에게 작업을 위임하는 세상에서는, 에이전트가 접근 가능한 제품이 그렇지 않은 제품보다 선택될 것입니다. 설령 에이전트 접근이 불가능한 제품이 더 나은 UI, 더 나은 브랜드, 더 나은 가격을 갖추고 있더라도 말입니다. 에이전트는 UI를 평가할 수 없습니다. 오직 기능 (Capabilities)만을 평가할 수 있습니다.

여러분은 이미 모바일 환경에서 이러한 역학 관계가 전개되는 것을 목격했습니다. 2010년에 모바일을 사후 고려 사항으로 취급했던 팀들은 모바일 퍼스트 (Mobile-first) 경쟁사들에게 사용자 기반을 잠식당하는 것을 지켜봐야 했습니다. 그들이 대응했을 때쯤에는 사용자의 전환 비용 (Switching cost)이 이미 지불된 상태였습니다. 동일한 강제적 동인 (Forcing function)이 에이전트 웹 (Agentic web)에도 다가오고 있으며, 기능 우선 (Capability-first)으로 구축할 수 있는 기회의 창은 모바일 시대의 창보다 더 좁습니다.

마지막 생각

여러분의 다음 스프린트 (Sprint)를 위한 가장 중요한 질문은 _"어떻게 하면 온보딩 (Onboarding) 흐름을 더 직관적으로 만들 수 있을까?"_가 아닙니다.

그것은 바로 다음과 같습니다: "만약 지금 당장 AI 에이전트가 사용자를 대신하여 우리 제품을 사용하려고 시도한다면, 성공할 수 있을까?"

만약 대답이 '아니오'이거나, 혹은 여러분의 팀이 이 질문을 한 번도 던져본 적이 없다면, 여러분은 다음 아키텍처 우선순위 (Architectural priority)를 찾은 것입니다.

아름다운 UI를 만드십시오. 훌륭한 경험을 설계하십시오. 하지만 사용자가 여러분의 홈페이지를 보기도 전에 여러분의 API를 두드릴 에이전트를 위해서도 구축하십시오.

앞문 (Front door)의 형태가 방금 바뀌었습니다.

MCP 서버, 에이전트 API (Agentic APIs), 또는 기능 우선 아키텍처 (Capability-first architectures)를 구축하고 계신가요? 질문이나 여러분의 MCP 도구 정의를 댓글로 남겨주세요. 함께 의견을 나누어 봅시다.