평가셋

보통의 소프트웨어는 고친 것이 잘 됐는지 확인하는 방법이 분명했습니다. 로그인 버튼을 누르면 로그인이 되거나 안 되거나 둘 중 하나여서, 회귀 테스트를 돌려 통과와 실패로 갈라 보면 끝났습니다. 회귀 테스트는 무언가를 고친 뒤 기존 기능이 깨지지 않았는지 기계가 자동으로 확인해 주는 절차입니다.

대규모 언어 모델을 붙인 기능은 이 방식에서 빠져나갑니다. 같은 회의록을 두 번 요약시키면 두 번 다 조금씩 다른 문장이 나오고, 둘 다 틀리지 않았습니다. 정답이 하나로 정해져 있지 않으니 일치 여부로 통과와 실패를 가를 수가 없습니다.

그래서 프롬프트 엔지니어링으로 지시문을 손볼 때마다 같은 대화가 반복됐습니다. 지시문은 모델에게 무엇을 어떻게 하라고 적어 주는 글인데, 그것을 고친 개발자가 "훨씬 나아졌어요" 라고 말하면 기획자가 자기 문서 두 개를 넣어 보고 "저는 오히려 나빠진 것 같은데요" 라고 답합니다. 양쪽 다 근거가 사례 두세 건이라 누구도 상대를 설득하지 못하고, 한 달 뒤 고객이 불평하고 나서야 그 변경이 문제였다는 것을 압니다.

평가셋은 이 판정을 사례 싸움에서 떼어 내려고 만든 묶음입니다. 판단에 쓸 사례를 미리 골라 파일로 고정해 두고, 무엇을 바꾸든 그 고정된 묶음을 통째로 다시 돌려 점수를 견줍니다. 바뀌는 것은 지시문이나 모델뿐이고 재는 자는 그대로입니다.

평가셋 하나는 세 가지로 이뤄집니다. 모델에 넣을 입력 목록, 각 입력에 기대하는 답, 그리고 나온 답을 점수로 바꾸는 채점 방법입니다.

1. 입력 목록 — 실제로 모델에 넣을 케이스를 모아 둔 것입니다. 페이지덱의 회의록 요약 기능이라면 회의록 원문 마흔 건이 여기 들어갑니다.
2. 기대하는 답 — 각 입력에 무엇이 맞는 답인지 적어 둡니다. 정답 문장을 통째로 적어 두기는 어려우니, 대개는 답에 반드시 들어가야 할 항목을 적습니다. "마감이 3월 20일로 정해졌다는 내용이 들어 있어야 한다" 같은 식입니다.
3. 채점 방법 — 나온 답과 기대하는 답을 견줘 점수를 매기는 규칙입니다. 정해진 숫자나 단어가 들어 있는지 기계가 대조하는 방식, 사람이 읽고 점수를 주는 방식, 다른 모델에게 채점을 맡기는 방식을 섞어 씁니다. 앞으로 갈수록 값이 싸고 뒤로 갈수록 미묘한 차이를 잡아냅니다.

케이스를 쉬운 것으로만 채우면 묶음이 제 일을 못 합니다. 점수가 늘 95점 근처로 나와서 무엇을 바꾸든 눈금이 움직이지 않기 때문입니다. 실제로 틀렸던 사례를 넣는 편이 확실합니다. 고객이 잘못된 답을 받았다고 알려 온 건, 사내에서 쓰다가 이상하게 나온 건을 발견할 때마다 묶음에 집어넣습니다.

규모는 서른에서 백 건 사이에서 시작하는 편입니다. 열 건이면 한 건이 달라질 때마다 점수가 10점씩 튀어 차이를 읽을 수 없고, 천 건이면 사람이 읽어 채점하는 몫을 감당하지 못합니다.

사내 자료를 찾아 붙여 답하게 만드는 RAG 방식이라면 채점 대상이 하나 늘어납니다. 답만 보는 것이 아니라 그 답의 근거로 붙여 온 자료가 맞는 자료였는지도 함께 봅니다. 답은 그럴듯한데 엉뚱한 문서를 보고 쓴 경우가 여기서 걸립니다.

케이스를 고르는 사람은 그 기능이 무엇을 잘해야 하는지 아는 사람입니다. 페이지덱에서는 기획자인 지현이 회의록 원문과 기대하는 항목을 채우고, 개발자인 태오가 그것을 돌려 점수를 냅니다. 이 순서가 뒤집히면 대개 묶음이 물러집니다. 개발자가 케이스까지 고르면 다루기 편한 입력만 모이고, 정작 고객이 걸려 넘어진 지저분한 회의록은 빠집니다.

읽는 사람은 셋입니다.

1. 고친 사람 — 지시문이나 모델을 바꾼 개발자가 올리기 전에 돌려 봅니다. 점수가 내려가면 그 변경은 나가지 않습니다.
2. 내보낼지 정하는 사람 — 기능을 열지 말지 판단하는 자리에서 씁니다. "요약 기능 열어도 될까요" 에 "평가셋 82점입니다" 로 답하면 적어도 같은 숫자를 놓고 이야기하게 됩니다.
3. 나중에 온 사람 — 반년 뒤 이 기능을 물려받은 사람이 평가셋을 읽고 이 기능이 무엇을 잘해야 하는 물건인지 파악합니다. 기대하는 답을 모아 둔 파일이 사실상 기능 명세 노릇을 합니다.

"평가셋 돌려 보고 점수 떨어지면 이 지시문은 안 올릴게요."

고친 쪽이 보기에 좋아 보여도 고정된 묶음에서 점수가 내려가면 되돌리겠다는 뜻입니다.

"그 케이스 평가셋에 넣어 두셨어요? 다음에 또 똑같이 틀릴 텐데요."

한 번 찾아낸 오류를 묶음에 등록해 두지 않으면 같은 실수가 다시 새어 나간다는 지적입니다.

"지금 스무 건뿐이라 이 점수 차이는 믿을 만하지 않아요."

케이스가 적어서 점수가 오른 것이 실제 개선인지 우연인지 가를 수 없다는 뜻입니다.

페이지덱에서 요약 기능의 지시문을 고칠 때 오가는 대화입니다. 태오가 지시문을 손보면 먼저 마흔 건짜리 묶음을 돌려 이전 점수와 나란히 붙여 놓습니다. 전체 점수가 올랐어도 내려간 케이스가 있으면 그 건을 열어 읽어 봅니다. 평균만 보고 넘기면 특정 종류의 회의록에서만 답이 나빠지는 변경을 놓치기 때문입니다.

지현은 여기서 숫자보다 빠진 케이스를 봅니다. 고객 문의로 들어온 사례가 아직 묶음에 없으면 그것부터 추가하자고 말합니다.

평가셋 점수를 기능의 품질 점수로 읽는 일이 가장 잦습니다. 82점이라는 값을 들으면 열 명 중 여덟 명은 만족한다는 뜻으로 받아들이게 됩니다. 실제로 이 값은 우리가 고른 마흔 건에서 우리가 정한 규칙으로 매긴 점수일 뿐입니다. 케이스를 다르게 고르면 같은 기능이 60점도 되고 90점도 됩니다. 이 숫자를 밖으로 들고 나가 다른 팀이나 다른 제품과 견주기 시작하면, 케이스를 후하게 고른 쪽이 늘 이기는 경쟁이 됩니다.

한 번 만들어 두면 계속 쓸 수 있다고 여기는 것도 흔한 오해입니다. 파일 형태라 코드보다 덜 낡을 것처럼 보이기 때문입니다. 실제로는 제품이 바뀌면 기대하는 답도 바뀝니다. 요약에 결정 사항만 담기로 정책을 바꾸면 예전에 만들어 둔 기대 항목이 전부 틀린 기준이 됩니다. 그대로 두면 평가셋은 옛 제품을 채점하는 자가 되고, 점수가 떨어졌다는 경고가 뜰 때마다 사람들이 그것을 무시하는 습관이 붙습니다. 그 습관이 붙고 나면 진짜 환각이 늘어난 날의 경고도 함께 묻힙니다.