대부분의 팀에는 이미 Google 순위 보고서가 있습니다. Search Console의 실적 탭을 클릭수로 정렬해 슬라이드에 스크린샷으로 붙여 넣은 것이죠. 거기에는 순위가 찍혀 있습니다. 무엇이 바뀌었는지, 왜 바뀌었는지, 누가 무엇을 해야 하는지는 찍혀 있지 않습니다.
이 워크플로는 그것을 한 번 앉아서 해결합니다. 쿼리 세트를 정하고, Codex에 보고서 계약을 글로 넘기고, 이후에는 매주 같은 모양의 보고서를 받기만 하면 됩니다. 첫 구축에 약 90분. 그 뒤 실행은 10분이면 끝납니다.
워크플로 전체. 원본 내보내기를 넣고, 정해진 모양의 보고서 하나를 받고, 마지막에 사람이 한 번 판단합니다.
완성하게 될 것
누구를 위한 글인가: 사이트 보고를 담당하면서 이미 Search Console 접근 권한이 있는 사람. 개발자일 필요는 없지만, Codex가 읽을 수 있는 곳에 파일을 둘 수 있어야 합니다.
끝나면 손에 남는 것: 저장된 보고서 템플릿, Codex가 매번 따르는 지시 파일, 그리고 실제 일주일치로 완성한 보고서 한 부입니다.
사전 준비: 확인된 Search Console 속성, 정말로 신경 쓰는 20~50개 쿼리 목록, 프로젝트 폴더에 접근할 수 있는 Codex, 그리고 고급 버전을 원한다면 자사 사이트 저장소에 대한 읽기 권한입니다.
완료의 정의: SEO를 하지 않는 사람에게 보고서를 건네도 "봐야 할 쿼리 세 개는 이것이고 이유는 이렇다"고 말할 수 있는 상태.
소요 시간: 첫 구축에 약 90분, 이후 실행당 10분 미만.
실적 보고서가 순위 보고서가 아닌 이유
Search Console이 주는 것은 네 개의 열입니다. 클릭수, 노출수, CTR, 평균 게재순위. 이것은 측정 표이고, 순위 보고서가 아닙니다. 순위 보고서는 다른 질문에 답해야 하며, 2026년의 시그널은 그 간극을 예전보다 넓혔습니다.
2026년 9월 9일 공개된 Zyppy 전문가 설문은 131명의 실무자에게서 13,665개의 데이터 포인트를 모았습니다. 클릭과 행동 시그널은 29.4%, 브랜드 시그널은 27.0%, 기술 SEO 건전성은 17.5%였습니다. 기술 건전성보다 위에 온 세 시그널 가운데 둘은 게재순위 열에 보이지 않습니다. 이 숫자들이 무엇을 바꾸는지는 별도의 실행 가이드에서 다루지만, 보고 관점에서 요약하면 이렇습니다. 순위만 보여주는 보고서는 가장 적게 움직인 시그널을 보고하는 셈입니다.
그 틈을 Codex가 메웁니다. Google이 무엇을 바꿨는지 이유까지 알려주지는 않습니다. 다만 당신이 그 이유를 말할 수 있을 만큼 일관된 형태로 증거를 조립해 줍니다.
시작 전 네 가지 결정
무엇이든 쓰기 전에 정하십시오. 나중에 바꾸면 보고서를 다시 만들어야 합니다.
- 쿼리 세트. 20~50개를 비즈니스가 생각하는 방식에 맞는 두세 개 묶음으로 나눕니다. "고볼륨 / 중볼륨 / 저볼륨"보다 "제품", "비교", "지원"이 낫습니다.
- 비교 구간. 최근 28일을 그 이전 28일과 비교합니다. 더 짧으면 노이즈가 많고, 더 길면 찾고 있는 변화가 숨습니다.
- 임계값. 무엇을 보고할 가치가 있는지 정합니다. 5계단 넘게 움직인 쿼리, 또는 클릭은 그대로인데 노출수가 30% 넘게 움직인 쿼리 정도가 무난한 기본값입니다.
- 저장 위치. 폴더 하나, 이름 규칙 하나.
reports/ranking/YYYY-MM-DD.md와 원본 내보내기를 담을data/하위 폴더. Codex에게는 일관된 쓰기 위치가 필요합니다.
1단계: 원본 데이터 내보내기
Search Console을 열고 속성을 선택한 뒤 실적 화면으로 갑니다. 기간을 56일로 잡으면 한 번의 내보내기로 28일 대 28일 비교가 가능합니다. 그다음 내보내기 버튼으로 쿼리 탭의 CSV를 받습니다.
페이지에 대해서도 같게 하고, 모바일 대 데스크톱 분리를 보고할 계획이라면 기기에 대해서도 합니다.
예상 결과물: data/ 안에 CSV 파일 세 개. 파일 이름에 내보낸 날짜를 넣습니다.
품질 점검: 쿼리 CSV를 열어 첫 데이터 행이 "anonymous"라는 단어가 들어간 쿼리가 아닌지 확인합니다. Search Console은 드문 쿼리를 감추기 때문에, 그대로 두면 보고서에 이름 없는 변동으로 나타납니다.
안 될 때: 내보내기가 잘렸다면 기간이 행 제한에 비해 너무 넓은 것입니다. 28일 구간으로 나눠 내보내고 이어 붙이는 일은 Codex에 맡기십시오.
2단계: 보고서 계약 작성하기
이 워크플로가 3주차를 넘겨 살아남을지를 결정하는 단계입니다. 계약은 Codex가 매번 읽는 파일에 둡니다. 프로젝트 루트의 AGENTS.md나, 보고서 폴더 안의 전용 지시 파일입니다.
계약에 필요한 것은 다음 다섯 가지뿐이고 그 외에는 없습니다.
계약 항목 | 쓸 내용 | 중요한 이유 |
|---|---|---|
입력 | 정확한 파일 경로와 기간 규칙 | 에이전트가 구간을 지어내는 것을 막는다 |
임계값 | 당신의 기준을 숫자로 | 표를 의사결정으로 바꾼다 |
출력 형태 | 세 개의 섹션, 이 순서대로 | 30주차를 1주차와 비교할 수 있게 한다 |
확신 규칙 | 데이터가 설명하지 못할 때 뭐라고 쓸지 | 자신감 넘치는 헛소리를 막는다 |
경계 | 에이전트가 하면 안 되는 일 | 신뢰할 때까지 읽기 전용 |
실제로 작동하는 버전은 이렇습니다.
## 순위 보고서 계약
입력: data/queries-*.csv, data/pages-*.csv
구간: 최근 28일 대 그 이전 28일. 두 날짜를 모두 보고서 헤더에 명시한다.
다음 세 가지만 보고한다:
1. 움직인 쿼리: 5계단 넘게 움직인 것, 클릭은 그대로인데 노출수가
30% 넘게 오른 것, 또는 상위 10위에서 밀려난 것.
2. 추정 원인: 파일 안의 데이터만 사용한다. 파일로 설명할 수 없으면
"이 데이터로는 설명되지 않음"이라고 쓴다.
3. 다음 주 확인: 표시된 쿼리마다 한 줄, 확인할 페이지나
쿼리를 정확히 지목한다.
데이터에서 짚을 수 없는 원인은 쓰지 않는다. 사이트 변경을 제안하지 않는다.
reports/ranking/ 밖의 파일은 절대 편집하지 않는다.예상 결과물: 지시 파일 하나. 커밋하거나 데이터 옆에 저장합니다.
품질 점검: 계약을 소리 내어 읽어 보십시오. 어떤 줄이든 손대지 않고 다른 사이트에 그대로 적용된다면, 아무것도 제약하지 못할 만큼 모호합니다.
안 될 때: Codex가 계속 섹션을 늘린다면 출력 형태가 충분히 구체적이지 않은 것입니다. 세 개의 제목을 원하는 문구 그대로 지정하십시오.
보고서의 구조. 사용한 파일을 나열한 꼬리말은 검토자가 가장 신뢰하는 부분이며, 대부분의 템플릿이 빼먹는 부분이기도 합니다.
3단계: 첫 보고서 생성하기
Codex에 폴더를 가리키고 계약에 따라 보고서 하나를 만들어 달라고 합니다. 채팅 답변이 아니라 파일을 요청하십시오. 그래야 검토도, diff도 가능합니다.
첫 실행에서 자신의 데이터가 실제로 어떤 모양인지 알게 됩니다. 두세 번의 수정은 각오하십시오. 정상이며, 워크플로 전체에서 가장 값싼 부분입니다.
예상 결과물: reports/ranking/YYYY-MM-DD.md. 헤더, 세 개의 섹션, 사용한 파일을 나열한 꼬리말이 붙습니다.
품질 점검: 표시된 쿼리 두 개를 골라 Search Console에서 숫자를 직접 확인합니다. 맞으면 파이프라인은 건전합니다. 틀리면 멈추고 데이터 단계를 고치십시오. 망가진 입력 위에서 분석을 디버깅하면 안 됩니다.
안 될 때: 가장 흔한 실패는 내보내기와 계약의 날짜 불일치입니다. 매번 헤더에 두 날짜를 고정하십시오. 이틀 차이가 횡보하던 달을 붕괴처럼 보이게 만드는 것을 막아 줍니다.
제가 처음 만든 버전은 실제로는 거의 아무것도 움직이지 않은 주에 움직인 쿼리 11개를 보고했습니다. 계약은 멀쩡했고 내보내기가 문제였습니다. 30일짜리 파일을 28일 구간과 비교하면서 이틀치 결측이 사이트 전체 붕괴처럼 보였던 것입니다. 지금 계약은 두 구간이 맞지 않으면 실행을 거부하고, 그 실패는 다시 나오지 않았습니다.
4단계: 에이전트가 쓸 수 없는 한 줄 추가하기
모든 보고서에는 사람이 쓴 문단 하나가 들어갑니다. 지난주에 무엇을 출시하고 바꾸고 깨뜨렸는지입니다.
이것은 장식이 아닙니다. 자신의 릴리스를 알고리즘 업데이트 탓으로 돌리는 에이전트를 잡는 가장 빠른 방법입니다. 보고서가 "제품 페이지 묶음이 떨어졌다"고 말하는데 당신의 메모가 "화요일에 템플릿을 바꿨다"고 말한다면, 설명의 범위가 즉시 좁혀집니다.
예상 결과물: 보고서 맨 위에 사람이 쓴 두세 문장.
품질 점검: 메모와 변동 섹션이 서로 모순된다면, 그 모순이 보고서에서 가장 값진 줄입니다. 덮지 말고 그대로 남겨 두십시오.
5단계: 보내기 전에 검증하기
보고서가 책상을 떠나기 전에 다음 세 가지를 확인합니다.
- 날짜. 두 구간이 헤더에 적혀 있고 내보내기와 일치하는가.
- 현물 확인 두 건. 표시된 쿼리 두 개를 직접 확인했는가.
- 모순 확인 한 건. 주장한 설명이 맨 아래 파일 목록에 없는 데이터를 참조하지 않는가.
세 가지가 모두 통과하면 공유해도 안전합니다. 이것은 당신 판단의 초안이지, 판단의 대체물이 아닙니다.
준비되면 쓰는 고급 경로
먼저 네 주 동안 손으로 돌리십시오. 같은 종류의 실수를 두 번 고친 뒤에야 자동화하십시오.
그다음 확장은 점진적으로 합니다.
- 실행 예약. 주간 예약 실행을 걸어 두면 노트북을 열기 전에 보고서가 나와 있습니다. 사람이 쓰는 문단을 필수 항목으로 두어 그것 없이는 보고서가 나가지 못하게 하십시오.
- 스냅샷을 버전 관리에 저장. 실행마다 커밋 하나가 됩니다. 두 주 사이의 diff는 어느 보고서보다 빠르게 읽힙니다.
- 두 번째 속성 추가. 경쟁사나 브랜드 쿼리는 본 보고서에 합치지 말고 같은 계약의 별도 보고서로 둡니다.
- 외부 시그널 하나 추가. 브랜드 검색이나 점유율 확인을 넣으면 2026년 설문의 브랜드 시그널이 이론이 아니라 측정 가능한 것이 됩니다.
자동화하지 말아야 할 것: 제안 단계입니다. 에이전트가 사이트 변경을 제안하기 시작하는 순간, 당신은 보고에서 게시로 넘어간 것이고 검토 부담은 절약한 시간보다 빠르게 늘어납니다.
문제 해결
증상 | 가능한 원인 | 해결 |
|---|---|---|
모든 쿼리가 떨어진 것처럼 보인다 | 내보내기 간 기간 어긋남 | 계약과 헤더 양쪽에 두 구간을 고정한다 |
보고서가 비어 있다 | 트래픽 규모에 비해 임계값이 너무 엄격하다 | 순위 임계값을 낮추기 전에 노출수 임계값을 낮춘다 |
매주 같은 다섯 개 쿼리만 나온다 | 쿼리 세트가 너무 좁다 | 롱테일과 비교 쿼리를 묶음에 추가한다 |
설명 없는 변동 | 저볼륨 쿼리에서는 정상 | "이 데이터로는 설명되지 않음" 출력을 두고 넘어간다 |
숫자가 Search Console과 다르다 | 내보내기의 속성이나 필터 불일치 | 매번 같은 속성과 같은 필터로 내보낸다 |
워크플로 유지하기
첫 분기를 넘겨도 쓸모 있게 유지하는 세 가지 습관이 있습니다.
쿼리 세트는 분기마다 검토한다. 작년 우선순위를 따라가는 보고서는 순위 보고서가 아니라 역사 수업입니다.
Search Console이 바뀌면 계약을 다시 읽는다. Google은 실적 화면과 내보내기 필드를 주기적으로 갱신합니다. 필드가 사라지면 그날 안에 계약을 고쳐야 합니다.
오래된 보고서를 남긴다. 이번 분기 보고서를 작년 같은 분기와 비교하는 것이, 진짜 하락과 계절성을 싸게 구분하는 유일한 방법입니다.
자주 묻는 질문(FAQ)
꼭 Codex여야 하나요? 아닙니다. 파일을 읽고, 일정에 따라 돌고, 검토 가능한 출력을 쓰는 에이전트면 무엇이든 됩니다. 사이트가 이미 저장소에 있다면 Codex가 잘 맞습니다. 보고서가 diff를 뜰 수 있는 커밋이 되기 때문입니다.
무료 도구만으로도 되나요? 됩니다. 워크플로 전체가 무료인 Search Console 데이터와 에이전트만으로 돌아갑니다. 유료 순위 트래커가 필요한 것은 경쟁사 순위나 자기 속성에서 볼 수 없는 순위가 필요할 때뿐입니다.
Search Console 실적 보고서와 무엇이 다른가요? 그쪽은 표를 보여줍니다. 이 워크플로는 판단을 만들어 냅니다. 어떤 쿼리가 임계값을 넘었는지, 데이터가 설명하는 것과 하지 못하는 것, 다음 주에 무엇을 살펴볼지. 게다가 기록이 남는데, 화면에는 남지 않습니다.
사이트 트래픽이 아주 적으면요? 노출수 임계값을 낮추고, 직전 28일 대신 작년 같은 28일과 비교하십시오. 저볼륨 사이트는 전주 대비보다 전년 대비 비교에서 시그널을 더 많이 얻습니다.
AI 개요나 AI 인용을 보고서에 넣어야 하나요? 넣고 싶다면 자체 계약을 가진 별도 섹션으로 추가하십시오. 순위 보고서에는 넣지 마십시오. 출처도 측정 방식도 다르고, 섞으면 둘 다 읽기 어려워집니다.
글쓴이: Leo Harrington, Auspia에서 500건 이상의 경영진 보고서를 다뤄 온 SEO 애널리틱스 번역가. 비전문가도 실행할 수 있는 보고서로 검색 데이터를 바꾸는 방법을 씁니다.
