SEO 기술부채, 고칠 것과 무시할 것 — 크롤러가 준 10,001개 문제 앞에서

테크니컬 SEO 감사에 쓰는 웹사이트 크롤링 도구는 10,001개의 문제를 기꺼이 건네준다. 때로는 임팩트나 우선순위 순으로 정렬까지 해서.

당신의 일은 비즈니스 임팩트와 수정에 드는 노력을 기준으로 어떤 이슈가 실제로 가장 중요한지 결정하는 것이다.

모든 테크니컬 SEO 감사는 같은 불편한 순간에 도달한다. 크롤이 끝나고 중복 제목, 리다이렉트 체인, 누락된 메타 디스크립션, 캐노니컬 충돌, 코어 웹 바이털스 경고, 고아 페이지, 끝없는 파라미터 URL 등 수만 개의 플래그가 담긴 스프레드시트를 마주한다.

특히 감사의 가치를 증명하려 할 때, 모든 이슈를 권고사항으로 바꾸고 싶은 본능이 든다. 그러나 개발 자원은 한정돼 있고, 콘텐츠 팀은 얇게 퍼져 있으며, 제품 로드맵은 이미 두 분기가 꽉 차 있다.

진짜 과제는 기술 부채를 찾는 것이 아니었다. 크롤러가 그건 잘한다. 무엇이 팀의 관심을 받을 자격이 있는지 결정하는 것이다.

목표는 깨끗한 크롤 리포트나 서치 콘솔의 미색인 페이지 0이 아니다. 어떤 기술적 문제가 크롤 가능성, 색인, 발견 가능성, 순위, 사용자 경험, 전환, 확장성을 진짜로 제한하는지 식별하고, 어떤 것이 모니터링하거나 무시해도 안전한지 정직해지는 것이다.

SEO에서 '기술 부채'란

소프트웨어 공학에서 빌려온 개념으로, SEO의 기술 부채는 사이트의 현재 기술 상태와 오가닉 가시성·크롤 가능성·색인·성능·비즈니스 성장을 뒷받침하는 데 필요한 기반 사이의 간극이다.

부채 유형	예시
크롤 부채	비대해진 색인 가능 URL, 패싯 내비게이션, 리다이렉트 체인, 크롤 트랩
색인 부채	중요 페이지 제외, 저가치 페이지 색인, 캐노니컬 충돌
아키텍처 부채	약한 내부 링크, 고아 페이지, 깊이 묻힌 우선순위 페이지
템플릿 부채	중복 메타데이터, 일관성 없는 헤딩, 얇은 페이지 템플릿
성능 부채	느린 템플릿, 나쁜 코어 웹 바이털스, 과도한 자바스크립트
마이그레이션 부채	레거시 리다이렉트, 옛 URL 구조, 일관성 없는 캐노니컬
구조화 데이터 부채	누락·무효·구식·저가치 스키마
리포팅 부채	부실한 GSC/GA4 매핑, 불명확한 페이지 그룹, 약한 SEO 측정

기술 부채는 단순한 오류 목록이 아니다. 검색엔진과 사용자가 콘텐츠에 접근하고, 이해하고, 신뢰하고, 우선순위를 매기고, 전환하기 어렵게 만드는 모든 것이다. 크롤 리포트에서 경악스러워 보이는 수십 개의 기술 점검에 실패하고도 매출에 측정 가능한 영향이 없는 사이트도 있다.

감사가 잘못된 우선순위를 만드는 이유

대부분의 감사는 도구 주도적이고, 거기서 문제가 시작된다. 크롤러가 수천 개 이슈를 뽑아내면 익스포트하고, 그 익스포트가 조용히 할 일 목록이 된다. 대부분은 끝내 해결되지 않는데도.

문제는 크롤러가 중요한 것이 아니라 세기 쉬운 것을 기준으로 정렬한다는 점이다.

함정	왜 생기나	왜 문제인가
이슈 개수로 우선순위	도구가 가장 큰 버킷을 먼저 보여준다	양이 많다고 임팩트가 큰 건 아니다
모든 페이지를 동등 취급	감사에 비즈니스 맥락이 없다	블로그 태그 페이지는 제품 페이지가 아니다
완벽한 크롤 점수 추구	팀이 깨끗한 리포트를 원한다	만점이 성장을 보장하지 않는다
저가치 URL 수정	쉬운 이슈는 생산적으로 느껴진다	실익 없이 자원을 태운다
기회비용 무시	모든 수정이 다른 일과 경쟁한다	정리 작업이 더 임팩트 큰 일을 밀어낸다

테크니컬 SEO 감사는 "무엇이 망가졌는가"만 답해서는 안 된다. 훨씬 유용한 질문 세트에 답해야 한다.

1. 무엇이 망가졌는가?
2. 어디서 벌어지고 있는가?
3. 얼마나 중요한가?
4. 무엇을 먼저 해야 하는가?

고칠 것, 지켜볼 것, 무시할 것

지금 고친다 (Fix now)

크롤링·색인·발견 가능성·순위·트래픽·전환·매출 창출 페이지에 직접 영향을 주는 이슈다.

• 중요 페이지가 noindex — 직접적 색인 차단
• robots.txt가 우선 섹션을 차단 — 크롤 자체를 막음
• 캐노니컬이 핵심 페이지를 다른 곳으로 지목 — 우선 페이지를 후보에서 제거
• 매출 페이지로 가는 내부 링크 깨짐 — 크롤 경로와 사용자 경로 약화
• 고가치 페이지의 핵심 템플릿이 느림 — UX와 잠재적 순위 신호 훼손
• 마이그레이션 리다이렉트 깨짐 — 트래픽과 링크 자산 유출
• 중복 페이지 세트가 서로 경쟁 — 잠식과 색인 비대

규칙: 이슈가 중요 페이지, 확장 가능한 템플릿, 매출 유발 경로, 또는 검색엔진 접근에 영향을 줄 때 즉시 고친다.

곧 고친다 (Fix soon)

긴급하지 않지만 성능·유지보수성·미래 확장성에 유의미한 저항을 만드는 이슈다.

• 우선순위 페이지가 너무 깊이 묻힘 — 약한 내부 권위 흐름
• XML 사이트맵에 구식 URL 포함 — 불명확한 크롤 신호
• 패싯 내비게이션이 크롤 낭비 생성 — 크롤 효율 저하
• 핵심 템플릿에 스키마 누락 — 구조화 데이터와 엔티티 명확성 상실
• 얇은 색인 가능 페이지가 대규모로 존재 — 사이트 품질 인식 약화
• 일관성 없는 헤딩 템플릿 — 명확성과 이해도 저하

모니터링 (Monitor)

나중에 중요해질 수 있지만 오늘 행동을 정당화하지 않는 이슈다. 저트래픽 페이지의 경미한 CWV 미달, 소수의 리다이렉트 체인, 저가치 URL의 중복 제목, 비핵심 크롤 이상, 색인 불가 요소의 자바스크립트 우려 등이다.

규칙: 임팩트가 불명확하거나, 범위가 제한적이거나, 아직 성과에 반영되지 않았을 때 모니터링한다.

지금은 무시 (Ignore for now)

기술적으로 불완전하지만 성능이나 사업 성과에 닿을 가능성이 낮은 것이다. 노출 0인 페이지의 메타 디스크립션 누락, 링크도 트래픽도 없는 옛 URL의 404, 유틸리티 페이지의 중복 H1, 저가치 페이지의 HTML 검증 이슈, 차단·noindex 페이지에 대한 도구 경고.

규칙: 고쳐도 크롤 가능성, 색인, 순위, 사용자 경험, 매출 경로, 미래 확장성이 개선되지 않을 때 무시한다.

5개 요소로 점수 매기기

버킷은 출발점이다. 우선순위를 반복 가능하게 — 그리고 이해관계자가 반박할 때 방어 가능하게 — 만들려면 5개 요소로 각 이슈를 채점한다.

요소	던질 질문
SEO 임팩트	크롤링·색인·순위·오가닉 트래픽에 영향을 줄 수 있는가?
비즈니스 임팩트	리드·매출·데모·가입·파이프라인에 연결된 페이지를 건드리는가?
규모	한 페이지인가, 한 템플릿인가, 수천 URL인가?
리스크	미래의 성과 손실, 마이그레이션 이슈, 복리 문제를 유발할 수 있는가?
노력	개발·콘텐츠·QA·이해관계자 작업이 얼마나 필요한가?

그다음 IT·제품 파트너가 알아볼 우선순위 레벨로 번역한다.

우선순위	언제 쓰나
P0	비즈니스 핵심 페이지의 크롤링·색인을 차단
P1	오가닉 성장·가시성·전환에 영향을 주는 고임팩트 템플릿·아키텍처 이슈
P2	중요하지만 긴급하지 않은 정리
P3	모니터링, 또는 향후 개발과 묶음 처리
P4	조건이 바뀌지 않는 한 무시

가장 강한 테크니컬 SEO 우선순위는 높은 SEO 임팩트, 높은 비즈니스 임팩트, 유의미한 규모, 관리 가능한 리스크, 합리적 노력의 교집합에 있다. 다섯 항목 모두 높으면 P0다. 노력이 크고 나머지 임팩트가 낮으면, 크롤러가 아무리 크게 플래그를 세워도 P4다.

핵심적이진 않지만 무시하기엔 너무 쉬운 이슈(누락된 페이지 제목, 사이트맵에서 빠진 색인 가능 URL 등)를 위한 별도 "퀵윈" 버킷을 만들어도 좋다.

전술의 핵심: URL 세그먼트로 섹션별 우선순위 정하기

대부분의 감사는 사이트 전체 크롤로 시작하고, 그것이 옳은 출발점이다. 그러나 그 자체로는 이슈가 어디서 발생하는지, 무엇에 영향을 주는지 감각이 없는 평평한 목록만 나온다.

크롤은 이렇게 말해줄 것이다 — 2,000페이지 중복 제목, 800 URL 메타 디스크립션 누락, 300 URL 리다이렉트, 150페이지 캐노니컬 이슈, 90페이지 내부 링크 깨짐, 40개 템플릿 성능 문제.

이 숫자들은 발견처럼 보이지만, 가장 중요한 질문에 답하기 전까지는 실행 가능하지 않다: 각 이슈가 어디서 발생하고 있는가?

제품 페이지의 중복 제목은 블로그 태그 페이지의 것과 다르다. 매출을 만드는 솔루션 페이지의 캐노니컬 충돌은 필터 URL의 것과 다르다. 느린 데모 페이지는 느린 작성자 아카이브와 다르다. 같은 이슈 유형, 완전히 다른 이해관계다.

대부분의 B2B·콘텐츠 중심 사이트를 위한 시작 세그먼트:

URL 세그먼트	예시 경로
홈페이지	/
제품·플랫폼	/platform/, /product/, /features/
솔루션 페이지	/solutions/, /industries/, /use-cases/
블로그·리소스	/blog/, /resources/, /insights/
케이스 스터디	/case-studies/, /customers/
전환 페이지	/demo/, /contact/, /pricing/
지원·문서	/docs/, /help/, /support/
레거시·저가치	/tag/, /author/, /archive/, 파라미터 URL

시작점은 사이트 아키텍처 — 메인 메뉴, 서브메뉴, 푸터다.

세그먼트를 나누면 리포트가 이렇게 바뀐다.

• 이전: "사이트에 중복 제목이 2,000개 있다"
• 이후: "중복 제목은 블로그 태그 아카이브에 집중돼 있고 검색 가치가 제한적이다"
• 더 긴급하게: "캐노니컬 충돌이 오가닉 파이프라인을 만드는 제품·솔루션 템플릿에 영향을 준다"

이것들은 같은 권고가 아니며 절대 같은 우선순위를 공유해서는 안 된다. 사이트 전체 크롤은 폭을 주고, URL 세그먼테이션은 우선순위를 준다.

크롤 데이터에 성과 데이터를 겹친다

세그먼테이션은 부채가 어디 사는지 알려준다. 임팩트를 이해하려면 크롤 데이터에 성과 데이터를 겹쳐야 한다.

스크리밍 프로그는 캐노니컬 충돌을 식별할 수 있지만, 그 영향받는 페이지가 데모 요청의 40%를 만든다는 사실은 알려줄 수 없다.

데이터 소스	무엇을 더하나
스크리밍 프로그	크롤 가능성, 색인 가능성, 메타데이터, 캐노니컬, 내부 링크, 응답 코드
서치 콘솔	노출, 클릭, CTR, 평균 순위, 색인된 페이지
GA4	오가닉 유입, 인게이지먼트, 전환, 매출 이벤트
백링크 데이터	외부 자산·권위를 가진 페이지
순위 추적	키워드 가시성과 순위 이동
로그 파일	실제 크롤 행동과 크롤 빈도
CRM·파이프라인 데이터	랜딩 페이지·콘텐츠 섹션별 비즈니스 가치

두 가지를 결합하면 우선순위가 대개 명확해진다.

발견	세그먼트	성과 맥락	권고
캐노니컬 충돌	제품 페이지	높은 노출, 감소하는 클릭	지금 고침
메타 디스크립션 누락	블로그 아카이브	노출 없음, 전환 없음	지금은 무시
리다이렉트 체인	레거시 URL	일부 백링크·내부 링크	곧 고침
내부 링크 깨짐	케이스 스터디	영업 지원 페이지	곧 고침
느린 템플릿	데모·솔루션	높은 전환 가치	지금 고침
중복 제목	태그 페이지	오가닉 가치 없음	무시 또는 noindex
얇은 페이지	프로그래매틱 지역 페이지	일부 노출, 약한 인게이지먼트	모니터링 또는 통합

같은 캐노니컬 충돌이 제품 페이지에서는 P0이고 태그 페이지에서는 P4다. 겹친 데이터만이 어느 쪽인지 알려준다.

반복 가능한 워크플로 (분기 1회 또는 연 2~3회)

1. 사이트 전체 크롤을 돌린다
2. URL 세그먼트를 만들어 크롤을 설정한다
3. 세그먼트별로 이슈를 검토한다 — 전체 합계에서 멈추지 말고 어디에 집중되는지 찾는다
4. 영향받는 템플릿을 식별한다 — 고립된 문제인지 시스템적인지 판단한다
5. 성과 데이터를 겹친다 — GSC, GA4, 백링크, 순위, 전환
6. 각 이슈를 채점한다 — SEO 임팩트, 비즈니스 임팩트, 규모, 리스크, 노력
7. 우선순위 레벨을 할당한다
8. 집중된 티켓을 만든다 — 세그먼트·템플릿별 개발 가능한 권고로 번역
9. 낮은 우선순위는 "퀵윈"으로 묶는다 — 향후 리디자인·CMS 업데이트·템플릿 작업에 포함
10. 간트차트·로드맵을 만든다 — 개발 자원에 맞춰 월별·분기별로
11. 전후 임팩트를 추적한다 — 색인, 순위, 트래픽, 전환, 크롤 행동

사고방식의 전환이 요점이다. 스크리밍 프로그는 기술 이슈를 찾는 데만 써서는 안 된다. 그것들을 로드맵으로 조직하는 데 써야 한다.

기술 부채는 조직 문제이기도 하다

기술 부채를 크롤로 빠져나올 수 있는 웹사이트 문제로 취급하고 싶어진다. 더 자주는 워크플로 문제다. 부채는 부주의가 아니라 프로세스 공백 때문에 쌓인다.

원인	SEO 영향
SEO가 출시 후에 투입됨	예방 대신 사후 정리
개발이 SEO 요구사항 없이 기능을 배포	크롤·색인·렌더링·아키텍처 이슈
CMS 템플릿에 거버넌스 부재	중복 메타데이터, 얇은 페이지, 일관성 없는 구조
마이그레이션이 급하게 진행	리다이렉트·캐노니컬·사이트맵·트래킹 이슈
테크니컬 QA 소유자 부재	작은 이슈가 시간이 지나며 복리로 커짐
리포팅 분절	팀이 수정과 사업 성과를 연결하지 못함

지속되는 해법은 일회성 티켓이 아니라 프로세스 수정이다.

• 제품 브리프에 SEO 요구사항 추가
• 출시 전 워크플로에 SEO QA 내장
• 메타데이터·헤딩·캐노니컬·스키마에 대한 CMS 가드레일 생성
• 분기별로 사이트 세그먼트별 크롤 데이터 검토
• 모든 릴리스 후 핵심 템플릿 모니터링
• 마이그레이션 전·중·후 기술 부채 검토 실행
• IT·콘텐츠·제품·분석과 공유 우선순위 구축

밀린 부채는 한 분기에 정리할 수 있다. 정리된 상태를 유지하는 것은 운영 모델의 문제다.

페이지가 사이트맵에 추가되지 않은 채, 또는 페이지 제목과 메타 디스크립션 없이 라이브되면, 프로세스를 멈추고 내부 팀에 필수 요소 사전 발행 체크리스트를 줘야 한다.

AI 검색과 GEO가 대화를 바꾸는 방식

기술 부채는 이제 전통적 순위에만 영향을 주지 않는다. 검색엔진, AI 시스템, 검색(retrieval) 모델이 콘텐츠에 접근·이해·연결·신뢰하는 데 얼마나 쉬운지에 점점 더 영향을 준다.

기술 부채	AI·GEO 영향
부실한 사이트 아키텍처	토픽 관계를 이해하기 어렵게 만듦
약한 내부 링크	중요 엔티티와 페이지 관계를 가림
일관성 없는 스키마	구조화된 맥락 약화
얇고 중복된 페이지	소스 품질에 대한 신뢰 저하
차단되거나 렌더링 어려운 콘텐츠	크롤러와 검색 시스템의 접근 제한
분절된 콘텐츠 허브	전문성 식별을 어렵게 만듦
자바스크립트 콘텐츠	LLM이 콘텐츠를 보지 못하고 사용·검색하지 못함
불명확한 저작자·조직 신호	신뢰와 귀속 약화

중요한 경고 하나: AI 검색이 모든 기술 이슈를 더 중요하게 만들거나 모든 P4를 긴급으로 재분류할 근거가 되지는 않는다. 크롤 가능한 콘텐츠, 깨끗한 아키텍처, 명확한 엔티티 관계, 구조화 데이터, 강한 내부 링크, 기술적으로 접근 가능한 페이지의 가치를 높일 뿐이다. 표면적 이슈는 여전히 무시해도 되는 채로 남는다.

죄책감 없이 무시해도 되는 것들

대부분의 감사 자료가 대놓고 말하지 않는 부분이 있다. 모든 기술 이슈가 티켓이 될 필요는 없다.

양심에 거리낌 없이 무시해도 되는 것들이다.

• 눈에 보이는 검색 영향이 없는 도구 경고
• 의도적으로 차단·noindex·폐기한 페이지의 이슈
• 비전략적 URL의 경미한 메타데이터 문제
• 내부 링크도 백링크도 없는 소수의 크롤 오류
• SEO·UX 결과가 없는 HTML 검증 이슈
• 유틸리티·아카이브·저가치 페이지의 중복 요소
• 향후 템플릿 업데이트 때 처리하는 편이 나은 일회성 이슈
• 사용자·검색엔진·사업 목표를 움직이지 않는 완벽주의적 수정

저임팩트 기술 부채를 무시하는 것은 게으름이 아니다. 우선순위 결정이다.

목표는 애초에 완벽한 크롤이 아니었다

깨끗한 크롤 리포트는 유용하고 보기에도 좋지만 목적은 아니다.

테크니컬 SEO는 검색엔진과 AI 크롤러가 사업에 가장 중요한 페이지를 효율적으로 크롤·렌더링·이해·색인·랭크하도록 도와야 한다. 그리고 한정된 엔지니어링·콘텐츠 자원이 그 페이지들에 집중되게 해야 한다.

훌륭한 테크니컬 SEO는 모든 것을 고치는 게 아니다. 무엇이 중요한지 알고, 왜 중요한지 증명하고, 유한한 자원을 성장에 영향을 줄 수 있는 이슈에 집중시키는 것이다.

스크리밍 프로그와 다른 크롤러는 강력하지만, 그 가치는 오류를 드러내는 데 있지 않다. 어떤 도구든 그건 한다. 그 가치는 기술 부채를 비즈니스 임팩트 관점에서 세그먼트하고, 우선순위를 정하고, 소통하도록 돕는 데 있다.

CEO, CFO, CMO는 서치 콘솔의 미색인 페이지를 0으로 줄이는 데 관심이 없다. 사업이 얼마나 많은 리드·전환·매출을 만드는지에 관심이 있다.

실무 정리

첫째, 크롤 익스포트를 할 일 목록으로 만들지 않는다. 이것이 이 글의 출발 진단이다. 크롤러는 중요한 순이 아니라 세기 쉬운 순으로 정렬한다.

둘째, 세그먼트 없이 우선순위를 정하지 않는다. "중복 제목 2,000개"는 발견이 아니다. 어디서 발생하는지 답하기 전까지는 실행 불가다.

셋째, 성과 데이터 없이 채점하지 않는다. 같은 캐노니컬 충돌이 P0과 P4를 오간다. 크롤 데이터만으로는 어느 쪽인지 알 수 없다.

넷째, P4 목록을 문서로 만든다. 무시할 것을 명시하는 것이 감사의 신뢰도를 오히려 높인다. "모든 걸 고쳐야 한다"는 보고서는 아무것도 실행되지 않는다.

다섯째, 프로세스 수정을 티켓과 같은 비중으로 다룬다. "밀린 부채는 한 분기에 정리할 수 있지만, 정리된 상태 유지는 운영 모델 문제" 라는 지적이 이 글의 가장 실무적인 부분이다.

여섯째, AI·GEO 영향을 과대 해석하지 않는다. 저자가 명시적으로 경고한다 — AI가 모든 P4를 긴급으로 만들지 않는다. 다만 엔티티 SEO — AI 검색은 키워드가 아니라 개념의 출처를 찾는다와 AI 검색을 위한 스키마: 엔티티 공백을 찾아내고 우선순위를 정하는 법이 다루는 항목의 가치는 올라간다.

일곱째, 자바스크립트 렌더링을 최우선 부채로 본다. 표에서 유일하게 "LLM이 콘텐츠를 아예 못 본다" 고 적힌 항목이다. 실제 감사 사례는 AI가 우리 회사를 확인할 수 없다 — 71개 기업 감사가 찾은 '84% 정체성 누출'에 있다.

여덟째, 경영진 언어로 번역한다. 미색인 페이지 0이 아니라 리드·전환·매출이다. 이 번역이 안 되면 개발 자원을 못 받는다.