프로덕션 첫 배포 사고에서 얻은 교훈

사내에서 담당하고 있는 프로덕트는 프론트엔드는 S3를, 백엔드는 Elastic Beanstalk를 통해 배포한다. 배포 관련 정보는 이전 외주 담당자가 작성한 간단한 인수인계 문서에 적힌 명령어 몇 줄이 전부였다. 이러한 상황에서 내가 할 수 있는 건, 배포 가이드를 만드는 것이었다.

• 배포 전 점검 사항
• 환경 별 배포 명령어
• 배포 후 확인할 작업 등

배포 직전까지 배포 가이드를 보며 검토했다. 프로덕션 첫 배포를 마치고 반영한 기능이 제대로 동작하는지 확인하고 퇴근했다.

그 다음 날 출근 길에 사이트에서 최신 자료가 보이지 않는다는 제보를 받았다. 그러면서 프로덕션에서 데이터베이스 연결이 잘못된 것 같다는 이야기도 들었다. 피크 타임(오전 10~12시)까지 남은 시간은 대략 2시간이었다. 하지만 노트북이 없는 상황에서 해당 문제를 해결하는건 불가했다. 일단 사용자에게 공지를 올린다고 하시면서, 지금 사용하는 유저가 있을 수 있으니 사이트를 내라자고 하셨다. 모바일로 AWS 콘솔에 접속해 EC2의 Inbound Rule 80 포트를 비활성화했다. 그럼에도 캐싱된 데이터가 계속 보여 CloudFront를 일시적으로 비활성화했다.

일단 지금 문제 상황과 내가 한 행동, 예상하는 원인, 출근해서 확인할 정보를 노션에 적으면서 원인을 생각했다. 그렇게 써내려가던 중, 환경변수가 생각났다.

회사에 도착하고, 이동 중에 정리한 문서를 열고 하나씩 살폈다. 역시나 환경 변수 문제였다. 평소 개발 환경에서만 배포를 진행했기에, 프로덕션 배포 시 환경변수를 수동으로 바꿔야한다는걸 간과했다. 허탈한 마음으로 환경 변수를 프로덕션에 맞게 바꾸고 다시 배포했다. 하지만 변한 것은 없었다.

도저히 짐작가는 원인을 찾지 못해, 결국 이전 외주 담당자에 연락했다. 담당자 분이 코드를 보시더니, 내가 수정한 환경변수가 아닌 Elastic beanstalk 에서 사용하는 환경변수(environment.config)를 가리키셨다. 이 역시 배포 환경에 맞게 바꿨어야 했다. 처음 확인했을 때 환경 별로 분리되어있는 걸 보고, 자동화하지 않으면 언젠가 문제가 발생할 것 같았는데 현실이 된 것이다. 방대한 양의 버그 리포트에 우선순위가 밀려 미루다 까먹은 것이 문제였다. 일단 production 버전으로 환경 변수를 수정하고 다시 배포를 했음에도 그대로였다. 대체 왜?

처음 error.log를 보았을 때는 원인을 유추할 만한 내용이 없었는데 이번에는 다를까 싶어 확인했다. DB_HOST 값 사이에 불필요한 스페이스가 있다는 에러 메시지를 보고 지웠더니 최신 자료들이 보였다. 그 때가 11시 5분이었다.

순간 긴장이 풀리면서도 비슷한 일을 반복하지 않기 위해 오늘의 이슈와 관련된 모든 정보(원인과 시도했던 방법, 앞으로 할 일 등)와 환경 변수를 확인하라는 강조 문구를 적었다. 이 사태에 대한 원인을 아래와 같이 정리해보았다.

• 프론트엔드와 달리 백엔드에는 배포 자동화 스크립트가 없다는 것을 간과함
• 배포 후, 업데이트한 기능이 잘 돌아간다는 것만 확인함
• api가 production을 바라보고 있어 데이터베이스까지 생각하지 못함

즉, 백엔드 배포 자동화가 없던 점과 환경 변수 관리 소홀로 이번 일이 발생했다. 이를 통해 배운 점은 다음과 같다.

• GitHub Actions이나 Jenkins를 사용해 배포 자동화를 구축하자
• 사소한 내용이라도 일단 문서에 적자(혼자 일하는 현 상황에서는 더욱 중요하다)

이 과정을 통해 프론트와 백엔드의 배포 기준이 다르다는 것도 알았다. 앞으로 당장 해야할 일은 GitHub Actions으로 환경 별로 환경 변수 파일을 자동으로 업데이트하고 배포 스크립트를 추가하는 것으로 생각했다.

이 이야기를 전한 지인에게서 의외의 답이 돌아왔다. 일단 해당 이슈와 배포 프로세스 관련 정보를 최대한 꼼꼼하게 문서화하고, 쌓여있는 프로덕트 버그를 고치는 것이 더 중요하다고 하셨다. 그렇게 지금도 버그 수정과 기능 추가 작업을 하고 있다. 이번 일을 통해 배포 자동화와 문서화의 중요성을 다시 한 번 실감했다.