AI 진단의 신뢰도를 높인 건 AI에게 덜 맡기는 것이었다

같은 페이지에 매번 다른 점수를 주던 AI를, 믿을 수 있는 진단으로 만들기까지

저희가 만드는 서비스는 웹페이지를 진단합니다. 주소를 넣으면 이 페이지가 AI 검색에 잘 노출될 수 있는지를 항목별로 따져 점수를 매기고, 무엇을 고치면 좋은지 알려줍니다. 진단이 핵심인 제품이죠. 그리고 진단을 내놓는 제품에게 가장 중요한 건 하나입니다. 그 진단을 고객이 믿을 수 있어야 한다는 것입니다.

그런데 초기에 저희는 그 신뢰를 스스로 무너뜨릴 뻔했습니다. 이 글은 AI에게 채점이나 판정, 평가를 맡기는 제품을 만드는 분들을 위해 썼습니다. AI를 기능으로 얹으면 데모는 근사하게 나오는데, 막상 실제 사용자에게 내놓으려 하면 전혀 다른 문제가 시작되거든요. 그 간극을 어떻게 메웠는지에 대한 기록입니다.

미리 요점만 짚어보면?

• 초기엔 AI에게 진단을 통째로 맡겼더니, 같은 페이지인데 볼 때마다 점수가 달랐습니다.
• 그래서 역할을 나눴습니다. 확인할 수 있는 사실은 코드가 판정하고, 판단이 필요한 것만 AI에게 맡겼습니다.
• 신뢰는 AI를 완벽하게 만드는 게 아니라, AI가 틀려도 되는 곳과 틀리면 안 되는 곳을 가르는 데서 나왔습니다.

같은 페이지를 세 번 봤는데 점수가 달랐습니다

아마 지난 1편 ‘콘텐츠 열심히 만들어도 왜 AI는 우리 회사를 모를까?’를 읽으신 분이라면 이 장면을 기억하실지도 모르겠습니다. 같은 페이지를 세 번 돌렸는데 점수가 72점, 85점, 61점으로 나왔던 이야기입니다. 진단을 대부분 AI에게 통째로 맡겼더니 벌어진 일이었죠.

데모에선 그럴 듯했습니다. 설명도 매끄럽고 감탄도 나왔죠. 그런데 돌려볼 때마다 답이 달라지는 진단을, 돈을 내고 쓰는 고객이 믿어줄 리 없었습니다. 그 세 개의 숫자를 보고 저희는 AI에게 전부 맡긴다는 생각을 접었습니다.

1편에서는 여기까지, 그러니까 ‘사실 확인은 코드, 판단은 AI로 나눴다’는 결론만 짧게 말하고 넘어갔습니다. 그런데 막상 그 말대로 역할을 가르는 일은 한 문장으로 끝나지 않았습니다. 무엇보다 ‘확인할 수 있는 사실’이라는 게 생각보다 호락호락하지 않았거든요. 이 글은 그 결론 뒤에서 실제로 무엇과 씨름했는지에 대한 기록입니다.

확인할 수 있는 사실은 코드에게

먼저 한 일은 AI가 하던 일을 둘로 나누는 것이었습니다. 한쪽은 “사실 확인”, 다른 한쪽은 “판단”. 이 둘은 성격이 완전히 다른데, 초기엔 둘 다 AI에게 떠넘긴 게 화근이었습니다.

사실 확인은 애초에 판단이 필요 없는 영역입니다. robots.txt라는 파일이 있는가, 특정 태그가 페이지에 들어 있는가, 보안 연결이 걸려 있는가. 이런 건 답이 정해져 있어서 코드가 확인하면 100% 맞습니다. 여기에 AI의 해석이 끼어들 이유가 없었습니다. 오히려 끼어들어서 “있는 것 같다”는 애매한 답을 내는 게 문제였죠.

다만 이 “사실 확인”도 생각만큼 단순하지는 않았습니다. robots.txt 같은 파일이 있는지 볼 때, 그 주소로 요청을 보내 정상 응답(200)이 왔는지만 보면 될 것 같지만 그렇지 않았습니다. 분명 200이 왔다고 기록돼 있는데 정작 그 안에 담긴 건 robots.txt가 아니라 사이트의 에러 페이지인 경우가 쌓이고 있었거든요. 요즘 웹사이트는 없는 주소를 요청해도 에러 화면을 정상 응답으로 돌려주는 일이 많습니다. 응답 코드만 믿었다면 “파일이 있다”고 판정하고 그냥 넘어갔을 겁니다. 그래서 응답이 정상인지뿐 아니라, 그 내용이 실제로 robots.txt나 사이트맵의 형식을 담고 있는지까지 확인하도록 고쳤습니다.

고객이 직접 짚어준 함정도 있었습니다. 어떤 고객의 robots.txt는 맨 위에 전체 차단(Disallow: /)이 걸려 있었습니다. 저희 초기 검증은 그 한 줄만 보고 “검색 로봇을 전부 막아두셨다”며 수정 가이드를 띄웠죠. 그런데 그 아래에는 검색엔진별로, 또 폴더별로 필요한 경로를 다시 열어둔(Allow) 규칙이 붙어 있었습니다. 전체를 막아두고 들여보낼 곳만 골라 허용하는, 오히려 꼼꼼한 설정이었던 겁니다. “우리는 제대로 열어뒀는데 왜 막혔다고 나오느냐”는 고객의 피드백을 받고서야, 저희 검증이 첫 줄만 보고 성급하게 판정했다는 걸 알았습니다. 그 뒤로는 규칙을 끝까지 읽고 봇과 경로별 예외까지 반영해 판정하도록 고쳤습니다.

이런 함정은 한둘이 아니었습니다. 사람 눈엔 같은 사이트인데, 주소 앞에 www가 붙었는지 아닌지에 따라 기계는 다른 사이트로 셉니다. 이걸 그냥 두면 같은 곳을 두 번 진단하거나, 같은 사이트인데 점수가 갈리는 일이 생깁니다. 그래서 이런 경우를 하나로 묶어 보도록 했습니다. 사이트맵이나 robots.txt 같은 파일이 아예 없는 사이트도 많은데, 그 하나가 없다고 관련 항목을 줄줄이 실패로 처리하면 실제보다 훨씬 나쁜 점수가 나옵니다. 그래서 “없어서 확인 자체가 안 되는 것”과 “있는데 잘못된 것”을 구분해, 없는 걸 무조건 감점하지는 않도록 나눴습니다.

모바일도 함정이었습니다. 어떤 사이트는 m으로 시작하는 별도 주소로 모바일 화면을 따로 두는데, 이걸 못 알아보면 “모바일 대응이 안 되어 있다”고 오판합니다. 실제로는 잘 되어 있는데도요. 이런 자잘한 판별을 코드로 하나씩 정리할 때마다, 진단은 조금씩 더 흔들림 없이 같은 답을 내놓았습니다. 겉보기엔 사소하지만, 이 바닥이 흔들리면 그 위의 점수는 전부 흔들립니다.

판단이 필요한 것만 AI에게, 대신 하네스를 씌워서

그렇다고 AI를 안 쓴 건 아닙니다. 사실만으로는 답할 수 없는 것들이 있으니까요. “이 콘텐츠가 전문가가 쓴 것처럼 보이는가”, “내용이 믿을 만한가” 같은 건 정답이 딱 떨어지지 않습니다. 이런 정성적인 판단은 오히려 AI가 사람보다 일관되게, 지치지 않고 해줍니다. 문제는 초기처럼 그냥 통째로 맡기면 흔들린다는 것이었습니다. 그래서 AI를 그대로 믿는 대신, 그 주위에 입력과 출력을 단단히 묶어두는 장치를 둘렀습니다. 저희는 이걸 하네스(harness)라고 부릅니다. 모델 자체를 더 똑똑하게 만드는 게 아니라, 모델이 틀릴 수 있다는 전제를 깔고 그 틀림이 최종 결과까지 번지지 않게 가두는 뼈대입니다.

먼저 한 번에 모든 걸 묻지 않았습니다. “이 페이지 어때?”처럼 크게 물으면 답이 산만해지고 매번 달라집니다. 그래서 판단해야 할 항목을 잘게 쪼개, 좁고 분명한 질문을 여러 번 던지는 방식으로 바꿨습니다. “이 글이 전문가가 쓴 것 같아?”처럼 뭉뚱그려 묻는 대신, “저자가 누구인지 본문에 드러나 있어?”, “주장에 근거나 출처가 붙어 있어?”처럼 확인 가능한 조각으로 나눠 물었습니다. 질문이 좁아질수록 답의 편차도 줄었습니다.

좁게 물어도 AI가 엉뚱한 걸 집어오는 일은 있었습니다. 한번은 “이 글의 저자가 본문에 드러나 있냐”고 물었더니, 페이지 아래 댓글 입력란에 적힌 임의의 닉네임을 저자로 끌어온 적이 있습니다. 사람이 보면 저건 저자가 아니라 댓글 칸이라는 걸 바로 아는데, AI는 이름처럼 생긴 글자를 그럴듯하게 저자라고 답한 거죠. 그래서 저자를 어디서 찾을지 범위를 좁혀주고, 댓글이나 입력란처럼 저자가 있을 리 없는 영역은 아예 보지 않도록 손봤습니다.

그리고 AI가 준 답도 그대로 믿지 않았습니다. AI의 답이 정해진 형식에 맞는지 한 번 더 검사하고, 형식을 벗어나거나 있지도 않은 값을 지어내면 그 단계에서 걸러냈습니다. AI를 신뢰하되, 그 신뢰를 검증으로 뒷받침한 겁니다. 이렇게 역할을 가르고 하네스를 씌우고 나서는, 같은 페이지를 다시 돌려도 점수가 예전처럼 크게 튀지 않았습니다.

페이지의 성격부터 정확히 봐야 했습니다

한 가지가 더 있었습니다. 같은 항목이라도 페이지 성격에 따라 잣대가 달라야 한다는 점입니다. 뉴스 기사에 어울리는 기준과 쇼핑몰 상품 페이지에 어울리는 기준은 다르니까요. 그런데 이 성격을 알아내는 일, 그러니까 이 페이지가 대체 어떤 페이지인지를 기계에 이해시키는 게 생각보다 까다로웠습니다.

처음엔 이것도 AI에게 페이지를 보여주고 키워드 몇 개로 성격을 짐작하게 했습니다. 그랬더니 헤더에 장바구니 버튼 하나가 들어 있다는 이유로, 실제로는 이벤트 안내 페이지나 단순 소개 페이지인데도 전부 상품 페이지로 인식해버렸습니다. 그 결과 상품 페이지에나 필요한 항목들이 잣대로 들이대지면서, 멀쩡한 페이지에 엉뚱한 감점과 맞지 않는 개선 가이드가 따라붙었습니다. 진단이 첫 단추부터 어긋난 거죠.

그래서 페이지 성격을 알아내는 것도 AI의 어림짐작이 아니라, 페이지에 실제로 담긴 단서들을 정해진 순서로 따져 판별하도록 바꿨습니다. 버튼 하나 같은 단편적인 신호가 아니라 여러 단서를 종합해서, 무엇을 근거로 이 페이지를 그 유형으로 봤는지 설명할 수 있게 만든 겁니다. 진단의 출발점이 흔들리지 않아야, 그 위에 쌓는 점수도 흔들리지 않았습니다.

결국 신뢰는 ‘틀려도 되는 곳’을 가르는 데서 나왔습니다

돌아보면 저희가 한 일은 AI를 더 똑똑하게 만든 게 아니라, AI가 틀려도 괜찮은 자리와 절대 틀리면 안 되는 자리를 갈라놓은 것이었습니다. 확인할 수 있는 사실은 코드에게 맡겨 바닥을 다지고, 판단이 필요한 것만 AI에게 좁게 물어보고, 그 답조차 다시 검증하고요. 진단을 믿게 만든 건 AI를 완벽하게 만드는 일이 아니라, 바로 그 사이에 분명한 선을 하나 긋는 일이었습니다.

물론 이걸로 다 해결된 건 아닙니다. 정성적인 판단에는 여전히 미세한 편차가 남아 있고, 그래서 저희는 그런 지표를 단독으로 내세우기보다 보조적으로 다룹니다. 완벽하게 똑같은 답을 강요하기보다, 흔들려도 되는 곳과 흔들리면 안 되는 곳을 구분하는 쪽을 택한 셈입니다.

AI를 얹은 제품이 점점 늘고 있습니다. 그때마다 저는 같은 질문을 먼저 하게 됩니다. 이 기능에서 AI가 틀려도 되는 부분은 어디고, 절대 틀리면 안 되는 부분은 어디인가. 그 선을 긋는 것이 곧 제품의 신뢰를 긋는 일이었습니다.

다음 편에서는 이 진단의 기준 자체를 어떻게 세웠는지, 그러니까 “AI는 어떤 콘텐츠를 인용하고 어떤 콘텐츠는 그냥 지나치는가”를 저희가 직접 들여다본 데이터와 함께 풀어보겠습니다.

※이 글은 AI의 도움을 받아 작성했습니다. 초반 구조 설계와 자료 정리에 AI를 활용했으며, 데이터 해석과 판단, 최종 문장은 직접 작성했습니다.

현재 FDE로 일하시거나, 최근 1년 내 일하셨던 분들은

“국내 FDE 현황 조사 2026” 참여하고, 리포트 & 네이버페이 포인트 받아가세요!

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.