내 AI 판정 시스템에 평가를 붙였다가, "버그"인 줄 알았던 게 내가 만든 설계였음을 깨달은 이야기
지피터스에서는 웨비나가 끝나면 참가자들이 SNS에 후기를 올리고, 그 인증을 확인해 리워드를 드립니다. 저는 이 확인 작업을, 이미지를 읽는 AI에게 맡겨 두었어요. 매주 웨비나마다 조용히 돌아가는, 손이 많이 가던 일을 덜어준 고마운 자동화였습니다.
그런데 문득 이런 생각이 들었어요. 이 AI, 실제로 얼마나 잘하고 있는 거지?
돌려보면 그럴듯한 판정을 내놓으니 "잘 되나 보다" 하고 넘어갔을 뿐, 한 번도 진지하게 성적표를 매겨본 적이 없었습니다. 이번에 그 "잘 되는 것 같다"를 숫자로 바꿔보기로 했고, 그 과정에서 예상과 전혀 다른 걸 배웠습니다.
🎯 마침 이번주 사내 주제가 'AI 평가'였다
저희 팀은 매주 사내에서 '로나'라는 프로젝트를 돌립니다. 매번 주제가 바뀌는데, 이번주 주제가 바로 AI Evaluation(AI 평가) — "내가 만든 AI 기능에 평가를 제대로 붙여보자"였어요.
주제를 받고 바로 정했습니다. 남의 예제 말고, 내 진짜 판정 시스템을 대상으로 삼자. 마침 지난 웨비나 세 번 분량의 실제 판정 기록이 그대로 남아 있었고, 각 건마다 "사람이 최종적으로 어떻게 결론 냈는지"까지 붙어 있었거든요. 채점 기준이 될 정답이 이미 있는 셈이라, 평가 재료로는 더할 나위 없었습니다.
🛠️ AI를 평가한다는 건, 감을 숫자로 바꾸는 순서다
AI 기능에는 함정이 하나 있습니다. 자신 있게 틀린다는 것. 사람이 짠 일반 프로그램은 2 더하기 2가 틀리면 바로 티가 나지만, AI는 같은 걸 봐도 매번 조금씩 다르게 판단하고 "좋은 답"의 정답이 하나로 고정되지 않습니다. 그래서 예시 두세 개가 잘 나오는 걸 보고 배포하면, 다른 케이스가 조용히 망가져도 모릅니다.
그래서 거창한 도구 없이, 순서대로 밟았습니다. 이 순서 자체가 저한테는 계속 작 은 깨달음을 줬어요.
먼저 "좋은 판정이란 무엇인가"를 확인 가능한 3줄로 못 박았습니다. 여기서 첫 번째 깨달음이 왔어요. "자연스럽다", "괜찮다" 같은 말은 채점할 수가 없습니다. 제 경우 제일 중요한 한 줄은 "정당하게 후기를 쓴 참가자를 부정으로 오해하지 않는다"였어요. 리워드를 놓치면 그게 곧 고객 불만이니까요. 목표를 이렇게 Pass/Fail로 답할 수 있게 바꾸지 않으면, 뒤의 모든 측정이 허공에 뜹니다.
그다음 실제 판정 기록을 한 줄씩 직접 읽었습니다. 여기서 두 번째 깨달음. 통계를 돌리거나 AI에게 "왜 틀렸어?"라고 묻고 싶은 유혹이 컸는데, 그러면 안 되더라고요. AI에게 물으면 그럴듯한 이유를 지어내고, 미리 만든 분류표에 끼워 맞추면 진짜 반복되는 문제는 안 보입니다. 사람이 맨눈으로 먼저 읽는 것 — 이게 평가의 진짜 출발점이었습니다.
🔍 읽다 보니 드러난 진실 (그리고 아하 모먼트)
기록을 하나하나 읽다 보니, 눈에 걸리는 숫자가 나왔습니다. AI가 "이거 의심스럽다"고 찍은 게 쉰두 건이었는데, 그중 사람이 다시 봐서 되살린 게 쉰한 건. 열 번 의심하면 아홉 번 반은 뒤집힌 겁니다.
처음엔 아찔했어요. "내 AI가 이렇게 헛발질을 하고 있었나?"
그런데 그 쉰한 건을 계속 읽다 보니 공통점이 보였습니다. 대부분 이런 경우였어요. 참가자가 후기는 멀쩡히 올렸는데, 폼에 캡처를 첨부할 때 실수로 줌 화면이나 발표 슬라이드를 넣은 겁니다. 이미지만 보면 "후기가 아니네?" 싶지만, 본인이 올린 SNS 링크를 열어보면 진짜 후기가 있는 거죠.
그 순간 기억이 났습니다. 몇 달 전에 제가 바로 이 상황 때문에 규칙을 하나 넣었다는 것. "이미지가 애매하면 함부로 탈락시키지 말고, 사람 검수 큐로 넘겨라." 실제로 예전 한 회차에서 이 처리를 안 했다가, 진짜 후기를 쓴 참가자 네댓 명을 부당하게 제외할 뻔한 적이 있었거든요.
여기서 이 실습의 가장 큰 아하 모먼트가 왔습니다. 그 "의심 쉰한 건"은 시스템이 틀린 게 아니라, 제가 만든 안전그물이 설계한 대로 정확히 작동한 결과였어요. 자동으로 확신할 수 없는 애매한 건을 사람 앞에 가져다 놓는 것 — 그게 원래 의도였습니다. 저는 하마터면 제가 공들여 만든 안전장치를 "98% 오작동"으로 오해하고 멀쩡한 설계를 뜯어고칠 뻔했습니다.
평가를 붙이는 진짜 이유는 버그를 찾는 게 아니라, "의도한 동작"과 "진짜 고장"을 구분하게 만드는 것이었습니다.
🔧 나머지 단계에서 얻은 것들
깨달음을 얻고 나서, 남은 순서를 마저 밟았습니다. 각 단계가 또 하나씩 배움을 줬어요.
사람 기준이 흔들리지 않는지 확인하는 단계. 같은 기록을 두 번 판정해 얼마나 일치하는지 봤는데, 단순 일치율은 95%로 완벽해 보였습니다. 그런데 제 데이터는 대부분 "포함" 결론이라, 아무렇게나 찍어도 우연히 겹치는 몫이 컸어요. 그 우연분을 빼고 다시 계산하니 실제 합의 수준은 겉보기 95%보다 눈에 띄게 낮았습니다. 높은 일치율에 속으면 안 된다는 걸 숫자로 배웠죠.
규칙으로 될 일과 판단이 필요한 일을 나누는 단계. "시스템이 이미지를 못 읽었는데 판정을 내렸다" 같은 건 규칙으로 딱 잡히니 코드에게 맡기고, "이 판단이 실제 근거에 매여 있나" 같은 진짜 판단만 AI 채점기에게 맡겼습니다. 코드로 될 일을 굳이 느리고 비싼 AI에게 시킬 이유가 없더라고요.
AI 채점기가 믿을 만한지 검증하는 단계. 재미있는 함정이 여기 있었어요. 제 채점기는 진짜 문제를 딱 절반만 잡아냈습니다. 이러면 채점기가 "문제 이만큼"이라고 보고해도 실제 문제는 그 두 배로 봐야 해요. 채점기의 성적을 먼저 재지 않으면, 채점기의 보고를 그대로 믿는 또 하나의 "감"이 될 뿐이었습니다.
마지막으로 이 전부를 한 번에 다시 돌릴 수 있는 형태로 묶었습니다. 이제 다음에 무언가 나빠지면, 배포 전에 자동으로 걸립니다. 실제로 일부러 고장 난 사례를 하나 끼워 넣어 봤더니, 검사가 그걸 정확히 잡아냈어요.
💬 그런데 진짜 고장은 없었나? 있었다, 그런데 이미 고쳐둔 거였다
이 과정에서 "진짜 고장"도 몇 개 다시 만났습니다. 이미지를 읽는 AI가 먹통이 됐을 때 백업으로 넘어가는 장치가 조용히 죽어 있던 문제, 판정 결과를 읽어들이는 부분이 통째로 깨졌던 문제.
그런데 반전이 있었어요. 그것들은 이미 제가 지난 며칠 사이에 발견해서 고치고, 재발 방지 장치까지 붙여둔 것들이었습니다. 제가 평가에 쓴 기록이 그 수리보다 이전 시점의 데이터였거든요.
그래서 이번 평가는 뜻밖의 선물을 줬습니다. 제가 감으로 "그게 문제였겠지" 하고 고쳤던 것들이, 데이터로 "맞아, 그게 진짜 문제였어"라고 뒤늦게 확인해준 거예요. 여기서 또 하나 배웠습니다. 낡은 로그로 지금 시스템을 평가하면 안 된다는 것. 제 데이터는 이미 고친 수정들보다 이전 것이라, "지금 시스템이 이렇다"고 말할 근거로는 쓸 수 없었습니다.
📋 실무자를 위한 정리
여기까지 읽으신 분들을 위해, AI 기능에 평가를 붙일 때 꼭 챙길 것을 순서대로 정리합니다.
1. 목표를 확인 가능한 문장으로 바꾼다. "좋다"를 Pass/Fail로 답할 수 있는 3줄로 못 박지 않으면 아무것도 측정할 수 없습니다.
2. 통계보다 먼저 사람이 직접 읽는다. AI에게 "왜 틀렸어?"를 묻지 마세요. 실패의 종류는 맨눈으로 읽어야 저절로 떠오릅니다.
3. "틀렸다"고 부르기 전에 설계 의도부터 확인한다. 겉으로 드러난 오류율을 그대로 믿으면, 저처럼 의도된 사람-검수 흐름을 고장으로 착각합니다. 이게 이 글의 핵심입니다.
4. 높은 일치율을 경계한다. 대부분이 한쪽 결론이면 우연히 겹치는 몫이 큽니다. 우연분을 빼고 봐야 진짜 합의 수준이 보입니다.
5. 코드로 될 일을 AI에게 시키지 않는다. 규칙으로 갈리는 건 코드에게, 진짜 판단만 AI 채점기에게.
6. 채점기의 성적부터 잰다. 채점기가 얼마나 정확한지 모른 채 그 보고를 믿으면, 감을 하나 더 얹는 것뿐입니다.
7. 낡은 로그가 아니라 현재 시스템으로 평가한다. 그래야 "지금" 이야기를 할 수 있습니다.
하나 덧붙이면, 이 과정은 혼자 하지 않았습니다. 서로 다른 관점의 여러 시선으로 동시에 뜯은 뒤 각자가 찾은 문제를 서로 반박하게 했더니, "그 럴듯하지만 틀린 개선안"이 걸러졌어요. "태그가 확인되면 자동 통과시키자"는 언뜻 맞아 보이는 제안이, 실제로는 딱 하나뿐인 정답 케이스를 망가뜨리는 지뢰라는 게 드러났죠. "의심은 사실 의도된 설계"라는 깨달음도 그 반박 과정에서 붙잡을 수 있었습니다.
🚀 앞으로의 계획
이번엔 낡은 데이터로 "설계 의도와 진짜 고장"을 갈라내는 데까지 했습니다. 다음은 지금 돌아가는 현재 시스템 위에서 같은 평가를 다시 돌리는 거예요. 이미 고친 수정들이 최신 데이터에서도 효과가 있는지 확인하려고 합니다.
손볼 곳도 하나 보였습니다. 지금은 "시스템이 진짜 고장 난 경우"와 "일부러 사람에게 넘기는 경우"가 똑같은 '의심' 딱지를 달고 있어서, 검수하는 사람이 둘을 한눈에 구분하기 어렵습니다. 이 둘을 다른 이름으로 갈라두면 검수가 훨씬 수월해질 것 같아요.
그리고 이 로나 프로젝트는 매주 주제가 바뀌며 계속됩니다. 매주 다른 시스템에 같은 방식으로 평가를 붙여 나가면, 우리 팀 AI들의 "건강검진 지도"가 한 장씩 쌓이게 됩니다.
혹시 여러분도 "돌려보니 잘 되는 것 같은" AI 기능을 하나 갖고 계시다면, 딱 한 번 숫자로 재보시길 권합니다. 다만 저처럼 먼저 물어보세요. 이 숫자, 정말 고장일까 아니면 내가 그렇게 만든 걸까?
