글로벌 IT 프로젝트에서 경험한 CI/CD 실전 사례

CI/CD에 대해서는 사내 교육, 여러 개발 포스팅 등을 통해 접했고 이해는 되지만, 아직 실제 프로젝트에서 사용하지 않아 CI/CD의 역할을 실감하지는 못했습니다. 최근 진행 중인 프로젝트에서 고객사의 Salesforce Org에 직접 배포했다가 롤백을 당하는 경험을 하고, CI/CD 파이프라인의 역할을 제대로 이해했습니다.

 

CI/CD 파이프라인 필요성

개발계에서는 빠른 배포를 위해 CI/CD를 거치지 않고 직접 org에 배포하고 테스트를 했지만, 검증계로 넘어가면서는 변경 이력이 남지 않고 테스트 검증이 부족하다는 문제가 있었습니다. 특히, 글로벌 프로젝트에서는 여러 팀이 동시에 개발을 진행하기 때문에 코드 충돌 위험이 높기 때문에 여러 레이어의 검증계를 가지고, 프로덕션 배포 전까지 테스트를 진행했습니다. 이 과정에서 CI/CD 파이프라인을 활용하여 여러 검증계 org의 브랜치를 만들고, 검증 후 머지하는 방식으로 진행했습니다.

 

CI/CD 파이프라인 구성

최근 프로젝트에서는 Azure DevOps를 통해 CI/CD 파이프라인을 관리했습니다. Git을 기반으로 브랜치 전략을 수립하고, Pull Request 단계에서 자동으로 코드 검증이 이루어지도록 설정했습니다. 빌드 과정에서는 Salesforce DX(SFDX)를 활용하여 검증계에 배포하고, 테스트 실행 결과를 확인한 후 머지 여부를 결정합니다.

Azure DevOps의 Pipeline과 Release 기능을 활용하여 검증된 코드만 프로덕션에 배포할 수 있도록 설정했고, 실패 시 롤백할 수 있었습니다. 직접 CICD 파이프라인을 운영하는 것을 보니, 어떻게 배포 안정성을 확보하고, 여러 개발 팀이 동시에 작업하더라도 충돌 없이 효율적으로 진행할 수 있는지 알 수 있었습니다.

 

CI/CD 적용 후 변화

CI/CD 파이프라인을 활용한 후 가장 큰 변화는 배포 안정성과 협업 효율성의 향상입니다. 이전에는 배포 후 문제가 발생했을 때, 어디서 발생한 것인지 찾아서 복구하는 데 많은 시간이 소요되었지만, 이제는 자동화된 검증을 통해 사전 예방이 가능해졌습니다. 또한, 변경 이력이 명확하게 관리되면서 글로벌 팀과의 협업도 훨씬 원활해졌습니다.

CI/CD를 도입하기 전에는 단순히 배포 자동화 도구라고 생각했지만, 실제 프로젝트에서 경험해보니 개발 프로세스를 체계적으로 정리하고, 조직적인 협업을 가능하게 하는 핵심 요소라는 점을 실감하게 되었습니다. 처음부터 CICD 파이프라인을 이해하고 배포했다면, 롤백을 안 당했겠지만... 롤백 당해서 더 자세히 배운 것 같네요. 앞으로 프로젝트에서는 최대한 이상적으로 CI/CD 파이프라인을 최적화하고, 테스트 자동화까지 연계하여 배포 신뢰도를 높이는 방향으로 운영하는 것이 목표입니다.

 

읽을거리

- https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_ci.htm

Continuous Integration | Salesforce DX Developer Guide | Salesforce Developers