운영 로그로 선별한 레거시 API의 ECS 이전·통합

왜 바꿔야 했는가

기존 EC2 백엔드는 로그인과 인증을 포함한 공통 기능을 담당하고 있었지만, 오래된 코드와 부족한 문서 때문에 실제 사용 범위를 알기 어려웠습니다. 전체 기능을 그대로 다시 만드는 방식은 사용하지 않는 API까지 옮길 위험이 있었고, 인증·쿠키 같은 숨은 의존성을 놓치면 고객 요청이 끊길 수 있었습니다.

첫 ECS 이전 이후에는 또 다른 운영 문제가 생겼습니다. 새 백엔드와 상품·이용권을 다루는 백엔드가 같은 DB와 ALB를 사용하면서도 별도 ECS 서비스로 운영돼, 공통 초기화와 인증 구조를 중복 관리하고 있었습니다. 이미 한 번 옮긴 서비스를 그대로 유지하기보다 운영 구조가 달라진 시점에 다시 통합할 필요가 있었습니다.

무엇을 확인했는가

첫 단계에서는 운영 Nginx 로그를 상태 코드와 노이즈 요청으로 나눴습니다. 이전 후보 API에서 오류 응답과 노이즈 경로를 제외해 실제 이전 범위를 확정했습니다. 요청 경로뿐 아니라 DB 연결, JWT·쿠키 호환성, 고정 egress IP, cron과 롤백 조건도 함께 정리했습니다.

두 번째 단계에서는 두 NestJS 백엔드가 공유하는 bootstrap, DB 연결과 AuthGuard를 확인하고, 서로 다른 API 경로와 기존 비즈니스 로직은 보존할 수 있는지 검토했습니다. 중복된 테이블 entity는 이름 충돌 없이 옮길 경계가 필요했고, 트래픽은 서비스별 listener rule을 바꿔 되돌릴 수 있어야 했습니다.

어떤 선택을 했는가

처음부터 전면 재작성하지 않고 로그로 확인된 실사용 API와 인증 의존성만 NestJS·TypeORM 기반 ECS 서비스로 재구현·이전했습니다. 호출 계약은 유지하고 기존 EC2 직접 운영 구조를 팀의 공통 ECS 배포 기준에 맞췄습니다.

이후 통합에서는 공통 bootstrap, DB 연결과 AuthGuard만 하나로 합치고 기존 비즈니스 로직과 API 경로는 유지했습니다. 중복 entity는 namespace를 분리해 이식 위험을 줄였고, 두 기능을 한 번에 다시 설계하는 대신 운영 중복을 제거하는 데 범위를 맞췄습니다.

어떻게 전환하고 검증했는가

로그 분석, 마이그레이션 범위 결정, 코드 구현과 배포를 직접 수행했습니다. 첫 전환은 새 target에서 DB·인증·외부 통신과 주요 API를 확인한 뒤 Route 53 컷오버로 진행해 서비스 중단 없이 마쳤습니다.

후속 통합은 staging에서 기존 응답과 인증 흐름을 검증하고 listener rule을 전환한 뒤 production에도 같은 순서로 적용했습니다. rollback 가능한 라우팅을 유지한 상태에서 트래픽을 옮겼고, 전환이 안정된 뒤 기존 ECS 서비스를 제거했습니다.

이후 무엇이 달라졌는가

운영 요청 로그에서 이전 후보 API를 추린 뒤 실제 이전 범위를 좁히고, 필요한 의존성과 함께 NestJS·TypeORM 기반 ECS 서비스로 옮겼습니다. 고객 요청을 중단하지 않고 전환한 뒤, 운영 구조의 변화를 다시 검토해 해당 백엔드를 기존 상품·이용권 백엔드에 통합하고 별도 ECS 서비스를 정리했습니다.

두 작업의 핵심은 새 기술로 한 번 다시 쓴 데 있지 않습니다. 실제 사용 근거로 범위를 정하고 안전하게 전환한 뒤, 시간이 지나 중복이 된 구조를 다시 단순화하는 서비스 수명주기 전체를 책임졌다는 점입니다.

다시 한다면

첫 ECS 이전 시점부터 API별 호출량, 오류율과 종료 후보를 지속적으로 남겨 후속 통합의 판단 비용을 더 줄이겠습니다. 공통 인증과 초기화 코드는 별도 경계로 명확히 관리해 서비스가 분리되거나 합쳐질 때 비즈니스 로직과 함께 움직이지 않도록 하겠습니다.

다만 실제 운영 로그로 범위를 정하고, 각 전환을 되돌릴 수 있는 라우팅 단위로 나누며, 안정화 뒤 중복 인프라를 제거하는 접근은 그대로 유지할 것입니다.