Export Service를 ECS에서 NPE로 옮기며 배운 것
여기서 말하는 내보내기 서비스는 관리자 플랫폼에서 CSV나 유사한 산출물을 비동기로 생성하던 백엔드다. NPE는 사내 managed EKS 플랫폼으로, ECS와는 별개의 컨테이너 실행 환경이다.
NPE로 옮기면 뭐가 좋은가
ECS를 직접 운영할 때는 클러스터 관리, 태스크 정의, 서비스 디스커버리, 로드밸런서 설정을 팀이 직접 해야 했다. NPE는 이런 인프라 영역을 플랫폼 레벨에서 추상화해준다.
- 도메인 연결과 인증서 관리가 자동화된다 — 서비스를 등록하면 사내 도메인 라우팅과 TLS 인증서가 플랫폼 차원에서 프로비저닝된다.
- 사내 시스템 연동이 자동으로 구성된다 — 모니터링, 로깅, 보안 스캔 같은 공통 인프라가 서비스 배포 시 자동으로 붙는다.
- EKS 버전 업그레이드를 플랫폼 팀이 관리한다 — 쿠버네티스 버전 EOL 대응, 노드 업그레이드, API 호환성 검증을 서비스 팀이 신경 쓸 필요가 없다.
- 표준화된 배포 파이프라인 — 사내 CI/CD 파이프라인과 통합돼 있어서, 팀마다 배포 방식이 다른 문제가 사라진다.
ECS에서 직접 관리하던 것들을 플랫폼에 위임할 수 있다는 점이 전환을 검토한 가장 큰 이유였다.
왜 이 서비스부터 옮기려 했나
이 서비스는 기능 특성상 컨테이너 플랫폼 전환 효과를 확인하기 좋은 대상이었다. 요청이 큐에 쌓이고, 작업량에 따라 처리량을 조정해야 했고, S3나 메시징 같은 외부 자원 접근도 명확했다. 즉, 운영 특성이 비교적 잘 드러나는 서비스였다.
전환 과정에서 무엇이 함께 바뀌었나
| 축 | ECS 운영 모습 | NPE 전환 후 달라진 것 |
|---|---|---|
| 배포 단위 | 태스크 정의 기반 | 쿠버네티스 워크로드 기준 |
| 런타임 구성 | ECS 태스크 환경 변수 | NPE 플랫폼 표준 설정 |
| 권한 모델 | 태스크 역할 기반 | 서비스 어카운트 + IAM 역할 매핑 |
| 확장 방식 | 큐 적재량 기반 스케일링 | NPE 플랫폼 수준 오토스케일링 |
핵심은 서비스 코드를 새 플랫폼에 포장하는 순간 운영 기준도 함께 명시해야 한다는 점이었다.
POC에서 확인한 것
이미지를 안정적으로 빌드하고 실행
NPE 플랫폼 기준에 맞는 컨테이너 이미지를 만들고, 기본 동작이 정상적으로 되는지 확인했다.
환경 변수와 헬스체크 규칙 적용
NPE가 기대하는 운영 규칙(프로브, 리소스 제한, 환경 변수)을 선언형으로 설정했다.
외부 자원 접근 권한 재구성
S3, SQS 등 AWS 자원에 대한 접근을 NPE의 서비스 어카운트 기반 IAM 매핑으로 다시 구성했다.
실제 요청 처리 검증
큐 메시지를 수신하고 내보내기 파일을 생성하는 전체 흐름이 NPE 위에서 동작하는지 확인했다.
런칭을 막은 현실적 제약
이 서비스가 외부에 노출되려면 Akamai를 통한 도메인 라우팅이 필요했다. 하지만 기존 도메인 체계가 복잡하게 얽혀 있어서, NPE 위의 새 엔드포인트로 도메인을 연결하는 작업이 단순하지 않았다. CDN 레이어의 라우팅 규칙, SSL 인증서 관리, 기존 서비스와의 도메인 공유 구조가 모두 함께 고려되어야 했다.
결국 NPE 전환 자체의 기술적 장벽은 넘었지만, 인프라 바깥의 도메인/네트워크 체계가 전환의 마지막 관문을 막는 형태가 됐다.
이 POC가 남긴 것
- 무엇이 되는지를 확인했다: 서비스 코드와 빌드 파이프라인은 NPE에서 동작할 준비가 됐다.
- 무엇이 안 되는지를 확인했다: 도메인 체계와 CDN 레이어가 플랫폼 전환의 숨은 비용이라는 점을 드러냈다.
- 같은 패턴의 전환 참조점을 남겼다: 이후 다른 서비스도 NPE를 검토할 때 이 POC의 Terraform, 서비스 어카운트, 헬스체크 설정을 재사용할 수 있다.
컨테이너 플랫폼 전환은 서비스 코드를 옮기는 일로 끝나지 않는다. 이미지, 권한, 환경 변수, 헬스체크 같은 운영 규칙은 물론이고, 그 바깥의 도메인과 네트워크 체계까지 함께 움직여야 한다. 이번 POC는 “플랫폼은 준비됐지만 런칭은 아직”이라는 현실적인 지점을 드러냈고, 프로덕션 런칭을 위해서는 도메인/CDN 정리가 선행되어야 한다는 것을 확인했다.
다음 글에서는 이 전환 과정에서 가장 크게 다시 만진 영역 — IAM 정책을 어떻게 쪼개고 최소 권한 원칙으로 재구성했는지를 더 좁혀서 본다.