CI/CD — GitHub Actions 만으로 충분한 시점

CI/CD를 처음 구성할 때 어떤 도구를 써야 하는지 고민하는 팀이 많다. Jenkins, GitLab CI, CircleCI, ArgoCD, Tekton 등 선택지는 넓다. 우리 팀은 지금 GitHub Actions 하나만 쓴다. 그 선택이 언제까지 유효한지, 어느 시점에 다시 검토해야 하는지를 정리해본다.

GitHub Actions 가 충분한 조건

우리 경험 기준으로, 아래 조건이 맞으면 GitHub Actions 만으로도 충분하다.

저장소가 GitHub에 있다. Actions는 GitHub에 통합되어 있어서 별도 연동 없이 이벤트 기반 트리거가 동작한다. PR 열리면 테스트, main 머지되면 배포로 이어지는 흐름이 설정 몇 줄로 끝난다.

배포 대상이 단순하다. 단일 서버나 소수의 인스턴스에 SSH로 배포하거나, Docker 이미지를 빌드해서 레지스트리에 올리는 수준이라면 Actions 만으로 처리된다.

병렬 빌드 수요가 많지 않다. 하루에 수십 번 이하의 빌드가 일어나는 팀이라면 GitHub에서 제공하는 무료 또는 유료 크레딧 범위 안에서 충분히 운영된다.

우리가 실제로 쓰는 구성

메인 워크플로우는 세 단계다. 린트와 단위 테스트 통과 여부를 먼저 확인하고, 통과하면 Docker 이미지를 빌드해서 레지스트리에 올린다. 이후 배포 서버에 SSH로 접속해서 새 이미지를 풀하고 컨테이너를 재시작한다.

롤백이 필요할 때는 이전 이미지 태그로 수동 재배포한다. 자동 롤백 로직은 아직 없다. 장애 빈도가 낮고, 자동 롤백보다 원인 파악을 먼저 하는 게 낫다고 판단했기 때문이다.

다시 검토해야 할 시점

배포 대상 환경이 많아지거나 복잡해지면 한계가 온다. 쿠버네티스 클러스터에 여러 서비스를 조율하며 배포해야 한다면 ArgoCD 같은 GitOps 도구가 더 적합하다.

빌드 시간이 길어지고 병렬 실행이 자주 필요해지면 비용이 올라간다. 이 시점에 자체 호스팅 러너를 쓰거나, 전용 CI 서버를 두는 방향을 검토한다.

보안 요구사항이 높아지면 시크릿 관리 방식을 다시 살펴야 한다. GitHub Secrets는 기본적인 용도에는 충분하지만, 세밀한 권한 관리가 필요하면 별도 시크릿 스토어가 필요해진다.

도구 선택의 기준

도구 선택에서 우리가 우선하는 것은 운영 복잡도다. 별도 서버를 관리하고 업데이트하고 모니터링하는 것도 비용이다. 지금 팀 규모와 서비스 수준에서 그 비용을 들일 필요가 없다면, 있는 것을 최대한 활용하는 쪽이 합리적이다.

“더 좋은 도구”보다 “지금 팀에 맞는 도구”가 더 중요하다.

— by slecs