AI 에이전트가 못 찾는 앱은 없는 앱과 비슷하다

사람이 앱을 쓰려면 먼저 검색하거나 추천받고, 설명을 읽어 이해한 뒤, 화면에서 행동할 수 있어야 한다. AI 에이전트도 순서는 비슷하다. 다만 화면을 보는 대신 공개 문서와 HTML 구조를 읽고, API나 도구 호출로 행동한다.

Edmund Yong은 AI 시대에 앱을 최적화하는 방법을 세 질문으로 정리한다. 에이전트가 앱을 찾을 수 있는가, 무엇을 하는지 이해할 수 있는가, 실제로 사용할 수 있는가. 그는 이를 findable, legible, usable로 나눈다.

찾을 수 있다는 말은 검색 결과에 뜬다는 뜻보다 넓다

첫 단계는 제품의 공개 설명을 분명하게 만드는 일이다. 어떤 고객이 어떤 작업에 쓰고, 무엇과 연결되며, 어떤 결과를 얻는지 랜딩페이지에 적는다. “업무를 혁신하는 AI”처럼 대상을 숨긴 문구는 사람에게도 모호하고 검색 시스템에도 분류할 단서가 적다.

Yong은 페이지가 HTTP 200을 반환하는지, robots.txt가 필요한 수집기를 막는지, sitemap에 홈·가격·문서 페이지가 들어 있는지를 먼저 확인하라고 한다. 여기서 모든 AI 봇을 허용해야 한다는 결론은 나오지 않는다. 검색 노출, 학습 수집, 저작권, 서버 비용을 구분한 뒤 허용 범위를 정해야 한다. 중요한 것은 의도하지 않은 차단과 의도한 정책을 구별하는 것이다.

읽을 수 있는 화면은 구조가 역할을 말한다

두 번째 단계는 페이지가 자기 구조를 설명하게 만드는 일이다. 버튼은 button, 이동은 링크, 입력은 form, 제목은 heading으로 표현한다. MDN의 semantic HTML 설명처럼 알맞은 요소는 코드에 역할을 남기고, 검색엔진과 보조기술이 구조를 해석하는 단서가 된다.

semantic HTML만 쓴다고 에이전트가 제품을 정확히 이해하는 것은 아니다. 시작 방법, 주요 흐름, 자주 나는 오류, 입력과 결과의 예시가 담긴 짧은 문서가 함께 있어야 한다. 화면의 구조와 제품의 설명은 서로 다른 층이다.

사용 가능성은 인터페이스보다 권한에서 갈린다

마지막 단계에서 Yong은 API, CLI, MCP를 후보로 든다. API는 외부 시스템이 핵심 동작을 호출하게 하고, CLI는 터미널에 익숙한 사용자의 작업을 줄인다. MCP 서버는 에이전트가 발견하고 호출할 도구의 이름과 입력 구조를 제공한다. MCP 공식 구조도 서버가 도구·리소스·프롬프트를 노출하고 호스트가 권한과 연결을 통제하는 형태로 설명한다.

인터페이스를 하나 더 만들면 공격 표면도 하나 늘어난다. 처음부터 제품 전체를 열기보다 외부 사용 가치가 큰 한두 동작만 고르고, 인증, 입력 검증, rate limit, 실행 기록, 오류 복구를 붙여야 한다. 사람용 화면과 에이전트용 도구가 서로 다른 데이터 규칙을 가지면 제품 로직도 두 벌이 된다.