당신 SaaS의 진짜 고객이 더 이상 사람이 아니라면, 지금 만들고 있는 그 예쁜 랜딩 페이지는 누가 봐주나요? AI 에이전트는 당신의 UI를 한 번도 보지 않아요. 에이전트가 읽는 건 딱 하나, 당신 도구의 description과 schema예요. 거기서 "이 작업엔 이 도구"라는 판단이 끝나면, 나머지는 쳐다보지도 않고 다음 도구로 넘어가요.
그러니까 이 글은 "에이전트 시대가 온대요" 같은 전망이 아니에요. 오늘 당장 당신 서비스의 description을 어떻게 고쳐 써야 에이전트가 당신을 고르는지, 손으로 바꿀 수 있는 5가지를 정리한 거예요. SEO를 처음 배우던 그날처럼, 지금이 그 출발선이에요.
SEO 1페이지가, 어느 날 의미가 없어지는 순간
시나리오 하나 그려볼게요. 당신은 몇 년을 갈아서 "이메일 마케팅 도구" 키워드로 Google 1페이지에 올랐어요. 그런데 2026년의 고객은 검색창을 열지 않아요. 대신 에이전트한테 이렇게 말하죠. "우리 뉴스레터 보낼 최적의 도구 찾아서 연동해줘."
이 순간 당신의 SEO 순위는 게임에서 빠져요. 에이전트는 Google 결과를 스크롤하는 대신, 자기가 접근 가능한 도구 목록(MCP 서버, API 카탈로그)에서 고르거든요. YC가 "에이전트 경제(Agent Economy)"라고 부른 게 바로 이 변화예요. 발견의 주체가 사람에서 에이전트로 넘어가는 것.
지금까지 SaaS의 발견(discovery)은 전부 "사람의 눈"에 보이려는 싸움이었어요. SEO, 카피, 입소문, 광고 — 다 사람용이었죠. 그런데 에이전트가 자율적 경제 행위자가 되면서, 이 전제가 통째로 무너지고 있어요.
에이전트는 이렇게 도구를 고른다 (그리고 당신을 탈락시킨다)
에이전트의 선택 과정은 의외로 단순하고, 그래서 더 냉정해요.
- 사용 가능한 도구 목록(MCP 서버, API 카탈로그 등)을 스캔
- 각 도구의 description, schema, 예시를 읽음
- 현재 작업에 가장 적합한 도구를 선택
- 실행 → 결과 평가 → 안 맞으면 미련 없이 다른 도구로 전환
2번에서 모든 게 결정돼요. 랜딩 페이지가 아무리 예뻐도, 가격이 아무리 착해도, tool description이 모호하면 그 순간 탈락이에요. a16z의 Yoko Li는 MCP 딥다이브에서 이걸 한 문장으로 정리했어요 — "개발자 중심 회사의 경쟁력이 '최고의 API 설계'에서 '에이전트를 위한 최고의 도구 컬렉션'으로 진화할 것"이라고요.
이게 왜 단순한 기술 트렌드가 아니라 비즈니스 모델 자체의 이동인지는, 항목별로 나란히 놓으면 분명해져요.
| 관점 | 기존 (사람 대상) | 에이전트 시대 |
|---|---|---|
| 발견 방식 | Google SEO, 광고, 입소문 | MCP 레지스트리, tool description, llms.txt |
| 선택 기준 | UI/UX, 브랜드, 가격 | description 명확성, schema 정합성, 응답 속도 |
| 통합 방식 | 사람이 직접 설정 | 에이전트가 자동 연결 (MCP) |
| 가격 모델 | 시트 기반 / 구독 | API 호출 기반, 에이전트가 가성비 비교 |
| 문서의 역할 | 사람이 읽는 참고자료 | 에이전트가 이해하는 실행 지침 |
표의 왼쪽이 지금까지 당신이 투자해온 세계고, 오른쪽이 고객의 다음 행동이 일어나는 세계예요. 그리고 이건 먼 미래가 아니에요. Vercel은 이미 AEO(AI Engine Optimization) 트래킹 시스템을 만들어서, 코딩 에이전트들이 Vercel을 얼마나 발견하고 추천하는지를 추적하고 있어요. 초기 데이터로는 코딩 에이전트의 약 20%가 웹 검색을 수행하고, 그 결과를 근거로 도구를 추천해요. The New Stack은 이 흐름을 아예 "에이전트 SEO의 골드러시"라고 불렀고요. 2000년대 초 다들 SEO에 뛰어들던 그 장면이, 지금 에이전트를 두고 반복되고 있는 거예요.
그래서 오늘 무엇부터 누르면 되나 — 실전 5단계
흐름을 구경만 하면 남는 게 없어요. 아래 5가지는 순서대로 손볼 수 있는 실전 항목이에요. 위에서부터 하나씩 적용하면 돼요.
- Tool Description부터 다시 쓰기 (가장 효과 큰 한 방)
에이전트가 도구 선택 때 가장 먼저, 그리고 가장 중요하게 읽는 게 description이에요. "이메일 발송 도구입니다" 같은 건 즉시 탈락이에요. 대신 "마케팅 이메일을 HTML 템플릿으로 작성하고, 수신자 리스트에 스케줄링된 시간에 발송합니다. 오픈율 추적과 A/B 테스트를 지원합니다"처럼, 에이전트가 '언제, 왜 이 도구를 써야 하는지' 스스로 판단할 수 있는 수준으로 구체적으로 쓰세요. - API를 에이전트 친화적으로 재설계
API와 tool은 1:1이 아니에요.send_email()하나보다draft_email_and_send()처럼 에이전트가 한 번의 호출로 작업을 끝낼 수 있는 고수준 액션이 훨씬 잘 선택돼요. 에이전트는 최소 호출로 결과를 얻고 싶어하거든요. JSON schema도 필수 필드·옵션 필드·예시를 빠짐없이 채워서 명확하게. - llms.txt 파일 깔기 (robots.txt의 AI 버전)
llms.txt는 LLM·에이전트용 robots.txt예요. 사이트 루트에 올려두면 모델이 당신 서비스를 더 정확히 이해해요. 서비스 설명, 주요 기능, API 엔드포인트 요약을 기계가 읽기 좋은 포맷으로 정리하세요. - MCP 서버 제공 + 마켓플레이스 등록
MCP(Model Context Protocol)는 모델이 외부 도구를 호출하는 표준 프로토콜이에요. 서비스에 MCP 서버를 만들어두면 Cursor, Claude Desktop 같은 클라이언트에서 바로 잡혀요. 여기에 Smithery, mcpt 같은 MCP 마켓플레이스에 등록하면 발견 가능성이 한 단계 더 올라가요. - AEO 추적 시작 (description A/B의 기반)
에이전트가 당신 도구를 얼마나 자주 발견·사용하는지 측정하세요. Vercel처럼 전용 시스템을 만들 수도 있지만, 가볍게는 API 로그에서 User-Agent가 에이전트인 요청을 필터링하는 것부터면 충분해요. 측정이 되면 "어떤 description이 선택을 유도하는지" A/B 테스트도 돌릴 수 있어요.
"에이전트 SEO"의 핵심 원칙 한 줄
HN 토론에서 나온 인사이트 — 같은 description이라도 모델마다 반응이 달라요. Claude, GPT, Gemini가 각자 다른 기준으로 도구를 평가하거든요. 그러니 한 description으로 모든 모델을 만족시키려 머리 싸매기보다, 핵심 기능을 명확하고 구체적으로 쓰는 게 결국 모든 모델에 두루 먹혀요.
단, MCP는 아직 초기 단계예요
인증, 권한 관리, 멀티테넌시 같은 핵심이 아직 표준화되지 않았어요. MCP 서버를 프로덕션에 올리기 전 보안 검토는 필수고, 현재 대부분의 MCP 서버가 로컬 우선(local-first)이라 원격 배포 시엔 추가 인프라 설계가 필요해요. "먼저 깃발 꽂기"는 좋지만, 보안 없이 꽂으면 안 돼요.
