AI 자동화 프로젝트 4: 검토는 추가 호출 한 번의 값을 할까
TL;DR
- 같은 요청과 초안을 바로 재작성과 검토 후 수정에 전달하는 비교 기능을 만들었다. 다섯 사례를 세 번씩, 실제 로컬 모델로 실행했다.
- 기대 답변과 일치한 결과는 14/15 대 11/15였다. 반대로 정상 초안을 유지한 결과는 5/6 대 6/6이었다. 이 실험에서 검토의 일관된 이득은 확인하지 못했다.
- 비교 화면에서 답변·검토 의견·모델 호출 수·시간을 함께 확인한다. 단계가 늘어났을 때 얻는 효과를 실행 기록으로 따져볼 수 있게 됐다.
들어가며
3편에서는 작성 → 검토 → 수정 흐름을 연결했다. 잘못된 초안이 고쳐지기도 했지만, 검토자는 모든 사례에 “수정 불필요”라고 답했다. 수정 역할이 원래 요청을 다시 읽고 답을 생성한 것만으로도 같은 결과가 나올 수 있었다.
그래서 마지막에 예고했던 비교를 진행했다. 같은 초안을 검토 없이 바로 재작성해도 잘 고쳐진다면, 검토 단계의 추가 호출을 정당화할 근거가 필요하다. 이번에는 오류를 고치는지와 함께, 이미 맞는 답변을 유지하는지도 살펴봤다.
초안을 고정하고 두 경로로 나눴다
두 경로가 서로 다른 초안을 생성하면 출발점부터 달라진다. 비교 기능에서는 초안을 직접 입력하도록 하고, 동일한 원래 요청과 초안을 두 경로에 전달했다.
| 경로 | 처리 순서 | 모델 호출 |
|---|---|---|
| 바로 재작성 | 제공 초안 → 수정 | 1회 |
| 검토 후 수정 | 제공 초안 → 검토 → 수정 | 2회 |
최종 수정 단계의 시스템 지시문도 같게 했다. 검토 경로에는 검토 의견이 추가된다. 두 경로는 각각의 Coral 스레드를 사용해 대화가 섞이지 않게 했고, 채점용 기대 답변 필드는 모델 입력에 추가하지 않았다.
실행 환경은 로컬 Docker의 Kafka·PostgreSQL·Coral·Ollama다. 같은 Worker에서 qwen2.5:1.5b를 CPU로 실행했고, 출력 토큰 상한은 256이었다. 검토자도 같은 모델을 사용한다. Jev는 API 키가 없어 이번에도 OFF였다.
사례는 오류 초안 세 개와 정상 초안 두 개다. 상품 문의를 ‘배송’으로 분류한 초안, 부정적인 리뷰를 ‘긍정’으로 분류한 초안, 오후를 오전으로 바꾼 문장을 넣었다. 정상 초안은 요청한 회의 문장과 올바른 환불 분류였다. 각각 세 번 반복해 15쌍을 비교했다. 서로 다른 문제 15개를 풀었다는 뜻은 아니다.
오류 수정과 정상 답변 유지에서 결과가 갈렸다
채점은 앞뒤 공백을 제거한 뒤 기대 답변과 정확히 같은지 확인한다. 이번 요청은 한 단어 분류와 문장 그대로 출력이어서 형식 준수도 결과에 포함했다. 긴 요약이나 자유로운 설명을 평가하려면 다른 기준이 필요하다.
| 관찰 | 바로 재작성 | 검토 후 수정 |
|---|---|---|
| 기대 답변과 일치 | 14/15 | 11/15 |
| 오류 초안을 일치 답변으로 변경 | 9/9 | 5/9 |
| 정상 초안의 일치 유지 | 5/6 | 6/6 |
| 모델 호출 | 15회 | 30회 |
두 경로 모두 전달까지 완료됐고 재시도는 없었다. 그런데 검토 의견은 15개 모두 “수정 불필요”였다.
부정적인 리뷰를 분류하는 사례가 차이를 잘 보여준다. “제품이 고장 나서 사용할 수 없습니다”에 대해 ‘긍정’이라는 잘못된 초안을 제공했다. 바로 재작성은 세 번 모두 ‘부정’으로 고쳤다. 검토 후 수정은 두 번 ‘긍정’을 유지했고, 한 번만 ‘부정’으로 바꿨다.
검토 경로에서 불일치한 나머지 두 결과는 형식 문제였다. “회의는 오후 3시에 시작합니다.”만 출력해야 하는데, 앞에 “다음 문장을 그대로 출력하세요:”나 “다시 출력:”을 덧붙였다. 시간 정보 자체는 맞았으므로, 네 번의 불일치를 모두 사실 오류라고 해석하면 안 된다.
바로 재작성도 정상 초안을 한 번 망가뜨렸다. 이미 맞는 회의 문장에 불필요한 설명과 다른 언어의 표현을 덧붙였다. 검토 경로는 정상 초안을 여섯 번 모두 유지했다. 전체 일치 수는 바로 재작성이 높았지만, 정상 답변 보존에서는 반대 결과가 나왔다.
이 작은 고정 사례만으로 어느 방식이 항상 낫다고 말할 수는 없다. 다만 현재 모델과 지시문에서 검토를 추가하면 품질이 안정적으로 좋아진다는 근거는 얻지 못했다. 잘못된 초안을 승인한 의견이 최종 답변에 어떤 영향을 줬는지도 별도 실험이 필요하다.
호출 수와 시간을 함께 남겼다
제공 초안으로 시작했기 때문에 초안 생성 비용은 없었다. 바로 재작성은 총 15회, 검토 후 수정은 총 30회 모델을 호출했다. 추가 검토에 필요한 호출 수는 분명하게 드러났지만, 전력이나 금액으로 환산한 비용은 측정하지 않았다.
시간은 더 조심해서 봐야 했다. 첫 번째 바로 재작성 추론 하나에 약 63.5초가 걸렸다. 모델 준비 상태와 실행 순서를 통제하지 않았고, 두 경로가 함께 접수되므로 전체 시간에는 큐 대기와 전달도 섞인다. 이번 누적 시간으로 속도 우열을 정하지 않았다.
같은 사례를 다시 실행할 수 있도록 비교 스크립트를 남겼다. Ollama와 앱이 실행된 상태에서 아래 명령을 사용한다. 모델 출력이 매번 같다는 보장은 없으므로 실행별 결과를 함께 저장한다.
.\scripts\compare.ps1 -Repetitions 3
콘솔에서 두 답변을 바로 비교하기
웹의 새 실행 → 검토 효과 비교에서 요청과 공통 초안, 선택 사항인 기대 답변을 입력한다. 비교 화면에는 두 최종 답변과 일치 여부, 호출 수, 추론·전체 시간이 나란히 표시된다.
위 이미지는 앞서 설명한 감정 분류 사례의 실제 로컬 실행 화면이다. 두 경로 모두 완료지만, 기대 답변 일치 여부는 다르다. 검토 의견을 펼치고 단계 상세로 이동하면 당시 입력과 결과를 확인할 수 있다. 기대 답변을 입력하지 않았거나 실행이 끝나지 않았다면 정답·오답으로 채점하지 않는다.
두 경로는 같은 트랜잭션에서 접수하되 이후 실행 기록은 각각 보존한다. 한쪽만 실패하면 그 경로의 실패 단계부터 재시도한다. 완료된 다른 경로를 다시 실행하지 않아도 된다. Kafka의 작업 전달, DB의 결과 보존, Coral의 문맥 전달 위에 이 비교를 얹었다.
자동 테스트는 59개 통과, 외부 서비스 설정이 필요한 2개 제외다. 실제 모델로 15쌍을 실행했고 데스크톱과 모바일 화면도 확인했다. 구현 커밋과 빌드·연동·복구 검사 결과를 함께 남긴다.
다음에는 검토자의 판정부터 확인하려 한다
이번에는 같은 입력을 두 경로에 넣고, 결과가 달라진 지점을 기록할 수 있게 됐다. 잘못된 초안을 고친 수와 정상 초안을 보존한 수를 함께 보니, 최종 답변 몇 개만 살펴볼 때 놓쳤던 차이가 드러났다.
다음에는 검토자가 틀린 답을 실제로 찾아내는지 확인하려 한다. 사례를 늘리고 다른 검토 모델이나 지시문을 비교하면서, 최종 수정 결과와 검토 판정을 따로 기록할 계획이다. 시간 비교를 하려면 모델을 준비한 뒤 실행 순서도 바꿔 가며 측정해야 한다.
Jev 실제 연동과 평가 결과에 따른 자동 재생성·토픽 선택은 아직 남아 있다. 먼저 판정이 얼마나 믿을 만한지 확인한 뒤, 그 판정이 다음 작업을 결정하도록 연결하려 한다.
작성 기준: 2026년 10월 1일. 실제 로컬 실행 기록과 구현·검증 결과를 기준으로 작성했다.
Comments