두 앱 저장소의 release.yml에서 밀려 있던 GitHub Actions 액션 버전들을 점검하다가, gradle/actions/setup-gradle만 요청받은 v6이 아니라 v5에서 멈췄습니다.

기술적으로는 아무것도 안 깨집니다. v6으로 올렸어도 빌드는 초록불로 시원하게 돌았을 것이고, 캐시도 빨라졌을지 모릅니다.

하지만 그 한 줄 아래에는 조용히 바뀐 남의 이용약관과 독점 구성요소가 숨어 있었습니다.

action.yml에 새로 생긴 한 줄

v6의 action.yml을 열어보았을 때 cache-provider라는 새로운 입력값이 보였습니다.

inputs:
  cache-provider:
    description: 'The cache provider to use'
    default: 'enhanced' # commercial caching service

기본값이 'enhanced'로 설정되어 있었고, 주석에는 아주 작게 ‘commercial caching service’ 라고 적혀 있었습니다.

출처를 따라가 보니, v6부터는 성능 개선이라는 이름 아래 캐시 기능을 gradle-actions-caching이라는 비공개 상용 바이너리로 분리해 두고 있었습니다.

조용히 바뀐 LICENSE 파일

더 결정적인 것은 LICENSE 파일의 변화였습니다.

• v5까지: 순수한 ‘The MIT License’ 단독 라이선스.
• v6부터: ‘벤더 포함 독점 구성요소(Proprietary components)가 포함되어 있다’는 안내 문구 추가.

릴리스 노트에는 이렇게 명시되어 있었습니다.

“v6으로 액션을 실행하면 Gradle의 상용 서비스 이용약관에 동의하는 것으로 간주됩니다.”

이 상용 캐시 요소는 옵션을 끄지 않는 한 기본으로 로드됩니다. 그리고 대부분의 팀은 빌드 속도를 위해 캐시를 켜서 씁니다.

편리함 뒤에 숨은 ‘침묵의 동의’

오픈소스 생태계에서 v5 -> v6 같은 메이저 버전 판올림은 보통 API 브레이킹 체인지를 점검하는 자리입니다.

누구도 “이 버전을 쓰면 상용 클라우드 서비스 약관에 서명하게 된다”는 사실을 예상하지 못합니다.

만약 Dependabot이나 자동 머지 봇이 열어준 PR을 보고 npm test나 CI 빌드가 초록불이라는 이유만으로 머지했다면, 우리는 우리도 모르는 사이에 회사의 빌드 머신에 서드파티 상용 에이전트를 상주시킨 셈이 됩니다.

기술적 성공과 옳은 결정은 다릅니다

이것이 바로 조용히 실패하는 또 하나의 전형적인 모습입니다.

1. 컴파일러는 약관을 읽지 않습니다: 바이너리가 제대로 로드되어 0을 뱉으면 정상으로 판단합니다.
2. CI 로그는 깨끗합니다: 오히려 빌드 시간이 10초 단축되었다고 자랑합니다.
3. 위험은 법적·구조적 층위에 쌓입니다: 저장소의 라이선스 투명성이 훼손되고, 언제 과금 정책이 바뀔지 모르는 비공개 바이너리에 종속됩니다.

우리는 즉시 v6 판올림을 거부하고 v5.x의 마지막 안정 버전으로 고정(Pinning)했습니다. 10초의 빌드 속도보다 저장소의 무결성과 독립성이 훨씬 값지기 때문입니다.

의존성을 대하는 세 가지 원칙

1. 메이저 판올림 시 라이선스 diff를 반드시 확인합니다: 코드가 바뀌지 않았더라도 라이선스 텍스트가 바뀌면 그것은 다른 제품입니다.
2. 기본값(default)에 상용 네트워크 호출이 있는지 봅니다: 외부 벤더 서버로 통신하거나 토큰을 요구하는지 액션 메타데이터를 검수합니다.
3. 빠르다고 다 좋은 것이 아닙니다: 빌드가 조금 느리더라도 무엇이 도는지 명확히 통제할 수 있는 빌드 환경을 유지합니다.

고치고 나서 적어 둔 것

• 판올림은 기능과 성능만 가져오지 않습니다. 때로는 새로운 제약과 남의 약관을 싣고 옵니다.
• 검사가 초록이고 속도가 빨라졌다고 해서 올바른 선택인 것은 아닙니다.
• 도구가 내미는 편리함에 서명하기 전에, 그 도구가 무엇을 대가로 요구하는지 읽어야 합니다.