빌드, 배포, CI/CD 개념 정리

기본적인 개념 정리가 필요할 것 같아서 기록하는 글.

netlify와 vercel을 비교하려고 구글링하다가 CI/CD를 알게 되었는데, 상반기에 정보처리기사 필기시험 준비하면서 책에서 얼핏 본 기억이 나서 오랜만에 책을 펼쳐봤다. 결론부터 말하자면 '빌드 자동화 도구'를 설명하는 파트에서 잠깐 스치듯 지나간 단어였다.😂

---

소프트웨어 패키징

모듈별로 생성한 실행 파일들을 묶어 배포용 설치 파일을 만드는 것.

소스 코드는 관리를 위해 기능별로 모듈화하여 패키징하고, 사용자 중심으로 진행한다.

소프트웨어 패키징 순서

1. 기능 식별 : 코드의 기능 확인
2. 모듈화 : 확인된 기능 단위로 코드 분류 및 모듈화 진행
3. 빌드 : 모듈 단위로 실행 파일을 제작하는 것
   또는 소스코드 파일을 컴퓨터가 실행 가능한 소프트웨어로 변환하는 과정
   (코드 컴파일 ~ 정적 파일 번들링 ~ 애플리케이션 의존성 관리 ~ 리소스 병합 ~ 배포 패키지 생성의 순서로 진행)
4. 사용자 환경 분석 : 사용될 환경이나 최소 운영 환경(운영체제, CPU, RAM) 정의
5. 패키징 및 적용 시험 : 빌드된 실행 파일들을 정의된 환경에 맞게 배포용으로 패키징하고, 정의된 환경과 동일한 환경에서 패키징 결과를 테스트하고 불편사항을 사용자 입장에서 확인
6. 패키징 변경 개선 : 확인된 불편사항에 대한 변경 및 개선 작업 진행
7. 배포 : 배포 수행시 오류가 발생하면 개발자에게 전달하여 수정 요청

---

CI/CD란?

용어를 설명하기에 앞서서, CI/CD 파이프라인이 왜 필요한지부터 설명해보려고 한다.

여러 블로거들이 설명해주신 글을 읽고, 효율적인 업무방식이라고 생각했다.

일단 우리가 아는 보통의 개발과정은,

1. 개발자들이 코드를 작성하여 개발한다.
2. 각자의 feature 브랜치에 코드를 push한다.
3. 각자 코드를 git에 올리고 통합(merge)한다.
4. 에러가 발생하여 디버깅하고 코드를 수정한다.
5. 1~4의 과정을 반복한다.
6. 에러 해결하여 배포하는데, 배포과정도 개발자가 직접 진행하니까 시간이 오래 걸린다.

소규모 프로젝트라면 이렇게 할 수도 있겠지만, 실무에서 규모가 큰 프로젝트를 진행하는데 매번 개발자가 수정부터 배포까지의 과정을 직접 수행하는건 작업의 효율성이 떨어진다. 하지만 CI/CD가 있으면,

1. 개발자들이 코드를 작성하고 개발하여 feature 브랜치에 push한다.
2. CI 서버에서 알아서 빌드~테스트 과정을 실행하고 결과를 전송한다.
3. 개발자들은 결과를 확인한 후에, 에러를 수정하고 코드를 main 브랜치에 통합(merge)한다.
4. main 브랜치에서 빌드와 테스트가 정상적으로 수행됐다면 CI가 알아서 배포한다.

즉, CI/CD 파이프라인은 개발자가 개발에만 집중하여, 더욱 효율적으로 작업할 수 있게 해준다.

---

CI (Continuous Integration)

CI는 '지속적 통합'이라는 의미로, 빌드/테스트 자동화 과정을 뜻한다.

애플리케이션에 대한 새로운 변경사항이 커밋될 때마다, 빌드 및 테스트가 이루어져 동작을 확인하고 문제가 없으면 레포에 통합(merge)된다. CI/CD 파이프라인을 구현하기 위한 첫번째 단계.

CI의 장점

• 테스트에 통과한 코드만 레포에 올라가므로, 해당 애플리케이션에 문제가 없다는 것을 보장할 수 있다.
• 여러 명의 개발자가 동시에 개발할 경우, 서로 충돌하는 문제를 해결할 수 있다.
• 변경사항이 레포에 올라오면 CI를 시작하고, CI 도중 문제가 생기면 실패하므로 코드의 오류를 파악하기 쉽다.

빌드 자동화 도구
빌드 과정을 포함하여 전처리(Preprocessing), 컴파일, 테스트, 배포까지 자동화하는 도구.
애자일(Agile) 개발 방법을 사용하면 하나의 작업이 끝날 때마다 모듈 단위로 나눠서 개발된 코드들이 지속적으로 통합되기 때문에, CI(지속적 통합) 개발 환경에서 유용하다.
대표적인 도구는 JAVA 기반의 Jenkins, Groovy 기반의 Gradle.

💡 협업 시에는 가능한 작은 단위로 나누어서 개발과 통합(merge)을 진행하는게 중요하다.
며칠씩 각자 개발하다가 통합시키면 충돌이 생길 가능성이 크고, 그걸 수정하는 시간이 더 오래 걸릴 수 있다.

---

CD (Continuous Delivery, Deployment)

CD는 '지속적 제공 (Continuous Delivery)'과 '지속적 배포 (Continuous Deployment)'라는 두 가지의 의미가 있다. CI 이후에 진행하는 과정이라는건 같지만, 어디까지 자동화하느냐에 따라 의미가 다르다.

지속적 제공 Continuous Delivery	CI로 코드의 빌드+테스트가 성공적으로 진행되었을 때, GitHub 같은 저장소에 자동으로 push되는 과정.
지속적 배포 Continuous Deployment	배포 준비가 된 코드가 자동으로 서버에 배포되는 것. '릴리즈(release)'라고도 한다. 지속적 배포는 빌드~테스트~배포 단계까지 자동화한다. 예를 들어 netlify나 vercel로 프로젝트가 배포된 뒤에 코드를 수정하고 push하면 몇 분 내로 반영되는 것을 생각해볼 수 있다. 참고로 netlify, vercel, github.io 등은 CI/CD가 자동으로 구축되어 있는 '서버리스 배포 플랫폼'이다.

지속적 배포의 장점

• 코드 변경에 오류가 없으면 수동 개입 없이 해당 변경사항이 자동으로 배포되어, 품질 저하 없이 최대한 빨리 사용자에게 새로운 기능을 제공할 수 있다.
• 개발자는 배포보다 개발에 집중할 수 있다.

---

참고자료

https://seosh817.tistory.com/104

https://jud00.tistory.com/entry/CICD%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C

https://yozm.wishket.com/magazine/detail/2184/