GitHub Actions의 의존성은 어떻게 관리해야 할까

애플리케이션에서는 잠금 파일을 자연스럽게 관리한다. 같은 코드를 받아 빌드했을 때 서로 다른 패키지가 설치되면 곤란하기 때문이다. 그런데 그 코드를 빌드하고 배포하는 GitHub Actions의 의존성은 어떨까.

워크플로 파일을 읽다 보면 외부 액션이 여러 단계에 들어 있다. 소스를 내려받고, 빌드 환경을 준비하고, 클라우드에 인증하고, 결과물을 배포한다. 우리는 이 액션들이 실행하는 코드를 배포 과정에 받아들이고 있다. 애플리케이션 코드만 검토해서는 배포에 영향을 주는 변경을 모두 관리하기 어렵다.

GitHub Actions 잠금 파일을 다룬 소개 글을 계기로 실제 운영 프로젝트에도 이 관점을 적용했다. 이미 빌드와 배포가 자동화된 환경이었다. 여기에 실행 의존성의 고정, 업데이트 제안, 반영 기준을 연결해 관리 방식을 보완했다.

워크플로가 그대로여도 실행하는 코드는 달라질 수 있다

워크플로의 uses에는 보통 액션 이름과 버전 태그를 적는다. 태그는 읽기 쉽지만 같은 이름이 계속 같은 커밋을 가리킨다는 보장은 없다. 원본 저장소에서 태그나 브랜치를 옮기면 우리 워크플로를 수정하지 않아도 다음 실행이 다른 코드를 사용할 수 있다.¹

배포 자동화에서는 이 차이가 중요하다. 액션마다 허용된 권한은 다르지만 일부는 소스와 빌드 결과물, 배포 자격 증명에 접근한다. 외부 코드의 변경도 서비스 배포에 영향을 주는 변경으로 취급할 이유가 있다.

우리 프로젝트는 Blacksmith로 빌드를 실행하고 클라우드에 배포하고 있었다. 실행 환경과 캐시를 개선하는 일에 더해, 그 과정에서 받아들이는 외부 코드의 버전을 관리할 필요가 있었다. 러너를 잘 운영하는 일과 그 위에서 실행할 의존성을 정하는 일은 각각 맡아야 할 책임이 있다.

잠금 파일은 실행할 버전을 검토 대상으로 만든다

actions.lock은 워크플로의 버전 참조가 실제로 어떤 커밋을 사용할지 기록한다. 잠금 대상으로 등록한 워크플로에서는 이 기록에 따라 액션을 실행한다. 직접 사용하는 액션뿐 아니라 그 액션이 사용하는 의존성도 관리 범위에 포함한다.¹

도입 후에는 읽기 쉬운 버전 표기와 실제 실행할 커밋을 함께 남겼다. 버전을 바꾸는 변경 요청에서 무엇을 선택했는지와 어떤 코드를 실행하게 되는지 같이 검토할 수 있다. 외부 저장소의 현재 상태에 맡기던 실행 기준을 우리 저장소의 변경 이력에 남기는 방식이다.

워크플로에 커밋 SHA를 직접 적어 고정하는 방법도 있다. 이미 커밋 SHA를 고정해 쓰고 있다면 기존 검토·갱신 절차와 잠금 파일의 차이를 비교하면 된다. 우리는 워크플로의 가독성을 유지하면서 의존성 기록을 함께 관리하려고 잠금 파일을 선택했다.

잠금의 범위도 분명히 해야 한다. 액션 커밋을 고정해도 그 코드가 안전한지까지 판정되지는 않는다. 러너 환경, 애플리케이션 패키지, 외부에서 내려받는 도구 등도 각자 관리가 필요하다. 잠금 파일은 배포 과정의 의존성을 관리하는 한 부분을 맡는다.

고정한 의존성을 갱신할 방법도 함께 둔다

버전을 고정한 다음에는 언제 무엇을 바꿀지 결정해야 한다. 고정한 채 방치하면 수정 사항과 보안 업데이트를 놓칠 수 있다. 그렇다고 새 버전을 곧바로 받아들이면 우리 환경에 맞는지 검토할 기회가 줄어든다.

이 역할을 Dependabot에 맡겼다. 업데이트 후보를 변경 요청으로 받아 검토한다. 잠금 대상으로 등록한 워크플로의 액션을 갱신할 때는 해당 잠금 항목도 함께 갱신하므로 버전 참조와 실행 커밋을 같은 변경에서 살펴볼 수 있다.²

여기서 잠금 파일과 Dependabot의 역할은 구분된다. 잠금 파일은 현재 사용할 의존성을 고정하고 Dependabot은 다음 변경을 제안한다. 검증과 반영 정책은 그 제안을 받아들일지 결정한다. 고정과 갱신을 함께 운영해야 의존성이 검토 가능한 상태로 유지된다.

이렇게 구성하면 업데이트를 기억해 두었다가 워크플로마다 찾아 바꾸는 작업의 일부를 도구에 맡길 수 있다. 팀은 제안된 변경의 필요성과 영향에 검토 시간을 쓸 수 있다. 다만 실제 검토 시간이 얼마나 줄어드는지는 별도 측정이 필요하다.

자동화에 앞서 변경을 허용할 기준을 정한다

업데이트 제안을 자동으로 받는 일과 운영에 자동으로 반영하는 일에는 다른 판단이 필요하다. 버전 번호가 작게 바뀌었다는 이유만으로 호환성과 안전성을 확정할 수는 없다. 실행 환경이나 필수 입력, 권한 요구가 바뀌는지도 살펴야 한다.

우리 프로젝트에서는 패치 업데이트부터 자동으로 처리하도록 정했다. 변경 범위가 좁고 근거를 확인할 수 있어야 한다. 주요 버전 변경이나 사용 방식의 조정이 필요한 업데이트, 판단 근거가 부족한 변경은 사람이 검토하도록 남겼다. 패치라는 이름보다 실제 변경 내용과 검증 가능성이 기준이다.

반영 순서도 정책으로 정했다. 개발 환경에서 먼저 확인한 뒤 같은 의존성 업데이트를 운영 환경의 기준으로 다시 검증해 반영한다. 개발 브랜치의 다른 기능 변경까지 함께 운영에 올리지 않도록 범위도 구분했다. 검토 후 후보가 바뀌었다면 바뀐 내용에 맞춰 다시 판단한다.

실패했을 때 멈출 지점까지 정하면 자동화의 책임이 분명해진다. 어디까지 도구가 진행하고 어떤 상황에서 사람이 판단해야 하는지 팀이 설명할 수 있어야 한다. 모든 업데이트를 자동 처리하는 범위보다, 허용한 변경에 같은 기준을 적용하는 일이 먼저였다.

도입 후에는 변경의 기준과 경로가 분명해졌다

이번 적용으로 달라진 관리 방식을 정리하면 아래와 같다.

실행할 의존성을 고정하면 예기치 않은 참조 이동이 배포 코드를 바꾸는 위험을 줄인다. 기록을 남기면 나중에 문제가 생겼을 때 당시 어떤 액션 코드를 사용하도록 정했는지도 추적하기 쉬워진다.

업데이트를 변경 요청에서 검토한다. 누가 버전을 갱신해야 하는지 기억하는 데 의존하던 일을 저장소의 검토 절차에서 다루게 된다. 각 변경에는 받아들인 이유와 보류한 이유를 남길 수 있다.

개발과 운영의 반영 기준을 연결하면서 업데이트가 어느 단계에 있는지도 구분했다. 제안을 받았는지, 검토 중인지, 개발 환경에 반영했는지, 운영 반영까지 마쳤는지를 같은 절차 안에서 다루도록 구성했다.³

어떤 의존성을 선택했고 왜 바꿨으며 어디까지 반영했는지 설명할 기준을 갖췄다. 빌드 속도나 비용, 장애율의 개선 수치로 해석할 근거는 아직 없다.

우리 환경에 맞게 도입 범위를 넓힌다

출발점은 현재 워크플로가 사용하는 외부 액션을 파악하는 일이다. 어떤 코드를 받아들이고 어떤 권한을 주는지 확인한 뒤 버전을 고정할 방식을 선택한다. 이미 커밋 SHA로 잘 관리하고 있다면 잠금 파일이 추가로 해결할 문제가 무엇인지부터 비교한다.

잠금 파일을 도입할 때는 파일을 만드는 작업과 검증을 함께 연결한다. 워크플로와 잠금 기록이 어긋나면 변경 요청 단계에서 발견하도록 두는 편이 좋다. 공개 미리보기 기능이므로 도입 시점의 지원 범위와 검증 도구의 변경 사항도 확인해야 한다.⁴

그다음 업데이트 제안을 받아 수동으로 검토하는 절차를 운영한다. 이 과정에서 자주 반복되는 판단과 사람이 살펴야 하는 변경이 구분된다. 범위가 좁고 검증 결과를 신뢰할 수 있는 변경부터 자동 반영으로 넓히면 된다. 개발 환경이 없거나 복구 절차가 준비되지 않았다면 잠금과 업데이트 제안까지 먼저 도입하는 선택도 가능하다.

우리가 이번에 적용한 원칙은 애플리케이션에서 익숙하게 쓰던 의존성 관리를 배포 자동화에도 적용하는 것이다. 실행할 코드를 정하고, 변경을 제안받고, 검토한 뒤 반영한다. actions.lock과 Dependabot은 이 절차를 저장소 안에서 계속 운영할 수 있도록 각각의 역할을 맡는다.

801플래닛은 서비스의 운영 조건에 맞춰 의존성 관리와 배포 절차를 설계한다. 현재 환경의 CI/CD 개선을 검토하고 있다면 클라우드 & 인프라 서비스에서 수행 범위를 확인할 수 있다.

참고 자료