최근 몇 년 동안, 마케팅 전문가들이 모든 최적화 프로세스의 최상위에 로딩 속도를 놓는 것을 보아왔습니다. 2017년 Google은 로딩 속도와 그 향후 순위에 미치는 영향의 중요성을 강조하기 시작했지만, 이 발언이 공식화된 것은 2018년 여름에 이르러서였습니다.
본 글에서는 여러분이 직접 웹사이트의 로딩 속도를 최적화하고 개선하기 시작할 수 있도록 도와드리고자 합니다. 모든 최적화 프로세스와 마찬가지로, 복잡해질 수 있는 기술적 측면이 있습니다. SEOcrawl에서 이런 종류의 글을 쓸 때 우리는 항상 여러분이 직접 구현할 수 있기를 원하지만, 일부 액션은 더 기술적인 수준의 지식이 필요합니다. 그렇긴 해도 솔직히 말해, 사이트의 WPO를 audit하기 위해 사용할 도구의 점수를 쫓느라 미치지는 맙시다.
최적화는 템플릿이 어떻게 디자인되었는지에 크게 의존하며, 모든 템플릿이 같은 성능을 얻을 수 있는 것은 아닙니다. 이 점을 명심하는 것이 중요합니다.
시작합시다!
WPO란?
Web Performance Optimization, 우리가 WPO라고 부르는 것은 단순히 웹사이트가 로드되는 방식에 영향을 미치는 다양한 프로세스의 최적화입니다.
audit를 시작하기 전에, 로딩 속도가 모든 사용자마다 다르다는 점을 명심하는 것이 중요합니다. 다양한 변수가 쿠엔카(Cuenca)에 있는 사용자와 오타와(Ottawa)에 있는 사용자가 느끼는 속도에 영향을 미칠 수 있습니다.
그래서 초 단위의 로딩 시간으로 작업하기보다는, 다음을 최적화하는 데 집중할 것을 권장합니다:
›
웹사이트 무게 (MB)
›
요청수 (Requests)
›
서버 응답 시간
이 3가지 영역을 개선하면 사용자의 위치에 관계없이 로딩 속도가 개선됩니다.
각 영역으로 들어가 다양한 도구를 통해 모든 URL의 성능을 개선하기 위해 어떻게 작업할지 살펴보겠습니다. 왜 모든 URL을 말씀드릴까요? 명백해 보일 수 있지만, 홈페이지 데이터만 평가된 많은 경우를 만났기 때문입니다. 그리고 물론 사이트의 모든 페이지가 같은 리소스를 로드하지는 않습니다.
Google 개발자 도구
시작하기 전에 Google이 개발자 도구를 통해 제공하는 옵션을 설명하고 싶습니다. 이 도구는 웹사이트가 어떻게 작동하는지 분석하기 위한 가장 중요한 도구 중 하나입니다. 브라우저가 열어둔 페이지에서 우클릭하면 다양한 옵션이 있는 패널이 나타납니다. Inspect (Ctrl + Shift + I)로 갑니다.
도구가 열리면 상단에서 찾을 수 있는 NETWORK 옵션으로 이동합니다. 브라우저에서 다시 ENTER를 누르면 도구가 다양한 리소스의 로딩을 보여줍니다.
Google 개발자 도구의 로딩 시간
이미지 하단에서 사이트가 어떻게 로드되는지에 대한 일반적 보기에 관심 있는 데이터를 볼 수 있습니다.
Domain, Scheme, Cookies 같은 추가 정보 요소를 활성화하면 특정 사례에서 우리에게 어떤 종류의 문제를 일으킬 수 있는 리소스를 찾는 데 도움이 될 수 있지만, 이 시점에서는 사전 정의된 것을 고수하겠습니다.
매우 흥미롭지만 명심해 두기 위해 살짝만 다룰 측면이 하나 있습니다. 연결 속도, 특히 모바일에서, 사이트가 로드되는 방식의 핵심 부분입니다. 이 도구에서 모바일의 3G 같은 더 느린 속도를 시뮬레이션할 수 있습니다.
느린 전송 속도 시뮬레이션
URL의 무게를 알고 어떻게 줄일까요?
무게는 메가바이트든 킬로바이트든 URL이 로드하는 데 시간이 걸리는 주요 이유 중 하나입니다. 그래서 이 측면을 깊이 다루는 것부터 시작합니다. 사이트에서 좋은 최적화를 달성하기 위한 길을 설정하기 때문입니다.
다음 데이터는 위에서 언급한 도구 GTMETRIX에서 가져온 것이며, 곧 최적화를 시작할 웹사이트에 해당합니다.
웹 무게 메트릭
오른쪽 컬럼의 데이터, 즉 (Page Details)를 참조하는 데이터, 특히 Total Page Size에 집중하겠습니다.
언뜻 보기에 이 사이트의 무게는 평균을 훨씬 웃도는 수준이지만, 중요한 것은 사이트의 총 무게가 아니라 그 무게가 로드되는 데 걸리는 시간입니다. Lazy Load라는 것이 있으며, 사용자가 리소스를 필요로 할 때까지 로딩을 지연시키는 기능입니다. 이에 대해서는 나중에 이야기하겠습니다.
위에서 살펴본 패널의 개발자 도구에서도 이 정보를 찾을 수 있습니다. 다시 한번 상기시켜 드립니다.
Google 개발자 도구의 로딩 시간
하단을 보시면, 7.5MB와 215 요청 모두 GTMETRIX가 보고한 수치에 매우 가깝습니다. 다른 도구를 사용하고 싶을 때를 대비해 GTMETRIX가 정보를 어디서 얻는지 아시는 것이 중요합니다.
이제 무엇이 그렇게 무겁고 어떻게 고칠 수 있는지 살펴보겠습니다.
Waterfall 옵션은 리소스가 어떻게 로드되는지의 시각적 보기를 제공하며, 리소스 URL, 상태, 도메인, 그리고 Size 컬럼을 보여줍니다. 마지막 컬럼을 클릭하면 무게가 가장 큰 것부터 작은 것 순으로, 그리고 가장 작은 것부터 큰 것 순으로 정렬합니다.
waterfall을 통한 로드 분석
무게를 보면 대부분의 경우 그렇듯이 이미지가 URL의 과도한 무게를 크게 책임지고 있다는 것을 알 수 있습니다.
이미지의 최대 무게에 대한 공식 사양은 없지만, 100KB 이하를 권장하며, 옵션이 있다면(Photoshop을 사용한다면 있음) 이미지를 JPG로 점진적으로 로드되도록 설정하고 알파 채널(투명도)이 필요하지 않을 때마다 PNG를 피하세요.
이미지 무게를 줄임으로써 사이트의 로딩을 크게 개선할 수 있으며, 사용할 수 있는 도구가 여러 개 있습니다. 저는 개인적으로 Photoshop으로 최적화하지만, 흥미로운 온라인 옵션도 있습니다:
GTMetrix와 Google 도구 모두 리소스를 유형별로 볼 수 있게 해줍니다. 즉, 이미지만, 스크립트만, CSS만...
이는 어디서 작업할지에 대한 더 넓은 관점에 유용합니다. 이 URL에서 이미지는 7.2MB 중 4MB를 차지하므로, 무게 문제의 큰 부분은 거기에 있습니다. 그래도 700KB가 넘는 CSS 파일과 300KB가 넘는 Script 같은 그 유형에 비해 매우 무거운 것으로 두드러지는 다른 리소스가 있습니다.
이 시점에서 로딩 속도 최적화(WPO)를 수행할 때 우리가 작업하기에 손이 닿지 않는 해결책이 있는 특정 문제에 직면해야 한다는 점을 명확히 하고 싶습니다.
이 경우 매우 큰 CSS 파일이 보입니다. 디자이너가 700KB가 넘는 CSS를 만들었다면 그 특정 파일을 최적화하기 어려울 것입니다.
이 파일들의 무게를 줄이기 위해 무엇을 할 수 있나요?
압축 (CSS, JS, HTML)
압축은 주석, 공백, 반복된 코드, 사용되지 않는 코드 같은 불필요한 데이터를 제거해 파일 무게를 줄이려는 프로세스입니다. 이 프로세스를 수행하는 도구는 많지만, 사용되지 않는 코드 부분은 더 어렵게 최적화되며 파일에 수동으로 들어가야 합니다(권장하지 않습니다).
다행히 우리는 WordPress에 대해 이야기하고 있고, 모두 알다시피 WordPress에서는 이 작업을 처리하는 플러그인을 찾지 못하는 것이 매우 드뭅니다.
개인적으로 저는 완전 무료인 Autoptimize와 유료인 WP Rocket을 사용하기를 좋아합니다.
본 글에서는 이 플러그인이 어떻게 작동하는지보다는 최적화 작업을 어떻게 수행할지를 설명하고 싶습니다. 다른 플러그인을 사용한다면 그것들도 이러한 옵션이 있고, 가장 좋은 것은 우리가 무엇을 하고 있는지 이해하는 것이기 때문입니다.
WP Rocket으로 압축
이 부분은 복잡하지 않습니다. 파일 최적화 탭으로 가서 HTML 압축 박스를 체크하기만 하면 됩니다. WP Rocket에서 이 옵션은 CSS와 JS 파일에 대해 아래에서 반복됩니다. 그래도 이 박스를 활성화하고 테스트할 것을 권장합니다. 무언가가 실패하면 문제를 정확히 찾기 더 쉬울 테니, 이 옵션을 한 번에 하나씩 반복하세요.
wp rocket으로 html 압축
압축의 효과를 확인하기 전에 캐시를 지워야 합니다. 그렇지 않으면 업데이트된 HTML의 결과를 보지 못할 것입니다.
브라우저 캐시를 어떻게 지우나요?
이런 종류의 플러그인에는 캐시를 지울 옵션이 함께 제공되며, 상단에서 볼 수 있습니다.
wp rocket으로 캐시 지우기
또 다른 방법은 Google 개발자 도구가 활성화되면(Ctrl + Shift + I) 브라우저를 통해서입니다.
"reload page" 화살표에서 우클릭하고 "empty cache and hard reload"를 선택합니다.
Chrome 브라우저에서 캐시 지우기
Autoptimize로 압축
Autoptimize에서는 optimize 액션이 압축을 수행하며, HTML 주석을 유지할 옵션을 제공하는 특수성이 있습니다. 이러한 주석은 보통 향후에 유용할 수 있는 정보를 유지하기 위해 개발자가 추가합니다.
autoptimize로 html 압축
이 최적화가 적용되었는지 확인하려면 URL의 소스 코드로 가서 다음과 같은 것을 보아야 합니다:
압축된 html 예시
코드는 읽을 수 없게 되지만 그 기능은 동일합니다.
이러한 옵션은 WP Rocket과 Autoptimize에서 CSS와 JS 파일에 대해 같은 방식으로 반복됩니다. 앞서 언급했듯이 모든 것을 한 번에 최적화하는 것은 권장하지 않고 1개씩 합니다. 이러한 플러그인은 압축된 파일의 사본을 보관하므로 해당 박스 체크 해제로 원본으로 되돌리는 것이 가능합니다.
페이지 무게를 계속 줄이기 위해 2가지 옵션이 더 있습니다:
›
로드에 CSS나 JS를 추가하는 플러그인을 제거하거나 줄이기.
›
CSS 파일에서 사용되지 않는 코드를 제거하거나 다듬기.
이 2가지 옵션은 더 복잡하고 더 많은 지식이 필요합니다. 제거하는 부분에 다른 페이지에서의 호출이 없는지 주의하고 확인해야 하기 때문입니다.
플러그인을 제거하는 것은 그것이 제공하는 리소스 때문에 항상 가능하지는 않지만, 다른 것보다 더 잘 최적화된 플러그인이 있습니다. 즉, 더 적은 요청과 더 가벼운 JS를 의미합니다. 그래서 멋진 WordPress 생태계에는 거의 항상 대안이 있습니다.
로딩 시간 vs 응답 시간
이제 요청, 응답 시간, 로딩 시간에 대해 이야기할 시간입니다. 이 시점에서 프로세스의 근본적인 부분인 서버를 언급해야 합니다. 서버 최적화는 보통 우리의 손이 닿지 않으므로 효율적인 솔루션을 선택하는 것이 중요합니다.
하지만 한 단계씩 가봅시다.
요청이란?
요청, 또는 HTTP Request는 주어진 리소스를 요청하기 위해 클라이언트에서 서버로 만드는 호출입니다. 요청은 다른 서버에 도달할 수 있습니다.
요청은 HTTP나 HTTPS일 수 있습니다. 요청의 구조를 보면 시간 지연이 어디서 일어나는지 분석할 수 있습니다.
HTTP 요청 시간 분석
HTTP 요청 구조
이 타이밍 차트에서 보이는 것을 분석해 보겠습니다.
›
요청이 시작되었지만 차단되거나 큐에 있음: 차단이 오래 지속되면 여러 이유 때문일 수 있습니다: 더 높은 우선순위의 요청이나 이 origin에 대한 많은 요청.
›
DNS Lookup: 브라우저가 요청의 IP 주소를 해결하고 있습니다.
›
Connecting: 요청을 해결하기 위해 서버에 연결하는 데 걸리는 시간. 이 시간이 길다면 네트워크 문제, 연결 오류 또는 과부하된 서버를 나타낼 수 있습니다.
›
Sending: 리소스 요청이 보내집니다.
›
Waiting: 이는 서버가 요청을 해결하고 응답을 보내는 데 걸리는 시간입니다; 길다면 서버에 문제가 있습니다.
›
Receiving: 리소스 수신.
HTTPS 요청은 한 단계 더 추가하며, 여기에 표시됩니다.
HTTPS 요청 분석
이 두 스크린샷은 두 개의 다른 사이트에 속하며, 하나는 최적화되지 않은 (HTTP Request) 사이트고 다른 하나는 최적화된 (HTTPS Request) 사이트입니다.
자세히 보고 비교하면 가장 큰 차이는 대기 시간에 있습니다. 이러한 경우 서버를 더 자세히 분석해야 합니다.
서버 요청: 어떻게 줄일 수 있나요?
보셨듯이 요청 수는 로딩 시간과 밀접하게 연관되어 있으므로 요청 수를 줄이면 URL의 로딩 시간이 개선됩니다. 최적화 프로세스에서 상식이 역할을 하며, 리소스가 사용자나 비즈니스에 정말 유용한지 아는 것이 중요합니다. 이는 아무것도 추가하지 않는 특정 리소스에 작별을 고해야 할 순간이지만, 그것을 결정할 사람은 제가 아닙니다.
그래도 이러한 액션이 사이트의 로드에 큰 변화를 가져오지 않더라도 요청을 개선할 수 있는 옵션이 있습니다. 다시 말씀드리지만 가장 좋은 것은 아무것도 추가하지 않는 리소스를 제거하는 것입니다.
CSS와 JS 결합
웹페이지를 최적화할 때 또 다른 인기 있는 액션은 CSS와 JS 리소스를 결합하는 것이지만, 그것은 무엇을 의미할까요?
결합의 목표는 파일 무게를 늘리는 대가로 요청을 줄이는 것입니다. 결합은 다양한 CSS나 JS 리소스를 단일 리소스로 통합하는 것을 의미합니다.
응답 시간이 길다면 결합이 유익할 수 있습니다. 보내는 시간이 매우 느리다면 다른 기법이 더 좋을 수 있습니다.
이상적인 것은 좋은 서버를 가지고 결합하는 것이며, 그러면 양쪽에서 이깁니다.
WP Rocket과 Autoptimize로 리소스 결합
이러한 플러그인으로 결합 작업은 이전처럼 간단합니다. 해당 박스를 체크하기만 하면 됩니다.
wp rocket에서 css 결합
WP Rocket에서 CSS와 JS 결합 옵션은 동일하며, 패널은 거의 동일합니다. 이미지에서 보듯이 결합하고 싶지 않은 파일의 경로를 추가하는 박스가 있습니다.
Autoptimize는 CSS로 작업하고 요청을 줄이기 위한 더 많은 옵션을 제공합니다. 제가 표시한 옵션에서는 결합하고 그것이 미칠 영향에 대한 경고를 주지만, 결국 이는 항상 상대적입니다.
본 글의 이 첫 부분에서는 거의 모든 WPO 최적화 플러그인에서 보통 보이는 특정 기본 액션이 무엇인지 설명하고 싶었지만, 요청과 로딩 시간 모두를 개선하기 위해 우리가 할 수 있는 것이 아직 많이 남아 있습니다.
캐시 구성
의심할 여지 없이 캐시 최적화는 사이트가 어떻게 로드되는지에서 가장 큰 개선을 알아챌 액션 중 하나입니다. 이 WordPress용 SEO 글에서 캐시가 어떻게 작동하는지 설명했습니다. 어떻게 작동하는지 이해하기 위해 살펴보시기를 권장합니다.
Autoptimize와 WP Rocket은 캐싱 액션을 수행하지만 WP Rocket은 몇 가지 옵션을 더 제공합니다. 플러그인이 이 최적화를 더 간단한 것으로 만들었다는 점은 주목할 가치가 있습니다: 옵션은 거의 몇 개 뿐이고 프로세스는 빠르고 무통입니다.
wp rocket 구성
보시다시피 WP Rocket은 4가지를 작업할 수 있게 해줍니다:
›
모바일 디바이스용 캐싱 활성화.
›
모바일 디바이스용 파일 별도 저장.
›
로그인된 사용자용 캐싱 활성화.
›
캐시를 지울 시간 지정.
선택할 옵션은 각 프로젝트에 따라 다르지만, 이 모든 것을 염두에 둔 제 조언은:
›
모바일 캐시는 항상, 대부분의 사이트가 반응형이지만 모바일에는 있고 데스크톱에는 없는 콘텐츠가 있을 수 있기 때문입니다.
›
파일 별도로.
›
로그인된 사용자용 캐시 없음, 무엇보다 편집을 하고 있다면 캐싱을 원하지 않기 때문입니다.
›
캐시 시간, 사이트에 얼마나 많은 변경을 하는지에 따라 다릅니다. 일일 뉴스 사이트라면 짧게, 자주 업데이트되지 않는 콘텐츠라면 더 길게.
Lazyload
Lazyload 기능은 사용자가 필요로 할 때 리소스(이미지와 Iframe)를 표시하는 데 도움이 됩니다. 즉, 브라우저는 사용자가 그쪽으로 스크롤할 때까지 이러한 리소스를 로드하지 않습니다. 이 기능은 많은 플러그인에서 구현되며 일부 WordPress 테마에서는 사전 구성되어 함께 제공되기까지 합니다. Chrome 76 버전부터는 브라우저에 기본으로 함께 제공되기까지 합니다.
이는 loading="lazy" 속성을 추가하면 브라우저가 이미 이미지의 lazy loading을 해석한다는 것을 의미하지만, 물론 모든 브라우저가 이를 해석하지는 않으므로 플러그인을 계속 사용할 것을 권장합니다. web.dev에서 가져온 이미지 lazy loading이 무엇인지 보여주는 비디오가 있습니다.
Iframe 최적화
iframe을 사용해 다른 사이트의 콘텐츠를 임베드한다면, 로드를 개선하기 위해 사용할 수 있는 두 가지 액션이 있습니다.
›
lazyload 함수를 통한 lazy loading
›
또는 사용자가 클릭할 때까지 iframe을 이미지로 교체
첫 번째와 두 번째 옵션 모두 다시 한번 우리의 단골 플러그인 WP Rocket을 통해 활성화할 수 있습니다.
JS 파일은 속도 audit가 페이지의 render blocking이라고 부르는 것의 원인 중 하나입니다. 이는 렌더링하는 동안 브라우저가 JS 파일을 다운로드하고 실행하기 위해 멈출 때 일어납니다. WPO 최적화의 목표는 가능한 한 빨리 사용자에게 정보를 전달하는 것이며, 이러한 이유로 이는 차단으로 간주됩니다. 다운로드된 JS가 실행될 때까지 아무것도 렌더링되지 않기 때문입니다.
그래서 이러한 유형의 액션이 audit에서 표시되는 경향이 있습니다. 잘 최적화되지 않은 서드파티 플러그인이나 테마를 사용할 때, 예를 들어 헤더에 있어서 렌더링을 차단하는 JS를 가질 수 있습니다.
이러한 경우 JS 호출 코드에 추가되는 두 속성, Defer와 Async를 사용해야 합니다. 이러한 속성이 작동하려면 스크립트가 외부여야 합니다.
두 속성 모두 JS에 의해 DOM HTML 해석이 멈추는 것을 방지하는 비슷한 목표를 가지지만, 둘 사이에는 주목할 만한 차이가 있습니다.
Async 속성으로 리소스는 HTML 로딩을 멈추지 않고 다운로드되지만, 다운로드되면 HTML 로딩이 일시 중지되어 JS를 실행합니다; defer 속성으로 리소스도 HTML 로딩과 병렬로 다운로드되지만 로딩이 끝날 때 실행되므로 스크립트에 의한 차단이 없습니다.
이와 관련해 WP Rocket과 Autoptimize 사이에 차이가 있습니다. WP Rocket은 결정을 훨씬 더 쉽게 만들고 JS가 렌더링을 차단하지 않도록 반자동 방식으로 작동합니다; 반면 Autoptimize에서는 Async 옵션만 토글할 수 있습니다.
Autoptimize에서는 추가 탭 아래에 Async로 로드하려는 JS 파일을 추가할 이 옵션이 있지만, 더 큰 유연성을 위해 또 다른 보조 플러그인 "Async Javascript"를 권장합니다.
autoptimize 비동기 로드
이 플러그인으로 Defer와 Async 모두 작업할 수 있고, 일을 더 쉽게 만들기 위한 원클릭 옵션도 제공합니다. 이 플러그인의 좋은 점은 스크립트로 작업할 수 있고 필요하다고 여기는 것을 제외할 수 있다는 점입니다. 반면 WP Rocket에서는 플러그인이 하는 것을 신뢰해야 합니다. 그래도 잘 합니다.
이 옵션은 같은 파일 최적화 탭에 있습니다.
wp rocket defer 속성
CDN이란 무엇이고 어떻게 도움이 될 수 있나요?
CDN은 콘텐츠 전송 네트워크라고 알려진 것입니다. CDN은 이러한 리소스에 대한 서버의 부하를 덜고 로드에 더 잘 응답하기 위해 정보와 리소스의 일부를 저장하는 일을 담당합니다. CDN에는 또한 사용자가 어디서 연결하든 사용자에게 리소스를 제공하기 위해 다양한 지점에서 리소스를 사용 가능하게 유지하는 지리적 사본 기능도 있습니다. 보통 이런 종류의 서비스는 이미지와 비디오 같은 무거운 파일에 사용됩니다.
이 서비스에 가입하는 것은 트래픽이 많은 사이트가 있을 때 중요하지만, 트래픽이 적은 사이트에 대해서도 배제해서는 안 됩니다.
좀 더 개선을 가져올 다른 액션
글을 마무리하기 위해 로딩 시간에 큰 변화를 가져오지는 않지만 요청을 줄이는 데 도움이 될 3가지 더 많은 개선이 있으며, 결국 그것이 우리가 원하는 것입니다.
글꼴 최적화
글꼴 최적화는 플러그인이나 CSS를 편집 및 최적화하는 수동 방식으로 할 수 있습니다. 이상적인 것은 사용할 글꼴만 호출하고 많은 경우에 일어나듯 모든 Google Fonts 파일을 다운로드하지 않는 것입니다.
Autoptimize에는 글꼴 작업을 위한 옵션이 있습니다.
autoptimize로 글꼴 최적화
프로젝트를 보지 않고 어떤 옵션을 선택할지 말하기는 어렵습니다. 템플릿이 어떤 글꼴을 사용하고 언제 로드하는지 모르기 때문에 가장 좋은 것은 테스트해 보고 결과를 보는 것입니다.
보시다시피 Google Fonts 옵션 바로 다음에 "Remove Emoji"가 있으며, 이는 서버 요청을 절약해 줍니다. 그 함수는 단순히 emoji를 나타내는 기호를 아이콘으로 변환하는 것입니다.
wp rocket emoji
WP Rocket은 또한 이러한 emoji를 비활성화할 수 있게 해주며, 또한 콘텐츠가 서드파티 사이트에 임베드되는 것을 방지하는 옵션도 제공합니다.
결국 사이트의 로딩 속도를 개선하기 위한 액션은 많이 있습니다. 모든 리소스를 최적화하기 위해 깊이 작업하는 것이 항상 가능한 것은 아닙니다. 비즈니스 유형과 그것이 필요로 하는 것에 따라 다르기 때문입니다.
이 WPO 최적화 가이드가 도움이 되고 여러분의 프로젝트나 클라이언트를 위해 적용할 수 있기를 바랍니다.
지난 10년 넘게 SEO에 완전히 빠져 살아왔습니다 — 솔직히 다른 길을 가고 싶지도 않았어요.
제 커리어가 한 단계 도약한 것은 인터넷 전체에서 방문자가 가장 많은 100개 사이트 중 하나인 Chess.com에서 시니어 SEO 스페셜리스트로 일했을 때입니다. 수백만 페이지, 수십 개 언어, 그리고 가장 경쟁이 치열한 SERP 중 하나에서 일한 경험은 어떤 강의나 자격증도 가르쳐주지 못하는 것들을 알려주었습니다. 이 경험은 진정으로 훌륭한 SEO가 어떤 모습이어야 하는지에 대한 제 관점을 완전히 바꾸어 놓았고, 이후 제가 만든 모든 것의 기초가 되었습니다.
이 경험을 바탕으로 SEO Alive를 창업했습니다 — 오가닉 성장에 진심인 브랜드를 위한 에이전시입니다. 우리는 대시보드와 월간 리포트를 파는 것이 목표가 아닙니다. 실제로 결과를 움직이는 전략을 만들어, 클래식 SEO의 최고와 흥미진진한 새로운 Generative Engine Optimization(GEO) 세계를 결합합니다 — 여러분의 브랜드가 Google의 파란 링크뿐 아니라 ChatGPT, Perplexity, Google AI Overviews가 매일 수백만 명에게 전달하는 AI 생성 답변 안에도 노출되도록 합니다.
그리고 이 두 세계를 제대로 다루는 도구를 찾을 수 없어서 직접 만들었습니다 — SEOcrawl입니다. 랭킹, 기술 감사, 백링크 모니터링, 크롤 건전성, AI 브랜드 가시성 추적을 한 곳에서 통합하는 엔터프라이즈 SEO 인텔리전스 플랫폼이죠. 항상 존재하기를 바랐던 바로 그 플랫폼입니다.
