LLM에도 EOL(End-of-Life)이 있다 — 모델을 종속 라이브러리처럼 관리하기

LLM을 실제 서비스에 통합할 때, 제가 처음 간과했던 것은 '그 모델을 언제까지 사용할 수 있는가'였습니다.

Rails 버전이라면 누구나 EOL(End-of-Life)을 신경 씁니다. PostgreSQL이라면 다음 메이저 업그레이드를 계획에 포함합니다. 그런데 모델의 경우, 선정 논의는 정확도와 비용에만 집중되어 있고, 수명에 대한 이야기는 나오지 않았습니다. 적어도 저에게는 그랬습니다.

모델에도 서비스 종료가 있다

알게 된 계기는 완전히 다른 작업을 하던 중이었습니다. 비용 최적화를 위해 사용 모델 목록을 살펴보다가 EOL(End-of-Life) 열에 눈이 멈췄습니다. 날짜가 과거였습니다. 아무리 봐도 끝났다는 것밖에 보이지 않았습니다. 의자에서 미끄러졌습니다.

Amazon Bedrock에는 모델 라이프사이클이라는 문서가 있으며, 각 모델은 Active → Legacy → EOL 순서로 전환됩니다. Legacy 상태가 되는 시점에 제공 종료일이 표시되며, EOL을 지나면 호출할 수 없습니다. Bedrock에 한정된 것이 아니라 주요 프로바이더 모두 같은 구조입니다. 모델은 영구적인 인프라가 아니라 기한이 정해진 종속물인 것입니다.

골치 아픈 점은 EOL이 다가와도 애플리케이션 자체가 아무런 경고를 내보내지 않는다는 것입니다. gem의 취약점이라면 bundle audit가 알려주고, EOL이 가까운 런타임이라면 CI(Continuous Integration)가 경고를 줍니다. 모델에는 그런 것이 없습니다. 문서를 능동적으로 찾아본 사람만이 알고 있는 상태가 됩니다.

교체 과정에서 깨지는 것은 코드가 아니다

'모델 ID를 한 줄만 바꾸면 된다'—이것이 제가 마이그레이션 전에 추정한 내용이었습니다. 바꿀 라인 수는 그 말이 맞습니다.

문제는 그 다음입니다. 같은 프롬프트에 대해 동작 방식이 달라집니다.

가장 까다로웠던 것이 답변 거부였습니다. 새로운 모델은 안전한 쪽에 치우쳐 있어서, 이전에는 문제없이 처리했던 입력에 대해서도 답할 수 있는데 '답변을 할 수 없다'는 식의 응답을 합니다.

모델의 EOL(End-of-Life)을 개발 계획의 마일스톤에 포함시키는 것이 가장 효과적입니다. EOL 날짜를 릴리스 계획이나 DB 버전 업그레이드와 동일하게 스케줄에 배치해야 합니다. 그렇게 하면 'EOL 2개월 전에 마이그레이션 검증을 시작한다'는 역산 과정이 작동합니다. 문서를 주기적으로 확인하는 운영 방식은 바쁜 시기에 반드시 건너뛰게 되므로 신뢰하지 않습니다.

완료 조건을 '작동 여부'가 아니라 '품질 동등성'으로 설정해야 합니다. 실제 업무 입력을 통한 비교 검증을 스테이징 환경에서 수행하고, 답변 거절 및 톤을 확인해야 합니다. 이 단계를 건너뛰면 모니터링 시스템을 우회할 수 있습니다.

마이그레이션을 하나의 모델로 끝내서는 안 됩니다. 용도별로 여러 개를 사용한다면, EOL은 각각 다가옵니다. 나란히 배치해 두지 않으면, 한쪽을 완료했다는 성취감에 다른 쪽을 잊어버리기 쉽습니다.

예상되는 반론

'추상화 레이어를 적용하여 프로바이더 비의존적으로 만들면 되지 않나?'

추상화 레이어는 이미 존재합니다. 모델 ID를 교체하는 것 자체는 설정 변경으로 끝납니다. 그럼에도 불구하고 이 글을 작성하는 이유는, 교체 후 남는 작업이 본질적이기 때문입니다.

코드의 의존성은 추상화를 통해 끊을 수 있습니다. 끊기 어려운 것은, 해당 모델의 특성에 맞춰 작성한 프롬프트입니다.

'EOL까지 여유가 있는데, 과장된 것 아닌가?'

여유가 길다는 것이 그대로 방심으로 이어집니다. 기한이 정해질 때까지 애플리케이션은 정상적으로 작동하기 때문에, 방치해도 아무 일도 일어나지 않습니다.

게다가 기간이 길수록, 해당 모델을 적용한 사람이 현장에 없을 가능성이 높아집니다. 리마인더를 심어 놓아도, 왜 그 설정인지 모르는 사람이 받게 됩니다. 여유는 준비의 시간인 동시에, 경위가 사라져가는 시간이기도 합니다.

'프롬프트 재평가는 자동화할 수 있지 않나?'

가능합니다. 백테스트(backtest)는 반자동으로 돌리고 평가 점수도 산출하고 있습니다.

문제는 사용 빈도입니다. 모델 교체는 아마 1~2년에 한 번일 것이고, 그 빈도로만 구동하는 시스템은 어렵습니다. 다음에 사용할 때는 전제가 바뀌어 있고, 재정비하는 것부터 시작해야 합니다. 자동화 자체보다, 필요할 때 작동 가능한 상태로 유지하는 것이 더 어렵다고 생각합니다.

'모델 업데이트는 정확도가 올라가니 오히려 환영할 만하다.'

오르는 것은 있습니다. 다만, 정확도의 척도는 최종적으로 사용자가 어떻게 느끼는지에 달려있습니다. 기계적인 점수는 어느 정도 파악할 수 있지만, 그 출력이 사용자에게 유용한지는 별개의 문제입니다. 항상 최신을 추구해서는 안 됩니다. 비즈니스적 비용도 고려해야 합니다.

그렇기 때문에, 업데이트를 환영할지 여부와는 분리하여, 기한은 기한으로서 계획에 포함시켜야 합니다.

아직 결정하지 못한 것

자동화할 여지는 있습니다. 모델의 상태를 주기적으로 가져와서 Legacy로 떨어지면 알림을 주는 것입니다. 기술적으로 어렵지 않습니다.

다만, 알림을 만든다고 해서 마이그레이션 자체가 자동화되지는 않습니다. 프롬프트 재튜닝(re-tuning)이 본질이기 때문입니다. 알림을 많이 만들어 안심하고, 실제 작업 견적은 부실하게 잡는 것이 더 위험할 수도 있다는 생각이 들어서 아직 손대지 않았습니다.

요약

• LLM에도 제공 종료(EOL)가 있다. 영구 인프라가 아닌 기한이 있는 의존성으로 관리해야 한다.
• EOL은 애플리케이션에서 관측할 수 없다. 라이프사이클 정보를 능동적으로 가져와 개발 계획의 마일스톤에 포함시켜야 한다.
• 마이그레이션의 본질은 코드 변경이 아니라 프롬프트 재튜닝과 재평가이다. 답변 거절의 변화는 모니터링을 우회하므로, 업무 입력에서의 비교 검증이 필요하다.
• 모델 ID는 환경 변수에 두어야 한다. EOL은 반복적으로 찾아온다.

본 기사는 Stock Tech Blog의 글입니다. 주식회사 Stock은 팀 정보를 가장 쉽게 관리할 수 있는 Stock과, 지식을 키워 기업 잠재력을 개방하는 나레칸(Narekan)이라는 2가지 제품을 개발하고 있습니다.

함께 개발할 엔지니어를 찾습니다 → 채용 정보

저자: 타케다 슈니치(@Shunichi-Takeda／주식회사 Stock CTO)

Discussion