AI 에이전트가 처리할 수 있는 SEO

여러 페이지 그룹에서 유기적 트래픽(organic traffic)을 잃은 것을 발견했습니다. SEO 대시보드를 열고, 보고서를 필터링하고, 결과를 내보낸 다음, AI 어시스턴트에 붙여넣어 무슨 일이 있었는지 질문합니다. 그런 다음 저장소(repository)를 열어 최근 출시가 해당 페이지들을 변경했는지 확인합니다.

조사가 시작되기도 전에 여러 시스템 간의 맥락(context)을 가지고 작업하고 있습니다.

SEO는 프로젝트를 구축하고 유지하는 환경에서 사용 가능해야 합니다. 에이전트에게 문제 조사를 요청하고, 관련 증거에 접근할 수 있게 하며, 그것이 제안하는 내용을 검토할 수 있어야 합니다.

이것이 바로 SEO MCP가 중요한 이유입니다. 이는 SEO 도구와 AI 에이전트 사이에 실질적인 연결을 만들어주기 때문에, 검색 성능 작업을 시작하기 위해 또 다른 대시보드에서 시작할 필요가 없습니다.

대시보드는 선택 사항이어야 한다

대시보드는 무엇이 변경되었는지 보여줄 수 있습니다. 하지만 그 변화를 이해하는 것은 종종 다른 곳의 정보가 필요합니다: 페이지 자체, 템플릿, 출시 기록, 또는 비즈니스 결정일 수 있습니다.

연결된 워크플로우에서는 요청이 작업이 발생하는 곳에서 시작될 수 있습니다:

어떤 페이지들이 유기적 트래픽을 잃었는지, 변화를 설명할 수 있는 증거는 무엇인지, 그리고 무엇부터 조사해야 할까요?

에이전트는 접근할 수 있도록 허가된 데이터를 검색하여 검사할 수 있는 조사를 반환합니다. 각 보고서가 어떤 메뉴에 들어있는지 알거나 동일한 URL을 세 가지 도구에 수동으로 복사할 필요가 없습니다.

차트(Charts)는 여전히 사람들이 패턴을 탐색하고 결과를 전달하는 데 도움이 됩니다. 하지만 별도의 애플리케이션을 여는 것은 답변을 얻기 위한 필수 조건이 아니라 선택이어야 합니다.

일상적인 SEO 작업의 경우, 인터페이스 자체가 이미 사용하고 있는 에이전트가 될 수 있습니다. 이 경우 제품의 가치는 대시보드를 방문하지 않더라도 데이터와 기능의 품질에 달려 있게 됩니다.

MCP가 SEO에 실제로 변화시키는 것

Model Context Protocol은 AI 애플리케이션을 외부 데이터 및 도구에 연결하기 위한 개방형 표준입니다.

SEO를 위해 서버는 키워드 순위 검색 결과를 가져오거나, 크롤링 발견 사항을 검사하거나, 검색 성능에 대한 쿼리를 노출할 수 있습니다. 호환 가능한 에이전트는 이러한 작업을 발견하고 요청과 관련된 작업들을 호출할 수 있습니다.

여기에는 세 가지 구별되는 역할이 있습니다:

• SEO 도구는 데이터를 공급하고 기능을 노출합니다.
• MCP는 에이전트가 이를 발견하고 사용할 수 있는 연결을 제공합니다.
• 에이전트는 결과를 해석하고 다음에 무엇을 조사할지 결정합니다.

MCP 자체는 트래픽 감소를 진단하지 않습니다. 또한 서버가 필요한 모든 보고서를 제공한다는 보장도 하지 않습니다. 사용 가능한 작업, 계정 권한, 데이터 범위가 에이전트가 실제로 할 수 있는 일을 결정합니다.

유용한 변화는 SEO 데이터가 작업을 수행하는 동안 접근 가능해진다는 것입니다. 더 이상 대시보드를 스프레드시트로 변환하고 그 스프레드시트를 프롬프트로 변환할 필요가 없습니다.

SEO가 '사고'한다는 것의 의미

보고서는 클릭이 감소했다고 알려줄 수 있습니다. 유용한 조사는 무엇이 else 변경되었는지 묻습니다.

노출(impressions)도 감소했나요? 노출은 비교적 안정적인데 클릭률(click-through rate)이 변했나요? 영향을 받은 페이지가 하나의 템플릿에 집중되어 있나요? 시기가 출시와 겹치나요?

그러한 질문들은 다른 다음 단계를 이끌어냅니다. 클릭 수만 반복하는 도구는 그 작업을 사용자에게 남겨둡니다.

제가 SEO가 '사고'할 수 있어야 한다고 말할 때, 저는 에이전트가 조사를 수행해야 한다고 의미합니다: 가설을 형성하고, 관련 증거를 요청하며, 설명을 비교하고, 무엇이 여전히 불확실한지 보여주는 것입니다. 추론은 도구가 반환하는 데이터에 근거하여 에이전트에 속합니다.

또한 정직한 답변으로 멈출 수 있어야 합니다: 아직 충분한 증거가 없습니다.

실시간 데이터에 대한 접근성은 조사를 가능하게 하지만, 모든 결론을 정확하게 만드는 것은 아닙니다. 트래픽 감소 근처에서 발생한 출시는 단서일 뿐, 그 출시가 원인이라는 증거는 아닙니다.

기대되는 결과는 사람이 의문을 제기할 수 있을 만큼 충분한 증거를 갖춘, 더 잘 뒷받침된 다음 행동입니다.

SEO가 프로젝트의 일부가 되다

SEO 보고서는 URL에 대해 알고 있습니다. 사용자의 리포지토리는 해당 URL이 어떻게 생성되는지 알고 있습니다.

이러한 관점들을 결합하면 문제를 조사하기 더 쉬워질 수 있습니다. 여러 개의 영향을 받는 페이지들이 동일한 레이아웃을 공유할 수 있습니다. 메타데이터 변경은 하나의 컴포넌트에서 비롯될 수 있습니다. 리디렉션(redirect)은 각 페이지에 작성되기보다는 라우팅 규칙(routing rule)에 의해 생성될 수 있습니다.

적절한 접근 권한만 있다면, AI 코딩 에이전트는 SEO 증거와 함께 해당 프로젝트 컨텍스트를 검토할 수 있습니다. 일반적인 추천을 제공하는 대신, 제안된 변경 사항이 어디에 속해야 하는지 식별하고 어떤 페이지에 영향을 미칠 수 있는지 설명해 줄 수 있습니다.

이를 위해서는 별도의 기능이 필요합니다. SEO MCP 서버를 연결한다고 해서 에이전트가 사용자의 코드, CMS 또는 Git 히스토리에 자동으로 접근할 수 있는 것은 아닙니다. 이러한 리소스들은 에이전트의 기존 환경이나 다른 승인된 통합을 통해 제공되어야 합니다.

이러한 구분은 중요합니다. 유용한 SEO 자동화는 양쪽 모두에 대한 컨텍스트가 필요하기 때문입니다. 즉, 검색 데이터가 무엇을 시사하는지 그리고 애플리케이션이 실제로 어떻게 작동하는지에 대한 정보가 필요합니다. 보고서만으로는 후반부를 스스로 공급할 수 없습니다.

트래픽 감소에서 검토 가능한 수정 사항까지

검색 성능(search performance), 크롤링 결과(crawl results), 리포지토리 접근 권한을 가진 에이전트 환경에서의 가상 조사를 고려해 봅시다:

지난 4주 동안 유기적 트래픽을 잃은 페이지를 조사하세요. 동등 기간과 비교하고, 공유되는 패턴을 찾고, 관련 코드 변경 사항을 확인하세요. 패치를 제안하기 전에 증거를 설명하세요. 아무것도 배포하지 마세요.

에이전트는 먼저 속성(property), 날짜 및 필터를 확인합니다. 사용 가능한 데이터가 요청된 비교를 지원할 수 없다면, 그렇게 말합니다.

다음으로, 영향을 받는 페이지들을 그룹화하고 감소세가 광범위한지 아니면 집중적인지 확인합니다. 만약 영향을 받은 URL들이 동일한 템플릿을 공유한다고 가정해 봅시다. 렌더링된 페이지를 검사하면 해당들의 카노니컬 링크(canonical link)가 관련 없는 카테고리 페이지를 가리키고 있으며, 최근의 diff를 통해 그러한 동작이 어디에서 도입되었는지 알 수 있습니다.

이것은 템플릿을 조사해 볼 이유입니다. Google의 canonicalization guidance는 canonical 주석이 선호되는 URL을 어떻게 전달하는지 설명하지만, 이는 Google이 반드시 따라야 하는 명령이라기보다는 신호에 불과합니다.

에이전트는 집중적인 diff를 제안하고 동일한 템플릿을 사용하는 다른 페이지들을 식별합니다. 사용자는 의도된 canonical URL들이 정확한지 검토한 후 배포 승인을 합니다.

배포 후, 관련 페이지들은 다시 가져오거나 크롤링하여 그 결과를 확인할 수 있습니다. 검색 성능은 나중에 별도로 평가됩니다.

산출물은 증거 추적(evidence trail), 검토 가능한 변경 사항, 그리고 검증 단계입니다. 이 예시의 어떤 것도 트래픽 복구를 보장하지 않으며, 그 어느 것 하나 보고서를 코딩 환경으로 수동으로 옮기는 것에 의존하지 않습니다.

왜 MCP 지원이 표준 기능이 되어야 하는가

SEO 도구가 에이전트 워크플로우에 참여하기를 원한다면, 저는 이제 MCP 지원을 핵심 제품 기대치로 간주할 것입니다.

개발자들은 모든 워크플로우마다 별도의 사용자 정의 통합(custom integration)을 구축하지 않고도 호환 가능한 클라이언트에서 그 기능을 사용할 수 있어야 합니다. 직접적인 API는 에이전트를 도구에 연결할 수도 있습니다. MCP는 이러한 기능들이 호환되는 환경 전반에 걸쳐 발견 가능하도록 만드는 공유 인터페이스를 제공합니다.

유용한 SEO MCP는 다음을 제공해야 합니다:

• 문서화된 입력과 예측 가능한 출력을 가진 명확한 작업(operation).
• 날짜, 필터, 단위, 소스 신선도 등을 포함하는 데이터 컨텍스트(Data context).
• 결과를 검색할 수 없을 때의 명시적인 사용 불가 상태(unavailable states).
• 데이터 읽기 권한과 변경 권한을 구별하는 권한(Permissions).
• 부분 응답이 완전한 분석으로 오해되지 않도록 하는 명확한 페이지네이션 및 사용 제한.

이 프로토콜은 발견 가능한 도구와 스키마를 지원합니다. SEO 제품들은 여전히 그 주변으로 의미 있는 작업과 응답을 설계해야 합니다.

대시보드에 채팅 상자를 추가하는 것만으로는 이 필요를 충족할 수 없습니다. 기능들은 개발자가 이미 사용하는 에이전트가 접근할 수 있어야 하며, 결과를 올바르게 해석하기에 충분한 컨텍스트가 제공되어야 합니다.

오직 인간의 탐색(navigation)만을 중심으로 구축된 제품은 또 다른 중요한 사용자를 문 밖에 남겨두기 쉽습니다. 바로 그 인간의 지침에 따라 작동하는 에이전트입니다.

여전히 인간이 결정을 소유한다

SEO를 에이전트에 통합하는 목적은 질문과 유용한 결정 사이의 작업을 줄이는 것입니다.

사람들이 여전히 목표를 정의합니다. 한 비즈니스는 총 방문자 수보다 적격 리드(qualified leads)에 더 관심을 가질 수 있습니다. 제안된 콘텐츠 변경 사항은 키워드 커버리지를 개선할 수는 있지만, 독자에게는 페이지의 유용성을 떨어뜨릴 수도 있습니다. 에이전트는 그러한 컨텍스트가 필요하며, 누군가가 그 트레이드오프(tradeoff)를 판단해야 합니다.

결과적인 변경 사항들 역시 명확한 경계가 필요합니다. 보고서를 읽고, diff를 제안하고, 콘텐츠를 게시하고, 코드를 배포하는 것은 서로 다른 행동입니다. 하나에 대한 접근 권한이 나머지 모든 것에 대한 권한을 암묵적으로 의미해서는 안 됩니다.

좋은 워크플로우는 증거(evidence)와 제안된 변경 사항들을 검토하기 쉽게 만듭니다. 이는 추천을 거부하거나, 또 다른 비교를 요청하거나, 사용 가능한 데이터가 불충분하다고 결정할 여지를 남겨둡니다.

앞서 언급한 예시의 개발자에게 이것은 도구들 사이에서 파일을 옮기는 대신 문제에 머무르는 것을 의미합니다. 에이전트는 관련 증거를 프로젝트로 가져와 조사하는 데 도움을 주고, 사용자가 검사할 수 있는 결정을 남깁니다.

이것이 SEO 도구가 나아가야 할 방향입니다: 작업이 발생하는 어디에서든 사용할 수 있는 신뢰할 수 있는 기능들. 대시보드는 여전히 하나의 선택지일 뿐입니다. SEO 기능은 프로젝트의 일부가 되어야 합니다.

Screpy로 실제로 구현해보기

Screpy's SEO MCP는 이 워크플로우를 ChatGPT, Claude, Codex, Cursor와 같은 AI 어시스턴트에게 가져옵니다. 호스팅된 MCP 서버에 연결하고, Screpy 계정으로 로그인한 다음, 어시스턴트가 프로젝트에 접근할 수 있도록 권한을 부여하세요.

프로젝트와 관련 데이터 연결이 설정되면, Screpy 대시보드를 열지 않고도 SEO 조사를 자동화하고, 기술적 문제를 우선순위별로 지정하며, 승인한 크롤을 시작하고, 완료된 크롤 결과를 비교할 수 있습니다. AI 비서가 사용 가능한 크롤 결과, 추적 순위, 연결된 Search Console 데이터와 직접 연동하여 작업할 수 있습니다.

예를 들어:

Screpy를 사용하여 최근 크롤을 조사합니다. 누락된 제목과 깨진 내부 링크를 찾고, 영향을 받은 페이지를 식별하며, 작업을 우선순위화합니다. 이 프로젝트의 관련 코드를 확인하고 검토를 위해 수정 사항을 준비합니다.

또한 저장소에 접근할 수 있는 코딩 에이전트와 함께라면, 작업 흐름은 문제를 식별하는 것에서 시작하여 승인된 수정 사항을 준비하거나 적용하고, 이후 크롤에서 그 결과를 확인하는 단계까지 확장될 수 있습니다. Screpy는 SEO 증거를 제공하고, 에이전트는 이 증거를 사용자의 코드와 함께 활용합니다.

조사와 구현 작업을 AI 워크플로우 내에서 유지할 수 있으며, 변경 사항은 사용자 통제 하에 있습니다. Screpy 대시보드는 필요할 때 사용할 수 있지만, SEO 작업이 반드시 이루어져야 하는 곳일 필요는 없습니다.