Jenkins에서 GitHub Actions로 전환하여 CI/CD를 AI와 사람 모두가 접근 가능한 형태로 구현

서론

Claude Code로 개발하다 보면, 코드의 상당 부분을 AI에게 맡길 수 있습니다.

하지만 CI/CD 영역은 코드나 설정 자체가 AI에게 전달될 수 있는 형태로 되어 있지 않았습니다.

Jenkins의 Job 설정은 서버상의 GUI와 독자적인 스크립트 안에 존재했고, 리포지토리에 있는 것은 Jenkins가 호출하는 셸 스크립트에 불과했으며, Jenkinsfile도 없었습니다.

Job의 흐름이나 설정 전체를 AI가 볼 수 없었기 때문에, 설정 관련 트러블슈팅 역시 사람이 화면이나 환경을 직접 보고 해결할 수밖에 없었습니다.

반면 GitHub Actions는 setup-java와 같은 공식 Action에 환경 구축을 맡길 수 있어, 자체적으로 구현해야 하는 부분을 줄일 수 있습니다.

AI에게 맡길 수 있는 범위가 넓어지면 그만큼 공수와 품질이 개선될 수 있다고 생각합니다. 따라서 CI/CD 역시 AI가 접근할 수 있는 환경으로 만들어야 한다고 생각했습니다.

그래서 CI/CD를 Jenkins에서 GitHub Actions로 옮겼습니다.

고민한 점: CI/CD도 '개발'의 대상에 포함시키기

이전 Jenkins 운영에는 다음과 같은 문제가 있었습니다.

• CI/CD에 접근할 수 있는 사람이 일부 담당자에게 한정되어 있어, 다른 사람들은 설정이나 코드를 읽는 것조차 할 수 없었습니다.
• 설정이 GUI와 독자적인 스크립트 안에 흩어져 있어 AI가 전달받을 수 없었습니다.
• 소스 관리는 GitLab을 사용했고, Jenkins의 스크립트도 그 동작을 전제로 하고 있었습니다.

JDK 조달이나 환경 구축 역시 수작업이었습니다.

1번과 2번은 같은 문제의 양면입니다. 설정이 눈에 보이지 않는 곳에 있기 때문에 다른 사람도 AI도 손댈 수 없었던 것입니다.

YAML 형태로 만들고 앱과 동일한 리포지토리에 두면, PR(Pull Request)로 리뷰할 수 있고 그대로 AI에게 읽히게 할 수 있습니다.

CI/CD를 '설정하는 것'에서 애플리케이션처럼 '개발하는 것'으로 바꾸는 것이 목표였습니다.

실행한 내용: 배포 환경을 코드로 만들기

배포(Deploy) 과정에서는 AWS CLI나 프론트엔드 빌드를 Docker로 구동합니다.
AWS CLI는 공식 컨테이너에서 실행해야 하며, runner에 직접 설치할 수는 없습니다.

runner는 공유되는 자원이기 때문에 임의로 무언가를 추가할 수 없기 때문입니다.

- name: Deploy
run: |
# AWS CLI는 공식 이미지를 사용하는 컨테이너에서 실행합니다 (환경 변수나 명령어 상세 내용은 생략)
...

사용 언어는 Java와 Node.js이며, 빌드를 위해서는 JDK와 Node가 필요합니다.

빌드 환경은 제품에 따라 두 가지 방식이 있습니다.

• 비교적 최신 구성의 제품: 공식 actions/setup-java를 사용하여 JDK를 준비합니다.
  프론트엔드(Node를 사용하는 부분)는 앱 측의 Dockerfile 내에서 빌드되므로, 배포 워크플로우에는 Node 설정이 나타나지 않습니다.
• 구형 구성의 제품: CI용 Docker 이미지를 Dockerfile로 만듭니다.
  화면마다 Node 버전이 다르거나 특정 패키지가 필요하기 때문입니다.

FROM <JDK 베이스 이미지>
# 화면마다 Node 버전이 다르므로, 빌드 시 전달합니다
ARG NODE_VERSION
...

구형 구성의 제품은 초기에는 runner에 있는 것으로 빌드했지만, 필요한 것이 갖춰지지 않아 컨테이너 방식으로 전환했습니다.

전환 후 달라진 점

CI/CD를 다룰 수 있는 사람이 늘어남

CI/CD가 코드로 읽히기 때문에 다른 사람들도 직접 손댈 수 있게 되었습니다. 실제로 다른 멤버들이 프론트엔드 lint를 PR에서 자동으로 실행하는 CI를 여러 제품에 추가해주고 있습니다.

환경 구축 및 인증의 번거로움 감소

이전에는 JDK나 Node를 공식적으로 다운로드하여 준비해야 했으며, 제품을 추가하거나 버전 업그레이드를 할 때마다 그 작업이 발생했습니다. 이제는 JDK를 공식 setup-java로, Node를 공식 Docker 이미지로 준비할 수 있게 되었고, 버전 업데이트도 지정 변경만으로 충분합니다.

소스 코드 가져오기(Source checkout) 역시 actions/checkout으로 충분하며, 인증 설정을 별도로 준비할 필요가 없어졌습니다.

빌드 환경이 눈에 보이게 됨

이전에는 빌드에 필요한 것이 Jenkins 서버 내부 내용에 의존했기 때문에, 버전이나 도입된 항목은 서버를 직접 보지 않으면 알 수 없었습니다. 이제는 Dockerfile에 작성되어 Node의 버전과 필요한 패키지 모두 리포지토리에서 읽을 수 있고, 변경된 차이점도 남아있습니다.

AI로 워크플로우 전용 가능

기존 제품의 워크플로우를 AI에게 읽히게 하여 신규 제품이나 다른 제품에 재사용하고 있습니다.

모든 제품의 구성을 통일했기 때문에, '저 제품과 같은 구성으로'라는 지시만으로 충분합니다.

신규 제품의 환경 구축 역시 기존 워크플로우를 전용하는 것으로 끝납니다.

AI로 릴리스 장애 조사하기

deploy 전환 중에 일부 요청이 실패하는 문제가 발생하여, 워크플로우와 빌드 설정을 AI가 읽게 하여 원인을 파악하고 배포 관련 설정을 검토하여 대처했습니다.

deploy 절차, 빌드, 배포 설정이 모두 코드로 읽을 수 있기 때문에, AI가 전반적으로 원인을 추적할 수 있습니다.

맺음말

CI/CD를 코드로 만들고 애플리케이션과 같은 위치에 두었기 때문에, 일부 사람만 만질 수 있던 것을 다른 사람도, AI도 만질 수 있게 되었습니다.

AI가 할 수 있는 영역을 늘리고 싶습니다.

그 토대로, 우선 CI/CD를 코드로 만들었습니다.

코드가 되어 있으면, 사람도 AI도 손댈 수 있습니다.

맡길 수 있는 범위는 여기서부터 넓혀갈 것입니다.

Discussion