AI 기능 품질, 점수만 보고 판단해도 될까요?

점수가 가장 높던 조합이 실제로는 문제투성이였어요

4월에 퍼플프린트 코치에 어떤 AI 모델과 지시문을 쓸지 고르려고 실험을 돌렸어요. 모델 네 개, 지시문 다섯 가지, 상황 세 개를 엮어 답을 받고 점수를 매겼어요. 가장 높은 조합은 4.41점이었고 보고서도 "채택"이라고 적었어요. 숫자만 보면 바로 붙여도 될 것 같았어요.

그런데 실제 서비스에 붙여 보니 전혀 달랐어요. "여기까지 정리됐어요"라고 말하고는 확인을 받기도 전에 다음 단계를 시작해 버렸어요. 만들어 주는 문서 모양이 매번 달랐고, 해요체로 말하라고 했는데 다른 말투가 섞였어요. 점수표에서는 작은 차이였지만, 쓰는 사람에게는 바로 크게 느껴지는 어긋남이었어요.

이걸 찾은 건 점수가 아니었어요. 실제 대화 내용을 처음부터 한 줄씩 읽어 봤기 때문이에요. 분위기가 좋은지는 점수에 잡혔지만, 정한 순서를 지켰는지, 단계를 넘어갈 때 확인을 받았는지는 따로 봐야 했어요.

몇 주 동안 0.1점을 올리려 했던 일

그 뒤로 한동안 정리 품질 점수를 올리는 데 매달렸어요. 지시문을 바꾸고, 조건을 나눠 보고, 점수와 흔들림을 다시 쟀어요. 미리 정해 둔 답으로 시험하면 좋아 보이는 신호도 있었어요.

그런데 실제처럼 답이 정해지지 않은 조건으로 가면 이야기가 달라졌어요. 말투 점수는 미리 정한 답에서는 올랐지만, 그렇지 않은 조건에서는 차이가 잡음 수준이었어요. 평균이 오른 항목도 끝내 의미 있는 개선으로 남지 못했어요. 열심히 올린 숫자가 실제 환경에서는 그대로 다시 나오지 않았던 거예요.

그때 처음 이 질문이 들었어요. 우리가 재고 있던 게 쓰는 사람이 느끼는 가치와 같은 것인가. 돌아보면 쓰는 분들은 점수 0.1 차이보다, 막히지 않고 끝까지 갈 수 있었는지에서 훨씬 큰 차이를 느꼈어요.

비싼 모델이 늘 좋은 건 아니었어요

같은 질문을 네 모델에 던져 비교했을 때도 비슷한 걸 봤어요. 값이 싼 모델이 비싼 모델과 같은 점수를 받으면서 훨씬 빨랐어요. 한쪽은 답이 2.6초 만에, 다른 쪽은 9.9초 만에 왔어요. 이 정도 차이는 쓰는 사람이 바로 느껴요.

비용도 마찬가지예요. 한 번의 대화에서는 몇 원 차이라도, 쓰는 사람이 늘면 그대로 곱해져요. 그래서 모델을 고를 때는 점수와 함께 속도와 대화 한 번의 비용을 같은 표에 적어요. 그때 시험한 모델과 숫자는 지금 쓰는 구성과 달라요. 남는 교훈은 비싼 걸 붙인다고 경험이 좋아지지는 않는다는 거예요.

지금은 이렇게 재요

지금은 코칭 규칙의 판이 바뀔 때마다 같은 시험 대화를 다시 돌려요. 그리고 규칙마다 따로 세요. 코치가 설계 용어를 썼는지, 확인 없이 단계를 넘었는지, 정한 걸 다시 물었는지처럼 기계로 셀 수 있는 건 코드로 세고, 질문이 자연스러운지처럼 판단이 필요한 건 판정용 AI로 따로 봐요. 판정용 AI도 처음에는 사람이 직접 채점한 결과와 맞춰 보고 나서 썼어요.

예를 들면 이런 식이에요. 어느 판에서 설계 용어를 쓰지 않게 규칙을 고친 뒤 같은 시험 대화를 다시 돌렸더니, 설계 용어가 나온 턴이 두 번에서 0번이 됐어요. 그리고 같은 비교에서 다른 규칙이 나빠지지 않았는지도 함께 확인했어요. 좋아진 숫자 하나만 보면, 그 대가로 무너진 다른 데를 놓쳐요.

한 번 돌린 결과로 결론 내지 않는 것도 규칙이에요. 같은 조건에서도 결과는 흔들려요. 한 회차에서 튄 숫자는 모델 차이가 아니라 그 회차의 우연일 수 있어서, 두 번 이상 돌린 결과를 나란히 놓고 봐요. 모델이나 사고 수준을 바꿀 때도 같은 입력 묶음으로 처음부터 다시 재요.

점수에 안 잡히는 문제는 대화를 읽어야 보여요

규칙을 고쳤는데 엉뚱한 데서 탈이 난 적도 있어요. 규칙에 문서의 칸 이름을 적어 두었더니, 코치가 그 칸을 채우려고 하나하나 묻기 시작했어요. 한 단계에서 선택 카드가 42장까지 늘었어요. 점수로는 질문이 성실해진 것처럼 보였지만, 쓰는 사람에게는 끝없는 질문이었어요. 그래서 "이미 나온 것으로 채우고, 칸 때문에 묻지 않는다"로 고쳤어요.

반대로 고치지 않기로 한 것도 있어요. 시험 대화 793턴 중 2턴에서, 한국어로 묻는데 코치가 한 턴만 다른 언어로 답하고 다음 턴에 돌아왔어요. 모델 쪽 흔들림으로 보여서 규칙으로 막으려 하지 않고 지켜보기로 했어요. 모든 이상을 고칠 수 있는 건 아니라서, 어디까지가 우리가 고칠 수 있는 문제인지 가르는 것도 측정의 일이에요.

내 서비스의 AI 기능을 시험할 때 볼 것

• •실제 사용자가 쓸 법한 말로 시험 입력 묶음을 만들고, 판마다 같은 묶음으로 돌린다
• •점수와 함께 대화 원문을 처음부터 끝까지 한 번은 읽는다
• •순서, 형식, 말투처럼 규칙으로 셀 수 있는 건 기계로 센다
• •한 번 돌린 결과로 결론 내지 않고, 두 번 이상 나란히 본다
• •속도와 대화 한 번의 비용을 점수 옆에 같이 적는다
• •좋아진 것만 보지 않고, 나빠진 것이 없는지 같이 본다

개발을 몰라도 이 표는 만들 수 있어요. 시험 입력 묶음과 셀 항목을 문서로 정해 두면, 코딩 에이전트에게 "이 묶음으로 돌리고 이 항목을 세어 줘"라고 맡길 수 있어요. 어떤 기준으로 재는지가 먼저 정해져 있어야 결과도 읽을 수 있어요.

시험 입력 묶음은 이렇게 만들어요

시험 입력은 실제로 쓸 사람의 상황에서 뽑아요. 퍼플프린트라면 처음 써 보는 사람, 이미 기획서를 가진 사람, 질문마다 "모르겠어요"라고 답하는 사람, 묻는 말과 다른 얘기를 하는 사람이 다 들어가요. 잘 따라오는 사람만 넣으면 점수는 좋게 나오지만, 실제로 막히는 사람은 그 묶음에 없어요.

쉬운 상황과 어려운 상황을 섞고, 한 번 정한 묶음은 함부로 바꾸지 않아요. 묶음이 바뀌면 지난 판과 비교할 수 없어서요. 새로운 문제 상황을 만나면 그 상황을 묶음에 더하되, 원래 있던 건 그대로 둬요. 그래야 고친 것이 예전에 잘 되던 걸 깨뜨리지 않았는지 같이 볼 수 있어요.

대화를 읽을 때는 이 다섯 가지를 봐요

• •첫 질문이 처음 온 사람도 바로 답할 수 있을 만큼 쉬운가
• •확인을 받기 전에 다음 단계로 넘어가지 않는가
• •앞에서 정한 걸 다른 말로 다시 묻지 않는가
• •답을 읽고 나서 다음에 할 일이 하나로 보이는가
• •처음부터 끝까지 같은 말투인가

이 다섯 가지는 점수표에 잘 안 잡혀요. 대화 전체로 보면 괜찮아 보여도, 한 턴에서 확인 없이 넘어가면 쓰는 사람은 거기서 멈춰요. 그래서 원문을 읽을 때는 잘 된 턴보다 쓰는 사람이 멈췄을 법한 턴을 찾으며 읽어요.

모델을 바꾸고 싶을 때의 순서

새 모델이 나오면 바로 바꾸고 싶어져요. 그럴 때도 순서를 지켜요. 지금 판으로 시험 묶음을 먼저 돌려 기준을 남기고, 모델만 바꿔 같은 묶음을 두 번 이상 돌린 뒤, 규칙별로 나란히 놓고 봐요. 좋아진 규칙과 나빠진 규칙이 섞여 나오면, 나빠진 쪽이 쓰는 사람에게 얼마나 큰지부터 따져요. 빨라졌는데 단계를 건너뛰기 시작했다면, 그건 바꾸면 안 되는 쪽이에요.

작은 팀이라면 이렇게 시작하세요

처음부터 거창한 측정 장치가 필요하지는 않아요. 실제 사용자 상황 열 개를 시험 입력으로 정하고, 고칠 때마다 그 열 개를 다시 돌려 원문을 읽는 것부터면 충분해요. 반복해서 보이는 문제가 생기면 그때 그 항목을 기계로 세는 규칙으로 바꾸면 돼요. 측정도 한 번에 완성하는 게 아니라 문제를 만날 때마다 자라요.

숫자 옆에 꼭 같이 적어 둘 것

결과를 남길 때는 숫자만 적지 않아요. 어느 판의 규칙인지, 언제 돌렸는지, 어떤 모델과 사고 수준이었는지, 몇 번 돌렸는지를 함께 적어요. 이게 없으면 몇 주 뒤에 "그때 왜 좋았지"를 아무도 설명하지 못하고, 같은 실험을 다시 하게 돼요.

점수를 만들 때 자주 하는 실수

• •시험 입력에 정답을 미리 넣어 두어, 실제보다 쉽게 시험한다
• •입력 몇 개만으로 돌리고 평균 하나로 결론 낸다
• •고칠 때마다 채점 기준도 같이 바꿔서, 전과 비교할 수 없게 된다
• •점수가 오른 판을 바로 내보내고, 실제 대화는 읽어 보지 않는다

숫자가 무엇을 대신 말하는지 같이 봐요

숫자는 분명 중요해요. 다만 숫자가 무엇을 대신해 말하고 있는지까지 같이 봐야 해요. 측정하는 대상 자체를 의심해야 하는 순간이 있어요. 실제로 써 보는 건 나중에 하는 확인이 아니라, 무엇을 잴지 정하는 일의 일부예요.