● 801 DECISION LAB · PORTFOLIO PLANNER 01
어떤 애플리케이션을, 어떤 순서로 바꿀지 결정한다.
최대 8개 애플리케이션을 사업 가치·변경 압력·실행 난이도로 비교하고, 7R 방향과 전환 웨이브, 선행조건, 90일 실행 골격을 만든다.
● ONE DECISION · MULTIPLE APPLICATIONS
비용 하나가 아니라 포트폴리오 전체의 실행 순서를 다룬다
현대화 후보가 여러 개일 때 어려운 질문은 예상 비용보다 먼저 무엇을 검증하고 어디서 작은 성공을 만들지다. 이 플래너는 각 애플리케이션을 동일한 근거 척도로 비교해 회의에서 검토할 수 있는 초안을 만든다.
- 01DIRECTION
- 유지·폐기·교체·리호스트·리플랫폼·리팩터링·리아키텍처링 중 방향성 판정
- 02SEQUENCE
- 사업 가치와 위험, 실행 난이도를 함께 고려한 1·2·3차 웨이브와 보류 구분
- 03NEXT 90 DAYS
- 착수 전 확인할 증거와 전략별 30·60·90일 실행 골격
● INTERACTIVE DECISION TOOL
같은 질문으로 최대 8개 애플리케이션을 비교한다
정답처럼 보이는 숫자를 만드는 대신 입력 근거의 수준, 주요 판정 요인과 선행조건을 결과에 함께 남긴다.
● METHOD · SCOPE · LIMITS
점수는 결정을 대신하지 않고, 검증 순서를 드러낸다
- 01평가 단위
- 하나의 애플리케이션 또는 함께 배포·운영되는 명확한 시스템 경계. 서로 다른 범위를 한 항목에 섞지 않는다.
- 02가치와 압력
- 사업 중요도·차별성·변경 수요와 변경 마찰·운영 위험·수명주기 위험을 분리해 본다.
- 03실행 난이도
- 의존성 결합도·데이터 전환 난이도·팀 준비도를 사용해 점수가 높은 후보라도 선행 준비가 필요한지 판정한다.
- 047R 방향
- AWS의 7R 분류를 의사결정 어휘로 사용한다. 자동 판정은 후보 가설이며 아키텍처 승인이나 공급자 선택이 아니다.
- 05데이터 처리
- 애플리케이션 이름과 선택값은 현재 브라우저에서만 계산한다. 서버 저장, 계정 생성과 결과 이메일 전송은 없다.
- 06적용 한계
- 예산·규제·계약·조직 제약과 실제 의존성은 별도 검증이 필요하다. 결과는 프로젝트 견적이나 완료 일정이 아니다.
● RELATED INSIGHTS
평가 방법과 실제 전환 조건을 함께 읽는다
애플리케이션 현대화는 어디서 시작할까 — 재작성 전에 만드는 전환 지도애플리케이션 현대화 · 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·마이그레이션·리아키텍처링의 오너십 공백을 짚는다.→
● RELATED WORK
애플리케이션 현대화 실행 사례
app-modernization
사례 보기 App Modernization으로 운영 안정·효율 개선
노후 모놀리식을 무중단으로 현대화해, 장애에 강하고 배포가 빠른 운영 체계로 바꿨습니다.
방향성 결과를 실제 전환 지도로 바꾼다.
의존성·데이터·운영 기준을 확인해 첫 웨이브의 범위와 성공 조건을 구체화한다.
● 이미 금융·헬스케어·미디어·공공의 팀들과 함께