애플리케이션 현대화는 어디서 시작할까 — 재작성 전에 만드는 전환 지도

오래됐다는 이유만으로 시스템을 바꿀 필요는 없다. 기능이 안정적이고 변경 요구가 적으며 운영 비용도 예측 가능하다면 그대로 두는 편이 낫다. 반대로 최신 프레임워크를 쓰더라도 작은 변경에 몇 주가 걸리고, 배포할 때마다 전체 서비스가 흔들리며, 장애의 원인을 찾을 수 없다면 이미 현대화 대상이다.

여기서 레거시란 연식이 아니라 변경 비용이 비즈니스 속도를 막는 상태를 뜻한다. 그래서 출발점은 Kubernetes나 마이크로서비스가 아니다. 무엇을 바꾸려 할 때 어디가 함께 움직이는지 다시 알아내는 일이다.

현대화는 기술 선택보다 변경 단위를 정하는 일이다

클라우드 이전, 현대화, 전면 재작성은 서로 겹칠 수 있지만 같은 말이 아니다.

Microsoft의 현대화 가이드도 리플랫폼, 리팩터, 리아키텍처를 복잡도와 가치가 다른 연속선으로 두고 구성요소마다 조합하라고 설명한다.¹ 하나의 프로젝트에 한 가지 전략만 강요하면 멀쩡한 코드까지 다시 만들거나, 반대로 구조를 바꿔야 할 병목을 플랫폼 이전으로 덮게 된다.

진단은 소스 코드 목록에서 끝나지 않는다

현행 구조를 그릴 때 저장소와 서버 목록만 모으면 중요한 연결이 빠진다. 실제 변경 위험은 데이터 소유권, 배치 작업, 외부 기관 연동, 인증·권한, 수동 배포와 사람의 승인 절차 사이에 숨어 있다.

AWS는 현대화 준비도를 비즈니스 적합성, 기능 적합성, 기술 적합성, 재무 적합성, 디지털 준비도라는 다섯 관점에서 평가한다.² 이를 운영 현장에 맞게 바꾸면 다음 질문이 된다.

문서가 없다면 실행 중인 시스템이 문서다. 트래픽, 로그, 배포 설정, 데이터베이스 스키마와 배치 일정을 역추적해 실제 의존성을 복원한다. 이 지도 없이 목표 아키텍처부터 그리면 전환 중에 숨은 연동을 발견하고 계획을 다시 쓰게 된다.

모든 구성요소에 같은 처방을 쓰지 않는다

AWS의 포트폴리오 평가 방식은 애플리케이션을 7R로 분류하고, 의존성과 기술 복잡도를 합쳐 이전 웨이브를 만든다.³ 현대화 프로젝트에서도 이 분류는 기술 유행보다 선택의 이유를 먼저 적게 해 준다.

결정표에는 선택뿐 아니라 왜 지금 이 선택을 했는지, 다시 검토할 조건이 무엇인지 적어야 한다. 현재 유지가 영구 유지를 뜻하지 않고, 리호스트가 현대화 완료를 뜻하지도 않는다.

목표 구조만큼 중간 구조가 중요하다

아키텍처 문서는 대개 현재와 목표 두 장을 보여준다. 실제 전환에 필요한 것은 그 사이의 여러 장이다. 기존 시스템과 새 모듈이 동시에 요청을 받는 기간, 데이터의 원본이 아직 레거시에 있는 기간, 새 API가 구형 연동 규격을 번역하는 기간을 설계해야 한다.

중간 구조에는 최소한 네 가지가 들어가야 한다.

1. 요청을 기존과 신규 중 어디로 보낼지 결정하는 지점
2. 데이터의 최종 원본과 복제·검증 방향
3. 구형·신형 인터페이스를 잇는 호환 계층
4. 실패할 때 되돌릴 수 있는 마지막 안전 지점

목표 구조는 방향을 설명하지만, 중간 구조는 서비스를 살려 둔다. 각 중간 상태에 종료 조건과 최대 유지 기간을 붙이지 않으면 임시 이중화가 새로운 레거시가 된다.

전환 웨이브는 가치·의존성·복구 가능성으로 자른다

낮은 위험부터 시작하라는 말만으로는 부족하다. 너무 쉬운 내부 도구만 옮기면 핵심 시스템의 가정을 검증하지 못한다. 첫 웨이브는 사업 가치가 있으면서도 영향 범위를 통제할 수 있어야 한다. Microsoft도 현대화를 작은 단계로 나누고, 단계마다 성공 조건과 롤백 절차를 정의하도록 권고한다.¹

각 웨이브는 배포 일정이 아니라 가설 검증 단위다. “새 서비스가 뜬다”가 아니라 “기존과 같은 결과를 내고, 실패해도 정해진 시간 안에 돌아갈 수 있다”가 종료 조건이어야 한다.

데이터 컷오버는 마지막 작업이 아니다

코드는 두 버전을 띄우기 쉽지만 데이터는 한 시점의 진실을 가져야 한다. 그래서 데이터 전략은 현대화 후반이 아니라 경계 설계와 함께 시작한다.

읽기 복제, 변경 데이터 캡처, 이중 쓰기, 배치 이관은 각각 다른 실패 모드를 가진다. 특히 이중 쓰기는 두 저장소 중 하나만 성공했을 때 복구 규칙이 없으면 정합성 문제를 키운다. 다음 항목을 먼저 정해야 한다.

• 어느 저장소가 각 단계의 최종 원본인가
• 누락·중복·순서 역전을 어떻게 대사하는가
• 스키마 변경이 구버전과 신버전에 동시에 안전한가
• 롤백할 때 신규 쓰기를 어디까지 되돌릴 수 있는가
• 개인정보·감사 데이터의 보존과 폐기는 누가 승인하는가

복제 지연이 0이라는 가정보다 지연을 측정하고 허용 범위를 정하는 편이 안전하다. 컷오버 계획에는 전환 버튼뿐 아니라 대사 쿼리, 책임자, 중단 기준과 복구 후 확인 절차가 함께 있어야 한다.

성공은 새 스택이 아니라 변경 성과로 측정한다

컨테이너 수나 마이크로서비스 수는 현대화 성과가 아니다. 시작 전에 현재 변경 흐름의 기준선을 잡고, 같은 애플리케이션에서 전후를 비교해야 한다.

DORA는 소프트웨어 전달 성과를 변경 리드타임, 배포 빈도, 실패 배포 복구시간, 변경 실패율, 배포 재작업률 다섯 지표로 본다.⁴ 여기에 서비스별 SLO, 인프라·라이선스 비용, 수동 승인 단계, 장애 영향 범위를 더하면 현대화가 실제 운영을 바꿨는지 볼 수 있다.

한 지표만 줄이면 다른 비용이 숨을 수 있다. 배포 빈도가 늘어도 변경 실패율과 재작업률이 함께 오르면 개선으로 보기 어렵다. 비용이 줄었지만 장애 복구가 느려졌다면 운영 위험을 다음 분기로 미룬 셈이다. 속도와 안정성, 비용을 한 묶음으로 봐야 한다.

현대화의 결과는 다음 변경에서 드러난다

우리는 한 모놀리식을 인프라·DB·API·프론트엔드 네 계층으로 나누고 NKS와 GitOps 위로 옮긴 과정을 모놀리식을 NKS로에서 기록했다. 그 사례의 핵심도 Kubernetes 자체가 아니라 변경 지점과 책임을 다시 보이게 만든 데 있었다.

기술 구조만 바뀌어도 현대화가 끝나지는 않는다. 누가 다음 웨이브를 결정하고 운영할지 모호하면 개선 백로그는 다시 밀린다. Assessment와 마이그레이션, 리아키텍처링의 오너십 문제는 구조 개선의 주체가 비는 이유에서 더 자세히 다뤘다.

현대화가 끝났다는 가장 좋은 신호는 새 기술 이름이 아니다. 작은 변경의 영향 범위를 설명할 수 있고, 평일에 배포하며, 문제가 생기면 정해진 절차로 되돌리고, 다음 팀이 구조를 읽을 수 있는 상태다.

레거시 구조와 의존성을 진단하고 단계별 전환을 직접 실행하는 일은 애플리케이션 현대화에서 다룬다. 클라우드 기반과 운영 자동화는 클라우드 & 인프라, 신규 사용자 제품은 제품 개발로 이어진다.

참고 자료