GC AI는 TypeSafe의 새 분류 모델 Jev를 시험하기 위해 내부 해커톤을 열어 12시간 동안 38개 프로젝트와 실험을 진행했다. 이 경험에서 Jev는 생성형 모델을 대체하기보다, 좁고 객관적인 질문에 빠르게 답해 결정적 코드나 더 강력한 모델로 작업을 넘기는 데 적합하다는 설계 원칙을 얻었다.

Jev는 텍스트를 생성하지 않는다. 대신 문맥과 함께 예·아니요, 선택지, 범위가 정해진 점수 같은 질문을 전달하면 0.1~0.5초 안에 구조화된 평가를 반환한다. GC AI는 표준 모델 호출보다 비용이 10~100분의 1 수준이라고 설명했다.

해커톤 프로젝트 가운데 가장 많은 표를 받은 것은 Slack에서 팀원들과 상호작용하는 나무늘보 ‘Jeventus’였다. 총 38개 프로젝트 중 23개가 세 개 부문에 제출됐고, 팀은 이를 통해 16개의 재사용 가능한 패턴을 정리했다.

잘하는 일과 실패하는 일

한 엔지니어는 Jev의 한계를 확인하는 스트레스 테스트를 진행했다. 3만 토큰의 상용구 속에서 특정 문장을 찾아냈고, 253개 선택지가 있는 조건에서 줄거리로 영화 제목을 맞히는 과제는 50번 중 46번 성공했다. 반면 특정 날짜의 요일을 계산하는 과제는 5번 중 4번 실패했다. 날짜·수학·시간 추론이나 일반 지식 기반처럼 다루는 일에는 신뢰하기 어렵다는 결과다.

한 문서에 대한 질문 20개를 한꺼번에 보내면 거의 추가 지연 없이 동시에 평가할 수 있었다. 그러나 비슷한 항목을 프롬프트 안의 배열에 넣어 평가하게 하자 정확도가 96%에서 72%로 떨어졌다. 인접한 행의 답을 서로 섞기 시작했기 때문이다. GC AI는 표 형식의 데이터를 한 프롬프트에 포장하기보다 항목별 API 호출을 병렬로 보내는 방식을 권했다.

약관 검사와 인용 검증

ToS Trap Spotter는 웹을 탐색하는 동안 소비자 이용약관을 검사하도록 만든 Chrome 확장 프로그램이다. 문서를 문단별로 나눈 뒤 각 문단에 자동 갱신, 강제 중재, 집단소송 포기, 일방적 변경 권한, 광범위한 책임 면책 등 8가지 검사를 병렬로 적용한다. Spotify의 110개 문단 이용약관을 1.9초 만에 평가했다. 프롬프트 조정에 쓰지 않은 합성 조항 평가 세트에서는 F1 점수 89%를 기록해 키워드 정규식 기준선의 57%보다 높았다.

초기 테스트에서는 데이터 공유 경고가 모두 오탐이었다. 웹페이지의 쿠키 동의 배너를 DOM 수집기가 가져와 약관 조항으로 평가한 것이 원인이었다. 모달 대화상자를 추출 대상에서 제외하자 문제가 해결됐다. 책임 면책 검사는 질문을 구체화해 오탐을 절반으로 줄였다. 회사의 책임을 제한하는지 묻는 대신 사용자가 겪는 손해·손실·피해에 초점을 맞췄다.

법률 연구용 채팅에서는 응답이 생성되는 동안 인용 문장이 출처의 뒷받침을 받는지 확인하는 검증기를 만들었다. 근거가 약하거나 없으면 생성이 끝나기 전에 해당 문장에 주황색 또는 빨간색 밑줄을 표시한다. 출처가 어떤 행동을 ‘할 수 있다’고 했는데 요약은 ‘해야 한다’고 바꾸는 사례에서는 일반적인 지원 여부 질문이 오류를 놓쳤다. 명시적 근거 여부, 세부 내용의 불일치, 과장 여부를 묻는 세 가지 예·아니요 질문을 추가하자 오류를 잡아냈다.

개발자 도구와 자동화의 경계

온콜 분류 봇 jev-pager는 알림 문구뿐 아니라 코드로 계산한 건수, 시각, 다른 알림 정보 등을 함께 평가한다. 실제 운영 알림 한 주치 136건을 재생했을 때 사람의 개입이 필요한 모든 사고를 찾아냈고, 잘못 호출한 경우는 한 번이었다. 모니터링 문구의 경보성 표현 때문에 사소한 타임아웃까지 과도하게 올리는 문제가 있었지만, 먼저 알림 유형을 분류한 뒤 그 결과를 호출 여부 판단에 넘기자 개선됐다. 관측된 CPU 값을 함께 제공했을 때 호출 정밀도는 0.63에서 0.92로 올랐다.

PR Stamper는 사람이 라벨을 붙이면 위험이 낮고 기계적으로 판단할 수 있는 풀 리퀘스트를 검토·승인한다. 병합은 하지 않는다. 마이그레이션, 인증, 결제 등 민감한 영역의 변경을 차단하는 하드코딩 정책과, 변경 유형·동작이나 공유 계약의 변경 여부·버그의 영향 범위를 살피는 7개의 파일 단위 검사를 결합했다.

반면 ‘이 테스트는 쓸모없는가?’처럼 포괄적이고 주관적인 질문으로 단위 테스트를 정리하려 했을 때 AUC는 0.54로 동전 던지기 수준이었다. 테스트가 모의 호출 횟수만 확인하는지, 애플리케이션 로직을 실행하는지 등 구조에 관한 사실 질문 8개로 나누자 AUC가 0.72로 올랐다. GC AI는 Jev가 구체적인 사실을 확인하는 데는 강하지만, 전체적인 품질 판단을 독자적으로 내리지는 못한다고 설명했다.

Jeventus도 같은 설계 원칙을 보여줬다. Jev는 Slack 메시지를 생성형 대화로 이어가지 않고, 먹이를 주는지·놀아주는지·꾸짖는지와 친절도 점수만 분류했다. 이후 표준 Postgres 쿼리가 배고픔과 기분 상태를 갱신하고, 정해진 코드가 답변을 선택했다. GC AI는 Jev를 텍스트 생성 모델이 아니라 빠르고 유형이 정해진 분기문처럼 쓰는 방식이 성공적인 프로젝트에서 반복됐다고 밝혔다.

적용할 때 살펴볼 점

GC AI가 정리한 원칙은 좁고 객관적인 기준을 질문하고, 나머지는 코드나 생성형 모델에 맡기는 것이다. 날짜 계산·집계·후보 추출처럼 코드가 더 잘하는 작업은 코드가 처리하고, 주관적 판단이나 텍스트 생성은 Jev에 맡기지 않는 편이 낫다. 해커톤 결과는 대부분 소규모의 합성 데이터에서 대개 한 번씩 시험한 수치이므로, 실제 데이터를 사용하는 평가로 다시 확인해야 한다.

해커톤 뒤 GC AI 엔지니어 한 명은 설계 원칙을 내부 개발자 도구 jev-design으로 정리했다. 아래에 포함된 내부 가이드와 인터랙티브 탐색 도구에는 38개 프로젝트와 16개 패턴이 담겼다. 전체 패턴 매트릭스는 새 탭에서 확인할 수 있다.