CI/CD

CI/CD는 Continuous Integration(CI)과 Continuous Delivery/Deployment(CD)를 통합해서 부르는 용어이다. CI/CD는 개발 과정에서 필요한 빌드, 테스트, 배포등의 과정을 자동화한다. CI/CD 자동화를 통해서 개발자들은 코드를 자동으로 테스트하고 배포할 수 있고, 이를 통해 효율적인 작업과 더 빠르고 더 자주 배포를 진행할 수 있게 된다.

CI

Continous Integration은 코드를 지속적으로 통합해나가는 것을 의미한다.
일반적으로 코드의 통합은 GItHub의 PR을 통해서 진행할 수 있다. 하지만 여기서 말하는 코드의 통합은 단순히 코드와 코드를 합치는 것 뿐만 아니라 코드를 테스트하고 유효한지 검사하는 확인을 포함한다.
코드를 통합할 때 가장 중요하고 걱정되는 부분은 "머지 후에 제대로 돌아갈까?" 이다. 이런 걱정과 의문을 매번 사람이 다 확인하는 것이 아니라 CI 과정에서 테스트를 실행하고 코드가 유효한지 검사한다. 만약 문제가 발생했을 경우 즉각적으로 피드백을 통해서 개발자가 문제를 확인하고 수정할 수 있게 만들어준다.

CD

Continuous Deployment는 CI 과정을 통해서 성공적으로 통합된 코드들을 실제 사용자가 사용하고 있는 Production 환경에 배포하는 것을 의미한다. CD는 Continous Deployment와 Delivery 두 의미로 모두 사용되는데 Continuous Delivery는 개발환경의 배포까지 자동화 된 것을 의미하며, Continous Deployment는 실제 사용자에게 제공되는 Production 환경까지의 배포를 자동화 한 것을 의미한다.

CI / CD 플랫폼의 종류

CI/CD는 일련의 과정을 처리하는 CI/CD 파이프라인을 구축함으로서 자동화한다. 개발자들은 이러한 파이프라인을 구축하고 모니터링 하기 위해서 이를 위한 CI/CD 플랫폼을 사용하는데 CI/CD 플랫폼의 종류를 구분하자면 크게 설치형과 클라우드형으로 나눌 수 있다.

CI/CD 파이프라인 또한 하나의 프로그램이므로 프로그램을 설계해두면 이를 실행할 컴퓨터가 필요하다. 설치형은 파이프라인을 구축하는 개발자가 직접 특정 컴퓨터에 CI/CD 플랫폼을 설치해서 활용하는 방법 이다. 대표적인 설치형 CI/CD 플랫폼으로는 Jenkins가 있다.

반대로 클라우드형같은 경우에는 CI/CD 플랫폼을 운영할 컴퓨터를 개발자가 직접 관리할 필요 없이 서비스 제공자가 클라우드에서 모두 운영해주는 형태 이다. 즉 클라우드형 CI/CD 플랫폼을 이용하면 별도의 컴퓨팅 자원에 대한 관리 없이 CI/CD 파이프라인의 구축에만 신경 쓸 수 있다. 다만, 컴퓨터에 직접 접근할 수 없고 플랫폼에서 제공해주는 수준까지만 할 수 있기에 세부적인 조정이 불가능하다는 단점이 있다.
대표적인 클라우드형 CI/CD 플랫폼의 예시로는 Travis CI, GitHub Actions 등이 있다.

CI/CD가 각광받는 이유

현재에는 어느정도 규모가 있는 개발팀의 경우 CI/CD를 구축하는 것이 보편적이다. 사실 CI/CD는 장점만 있는 것은 아니다. CI/CD를 구축하고 운영하기 위해서는 이를 구축하고 관리하기 위한 노력도 필요하며, CI/CD 플랫폼, 서버를 사용해야하기에 개발자가 직접 배포 과정을 진행하는 것 보다 비용도 많이 든다 는 단점이 있다. 그럼에도 불구하고 왜 CI/CD를 구축하려고 할까? 그 이유는 효율 때문이다.

소프트웨어는 하드웨어에 비해 상대적으로 변경하기가 쉽다. 그리고 기업에서는 항상 유저의 피드백을 통해서 프로덕트를 더 좋은 방향으로, 더 빨리, 더 자주 개선하고자 한다.
이런 상황에서 개발자가 직접 수동으로 배포를 하는 과정에 리소스를 쏟기보다 프로덕트의 개발 및 개선 과정에 더 많은 리소스를 투입하는 것이 효율적이다.
과거에는 하드웨어가 개발자의 몸값에 비해서 상대적으로 비쌌기 때문에 하드웨어를 효율화하기 위해서 개발자들이 노력했다면, 현대에는 기술의 발전으로 인해 하드웨어가 상대적으로 싸졌기에 비싼 인력인 개발자의 공수를 더 투입하는 것 보다 하드웨어의 사양을 증대시키거나, 필요한 PaaS 서비스들을 활용해서 개발자들이 핵심 가치를 창출하는 데 집중시키는 방향으로 산업이 발전하고 있다.
CI/CD는 이러한 상황에 맞춰서 그 효율이 입증되어서 각광받고 있는 것이다.

프론트엔드가 배포까지 알아야 할까?

흔히 개발을 처음 하는 입장에서는 “개발"이라고 하면, 특히 “프론트엔드 개발"이라고 하면 UI와 기능들을 코드로 개발하는 것이 업무의 전체라고 생각하기 쉽다. 하지만 개발자가 하는 개발 중에서 기능 개발은 전체 프로세스의 일부분일 뿐이다.

현대 IT팀에서 개발자는 기본적으로 제품의 기획 분석, 기능 개발, 배포 및 운영을 책임져야 하며, 나아가서 제품의 기획단에도 참여해서 개발적으로 어떻게 요구사항들을 풀어나갈 수 있는지, 유저의 피드백을 어떤 방식으로 수용하면 좋을지에 대한 의견도 내곤 한다.
배포 및 운영까지 나의 책임이란 생각을 가져야지만 전체 개발 과정을 보는 시야가 길러지고 그에 맞춰서 개발 일정을 조율하고, 어떤 식으로 하면 배포와 운영을 안정적으로 할 수 있을까?란 고민을 할 수 있게 된다.

물론, 프론트엔드 개발자는 상대적으로 백엔드, DevOps 개발자에 비해서 배포와 운영에 대한 부분보다는 FE단의 개발에 업무의 비중이 집중되어 있다. 하지만 프론트엔드 개발자에게도 기본적으로 배포를 하고 운영할 수 있는 능력은 요구되며, 나아가 추후 내가 개발한 프로덕트에서 특정한 문제가 생겼을 때 배포가 어떤 개념인지, 어떤 식으로 이루어져있는지를 전혀 모른다면 원활하게 트러블 슈팅을 할 수 없다.

이러한 이유들로 프론트엔드 개발자도 배포에 대한 기본적인 지식은 반드시 가지고 있어야 한다.