CI/CD 처음 도입해본 팀 프로젝트 경험
약 78초
팀 프로젝트에서 CI/CD를 처음 설정하면서 겪은 과정과 실제 효과를 서술
팀 프로젝트에서 매번 배포할 때마다 수동으로 빌드하고 서버에 올리는 과정이 반복되었습니다. 처음에는 귀찮긴 해도 괜찮다고 생각했지만, 팀원 4명이 각자 다른 방식으로 배포하다 보니 누가 어떤 버전을 올렸는지 알 수 없는 상황이 발생했습니다.
그때 GitHub Actions를 처음 사용해 보았습니다. main 브랜치에 푸시가 되면 자동으로 빌드하고 테스트를 돌리도록 설정했습니다. 처음에는 설정 파일 하나를 만드는 데 두 시간이 걸렸고, 테스트 실패 원인을 파악하는 데도 오랜 시간이 소요되었습니다. 그러나 한 번 돌아가기 시작하니 팀원 누군가가 실수로 테스트를 깨뜨리면 바로 알 수 있게 되었습니다. 이전에는 배포하고 나서야 문제를 알았지만, 이후에는 합치기 전에 확인할 수 있었습니다.
품질 향상에 가장 크게 기여한 것은 자동화가 아니라 '코드를 합치기 전에 확인하는 습관'이 생긴 것이었습니다. 도구 자체보다 프로세스가 바뀐 것이 진정한 변화였습니다. 지금도 프로젝트를 시작하면 초반에 이 설정부터 잡으려고 합니다.
이 결의 특징
팀 프로젝트 배포가 '각자 다른 방식, 누가 어떤 버전을 올렸는지 불명확'한 상태로 진행되다, GitHub Actions로 자동화했을 때 '실수를 합치기 전에 즉시 탐지'하는 흔적이 있습니다. 초기 설정에 2시간 투자, 테스트 실패 원인 파악에 오랜 시간이 필요했던 점입니다.
이 결이 통하는 자리
팀 배포 프로세스가 수동이고 각자가 다르게 하고 있을 때 살아 있을 때 통합니다. 도구 자체보다 '코드 합치기 전 확인' 습관의 변화에 영향력이 있을 때 강합니다. 초기 설정 비용을 감수하고도 장기적 비용이 낮아지는 지점에서 가치를 인식합니다.