이번 AWS Summit 행사에서 가장 기대했던 점은 근 1년간 가지고 있던 “레거시 서비스에 어떻게 AI 에이전틱 프로그래밍을 할 수 있는가?”라는 질문에 대한 해답을 얻는 것이었다.
현재 시중에 나와있는 “ONLY VIBE CODING”으로 만들어진 수많은 프로덕트(혹은 프로덕트라 주장하는 것)는 대부분 토이 프로젝트 수준이다. 토이 프로젝트라고 비난하는 것이 아니라, 1) 서비스의 규모 자체가 작고 2) 처음부터 AI와 쌓아올린 코드베이스 라는 것이다.
하지만 많은 프로덕트들은 이미 만들어져있다. AI의 손길이 전혀 닿지 않은, 구식인 스택을 가지고 이미 세상에 나와있다. 그 프로덕트들도 처음에는 아름다운 아키텍처와 깔끔한 추상화, 느슨한 결합을 표방하고 나왔겠으나, 시간의 흐름에 따라 처음과는 다소 다른(?) 모습을 가지게 되었을 것이다. 요구사항이 바뀌거나, 소스코드를 유지보수하거나 고도화 하는 업체가 바뀌거나 하는 등등의 이유로 말이다.
물론 아닌 곳도 많을 것이다!! 하지만 나는 엔트로픽 증가의 법칙처럼 소스코드와 인프라는 시간이 지나면서 복잡해진다고 믿고 있다…
그래서 클로드 코드와 함께 개발하면서 두가지 고민을 가지게 되었다.
1) 사용하지 않는 코드들이 섞인 오래된 수십만줄의 스파게티 코드들, 기능 추가와 수정을 거치며 복잡한 의존관계를 가지게 된 DB 스키마, 여러 뎁스의 의존성 레이어 등을 한정된 컨텍스트를 가진 AI 에이전트에게 어떻게 주입시킬 것인가, 어떻게 활용할 것인가…
2) 이미 운영중인, 어느정도 규모가 있는 서비스에 새로운 프로덕트를 추가할 때 토이 프로젝트 수준의 바이브 코딩이 아니라 기획/디자인/개발/운영 전반에서는 AI를 어떻게 활용할 것인가
의존성 사슬: 하나의 모듈을 수정하면 다른 모듈과 라이브러리까지 연쇄적으로 영향을 받는 구조
실행환경 종속: 비즈니스 로직이 특정 프레임워크와 실행방식에 강하게 결합
플랫폼 고착: 특정 os나 인프라 환경에 고착되어 클라우드 네이티브 전환을 막는 족쇄
왜 에이전틱 AI가 필요한가?
AWS Transform: 에이전틱 현대화를 실제 서비스로 구현한 방식
특화 에이전트
Windows/Mainframe/Vmware 현대화 전문 에이전트
공유 워크스페이스 및 개발자 경험
웹 워크스페이스에서 전체 현황을 통합 관리
기존 개발 도구(CLI/KIRO/VSCode) 그대로 활용
거버넌스 & 통제
계획 검토 및 승인
진행 추적, 감사
엔터프라이즈 제어 모델 적용
AWS Transform은 워크로드 특성에 따라 각기 다른 시작점을 제공한다.
Assessment / Wave Planning: 자산분석 및 무엇부터 바꿀지 판단하고, 현대화 순서를 정하는 단계
Windows 현대화: .NET, SQL, Server, UI, 배포까지 아우르는 통합 현대화
VMware / 메인프레임: 대규모 마이그레이션, 시스템 분할, 단계별 전환 계획이 필요한 워크로드
Custom 변환: Java, Python, JS 등 다양한 언어의 버전 업그레이드, API/프레임워크 전환, 조직 고유 코드 변환 자동화
놀유니버스 티케팅 시스템 현대화 여정
놀유니버스는 중요한 티케팅 시스템 현대활르 어떻게 시작하고 추진했는가
1988년부터 28년동안 중단 없이 운영
트래픽의 변곡점, K-Culture 글로벌 확산
공연 규모 사상 최대 경신
트래픽 패턴의 양적 변화
티켓 오픈 시 국내외 트래픽이 동시에 폭주
인기 콘서트 티켓 오픈 시 트래픽은 일상의 수십, 수백배. → 그 ‘특별한 날’의 빈도가 늘고 강도도 더 세짐
안정의 버팀목이 변화의 족쇄가 되다
실패해서 바꾸는게 아니라, 성공해서 바꾸는 것.
기존 시스템의 검증된 안정성, 물리 인프라의 신뢰성, 축적된 운영 노하우는 지속적인 성장의 버팀목이 되었다.
그러나 이는 동시에 변화에 대한 저항, 탄력적 확장 불가능, 기술/인력에 대한 과도한 의존이라는 변화의 족쇄가 되었다.
28년간 검증된 안정성 = 트래픽이 예측 가능할 때의 이야기
→ 오히려 건드리면 안된다는 생각을 하게 됨
글로벌 트래픽 대응을 위한 시도가 어려웠음
성장의 버팀목이 족쇄가 되는 순간, 변화는 선택이 아닌 필수가 된다.
변화의 결과로 드러난 3가지 한계
심화되는 기술 부채: MS 종속 아키텍처로 기술 부채 가중
예측 불가능한 글로벌 폭증: 국내/글로벌 트래픽 급증으로 기존 인프라 한계 도달
종속적 구조의 병목: Windows/IIS 종속 구조로 트래픽 대응 한계, 기술 전환 필요
인프라/애플리케이션/보안 - 3중 교착
인프라/운영
증설에 수주 소요, 수동 배포로 다운타임 발생
Configuration Drift로 환경 불일치 상시화
애플리케이션
비동기 처리 한계, DI/미들웨어 파이프라인 부재(현대적 설계 패턴조차 없었음. ) 너무 강하게 결합해서, 문제가 어딘지 알아도 이를 고치기 어려웠음
마이크로서비스 전환 구조적 불가
보안/컴플라이언스
모니터링 부재 → MTTR 증가, DR 보장 불가
패치 지연 → CVE 노출 위험 확대
레거시 구조
위의 문제로 현대화 결정. 그러나 하나씩 바꿀수는 없었다. 레거시라는 늪..
이러한 문제를 위해 AI를 활용해보기로함
그렇다면 왜 AI인가? → 수작업 마이그레이션이 어려웠기 때문
핵심제약: 운영에 묶인 리소스
분석불가: 수백만 라인의 코드가 블랙박스였다.
분리불가: 강결합 구조. “이것만” 분리는 불가능했음.
중단불가: Feature Freeze 불가. 비즈니스는 우리를 기다려주지 않는다.
범용 Coding Agent의 구조적 한계
대규모 컨텍스트의 벽 : 에이전트는 현재 편집중인 파일 A는 분석할 수 있지만, 파일 A가 참조하는 프로젝트 B, 공유 라이브러리 C는 추적 불가 영역이다.
종속성 그래프 해석 불가 : 프로젝트 참조, NuGet 버전 매핑, GAC/COM, 리플렉션 기반 암묵적 의존으로 구성된 4가지 의존성 레이어를 통합 분석해 빌드 순서를 결정하지 못하는 이슈 (의존성 레이어 그래프를 해석하지 못해서 빌드 순서를 결정하지 못함 -> 캐스케이딩 빌드 실패)
오케스트레이션의 부재 : Code Group 식별, 병렬 전략, API 대체, 패키지 매핑, 통합 빌드 검증 등 오케스트레이터 역할을 수행하지 못함. (대량 파일의 변환을 전체적으로 조율하는 건 범용 에이전트의 설계 범위 밖이기 때문)
“AI를 쓸 것인가”가 아니라 “어떤 AI를 어떤 범위에서 쓸것인가”가 진짜 질문
전문화된 Transform 서비스의 선택
범용 코딩 에이전트 = 능숙한 목수
AWS Transform = 설계사 + 시공 관리자
AWS Transform 오케스트레이션
분석: 수천개의 파일을 전체 흐름을 파악
분할: 코드 그룹 분할
계획: 사람이 검토할 수 있도록 계획 제시
실현: 수립된 계획에 따라 병렬 변환 자동으로 수행
⇒ 전문 도구(AWS Transform)이 구조 변환 + 범용 도구(Kiro CLI)가 후속 개발 (같이 쓰는거임~)
우리가 타협하지 않기로 한것(Non-Negotiable KPIs)
Zero downtime - 운영 영향 최소화
SLA 유지, Feature Freeze 없음, 운영 부담 최소화
신속한 가시성
6주 내 전환 성과 가시화. 후속 투자 정당화.
Container native
Step 1. 10시간에 끝낸 대규모 병렬 변환
의존성 그래프 분석
Code Group 분할
변환 계획 자동 생성
병렬 변환 실행
결과
150만 라인의 LoC전환 대상 코드
AI 변환 소요까지 10시간
1500개의 파일 변환
Transform이 해결해주지 못한것..
Step 2. 빌드 성공 ≠ 프로덕션 투입
AWS Transform이 해주지 못한 것
View/정적 파일 (cshtml 문법 변환, wwwroot 이동)
모델 바인딩/라우팅 ([FromBody] / [FromQuery] 명시, 라우팅 규칙 변경)
인프라/도커 (리눅스 경로 대소문자, SSL/TLS handshake)
Kiro를 사용해 디버깅
에러 발견
Kiro CLI 분석 - 사람이 한건씩 추적하던걸 패턴단위로 추적
패턴 수정 - Kiro는 230개의 테스트를 20초만에 생성하고 수행함
Human 검증
AI - 속도와 규모
Human - 정확성과 검증
운영 모델의 근본적 전환
실제로 해낸 것들
6주로 잡았지만 실제로 전환까지 4주 걸림
3배의 생산성 향상
50% 공수 절감
playbook - 재현 가능한 방법론
“현대화는 코드의 버전을 올리는 것이 아니라, 팀이 일하는 방식을 바꾸는 것이다.”
배포 (공포 → 일상)
스케일링 (예측 → 반응)
장애 대응 (탐정 → 소방관)
놀유니버스의 자체 하네스
현대화 플로우
놀유니버스 Harness
도구
자체 변환 스크립트
CI/CD 파이프라인
프로세스
검증 기준 문서화
승인 게이트 절차
AI 협업
프롬프트 전략
코드 리뷰 패턴
블랙박스를 가시화하라
운영 전환까지 설계하라
완벽한 준비를 기다리지 마라
AI ‘개발’에서 ‘운영’으로: 엔터프라이즈 AI 전환(sponsored by BESPIN GLOBAL) 세션
서비스 제작 프로세스의 변화는 모든 과정에 AI를 적극적으로 사용해서 관리하는것. 즉, AI DLC의 핵심 개념과 같이 AI를 도구가 아닌 동료로 활용하는 것
느낀점: 기획/개발자가 요구사항을 더 세밀하게 분석하는건 한계가 있다. 타겟과 함께 요구사항 분석하고, 빠르게 프로토타입을 제공하는 것이 나을수도.(이제 AI가 있어서 가능해짐)
놀유니버스
문제를 파악하는게 중요하다. “레거시”라는 단어로 퉁치기 보다는, 그 레거시가 무엇으로 쌓아진 레거시인지 파악해야 한다. (실제로 놀유니버스 세션 내용도 어떻게 AWS Transform 을 적용했느냐 보다는 놀유니버스에서 파악한 레거시 시스템의 문제가 무엇인지 상세하게 분석한 내용을 공유하는데 더 많은 시간을 사용했다.) AWS Transform을 쓰든 아예 새로 만들든, 원인을 알아야 동일한 문제가 재발하지 않는다.
일단 작게라도 하는게 중요.
전반적인 행사 후기
(AI DLC) AI DLC를 엄청 밀길래 반신반의 했는데, 웅진씽크빅 세션 듣고 적용할 수 있는 방법론이라고 생각했다. 특히 오래된 기존 서비스를 운영중이던 회사에서도 적용할 수 있는 방법론이라는 점에서 매력적이었다. AI는 이제 엔지니어링 패러다임이 아니라 소프트웨어 개발 패러다임의 핵심이 되었다. 그래서 AI DLC 뭔지 찾아봄.
(인간의 영역) 내가 가지고 있던 고민들(레거시 코드베이스를 어떻게 혁신할 것인가)이 AWS Transform으로 소위 ‘딸깍’ 되어버린 것에서 뭔지 모를 무력감을 느꼈다. 물론 AWS Transform이 전부는 아니지만…ㅎㅎ 휴먼 리소스에서 가장 많이 소요되는 부분이 몇시간만에 해결되는 걸 보니 신기하기도 하고 기분이 묘했다. 인간의 영역은 개발, 디버깅에서 검토, 설계 역할로 넘어갔다.(넘어가고 있다 ❌ 이미 넘어갔다.✅)
(인프라 - AI) 놀유니버스에서는 아예 레거시 인프라를 뜯어고쳤는데, 결과물을 보고 나니 인프라도 이제는 AI 중심의 설계로 패러다임이 이동할 것 같다고 생각했다. (굳이 놀유니버스 뿐만 아니라 내가 들은 세션의 대부분이 그랬다)
(인프라 - 복잡성) 현대카드 데이터 사이언스 플랫폼 세션도 들었는데, 보안/감사 이슈 때문에 인프라는 좀 더 세분화되고 복잡해질 것 같다. 성능을 위해 클라우드를 사용하는 부분과 보안 이슈로 클라우드에 올리지 못하고 온프레미스로 관리되는 부분이 동시에 있을수 있기 때문에.. 인프라 공부, CS 공부를 더 열심히 해야한다!! ㅠㅠ
(행사 주제) 사실상 AI 컨퍼런스가 아닌가 싶을 정도였다. 왜냐면 거의 대부분의(사실상 모든) 세션이 AI와 관련된 세션이었다. 세션 뿐만 아니라 부스에서도 대부분 자체 AI 서비스를 홍보하거나, 혹은 자기들 서비스가 어떻게 AI를 활용하고 있는지 위주로 보여줬다. 이제 AI는 붐이 아니라 새로운 패러다임이고 그 패러다임의 시작점에 있다는 생각을 했다.
(사람너무많아) 개발자 망한다는거 다 거짓말같다.. 그렇지 않으면 이 행사에 사람이 이렇게 많을리가 없다… 기념 티셔츠 받는 줄이 한 층을 가로짓는 수준이었다.. 근데 그만큼 스탭도 많이 배치되고, 보안요원이 현장 질서 유지를 잘 해주셔서 큰 불편함은 없었다!!
