에잇퍼센트의 Kiro CLI 기반 Amazon ECS 현대화 여정

이 블로그는 에잇퍼센트와 AWS의 협업으로 작성되었습니다.

현업 운영을 병행하면서 2영업일 만에 레거시 서비스를 Amazon ECS로 전환하고, 월 운영 비용을 약 76% 절감할 수 있을까요? 에잇퍼센트는 AI 코딩 에이전트 Kiro CLI와 오픈소스 AI-Driven Modernization Prompt Sets를 결합해 이를 실현했습니다.

이번 글에서는 에잇퍼센트가 AWS Lift-On 프로그램의 지원을 받아, 소규모 백엔드 팀이 기능 개발과 장애 대응을 병행하면서도 Amazon EC2 기반 워크로드를 Amazon ECS Fargate로 전환한 과정을 공유합니다. 첫 번째 대상인 내부 API 서비스에서 검증한 워크플로우를 외부 메인 API 서비스에 그대로 재사용해 약 2주 만에 검증 단계까지 도달했고, 전환 이후에는 대상 서비스 기준 월 운영 비용 절감과 함께 언제든 부담 없이 릴리스할 수 있는 무중단 배포 체계를 갖추게 되었습니다.

에잇퍼센트 소개

에잇퍼센트 로고

에잇퍼센트는 2014년 출발한 개인 간(P2P) 금융 투자 플랫폼입니다. 2015년 국내 최초로 P2P 개인신용대출을 선보이며 중금리 대출 시장을 개척했고, 현재는 금융위원회 등록 온라인투자연계금융업자로서 2,000억 원 이상의 대출잔액을 운영하고 있습니다. 자체 개발한 AI 기반 신용·자산 평가 솔루션 E-index를 투자 심사에 활용하며, 개인신용대출 외에도 전월세보증금담보대출, 스탁론, 저축은행 연계투자 등으로 상품 라인업을 확장하고 있습니다. 에잇퍼센트는 2016년부터 AWS를 주 인프라로 사용해 왔으며, Amazon EC2·Aurora·ElastiCache·S3 등을 활용해 전체 플랫폼을 운영하고 있습니다.

프로젝트 배경

에잇퍼센트 백엔드는 수 년간 Amazon EC2 기반으로 서비스를 운영해 왔으며, 다음과 같은 구조적 한계를 인지하고 있었습니다.

구분	문제	현장의 목소리
배포 안정성	패키지 교체 타이밍에 따라 짧은 간섭 발생 → 배포 시점 신중히 선택	“배포를 피크 없는 새벽으로 잡아야 해서 릴리스가 계속 밀려요”
환경 일관성	인스턴스별 개별 설정 → 서버 간 설정 드리프트, 인프라 일부만 코드 관리	“staging이랑 production이 달라서 배포 후에야 버그가 보여요”
리소스 효율	단일 인스턴스(SPOF) + 피크 기준 고정 배치 (평균 CPU <10%)	“장애 나면 대안이 없고, 평소엔 서버비만 나가요”

문제의 본질은 기술보다 리소스였습니다. 소규모 백엔드 팀이 기능 개발과 외부 연동, 장애 대응을 동시에 처리하는 상황에서, 운영 서버 10대 규모의 ECS 전환은 기존 방식대로라면 수 개월 전담 스프린트가 필요한 규모였습니다. 이 과제는 분기마다 우선순위 회의에서 밀리며 기술부채로 누적되어 왔습니다.

여기에 더해 금융 서비스 특유의 환경은 전환 난이도를 높이는 요인이었습니다. 단 한 건의 트랜잭션 불일치나 짧은 서버 중단도 곧바로 금융사고로 이어질 수 있으며, 신용평가 기관·오픈뱅킹·전자서명·정부 API 등 수십 개 외부 엔드포인트와 끊임없이 통신하는 네트워크 의존성(전용선·VPN·인터넷 혼재)도 고려해야 했습니다.

AS-Is Architecture

에잇퍼센트 AS-Is 아키텍처 다이어그램

에잇퍼센트 전환 전(AS-Is) 아키텍처

해결 방식: AI-Driven Modernization 워크플로우

왜 Amazon ECS Fargate인가?

Fargate를 선택한 이유는 ① 서버 관리 오버헤드 제거 ② Graviton(ARM64) 단가 이점 ③ 태스크 단위 IAM Role로 최소 권한 적용 용이 ④ Auto Scaling 정책의 즉시 반영이었습니다.

항목	기존 (EC2)	전환 후 (ECS Fargate)
배포 방식	SSH 접속 → 수동 패키지 교체	CI/CD + Rolling Update + Circuit Breaker
스케일링	피크 기준 고정 배치	Target Tracking + Scheduled Scaling
장애 복구	수동 대응 (SPOF)	Multi-AZ 자동 복구, 자동 롤백
비용 구조	24/7 고정 과금	태스크 단위 종량 과금
운영 가시성	인스턴스 단위 CloudWatch	Container Insights 태스크 단위 메트릭

이번 현대화에는 몇 가지 전제가 필요했습니다. 현업 운영을 병행하면서도 최소 인력으로 빠르게 성과를 낼 수 있어야 했고, 첫 전환의 경험이 이후 대상에 그대로 적용되어 누적 가속이 가능한 재사용 표준 패턴으로 남아야 했습니다.

전환 패턴은 Replatform(Lift, Tinker, and Shift)을 선택했습니다. 실행 환경을 Amazon ECS Fargate로 이식하는 데 초점을 맞추고, Amazon Aurora PostgreSQL·Amazon ElastiCache for Redis·Amazon S3 등 데이터 계층은 기존 구성을 그대로 유지했습니다.

진행은 AWS Samples에서 공개한 AI-Driven Modernization Prompt Sets를 기반으로, Kiro CLI의 modernization agent를 통해 다음 단계를 순차 진행했습니다. 이 프롬프트 세트는 레거시 워크로드를 AWS 관리형 서비스 기반 현대 아키텍처로 전환하기 위한 단계별 프롬프트와 실행 가이드를 오픈소스(MIT-0)로 제공합니다.

AI-Driven Modernization Prompt Sets의 Modernization Agent를 사용하는 모습

AI-Driven Modernization 워크플로우 다이어그램

AI-Driven Modernization 워크플로우 — 각 스테이지 산출물이 다음 스테이지의 입력이 됩니다

각 스테이지의 산출물은 다음 스테이지의 입력이 됩니다. 현황 분석 결과가 요구사항 정의로, 요구사항이 아키텍처 설계로, 설계가 태스크 리스트로 이어지는 구조입니다.

프롬프트 세트의 .kiro/ 디렉터리에는 safety-critical 가이드(steering·guides)와 상황별 참조 자료(skills)가 계층적으로 구성되어 있어, 에이전트가 각 스테이지에서 필요한 컨텍스트만 로드하도록 설계되어 있습니다.

핵심은 사람과 AI의 역할 재배치였습니다. 분석과 반복적 코드 생성은 AI가 전담하고, 엔지니어는 비즈니스 맥락이 필요한 의사결정(서버 성능 튜닝, 배치 전략, 롤백 기준 정의 등)과 최종 검증에 집중했습니다. 프롬프트 세트 자체에 질문-답변 기반 승인 게이트와 감사 기록 규칙이 내장되어 있어, 각 스테이지에서 사람의 승인 없이는 다음 단계로 넘어가지 않도록 안전성을 확보했습니다.

에잇퍼센트에서는 이 기본 프롬프트 세트를 그대로 사용하되, 금융 도메인 특성과 팀 내부 규칙(기존 Terraform 모듈 컨벤션, 외부 연동 검증 기준 등)을 반영해 일부 프롬프트와 skills를 팀 컨텍스트에 맞게 커스터마이즈했습니다.

시범 적용: 문서 없는 레거시에 AI를 먼저 투입

본격 전환에 앞서, 팀은 관리 중단 상태의 소규모 레거시 서비스 하나를 시범 대상으로 삼았습니다. 유지보수가 멈춰 있어 담당자가 없었고, 프레임워크 없는 순수 PHP 스크립트에 외부 업체가 제공한 네이티브 바이너리까지 결합된 사실상 “블랙박스 레거시”에 가까운 상태였습니다. 기존 방식이었다면 코드 이해 단계에서부터 막혀 착수 자체가 보류될 법한 서비스였습니다.

현황 분석: 블랙박스를 열다

Stage 1(현황 분석) 프롬프트를 실행하자, AI 에이전트는 소스코드를 클론한 뒤 PHP 파일 7개와 네이티브 바이너리 2개로 구성된 서비스의 전체 구조를 수 분 만에 정리했습니다. 각 엔드포인트의 기능·입출력 형식·외부 API 통신 방식(SSL 소켓 연결, 문자 인코딩 변환 등)을 분석하고, 동시에 AWS CLI를 통해 인프라 현황(단일 EC2 인스턴스, ALB 미사용, CI/CD 파이프라인 없음)을 수집해 분석 보고서를 생성했습니다.

이 과정에서 AI는 컨테이너화에 영향을 주는 핵심 사항을 스스로 식별해 사용자에게 확인을 요청했습니다.

AI 질문: “네이티브 바이너리의 라이브러리 의존성을 확인해야 합니다. ldd 결과를 제공해주실 수 있나요?”

사용자 답변: ldd 실행 결과 — 표준 glibc만 필요

AI 판단: “특수 라이브러리 불필요. Debian 기반 PHP 공식 이미지로 충분. 단, ARM64(Graviton) 사용 불가 — x86-64 전용 바이너리이므로 amd64 아키텍처로 고정 필요”

이처럼 AI가 기술적 발견을 하고, 사람이 실행 환경의 사실관계를 확인해주는 질문-답변 사이클이 반복되며 분석의 정확도를 높여갔습니다.

요구사항 정의

Stage 2(요구사항 정의)에서는 Stage 1에서 도출된 현황 보고서를 입력으로, AI 에이전트는 전환 시 반드시 충족해야 할 요구사항을 기능적/비기능적으로 분류해 정리했습니다. 이 단계에서 핵심은 “있는 그대로 옮기는 것”과 “반드시 개선해야 할 것”의 경계를 명확히 긋는 일이었습니다.

에이전트는 Stage 1 산출물(애플리케이션, 데이터베이스, 인프라 현황)을 분석한 뒤, 금융 서비스 특성을 반영한 요구사항 초안을 생성하고 사용자에게 검증을 요청했습니다.

무중단 운영 요구사항:

AI 질문: “현재 서비스의 허용 가능한 최대 다운타임은 얼마인가요? 배포 시에도 동일한 기준이 적용되나요?”
사용자 답변: “금융 서비스 특성상 다운타임 제로를 목표합니다. 기존에는 배포 시점을 트래픽이 적은 시간대로 제한해왔습니다.”
AI 판단: “Rolling Update + Deployment Circuit Breaker 조합으로 무중단 배포 요건 충족 가능. 헬스체크 grace period를 충분히 확보해 컨테이너 기동 시간을 보장해야 함.”

외부 연동 보전 요구사항:

AI 질문: “Stage 1에서 식별된 외부 엔드포인트(오픈뱅킹, 전자서명, 신용평가 등) 중 IP 화이트리스트 기반으로 통신하는 것이 있나요?”
사용자 답변: “일부 금융기관 연동은 고정 IP 기반입니다. NAT Gateway IP가 변경되면 안 됩니다.”
AI 판단: “기존 NAT Gateway를 재사용하는 방향으로 네트워크 설계. Fargate 태스크가 동일 퍼블릭 서브넷의 NAT를 경유하도록 구성해 외부 연동에 영향 없음을 보장.”

환경 일관성 요구사항:

AI 질문: “현재 인스턴스별로 개별 관리되는 환경변수를 어디서 중앙 관리하길 원하시나요? AWS Systems Manager Parameter Store와 AWS Secrets Manager 중 선호가 있나요?”
사용자 답변: “민감 정보는 Secrets Manager, 일반 설정은 ECS Task Definition 환경변수로 통합해주세요.”
AI 판단: “서버 간 설정 드리프트 문제를 원천 제거. 모든 태스크가 동일한 Task Definition에서 기동되므로 환경 일관성 자동 확보.”

이처럼 AI는 기술적 분석 결과를 비즈니스 제약 조건과 매핑하고, 사용자는 운영 현장의 맥락(어떤 연동이 IP 기반인지, 어떤 수준의 가용성이 필요한지)을 제공하는 역할 분담이 이루어졌습니다. 최종 산출물은 요구사항 분석 명세서로, 이후 Stage 3의 작업 계획이 각 요구사항을 하나 이상 충족하도록 트레이서빌리티를 유지하는 기준이 되었습니다.

계획 수립: 팀 컨텍스트에 맞춰 조율

Stage 3(계획 수립)에서 AI는 8개 Phase로 구성된 작업 목록을 생성했습니다. 각 Phase는 다음과 같이 구성했습니다.

Phase1: 기반 인프라 구축 (IAM, Security Group)
Phase2: 애플리케이션 컨테이너화 (Dockerfile 추가)
Phase3: 컨테이너 이미지 동작 테스트 (로컬 빌드, 엔드포인트 검증)
Phase4: Amazon ECR 리포지토리 생성 및 이미지 Push
Phase5: ECS 서비스 및 Green(테스트) 환경 구축
Phase6: Green 환경 배포 및 테스트
Phase7: CI/CD 파이프라인 구성
Phase8: 모니터링 환경 구성 (CloudWatch 대시보드, Alarms)

이 과정에서 단순히 “표준 ECS 전환 절차”를 나열하는 것이 아니라, 팀의 기존 인프라 코드 컨벤션을 분석한 뒤 맞춰 나갔습니다.

Terraform Cloud 컨벤션 정렬:

AI 질문: “Terraform 백엔드로 Terraform Cloud를 사용하시나요, 로컬 백엔드를 사용하시나요?”
사용자 답변: “Terraform Cloud. 기존 리소스에 영향 주지 않도록 별도 워크스페이스로 분리해주세요.”

AI는 팀이 이미 운영 중이던 유사 서비스의 Terraform 디렉토리 구조를 분석해 네이밍 규칙(워크스페이스, 리소스명, 태그)을 자동으로 맞췄습니다.

보안 환경 반영:

AI 질문: “기존 VPC 전체 포트 허용 보안그룹을 재사용할까요, 서비스 전용 보안그룹을 새로 생성할까요?”
사용자 답변: “서비스 전용으로 새로 생성해주세요.”

최소 권한 원칙에 따라 ECS 태스크 전용 보안그룹과 Green 환경 테스트용 Internal ALB 보안그룹이 별도로 설계되었습니다.

실행: 생성된 작업 목록을 빠르게 수행

검증된 작업 목록에 따라 Phase 1(기반 인프라)부터 Phase 8(모니터링)까지 순차 실행했습니다. AI 에이전트가 각 Phase의 체크박스를 하나씩 실행하고, 완료 시 업데이트하며, 문제가 발생하면 사용자에게 보고하고 대기하는 방식으로 진행했습니다.

실행 중에도 예상치 못한 이슈가 발생했지만, AI가 원인을 분석하고 해결 방안을 제시하는 패턴이 반복되었습니다. 예를 들어, CI/CD 파이프라인(Phase 7)에서 AWS CodePipeline이 Terraform으로 생성되자마자 자동 트리거되었는데, 이 시점에 빌드 설정 파일이 아직 리포지토리에 푸시되지 않아 빌드가 실패했습니다. AI는 작업 순서를 재조정(빌드 설정 파일 커밋 → Terraform apply)하여 문제를 해결했습니다.

최종적으로 컨테이너 이미지 빌드, Amazon ECS Fargate 배포, CI/CD 파이프라인, Amazon CloudWatch 모니터링 대시보드까지 약 5.5시간 만에 전체 구성을 완료했습니다. 이 시범 과정은 워크플로우의 실효성을 팀 내에서 먼저 확인하는 저위험 검증 단계가 되었으며, 이후 본격 전환에서 동일한 패턴을 재사용할 수 있다는 확신을 주었습니다.

작업 내용

전환 작업은 논리적으로 6개 영역으로 나누어 진행했습니다. 구체적인 명령어나 내부 자원 명칭은 생략하고, 활용한 AWS 서비스와 설계 의도 중심으로 소개합니다.

To-Be Architecture

에잇퍼센트 To-Be 아키텍처 다이어그램

에잇퍼센트 전환 후(To-Be) 아키텍처

1. 컨테이너 이미지와 기반 인프라

컨테이너 이미지 및 기반 인프라 구성 다이어그램

컨테이너 이미지 및 기반 인프라 구성

기존에는 CI용 Dockerfile만 존재했기에, 운영용 Multi-stage Dockerfile을 AI가 생성했습니다. 인프라는 내부적으로 검증된 Terraform 모듈을 재사용해 선언적으로 구성했습니다.

활용 AWS 서비스: Amazon ECR, AWS Secrets Manager, AWS IAM Task Role, Amazon VPC Security Group

2. CI/CD 파이프라인

CI/CD 파이프라인 구성 다이어그램

GitHub Actions 기반 CI/CD 파이프라인 구성

GitHub Actions 기반으로 빌드 워크플로우(ARM64 이미지 빌드 → Amazon ECR push)와 배포 워크플로우(ECS 배포 → 검증)를 구성했습니다. Rolling Update에 Deployment Circuit Breaker를 결합해 배포 실패 시 자동 롤백이 동작합니다.

3. 모니터링

모니터링 구성 다이어그램

Amazon CloudWatch 기반 모니터링 구성

Amazon CloudWatch Logs 그룹, CPU/Memory 임계 알람, Container Insights with enhanced observability를 Terraform으로 선언했습니다. 태스크 단위 메트릭이 즉시 확보되어 운영 가시성이 크게 개선되었습니다.

4. End-to-End 검증

End-to-End 검증 다이어그램

실제 워크로드 경로 End-to-End 검증

단순 헬스체크를 넘어 실제 워크로드 경로를 end-to-end로 검증했습니다.

다수의 RDS 연결 (Amazon Aurora Writer/Reader, 보조 DB)
Celery 브로커 연결 및 태스크 제출 → 워커 소비 경로
외부 중요 연동(Apache Kafka, Amazon SageMaker 엔드포인트 호출, 외부 금융 파트너 API 등) 도달성 검증

5. Auto Scaling: Target Tracking + Scheduled Scaling

Auto Scaling 구성 다이어그램

Target Tracking + Scheduled Scaling 조합 구성

과거 특정 시간대에 일시적으로 대규모 트래픽이 유입되며 CPU가 포화된 장애 사례가 있었습니다. 이에 Scheduled Scaling을 Target Tracking 정책과 결합해, 피크 직전 일정 시점에 최소 태스크 수를 미리 늘려두고 피크 종료 후 다시 축소하는 방식을 적용했습니다. 이로써 피크 시작 시점의 지연 응답 가능성을 구조적으로 해소했습니다.

6. 트래픽 컷오버: ALB Weighted Forward

ALB Weighted Forward 트래픽 컷오버 다이어그램

ALB Weighted Forward를 활용한 단계적 트래픽 컷오버

DNS 가중치 라우팅 대신 Application Load Balancer(ALB) 리스너 규칙의 weighted forward를 사용했습니다. 모든 요청이 동일한 ALB로 수신된 뒤 요청 단위로 타겟 그룹에 분배되므로, DNS TTL 캐시 영향 없이 가중치 변경이 즉시 반영되고 롤백도 즉시 가능합니다.

단계적 컷오버는 가중치(w1, w2)를 다음과 같이 조정하며 진행했습니다.

EC2 100 / ECS 0
→ EC2 90 / ECS 10
→ EC2 50 / ECS 50
→ EC2 0  / ECS 100

각 단계마다 에러율과 p95 응답 시간을 기준으로 롤백 여부를 판단했습니다. 구조상 ALB 가중치 변경만으로 즉시 이전 상태로 복귀할 수 있어, 컷오버 리스크를 실질적으로 낮췄습니다.

결과 및 성과

수치화된 결과

전환 전후 주요 지표를 요약하면 다음과 같습니다.

구분	전환 전 (EC2)	전환 후 (ECS Fargate)
전환 기간	수 개월 전담 스프린트 필요 예상	내부 API 2영업일, 외부 메인 API 약 2주 (현업 병행)
월 운영 비용	24/7 고정 가동 (평균 CPU <10%)	약 76% 절감 (2차 대상 서비스 기준)
배포	트래픽이 적은 시간대로 제한, 짧은 간섭 발생	무중단 배포, 시간대 제약 없이 상시 릴리스
배포 실패 복구	수동 대응	Deployment Circuit Breaker 자동 롤백
운영 가시성	인스턴스 단위 메트릭	태스크 단위 메트릭 (Container Insights)

기존 방식이었다면 수 개월 전담 스프린트가 필요했을 규모의 전환이, 현업 업무를 병행하면서도 주 단위로 측정 가능한 속도로 진행되었습니다. 전환 속도 측면에서 1차 대상인 내부 API 서비스는 2영업일, 2차 대상인 외부 메인 API 서비스는 약 2주 만에 검증 단계까지 도달했습니다.

컨테이너 기반 서비스 전환으로 월 운영 비용은 2차 대상 서비스 기준 약 76% 절감되었습니다. 첫째, EC2를 24/7 고정 가동하던 구조에서 태스크 단위 Auto-scaling 기반 탄력 운영으로 전환하면서, 야간·주말에는 최소한의 워크로드만 유지해 유휴 비용을 대폭 줄였습니다. 둘째, 컨테이너 단위 격리로 워크로드에 맞춘 사이즈 최적화가 가능해져, EC2 대비 서비스 스펙을 줄여도 동일한 처리 성능을 확보할 수 있었습니다. 셋째, AWS Graviton 기반 ARM64 Fargate를 채택해 x86 대비 약 20% 낮은 단가를 확보했습니다. 넷째, 상태를 외부 서비스로 분리한 stateless 구조로 영구 EBS 볼륨이 불필요해져 별도의 스토리지 비용이 발생하지 않았습니다.

운영 지표 역시 고르게 개선되었습니다. 배포 간섭 가능성이 제거된 무중단 배포 체계가 갖춰졌고, 인스턴스 단위에서 태스크 단위로 메트릭 수집 범위가 확장되며 운영 가시성이 한층 높아졌습니다. Deployment Circuit Breaker를 통한 자동 롤백으로 배포 실패 시 복구 시간이 단축되었고, 릴리스 빈도의 구조적 제약이 사라져 제품 개선 주기를 단축할 수 있는 기반이 마련되었습니다.

정성적 성과

가장 큰 성과는 수치가 아니라 팀의 인식 변화입니다. 이전에는 현대화 작업이 “착수하려면 분기 하나를 비워야 하는 일”이었다면, 이제는 “현업 운영과 병행하면서 단계적으로 진행할 수 있는 일”로 자리 잡았습니다. AI 에이전트가 반복 공수를 흡수하면서, 엔지니어는 판단과 검증에 집중할 수 있게 되었습니다.

시범 대상이었던 관리 중단된 PHP 레거시 서비스는, 기존 방식이라면 “언젠가 손대야 할 골칫거리”로 남았을 가능성이 높았습니다. AI 에이전트가 코드를 분석해 기능과 외부 의존성을 빠르게 정리해줌으로써 담당자 공백과 문서 부재라는 전형적인 전환 장벽이 실질적으로 낮아졌습니다.

또한 1차 전환에서 만든 Terraform 모듈·CI/CD 워크플로우·Dockerfile 패턴과, 팀 컨텍스트에 맞게 다듬은 프롬프트 세트가 2차 전환에 그대로 재사용되었습니다. 첫 사례가 단독 성과로 끝나지 않고 조직 자산으로 축적되었고, 남은 전환 대상도 동일 패턴으로 확장 가능하다는 확신을 얻었습니다.

전환 과정에서 하드코딩된 credential을 AWS Secrets Manager로 외부화하고, 후속으로 AWS IAM Task Role 기반 임시 credential 전환을 단계적으로 추진하게 되었습니다. 현대화가 런타임 교체 이상의 보안·거버넌스 개선 기회로 확장된 것입니다.

향후 기대 효과

배포 주기 단축: 무중단 배포로 릴리스 빈도 제약이 사라지면서 제품 개선 속도 자체가 빨라집니다.
운영 비용 탄력성: Auto Scaling 기반 구조로 트래픽 변동에 따라 비용이 자연스럽게 조정됩니다.
장애 격리: Multi-AZ, Auto Scaling, Deployment Circuit Breaker 조합으로 단일 장애가 서비스 전면 중단으로 이어지지 않습니다.
조직 학습: 첫 전환의 경험이 커스터마이즈된 프롬프트 세트, Terraform 모듈, 런북으로 문서화되어, 앞으로 어떤 엔지니어가 합류하더라도 동일 수준의 품질로 현대화 작업을 재현할 수 있습니다.

마치며

AI 코딩 에이전트는 숙련된 엔지니어를 대체하지 않습니다. 대신, 리소스가 부족해 시작조차 못 하던 과제의 진입장벽을 낮춰주는 도구로 자리 잡았습니다. “중요하지만 착수할 여력이 없던 일”을 “이번 분기에 해볼 만한 일”로 바꿔주는 것 — 소규모 팀에게 이보다 실용적인 변화는 많지 않습니다. 에잇퍼센트는 남은 전환 범위도 같은 방식으로 이어가며, 현대화 경험 자체를 조직의 표준 역량으로 축적해 나갈 계획입니다.

이 글에서 소개한 AI-Driven Modernization Prompt Sets는 오픈소스로 공개되어 있어, 비슷한 고민을 가진 팀이라면 자신의 워크로드에 맞게 커스터마이즈해 바로 시작할 수 있습니다. Amazon ECS와 AWS Fargate에 대한 자세한 내용은 Amazon ECS 개발자 가이드에서, AWS Lift-On 프로그램에 대한 정보는 AWS 담당자를 통해 확인하실 수 있습니다.

참고 자료

본 글의 도표, 예시 코드, 스크린샷 및 데이터는 실제 고객 환경과 무관하며, 외부 공개 가능한 수준으로 비식별 처리하였습니다.

AWS 기술 블로그