블로그에 AdSense 스크립트와 광고 소유권 파일 서빙 적용

블로그에 AdSense 를 붙이는 작업을 했다. 생각보다 손댈 곳이 두 군데로 명확했는데, 막상 하나씩 뜯어보면 각각의 역할이 꽤 다르다.

왜 두 파일인가

base.html 과 main.py, 두 파일만 건드렸다. 라인 수도 크지 않은 핀포인트 수정이지만, 이 두 파일이 맡는 역할이 서로 다른 레이어라서 짚고 넘어갈 가치가 있다.

파일	변경 내용	역할
`app/templates/base.html`	AdSense `<script>` 태그 삽입	모든 페이지 `<head>` 에 광고 스크립트 전파
`app/main.py`	`/ads.txt` 라우트 추가	Google 게시자 ID 소유권 검증 파일 서빙

base.html 에 넣은 건 전형적인 템플릿 상속 구조 활용이다. 모든 페이지가 base.html 을 상속받는 구조라면, 여기 <head> 안에 스크립트 한 줄 넣는 것만으로 사이트 전체에 AdSense 가 활성화된다. 페이지마다 따로 붙이는 건 유지보수 지옥이라 당연한 선택.

main.py 의 /ads.txt 라우트는 조금 다른 이야기다. 이건 Google 이 "이 도메인의 진짜 운영자가 AdSense 계정을 소유하고 있는지" 를 확인하는 파일이다. 도메인 루트에서 https://blog.slecs.net/ads.txt 로 접근 가능해야 하고, 내용에는 Google 게시자 ID가 포함돼야 한다.

`/ads.txt` 를 정적 파일로 안 두고 라우트로 만든 이유

정적 파일 디렉토리에 그냥 ads.txt 하나 던져놓을 수도 있다. 실제로 많은 블로그 프레임워크에서 그렇게 처리한다. 근데 FastAPI / Flask 계열 앱이라면 라우트로 처리하는 게 몇 가지 면에서 낫다.

명시성: 라우트로 선언하면 main.py 를 읽는 것만으로 "이 앱이 /ads.txt 를 서빙한다"는 사실이 바로 보인다. 정적 파일로 두면 파일 시스템을 뒤져야 존재를 알 수 있음.
배포 일관성: 컨테이너 배포 환경에서는 정적 파일 경로 마운트 설정이 꼬이는 경우가 있다. 라우트로 처리하면 앱 코드 안에서 완결되기 때문에 환경 설정에 덜 의존한다.
내용 동적 변경 여지: 지금은 단순 텍스트 응답이지만, 나중에 게시자 ID 를 환경 변수로 관리하거나 여러 계정을 다루게 될 경우에도 라우트가 훨씬 유연하다.

코드 패턴으로 보면 대략 이런 모양이다.

@app.get("/ads.txt", response_class=PlainTextResponse)
async def ads_txt():
    return "google.com, pub-XXXXXXXXXXXXXXXX, DIRECT, f08c47fec0942fa0"

응답 타입을 PlainTextResponse 로 명시하는 게 중요하다. Google 크롤러가 ads.txt 를 읽을 때 text/plain 콘텐츠 타입을 기대하는데, JSON 이나 HTML 로 내려가면 인식 못 한다.

`<head>` 스크립트 삽입 위치

base.html 쪽도 그냥 붙인 게 아니다. AdSense 스크립트는 <head> 안에 들어가야 하고, 위치에 따라 페이지 로딩 성능에 영향을 줄 수 있다.

<head>
  <meta charset="UTF-8">
  <!-- ... 기존 메타 태그들 -->
  <script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-XXXXXXXXXXXXXXXX"
     crossorigin="anonymous"></script>
</head>

async 속성이 붙어 있는 게 핵심이다. 없으면 스크립트 로드가 렌더링을 블로킹한다. 블로그 콘텐츠가 광고 스크립트 때문에 느려지는 건 UX 관점에서도, SEO 관점에서도 좋지 않다. AdSense 공식 스니펫에 async 가 기본으로 붙어 있는 이유가 여기 있다.

회고

작업 자체는 작다. 두 파일, 몇 줄. 근데 이런 인프라성 설정 작업이 은근히 틀리기 쉬운 지점이 있다. /ads.txt 접근이 안 된다거나, 게시자 ID 오타로 Google 심사가 계속 보류 상태에 머무는 경우가 대표적이다. 배포 직후에 실제로 curl https://blog.slecs.net/ads.txt 로 내용 확인하고, 크롬 개발자 도구에서 <head> 스크립트가 제대로 들어갔는지 눈으로 찍어보는 게 맞다. 자동화 테스트까지 붙이기엔 작은 작업이지만, 수동 검증 체크리스트는 커밋 전에 머릿속에 돌려두는 습관이 있다.

AdSense 승인은 사이트 콘텐츠 심사까지 있어서 이 커밋만으로 바로 광고가 뜨는 건 아니다. 하지만 기술적 요건 — 스크립트 삽입과 ads.txt 서빙 — 은 이걸로 끝.

끝.