"잘 되는 것 같다"는 느낌만 믿고 AI를 붙였다간

요즘 요약·번역·분류에 RAG까지, AI 기능을 이것저것 붙여봤다. 그런데 막상 "이거 잘 되는 거 맞아?"라고 물으면 자신 있게 답을 못 하겠더라.

구체적으로는 도메인 지식이 부족해서 "정말로 개선된 거 맞아?"라는 의문이, 기술적으로는 AI에 대한 지식과 경험이 부족해서 "정말 환각이 안 일어날까?"라는 의구심이 들었다. 그저 데모 몇 개 돌려보고 "오 되네" 했을 뿐이었다. 😅

데모 몇 개로 판단하는 건, 거울만 보고 다이어트 성공했다는 소리

거울은 그날 조명이랑 각도, 심지어 기분에 따라 다르게 보인다. 체중계에 안 올라가면 진짜 빠진 건지 알 수가 없다. AI도 똑같다. 눈으로 몇 개 훑어보고 "괜찮은데?" 하는 건 딱 그 수준의 판단이다.

프롬프트 하나 고쳐서 이 질문이 좋아진 것 같아도, 뒤에서 다른 50개가 조용히 망가졌을 수 있다. 내가 운 좋게 잘 되는 표본만 골라 본 걸 수도 있고.

진짜 문제는 고도화 과정이라고 본다. 이전 버전에 비해 얼마나 나아졌는지를 측정하지 않으면, 개선이 된 건지, 제자리인지, 오히려 퇴보한 건 아닌지 감에 의존할 수밖에 없다.

측정하지 않으면, 개선 성공 여부를 알기 어렵다

숫자가 없으면 개선이 쌓이질 않는다. A안이 나은지 B안이 나은지도 결국 감으로 우기게 되고(심지어 실무자마다 관점도 다르다...), "이 정도면 출시해도 되나?"라는 기준선도 세울 수가 없다. 나는 이 부분이 제일 답답했다. 열심히 고치긴 하는데, 개선 결과를 실무자의 정성적 평가 한두 건에 의존해야 하니까.

결국 필요한 건 채점할 '정답지'였다

시험을 채점하려면 답안지가 있어야 하듯, 모델 점수를 매기려면 비교 기준이 되는 정답셋이 있어야 한다. 부르는 이름만 다를 뿐 ground truth, reference, 정답셋 다 같은 얘기다.

근데 아무 답이나 모아둔다고 정답지가 되는 게 아니더라. 두 가지가 필요하다. 정확성 — 답이 실제로 맞아야 하고, 대표성 — 현실에서 튀어나올 상황들을 골고루 담아야 한다. 이게 부실하면 멀쩡한 모델을 오히려 나쁘다고 오판하게 된다. 저품질 정답지는 없느니만 못하다.

그리고 작업마다 정답의 생김새가 다르다는 게 은근 함정이다:

• 요약 → 리뷰 원문에 대한 모범 요약
• 번역 → 원문에 대한 기준 번역
• RAG → 질문에 대한 정답 + 그 근거
• 분류 → 문의에 대한 정답 라벨

다만 분류·RAG처럼 정답이 또렷한 작업과 달리, 요약·번역은 "정답"이 하나로 딱 떨어지지 않는다. 사람이 써도 열 명이 열 가지로 쓰니까. 특히 문학 쪽으로 갈수록 심하다. 오죽하면 "초월번역"이라는 말이 생기고, 어떤 회사는 번역가가 아니라 "번역작가"라고까지 부르겠는가? 그래서 이런 생성 작업에서 정답지는 유일한 정답이라기보다 "기준점"에 가깝고, 다중 참조나 LLM 채점 같은 걸로 보완해야 한다고 이해했다.

그래서 다음부터는

평가의 첫걸음은 화려한 측정 도구가 아니라 정답지 만들기다. 귀찮아서 자꾸 뒤로 미뤄왔는데, 결국 이게 없으면 "잘 되는 것 같다"는 주관적 착각에서 못 벗어난다.

또, 실무자 간의 관점 차이 때문에 한쪽에서는 "A가 좋다", 다른 쪽에서는 "B가 좋다"는 식으로 뒤늦게 교착 상태에 빠질 수도 있다. 다음 기능부터는 기획 단계에서 정답지와 배포 가능 기준부터 잡아둘 것이다.