의존성 격차가 프로젝트가 되기 전에 버전 올리기

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

의존성 버전을 가장 쉽게 올리는 방법은 허무할 만큼 단순합니다. 자주 올리면 됩니다.

Spring Boot 3.1.4에서 3.1.5로 가는 일은 보통 2.4인 서비스를 3.1로 한 번에 옮기는 일보다 작습니다. 언젠가 큰 이동을 해야 할 서비스라면 작은 이동을 전부 미룬다고 작업이 사라지지 않습니다. 호환성 변경, deprecated API, 달라진 기본값, 언어나 런타임 요구사항과 라이브러리 사이의 문제가 하나의 프로젝트로 합쳐집니다. 문제가 생겨도 어느 변화 때문인지 찾기 어렵습니다.

소프트웨어는 회사의 자산입니다. 운영하는 자산이라면 기능 요청에 적혀 있지 않은 유지보수도 필요합니다.

모든 저장소에 같은 일정을 적용하지 않기

의존성을 최신에 가깝게 유지하자는 말은 한 팀이 저장소 하나를 맡을 때 쉽습니다. 운영 저장소가 스무 개라면 모든 라이브러리 릴리스를 똑같이 급하게 처리할 수 없습니다.

먼저 비즈니스 중요도와 변경 빈도로 시스템의 순서를 정합니다. 팀이 얼마나 자주 수정하는지, 어느 정도의 트래픽이나 사용자를 담당하는지, 장애 비용은 얼마인지, 얼마나 오래 운영할지, 실제로 계속 운영 중인지도 함께 봅니다. 그다음 현재 인원으로 몇 개를 제대로 관리할 수 있는지 결정합니다.

가장 중요한 그룹은 patch와 minor 버전을 자주 올릴 수 있습니다. 다른 그룹은 큰 릴리스를 위한 정기 작업 시점을 둘 수 있습니다. 곧 종료할 가치 낮은 시스템은 보안 수정만 적용할 수도 있습니다. 스무 개가 모두 중요하고 오래 살아야 한다면 개발자가 조용히 더 빨리 일할 문제가 아니라 팀의 유지보수 역량이 부족한 것일 수 있습니다.

우선순위가 1위 시스템부터 실험해야 한다는 뜻은 아닙니다. 가장 중요한 서비스는 실패 비용도 가장 큽니다. 새 프레임워크 라인이나 업그레이드 절차를 처음 적용한다면 5순위 서비스, 또는 트래픽은 낮지만 계속 변경하는 시스템에서 시작할 수 있습니다. 감당 가능한 영향 범위에서 마이그레이션 문제를 발견하고 배운 내용을 핵심 서비스에 적용하면 됩니다.

이는 단계적 운영이지 방치가 아닙니다. 어느 시스템이 어느 그룹이고 언제 다시 분류할지 기록해야 합니다. 그렇지 않으면 “나중에 올리자”가 누구도 결정하지 않은 영구 정책이 됩니다.

최신 유지가 모든 릴리스의 즉시 설치는 아니다

버전이 나오는 날 무조건 올리지는 않습니다. 특히 .0 릴리스는 조심합니다. 저는 농담처럼 ’0 버전의 저주’라고 부릅니다. 새 계열의 첫 GA 릴리스에서는 이후 patch에서 정리될 문제가 드러날 수 있습니다. 중요한 서비스라면 GA 이후 안정된 patch를 기다리는 것도 합리적인 트레이드오프입니다.

이 주의와 여러 major 계열 뒤에 계속 머무는 것은 다릅니다. 첫 릴리스를 피하면서도 지원되는 계열을 꾸준히 따라갈 수 있습니다. 버전 숫자 경쟁에서 이기는 것이 목적이 아닙니다. 이해할 수 있는 크기로 거리를 유지하는 것이 목적입니다.

업그레이드에는 평범한 엔지니어링 검증이 따라야 합니다. 릴리스 노트를 읽고 컴파일과 테스트를 실행합니다. deprecated 항목과 달라진 기본값을 확인합니다. 무엇이 바뀌었는지 보고 생길 수 있는 문제를 생각한 뒤, 가능하면 업그레이드한 서비스에 트래픽을 넣어봅니다. 빌드가 초록색인 것은 유용하지만 운영 결과의 전부는 아닙니다.

자주 올리면 진단이 쉬워집니다. patch 하나만 바뀌었다면 회귀 문제를 찾을 범위가 좁습니다. 수년간의 의존성 변경을 함께 적용하면 실패 원인 후보가 많아집니다. 작은 단계는 롤백과 리뷰도 쉽게 합니다.

새 의존성마다 유지보수 계좌가 열린다

의존성을 추가할 때는 당장의 이점이 보이므로 비용을 작게 보기 쉽습니다. 코드를 줄이거나 필요한 기능을 제공합니다. 그 뒤부터 팀은 버전, 보안 공지, 호환성 표, 런타임 요구사항, 설정 변경과 프로젝트 중단 가능성까지 따라가야 합니다.

저는 모든 의존성이 유지보수 비용을 추가하고, 그런 의미에서 기술 부채가 될 가능성을 추가한다고 봅니다. 라이브러리를 절대 쓰지 말자는 뜻은 아닙니다. 얻는 가치가 반복되는 의무를 감당할 만한지 묻자는 뜻입니다.

추가하기 전에는 이런 내용을 확인합니다.

• 문제가 라이브러리를 쓸 만큼 크거나 전문적인가?
• 프로젝트가 유지되고 있으며 우리 기술 구성과 호환되는가?
• 이미 사용하는 다른 의존성이 같은 문제를 풀고 있지 않은가?
• 라이브러리 API가 우리 코드에 얼마나 넓게 퍼지는가?
• 나중에 제거하거나 교체할 수 있는가?

가장 좋은 의존성 업그레이드는 더는 비용을 정당화하지 못하는 의존성을 삭제하는 것일 수 있습니다. 제거하면 버전 표면, 호환성 조합과 다음 유지보수자가 알아야 할 지식이 줄어듭니다. 이는 부채를 직접 줄이는 일입니다.

유지보수도 기능 전달의 일부다

회사가 필요로 하는 동안 계속 살아야 할 핵심 시스템이 오래된 프레임워크에 머무르면 릴리스마다 격차가 쌓입니다. 오늘 서비스가 잘 돌아갈 수 있으니 부채는 조용합니다. 보안 요구사항, 런타임 지원 종료, 새 기능이나 채용 문제가 압박 속의 이동을 강제할 때 눈에 보입니다.

꾸준히 따라가면 대규모 부채를 갚는 느낌이 들지 않습니다. 구조 작업이 없기 때문입니다. 바로 그것이 목적입니다. 정기적인 patch 업그레이드와 계획된 major 업그레이드는 구조 프로젝트가 생기지 않게 합니다.

프로젝트가 제 손에 있는 동안에는 의존성 상태를 설명할 수 있어야 합니다. 어느 계열을 따르는지, 왜 업그레이드를 늦췄는지, 어떤 테스트로 호환성을 확인하는지, 누가 결정을 다시 볼지 알아야 합니다. 제가 관리하는 프레임워크 템플릿을 업데이트하는 일도 회사 서비스와 같은 규칙을 따릅니다. 무엇이 바뀌었는지 확인하고, 실행하고, 격차가 모르게 벌어지지 않게 합니다.

의존성을 자주 올리는 일이 당연한 유지보수처럼 들린다면 좋습니다. 원래 평범한 일이 되어야 합니다. 건강한 자산은 몇 년마다 다시 유지 가능한 상태가 되기 위한 특별 캠페인을 필요로 하지 않습니다.