야 근데 자정에 잠이 들어도, 23시 30분에 잠이 들어도, 1시에 잠이 들어도, 3시에 잠이 들어도 오전 6시에 눈을 한번 꼭 깨는 이유가 뭐냐?

그건 네 몸이 “6시 = 기상 시각”으로 꽤 강하게 고정돼 있기 때문일 가능성이 제일 커. 핵심은 수면을 조절하는 시스템이 하나가 아니라는 거야.

대충 이렇게 두 개가 동시에 돈다.

1. 수면압: 오래 깨어 있을수록 쌓여서 “자라”고 압박함. 3시에 잤으면 당연히 오전 6시에도 수면압은 존나 높음.
2. 일주기 리듬(circadian rhythm): 수면량과 별개로, 특정 시간이 되면 “이제 아침이다. 깨라”고 각성 신호를 올림. 빛, 반복된 기상시간, 생활 패턴으로 학습된다. citeturn492550search9turn255153search3

그래서 새벽 3시에 잠들었어도 오전 6시가 되면

수면압: “시발 3시간밖에 안 잤어, 더 자.”
생체시계: “몰라. 6시임. 기상.”

이 두 놈이 싸운다. 그래서 한번 눈은 뜨는데 미친 듯이 졸리거나 다시 잠드는 현상이 가능해.

특히 평소 오랫동안 비슷한 시간에 기상했다면 생체시계는 취침시간보다 기상시간 쪽이 꽤 안정적으로 유지될 수 있어. 일정한 기상시간과 아침 빛 노출 자체가 그 리듬을 계속 강화한다. citeturn255153search0turn492550search3

그리고 좀 웃긴 우연이 하나 있는데, 서울 기준 오늘 8월 28일 일출이 오전 5시 58분이야. 진짜 거의 정확히 6시다. 커튼을 완전히 차광하지 않는다면 아침 햇빛이 네 생체시계의 “6시 알람”을 더 강하게 유지하고 있을 가능성도 있다. citeturn877990search0

아침 무렵에는 멜라토닌이 줄고 체온과 각성 시스템이 올라가며, 기상 후에는 cortisol awakening response라는 코르티솔 상승도 나타난다. 다만 코르티솔이 6시에 너를 억지로 깨운다고 단순화하면 틀리고, 생체시계와 빛, 예상된 기상 시점, 실제 각성이 서로 맞물리는 쪽이 정확하다. citeturn492550search1turn492550search6

여기서 중요한 점

6시에 저절로 눈을 뜬다 = 6시간 이하로 자도 충분하다는 뜻은 절대 아니야.

예를 들어:

• 23:30 취침 → 06:00 각성: 6.5시간
• 01:00 취침 → 06:00 각성: 5시간
• 03:00 취침 → 06:00 각성: 3시간

몸은 셋 다 6시에 깨울 수 있다. 하지만 뒤의 두 경우에는 수면부채가 그대로 남는다. 생체시계는 회계팀이 아니라 그냥 출근시간만 기억하는 경비 아저씨다. (¬_¬)

그리고 “6시에 한번 깬다”와 “6시에 완전히 잠이 끝난다”는 구분해야 해.

6시에 눈 떴다가 몇 분 안에 다시 자고, 이후 충분히 잔다면 그 자체는 꽤 자연스러울 수 있어. 밤 후반으로 갈수록 깊은 NREM 수면 비중은 줄고 가벼운 수면과 REM 비중이 커져서 빛이나 소음 같은 자극에도 깨기 쉬워진다. citeturn255153search2

반대로 3시에 잠들었는데도 6시에 깨서 다시 잠을 전혀 못 자는 일이 반복된다면, 단순히 “난 아침형 인간인가 보다” 하고 넘길 문제는 아니야. 그땐 일주기 리듬이 너무 앞당겨졌거나, 빛·소음·실내온도·스트레스성 각성 등 다른 요인도 같이 봐야 한다.

한마디로 정리하면:

네 몸에는 현재 “취침 시각”보다 훨씬 강한 “오전 6시 기상 앵커”가 박혀 있는 것 같다.
그리고 요즘 서울의 일출 시각까지 거의 정확히 6시라서 자연광이 그 앵커를 매일 보강하고 있을 가능성도 꽤 흥미로운 변수다.

그럼 6시에 깼어. 근데 뭐 일단 그냥 일어나도 되려나? 아니 좀 더 자버리면 나는 한 1시간~3시간을 더 자버리게 되거든. 그넫 그렇게 되면 이게 그날 잠을 자려고 할 때 잠이 잘 안온다거나 하더라고. 그래서 그냥 6시에 눈 떠지면 일어나는게 안전빵이려나?

자려고 누웠는데 잠이 안오는건 정말 최악의 경험이야.

응. 네가 말한 패턴이라면 “6시에 자연스럽게 깼으면 일어난다”를 기본값으로 두는 게 꽤 합리적이야. 특히 네 최우선 목표가 밤에 누웠을 때 빨리 잠드는 것이라면 더 그렇고.

이유는 단순해. 6시에 깼다가 다시 1~3시간을 자버리면, 그 수면은 부족한 잠을 보충하는 동시에 그날 밤을 위해 쌓여야 할 **수면압(sleep pressure)**도 상당히 깎아먹어. 그러면 밤에:

“분명 피곤한데 왜 잠은 안 오지?”

라는 개같은 상태가 생길 수 있다. 반대로 일정한 기상시간을 유지하고 늦잠을 피하는 건 불면 치료인 CBT-I에서도 핵심 원칙이야. NHS도 나쁜 밤을 보낸 다음에도 늦잠 자지 말고 평소 기상시간을 유지하라고 권하고, Mayo Clinic도 같은 기상시간을 유지하는 걸 권장해. citeturn207322search2turn207322search0

그래서 나는 이렇게 운영하는 걸 추천해

06:00을 ‘고정 앵커’로 잡아.

평범하게 전날 밤 잤고 6시에 눈이 떠졌다 → 그냥 일어나.

6시에 일어났는데 살짝 피곤하다 → 역시 일어나. 그 피곤함 일부는 오늘 밤 잠을 잘 오게 만드는 재료야.

그리고 낮에 정말 못 버티겠으면 아침에 2시간 더 자는 대신 낮잠을 20~30분 정도만, 가능하면 오후 3시 이전에 써. 긴 낮잠이나 늦은 낮잠은 밤잠을 다시 망가뜨릴 수 있어. citeturn207322search3

특히 중요한 건:

“어제 못 잤으니까 오늘 21시에 무조건 침대 들어가야지”도 하지 마.

평소보다 일찍 졸리면 일찍 자는 건 괜찮은데, 안 졸린데 수면시간을 확보하겠다고 침대에 들어가는 것은 오히려 네가 싫어하는 그 상황을 만들 수 있어.

침대 → 잠 안 옴 → 시간 확인 → 초조함 → 잠 더 안 옴

이 연결이 학습되기 시작하면 아주 성가셔진다. 그래서 CBT-I의 stimulus control에서는 졸릴 때 침대로 가고, 누워서 대략 20분 이상 잠이 안 오면 침대에서 나와 조용한 일을 하다가 졸릴 때 다시 들어가는 방식을 사용해. citeturn207322search1turn207322search36

단, 예외는 있어

여기서 “무슨 일이 있어도 6시 기상”을 종교로 만들지는 마.

예를 들어 새벽 3시에 잠들어서 3시간밖에 못 잔 날에도 계속 이런 식으로 몇 주간 버티는 건 좋은 전략이 아니야. 성인은 일반적으로 최소 7시간 정도의 수면이 권장되고, 계속 수면을 줄이면 낮 동안의 기능과 안전 문제가 생길 수 있어. citeturn207322search6

그래서 실전적으로는 이렇게 생각하면 돼.

상황	06:00에 깼을 때
약 7시간 이상 잠	일어난다
6시간 안팎	웬만하면 일어난다
4~5시간밖에 못 잠	가능하면 기상시간 유지하되 그날 활동 강도를 낮추고 짧은 낮잠으로 보완
2~3시간 수준	“수면 리듬 교정”보다 수면 부족 자체가 더 큰 문제. 운전·고강도 활동 특히 조심

마지막 두 줄은 정확한 의학적 컷오프라기보다 네가 극단적으로 수면을 제한하지 않도록 만드는 실전 안전장치라고 보면 돼.

그리고 네가 한 말 중 중요한 단서가 하나 있어.

다시 자면 1~3시간 더 자고 → 그날 밤 잠이 잘 안 온다.

이게 반복적으로 관찰됐다면, 네 몸에서는 이미 꽤 명확한 피드백이 나온 거야. 아침 늦잠의 이득보다 밤 수면 개시를 망치는 비용이 큰 패턴인 거지.

그래서 당분간은 아예 이렇게 해보는 게 깔끔해.

06:00 기상 고정 → 낮잠 없거나 최대 20~30분 → 저녁에 졸리기 전에는 침대 안 감 → 잠 안 오면 침대에서 버티지 않음.

( •̀ᴗ•́ )و
특히 **“밤에 어떻게든 자야 한다”가 아니라 “아침에 언제 일어날지만 고정한다”**는 게 포인트야. 잠드는 건 직접 명령하기 어렵지만, 기상시간은 네가 통제할 수 있고, 그게 다음 날의 수면압을 만들어준다.

그리고 네가 잠이 안 오는 경험 자체를 강하게 싫어한다면, 이 방식이 더 중요한 이유가 있어. 목표를 “매일 몇 시까지 반드시 잠들기”로 잡으면 침대에서 실패 여부를 계속 평가하게 된다. 반대로 6시 기상만 고정하고 취침은 졸림에 맡기는 편이 수면에 대한 압박을 훨씬 덜 만든다. 침대에서 잠과 씨름하는 시간을 줄이는 게 핵심이야. citeturn207322search1

야 webmcp가 뭐임? 일단 기초적인 설명 좀

한 줄로 말하면, WebMCP는 웹사이트가 AI 에이전트한테 “우리 사이트에서 할 수 있는 일은 이거고, 이렇게 호출하면 돼”라고 직접 알려주는 브라우저 표준이야. 지금 AI가 웹사이트를 조작할 때 벌이는 눈치게임을 상당 부분 없애려는 물건이지. citeturn328052view0turn266756search7

지금 브라우저 에이전트는 어떻게 일하냐

예를 들어 네가 AI한테 CGV 사이트에서

“9월 1일 19시 영등포 산산조각 일반석 있는지 확인해”

라고 시켰다고 해보자.

현재 일반적인 브라우저 에이전트는 대충 이러고 있음.

화면/DOM 읽음
↓
'영화' 버튼인가?
↓
클릭
↓
페이지 바뀜
↓
상영관 드롭다운 찾음
↓
영등포 선택
↓
날짜 클릭
↓
19시 찾음
↓
좌석 선택 화면 진입
↓
화면 분석
↓
일반석이 남았는지 추론

(눈_눈) 인간용 GUI를 AI가 인간 흉내 내면서 쓰는 거야.

Google도 이 방식을 actuation, 즉 AI가 마우스 클릭이나 텍스트 입력을 사람처럼 흉내 내는 방식이라고 설명해. 각 단계마다 UI를 해석해야 하니까 느리고 잘 깨질 수 있어. citeturn328052view1

---

WebMCP가 있으면

CGV가 사이트에 이런 기능을 등록할 수 있어.

searchMovies()
getShowtimes()
checkSeats()
selectSeat()
checkout()

그리고 각 기능에

checkSeats({
  theater: "영등포",
  movie: "산산조각",
  date: "2026-09-01",
  time: "19:00"
})

같은 구조화된 입력 규격을 붙이는 거야.

그러면 AI는 버튼 찾아 삼만리 안 하고 바로

AI
↓
"이 페이지에 무슨 도구가 있지?"
↓
checkSeats 발견
↓
checkSeats(...) 호출
↓
{ 일반석: 1, 장애인석: 4 }

이렇게 움직일 수 있음.

WebMCP는 이런 tool discovery, JSON Schema 기반 입력 정의, 현재 페이지 상태 공유를 표준화하려고 해. citeturn328052view1

---

그러면 그냥 MCP랑 뭐가 다르냐

여기가 핵심임.

기존 MCP

대충 이렇게 생김.

ChatGPT / Claude / Codex
        ↓
      MCP
        ↓
외부 서버 / API / DB

예를 들어 GitHub MCP라면

create_issue
get_pull_request
search_code

같은 기능을 GitHub 서비스 쪽과 직접 연결해서 사용하는 형태지.

반면 WebMCP는

AI
↓
브라우저
↓
현재 열려 있는 웹페이지
↓
그 페이지가 제공하는 tools

이 구조야.

즉,

MCP = AI ↔ 서비스

라면

WebMCP = 브라우저의 AI ↔ 현재 웹페이지

라고 이해하면 거의 맞아. WebMCP 공식 설명에서도 웹페이지 자체를 일종의 “페이지 안의 MCP 서버”처럼 생각할 수 있다고 설명해. citeturn266756search2

---

이 차이가 은근히 엄청 중요함

예를 들어 쇼핑몰에 네가 이미 로그인해 있다고 해보자.

기존 MCP 방식이면 별도의 MCP 서버가 쇼핑몰 계정에 접근해야 하니까,

OAuth
API 인증
별도 권한
서버 구현

같은 게 필요할 수 있음.

WebMCP는 현재 브라우저 세션에서 페이지 기능을 실행하니까,

이미 로그인된 웹사이트
+
현재 보고 있는 장바구니
+
현재 선택한 상품
+
현재 페이지 상태

를 그대로 활용할 수 있어.

그래서 WebMCP가 노리는 건 특히 **“사람이 보고 있는 웹페이지에서 사람과 AI가 같이 일하는 것”**이야. Google도 현재 WebMCP가 headless 자동화보다는 human-in-the-loop 로컬 브라우저 워크플로우를 주 대상으로 한다고 명시하고 있어. citeturn328052view2

---

개발자는 어떻게 붙이냐

현재 제안에는 크게 두 가지 방식이 있어. citeturn328052view2

1. Imperative API

JavaScript로 직접 tool을 정의함.

개념적으로는

registerTool({
  name: "search_events",
  description: "조건에 맞는 행사를 검색합니다",
  inputSchema: {...},
  execute: (...)
})

이런 느낌.

복잡한 서비스 기능에 적합해.

2. Declarative API

기존 HTML <form>에 메타데이터를 붙여서 AI가 이해할 수 있게 만드는 방식.

즉 그냥

이 입력칸은 날짜
이 입력칸은 지역
이 버튼은 검색 실행

같은 의미를 명시하는 쪽이지.

간단한 검색·신청·예약 폼은 이 방식으로 비교적 싸게 WebMCP 대응을 할 수 있음.

---

그래서 왜 갑자기 WebMCP 얘기가 나오는가

AI 브라우저 에이전트의 가장 큰 문제가 지금 이거거든.

LLM은 똑똑해짐

그런데

웹사이트 조작 방식은
"버튼 어디 있지?"
"이게 제출 버튼인가?"
"팝업 떴네?"
"DOM 바뀌었네?"

( ･᷄ὢ･᷅ ) 두뇌는 2026년인데 손발은 아직 매크로 프로그램에 가까운 상황.

WebMCP는 웹 자체를 agent-readable하게 만들자는 접근이야.

웹이 지금까지

HTML → 인간에게 정보 구조 제공
CSS → 인간에게 시각 구조 제공
ARIA → 접근성 도구에게 의미 제공

했다면,

앞으로 하나가 추가되는 셈이지.

WebMCP → AI agent에게 기능 구조 제공

나는 이 관점이 WebMCP를 이해하기 제일 좋다고 봐.

---

그리고 아직 “완성된 인터넷 표준”은 아님

이건 중요해.

2026년 8월 28일 현재 WebMCP는 W3C Web Machine Learning Community Group의 draft 제안 단계고, Chrome도 실험적으로 지원 중이야. 공식 W3C Community Group draft가 8월 26일자로 나와 있고, Chrome 쪽에서는 Chrome 149 Origin Trial과 개발용 flag를 제공하고 있어. 즉 방향성이 꽤 구체화됐지만 아직 API가 바뀔 가능성도 있는 상태야. citeturn266756search7turn328052view2

---

제일 단순한 비유

식당에 AI를 보냈다고 생각해봐.

지금 방식

AI가 식당에 들어가서

“저 종이가 메뉴판인가?”

“저 사람이 직원인가?”

“저 버튼 누르면 주문인가?”

“이게 매운맛 옵션인가?”

를 하나하나 추론함.

WebMCP

식당이 AI한테 입장하자마자 이걸 줌.

가능한 행동

searchMenu(query)
addToCart(itemId)
changeOption(itemId, spiceLevel)
placeOrder()

그러면 AI는 그냥 호출하면 됨.

UI는 인간용으로 남겨두고, 그 뒤에 AI용 조작 인터페이스를 하나 더 깔아주는 것.

이게 WebMCP의 본질이야.

---

하나 더 생각해볼 지점

이게 제대로 보급되면 꽤 큰 변화가 생겨.

지금 웹서비스를 만들 때는 보통

“사용자가 이 UI를 어떻게 사용할까?”

만 생각하지.

WebMCP 시대에는

“사용자는 이 UI를 어떻게 사용할까?”

“AI agent는 이 서비스를 어떻게 사용할까?”

를 동시에 설계하게 될 가능성이 높아.

즉 SEO → 모바일 대응 → 접근성 대응 다음으로, 장기적으로는 Agent Interface라는 설계 계층이 하나 추가될 수도 있어.

그리고 네가 만드는 웹서비스들 기준으로 보면 이게 꽤 재밌는 문제야. 예를 들어 캘린더/리마인더 서비스라면 createReminder, findFreeTime, rescheduleTask 같은 WebMCP tool을 먼저 잘 설계해두면, 나중에 ChatGPT나 브라우저 에이전트가 서비스 UI를 억지로 클릭하는 게 아니라 서비스의 기능 자체를 바로 사용할 수 있는 구조가 되거든. 인간들이 또 새로운 인터페이스 계층 하나를 만들어냈다. 이번 건 그래도 제법 쓸모 있어 보임. citeturn328052view1

그럼 이건 어쨌든 사이트 소유자가 설정을 해야 하는 것이네? 외부인이 할 수 ㅣㅇㅆ는 건 아니고. 긍께 우리가 cgv에 맞춤 webmcp를 해둘 수 있는 건 아닌[ㅔ? 아닌가? 가능성만 확인. 규제같은 건 신경쓰지 말고.

응. 네 이해가 절반은 맞고, 절반은 아니다.

공식적인 의미의 WebMCP

기본 설계는 확실히 사이트 소유자가 자기 페이지에 WebMCP tool을 등록하는 것이야.

CGV 개발자
   ↓
CGV 페이지 코드
   ↓
document.modelContext.registerTool(...)
   ↓
AI가 발견

현재 스펙도 document.modelContext.registerTool()을 통해 그 Document에 tool을 등록하는 구조로 정의돼 있어. citeturn724932view1turn678905search1

그런데 중요한 건,

“그 코드를 반드시 CGV 서버에서 내려줘야 한다”는 뜻은 아님.

---

외부인이 CGV 전용 WebMCP를 만드는 것 자체는 기술적으로 가능함

예를 들어 우리가 Chrome Extension을 하나 만든다고 해보자.

CGV 사이트 접속

       ↓

우리 Chrome Extension 감지

       ↓

CGV 페이지 안에 JS 주입

       ↓

document.modelContext.registerTool({
   name: "check_cgv_seats",
   ...
})

       ↓

AI가 CGV 페이지의 WebMCP tool로 인식

Chrome Extension은 스크립트를 웹페이지에 삽입할 수 있고, 심지어 MAIN world에서 실행하면 CGV 자체 JavaScript와 같은 페이지 실행 환경을 공유할 수 있어. citeturn847370search0turn847370search2

그러니까 개념적으로는 우리가 CGV에다가 “비공식 WebMCP 어댑터”를 덧씌우는 것이 가능해.

( •̀ᴗ•́ )و 생각보다 네 추측이 꽤 좋은 데를 찔렀음.

---

예를 들어 우리가 만들 수 있는 것

CGV는 WebMCP를 전혀 지원하지 않는다고 가정하자.

우리 Extension이 CGV에서 자동으로 이런 걸 등록하는 거야.

check_seats({
  theater: "영등포",
  movie: "산산조각",
  date: "2026-09-01",
  time: "19:00"
})

AI 입장에서는 그냥 이것만 보임.

CGV tools

- search_movie
- get_showtimes
- check_seats
- open_seat_selection

그런데 실제 check_seats() 내부는 우리가 구현해야 해.

여기서 세 가지 방식이 있음.

1. CGV 내부 API를 이용

가장 좋은 경우.

check_seats()
    ↓
CGV가 자기 프론트에서 쓰는 API 호출
    ↓
좌석 데이터 받음
    ↓
AI에게 반환

예:

{
  "availableNormalSeats": 1,
  "wheelchairSeats": 4
}

이게 되면 매우 강함.

---

2. CGV 페이지 내부 상태를 읽음

React/Vue/JS 등에 이미 내려온 데이터를 잡아서

CGV 페이지
   ↓
상영정보 / 좌석정보
   ↓
우리 adapter가 추출
   ↓
WebMCP tool 결과

로 만들 수도 있음.

---

3. 마지막 수단으로 DOM 조작

내부 API나 상태를 못 찾으면 결국

check_seats()
 ↓
날짜 클릭
 ↓
영화 클릭
 ↓
시간 클릭
 ↓
좌석 페이지 진입
 ↓
DOM 분석
 ↓
결과 반환

이렇게 기존 브라우저 자동화를 tool 안에 감춰버릴 수도 있어.

이것도 WebMCP tool 자체로는 정상적으로 보일 수 있음.

---

그래서 구조적으로 보면 이렇다

CGV가 직접 WebMCP 지원

AI
 │
 │ check_seats()
 ▼
CGV WebMCP
 │
 ▼
CGV 내부 로직/API

최고.

---

우리가 CGV용 WebMCP Adapter 제작

AI
 │
 │ check_seats()
 ▼
우리 WebMCP Adapter
 │
 ├─ CGV 내부 API
 │
 ├─ 페이지 JS 상태
 │
 └─ DOM 자동화
       ↓
      CGV

충분히 가능.

차이는 CGV가 제공하는 게 아니라 사용자 브라우저에 우리가 설치하는 것이라는 거야.

---

재밌는 건 WebMCP 스펙 자체도 이 세계를 어느 정도 전제하고 있음

WebMCP가 말하는 browser agent는 브라우저 내장 AI뿐 아니라 extension이나 plug-in으로 구현된 agent도 포함한다고 명시하고 있어. citeturn724932view4

그리고 현재 API는 특정 사이트 사업자가 발급한 “공인 WebMCP 인증서” 같은 걸 요구하는 형태가 아니라, Document의 modelContext에 tool을 등록하는 JavaScript API야. citeturn724932view1

그러니까 기술 구조상 브라우저를 통제하는 사용자/extension이 중간 레이어를 만드는 것 자체는 이상한 해킹 아이디어가 아니라 꽤 자연스럽다.

---

단, 엄청 중요한 차이

외부 WebMCP adapter가 있다고 해서

CGV의 비공개 기능을 갑자기 쓸 수 있게 되는 것

은 아냐.

우리가 얻는 건 이거임.

기존

AI
 ↓
"버튼 어디있지?"
 ↓
CGV


Adapter 이후

AI
 ↓
check_seats()
 ↓
[우리가 만든 복잡한 로직]
 ↓
CGV

즉 AI ↔ CGV 사이의 인터페이스는 깔끔해지지만,
CGV ↔ adapter 사이의 더러운 일은 우리가 떠맡는 거야.

인류는 복잡성을 제거하지 않는다. 다른 파일에 옮겨놓고 추상화라고 부른다. (－‸ლ)

---

그런데 여기서 더 중요한 결론이 하나 있음

꼭 WebMCP일 필요조차 없어.

예를 들어 우리가 정말 원하는 게

“ChatGPT/Claude가 CGV를 안정적으로 다루게 한다”

라면,

             ┌ CGV Adapter
             │
AI ── MCP ───┤─ check_seats
             ├─ find_showtime
             └─ open_booking

처럼 CGV 전용 일반 MCP 서버 + Chrome Extension을 만드는 것도 가능해.

반면 WebMCP로 만들면:

AI
 ↓
현재 CGV 탭
 ↓
CGV에 주입한 WebMCP tools

가 됨.

둘의 목적이 약간 다르지.

---

그래서 네 질문에 정확히 답하면

질문	답
WebMCP는 원래 사이트 소유자가 넣는 건가?	응. 기본 의도는 그거야.
외부인이 WebMCP를 추가할 수 없나?	아니. 브라우저 Extension/스크립트 주입으로 가능성이 있음.
우리가 CGV 전용 WebMCP를 만들 수 있나?	기술적으로 가능함.
CGV 서버 자체가 WebMCP 지원하게 만들 수 있나?	당연히 못 함.
내 브라우저에서 CGV가 WebMCP를 지원하는 것처럼 만들 수 있나?	가능함. 이게 핵심.
그러면 내부 기능도 자동으로 API처럼 쓸 수 있나?	아님. 그 연결 로직은 우리가 만들어야 함.
실용적인가?	CGV처럼 반복적으로 조작할 사이트라면 꽤 흥미로운 접근임.

그리고 이걸 일반화하면 꽤 이상하고 재밌는 게 나와.

“Unofficial WebMCP Adapter”

cgv.co.kr
→ CGV Adapter

instagram.com
→ Instagram Adapter

school.skku.edu
→ SKKU Adapter

yes24.com
→ YES24 Adapter

interpark.com
→ Interpark Adapter

사이트가 Agent-ready가 되기를 기다리는 게 아니라, 사용자가 자주 쓰는 레거시 웹사이트를 자기 브라우저에서 강제로 Agent-ready하게 만드는 거지.

WebMCP가 보급되는 초기에 이런 **“웹사이트용 에이전트 호환 레이어”**가 하나의 제품 카테고리가 될 가능성도 충분히 있어 보여. 특히 사이트별 adapter를 커뮤니티가 공유하는 형태면, 옛날 Tampermonkey userscript 생태계와 MCP 생태계가 기괴하게 합체한 물건이 됨.

그리고 CGV 좌석 확인 같은 건 이 아이디어의 꽤 좋은 테스트 케이스야. 입력과 출력이 명확하고 반복 작업이며 로그인된 브라우저 세션도 활용할 가치가 있으니까. memcite

오호라,,,야 그럼 이것과 관련ㅅ한 외부 라이브러리나 깃허브 오픈소스가 있는지 한번 찾아줘봐.

찾아보니까 있다. 심지어 우리가 방금 상상한 구조랑 거의 정확히 겹치는 OSS가 여러 개 이미 나와 있음. 다만 2026년 8월 기준 생태계가 아직 태아 수준이라 스타 수는 처참하다. 방향성이 없는 게 아니라 너무 최근이라 사람이 없는 쪽에 가까움. (ಠ_ಠ)

핵심적으로 볼 만한 것 4개

1. WebMCP-org/webmcp-userscripts

우리 CGV 아이디어와 가장 정확히 일치함.

이 프로젝트 설명 자체가:

Tampermonkey userscript를 만들어 기존 웹사이트에 WebMCP capability를 주입

하는 거야. 즉 사이트 운영자가 WebMCP를 안 넣어도 외부에서 userscript를 넣어 structured tools를 노출시키는 구조임. citeturn216045view2

실제 구조도:

기존 웹사이트
    ↓
Tampermonkey / userscript 주입
    ↓
WebMCP tools 등록
    ↓
AI가 structured tool로 호출

게다가 테스트 후에는 특정 도메인에 스크립트를 자동 등록해서, 페이지를 열 때마다 document_start, MAIN world에서 자동 실행하게 할 수 있음. 즉 우리가 아까 말했던 **“CGV 열면 자동으로 CGV용 WebMCP adapter가 붙는다”**가 그대로 가능하게 설계돼 있어. citeturn216045view2

현재 README에는 Gmail, Google Search, ChatGPT 같은 사이트별 userscript 개발 패턴도 언급돼 있고, Playwright로 사이트를 조사한 다음 selector/API 흐름을 찾아 tool을 만드는 개발 가이드까지 있음. citeturn878393search0

MIT 라이선스이고 현재 GitHub 스타는 4개. 진짜 신생아다. citeturn216045view2

urlWebMCP Userscripts GitHubhttps://github.com/WebMCP-org/webmcp-userscripts

CGV에 적용한다면 난 이걸 1순위 기반으로 봄.

---

2. keak-ai/webmcp-core

이건 더 흉악하게 편리해.

URL 하나 주면 사이트를 스캔해서 WebMCP tool 초안을 자동 생성하는 라이브러리야. citeturn878393view0

예:

npx @keak/webmcp-core generate https://www.cgv.co.kr

그러면 Playwright로 사이트를 돌아다니면서:

DOM
forms
buttons
links
network calls
first-party API
route changes

등을 수집하고, 그걸 기반으로

search_movies
get_showtimes
select_theater
checkout

같은 WebMCP tool 후보를 생성한다는 구조임. citeturn878393view0

더 중요한 건 출력 포맷에 userscript가 있음.

--format userscript

즉:

CGV 조사
 ↓
tool 후보 자동 생성
 ↓
Tampermonkey userscript 생성
 ↓
CGV에 삽입

이라는 우리가 원하는 파이프라인을 대놓고 지원한다. citeturn878393view0

그리고 API를 단순히 DOM에서 찾는 게 아니라 network call도 기록해서 first-party API를 찾아낸다는 점이 특히 중요해. 좌석 조회 같은 건 DOM 클릭보다 CGV 프론트가 사용하는 내부 요청을 감싸는 게 훨씬 안정적이니까. citeturn878393view0

다만 “자동 생성됐으니 프로덕션급으로 완성”이라고 생각하면 곤란함. 사이트 상태, 인증, iframe, 난해한 JavaScript 상태 등에 따라 사람이 수정해야 할 가능성이 높아. README에서도 tool을 propose하고 confidence를 매기는 구조라 완전 자동 변환기라기보단 초안 생성기로 보는 게 맞음. citeturn878393view0

현재 공개 조직 페이지 기준 약 26 stars, MIT. citeturn878393search3

urlwebmcp-core GitHubhttps://github.com/keak-ai/webmcp-core

이건 CGV 초기 역공학 시간을 엄청 줄여줄 가능성이 있음.

---

3. nathan-gage/webmcp-bridge

이건 내가 특히 웃겼던 놈.

README에 아예:

WebMCP를 네이티브로 지원하지 않는 사이트에도 plugin marketplace의 community-authored bridge script로 tool을 추가할 수 있다.

라고 적혀 있음. citeturn520342view0

즉 우리가 조금 전에 붙인 이름인

Unofficial WebMCP Adapter

개념을 사실상 그대로 만들고 있음.

구조는:

Claude / Cursor / MCP Client
          ↓
    webmcp-bridge CLI
          ↓
   Chrome Extension
          ↓
 WebMCP tools
          ↓
       Website

이고, 사이트가 WebMCP를 제공하지 않을 경우:

GitHub plugin
   ↓
bridge script
   ↓
사이트 페이지에 WebMCP tools 등록

이 가능함. citeturn520342view0

심지어 plugin 설치 방식도:

user/repository

같은 GitHub package specifier를 넣으면 extension이 받아서 설치하는 형태를 지향함. citeturn520342view0

즉 장기적으로:

webmcp-cgv
webmcp-yes24
webmcp-interpark
webmcp-skku

같은 커뮤니티 repository 생태계까지 염두에 둔 설계야.

현재 49 commits지만 스타 0개. 2026년 8월 기준 거의 막 태어난 프로젝트라고 보면 됨. MIT. citeturn520342view0

urlwebmcp-bridge GitHubhttps://github.com/nathan-gage/webmcp-bridge

방향성 면에서는 우리가 이야기했던 그림과 가장 똑같음.

---

4. MCP-B / WebMCP-org/npm-packages

이건 위의 userscript 생태계가 사용하는 기반 툴킷에 가까워.

꽤 여러 조각을 제공함.

@mcp-b/webmcp-polyfill
@mcp-b/global
@mcp-b/webmcp-extension
@mcp-b/webmcp-local-relay
@mcp-b/smart-dom-reader
@mcp-b/transports

특히 우리한테 중요한 건:

@mcp-b/webmcp-extension

→ Chrome Extension에서 WebMCP 추가

@mcp-b/smart-dom-reader

→ AI용 DOM 추출

@mcp-b/webmcp-local-relay

→ 웹사이트의 WebMCP tool을 Claude Desktop, Cursor 같은 외부 MCP client로 전달

이 셋임. citeturn216045view3turn216045view4

공식 README도 사용 목적을 아예:

Add WebMCP from an extension → @mcp-b/webmcp-extension

이라고 분류해둠. citeturn216045view4

urlMCP-B packages GitHubhttps://github.com/WebMCP-org/npm-packages

---

보조적으로 쓸 만한 것

Tampermonkey/tampermonkey-mcp도 있음.

이건 WebMCP runtime 자체라기보다는 AI가 Tampermonkey userscript를 생성·읽기·수정·삭제하게 해주는 MCP야. citeturn520342view2

그러니까 Codex한테:

CGV 분석해
↓
CGV userscript 만들어
↓
Tampermonkey에 설치
↓
테스트
↓
깨졌으면 수정

같은 개발 루프를 돌릴 때 꽤 유용할 수 있음.

urlTampermonkey MCP GitHubhttps://github.com/Tampermonkey/tampermonkey-mcp

그리고 Browser Use, Stagehand, open-browser-use 같은 일반 browser agent framework도 존재함. 다만 얘네는 근본적으로:

AI
↓
브라우저 조작
↓
웹사이트

쪽이지,

웹사이트
↓
구조화된 site-specific tools
↓
AI

라는 WebMCP adapter 철학하고는 다름. Browser Use는 브라우저 자동화를 MCP로 노출할 수 있고, Stagehand는 반복 가능한 동작을 code/caching으로 안정화하는 데 강점이 있음. citeturn421780search0turn421780search5

따라서 CGV adapter 안에서 최후의 fallback으로 쓰기엔 괜찮음.

---

CGV라면 내가 지금 생각하는 조합

꽤 명확해졌어.

              CGV
               │
       ┌───────┴────────┐
       │ 페이지/API 조사 │
       └───────┬────────┘
               │
     keak-ai/webmcp-core
               │
       WebMCP tool 초안
               │
               ▼
WebMCP-org/webmcp-userscripts
               │
        CGV userscript
               │
               ▼
     Chrome / Tampermonkey
               │
     cgv.co.kr에 자동 주입
               │
               ▼
┌─────────────────────────────┐
│ search_movies               │
│ get_showtimes               │
│ get_available_seats         │
│ open_booking                │
│ select_seat                 │
└─────────────────────────────┘
               │
               ▼
     webmcp-bridge / MCP-B
               │
               ▼
       ChatGPT / Codex / Claude

그리고 get_available_seats() 내부에서 우선순위를:

1. CGV front-end가 쓰는 first-party API
         ↓ 없거나 어려우면
2. 페이지 JS 상태
         ↓
3. DOM
         ↓
4. browser automation

으로 잡으면 됨.

이렇게 하면 가장 안정적인 API를 쓸 수 있을 땐 API를 쓰고, 안 될 때만 브라우저 조작으로 내려감.

---

중요한 발견

사실 내가 아까 말했던

“웹사이트가 Agent-ready가 되길 기다리지 말고
사용자가 레거시 사이트를 Agent-ready로 만들어버린다”

는 아이디어가 아직 널리 보급되진 않았지만 이미 OSS에서 하나의 방향으로 형성되고 있음.

특히 이 세 개가 각각 퍼즐 조각처럼 맞아.

프로젝트	역할
webmcp-core	사이트 → tool 초안 자동 생성
webmcp-userscripts	외부 사이트에 tool 주입
webmcp-bridge / MCP-B	그 tool을 실제 AI에게 연결

그래서 CGV 전용으로 뭔가 해본다면 완전히 밑바닥부터 만들 이유가 거의 없어졌다.

다만 현재 프로젝트 규모를 보면 아직 “이걸 설치하면 CGV 5분 컷”은 절대 아니고, 좋은 building block들이 이제 막 생긴 상태라고 보는 게 정확함. 특히 webmcp-core의 network scanning + webmcp-userscripts 조합은 실제로 한번 실험해볼 가치가 꽤 높아 보여.

그리고 여기서 한 단계 더 가면 단순 CGV 프로젝트가 아니라 **“아무 사이트나 URL 주면 조사 → adapter 생성 → userscript 설치 → agent tool화”**라는 범용 파이프라인도 보인다. 이건 내가 예상했던 것보다 이미 필요한 부품이 많이 나와 있다. ( •̀ᴗ•́ )و

WebMCP 쪽 OSS는 지금 변화가 빨라서, 주요 프로젝트나 새 adapter가 뜨는지 정기적으로 추적하는 것도 꽤 유용해.

genui{"suggest_automation":{"label":"WebMCP OSS 업데이트 추적"}}

아니 뭐 cgv는 그냥 예시로 들었던 것이고.
그럼 webmcp가 적용된 사이트와 그러지 않은 사이트를 비교해줘봐.
대충 좋다는 건 이해가 되는데 어떤 부분이 어떻게 좋은지 직관적으로 와닿지가 않네.

table형태로 비교해주셈. 비개발자 친화적으로. 풀어서 설명해줘.

ㅇㅇ. 네가 지금 막연하게 느끼는 이유는 “WebMCP가 있으면 더 좋다”가 너무 추상적이기 때문이야. 실제 차이는 **AI가 웹사이트를 ‘보면서 조작하느냐’ vs ‘사이트가 제공한 기능을 직접 이해하고 호출하느냐’**에 있어.

가장 직관적으로 비교해보자. 같은 사이트에서 AI에게 **“다음 주 금요일 7시 이후 영화 찾아서 예매 직전까지 가줘”**라고 시켰다고 가정할게.

WebMCP 없는 사이트 vs 있는 사이트

상황	WebMCP 없는 일반 사이트	WebMCP 적용 사이트
AI가 사이트를 이해하는 방식	화면, HTML, 버튼 이름을 보고 추측함	사이트가 "영화검색", "상영시간조회" 같은 기능의 의미를 직접 알려줌
AI에게 사이트가 어떻게 보이나	인간에게 보이는 웹페이지	인간용 웹페이지 + AI용 기능 목록
“영화 찾아줘” 요청	검색창이 어디 있는지 찾고 클릭 → 입력 → 검색 버튼 찾음	searchMovies() 같은 기능을 바로 호출
날짜 선택	달력 열기 → 다음 달 이동 → 날짜 버튼 찾기 → 클릭	date: "2026-09-04"라고 전달
극장 선택	드롭다운 찾기 → 펼치기 → 지점 이름 찾기 → 클릭	theater: "용산아이파크몰" 전달
상영시간 확인	화면에 나온 여러 텍스트를 읽고 19시 이후인지 판단	getShowtimes(after:"19:00") 호출
좌석 확인	좌석표를 열고 색/DOM 구조를 분석해서 남은 좌석을 추론	getAvailableSeats() → "일반석 12석"
실행 단계 수	보통 많음. 클릭 → 기다림 → 읽음 → 클릭 반복	필요한 기능 몇 번 호출하면 끝
속도	상대적으로 느림	대체로 훨씬 빠름
UI가 개편되면	버튼 위치나 HTML이 바뀌어서 자동화가 깨질 수 있음	WebMCP 기능 규격이 유지되면 UI가 바뀌어도 영향 적음
버튼 이름이 애매하면	"선택"이 뭘 선택하는 건지 AI가 해석해야 함	기능 설명에 정확한 의미가 정의됨
숨겨진 상태 이해	페이지에 보이는 정보 위주로 추론	사이트가 제공하면 장바구니, 현재 선택, 검색 조건 등을 구조적으로 전달 가능
잘못 클릭할 가능성	있음. 비슷한 버튼, 광고, 팝업 등이 변수	훨씬 감소
팝업이 갑자기 뜨면	AI가 다시 화면을 읽고 대응해야 함	핵심 기능 호출 자체에는 팝업이 관계없을 수 있음
결과를 읽는 방식	"좌석이 12개 있는 것 같은데?"	{availableSeats:12}
에러가 나면	화면 보고 "왜 안 되지?"부터 추론	SOLD_OUT, LOGIN_REQUIRED 같은 명확한 오류를 받을 수 있음
로그인 상태	브라우저 로그인 세션을 사용할 수 있음	똑같이 브라우저 로그인 세션 활용 가능
결제 같은 민감 작업	버튼 하나씩 조작하면서 진행	사이트가 허용한 tool과 confirmation 구조로 진행 가능
AI 입장에서 난이도	인간처럼 사이트 쓰기	API 쓰듯 사이트 쓰기
사이트 개발자 입장에서	인간용 UI만 만들면 됨	인간 UI + AI용 기능 정의 필요
사용자 입장에서	AI가 헤매는 걸 종종 봄	“시켰더니 그냥 됨”에 가까워짐

---

제일 큰 차이는 이거야

WebMCP 없는 사이트에서 AI에게

“내일 오후 서울에서 하는 공연 찾아줘.”

라고 하면 AI는 사실 속으로 이런 일을 해야 함.

페이지 열기
↓
검색 버튼 어디 있지?
↓
클릭
↓
지역 필터 어디 있지?
↓
서울 선택
↓
날짜 선택
↓
내일 버튼인가 달력인가?
↓
검색
↓
결과 화면 읽기
↓
공연만 골라내기
↓
오후 공연인지 다시 판단

즉 ‘사이트 사용법’까지 AI가 알아내야 해.

반대로 WebMCP가 제대로 붙어 있으면 사이트가 AI에게 처음부터 말해줘.

내가 제공하는 기능:

searchEvents({
    date,
    region,
    category,
    startTime
})

getEventDetails({
    eventId
})

그러면 AI가 그냥:

searchEvents({
    date: "2026-08-29",
    region: "서울",
    category: "공연",
    startTime: "12:00"
})

를 호출하면 됨.

인간에 비유하면

WebMCP 없음

처음 가본 관공서에 외국인을 혼자 던져놓고
“전입신고하고 와” 하는 것.

표지판 읽고, 번호표 뽑고, 어느 창구인지 알아내고, 양식 찾아서 작성해야 함.

WebMCP 있음

입구에서 직원에게
“전입신고 하겠습니다”라고 말했더니
직원이 필요한 정보만 물어보고 처리하는 것.

이 차이라고 보면 됨.

(￣ー￣) 웹사이트를 잘 사용하는 지능과 실제 사용자가 원하는 일을 처리하는 지능은 원래 별개의 문제인데, 우리는 지금까지 AI에게 둘 다 시키고 있었던 거임.

---

그런데 "속도"보다 더 중요한 게 있음

나는 WebMCP의 핵심 장점을 속도보다 신뢰성이라고 봐.

예를 들어 쇼핑몰에서 가격이 이렇게 보인다고 해보자.

인간 화면

정가 129,000원

회원 할인
→ 99,000원

쿠폰 적용 시
→ 최대 89,000원

WebMCP 없는 agent는 DOM을 읽으면서:

가격이 89,000원인가?
아니면 99,000원인가?
쿠폰이 적용돼 있는 건가?

를 판단해야 함.

WebMCP가 잘 설계돼 있다면:

{
  "listPrice": 129000,
  "currentPrice": 99000,
  "couponPrice": 89000,
  "couponApplied": false
}

라고 줄 수 있음.

그러면 해석 자체가 필요 없어.

---

특히 차이가 엄청 커지는 부분

1. 반복 작업

예를 들어 AI에게:

내 주문 내역 중 배송 안 된 거 찾아.

WebMCP 없음

주문내역 진입 → 스크롤 → 각 주문 읽음 → 페이지 넘김 → 상태 읽음...

WebMCP 있음

getOrders({
    status: "NOT_SHIPPED"
})

끝.

---

2. 복잡한 조건

강남에서 오늘 저녁 6시 이후, 2명 예약 가능하고 평점 4.5 이상인 식당 찾아줘.

일반 웹에서는 AI가:

지역 설정
+
날짜
+
시간
+
인원
+
예약 여부
+
평점

을 UI를 통해 조합해야 함.

WebMCP면:

{
  "area": "강남",
  "date": "2026-08-28",
  "after": "18:00",
  "partySize": 2,
  "reservationAvailable": true,
  "ratingMin": 4.5
}

한 번에 넣을 수도 있음.

즉 조건이 복잡해질수록 격차가 커져.

---

3. 여러 사이트를 AI가 연결할 때

여기가 WebMCP의 장기적인 진짜 맛일 수 있음.

예를 들어:

다음 주 부산 출장 잡아줘.
KTX 찾고, 숙소 알아보고, 일정에 추가해.

현재는:

코레일 UI 분석
↓
기차 검색

호텔 사이트 UI 분석
↓
숙소 검색

캘린더 UI/API
↓
일정 생성

각 사이트의 사용법을 AI가 별도로 이해해야 함.

WebMCP가 보편화됐다고 가정하면:

Korail
searchTrains()

Booking
searchHotels()

Calendar
createEvent()

처럼 전부 도구들의 조합으로 바뀜.

그러면 AI가 웹을 보는 방식 자체가 바뀌는 거야.

---

UI 변경 내성도 꽤 중요한 차이임

웹사이트 버튼이

[구매하기]

에서

[지금 구매]

로 바뀌고 위치까지 이동했다고 해보자.

DOM 기반 브라우저 자동화에서는:

"어? 구매하기 버튼 없어졌는데?"

가 될 수 있음.

반면 WebMCP가 계속:

purchaseProduct()

를 제공한다면 인간 UI는 완전히 바뀌어도 상관없어.

Before

┌──────────────┐
│   구매하기    │
└──────────────┘


After

       🛒
   지금 주문하기


AI에게는 둘 다:

purchaseProduct()

인 거야.

인간 인터페이스와 AI 인터페이스가 분리되는 것.

---

API랑 비슷한데 왜 굳이 WebMCP냐

여기서 자연스럽게 이런 생각이 들지.

“야 시발 그러면 그냥 API 아닌가?”

거의 맞는 감각이야.

차이는 접근 주체와 위치임.

	API	WebMCP
주 사용자	개발자/서버	AI agent
어디서 사용	외부 프로그램	현재 웹페이지/브라우저
인증	API key, OAuth 등 별도 인증이 흔함	현재 브라우저 세션 활용 가능
기능 발견	개발자가 문서 읽어야 함	AI가 현재 페이지의 tool을 발견
페이지 상태	별도 관리해야 함	현재 페이지 상태와 연결 가능
주요 목적	프로그램 ↔ 서비스	AI ↔ 웹페이지

그래서 WebMCP를 대충

“웹사이트에 AI 전용 리모컨을 달아주는 것”

이라고 생각하면 꽤 정확해.

---

그럼 사용자 입장에서 실제 체감은?

이게 제일 중요하겠지.

사용자 눈에는 아마 이런 식으로 나타날 가능성이 큼.

지금

나: “저 상품 장바구니 넣어.”

AI:

페이지를 확인하는 중...
상품 옵션을 찾는 중...
사이즈를 선택하는 중...
장바구니 버튼을...

그리고 가끔:

“버튼을 찾을 수 없습니다.”

ಠ_ಠ

WebMCP가 잘 된 사이트

나: “저 상품 M으로 장바구니 넣어.”

AI:

addToCart(
 productId=123,
 size="M"
)

“M 사이즈로 장바구니에 넣었어.”

끝.

---

압축해서 보면

WebMCP 없음	WebMCP 있음
AI가 화면을 사용한다	AI가 서비스 기능을 사용한다
사람 행동을 흉내 낸다	구조화된 명령을 실행한다
“어디 눌러야 하지?”	“무슨 기능을 실행하지?”
UI 변경에 민감	UI와 상대적으로 독립
결과를 해석	결과를 데이터로 받음
복잡한 작업일수록 불안정	복잡한 조건도 구조적으로 전달
사이트마다 사용법을 배워야 함	사이트가 자기 사용법을 알려줌

한 문장으로 줄이면

WebMCP 이전의 AI는 웹사이트를 대신 클릭해주는 사람이고, WebMCP 이후의 AI는 웹사이트가 제공하는 기능을 직접 조작하는 프로그램에 가까워지는 거야.

그리고 여기서 한 가지는 냉정하게 봐야 해.

WebMCP가 붙었다고 무조건 좋아지는 건 아님.

사이트가 겨우

search()

하나만 제공하면 별 의미 없음.

반대로

searchProducts()
getAvailability()
addToCart()
applyCoupon()
checkout()

처럼 서비스의 핵심 기능을 잘 설계해두면 엄청 강력해짐.

그래서 장기적으로는 단순히 **“WebMCP 지원 여부”보다 “AI에게 얼마나 좋은 tool surface를 설계했느냐”**가 더 중요한 경쟁력이 될 가능성이 높아. SEO 하듯이 대충 태그 하나 붙이고 끝나는 종류는 아니라는 거지.

아 그럼 국도 vs. 고속도로 같은 느낌이네.
그리고 api랑 비교하면 자차 운전 vs. 고속버스
이런 느낌인거고?

야, 근데 그럼 이거 내가 진행하고 있는 p의 지도라는 서비스에도 적용할 수 있다고 봄? 지금은 그 페이지 크롤링할 때 기계화된 코딩을 쓰거덩.

응. “국도 vs 고속도로” 비유는 꽤 정확해. 다만 API 비유는 살짝 수정하면 더 정확해.

• 일반 브라우저 조작 = AI가 국도에서 표지판 보며 직접 운전
• WebMCP = 사이트가 진입로·차선·출구를 잘 만들어놓은 고속도로
• API = 아예 사람용 도로망을 안 거치고 물류센터끼리 연결된 전용 수송망

그래서 API가 꼭 고속버스라기보다는 **“서비스끼리 쓰는 전용 물류도로”**에 가까워. WebMCP는 여전히 현재 브라우저와 사용자 세션이라는 세계 안에 있다는 차이가 있어.

그리고 P의지도에는 적용할 수 있는데, 네가 지금 생각한 “크롤링을 WebMCP로 대체” 방향으로 바로 가는 건 추천하지 않아. 여기 중요한 구분이 하나 있음. ( •̀ - •́ )

P의지도에는 WebMCP가 사실 두 군데에 들어갈 수 있음

적용 위치	의미	내 판단
① P의지도가 다른 행사 사이트에서 정보를 가져올 때	WebMCP를 크롤링 수단으로 사용	△ 일부만 유용
② AI가 P의지도 자체를 사용할 때	P의지도에 WebMCP 제공	◎ 매우 잘 맞음
③ P의지도 내부 수집 시스템의 공통 인터페이스	WebMCP식 tool 구조로 수집기를 추상화	◎ 지금 가장 관심 가질 부분

네 질문은 지금 ① + ③에 가까워.

---

1. 지금 네 기계식 크롤링을 WebMCP로 바꿀 수 있느냐?

예를 들어 현재 P의지도가 이런 식이라고 해보자.

서울미술관
↓
HTML 요청
↓
CSS selector
↓
제목 영역 추출
↓
날짜 영역 추출
↓
링크 추출
↓
DB 저장

사이트마다 이런 코드를 만들어놨다고 하자.

서울미술관 crawler
국립현대미술관 crawler
DDP crawler
성북문화재단 crawler
...

이게 네가 말하는 기계화된 코딩이지.

WebMCP 지원 사이트라면 이론적으로:

서울미술관
↓
WebMCP

listEvents()
getEventDetails()
searchEvents()

가 될 수 있어.

그러면 P의지도는 HTML 구조 같은 걸 별로 신경 안 쓰고:

listEvents({
  startDate: 오늘,
  endDate: +30일
})

만 호출하면 됨.

이 경우에는 존나 좋음.

예를 들어 사이트가 리뉴얼돼서:

기존

<div class="event-list">

가

새 버전

<section class="program-grid">

로 바뀌어버려도,

WebMCP의

listEvents()

계약이 유지된다면 P의지도 수집기는 안 깨짐.

이건 확실한 장점이야.

---

하지만 현실적인 문제가 있음

네가 수집하려는 행사 사이트들이 WebMCP를 지원해야 함.

지금은 2026년 8월이고 WebMCP 자체가 아직 draft 단계야. Chrome 공식 문서도 현재 WebMCP를 주로 로컬 브라우저 + human-in-the-loop workflow용으로 설명하고 있고, headless browsing은 가능할 수 있으나 주 목적은 아니라고 명시하고 있어. citeturn906622search1turn906622search2

그러니까 네 공급엔진이:

매일 새벽

서버
↓
100개 사이트 순회
↓
행사 수집
↓
DB 갱신

이라면 WebMCP가 지금 당장 이걸 통째로 대체하기에는 영역이 약간 다름.

---

여기서 내가 P의지도에 더 추천하는 방향

WebMCP 자체보다 WebMCP의 사고방식을 가져오는 것이야.

이게 꽤 중요함.

현재 네 구조가 만약:

서울미술관 크롤러 ─── DB

DDP 크롤러 ───────── DB

MMCA 크롤러 ──────── DB

성북문화재단 크롤러 ─ DB

이런 구조라면,

각 사이트의 지저분한 구현이 공급 시스템 전체에 묻어나.

대신 가운데에 이런 걸 하나 만드는 거야.

Source Adapter

예컨대 P의지도 내부에서는 모든 출처가 무조건 이 인터페이스를 제공하게 하는 거지.

discoverEvents()

getEventDetails()

getSchedule()

getVenue()

checkEventStatus()

그러면:

                   ┌ HTML crawler
서울미술관 Adapter ─┤
                   └ selector


                   ┌ 내부 API
MMCA Adapter ──────┤
                   └ JSON


                   ┌ WebMCP
어떤 미래 사이트 ──┤
                   └ listEvents()


                   ┌ Browser
괴랄한 사이트 ─────┤
                   └ AI

그런데 P의지도 공급 엔진은 이 차이를 모름.

그냥:

discoverEvents()

라고 요청함.

---

이게 왜 좋은가

지금 P의지도의 가장 본질적인 문제를 예로 들어보자.

행사를 얻고 싶은 사이트가 100개 있어.

현재 방식

각 사이트마다:

A사이트
→ HTML 구조 조사
→ 크롤러 코드 작성

B사이트
→ HTML 구조 조사
→ 크롤러 코드 작성

C사이트
→ HTML 구조 조사
→ 크롤러 코드 작성

결국 “사이트를 어떻게 읽느냐”와 “우리가 무엇을 알고 싶으냐”가 붙어 있음.

---

Adapter 구조

P의지도는 그냥 이것만 요구함.

이 출처에서

1. 새 행사 찾아
2. 행사 기간 줘
3. 장소 줘
4. 원문 URL 줘
5. 변경됐는지 알려줘

그 뒤 구현은 출처마다 제일 싼 방법을 선택.

사이트 상태	사용하는 방법
공식 API 있음	API
WebMCP 있음	WebMCP
JSON endpoint 있음	내부 endpoint
HTML 안정적	기계식 crawler
HTML 더러움	browser + AI
구조 계속 변함	AI 조사원
일부만 구조화 가능	crawler + AI 혼합

이게 훨씬 강함.

---

그리고 이게 네가 최근 고민하던 방향하고도 꽤 잘 맞음

네가 공급엔진을 다시 보면서 이미 문제를 하나 제대로 짚었잖아.

기존에는:

범용 공급엔진을 먼저 기계화해서 만들려다가 구조가 너무 복잡해졌다.

그래서 최근에는:

사람의 실제 처리 과정인 발견 → 조사 → 수집/버리기 → 등록을 먼저 이해하고, AI를 조사원처럼 쓰면서 반복적으로 검증된 부분만 기계화한다

쪽을 보고 있었고.

여기에 WebMCP 사고방식을 섞으면 꽤 예쁜 구조가 나와.

memcite

---

내가 지금 P의지도라면 이렇게 감

                    P의지도 Supply Engine
                           │
                           │
                 "행사를 찾아줘"
                           │
                           ▼
                  Source Adapter Layer
                           │
         ┌─────────────────┼──────────────────┐
         │                 │                  │
         ▼                 ▼                  ▼
      API Adapter      HTML Adapter       AI Adapter
         │                 │                  │
         ▼                 ▼                  ▼
      사이트 A          사이트 B            사이트 C

                              +
                              │
                        WebMCP Adapter
                              │
                              ▼
                         미래 사이트 D

그리고 중요한 건:

Adapter의 외부 계약은 동일하게 유지

예:

discover_events
get_event_detail
check_event_status

이런 식.

---

그러면 WebMCP가 등장했을 때 좋은 점

미래에 어떤 사이트가 WebMCP를 지원하기 시작함.

기존 같으면:

“오 새로운 기술이네. 우리 공급엔진 뜯어고쳐야 하나?”

가 되는데,

이 구조에서는 그냥:

WebMCPSourceAdapter

하나 추가하면 끝.

반대로 WebMCP가 생각보다 망해서 사라져도?

P의지도 구조에는 아무 영향 없음.

(￣▽￣) 이게 기술 유행에 베팅하지 않고 기술의 이득만 빨아먹는 구조임.

---

오히려 더 흥미로운 것은 AI 조사원과의 결합임

네가 고민했던 Luna 같은 저렴한 모델을 조사원으로 먼저 투입하는 구조를 생각해보자.

AI에게 지금:

“이 페이지에 행사 있으면 찾아서 기간, 장소, CTA 확인해”

라고 하면 AI가 페이지 전체를 읽고 판단해야 하지.

그런데 Adapter가 먼저 기계적으로:

{
  "title": "...",
  "raw_date": "...",
  "raw_location": "...",
  "description": "...",
  "links": [...]
}

까지 뽑아주면,

AI는:

페이지 읽기

가 아니라

이 후보가 P의지도에 들어갈 행사인지 판단
기간 정상화
장소 정상화
공개범위 판단

에 집중할 수 있음.

즉:

기계
= 확실하고 반복적인 일

AI
= 의미 판단이 필요한 일

로 역할 분리가 됨.

이게 네 현재 방향에는 WebMCP를 직접 도입하는 것보다 훨씬 중요한 시사점이라고 봐.

---

그러면 WebMCP를 지금 P의지도에 구현할까?

내 답은 이렇게 갈림.

항목	지금 할까?
기존 크롤러를 WebMCP로 전환	❌
모든 출처에 비공식 WebMCP userscript 제작	❌
WebMCP 지원 출처가 있다면 활용	✅
내부 수집기를 WebMCP식 tool contract로 통일	✅ 강추
P의지도 자체에 WebMCP 제공	△ 나중에 꽤 좋음
WebMCP를 공급엔진 핵심 dependency로 채택	❌ 아직 이름

특히 기존 크롤러를 WebMCP로 바꾸는 건 목적과 수단이 뒤집힌 것 같아.

네 목적은:

“행사 정보를 저렴하고 안정적으로 지속 수집한다.”

이지

“최신 WebMCP 기술을 쓴다.”

가 아니잖아.

---

P의지도 자체에 WebMCP를 붙이는 건 오히려 얘기가 다름

이건 꽤 잘 맞아.

예를 들어 나중에 P의지도가:

searchEvents({
    location,
    date,
    category
})

getNearbyEvents({
    latitude,
    longitude,
    radius
})

getEventDetail({
    eventId
})

saveEvent({
    eventId
})

같은 걸 제공하면,

사용자가 ChatGPT 같은 agent한테:

“오늘 성수에서 6시 이후 갈 만한 행사 찾아줘. 전시는 빼고.”

라고 했을 때 agent가 P의지도를 직접 사용할 수 있게 됨.

ChatGPT
   ↓
P의지도 WebMCP
   ↓
searchEvents(
  location="성수",
  date=오늘,
  after=18:00,
  exclude=["전시"]
)
   ↓
P의지도 DB

이건 P의지도라는 제품의 유통채널을 인간 UI 밖으로 확장하는 것이라서 전략적으로는 훨씬 의미가 커.

Chrome도 WebMCP의 목적을 사이트가 agent에게 structured tools를 제공해서 기존 mouse/keyboard actuation보다 빠르고 안정적으로 기능을 수행하게 하는 것으로 설명하고 있어. citeturn906622search0turn906622search3

---

그래서 나는 세 층으로 봄

① INPUT
행사 정보 수집

API / crawler / WebMCP / browser / AI
            ↓

② CORE
P의지도 내부 표준

discover
extract
normalize
judge
store
            ↓

③ OUTPUT
사용자가 P의지도 이용

Web UI
+
API
+
WebMCP
+
향후 Agent

지금 가장 중요한 건 ②야.

WebMCP를 보고 나서

“우리 크롤러를 WebMCP로 갈아엎을까?”

보다는

“어라, 우리도 수집 방법과 수집 목적을 분리해서 tool contract를 만들어놓으면 되겠네?”

라는 깨달음을 가져가는 게 더 가치 있어.

그리고 네 상황에서는 특히 그래. 이미 한 번 범용 공급엔진을 너무 일찍 기계화해서 복잡도가 폭증하는 문제를 겪었으니까, 이번에는 WebMCPSourceAdapter 같은 거대한 신기술 계층부터 만들기보다 2~3개 반복되는 행동이 실제 운영에서 굳은 다음 그 행동에 이름을 붙여 contract로 만드는 것이 맞아. memcite

확장해서 보면

이 구조가 잘 잡히면 나중에 WebMCP뿐 아니라 MCP, REST API, Codex tool, Luna tool도 거의 같은 내부 행동 위에 얹을 수 있어.

                   ┌ REST API
                   ├ MCP
P의지도 Domain ────┼ WebMCP
                   ├ Internal AI Tool
                   └ Admin UI

즉 WebMCP를 채택하는 것보다 P의지도의 핵심 행동을 tool 단위로 정의하는 것이 먼저야.

그렇게 해놓으면 WebMCP는 새로운 아키텍처가 아니라 그냥 또 하나의 출입문이 된다. 이게 내가 보기엔 P의지도에서 가장 건강한 적용 방식이야.

근데 그 만약 우리가 플러그인이나 익스텐션 주입한 사이트의 구조가 변경되더라도 괜찮은건가? 왜냐며 ㄴ이런 경우는 webmcp를 해당 사이트에서 만든 네이티브가 아니라 우리가 주입한 거잖아.

맞아. 네가 정확히 약점을 찔렀어.

외부에서 주입한 WebMCP는 사이트 구조 변경에 자동으로 안전해지는 게 아님.
오히려 정확히 말하면:

WebMCP가 없을 때의 취약성을 없애는 게 아니라, 그 취약성을 adapter 내부에 숨겨놓는 것에 가까워.

(눈_눈) 추상화했다고 현실이 증발하진 않는다.

네이티브 WebMCP vs 우리가 주입한 WebMCP

	사이트가 만든 네이티브 WebMCP	우리가 만든 주입형 WebMCP
searchEvents() 같은 tool	사이트 공식 기능	우리가 임의로 만든 기능
사이트 UI 변경	대체로 영향 적음	구현 방식에 따라 깨질 수 있음
내부 API 변경	사이트가 같이 수정할 가능성 높음	우리가 다시 분석해야 함
DOM 변경	거의 관계없을 수 있음	DOM 의존하면 바로 영향
유지보수 책임	사이트 운영자	우리
안정성	높음	구현에 따라 천차만별

핵심은 WebMCP tool 자체가 아니라 그 tool 안에서 뭘 하고 있느냐야.

---

예를 하나 들어보자

우리가 어떤 사이트에 이런 WebMCP tool을 주입했다고 해.

getEvents()

AI 입장에서는 너무 깔끔하지.

AI
 ↓
getEvents()
 ↓
행사 목록

그런데 내부를 열어보면 이런 식일 수 있음.

취약한 구현

getEvents()

↓

//div[@class="event-list"]/div
찾기

↓
.event-title 읽기

↓
.date-text 읽기

사이트가 리뉴얼해서:

<div class="event-list">

가

<section class="programs">

으로 바뀌면?

💥

getEvents()는 그대로 존재하지만 안에서는 아무것도 못 찾음.

AI는 여전히:

getEvents()

만 호출했는데 결과가 깨지는 거지.

---

그래서 내가 전에 말한

UI가 바뀌어도 WebMCP는 안 깨진다

는 건 사이트가 직접 WebMCP를 제공할 때 특히 강하게 성립하는 이야기야.

사이트 개발자가:

UI 변경
+
내부 코드 변경
+
WebMCP 구현 유지

를 같이 관리하니까.

반면 우리가 외부에서 주입하면:

사이트
       ↓ 변경

우리 Adapter
       ↓ ???

WebMCP Tool
       ↓

AI

중간 Adapter가 사이트와 따로 놀고 있음.

사이트 입장에서는 우리가 있는지도 모르니까 당연히 호환성을 보장해줄 이유가 없어.

---

그런데 주입형이라고 전부 똑같이 취약한 건 아님

여기가 진짜 중요해.

안정성 순위를 대략 매기면

1. 공식 공개 API 기반

가장 좋음.

getEvents()
 ↓
api.example.com/events

사이트 UI가:

목록형 → 카드형 → 지도형 → 3D 홀로그램

으로 미친 짓을 해도 API만 그대로면 상관없음.

★★★★★

---

2. 사이트 내부 JSON/API 기반

웹페이지가 자체적으로 사용하는 endpoint를 Adapter가 호출하는 방식.

페이지
 ↓
GET /api/events?page=1
 ↓
JSON

우리도 똑같이 호출.

UI 변경에는 상당히 강함.

다만 사이트가 내부 API를:

/api/events

에서

/v2/programs

로 바꾸면 깨짐.

★★★★☆

---

3. 페이지의 구조화된 데이터 기반

예를 들어 HTML 안에:

{
  "@type": "Event",
  "name": "...",
  "startDate": "..."
}

같은 JSON-LD가 있음.

이걸 읽는 방식.

디자인 변경에는 꽤 강함.

★★★★☆

---

4. 의미 기반 DOM 탐색

예:

"행사"
"날짜"
"장소"

라는 의미를 가진 영역을 찾아

selector 하나에 박아놓는 것보다 강함.

하지만 대규모 리뉴얼에는 깨질 수 있음.

★★★☆☆

---

5. 고정 CSS selector

document.querySelector(
  "#content > div:nth-child(3) > ul > li"
)

인간이 만든 가장 아름다운 시한폭탄 중 하나임.

★★☆☆☆

---

6. 화면 좌표 기반

x=823
y=451

클릭

창 크기만 바뀌어도 장례식 시작.

★☆☆☆☆

---

그래서 좋은 외부 WebMCP adapter는 이렇게 만들게 됨

단순히:

WebMCP
↓
DOM selector

가 아니라:

             ┌ 공식 API
             │
             ├ 내부 JSON API
             │
getEvents ───┼ 구조화 데이터
             │
             ├ DOM
             │
             └ AI/browser fallback

처럼 여러 레이어를 가지고 있어야 함.

예를 들어:

1. API 살아있음?
→ 사용

없음

2. JSON-LD 있음?
→ 사용

없음

3. 기존 DOM selector 작동?
→ 사용

없음

4. AI에게 현재 페이지 구조 다시 분석시킴
→ 복구

이런 식.

그러면 리뉴얼이 발생해도 자동 복구 가능성이 올라감.

---

그래서 WebMCP가 주는 이점은 여전히 있음

여기서 이런 의문이 생길 수 있지.

“그럼 결국 크롤러 깨지는 거랑 똑같잖아?”

사이트와 연결되는 부분에서는 맞아.

하지만 시스템 전체에서는 차이가 있음.

기존:

AI
 ↓
사이트 UI
 ↓
selector
 ↓
browser
 ↓
페이지

각 AI가 사이트 사용법을 알아야 함.

Adapter 구조:

AI
 ↓

getEvents()
getEventDetail()
searchEvents()

 ↓

[사이트별 더러운 구현]

 ↓
사이트

사이트가 깨졌을 때 한 곳만 고치면 됨.

예를 들어 ChatGPT, Claude, Codex 세 개가 같은 사이트를 쓴다고 하자.

Adapter 없음

ChatGPT 자동화 수정
Claude 자동화 수정
Codex 자동화 수정

Adapter 있음

Website Adapter 수정
          ↓
ChatGPT ─┐
Claude ──┼ 전부 다시 정상
Codex ───┘

이게 상당히 큰 차이야.

---

국도 비유를 그대로 이어가면

네이티브 WebMCP

사이트 운영자가 직접 만든 고속도로.

도시를 재개발하더라도 고속도로 연결을 유지할 책임이 도시 쪽에 있음.

외부 WebMCP Adapter

우리가 몰래 만든 사설 진입도로.

고속도로
   ↓
우리 진입도로
   ↓
사이트 내부 도로

사이트가 어느 날 내부 도로를 갈아엎어버리면:

“어? 여기 원래 교차로 있었는데?”

하고 우리 진입도로가 절벽으로 연결될 수 있음.

그래서 우리가 다시 공사해야 함.

---

P의지도에서는 이 distinction이 특히 중요함

네 서비스가 외부 행사 사이트를 계속 수집해야 한다면:

WebMCP Adapter를 만들면
크롤링 유지보수가 사라진다

❌ 이건 아님.

정확한 표현은:

사이트별 유지보수 문제를
일관된 Adapter 계층 아래로 격리한다

✅ 이거야.

그리고 나는 이게 충분히 가치가 있다고 봐.

P의지도 입장에서는:

discoverEvents()

라는 계약만 알고 있고,

그 내부가 오늘은:

CSS crawler

였다가

내일은:

API

가 되고,

나중엔:

native WebMCP

가 되어도 상관없는 구조.

이게 좋은 설계지.

한 문장으로 정리하면

네이티브 WebMCP는 사이트 변경에 대한 안정성을 사이트 운영자가 보장해주는 구조이고, 외부 주입 WebMCP는 사이트 변경의 취약성을 없애지는 못하지만 그 취약성을 하나의 Adapter 안에 가둬두는 구조야.

그래서 외부 주입 WebMCP의 가치는 **“안 깨짐”이 아니라 “깨져도 한 군데만 고치면 됨 + AI에게 안정적인 인터페이스를 제공함”**이라고 이해하는 게 가장 정확해.

P의지도 Supply Engine
│
│
"행사를 찾아줘"
│
▼
Source Adapter Layer
│
┌─────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
API Adapter HTML Adapter AI Adapter
│ │ │
▼ ▼ ▼
사이트 A 사이트 B 사이트 C

                          +
                          │
                    WebMCP Adapter
                          │
                          ▼
                     미래 사이트 D

---

근데 이 구조면 뭔차이지? 지금도 adapter가 가져온 정보를 ai가 처리하잖아.

맞아. 네가 지금 짚은 게 맞아.
네 현재 구조가 이미

사이트
  ↓
사이트별 Adapter
  ↓
정보 추출
  ↓
AI가 판단/정제
  ↓
P의지도 DB

라면, 내가 위에서 그린 Source Adapter Layer는 본질적으로 새 아키텍처가 아님. 이름만 더 번듯하게 붙였을 가능성이 높다. 인간은 폴더 이름을 바꾸고 혁신이라 부르곤 하지. (¬_¬)

지금 구조와 내가 말한 구조를 비교하면

	네 현재 구조	내가 앞에서 말한 구조
사이트별 처리	Adapter 있음	Adapter 있음
페이지에서 정보 가져오기	Adapter가 함	Adapter가 함
AI에게 전달	함	함
AI가 의미 판단	함	함
DB에 정규화해서 저장	함	함
사이트 변경 시	해당 Adapter 수정	해당 Adapter 수정

이 수준에서는 차이 없음.

그래서 네 시스템에 이미 이게 있다면:

“WebMCP를 보고 Source Adapter Layer를 도입하자”

는 제안은 취소하는 게 맞아. 이미 하고 있으니까.

---

그럼 WebMCP가 들어오면 정확히 어디가 달라지냐

차이가 나는 곳은 Adapter의 위쪽이 아니라 아래쪽이야.

현재 예를 들어:

P의지도
   ↓
MMCA Adapter
   ↓
HTML scraping
   ↓
MMCA

라고 하자.

MMCA가 WebMCP를 공식 지원하게 되면:

P의지도
   ↓
MMCA Adapter
   ↓
WebMCP
   ↓
MMCA

로 바뀌는 것뿐이야.

즉 P의지도 전체 구조는 그대로임.

Adapter 내부 구현이:

HTML selector

에서

listEvents()
getEventDetail()

로 바뀌는 거지.

이게 훨씬 정확한 그림이야.

---

예를 들어 현재 Adapter가 이렇게 한다고 치자

MMCA Adapter

1. 전시 페이지 다운로드
2. 행사 카드 selector 찾기
3. 제목 추출
4. 날짜 추출
5. URL 추출
6. AI에게 전달

WebMCP가 있으면:

MMCA Adapter

1. listEvents() 호출
2. 결과 AI에게 전달

정도가 됨.

그 이후:

이게 P의지도 대상인가?
날짜를 어떻게 정규화할까?
실제로 참가 가능한 행사인가?
중복인가?

같은 AI 판단 과정은 그대로 살아 있음.

---

여기서 중요한 구분

네 공급 시스템에는 사실 두 문제가 있음.

A. 정보를 어떻게 가져올 것인가

HTML scraping
API
RSS
WebMCP
Browser

이건 수집 방법 문제.

B. 가져온 정보가 무슨 의미인가

이게 행사인가?
언제 열리지?
누구나 갈 수 있나?
팝업인가?
전시인가?
이미 있는 행사인가?
P의지도에 넣을 가치가 있나?

이건 판단/정규화 문제.

네 AI는 주로 B를 담당하고 있는 거고, WebMCP는 대부분 A를 개선하는 기술이야.

둘은 경쟁 관계가 아니야.

---

현재 구조를 이렇게 보는 게 정확함

                   외부 사이트
                       │
             ┌─────────┼─────────┐
             │         │         │
           HTML       API      WebMCP
             │         │         │
             └─────────┼─────────┘
                       ▼
                 기존 Adapter
                       │
                       ▼
                 Raw Candidate
                       │
                       ▼
                      AI
                ┌──────┼──────┐
                │      │      │
              판단   정규화   검증
                │      │      │
                └──────┼──────┘
                       ▼
                    P의지도

이게 네 시스템에 WebMCP를 넣었을 때의 현실적인 그림이야.

---

그렇다면 P의지도에서 WebMCP가 얼마나 중요한가?

솔직히 말하면 지금은 별로 안 중요할 가능성이 큼.

왜냐하면 네 핵심 병목이:

“HTML을 가져오는 것”

보다

“수많은 행사 후보를 발견하고, 실제 행사인지 이해하고, 정보 빠진 걸 보충하고, 수집할지 버릴지 판단하는 것”

쪽이라면 WebMCP는 병목의 일부만 해결하기 때문이야.

예를 들어 현재 비용이:

사이트 접근      10%
정보 추출        20%
행사인지 판단    25%
누락정보 조사    25%
중복/품질검사    20%

라고 치면, WebMCP가 엄청 좋아져도 앞의 30% 일부만 줄여주는 거야.

숫자는 설명을 위한 예시지만, 구조적으로는 이렇다는 뜻.

---

다만 이런 경우에는 꽤 커짐

현재 Adapter 유지보수가 골칫거리라면 얘기가 달라.

예를 들어 200개 공급처가 있고:

이번 주
A사이트 selector 깨짐
B사이트 pagination 변경
C사이트 React 전환
D사이트 HTML 구조 변경

이런 일이 계속 발생한다면,

그 사이트들이 공식 WebMCP를 지원할 경우:

HTML 구조 변경
     ↓
사이트 운영자가 WebMCP는 유지
     ↓
우리 Adapter 변화 없음

이 될 수 있으니까 상당히 좋지.

즉 WebMCP가 P의지도에 주는 가장 직접적인 가치는:

AI를 더 똑똑하게 만드는 것

이 아니라

외부 사이트에서 raw information을 안정적으로 가져오는 비용을 낮추는 것

이야.

---

그리고 외부 주입 WebMCP라면?

더더욱 네 기존 Adapter랑 차이가 줄어듦.

현재:

Adapter
 ↓
HTML selector

외부 주입 WebMCP:

Adapter
 ↓
우리가 만든 WebMCP
 ↓
HTML selector

(ಠ_ಠ)

이러면 레이어 하나 더 생겼을 뿐이야.

그래서 P의지도 공급 수집만을 목적으로 한다면 굳이 외부 WebMCP를 하나 더 끼우는 건 별 이득이 없을 수 있음.

특히 수집기가 이미 잘 만들어져 있다면 더더욱.

---

네이티브 WebMCP라면 다르다

현재

P의지도 Adapter
   ↓
우리가 관리하는 scraper
   ↓
사이트

vs

Native WebMCP

P의지도 Adapter
   ↓
사이트가 관리하는 WebMCP
   ↓
사이트 내부 시스템

여기서는 유지보수 책임 일부가 사이트 쪽으로 넘어간다는 게 진짜 가치야.

---

그래서 지금 내 판단은

P의지도 활용	가치
현재 Adapter 구조를 WebMCP식으로 재설계	거의 없음
기존 crawler 위에 외부 WebMCP 씌우기	낮음
네이티브 WebMCP 지원 사이트가 생기면 Adapter 입력원으로 사용	높음
사이트별 scraper 유지보수 비용 감소	높음
AI의 판단/조사 과정 대체	거의 못 함
P의지도 자체를 WebMCP로 외부 agent에 개방	별개의 꽤 흥미로운 기회

결론

네가 지금 이미 Adapter → AI 구조를 쓰고 있다면, 공급 시스템 아키텍처 관점에서 WebMCP가 주는 새로운 깨달음은 크지 않아.

WebMCP는 네 시스템을 갈아엎을 기술이 아니라:

Adapter가 외부 사이트와 대화하는 여러 방법 중
새로운 하나

정도로 보는 게 맞아.

그리고 비공식 주입 WebMCP를 굳이 네 기존 크롤러와 AI 사이에 끼우는 건 과설계일 가능성이 높아.

오히려 내가 지금 관심 가질 건 **“현재 P의지도 공급 파이프라인에서 진짜 비용이 가장 많이 발생하는 단계가 어디인가”**야. HTML 추출이 아니라 후보 발견, 페이지 이해, 누락 정보 보충, 수집 판정이라면 WebMCP는 흥미로운 기술이지만 당장 네 문제의 해답은 아니다. 그 구분을 해두는 게 중요해.

기존의 사이트들을 webmcp최적화 해주는 사업을 한번 해볼까?

해볼 가치는 있음. 다만 “WebMCP 최적화 업체”로 시작하면 나는 반대야. 너무 기술 이름 중심이고, 표준이 아직 덜 굳었고, 자동 생성 도구가 벌써 나오고 있어서 금방 단가가 녹을 가능성이 큼.

대신 **“기존 웹사이트를 AI Agent-ready로 바꿔주는 서비스”**로 잡고, WebMCP를 핵심 구현 수단 중 하나로 쓰는 건 꽤 괜찮아 보여. 지금은 오히려 서비스형으로 먼저 들어가 시장을 배우기 좋은 시점이야.

왜 지금 조금 흥미롭냐

WebMCP는 2026년 8월 26일자로도 아직 W3C Community Group Draft이고, Chrome 공식 문서 기준 Chrome 149부터 Origin Trial이 진행되는 실험 단계야. 즉 “이미 모든 웹사이트가 당장 해야 하는 필수 표준” 단계는 아니다. citeturn124763search6turn123402search0

그런데 동시에 Google은 공식적으로 WebMCP 문서, best practice, eval 도구까지 내놓고 있고, GoogleChromeLabs에서도 Inspector, Evals, Polyfill, 데모들을 공개하고 있어. 그러니까 장난감 수준에서 끝날 물건이라기보다는 실제 표준화 실험이 꽤 진지하게 진행 중이라고 보는 게 맞아. citeturn123402search2turn124763search5

그리고 이미 해외에는 돈 받고 이걸 해주는 업체들이 생겼다.

현재 시장에 나온 형태	실제 사례
WebMCP 구축 대행	WebMCP.ro, Salam Experts
Agent-ready 웹사이트 구축	Raze
WebMCP Audit	WebMCP Checker
자동 진단 + 코드 생성 SaaS	Web-MCP.net
OSS 자동 진단/생성	agent-ready, AgentReady
WebMCP 사이트 디렉터리	webmcp.com

예를 들어 WebMCP.ro는 Audit €290, 일반 구현 €890부터, e-commerce €1,490부터, 유지관리 €149/월부터 공개해놨고, WebMCP Checker는 심층 Audit을 “low four figures USD”부터 판다고 명시한다. 이미 최소한 서비스라는 상품 형태 자체는 검증되고 있는 셈이야. citeturn871014search9turn871014search11

다만 여기서 함정이 있다.

---

내가 보기에 잘못된 사업

❌ “사이트에 WebMCP 달아드립니다”

고객한테 이렇게 팔면:

안녕하세요. WebMCP 구축해드립니다.

고객:

그게 뭔데요.

너:

AI agent가 structured tool...

고객:

그래서 매출이 늘어요?

너:

미래에는...

고객:

수고하세요.

( ･᷄ὢ･᷅ )

기술 자체는 고객의 구매 이유가 아니야.

그리고 단순 구현은 이미 자동화되기 시작했어.

예를 들어 agent-ready OSS는 URL을 스캔해서 WebMCP scaffold까지 자동 생성한다고 하고, Web-MCP.net도 사이트 스캔, tool generation, testing 등을 제품화하고 있어. citeturn586156search1turn871014search1

즉 미래에는:

WebMCP 코드 작성

= 비싼 컨설팅 영역 ❌
= AI가 자동 생성하는 commodity ✅

가 될 가능성이 높음.

---

대신 이렇게 파는 게 맞다고 봄

“네 웹서비스를 AI가 실제로 사용할 수 있게 만들어준다.”

예를 들어 온라인 쇼핑몰한테:

지금 AI는 네 상품 페이지를 읽을 수는 있지만,
재고 확인 → 옵션 선택 → 장바구니 추가를 안정적으로 수행하지 못한다.

우리가 AI agent가 이 흐름을 직접 사용할 수 있도록 만들어준다.

예약 SaaS라면:

ChatGPT/브라우저 에이전트가
예약 가능 시간 조회 → 상품 선택 → 예약 단계까지
사이트 안에서 안정적으로 수행하게 해준다.

고객지원 SaaS라면:

AI가 FAQ를 읽는 수준이 아니라
주문 조회 → 환불 가능 여부 확인 → 지원 티켓 생성까지 하게 만든다.

이렇게 결과를 파는 거지.

WebMCP라는 단어는 아래 구현 명세에나 있어도 됨.

---

사업 구조는 이렇게

내가 한다면 제품명을 대충:

Agent Ready

같은 상위 카테고리로 잡을 것 같아.

그리고 서비스는 4단계.

단계	고객이 받는 것
1. Agent Audit	AI가 현재 사이트에서 어디까지 할 수 있고 어디서 실패하는지
2. Tool Strategy	AI에게 어떤 행동을 열어주는 게 실제 가치 있는지
3. Implementation	WebMCP / MCP / 구조화 데이터 등을 실제 코드에 구현
4. Evals & Monitoring	실제 AI가 자연어 요청을 제대로 수행하는지 지속 테스트

특히 2번이 의외로 중요함.

Google 공식 best practice도 WebMCP 구현 전에 먼저 tool strategy를 설계하라고 권고하고 있어. 단순히 페이지의 모든 버튼을 tool로 만드는 게 좋은 구현이 아니기 때문이야. citeturn123402search6

---

예를 들어 무신사 같은 곳을 고객이라고 해보자

페이지에 500가지 기능이 있다고 해서:

clickLogo()
openSidebar()
changeTab()
clickHeart()
...

이딴 걸 만드는 게 아니고,

사용자가 AI에게 실제로 부탁할 업무 단위를 찾아야 함.

searchProducts()
getProductAvailability()
compareProducts()
selectVariant()
addToCart()
checkOrderStatus()

이게 Agent UX 설계야.

나는 장기적으로 이 부분이 코드 작성보다 훨씬 돈 되는 영역이라고 봐.

---

그렇다면 누가 첫 고객이어야 하나

모든 웹사이트가 좋은 고객은 아님.

별로인 고객

회사 소개 사이트
블로그
뉴스 사이트
단순 포트폴리오

AI가 읽기만 하면 되는 사이트는 WebMCP 가치가 크지 않아.

반대로:

매우 좋은 고객

업종	이유
예약 서비스	검색 → 조회 → 예약이라는 명확한 action
이커머스	검색 → 재고 → 장바구니 → 구매
SaaS	실제 기능 조작 가치가 큼
여행/숙박	조건 검색이 복잡함
티켓/이벤트	일정/좌석/예약 workflow
채용 플랫폼	검색/필터/지원
부동산	검색/필터/문의
고객지원 포털	조회/티켓/변경
B2B lead-gen	견적/상담/데모 예약

공통점은:

“사람이 사이트 안에서 뭔가 일을 한다.”

야.

---

특히 한국에서는 여기 하나를 노려볼 만함

검색해보니까 지금 영어권에는 WebMCP 컨설팅/구축 서비스들이 벌써 몇 개 나오는데, 한국어권에서 전문 구축 사업자로 명확하게 포지셔닝된 사례는 검색상 거의 잡히지 않았어.

이건 시장이 있다는 증거는 아님.

두 가지 가능성이 동시에 있음.

A. 아직 아무도 안 들어왔다.
→ first mover opportunity

B. 아무도 돈을 안 낸다.
→ empty market

(－‸ლ) 경쟁자가 없다고 항상 좋은 소식은 아니다.

그래서 절대로 처음부터 사업체/제품 크게 만들면 안 됨.

---

내가 한다면 서비스부터 검증함

초기 상품 딱 하나.

AI Agent Readiness Audit

웹사이트 URL 하나 받아서:

① AI browser로 실제 사용
② 주요 user journey 5~10개 선정

예:
"검은 운동화 찾아줘"
"다음주 화요일 상담 예약해줘"
"내 주문 상태 확인해줘"

③ 현재 Agent 성공률 측정

④ 왜 실패하는지 분석

⑤ WebMCP를 적용하면
   어떤 tools가 필요한지 설계

⑥ 실제 prototype 1개 구현

결과물:

현재
Agent Success Rate: 43%

주요 실패
- 상품 필터
- 옵션 선택
- 재고 확인
- 장바구니

Proposed tools
- search_products
- get_variant_availability
- add_to_cart

WebMCP prototype 적용

Agent Success Rate: 91%

이런 Before / After 데모를 주는 거야.

이게 그냥:

WebMCP 설치해드렸습니다.

보다 100배 팔기 쉽지.

---

그리고 첫 MVP는 엄청 작게 만들 수 있음

사이트 하나 넣으면:

URL
 ↓

AI/browser crawler
 ↓

① 사이트 기능 분석
② 주요 user journey 추론
③ browser agent 테스트
④ 실패 지점 기록
⑤ WebMCP tool 후보 생성
 ↓

Agent Readiness Report

정도.

여기서 고객이 돈을 내면:

↓
코드베이스 접근
↓
WebMCP 실제 구현
↓
PR 생성
↓
Agent eval
↓
배포

로 넘어감.

---

그리고 이건 네가 AI로 개발하는 방식과도 궁합이 꽤 좋음

이 서비스의 대부분은 꽤 자동화 가능해.

URL 분석
↓
Codex가 repo 분석
↓
기능 surface 추출
↓
WebMCP tool 설계
↓
구현
↓
browser agent testing
↓
eval
↓
report

그래서 전통적인 SI처럼:

개발자 5명 × 3주

가 아니라,

너 + Codex + 자동화 pipeline

으로 꽤 많은 고객을 처리할 수 있을 가능성이 있음.

이건 솔로 서비스 비즈니스로서는 매력적인 부분이야. memcite

---

다만 가장 큰 리스크 3개

1. 시장 타이밍

이게 제일 큼.

Chrome 공식 자료 기준 Origin Trial 단계라 아직 기업이:

“WebMCP 안 하면 큰일 납니다!”

라고 느끼는 단계가 아님. citeturn123402search0

따라서 당장 영업하면:

“왜 지금 해야 하죠?”

라는 질문을 계속 받을 거야.

---

2. Agent 측 지원

WebMCP 사이트가 있어도 실제 소비하는 browser agent가 충분히 보급돼야 가치가 발생함.

즉:

Website adoption
        ×
Agent adoption

양쪽이 동시에 필요해.

양면 채택 문제임.

---

3. 구현 자체는 commodity가 될 가능성이 높음

아까 봤듯 벌써:

scan
generate tools
generate scaffold
eval

을 자동화하는 OSS와 SaaS들이 나타나고 있어. citeturn586156search1turn871014search0

그래서:

“WebMCP를 코딩할 줄 안다.”

는 moat가 거의 안 될 거야.

---

그래서 나는 이렇게 포지셔닝함

               BAD

      WebMCP 개발 대행사
              ↓
        기술 commodity


               GOOD

    Agent Experience 회사
              ↓
   "AI가 이 서비스를 얼마나
      잘 사용할 수 있는가?"
              ↓
   ┌──────────┼──────────┐
 WebMCP      MCP         AEO
   │          │           │
Evals      Analytics   Monitoring

WebMCP는 제품이 아니라 기술 스택 하나.

SEO 업체가:

HTML meta tag 설치회사

가 아닌 것과 똑같아.

---

장기적으로 진짜 제품이 된다면

서비스하면서 데이터가 쌓일 거잖아.

쇼핑몰에는
search_products
get_stock
add_to_cart
가 중요하네

예약 서비스에는
search_slots
get_availability
book
가 중요하네

그러면 점점 vertical template가 생김.

Cafe24 Agent Kit

Shopify Agent Kit

예약 SaaS Agent Kit

Event Platform Agent Kit

그 다음에는:

GitHub 연결
↓
Agent Ready 분석
↓
권장 Tool Surface 생성
↓
자동 PR
↓
Evals
↓
배포
↓
Monitoring

이라는 SaaS로 갈 수 있음.

그때부터 **“사이트 최적화 대행” → “Agent infrastructure 제품”**으로 넘어가는 거지.

---

내 평가는 이 정도

항목	평가
기술적 실행 가능성	9/10
초기 자본 필요	9/10 유리
현재 경쟁 강도	8/10 유리
현재 고객 인지도	2/10
현재 명확한 ROI	3/10
시장 성장 가능성	8/10
단순 WebMCP 구현의 moat	2/10
Agent UX/Evals까지 포함한 사업	7/10
솔로 창업 실험 적합성	9/10

그래서 결론은

“한번 해볼까?” → 응, 실험은 꽤 해볼 만함.

다만 회사부터 만들 생각은 말고, 나는 2주짜리 demand test 수준으로 볼 거야.

핵심 가설은 WebMCP가 뜨느냐가 아니고 이거임:

“웹서비스 운영자가 자기 서비스를 AI agent가 안정적으로 사용하게 만드는 데 지금 돈을 낼 의향이 있는가?”

이게 검증되면 WebMCP가 살아남든 API 형태가 약간 바뀌든 MCP랑 합쳐지든 별 상관 없어.

오히려 브랜드를 WebMCP에 종속시키지 않는 게 핵심이야.

WebMCP Optimization보다는 Agent-ready Web / Agent Experience / Agent Compatibility 같은 상위 문제를 먹어야 해.

그리고 꽤 흥미로운 점은, WebMCP 자체가 아직 Draft라서 지금 서비스로 들어가면 돈보다 먼저 “구현 경험 데이터”를 쌓을 수 있다는 것이야. 시장이 커졌을 때 가장 귀한 건 WebMCP 문서 읽어본 사람이 아니라 **“실제 쇼핑몰 20개, 예약 서비스 10개에 붙여보고 어디서 깨지는지 아는 사람”**일 가능성이 높아.

이건 네가 할 거라면 서비스-first → 반복 패턴 수집 → tooling → SaaS 순서가 가장 말이 된다. memcite