데브옵스(DevOps) / CICD란?

데브옵스(DevOps)와 CICD 개념에 대해서 알아보겠습니다.

 

 

1. 데브옵스란?

 

데브옵스라는 단어는 누구나 한 번쯤은 들어봤을 단어인 만큼 굉장히 많이 사용되는 단어지만 명확한 정의를 아는 사람은 많지 않다고 합니다. 

 

데브옵스가 생긴 이유는, 소프트웨어는 개발부터 고객에게 배포될 때까지 개발, 테스트, 인프라 등 다양한 과정을 거치게 됩니다. 다양한 과정을 거치는 만큼 회사가 조금만 커져도 자연스럽게 각 단계를 진행하는데 반복적이고 불필요한 작업과 오버헤드가 생기기 마련이죠. 결과적으로 배포 주기가 길어지고 배포되는 변경 사항이 커져 배포의 위험이 증가하고 고객에게 새로운 소프트웨어가 전달되기까지 오랜 시간이 걸리게 됩니다.

 

이러한 문제를 해결하기 위해 나온 개념이 데브옵스입니다. 데브옵스는 개발(Development)과 운영(Operation)의 합성어로, 개발과 운영을 하나로 합쳐서 일하는 철학, 도구, 환경, 문화 등의 조합을 나타냅니다.

개발부터 배포까지 모든 단계에 자동화와 모니터링을 도입해서 더 짧은 개발 주기, 더 많은 배포 빈도, 안정적인 소프트웨어를 배포하자는 목표를 갖고 있습니다.

 

데브옵스는 서버 구성, 배포, 테스트 등의 반복적이고 단순한 작업을 최대한 자동화해서 배포에 들어가는 비용을 최대한으로 줄이는 것부터 시작됩니다. 배포가 쉬워지면 작은 단위로도 배포를 여러 번 할 수 있게 되고, 결국 큰 장애가 발생하기 전에 문제를 바로 발견해서 해결할 수 있고 서비스를 민첩하게 운영할 수 있는 결과를 가져옵니다.

 

데브옵스를 실천하는 방식에는 여러 가지가 있습니다. 

지속적통합(CI), 지속적 전달/배포(CD), 마이크로 서비스, 커뮤니케이션 및 협업 등이 있습니다.

꼭 여러 부서로 나뉘어진 큰 회사에서만 필요한 것이 아니며, 인원이 몇 없는 작은 회사라도 개발부터 배포까지 불필요하고 반복적인 과정이 존재해서 시간이 소모된다고 느껴지면 데브옵스가 필요합니다.

 

 

- CI/CD/CD의 개념

	소스 코드 푸시	빌드&유닛 테스트	유닛 테스트	스테이징 서버 배포&테스트	운영 서버 배포&테스트
CI	자동	자동
지속적 전달 (Continous Delivery)	자동	자동	자동	자동	수동
지속적 배포 (Continous Deployment)	자동	자동	자동	자동	자동

 

 

---

 

 

2. 지속적 통합(CI)

 

CI라는 단어로 많이 사용되는 지속적 통합(Continuos Intergration)은 데브옵스의 소프트웨어 개발 방식 중 하나로, 개발자들이 코드를 메인 브랜치에 병합하는 시간을 최대한 앞당겨 버그를 빨리 찾을 수 있게 하는 것이다.

 

하나의 프로젝트를 여러 명의 개발자와 동시에 진행해본 사람이라면 코드를 메인 브랜치에 커밋할 때 병합 시 발생하는 코드 충돌로 곤혹을 치른 경험이 있을 것입니다. 보통 이런 문제가 생기는 이유는 개발자들이 로컬 혹은 다른 브랜치에서 오랜 시간 동안 많은 양의 코드를 작성하고 배포를 위해 마지막에 메인 브랜치에 병합하기 때문입니다. 너무 많은 코드를 한 번에 병합하다 보니 병합 시간도 오래 걸릴뿐더러 버그의 위험성도 매우 높아집니다. 그리고 일찍 개발된 작은 기능들이 있어도 가장 큰 기능들과 함께 기다렸다가 병합되기 때문에 개선점이 배포되는 시기도 자연스럽게 늦어집니다. 이러한 문제는 최신 버전의 서비스를 고객들에게 최대한 빨리 제공하자는 데브옵스의 목표와 맞지 않는다. 이런 문제를 해결하고자 하는 것이 지속적 통합이다.

 

지속적 통합이 도입될 경우 개발자들이 메인 브랜치에 코드를 커밋할 때마다 자동으로 전체 유닛 테스트를 실행하게 됩니다. 그리고 테스트가 실패한 경우에는 알림을 보내 해당 내용을 커밋한 개발자가 문제를 해결하게 합니다. 개발자들이 코드를 푸시하기 이전에 자신이 작성한 그리고 영향이 미쳤을 것이라고 예상하는 부분에 대해서는 유닛 테스트를 돌려 볼 것이지만 전체 유닛 테스트는 돌리는 데 시간도 오래 걸리고, 비효율적입니다.

따라서 개발자는 우선 메인 브랜치에 커밋을 하고 예상하지 못한 영향으로 인해 테스트 케이스가 실패한 경우에만 문제를 처리하면 됩니다.

 

그리고 작은 단위로 메인 브랜치에 커밋이 일어나다 보니 병합 시 발생하는 코드 충돌 문제에서 상당수 해방 될 수 있습니다. 또한 전체 테스트가 굉장히 빈번하게 돌아가기 때문에 버그도 굉장히 빨리 발견되고 처리됩니다.

 

다만 지속적 통합을 도입하기 위해서는 제품의 품질을 보장할 수 있다고 믿을 수 있는 자동화 테스트가 잘 작성돼 있어야 합니다.

 

 

---

 

3. 지속적 전달, 지속적 배포(CD) 

 

CD라는 단어로 많이 알려진 지속적 전달(Continous Delivery)과 지속적 배포(Continous Deployment)는 지속적 통합과 마찬가지로 데브옵스의 소프트웨어 개발 방식입니다. 지속적 통합에 이어 영역을 더 확장해서 유닛 테스트까지 완료된 코드를 운영 서버에 배포하기 전 단계인 스테이지 서버에 배포하고, 해당 서버에서 UI 테스트, 연동 테스트 등 다양한 테스트를 자동으로 진행합니다. 해당 테스트도 모두 통과했다면 이제 운영 서버에 배포하기 위한 준비를 하는데, 이때 수동으로 사람이 운영 서버 배포를 승인하는 것이 지속적 전달이고 운영 서버까지 자동으로 배포되는 것이 지속적 배포입니다.

 

지속적 전달과 배포는 지속적 통합과 비슷하게 개발자의 생산성을 향상하고 버그를 더 빨리 발견할 수 있다는 이점을 가져옵니다. 그리고 더 나아가 작은 기능 하나하나도 커밋만 일어나면 운영 서버에 자동으로 배포 혹은 준비 단계까지 가기 때문에 고객에게 최신 버전의 서비스를 최대한 빠르게 전달할 수 있다는 장점이 있습니다.

 

하지만 지속적 통합과 마찬가지로 자동화 테스트가 의미 있는 수준으로 잘 작성돼 있어야 한다는 전제가 있습니다.

 

---

출처 : 서비스 운영이 쉬어지는 AWS 인프라 구축 가이드