독립 사이트를 운영하면서 매주 월요일 오전마다 같은 일을 하고 있다는 걸 깨달았다.
Google Search Console을 열어 지난달 검색어 데이터를 수동으로 내보낸다. GA4를 열어 트래픽 상위 50개 랜딩 페이지를 CSV로 내보낸다. Excel로 두 표를 합친다. GSC의 노출·클릭 데이터와 GA4의 세션·전환 데이터를 URL 기준으로 맞춘다. 그런 다음 수작업으로 색을 표시한다. 트래픽이 감소하면 빨간색, 전환율이 평균보다 낮으면 노란색으로 표시한다.
전체 과정에 대략 한 시간 반이 걸린다. 끝내고 단체 채팅방에 올리면 고객은 "확인했습니다"라고 한마디 답한다.
나는 이 일을 3년 동안 매주 반복했다.
그러던 지난달, 기술 분야에서 일하는 친구가 내 화면을 잠깐 보더니 가슴 아픈 말을 했다. "이거 그냥 API 연결하면 되는 일 아니야? 왜 매주 수동으로 하고 있어?"
나는 잠시 멍해졌다. 친구 말이 맞았다. GSC와 GA4에 API가 있다는 걸 몰랐던 게 아니다. 매번 "스크립트를 작성해서 API를 호출한다"고 생각하면 머릿속에 하나의 거대한 프로젝트가 떠올랐기 때문이다. Python 작성, 인증 처리, 페이지네이션 처리, 필드 매핑, 프런트엔드 화면 구성…… 이 작업들을 합치면 분명 시간을 절약할 수 있지만, 시작 비용이 너무 높아서 계속 손을 놓고 있었다.
전환점은 무엇이었을까? Codex였다.
1. 먼저 Codex가 무엇인지, 그리고 왜 ChatGPT와 다른지
AI가 코드를 작성한다는 말을 들으면 많은 사람은 먼저 "ChatGPT로 스크립트 하나 작성해 줘"라고 생각한다. 나도 해봤다. ChatGPT가 코드를 주면 에디터에 붙여 넣고, 환경을 설정하고, 의존성을 설치하고, 오류를 실행한 뒤 오류 내용을 다시 붙여 넣어 수정하게 하고, 다시 실행하고, 또 오류가 나고…… 이런 과정을 일곱여덟 번 반복하면 데이터를 수동으로 내보내는 것보다 더 피곤하다.
Codex의 포지셔닝은 완전히 다르다. Codex는 터미널에서 직접 실행되는 프로그래밍 Agent다. 독립적인 샌드박스 환경을 갖추고 있어 파일을 읽고, 파일을 작성하고, 패키지를 설치하고, 명령을 실행하고, 오류를 처리할 수 있다. 처음부터 끝까지 코드를 직접 복사하고 붙여 넣을 필요가 없다. 자연어로 지시하면 스스로 계획하고, 작성하고, 실행하고, 수정한다.
예를 들어 내가 Codex에 입력한 문장은 다음과 같았다.
"GSC의 최근 28일 검색어 데이터를 내보내고, GA4의 랜딩 페이지 데이터와 URL 기준으로 병합해서 트래픽이 가장 많이 감소한 상위 20개 페이지 표를 만들어 줘."
Codex는 다음 작업을 스스로 완료했다.
•현재 환경에 Google API용 Python 라이브러리가 있는지 확인하고, 없으면 직접 설치•내 GSC와 GA4 인증 파일 경로를 읽고 OAuth 처리•GSC API를 호출해 검색어 차원과 페이지 차원의 데이터를 가져오고 페이지네이션 자동 처리•GA4 Data API를 호출해 랜딩 페이지 차원의 세션과 전환 데이터를 가져오기•URL 정리(매개변수 제거, 끝의 슬래시 제거, www 접두사 통일)•URL 기준으로 교집합 병합을 수행하고 각 페이지의 노출-클릭-전환 퍼널 계산•트래픽 감소 폭을 기준으로 정렬한 Markdown 표 출력
나는 옆에서 화면을 지켜봤고, Codex는 모든 작업을 스스로 끝냈다. 도중에 GA4 API 날짜 형식에서 한 번 오류가 발생했지만, 오류 메시지를 읽고 직접 수정한 뒤 다시 실행해 정상적으로 완료했다.
🔴 AI 프로그래밍 도구의 차이는 "코드를 작성할 수 있는가"가 아니다. 모두 작성할 수 있다. 핵심은 "스스로 실행해서 정상적으로 끝낼 수 있는가"다.
2. Codex로 GSC+GA4 데이터 폐쇄 루프를 구축한 전체 과정
이제 실제 작업 순서에 따라 이 흐름을 어떻게 구축했는지 되짚어 보겠다. 이론은 다루지 않는다. 각 단계는 터미널에서 실제로 실행해 본 과정이다.
1. 준비 작업: Google Cloud 인증
이 과정은 피할 수 없다. GSC와 GA4의 API는 모두 Google Cloud의 OAuth 또는 Service Account 인증을 사용해야 한다. AI를 사용하든 사용하지 않든 이 단계는 직접 처리해야 한다.
내가 한 일은 다음과 같다.
•Google Cloud Console에서 프로젝트를 만들고 Search Console API와 Google Analytics Data API를 활성화•Service Account를 만들고 JSON 키 파일을 로컬에 다운로드•GSC에서 해당 Service Account의 이메일을 "제한된 사용자"(전체 권한)로 추가•GA4 관리 화면에서 해당 이메일을 "데이터 조회자"로 추가
Codex는 이 단계에서는 도와줄 수 없다. 인증과 권한 부여는 사람과 웹페이지가 상호작용하는 과정이므로 Google의 인증 페이지를 대신 클릭할 수는 없다. 하지만 이후 단계에서는 인증 파일 경로만 올바르면 원활하게 연결할 수 있다.
⚠️ 대부분의 API 자동화가 처음 막히는 지점은 코드가 아니라 권한이다. Google의 권한 시스템은 러시아 인형처럼 되어 있다. GSC에 하나의 입구가 있고, GA4에 또 다른 입구가 있으며, Google Cloud에도 입구가 하나 더 있다. 세 입구의 권한은 서로 연결되지 않는다. 이 단계를 인내심 있게 끝내면 이후 과정은 순조롭다.
2. 첫 번째 Skill: GSC 검색어 데이터 가져오기
Codex의 작업 방식은 다음과 같다. 여러 작업을 하나의 재사용 가능한 Skill(기술 파일)로 묶어 ~/.codex/skills/ 디렉터리에 저장할 수 있다. 같은 Skill을 호출할 때마다 동일한 로직에 따라 실행된다.
먼저 가장 단순한 버전을 작성했다. GSC의 검색어 차원 데이터만 가져오는 Skill이었다.
이 Skill은 Codex에 세 가지를 알려 준다. 어떤 API를 사용할지, 어떤 차원을 가져올지, 어떤 형식으로 출력할지다. 한 번 실행하자 약 40초 만에 상위 100개 검색어 목록이 출력됐다. 클릭 수, 노출 수, CTR, 평균 순위가 포함된 목록이었다.
나는 이 결과를 지난달 수동으로 내보낸 CSV와 대조했고, 데이터가 완전히 일치했다. 그때 "수작업 시대가 끝났다"는 느낌이 들었다.
하지만 완벽하게 정확한 것은 아니었다. GSC API에는 함정이 있다. 기본적으로 1000행만 제공하므로 그 이상이면 페이지를 넘겨야 한다. 처음 실행했을 때 내 사이트에는 한 달 동안 3400개가 넘는 검색어가 있었다. Codex는 반환된 데이터 행 수가 맞지 않는 것을 스스로 발견하고 페이지네이션 로직을 추가해 다시 실행했다. 두 번째 실행에서는 전체 데이터가 나왔다.
스스로 발견하고, 스스로 수정했다. ChatGPT로 스크립트를 작성하는 것과는 완전히 다른 경험이었다.
3. 두 번째 Skill: GA4 연결하기
GSC 데이터를 가져온 뒤 GA4의 랜딩 페이지 데이터도 가져오도록 했다.
난이도가 한 단계 높았다. GA4 Data API에서는 직접 "데이터 요청 본문"을 만들어야 한다. 필요한 차원(landingPage), 지표(sessions, conversions, eventCount), 날짜 범위와 필터 조건을 정의해야 한다. 요청 본문의 JSON 구조는 GSC와 완전히 다르고, GA4 응답의 필드명은 eventName_xxx처럼 긴 형식이라 직접 파싱해야 한다.
Codex가 GA4 API를 읽고 쓰는 방식은 인상적이었다. 기계적으로 지시에 따라 API를 호출하는 것이 아니라, 호출하기 전에 먼저 Schema 탐색을 수행했다. GA4 Metadata API를 호출해 해당 속성에서 사용할 수 있는 차원과 지표, 필드명 조합 방식을 모두 확인한 다음 요청 본문을 구성했다.
💡 이런 "현장을 먼저 파악한 뒤 움직이는" 작업 방식은 사람이 새로운 API를 연동할 때 실제로 하는 방식이다. AI가 이를 자동화한 것이다.
두 Skill을 실행한 뒤 두 개의 표를 얻었다.
•GSC 검색어 차원: 키워드, 페이지 URL, 클릭, 노출, CTR, 평균 순위•GA4 랜딩 페이지 차원: 페이지 URL, 세션, 전환, 평균 참여 시간
다음은 병합이었다.
4. 병합: 두 개의 표에서 우선순위가 정리된 할 일 목록으로
두 표를 병합하는 일은 간단해 보인다. URL과 URL을 맞춰 붙이면 끝이다. 하지만 실제로 해보면 작은 함정이 무수히 많다.
나는 Codex에 먼저 두 표의 데이터 샘플을 직접 "살펴보라"고 했다. Codex는 GSC의 페이지 URL에는 https:// 접두사가 붙어 있지만 GA4의 랜딩 페이지 경로에는 /blog/seo-guide만 적혀 있다는 것을 발견했다. GSC URL 끝에는 ?utm_source=google 같은 쿼리 매개변수가 붙어 있지만 GA4에서는 이미 제거되어 있었다. GSC에는 데이터가 있지만 GA4에는 없는 페이지도 있었고, 반대의 경우도 있었다.
Codex는 이러한 차이를 직접 데이터 정리했다. 접두사, 매개변수, 앵커를 제거하고 끝의 슬래시를 통일한 뒤 교집합 병합을 수행했다.
병합이 끝난 뒤 Codex가 출력한 것은 차가운 피벗 테이블이 아니라 문제 유형별로 우선순위가 표시된 진단 결과였다.
우선순위｜페이지 특성｜진단 방향
🔴 P0｜노출 30% 이상 감소, 순위가 top5에서 top10 밖으로 하락｜순위 손실: 외부 링크와 콘텐츠 최신성 점검
🟡 P1｜노출은 높지만 CTR이 낮음(CTR이 평균보다 50% 낮음)｜제목의 매력 부족: Title과 Meta 수정
🟡 P1｜클릭은 높지만 전환이 낮음(전환율이 평균보다 40% 낮음)｜랜딩 페이지의 전환 유도력 부족: 페이지 콘텐츠와 CTA 점검
🟢 P2｜순위 8~20위이며 검색량이 높음｜손에 닿을 듯한 기회: 내부 링크와 콘텐츠 보강
📊 서로 고립된 두 개의 보고서를 심각도에 따라 정렬된 할 일 목록으로 바꾸는 것, 이것이 바로 "데이터 폐쇄 루프"의 의미다. 데이터를 보기 위한 것이 아니라 무엇을 해야 하는지 알기 위한 것이다.
3. 이 과정에서 실제로 부딪힌 문제
Skill을 작성하고 실행이 정상적으로 끝난 뒤 돌아보면 모든 일이 "당연한 흐름"처럼 보인다. 하지만 당시에는 실제로 나를 막아 세운 문제가 몇 가지 있었다.
문제 1: 직관적이지 않은 GA4 지표명
GA4 API에서 세션 수는 sessions라고 부르고, 전환 수는 conversions가 아니라 eventCount라고 부른다. 단, 전환으로 표시한 이벤트에 한정된다. 평균 참여 시간은 avgTimeOnPage가 아니라 userEngagementDuration이며, 직접 세션 수로 나눠야 한다.
문서를 보면 물론 이해할 수 있다. 문제는 항목별로 확인하는 데 한두 시간이 걸린다는 것이다. Codex가 절약해 준 시간은 바로 이 부분이었다. API 요청을 구성하기 전에 GA4 Metadata 인터페이스를 직접 호출해 해당 속성에서 사용할 수 있는 모든 지표의 이름, 유형, 설명을 가져온 다음, 영어 의미를 기준으로 "내가 원하는 세션 수"에 어떤 필드가 대응하는지 찾아냈다.
문제 2: GSC API의 할당량 제한
GSC API의 일일 할당량에는 수동으로 GSC를 사용할 때와 마찬가지로 상한이 있다. 처음에는 페이지네이션을 너무 공격적으로 설정해 20페이지를 동시에 호출했고, 곧바로 속도 제한에 걸렸다. Codex는 HTTP 429를 받은 뒤 몇 초간 멈춰 재시도했고, 두 번째에는 페이지네이션 속도를 초당 2페이지로 낮춰 안정적으로 실행했다.
이 경험을 통해 깨달은 점은 AI가 아무리 똑똑해도 사람이 만든 API를 호출한다는 것이다. API의 속도 제한 규칙, 데이터 형식, 필드명 같은 번거로운 작업은 대신 처리해 주지만, 함정이 어디에 있는지는 알고 있어야 한다.
문제 3: Codex가 때때로 과도하게 엔지니어링한다
한 번은 Codex에 "데이터를 페이지 유형별로 그룹화해 줘"라고 요청했다. 내 의도는 URL 경로의 /blog/, /product/ 같은 접두사로 구분하는 것이었다. 하지만 Codex는 각 페이지의 HTML 구조를 읽고 페이지 유형을 추출하는 것으로 이해했다. 실제로 그렇게 했다. requests 라이브러리로 페이지별 HTML을 크롤링하고, meta 태그와 schema 마크업을 분석한 뒤 분류했다.
실행 자체는 성공했지만 거의 4분이 걸렸다. 내가 원한 것은 사실 URL 경로 접두사를 기준으로 조건을 나누는 것뿐이었다.
⚠️ AI와 협업할 때는 문제의 구체성이 효율을 결정한다. 더 정확하게 말할수록 더 빠르게 처리한다. 너무 모호하게 말하면 가장 복잡한 방식으로 "이해"하려 한다. 게다가 우회하고 있다는 사실을 반드시 알려 주지도 않는다.
4. 일회성 스크립트가 아닌 "재사용 가능한" 시스템으로 만들기
한 번 실행에 성공하는 것은 쉽다. 매주 실행할 수 있고 다른 사이트에도 적용할 수 있는 "데이터 폐쇄 루프"로 만드는 것이 진짜 가치 있는 부분이다.
Codex의 Skill 메커니즘으로 캡슐화하기
Codex는 Skill 파일을 지원한다. ~/.codex/skills/ 디렉터리에 저장하는 Markdown 형식의 지시 파일이다. 본질적으로는 매우 정밀하게 작성된 작업 매뉴얼이라고 볼 수 있다. Codex는 Skill을 호출할 때마다 동일한 SOP에 따라 처음부터 끝까지 실행하므로, "지난번에 임시로 수정한 것을 원래대로 돌려놓는 것을 잊는" 문제가 발생하지 않는다.
나는 GSC+GA4 데이터 가져오기→정리→병합→진단→출력 과정을 세 개의 독립적인 Skill로 나눴다.
Skill｜기능｜출력
seo-gsc-pull｜GSC 검색어+페이지 차원 데이터를 가져오고 자동으로 페이지네이션｜두 개의 CSV: gsc_queries.csv, gsc_pages.csv
seo-ga4-pull｜GA4 랜딩 페이지+전환 데이터를 가져오고 지표 자동 매칭｜ga4_landing.csv
seo-data-merge｜세 표를 병합하고 URL을 정리한 뒤 진단 순위 출력｜Markdown 진단 보고서+병합된 CSV
세 개로 나누면 GSC에 문제가 생겼을 때 GSC 부분만 실행하고, GA4 할당량이 부족할 때는 GA4 부분만 실행할 수 있어 서로 막히지 않는다. 또한 고객마다 사이트가 달라도 앞의 두 Skill은 데이터 소스가 다를 수 있지만, 세 번째 Skill(병합 및 진단)은 재사용할 수 있다. 사이트 URL 매개변수 하나만 바꾸면 된다.
한 줄 명령으로 전체 과정 실행하기
세 Skill로 나눈 뒤 Codex에서 "오케스트레이션 Skill"을 하나 작성했다.
/seo-weekly-report site=example.comCodex는 이 명령어를 확인한 뒤 세 개의 Skill을 순서대로 실행합니다. GSC 데이터를 가져오고, GA4 데이터를 가져오고, 진단 결과를 통합한 다음, 마지막으로 터미널에 P0/P1/P2 순으로 정렬된 페이지 단위 진단 보고서를 출력합니다. 전체 과정은 약 2분 조금 넘게 걸립니다.
💡 "자동화"란 절대 고장 나지 않는 스크립트를 작성하는 것이 아닙니다. 반복적으로 해야 하는 작업을 한마디로 실행할 수 있고, 데이터 변화에도 대응할 수 있는 프로세스로 바꾸는 것입니다.
다섯째, 이 시스템을 구축한 뒤 실제로 달라진 점
과장 없이 말하면, 제 월요일 오전은 완전히 달라졌습니다.
예전에는:
•GSC와 GA4 데이터를 수동으로 내보내고 정리한 뒤 통합하는 데 40분•Excel에서 색상을 표시하고 우선순위를 정하는 데 20분•"이번 주 SEO 요약"을 작성해 단체 채팅방에 보내는 데 20분•고객은 "확인했습니다. 수고하셨어요"라고 한마디 답장
지금은:
•월요일에 출근해 터미널에 /seo-weekly-report 한 줄 입력•2분 후 진단 보고서가 reports/ 디렉터리에 생성•복사해 WeChat에 붙여넣고, 설명 두 문장을 덧붙여 전송
그런데 동시에 재미있는 일이 생겼습니다. 예전에는 제가 "오랫동안 작업해서" 보고서를 보내면 고객도 많은 일을 했다고 생각했습니다. 이제는 2분 만에 결과를 내놓으니, 오히려 어떤 고객은 "이렇게 빨리요? 제대로 검토한 거 맞나요?"라고 생각합니다.
웃기죠? 하지만 이것이 실제 인간의 심리입니다.
그래서 지금은 전략을 조정했습니다. 보고서가 생성된 뒤 P0로 분류된 페이지 몇 개를 골라 15분 동안 하나씩 직접 열어 확인하고, 보고서에 "수동 검토 의견"을 한 줄 추가합니다. 이 15분은 낭비가 아닙니다. 고객에게 "누군가 실제로 검토했다"는 느낌을 주기 위한 시간입니다. AI가 뱉어낸 기계적인 보고서가 아니라요.
🔴 AI가 대신하는 일은 번거로운 작업입니다. 하지만 여러분의 판단, 경험, 그리고 한 번 더 확인하려는 태도는 자동화할 수 없는 부분입니다. 그리고 바로 그 부분을 고객이 가장 중요하게 생각합니다.
여섯째, 이 시스템을 구축하려는 분들을 위한 현실적인 조언
여러분도 Codex로 자신만의 SEO 데이터 선순환을 구축하고 싶다면, 다음은 제가 실제 비용과 시간으로 얻은 조언입니다.
① 처음부터 완벽함을 추구하지 마세요. 먼저 GSC부터 단독으로 연결하세요.
Skill 하나로 최근 28일간의 검색어 데이터를 가져와 CSV로 출력하게 하세요. 이것만 정상적으로 작동해도 이미 "완전 자동 순위 추적" 기능을 갖춘 것입니다. 처음부터 구축하는 데 30분이 걸렸고, 그중 대부분은 Google Cloud 권한 설정에 썼습니다. 첫 번째 Skill을 연결하고 나니 심리적인 장벽도 사라졌습니다.
② 인증 파일을 철저히 관리하세요. 전체 연결 과정의 "핵심 약점"입니다.
Google Cloud의 Service Account JSON 키 파일이 유출되면 다른 사람이 여러분의 GSC와 GA4를 읽고 쓸 수 있습니다. 이 파일은 Git 저장소에 두지 말고, 환경 변수로 경로를 참조하세요. Codex의 Skill에서는 `${GSC_CREDENTIALS_PATH}`처럼 참조하고, 하드코딩하지 마세요.
③ Codex 로그에 각 단계의 소요 시간을 출력하게 하세요.
Skill에 "각 작업 후 소요 시간을 기록해 주세요"라는 문장을 추가하세요. 잘난 척하려는 것이 아니라 어느 단계가 병목인지 파악하기 위해서입니다. GSC API 가져오기가 느린지, GA4 페이지가 많은지, URL 정리 로직이 너무 복잡한지 확인할 수 있습니다. 알아야 정확히 최적화할 수 있습니다.
④ 여러 사이트에 재사용하기 전에 새 사이트와 기존 사이트의 GA4 속성 구조가 일치하는지 먼저 확인하세요.
같은 Skill을 실행해도 A 고객은 정상 작동하고 B 고객은 오류가 발생하는 경우가 있습니다. 80%는 두 GA4 속성의 맞춤 측정기준과 이벤트 이름이 서로 다르기 때문입니다. 새 사이트에서 처음 실행할 때는 Codex가 먼저 GA4 Metadata를 한 번 가져와 구조를 확인하게 하세요.
📊 실제 데이터: 한 고객을 위해 전체 프로세스를 처음부터 구축하는 데 약 45분이 걸렸습니다(Google 권한 설정 포함). 이후 매주 실행 시간은 약 2분입니다.
GitHub에는 바로 가져와 수정할 수 있는 오픈 소스 Codex SEO Skill이 몇 가지 있습니다. owensky-dev는 seo-gsc-ga4-analyst를 만들었고, AminForou는 mcp-gsc라는 MCP 서버를 만들었습니다. 처음부터 직접 만들 필요는 없습니다. 완성된 Skill을 가져와 한 번 실행해 출력이 어떻게 생겼는지 확인한 다음, 자신의 요구에 맞게 수정하세요. 처음부터 작성하는 것보다 10배 빠릅니다.
물론 기존 Skill이 가져오는 출력이 여러분의 요구에 완전히 맞지는 않을 수 있습니다. 예를 들어 owensky-dev의 Skill은 기본적으로 90일간의 데이터를 가져오지만, 저는 28일 단위로 분석하는 것을 선호합니다. 이런 작은 변경은 Skill 파일에서 매개변수 하나만 수정하면 됩니다. Codex가 여러분의 수정 사항을 읽고 그대로 실행합니다.
아이디어 하나에서 안정적으로 실행되는 시스템을 만들기까지 전체 과정에 약 이틀 오후가 걸렸습니다. 첫째 날 오후에는 권한과 API 연동을 처리했고, 둘째 날 오후에는 Skill을 작성하고 출력 형식을 조정했습니다. 그 후 매주 이 시스템은 제가 그 이틀 오후에 들인 시간을 다시 절약해 주고 있습니다.
지난주에 해외 무역 사이트를 운영하는 동료가 물었습니다. "어떤 도구로 데이터를 보고 있어?"
저는 Codex라고 답했습니다.
그가 비싸지 않냐고 물었습니다.
저는 지난주에 Excel에 쓴 시간보다 비싸지는 않다고 말했습니다.
그는 몇 초 동안 멈춰 있었습니다. 그리고 말했습니다. "그럼 그 Skill 나한테도 하나 보내 줘."