코드 멀쩡한데 트래픽 떨어졌다면? 배포 전 SEO 장애 막는 품질 게이트 전략

트래픽이 갑자기 떨어졌는데, 무엇이 바뀌었는지 아무도 모릅니다. SEO 실무자라면 한 번쯤 겪어 봤을 장면입니다. 지난 9월 3일과 4일 서울 마포에서 열린 ‘Search SEOul(서치 서울) 2026’에서는 이 익숙한 장면을 출발점으로 삼은 발표가 있었습니다. 올해 2회째인 서치 서울은 해외에서 주로 열리던 글로벌 SEO 컨퍼런스를 한국에서 열고, 한국 검색 환경과 해외 SEO·GEO 흐름을 함께 다루는 행사입니다.

요즘IT는 서치 서울 2026의 공식 미디어 파트너로서, 행사 발표 가운데 요즘IT 독자에게 도움이 될 만한 내용을 골라 전문을 소개하고 있습니다. 이번 글은 행사 둘째 날 오전, 아스펜 그룹(The Aspen Group)에서 AI 기반 SEO를 이끄는 조리 포드(Jori Ford) 시니어 디렉터가 ‘SEO Needs Quality Gates, Not Audits(SEO에 필요한 건 감사가 아니라 품질 게이트다)’라는 제목으로 발표한 내용입니다. 개발팀이 코드를 배포하기 전에 거치는 자동 검사 단계에 SEO 점검을 끼워 넣어, 문제가 터진 뒤에 찾아내는 대신 배포 전에 막자는 제안입니다. 영어로 진행된 발표를 한국어로 옮겼고, 발표 말미의 질의응답도 함께 실었습니다.

앞선 세션에서 감사(audit), 그러니까 사이트를 기술적으로 점검하는 이야기가 많이 나왔습니다. 우리 SEO 실무자들은 감사를 정말 자주 하죠. 그래서 본론에 들어가기 전에 이야기를 하나 들려 드리려고 합니다. 감사를 해 본 분이라면 대부분 어떤 식으로든 겪어 봤을 이야기, 한마디로 개발 작업이 SEO를 망가뜨린 이야기입니다.

코드는 멀쩡했는데, 트래픽이 떨어졌습니다

매일 애널리틱스를 들여다보는데 모든 게 순조롭습니다. 오가닉 트래픽도 아주 좋습니다. 그러다 트래픽이 떨어집니다. 여러분은 아무것도 하지 않았는데요. 그럼 트래픽은 왜 떨어졌을까요? 상사나 클라이언트에게서 무슨 일이냐는 전화가 오고, 여기저기 다 뒤져 봐도 답이 없습니다.

보통 그다음에는 웹사이트에, 기술 쪽에 무슨 일이 있었는지를 떠올립니다. 그래서 배포 이력, 새로 반영된 것들을 찾아봅니다. 엔지니어에게 “코드 배포한 거 있어요? 뭔가 잘못한 거 아니에요?” 하고 묻죠. 그런데 핵심은 바로 이 ‘잘못’이라는 말에 있습니다. 엔지니어는 잘못한 게 아닙니다. 원인이 엔지니어가 한 작업인 경우가 대부분이긴 하지만요.

이 이야기는 SEO 담당자가 엔지니어에게 요청한 수정이, 엔지니어의 손을 거쳐 결국 SEO에 해를 끼친 이야기입니다. 코어 웹 바이탈(Core Web Vitals)은 다들 아실 겁니다. 성능을 높이려고 엔지니어에게 코어 웹 바이탈을 개선해 달라고 요청해 본 분도 많을 거고요. 이 사례에서는 CLS(Cumulative Layout Shift, 누적 레이아웃 이동)를 개선하려는 코어 웹 바이탈 수정이 배포됐는데, 그 수정이 DOM을 망가뜨렸습니다. title 태그를 엉뚱한 곳으로 옮겨 버렸거든요. SEO 담당자가 SEO 문제이자 사용자 경험 문제를 풀어 달라고 엔지니어에게 요청했는데, 그 결과가 SEO를 해친 겁니다.

전날 발표에서 오케스트레이션, 즉 여러 부서의 일을 조율하는 이야기를 아주 잘 풀어 줬는데요. 부서마다 목표가 다르게 정해져 있습니다. 엔지니어에게 코어 웹 바이탈 수정을 요청하면 어떻게 될까요? 엔지니어는 성능을 고치려고 합니다. 이 사례에서 문제는 코드가 아니라 DOM이었습니다.

구글 문제가 아니라 크롤러 문제입니다

우리는 이런 일을 SEO 문제로 여길 때가 많습니다. 구글이 특정한 기술 작업을 하도록 우리를 몰아붙이니까요. 우리에겐 가이드라인이 있습니다. 전날에도 전략적으로 콘텐츠와 기술에 집중하라는 이야기를 들었고, 맞는 말입니다. 기술을 고치기 위한 구체적인 가이드라인이 있죠. 그런데 여기서 핵심은 ‘고친다’는 말입니다. 망가지지 않은 걸 어떻게 고칩니까?

크롤러가 여러분의 정보와 데이터에 접근하려면 아주 구체적인 무언가가 필요합니다. 크롤러는 그 정보를 뽑아낼 때 일관되게 DOM을 활용합니다. 그러니 DOM이 구조를 갖추고 있어야 합니다. 코드를 위계에 맞게 구조화하라는 말, 구조화 데이터가 있어야 코드를 이해할 수 있다는 말을 얼마나 자주 듣습니까? 그러니 이건 구글 문제가 아니라 크롤러 문제입니다.

제 발표를 들어 본 분은 아시겠지만, 저는 크롤러를 정말 좋아합니다. 그 기반이 되는 층을 이해하지 못하면 SEO 일을 제대로 해낼 수 없다고 생각합니다. 모든 게 크롤러와 연결돼 있습니다. 그리고 모든 게 크롤러와 연결돼 있다면, 기술은 우리 모두가 일을 잘 해내는 데 필요한 토대입니다. 그 토대가 깨지면 우리는 실패합니다. AI 답변도 크롤러를 쓰고, 쇼핑 봇도 크롤러를 씁니다. 구글도 네이버도 모두 크롤러에 기대고 있습니다. 이게 핵심입니다.

이 크롤러들은 아주 특화된 구조를 요구합니다. 그 때문에 우리는 팀의 다른 구성원들에게 그 구조를 대신 만들어 달라고 가르쳐야 했습니다. 저는 이걸 바꾸고 싶습니다. 우리가 팀과 더 나은 파트너, 더 나은 오케스트레이터가 되도록 돕고 싶어요. 기술이 그 토대라면, 우리가 해야 할 단 한 가지는 엔지니어링팀과 더 나은 파트너가 되는 겁니다.

어떻게 하면 될까요? 저는 엔지니어에게 무엇을 고치라고 지시하고 감사를 하는 대신, 우리가 그들의 프로세스 안으로 들어가자고 제안합니다. 파트너의 프로세스를 들여다보고, 거기에 녹아드는 겁니다.

엔지니어가 매일 쓰는 CI/CD 파이프라인

그래서 먼저 소개하고 싶은 게 대부분의 엔지니어가 매일 일하는 방식, CI/CD 파이프라인입니다. 발표장에서 물어보니 아는 분이 많지 않더군요. 에이전시든 컨설팅이든 인하우스 SEO든, 엔지니어는 여러분을 돕고 지원해 줘야 하는 사람들입니다. 그들의 지원을 받으려면 여러분도 그들이 하는 일을 이해해야 합니다.

여러분이 수정 요청을 보내거나, 감사 결과를 들고 가서 뭔가 망가졌다고 말하면 엔지니어 쪽에서는 이런 일이 일어납니다. 티켓이 들어가고, 그 티켓은 피처 브랜치(feature branch)에서 작업됩니다. 엔지니어는 코드를 작성해 저장소(repository)라는 곳에 푸시합니다. 이 저장소는 엔지니어가 일을 잘 해낼 수 있도록 짜여 있어서, 코드를 푸시하면 자동으로 CI 파이프라인을 거칩니다.

CI 파이프라인은 한마디로 사전 테스트입니다. 망가진 코드를 내보내지 않도록 미리 확인하는 장치죠. 그런데 SEO는 코드가 망가졌느냐 고쳐졌느냐의 문제가 아닙니다. 우리는 엔지니어에게 우리가 원하는 대로 코드를 리팩터링하고 수정해 달라고 요청하는 겁니다. 엔지니어는 뭔가를 망가뜨리는 게 아니라, 무엇을 내보내야 하는지 모를 뿐입니다. 그래서 저는 우리가 이 파이프라인의 일부가 되자고 제안합니다. CI 단계에서 우리만의 테스트를 만들어 엔지니어를 돕자는 거죠.

CI 다음은 코드 리뷰입니다. 다른 엔지니어가 코드를 검토하면서 도와주고, 제대로 됐는지 확인합니다. SEO 쪽에서도 비슷한 걸 합니다. 사이트에 이런 작업을 했는데 한번 봐 줄 수 있는지, 괜찮아 보이는지 서로 묻습니다. 그런데 우리가 놓치는 게 있습니다. 엔지니어의 코드 리뷰는 다른 엔지니어가 웹사이트와 코드를 보고 망가지지 않았는지를 확인하는 일이라는 점입니다. 망가진 게 없으니 무엇을 고쳐야 하는지도 모릅니다.

코드 리뷰를 마치면 코드는 병합(merge)돼 프로덕션에 배포됩니다. 우리가 실패하는 지점이 바로 여기입니다. 엔지니어는 탄탄하고 잘 작동하는 코드를 병합해 내보냈는데, 그 코드가 사용자에게는 아무 문제가 없지만 우리에게는 문제가 되는 겁니다.

감사 대신 품질 게이트

그래서 제 제안은 이렇습니다. 앞선 세션에서는 감사를 많이 하라고 했는데, 이 대목에서만큼은 반대 의견을 내겠습니다. 저도 많은 것을 감사해야 한다고 생각합니다. 다만 기술 감사는 그만두고, 이미 있는 파이프라인에 참여하자는 겁니다. 그게 선제적인 방식입니다. 감사는 낡은 방식입니다. 엔지니어가 자기 일을 다 끝낸 뒤에야 돌아가니까요. 누군가 일을 잘 해냈는데 “잘하긴 했는데, 아주 잘못했어요”라는 말을 듣는다고 생각해 보세요. 아무도 그런 말을 듣고 싶어 하지 않습니다.

엔지니어는 일을 잘 해냈고, 우리는 그걸 인정해 주고 싶습니다. 그러니 너무 늦게, 수동으로 또는 정해진 일정에 따라 돌아가는 감사 대신 선제적인 품질 게이트(quality gate) 절차로 바라보자는 겁니다. 다들 스크리밍 프로그(Screaming Frog), 셈러시(Semrush), 에이레프스(Ahrefs) 같은 도구로 기술 감사를 돌리실 겁니다. 그리고 너무 늦게 알게 되죠. 트래픽은 이미 빠졌고, 엔지니어는 이미 수정을 배포했고, 이제 진짜 문제도 아닌 문제를 찾느라 엄청난 시간을 허비합니다.

품질 게이트는 문제가 생기기 전에 작동합니다. 문제가 밖으로 나가지 않으니 오가닉 트래픽이 깨질 일도 없고, 엔지니어가 일을 잘못했다는 말을 들을 일도 없습니다. 감사를 하면 우리는 피해를 찾아냅니다. 방식을 바꾸면 피해를 막을 수 있습니다. 사후 대응에는 돈과 시간이 들고, 우리 브랜드와 클라이언트도 타격을 입습니다. 그런데 엔지니어들은 이미 예방하는 시스템을 만들어 뒀습니다. 우리가 하고 싶은 것도 예방입니다.

그럼 어떻게 할까요? 엔지니어 친구들에게서 조금 빌려 오겠습니다. 엔지니어의 기존 파이프라인에는 지금 빠져 있는 게 있습니다. DOM을 보지 않는다는 점입니다. 엔지니어의 머릿속에 DOM은 없습니다. 엔지니어가 확인하는 건 웹사이트가 제대로 작동하느냐입니다. 버튼이 작동하는지, 폼을 채울 수 있는지, 올바른 응답이 오는지요. DOM이 망가졌는지는 보지 않습니다.

그래서 CI/CD 파이프라인 안에 DOM 렌더링 확인을 넣습니다. 이를 위한 스크립트를 우리가 직접 만들어 게이트를 세워 줍니다. 그러면 엔지니어는 코드를 내보낼 때 통과했는지 실패했는지를 그 자리에서 알게 됩니다. 문제 있는 코드를 내보내면 프로덕션에 가기 전에 거기서 멈춥니다. 플래그가 붙으니 미리 경고할 수 있는 거죠.

그리고 우리 자신에게 필요한 것, 피드백 루프를 닫는 일입니다. 뭔가 배포됐는데 우리는 전혀 모르는 경우가 얼마나 많습니까? 무언가 망가졌을 수 있다는 것도, 어떤 기능이 출시됐다는 것도 모르죠. 하지만 우리가 게이트의 일부가 되면 우리만의 피드백 루프를 만들 수 있습니다. 슬랙이나 팀즈 알림, 문자 메시지, 이메일로 우리에게 알림이 오게 하면 됩니다.

작은 수정이 큰 장애로 번지는 네 지점

제가 이게 왜 그렇게 중요하다고 생각할까요? 제 SEO 커리어의 90%는 기술에 관한 일이었습니다. 그 경력으로 CMO가 됐고, 이어 최고제품책임자(CPO)가 됐다가 지금은 다시 인하우스로 돌아왔습니다. 그런데 2000년대 초에 제가 풀던 바로 그 근본적인 문제가 여전히 그대로였습니다. 테크니컬 SEO로서 매번 똑같은 문제를 봐야 했습니다. title 태그가 엉뚱한 곳에 들어가 있거나, canonical 태그 때문에 색인이 망가지는 문제 말이죠. 배포된 작은 변경이 SEO에는 큰 장애를 일으켰습니다.

그리고 그건 우리가 그 작은 것들을 요청했기 때문에 벌어진 일이었습니다. 이커머스 사이트 템플릿에 프로그래매틱 SEO를 요청했는데, 그 템플릿에 뭔가가 배포되면서 DOM 전체가 다시 배치되고 잘못된 상태로 나가 버립니다. 스키마 마크업 변경을 요청했더니, CMS는 한쪽에서 스키마를 넣고 있는데 템플릿 단에서는 클라이언트 사이드에서 또 넣고 있습니다. 이런 일들이 모두 우리에게 큰 혼란을 일으킵니다. 예를 들어 보겠습니다.

title 태그 위치

렌더링된 head 코드에 title 태그가 없다면 구글이든 네이버든, 어떤 검색엔진이든 그 태그가 있다는 걸 알 수 있을까요? 모릅니다. 작은 수정 하나가 렌더링 결과를 바꿔 버리면 이제 여러분 페이지에는 title이 없습니다. 구글은 제멋대로 제목을 만들어 내고, 여러분 브랜드는 마땅히 나와야 할 모습으로 검색 결과에 나오지 않습니다. 품질 게이트가 있었다면 렌더링된 DOM에서 title이 head 안에 있는지 확인하고 엔지니어에게 경고했을 겁니다.

레이아웃 이동

우리는 앞으로도 코어 웹 바이탈 개선을 계속 요청할 겁니다. 그런데 문제가 있습니다. CLS까지 내려가면 엔지니어가 고칠 수 있는 방법은 몇 가지로 정해져 있습니다.

그 시간을 줄이려고 엔지니어가 가장 먼저 꺼내는 해법이 DOM을 다시 배치(reflow)하는 겁니다. 여러분은 그 몇 밀리초가 아주 값지다고 생각할지 모릅니다. 하지만 그 대가로 색인에서 빠질 위험을 감수해야 한다는 걸 안다면, 아마 그 몇 밀리초는 포기할 겁니다. 초록색(양호)으로 만드는 대가가 구글이 더는 페이지를 크롤링하지 못하는 거라면, CLS가 노란색(개선 필요)이어도 괜찮다고 할 겁니다.

이걸 품질 게이트에 넣으세요. DOM을 다시 배치해도 좋지만 다른 걸 망가뜨리지는 말라는 걸 엔지니어가 알게 하는 겁니다. 우리가 감수할 수 있는 최소선, 즉 임계치를 정해 두면 게이트가 경고해 줍니다.

스키마 마크업

게이트에 또 무엇을 넣을 수 있을까요? 스키마 마크업입니다. 이번 행사에서 모두가 AI 이야기를 했고, 구조 이야기를 했고, 검색 결과에 노출되고 싶다는 이야기를 했습니다. AI는 페이지의 맥락을 이해할 때 구조화 마크업에 크게 의존합니다. 그런데 스키마 마크업의 구조가 잘못돼 있거나, 중첩이 제대로 안 돼 있거나, 두 번 삽입돼 있으면 AI는 이해하지 못합니다. 그러니 스키마가 제대로 나오는지 확인하는 것도 게이트에 넣으세요.

이 게이트들이 중요한데도 아직 표준이 아닌 이유, 그리고 제가 이 이야기를 하는 이유는 SEO가 그렇듯 모든 조정이 브랜드마다, 작동 방식마다 제각각이기 때문입니다. 이 모델도 마찬가지입니다. 엔지니어가 일하는 방식, 템플릿을 코딩하는 방식, 어떤 CMS를 쓰는지, 애초에 이걸 문제로 보는지에 따라 달라집니다. 이런 패턴이 여러분 비즈니스에는 아예 없을 수도 있고, 하나만 발견될 수도 있습니다.

canonical 태그와 meta robots

제게 가장 치명적인 건 이겁니다. 저는 제 사이트가 색인에서 빠지는 걸 원하지 않습니다. 중복 콘텐츠도 원하지 않습니다. 어떤 페이지가 가장 중요한지 검색엔진이 알 수 있도록 그렇게 공을 들였는데, 템플릿에 대한 CMS 업데이트 한 번이 그걸 전부 망칠 수 있습니다. 게이트에 넣는다면, 파트너를 돕는다면 그런 일은 없습니다.

실제로 돌아가는 게이트

그래서 실제로는 어떤 모습일까요? 이렇게 말로만 하면 듣기 좋은 이야기처럼 들린다는 걸 압니다. 게이트에 넣으면 될 것도 같지만, 정말로 작동합니다. 제가 게이트를 직접 만들었습니다. 저는 발표할 때마다 오늘도, 내일도, 앞으로도 쓸 수 있는 자료를 남기려고 합니다. 그래서 누구의 파이프라인에든 오늘 바로 덧붙일 수 있는 기본 구조의 게이트를 만들었습니다. 기존 파이프라인을 흔들 필요가 없습니다. 깃랩(GitLab)이나 깃허브(GitHub) 같은 곳에 이 액션을 추가하면 됩니다.

엔지니어에게는 이게 어떻게 보일까요? 발표장에서는 시연 영상으로 보여 드렸습니다. 엔지니어가 코드를 배포하려는 장면입니다. 사실 영상 속 사람은 제 코드를 배포하는 저지만, 배포 과정은 똑같습니다. 엔지니어가 병합 요청(merge request)을 올리면 무슨 일이 일어나는지 보여 드리고 싶었습니다. 오늘 당장 실시간으로 할 수 있는 일이라는 걸 아셨으면 해서요. 엔지니어가 보게 되는 게 바로 이 게이트입니다. 코드를 내보낼 때 회귀 테스트가 돌고, 액션이 실행됩니다.

그러면 게이트가 빨간 플래그를 띄우고 무엇을 해야 하는지 알려 줍니다. 엔지니어는 그걸 검토할 수 있습니다. 게다가 저는 이미 슬랙에 연결해 뒀습니다. 그래서 여러분도 SEO 알림을 받는데, 엔지니어용이 아니라 여러분이 이해할 수 있는 쉬운 말로 옵니다. 어디를 살펴봐야 하는지, 엔지니어가 무엇을 배포했는지, 엔지니어와 무슨 이야기를 해야 하는지 알 수 있습니다. 그리고 나중에 엔지니어가 그걸 고쳤는지도 다시 확인할 수 있습니다.

품질 게이트의 좋은 점이 여기 있습니다. 게이트가 엔지니어의 코드 배포를 멈추니까, 엔지니어는 코드를 검토하고, 문제가 무엇인지 이해하고, 코드를 어떻게 리팩터링할지 정한 뒤 다시 내보낼 수 있습니다. 엔지니어도 원인을 파악하는 시간을 아끼고, 여러분도 시간과 돈을 아낍니다.

잘 통과하면 이렇게 됩니다. 품질 게이트가 돌고 모든 게 잘되면 엔지니어는 초록색 체크 표시를 봅니다. 그리고 무엇을 제대로 했는지 쉬운 말로 설명을 받습니다. 엔지니어가 배웠으니 같은 실수를 할 가능성도 줄어듭니다.

AI를 붙이면 게이트도 배웁니다

앞서 말했듯 게이트는 엔지니어를 막기만 하는 게 아닙니다. 엔지니어도 배우고, 여러분도 배웁니다. 지금 보여 드린 건 정적인 버전입니다. 이 정도로도 꽤 잘 돌아가고, 저는 마음에 듭니다. 각자 자기 방식으로 고쳐서 핵심 요소를 챙기면 된다고 생각합니다.

그런데 이걸 더 낫게 만들 수 있다면요? 저는 뭐든 더 낫게 만드는 걸 좋아하고, AI 시대에는 훨씬 더 낫게 만들 수 있다고 생각합니다. AI API와 연동하면 게이트가 스스로 학습합니다. 새로운 패턴이 보이면 그 패턴을 넣어 품질 게이트를 업데이트할 수 있습니다. 이런 일이 쌓일수록 AI가 더 잘 알아보고, 플래그가 많이 붙을수록 여러분은 어떤 새 습관을 들여야 하는지 알게 됩니다. 이제 엔지니어도 배우고 게이트도 배웁니다. 코드도 좋아집니다.

그렇게 배포를 이어 가면서 우리가 그만둔 게 있습니다. 감사를 그만뒀습니다. 엔지니어가 일을 잘하는 걸 가로막는 것도 그만뒀습니다. 그러면서도 우리 일은 빈틈없이 해냅니다. 우리 스스로 걸림돌이 되지 않는 겁니다. 우리 성과를 깎아 먹는 수정을 요청하는 건 우리에게 도움이 안 됩니다. 우리 시간도, 엔지니어의 에너지도 낭비합니다. 수정을 요청했는데 기술 부채 우선순위 목록 어딘가에 올라가서 언제 처리될지 영영 모르는 경우가 얼마나 많았습니까? 이제 그런 일은 없어야 합니다. 이게 그 해법입니다.

게이트가 배우면 여러분도 배우고, 여러분이 배우면 여러분이 남기는 코멘트가 좋아지고, 코멘트가 좋아지면 시스템 전체가 좋아집니다.

저는 이게 다른 부서와의 진정한 오케스트레이션이자 파트너십이라고 생각합니다. 이제 우리는 친구이자 동맹이고, 합리적이고 책임감 있게 함께 일합니다. 그리고 여러분에게는 숨 돌릴 여유가 생깁니다. 테스트하고 모델링할 여유, 파트너가 자기 일을 잘 해낼 거라고 믿을 여유 말이죠. 파트너도 여러분을 믿을 수 있습니다. 이제 여러분이 그들이 무엇을 상대하는지 이해하고, 그들이 매일 일하는 제약 안에서 함께 일하니까요.

어떤 도구로, 어떻게 들여올까

이런 게이트가 어떻게 돌아가는지 더 잘 이해하고 싶다면 아래 도구들을 익혀 보길 권합니다. 대부분 무료이고, 엔지니어가 자기 쪽에서 바로 적용할 수 있는 도구입니다.

제가 만든 저장소는 누구나 쓸 수 있습니다. 제 깃허브에 올려 뒀으니 링크드인으로 연락 주세요. 답이 조금 늦을 때가 있어서, 행사 중 점심 전이나 쉬는 시간에 저를 붙잡아 주시면 연결해서 저장소를 공유하고 사용법도 안내해 드리겠다고 말씀드렸습니다. README를 꼼꼼하게 써 뒀으니 엔지니어와 함께 보셔도 됩니다. 다만 기본 저장소이니, 여러분이 이걸 바탕으로 더 발전시키면 좋겠습니다.

헤드리스 브라우저·DOM 테스트

플레이라이트(Playwright)와 퍼피티어(Puppeteer)는 엔지니어 대부분이 이미 알고 있을 겁니다. 브라우저를 헤드리스로 띄워 크롤링이나 추출, 리모델링을 해 본 사람이라면 익숙한 도구입니다.

성능 예산

코어 웹 바이탈을 다룬다면 라이트하우스(Lighthouse) 같은 도구를 쓰는 게 좋습니다. 직접 연동할 수 있습니다.

스키마 검증

구글이 제공하는 도구에 직접 연결하길 권합니다. 무료 API를 써서 처리할 수 있습니다.

크롤링 비교

엔지니어에게도, 우리에게도 정말 중요한 부분입니다. 엔지니어는 코드 수준에서 차이를 보고, 여러분은 여러분 쪽에서 두 환경의 차이를 볼 수 있습니다. 스크리밍 프로그를 권합니다. 엔지니어가 보는 코드와 비교할 수 있고, 엔지니어는 자기 환경에서 확인하면서 서로 메모를 공유하고 이야기를 나눌 수 있습니다.

CI/CD 연동

엔지니어에게 파이프라인이 있는지 모르거나 함께 다뤄 본 적이 없다면 그냥 물어보면 됩니다. 깃허브나 깃랩을 쓰는지, 그 밖의 비슷한 도구를 쓰는지요. 엔지니어가 정확한 답을 못 하면 “브랜치는 어떻게 보호하고 있어요?”라고 물어보세요. 그 답이 아마 여러분이 찾는 파이프라인일 겁니다.

이런 도구를 쓸 때 꼭 알아 두셨으면 하는 게 있습니다. 이걸 엔지니어에게 들고 가서 “오늘 당장 이걸 적용하고 매번 돌려야 합니다”라고 말하면 안 됩니다. 엔지니어는 그렇게 일하지 않습니다. 자기들 게이트를 만들 때도 먼저 시험해 봅니다.

그러니 이런 걸 도입한다면 기존 파이프라인과 나란히 돌려 달라고 요청하세요. 독립적으로 실행되는 액션으로 두고, 필수가 아니라 선택으로 두세요. 이게 잘 작동한다는 걸 엔지니어가 직접 보게 하고, 여러분이 그들의 일하는 방식을 이해하고 있다는 걸 보여 주세요. 그래야 두 부서 사이에 신뢰가 쌓입니다.

혼자든, 에이전시든, 인하우스든 오늘 시작할 수 있습니다

저는 이 방식이 우리 모두에게 통한다고 생각합니다. 컨설턴트도, 에이전시도, 인하우스도 계실 텐데, 어느 경우에나 기회가 됩니다.

• 혼자 일한다면 직접, 독립적으로 돌려 보세요. 파트너에게 그들의 깃허브 저장소에서 나란히 돌려 봐도 되는지, 내 브랜치를 따로 운영해도 되는지 물어보세요. 적어도 그들이 지금 무엇을 배포하는지, 어디에 기회가 있는지 이해할 수 있고, 더 나은 대화를 나눌 수 있습니다. 내가 그들을 어떻게 도울 수 있을지도 보입니다.
• 에이전시라면 영업에 쓰기 아주 좋은 기본 상품입니다. 지금 이걸 하는 곳은 없습니다. 저는 아무도 하지 않는 걸 가져오는 걸 좋아합니다. 개념적으로 우리가 더 잘할 수 있다고 생각하니까요.
• 인하우스라면 오늘 바로 엔지니어에게 가서 정말 멋지다고 말해 주세요. 오늘 배운 걸 이야기하고, 이걸 함께 세팅해서 시험해 봐도 되는지 물어보세요.

질의응답

발표 말미에는 사전에 받은 질문 두 가지에 답하고, 현장 질문을 하나 받았습니다.

Q. 사이트가 색인은 되는데 노출과 트래픽이 거의 없습니다. 구글 디스커버(Google Discover)에 들어가려면 무엇이 가장 중요할까요?

기술 주제에서 조금 벗어난 질문이라고 생각하실 수 있지만, 저는 SEO로서 이것저것 두루 다뤄 왔으니 답해 보겠습니다. 사이트 이름을 소리 내어 말하진 않겠습니다. 구글 디스커버에 들어가고 싶은 블로그입니다. 제가 보기에 이 블로그는 색인은 아주 잘 되고 있는데, 원하는 만큼의 노출과 키워드 클릭이 나오지 않는 게 문제입니다.

간단히 살펴봤더니 크게 두 가지 문제가 보였습니다. 첫째는 우리 SEO 실무자들이 즐겨 이야기하는 코어 웹 바이탈입니다. 코어 웹 바이탈은 사용자 경험을 이해하는 방법이고, 지금 좋은 사용자 경험을 제공하고 있느냐에 대한 구글의 해석일 뿐입니다.

이 사이트에는 사이트 전체가 렌더링되기 전에 먼저 렌더링되는, 존재감이 아주 강한 광고가 있습니다. 스스로 콘텐츠를 가려 구글이 접근하지 못하게 막고 있는 셈이죠. 그러니 코어 웹 바이탈 성능부터 챙기세요. 우선 렌더링을 막는 요소를 모두 걷어내 콘텐츠에 실제로 접근할 수 있게 해야 합니다. 지금은 구글이 콘텐츠를 보지 못하고 있으니까요.

둘째, 이 사이트는 여행 분야인데, 여행 분야에서는, 특히 한국에서는 E-E-A-T, 그중에서도 전문성을 봅니다. 블로그를 둘러보니 전문 여행 업체가 없었습니다. 여행사를 대변해 이야기하는 사람도, 이 분야에서 이력을 쌓은 사람도 없었습니다. 권위 측면에서도 문제가 있습니다. 이 사이트를 가리키는 권위 있는 사이트가 없고, 이 사이트도 그런 사이트를 가리키지 않습니다. 데이터를 가져오는 정부 사이트들은 관련성이 있습니다. 하지만 이 사이트가 관련성을 얻으려면 전문가들도 이 사이트를 가리켜야 합니다.

Q. 새로 낸 앱을 앱 스토어에서 더 많이 내려받게 하려면 어떻게 해야 할까요?

처음에는 답하지 못할 줄 알았는데, 생각해 보니 제가 푸드보스(FoodBoss)에서 CMO로 일하면서 앱 다운로드 수를 100건에서 1만 건 남짓까지 늘렸더군요. 그러니 답할 수 있을 것 같습니다.

저는 우리 사업의 틈새, 이 경우에는 음식 배달에 집중했습니다. 도어대시(DoorDash)를 비롯한 거대 기업들과 경쟁해야 했죠. 저는 키워드가 아니라 사람들이 겪는 문제에 집중했습니다. 사람들의 문제에 집중하면 사람들이 여러분을 찾아옵니다. 그 문제에 맞춘 랜딩 페이지를 두세요. 사람들이 찾아오면 앱 다운로드로 이끌면 됩니다.

다음으로, 테스트 프로그램을 만드세요. 이걸 하지 않는 곳이 많던데, 다운로드와 좋은 리뷰, 솔직한 피드백을 얻는 쉬운 방법입니다. 자체 프로그램을 시작해 베타나 알파 단계의 앱을 내려받아 달라고 하고, 피드백을 직접 달라고 요청하세요. 그리고 문제를 바로 고치세요. 문제를 고쳐 주면 그 사람들이 공개적으로 리뷰를 남깁니다. 좋은 관계가 생기고, 새 고객이 생기고, 이게 테스트 플랫폼의 일부가 됩니다.

앱 스토어 페이지는 대표 키워드(head term)가 아니라 구체적인 표현에 맞춰 최적화하세요. 앱 스토어에 들어가면 선두에 서서 판을 이끌고 싶어지기 마련인데, 꼭 그럴 필요는 없습니다. ‘보안 앱’과 ‘스미싱 공격 방지 앱’을 비교해 보세요. 후자가 더 롱테일이지만 훨씬 좋은 성과를 냅니다. 그리고 플레이 스토어 광고를 쓰세요. 경쟁이 덜한 키워드를 노린다면 그 키워드를 차지하고 경쟁사 옆에 노출될 수 있습니다. 그러면 브랜드가 알려집니다.

Q. (현장 질문) 웹사이트에 마크다운 연동을 넣는 곳이 많아 저도 버튼 형태로 추가했는데, AI 트래픽에는 이렇다 할 효과가 없었습니다. 특히 고객지원 페이지에서 마크다운이 의미가 있는지 경험을 듣고 싶습니다.

좋은 질문입니다. 사실 작년 테크 SEO 커넥트(Tech SEO Connect)에서 이 주제로 이야기했습니다. 마크다운은 가치가 있지만, 그 가치는 사이트 규모에 달려 있습니다. AI 크롤러를 인색한 봇이라고 생각하세요. 바로 얻을 수 있는 정보에 에너지를 낭비하고 싶어 하지 않습니다. 페이지의 텍스트에서 맥락을 뽑아낼 수 있다면 마크다운은 완전히 무시합니다.

이번엔 방대한 정보를 담은, 엄청나게 큰 사이트를 떠올려 보세요. 마크다운이 실제로 의미를 갖는 건 이럴 때입니다. 크롤러가 이미지를 다 해석하지 못하고 자바스크립트를 다 파싱하지 못할 때, 그리고 head에서 마크다운의 존재를 알려 정보를 더 쉽게 가져갈 방법이 있다는 표시를 줄 때입니다. 그렇지 않으면 크롤러는 마크다운을 통째로 무시합니다.

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.