폐쇄망 환경의 레거시 CI/CD 개선기: 수동 배포 5단계를 1단계로 자동화하기

■ 배경: "원래 그래요"

제가 일하고 있는 금융 회사에 구현되어 있던 기존 CI/CD 시스템은 반쪽짜리 자동화였습니다.

Jenkins를 통해 빌드된 소스 압축 파일일이 타겟 서버로 전송되는 것까지는 구현되어 있었지만, 그 이후의 과정은 온전히 개발자의 몫이었습니다.

개발자가 직접 타겟 서버에 서버 접속용 client를 이용해 접속하고, 각 도메인 환경에 맞춰 스크립트를 찾아 실행하는 5단계의 번거로운 수작업을 거쳐야만 했습니다.

MSA로 구성된 서비스는 여러 서버와 그 안에 도메인이 또 나뉘어있는데 이러한 구조는 신규 입사자 온보딩의 높은 진입 장벽이 되었고, 무엇보다 크고 작은 휴먼 에러(Human Error)를 유발했습니다.

 

다들 레거시 시스템의 불편함을 감수하고 있었습니다. "이미 앞서 비슷한 서비스를 운영하는 다른 팀도 이렇게하고 있다." 라고 말이죠.

이 '당연한 불편함'이 팀의 생산성을 갉아먹고 있다고 판단하여 개선 작업에 착수했습니다.

기존의 배포 방식 도식화

■ 분석하기: 왜?

가장 먼저 든 생각은 "왜 이런 방식으로 되어있을까?"였습니다. 처음 이러한 아키텍처가 구현된 이유가 있을테니까요.

원인은 사내의 시스템이 강력한 보안 정책이 적용된 폐쇄망이었다는 점이었습니다.

 

보안적 제약 사항

- Jenkins를 통한 SSH 원격 명령어 실행 제한(특정 파일 전송만 허용)

- 서버 내 Crontab 사용 불가

- 외부 라이브러리(예: inotify-tools) 도입 불가

- 역할 별 서버 계정 분리(FTP, webdomain 접근)

 

요약하자면, 저희 보안 환경에서는 jenkins가 설치된 서버에서 소스가 배포되어야할 타겟 서버로 약속된 위치로 빌드된 소스파일의 압축파일(tar.gz)만 전달이 가능했고 FTP용 계정은 웹 도메인이 있는 폴더로 접근이 불가했습니다.

외부 라이브러리 사용이나 스케줄링 작업(crontab)을 사용 못하니 "개발자들이 직접 웹 도메인에 접근 가능한 계정을 발급 받아 직접 서버에 접속해서 수동 배포를 진행하는 방식"으로 진행하게 된 것으로 추측할 수 있었습니다.

 

"그렇다면 주어진 리눅스 순정(Native) 기능만으로 우회해서 해결할 수는 없을까?" 결국 외부 의존성을 완전히 배제하고, Jenkins가 넘겨주는 파일과 리눅스의 기본 유틸리티(nohup, shell script)만을 조합하여 직접 스케줄링(Watcher) 기능을 구현하기로 결론 내렸습니다.

---

■ 고민: 폴링(Polling) 방식, 과연 안전한가?

저는 watcher 기능을 구현하기 위해 jenkins가 소스 파일이 압축된 파일을 전달한 후 job 정보를 담은 txt 파일을 추가로 전달하는 execute를 추가했습니다.

 

타겟 서버에서는 txt 파일(이하 flag 파일)이 서버에 도착했는지 감지하기 위해, 특정 경로를 주기적으로 확인하는 폴링(Polling) 방식의 쉘 스크립트를 작성했습니다. 하지만 여기서 두 번째 고민이 시작되었습니다.

 

 

"무한 루프를 돌며 파일을 체크하는 폴링 방식이 서버 CPU에 과부하를 주지는 않을까?"

 

 

세련된 이벤트 기반(Event-driven) 감지 방식이 아니었기에, 시스템 안정성에 대한 팩트 체크가 반드시 필요했습니다.

1. 부하 테스트 및 검증: 스크립트 실행 후 리눅스 top 명령어를 통해 실시간 리소스 점유율을 모니터링했습니다. 2초 주기로 sleep을 주어 검사한 결과, 해당 프로세스의 CPU 점유율은 0.1% 미만으로 시스템에 미치는 영향이 사실상 제로에 가깝다는 것을 확인했습니다.
2. 리스크 범위 한정: 만에 하나 발생할 수 있는 사이드 이펙트를 고려하여, 대고객 서비스가 구동되는 운영(Prod) 서버가 아닌 개발(Dev) 서버에만 선제적으로 적용하였습니다.

이러한 검증 과정을 거치니, 투박해 보이던 폴링 방식이 주어진 제약 속에서는 가장 안전하고 합리적인 엔지니어링 선택이라는 확신이 들었습니다.

---

■ 구현 과정

jenkins 스크립트에서 플래그(Flag) 파일 생성

빌드된 소스 파일(.jar 등)이 서버로 넘어올 때, 해당 빌드의 메타 데이터를 담은 텍스트 파일을 함께 전달합니다. 여러 Job을 구분하기 위해 환경변수를 활용했습니다.

# Jenkins 빌드 후 처리 단계에서 실행
$ echo ${JOB_NAME} > deploy_flag.txt

 

배포 쉘 및 와쳐(Watcher) 만들기

타겟 서버에서는 특정 위치에 플래그 파일이 있는지 2초마다 확인합니다. 파일이 감지되면 내부 로직을 수행하고 플래그 파일을 삭제합니다. 이 스크립트가 세션 종료 후에도 백그라운드에서 계속 돌 수 있도록 nohup을 사용했습니다.

# 백그라운드에서 와쳐 스크립트 실행
$ nohup sh /watcher.sh &

명령어 실행 시 생성되는 nohup.out 파일에 echo 명령어로 배포 진행 상황을 출력하도록 구성하여, 필요시 배포 로그를 쉽게 트래킹할 수 있게 만들었습니다.

백그라운드 프로세스 확인 및 종료

스크립트를 수정하거나 프로세스를 내려야 할 때는 아래와 같이 PID를 찾아 깔끔하게 종료합니다.

# 실행 중인 프로세스 ID 확인
$ ps -ef | grep deploy

# 프로세스 강제 종료
$ kill -9 [processId]

 

■ 결과 및 회고

최종 배포 프로세스(위: 과거 / 아래: 현재)

 

1. 80% 효율성 향상: 수동으로 진행하던 5단계 배포가 Jenkins 빌드 버튼 클릭 한 번(1단계)으로 단축되었습니다. 팀원들이 인프라 작업에 쏟던 시간을 온전히 비즈니스 로직 개발에 집중할 수 있게 되었습니다.
2. 안정성 및 보안 강화: 사람이 직접 서버에 접속해서 명령어를 치는 과정이 사라지니 휴먼 에러가 완전히 사라졌습니다. 더불어 불필요한 SSH 원격 접속을 차단하여 사내 보안 정책도 자연스럽게 준수하게 되었습니다.

---

최신 기술과 화려한 툴을 도입하는 것만이 정답은 아니라고 생각합니다. 때로는 강력한 제약 조건 속에서도 '왜 이 기술이어야 하는가?'를 고민하고, 기본기에 충실한 대안을 찾아내어 동료들의 불편함을 해소하는 과정 자체가 개발자로서 큰 성장이 되는 것 같습니다.

비슷한 폐쇄망 환경에서 레거시 시스템으로 고통받고 계신 분들께 이 작은 개선기가 도움이 되기를 바랍니다.