배포 자동화 리팩토링, 젠킨스에서 ArgoCD로 (5) — 지금까지의 성과와 앞으로
여기까지 온 길
1편에서 왜 이 전환을 시작했는지 짚었고, 2편에서 샘플 앱으로 ArgoCD 개념을 손에 익혔고, 3편에서 실제 서비스의 젠킨스 스크립트와 헬름 차트를 전수조사했고, 4편에서 실제 적용 과정에서 부딪힌 문제들을 다뤘다. 이번 마지막 편에서는 지금 이 시점에 뭐가 됐고 뭐가 안 됐는지를 솔직하게 정리하고, 앞으로 어떻게 넓혀갈지, 그리고 돌아보면서 든 생각을 남긴다.
지금까지 된 것
- 백엔드 서비스 하나(
aidt-lm-service)를 개발 환경에서 ArgoCD로 배포하는 흐름 전체 검증 - 젠킨스는 “빌드 → 이미지 푸시 → 이미지 태그를 Git에 반영”까지만 하도록 역할 축소
- 스테이징에 해당하는 물리적으로 다른 클러스터 두 대에 걸친 배포 구조까지 확인
- 자동 동기화 1단계(Git 변경 시 자동 반영) 적용, 몇 차례 배포를 거치며 안정성 확인 중
아직 안 된 것 — 솔직하게
프론트엔드는 아직이다. 1편에서도 밝혔듯, 프론트엔드는 지금과 다른 빌드·배포 방식을 쓰고 있어서 이 구조를 그대로 가져다 쓸 수 있을지부터 확인이 필요하다. 이 아키텍처 검토가 끝나야 프론트엔드 전환을 시작할 수 있다.
운영 환경은 아직이다. 지금까지 다룬 모든 내용은 개발 환경 기준이고, 스테이징까지 충분히 안정성이 확인되면 그다음 운영으로 넘어갈 계획이다. 순서를 건너뛰지 않는 이유는 이 시리즈 내내 반복했던 원칙 그대로다 — 검증 안 된 걸 운영에 먼저 들이지 않는다.
자동 동기화 2단계(자기 치유)도 아직이다. 4편에서 다뤘듯, 클러스터 쪽 변경까지 자동으로 되돌리는 옵션은 배포 전략상 위험 요소가 있어서 1단계를 며칠 더 지켜본 다음 켤 계획이다.
세밀한 권한 분리도 지금은 안 했다. 지금 이 구조를 실제로 쓰는 사람이 팀 안에서도 소수라, 여러 팀이 나눠 쓰는 조직에서 필요한 수준의 정교한 권한 체계는 지금 과했다고 판단했다. 다만 이건 “안 해도 된다”가 아니라 “지금 규모엔 안 맞다”는 판단이라, 팀이나 사용 범위가 커지면 이 부분부터 다시 조일 생각이다.
운영 전환 시 재확인이 필요한 부분이 하나 더 있다. 운영 환경은 시크릿 관리 방식이 스테이징과 달라서, 지금 스테이징에서 검증한 흐름을 그대로 옮길 수 없는 지점이 있다는 걸 전수조사 과정에서 발견했다. 이 부분은 운영 전환 직전에 별도로 재확인할 계획이다.
앞으로의 순서
1
2
3
4
5
1. 스테이징 전체 안정화 확인 → 자동 동기화 2단계(자기 치유) 적용
2. 프론트엔드 아키텍처 검토 → 백엔드와 같은 구조 적용 가능 여부 확정
3. 스테이징 검증 끝나면 운영 환경 확대 (시크릿 관리 방식 차이 재확인 포함)
4. 배포 대상·사용 인원이 늘어나면 권한 체계 재설계
5. (장기) ArgoCD 자체를 지금의 임시 위치에서, 배포 도구들이 모여있는 전용 환경으로 이전
한 번에 다 하지 않고 이 순서를 지키는 이유는, 이 시리즈 전체에서 계속 강조했던 원칙과 같다 — 한 번에 변수 하나만 검증한다. 변화가 여러 개 겹치면, 뭔가 안 됐을 때 원인을 좁히는 데 오히려 더 오래 걸린다.
돌아보면서
몇 가지 남기고 싶은 생각이 있다.
잘했다고 생각하는 것 — 짐작으로 설계하지 않고 실제 파일(헬름 템플릿, 젠킨스 스크립트)을 직접 열어서 값 하나하나의 출처를 확인한 것. 이 과정에서 이미 죽어있던 값들, 그리고 원래 짐작과 다르게 물리적으로 나뉘어 있던 클러스터 구조 같은 걸 미리 발견할 수 있었다. 만약 대충 짐작으로 설계부터 시작했으면, 실제 적용 단계에서 훨씬 크게 헤맸을 거다.
아쉬운 점 — 클러스터 토폴로지를 처음부터 정확히 확인하지 않고, “그냥 라벨이겠거니” 하고 넘어갔던 순간이 있었다. 다행히 실제 배포 전 설계 단계에서 걸러졌지만, 좀 더 일찍 “이 값이 정말 라벨일 뿐인지” 의심하고 확인했으면 그 시간을 아낄 수 있었을 거다. 값 하나를 볼 때마다 “이게 그냥 표시용인지, 아니면 실제로 뭔가를 가리키는지”를 매번 확인하는 습관을 이때 다시 새겼다.
의외로 도움이 됐던 것 — 실제 서비스로 바로 뛰어들지 않고 상관없는 샘플 앱으로 먼저 개념을 익힌 것. 처음엔 돌아가는 길처럼 느껴졌는데, 덕분에 실제 서비스를 옮길 때 “이게 ArgoCD 자체의 특성 때문인지, 우리 서비스 구조 때문인지”를 거의 항상 구분할 수 있었다.
마무리
이 시리즈는 여기서 일단 마무리하지만, 실제 전환 작업은 아직 진행 중이다. 프론트엔드 전환이든 운영 확대든 의미 있는 진전이 생기면, 그때 다시 이어서 기록을 남길 생각이다. 지금 비슷한 전환을 고민하고 있는 누군가에게, 완성된 결과물보다 오히려 “이렇게 판단하고 이런 순서로 갔다”는 과정 쪽이 더 도움이 될 수도 있겠다는 생각으로 이 시리즈를 썼다.
(회사·인프라 관련 실명, 클러스터 식별자, 내부 호스트 주소 등은 전부 임의로 재구성해 게시했다.)