갓 올라온 gem은 일단 숙성부터 — Bundler의 'cooldown'이 공급망 공격을 막는 법

라이브러리 하나가 회사를 무너뜨릴 수 있는 시대

요즘 보안에서 제일 무서운 게 '공급망 공격(supply chain attack)'이에요. 이게 뭐냐면, 해커가 내 서버를 직접 뚫는 게 아니라 내가 가져다 쓰는 오픈소스 라이브러리에 악성 코드를 몰래 심는 방식이에요. 내가 신뢰하는 패키지가 어느 날 갑자기 배신하는 거죠.

실제로 npm이나 PyPI, RubyGems 같은 패키지 저장소에서 이런 사고가 끊이질 않았어요. 공격자가 인기 라이브러리 관리자의 계정을 탈취하거나, 비슷한 이름으로 가짜 패키지를 올리거나, 멀쩡하던 패키지의 새 버전에 슬쩍 악성 코드를 넣어 배포하는 식이에요. 문제는 우리가 bundle update 한 번 치면 그 오염된 최신 버전이 자동으로 내 프로젝트에 빨려 들어온다는 거예요.

그래서 Ruby의 패키지 관리자인 Bundler가 내놓은 해법이 바로 cooldown(쿨다운) 기능이에요.

'갓 나온 버전은 일단 거른다'는 발상

cooldown의 아이디어는 정말 단순하면서도 똑똑해요. 방금 막 배포된 따끈따끈한 버전은 곧바로 안 쓰고, 일정 기간(예: 7일)이 지난 버전만 설치 대상으로 삼는다는 거예요.

악성 버전이 패키지 저장소에 올라오면 보통 며칠 안에 누군가 발견해서 신고하고 내려지거든요. 커뮤니티의 눈이 워낙 많으니까요. cooldown은 바로 그 '발각되기까지의 시간'을 활용하는 거예요. 새 버전이 올라와도 일주일은 그냥 지켜보다가, 그 사이에 문제없이 잘 살아남은 버전만 받아들이는 거죠. 일종의 '숙성 기간'을 두는 셈이에요. 음식도 갓 나온 것보다 검증된 게 안전하잖아요.

설정도 직관적이에요. Gemfile이나 번들러 설정에서 쿨다운 일수를 지정해두면, 의존성을 업데이트할 때 그 기간을 못 채운 최신 버전은 건너뛰고 그 직전의 안정된 버전을 골라줘요. 보안에 민감한 패키지는 더 길게, 덜 민감한 건 짧게 차등을 둘 수도 있고요.

다른 생태계와 비교하면

사실 이런 '시간을 두고 검증한다'는 접근은 다른 곳에서도 비슷하게 나타나고 있어요. npm 쪽에선 --before 같은 옵션으로 특정 시점 이전 버전만 받게 하거나, 일부 기업은 사내 프록시 저장소에 패키지를 며칠 격리했다가 푸는 운영을 하기도 해요. 자동 의존성 업데이트 도구인 Dependabot, Renovate에도 '며칠 지난 버전만 PR 올리기' 같은 옵션이 있고요.

Bundler의 cooldown이 좋은 건 이걸 별도 도구 없이 패키지 관리자 자체에 기본으로 녹여 넣었다는 점이에요. 외부 서비스나 복잡한 사내 인프라 없이, 설정 한 줄로 모든 Ruby 프로젝트가 이 보호막을 두를 수 있게 된 거죠.

한국 개발자에게는

Rails로 서비스를 운영 중이라면 한 번쯤 진지하게 검토해볼 가치가 있어요. 특히 CI 파이프라인에서 의존성을 자동 업데이트하는 팀이라면, cooldown을 걸어두는 것만으로 '배포 당일 악성 버전을 그대로 받아버리는' 최악의 시나리오를 상당히 줄일 수 있어요.

다만 트레이드오프도 알아둬야 해요. cooldown을 길게 잡으면 긴급 보안 패치가 나왔을 때 그 패치도 며칠 늦게 받게 되거든요. 그러니까 평소 의존성엔 쿨다운을 두되, 보안 권고(CVE)가 떴을 땐 수동으로 즉시 올리는 예외 절차를 함께 마련해두는 게 현실적이에요.