1시간 걸리던 파일·DB 동기화를 버튼 하나로 — 수동 배포 자동화
내가 이 회사에 뽑힌 이유가 이 작업이었음. 사람이 손으로 하던 파일·DB 동기화 자동화.
서버 구성
서버가 세 덩어리처럼 보이는데 실제로는 두 대임.
- 개발 서버 — 앱 개발자들이 apk 파일이랑 음원·이미지 리소스(pak 확장자)를 올리고 지우면서 앱을 테스트하는 곳
- 운영 서버 — 스테이징이랑 실서버가 같은 서버에 있음. 근데 스테이징 서버가 따로 있는 게 아니라, 데이터가 두 벌 있음. 폴더도 DATA1/DATA2, DB 테이블도 DATA1/DATA2 이런 식으로 쌍으로 존재
라이브 배포라는 게 파일을 새로 올리는 게 아니라 서비스가 DATA1을 볼지 DATA2를 볼지 스위칭하는 원리. 폴더 경로랑 테이블만 바꿔치는 거라 스테이징에서 확인 끝나면 스위칭 한 번으로 바로 적용됨.
그래서 어느 쪽이 스테이징이냐는 고정이 아님. 지금 DATA1이 라이브면 DATA2가 스테이징이고, 스위칭하는 순간 DATA2가 실서버가 되면서 DATA1이 다음 스테이징이 됨. 동기화도 항상 “지금 라이브가 아닌 쪽”으로 함.
동기화했다고 바로 스위칭하는 것도 아님. 스테이징에서 라이브테스트를 한 번 더 함. 개발 서버에서 이미 테스트한 내용이지만 실서버랑 완전히 같은 환경에서 마지막으로 검증하는 단계. 여기까지 통과해야 흔히 말하는 “라이브”, 즉 스위칭을 함.
블루그린(blue-green) 배포라고 보면 생각하기 쉬움. 환경 두 벌 두고, 대기 중인 쪽에 새 버전 올려서 검증(라이브테스트)한 다음 트래픽만 스위칭하는 방식.
수동으로 하던 시절
앱 개발자들이 개발 서버에서 테스트를 끝내면 “이거 올려주세요” 요청이 옴. 그러면 사람이:
- 스테이징 파일들 수동 백업
- 개발 서버에서 변경된 파일 찾아서 복사
- DB 변경분은 row 데이터를 직접 delete 하고 insert
이걸 매번 손으로 했고, 숙련된 사람이 해도 1시간이 걸렸음.
테스트 환경 만들기
자동화 스크립트를 짜는 것보다 이게 더 문제였음. 이 프로젝트는 git도 없고, 운영 서버에서 바로 테스트할 수도 없는 환경.
- 일단 로컬에서 한 번 돌려봄
- Xen으로 가상 서버 두 대를 띄워서 운영이랑 똑같은 환경을 세팅
- 거기서 동기화 전체 흐름을 돌려보고 되는 거 확인한 뒤에 실제 적용
동기화 로직
버튼 하나 누르면 아래 순서로 돎.
- 시작하기 전에 스테이징 파일을
cp -r로 통째로 복사해서 백업해두고, 도중에 뭐 하나라도 에러 나면 그 백업으로 롤백함. 어중간하게 반만 덮인 상태가 제일 위험해서 이게 핵심 - 훅으로 협업 메신저에 동기화 시작·소요 시간·성공/실패를 쏘고 로그도 남김. 누가 언제 돌렸는지 채널만 봐도 알 수 있음
하는 김에 — 파일 다중 업로드
개발 서버 업로드가 파일을 한 번에 하나씩만 올릴 수 있게 돼 있었음. 앱 개발자들이 pak 파일 수십 개를 하나하나 올리고 있길래, 하는 김에 여러 개 선택해서 한 번에 업로드되게 바꿔줌.
결과
숙련자도 1시간 걸리던 작업이 버튼 클릭 하나로 끝남. 요청 올 때마다 사람이 붙어서 백업하고 복사하고 DB 만지던 게 없어졌고, 실패해도 롤백되니까 부담 없이 돌릴 수 있게 됨.