같은 latest 태그가 같은 환경은 아니다: Vercel Managed Images의 업데이트·digest 선택

코딩 에이전트를 어제와 같은 코드로 실행했는데 결과가 달라졌다고 하자. 여기서 먼저 비교할 것은 설정에 적힌 이미지 이름만이 아니다. vercel/sandbox/universal:latest라는 이름이 같아도, 그 이름이 가리키는 베이스 이미지는 업데이트될 수 있다. 반대로 digest로 베이스 이미지를 고정하면 자동 이미지 업데이트를 받지 않는다. 편리한 자동 패치와 변경 원인을 좁히는 고정은 서로 다른 운영 선택이다. 앞의 상황은 판단을 설명하기 위한 가정이며, 이 글에서 실제 장애를 관찰했다는 뜻은 아니다.

Vercel Managed Images는 2026년 8월 10일 발표됐다. 이 글은 10월의 새 발표로 다루는 뉴스가 아니라, 2026년 10월 25일 보존한 공식 발표와 이미지 문서를 읽고 정리한 선택 가이드다. 독자가 얻을 결과는 “환경 드리프트가 사라진다”는 약속이 아니라, 어느 작업에서 무엇을 고정하고 언제 패치를 다시 검증할지 나누는 기준이다.

이름이 같은 것과 이미지가 같은 것은 다르다

공식 발표에 따르면 Sandbox SDK 버전 3부터 새 Sandbox의 기본값은 vercel/sandbox/universal:latest다. 기존 runtime 속성은 deprecated, 즉 사용 중단 예정으로 분류됐지만 제거된 것은 아니다. 따라서 새 기본값 설명을 곧바로 모든 기존 코드가 전환됐다는 뜻으로 읽으면 안 된다. 공식 발표의 도입부와 마이그레이션 설명이 이 범위를 구분한다.

Managed Images에는 nightly 릴리스가 있다. latest뿐 아니라 언어 버전을 표시한 rolling 태그도 운영체제와 의존성 업데이트를 받을 수 있다. 문서는 node:26, python:3.14를 예로 든다. 그러므로 언어 버전이 이름에 적혀 있다는 이유만으로 운영체제와 모든 패키지까지 영원히 같다고 판단할 수 없다. 이 주기는 공급자가 설명한 릴리스 방식이지, 특정 취약점의 패치가 몇 시간 안에 도착한다는 측정값이나 보장 시간이 아니다.

rolling 태그의 문자열은 유지돼도 참조 이미지는 바뀔 수 있습니다. A·B는 설명용 식별자이며 실제 이미지 측정값이 아닙니다. 출처: vercel.com/changelog/vercel-sandbox-managed-images.

공식 발표는 각 릴리스 안에서는 가능한 곳에서 의존성을 특정 버전에 고정한다고도 설명한다. 여기서 “가능한 곳에서”라는 조건과 “각 릴리스 안”이라는 범위를 놓치면 안 된다. 릴리스 내부의 일관성과, 다음 릴리스를 가리킬 수 있는 태그의 가변성은 동시에 성립한다. 같은 이름으로 새 Sandbox를 만드는 것과 같은 베이스 이미지로 만드는 것을 구분해야 하는 이유다. 이 설명은 이미 실행 중인 Sandbox의 파일시스템이 매일 자동 교체된다는 뜻도 아니다.

자동 업데이트와 digest 고정, 무엇을 우선할까

자동 업데이트를 먼저 받을 작업에는 rolling 태그를, 변경 원인을 분리해야 하는 평가에는 검증한 digest를 선택한다. 아래 표는 제품의 보장 목록이 아니라 공식 업데이트 동작을 바탕으로 작성한 편집상 판단표다. 실제 조직의 보안 기준이나 검증 절차를 대신하지 않는다.

작업에서 중요한 것	먼저 고려할 참조	얻는 것	함께 맡아야 할 일
자주 바뀌는 도구를 쓰는 개발·탐색 작업	rolling 태그	새 이미지의 운영체제·도구 업데이트를 자동으로 따라감	업데이트 후 호환성 확인, 실제 사용 이미지 기록
프롬프트·에이전트 변경 효과를 비교하는 평가	검증한 digest	베이스 이미지라는 변경 요인을 고정	외부 모델·입력·설정도 별도로 통제
재현 가능한 장애 분석과 되돌리기 기준 보관	문제 당시의 실제 digest	같은 베이스 이미지 식별자를 다시 지정	당시 앱 코드·설정·접근 가능한 의존성 보관
검토를 거쳐 패치를 반영하는 운영	검증한 digest를 다음 digest로 명시적으로 교체	이미지 교체 시점을 검토 과정에 포함	새 이미지 테스트와 패치 승격 책임 유지

업데이트 동작은 공식 발표에 근거하며 용도별 선택은 편집상 제안입니다. digest 고정은 보안 패치 검토를 없애지 않습니다. 출처: vercel.com/changelog/vercel-sandbox-managed-images.

발표의 Secure by default 절은 digest로 고정한 이미지가 자동 업데이트에서 제외된다고 명시한다. 고정은 보안 인증서가 아니다. 예전 이미지로 돌아갈 수 있다는 장점만 보고 업데이트를 영구히 멈추면, 새 이미지에 담기는 보안 수정도 자동으로 들어오지 않는다. “이 digest가 검증됐다”와 “앞으로 검토가 필요 없다”는 다른 문장이다.

실무적으로는 작업 기록에 요청한 참조 문자열과 실제 이미지 식별자를 구분해 남기는 방법을 권한다. 여기에 앱 커밋, 의존성 잠금 파일, 주요 설정의 버전을 함께 묶으면 원인을 좁히기 쉽다. 이는 이 글의 운영 제안이며, 특정 SDK가 이 모든 필드를 자동 기록한다거나 그 수집 명령을 여기서 실행했다는 뜻은 아니다. 실제 digest 값도 취득하지 않았으므로 복사 가능한 값처럼 만들어 싣지 않는다.

digest가 고정하는 경계 밖도 있다

이미지 digest가 고정하는 대상은 베이스 이미지 아티팩트다. 그 위에서 내려받는 패키지, 호출하는 외부 모델, 실시간 데이터와 비밀 값까지 그 digest 하나로 동결된다고 확대하면 안 된다. 예를 들어 같은 베이스 이미지에서 잠금 없이 실행 시점에 설치하는 의존성은 별도의 변경 요인이다. 외부 API 응답이 달라지는 문제도 이미지가 같다는 사실만으로 배제할 수 없다. 이 경계 설명은 공식 자료의 이미지 식별자 의미에서 도출한 편집상 추론이지, Vercel에서 측정한 재현율이 아니다.

외부 의존성까지 digest 하나로 고정된다는 확대 해석을 피하기 위한 반례입니다. 전체 행동 재현을 측정한 제품 보장이 아닙니다. 출처: vercel.com/changelog/vercel-sandbox-managed-images.

따라서 비교 평가가 목적이라면 “digest만 고정했으니 결과 차이는 전부 프롬프트 때문이다”라는 결론을 피해야 한다. 베이스 이미지 고정은 여러 변경 요인 중 하나를 통제하는 방법이다. 반대로 개발 탐색에서 모든 요소를 고정하는 일이 항상 더 낫다고 단정할 수도 없다. 최신 도구를 따라갈 필요와 테스트 비용을 함께 비교하는 편이 맞다. 이 글에는 비용 절감률, 실행 속도 향상, 환경 차이 발생률을 입증하는 실험이 없다.

마이그레이션은 OS·사용자·시작 방식을 따로 확인한다

발표는 universal 기본 운영체제가 Amazon Linux에서 Ubuntu로 바뀐다고 설명한다. 보존 시점 카탈로그에서 universal은 Ubuntu 26.04, Node.js 24, Python 3.14를 포함한다. 이는 해당 자료의 카탈로그 예시이며 latest의 내용을 영구히 약속하는 숫자가 아니다. 특히 특정 언어 버전이 필요한지와 운영체제 계열이 달라져도 되는지는 별개의 질문이다.

사용자 전제도 달라진다. 발표에 따르면 Managed Images의 기본 사용자는 ubuntu 또는 arch이며 passwordless sudo를 쓴다. 기존 vercel-sandbox 사용자를 가정한 경로, 홈 디렉터리, 파일 소유권 처리는 별도로 검토할 대상이다. digest를 지정했다고 sudo 권한이나 네트워크 정책이 자동으로 줄어드는 것은 아니다. 또한 AL2023이 필요한 팀은 deprecated runtime에 남을 수 있다는 예외가 있다. “Managed Images가 새 기본값”이라는 설명을 “Amazon Linux 런타임이 제거됐다”로 바꾸면 잘못이다.

커스텀 이미지가 안 뜰 때는 이름보다 상태를 나눈다

일반 컨테이너 이미지를 지정하면 애플리케이션까지 자동 시작될 것이라는 기대도 분리해야 한다. 이미지 문서의 Custom images 절은 VCR이 최적화된 linux/amd64 빌드를 준비한 뒤 Sandbox에서 사용할 수 있다고 설명한다. image_not_ready는 준비가 끝나지 않았다는 신호이며, 문서상 준비 완료 뒤 다시 시도할 대상이다. 이 상태를 곧바로 업로드 실패로 단정해서 다른 이미지를 밀어 올리는 것은 원인과 처방을 섞는 일이다.

VCR 준비·프로젝트 공유·실행 절차는 서로 다른 문제입니다. 실제 장애 화면이 아닌 공식 문서 기반의 진단 흐름입니다. 출처: vercel.com/docs/sandbox/concepts/images.

진단은 세 질문으로 나누면 명료하다. 첫째, 이미지를 찾을 권한이 있는가. 같은 팀이어도 VCR 저장소는 기본적으로 프로젝트에 속하며, 다른 프로젝트에서 사용하려면 저장소 공유가 필요하다. 없는 저장소나 공유되지 않은 참조는 not_found가 될 수 있다. 따라서 문자열 오타만이 유일한 원인은 아니다.

둘째, 이미지를 사용할 준비가 됐는가. 권한이 맞아도 준비 중인 이미지는 아직 사용할 수 없다. 셋째, Sandbox 생성 뒤 프로세스를 시작했는가. 커스텀 이미지의 Docker ENTRYPOINT와 CMD는 실행되지 않으며, 생성 뒤 sandbox.runCommand()로 시작해야 한다. 이미지 참조가 맞다는 사실과 앱 프로세스가 떠 있다는 사실은 다르다. 여기서는 실제 계정 권한 테스트나 레지스트리 업로드를 하지 않았으므로, 위 흐름은 공식 상태 의미를 분리한 진단 가이드다.

선택의 결론과 자료 범위

Managed Images는 자동 업데이트되는 출발점을 제공하지만, rolling 태그가 환경의 불변 식별자는 아니다. 고정이 필요하면 digest를 선택하되 패치 검토 책임을 함께 가져가고, 자동 업데이트를 선택하면 변경을 추적하고 호환성을 확인하는 쪽에 무게를 둔다. 환경을 하나의 이름으로 부르는 대신, 베이스 이미지·앱 입력·권한·시작 절차의 경계를 나누는 것이 이 선택의 핵심이다.

이 글은 공식 자료에 근거한 운영 선택 해설이며, Sandbox 실행·이미지 빌드·성능 재현 실험은 하지 않았다. 요금제 자격, 무료 사용 여부, 실제 패치 지연 시간도 검증하지 않았다. 그림은 자료를 바탕으로 새로 그린 설명도이며 제품 화면, 실제 장애 로그 또는 성능 결과가 아니다.

출처와 확인 범위:

• Vercel Sandbox now runs on Vercel Managed Images — 2026년 8월 10일 발표. 기본값, nightly 업데이트, digest 고정, OS와 사용자 전환 설명.
• Vercel Sandbox: Images — 문서 표시 갱신일 2026년 8월 11일. Release cadence, Custom images, Use a shared image, Image references 절을 2026년 10월 25일 보존한 본문 기준으로 확인.