강남언니 SEO 웹 전략을 보고 정리한 테크니컬 SEO

2026. 7. 17. 12:26개발/FE

FECONF 2025에서 공개된 강남언니 SEO 웹 전략 영상을 봤다. 제목부터 강했다. 1년에 10억 원을 절약했다는 이야기였는데, 단순히 광고비를 아꼈다는 말보다 더 인상적이었던 건 SEO를 바라보는 관점이었다.

나는 SEO라고 하면 먼저 메타 태그, 시멘틱 태그, LCP 같은 키워드를 떠올렸다. 프론트엔드 개발자가 챙겨야 하는 SEO도 그 정도라고 생각하기 쉬웠다. 그런데 강남언니 사례에서 중요한 포인트는 조금 달랐다.

핵심은 검색 엔진이 우리 페이지를 얼마나 잘 발견하고, 이해하고, 노출하고, 사용자가 클릭하게 만들 수 있는가였다. 즉, SEO는 태그 몇 개를 넣는 작업이 아니라 검색 유입 퍼널을 설계하는 일에 가까웠다.

SEO를 퍼널로 보기

영상에서 가장 좋았던 부분은 SEO를 퍼널로 나눠서 설명한 점이었다.

검색 유입은 크게 이렇게 볼 수 있다.

  • 검색 노출: 페이지가 검색 결과에 뜨는가
  • 검색 유입: 사용자가 검색 결과에서 클릭하는가
  • 앱 내 전환: 들어온 사용자가 서비스가 원하는 행동을 하는가

 

프론트엔드 개발자가 흔히 말하는 SEO 작업은 보통 앞의 두 단계와 많이 연결된다. 페이지가 검색 엔진에 잘 수집되고, 검색 결과에서 클릭하고 싶게 보여야 한다.

강남언니처럼 병원, 시술, 리뷰, 지역 같은 페이지가 많은 서비스에서는 이 퍼널이 더 중요해진다. 페이지가 많다는 것은 SEO 기회가 많다는 뜻이기도 하지만, 동시에 잘못 관리하면 검색 봇의 리소스를 낭비할 수 있다는 뜻이기도 하다.

 

크롤링이 된다고 노출되는 것은 아니다

SEO를 공부할 때 자주 헷갈리는 개념이 크롤링과 인덱싱이다.

크롤링은 검색 봇이 페이지를 방문해서 수집하는 과정이다. 인덱싱은 수집한 페이지가 검색 엔진의 색인에 등록되는 과정이다. 검색 결과에 노출되려면 단순히 크롤링되는 것만으로는 부족하고, 인덱싱까지 되어야 한다.

 

이 차이를 이해하면 테크니컬 SEO의 역할이 더 분명해진다.

테크니컬 SEO는 검색 엔진이 우리 사이트의 중요한 페이지를 잘 찾고, 불필요한 페이지에 시간을 쓰지 않게 만들고, 수집한 페이지의 의미를 정확히 이해하도록 돕는 작업이다.

 

크롤링 버짓을 아껴야 한다

강남언니 사례에서 특히 기억에 남은 개념은 크롤링 버짓이었다.

검색 봇은 우리 사이트를 무한히 탐색하지 않는다. 하루 동안 특정 사이트에 사용할 수 있는 시간과 리소스가 제한되어 있다. 이 리소스를 크롤링 버짓이라고 볼 수 있다.

 

페이지가 적은 사이트라면 크게 체감되지 않을 수 있다. 하지만 강남언니처럼 병원, 시술, 리뷰, 지역, 필터 조합으로 많은 URL이 만들어지는 서비스에서는 이야기가 달라진다.

 

예를 들어 필터 페이지를 생각해보면, 지역과 정렬 조건과 카테고리가 조합되면서 수많은 URL이 생긴다. 이 중에는 검색 유입 가치가 있는 페이지도 있지만, 거의 같은 내용을 보여주는 중복 페이지도 생길 수 있다.

 

 

모든 URL을 검색 봇에게 열어두면 이런 문제가 생긴다.

  • 의미 없는 URL이 크롤링된다.
  • 중복 콘텐츠가 늘어난다.
  • 중요한 페이지의 수집 우선순위가 밀린다.
  • 검색 엔진이 대표 페이지를 판단하기 어려워진다.

 

그래서 테크니컬 SEO에서는 어떤 페이지를 검색 엔진에 보여줄 것인가를 정해야 한다. 이건 단순한 개발 구현이 아니라 제품과 비즈니스 판단이 섞인 작업이다.

 

사이트맵은 URL 목록이 아니라 전략이다

사이트맵은 검색 엔진에게 우리 사이트의 URL을 알려주는 파일이다. 그런데 영상 내용을 정리하면서 사이트맵을 단순한 체크리스트로 보면 안 되겠다고 느꼈다.

 

사이트맵은 검색 엔진에게 이 페이지들이 중요하다고 알려주는 신호에 가깝다.

 

큰 서비스에서는 모든 URL을 하나의 사이트맵에 넣을 수도 없다. 사이트맵에는 URL 수와 용량 제한이 있기 때문에, 규모가 커지면 여러 파일로 나누고 사이트맵 인덱스로 묶어야 한다.

 

예를 들어 이런 식의 기준이 필요하다.

  • 정적 페이지 사이트맵
  • 병원 페이지 사이트맵
  • 시술 페이지 사이트맵
  • 리뷰 페이지 사이트맵
  • 국가나 언어별 사이트맵
  • 지역 조합 페이지 사이트맵

 

중요한 건 파일을 나누는 기술 자체가 아니다. 어떤 URL 그룹이 검색 유입 가치가 있는지 판단하고, 그 URL을 검색 엔진에 명확히 전달하는 것이다.

Canonical은 중복 URL의 기준을 잡는다

동적 페이지가 많아지면 같은 콘텐츠가 여러 URL로 접근되는 일이 많다.

예를 들어 같은 병원 페이지라도 쿼리스트링이나 유입 경로에 따라 URL이 달라질 수 있다. 사용자는 같은 내용을 보고 있지만 검색 엔진 입장에서는 서로 다른 페이지처럼 보일 수 있다.

 

이때 canonical 태그가 필요하다.

canonical은 검색 엔진에게 이 페이지의 대표 URL은 이것이다라고 알려준다. 중복 URL이 생기는 서비스에서 canonical이 없으면 SEO 가치가 여러 URL로 흩어질 수 있고, 검색 엔진이 어떤 페이지를 기준으로 삼아야 할지 헷갈릴 수 있다.

 

프론트엔드에서는 페이지별 canonical URL을 정확히 생성하는 로직이 중요하다. 특히 다국어, 지역, 필터, 정렬, 검색 조건이 섞이는 서비스라면 더 그렇다.

검색 결과에서 클릭하고 싶게 만들기

검색 결과에 뜨는 것만으로는 부족하다. 사용자가 클릭해야 유입이 생긴다.

이 단계에서는 메타 태그, Open Graph, 구조화 데이터가 중요해진다.

title과 description은 검색 결과에서 사용자가 가장 먼저 보는 정보다. SNS에 공유될 때는 OG 태그가 첫인상을 만든다. 다국어 서비스라면 언어별 메타 정보가 제대로 나오는지도 중요하다.

 

영상 메모를 정리하면서 기억에 남은 예시는 검색 결과에 엉뚱한 언어나 내부 키값이 노출되는 문제였다. 사용자가 일본어로 검색했는데 한국어 설명이 나오거나, 사람이 읽을 문장이 아니라 개발 중 쓰던 키값이 보인다면 클릭률과 신뢰도가 떨어질 수밖에 없다.

 

결국 메타 태그는 단순히 head에 넣는 코드가 아니라 검색 결과에서 사용자를 설득하는 문구다.

구조화 데이터는 검색 엔진에게 설명서를 주는 일이다

구조화 데이터도 중요하다. 검색 엔진은 HTML을 읽고 페이지의 의미를 추론하지만, 구조화 데이터를 넣으면 페이지의 정보를 더 명확히 전달할 수 있다.

 

예를 들어 병원 서비스라면 병원 정보, 리뷰, 평점, 위치, FAQ 같은 데이터를 검색 엔진이 이해하기 좋은 형태로 제공할 수 있다. 이벤트 페이지라면 이벤트 날짜와 장소를, 블로그 글이라면 작성자와 발행일을 알려줄 수 있다.

 

보통 JSON-LD 형식으로 넣고, Schema.org의 타입을 따른다.

프론트엔드 개발자 입장에서는 이 부분이 꽤 흥미롭다. 검색 결과에서 별점, FAQ, breadcrumb 같은 리치 결과가 나오는 것이 단순히 검색 엔진이 알아서 해주는 일이 아니라, 우리가 페이지에 어떤 정보를 구조화해서 넣었는지와 연결되기 때문이다.

성능 개선도 SEO와 연결된다

LCP, INP, CLS 같은 Core Web Vitals는 사용자 경험 지표로 많이 이야기된다. 그런데 SEO 관점에서도 성능은 중요하다.

페이지가 느리면 사용자가 이탈할 가능성이 높고, 검색 봇이 같은 시간 안에 수집할 수 있는 페이지 수도 줄어든다. 특히 페이지 수가 많은 서비스에서는 개별 페이지의 수집 비용을 줄이는 것이 크롤링 효율과 연결된다.

 

그래서 LCP 개선은 단순히 Lighthouse 점수를 올리는 작업이 아니다. 검색 봇이 페이지를 더 빠르게 읽고, 사용자가 검색 유입 후 더 안정적으로 페이지를 경험하게 만드는 작업이다.

SEO는 배포하고 끝나는 작업이 아니다

SEO 작업은 배포 직후 바로 결과가 보이지 않는다. 검색 엔진이 다시 크롤링하고, 인덱싱하고, 검색 결과에 반영하는 데 시간이 걸린다.

그래서 모니터링이 필요하다.

 

볼 수 있는 지표는 다음과 같다.

  • 검색 노출 수
  • 클릭 수
  • CTR
  • 평균 게재 순위
  • 색인된 페이지 수
  • 크롤링 오류
  • 사이트맵 상태
  • Core Web Vitals
  • 유입 이후 전환율

 

Google Search Console은 필수에 가깝고, 한국 사용자 대상 서비스라면 네이버 서치어드바이저도 같이 봐야 한다.

중요한 건 검색 순위가 올랐는가만 보는 것이 아니다. 노출이 늘었는지, 클릭이 늘었는지, 들어온 사용자가 실제 서비스 행동으로 이어졌는지를 함께 봐야 한다.

정리

이번 영상을 보고 테크니컬 SEO를 조금 다르게 보게 됐다.

예전에는 테크니컬 SEO를 메타 태그, 시멘틱 태그, sitemap.xml, robots.txt 같은 체크리스트로 이해했다. 물론 이것들도 중요하다. 하지만 강남언니 사례에서 더 크게 보였던 것은 검색 유입 전체를 설계하는 관점이었다.

 

테크니컬 SEO는 결국 이런 질문에 답하는 일이다.

  • 검색 봇이 중요한 페이지를 찾을 수 있는가?
  • 불필요한 URL에 크롤링 버짓을 낭비하고 있지 않은가?
  • 수집된 페이지가 인덱싱될 만큼 명확한가?
  • 중복 URL의 대표 기준이 잡혀 있는가?
  • 검색 결과에서 사용자가 클릭할 이유가 보이는가?
  • 유입 이후 실제 전환까지 이어지는가?

 

SEO는 검색 순위를 억지로 올리는 기술이 아니다. 좋은 페이지가 검색 엔진과 사용자에게 제대로 발견되도록 길을 정리하는 작업이다.

특히 프론트엔드 개발자는 그 길의 많은 부분을 코드로 만들 수 있다. 그래서 테크니컬 SEO는 단순한 부가 작업이 아니라, 서비스 성장과 직접 연결되는 프론트엔드의 중요한 영역이라고 느꼈다.

참고

 

이미지는 Chatgpt를 이용하여 생성했습니다.

'개발 > FE' 카테고리의 다른 글

TypeScript 컴파일러 성능 측정 (3.9 vs 5.8)  (0) 2026.03.29
타입 스크립트 컴파일러 동작 방식  (0) 2026.03.17