신모델이 나왔다, 전부 갈아탈까 — 카나리 3일이 대신 답해준 것

새 AI 모델이 나오면 늘 같은 고민이 시작된다. 좋다는 건 알겠는데, 비용도 두 배라는데, 지금 잘 굴러가는 시스템을 전부 갈아엎어도 되나? 이 글은 그 고민을 ‘기기 한 대’에게 3일 동안 대신 시켜 본 기록이다.

지난주에 새 AI 모델이 나왔다. 벤치마크 점수는 눈에 띄게 높았고, 며칠짜리 작업을 혼자 끌고 가는 지구력이 좋아졌다는 평이 따라붙었다. 그리고 가격이 두 배였다.

나는 컴퓨터 다섯 대를 AI 작업자처럼 묶어서 쓰고 있다. 지난 화에 쓴 그 ‘함대’다. 다섯 대가 하루 종일 모델을 호출하니, 모델 단가가 두 배가 되면 체감 비용도 그냥 두 배다. “전부 갈아타자”는 결정은 곧 “고정비를 두 배로 올리자”는 결정이기도 했다. 그래서 망설였다. 좋아 보인다는 이유만으로 함대 전체를 갈아엎기엔, 잘 굴러가던 시스템이 아까웠고 지갑이 무서웠다.

전부냐 전무냐를 거부하기

이럴 때 흔히 두 갈래로 갈린다. “신모델 나왔으니 당장 다 바꿔” 아니면 “비싸니까 그냥 쓰던 거 쓰자”. 둘 다 편한 결정이다. 판단을 한 번만 하면 되니까.

나는 세 번째 길을 골랐다. 다섯 대 중 한 대만 새 모델로 바꾸고, 나머지 넷은 그대로 둔다. 광산에 들어갈 때 카나리아 한 마리를 먼저 들여보내듯, 검증용 기기 한 대가 먼저 신모델로 일을 해 보는 것이다. 잘하면 늘리고, 별로면 그 한 대만 되돌리면 된다. 되돌리는 비용이 거의 0이라는 점이 이 전략의 전부다.

조건도 정했다. 막연히 “써 보니 좋더라”는 감상은 받지 않기로 했다. 실제 업무를 시키고, 새 모델이 아니었으면 놓쳤을 것 같은 순간이 있었는지만 세기로 했다. 3일을 줬다.

첫째 날 — 합치기 전에 한 번 더 읽은 것

첫 사례는 코드 합치기(merge) 검토였다. 팀원 기기가 올린 작업 결과를 본문서에 합치기 전에, 검증용 기기가 변경 내역을 한 줄씩 실제로 다시 읽었다. 형식적인 통과 의례가 아니라 진짜로 읽었다는 게 곧 드러났다. 변경 내역 안에서, 이미 취소하기로 결정했던 작업의 흔적이 살아 있는 모순을 찾아낸 것이다.

사람으로 치면 이렇다. 회의에서 “B안은 폐기”라고 결정했는데, 다음 주에 올라온 문서 한구석에 B안 내용이 그대로 남아 있는 걸 검토자가 잡아낸 셈이다. 합쳐진 뒤에 발견했으면 “이거 왜 들어가 있지”부터 시작하는 고고학이 됐을 일이, 합치기 전에 한 문장으로 끝났다.

둘째 날 — “배포해도 됩니다”를 의심한 것

둘째 날이 제일 아찔했다. 배포 승인 요청이 하나 올라왔다. 서류상으로는 멀쩡했다. “이 변경분을 운영 서버에 내보내겠습니다, 승인해 주세요.” 평소라면 통과됐을 것이다.

그런데 검증용 기기가 승인 전에 운영 서버의 현재 상태를 실제로 확인했고, 이상한 점을 찾았다. 그 변경분은 이미 배포되어 있었다. 승인 요청 자체가 옛날 정보 위에서 작성된, 말하자면 유통기한 지난 서류였던 것이다. 그걸 모르고 승인해서 그대로 진행했다면, 이미 잘 돌고 있는 운영 서버를 더 옛날 상태로 되감는 — 한마디로 멀쩡한 걸 망가뜨리는 — 배포가 될 뻔했다.

“서류가 멀쩡하다”와 “서류의 전제가 아직 사실이다”는 다른 문제다. 전자는 누구나 본다. 후자를 보러 가는 건 한 단계 더 깊은 의심인데, 신모델은 그걸 시키지 않아도 했다.

어느 노드에 말을 걸어도 결재·릴레이·확인 신호는 허브로 수렴한다 — 멀티에이전트 거버넌스의 한 장면

덧붙임 — 자기 오보를 자기가 잡은 밤

다만 저 피드에 쌓이는 보고가 늘 옳기만 한 건 아니다. 사흘 사이 그걸 보여 준 사고도 하나 있었다. AI 가 “기기 간 문서 동기화가 멈췄다”고 두 번이나 보고해 온 것이다. 두 번이면 보통 진짜다. 그런데 사고 조사를 시키자 예상 밖의 결론이 돌아왔다. 동기화는 멀쩡했고, 고장 나 있던 건 보고자 자신이 읽은 사본이었다. 검증용으로 떠 둔 문서 사본이 옛날 작업 갈래에 좌초된 채 낡은 내용을 읽고 있었고, 그 낡은 화면을 근거로 “동기화가 멈췄다”는 경보를 울린 것이다. 공교롭게도 그건 그날 조사하던 결함과 정확히 같은 종류였다. 남의 사고를 조사하다가, 같은 구덩이에 빠져 있는 자기 발밑을 발견한 셈이다.

여기서 끝났으면 그냥 민망한 해프닝이다. 흥미로운 건 그다음이었다. AI 는 “제 보고 두 건은 오보였습니다”라고 증거와 함께 스스로 정정했고, 같은 밤에 어느 기기든 사본이 아니라 정본을 직접 읽도록 읽기 경로를 고쳐서 같은 부류의 오보가 다섯 대 어디에서도 재발할 수 없게 만들었다. 나는 이 장면이 사흘 중 가장 마음에 들었다. AI 에게 기대할 가치는 안 틀리는 게 아니다 — 그건 불가능하다. 틀렸을 때 그걸 증거로 스스로 잡아내고, 사과문이 아니라 재발 방지 패치로 마무리하는 것. 사람 팀에서도 흔치 않은 그 마무리를, 기계가 한밤에 혼자 해냈다.

셋째 날 — 사고를 고치는 게 아니라 재발을 막은 것

셋째 날엔 좀 더 큰 일을 줬다. 얼마 전 함대에서 두 기기가 같은 파일을 동시에 고치다 한쪽 수정이 사라지는 사고가 있었다. 흔한 동시 작업 사고다. 보통은 “사라진 부분 복구”로 끝내고 넘어간다.

검증용 기기에게는 복구가 아니라 재발 방지를 설계하라고 시켰다. 그러자 같은 파일을 두 기기가 동시에 잡을 수 없게 하는 잠금 구조를 설계하고, 구현하고, 그걸 검증하는 테스트까지 스스로 짰다. 여기까지도 만족스러웠는데, 진짜는 그다음이었다. 그 테스트를 돌리는 과정에서 이번 사고와 무관하게 잠복해 있던 별개의 버그 — 운영체제가 다른 기기에서만 미묘하게 다르게 동작하는 호환성 문제 — 가 함께 걸려 나왔다. 사고 하나를 수습하러 들어갔다가, 아직 터지지 않은 사고 하나를 미리 제거하고 나온 것이다.

솔직한 체감 — 이름만 바뀐 가격 인상 아닌가?

여기까지 읽으면 신모델 예찬 같지만, 솔직한 체감을 하나 적어 둬야 공정하다. 3일 내내 마음 한구석엔 이런 의심이 있었다. “이거 사실 이름만 바꾼 가격 인상 아닌가?” 기존 모델도 시키면 어지간한 건 다 했다. 새 모델이 한 일들도 “기존 모델은 절대 못 했다”고 단언하기는 어렵다. 그러니 단가표만 보면, 같은 노동에 새 상표를 붙여 두 배를 받는 그림으로 보일 수도 있다.

그런데 사흘치 기록을 다시 보다가 생각이 한 칸 옮겨갔다. 내가 줄곧 토큰 단가, 그러니까 재료비를 보고 있었다는 것. 정작 내게 의미 있는 숫자는 결과물 하나당 비용이다. 위의 배포 사고가 실제로 났다면 수습에 하루는 갔을 것이다. 다섯 대가 하루 종일 도는 비용, 그리고 그날 못 한 일의 기회비용까지. 잠복 버그가 나중에 터졌어도 마찬가지다. 단가가 두 배라도 사고 한 번을 막을 때마다 그 차액은 몇 번이고 회수된다. 거꾸로 단가가 절반이어도 일을 두 번 시켜야 하면 싼 게 아니다.

“라벨에 붙은 가격”이 아니라 “끝난 일 하나당 가격”으로 환산하기. 모델 비교에서 이번에 얻은 가장 쓸 만한 프레임이었다.

결정 — 전환은 하되, 최대로 밟지는 않는다

3일이 끝나고 결정했다. 함대는 새 모델로 전환한다. 다만 사용량을 최대로 끌어올리는 것은 보류한다.

전환을 결정한 근거는 위의 세 장면이다. 셋 다 “더 잘 짠 코드”가 아니라 “사고를 미리 막은 판단”이었고, 그건 내 시스템에서 가장 비싼 종류의 가치다. 한편 사용량을 최대로 밟지 않는 건, 두 배 단가의 고정비를 검증 3일 만에 전부 약정하는 게 영 내키지 않아서다. 나는 큰 결정에서 “안 해서 후회”보다 “질러서 후회”를 훨씬 오래 곱씹는 사람이라는 걸 스스로 안다. 그 성향까지 계산에 넣으면, 전환이라는 큰 걸음과 증액 보류라는 브레이크를 같이 밟는 중간안이 내게는 정답에 가깝다. 사용량은 다음 달 청구서라는 실측 데이터를 보고 다시 정하면 된다.

카나리, 실측, 점진

정리하면 이번에 한 일은 세 단어다. 카나리 — 실측 — 점진. 한 대만 먼저 보내고, 감상이 아니라 기록으로 평가하고, 결과만큼만 움직인다.

새 도구가 나올 때마다 “전부 갈아타기 vs 그대로 버티기”의 양자택일로 몰리는 건, 사실 도구의 문제가 아니라 검증 비용의 문제다. 되돌리기 쉬운 작은 실험 하나를 설계할 수 있다면, 그 양자택일은 거의 항상 피할 수 있다. AI 모델이라서 특별한 게 아니다. 다만 AI는 “한 대만 바꿔서 사흘 시켜 보기”가 유난히 싸게 먹히는 도구라서, 이 오래된 지혜가 유난히 잘 듣는 동네일 뿐이다.

다음에 또 새 모델이 나오면, 나는 같은 일을 반복할 것이다. 한 마리부터.

이 글은 새 AI 모델(Fable 5) 출시 직후, 5대 기기 중 1대만 먼저 전환해 3일간 실무 검증한 뒤 전체 전환을 결정한 과정을 일반 독자용으로 풀어쓴 에피소드입니다. 함대 운영 구조 자체는 ep34에서 다뤘습니다.

— 강대종