여러 무료 AI 모델만으로 개발 작업을 계속 돌릴 수 있는지 실험하면서 PM, Worker, QA, Reviewer 역할을 나눠 작은 오케스트레이터를 만들었다.
처음에는 역할만 잘 나누면 될 거라고 생각했다. PM이 task를 정리하고 Worker가 코드를 고치고 QA가 확인한 뒤 Reviewer가 검토하면 자연스럽게 다음 작업으로 이어질 것 같았다.
실제로 막힌 부분은 모델 성능보다 판정을 어떻게 읽고 다음 상태로 넘길지였다.
좋은 설명보다 먼저 필요한 것은 한 줄 판정이었다
Reviewer가 긴 리뷰를 작성하면 사람에게는 유용하다. 하지만 자동화는 그 글에서 성공인지 실패인지 다시 해석해야 한다.
표현이 조금만 달라져도 PM이 완료 작업을 다시 큐에 넣거나, 실패한 작업을 성공으로 오해할 수 있었다.
그래서 Reviewer 출력의 첫 부분을 단순하게 고정했다.
PASSFAIL- 필요한 경우 짧은 이유와 수정 요구
상세 설명은 그 뒤에 붙인다. 자동화는 첫 판정만 읽어 상태를 결정하고, 사람은 아래의 근거를 읽는다.
재시도에도 상한을 뒀다
무료 모델은 일시적인 제한이나 응답 실패가 생길 수 있다. 그래서 첫 실패만으로 작업 전체를 막지 않고 다른 모델로 fallback하도록 했다.
하지만 무한 재시도는 하지 않았다. 같은 task 정의가 잘못돼 있으면 모델을 계속 바꿔도 같은 문제를 반복하기 때문이다.
재시도 횟수를 제한하고, 범위를 넘으면 작업을 BLOCKED로 남겨 원인과 마지막 상태를 보고하도록 했다.
역할을 나누니 상태 파일이 더 중요해졌다
PM과 Worker가 서로 다른 모델이면 대화 메모리를 공유하지 않는다. 그래서 현재 task, 마지막 판정, checkpoint, 다음 실행 조건을 저장소의 상태로 남겼다.
모델이 바뀌어도 시스템이 현재 위치를 알 수 있어야 한다.
이 구조에서 중요한 것은 “무료 모델이 유료 모델만큼 똑똑한가”가 아니었다.
- Worker가 범위를 지키는가
- QA가 실제 결과를 확인하는가
- Reviewer가 명확한 판정을 내리는가
- 실패 상태에서 안전하게 다시 시작할 수 있는가
- 유료 모델 호출 없이도 전체 흐름이 유지되는가
여러 AI를 연결할수록 자연어 대화보다 작고 명확한 프로토콜이 중요해졌다.
결국 오케스트레이터의 신뢰도는 가장 똑똑한 모델이 아니라, 각 단계가 다음 단계에 얼마나 분명한 상태를 넘기느냐에서 결정됐다.