지난 글에서는 Career Radar가 어떤 앱이 되어야 할지 다시 생각했다. 공고를 판정하는 도구에서 개인의 맥락을 기억하는 비서로 나아갈 수도 있겠지만, 그전에 판단을 어떻게 확인할지부터 정리하기로 했다.
이번에는 화면에 새 기능을 붙이지 않았다. 대신 같은 사례를 다시 실행하고, 이전 결과와 비교하는 평가 도구를 만들었다. PR #12에 담은 M4-A 작업이다.
재미있게도 리뷰에서 발견한 문제는 판정 자체보다, 무엇을 같은 평가 사례로 볼 것인가에 있었다.
무엇이 바뀌면 다른 실험이고, 무엇이 바뀌어도 같은 실험으로 비교할 수 있을까. 이 글은 그 기준을 정하게 된 과정이다.
테스트가 통과했다는 것 다음에 남겨야 할 것
지금까지도 합성 이력서와 공고를 넣어 판정 규칙을 확인하는 테스트는 있었다. 필수 조건에 명백히 못 미치는데 현실적인 지원이라고 판정하지 않는지, 경력에 없는 내용을 근거로 쓰지 않는지 같은 것들이다.
그런데 결과를 계속 돌아보려면 “이번에도 통과했다”만으로는 부족했다. 어떤 입력과 기대값으로 실행했는지, 이전에 통과하던 사례가 실패하게 됐는지까지 남아야 했다.
그래서 기존 16개 사례를 유지하면서 변형 사례를 더해 28개로 늘리고, 사례별 결과를 저장하고 비교하도록 했다. 사람이 검토했는지도 별도로 표시할 수 있게 했다.
여기서 말하는 평가는 실제 모델을 호출하는 실험이 아니다. 합성 입력과 미리 만든 판정 초안을 넣고, 코드로 작성한 정책이 어떻게 처리하는지 확인하는 것이다. 모델이 이력서를 잘 이해하는지는 아직 다른 검증이 필요하다.
검토 완료 표시도 입력 변경으로 잡혔다
처음 구현은 평가 사례 전체를 하나의 해시로 묶었다. 내용이 달라졌다면 이전 결과와 그대로 비교하면 안 된다는 생각이었다.
문제는 그 안에 이력서·공고·기대 판정뿐 아니라, 사례를 설명하는 문장과 사람의 검토 상태까지 함께 들어 있었다는 점이다.
사람이 사례를 읽고 검토 상태를 pending에서 accepted로 바꾸면 어떻게 될까? 판정에 넣는 입력도, 기대하는 결과도 그대로인데 다른 사례처럼 취급됐다. 설명을 조금 고쳐도 마찬가지였다.
리뷰에서는 이 상황을 28개 사례에 적용해 확인했다. 검토를 마쳤다고 표시했더니 이전 실행과 비교할 수 있는 사례가 0개가 됐다.
비교하지 못했다고 “회귀 없음”으로 통과시킨 것은 아니다. 비교할 수 없다며 종료됐다. 그래도 평가 자료를 정리하는 정상적인 작업 때문에 정작 계속 확인하고 싶었던 비교가 끊기는 것은 문제였다.
평가 자료를 검토할수록 이전 기록을 쓰기 어려워지는 구조였다.
판정의 조건과, 사례에 붙인 설명을 나눴다
수정 커밋에서는 해시를 두 개로 나눴다.
contractHash: 실제 입력과 기대 판정, 반드시 잡아야 할 제한 조건처럼 평가의 조건이 되는 값.annotationHash: 사례의 설명, 검토 상태, 출처처럼 사례를 관리하기 위해 붙이는 정보.
입력이나 기대값이 바뀌면 여전히 별도로 다룬다. 하지만 설명이나 검토 상태만 바뀌었다면 이전 결과와 비교하되, 주석이 달라졌다는 사실도 함께 남긴다.
이 차이가 실제로 작동하는지 확인하려고, 재검토에서는 28개 사례 모두에 검토 완료 표시를 하고 설명도 바꿨다. 여기에 판정 함수가 무조건 REALISTIC을 반환하도록 일부러 망가뜨렸다.
이번에는 28개가 모두 비교 대상에 남았고, 28개의 주석 변경도 따로 표시됐다. 의도적으로 넣은 잘못된 동작은 19개 사례에서 회귀로 잡혔다. 실제 앱에서 버그 19개를 발견했다는 뜻이 아니라, 비교 기능이 오류를 놓치지 않는지 확인하기 위한 합성 실험이다.
단순히 해시 하나를 둘로 나눈 수정이지만, 무엇이 바뀌었을 때 비교를 이어가도 되는지 기준이 생겼다.
28개 통과와, 좋은 추천은 아직 다른 말이다
수정된 코드에서 테스트 141개와 정책 평가 28개가 통과했다. 타입 검사와 린트, 빌드도 다시 확인했다.
그렇다고 이 숫자를 추천 정확도로 읽으면 안 된다. 현재 28개 사례의 사람 검토 상태는 모두 대기 중이다. 앞의 검토 완료 표시는 비교 기능을 확인하는 실험에서만 바꾼 것이다.
지금 확인한 것은 작성해 둔 정책 계약을 코드가 지키는지다. 그 기대 판정이 실제 구직 상황에서도 적절한지, 모델이 같은 근거를 안정적으로 찾아내는지는 아직 확인하지 않았다.
첫 번째 코드 리뷰 글에서도 판정의 근거를 따져봤는데, 이번에는 그 판정을 확인하는 도구까지 돌아보게 됐다.
기록을 많이 남기는 것보다 먼저 정할 것
처음에는 평가 사례를 늘리고 결과를 저장하면 다음 개발의 기반이 될 거라고 생각했다. 해보니 기록의 양보다 먼저 정해야 할 것이 있었다.
무엇이 바뀌면 다른 실험이고, 무엇이 바뀌어도 같은 실험으로 비교할 수 있을까?
나중에 프롬프트나 모델을 바꿀 때도 이런 구분이 필요할 것 같다. 다만 이번에 만든 것은 정책을 비교하는 기반까지다. 실제 모델을 바꿔 가며 성능을 비교하는 도구가 완성된 것은 아니다.
화면에 보이는 기능은 늘지 않았지만, 다음 수정을 했을 때 무엇이 달라졌는지 물어볼 방법은 조금 더 나아졌다.
아직 작은 토이 프로젝트다. 그래도 “일단 돌아간다” 다음에는 이런 질문이 생긴다는 것을, 직접 만들면서 배우고 있다.