레거시를 버리지 않고, 다시 바꿀 수 있는 시스템으로.

• 구조를 아는 사람이 없음

  문서와 담당자가 사라져, 작은 변경도 영향 범위를 알 수 없다.

• 전면 재작성이라는 큰 베팅

  기존 운영과 신규 구축을 오래 병행하다 일정과 비용이 무너진다.

• 기술 부채를 그대로 이전

  서버만 클라우드로 옮겨도 코드·데이터·배포의 병목은 남는다.

1. 01
   진단코드·데이터·트래픽·연동·배포 흐름을 복원하고 기준선을 측정
2. 02
   전환 설계구성요소별 전략, 목표·중간 구조, 웨이브와 종료 조건 정의
3. 03
   단계적 현대화위험을 좁힌 단위로 분리·검증하고 트래픽을 점진 전환
4. 04
   안정화·인계데이터 정합성, 롤백, 관측성, 배포 지표를 검증하고 운영에 인계

• 
  애플리케이션 현대화는 어디서 시작할까 — 재작성 전에 만드는 전환 지도애플리케이션 현대화 · 2026년 7월 18일
  레거시 애플리케이션을 전면 재작성하지 않고 현대화하는 방법을 정리했다. 현행 구조와 의존성을 진단하고, 유지·교체·리플랫폼·리팩터·리아키텍처를 구분해 단계별 전환과 성공 지표를 설계한다.
  →
• 
  모놀리식을 NKS로 — 네 개의 계층으로 다시 세우기애플리케이션 현대화 · 2026년 5월 30일
  단일 배포와 외부 CI에 묶여 있던 서비스를 NCP의 NKS 위로 옮겼다. 인프라·DB·API·프론트엔드를 네 계층으로 나누고, Terraform·관리형 Cloud DB·ArgoCD GitOps로 배포를 Git 단일 진실로 만든 기록.
  →
• 
  8명이 못 푼 문제, 혼자서는 왜 3일이면 됐을까애플리케이션 현대화 · 2026년 7월 3일
  8인 SI 프로젝트가 풀지 못한 문제를 혼자 3일에 해결한 사례를 개인기만으로 설명하지 않고, 커뮤니케이션 경로와 책임 분산, 의사결정 구조의 영향을 살핀다. 같은 렌즈로 Assessment·마이그레이션·리아키텍처링의 오너십 공백을 짚는다.
  →

공공·금융·교육처럼 서비스 중단과 데이터 정합성, 감사 가능성이 중요한 환경의 점진적 전환.