CI/CD 개념

CI/CD

사실 CI/CD 개념 자체만 두고 보자면 자동화와 직접적으로 관련있는 내용은 아니다.

그럼에도 불구하고 CI/CD하면 거의 항상 따라오는것이 자동화인데,

프로젝트의 크기가 커질수록 자동화가 배제된 CI/CD는 더더욱 상상하기 어려워진다.

이게 도대체 무슨 소리인지, 우선 CI/CD가 무엇인지부터 간략히 살펴보자.

CI

CI는 지속적 통합(Continuous Integration)으로,

모든 개발이 끝난 이후에 코드 품질을 관리하는 고전적 방식의 단점을 해소하기위해 나타난 개념이다.

말그대로 개발을 하면서 ‘코드에대한 통합’을 ‘지속적’으로 진행함으로써 품질을 유지하자는 것이다.

조금은 극단적인 예를 들어보자.

10명의 개발자가 참여하는 프로젝트가 있다고 가정해보자.

git에 기본 틀이 잡혀있는 코드가 올라와있고, 각 개발자가 자신의 로컬환경에 clone 받아서 작업을 시작한다.

그런데 개발이 끝날때까지 모든 개발자가 한 번도 중앙저장소에 코드를 올리지 않았고,

개발이 끝난 이후에 10명의 개발자의 코드를 한 번에 통합해야하는 상황이라면?

상상만해도 끔찍하니 더 말하진 않겠다.

적절한 예시일지 모르겠지만, 이해를 돕기위해 다른 예를 들어보자.

건물을 전부 다 지어놓고 마지막에 다시 돈을들여 대규모 보수공사를 하는 것보다,

층을 하나씩 쌓을때마다 올바르게 지어지고있는지 체크해주는것이 질적, 비용적 측면에서 모두 유리할 것이다.

햄버거를 다 만들어놓고 모든 재료가 제대로 들어갔는지, 유통기한이 지나지 않았는지 확인하는 것보다,

재료 하나를 올릴때마다 유통기한이나 재료의 양 등을 체크하는게 더욱 유리한 것처럼 말이다.

그렇다면 지속적 통합을 이루기 위해서는 어떻게 해야할까?

첫 번째 예제의 상황에서, 이런 규칙을 정하면 어떨까?

1. 모든 개발자는 퇴근하기 전에 자신의 코드를 중앙 코드와 통합한다.

2. 통합된 코드에서 본인의 코드가 제대로 동작하는지 테스트한다.

3. 통합된 코드가 제대로 빌드되는지 테스트한다.

4. 결과를 정리하고. 버그가 있다면 다음날 업무 목록에 적어둔다.

쉽게 말하면, 매일 퇴근하기 전에 git에 코드를 올리고 문제가 없는지 테스트하라는 것이다.

이러한 과정이 프로젝트 시작부터 종료까지 잘 지켜진다면 코드의 품질을 어느정도는 유지할 수 있을 것 같다.

그리고 막판에가서 모든 개발자의 코드를 통합하겠다고 난리법석(?)을 떨지 않아도 될 것 같다.

근데 왜 “~하다.” 라고 표현하지 않고, “~ 것 같다.” 라고 표현했을까?

이 방식은 개념만 놓고보면 아주 이상적으로 보인다.

하지만 CI의 단점이 있는데, 이미 눈치챈 사람도 있겠지만 ‘너무 귀찮다’는 것이다.

git에 코드를 올리는 것 까지는 그렇다고 쳐도,

코드가 커질수록 테스트 양은 물론이거니와 테스트 시간도 점점 길어질 것이다.

게다가 이것은 굳이 사람이 일일이 돌리지 않아도 되는 매우 지루한 반복 작업이다.

이렇게 되면 어떨까?

git에 코드만 올려놓으면 알아서 테스트와 빌드를 수행하고,

그 결과를 잘 정리해 개발자에게 자동으로 알려주는 프로그램이 있다면 좋지 않을까?

그렇기에 CI를 설명할때 항상 자동화라는 키워드가 따라다니는 것이다.

그럼 CI 자동화가 잘 이루어졌을때, 위의 규칙이 얼마나 단순화되는지 확인해보자.

1. 모든 개발자는 퇴근하기 전에 자신의 코드를 중앙 코드와 통합한다.

2. 다음날 출근시 메일로 발송된 결과 리포트를 확인하고 버그가 있으면 수정한다.

테스트나 빌드등 복잡한 절차가 모두 생략되고,

그냥 퇴근전에 코드를 git에 올리고 가면 되는 것이다.

이정도의 의지도 없다면 사실상 CI를 통한 코드 품질 개선 의지가 없다고 보는게 맞다.

CD

그렇다면 CI/CD에서 CD는 무엇일까?

CD란 지속적 배포(Continuous Deploy 또는 Delivery)로써,

소프트웨어가 항상 신뢰 가능한 수준에서 배포될 수 있도록 지속적으로 관리하자는 개념이다.

사실 어려울 것 없이 그냥 CI의 연장선으로 생각하면 된다.

배포 이전에 테스트와 빌드는 필수적이기 때문에,

사실상 CD가 되려면 항상 CI가 선행되어야 한다고 봐도 무방하다.

즉, CI 프로세스를 통해 개발중에 지속적으로 빌드와 테스트를 진행하고,

이를 통과한 코드에 대하여 테스트서버와 운영서버에 곧바로 그 내용을 배포해 반영하는 것이다.

이상적인 환경이라면 테스트와 빌드가 ‘지속적’으로 이루어지기 때문에,

배포 또한 자연스럽게 ‘지속적’으로 이루어지게 된다.

사실상,

CI = 빌드 및 테스트 자동화

CD = 배포 자동화

라고 기억해도 무방하다.

중요한 것은,

코드 품질관리에 있어서 CI/CD 자동화가 ‘왜’ 필요하며,

이러한 시스템을 구축하는 것이 ‘왜’ 중요한지에 대해 이해하는 것이다.

DevOps 엔지니어의 역할

CI/CD 자동화는 DevOps 엔지니어의 핵심 업무에 속한다.

이처럼, DevOps 엔지니어는 CI/CD를 위한 파이프라인을 구성하고, 이를 자동화 단계까지 끌어 올린다. 또한 중간중간 모니터링 지표를 구성하여, 개발자들의 개발 방향을 가이드한다. 이를 통하여, 고객들에게 안정적이고 신뢰성 높은 서비스 프로덕션을 제공한다.

서비스 제품을 개발하는 일도 중요하지만, 고객에게 안정감 있는 서비스를 배포하여 운영하는 일도 중요하다. (수시로 종료되는 어플리케이션을 믿고 사용하는 고객들은 없겠죠? 특히 개인정보에 민감한 서비스일수록)

DevOps 엔지니어가 사용하는 대표적인 CI/CD 툴로는, Jenkins / Travis CI / Bamboo 등이 있다.

Related Posts

https://itholic.github.io/qa-cicd/

https://artist-developer.tistory.com/24

https://engineering.linecorp.com/ko/blog/build-a-continuous-cicd-environment-based-on-data/