[후기] 좌충우돌 Github Actions를 사용한 자동 배포 도입 후기

목차

들어가기 전에

이 글은 단순한 후기 글이기 때문에 자동 배포 방법에 대한 기술적인 내용은 다루지 않습니다.

 

지금 회사에서는 모든 배포 절차가 수동으로 진행되고 있었습니다. IDE에서 애플리케이션을 빌드하고 SFTP로 서버에 빌드된 파일을 업로드한 후 SSH로 서버에 접속해서 실행중인 서버를 종료하고 새로 서버를 실행하는 방식이었죠.

 

이런 수동 배포 절차를 진행할 때마다 배포할 서버에 접속한게 맞는지, 제대로 된 파일을 배포하는게 맞는지 등을 매번 체크해야 하는게 너무 번거롭다보니 소위 말하는 '딸깍' 한번이면 빌드부터 배포까지 되도록 자동 배포 도입을 시도하려고 했습니다.

어떻게 자동 배포를 도입할까?

자동 배포에 대해 아는 내용이 없다보니 어떤 방법을 써야할지부터 고민이었습니다. 어떤 배포 도구를 써야하는지, 어떤 방법을 써야하는지에 대한 개념 자체가 없어서 시작을 못하고 있던 상태였죠.

 

이리저리 방황하다가 결국 깃허브 액션을 사용해서 자동 빌드 + 배포를 도입해보기로 결정했습니다. 사내에서 형상 관리 시스템으로 깃허브를 사용해서 깃허브의 특정 명령을 트리거로 동작할 수 있는 점과 따로 뭔가를 설치하는 절차 없이 워크플로우 스크립트만 작성하면 바로 적용할 수 있다는 점이 매력적으로 느껴졌습니다.

이때까지만 해도 앞으로 무슨 일이 벌어질 지 알지 못했습니다.

첫번째 난관

자동 배포 도입은 호락호락하지 않았습니다.

 

가장 먼저 간과한 점은 깃허브 액션으로 이뤄지는 자동 배포는 깃허브가 서버에 접속하는 클라이언트가 된다는 점이었습니다. 서버에 배포를 하려면 서버에 접속을 해야 하는데, 깃허브 액션 러너의 수많은 IP를 일일이 등록하는건 사실상 불가능했기 때문이죠. 깃허브 액션 러너에서 사용하는 IP가 어마어마하게 많을 뿐만 아니라 IP의 변경 가능성을 무시할 수 없었습니다.

 

AWS를 사용하고 있었다면 참고할 자료가 굉장히 많았을테니 문제가 없었겠지만 NHN 클라우드를 사용하고 있다보니 참고 자료가 굉장히 제한적이어서 난감했죠.

클라우드의 기능을 활용하자!

열심히 관련 자료를 찾아보다가 NHN 클라우드의 기능 중에 깃허브 액션 러너 같은 외부에서 직접 서버에 접속하지 않고 AWS와 비슷하게 클라우드 자체적으로 서버에 배포를 진행할 수 있는 서비스가 있고, 이 서비스를 사용할 수 있는 REST API가 있다는걸 알게 됐습니다.

 

비록 AWS와는 다르게 깃허브와 연동되지 않아 Curl로 직접 API를 호출해야 했지만 방화벽을 설정하지 않고도 자동 배포를 도입할 수 있다는 점에서 아주 만족스러웠습니다. 다른 프로젝트에 자동 배포를 도입할 때도 API의 파라미터나 레포지토리의 Secret, Variable만 변경하면 되니까 딱히 문제도 없었습니다.

두번째 난관

이렇게 첫번째 난관을 뚫고 자동 배포를 도입해서 쓰던 도중에 갑자기 서비스 사용량이 얼마 남지 않았다는 메일이 날아왔습니다.

알고 보니 Private 레포지토리는 깃허브 액션의 기본 사용량에 제한이 있었던 것이었습니다. 무작정 자동 배포를 도입해서 쓰고 있었는데 청천벽력 같은 소식이었죠.

 

하지만 이미 자동 배포를 맛본 이상 예전의 수동 배포로 돌아가고 싶지 않았습니다. 그래서 어떻게든 방법을 찾아내야 했죠.

어처구니 없는 원인

자세히 보니 문제가 된 사용량은 깃허브 액션 동작 시간이 아니라 스토리지의 용량이었습니다.

 

아는게 없는 상태에서 워크플로우 작성하는걸 무작정 따라하다보니 빌드와 배포를 별도의 Job으로 나눈채로 작성했습니다. 빌드 단계에서 빌드된 아티팩트를 업로드하고 배포 단계에서는 업로드된 아티팩트를 다운로드 받아서 배포하는 식이었죠.

 

이렇게 배포를 할때마다 아티팩트가 깃허브 스토리지에 업로드되다보니, 수시로 변경사항을 반영하는 개발 환경의 특성 상 어마어마한 속도로 스토리지 용량을 차지하게 되었고 결국 사용량 경고 메일까지 날아오게 된거였죠.

원인을 찾았으니 해결하자

사실 자동배포 절차에서 빌드와 배포를 별도의 Job으로 나눌 이유가 없었습니다. 테스트 - 빌드 - 배포라는 3개의 작업만 수행하기도 했고, 어차피 이전 스텝이 실패하면 알아서 중단되니까 굳이 Job으로 나눌 이유가 없었는데 무작정 따라하느라 그 부분을 확인하지 않은거였죠.

 

굳이 나눌 이유가 없으니 나눠둔 Job을 하나로 통합하면서 아티팩트를 업로드/다운로드하던 스텝도 자연스럽게 제거했습니다.

 

아티팩트 업로드 절차가 사라지니 스토리지 용량이 가득 차서 워크플로우가 중단되던 문제도 사라졌구요.

두번째 난관을 해결할 다른 방법은 없었을까?

사실 스토리지 사용량 이슈같은 경우에는 해결 방법을 찾다보니 자체 호스트 실행기를 사용할 수도 있다는걸 알게 되었습니다. 깃허브 액션의 월간 사용량 제한이나 과금 정책이 있는 이유가 깃허브에서 호스팅하는 실행기를 사용하려면 돈을 내고 쓰라는거였죠.

 

하지만 지금의 사용량 추세를 봤을 때는 월간 사용량 제한으로도 운영이나 개발하는 데에 지장이 없어서 자체 호스트 실행기를 구성하는 것은 보류하기로 했습니다. 월간 사용량 제한을 넘어서서 과금되는 금액이 어느정도 선을 넘어섰을 때 CI/CD용으로 별도의 클라우드 인스턴스를 추가해서 자체 호스트 실행기를 구성하게 되지 않을까 싶습니다.

마치며

아무것도 모르는 채로 무작정 도입한 자동 배포지만 그 과정에서 배운 점은 상당히 많았던 것 같습니다. 특히 깃허브 액션의 여러가지 제약이나 고려해야 할 점들은 앞으로도 유용하게 쓰일 수 있는 내용 같구요.

 

비록 이런저런 이슈들이 있었다고는 하지만 아무런 이슈도 없었다면 알지 못했을 내용들을 알게 되어 좋았고, 무엇보다 원래 목적이었던 귀찮은 수동 배포를 걷어내고 "딸깍"으로 배포하는 과정을 도입하는 것은 성공해서 좋은 경험이었다고 생각합니다.