어느 제품팀이 고객 워크플로 자동화에 6주를 썼습니다. 완성을 이틀 앞두고 더 빠르고 저렴한 새 모델이 공개됐습니다. 슬랙에 링크가 쏟아졌습니다. 팀장은 회의를 소집했고, 새 모델로 전환하기로 했습니다. 3주를 더 썼습니다. 그사이 또 다른 모델이 발표됐습니다.
이 장면을 겪은 팀들이 공통으로 내리는 진단이 있습니다. "AI가 너무 빨리 발전한다. 최신 모델을 항상 추적해야 한다." 처방도 같습니다. 발표가 나오면 즉시 검토하고, 더 나으면 교체한다.
그런데 교체한 뒤에도 같은 장면이 반복됩니다. 진단이 맞다면 처방을 충실히 따를수록 충격이 줄어야 하는데, 많은 팀에서 그렇지 않습니다. 이 불일치는 진단 자체가 빗나간 데서 시작합니다.
6주가 어디에 쌓였는가
MIT 슬론 경영리뷰가 다룬 사례들을 보면, 같은 기간 비슷한 모델을 사용한 팀이라도 교체 충격이 크게 다른 경우가 있었습니다. 충격이 큰 팀과 작은 팀 사이에는 일관된 패턴이 있었습니다.
충격이 큰 팀은 모델 응답에 직접 맞닿는 방식으로 워크플로를 쌓았습니다. 프롬프트 구조가 그 모델의 출력 형식을 전제했고, 후처리 로직이 그 모델의 오류 패턴을 기준으로 작성됐습니다. 특정 모델이 JSON 출력을 일관되게 반환한다고 파악하면 그 형식에 맞춰 파싱 로직을 쌓습니다. 그 모델이 특정 유형의 질문에서 길게 설명한다는 걸 알면, 응답을 잘라 쓰는 로직도 추가합니다. 새 모델은 다르게 실패합니다. 다른 케이스에서 JSON 형식을 어기고, 다른 질문 유형에서 짧게 답합니다. 후처리 전체가 다시 쓰여야 합니다. 6주가 다시 필요한 이유입니다.
충격이 작은 팀은 처음부터 레이어를 분리했습니다. 모델 응답을 한 단계 거른 뒤 처리했습니다. 모델이 어떤 형식으로 출력하든 먼저 정규화하는 단계를 뒀고, 그 위에 검증 로직을 올렸습니다. 어떤 모델을 쓰든 검증 로직은 바뀌지 않습니다. 새 모델로 교체할 때 수정하는 부분은 정규화 단계뿐입니다.
같은 6주를 쓰고도 한 팀의 6주는 특정 모델과 묶여 있었고, 다른 팀의 6주는 모델과 분리된 레이어가 됐습니다.
이 상태를 워크플로를 만드는 도중에 알아채는 신호가 있습니다. 특정 모델의 응답에 맞춰 예외 처리 로직을 추가하게 될 때입니다. 처음에는 "이 케이스에서 모델이 이렇게 답하더라"는 관찰에서 시작합니다. 관찰이 쌓이면서 그 관찰을 전제로 코드가 쌓입니다. 이 시점에 '지금 만들고 있는 것이 이 모델에 종속되는가'를 물어야 합니다. 대답이 '예'라면 레이어 분리를 지금 시작하는 것이 6주 뒤보다 훨씬 쉽습니다.
팀이 스스로 만든 전환비용
경영 전략에서 전환비용(switching cost)은 기업이 고객에게 부과하는 개념으로 발전했습니다. 고객이 다른 서비스로 이동할 때 드는 비용을 높여 이탈을 줄입니다. 소프트웨어 구독의 데이터 이관 절차, 플랫폼 학습에 드는 시간, 기존 시스템과의 연동이 여기에 속합니다. 전략적으로 잘 설계된 전환비용은 경쟁사가 쉽게 넘지 못하는 해자가 됩니다.
그런데 AI 모델 교체 사이클이 짧아지면서, 이 논리가 실무에서 방향을 바꿔 작동합니다. 팀이 자신이 쓰는 도구에 스스로 묶이는 것입니다.
전환비용이 높을 때 경쟁사가 더 나은 제품을 내놓으면 고객은 떠나기 어렵습니다. 같은 논리로, 자신이 만든 전환비용이 높은 팀은 더 나은 모델이 나와도 옮기기 어렵습니다. 옮기면 지난 6주가 무너집니다. 남아 있으면 성능이 낮은 모델을 계속 씁니다. 두 선택지 모두 팀에 비용을 부과합니다. 이 상태는 초기 설계 결정에서 시작됩니다.
여기서 역설이 있습니다. 모델 발표마다 즉시 검토하고 교체하는 팀이 오히려 전환비용을 높게 유지하는 경우가 있습니다. 교체를 결정할 때마다 팀의 관심이 분산되고, 교체 이후에도 새 모델에 맞춰 워크플로를 손봐야 합니다. 교체 빈도가 높으면 이 비용이 누적됩니다. 처음부터 레이어를 분리했다면 교체 빈도가 높아져도 비용이 제한됩니다.
이 결정을 팀 내에서 누가 내리느냐도 중요합니다. 엔지니어가 단기 효율을 우선하면 모델 종속 설계가 됩니다. PM이나 디렉터가 교체 비용을 제품 지표로 관리하면 설계 방향이 달라집니다. '다음 모델 교체 시 이 워크플로를 다시 짜는 데 며칠이 걸리는가'를 추정 가능하게 만드는 것이 PM의 역할 중 하나입니다.
교체 기준이 없으면 교체가 업무가 됩니다
새 모델이 발표될 때마다 팀 내에 논쟁이 생깁니다. 교체할 것인가, 기다릴 것인가. 이 논쟁 자체가 비용입니다. 성능 비교 문서를 쓰고, 벤치마크를 돌리고, 채택 여부를 회의합니다. 결론 없이 끝나면 다음 발표 때 처음부터 다시 합니다. 발표 주기가 짧아질수록 이 비용이 실무에서 차지하는 비중이 늘어납니다.
교체 기준이 있는 팀은 이 과정을 짧게 끝냅니다. 기준의 출발점은 간단합니다. 현재 모델로 처리하지 못하는 케이스가 실제로 존재하는가입니다. 팀이 처음 워크플로를 만들 때 해결하려 했던 문제 중 아직 풀리지 않은 것을 목록으로 관리하고 있으면, 새 모델이 나왔을 때 그 목록과 대조하면 됩니다.
새 모델이 그 케이스를 처리하는지 확인하는 것이 두 번째입니다. 발표 자료나 범용 벤치마크보다는 팀의 실제 데이터로 테스트합니다. 범용 벤치마크 점수가 높아도 팀이 주로 다루는 업종 특화 용어에서 다르게 실패할 수 있습니다. 마지막으로 검증 포함 교체 비용이 그 이득보다 작은지 판단합니다. 이 세 단계를 거치면 채택 여부가 수치로 결론납니다.
"새 모델이 나왔다"는 그 자체로 채택 이유가 되기 어렵습니다. 발표는 기준을 확인하는 계기가 되고, 논쟁 없이 30분 안에 결론이 납니다. 기준이 없는 팀은 같은 30분 동안 논쟁을 시작합니다.
이 기준이 영구히 옳을 수는 없습니다. 현재 처리 못 하는 케이스 목록을 잘못 관리하면 필요한 교체를 놓칩니다. 기준을 세운 뒤에는 분기마다 한 번씩 점검해야 합니다. 기준이 있되, 기준이 고정되지 않아야 합니다.
모델이 교체돼도 팀에 남는 판단력
AI 모델 성능이 높아지는 추세는 앞으로도 이어질 가능성이 높습니다. 더 싸고 빠른 모델이 짧은 주기로 나올 것이라는 전제를 받아들인다면, 교체를 피하는 전략을 세우기는 어렵습니다. 그렇다면 교체가 반복되는 환경에서 팀에 무엇이 쌓여야 하는지를 묻는 편이 더 실용적입니다.
특정 모델을 오래 쓴 경험은 그 모델이 교체되면 상당 부분 사라집니다. 그 모델의 오류 패턴을 학습한 시간, 출력 형식에 맞춘 후처리 코드, 그 모델의 특성을 기준으로 작성한 내부 가이드라인이 여기에 속합니다. 어떤 모델을 써도 남는 자산은 따로 있습니다.
모델이 잘하는 작업 유형과 못하는 유형을 구분하는 감각입니다. 특정 모델에 대한 지식이 아니라, 언어 모델이 일반적으로 어디서 실패하는가에 대한 이해입니다. 이 감각은 새 모델에도 적용됩니다. 레이어를 분리하는 설계 습관도 마찬가지입니다. 한 번 익히면 다음 워크플로를 만들 때도 처음부터 올바른 방향으로 시작합니다.
판단력이 있다는 것은 실무에서 이렇게 나타납니다. 새 모델의 발표 자료를 받았을 때, 팀이 주로 처리하는 케이스와 그 모델의 강점이 겹치는지를 5분 안에 판단합니다. 겹치지 않으면 검토 대상에서 제외합니다. 겹치면 실제 데이터로 테스트합니다. 이 흐름이 자동으로 돌아가는 팀은 모델 발표를 업무 중단 사건으로 경험하지 않습니다.
이런 자산은 다음 모델이 나와도 사라지지 않습니다. 모델은 6주마다 교체될 수 있지만, 이 자산은 교체 사이클에 묶여 있지 않습니다. 6주를 다시 쓰느냐 3일로 끝내느냐의 차이는 어느 모델을 쓰느냐가 아니라 이 자산이 팀에 있느냐에서 납니다.
