목록으로

5개월 플랜이 5일로 줄어든 AWS 마이그레이션 회고

약 5분 읽기😎 일상#Daily댓글로 이동

서버 이전, 그리고 야근

main
date
Feb 14, 2026
slug
daily-log-3
author
status
Public
tags
Daily
summary
서버 이전, 그리고 야근
type
Post
thumbnail
category
😎 일상
updatedAt
May 6, 2026 08:26 AM
지난 주말, IDC 환경에서 운영 중이던 DB 서버의 SSD 장애로 인해 4일치 데이터 유실과 서비스 중단이 발생했다.
 
문제는 단순 장애가 아니라, 해당 IDC 서버 업체가 우리 서비스의 지분 49%를 보유한 대주주임에도 불구하고 서버 관리 및 장애 대응이 사실상 전무한 상태였다는 점이다.
 
기존에도 매일같이 발생하는 DDoS 공격으로 정상적인 서비스 운영이 어려웠고, 이러한 상황이 반복되다 보니 작년 말부터 클라우드 환경으로 마이그레이션을 진행하여 올 하반기에 오픈하는 계획을 내부적으로 논의 하고 있었다.
이에 따라 올해 초부터 AWS 이전 프로젝트를 준비 중이었고, 원래 계획은 다음과 같았다.
  • 3 ~ 4월: 인프라 구축 및 서비스 이전
  • 5월: 테스트 및 버그 수정
  • 6월: 운영 서버 및 신규 서버 A/B 테스트 진행
  • 7월: 운영 서버 전환
그러나 주말 장애 이후, 대표님이 일요일 새벽 사내 메신저에 공지가 올라왔다.
 
“이번 주 내로 모든 서비스 AWS 이전 완료.”
 
5 개월 플랜이 워킹데이 기준 5일짜리 일정으로 바뀌는 순간이다… 세상에

갑작스러운 서버 이전 작업 시작

월요일, 출근하자마자 긴급 미팅을 진행했고, 각자 이전해야 할 영역을 나누어 작업에 들어갔다.
내가 맡은 업무는 다음과 같다.
  • Nginx 기반 웹 서버 환경 구축 (개발/운영)
  • 깃서버 이전
  • 레거시 PHP 서비스 마이그레이션
  • 크론탭 통합 컨테이너 작업
  • Redis 서버 구축 및 세션 연동
  • 기존 온프레미스 파일 서버 → R2 스토리지 전환
 
** 원래는 온프레미스 환경에 깃랩 서버를 띄워서 사용했지만 별 이점이 없어 보여 깃허브로 전환하자고 건의하여 해당 작업은 생략됨 (그치만,,, 이미 깃랩 서버 이전까지는 완료했던 상황)
 
초기에는 Ubuntu 22 버전으로 진행하였다.
우리가 사용하는 PHP 7.2 버전을 호스트 OS에서 바로 사용할 수 있었기 때문이다.
하지만 대표님이 “왜 24 버전을 안 쓰냐” 라고 하셔서, 24버전 부터는 PHP 7.2 버전이 설치조차 되지 않는다는 점을 설명했지만, 끝까지 OS를 24 버전으로 올리고 그 안에서 서비스를 옮기는 방향으로 다시 방향을 잡으라고 한다…ㅎ
 
22 버전에서도 서드파티 PPA를 사용해서 PHP 7.2 버전을 다운 받은 건데 참.. 도커 컨테이너 환경으로 구축하면 진행은 될 듯하여 기존에 작업해뒀던 웹서버 환경을 밀고 OS를 24로 다시 업그레이드 후 컨테이너 환경으로 PHP 환경을 구축하였다.
 
계속해서 서버 이전 작업을 진행 하고 있는데 메신저로 각 태스크 별 기간이 할당되어있었다..?
  • 9일(월) : 웹/DB서버/세션/API서버/iChart 서비스 이전 완료, STATIC 서버 통합
  • 10일(화) : 파일 업로드, 푸시 서버 완료
  • 11일(수) : 검색 서버 이전 완료
  • 12일(목) : 백업 설정, 각종 CS처리, 미지급 상품 지급, 작업 마무리 (늦어도 모든 서버 목요일까지 완료)
  • 13일(금) : 서버 이전 완료
 
기가찬다… 아무리 서버 이전 작업이 처음라지만 저게 맞나..? 저렇게 했을 경우 어떤 문제가 생길지 모르는데 바로 운영 반영이라니.. 너무 급하게 진행하는 서버 이전 작업이라 시작부터 불안하다.
 

야근 시작

매일같이 새벽 2시에 퇴근할거라고는 생각도 못 했다.
그주 내내 새벽 2시 퇴근이 반복됐다. (1시 40분쯤 되면 옆에서 대표님이 정리하라고 해서 그나마 강제 퇴근)
 
아무쪼록 첫 날, 서비스 마이그레이션 작업은 마무리하고 퇴근하는 길에 대표님께서 “이게 되네? 이번 주내로 서비스 전환이 끝나겠는데요???? 😆” 이런 늬양스로 말하는데 뭐지 싶었다. 진짜 뭐지..?
 
둘 째 날부터는 뭐 계획대로 되는 게 거의 없었다.
 
우리 서비스는 그동안 초고사양 서버 스펙에 의해 가려져 있던 문제들이 많은 상태였다. 코드 구조나 쿼리, 캐시 전략 같은 근본적인 문제는 그대로 둔 채, 인프라만 바뀌는 상황이었다.
 
위에서 언급한대로 초고스펙 서버 환경이라는것이 가능한 이유는 서버 회사가 우리 주주이기 때문에 서버 사양 관련해서는 지원을 해준걸로 알고 있다.
 
서비스 테스트 환경을 구축하고 사내 IP만 허용하여 서비스를 운영했을 때에는 정상적으로 된것 처럼 보였다. 그치만 서비스를 오픈하는 순간 점점 딜레이가 발생하더니 Timeout으로 서비스 장애가 발생하게 되었다.
 
이 부분에서 계속 발목이 잡히니 대표는 와서 소리를 지르더라, 느려지는 부분 하나 파악 못해서 서비스를 못 열고 있냐고.. 애초에 이럴거 생각 못하고 시작한 것도 아닌데 저렇게 쪼아되니 답답한 상황이였다. (이마저도 서버 이전 이틀 째되던 날이였다. 이틀.)
 
원인을 확인해보니,
  • 기존 서버 대비 최대 1/10 수준의 EC2 스펙
  • DB, API, WEB, CACHE, SEARCH 전부 저사양
  • MySQL 5 → 8 업그레이드로 인한 추가 이슈
  • 슬로우 쿼리 다량 발생
 
DB 커넥션 풀이 계속 물고 있어서 웹서버에서 응답을 받지 못하는 상황이 발생했고, 이렇게 병목이 지속되는 만큼 PHP 워커 풀 또한 초과하여 웹서버 부하도 발생하는 부분이 확인되었다. 이 부분을 수정하니 서비스는 정상적으로 운영되는 듯 보였으나 유저가 증가하면 증가할 수록 동일한 증상이 발생하였다.
 
결과적으로는 부하가 심한 쿼리가 다량 실행되어 DB에서 블록킹이 발생하여 클라이언트에서 응답을 받지 못하여 서비스가 지연되는 것이였다.
 
근데 아까 말했다싶히 서버 사양을 고사양으로 올려서 이 엘리언 코드가 어떻게든 돌아가는 환경을 만들어준거라 아마 서버 비용이 기존 측정한 것 보다 훨씬 더 나올 것으로 예상된다. 이건 뭐 나중에 다시 조정하고..
 
아무튼, 목요일까지 파일 구조도 전부 변경하였고 서비스를 전환하는데는 성공했다. 금요일은 대부분을 테스트 및 서버 장애 대응하는데 다 사용했다.
—
 
사실 이 기록은 특별한 이야기가 있는 건 아니다.
개발자로 전직 이후에 처음 경험해보는 대규모 서버 이전 작업과, 새벽까지 이어지는 야근이 겹쳐 꽤 힘들었지만 그래도 이 힘듬 마저도 새로운 경험이기에 이 때의 감정, 분위기를 남기고 싶어서 작성해본다.
 
예전 요리사로 지내면서 야근을 밥먹듯이 했었는데, 그때와는 느낌이 좀 달랐다. 요리사의 야근은 그냥 육체적으로 힘든거라면 개발자의 야근은 눈..과 정신이 너무 피로함이 느껴졌다.
그래도 이런 경험들 역시 개발자로서 겪어볼 만한, 그리고 언제가는 도움이 될 값진 경험이라고 생각한다.
우리 서비스는 연예 커뮤니티 관련 서비스이다. (사실 일상 글이 대부분이긴 하지만)
서버 이전 기간동안 사실상 3일 정도 서버가 닫혀 있었고, 어거지로 서버를 오픈한 순간에도 계속해서 장애가 발생하여 점검 ↔ 오픈이 반복되었다. 또한 점검 기간도 계속 늘어남에 따라 회원들이 느꼈을 피로감도 충분히 이해하고 있다.
 
그치만, 매번 오픈될 때마다 각종 게시판에는 우리 개발팀을 향한 비난 글이 쏟아졌고, 그중에서도 “개발탐이 무능하다” 라는 글을 봤을 때는 처음으로 게시글에 댓글을 달고 싶다라는 생각이 들었다.
물론 응원해주는 회원들의 글도 있었지만 눈에 띄는건 안좋은 글 인것 같다. 그래서 오픈 직후 그런 게시글을 보는게 무서워 들어가질 못했다.
 
후…
 
아마 2월은 서비스 안정화 위주의 작업이 계속 이어질 것 같다. 아직 못 옮긴 기능도 있고, 자잘하게 문제가 발생하는 부분도 분명히 있을 것이다.
 
2월에는 안정화가 끝나고 3월에는 본격적으로 서비스 리뉴얼 작업에 몰두 되었으면 하는 바램이다.