1. 들어가며..

CICD를 제대로 이해하기 위해서는 CICD가 왜 생겨났는지 그 배경과 역사를 이해하는 것이 중요합니다. CICD가 없을때는 개발이 어떻게 진행되는지 알아보고, CICD가 어떻게 개발자들의 삶과 생산성을 발전시켜주는지 알아봅니다.

본격적인 내용에 앞서 앞으로 저희는 Staging 서버라는 단어가 자주 보게 될 것 입니다. Staging은 실제 유저에게 배포되어 서비스되는 단계인 Production 의 전 단계 서버를 의미합니다. 실제 유저에게 배포하기 전에 테스트 하는 용으로 주로 사용됩니다.

앞으로 자주 출몰하는 Build 라는 단어도 생소 할 수 있습니다. Build란 인간이 읽을 수 있는 소스코드를 프로그램 실행 시 컴퓨터가 읽을 수 있게 필요한 모든 것(pre-processing, compiling, converting data files, running automated tests, packaging 등)을 준비하는 작업입니다. ****

예를 들어, 소프트웨어 빌드의 가장 중요한 단계 중 하나는 소스 코드 파일을 실행 코드로 변환하는 컴파일 프로세싱 단계이며**,** 파이썬과 자바스크립트 같은 interpreted language들은 컴파일 단계가 없기때문에 빌드하는 과정이 뚜렷하지 않다는 특징이 있습니다. 그래서 파이썬이나 자바스크립트에서 빌드는 대부분 dependency와 라이브러리 설치가 대부분을 차지합니다. 하지만 이와 달리 Java나 C/C++ 같은 컴파일 언어에서는 명확한 빌드 단계가 존재하여 그 중간 컴파일 과정을 개발자들이 직관적으로 확인할 수 있습니다.

2. 개발자가 하는 일들 - 개발 부터 배포까지

일반적으로 개발자는 개발, 즉 코딩이 주 업무일거라고 생각합니다. 개발자이기 때문에 당연히 코드를 짜는것에 가장 많은 시간을 사용하게 될거라고 생각되겠지만 실제로 개발자의 하루는 코딩 외에도 여러 다른 업무들로 구성되어 있습니다. 개발 외적인 업무로는 테스트, 배포등 다양한 업무가 포함되며 우리의 생각보다 코딩 못지 않게 많은 공수가 들어야 하는 작업입니다.

예를 들어, 개발자가 하나의 기능을 구현이 완료된 후에는 자신의 코드가 제대로 작동하는지 확인하기 위해 테스트를 진행해야 합니다. 이를 위해 먼저 자신의 feature branch에서 Unit Test를 실행해야할 것입니다. 그 후에는 Pull Request를 거쳐 develop branch에 merge가 될것이고, 그 후 다시 develop branch에서 Unit Test를 실행해봐야 할 것 입니다. 그렇다면 왜 이런 절차를 계속 반복해야하는 것일 까요?

그 까닭은 feature branch를 기준으로 실행한 Unit Test가 정상적으로 동작하더라도, develop branch에서 merge가 이루어진 후 실행한 Unit Test에서 예기치 않은 문제가 발생할 수 있기 때문입니다. 다른 개발자들이 구현한 코드와 내가 작업한 코드가 깃허브 상에서 병합된다는 특징 때문에, develop branch에서는 다른 개발자들의 코드가 내 코드에 문제 원인이 될 수 있고, 그 반대로 내 코드가 다른 개발자들의 코드에 오류를 일으킬 수 있습니다. 따라서 develop branch에서 merge가 된 후 unit test가 정상 통과 되는지 꼭 다시 실행해봐야 합니다.

Develop branch에서 Unit Test를 실행해서 모든 테스트들이 통과 된 것을 확인했다면, 이제는 이를 Staging 서버에 배포해야 합니다. 각 개발팀마다 배포 과정이 상이하지만, 일반적으로는 Staging (1) 서버에 직접 접속 후에 새로운 코드를 pull로 내려받고, (2) 빌드 명령어를 실행해 빌드 과정을 거친 후 (3) 애플리케이션 서버를 실행시키는 과정을 거쳐 배포를 완료하게 됩니다. 이러한 배포 과정에서 만일 빌드 시간이 오래 걸리게 된다면 최종적으로 배포 과정에 드는 시간이 길어지게 되며, 특히 배포해야 하는 서버의 수가 여러개라 한다면 소요시간은 더욱 증가하게 될 것입니다.

Staging에서 배포가 끝난 후에는 더 복잡한 절차들이 남아있습니다. Integration test와 E2E (End To End) Test를 진행해야 합니다. unit test만으로는 시스템 전체를 온전히 테스트 하기에는 부족하기 때문에 더 심화된 테스트 과정인 integration test와 E2E test를 진행하게 되는데, 이러한 테스트들은 프로덕션과 최대한 동일한 환경을 구축한 후 진행되어야 합니다. 따라서 테스팅을 위한 제반사항을 setup 하는데 뿐만 아니라 실행 하는 과정도 unit test보다 더 많은 공수가 들 것 입니다.

Staging에서 모든 테스트가 완료되면 이제 Production 배포만이 남게 됩니다. Production 배포 과정은 일반적으로 Staging 배포보다 더 시간이 들어갑니다. Staging 환경보다 Production 환경이 더 복잡하고 규모가 클수 밖에 없기 때문입니다. 무엇보다, Production 배포까지의 과정이 한번에 성공적으로 진행되지 않는다는 점이 많은 개발자들의 발목을 붙잡게됩니다. 테스트 중 대부분의 경우에서 예상치 못한 버그나 오류들이 자주 발견되기 때문입니다. 그 즉시 개발자는 발견한 버그나 오류를 수정해야 하고, 처음으로 돌아가 테스트부터 모든 배포 과정을 다시 밟아야 하는 수고가 동반됩니다.

그림 [2-1] 개발부터 배포까지의 전체 WorkFlow

3. 개발자의 생산성을 어떻게 하면 높일 수 있을까?

앞선 내용에서 볼 수 있듯이 개발부터 테스트 그리고 배포까지의 과정은 쉽지 않은 과정입니다.굉장히 반복적이고 매뉴얼적인 과정입니다. 문제는 이러한 과정들이 개발자의 생산성을 낮춘다는 것입니다. 개발자의 시간은 새로운 기능들을 구현하고 시스템을 확장 시키는데 쓰이는게 가장 이상적일 것입니다. 하지만 현실은 많은 테스트와 배포를 반복하는 과정에 개발자들이 많은 시간을 뺏기게 됩니다.

많은 기업들과 개발자들이 어떻게 하면 테스트와 배포같은 수동적이고 반복적이면서 비생산적인 업무를 최대한 줄이고, 그 시간에 개발을 더 할 수 있을지를 고민해왔습니다. 그리고 정답을 자동화 에서 찾았습니다. Unit Test, Integration Test, E2E Test등의 테스트 과정과 모든 배포 과정을 굳이 사람이 직접 실행할 필요 없이 자동으로 실행 되도록 하고, 문제가 생겼을때 자동으로 알려주는 시스템을 구축해서 개발자 대신 모든 과정을 자동으로 진행되도록 하는 시스템, 즉 개발 환경 자동화 를 통해서 개발자의 생산성을 높이게 되었습니다. 이러한 개발 환경 자동화 작업이 바로 CICD 입니다. Continuous Integration / Continuous Deployment 의 약자인 CICD를 통해서 개발자가 최대한 실제 개발에만 신경을 쓰고 나머지 과정들은 자동으로 이루어질 수 있도록 해서 개발자들의 생산성을 최대한으로 높일 수 있도록 합니다.

4. 더 자주 그리고 더 빨리

개발자들의 생산성을 높이게 되는 것 외에도 CICD의 또 다른 혜택은 바로 배포를 더 빨리 그리고 더 자주할 수 있게 된다는 점입니다. CICD가 사용되기 전에는 모든 배포 과정에 개발자들의 공수가 크게 들다보니 대부분의 기업에서는 정해진 주기에만 배포를 실행했습니다. 예를 들어, 한달에 한번 혹은 분기에 한번 정해진 날에 배포를 하거나, 정해진 기능들이 모두 구현 되었을때 배포를 하거나 하는 등의 방식으로 배포를 했습니다. 그렇지 않으면 개발자들이 개발을 할 시간이 없어 항상 테스트와 배포에 모든 시간을 할애해야만 했을 것입니다.

하지만 CICD 시스템이 구현되어 있으면, 개발자가 기능 구현을 하고 코드를 푸쉬하는 순간부터 자동으로 테스트와 배포 과정이 이루어지므로 더 빠르게 그리고 더 자주 배포가 가능해집니다. 사람의 공수가 들지 않기 때문에, 테스트부터 배포 과정을 굳이 정해진 주기에만 실행할 이유가 없어졌습니다. 오히려, 모든 커밋마다 테스트를 자동으로 실행하고 배포까지 자동으로 이어질 수 있게 됩니다. 테스트만 촘촘하게 구현이 잘 되어 있다면 굳이 정해진 주기에 한번에 배포할 필요가 없이, 개별의 기능들이 커밋될때마다 바로 CICD 시스템을 통해 자동으로 테스트되고 배포될 수 있습니다. 하여, CICD 시스템을 잘 구축해놓은 기업들은 하루에도 여러번 배포가 가능하게 됩니다. 여러분도 잘 알고있는 기업인 Netflix가 좋은 예가 될것 같습니다. Netflix는 하루에 100번 이상도 배포를 하기로 유명합니다.

현대의 개발 환경에서 CICD는 빼놓을 수 없는 굉장히 중요한 사항이 되었습니다. CICD 시스템이 잘 구축되어 있는 팀과 그렇지 않은 팀의 개발 생산성은 많은 차이가 납니다. 다음에는 CICD의 구체적인 작동 원리와 workflow에 대해서 알아보겠습니다.