00. 인프라 자동화를 위한 여행의 시작

it인프라 자동화를 위한 여정의 시작.

시작은 이러했다.

내가 근무하던 한 회사는 고객사에 회사 솔루션을 구축 / 운영 하는 회사였는데, 일반적인 SI/SM 조직과는 다르게 고객사에서 제공해주는 부분은 물리 서버를 설치하기 위한 Rack, 전원, 그리고 업링크 구성을 위한 네트워크와 스위치만 제공해주고, 서버/OS/S/W를 모두 구성해야 하는... 그렇다. turnkey 방식으로 계약된 솔루션이였다.

배포만 전담으로 하고 있는 딜리버리 파트가 존재했는데 파트인원은 총 3명, 실무는 주로 외주인력을 사용했는데 총 6명의 인원이 각 고객사 전산센터에 상주근무를 하고 있었다. 대충 계산해보니 1명당 약 300대의 서버를 배포해야 하는 업무인데, 문제는 이 배포업무가 전부 수동으로 진행하고 있었다는 점이다.

300대의 서버. 많은 수량이 아닐수도 있지만, 작업절차 자체가 너무 복잡했다.(기본 Setup을 위해서는 약 40번의 수동배포 작업이 존재) 달인이 될수도 있지만, 달인이 되기까지 많은 시행착오를 거치게 될 것이고, 시행착오의 과정에서는 실수가 포함될 수 밖에 없는 구조였다.

현실이 이렇다 보니 외주 근무자는 아침 출근하자마자 퇴근전까지 커맨드만 죽으라고 치다가 퇴근해야하고, 시간내에 완료가 되지 않으면 밤 늦게까지 배포를 하다가 퇴근하는 일도 다반사였다. 늦게까지 일하면서 고생이란 고생은 다 하는 외주근무자들이 피드백은 배포실수로 인한 꾸지람밖에 없었다. 이렇게 살 수는 없었다. 저녁이 있는 삶이라 하지 않았던가?

Info

자동화... 자동화가 필요했다.

자동화 Step#1 - Jenkins 도입

당시에는 Puppet / Chef라는 Configure management 툴이 있었는데, 진입장벽이 너무 높았다..
추후 유지보수에도 문제가 생길것이 뻔했다. 그래서 다음 타자로 고민 했던것이 허드슨(현재의 Jenkins)이였다.

데이터 흐름도는 단순했다. nfs서버에다가 데이터들을 배포해놓고 jenkins 와 jenkins slave로 연동해서 배포하는 절차로 구성했다.
back

Jenkins를 CI용으로 사용하는 경우가 다반사였지, CD용으로 사용하는 경우는 많지 않았던것으로 기억한다. 그걸. 우리파트원들이 해낸거다,.ㅜㅜ jenkins를 구축하고, 각 배포절차를 jenkins project단위로 쪼개고, Project별로 shell모듈을 이용해 배포절차를 만들어 냈다. 외주 근무자들에게 jenkins사용방법을 설명해주고 추후 운영시 어떤 절차를 통해서 스크립트를 개발하면 되는지, 안내를 해주었다. jenkins project에 구성된 스크립트를 통해 자동으로 실행되도록 구현을 하였다. 기본 배포업무의 시간이 단축되었다. (3주 -> 1~2주 소요)

외주 근무자들도 jenkins 빌드버튼을 눌러놓고 다음날 출근해서 결과화인만 하면 되는 수준으로 만들어졌다. 잘 된줄 알았는데 시간이 지날수록 또다른 문제가 생겼다. 각 외주 근무자들이 자기만의 스타일대로 스크립트를 짜다보니 A고객사에서 배포하는 절차를 B고객사에 이식이 불가능했다. 코드가 긴 절차를 작성자가 없이는 해석이 불가능한 절차들도 생겨나기 시작했다. 고민에 빠졌다. 개발코드도 아니고 쉘 스크립트 작성 표준안따위 만들 여유는 없었다. 필요하다는 생각도 없었다. 개발팀에 가서 협업을 위한 개발과정을 어떻게 하는지 엿보았다. git을 사용하고 있었다. ...
...
...
우리도. git 써보자

자동화 Step#2 - Jenkins 고도화

Jenkins를 대체할. 혹은 고도화를 할 갈림길에서 고민하고 있던 찰나. Jenkins에 보안취약점이 발생했다. 심각도 최상이다.

고객사에서도 취약점 대상인지, 빠르게 패치해달라는 요구사항이 계속 들어왔다. ASAP으로 jenkins 업그레이드가 필요했다. (https://knvd.krcert.or.kr/detailSecNo.do?IDX=4842)

그런데.. Jenkins 업그레이드가 쉽지 않았다. rpm으로 jenkins를 upgrade를 하고 Jenkins Project에 들어갔더니....

난리났다. hudson에서 사용하는 xml버전은 1.0인데, jenkins 최신버전은 1.1로 버전에 올라갔다. 그 과정에서 연결된 플러그인도 버전이 올라가다 보니 hudson에서는 잘 되던 작업이 jenkins에서는 인식을 못하는 일이 생겨난것이다. 그동안 잘 되던 절차들이 업그레이드 되면서 또 다시 수동으로 돌아갈수도 있는 위기였다.

그래서 기존에 쓰던 Jenkins Project는 전부 수동으로 마이그레이션을 하고 겸사겸사 각 고객사별로 개별적으로 작성된 project도 통합하였다.

그리고 또 하나,. 저 시절 방안을 찾다가 Jenkins blueocean이라는 플러그인을 발견했다,. 이거 활용을 잘하면 pipeline처럼 사용할 수 있겠다... 싶었다.

back

Jenkins Project 페이지 하나에서 사용자가 선택하는 값을 기준으로 배포하도록 구성했다. Project에서 type이라는 변수를 놓고 type이 web일 경우, db일 경우 각각 별도의 pipeline은 타도록 설계하였고, WebUI는 BlueOcean을 보여주었다. 기존에 1개씩 직렬로 수행하던 작업을 병렬로 바꾸니 배포완료시간도 줄어들게 되었다. (1~2주 걸리던 작업이 4일로 단축되었다)

저때 고생을 좀 했는데, Jenkins 상위버전을 사용하기 위해서는 JDK 1.8이상 요구되었는데, 그때까지만 해도 사용하던 자바는 1.6버전이였다. 그렇다.... Oracle java 1.6에서는 Jenkins 2.x버전으로 구동이 되지 않았던 것이다.. 그래서 각 고객사 OS에 java 1.8버전을 설치해했다.

아울러 업무 문화를 만들었는데 상용환경에서 Jenkins Project를 생성 / 수정을 할 경우 내부에서 논의를 거쳐 각 고객사에 적용하도록 하였다.왜 만들었는지, 어떤방식으로 작동하는지, 타 고객사에 배포해두면 좋을지 등등.

자동화 Step#3 - Ansible 도입

아까 앞에서 기술한 git 기억나는가? 기존에 배포코드는 jenkins ui에서만 만들어두었는데 고객사가 늘어나고 해야할 Project가 많아지니 배포 코드 관리하기가 어려워졌다. 개인적으로는 git을 경험한 적이 없었기 때문에 옆개발팀 팀원에게 두달정도 git 사용하는 방법을 들었고, git기반의 인프라관리, 즉.IaC를 구성하기로 하였다.
사내 솔루션도 클러스터 기반의 S/W들이 도입되기 시작하였고, kafaka / zookeeper 등 서버 단위로 클러스터 구성하기 위한 절차들이 생기는데 기존 Project가지고는 구현하기가 어렵다고 판단했다.. 이제 jenkins말고 다른걸 찾아봐야할 시기가 온 것이다.

한국 Redhat. Automation관련된 자료들을 소개. 성공사례를 끊임없이 내놓던 시기였다.
Ansible 기반의 배포 자동화를 검토해보고 싶었다, Redhat담당자를 초청하여 기존 인프라 현황에 더불어 우리의 요구사항을 전달해주었다.
그후 몇일 뒤. 대략적인 아키텍쳐가 나왔다. 세부적인 Flow는 실제 프로젝트를 진행하면서 나올수 있는 절차였지만 대략적인 아키텍쳐만으로도 현재 수행하고 있는 절차에 비하면 훌륭했다.

간단한 기능 몇가지만 해보았는데 좋았다. 기존 jenkins기반에서 프로비져닝시 발생했던 문제들을 ansible에서는 해소가 되었다,
무엇보다 동일한 yaml 포맷을 사용하기 때문에 개발자 성향에 따라 달라지는 스크립트 내용따위도 줄어들었다.
외주 근무자들에게 Ansible시스템 소개 / 코드 작성 방법을 설명하고 GIt에 대해 알려주기 시작하였다.

git을 쓰게 되니 내부에서 논의하던 Jenkins Project 설명을 굳이 하지 않아도 되었다. request merge할때 코멘트를 작성하면 해결되는 일이였다. 정말 이해하기 힘든 설명일 경우에만 메신저로 물어보는것으로 해결되었다.

그래서 Git 기반의 Ansible을 우리는 쓰기로 결정했다. 근데 아직 아쉬운 점이 있는데, Ansible로 배포하려면 서버에 원격접근하여 배포 행위를 수행해야 하는데 먼가... 불편해보였다. 심하게는 jenkins 보다 퇴보된 느낌이였다.

Jenkins와 Ansible을 연동해보았다. 아쉬움이 생겼다. Foreman에 Ansible을 연동해보았다. 역시 아쉬움이 생겼다.
Redhat에서는 Automation 상용제품을 만들어 냈는데, 거기에 대응하는 오픈소스 프로젝트가 있을터. 그렇다.. 찾았다 바로 AWX(https://github.com/ansible/awx)) 였다.

AWX 약식 구성도

Web기반에 Ansible을 사용할 수 있게 되었고, 굳이 서버에 접근하지 않고 WebUI기반으로 배포업무를 수행하면 되니 내가 생각했던 것들을 해결하기에는 완벽에 가까워졌다.
다만 외주 근무자들이 처음 ansible용 yaml 작성을 힘들어 했고, 특히 정기적인 pull을 안하다보니 충돌나는 등 적응기간이 필요했다.
그리고 우리는 기존보다 더 복잡해진 배포절차가 생겼음에도 불구하고, 단 하루만에 구축을 완료하는 엄청난 쾌거를 만들어 냈다.
처음엔 3주 소요되던 초기 setup절차가 단 하루만에 배포되는 절차를 성공시킨것이다.

자동화의 역설

Warning

밝은 미래, 어두운 관리

배포 자동화에 성공했다. 단순히 서버만 배포하는것으로 끝이 아닌 전체 infra를 관리 할 수 있는 방안도 마련되었다.

그런데 이번엔 방향이 이상하게 흘러갔다. 6명에서 3주간 소요되던 배포일자가 하루, 이틀이면 끝나게 되니 굳이 6명 모두 다 필요한건지에 대한 첼린지가 들어온것이다.

이미 비용 감축을 위한 준비는 다 끝나있었고, 내가 6명 다 없어도 됩니다라는 말을 할때까지 보고사항에 대해 승인되지 않았다.
느낌이 좋지 않았다. 그동안 고생하면서 일했는데...
다양한 환경의 infra을 구성하기 위해서는 외주인원 6명 모두 필요하다는 나름대로 자료를 준비해서 보고했다,(Saltstack도 이때 준비해봣었다)
하지만 설득실패하였다.ㅠ

결국 외주근무자 6명중 2명만 유지하고 나머지는 각 소속사로 복귀. 최종적으로는 1명만 유지하게 되었다.

사용자의 최소한의 개입으로 안정되고 동일한 품질의 배포된다는 장점이 있기에 만족한다.
하지만 자동화의 역설을 보는것 같아 씁슬했다.

reference


perplexity에서 생성한 AI이미지

작성일: 2026년 6월 30일 , 마지막 업데이트: 2026년 7월 13일