왜 제작 단계에서 최적화를 심어야 하나 — 다 만든 뒤 덧붙이기의 비용

왜 "다 만든 뒤 최적화"가 비싼가?

홈페이지를 먼저 멋지게 만들고, 검색과 AI 노출은 오픈한 다음에 붙이자는 순서는 흔합니다. 디자인이 눈에 보이는 결과라 우선순위가 높고, 최적화는 추상적이라 뒤로 미뤄지기 때문입니다. 문제는 최적화가 페이지에 끼워 넣는 장식이 아니라 사이트의 뼈대와 맞물린 작업이라는 점입니다. 뼈대를 다 굳힌 뒤에 손대면, 단순히 무언가를 더하는 게 아니라 이미 만든 것을 뜯어 고치는 일이 됩니다.

예를 들어 제품 페이지 주소가 /page?id=37 처럼 매겨져 있으면, 검색엔진과 AI가 읽기 좋은 /products/desk-lamp 형태로 바꾸는 순간 기존 주소 전부에 리다이렉트를 걸고 색인을 다시 정리해야 합니다. 페이지 한두 개면 몰라도 수십 개라면 별도 프로젝트가 됩니다. 이 비용은 처음 설계 때 주소 규칙만 정해 뒀다면 0이었습니다.

나중에 붙일 때 실제로 뜯는 것은 무엇인가?

덧붙이기 방식에서 다시 손대는 부분은 거의 정해져 있습니다. 첫째 URL 구조입니다. 주소를 바꾸면 리다이렉트와 재색인이 따라옵니다. 둘째 페이지 정보구조입니다. 제목과 문단의 위계(H1 하나, 그 아래 질문형 H2)가 잡혀 있지 않으면, 검색·AI가 핵심을 추출하도록 문서 골격을 다시 짜야 합니다. 셋째 콘텐츠 문단의 형태입니다. AI가 그대로 들어올릴 40~80단어 자기완결 문단, 즉 answer block은 기존 마케팅 문장을 다시 써야 나옵니다.

세 가지 모두 "내용을 더한다"가 아니라 "이미 있는 것을 바꾼다"입니다. 바꾸는 작업은 더하는 작업보다 비쌉니다. 기존 구조를 분석하고, 깨지지 않게 고치고, 다시 검증하는 단계가 전부 추가되기 때문입니다.

제가 ‘나중에 붙이기’ 견적을 낼 때 가장 먼저 표시하는 게 이 세 항목입니다 — 여기에 손이 닿는 순간, 단순 추가가 아니라 재작업으로 넘어가기 때문입니다.

세 칩 모두 설계 단계라면 추가 비용 0으로 처음부터 들어갑니다 — 같은 결과를 더 싸게 만드는 길이 ‘붙이기’가 아니라 ‘처음부터’인 이유가 이 칩에 다 있습니다.

설계부터 넣으면 무엇이 달라지나?

같은 항목을 첫 단계에서 넣으면 추가 공수가 작습니다. 어차피 만들 페이지의 주소 규칙을 정할 때 검색 친화적 형태로 정하고, 어차피 쓸 본문을 쓸 때 answer block 형태로 쓰고, 어차피 넣을 마크업에 구조화 데이터(@graph)를 함께 넣습니다. 별도 프로젝트가 아니라 본 작업의 일부가 됩니다.

일관성도 따라옵니다. 디자인과 최적화가 같은 사람의 머릿속에서 나오면, 화면에 보이는 제목과 검색엔진이 읽는 제목, AI가 인용하는 문단이 서로 어긋나지 않습니다. 나중에 다른 팀이 끼워 넣으면 톤과 구조가 미묘하게 따로 놀고, 그 불일치가 다시 손볼 거리를 만듭니다. GEO와 SEO의 차이가 궁금하다면 GEO와 SEO는 무엇이 다른가를 함께 보면 도움이 됩니다.

제작사와 최적화사를 따로 맡기면 생기는 손실은?

가장 큰 손실은 책임 경계에서 나옵니다. 제작사는 디자인과 동작을, 최적화사는 검색·AI 노출을 맡습니다. 그런데 구조화 데이터를 넣거나 URL을 바꾸려면 제작사가 짠 코드를 고쳐야 합니다. 이때 두 가지가 자주 부딪칩니다. 하나는 권한입니다. 최적화사가 코드를 직접 못 만지고 제작사에 요청해야 하는데, 제작 계약이 끝났거나 추가 비용이 붙습니다. 다른 하나는 책임입니다. 노출이 안 나오면 제작사는 "콘텐츠 문제", 최적화사는 "구조 문제"라며 서로 원인을 미룹니다.

이 경계 비용은 기능 부족이 아니라 분업 구조 자체에서 생깁니다. 두 회사가 아무리 유능해도, 한쪽이 만든 것을 다른 쪽이 고쳐야 하는 구조라면 마찰은 남습니다. 한 팀이 처음부터 함께 설계하면 이 경계가 사라지고, 문제가 생겨도 원인을 미룰 상대가 없으니 바로 해결로 갑니다.

통합으로 진행하면 순서는 어떻게 되나?

Findable은 디자인과 최적화를 같은 흐름에서 진행합니다. 실제 순서는 이렇습니다. 먼저 비즈니스 목표(문의·구매)에서 역산해 정보구조를 잡습니다. 어떤 페이지가 필요하고, 주소를 어떻게 매기고, 제목 위계를 어떻게 둘지를 디자인 와이어프레임과 동시에 결정합니다. 다음으로 각 페이지의 마크업에 구조화 데이터를 처음부터 심습니다. 그다음 본문을 쓸 때 answer block 형태로 작성합니다. 마지막으로 페이지 사이를 내부링크로 엮어 검색·AI가 사이트의 주제 관계를 읽도록 합니다.

핵심은 이 네 가지가 별도 단계가 아니라 제작과 겹쳐 진행된다는 점입니다. 그래서 오픈 시점에 사이트는 이미 사람에게도 AI에게도 읽히는 상태로 나옵니다. 나중에 무언가를 붙이려고 다시 뜯을 일이 없습니다.

이 ‘겹쳐 진행’을 말로만 하면 흐릿해서, 저는 제작 단계마다 어떤 최적화를 ‘언제’ 심는지 표로 못 박아 둡니다. 같은 항목이라도 심는 시점이 한 칸만 늦어도 비용이 달라지거든요.

오른쪽 칸이 곧 ‘나중에 붙이기’의 청구서입니다 — 같은 작업인데 시점만 늦춰서 더 내는 돈이라, 저는 도면 단계에서 왼쪽 칸을 다 채워 둡니다.

그래도 이미 만든 사이트라면?

이미 완성된 사이트라도 개선은 가능합니다. 다만 위에서 본 비용을 안고 시작한다는 점을 알고 들어가는 게 좋습니다. URL을 건드리지 않아도 되는 구조화 데이터·answer block부터 넣고, 주소·정보구조 변경은 효과 대비 비용을 따져 단계적으로 진행하는 편이 현실적입니다. Findable의 무료 진단은 현재 사이트에서 무엇을 추가로 넣을 수 있고 무엇은 다시 뜯어야 하는지를 먼저 구분해 드립니다. 회사 소개에서 진행 방식과 원칙을 확인할 수 있습니다.

한 줄 결론

최적화는 다 만든 집에 붙이는 인테리어가 아니라 설계 도면에 들어가는 배관입니다. 도면 단계에서 그리면 싸고, 벽을 다 세운 뒤 뚫으면 비쌉니다. 제작과 최적화를 한 팀에서 처음부터 함께 설계하는 이유가 여기 있습니다.