Executive Summary

편집자의 노트. 이 글은 모델 신원의 계보를 다룬다. 학습 데이터 쪽의 계보 공백을 짚은 MAI 모델의 데이터 조달 계보와 짝을 이루지만 층이 다르다. 그 글이 모델에 들어간 것의 출처를 물었다면, 이 글은 지금 응답하는 것의 신원을 묻는다. EU AI법 일정과 조항 해석은 2026년 8월 2일에 실제로 무엇이 켜졌나를 따른다.

네 수치가 문서와 산출물 사이의 간극을 잰다

앞의 두 수치는 공개의 양과 검증의 부재가 어디서 갈라지는지 말해 준다. 셋째는 외부인이 그 부재를 직접 재려 할 때 무엇이 막는지, 넷째는 이름과 산출물이 얼마나 멀어질 수 있는지 보여준다. 분모는 문항이 적용되는지에 따라 37점과 35점으로 갈리고, 그 차이가 최상위 순위를 뒤바꾼다.

출처: Abraham, S., & Bucknall, B. (2026), Silent Updates: Measuring and Closing the Post-Deployment Disclosure Gap, arXiv:2608.11803v1. 모든 수치는 논문이 밝힌 표본 16곳(1차 제공자 9곳 + 호스트 7곳) 기준이며 저자들 스스로 예비 결과로 표기했다.

2026년 8월 12일 arXiv에 올라온 Silent Updates: Measuring and Closing the Post-Deployment Disclosure Gap은 Sophia Abraham과 Ben Bucknall이 쓴 cs.CY 분류 논문이고, AI 윤리·사회 학회 AIES-26에 채택됐다. 저자들은 결과를 예비적(preliminary)이라고 직접 표기했다. 이 글의 모든 수치는 그 v1 본문과 초록에서 확인한 것이다.

논문이 출발점으로 삼는 사실은 단순하다. 배포된 파운데이션 모델은 고정된 시스템이 아니다. 사업자는 모델을 내린 적도, 새 이름을 붙인 적도 없이 그 행동을 바꿀 수 있다. 초록은 그 경로를 다섯 가지로 꼽는다. 각각이 무엇을 건드리는지 보면, 왜 버전 번호가 이 변화를 잡아내지 못하는지가 드러난다.

경로의 명칭과 순서는 arXiv:2608.11803v1 초록 원문을 따랐다. 오른쪽 두 열은 각 경로가 실무에서 어떻게 관측되는지를 정리한 것이다.

다섯 경로의 공통점은 모델 식별자를 건드리지 않는다는 점이다. API 호출에 적는 문자열은 그대로고, 청구서에 찍히는 이름도 그대로다. 왼쪽에서 무엇이 바뀌든, 가운데 이름은 움직이지 않는다.

1.1논문이 말하는 “조용히”는 세 가지가 동시에 없는 상태다

논문이 쓰는 silently는 “몰래”라는 정서적 표현이 아니고, 세 가지 부재가 겹친 상태를 가리키는 조작적 정의다. 공개 고지가 없고, 버전 번호 증가가 없고, 재평가가 없다. 셋 중 하나라도 있으면 외부 관측자가 붙잡을 실마리가 남는다. 셋이 모두 없을 때만 변경은 외부에서 사실상 존재하지 않는 일이 된다.

이 정의가 중요한 이유는 비난의 대상을 좁혀 주기 때문이다. 사업자가 모델을 개선하는 것은 문제가 아니다. 문제는 개선의 사실이 외부 기록에 아무 흔적도 남기지 않는 배포 관행이다. 논문의 표현을 그대로 옮기면, 이런 변경은 평가 결과나 시스템 카드가 가리키는 모델과 사용자에게 서빙되는 모델을 잇는 외부에서 검증 가능한 관리 연속성이 존재한다는 거버넌스의 핵심 가정을 흔든다.

1.2같은 이름이 다르게 답한다는 계측은 2023년에 이미 나왔다

이 문제가 이번에 처음 제기된 것은 아니다. 2023년 7월, 스탠퍼드와 UC 버클리의 Lingjiao Chen, Matei Zaharia, James Zou가 같은 이름의 상용 API가 몇 달 사이에 다르게 행동한다는 것을 How is ChatGPT’s behavior changing over time?에서 계측했다.

가장 널리 인용된 수치는 소수 판별 과제의 정확도다. GPT-4는 2023년 3월에 84%를 기록했고 6월에 51%로 내려갔다. 저자들은 원인의 일부를 사고 연쇄 프롬프트를 따르려는 성향의 저하로 설명했다. 다만 흔한 오독이 하나 있다. 같은 과제에서 GPT-3.5는 3월보다 6월에 더 좋아졌다. 방향은 모델마다 갈렸다. “모델은 시간이 지나면 나빠진다”가 아니라 “같은 이름의 서비스가 짧은 기간에 상당히 달라질 수 있다”가 그 논문의 결론이다. 두 모델 모두에서 코드 생성의 포맷 오류가 늘었고, GPT-4는 민감한 질문과 여론조사 문항에 답하려는 의향이 낮아졌다.

그 논문이 결론에 적은 문장은 이렇다. 같은 이름의 LLM 서비스가 비교적 짧은 기간에 상당히 달라질 수 있으며, 그래서 LLM에 대한 지속적 모니터링이 필요하다. 계측을 한 번의 벤치마크가 아니라 상시 장치로 두어야 한다는 주장은 이때 이미 나와 있었다.

3년 전 논문이 “바뀐다”를 계측했다면, 이번 논문은 축을 옮겼다. 행동 변화를 재는 대신 사업자가 그 변화를 어떻게 공개하는지를 잰다. 앞의 연구가 밖에서 두드려 본 것이라면, 이번 연구는 안에서 문이 열려 있는지를 센 것이다.

1.3가중치가 바뀔 수 있다고 사업자 문서가 이미 적어 두었다

무통보 변경이 추측이 아니라는 증거는 사업자 문서 안에 있다. 마이크로소프트 Foundry의 모델 수명주기 문서는 프리뷰 단계를 이렇게 정의한다. “Experimental. Weights, runtime, and API schema might change.” 실험적이며, 가중치와 런타임과 API 스키마가 바뀔 수 있다는 뜻이다. 같은 이름 아래에서 가중치가 교체될 수 있다는 사실을 호스트가 공식 문서에 적어 둔 것이다.

이것을 부정직함으로 읽으면 논점을 놓친다. 문서는 정직하다. 문제는 그 정직한 고지를 받은 사용자가 실제로 언제 바뀌었는지 확인할 방법을 함께 받지 못한다는 데 있다. “바뀔 수 있다”는 예고와 “바뀌었다”는 기록 사이의 거리가 이 논문이 재려는 간극이다.

1.4시스템 카드가 어느 스냅샷을 평가했는지 밝히지 않는다

논문이 든 1차 제공자 사례 하나가 이 절의 착지점이다. GPT-5 시스템 카드는 평가 대상을 gpt-5-thinking과 gpt-5-main으로 지칭한다. 그런데 논문의 지적은 이렇다. 그 시스템 카드는 어느 스냅샷이 평가된 배포에 해당하는지 명시하지 않는다. 평가는 실제로 수행됐고 문서도 공개됐다. 다만 그 문서를 읽은 사람이 지금 자기 API 호출이 그 평가 대상과 같은 것인지 확인할 길이 없다.

앞서 다룬 문제와는 층이 다르다. 닫힌 모델로 하는 과학의 재현성에서는 단일 사업자의 모델이 닫혀 있어 연구를 재현할 수 없다는 점을 다뤘다. 이번 논문은 그 문제를 개별 사업자의 정책이 아니라 16곳 규모의 공개 관행 계측으로 옮긴다. 닫혀 있느냐 열려 있느냐가 아니라, 열어 놓은 문서가 실제 산출물과 연결되느냐를 묻는 것이다.

문제를 지적하는 논문과 계측하는 논문은 무게가 다르다. 이 논문의 기여는 무통보 업데이트가 있다는 주장이 아니라, 사업자들이 그 변경을 얼마나 공개하는지를 채점 가능한 형태로 만든 데 있다. 저자들은 그 도구를 Silent Updates Scorecard(무통보 업데이트 스코어카드)라 부르고 공개 도구로 내놓았다.

척도는 29개 문항을 7개 영역으로 묶는다. 이진 문항은 0점 또는 1점, 수치 문항은 채점 지침의 임계값에 따라 0에서 3점까지 구간으로 배점된다. 1차 제공자에게 적용되는 최대 점수는 37점이다. 어느 영역이 몇 문항인지를 보면 이 척도가 무엇을 중요하게 보는지가 드러난다.

출처: arXiv:2608.11803v1. 영역 표기는 논문의 문항 번호 접두어를 따랐다. 문항별 개별 배점표는 논문 부록에 있고, 이 글에서는 재현하지 않는다.

7개 영역 중 가장 많은 문항이 걸린 곳이 안전성 평가 추적성이다. 문서가 있는지를 묻는 영역이 아니라, 그 문서가 실제로 서빙되는 버전에 붙어 있는지를 묻는 영역이다. 이 배분 자체가 논문의 논지를 드러낸다.

2.1분모가 35인 사업자가 둘 있다

점수표의 분모는 사업자마다 같지 않다. X 영역의 두 문항은 API와 챗봇을 함께 운영하는 사업자에게만 적용된다. 비교 가능한 챗봇 표면이 없는 사업자에게는 해당 없음으로 처리되고, 그만큼 최대 점수가 줄어든다. 논문 표의 캡션도 적용 가능한 최대점 기준으로 정규화했다고 밝힌다.

표본에서 Cohere와 AI21이 이 경우다. 두 곳의 분모는 37이 아니라 35다. 사소한 각주처럼 보이지만 결과의 순위를 뒤집는다.

2.2투명성 지수가 재던 것과 이 척도가 재는 것

이 척도에는 방법론적 조상이 있다. 스탠퍼드 CRFM의 Foundation Model Transparency Index(FMTI)다. 100개 지표로 개발사를 채점해 왔고, 세 판본의 결과는 아래와 같다.

출처: Stanford CRFM, Foundation Model Transparency Index. 2025년 12월 판 평균은 CRFM 1차 페이지 기준 41점이다. 일부 2차 요약에는 40으로 적힌 사례가 있다.

점수가 오르고 내린 이유보다 중요한 것은 두 척도가 서로 다른 질문을 한다는 점이다. FMTI는 개발사가 제출한 투명성 보고서를 근거로 “공개했는가”를 채점한다. 공개된 주장의 진위를 독립적으로 검증하지는 않는다. v1.1에서 평균이 크게 오른 것도 상당 부분 그 과정에서 개발사들이 새로 내놓은 정보 덕분이었다. 저작권 지위, 데이터 접근, 데이터 노동, 다운스트림 영향은 판본이 바뀌어도 계속 어두운 영역으로 남았다.

Silent Updates Scorecard는 그 위에 한 층을 얹는다. 공개된 문서가 지금 서빙되는 산출물과 연결되는가를 묻는다. 투명성 점수가 37에서 58로 올랐다가 41로 내려가는 동안, 이 층은 한 번도 계측된 적이 없었다.

2.30점이 나온 두 문항의 원문

“0/9”라는 숫자가 무엇을 뜻하는지는 문항 두 개의 원문에 적혀 있다.

• M2: “Can the deployed API model be mapped to a published safety evaluation using publicly available information?” 공개된 정보만으로 배포된 API 모델을 공개된 안전성 평가에 대응시킬 수 있는가.
• M6: “Is the content or usage policy explicitly linked to specific model versions?” 콘텐츠 정책 또는 이용 정책이 특정 모델 버전에 명시적으로 결속되어 있는가.

두 문항 모두 표본 9곳 전부에서 충족되지 않았다. 첫째 문항이 0점이라는 것은 안전성 평가가 없다는 뜻이 아니다. 평가는 있는데 그것이 지금 응답하는 모델을 가리키는지 확인할 방법이 없다는 뜻이다. 둘째 문항이 0점이라는 것은 “이 모델은 이런 용도로 쓰지 마라”는 약속이 특정 버전에 붙어 있지 않다는 뜻이다. 모델이 조용히 바뀌면 그 약속이 여전히 유효한지도 함께 흐려진다.

결과의 핵심은 총점이 아니라 비대칭이다. 문서의 존재를 묻는 문항에서는 대부분의 사업자가 점수를 받았고, 문서와 산출물의 연결을 묻는 문항에서는 거의 아무도 받지 못했다. 같은 사업자, 같은 척도 안에서 두 종류의 문항이 이렇게 갈린다.

위쪽 세 문항은 사업자들이 이미 잘하고 있는 영역이다. 아홉 곳 중 여덟 곳이 전용 체인지로그 페이지를 운영하고, 일곱 곳이 정량 안전성 지표를 공개하고, 여섯 곳이 버전 간 안전 관련 행동 차이를 서술한다. 아래쪽으로 내려갈수록 숫자가 급격히 줄어든다. 평가된 모델 버전을 모델 카드에 정확히 명시한 곳은 한 곳이었다. Anthropic이다. M1은 이진 문항이라 부분 점수가 없다.

3.1논문이 이름 붙인 네 가지 실패 유형

논문은 이 비대칭이 어떤 형태로 나타나는지를 네 가지 유형으로 정리한다. 각각을 문항 결과와 함께 읽으면 무엇이 부족한지가 구체적으로 잡힌다.

네 유형은 앞 절의 문항 결과와 하나씩 짝이 맞는다. 첫째 유형은 M1의 1/9과 이어진다. 날짜가 붙은 스냅샷 이름을 지정할 수 있는 사업자는 여럿인데, 평가된 버전을 모델 카드에 정확히 적어 둔 곳은 한 곳이었다. 둘째 유형은 C1의 8/9과 대비해서 읽어야 한다. 체인지로그 페이지는 거의 모두 갖췄지만, 그 페이지가 출시를 기록하는 신뢰도와 행동 변화를 기록하는 신뢰도는 같지 않다. 넷째 유형은 M2의 0/9이 그대로 옮겨진 것이다. 셋째 유형에만 사업자 수를 붙이지 않았다. 표면 간 일치를 묻는 두 문항은 API와 챗봇을 함께 운영하는 사업자에게만 적용되고, 이 글이 확인한 범위에는 그 영역의 사업자별 충족 수가 포함되지 않았다.

3.2순위는 기준에 따라 1위가 바뀐다

사업자별 총점은 아래와 같다. 표를 읽을 때 분모 열을 함께 봐야 한다. 앞서 짚었듯 Cohere와 AI21은 챗봇 표면 문항이 적용되지 않아 분모가 35다.

출처: arXiv:2608.11803v1. 원 논문 표는 원점수 기준으로 정렬되어 있고, 적용 문항 대비 비율은 그 캡션의 정규화 방식을 따라 계산했다. 평균 16.4점은 원점수 단순평균(148÷9)이고, 44.4%는 각 사업자의 적용 가능한 최대점을 기준으로 논문이 직접 밝힌 값이다.

원점수로는 OpenAI가 1위, 적용 문항 대비 비율로는 Cohere가 1위다. 두 기준이 1·2위를 뒤바꾼다. 순위를 인용할 때 어느 기준인지 밝히지 않으면 곧바로 틀린 문장이 된다. 그리고 어느 기준으로 봐도 최고점이 62%대에 머문다는 사실이 더 중요하다. 이 표는 잘한 사업자와 못한 사업자를 가리는 성적표라기보다, 잘한 쪽조차 3분의 1 이상을 비워 둔 지형도다.

3.3이름은 그대로, 산출물은 열 번 바뀐 사례

논문이 든 가장 선명한 사례는 DeepSeek의 deepseek-chat 식별자다. 논문의 표현을 옮기면, 이 식별자는 안정적으로 유지된 반면 그 아래 서빙되는 산출물은 19개월에 걸쳐 문서화된 열 번의 릴리스를 거쳐 바뀌었다. 2024년 5월의 V2 계열에서 시작해 V2.5, V3, V3.1, V3.2 계열까지 이어진다.

이 사례의 출처가 중요하다. 논문이 몰래 알아낸 것이 아니라 DeepSeek 자신이 공개한 릴리스 노트를 시계열로 재구성한 것이다. 즉 기록이 없어서 생긴 문제가 아니다. 기록은 있었고, 그 기록이 사용자가 호출하는 식별자와 결속되지 않았을 뿐이다. 체인지로그를 운영한다는 사실과 그 체인지로그로 지금 내 요청이 무엇을 만나는지 알 수 있다는 사실은 서로 다른 이야기다.

3.4약관이 외부 계측을 막는다

사업자가 고리를 열지 않으면 외부에서 직접 재면 될 것 같다. 그런데 그 길에도 문턱이 있다. T2 문항은 이용약관이 벤치마킹과 그 결과의 공표를 허용하는지 묻는다. 아홉 곳 중 세 곳만 허용했다. 나머지 여섯 곳은 명시적인 벤치마킹 조항이나 더 넓은 경쟁 제품 관련 조항으로 이를 제약한다.

논문이 인용한 조항 문구를 보면 제약의 형태가 드러난다. Cohere 약관에는 “for any other benchmarking or competitive purposes”라는 표현이 있고, Together AI 약관에는 “competitive analysis or benchmarking”이 있다. OpenAI, Anthropic, Google, Mistral, xAI의 경우는 벤치마킹을 직접 지목한 조항이 아니라 경쟁 제품 개발을 금지하는 더 넓은 조항이 근거가 된다.

사업자는 문서와 산출물을 잇는 고리를 공개하지 않고, 그 고리를 외부에서 재려는 시도는 약관이 제약한다. 검증의 부재가 우연이 아니라 두 겹으로 닫혀 있다는 뜻이다.

실무에서 모델을 직접 1차 제공자에서 받는 조직은 오히려 적다. 클라우드 플랫폼이나 추론 호스트를 한 겹 거치는 경우가 흔하다. 그 경우 모델의 신원은 두 손을 거쳐 도착한다. 논문은 서드파티 추론 호스트 7곳을 별도의 4문항 척도로 평가했다.

출처: arXiv:2608.11803v1. 호스트 척도는 1차 제공자의 29문항과 별개로 설계됐다.

결과는 7곳 중 여섯 곳이 4점 중 3점, Fireworks AI가 2점이었다. 논문은 Fireworks AI에 대해 수명주기와 배포 공개에 공백이 있다고 적었다. 이 점수를 1차 제공자의 44.4%와 비교하면 틀린다. 문항 집합 자체가 다르다. 1차 척도는 평가 문서와 배포의 연결을 주로 묻고, 호스트 척도는 배포 구현의 투명성을 묻는다. 호스트가 더 투명하다는 결론은 이 데이터에서 나올 수 없다.

4.1같은 모델 이름이 호스트마다 다른 수명을 갖는다

호스트 계층이 좌표를 하나 더 늘린다는 사실은 사업자 문서가 직접 밝히고 있다. Anthropic의 모델 폐기 문서에는 파트너 운영 플랫폼, 곧 Amazon Bedrock과 Google Cloud가 자체 은퇴 일정을 정한다는 문장이 있다. 따라서 모델의 수명주기 상태와 날짜가 플랫폼에 따라 달라질 수 있다고 문서는 덧붙인다.

실무에서 이 문장의 의미는 분명하다. 조직 안에서 “우리는 이 모델을 씁니다”라고 합의했더라도, 어느 호스트를 거치는지에 따라 그 모델이 언제까지 존재하는지가 달라진다. 모델 이름은 조달 문서에 한 줄로 적히지만 그 이름만으로는 좌표가 확정되지 않는다.

신원 정보는 1차 제공자에서 사용자에게 닿는 사이 어디선가 끊긴다. 왼쪽에서 오른쪽으로 갈수록 확정되는 정보가 줄어든다.

4.2버전 고정은 이미 제품 기능으로 존재한다

호스트 계층을 부정적으로만 볼 이유는 없다. 오히려 통제 장치를 가장 구체적으로 문서화한 쪽이 호스트다. 마이크로소프트 Foundry의 모델 수명주기 정책을 보면 그렇다. 정식 공급 모델은 출시 시점에 18개월 뒤 은퇴일이 프로그램적으로 설정되고, 그 날짜를 Models API로 조회할 수 있다. 12개월째에 폐기 단계로 들어가 신규 고객 접근이 차단되고, 18개월째 은퇴 이후의 모든 추론 요청은 410 Gone을 받는다. 통보 기준은 정식 공급 모델 60일 이상, 프리뷰 30일 이상이며 이메일과 서비스 상태 알림 채널을 함께 쓴다.

더 눈에 띄는 것은 자동 업그레이드를 끄는 선택지가 문서화되어 있다는 점이다. 표준 계열 배포는 리전별 롤링으로 자동 업그레이드되지만, 배포의 versionUpgradeOption을 새 기본 버전이 나올 때 올리기, 현재 버전이 만료될 때 올리기, 자동 업그레이드 없음 가운데 하나로 설정할 수 있다. 그리고 예약 용량 배포는 자동 업그레이드 대상에서 제외된다. 즉 버전을 붙잡아 두는 기능은 이미 제품 안에 있다.

자동 업그레이드가 실무에서 어떤 모습인지는 같은 문서의 예시가 보여준다. gpt-4o의 2024년 5월 13일 버전이 2026년 10월 1일에 은퇴할 때, 표준 SKU 배포는 gpt-5.1로 자동 업그레이드된다. 배포 설정을 손대지 않으면 어느 날부터 다른 모델이 응답한다는 뜻이다. 설정을 바꿀 수는 있다. 다만 바꾸지 않았을 때의 기본값이 교체라는 사실은 조달 문서에 잘 적히지 않는다.

비대칭은 다른 곳에 있다. 프리뷰 등급 모델에는 그 선택지가 없다. 문서는 은퇴하는 프리뷰 모델에 계속 머무를 방법이 없다고 명시한다. 파트너 모델의 수명주기도 차등이 있다. Anthropic, DeepSeek, Fireworks, Mistral AI의 정식 공급 모델은 표준 18개월이 아니라 12개월 주기를 따른다. 정부 클라우드는 한 번에 한 버전만 지원하고 새 버전이 나오면 30일 중첩 기간을 둔다. 보안이나 컴플라이언스 사유의 긴급 은퇴 권한도 명시되어 있다.

4.3고정됐다는 약속은 문서에 있고, 확인할 방법은 없다

같은 문서에서 논문의 논지가 가장 선명해지는 대목이 나온다. 정식 공급 단계의 정의가 이렇다. “Production-ready. Weights and APIs are fixed. Runtime patches for security vulnerabilities don’t affect outputs.” 프로덕션에 쓸 수 있고, 가중치와 API가 고정되며, 보안 취약점에 대한 런타임 패치는 출력에 영향을 주지 않는다는 뜻이다.

이것은 드문 문서다. 행동 안정성을 호스트가 명시적으로 약속한 사례이기 때문이다. 그런데 그 약속을 외부에서 확인할 수단은 함께 제공되지 않는다. 사용자는 문장을 신뢰할 수 있을 뿐이다. 논문이 재려던 간극이 정확히 이 자리에 있다. 문제는 사업자가 거짓을 말한다는 것이 아니라, 참인지 거짓인지 확인할 방법이 외부에 없다는 것이다.

같은 문서에 작은 증거가 하나 더 있다. 문서와 포털에서 Deprecated로 표시되는 상태가 API에서는 Deprecating이고, API의 Deprecated는 은퇴가 이미 완료된 상태를 뜻한다. 수명주기 상태라는 가장 단순한 메타데이터조차 표면마다 다르게 읽힌다.

4.4불변 스냅샷 결속은 가설이 아니라 이미 돌아가는 기능이다

논문이 직접 강조한 반례가 있다. Replicate다. 논문의 표현으로는 표본에서 관측된 가장 강한 스냅샷 결속 수단을 제공한다. 각 배포가 콘텐츠 해시로 식별되고, 해시로 식별된 과거 버전을 API로 계속 조회할 수 있다. 실제 API 문서를 보면 소유자와 모델 이름에 64자 버전 식별자를 더해 특정 버전을 지목하고, 그 버전을 조회하거나 실행할 수 있다.

저자들이 덧붙인 문장이 이 절의 결론이다. 이 사례의 의미는 Replicate 자체보다 넓다. 불변 스냅샷 결속은 가설적 인프라가 아니라 이미 프로덕션 시스템에 존재한다. 기술이 없어서 계보가 없는 것이 아니라, 대부분이 그것을 노출하지 않기로 선택한 것이다.

논문은 진단에서 멈추지 않는다. 다만 처방이 “모든 변경을 공개하고 매번 재평가하라”는 요구는 아니다. 그런 요구는 실무에서 지켜지지 않는다. 대신 저자들은 Three-Part Behavioral Trigger System(3부 행동 트리거 체계)을 제안한다. 변경의 성격에 따라 발동되는 의무의 무게를 달리하는 설계다.

출처: arXiv:2608.11803v1. 저자들은 제시된 수치 임계값이 예시일 뿐이라고 명시하며, 임계값을 어디에 둘지의 문제는 이 논문에서 해결하지 않는다고 밝혔다.

설계의 요점은 무게 배분이다. 시스템 프롬프트를 한 줄 고친 것과 모델이 이전에 없던 능력을 얻은 것에 같은 절차를 요구하면 체계가 무너진다. 앞의 것에는 로그 공개를, 뒤의 것에는 전면 재평가를 붙인다. 다만 논문은 그 숫자를 확정하지 않았다. 저자들은 수치 임계값을 예시로만 제시했다. 이 표를 규제 초안처럼 읽으면 논문이 하지 않은 주장을 얹는 셈이 된다.

무게를 갈라야 하는 실무적 이유도 있다. 전면 재평가는 공짜가 아니다. 상업 감사 견적을 기준으로 보면 외부 레드티밍 한 차례가 수천에서 수만 달러대이고, 여러 위험 영역을 묶은 종합 엔게이지먼트는 십만 달러대까지 올라간다. 반면 API 접근으로 돌리는 경량 회귀 모니터링은 수백 달러대에서 시작한다. 견적 단가는 벤더와 범위에 따라 크게 달라지므로 여기서는 자릿수 대조로만 읽는 편이 안전하다. 모든 변경에 전면 재평가를 요구하는 설계가 실무에서 지켜지지 않는 이유, 그리고 가벼운 변경에는 로그 공개만 붙이는 설계가 현실적인 이유가 이 자릿수 차이에 있다.

5.1통보 기준은 이미 사업자마다 다르다

트리거 체계가 채우려는 공백이 어디인지는 현행 공개 정책을 나란히 놓으면 잡힌다. 폐기와 은퇴에 대해서는 사업자들이 이미 성문화된 기준을 갖고 있다. 다만 그 기준이 서로 다르고, 모두 예외 조항을 품고 있다.

각 사업자의 공식 정책 문서에서 2026년 8월 14일 확인. 표의 기간은 폐기·은퇴 통보에 대한 기준이며, 모델 행동 변경의 통보 기준이 아니다.

이 기준들은 모델이 내려갈 때의 통보 기간이다. 모델이 자리에 그대로 있으면서 행동이 달라질 때 며칠 안에 알려야 한다는 기준은 어느 사업자에게도 없다. 폐기는 성문화됐고 변경은 성문화되지 않았다. 3부 트리거가 겨냥하는 공백이 그 자리다.

통보 기간의 숫자보다 눈여겨볼 것은 그 숫자를 예고하는 방식이다. Anthropic은 모델의 수명주기를 활성, 레거시, 폐기, 은퇴 네 단계로 나누고, 아직 활성인 모델에도 잠정 은퇴일을 미리 적어 둔다. 표기 형식이 “이 날짜보다 이르지는 않다”다. 확정일이 아니라 하한을 공표하는 방식이라, 이용자는 최악의 경우를 기준으로 이행 계획을 세울 수 있다. 폐기 계층에서는 이렇게 좌표가 미리 주어진다. 같은 사업자도 모델 행동이 달라지는 일에 대해서는 이런 하한을 공표하지 않는다.

공정하게 짚을 대목도 있다. Anthropic의 폐기 이력 표에 실린 아홉 건의 공지에서 통보부터 은퇴까지의 간격을 계산하면 60일에서 189일 사이에 있고, 최솟값이 정확히 공표 기준인 60일이다. 이력상 자기 기준을 어긴 사례가 없다. 같은 문서는 폐기의 부작용도 직접 인정한다. 연구자가 진행 중인 비교 연구에서 모델 접근을 잃는다는 문장이 들어 있고, 모델 가중치를 장기 보존하겠다는 약속도 함께 적혀 있다. 정책과 집행이 일치한 사례는 표본 안에서 이렇게 확인된다.

5.2규제는 문서를 요구하지만 대응을 요구하지 않는다

2026년 8월 2일에 EU AI법에서 무엇이 켜졌는지는 정확히 구분해야 한다. 이날 발효된 것은 Article 50의 투명성 의무와 Article 101의 범용 AI 모델 관련 집행권이다. 벌금 부과, 기술 평가, 시장 철수 명령이 여기 속한다. 집행위원회는 앞서 7월 20일에 Article 50 시행 가이드라인을 채택했다. 제재 상한은 전 세계 연매출 3% 또는 1,500만 유로 중 큰 금액이다.

흔한 오해를 정리하면, 범용 AI 모델에 대한 의무 자체는 2025년 8월 2일부터 이미 존재했다. 8월 2일을 의무 신설일로 쓰면 부정확하다. 그 이전에 출시된 모델에는 2027년 8월 2일까지 준수 유예가 적용된다. 자세한 일정과 조항 해석은 EU AI법 2026년 8월 마감의 실제에서 정리했다.

이 글의 질문으로 돌아오면 답은 이렇다. 규제는 문서 제출 의무를 확대했다. 그런데 제출된 문서가 실제 서빙 산출물과 대응하는지 검증하도록 요구하는 조항은 없다. 감사 앞에 놓이는 것은 문서이고, 그 문서가 어느 산출물을 가리키는지는 여전히 사업자가 공개하기로 선택한 범위 안에 있다.

5.3한계를 적은 문장이 그대로 논증이 된다

논문의 한계를 숨기지 않는 것이 이 보고서의 신뢰도에 직결된다. 채점은 공개 문서와 표준 API 접근을 사용해 단일 채점자가 수행했다. 완성된 스코어카드는 이후 독립적인 증거 감사를 거쳤지만, 채점자 간 신뢰도의 공식적 측정은 후속 과제로 남았다고 저자들은 밝힌다. 결과도 예비적이라고 표기했다. 표본은 16곳이므로 “업계 전체에 검증 수단이 없다”로 확장하면 논문이 하지 않은 말이 된다.

그런데 저자들이 적은 또 하나의 한계는 성격이 다르다. 측정 범위가 사업자가 공개 API와 문서를 통해 노출하는 것에 갇힌다는 점을 인정하면서, 저자들은 이렇게 덧붙인다. 그 제약은 연구의 흠이 아니라 연구가 다루는 문제의 일부다. 외부 거버넌스 장치는 사업자가 공개하기로 선택한 정보에만 의존할 수 있다. 한계 서술이 그 자체로 핵심 논증이 되는 흔치 않은 문장이다.

페블러스는 데이터가 모델에 들어가기 전 상태를 다룬다. 그래서 이 논문의 발견이 남의 계층 이야기로 들리지 않는다. 데이터 쪽에서 오래 씨름해 온 문제가 모델 쪽에서 같은 모양으로 반복되고 있기 때문이다. 스탠퍼드 AI Index 2026에 따르면 최소 한 개 업무 기능에서 AI를 쓰는 조직은 88%인데 어느 한 기능이라도 완전히 스케일한 조직은 10%에 못 미친다. 표본과 방법론이 이 논문과 다르므로 나란히 놓을 수치는 아니지만, 도입은 넓고 정착은 얕은 지형에서 모델의 신원 문제가 어떻게 실무 리스크가 되는지를 가늠하는 배경으로는 읽어 둘 만하다.

6.1데이터 계층은 이 문제를 해시와 버전 핀으로 답했다

데이터 카탈로그를 운영해 본 조직은 이 논문의 구조를 곧바로 알아본다. 카탈로그에 항목이 적혀 있다는 사실은 감사에 대한 답이 되지 못한다. 감사가 묻는 것은 목록의 존재가 아니라 목록의 그 항목이 지금 쓰이는 그 데이터라는 증명이다. 데이터 계층은 그 질문에 콘텐츠 해시, 버전 핀, 리니지 기록으로 답해 왔다. 완벽하지는 않아도 대응 관계를 외부에서 확인할 수 있는 형태로 남기는 관행이 자리 잡았다. 모델 계층에는 아직 그 답이 없다. Replicate의 64자 버전 식별자가 보여주는 것은 답이 기술적으로 어렵지 않다는 사실이다.

6.2드리프트를 계측하는 사상은 데이터에서 모델로 이어진다

DataClinic이 데이터셋의 드리프트를 계측하는 이유는 데이터가 나빠질 것을 예상하기 때문이 아니라, 나빠졌는지 여부를 주장이 아니라 기록으로 판정하기 위해서다. 모델 계층의 무통보 변경도 같은 방식으로만 다뤄질 수 있다. 사업자가 바뀌지 않았다고 말하는 것과 우리 쪽 회귀 배터리가 같은 지문을 내놓는 것은 다른 종류의 증거다.

Physical AI에서는 문제가 더 날카로워진다. 로봇의 행동 정책이 호출하는 시각 언어 모델이 조용히 바뀌면, 그 로봇에 대해 축적한 안전 검증 이력 전체의 근거가 흔들린다. 데이터를 만진 모델의 좌표를 남기는 일이 실험 노트의 문제가 아니라 안전 문서의 문제가 되는 지점이다. 학습 데이터 조달 쪽의 같은 공백은 MAI 모델의 데이터 조달 계보에서, 에이전트가 남기는 기록의 삭제 문제는 에이전트 메모리의 계보와 삭제에서 각각 다뤘다.

6.3지금 확인할 수 있는 세 층의 체크리스트

사업자가 고리를 열어 주기를 기다리는 것 말고 지금 할 수 있는 일이 있다. 아래 항목은 모두 앞 절에서 1차 문서로 확인한 사실에서 도출한 것이다. 조달, 계약, 운영의 세 층으로 나눠 정리했다.

계약 층의 두 번째 항목이 실무에서 가장 자주 빠진다. 통보 기간의 숫자는 조달 문서에 적히지만, 그 숫자를 무력화하는 예외 조항은 대개 읽히지 않는다. 앞서 본 세 사업자의 정책에는 모두 안전이나 컴플라이언스 사유의 단축 조항이 들어 있다. 그 조항이 부당하다는 뜻이 아니다. 60일을 전제로 세운 이행 계획이 실제로는 훨씬 짧은 기간에 실행될 수 있다는 사실을 알고 계획을 세워야 한다는 뜻이다.

6.4계측을 자기 쪽에 두는 조직만 답을 갖는다

이 논문이 조직에 남기는 실질적 결론은 방어적이다. 문서와 산출물의 대응을 사업자가 열어 주지 않는 동안, 그 대응을 짐작이 아니라 기록으로 다룰 수 있는 조직은 계측을 자기 쪽에 둔 조직뿐이다. 응답 지문을 남기고, 모델 식별자와 출력을 묶어 보관하고, 회귀 배터리를 상시로 돌리는 일은 사업자의 협조 없이도 할 수 있다. 데이터 품질 진단이 오래 해 온 일과 같은 작업이며, 대상이 데이터셋에서 서빙 엔드포인트로 옮겨간 것뿐이다.

편집자의 노트. 페블러스는 데이터 품질과 계보를 계측하는 도구를 만든다. 이 글에서 정리한 세 층의 체크리스트는 그 사상을 모델 서빙 계층에 적용해 본 것이고, 우리 제품이 지금 그 계층을 전부 덮는다는 주장은 아니다. 관련 논의는 데이터 조달 계보와 EU AI법 리포트에 이어 두었다.

이 글의 논문 관련 수치는 모두 1차 출처인 arXiv:2608.11803v1에서 확인했다. 사업자 정책에 관한 서술은 각 사업자의 공식 문서를 2026년 8월 14일에 직접 읽고 정리한 것이다. 아래는 그 1차 출처, 선행 계측과 방법론적 조상이 되는 학술 문헌, 규제 조항, 그리고 같은 주제를 다룬 페블러스의 인접 글이다.

1차 출처

• 1.Abraham, S., & Bucknall, B. (2026). Silent Updates: Measuring and Closing the Post-Deployment Disclosure Gap. arXiv:2608.11803v1 [cs.CY], 2026-08-12. Accepted to AIES-26.

선행 계측·방법론 (학술)

• 2.Chen, L., Zaharia, M., & Zou, J. (2023). How is ChatGPT’s behavior changing over time? arXiv:2307.09009 (v1 2023-07-18, v3 2023-10-31).
• 3.Stanford CRFM. Foundation Model Transparency Index (2023-10 v1.0 / 2024-05 v1.1 / 2025-12).
• 4.Stanford HAI. (2026). AI Index Report 2026. 6장 맥락 수치(업무 기능 도입률과 완전 스케일 비율).

정책·규제

• 5.EU 인공지능법(Regulation (EU) 2024/1689). Article 50(투명성 의무), Article 99(제재), Article 101(범용 AI 모델 제공자에 대한 벌금), Article 111(3)(기존 출시 모델 유예).
• 6.유럽집행위원회. (2026-07-20). Article 50 투명성 의무 시행 가이드라인.

사업자 공식 문서

• 7.OpenAI. Deprecations. 2026-08-14 확인.
• 8.Anthropic. Model deprecations. 2026-08-14 확인. 통보 간격 60~189일은 이 문서의 폐기 이력 표에서 산출.
• 9.Microsoft. Foundry Models lifecycle and support policy. 2026-08-14 확인.
• 10.Replicate. HTTP API reference. 64자 버전 식별자와 버전별 조회 엔드포인트. 2026-08-14 확인.

페블러스 인접 글

• 11.페블러스. EU AI법 2026년 8월 마감의 실제. 이 글의 규제 서술이 따르는 기준.
• 12.페블러스. MAI 모델의 데이터 조달 계보. 학습 데이터 쪽의 같은 공백.
• 13.페블러스. 닫힌 모델로 하는 과학의 재현성. 단일 사업자 관점에서 본 재현성 문제.
• 14.페블러스. 에이전트 메모리의 계보와 삭제. 실행 기록이 사라질 때의 문제.