저는 개인적으로 실생활의 불편을 해결해 보려고 작은 서비스를 하나 만들었습니다. 제가 직접 쓸 때는 기능도 잘 동작했고, 만족스러웠습니다. 문제는 그다음이었습니다. 서버는 성공을 뜻하는 200을 응답했지만, 저 말고 다른 사람들이 이 서비스를 만날 방법은 없었습니다. 그렇다면 "다른 사람도 이걸 쓰게 하려면 어떻게 해야 할까?" 그 질문을 붙들고, 제가 정리한 것들을 다뤄보고자 합니다.

이번 글에서 다루고 싶은 건 세 가지입니다.

첫째, 기능이 동작하는 것과 사용자가 그 기능을 발견하는 것은 완전히 다른 문제라는 점.
둘째, SEO(검색엔진 최적화)는 검색엔진을 위한 장식이 아니라, 제품이 외부에 자신을 설명하는 방식이라는 점.
셋째, 그 설명이 계속 바뀔 거라면 메타데이터도 한곳에서 관리해야 한다는 점.

기능이 동작한다는 말의 한계

도메인을 사고 배포를 마쳤을 때, 저는 프로젝트를 완성했다고 생각했습니다. 링크를 열면 화면이 떴고, 기능도 정상적으로 돌아갔으며, 보여준 친구들의 반응도 좋았으니까요.

개발자에게 배포는 완성입니다. 로컬에만 있던 결과물이 공개 주소를 갖고 누구나 접근할 수 있는 상태가 되는 순간이니까요. 하지만 사용자 입장에서 그 사이트는 아직 시작되지도 않았습니다. 검색되지 않고, 제대로 설명되지 않으며, 링크를 받아도 무엇을 하는 곳인지 드러나지 않는 페이지는 '없는 제품'에 가깝습니다. 누군가 직접 링크를 건네주지 않는 한, 사용자가 제품과 마주칠 경로 자체가 없기 때문입니다.

그래서 자연스럽게 SEO를 떠올렸습니다. SEO(Search Engine Optimization, 검색엔진 최적화)는 검색엔진이 내 페이지를 잘 읽고, 알맞게 정리해서, 검색 결과에 제대로 노출할 수 있도록 돕는 작업입니다. 보통은 도메인을 등록하고 sitemap.xml로 사이트 구조를 알려주며, robots.txt로 크롤링 허용 범위를 설정하면 검색엔진에 페이지를 보여줄 수 있습니다.

처음에는 SEO를 배포 뒤에 덧붙이는 단순한 기술 작업쯤으로 생각했습니다. 제목과 설명 몇 줄 넣고 정적 리소스를 열어두면 끝나는 일처럼 여겼으니까요. 하지만 텅 빈 검색 결과를 마주하자, 문제가 완전히 달라 보였습니다. 막혀 있던 건 제품의 기능이 아니었습니다. 이미 만들어 놓은 서비스가 과연 무엇인지, 외부에 제대로 설명하지 못하고 있다는 점이 진짜 문제였습니다.

그제야 작업이 둘로 갈라져 보였습니다. 기능을 만드는 일, 그리고 만든 기능이 외부에서 발견되고 이해되게 만드는 일. 둘은 긴밀히 이어져 있지만 결코 같은 일은 아니었습니다. 좋은 기능을 만들면 언젠가 사용자가 생길지도 모릅니다. 하지만 그 '언젠가'라는 막연한 기대 사이에는 중요한 단계가 하나 비어 있습니다. 사용자는 제품을 먼저 인지해야 하고, 검색엔진은 페이지의 의도를 먼저 이해해야 한다는 사실입니다.

첫 SEO 작업을 메타 태그 추가로 시작하지 않은 이유

SEO를 구현하는 가장 빠른 길은 각 페이지에 메타 태그를 직접 붙이는 것이었습니다. 페이지마다 제목과 설명을 적고, 새로운 값이 필요해질 때마다 그 자리에 덧붙이면 되니까요. 작은 서비스에서는 보통 이 방식이 가장 빠르고 효율적으로 느껴집니다.

저는 그렇게 시작하지 않았습니다. 대신 페이지의 외부 표현을 담는 메타데이터 모델을 먼저 구축하고, 각 페이지가 그 모델을 통해 자신을 설명하도록 구조를 짰습니다. 판단 기준은 단순했습니다. 한 페이지에만 영향을 주는 값이면, 해당 페이지와 가까운 곳에 둡니다. 반면, 여러 페이지의 외부 표현을 한꺼번에 바꾸는 값이면 한곳에서 모아 관리합니다.

제목, 설명, 대표 URL, 언어 정보, 공유용 이미지 정보 등은 페이지마다 다르면서도, 서비스 전체의 정책이 바뀌면 함께 흔들리는 속성을 가집니다. 이러한 값들을 컨트롤러와 화면 곳곳에 흩어두면, 처음에는 멀쩡해 보이지만, 정책이 하나 추가될 때마다 모든 페이지의 코드를 다시 열어봐야 합니다. 특정 페이지에만 반영이 누락되는 에러가 생기기도 쉽고요.

그래서 첫 작업의 핵심은 메타 태그 몇 줄을 추가하는 게 아니라, “외부에 노출되는 제품 설명을 한곳에서 생성하자”는 아키텍처 관점의 설계 결정이었습니다. 각 페이지는 자신에게 필요한 메타데이터를 요청하고, 화면(View)은 전달받은 값을 그대로 표시할 뿐입니다. 즉, 제품의 '자기소개'를 만드는 책임과 역할을 한곳에 모은 것입니다.

물론 모든 프로젝트에 맞는 방식은 아닙니다. 코드 베이스가 아직 작았기에 가능한 선택이었고, 팀 규모가 크거나 시스템 구조가 복잡했다면, 컴포넌트 간에 더 명확한 경계가 필요했을 것입니다.

SEO를 단순히 검색엔진용 장식으로 바라보면 메타 태그 몇 줄을 붙이는 일이 되고, 제품의 자기소개로 바라보면 그 소개를 어디서 만들고 관리할지부터 고민하게 됩니다. 어쩌면 처음에 정해야 했던 건 메타 태그의 종류가 아니라, 이 제품이 자기 자신을 어디에서 말하게 할 것인가에 대한 근본적인 위치였는지도 모릅니다.

구글 서치 콘솔과 네이버 서치어드바이저를 고른 이유

페이지가 외부에 자기 자신을 설명할 표면을 갖췄어도, 검색엔진이 그 페이지의 존재를 모르면 검색 결과에 등장할 일은 없습니다. 그래서 메타데이터 설계 이후 다음 결정은 "어디에 내 사이트를 등록할 것인가"였습니다.

저는 구글 서치 콘솔(Google Search Console)과 네이버 서치어드바이저, 두 곳을 골랐습니다.

서치 콘솔은 구글 검색에 내 사이트를 등록하고, 사이트맵(sitemap.xml)을 제출하여 색인 상태와 검색 노출 데이터를 확인하는 도구입니다. 네이버 서치어드바이저는 네이버 검색을 대상으로 거의 같은 역할을 수행합니다. 두 도구 모두 무료이며, 사이트 소유권 확인과 사이트맵 제출이 기본 흐름입니다.

선택 기준은 단순했습니다. 국내 사용자를 타깃으로 삼는다면 네이버의 점유율을 무시하기 어렵고, 글로벌 노출이나 타 검색엔진과의 호환성을 고려하면 구글이 사실상 업계 표준에 가깝습니다. 특히 구글은 GA4(Google Analytics 4)와 연동하여 사용자의 유입 흐름과 활동 데이터를 한 번에 파악하기 좋다는 장점도 있습니다.

다른 검색엔진까지 챙기지 않은 것은, 들이는 시간 대비 추가로 확보할 수 있는 사용자가 얼마나 될지 확신이 없었기 때문입니다. 사이드 프로젝트 단계에서는 여러 검색엔진에 어설프게 걸쳐 두는 것보다, 주요 플랫폼 두 곳을 정확하게 정리하는 편이 훨씬 낫다고 판단했습니다.

검색엔진 등록 자체보다 더 중요한 효과는 따로 있었습니다. 두 도구 모두 "내 페이지를 검색엔진이 현재 어떻게 바라보고 있는가"를 투명하게 보여줍니다. 그동안 막연하게 추측만 하던 부분이 처음으로 명확한 데이터가 되어 눈앞에 나타난 것입니다. 어떤 페이지가 색인되었는지, 어떤 검색어로 노출되는지, 혹은 어디에서 누락되고 있는지 말이죠.

결국 메타데이터를 한곳에 모은 결정도, 필요한 항목을 미리 잡아둔 결정도 모두 이 대시보드 화면 위에서 검증되는 구조였습니다.

6월 22일 기준, 7일 동안의 검색 노출량: Google Search Console <출처: 작가, 화면 캡처>

당장 쓰지 않을 항목을 미리 둔 이유

가장 망설인 건 따로 있었습니다. “당장 쓰지 않을 항목까지 모델에 넣을 것인가.”

필요할 때마다 추가하면 된다는 생각도 맞습니다. 작은 프로젝트에서 미래를 과하게 그리면 오버 엔지니어링(Over-engineering, 과잉 설계)이 되기 쉽고, 쓰지 않는 항목을 미리 만들어두는 건 자칫 자기만족으로 흐를 수 있으니까요.

그럼에도 몇 가지 항목은 미리 자리를 비워두었습니다. 대표 URL을 무엇으로 정의할지, 언어별 페이지를 어떻게 구분할지, 특정 페이지의 공유 정보를 어떻게 처리할지 같은 것들이었습니다. 이는 '있으면 좋은 기능'이라기보다는, 외부 노출을 본격적으로 다루기 시작하면 거의 반드시 마주치는 핵심 표현 방식에 가까웠습니다.

이 작업은 일반적인 기능 개발과는 성격이 다릅니다. 기능은 제품 방향에 따라 사라지거나 바뀌기도 합니다. 반면, 외부 표현은 한번 공개되면 검색엔진과 사용자에게 지속해서 영향을 줍니다. 그래서 저는 판단 기준을 '지금 화면에서 당장 쓰느냐'가 아니라, '나중에 여러 페이지에 동시에 영향을 줄 수 있는가'에 두었습니다.

시간이 흘러 외부 노출과 관련한 결정들이 실제로 추가되었을 때, 이 선택은 큰 도움이 되었습니다. 각 페이지의 처리 흐름을 전부 다시 손대는 대신, 기존 구조 안에서 값을 확장하고 생성 규칙만 조금 조정하면 됐기 때문입니다. 처음부터 완벽하게 설계했다는 뜻은 아닙니다. 다만 외부에 노출되는 정보는 화면 안쪽의 기능보다 변경 축이 훨씬 넓다는 것, 그리고 검색 결과·공유 화면·언어·검증 정책 등이 뒤늦게 따라붙는다는 사실만큼은 분명해졌습니다.

작은 서비스의 SEO라고 해서 처음부터 크게 만들 필요는 없습니다. 다만 이 질문만큼은 한 번쯤 던져볼 만합니다. "이 페이지가 외부에 보이는 방식을 바꾸고 싶을 때, 나는 과연 몇 군데의 코드를 고쳐야 하는가?" 만약 고쳐야 할 곳이 너무 많다면, 이제 메타데이터도 제품 설계의 중요한 일부로 바라볼 시점인지도 모릅니다.

기능을 더 붙이는 대신, 발견 가능성을 보기로 했다

사용자를 늘리고 싶을 때 가장 쉽게 선택하는 방법은 기능을 더 만드는 일입니다. 새로운 기능에는 앞으로 전진하는 감각이 있고, 작업한 흔적도 분명하게 남으니까요. 반대로 검색 노출을 손보는 일은 화면에 드러나는 변화가 적고, 핵심 기능이 달라지지도 않습니다. 그래서 우선순위에서 자꾸만 뒤로 밀립니다.

저 역시 그런 유혹을 느꼈습니다. 하지만 당시 마주한 진짜 문제는 기능의 개수가 아니었습니다. 최소한의 기능은 이미 돌아가고 있었고, 직접 써본 사람들의 반응도 나쁘지 않았습니다. 그런데도 유입이 전혀 없다면, 먼저 의심해야 할 곳은 기능이 아니라 '발견 경로'입니다. 사용자가 없는 제품에 기능을 계속 붙이는 건, 때로 당면한 문제를 뒤로 미루는 방식이 되기도 하니까요.

이러한 점검은 코드가 정상적으로 동작하는가와는 완전히 다른 축에 있습니다. “검색하면 나오는가?”, “검색 결과에서 무엇을 하는 서비스인지 명확히 알 수 있는가?”, “링크를 공유했을 때 최소한의 설명이 붙는가?” 제품이 시장에 발을 들이는 순간부터는, 결코 피할 수 없는 질문이기도 합니다.

배포된 사이드 프로젝트는 더 이상 컴퓨터 안의 실험실에 머물지 않습니다. 아무리 작아도 엄연히 시장에 놓인 하나의 제품입니다. 그 순간부터는 '내가 무엇을 만들었는가'보다 '외부에서 이 제품을 어떻게 이해하고 있는가'가 훨씬 더 중요한 질문이 됩니다. 저에게 SEO는 그 제품의 표면을 깨끗하게 정리하는 작업이었습니다. 검색엔진을 속이는 기술이 아니라, 제가 만든 제품을 일관된 언어로 정의하고 설명해 보는 일에 가까웠습니다.

‘동작하는 사이트’와 ‘사용자에게 닿는 사이트’는 전혀 다른 문제였습니다. 사이드 프로젝트를 배포하는 순간, 우리는 단순히 코드를 짜는 개발자에서 제품을 설명하고 유통하는 메이커의 역할까지 함께 부여받습니다.

다음 글에서는 이 표면을 실제로 어떻게 정리했는지, 메타데이터 모델을 어떤 형태로 설계했고, 어떤 필수 항목부터 채워 넣었는지 본격적으로 이어가 보려 합니다. 저처럼 "분명히 배포는 마쳤는데, 아무도 들어오지 않아요."라는 단계에서 멈춰 있는 분이 있다면, 다음 글로 넘어가기 전에 이 질문을 스스로에게 먼저 던져보면 좋겠습니다.

"내 제품은, 내가 없는 자리에서 자기 자신을 어떻게 설명하고 있을까요?"