제가 한 일은 판단 몇 번이 전부였는데, 그 판단이 전부 규칙으로 남았어요.
제가 만드는 서비스 로나는 사용자의 실제 업무에 맞는 AI 코칭을 자동으로 만들어줘요. 요즘은 업무에 도움이 될 만한 주제들을 미리 선별해두고, 그 주제로 실습을 진행하게 하는 실험을 하고 있고요. 그런데 정작 그 "자동으로 만든 코칭"의 품질 관리는 어땠냐면 — 간단한 평가 장치는 있었지만 미흡한 데가 많았어요. 특히 코칭을 생성하는 파이프라인 쪽이요.
이번에 로나 추천 코칭으로 「내 기능에 평가 붙이기 — AI eval 한 바퀴」를 받아서, 바로 이 생성 파이프라인에 평가를 붙여봤습니다. 주제를 고르니 브라우저에 진행표 창이 하나 떴고, 이후로는 이 창이 지금 어디쯤인지 계속 잡아줬어요. 진행한 순서 그대로 옮겨볼게요.
1. 어떤 걸 평가할지부터 정했어요
코칭이 제 작업 폴더를 훑더니 평가 후보 세 곳을 내밀었어요. 코칭을 만들어내는 지점, 사용자 요청을 이해하는 지점, 자료를 조사하는 지점. 최종 산출물이 나오는 생성 지점을 골랐고, '좋다'의 기준을 세 문장으로 박았습니다. 요청을 실제로 다뤘는가. 깨진 조각이 없는가. 지시가 실행 가능한가.
말로만 두면 애매해서 예시까지 붙여뒀어요. "8단계로 짜달라"고 요청했으면 결과물도 정확히 8단계여야 하고(요청 충실), 채워지다 만 빈칸이나 중간에 끊긴 코드가 없어야 하고(깨진 조각 없음), 존재하지 않는 도구를 설치하라고 시키면 안 된다(실행 가능), 이런 식으로요.
별거 아닌 것 같았는데, 이 세 줄이 이후 모든 판단의 자 역할을 했어요. 뒤에서 뭐가 애매해질 때마다 여기로 돌아왔거든요.
2. 기록 40건을 뽑았는데, 26건이 가짜였어요
데이터베이스에서 최근 생성 기록 40건을 내렸어요. 그런데 뭔가 이상해서 물었죠. 이거 내가 평가하려는 그 경로에서 나온 기록 맞아? 확인해 보니 40건 중 26건은 발급 과정에서 생긴 복제본이었어요. 모델이 새로 만든 게 아니라, 이미 만든 걸 사람별로 복사한 행인 거예요.
이걸 그대로 뒀으면 뒤의 모든 숫자가 엉켰을 거예요. 진짜 생성분 32건 전부로 다시 뽑았습니다. 돌아보면 이 확인이 이후 작업 전체의 토대가 됐어요.
3. 서른두 건을 전부 읽었어요 — 대신 읽는 방식을 바꿔서
교안의 원칙은 "사람이 직접 읽어라"예요. 맞는 말인데 32건, 한 건에 수십 쪽짜리를 혼자 다 읽기엔 무리라서 절충했어요. 다른 AI(코덱스)에게 조건을 걸고 1차 메모를 시켰습니다. 관찰만 할 것. 왜 그런지 추측하지 말 것. 유형 이름을 붙이지 말 것.
조건을 이렇게 건 이유가 있어요. AI에게 "왜 실패했어?"라고 물 으면 그럴듯한 소설을 지어내거든요. 그래서 "요청은 8단계인데 결과물은 6단계"처럼 확인 가능한 사실만 적게 했고, 올라온 메모는 전부 제가 읽고 승인했어요. 묶어 보니 실패 유형이 12종 나왔습니다.
4. "80% 일치"라길래 좋아했는데, 착시였어요
다음은 채점 기준이 사람마다 같게 읽히는지 확인하는 차례였어요. 같은 10건을 두 AI가 서로 모르게 각자 채점하게 했더니 80%가 일치했습니다. 높아 보이죠. 그런데 함정이 있었어요. 둘 다 후하게 합격을 주는 성향이라, 내용을 안 봐도 우연히 겹칠 확률이 66%나 됐던 거예요.
우연 몫을 빼고 보는 지표(카파)로 계산하면 0.41 — 기준이 아직 안 맞았다는 뜻이에요. 판정이 갈린 두 건은 제가 갈랐고, 그 판단이 "산출물 위치 지시를 어겨도 실패로 본다" 같은 규칙 문장으로 남았습니다. 이 몇 분이 이번 코칭에서 제일 값진 노동이었다고 생각해요.
5. 코드 검사가 눈보다 잘 찾았어요
규칙으로 잴 수 있는 건 전부 코드로 뺐어요. 이런 검사들이에요.
- 채워지다 만 빈칸이 본문에 남아 있는가
- 요청한 단계 수와 실제 단계 수가 같은가 (8개를 시켰는데 6개면 실패)
- "한 폴더에 담아라"라고 명시했는데 다른 폴더에 두지 않았는가
- 설명문이 마침표로 끝나는가 — 안 끝나면 중간에 끊긴 것
- 코드 블록의 괄호가 전부 닫혀 있는가 — 안 닫혔으면 끊긴 것
이 여섯 개를 32건에 돌 렸더니, 사람과 AI가 눈으로 읽으며 놓친 위반이 다섯 건 더 나왔습니다. 특히 결과물이 중간에서 끊기는 결함은 눈으로 6건인 줄 알았는데 실제로는 9건, 전체의 28%였어요.
고백하자면 처음 만든 검사 규칙은 하나도 못 잡았어요. 머리로 상상해서 만든 규칙이었거든요. 정상 산출물 32건을 늘어놓고 들여다보니 그제야 규칙이 보였습니다. 멀쩡한 설명문은 전부 마침표로 끝나고, 멀쩡한 코드는 괄호가 닫혀 있어요. 이 두 줄짜리 규칙이 끊긴 9건을 전부 잡았고, 멀쩡한 걸 끊겼다고 잘못 짚은 경우는 없었습니다.
6. AI 채점기는 만점이 두 시간을 못 갔어요
코드로 못 재는 판단 — "요청을 충실히 따랐는가" — 만 AI 채점기에 맡겼어요. 정답을 가린 채 시험을 보게 했더니 6문제 전부 정답. 여기서 끝냈으면 "검증된 채점기"라고 믿고 넘어갔을 거예요.
그런데 두 시간 뒤 새 문제 8건으로 다시 시험을 치르게 하자 62.5%로 떨어졌습니다. 아까 맞힌 문제의 판정을 뒤집기까지 했어요. 문제 수가 적을 때의 만점은 실력이 아니라, 아직 틀릴 기회가 없었다는 뜻이었던 거예요.
덤으로 하나 더 배웠어요. 채점 기준 문서에 정답 목록을 같이 적어뒀는데, 점검 단계에서 그게 걸렸습니다. 채점기가 그 문서를 읽는 순간 시험지 유출이 되는 구조였던 거예요. 정답지는 채점기가 읽을 수 있는 파일에서 물리적으로 떼어놔야 하더라고요.
7. 마지막엔 일부러 하나를 깨뜨려 봤어요
사람 정답이 붙은 문제집(골든셋) 8건을 굳히고, 검사·채점기·문제집을 한 번에 돌리는 실행 명령 하나로 묶었어요. 그리고 확인 사살로, 멀쩡한 기록 하나를 일부러 살짝 깨뜨려 넣어봤습니다. 검사가 정확히 그 한 건을 짚어냈어요. 앞으로 생성 로직을 고치다가 예전에 잡은 결함이 되살아나면, 배포 전에 이 장치가 먼저 알게 됩니다.
돌아보면
남은 건 평가 폴더 하나와 재실행 명령어 하나예요. 제가 실제로 한 일을 세어 보면 판단 몇 번이 전부입니다. 어디를 잴지, 어떤 기록이 진짜인지, 갈린 판정을 어느 쪽으로 볼지. 나머지는 전부 AI가 했어요. 그런데 그 몇 번의 판단이 규칙과 정답지로 저장됐고, 다음부터는 제가 자리에 없어도 같은 기준으로 돌아갑니다.
다음 숙제는 이 실행 명령을 배포 과정(CI/CD — 코드를 고쳐 내보낼 때마다 자동으로 도는 검사 라인)에 붙이는 거예요. 지금은 제가 명령을 돌려야 하지만, 배포할 때마다 문제집이 자동으로 풀리게 하면 옛 결함이 되살아나는 걸 사람이 지켜보지 않아도 됩니다. 해보니 평가도 결국 인프라더라고요. 한 번 만들고 끝나는 게 아니라, 기록이 쌓이고 정답지가 늘고 채점기가 교정되는 순환을 받쳐줄 기반이 있어야 굴러가요.
제일 크게 달라진 건 말의 단위였어요. "요즘 생성이 좀 이상한 것 같아"가 "끊김 28%, 채점기는 아직 못 믿음"으로 바뀌면, 회의는 짧아지고 다음 할 일은 분명해집니다. 감을 숫자로 바꾸는 데 필요했던 건 대단한 인프라가 아니라, 순서를 잡아주는 코칭이었어요.
