CI/CD: 비효율의 굴레를 끊어내는 여정

변수 위치만 바뀌었을 뿐인데…  신뢰가 무너진 순간

저는 열심히 프로젝트를 진행하던 중, 사소하지만 치명적인 실수를 저질렀습니다. 예를 들면 함수 호출 시 #hello(a, b)여야 할 변수 위치를 #hello(b, a)로 바꿔버린 어이없는 경험이었죠. 다행히 빠르게 찾아 해결했지만, 이 작은 실수는 제 코드에 대한 깊은 의심을 품게 만들었습니다.
문득 이런 생각이 들더군요. 만약 이 순간, 테스트 코드가 있었다면 어땠을까? 최소한 변수의 위치가 바뀌어 의도치 않은 결과가 발생했다면, 자동화된 테스트가 이를 즉시 잡아줬을 겁니다. 이런 기본적인 안전망조차 없다는 현실이 답답하게 느껴졌습니다.

---

반복되는 문제: "지금까지 일해왔던 방식은 틀렸다!"

비단 저의 실수 때문만은 아니었습니다. 협업 환경에서는 자잘한 문제들이 끊이지 않았죠. 동시 다발적으로 개발하다 보니 코드 충돌은 빈번했고, 빠른 개발 주기에 맞춰 움직이다 보니 "리뷰 시간이 아깝다"는 핑계로 코드 리뷰를 건너뛰기 일쑤였습니다.
더 큰 문제는 테스트 코드 작성 문화가 부재했다는 점이었습니다. 각자 본인의 로컬 환경에서만 동작을 확인하고 머지하는 일이 반복되다 보니, 다른 사람의 코드를 신뢰하기 어려워졌습니다. 결과는 어땠을까요? 나중에 코드를 이해하기 위한 히스토리 파악 시간은 물론, 숨어있던 버그를 찾아 헤매는 시간이 훨씬 길어지는 악순환이 반복될 뿐이었습니다.
이러한 경험들이 저에게 말해주는 바는 명확했습니다. "지금까지 일해왔던 방식은 일하는 시간만 증가시키고, 코드의 품질은 결코 높이지 못한다."

---

신뢰할 수 없는 개발 주기, 그 끝은 버그와 야근뿐

현재의 개발 방식은 아래와 같은 문제들을 야기했습니다.

• 코드 신뢰도 하락 및 개발 시간 증가: 코드 스타일이 통일되지 않고, 핵심적인 코드 리뷰와 테스트 코드 작성 문화가 부재하니 다른 사람이 짠 코드의 히스토리를 이해하기 어려웠습니다. 심지어 제가 짠 코드조차 며칠 뒤면 믿을 수 없게 되더군요. "과연 누가 이 코드의 품질을 검증해줄 수 있는가?"라는 근본적인 질문에 답할 수 없었습니다.
• 개발 외 업무 증가 (환경 문제): 각자 PC에서만 검증을 진행하다 보니, 막상 배포 단계에 이르면 환경 설정 문제가 불쑥 튀어나와 개발 외적인 업무 부담을 가중시켰습니다.

이렇게 신뢰할 수 없는 개발 주기 속에서 아무리 열심히 개발을 해도, 우리에게 남는 건 쌓여가는 버그와 끝나지 않는 연장 근무뿐이라는 씁쓸한 현실을 깨달았습니다.

---

CICD, 더 나은 개발 문화를 위한 변화의 시작

이러한 문제의식을 바탕으로, 저는 Gitlab CI/CD 파이프라인 도입을 구상하게 되었습니다. 개발 상태, 배포 상태 등을 한눈에 확인할 수 있는 CI/CD 도구는 개발팀뿐만 아니라 매니저 입장에서도 효율적인 프로젝트 관리를 가능하게 하는, 더할 나위 없는 솔루션이라고 확신했습니다. 일하는 사람이라면 누구나 효율적으로 일할 수 있는 방법에 대해 고민해야 한다고 믿었으니까요.
Gitlab CI/CD 파이프라인은 다음을 약속합니다.

• CI (Continuous Integration, 지속적인 통합): 애플리케이션 코드의 변경사항이 정기적으로 빌드 및 테스트(품질 검사 등)를 거쳐 공유 Repository에 병합되는 프로세스입니다. 버그가 없고 견고한 애플리케이션을 고객에게 전달하기 위한 초석이라고 할 수 있죠.
• CD (Continuous Delivery/Deployment, 지속적인 제공/배포): 개발이 완료된 코드를 배포하는 과정을 자동화하는 프로세스입니다.

전체적인 CI/CD 흐름은 다음과 같습니다.

1. 개발 후 배포해야 할 브랜치로 Pull Requests (PR)를 보냅니다.
2. 해당 PR에 대해 자동으로 빌드, 테스트가 진행됩니다. (이 단계에서 작성된 테스트 코드가 자동으로 실행되며 문제 발생 시 즉시 알려줍니다.)
3. 실패했다면 사유와 함께 알림을 즉시 전달합니다.
4. 배포해야 될 브랜치로 Merge가 된다면 이미지 빌드를 통한 배포가 됩니다.

---

현실의 벽: "귀찮을 뿐인데 굳이?"

저는 백엔드 개발자로서 개발 프로세스 개선에 기여하고 싶었고, 그 결과물로 Kubernetes와 Gitlab-runner를 활용하여 개발 서버 배포 자동화를 완성했습니다. 이제 남은 일은 이 새로운 시스템의 필요성을 회사 동료들에게 알리고 설득하는 것이었습니다.
 
하지만 현실은 그리 녹록지 않았습니다. 많은 분들이 회의적인 시선을 보냈죠. "지금도 조금 불편할 뿐이지, 수정하고 테스트를 반복하면 되는데 굳이?"라는 의견이 많았습니다. 사내 인터뷰를 진행했을 때도 의견은 반반으로 나뉘었습니다. "있으면 좋겠다"는 긍정적인 반응과 "없어도 된다"는 유보적인 반응이 공존했습니다.
 
그럼에도 저는 회사의 한 직원으로서 개발 프로세스 개선에 대한 필요성을 강하게 느끼고 이 일을 추진해왔습니다. 이제 남은 것은 이러한 노력이 단순히 저만의 성과가 아닌, 팀과 회사 전체의 생산성을 높이는 필수적인 변화임을 증명하는 것입니다.
 

작은 시작, 그리고 긍정적인 파급 효과

(2025.07.13 추가)
저는 포기하지 않았습니다. 계속해서 동료 인터뷰를 진행하며 CI/CD의 잠재적인 가치를 설명하고, 좋은 인상을 남겨주기 위해 제가 일하는 팀에서라도 CI/CD를 이용해 개발했던 프로젝트를 배포하며 그 효과를 직접 보여주기 시작했습니다.
이러한 노력 덕분일까요? 아직은 저와 같이 일하는 팀에서만 사용하고 있지만, 이제는 제가 속한 사업 부서에서 CI/CD 도입을 논의하고 있습니다. 작은 시작이었지만, 이러한 긍정적인 파급 효과가 더 좋은 결과로 이어질 것이라고 확신합니다.  이번이 시작점이 되어, 더 많은 개발 팀이 효율적이고 신뢰할 수 있는 개발 문화를 만들어가는 데 영감을 주기를 바랍니다.