평소에 묻던 질문
데이터 수집 도구를 운영하면서 Codex에 자주 묻는 말이 있다. 각 나라의 복권 결과가 잘 수집됐는지, 문제가 있으면 어디부터 확인해야 하는지다. 답을 빨리 받는 것보다 제대로 확인한 답을 받는 것이 중요했다.
기록을 넣으면 원인 후보와 다음 확인 순서를 설명하는 읽기 전용 진단 도구를 만들었다. 원천에서 아직 결과를 발표하지 않은 경우, 수집한 자료의 형식이 맞지 않는 경우, 내부에는 새 값이 있지만 앱에는 이전 값이 보이는 경우부터 다뤘다.
상태가 분명한 부분은 코드가 판정하고, 모델은 근거를 읽어 설명하도록 했다. 모델의 추측으로 재수집이나 전송을 실행하지는 않았다. 사람이 결과를 보고 다음 조사를 정하는 도구였다.
인용문이 있다고 통과시킬 수는 없었다
실제 모델을 연결하자 출력 형식부터 맞추기 어려웠다. 근거 ID를 넣어야 할 자리에 인용문이 들어가거나, 필요한 확인 항목이 빠졌다. 자료에 들어 있는 실행 지시를 무시했다는 정상적인 설명을 검증 코드가 잘못 막는 경우도 있었다.
모델이 잘못 쓴 부분과 검증 코드가 잘못 읽은 부분을 나눠 고쳤다. 잘못된 응답을 조용히 보정해서 성공으로 만들지는 않았다. 어떤 ID의 어느 문장을 사용했는지 맞지 않으면 보류했다.
JSON Schema도 적용했다. 응답에 필요한 필드와 허용값을 정해 모델에 전달하는 방식이다. OpenRouter에서는 지원하는 모델·제공 경로에 이 형식을 사용할 수 있지만, 같은 모델도 제공 경로에 따라 지원과 강제 수준이 다를 수 있다. 구조화 출력 안내
그래서 받은 응답은 코드에서 다시 확인했다. 허용된 근거인지, 인용문이 원문과 같은지, 필수 항목이 모두 있는지를 검사했다. 자료가 오래됐거나 근거가 없을 때는 설명을 만들어 이어가지 않았다.
형식은 맞았고, 설명은 더 봐야 했다
마지막 시험에서는 합성 사례 세 종류를 각각 두 번씩 실행했다. 실제 모델 응답 6개가 출력·인용 검사를 모두 통과했고, 평균 응답 시간은 9.677초였다.
여기까지는 분명한 결과였다. 다만 상태 분류는 코드가 먼저 정해 모델에 제공하고 있었다. 이 결과를 모델의 원인 판단 정확도 100%라고 쓸 수는 없었다.
원문을 제대로 인용해도 그 문장이 옆에 적힌 원인 후보를 충분히 뒷받침하는지는 따로 봐야 했다. 예를 들어 전달과 공개 결과가 다르다는 근거로 캐시 지연을 의심할 수는 있다. 하지만 차이가 있다는 사실만으로 캐시가 원인이라고 확정할 수는 없다.
설명이 기존 상태를 다시 말하는 경우도 많았다. 필수 근거를 빠짐없이 보여주는 것과 사람이 다음에 무엇을 해야 할지 이해하게 만드는 것은 다른 일이었다. 실제 조회 순서는 코드가 정리한 확인 항목을 먼저 보도록 남겼다.
응답 시간 앞에 빠진 시간이 있었다
시험을 마친 뒤 이 방법이 정말 효율적인지 다시 물었다. 모델이 응답하는 데 걸린 시간은 있었지만, 자료를 찾아 준비하고 답변을 검토하는 전체 시간은 재지 않았다.
현재 흐름은 사람이 기록을 모아 파일로 준비하고, 코드가 상태를 분류한 뒤, 모델이 설명하고, 사람이 다시 읽는 방식이다. 평소의 “오늘 잘 수집됐나요?”라는 질문을 그대로 해결하려면 아직 앞부분이 비어 있었다. 진단 도구가 필요한 운영 기록을 스스로 모두 가져오는 상태는 아니었다.
이미 수집 대상과 최신 실행, 저장된 결과, 전달 상태를 조회하는 API와 확인 스크립트가 있었다. 모델을 더 시험하기 전에 이 조회를 함께 사용할 수 있는지 보는 편이 필요했다. API가 있다는 것과 그 자료를 읽을 권한이 준비됐다는 것도 각각 확인해야 한다.
같은 값이어도 최신은 아닐 수 있다
조회만 모으면 끝나는 것도 아니었다. 내부 저장값과 앱에 공개된 값이 같아도 두 곳이 함께 이전 회차를 보여주고 있을 수 있다. 공식 원천의 최신 결과까지 확인해야 “최신 회차가 수집됐다”고 말할 수 있다.
추첨 일정상 아직 발표할 시간이 아닌 것과, 원천을 실제로 열어보고 미게시 상태를 확인한 것도 구분해야 했다. 자료를 못 봤다면 그 항목은 미확인으로 남기는 편이 낫다.
요청 접수부터 공개 결과까지 나눠 확인했던 과정은 202를 받았는데 아무것도 수집되지 않았다에 적었다. 이번에는 그 확인 과정에 설명 도구를 붙이면서, 설명 전에 무엇을 가져와야 하는지 다시 보게 됐다.
다음 비교에서는 처음부터 끝까지
현재 구현은 로컬 진단과 합성 자료의 실제 모델 시험까지다. 운영에 연결해 반복 사용하거나 확인 시간을 줄였다는 결과는 아직 없다.
이 도구의 효율을 비교하려면 같은 수집 상태를 기존 조회 도구, Codex 대화, 진단 도구로 각각 확인해야 한다. 자료를 모으는 시간부터 결론을 검토하는 시간까지 함께 재야 어느 부분에서 도움이 되는지 알 수 있겠다. 모르는 항목을 감추지 않았는지, 추가로 물어봐야 할 일이 늘지는 않았는지도 볼 필요가 있다.
이번에 모델 응답을 검사할 방법은 마련했다. 아직 답하지 못한 것은 그 응답이 내 확인 업무를 얼마나 덜어주는가다. 평소에 묻던 짧은 질문 하나에 어떤 자료로 어디까지 확인해 답할 것인지, 그 앞부분이 남아 있다.