우리 Monorepo에서 Dependabot 노이즈를 줄인 방법

Source: Dev.to

왜 Dependabot이 필요했는가

• 의존성 관리를 점점 더 수동적이고 오류가 발생하기 쉬운 방식으로 진행하고 있었다.
• InnerSource Terraform 모듈이 자주 업데이트되었지만, 이를 사용하는 프로젝트는 변경 사항을 직접 추적하고 적용해야 했다. 시간이 지나면서 프로젝트가 뒤처져 업그레이드가 어려워지고 호환성 문제 위험이 커졌다.
• Spring Boot 의존성은 초기 설정 이후 거의 업데이트되지 않아 알려진 취약점이 코드베이스에 남아 있었고, Nexus SCA에서 반복적인 경고가 발생했다.
• CI 파이프라인이 취약점 정책 위반으로 실패하기 시작했으며, 대부분 이미 해결책이 제공된 문제였다.

보안 경고, CI 실패, 그리고 수동 업데이트에 드는 비용 증가를 방지하기 위해 인프라와 애플리케이션 의존성을 자동으로 최신 상태로 유지할 방법이 필요했다. 그래서 GitHub의 Dependabot을 도입하게 되었다.

모노레포에서 Dependabot 관리

생태계별 그룹화된 풀 리퀘스트

• 모든 Maven 기반 업데이트는 하나의 풀 리퀘스트로 생성된다.
• 모든 Docker 기반 업데이트는 별도의 하나의 풀 리퀘스트로 생성된다.
• 다른 생태계에도 동일한 패턴이 적용된다.

생태계별 업데이트 빈도

• Terraform 의존성은 InnerSource 모듈이 자주 변하기 때문에 매일 확인한다.
• 그 외의 모든 생태계(Maven, Docker 등)는 최신성 유지와 검토 부담을 균형 있게 맞추기 위해 주간 단위로 확인한다.

Dependabot 설정 예시

updates:
  - package-ecosystem: "maven"
    directories:
      - "/packages/app_a"
      - "/packages/app_b"
    schedule:
      interval: "weekly"
      day: "tuesday"
      time: "19:00"

Dependabot PR을 일반 기능 브랜치처럼 다루기

• 모든 Dependabot PR은 개발자가 만든 브랜치와 동일한 CI 파이프라인을 트리거한다.
• 자동화된 테스트 스위트가 각 풀 리퀘스트마다 실행되어 인프라와 애플리케이션 변경을 검증한다.
• 모든 필수 체크와 리뷰를 통과한 뒤에만 PR이 병합된다.

소유권 및 모니터링

• 각 Dependabot PR은 작은 Jira 작업에 연결되고 명확히 개발자에게 할당된다.
• 할당된 개발자는 PR 결과를 검토하고 CI 또는 테스트 실패를 조사한다.
• PR이 실패하면 원인(브레이킹 체인지, 테스트 이슈, 설정 업데이트 필요 등)을 파악하고 수정 조치를 취한다.

이 가벼운 프로세스를 통해 Dependabot PR이 배경 소음이 되지 않도록 한다.

비근무시간 CI 실행

• Dependabot이 트리거한 파이프라인은 개발 피크 시간을 피해서 실행되도록 스케줄링한다.
• 이를 통해 공유 CI 자원에 대한 경쟁을 줄이고, 개발자가 활발히 작업하는 동안 리소스 사용을 최소화한다.
• 팀은 다음 근무일까지 최신 결과를 받아볼 수 있어 기능 개발 속도를 늦추지 않는다.

눈에 보이는 혜택

• 의존성 관련 CI 실패가 크게 감소했다.
• 적시 업데이트 덕분에 Nexus SCA에서 발생하는 취약점 알림이 감소했다.
• 더 적고 의미 있는 풀 리퀘스트가 생성돼 리뷰가 빠르고 쉬워졌다.
• Terraform 모듈과 Spring Boot 애플리케이션 전반의 안정성이 향상되었다.
• 활성 개발에 영향을 주지 않으면서 CI 자원을 효율적으로 활용할 수 있게 되었다.

전체적으로 이 접근 방식은 의존성 관리를 반응형 문제에서 예측 가능하고 소음이 적으며 신뢰할 수 있는 프로세스로 전환시켰다.