[DevOps] 그래서 CI/CD가 뭔데?

드디어

CI/CD까지 도착하여 포스팅을 하게 되었다.
긴 시간이었고, 나 또한 그동안 배우고 겪었던 것들을 글로 풀어내느라 시간을 꽤 썼다.
인터넷을 찾아보면 CI/CD에 관련된 수 많은 자료가 나오므로, 자세한 설명보다는 내가 배우고 느낀대로 적어보겠다.

들어가기 앞서

CI/CD라는 단어를 사용하기 전에 우리는 왜 CI/CD를 적용해야 하는가를 생각해야 한다.
앞선 글 DevOps란 무엇인가?에서 설명했듯이,
고객에게 가치를 빠르고 안정적으로 전달하는 것이 DevOps의 목적이고, 이를 위해 CI/CD를 활용하는 것이다.

더 상세한 설명을 하기 전에,
CI = 지속적인 통합 + 자동화
CD = 지속적인 배포 + 자동화
개발 -> CI -> CD 순으로 Flow가 진행됨을 먼저 알고가면 좋을 것 같다.

CI / CD

인터넷을 찾아보면 수 많은 CI/CD pipe-line 관련 이미지가 나온다.
그 중 위 이미지는 가장 간략하고 정확하게 CI/CD의 개요에 대해 설명하는 그림인것 같아 가져와봤다.

이 중, 개발자가 혼자서 진행하는 부분은 CI, CD 파이프라인 중 어디에도 속하지 않는다.
다시 말해서 CI/CD의 파이프라인을 태운다는 것은 협업을 기반으로 한다는 의미이다.

물론 규모가 작아 혼자서도 CI/CD 파이프 라인을 구축할 수도 있다.
하지만 CI/CD 파이프라인의 극적인 효율은 협업을 할 때 나오게 된다.

CI = Continuous Integration

CI는 개발자들의 코드를 지속적, 자동적으로 빌드하고, 단위테스트를 거치며, 통합테스트를 하는 과정이다.
CI의 파이프라인이 구축되어 있지 않은 극적인 상황을 생각해 보자.

10명의 개발자가 각자 빌드 후, 유닛테스트를 하고 통합테스트를 진행한다.
문제는 단위테스트와 통합테스트를 하는 시점이 모두에게 동일하고 명확하게 정의되기가 어렵다는 점이다.
만약, 10명의 개발자가 각자 개발 후 통합테스트를 한 번에 진행한다면…?

상상은 각자의 몫이다.

이제 CI를 적용해서 각 개발자들 간의 Ground Rule을 다음과 같이 세웠다고 생각해보자.

모든 개발자들은 퇴근 전 각자의 코드를 Main 코드와 통합한다.
각자의 코드가 잘 동작하는지 테스트한다.
통합테스트를 진행한다.
버그가 발견된다면, To-Do 목록에 작성하고 다음 날 업무를 수행한다.

CI를 적용하기 전 상황보다는 효율적이고 소스코드의 관리도 훨씬 잘 될 것이다.
하지만 글을 쓰면서도 위의 모든 과정이 너무나도 귀찮다.

당신이 개발자라면 위와 같은 과정을 수작업으로 하겠는가?

누군가가 나 대신 빌드와 테스트들을 해주고 버그를 기록해준다면 얼마나 좋을까.
그래서 CI/CD 파이프라인에는 필연적으로 자동화가 포함이 된다.
자동화가 적용된 위의 WorkFlow는 다음과 같이 간소화 된다.

퇴근 전 각자의 코드를 Main 코드와 통합한다.
다음날 출근 후, 버그 리포팅을 기반으로 코드를 수정한다.

개발자들이 게을러야 하는 이유가 단적으로 드러나지 않는가?

CD = Continuous Deploy/Delivery

CD는 개발된 SW가 배포되는 시점에 신뢰할 수 있는 수준을 유지하도록 지속적으로 관리하는 것이다.
CI의 연장선상에 있으며, 이상적으로는 CI가 지속적/자동적으로 이루어진다면,
CD 또한 지속적/자동적으로 이루어질 수밖에 없다.

실제로 CI/CD 파이프 라인을 구축해서 배포를 해본다면, 얼마나 효율적인지 알 수 있다.

이론은

별거없다. CI/CD의 등장배경과 특징 및 장점을 살펴보았지만, 이해하기 어려운 개념은 아니다.
하지만 실제로 CI/CD 자동화 파이프라인을 구축하기 위해서는 많은 삽질이 필요하다.
어떤 프로세스를 언제 어떻게 적용하고, 결과는 어떤 방법으로 처리할지 등이 고려되어야 한다.

바닥부터 구축하라고하면 차라리 안하는게 나을수도 있지만, 역시 누군가가 만들어놓은 솔루션이 있다.
Jenkins, Travis, GitLabCI 등의 CI 서버가 있고 각 솔루션의 장단점을 분석한 후에 단계별 Stage의 tool들을 살펴보러가겠다.

Reference

<< Previous Next >>