개발기초 팀에 CI/CD 파이프라인 처음 도입했던 경험 (겪었던 문제와 해결 과정)

통화연결 자동응답 처리 운영당시에는 오랫동안 개발자가 직접 로컬에서 빌드해서 서버에 파일을 올리는 수동 배포 방식을 쓰고 있었습니다. 배포할 때마다 실수가 생기는 일이 반복되면서, CI/CD 파이프라인을 도입하게 되었습니다. 처음 해보는 작업이라 예상보다 훨씬 많은 시행착오를 겪었습니다.

상황: 왜 도입이 필요했나

수동 배포 과정에서 [특정 파일을 빠뜨리고 올리거나 / 배포 순서를 착각해서 오류가 발생하는] 일이 반복됐고, 배포할 때마다 담당자가 긴장 상태로 진행해야 했습니다. 이 부담을 줄이기 위해 자동화 도입을 결정했습니다.

문제 1: 어떤 도구를 선택할지부터 막막했다

[Jenkins / GitLab CI / GitHub Actions] 등 선택지가 여러 개였는데, 각각 장단점을 판단할 만한 경험이 없어서 결정하는 데만 꽤 시간이 걸렸습니다.

해결: 완벽한 선택을 하려고 하기보다, [기존에 쓰던 형상관리 도구와 잘 맞는 것 / 팀원들이 이미 어느 정도 써본 적 있는 것]을 기준으로 먼저 하나를 정하고 시작했습니다. 처음부터 완벽한 선택을 하려다 보니 진행이 안 됐는데, "일단 시작하고 개선하자"는 쪽으로 방향을 바꾸니 진행이 됐습니다.

문제 2: 빌드는 성공했는데 배포 이후 서비스가 정상 동작하지 않았다

파이프라인 자체는 문제없이 돌아갔는데, 막상 배포된 서버에서 [환경변수 설정 누락 / 설정 파일 경로 차이] 때문에 서비스가 제대로 뜨지 않는 문제가 있었습니다.

원인: 로컬/개발 환경에서만 존재하던 설정값들이 파이프라인에는 반영되어 있지 않았습니다. 수동 배포할 때는 담당자가 매번 직접 챙겨주던 부분이었는데, 자동화하면서 그 과정이 빠진 것이었습니다.

해결: 환경별로 필요한 설정값을 전부 정리해서 별도로 관리하고, 파이프라인에서 배포 단계마다 해당 환경의 설정을 명시적으로 주입하도록 구성했습니다.

문제 3: 배포 실패 시 원인을 못 찾아서 헤맸다

파이프라인이 처음 실패했을 때, 로그를 어디서 봐야 하는지조차 몰라서 원인을 찾는 데 오래 걸렸습니다.

해결: 실패 시 알림이 [슬랙 / 메신저]로 바로 오도록 설정하고, 실패 로그의 핵심 부분만 요약해서 함께 전송되도록 구성했습니다. 이후로는 실패 원인을 훨씬 빠르게 확인할 수 있게 됐습니다.

마무리하며

CI/CD를 도입하면서 느낀 건, 자동화는 도입 자체보다 "기존에 사람이 암묵적으로 하던 일까지 전부 파이프라인에 옮겨 담는 과정"이 핵심이라는 점이었습니다. 처음에는 번거롭게 느껴졌지만, 지금은 배포할 때 느끼던 긴장감이 훨씬 줄었습니다.

아직 수동 배포를 하고 계신 팀이 있다면, 완벽한 파이프라인을 처음부터 만들려 하지 마시고, 가장 반복적이고 실수가 잦은 부분부터 하나씩 자동화해나가시는 걸 추천합니다.