능력표는 코드 밖에서 낡는다 | 법마디(Lawmadi) OS 기술칼럼

초록 '모델은 교체 가능한 부품'이라는 말은 어댑터 계층이 얇을 때만 참입니다. 그런데 이번 달 주요 오픈소스 릴리스를 나란히 놓고 보면, 어댑터가 얇아지는 대신 그 옆에 '모델 능력표'라는 데이터가 자라고 있습니다. 어떤 모델이 어떤 추론 노력 단계를 받는지, 어느 엔드포인트로 가야 하는지, 함수 호출 규약이 무엇인지가 코드가 아니라 표에 적히고, 그 표는 벤더가 새 모델을 낼 때마다 낡습니다. 표가 낡았을 때의 실패는 예외가 아닙니다 — 호출은 400 한 줄로 튕기고, 라우팅은 조용히 다른 모델로 흐르며, 엔진이 지원하던 아키텍처는 조용히 목록에서 빠집니다. 세 프로젝트의 변경 목록에서 이 실패의 세 형태를 확인하고, 우리 파이프라인의 핀이 실제로 몇 자리인지 세어 봅니다.

모델을 바꿀 수 있다는 것과 모델을 바꿔 봤다는 것은 다릅니다. 호출 코드가 한 줄도 안 바뀌었는데 결과가 달라지는 자리들이 있기 때문입니다. 이번 달 릴리스 노트를 읽다 보면 그 자리가 어디인지가 꽤 선명하게 드러납니다. langchain 의 OpenAI 패키지는 '모델 프로파일 데이터 갱신'이라는 잡무 커밋을 한 릴리스 안에서 세 번 반복했고, 그 사이에 gpt-5 계열의 추론 노력 단계 목록을 '고쳤으며', 특정 모델을 다른 API 로 라우팅하는 수정을 넣었습니다. LlamaIndex 는 Claude Sonnet 5 지원 추가와 그 모델의 함수 호출 수정을 같은 릴리스에 나란히 실었습니다. vLLM 은 열 개의 모델 아키텍처를 지원 목록에서 지웠습니다. 셋을 겹쳐 보면 공통된 사실이 하나 남습니다. 모델의 능력은 코드가 아니라 코드 옆의 표에 적히고, 그 표는 우리가 손대지 않아도 낡습니다.

핵심 기술 개념

모델 능력표(model profile)

모델마다 무엇을 지원하는지를 코드가 아니라 데이터로 들고 있는 표. langchain-openai 1.6.1 의 변경 목록에는 `chore(model-profiles): refresh model profile data` 가 세 번(#40217·#40171·#39954) 들어 있고, 그와 별개로 `fix(openai): correct reasoning_effort_levels for gpt-5 and gpt-5.1 profiles`(#39936)가 있다. 표의 갱신은 잡무이고 표의 오류는 결함이라는 뜻이다.

라우팅의 침묵 실패(silent routing miss)

지정한 목적지가 실제로는 적용되지 않았는데 예외도 경보도 나지 않는 실패. langchain 1.4.0 의 `fix(langchain): include model destination in agent tool routing`(#38355)이 이 유형이고, LlamaIndex 의 `default MetadataFilters condition to AND when None`(#22155)·`respect mmr_threshold=0`(#22126)도 같은 자리다 — 값을 줬는데 없는 것으로 읽힌 것이다.

지원의 유효기간(support expiry)

'이 엔진이 이 모델을 돌린다'는 사실이 영구가 아니라는 것. vLLM v0.29.0 은 Breaking Changes 에서 아키텍처 10종을 제거하고(#53608), FlexOlmo·Olmo3·Hunyuan V1/VL 을 Transformers 모델링 백엔드로 넘겼으며(#53615), 종전 엔트리포인트 `python -m vllm.entrypoints.openai.api_server` 를 폐기했다(#52131). 지원 목록은 늘기만 하지 않는다.

기술 심층 분석

능력은 코드가 아니라 표에 적힌다 — langchain-openai 1.6.1 / 1.6.2

langchain 의 OpenAI 패키지 1.6.1 변경 목록을 성격별로 갈라 보면 흥미로운 모양이 나옵니다. 기능 추가는 비동기 도구 지원과 구성 갱신 지원 둘이고, 나머지 상당수는 '모델이 무엇을 할 수 있는가'에 대한 기록을 고치는 일입니다. 모델 프로파일 데이터를 새로 받아 오는 잡무 커밋이 한 릴리스 안에서 세 번 반복되고, 그와 별개로 gpt-5 와 gpt-5.1 프로파일의 추론 노력 단계 목록이 틀렸다는 수정이 들어 있으며, 특정 모델을 응답 API 쪽으로 라우팅해야 한다는 수정도 있습니다. 바로 다음 릴리스인 1.6.2 는 변경이 세 줄뿐인데 그중 하나가 새 모델의 추론 노력 단계를 표에 추가하는 것입니다. 즉 이 라이브러리에서 '모델을 지원한다'는 말의 실체는 상당 부분 표의 항목이고, 그 표는 벤더가 모델을 낼 때마다, 그리고 기존 모델의 파라미터 규약이 바뀔 때마다 낡습니다. 여기서 중요한 것은 이 낡음이 우리 코드의 변경과 무관하게 진행된다는 점입니다. 우리가 버전을 고정해 두면 코드는 그대로지만 표도 그대로 멈추고, 벤더 쪽만 앞서 나갑니다. 표가 틀렸을 때 우리가 받는 신호는 대개 예외 스택이 아니라 제공자가 돌려준 400 한 줄입니다.

새 모델 '지원'은 두 조각으로 온다 — LlamaIndex v0.14.24

LlamaIndex 의 이번 릴리스에는 Anthropic 통합 패키지에 새 모델 지원을 추가한 항목과, 그 모델의 함수 호출을 고친 항목이 나란히 들어 있습니다. 같은 릴리스에서 두 줄로 갈라져 있다는 사실 자체가 정보입니다. 모델을 목록에 넣는 일과 그 모델의 도구 호출 규약을 맞추는 일은 다른 작업이고, 뒤엣것은 대개 실제로 호출해 본 뒤에야 드러납니다. 같은 릴리스의 코어에는 가변 위치 인자와 키워드 인자를 필수 도구 파라미터로 표시하지 않도록 고친 항목도 있습니다. 파이썬 함수 시그니처에서 도구 스키마를 자동 생성하는 경로에서는 이런 누수가 조용히 일어납니다 — 모델은 스키마가 요구하는 대로 존재하지 않는 인자를 채우려 들고, 그 결과는 실패가 아니라 그럴듯한 오호출로 나타납니다. 새 모델로 갈아탈 때 우리가 확인해야 하는 것은 '목록에 있는가'가 아니라 '도구 호출이 같은 모양으로 오는가'입니다. 앞만 보고 핀을 올리면 생성은 멀쩡한데 도구 경로에서만 어긋나고, 그 어긋남은 응답 품질 지표에 먼저 나타나지 않습니다.

지원 목록은 늘기만 하지 않는다 — vLLM v0.29.0 의 제거 목록

추론 엔진 쪽에서는 반대 방향의 사실이 나옵니다. vLLM 의 이번 릴리스는 파괴적 변경 절에서 오래 폐기 예정이던 모델 아키텍처 열 종을 실제로 제거했고, 네 개 모델군을 자체 구현 대신 Transformers 모델링 백엔드로 넘겼으며, 오랫동안 쓰이던 파이썬 모듈 실행 방식 엔트리포인트를 폐기하고 전용 명령으로 대체했습니다. 환경변수 두 개도 제거되어 명령행 인자로 옮겨갔고, 기본 러너가 새 구현으로 바뀌었습니다. 이 목록이 말하는 것은 '이 엔진이 이 모델을 돌린다'는 명제에도 유효기간이 있다는 것입니다. 자체 구현에서 공용 백엔드로 옮겨간 모델은 계속 돌아가지만 성능 특성과 지원 기능이 달라질 수 있고, 제거된 아키텍처는 그 버전에서 아예 뜨지 않습니다. 인프라를 고정 버전으로 박아 두는 조직에서는 이 변화가 업그레이드 시점에 한꺼번에 도착합니다. 그래서 의존성 갱신 계획을 세울 때 봐야 할 것은 새 기능 목록이 아니라 제거·이관 목록이고, 그 목록과 우리 모델 핀의 교집합이 비어 있는지가 실제 판정 기준입니다.

지정했는데 안 먹는다 — 라우팅이 침묵하는 자리

세 프로젝트에서 성격이 같은 수정이 반복됩니다. langchain 은 에이전트의 도구 라우팅에서 모델 목적지를 포함하도록 고쳤고, LlamaIndex 는 메타데이터 필터의 결합 조건이 지정되지 않았을 때의 기본값을 명시했으며, 유사도 임계값 0 이 '설정되지 않음'으로 읽히던 것을 고쳤습니다. 셋 다 사용자가 값을 줬는데 그 값이 적용되지 않은 유형이고, 셋 다 예외를 던지지 않습니다. 우리도 같은 형태를 밟았습니다. 생성 경로를 교체한 직후의 실측에서 협의 호출 64회와 분류 호출 10회가 경량 축이 아니라 본답변 모델로 돌고 있었는데, 원인은 호출부가 모드 인자 없이 모델 선택 함수를 부른 것이었습니다. 경량 축은 존재했고 설정도 맞았지만 아무도 그 축에 닿지 않았습니다. 이런 결함은 오류율에도 지연 시간에도 나타나지 않습니다 — 결과가 오히려 조금 더 좋아 보이기 때문에 품질 지표는 침묵하고, 신호는 청구서에만 남습니다. 라우팅을 도입할 때는 '무엇으로 갔는가'를 응답에 되싣거나 로그의 모드 이름과 실제 모델 이름을 짝지어 세는 감사를 함께 만들어야 합니다.

설정이 퍼지면 비밀도 함께 퍼진다 — vLLM 의 로그 마스킹 세 자리

같은 릴리스의 보안 절에는 눈여겨볼 항목이 있습니다. API 키와 허브 토큰을 가리는 수정이 한 건이 아니라 세 건이고, 가려야 했던 자리가 각각 다릅니다 — 서버 시작 로그, 컴파일 캐시의 팩터, 그리고 별도 프런트엔드의 실행 로그입니다. 세 자리가 따로 고쳐졌다는 것은 비밀이 한 경로로만 흐르지 않았다는 뜻입니다. 설정값은 기동 로그로도 나가고, 캐시 키를 만드는 재료로도 들어가고, 다른 언어로 쓰인 보조 프로세스의 실행 인자로도 넘어갑니다. 능력표가 데이터로 분리되는 흐름은 이 표면을 더 넓힙니다. 모델별 설정이 늘어날수록 그 설정을 찍어 보는 자리가 늘고, 그중 하나에 자격증명이 섞여 들어갑니다. 실무적으로 이 축은 '키를 로그에 찍지 말라'는 규칙 하나로 닫히지 않습니다. 닫는 방법은 규칙이 아니라 세는 것입니다 — 자격증명이 흘러갈 수 있는 표면을 열거하고, 표면마다 마스킹이 실제로 걸려 있는지 각각 확인해야 합니다. 한 자리를 고치고 나머지를 보지 않으면 '고쳤다'는 기록만 남고 유출 경로는 그대로 남습니다.

기술적 트레이드오프

긴장 관계 모델 능력표를 라이브러리 안에 두면 호출부가 단순해지지만 표는 벤더보다 늦게 갱신되고, 표를 우리 설정으로 빼면 갱신은 빨라지지만 진실이 어디 있는지 흩어진다. 어댑터를 얇게 두면 교체는 쉬워지지만 모델별 최적화를 포기해야 하고, 두껍게 두면 성능은 오르지만 교체 비용이 그만큼 어댑터에 쌓인다.

실무적 해소 '무엇이 틀렸을 때 누가 막는가'로 가릅니다. 품질 보장의 책임을 모델이 아니라 검증 계층에 두면 어댑터는 얇아도 되고, 표가 낡아 생기는 실패는 잘못된 답이 아니라 호출 실패로 떨어집니다. 반대로 검증이 모델의 판단에 기대고 있으면 표의 낡음이 곧바로 답변 품질로 새어 나가므로, 그때는 어댑터를 두껍게 하고 모델별 회귀 검사를 붙이는 비용을 치러야 합니다. 즉 어댑터 두께는 취향이 아니라 검증 계층의 강도가 정합니다.

법마디 OS에 적용한다면

법마디 OS 의 대명제는 품질 보장의 책임을 LLM 이 아니라 자산·검증 계층에 둔다는 것입니다. 검증된 자산과 국가법령정보센터 실시간 대조가 미검증 인용을 차단하므로, 생성 텍스트가 어느 모델에서 나왔든 그 계층이 같은 방식으로 막습니다. 2026-09-04 에 생성 경로를 통째로 갈아 끼울 수 있었던 근거가 그것이고, 그때 래퍼 시그니처를 그대로 유지해 호출부 열 곳이 같은 깔때기를 계속 썼습니다. 그런데 오늘 이 글을 쓰면서 우리 핀이 실제로 몇 자리인지 감사 스크립트로 세어 봤습니다. 모델 이름이 박힌 자리는 스물네 곳, 파일로는 열다섯 개입니다 — 코드 기본값과 생성 스크립트들, 그리고 워크플로 정의와 빌드 설정과 배포 스크립트에 흩어져 있습니다. 값이 하나로 일치해 있어 감사는 통과했지만, '부품 교체'의 실제 단위가 한 상수가 아니라 스물네 자리라는 사실은 그 자체로 설계 정보입니다. 라우팅의 침묵 실패도 남의 이야기가 아니었습니다. 교체 직후 실측에서 협의 예순네 번과 분류 열 번이 경량 축 대신 본답변 모델로 돌고 있었고, 원인은 호출부가 모드 인자 없이 선택 함수를 부른 것이었습니다. 그리고 오늘 새벽 배치에서는 이 기술 칼럼 자체가 품질 게이트에 걸려 발행되지 않았습니다. 잡은 초록이었고 종료 코드도 0 이었으며 커밋 제목에는 기술 칼럼이 그대로 적혀 있었습니다. 판정이 갈린 유일한 자리는 등록 대장의 그날 항목이 다섯 개뿐이라는 것이었습니다. 세 사례의 공통점은 하나입니다 — 요약 화면은 침묵했고, 대장을 세었을 때만 드러났습니다.

기술적 함의

라이브러리의 모델 능력표는 코드가 아니라 데이터다. 버전을 고정하면 코드와 함께 표도 멈추므로, 의존성 정책에는 '언제 올릴 것인가'와 별개로 '표가 낡으면 어떻게 알 것인가'가 있어야 한다. 표가 낡았을 때의 신호는 예외가 아니라 제공자의 400 이다.
새 모델 지원은 '목록에 추가'와 '도구 호출 정합' 두 조각으로 온다. 앞만 보고 핀을 올리면 생성은 멀쩡한 채 도구 경로에서만 어긋나고, 그 어긋남은 응답 품질 지표에 먼저 나타나지 않는다.
모델 핀은 한 값이 아니라 자리의 집합이다. 세어 보지 않으면 교체는 부분적으로만 일어나며, 부분 교체의 증거는 오류율이 아니라 청구서와 로그의 모델 이름에만 남는다.

"모델을 부품이라고 부를 수 있으려면 부품이 아닌 것들이 어디에 있는지를 먼저 알아야 합니다. 능력표는 코드 밖에서 낡고, 라우팅은 예외 없이 빗나가며, 핀은 한 자리가 아닙니다. 교체 가능성은 선언이 아니라 세어 본 숫자입니다."

참고 자료

칼럼니스트

지유

최고기술책임자 (CTO · Chief Technology Officer)

실리콘밸리 유니콘 창업 멤버급 / AI 무결성 검증 분야 세계적 석학급

법마디 OS 무료로 경험하기

본 칼럼은 법마디 OS 기술팀의 관점이며, 특정 제품·기술에 대한 보증이나 법률 자문이 아닙니다.