개발

[Github Actions CI/CD와 AWS Blue-Gree] 도입기존 개발자 없이 문서화 하나 안되어있는 서비스의 개발을 맡았는데 서버가 터져버린 일

까다로운 ISTP 2025. 6. 26. 00:17
반응형

 

 

모든 개발자가 떠난 서비스를 물려받다

 

내가 온리유에 합류했을 때 상황은 이랬다. 모든 개발자가 이미 퇴사한 상태. 개발을 모르는 대표가 혼자 버티고 있었다.

인수인계? 그런 건 없었다. 도메인 호스팅 계정조차 찾는 데 이틀이 꼬박 걸렸다. 코드는 여러 개발자가 'MVP 빨리 만들기'라는 목표로 던져놓은 파편들뿐이었다.

2명이서 서비스를 처음부터 다시 만들기로 했다. 다만 기존 고객은 유지해야 했기에, 레거시를 하나씩 분석하며 점진적으로 전환하는 방식을 택했다.

 

 

진짜 문제는 배포 자체가 수동이었다는 것

 

당시 배포 프로세스를 보고 놀란 건, 아니 프로세스라고 부르기도 뭐한 수준이었다.

  1. EC2에 SSH로 직접 접속
  2. git pull
  3. npm build
  4. pm2 restart

끝이었다. 문서도 없고, 롤백 방법도 없었다. 그냥 사람이 감으로, 기억에 의존해서 하는 작업이었다.

 

 

그날 새벽, 서비스가 죽었다

 

그러다 드디어 사고가 터졌다.

새벽 1시, 평소처럼 배포를 진행했다. 그런데 서비스가 안 올라왔다. 완전히 죽었다.

당황해서 git reset으로 코드를 되돌렸다. 여전히 죽어있었다. 이상했다. 코드를 되돌렸는데 왜 여전히 안 되지?

차근차근 디버깅을 시작했다. 알고 보니 원인은 어이없을 정도로 단순했다.

빌드 결과물 경로가 바뀐 거였다.

  • 기존: dist/main.js
  • 변경: dist/src/main.js

개발 환경에서는 잘 돌아갔다. 하지만 프로덕션의 pm2는 여전히 옛날 경로를 보고 있었다.

 
javascript
module.exports = {
  apps: [{
    name: 'oniyou-api',
    script: 'dist/src/main.js',  // 이 한 줄 때문에...
  }]
};

 

 

ecosystem.config.js를 급하게 수정하고 pm2를 재시작했다. 겨우 서비스가 살아났다.

 

새벽 7시가 넘어서였다.

 

사실 솔루션은 간단했지만 결국 pm2  기반 JS 서비스에 대한 이해 부족, 기존 문서화 부족 등으로 쉽게 해결하지 못했고 근본적으로는 배포 사이클 자체가 불안한게 원인이었다. 

 

 

사실 우리가 원했던 건 거창한 게 아니었다

서비스는 복구됐지만, 이대로는 안 되겠다는 생각이 들었다. 1-2명이 운영하는 서비스가 매번 이런 위험을 안고 있다는 건 말이 안 됐다.

사실 우리가 원했던 건 단순했다. "배포해도 서비스가 안 죽는 구조"

거창한 쿠버네티스나 도커 스웜 같은 건 필요 없었다. 그냥 배포하다가 문제가 생기면 빠르게 되돌릴 수 있으면 됐다.

 

 

Blue-Green 배포로 구조를 바꾸다

그래서 Github Actions를 이용하게 빠르게 사전 빌드해서 AWS CodeDeploy와 AWS LoadBalancer를 이용한 Blue-Green 배포를 도입했다.

선정 이유는 명확했다. 현재 상황에서 구축할 수 있는 기술 중에 가장 안정적이고 빠르게 배포 가능하며 빠른 시일 내에 개발 환경에 적용시킬 수 있는 방법이었기 때문이다.

원리는 간단했다.

  • EC2 인스턴스 2개를 준비한다
  • 하나는 현재 서비스 중(Blue), 하나는 대기 중(Green)
  • 새 버전은 Green에 배포하고 테스트한다
  • 문제없으면 로드밸런서를 Green으로 전환한다
  • 문제 생기면? 그냥 Blue로 다시 돌린다

GitHub Actions가 코드를 빌드하고, CodeDeploy가 배포하고, health check가 확인하고, 로드밸런서가 전환한다. 사람이 하던 일을 시스템이 대신하게 만든 것뿐인데, 효과는 확실했다.

 

 

결국  얻은 건

30분 넘게 걸리던 배포가 10분 안에 끝났다. 하지만 진짜 중요한 변화는 따로 있었다.

더 이상 새벽 배포가 무섭지 않았다.

빌드 문제가 생기면 배포되지 않고 만약 문제가 생겨도 1분 안에 롤백할 수 있다는 확신. 그게 우리에게 가장 큰 변화였다.

 

 

새벽 1시의 그 사건이 우리에게 가르쳐준 건 이거였다. 제품의 진짜 속도는 빠른 개발이 아니라, 안정적인 구조에서 나온다는 것.

 

그래서 오늘도 우리는 '사람이 덜 고민해도 되는 구조'를 만들어가고 있다.

반응형