솔직히 말해봅시다. 오늘 아침 출근해서 가장 먼저 한 일이 무엇입니까. 커피를 내리기도 전에 습관적으로 GitHub 알림 창을 켜고, Dependabot이 쏟아낸 수십 개의 PR을 보며 'Merge' 버튼을 누르지는 않았습니까. 녹색 체크 표시가 주는 안도감, 시스템이 최신 상태라는 착각. 그 알량한 도파민에 중독되어 정작 중요한 리소스를 태우고 있다는 생각은 안 해보셨나요.
실리콘밸리에서 15년을 구르며 수많은 장애를 겪었습니다. 그중 절반은 우리가 건드리지 말았어야 할 코드를 굳이 '최신 버전'으로 올리려다 발생했습니다. 넷플릭스에서 플랫폼 엔지니어링을 하며 뼈저리게 느낀 건, 가용성 99.999%를 지키기 위해 엔지니어의 수명을 갈아 넣는 건 미친 짓이라는 겁니다. 최근 앤드류 네스빗이 제안한 'Dependabot 소음 줄이기 전략'을 보며 쓴웃음을 지었습니다. 겉보기엔 풍자처럼 보이지만, 그 안에는 24시간 호출(On-call)에 시달리는 엔지니어들이라면 누구나 공감할 피 섞인 생존 본능이 들어있기 때문입니다.
우선 '쿨다운(Cooldown)' 전략을 봅시다. 새 버전이 나왔다고 바로 적용하는 건, 내 프로덕션 환경을 베타 테스터들의 놀이터로 내어주는 것과 같습니다. 네스빗은 중요 시스템의 경우 최소 30일을 기다리라고 말합니다. 100% 동의합니다. 오픈소스 생태계, 특히 npm 같은 곳은 하루에도 수백 번씩 깨집니다. 누군가 네브래스카의 지하실에서 만든 패키지 하나가 전 세계 서버를 마비시키는 꼴을 보고 싶지 않다면, 남들이 먼저 피를 흘릴 때까지 기다리세요. 최신 기술 도입이라는 허영심보다 중요한 건 새벽 3시에 PagerDuty가 울리지 않는 것입니다.
다음으로, 'CVSS 점수의 허상'을 직시해야 합니다. 보안 팀은 CVSS 9.8점짜리 취약점이 떴다며 당장 패치하라고 난리를 칩니다. 하지만 맥락(Context)이 없는 점수는 쓰레기 데이터입니다. 사용자 입력을 전혀 받지 않는 내부 서비스에서, PDF 파싱 라이브러리의 원격 코드 실행(RCE) 취약점이 무슨 소용입니까. "우리 서비스 맥락에서는 악용 불가능(Not Applicable)"이라고 선언하고, 리스크 수용 대장(Risk Acceptance Register)에 기록한 뒤 무시하는 배짱이 필요합니다. 보안 연구원들은 논문을 쓰기 위해 모든 가능성을 보고하지만, 우리는 제품을 출시해야 하는 사람들입니다.
더 과격한 방법들도 있습니다. 네스빗은 open-pull-requests-limit을 0으로 설정하라고 제안합니다. 농담 같습니까? 저는 진지하게 고려해 볼 만하다고 생각합니다. 스프린트 기간 내내 봇이 생성한 PR에 시달리느니, 차라리 보안 대시보드만 켜두고 분기별 유지보수 기간(Maintenance Window)에 몰아서 처리하는 게 훨씬 효율적입니다. 매일 조금씩 고통받느니, 계획된 고통을 겪는 게 낫습니다.
심지어 그는 의존성을 직접 벤더링(Vendoring) 하거나, 락파일(Lockfile)을 버전 관리에서 빼버리라는 극단적인 조언도 서슴지 않습니다. 벤더링을 하면 코드가 내 리포지토리 안으로 들어오니 스캐너의 감시망을 피할 수 있고, 업데이트의 고통(5만 줄의 Diff)을 늘려서 불필요한 변경을 억제한다는 논리입니다. 기술적으로는 미친 소리처럼 들리겠지만, 운영 관점에서는 일리가 있습니다. 변경의 마찰 계수를 높여서 시스템의 안정성을 강제하는 겁니다.
물론 이 모든 조언을 문자 그대로 받아들여 보안을 포기하라는 뜻은 아닙니다. 핵심은 '주객전도'를 막자는 겁니다. Dependabot은 도구일 뿐입니다. 도구가 주인을 부려먹고, 알림 소음이 엔지니어의 집중력을 갉아먹는 상황을 방치하지 마십시오.
여러분의 팀이 5명 이하라면, 혹은 당장 비즈니스 로직을 짜내기도 벅찬 스타트업이라면 더더욱 이 '게으른' 전략이 필요합니다. 완벽한 보안, 완벽한 최신 버전 유지는 허상입니다. 우리가 지켜야 할 것은 라이브러리의 버전 숫자가 아니라, 서비스를 지탱하는 여러분 자신의 멘탈과 건강입니다. 오늘 하루쯤은 Dependabot 알림을 꺼두셔도 됩니다. 세상 안 망합니다. 퇴근하고 잠이나 푹 주무십시오.
