비용을 줄이기 위해 여러 무료 AI 모델을 fallback으로 연결해본 적이 있다.
구조는 간단하다. 첫 모델이 작업을 완료하지 못하면 두 번째 모델로 넘기고, 다시 실패하면 세 번째 모델이 이어받는다.
처음에는 “한 모델이 못하면 다른 모델이 해주니까 성공률이 올라가겠지”라고 생각했다. 실제로 최종 성공률은 높아질 수 있었다. 하지만 운영하면서 더 중요한 문제가 보였다.
아주 작은 수정에서 guard의 필요성이 먼저 드러났다
테스트 파일의 괄호 하나를 고치는 작업을 자동화에 맡긴 적이 있다. 첫 worker는 작업을 끝내지 못했고, 다음 worker는 Windows Runner인데 Linux 명령을 사용한 데다 요청하지 않은 새 테스트 파일까지 만들었다.
만약 목표가 “테스트만 통과하면 성공”이었다면 이 변경이 그대로 남을 수도 있었다. 하지만 해당 task에서 허용한 것은 기존 파일의 문법 오류 수정뿐이었다.
그래서 write-path guard가 새 파일 생성을 범위 밖 변경으로 판단해 원복했고, 다음 fallback은 깨끗한 시작 상태에서 다시 작업했다. 마지막 worker가 원래 문제만 수정하면서 작업이 끝났다.
이 사례의 전체 흐름은 괄호 하나 고치는데 AI 셋이 출근한 이유에, 변경 경로 제한은 AI Agent가 시키지 않은 파일까지 만들 때 막는 방법에 따로 남겼다.
모델마다 실패 방식이 달랐다
어떤 모델은 아예 worker 단계에서 실패했다.
다른 모델은 명령을 실행하지만 운영체제를 잘못 가정했다.
또 다른 모델은 요청하지 않은 테스트 파일을 추가하면서 목표를 우회하려 했다.
모든 모델이 같은 방식으로 실패한다면 예외 처리가 쉽다. 하지만 서로 다른 모델을 연결할수록 실패 패턴도 다양해진다.
그래서 모델별 프롬프트를 계속 고치는 것만으로는 부족했다.
fallback 사이에 공통 규칙이 필요했다
어떤 모델이 작업하더라도 결과는 같은 기준으로 검사해야 했다.
내가 공통으로 확인한 것은 다음과 같았다.
- 지정된 작업 범위를 벗어나지 않았는가
- 허용되지 않은 파일을 만들지 않았는가
- 테스트와 빌드가 통과하는가
- task 시작 전 상태와 비교해 예상한 변경만 있는가
- 실패했다면 다음 모델에게 깨끗한 상태를 넘기는가
이 검증 계층이 있으면 모델별 특성이 달라도 시스템 전체의 기준은 유지할 수 있다.
이전 모델의 실수를 다음 모델에게 넘기지 않는다
fallback 구현에서 특히 중요한 부분은 상태였다.
첫 모델이 파일을 반쯤 수정한 상태에서 실패하고, 그 상태를 그대로 두 번째 모델에게 넘기면 두 번째 모델은 원래 task가 아니라 첫 번째 모델이 만든 중간 상태를 해결하게 된다.
그래서 실패한 실행의 변경이 명백히 잘못된 경우에는 기준점으로 원복한 뒤 다음 모델을 시작하는 편이 훨씬 예측 가능했다.
모델 선택은 실행 전략의 한 부분일 뿐이다
비용, 속도, 코딩 성능을 비교해 어떤 모델을 먼저 호출할지 정할 수 있다.
하지만 실제 자동화 품질은 모델 순서만으로 결정되지 않았다.
좋은 모델 하나에 모든 권한을 주는 것보다, 평범한 모델 여러 개를 쓰더라도 결과 검증과 복구 규칙이 명확한 쪽이 더 안전할 수 있었다.
fallback의 목적은 무한 재시도가 아니다
실패할 때마다 계속 다른 모델을 부르면 언젠가는 성공할 것 같지만, 실제로는 같은 잘못된 task 정의를 여러 모델이 반복할 수도 있다.
그래서 재시도 횟수를 제한하고, 일정 횟수 이상 실패하면 사람에게 원인과 변경 내역을 보고하도록 했다. Reviewer가 먼저 PASS/BLOCKED 같은 판정을 내리고, 그 판정과 증거를 PM이 정리하는 verdict-first 흐름도 이 이유에서 추가했다.
fallback은 사람의 판단을 없애는 기능이 아니라 예측 가능한 실패를 자동으로 흡수하는 장치에 가깝다.
무료 모델을 여러 개 연결하면서 가장 크게 배운 점은 이것이었다.
자동화의 신뢰도는 가장 똑똑한 모델보다, 가장 나쁜 실행을 어디까지 허용하느냐에 더 크게 좌우된다.