CI/CD 툴이 뭘까? - 주니어 개발자의 오해

이번에는 제가 DevOps 개념을 처음 공부하면서 겪었던 CI/CD 툴에 대한 오해를 가볍게 소개해보려고 합니다.

부끄럽지만 귀엽게 봐주시죠 ㅋㅋ;;;;

 

CI/CD 툴에 대해 가졌던 아주 큰 오해

한창 서비스 개발 초기에 AWS의 EC2 인스턴스 혹은 ECS에 어떻게 자동으로 빌드, 테스트, 배포할 수 있을지 공부했었습니다.

처음 공부할 때에는 CI/CD 툴들은 EC2 인스턴스 같은 배포 타겟에 "알아서" 접속해서 build, test, run을 해줄 거라고 생각했습니다.

 

이게 왜 오해일까요?

 

telnet, ssh, teamviewer와 같은 원격제어와 비교해보면 이해하기 쉬울 것 같습니다.

다른 머신을 제어하기 위해서는 최소한 같은 프로토콜을 사용해야 하고 인증도 필요합니다.

어느 한쪽에서 원한다고 일방적으로 연결을 맺어 다른 머신을 제어할 수 없는 것이지요.

 

제가 생각했던대로 CI/CD 툴이 "알아서" 빌드, 테스트, 배포를 하기 위해서는 최소 다음 하나를 만족해야 합니다.

1. 배포 대상이 따로 제어 API를 지원하지 않는다면, 툴 에이전트가 배포 대상에 설치되어 있어야 한다.
2. 배포 대상이 제어 API를 지원한다면 API를 이용하여 자동화 과정을 진행합니다.

 

그러면 자동화는 어떻게 했을까요?

그 당시 생각했던 방안은 2가지가 있었고, 분석한 장단점은 다음과 같았습니다.

1. paramiko, fabric 같은 ssh client 기능을 지원하는 라이브러리를 이용해서 배포 대상들을 제어한다.
   • 장점: 직접적인 제어가 가능하기 때문에 낮은 러닝커브로 자동화가 가능하다.
   • 단점: 모든 것을 코드로 작성해야 하기 때문에 유지보수가 어렵고, 일관성 있는 관리가 어렵다.
2. CI/CD 툴을 사용한다.
   • 장점: 체계적인 관리를 할 수 있도록 기능이 지원될 것 같다(어떻게 지원해줄지 예상이 안됨).
   • 단점: 아직 정체를 모르는 CI/CD 툴에 대해서 공부해야 한다(러닝커브가 예상이 안됨).

 

팀 내에서는 시간을 들이더라도 두번째 안인 CI/CD 툴의 사용으로 방향이 결정되었고, 조금 더 공부할 수 있었습니다.

젠킨스, AWS CodePipeline, github action 등 다양한 CI/CD 툴을 조사해봤고, 결국에는 github action을 사용하게 되었습니다.

 

도구는 도구일뿐이라고 생각했는데 도구 선정도 쉽지 않더라구요ㅎㅎㅎ;;;

저한테는 한 주니어 개발자가 기술에 대한 환상을 직접 파헤쳐가는 짧은 모험기였는데 여러분은 어떠셨나요?

 

다음에는 github action 대한 포스팅을 준비해보겠습니다 :)