SEO 검증 정확도 높이려고 텍스트 범위 확대했다

사이트 본문을 추출할 때 1200자로 제한하던 걸 3000자까지 확대했다. scripts/bot-action-worker.py의 SEO 자동 수정 로직을 손봤다.

왜 한도를 늘렸나

우리 SEO 자동 수정 시스템(codex)은 사이트 콘텐츠를 분석해서 메타 태그나 구조화된 데이터를 자동으로 개선한다. 그 과정에서 원본 사이트 본문을 맥락 정보로 함께 전달하는데, 이 근거가 너무 짧으면 AI 모델이 충분한 정보 없이 판단해야 해서 오류율이 높아진다.

1200자 제한은 초기 구현 단계에서 보수적으로 설정한 값이었다. 성능 오버헤드 걱정도 있고, 초기에는 간단할수록 좋다는 생각이 있었기 때문. 하지만 실제 운영 피드백이 계속 들어왔다. "이 페이지는 충분한 콘텐츠인데 검증이 떨어진다", "메타 설명이 부정확하게 수정된다" 같은 것들.

데이터를 분석해보니 패턴이 명확했다. 사이트 본문이 1200자 근처에 있는 경우, 즉 충분한 컨텍스트가 잘렸을 가능성이 높은 경우에 오류가 집중되어 있었다. 단순 우연이 아니라 시스템의 한계가 명확하게 드러난 거였다.

기술적으로 뭐가 바뀌었나

실제 구현은 간단하다. worker 스크립트에서 본문을 추출할 때 슬라이싱하는 부분의 상수값만 바꾼 것. 하지만 이 작은 변경이 upstream AI 모델이 받는 정보량을 대폭 늘렸다.

3000자 선택은 우리 사이트 풀의 평균 본문 길이와 충분하다고 여겨지는 컨텍스트 윈도우를 맞춰본 결과다. 더 크게 가면 API 비용과 처리 시간도 증가하고, 너무 작으면 여전히 정보 부족 문제가 남는다. 데이터-비용-품질 그래프에서 이 지점이 최적점으로 보였다.

회고: 초기 설정의 함정과 데이터 기반 개선

이건 흔한 패턴이다. 초기에 성능을 우려해서 한도를 보수적으로 설정했는데, 실제 운영 데이터가 그 우려가 기우였음을 보여주는 경우다. 더 일반적으로는, 한도나 임계값이 "언젠가 조정하겠지" 하는 마음으로 살아남는 코드들이 많다.

팀 관점에서 이런 변경이 중요한 이유:

• QA 피드백이 패턴이 되면 정량화해야 한다. "검증이 떨어진다"는 정성적 불만이 아니라, 실제로 1200자 근처 사이트에서 오류율이 유의미하게 높은지 확인하는 과정 자체가 의사결정을 뒷받침한다.
• 초기 설정을 의심하는 자세. "왜 1200이었을까"를 되짚어보면 그게 단순 임의값인지 아니면 진짜 기술적 제약인지 명확해진다.
• 코드 리뷰 때 "왜 이 숫자?"라고 물어보기. 팀원이 이런 마법의 숫자를 보면 근거를 물어봐야 다음에 더 나은 초기값 설정이 가능해진다.

이번 작업으로 배운 점: 작은 수치 변경이라도 "언제 재평가할지", "어떤 메트릭으로 판단할지"를 미리 문서화해두면, 나중에 비슷한 개선이 더 빠르고 자신 있게 진행된다. 데이터가 방향을 제시하는 아주 깔끔한 사이클이었다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.