💡 CI/CD란?

CI와 CD는 각각 지속적인 통합, 그리고 지속적인 제공[배포]을 의미한다. 이는 개념만 두고 보자면 자동화와 직접적 연관이 없다. 그런데 우리가 일반적으로 묶어 말하는 CI/CD는 항상 '자동화'의 개념이 따라 붙는다. 자동화의 개념이 붙는 배경이 무엇인지, CI와 CD의 정확한 의미와 과정을 자동화 개념과 함께 알아보자.

---

📌 CI (Continuous Integration)

CI의 의미

Continuous Integration은 지속적인 통합이라는 의미이다. 애플리케이션의 버그 수정이나 새로운 코드 변경이 주기적으로 빌드 및 테스트되면서 공유되는 레파지토리에 통합(merge)되는 것을 의미한다.

CI가 왜 중요해?

예시를 들어 생각해 보자. 개발자들이 하나의 프로젝트를 진행하고 있으며, Git 등을 사용하고 있다. 또한, 그 프로젝트에 2명 이상의 개발자가 참여하고 있다.

그렇다면 여기서 개발자들이 빈번하게 merge하지 않고, 2일 3일 혹은 더 오랜 기간동안 개발을 진행하다가 며칠동안 작업한 많은 코드들을 한 번에 merge한다면 어떻게 될까?

당연히, 충돌되는 코드가 많이 생겨날 것이다. 이렇게 된다면 새로운 기능의 코드를 작성하는 시간보다, 충돌하는 많은 코드들을 수정하는 데에 시간이 더 오래 걸릴 수 있다. 그리고 이는 좋은 방향이 아니다.

그렇기에, 가능한 작은 단위로 나누어서 주기적으로 빈번히 개발하고 계속해서 통합하여 나가는 것이 중요하다.

빈번하게 merge하는 경우, 그 흐름은 다음과 같겠다.

1. 개발자들은 계속해서 관리 시스템에 통합한다.
2. 통합한 코드가 제대로 동작하는지 빌드 및 테스트를 진행한다.
3. 문제가 발생하면 해결한다.

CI와 자동화

위의 단계는, "귀찮다" 라는 치명적인 단점이 있다.
빈번하게 통합해줄 때마다 진행해야 하는 과정이기에, 한 번에 몰아서 빌드, 테스트를 진행하는 그 시간보다 훨씬 오래 걸리는 것도 있다.

물론 한 번에 테스트해서 문제가 생긴 코드들을 하나하나 다 고치는 것보다는 결과적으로 문제 해결이 빠르고 좋은 방법일지라도, 당장은 귀찮은 작업인 것이다.

여기서 "그러면, 굳이 사람이 할 필요가 없지 않아?" 하는 생각에, 자동화의 개념이 따라 붙는다. 이것이야말로 똑같이 반복되는 귀찮은 작업을 하지 않으면서도, 주기적인 merge로 충돌은 최소화하는 편한 방법인 것이다 :>

자동화되었을 때의 과정

1. 개발자들은 계속해서 관리 시스템에 통합한다.
2. (빌드&테스트 자동) 문제가 생기면 확인해서 해결한다.

CI의 장점

• 코드의 검증에 들어가는 시간이 줄어든다.
• 개발의 편의성이 증가한다.
• 항상 테스트 코드를 통과한 코드만이 레포지터리에 올라가가기 때문에, 좋은 코드 퀄리티를 유지할 수 있다.

---

📌 CD (Continuous Delevery)

CD의 의미와 자동화

지속적인 제공(Continuous Delivery) 과 지속적인 배포(Continuous Deployment)의 의미가 있다. 이 두 용어는 상호 교환적으로 사용된다.

CI에서 빌드 및 테스트가 진행된 후에, 배포 단계에서 release할 준비 단계를 거치고 문제가 없는지 검증하는 팀이 검증을 한다.

그 후에 결론이 "이제 사용자들에게 서비스를 제공해도 되겠다!" 라고 나서 배포를 수동적으로 진행하는 것이 continuous Delivery, 지속적인 제공이다.

또한, 위와 같이 배포한 준비가 되자마자 자동화를 통해 배포를 진행하는 것을 Continuous Deployment, 지속적인 배포이다.

CD를 적용한 후의 흐름
1. CI를 적용하여 코드를 검증한다.
2. 배포 환경과 비슷한 곳에서 검증을 진행한다.
3. 검증된 소프트웨어를 실제 환경에 배포한다.

CI와 CD는 어느 정도를 자동화할지에 따라 조금씩 달라지기에, CI/CD라고 해서 모두 같은 것은 아니고, 회사 혹은 팀마다 그 정도가 달라진다.

지속적 배포의 사례

지속적 배포의 가장 흔한 사례가 Github Pages 이다. 지정해둔 디렉터리에 정해진 방식에 따라 잘 커밋하기만 하면, Github Pages가 알아서 해당 파일을 잘 번들링해서 Github Page 서버에 업로드한다. 이렇게 자동으로 인터넷에 배포가 되는 것이다. 이로써 결과물을 직접 공유할 수도 있고, 주변으로부터 빠르게 피드백도 받을 수 있다.

*번들링 : 여러 파일을 하나로 결합하는 작업 (주로 웹 및 프론트엔드 개발에서 사용하는 용어)

CD의 장점

• 개발자는 배포보다는 개발에 더욱 신경 쓸 수 있도록 도와준다.
• 개발자가 원클릭으로 수작업 없이 빌드, 테스트, 배포까지의 자동화를 할 수 있다.
• 휴먼 에러(Human Error)를 방지할 수 있다. 특정 과정을 생략하거나 다르게 진행하여 오류가 발생하는 것을 막고, 전체 배포 과정을 매번 일관되게 진행하는 구조를 설계함으로써 휴먼 에러 발생 가능성을 낮춘다.

---

CI/CD 파이프라인과 DevOps

전체 배포 과정은 다음과 같다.

개발자가 코드를 원격 저장소에 올리면, 그 코드가 빌드 및 테스트와 릴리즈를 거쳐 배포 서버로 전달 된다. 배포 서버에 도달한 빌드된 코드는 애플리케이션 서버로 최종 배포가 완료 되고, 그 결과물을 유저가 직접 확인하게 된다.

여기서 우리가 '자동화'를 고려하는 부분은 보통 코드가 빌드되면서 최종적으로 배포가 되는 단계까지이다. 이 부분을 지속적인 통합 및 배포를 위하여 일련의 자동화 단계로 만드는데, 이것을 파이프라인을 구축한다고 표현한다.

파이프라인의 분리

*파이프라인(Pipeline) : 배포에서 이 용어는 소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조를 뜻한다.

파이프라인을 여러 단계로 분리할 때, 대표적으로 쓰이는 세 가지 단계는 다음과 같다.

• Source 단계: 원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우, 이를 감지하고 다음 단계로 전달
• Build 단계: Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공하며, Build 단계를 거쳐 생성된 결과물을 다음 단계로 전달
• Deploy 단계: Build 단계로부터 전달받은 결과물을 실제 서비스에 반영

파이프라인의 단계는 필요에 따라 더 세분화되거나 간소화될 수 있고 DevOps를 전문으로 학습하는 경우 아래와 같이 파이프라인의 단계를 세분화해서 나누기도 한다.

CI/CD 파이프라인 구성 요소
빌드 (소프트웨어 컴파일)
테스트 (호환성 및 오류 검사)
릴리스 (버전 제어 저장소의 애플리케이션 업데이트)
배포 (개발에서 프로덕션 환경으로의 변환)
규정 준수 및 유효성 검사

데브옵스 DevOps

| Development + Operation

-> 개발담당자와 운영담당자가 연계하여 협력하는 개발 방법론

즉, 시스템 개발자와 운영을 담당하는 정보기술 전문가 사이의 소통, 협업, 통합 및 자동화를 강조하는 소프트웨어 개발 방법론이다. 이러한 데브옵스의 개념은 애자일 소프트웨어(Agile software) 개발과 CI/CD 개념과도 관련이 있다.

*애자일 개발 프로세스 : 짧은 일정 주기에 따라 계속해서 프로토타입을 형성하고 요구사항에 따라 즉시 개발 및 적용하는 개발 방법

데브옵스를 적용하기 위해서 구축하는 것이 바로 CI/CD 파이프라인인 것이다. 즉, CI와 CD의 자동화를 통해서 개발부서와 운영부서가 함께 상호 협력하며 소프트웨어를 개발하고 운영해나갈 수 있다.

데브옵스 장점

• 속도 : 작업 속도가 빨라지면서 시장 변화에 더 잘 적응하고 효율적으로 비즈니스 성과를 창출할 수 있다.
• 신속한 제공 : 새로운 기능의 릴리스와 버그 수정 속도가 빨라질수록 경쟁 우위를 차지할 수 있다.
• 안정성 : 애플리케이션 업데이트와 인프라 변경의 품질 보장, 지속적 통합 및 지속적 전달과 같은 방식을 통해 변경 사항이 제대로 안전하게 작동하는지 테스트 가능하다.
• 협업 강화 : 개발자와 운영 부서 간의 협력을 통해 효율적으로 일하는 팀이 구축 가능하다.
• 보안 : 자동화를 통해 규정 준수에 용이, 세분화된 제어 및 구성 관리 기술을 사용할 수 있다.