웹사이트 감사 도구를 만들며 배운 점: 발견 항목이 많다고 수정이 늘지는 않습니다

AI 요약

GazeRank는 웹사이트를 검사해 건강 점수와 SEO, 성능, 접근성, AI 검색 가시성 관련 문제를 보여주는 도구입니다. 개발자는 처음에 검사 항목과 발견 결과를 늘리는 데 집중했지만, 보고서가 길어질수록 사용자가 멈춘다는 점을 알아챘습니다. 문제를 찾았더라도 “월요일 아침에 무엇을 해야 하나요?”라는 질문에 답하지 못하면 실제 수정으로 이어지지 않았습니다.

그래서 보고서를 Scan → Prioritize → Fix → Verify → Monitor 흐름으로 다시 구성했습니다. 앞부분에는 지금 가장 영향이 큰 수정 항목, 해당 사이트에서 그 문제가 중요한 이유, 수정 여부를 확인하는 방법을 담으려 합니다. 현재는 우선순위 항목 3~5개를 앞에 두고 전체 발견 목록을 아래에 배치하지만, 경쟁 도구처럼 100개가 넘는 결과를 보여주는 편이 나은지는 아직 판단하지 못했습니다. ‘메타 설명 누락’처럼 바로 고칠 수 있는 문제와 ‘콘텐츠 깊이 부족’처럼 해결책을 정하기 어려운 문제도 보고서가 어디까지 도와야 할지 고민거리입니다.

보고서 길이보다 실제 수정 여부를 측정해야 합니다

댓글에서는 짧은 목록과 긴 목록 중 무엇이 더 나은지 추측하기보다, 실제 수정률을 측정하자는 제안이 나왔습니다. 이미 검사한 200개 넘는 사이트 중 일부를 몇 주 뒤 다시 검사하고 결과를 비교하면, 발견 항목 가운데 실제로 수정된 비율을 볼 수 있다는 의견입니다. 짧은 목록을 받은 사이트와 긴 목록을 받은 사이트의 차이도 살펴보자고 했습니다.

도구 개발자는 현재 발견 항목에서 “수정했습니다”를 누르면 해당 문제만 다시 검사하고 전후 결과를 보여준다고 설명했습니다. 다만 우선순위 정렬에는 아직 영향도와 심각도를 주로 쓰며, 쉬움·보통·어려움으로 표시한 수정 노력은 정렬에 반영하지 않았다고 밝혔습니다.

이 지점에서는 의견이 갈렸습니다. 영향도가 큰 어려운 수정과 영향도는 보통이지만 쉬운 수정이 함께 있다면, 쉬운 항목을 먼저 올려야 하는지 논의했습니다. 한 댓글은 순서가 곧 우선순위라는 인상을 주므로 영향도 순서를 유지하고 각 항목에 “10분이면 수정”이나 “개발자 필요” 같은 노력을 표시하자고 제안했습니다. 대신 두세 개의 쉬운 항목을 별도 ‘오늘 수정’ 구역에 두면 시작점을 만들면서도 어려운 고영향 항목을 낮춰 보이지 않게 할 수 있습니다. 개발자에게 전달할 항목만 모은 내보내기 기능도 제안했습니다.

전체 목록과 실행 목록은 서로 다른 역할을 합니다

댓글에서는 100개짜리 결과와 우선순위 3개짜리 목록이 양자택일이 아니라는 관점도 나왔습니다. 전체 목록은 검사 도구가 충분히 살펴봤다는 인상을 주고, 짧은 목록은 당장 행동을 이끕니다. 따라서 전체 목록을 없애기보다 접힌 부록에 두고, 보고서 맨 위에는 실행할 항목을 제한하자는 의견입니다. 한 개발자는 “긴 목록은 마케팅이고 짧은 목록은 제품”이라고 표현했습니다.

항목마다 문제 내용과 해당 URL, 사이트별 영향, 수정 후 통과해야 할 확인 방법을 적자는 제안도 있었습니다. 다만 짧은 목록만으로는 실행까지 이어지지 않을 수 있습니다. 문제를 알아도 누가 맡을지 정해지지 않으면 보고서가 개발자에게 전달된 뒤 멈출 수 있다는 지적이 나왔습니다. 개발자는 사용자가 막히는 원인이 ‘어떻게 고치는지 모름’인지 ‘누가 맡는지 모름’인지 아직 데이터로 확인하지 못했다고 했습니다. 댓글에서는 실제 사용자에게 상위 항목을 맡을 사람을 지정하게 하고, 일주일 뒤 진행 여부를 확인해 둘 상황을 구분해 보자는 제안이 나왔습니다. 아무도 배정되지 않은 경우와 배정됐지만 작업이 끝나지 않은 경우는 원인이 다르기 때문입니다.

진단에서 수정 초안과 검증까지

‘콘텐츠 깊이 부족’처럼 정답이 명확하지 않은 항목에는 문제 설명만 제시하기보다 첫 수정 초안과 확인 방법을 함께 제공하자는 의견도 나왔습니다. 초안은 실행에 필요한 수고를 줄이고, 검증 절차는 결과를 확인하게 합니다. 한 댓글 작성자는 실제로 반응을 얻은 수정은 문제 진단만 전달했을 때가 아니라, 문구에 넣을 구체적인 단어까지 제안했을 때였다고 설명했습니다. 도구가 자체적으로 다시 검사하는 절차만 믿지 말고 사용자가 직접 확인할 방법도 제공해야 한다는 지적도 있었습니다. 자동 검사 도구가 다운로드 실패를 놓치거나 브라우저에서 이미지를 불러오지 못해 결과를 잘못 보고한 사례가 있었기 때문입니다.

AI 검색 가시성도 별도 검증이 필요하다는 논의가 이어졌습니다. 개발자는 현재 점수가 AI 크롤러 접근, 구조화 데이터, 인용에 적합한 콘텐츠 신호를 측정하므로 실제 답변에 등장하는지를 보는 ‘가시성’보다는 ‘AI 검색 준비도’에 가깝다고 밝혔습니다. 댓글에서는 크롤링 보고서와 실제 인용 여부 확인을 분리하고, 같은 프롬프트와 모델 설정으로 주기적으로 질문한 뒤 원문 답변을 저장해 ‘인용됨·언급됨·바꿔 말해짐·나타나지 않음’을 처음에는 수동으로 분류하자는 제안이 나왔습니다. 한 번의 누락을 신호로 보지 말고 여러 주 동안 반복되는 결과를 살펴야 한다는 의견도 덧붙었습니다.

Indie Hackers 반응

• @smoke_test_1024 — 수정으로 이어지는 보고서가 무엇인지 알아내려면 신규 사용자가 더 필요하지 않을 수 있습니다. 이미 200개 넘는 사이트를 검사했으니 몇 주 뒤 일부를 다시 검사해 결과를 비교해 보세요. 표시된 문제 중 실제로 수정된 비율은 얼마인지, 짧은 목록을 받은 사이트와 긴 목록을 받은 사이트에서 그 비율이 다른지 확인할 수 있습니다. 대략적인 수치라도 하나 나오면 보고서 길이에 관한 논쟁을 이론보다 빨리 끝낼 수 있습니다. “표시된 문제 중 60일 안에 X%가 수정됐습니다”라는 수치는 완전성 지표보다 랜딩 페이지에 쓰기에도 더 강합니다.
• @Mythex — 목록 맨 위에는 세 항목을 두되 각 항목을 완결된 정보로 만드세요. 무엇이 문제인지, 어느 URL에서 발생했는지, 이 사이트에서 왜 중요한지, 수정 후 어떤 검사를 통과해야 하는지 적으면 됩니다. 전체 목록은 아래에 기본적으로 접어 두면 됩니다. ‘다시 검사’ 기능도 과소평가하기 쉽습니다. 문제 하나만 다시 검사하는 버튼은 사용자가 작은 성공을 마무리하게 하고, 그 경험이 다음 항목으로 돌아오게 합니다.
• @octyn — 100개 항목이 담긴 결과와 3개 항목 목록은 서로 다른 일을 하므로 둘 중 하나를 고를 필요는 없습니다. 완전한 목록은 검사 비용을 지불할 만하다는 느낌을 주고, 짧은 목록은 실제로 월요일 아침에 행동하게 합니다. 긴 목록은 사실상 마케팅이고 짧은 목록은 제품입니다. 둘을 뒤바꿔 보여주는 게 유일한 실수입니다.
  • @prasibv — “아무도 배정되지 않음”과 “배정됐지만 끝나지 않음”이라는 구분을 놓치고 있었습니다. 아무 일도 일어나지 않은 상황을 한 가지 문제로 취급했는데, 둘은 다른 문제이고 해결책도 다릅니다. 제품 전체를 바꾸기 전에 보고서 하나로 시험해 보라는 제안이 특히 와닿았습니다. 기능을 먼저 만들고 쓰이는지 확인하는 것보다 사용자 세 명에게 직접 시험해 보는 편이 빠르고 더 많이 배울 수 있습니다.
• @aryan_sinh — 우선순위를 좁힌 보고서로 사용자가 실제로 더 많은 수정을 완료하나요? 아니면 병목이 문제를 찾는 단계에서 문제를 고치는 방법을 아는 단계로 옮겨가나요?
  • @prasibv — 아직 사용자 수가 충분하지 않아 데이터로 답할 수는 없습니다. 다만 병목이 옮겨간다는 말씀은 맞을 것 같습니다. 보고서를 줄여서 “어디서 시작할지 모르겠다”는 문제는 해결했지만, “무엇을 해야 하는지는 알겠는데 어떻게 하는지 모르겠다”는 문제는 해결하지 못했습니다. 오히려 실행 경로가 없는 명확한 항목 세 개가 무시할 수 있는 항목 40개보다 더 답답할 수도 있습니다. 검증 단계와 담당자 지정 논의도 모두 문제를 찾는 일보다 수정하는 일이 어렵다는 점을 가리킵니다.
• @jessie_geo — 점수를 ‘준비도’로 바꾸는 편이 정직하며, 크롤링 보고서와 인용 확인 절차는 분리하는 게 좋습니다. 그래야 ‘인용 가능한 상태’와 ‘실제로 인용됨’을 혼동하지 않습니다. 주간 검사는 가능한 경우 같은 프롬프트와 모델 설정을 쓰고 원래 답변을 저장한 뒤, 인용됨·언급됨·바꿔 말해짐·나타나지 않음으로 분류해 보세요. 잡음이 있으니 한 번 빠진 결과는 우연으로 보고, 3주 연속 나타나지 않을 때 신호로 취급하는 편이 낫습니다.

원문: Indie Hackers / 번역·요약: Trawling