AI 업계는 장기 지원 모델을 마련해야 한다

AI 업계는 최첨단 모델 개발을 계속하면서도 조직이 수년간 의존할 수 있는 장기 지원(LTS) 모델을 제공해야 한다는 주장이 나왔다. 학교와 병원처럼 모델을 업무에 통합하는 조직에는 새 모델의 성능뿐 아니라 예측 가능한 유지보수와 변경 절차도 필요하다는 취지다.

인공지능 업계의 논의는 새 벤치마크 기록을 세우거나 코딩 성능을 높이고, 첫 토큰이 더 빨리 나오는 모델에 쏠리곤 한다. 새 모델이 나올 때마다 도구와 프롬프트를 다시 검토하고 시스템을 옮겨야 한다는 분위기도 생긴다. 그러나 다리오 아모데이의 ‘우리는 최첨단 개발 속도를 조절해야 한다’는 글에 대한 앞선 반론에서 제시했듯, 개발 속도를 늦추면 안전 연구에 시간을 더 줄 뿐 아니라 기존 시스템의 작동 방식을 익히고 업무와 기관에 정착시킬 시간도 생긴다.

이미 충분히 쓸 만한 시스템이 있는데도 계속 교체해야 할 이유가 있을까. 글은 AI 업계에도 우분투의 장기 지원판과 같은 모델이 필요하다고 주장한다. 최첨단 개발은 이어가되, 조직이 수년간 의존할 수 있도록 안정적으로 유지되는 버전이다.

새 버전과 장기 지원판은 목적이 다르다

리눅스는 오래전부터 두 가지 배포 방식을 함께 운용해 왔다. 롤링 릴리스는 최신 커널과 패키지를 제공하지만 때로는 기존 환경을 깨뜨린다. 그 위험을 감수하고 최신 버전을 원하는 사람에게는 적합하다. 반면 다른 사람의 업무를 떠받치는 기반 시스템에는 정해진 지원 기간과 예측 가능한 유지보수, 기존 작업을 쉽게 깨뜨리지 않는 변경이 중요하다. 우분투는 2년마다 장기 지원판을 지정해 5년간 유지하며, 최신 버전을 원하는 사람을 위한 중간 릴리스도 계속 내놓는다.

지원 버전은 동결된 버전이 아니다. 취약점을 고치고 버그를 해결하며 지원 대상 구성요소를 업데이트한다. 핵심은 최신 버전으로 계속 교체하는 대신, 이미 정해진 릴리스를 유지하는 데 있다.

AI에는 이에 견줄 만한 약속이 없다. 모델 스냅샷을 지정하거나 기업 고객에게 폐기 예고 기간을 제공하는 방식이 어느 정도 안정성을 주지만, 특정 버전을 고정한다고 해서 장기적인 제공과 유지보수, 호환성이 보장되는 것은 아니다.

가장 가까운 사례는 앤스로픽이 2025년 11월 발표한 약속이다. 회사가 존속하는 동안 공개 출시한 모든 모델의 가중치를 보존하겠다는 내용이다. 이는 중요한 약속이지만 다른 질문에 답한다. 가중치 보존은 모델을 보호하고, 지원 기간은 그 모델에 맞춰 업무를 구축한 사람들을 보호한다.

모델 교체가 조직에 주는 비용

학교와 고등교육기관, 영국 국민보건서비스(NHS) 트러스트가 어떻게 운영되는지 생각해 보자. 이런 조직이 변화를 조심스러워하는 까닭은 구성원에게 상상력이 부족해서가 아니다. 실패의 대가가 크고 예산이 제한돼 있으며, 혼란의 피해를 감당할 힘이 적은 사람들이 그 영향을 받기 때문이다.

한 대학이 특정 모델을 중심으로 접근성 높은 수업 절차를 개발하는 데 6개월을 썼다고 가정해 보자. 교직원을 교육하고 학생 보호 절차를 만들며, 복잡한 학생 질문에 모델이 어떻게 답하는지 시험한다. 추가 지원이 필요한 학생을 위한 안내를 마련하고, 교사들은 어떤 지시가 효과적인지, 모델이 어디서 실수하는지, 어떤 답을 확인해야 하는지 익힌다. 각 결정은 ‘서기 규칙’에서 제기한 질문, 즉 특정 용도가 장벽을 없애는지 아니면 학습 자체를 없애는지에 달려 있다. 그리고 이 질문은 실제 사용하는 모델을 대상으로 답해야 한다.

절차가 효과를 내기 시작하면 직원은 익숙해지고 학생은 더 독립적으로 일할 수 있는 습관을 갖춘다. 그런데 모델이 폐기되거나 동작이 크게 바뀌고, 새 모델이 익숙한 작업을 다르게 처리하면 대학은 절차를 다시 평가하고 직원을 재교육하며 새 시스템을 시험해야 한다. 일부 작업은 처음부터 다시 해야 한다. 그 혼란은 이전 버전을 겨우 익힌 사람들에게 돌아간다. 새 모델의 역량이 더 뛰어나더라도 전환 비용까지 사라지는 것은 아니다.

언어 모델 API를 바탕으로 소프트웨어나 업무 절차를 만든 사람도 같은 문제를 더 작은 규모로 경험할 수 있다. 예고 없는 모델 업데이트는 형식, 도구 선택, 거부 응답, 까다로운 예외 상황의 처리 방식을 바꿀 수 있다. 유효한 JSON을 반환하던 시스템이 애플리케이션을 망가뜨리는 구조를 내놓기 시작할 수도 있다. 일반적인 작업에서는 나아져도 특정 기업이 의존하는 작업에서는 예측하기 어려워질 수 있다. 이 불일치는 사용자의 관점에서 ‘중간’이라는 글에서 다뤄졌다.

전통적인 소프트웨어에서는 개선과 호환성을 깨는 변경을 구분한다. AI에서는 벤치마크 성능을 높인 릴리스가 실제 시스템의 전제를 조용히 깨뜨릴 수 있다. 업무 시스템에 필요한 것은 변화가 눈에 보이게 전달되고, 그 변화를 거쳐 갈 경로가 마련되는 일이다.

AI 장기 지원판이 약속할 내용

주요 AI 연구소가 역량 있는 모델을 5년간 지원하는 LTS 버전으로 지정한다고 상상해 보자. 오래된 모델 이름을 API 메뉴에 남겨 두는 것보다 실질적인 약속이어야 한다. 제공업체와 해당 기술을 바탕으로 시스템을 구축하는 사람들 사이의 관계를 명확히 하는 것이다.

그 기반이 될 약속은 세 가지다.

• 버전별 동작 기록과 통제된 변경: 모델 체크포인트, 추론 설정, 인터페이스를 문서화하고 버전을 관리한다. 제공업체는 호환성 기준을 공개하고, 하위 애플리케이션이 의존하는 작업과 출력 형식을 대상으로 회귀 테스트를 유지한다.

모든 프롬프트가 영원히 똑같은 답을 내놓는다고 보장하자는 뜻은 아니다. 언어 모델은 확률적으로 작동하므로 가중치가 그대로여도 출력은 달라질 수 있다. 시스템 프롬프트, 추론 소프트웨어, 안전 필터, 도구 정의 등 서비스 제공 체계의 다른 요소도 동작에 영향을 준다.

목표는 중요한 변경을 눈에 띄고 측정 가능하며 통제된 방식으로 만드는 것이다. 지원 버전의 동작을 조용히 바꿔 기존 업무 절차가 무효가 되게 해서는 안 된다. 변경이 필요하면 문서화하고 시험하며 이전 절차에서 옮겨 갈 경로를 제공해야 한다.

• 불필요한 혼란을 줄이는 보안·안전 유지보수: LTS 모델도 보안 업데이트와 안전장치 개선이 필요하다. 안정성을 이유로 동작이 바뀔 수 있다는 이유만으로 취약점을 그대로 두어서는 안 된다.

제공업체는 통상적인 유지보수와 모델 동작에 중대한 영향을 주는 변경을 구분해야 한다. 변경 사항을 공개하고 안전성과 작업 성능을 모두 다루는 회귀 테스트로 업데이트를 시험해야 한다.

두 목표가 충돌할 때도 있다. 심각한 취약점을 해결하려면 기존 업무 절차가 깨질 수 있고, 긴 전환 기간을 허용할 수 없는 긴급 보안 문제도 생긴다. 모든 경우에 안전성과 호환성을 완벽히 맞출 수 있다고 가장하기보다, 결정의 이유를 설명하고 불필요한 혼란을 줄이며 명확한 대응 경로를 마련해야 한다.

• 예측 가능한 제공 기간과 비용: 기관에는 정해진 지원 기간, 폐기 전 충분하고 의미 있는 사전 통지, 투명한 가격 또는 합의된 가격 조건, 지원 종료 시 문서화된 이전 경로가 필요하다.

기술적으로는 계속 쓸 수 있어도 비용이 감당하기 어려워지면 믿고 의존할 기반이 되지 못한다. ‘요금계’에서 지적했듯, 소비자용 AI의 가격은 계획을 세우기 어렵게 책정된 경우가 많다. 새 모델에 컴퓨팅 자원을 돌리기 위해 제공업체가 짧은 통지만으로 기존 모델을 철회할 수 있어도 안정적인 기반이 아니다.

공개 가중치나 로컬에서 호스팅할 수 있는 가중치는 연속성을 확보하는 또 다른 경로가 될 수 있다. 단일 제공업체의 상업적 결정에 대한 의존은 줄일 수 있지만, 하드웨어와 추론 인프라, 보안, 유지보수 비용까지 없애 주지는 않는다. 장기 지원이 반드시 무료여야 한다는 뜻은 아니다. 모델에 의존하는 비용과 조건을 조직이 계획할 수 있을 만큼 미리 알아야 한다는 뜻이다.

안정성은 안전의 일부다

사람들은 시스템을 충분히 오래 사용하면 동작을 이해하게 된다. 어떤 일을 잘하고 어디서 실패하는지, 평소와 다른 답은 어떤 것인지 익힌다. 이런 친숙함은 정식 시험을 대신할 수 없지만, 문제가 생겼을 때 알아차리는 데 도움이 될 수 있다.

직원들이 계속 새 모델을 익혀야 한다면 그런 친숙함을 쌓을 기회가 줄어든다. 시스템의 평소 답변을 아는 교사는 학생에게 낯선 답이 나왔을 때 알아차릴 수 있다. 행정 도구의 한계를 익힌 돌봄 노동자는 그럴듯하지 않은 결과를 발견할 가능성이 더 높다. ‘87’은 더 어려운 문제를 제기한다. 감독은 그 일을 맡은 사람이 그럴듯한 실수를 알아볼 전문성을 유지할 때만 효과가 있으며, 그 전문성은 종종 넘겨받은 업무 자체를 통해 길러진다. 익숙해질 시간을 다시 처음부터 시작하게 만드는 릴리스 주기는 같은 목표를 거스른다.

물론 시스템을 바꾸면 안전성이 높아질 수 있다. 새 모델의 오류가 크게 줄어들 수도 있으며, 성능이 떨어지는 버전을 무기한 유지하는 것은 무책임할 수 있다. 그러나 결정할 때는 개선의 이익과 이전에 드는 비용과 위험을 함께 따져야 한다. 새 버전이라는 이유만으로 교체가 자동으로 이롭다고 가정해서는 안 된다.

앞선 최첨단 개발 속도 조절에 관한 글에서는 역량 발전과 엄격한 교육·통제 절차가 함께 작동하는 안전 핵심 분야의 사례로 상업 항공을 들었다. 항공기는 영원히 바뀌지 않는 것이 아니다. 항공기 변경은 운용자가 정보를 받고 자격을 갖추며 기계를 안전하게 다룰 수 있도록 설계된 절차를 거친다.

AI에도 기술을 둘러싼 사람과 기관의 업무를 존중하는 태도가 필요하다. 신뢰성은 모델만의 속성이 아니다. 모델을 둘러싸고 구축된 사람, 절차, 인프라도 신뢰성의 일부다.

최첨단 개발과 안정적인 지원은 함께 갈 수 있다

장기 지원에 자원을 쓰면 새 모델을 개발하고 제공하는 데 쓸 돈과 시간이 줄어든다는 반론이 있다. 구형 모델을 유지하는 데는 비용과 엔지니어링 시간, 컴퓨팅 자원이 든다. 제공업체가 경제적으로나 안전 면에서 더는 지원할 수 없는 시스템을 폐기할 정당한 이유도 있다.

LTS 프로그램은 모델이 사라질 때 그 비용을 사용자에게 넘기는 대신 비용을 명시적으로 드러낼 수 있다. ‘타임스탬프’에서 다룬 문제도 다른 맥락에서 같은 비대칭을 짚었다. 계산에 포함되는 비용과 실제로 부담하게 되는 비용은 흔히 다르다. 지원은 실제 비용을 반영한 가격으로 제공하고, 기간과 종료일을 정할 수 있다.

모든 모델을 장기 지원할 필요도 없다. 실험용이거나 수명이 짧거나 장기 배포에 적합하지 않은 모델도 있다. 빠른 실험을 위해 만든 모델과 오래 쓰는 작업의 믿을 만한 기반으로 의도적으로 제공하는 모델을 구분하면 된다.

두 경로는 공존할 수 있다. 최첨단 연구는 추론과 과학적 발견, 멀티모달 역량의 한계를 계속 넓힐 수 있다. 최신 성능이 필요한 사용자는 새 모델을 채택하고, 안정성을 중시하는 조직은 지원 버전을 선택한 뒤 그 이점이 전환 노력을 정당화할 때 옮겨 갈 수 있다.

인상적인 시연에서 믿고 쓰는 도구로

발명과 도입은 서로 다른 과정이다. 폴 데이비드의 공장 전기화 연구가 보여 주듯, 전기 모터는 생산성 향상이 나타나기 수십 년 전부터 존재했다. 이득을 얻으려면 모터에 맞춰 공장 자체를 재구성해야 했기 때문이다.

AI도 비슷한 과제를 안고 있다. 더 역량 있는 모델이 자동으로 더 역량 있는 기관을 만들지는 않는다. 조직은 절차를 개발하고 직원을 교육하며 위험을 평가하고 기술이 실제로 도움이 되는 곳을 알아낼 시간이 필요하다. 그 과정에서 업무의 기반이 몇 달 뒤에도 존재할지, 예상한 대로 작동할지 계속 걱정하지 않아도 돼야 한다.

안정적인 릴리스 주기가 AI 도입의 모든 문제를 해결하지는 않는다. 신뢰할 수 없는 모델을 믿을 만하게 만들거나 환각을 없애거나 사람의 감독을 불필요하게 하지는 않는다. 다만 조직이 그런 문제를 다룰 더 단단한 기반을 제공한다.

AI 업계는 모델 역량을 높이는 데 막대한 노력을 쏟아 왔다. 이제 장기 지원도 특별 계약을 맺은 기업 고객만을 위한 뒷일이 아니라 제품의 핵심 요소로 다뤄야 한다. 사람들은 도구를 중심으로 오래가는 무언가를 구축할 만큼 믿을 수 있을 때 그 도구를 도입한다. 그 순간은 대개 도구가 가장 인상적으로 보이는 때와 다르다.

최첨단 개발은 계속 야심 차게 추진할 수 있다. 현실의 업무를 떠받치는 릴리스 주기는 신뢰할 수 있을 만큼 안정적이어야 한다.

이 글에서 기관의 관성, 직원 교육, 보조 업무 절차 변경에 따른 사람들의 부담을 다룬 부분은 고등교육 및 특수교육(SEN) 분야에서 일상적으로 겪은 경험에 바탕을 둔다. 리눅스 릴리스 주기, API의 호환성을 깨는 변경, 동결된 가중치와 서비스 제공 체계의 차이에 관한 기술적 논점도 소프트웨어를 만들고 리눅스 시스템을 다룬 경험에 기반한다.

우분투의 릴리스 주기에 관한 설명은 Canonical이 공개한 수명주기 문서, 특히 5년의 표준 LTS 유지보수 기간과 Ubuntu Pro 연장 지원을 가리킨다. 앤스로픽의 가중치 보존 약속은 2025년 11월 공개된 회사의 발표다. 결론의 역사적 비유는 폴 A. 데이비드가 1990년 American Economic Review에 발표한 논문 ‘다이너모와 컴퓨터: 현대 생산성 역설의 역사적 관점’에 바탕을 둔다.

이 글에서 추측의 여지가 가장 큰 부분은 최첨단 AI 연구소의 내부 경제성이다. 제공업체가 모델 스냅샷 고정과 기업용 폐기 예고 기간을 제공하기는 하지만, 기존 추론 서버를 계속 가동하는 비용과 새 아키텍처에 맞춰 컴퓨팅 자원을 통합하는 비용의 정확한 비교는 알 수 없다. 따라서 세 부분으로 구성된 LTS 체계는 현재 제공업체가 저렴하거나 쉽게 실행할 수 있다는 주장이 아니다. 공공 서비스와 기업이 업계에 필요로 하는 것을 제시하는 정책·엔지니어링 제안이다.