AI 안경 앱을 만들려면 전용 SDK와 새로운 UI 프레임워크부터 배워야 할 것 같았습니다.

그런데 Meta가 2026년 Connect에서 공개한 방향은 조금 다릅니다.

HTML, CSS, JavaScript를 이미 쓸 줄 안다면 그 기술 그대로 Meta Ray-Ban Display용 Web App을 만들 수 있고, WebMCP를 이용하면 앱의 일부 기능을 Meta AI가 직접 호출하게 만들 수도 있습니다.

예를 들어 사용자가 안경을 쓰고 이렇게 말한다고 해보겠습니다.

"장보기 목록에 우유 추가해줘."

기존 방식이라면 AI가 화면을 보고 버튼을 찾아 누르거나, 별도의 앱 전용 연동 API가 필요할 수 있습니다.

WebMCP에서는 웹사이트가 아예 다음처럼 선언할 수 있습니다.

이 웹 앱이 AI에게 허용하는 기능

- add_item
- complete_item
- show_today_list

Meta AI는 그중 허용된 기능만 찾아 호출합니다.

여기서 중요한 변화는 단순히 "안경에서 웹페이지가 열린다"가 아닙니다.

웹 앱이 사람뿐 아니라 AI Agent가 사용할 수 있는 인터페이스도 함께 제공하기 시작한다는 점입니다.

먼저 Web App과 WebMCP를 구분해야 합니다

두 개를 같은 기술처럼 보면 이해하기 어렵습니다.

Web App

Meta Ray-Ban Display 안에서 실행되는 웹 애플리케이션입니다.

Meta 공식 문서 기준으로 표준 Web API를 사용하며 별도의 companion app 없이 HTML, CSS, JavaScript로 만들 수 있습니다.

현재 지원되는 대표 기능은 다음과 같습니다.

Display
- 600 × 600 additive display

Input
- 방향 이동
- 선택
- pinch-and-drag
- Meta Neural Band 입력

Text
- 음성 받아쓰기
- handwriting
- on-screen keyboard

Context
- device motion
- orientation
- phone location

Network
- fetch
- WebSocket

Offline
- Service Worker
- Cache API

즉 개발자가 기존 웹 기술을 상당 부분 그대로 재사용할 수 있습니다.

WebMCP

WebMCP는 웹 앱 안에서 AI Agent가 호출해도 되는 기능을 구조화된 tool로 공개하는 방식입니다.

Meta는 WebMCP를 현재 developer preview로 제공하고 있으며, 개발자가 어떤 기능을 Meta AI에 열어줄지 직접 정의한다고 설명합니다.

흐름을 단순화하면 다음과 같습니다.

사용자
  ↓
"장보기 목록에 우유 추가해줘"
  ↓
Meta AI
  ↓
웹 앱이 공개한 tools 확인
  ↓
add_item({ name: "우유" })
  ↓
웹 앱 실행
  ↓
결과 반환

AI가 화면을 보고 "아마 이 버튼이겠지"라고 추측하는 대신, 웹 앱이 명시적인 기능 계약(contract)을 제공합니다.

왜 이것이 흥미로울까?

지금까지 AI Agent가 웹을 조작하는 방식은 크게 두 가지가 많았습니다.

1. 화면을 보고 조작

Screenshot
→ 버튼 위치 추론
→ 클릭
→ 화면 변화 확인

사람의 사용 방식과 비슷하지만 UI가 바뀌면 쉽게 실패할 수 있습니다.

2. 서비스 API를 직접 호출

Agent
→ REST API
→ Backend

안정적이지만 서비스마다 별도의 Agent 연동을 설계해야 할 수 있습니다.

WebMCP가 지향하는 것은 그 중간에 가깝습니다.

웹 앱 자체가
"내가 제공하는 기능은 이것이다"
라고 Agent에게 알려준다.

즉 UI가 사람을 위한 인터페이스라면, WebMCP tool은 AI를 위한 인터페이스라고 볼 수 있습니다.

CodeBridge Mini Lab: Todo 웹 앱에 AI용 도구 하나 추가하기

가장 작은 예제로 생각해보겠습니다.

기존 웹 앱에 이런 함수가 있다고 가정합니다.

async function addTodo(text) {
  todos.push({ text, done: false });
  renderTodos();
}

사람은 입력창에 텍스트를 쓰고 추가 버튼을 누릅니다.

사용자
 ↓
Input
 ↓
Button
 ↓
addTodo()

WebMCP에서는 이 기존 함수를 AI가 호출할 수 있는 tool로 한 번 더 연결할 수 있습니다.

아래 예시는 2026년 9월 WebMCP draft API의 개념을 보여주기 위한 예입니다. WebMCP와 Meta 지원은 아직 preview 단계이므로 실제 배포 전에는 최신 명세와 Meta 문서를 다시 확인해야 합니다.

const controller = new AbortController();

await document.modelContext.registerTool(
  {
    name: "add_todo",
    description: "현재 Todo 목록에 새로운 할 일을 추가합니다.",
    inputSchema: {
      type: "object",
      properties: {
        text: {
          type: "string",
          description: "추가할 할 일 내용"
        }
      },
      required: ["text"]
    },
    async execute({ text }) {
      await addTodo(text);

      return {
        content: [
          {
            type: "text",
            text: `할 일 '${text}'을 추가했습니다.`
          }
        ]
      };
    }
  },
  { signal: controller.signal }
);

핵심은 새로운 비즈니스 로직을 하나 더 만드는 것이 아닙니다.

기존의:

addTodo()

를 사람이 버튼으로도 사용하고, AI가 tool로도 사용할 수 있도록 두 개의 입구를 만드는 것입니다.

             ┌─ UI Button ───────┐
사용자 ───────┤                   ↓
             │                addTodo()
Meta AI ──────┤                   ↑
             └─ WebMCP Tool ─────┘

이 구조가 잘 잡히면 UI와 Agent용 기능이 서로 다른 구현으로 갈라지는 것을 줄일 수 있습니다.

여기서 더 중요한 것은 tool을 많이 만드는 게 아닙니다

WebMCP를 처음 보면 앱 기능을 전부 tool로 노출하고 싶어질 수 있습니다.

하지만 실제로는 반대가 더 안전합니다.

예를 들어 쇼핑 앱이라면:

search_products
show_cart
add_to_cart
remove_from_cart
checkout
change_address
cancel_order

를 한 번에 모두 열기보다 먼저 부작용이 작은 기능부터 시작하는 편이 좋습니다.

1단계
search_products
show_cart

2단계
add_to_cart
remove_from_cart

3단계
checkout
cancel_order

특히 결제, 삭제, 주문처럼 실제 상태를 크게 바꾸는 작업은 AI가 잘못 호출했을 때 비용이 큽니다.

따라서 Agent용 tool을 설계할 때는 "AI가 무엇을 할 수 있는가"보다 먼저 다음 질문을 하는 편이 좋습니다.

AI가 실수했을 때 어떤 일이 생기는가?

좋은 Tool Schema는 작은 API 문서와 비슷합니다

다음 두 tool 중 AI가 더 안정적으로 사용할 수 있는 것은 어느 쪽일까요?

모호한 버전

{
  name: "add",
  description: "Add item"
}

명확한 버전

{
  name: "add_todo",
  description: "현재 사용자의 Todo 목록에 새로운 할 일을 하나 추가합니다.",
  inputSchema: {
    type: "object",
    properties: {
      text: {
        type: "string",
        description: "사용자가 추가하려는 할 일의 전체 문장"
      }
    },
    required: ["text"]
  }
}

두 번째가 훨씬 명확합니다.

AI Agent 입장에서 tool 이름과 description, parameter schema는 사실상 API 문서이면서 동시에 프롬프트의 일부입니다.

따라서 WebMCP를 잘 쓰려면 프롬프트 작성보다도:

좋은 함수 경계
명확한 이름
작은 입력 schema
예측 가능한 반환값
부작용 관리

가 더 중요해질 수 있습니다.

AI 안경에서는 이 구조가 더 자연스럽습니다

스마트폰에서는 사용자가 직접 화면을 터치할 수 있습니다.

AI 안경에서는 상황이 다릅니다.

요리 중
자전거 이동 중
장비 수리 중
현장 점검 중
운동 중

처럼 손을 자유롭게 쓰기 어려운 순간이 많습니다.

그래서 Meta도 AI glasses의 개발 방향을 hands-free, eyes-up 경험으로 설명합니다.

예를 들어 현장 점검용 웹 앱이라면 사용자가 안경을 쓴 채:

"현재 장비를 점검 완료로 표시해줘."

라고 말하고 WebMCP tool이:

mark_inspection_complete()

를 호출하는 구조를 생각할 수 있습니다.

사용자가 메뉴를 열고 작은 버튼을 찾아 누르는 것보다 안경이라는 form factor에 더 자연스럽습니다.

화면도 기존 모바일 UI처럼 만들면 안 됩니다

Meta Ray-Ban Display Web App은 600×600 additive display를 사용합니다.

Meta는 어두운 배경은 시야에서 사라지고, 밝고 대비가 높은 요소가 더 잘 보인다고 설명합니다.

따라서 데스크톱 웹사이트를 그대로 줄이는 접근보다는:

한 화면
한 목적
짧은 텍스트
큰 상태 표시
최소한의 선택지

가 훨씬 적합합니다.

예를 들어 Todo 앱에서도:

오늘 할 일 17개
필터 6개
통계 차트
사이드 메뉴

를 보여주기보다:

다음 할 일

회의 자료 보내기

[완료]

처럼 현재 순간에 필요한 정보만 보여주는 편이 자연스럽습니다.

하드웨어가 없어도 시작할 수 있습니다

이 부분도 진입 장벽을 꽤 낮춥니다.

Meta는 Ray-Ban Display용 브라우저 기반 Web App Simulator를 제공하고 있습니다.

Chrome에서:

600 × 600 display
D-pad input

등을 시뮬레이션할 수 있어서 실제 안경이 없어도 레이아웃과 기본 조작을 테스트할 수 있습니다.

즉 웹 개발자라면 가장 작은 실험은 다음 정도로 시작할 수 있습니다.

1. 기존 Todo Web App 준비
2. 600×600 UI로 단순화
3. 키보드 방향키 + Enter 대응
4. WebMCP tool 하나만 추가
5. 브라우저 Simulator에서 확인

거대한 AR 프로젝트를 만들 필요가 없습니다.

WebMCP와 Meta AI Connector는 같은 것도 아닙니다

이 부분도 헷갈리기 쉽습니다.

WebMCP

Meta AI
→ 현재 열려 있는 Web App의 tool 호출

웹 앱 내부 기능을 AI가 조작하게 만드는 쪽입니다.

Meta AI Connector

Meta AI
→ 외부 Service / API / MCP Server

웹 앱을 열지 않고도 서비스 자체를 Meta AI에 연결하는 방식입니다.

따라서 선택 기준을 간단히 정리하면 다음과 같습니다.

화면이 필요한 경험
→ Web App

웹 앱 안의 기능을 음성으로 제어
→ WebMCP

서비스 자체를 Meta AI에 직접 연결
→ Meta AI Connector

카메라·오디오·하드웨어에 더 깊게 접근
→ Device Access Toolkit

지금 당장 AI 안경 앱을 만들어야 할까?

모든 서비스가 AI 안경 앱을 만들 필요는 없습니다.

현재 WebMCP는 developer preview이고, 일반적인 배포·검색 경로도 아직 확장 중입니다.

하지만 웹 개발자 입장에서 지금 볼 가치는 충분합니다.

이유는 Meta Ray-Ban Display 자체보다 더 큰 변화가 있기 때문입니다.

웹사이트의 사용자가 사람만이라는 전제가 조금씩 깨지고 있습니다.

앞으로 웹 앱은:

사람에게는 UI
AI에게는 Tool

이라는 두 개의 인터페이스를 동시에 갖게 될 가능성이 큽니다.

이 관점에서 WebMCP는 단순히 "AI 안경 기능"이 아니라 Agent가 웹을 사용하는 방식이 어떻게 바뀔 수 있는지 보여주는 실험에 가깝습니다.

결론: 앞으로 좋은 웹 앱은 AI가 사용할 기능도 설계해야 할 수 있습니다

Meta Ray-Ban Display의 Web Apps는 웹 개발자가 익숙한 기술로 새로운 form factor에 들어갈 수 있게 합니다.

WebMCP는 거기서 한 단계 더 나아갑니다.

기존 웹
사람 → UI → 함수

WebMCP가 있는 웹
사람 → UI ───────┐
                  ↓
AI → Tool ─────→ 함수

결국 중요한 것은 AI에게 모든 권한을 주는 것이 아닙니다.

어떤 작업을 tool로 노출하고, 어떤 작업은 사용자 확인 뒤에 실행하며, 어떤 작업은 아예 열지 않을지 설계하는 것입니다.

웹 개발의 관심사가 화면 구성에서 조금씩 Agent가 사용할 수 있는 기능 경계 설계까지 넓어지고 있습니다.

지금 WebMCP를 볼 때 가장 흥미로운 지점도 바로 여기에 있습니다.

함께 읽으면 좋은 글

참고 자료