FTP 시절의 아찔했던 순간들
과거 FTP 배포 시절, 가장 아찔했던 순간은 로컬에서 작업한 소스 파일을 서버로 드래그 앤 드롭할 때였습니다.
무조건적인 덮어쓰기 방식은 개인 작업 시에는 그나마 통제 가능했지만, 협업 상황에서는 동료의 코드를 덮어버려 소스가 꼬이는 대참사가 빈번히 발생하곤 했습니다.
더 큰 문제는 로컬과 서버의 환경 차이였습니다.
내 컴퓨터에선 되는데 서버에선 안 되는 현상이 반복되자, 결국 위험을 무릅쓰고 실 서버에 직접 접속해 코드를 수정하는 라이브 코딩 상황까지 벌어졌습니다.
서비스의 안정성보다는 운에 맡기는 배포였던 셈입니다. 😭
시간이 흐르며 코드 형상관리의 중요성과 안전한 개발 환경에 대한 요구가 높아졌고, 많은 기업이 현대적인 워크플로우로 눈을 돌리기 시작했습니다.
우리 회사 역시 서비스 고도화를 위해 GitLab CI/CD 배포 자동화 환경을 구축했고,
이를 통해 단순한 '편리함'을 넘어 장애율 80% 감소'라는 압도적인 안정성을 확보하게 되었습니다.
⚙️ GitLab CI/CD 파이프라인의 3단계 흐름
1. Build (빌드 자동화)
가장 먼저 수행되는 단계.
개발자가 코드를 Push하면 GitLab Runner가 즉시 작동하여 Java 17 / Spring Boot 3.3.4 환경에서 빌드를 시작합니다.
로컬 PC 환경 설정과 상관 없이 동일한 환경에서의 실행 가능한 JAR 파일이 생성되어 누구는 되고 누구는 안되는 환경이 아닌 공통된 환경을 보장합니다.
2. Test (품질 검증)
빌드가 성공하면 곧바로 테스트 단계.
작성된 JUnit 테스트 코드가 자동으로 실행되며, 만약 단 하나의 테스트라도 실패하면 배포 파이프라인은 그 즉시 중단됩니다.
잘못된 코드를 push 하더라도 서버에 반영되기 전에 차단되어 FAIL이란 결과를 받게 됩니다.
오류를 배포 전 단계에서 확인하고 고칠 수 있습니다.
3. Deploy (배포 자동화)
테스트까지 통과한 검증 완료된 파일만이 실제 서버로 전송됩니다.
스크립트 기반으로 배포가 진행되기에 에러가 차단되며 롤백 기능도 갖추고 있어 이전 버전의 환경으로 쉽게 롤백도 가능합니다.
장애율 80% 감소를 이끈 3가지 결정적 요인
1. 휴먼 에러 이슈
FTP 시절에는 사람이 파일을 직접 옮기다 보니 파일 누락이나 잘못된 파일 덮어쓰기 같은 실수가 잦았습니다.
👉 GitLab CI/CD는 미리 정의된 스크립트에 따라 배포를 수행하기 때문에 배포 과정에서 사람이 개입하지 않아 허무하거나 어이 없는 장애 발생 빈도가 0% 로 되었습니다.
2. 배포 전 검사
과거에는 코드를 짰으니 일단 올리고 테스트 해봤다면, 이제는 테스트 코드가 통과되지 않으면 배포가 되지 않습니다.
👉 Spring Boot 3.3.4로 넘어오면서 엄격해진 빈(Bean) 주입이나 설정 오류들을 빌드 단계에서 미리 잡아냈습니다.
덕분에 서버가 켜지지도 않는 치명적인 장애를 배포 전에 확인하여 수정할 수 있었습니다.
3. 개발 환경 일관성
"내 컴퓨터에서는 잘 되는데 서버에서는 왜 안 되지?"라는 고질적인 문제때문에 환경을 맞추는데 시간이 소요됐습니다.
👉 GitLab Runner를 통해 서버와 동일한 환경에서 빌드를 진행하고, 컨테이너 기반으로 배포 환경을 통일했습니다.
환경 변수 하나 때문에 통일성이 무너지는 환경이 사라졌습니다.
| FTP (수동 배포) | GitLab CI/CD (자동 배포) | |
| 배포 소요 시간 | 20~30분 (수동 체크 포함) | 3~5분 (완전 자동) |
| 배포 시 장애 발생률 | 약 20% (5번에 1번꼴) | 4% 미만 (80% 이상 감소) |
| 장애 복구 시간(MTTR) | 원인 파악 후 재업로드 (수십 분) | 원클릭 롤백 (즉시) |
개발자가 본업에 집중할 수 있는 환경 구축 완료❗
결국 CI/CD 도입이 가져다준 가장 큰 장점은 압도적인 안정성이었습니다.
과거에는 배포 날마다 혹시 실수하지 않았을까 하는 불안함이 가득했지만, 이제는 그 마음이 확신으로 바뀌었습니다.
설령 실수가 발생하더라도 파이프라인이 운영 단계로 넘어가기 전 치명적인 에러를 미리 걸러주기 때문입니다.
자동화된 환경이 코드를 대신 검증해줌으로써 휴먼 에러를 원천적으로 차단했고, 우리는 견고해진 인프라 위에서 오로지 더 나은 기능을 고민하는 데에만 시간을 할애할 수 있게 되었습니다.
배포에 쏟던 에너지를 오롯이 개발 본연의 가치에 쏟을 수 있는 환경, 그것이 이번 고도화 프로젝트가 남긴 가장 값진 결과물입니다.
'Case Study > Modernization' 카테고리의 다른 글
| PHP 레거시 시스템을 Spring Boot로 전환하며 고민했던 기록들 (0) | 2026.03.12 |
|---|