AI가 만든 것을 어떻게 검증하십니까 — 답을 가리고, 틀린 것을 세는 법

만들 수 있느냐는 이제 질문이 아닙니다. 만든 것이 맞는지 누가, 어떻게 확인하느냐가 질문입니다.

만드는 속도는 이미 문제가 아닙니다

요즘 AI 도입 상담에서 "이걸 만들 수 있느냐"는 질문은 거의 나오지 않습니다. 대체로 만들어집니다. 남는 질문은 하나입니다. 만들어진 것이 맞는지 어떻게 아느냐.

이 확인 작업은 저절로 되지 않습니다. 결과가 그럴듯해 보이는 것과 맞는 것은 다르고, 특히 보고서·분석·판정처럼 형태가 정해진 결과물은 틀려도 티가 나지 않습니다.

저희는 최근 이 문제를 정면으로 다뤄야 하는 일을 하나 했습니다. 오래 굳어진 체계 하나를 AI로 옮겨 풀이를 생성하는 일이었는데, 완성한 순간 곧바로 벽에 부딪혔습니다. 잘 맞는다는 후기를 백 개 모아도 그것은 증거가 되지 않습니다. 사람은 맞은 것만 기억하기 때문입니다.

그때 세운 검증 절차를, 업무에 그대로 옮길 수 있는 형태로 정리했습니다.

하나. 답이 이미 나와 있는 사례를 고르십시오

검증의 출발점은 정답을 이미 아는 문제입니다.

회사 업무라면 결론이 난 지난 건들이 여기에 해당합니다. 작년에 승인·반려가 갈린 신청서, 이미 결과가 나온 견적, 클레임으로 이어졌던 주문. 결과를 아는 사례가 충분히 쌓여 있는 영역부터 손대야 검증이 가능합니다.

거꾸로 말하면 답안지를 만들 수 없는 일은 지금 착수할 때가 아닙니다. 결과가 몇 년 뒤에 나오는 일, 사람마다 판단이 갈리는 일이 그렇습니다.

둘. 답을 가린 채 풀리십시오

여기가 대부분 빠뜨리는 단계입니다.

AI에게 사례를 주면서 결론을 짐작할 단서까지 함께 주면, 그것이 맞혔을 때 우리는 아무것도 알아내지 못합니다. 맞힌 것인지, 알고 있던 것을 옮겨 적은 것인지 구분할 수 없기 때문입니다.

그래서 저희는 결론으로 이어질 만한 정보를 전부 지웠습니다. 대상이 누구인지, 언제·어디의 일인지 알 수 있는 값을 하나도 남기지 않았습니다. 그리고 실제로 지워졌는지 기계적으로 확인했습니다 — AI에게 들어가는 글 전체를 단서가 될 만한 낱말로 훑어, 하나라도 걸리면 검증을 중단하도록 했습니다.

이 확인 단계가 없으면 블라인드는 선언에 그칩니다. 실무에서도 마찬가지입니다. 지난 사례를 넣을 때 결과 컬럼만 지우고 결과를 암시하는 메모는 그대로 남겨 두는 실수가 대단히 흔합니다.

셋. 판정 기준을 미리 적으십시오

결과를 본 뒤에 기준을 만들면 무엇이든 맞은 것처럼 보입니다.

그래서 무엇을 "맞았다"고 볼지, 무엇을 "빗나갔다"고 볼지를 사례를 돌리기 전에 문장으로 적어 두어야 합니다. 저희는 여기에 하나를 더 붙였습니다. 맞았다고 판정한 대목은 그 근거가 되는 기록을 함께 남기게 했습니다. 근거를 못 대면 판정에서 뺍니다.

이 규칙 하나가 검증의 성격을 바꿉니다. 인상평이 아니라 셀 수 있는 것이 됩니다.

결과를 읽는 법 — 세는 방법이 절반입니다

절차보다 어려운 것이 결과 해석입니다. 네 가지를 권해 드립니다.

하나, 맞은 것과 틀린 것을 함께 셉니다. 저희 사례에서는 두 건에 대해 각각 22곳과 31곳이 기록과 맞아떨어졌고, 3곳과 6곳이 빗나갔습니다. 앞의 숫자만 적힌 보고서는 검증 결과가 아니라 홍보물입니다. 사내에서 AI 성과를 보고받으실 때 하실 질문도 이것입니다 — 몇 건이 틀렸습니까.

둘, 틀린 것을 유형으로 나눕니다. 전부 같은 실패가 아닙니다.

• 완전히 빗나간 것 — 정반대의 답을 냈습니다. 도구의 한계를 그대로 보여줍니다.
• 반만 맞은 것 — 방향은 맞는데 결론이 틀렸습니다. 대개 근거는 잡았으나 마지막 판단에서 어긋난 경우로, 사람이 한 단계만 개입하면 되는 자리입니다.
• 전제가 달라 적용되지 않는 것 — 답 자체는 말이 되는데 이 사례에 해당하지 않습니다.

셋, 세 번째 유형을 가장 눈여겨보십시오. 여기서 그 도구가 무엇을 기본값으로 가정하고 있는지가 드러납니다. 저희 사례에서 AI는 대상이 누구인지 모르는 상태에서 국내 제도를 전제한 답을 냈습니다. 우연한 실수가 아니라 학습된 기본값이 나온 것이고, 이런 기본값은 맞은 답들 속에도 똑같이 섞여 있습니다. 틀린 답이 그것을 눈에 보이게 해 준 셈입니다.

업무로 옮기면 이렇습니다. 우리 회사 규정이 아니라 업계 일반 관행으로 답하고 있지는 않은지, 최근 개정 전 기준으로 답하고 있지는 않은지 — 검증의 오답 목록이 그 실마리를 줍니다.

넷, 맞은 것도 한 번 더 나눠 봅니다. 누구에게나 맞는 말과 이 사례에서만 성립하는 말은 다릅니다. "꼼꼼한 편이지만 때로 서두른다" 같은 문장은 언제나 맞습니다. 검증에서 실제로 점수를 줘야 하는 것은 틀릴 수도 있었는데 맞은 답뿐입니다.

검증이 덤으로 알려주는 것

이번 작업에서 예상하지 못한 소득이 있었습니다. 검증 절차를 돌리는 동안 기존 시스템의 결함이 여러 건 드러났습니다.

이유는 단순합니다. 사람이 하던 판단을 기계에 맡기려면 그동안 암묵적으로 넘어가던 예외와 경계값을 전부 말로 적어야 하기 때문입니다. 그 과정에서 원래 있던 오류가 함께 올라옵니다.

특히 경계값이 그렇습니다. 사람이 눈으로 볼 때는 자연스럽게 넘어가던 자리가, 계산으로 옮기는 순간 결과를 가르는 선이 됩니다. 실제로 저희 사례에서는 입력 하나가 아주 조금 어긋난 것 때문에 결과의 한 축이 통째로 뒤집혔습니다. 그 사실을 검증 전에는 아무도 몰랐습니다.

AI 도입의 첫 성과가 새 자동화가 아니라 기존 업무의 오류 발견인 경우는 생각보다 흔합니다.

사후 대조와 예측은 다릅니다

마지막으로 가장 중요한 구분입니다.

지난 사례로 통과했다는 것은 지난 사례와 닮은 일에서 쓸 만하다는 뜻입니다. 앞일을 맞힌다는 뜻이 아닙니다. 저희도 리포트 안에 이 문장을 굵게 넣어 두었습니다 — 이것은 예측이 아니라 사후 대조입니다.

검증 결과를 사내에 공유하실 때 이 한 줄을 함께 적어 두시기 바랍니다. 이것이 빠지면 좋은 검증 결과가 오히려 과신의 근거가 됩니다.

정리하면

답이 나와 있는 사례를 고르고, 답을 가리고, 기준을 먼저 적고, 틀린 것까지 세십시오. 그리고 틀린 것들을 유형별로 읽으십시오. 거기에 그 도구를 어디까지 믿어도 되는지가 적혀 있습니다.

만드는 일에 반나절이 들고 검증에 그보다 오래 걸린다면, 그것은 일을 잘못한 것이 아니라 제대로 하고 있는 것입니다.

이 글의 사례가 된 리포트는 오리엔텔러에서 동일하게 확인하거나 검증할 수 있습니다.