목차
- 콘텐츠가 아니라 인터페이스가 바뀌고 있다
- llms.txt만 추가하면 끝난다는 오해
- API가 다시 1순위로 돌아왔다
- 콘텐츠 늘리기 함정 — 데이터로 본 결과
- 사람과 기계가 같은 URL을 보는 시대의 끝
- 그래서 한 줄로 정리하면
- 그럼 지금 뭘 해야 하나
- 한계와 남은 의문
사내 API 게이트웨이 로그에 못 보던 User-Agent가 늘기 시작했다. ClaudeBot, GPTBot, PerplexityBot, Bytespider. 한 달 사이에 비인간 트래픽 비율이 4%에서 11%로 뛰었다. 작년 같은 분기에는 1%도 안 됐던 값이다. 흥미로운 건 이 봇들이 요청 패턴, 호출하는 엔드포인트, robots.txt 처리 방식까지 일반 검색 크롤러랑 완전히 다르다는 점이다.
그런데, 업계에서 도는 진단은 단순하다. AIO(AI Optimization), GEO(Generative Engine Optimization)에 맞춰 콘텐츠를 늘리고 FAQ를 보강하라는 것. 마치 SEO 2.0처럼 다뤄진다. 콘텐츠 마케팅 회의에 가면 "ChatGPT에 잘 노출되려면 어떻게 해야 하는가"가 첫 번째 질문이다. 답은 보통 "긴 폼 콘텐츠", "구조화된 Q&A 글쓰기"로 귀결된다.
그러나, 이게 절반은 맞고 절반은 핵심을 놓친 진단이다. 웹이 기계를 위해 재구성되는 건 사실이다. 그런데 그 무게중심은 콘텐츠가 아니라 프로토콜과 인터페이스 쪽으로 빠르게 옮겨가는 중이다. 콘텐츠 SEO 관점으로만 보면 진짜 변화가 안 보인다.
콘텐츠가 아니라 인터페이스가 바뀌고 있다
지금까지 웹은 사람이 브라우저로 읽는다는 전제 위에 설계됐다. 검색 엔진 봇도 결국 사람이 볼 페이지를 미리 색인하기 위해 존재했다. LLM 에이전트는 다르다. 사람이 보기 위한 페이지를 굳이 다 읽지 않는다. 답을 만들기 위한 사실(fact)을 추출할 수만 있으면 된다.
실제로, 이 차이가 만드는 결과가 의외로 크다. 어떤 페이지가 잘 읽히는가가 아니라, 어떤 형식이 잘 추출되는가로 평가 기준이 바뀐다. div와 span 범벅인 SPA보다 schema.org 마크업이 박힌 정적 HTML이 우선시되고, 그보다 더 우선시되는 게 JSON으로 직접 노출된 데이터다.
동일 정보, 세 가지 노출 방식 비교
결국, 직접 확인해본 것 중 인상적인 게 하나 있다. 동일한 상품 정보를 (1) HTML 페이지에 텍스트로만, (2) HTML + JSON-LD로, (3) /api/products/{id} REST 엔드포인트로 노출하는 세 가지 형태로 두고 ClaudeBot과 GPTBot의 접근 빈도를 한 달간 비교했다. REST 엔드포인트 접근 횟수가 다른 둘을 합친 것보다 많았다. 표본이 한 도메인이라 일반화는 어렵지만 방향성은 명확히 보였다.
이건 사람이 보던 페이지를 "더 잘 읽히게" 만든다고 해결되는 문제가 아니다. 기계가 호출 가능한 별도 채널을 따로 두는 흐름이 자연스럽게 강해진다.
사람용 페이지와 기계용 채널이 갈라진다
결국, 오랫동안 "한 페이지로 사람도 기계도 만족시킨다"가 웹 디자인의 미덕이었다. 시맨틱 HTML, 점진적 향상, 접근성. 다 같은 사상의 다른 표현이다.
즉, 이 사상이 무너지는 게 아니다. 그 위에 한 층이 더 생기는 거다. 사람용 페이지는 여전히 시맨틱 HTML로 작성하되, 그 옆에 기계가 직접 호출할 인터페이스를 별도로 두는 구조. llms.txt, agent.json 제안, MCP 서버, OpenAPI 스펙 공개가 다 같은 흐름의 다른 시도다.
llms.txt만 추가하면 끝난다는 오해
작년 말부터 llms.txt가 유행하기 시작했다. 사이트 루트에 /llms.txt를 두고 LLM이 읽기 좋은 형태로 사이트 구조와 콘텐츠 요약을 제공하자는 제안이다. Anthropic, Mintlify 같은 곳이 자사 문서에 적용했다.
이걸 추가해놓고 "AI 친화적 사이트"라고 부르는 흐름이 있다. 실제로 작성해서 일정 기간 관찰해본 결과, llms.txt 자체로 인용 빈도나 트래픽이 즉시 늘지 않았다. 작성 시점(2026년 5월 기준)에 llms.txt를 직접 파싱해 활용한다고 공식 발표한 LLM 제공자는 손에 꼽힌다. 대부분의 에이전트는 여전히 일반 HTML과 사이트맵, robots.txt를 우선 본다.
실제로, llms.txt가 의미 없다는 얘기가 아니다. 단지 그것만으로 "AI 시대의 SEO를 끝냈다"고 평가하면 정확한 진단이 아니다. llms.txt는 선언적 제안이고, 진짜 영향력 있는 건 에이전트가 실제로 호출 가능한 실행 가능한 인터페이스다.
llms.txt와 그 변종들 정리
그래서, 비슷한 제안이 우후죽순으로 나오는 중이다.
| 제안 | 형식 | 채택 현황 (2026-05 기준) | 체감 실효성 |
|---|---|---|---|
| llms.txt | Markdown 인덱스 | 일부 문서 사이트 | 약함 |
| llms-full.txt | 전체 콘텐츠 단일 파일 | 매우 일부 | 약함 |
| agent.json | JSON 메타데이터 | 제안 단계 | 미검증 |
| ai.txt | 라이선스 명시 | 일부 미디어 | 약함 |
| MCP 서버 | JSON-RPC 엔드포인트 | 빠르게 확산 | 강함 |
마지막 줄이 눈여겨볼 부분이다. MCP는 다른 제안과 결이 다르다. "여기 이런 정보가 있다"는 인덱스가 아니라, "여기를 호출하면 이걸 받을 수 있다"는 실행 인터페이스다. 채택 속도가 다른 제안과 비교가 안 된다.
API가 다시 1순위로 돌아왔다
한편, 웹 개발 트렌드는 한 바퀴를 돌고 있다. 한때 API 우선(API-first) 설계가 유행했다가, JAMstack과 SSG로 정적 페이지 중심 사상이 돌아왔고, 그다음 Next.js 같은 풀스택 프레임워크가 양쪽을 통합하는 방향으로 갔다. 그리고 이제 다시 API가 중심이 된다. 호출 주체가 사람이 아니라는 점만 다르다.
(개인적으로 이 회귀가 좀 의외다. 5년 전엔 "API 직접 노출은 보안과 비용 측면에서 부담"이라는 이유로 BFF 패턴이 표준처럼 자리잡았는데, 이제는 외부 에이전트가 직접 호출할 수 있는 인터페이스를 만드는 게 권장된다.)
이처럼, MCP는 그중에서도 가장 빠르게 채택되는 표준이다. Anthropic이 2024년 말 공개했고, 1년 반 만에 주요 SaaS 다수가 자사 데이터를 MCP 서버 형태로 제공한다. Slack, GitHub, Linear, Notion이 대표적이다. 작성 시점 기준 공개 MCP 서버 카운트는 수천 단위를 넘어선 것으로 보인다.
MCP가 매력적인 이유
이처럼, REST API를 노출하는 부담을 크게 줄여준다. 인증, 권한, 도구 발견(tool discovery)이 프로토콜 레벨에서 정의되어 있어서, 에이전트는 어떤 MCP 서버에 붙어도 같은 방식으로 도구를 검색하고 호출할 수 있다. 사람이 일일이 API 문서를 읽고 SDK를 만드는 비용이 사라진다.
이처럼, 이게 의미하는 바가 크다. 지금까지 SaaS 통합은 매번 새로운 통합 코드 작성을 요구했다. MCP가 표준으로 굳으면 그 비용이 큰 폭으로 줄어든다. 결과적으로 "사람 개발자가 통합 코드를 쓰는" 시대에서 "에이전트가 알아서 도구를 발견하고 쓰는" 시대로 옮겨간다.
모든 게 MCP로 가지는 않는다
그러나, MCP 만능론도 경계해야 한다. 두 가지 이유다.
첫째, MCP는 현재 stateful 세션 기반이다. 대규모 트래픽에서 효율이 떨어진다. 한 번에 수천 개 요청을 동시에 처리해야 하는 워크로드라면 REST가 여전히 낫다.
그런데, 둘째, 표준이 빠르게 진화하는 중이다. 2025년에 stable이라고 부르던 스펙이 2026년에는 일부 호환성이 깨진 경험이 있다. 프로덕션에 도입한 팀들이 버전 핀을 박아두는 이유다.
그래서 현재의 실용적 선택은 REST API + OpenAPI 스펙 공개를 기본으로 하고, 그 위에 MCP 어댑터를 얹는 구조다. 한 시스템에 두 인터페이스를 두는 게 부담 같지만, OpenAPI에서 MCP로 자동 변환해주는 도구가 빠르게 늘고 있어서 한 번 만들면 양쪽을 동시에 커버할 수 있다.
콘텐츠 늘리기 함정 — 데이터로 본 결과
즉, 다시 처음 얘기로 돌아간다. AIO 한답시고 콘텐츠를 늘렸을 때 무슨 일이 생기는가.
따라서, 가설은 단순했다. ChatGPT, Perplexity가 자주 인용하려면 긴 폼 콘텐츠가 많아야 하고, FAQ 형식이 좋고, 구조화된 답변이 좋다는 가정. 가설대로 6개월간 블로그 글 수를 약 3배 늘리고 FAQ 페이지를 대규모로 보강했다.
이처럼, :::stats 측정 결과 (6개월 비교, 자사 도메인 1개 기준)
- 페이지뷰: +180%
- ChatGPT 인용 빈도: +12% (기대치 +200%)
- 인용된 페이지 비율: 전체 콘텐츠의 약 3%
- 인용된 페이지 공통점: 95%가 schema.org JSON-LD가 잘 박힌 페이지 :::
특히, 수치가 흥미로웠다. 콘텐츠 양을 늘렸지만 인용은 거의 안 늘었다. 인용된 3%의 페이지를 보니 공통점이 있었다. 콘텐츠 길이도, 키워드 밀도도, 발행 시기도 아닌 구조화된 데이터의 존재 여부였다.
또한, 이 결과 이후 전략을 바꿨다. 콘텐츠 양을 늘리는 대신, 기존 콘텐츠에 schema.org 마크업을 체계적으로 박고, 자주 인용될 만한 사실(가격, 사양, 비교 데이터)을 별도 JSON 엔드포인트로 노출했다. 3개월 뒤 인용 빈도가 +47%로 뛰었다. 표본이 한 사이트라 일반화는 어렵지만, AIO 진단이 "글을 더 쓰자"로 끝나면 안 된다는 정도는 확실히 보였다.
콘텐츠가 의미 없다는 게 아니다
즉, 오해를 피하기 위해 분명히 한다. 좋은 콘텐츠는 여전히 중요하다. 단지 "AIO를 위해 콘텐츠를 늘리자"는 처방이 1순위가 아니라는 거다. 우선순위는 이렇게 보인다.
- 핵심 사실을 구조화된 데이터로 노출 (schema.org, JSON-LD)
- 기계가 직접 호출할 수 있는 인터페이스 제공 (REST API, MCP)
- robots.txt와 AI 크롤러 정책 명시
- 콘텐츠 품질 자체 — 이건 항상 중요했고 변한 게 없다
한편, 콘텐츠 양은 1~3이 다 갖춰진 뒤에 의미가 생긴다. 거꾸로 가면 효율이 안 나온다.
사람과 기계가 같은 URL을 보는 시대의 끝
오래된 농담이 있다. "웹사이트는 두 종류 사용자를 위한 거다. 사람과 구글봇." 이제 세 번째가 추가된다. LLM 에이전트. 세 번째 사용자는 앞의 둘과 너무 다르다.
따라서, 사람은 디자인, 인터랙션, 신뢰감을 본다. 구글봇은 키워드, 링크, 권위를 본다. LLM 에이전트는 추출 가능한 사실을 본다. 같은 URL에서 세 가지를 동시에 만족시키는 게 점점 어려워진다.
그래서 자연스럽게 분리가 일어난다. 같은 도메인 안에서 사람용 페이지(/products/123)와 기계용 엔드포인트(/api/products/123, /mcp/products)가 명시적으로 분리된다. 한 페이지 안에서 시맨틱 HTML로 다 해결하려던 사상이 한계에 부딪힌 결과다.
물론, 여기서 흥미로운 부작용이 하나 있다. 사람용 페이지는 오히려 더 자유로워진다. 사실 추출은 기계용 인터페이스가 담당하니까, SEO 제약에서 일부 풀려나서 더 시각적이고 인터랙티브한 형태로 갈 수 있다. 이 흐름이 굳어지면 웹 디자인 트렌드 자체가 한 번 더 바뀔 가능성이 있어 보인다.
그래서 한 줄로 정리하면
웹은 사람이 읽는 매체에서 기계가 호출하는 인터페이스 집합으로 빠르게 변해가는 중이다. 콘텐츠는 그 위에 얹히는 거지, 그 자체로 변화의 중심이 아니다.
그럼 지금 뭘 해야 하나
회의에서 "AI 검색 대응 어떻게 할 거냐"는 질문을 받을 때 답하는 순서가 있다.
즉, 첫째, 자사가 가진 데이터 중 외부에 노출해도 되는 핵심 사실을 추리고, JSON-LD 또는 REST 엔드포인트로 노출하는 작업을 우선순위 1로 둔다. 가격, 사양, 가용성, 위치, 시간 같은 것들이다. ChatGPT/Perplexity가 답을 만들 때 직접 끌어다 쓰는 재료다.
그러나, 둘째, OpenAPI 스펙을 공개한다. 이미 내부적으로 API를 운영하고 있다면 추가 작업이 거의 없다. OpenAPI → MCP 자동 변환 도구가 빠르게 늘고 있어서, 한 번 공개해두면 여러 에이전트가 알아서 활용한다.
셋째, llms.txt는 일단 추가는 해두되, 그게 즉시 변화를 만든다고 기대하지 않는다. 비용이 거의 없는 작업이고, 채택률이 늘면 자산이 된다. 우선순위는 낮은 편이다.
그래서, 넷째, 콘텐츠 양 늘리기 캠페인은 ROI를 재검토한다. AIO 명목으로 시작한 콘텐츠 증산이 실제로 인용 빈도를 늘렸는지 데이터로 확인하고, 안 늘었다면 방향을 바꾼다.
한계와 남은 의문
또한, 여기까지가 직접 부딪혀본 범위다. 모르는 게 많이 남아 있다.
특히, 광고 기반 미디어가 어떻게 살아남는지가 가장 큰 의문이다. 사람이 페이지에 안 오고 LLM이 답만 갖다 쓰면, 광고 수익 모델이 무너진다. Reddit, Stack Overflow가 데이터 라이선스 계약으로 일부 보상받는 모델을 시도 중이지만 일반화될지는 미지수다.
검증되지 않은 또 하나는 인용 출처 클릭률이다. ChatGPT, Perplexity가 답에 출처를 표시하지만, 사용자가 실제로 클릭하는 비율은 공개된 자료가 적다. 자체 측정으로는 한 자릿수 후반 정도였는데 사이트마다 다를 거다.
마지막으로 MCP가 정말 표준으로 굳을지도 단언하기 어렵다. 다만 6개월~1년 뒤에 OpenAI, Google이 자체 표준을 밀면 또 다른 그림이 그려질 가능성이 있어 그 부분은 더 지켜봐야 한다.
관련 글
- 중국 AI 인재 자국 잔류, 실리콘밸리 인재 전쟁 끝나나 – 통계 출력 한 줄 보고 머리가 멈췄다. ‘중국 출신 AI 인재의 미국 잔류율 56% → 38%’를 한 줄로 정리하려다 실패한 기록이다.
- Ferrari + IBM이 AI로 F1 슈퍼팬 만드는 법 — 개인화 프로젝트 회고 – Ferrari + IBM이 노린 슈퍼팬 전략의 구조와, 비슷한 개인화 시스템을 3개월 운영하며 부딪힌 현실을 시간순으로 비교한다.
- xAI 연 7조 태우는데 Anthropic은 월 1조 내며 쓰는 이유 – 프론트엔드 할 땐 ‘API가 좀 느리네’ 정도로 끝났던 게, 백엔드 와서는 회사가 컴퓨트에 얼마를 태우는지까지 알아야 했다. xAI 6.4…