AMP만 적용하면 구글 검색 상단에 올라갈 수 있다고 믿었습니다. 그래서 며칠 밤을 새워 블로그 주요 글들을 AMP 버전으로 다시 짰는데, 결과는 기대와 꽤 달랐습니다. 이 글은 그 경험을 바탕으로 AMP가 실제로 어떤 기술이고, 왜 많은 개발자들이 지금 AMP를 걷어내고 있는지를 담았습니다.
AMP 규격, 실제로 얼마나 까다로울까?
AMP(Accelerated Mobile Pages)란 구글이 주도해 만든 모바일 최적화 HTML 프레임워크입니다. 여기서 AMP란 단순히 "빠른 페이지"가 아니라, 구글이 정한 특정 HTML 규격을 완전히 준수해야만 인정받는 별도의 기술 표준입니다. 일반 HTML을 조금 손보는 수준이 아니라, 사실상 페이지를 처음부터 다시 짜야 하는 수준이라는 게 제가 직접 써봤을 때 가장 먼저 든 생각이었습니다.
가장 먼저 부딪힌 건 커스텀 태그 규칙이었습니다. 일반 HTML에서 쓰는 <img> 태그 대신 amp-img를, 분석 스크립트 대신 amp-analytics를 써야 했습니다. 이 커스텀 태그들은 각각의 속성 규칙이 따로 있어서, 기존 HTML 구조를 거의 그대로 쓸 수가 없었습니다. 여기에 인라인 CSS 20KB 제한까지 있었는데, 이 제한이란 페이지 스타일 전체를 20KB 이하의 <style> 블록 하나에 담아야 한다는 규칙입니다. 저는 이 작업만 며칠을 썼습니다. CSS를 압축하고, 쓰지 않는 스타일을 일일이 걷어내고, 다시 확인하는 과정을 반복했습니다.
그다음 관문이 AMP Validator였습니다. AMP Validator란 작성한 AMP 페이지가 공식 규격을 통과하는지 검증해주는 공식 도구입니다. 처음에는 오류가 열 개 넘게 떴고, 하나 고치면 또 다른 오류가 나왔습니다. 광고 스크립트나 댓글 위젯처럼 서드파티 요소들이 AMP 규격과 충돌하는 문제도 있었는데, 이걸 해결하는 데 예상보다 훨씬 많은 시간이 걸렸습니다. 결국 Validator를 통과시키던 순간의 성취감은 컸지만, 제 경험상 이건 실력의 문제라기보다 규격 자체가 주는 피로감이 상당한 작업이었습니다(출처: AMP Project 공식 문서).
- 일반 <img> → amp-img 커스텀 태그로 전면 교체 필수
- 인라인 CSS 20KB 이하 제한: 스타일 압축과 정리 작업 필요
- amp-analytics 등 서드파티 스크립트 규격 충돌 문제
- AMP Validator 통과까지 반복적인 오류 수정 과정
유지보수 이중 부담, 생각보다 훨씬 무거웠습니다
AMP 페이지를 처음 만들고 나서 뿌듯했던 건 솔직히 일주일도 안 됐습니다. 문제는 콘텐츠를 수정할 때마다 일반 페이지와 AMP 페이지를 따로 업데이트해야 한다는 점이었습니다. 글 하나를 고치는 데 두 배의 시간이 걸렸고, 한쪽만 수정하면 두 버전 사이에 내용이 어긋나는 문제도 생겼습니다. 제 경험상 이 이중 유지보수 부담은 처음에는 감당할 만하다고 생각했지만, 콘텐츠 수가 늘어날수록 점점 감당하기 어려워졌습니다.
트래픽 결과도 솔직히 이건 예상 밖이었습니다. 당시 구글은 Top Stories 캐러셀이라고 불리는 모바일 검색 상단의 특별 노출 영역을 AMP 페이지에 우선 배정했습니다. Top Stories 캐러셀이란 모바일 구글 검색 결과 상단에 카드 형태로 띄워주는 뉴스·콘텐츠 추천 슬라이더를 말합니다. 이 혜택을 기대하고 투자했는데, 실제 트래픽 상승폭은 며칠 간의 작업량에 비해 크지 않았습니다. AMP가 잘 먹히는 영역이 뉴스처럼 속보성 콘텐츠에 집중돼 있었기 때문으로 보입니다.
그러다 구글이 AMP 전용 노출 우대 정책을 점차 축소하기 시작했습니다. 더 이상 AMP 페이지가 아니어도 Top Stories 캐러셀에 노출될 수 있게 정책이 바뀐 것입니다. 이 시점부터 저는 AMP 유지보수를 중단하고 일반 페이지의 로딩 속도 자체를 개선하는 방향으로 전략을 바꿨습니다. 솔직히 그 결정이 훨씬 합리적이었다고 지금도 생각합니다.
Core Web Vitals 시대, AMP는 지금 어디쯤 있을까?
구글이 AMP 우대 정책을 축소하면서 전면에 내세운 것이 Core Web Vitals입니다. Core Web Vitals란 LCP(최대 콘텐츠 렌더링 속도), FID(첫 입력 지연), CLS(레이아웃 이동 안정성) 등 실제 사용자 경험을 수치로 측정하는 구글의 웹 성능 지표 세트입니다. 여기서 중요한 점은 이 지표가 AMP 여부와 무관하게 모든 페이지에 동일하게 적용된다는 것입니다. AMP가 아니어도 Core Web Vitals 점수가 높으면 검색 노출에서 이점을 가질 수 있게 됐습니다(출처: web.dev - Core Web Vitals).
이 변화가 의미하는 바는 명확합니다. 구글이라는 단일 플랫폼에 종속된 별도 규격을 유지보수하는 것보다, 표준 웹 기술로 성능을 끌어올리는 편이 훨씬 지속 가능한 전략이라는 것입니다. 제가 실제로 AMP를 걷어낸 뒤 이미지 최적화, 코드 스플리팅(code splitting, 페이지에서 필요한 코드만 나눠 불러오는 기법), 캐싱 전략 같은 표준 기술에 집중했더니, 유지보수 부담은 줄면서 Core Web Vitals 점수는 오히려 개선됐습니다.
그렇다고 AMP가 완전히 의미 없어졌다고 보기는 어렵습니다. 속보 뉴스처럼 극단적으로 빠른 로딩이 경쟁력 자체인 도메인에서는 여전히 고려할 여지가 있습니다. 하지만 일반 블로그나 콘텐츠 사이트라면 지금 시점에 AMP에 신규 투자하는 건 비용 대비 효과 면에서 맞지 않는다고 봅니다. 일반적으로 AMP 도입이 SEO에 필수라고 알려져 있는 경우도 있는데, 실제로 써보니 표준 성능 최적화만으로도 충분한 효과를 낼 수 있다는 것이 제 결론입니다.
자주 묻는 질문
Q. 지금도 AMP를 새로 적용하는 게 의미 있을까요?
A. 일반 블로그라면 솔직히 권하기 어렵습니다. 구글이 AMP 전용 노출 우대 정책을 축소한 이후로는 Core Web Vitals 점수를 높이는 표준 최적화가 훨씬 효율적입니다. 다만 속보 뉴스처럼 로딩 속도가 경쟁력 자체인 도메인이라면 아직 검토할 여지는 있지 않을까요?
Q. AMP Validator 오류, 어떻게 잡아야 하나요?
A. AMP Validator는 오류 메시지가 비교적 구체적으로 나오는 편입니다. 커스텀 태그 누락이나 CSS 용량 초과가 가장 흔한 원인이니, 먼저 amp-img 교체와 인라인 CSS 20KB 제한을 확인하는 게 우선입니다. 오류 하나씩 잡아가다 보면 패턴이 보이기 시작합니다.
Q. Core Web Vitals 점수를 높이려면 뭐부터 해야 하나요?
A. 가장 체감 효과가 큰 순서대로라면 이미지 최적화(WebP 변환, 사이즈 조정)가 첫 번째입니다. 그다음으로 불필요한 서드파티 스크립트 제거, 코드 스플리팅 적용 순으로 살펴보시면 LCP와 CLS 수치가 눈에 띄게 달라지는 걸 느끼실 수 있을 겁니다.
Q. AMP 페이지와 일반 페이지를 동시에 운영해야 하나요?
A. AMP를 도입하면 두 버전을 따로 관리해야 합니다. 콘텐츠가 많아질수록 이 이중 유지보수 부담이 상당해집니다. 지금 시점에서 신규로 시작하는 블로그라면 AMP 없이 일반 페이지 성능을 높이는 방향이 훨씬 현실적이지 않을까 생각합니다.
결론
AMP는 분명 등장 당시에는 모바일 성능 문제에 대한 합리적인 해법처럼 보였습니다. 저도 그렇게 믿고 상당한 시간을 투자했습니다. 하지만 구글이라는 단일 플랫폼에 종속된 별도 규격을 계속 유지보수해야 한다는 구조적 한계는 시간이 지날수록 더 분명해졌고, 결국 구글 스스로도 플랫폼 독립적인 Core Web Vitals 지표로 무게중심을 옮겼습니다.
지금 블로그를 새로 시작하거나 운영 중이라면, AMP에 투자하기보다 이미지 최적화, 코드 스플리팅, 캐싱 전략 같은 표준 웹 기술로 성능을 끌어올리는 쪽이 장기적으로 더 안정적인 선택이라고 봅니다. AMP Validator 오류를 붙잡고 씨름하는 시간이 있다면, 그 시간을 Core Web Vitals 점수를 직접 개선하는 데 쓰는 것이 지금 시점에는 훨씬 현명한 방향입니다.
참고: AMP Project 공식 문서 / Google Search Central - AMP 가이드 / web.dev - Core Web Vitals