CI/CD(Continuous Integrationand Delivery)는 소프트웨어 구축 및 테스트, 배포 방법을 완전히 변화시키고 있습니다. CI/CD툴은 이러한 프로세스를 자동화하여 오류 발생률을 줄이고 워크플로우를 최적화합니다. 각 개발 단계를 거치는 동안 프로세스 전반에 걸친 자동화된 테스트를 통해 코드의 오류를 포착하고 롤백을 시키기까지 합니다.
이런 CI/CD툴 사용은 지속적으로 증가할 것이고, 이에 따라 소프트웨어 개발 방식도 개선될 것입니다. 배포는 더이상 연간, 분기별 또는 월간 이벤트일 필요가 없습니다. CI/CD를 통해 DevOps 팀은 하루에 여러 번도 배포할 수 있어졌기 때문입니다.

CI/CD의 10가지 장점을 알아보세요
CI/CD에 대한 개략적인 설명에 이어, 그 이점을 간략히 살펴보겠습니다.
1. 핸드오프 감소
개발 파이프라인에서 핸드오프가 감소할수록, 장애 지점이 줄어들어 프로세스가 간소화됩니다.
2. 개발 속도 향상
CI/CD를 통해 모든 개발 단계가 더욱 빨라집니다. 프로세스 전반에 걸쳐 반복 속도가 빨라져 모든 팀의 효율성이 향상되고 개발자는 다음 프로젝트로 마음 놓고 넘어갈 수 있습니다.
3. 더 많은 배포
2주 또는 그 이상에 한 번씩 진행했던 릴리즈를, 이제 하루에 6번 이상까지도 할 수 있습니다.
4. 더욱 빠른 테스트
개발 워크플로우에서 시간이 많이 소요되는 부분 중 하나가 제거되고 개발자는 다른 고부가가치 프로젝트를 작업할 수 있습니다. 자동화된 테스트를 통해 피드백을 더 빨리 받음으로써 팀은 개발 중간 단계나, 최악의 경우엔 최종 릴리즈에서 버그를 찾는 불상사를 줄이고 일찍 문제를 바로잡을 수 있습니다.
5. 버그 감소
개발 프로세스 전반에 걸친 자동화된 테스트를 통해 버그가 발생할 때마다 버그를 잡아서 마스터로 올려지지 않게 롤백됩니다. 이를 통해 전반적으로 코드 품질을 개선하고 모든 릴리즈가 의도한 대로 작동합니다.
6. 컴플라이언스 향상
컴플라이언스 처리를 개발 과정에 통합하여 컴플라이언스 되지 않은 애 플리케이션을 릴리즈할 위험을 줄일 수 있습니다. 자동화된 컴플라이언스통해 감사를 더욱 쉽게 완료할 수 있으며, 비용이 많이 드는 실수(특히 고규제 산업에서)를 방지할 수 있습니다.
7. 혁신에 더 많은 시간 투자
인테그레이션 유지 보수 및 차별화되지 않은 IT 지출에 소요되는 시간이 줄어들어 리소스를 다른 곳으로 할당할 수 있습니다.
8. 개발자들의 높은 만족감
개발자는 버그가 있다는 것을 알게 될 때까지 몇 주 동안 기다리지 않고 자신 있게 작업하고 신속하게 문제를 해결할 수 있습니다.
9. 오버헤드 비용 절감
코드를 개발자들이 수동으로 배포하거나 테스트하려면 더 많은 개발자가 필요하고 이는 예산에 큰 고정 비용이 됩니다. 자동화된 워크플로우는 수동 작업을 줄이고 예산을 더 효율적으로 만듭니다.
10. 일관된 프로세스
개발 워크플로우에 더 많은 자동화 기능이 있다는 것은 프로세스의 한 단계도 누락되지 않는다는 것을 의미합니다. 빌드는 보다 일관적이고, 새로운 개발자 교육이 더 용이해지며, 조직은 이러한 빌드가 구축되는 방법과 출시되는 시기를 더 잘 통제할 수 있습니다.
최적의 CI/CD 툴을 사용하고 계십니까?
생산성 속도를 정확히 측정하려면 일부분이 아닌 전체 SDLC 를 평가해야 합니다. SW 기술 전문가 Gary Gruver 가 자신의 저서 <기업 내 개발 및 운영팀 신설 및 확장>에서 제안한 바에 의하면, 이는 개발 조직에서부터가 아닌 애초에 새로운 기능을 만들도록 한 아이디어 그 자체에서 시작하는 게 낫습니다. 깃랩의 SDLC 를 한 개발자의 관점에서 분석하기 시작하는 것이죠. 즉,첫 번째 아이디어에서 시작해 개발, 테스트 환경, sw 생산으로 이어져야 합니다. 아이디어 실행을 위해 수행해야 하는 개별 단계는 무엇이 있을까요? 이 프로세스는 조직의 가치 흐름 방식을 정의하고 시스템의 병목 현상을 식별합니다.
원활한 CI/CD를 구축하기 위해서는 애플리케이션을 배포하는 데 필요한 모든 것을 갖추어야 합니다. 안타깝게도 CI/CD를 사용하는 많은 조직에서 사용하는 툴로 인해 최적의 워크플로우가 되지 않는 경우가 많습니다. 특히 문제가 발생할 경우 더욱 그 렇습니다.
파이프라인에 장애가 발생할 경우, 개발자는 특정 툴에 액세스할 수 없기 때문에 문제를 해결할 가시성이 부족할 수 있습니다. 때로는 두 팀이 서로 협력해야 하는 경우도 있습니다. 한 팀은 문제를 해결할 수 있고 다른 팀은 문제를 볼 수 있습니다. 두 팀 모두 액세스 권한이 있더라도 서로 다른 툴로 협업하고 있습니다. 예를 들어, JenkinsCI에는 코드 검토 메커니즘이 없기 때문에 팀들이 올바른 해결책을 만들기 위해 SCM과 CI 도구를 왔다 갔다 해야 합니다.
이런 복잡한 툴 체인을 유지하기 위해서는 복잡한 인테그레이션 작업을 거치고 정기적인 유지보수도 치러야 한다는 단점도 있습니다. 서비스 불안정성과 취약한 구성으로 인해 전체 라이프사이클에 영향을 미치는 중단이 발생하여 빌드가 시작하고 완료될 때까지 오랜 시간이 걸릴 수 있습니다. ‘단순’플러그인 업그레이드 또는 설치를 시도했다가 시스템 전체를 중단시키는 경우도 드물지 않습니다. Jenkins의 창시자 Kohuke Kawaguchi 는 깃랩 블로그에서 젠킨스가 사용하는 플러그인의 수가 너무 많아서 신뢰성이 떨어지고 여러 도구가 이어 붙여진 ‘프랑켄슈타인 플랫폼’으로 악명을 떨치는 등의 몇 가지 단점을 인정한 바 있습니다. 그의 솔직한 발언은 Jenkins가 이 문제를 적극적으로 해결하고 있다는 것을 보여주지만, 한편으로는 여전히 많은 DevOps 팀들이 너무나 잘 알고 있는 문제를 부각시켰습니다.
이런 인테그레이션이 지금은 대게 문제없이 이루어지고 있을 겁니다… 하지만 문제는 언젠가는 반드시 생기죠.