Vercel이 빌드 로그에서 비밀을 가린다: [REDACTED]를 보안 경계로 착각하지 않는 법

테크

빌드 로그에 DATABASE_URL이나 API token이 찍히는 순간, 비밀은 더 이상 환경 변수 저장소 안에만 있지 않다. 복사 가능한 웹 화면, Log Drain, 지원 티켓, CI 아카이브까지 별도의 유출 표면이 된다. Vercel은 7월 9일부터 Sensitive로 표시된 Environment Variable 값이 32자 이상이면 배포 빌드 로그에서 REDACTED로 치환한다. 반가운 안전망이지만, 이것을 ‘비밀이 안전해졌다’는 선언으로 읽으면 가장 위험한 사각지대를 놓친다.

Vercel 배포 비밀을 분류, 주입, 빌드 로그 마스킹, Activity Log, 키 회전의 다섯 단계로 관리하는 보안 경계 다이어그램
자동 마스킹은 마지막 안전망이다. 비밀 분류와 최소 주입, 출력 금지, 노출 감지와 회전이 앞뒤에서 연결되어야 한다.

무엇이 바뀌었나

Vercel의 공식 변경 사항은 조건이 명확하다. 변수가 Sensitive로 지정되어 있고 값이 32자 이상일 때 빌드 로그에서 실제 값 대신 REDACTED가 보인다. Build Logs 화면은 마스킹이 일어났다는 사실도 알린다. Activity Log에는 변수 key, project, deployment가 기록되지만 값은 남지 않는다. 일부 배포 보안용 system Environment Variable도 별도로 마스킹된다.

즉 모든 환경 변수, 모든 길이, 모든 표현을 포괄하는 범용 DLP가 아니다. 공식 설명이 보장하는 범위는 ‘Sensitive로 분류된 32자 이상 값’이다. 31자 이하의 짧은 token, 비밀의 일부 문자열, base64나 URL encoding처럼 변형된 값, 애플리케이션이 새로 조합한 credential까지 자동으로 가려진다고 가정해서는 안 된다.

또한 Sensitive 지정은 Production과 Preview에서만 가능하다. 기존 변수를 같은 자리에서 Sensitive로 바꾸는 것이 아니라 삭제 후 Sensitive 옵션으로 다시 추가해야 한다. 값 변경은 다음 deployment부터 적용되므로, 재등록 직후 기존 deployment가 안전해지는 것도 아니다.

마스킹은 보관·권한·회전을 대신하지 않는다

로그 마스킹은 값이 출력된 뒤 표시 계층에서 피해를 줄이는 통제다. 더 앞단의 질문은 왜 build process가 그 비밀을 읽을 수 있었는지, install script와 third-party build plugin까지 같은 환경을 공유해야 했는지다. build-time에 필요 없는 runtime secret은 빌드에 주입하지 않는 것이 가장 강한 통제다.

Sensitive 변수는 생성 후 값을 읽을 수 없는 형태로 관리되지만 runtime에는 애플리케이션이 사용해야 한다. 따라서 악성 dependency, 잘못된 build command, 공격받은 plugin이 값을 읽고 외부로 전송할 가능성까지 마스킹이 막아주지는 않는다. 콘솔 출력 한 경로를 가리는 것과 execution context에서 비밀 접근을 차단하는 것은 다른 보안 경계다.

Vercel은 2026년 4월 보안 공지에서 비-Sensitive 환경 변수가 열거·복호화된 사건을 공개하고 해당 값을 우선 회전하라고 권고했다. 7월 마스킹 기능이 그 사건의 직접 후속이라고 변경 로그가 명시하지는 않는다. 다만 두 문서는 같은 운영 교훈을 준다. ‘환경 변수’라는 이름이 비밀 등급을 자동으로 부여하지 않으며, 팀이 Sensitive 분류와 회전 책임을 명시해야 한다.

배포 로그를 별도 데이터 흐름으로 모델링하라

첫째, source of truth에서 변수를 public config, internal config, credential로 나눈다. NEXT_PUBLIC_*처럼 클라이언트 번들에 들어가는 값은 애초에 비밀이 아니다. 반대로 database URL, signing key, provider token은 Preview와 Production에서 Sensitive 정책을 강제하고 owner와 rotation SLA를 붙인다.

둘째, 주입 경로를 나눈다. package install과 static build에 필요한 값, server runtime에만 필요한 값, one-off migration에 필요한 값을 같은 세트로 전달하지 않는다. Preview에는 production credential을 복제하지 말고 별도 scope와 최소 권한을 사용한다.

셋째, 출력 경로를 inventory한다. Vercel Build Logs뿐 아니라 GitHub Actions, build cache metadata, error tracker, Log Drain, artifact, 지원 티켓에 동일한 값이 이동할 수 있다. GitHub도 structured secret은 정확한 로그 redaction을 어렵게 할 수 있다고 문서화한다. 한 플랫폼의 마스킹 성공을 다른 저장소의 안전으로 확장 해석하지 말아야 한다.

넷째, ‘값’ 대신 안전한 증거를 남긴다. key 존재 여부, fingerprint 앞 8자리, credential version, target environment, rotation timestamp만 기록하면 디버깅 가능성과 비밀 노출을 동시에 줄일 수 있다. 오류 메시지도 전체 connection string 대신 provider, host class, error code를 구조화해서 남긴다.

커뮤니티 신호: 외부 시크릿 관리와 플랫폼 정책 사이의 틈

Vercel Community에는 Doppler에서 Restricted로 관리한 변수가 integration을 통해 Vercel에 동기화된 뒤 Sensitive로 전환되지 않는다는 질문이 올라왔다. Vercel 답변은 당시 integration별 지원이 필요하며, 임시 방안으로 동기화를 끊고 변수를 다시 추가하는 방법을 안내했다.

이 사례는 모든 integration의 현재 동작을 일반화하는 사실 근거가 아니다. 하지만 실무에서 비밀 등급이 시스템 경계를 넘을 때 보존되지 않을 수 있다는 좋은 신호다. 원본 secret manager의 ‘Restricted’가 대상 플랫폼의 ‘Sensitive’와 자동으로 같은 의미인지, drift와 source-of-truth 손실을 누가 책임질지 검증해야 한다.

커뮤니티가 궁금해하는 핵심도 ‘REDACTED가 보이느냐’보다 자동 동기화, rotation, rollback을 유지하면서 Sensitive 정책을 강제할 수 있느냐다. 보안 UI 한 번 클릭보다 통합 경로의 지속 가능한 운영 계약이 중요하다.

오늘 실행할 체크리스트

1. Production·Preview의 모든 변수 key를 export 가능한 metadata 기준으로 목록화하고 credential 후보를 owner와 함께 분류한다.

2. credential인데 Sensitive가 아닌 값을 우선 회전한 뒤, 기존 값을 삭제하고 Sensitive로 재등록한다. 삭제 전에 의존 deployment와 rollback 계획을 확인한다.

3. team-wide Environment Variable Policy로 Production과 Preview의 신규 변수를 Sensitive로 강제할지 결정한다.

4. build command, install script, code generation, telemetry setup에서 process.env 전체나 connection string을 출력하는 코드를 검색한다.

5. 32자 미만 token, JSON credential, PEM, URL-encoded 값, 접두사·접미사가 붙은 값을 별도 테스트 fixture로 만들어 로그에 원문이 남지 않는지 확인한다.

6. GitHub Actions, Log Drain, error tracker, artifact와 지원 티켓까지 동일한 canary secret이 노출되는지 end-to-end로 점검한다.

7. 로그에는 key, fingerprint, version, environment만 남기는 safe logger helper를 만들고 code review 규칙에 포함한다.

8. 노출을 발견하면 로그 삭제만 하지 말고 credential을 revoke·rotate하고 Activity Log와 최근 deployment를 조사한다.

9. 외부 secret manager integration이 Sensitive 속성과 rotation을 보존하는지 테스트하고, 불가능하면 허용 가능한 임시 절차와 만료일을 문서화한다.

리스크와 반론

‘플랫폼이 자동으로 가려주니 개발자가 신경 쓸 일이 줄었다’는 말은 절반만 맞다. 우발적인 console.log 피해는 줄지만, 값이 short secret이거나 변형되었거나 다른 로그 저장소로 이동하면 보장 범위를 벗어날 수 있다. 자동 마스킹은 실패해도 피해를 줄이는 defense-in-depth이지 출력 허가가 아니다.

‘디버깅하려면 실제 값을 봐야 한다’는 주장도 자주 나온다. 대부분의 경우 전체 비밀보다 존재 여부, 환경, version, fingerprint, provider error code면 충분하다. 실제 값이 꼭 필요하다면 일반 로그가 아니라 승인·감사·만료가 있는 break-glass 절차로 분리해야 한다.

마지막으로 Sensitive 강제는 local development 경험을 자동으로 해결하지 않는다. Vercel 문서상 Sensitive는 Development에 적용할 수 없고 local env file은 plaintext다. 개발 노트북의 .env, shell history, agent tool access와 화면 공유는 별도 위협 모델로 관리해야 한다.

Vercel 배포 비밀 감사 체크포인트

✓Production·Preview의 모든 변수 key를 export 가능한 metadata 기준으로 목록화하고 credential 후보를 owner와 함께 분류한다.

✓credential인데 Sensitive가 아닌 값을 우선 회전한 뒤, 기존 값을 삭제하고 Sensitive로 재등록한다. 삭제 전에 의존 deployment와 rollback 계획을 확인한다.

✓team-wide Environment Variable Policy로 Production과 Preview의 신규 변수를 Sensitive로 강제할지 결정한다.

✓build command, install script, code generation, telemetry setup에서 process.env 전체나 connection string을 출력하는 코드를 검색한다.

✓32자 미만 token, JSON credential, PEM, URL-encoded 값, 접두사·접미사가 붙은 값을 별도 테스트 fixture로 만들어 로그에 원문이 남지 않는지 확인한다.

✓GitHub Actions, Log Drain, error tracker, artifact와 지원 티켓까지 동일한 canary secret이 노출되는지 end-to-end로 점검한다.

✓로그에는 key, fingerprint, version, environment만 남기는 safe logger helper를 만들고 code review 규칙에 포함한다.

✓노출을 발견하면 로그 삭제만 하지 말고 credential을 revoke·rotate하고 Activity Log와 최근 deployment를 조사한다.

✓외부 secret manager integration이 Sensitive 속성과 rotation을 보존하는지 테스트하고, 불가능하면 허용 가능한 임시 절차와 만료일을 문서화한다.

정리

REDACTED는 좋은 안전망이지만 보안 경계의 끝이 아니다. 실무 팀이 해야 할 일은 비밀을 먼저 분류하고 필요한 phase에만 주입하며, 값 대신 안전한 증거를 기록하고, 모든 출력 채널을 검증한 뒤 노출 시 즉시 회전하는 것이다. 빌드 로그 보안은 마스킹 기능이 아니라 이 전체 데이터 흐름의 운영 품질로 결정된다.

출처

다른 글