Gartner TIME 모델로 레거시 앱을 어떻게 처리할지 결정하는 방법 (유지·투자·이전·폐기)

회사에 굴러다니는 시스템이 200개를 넘는 상황에서 어떤 것을 살리고 어떤 것을 버릴지 결정해야 하는 순간은 누구나 한 번쯤 마주친다. 이럴 때 Gartner TIME 모델 없이 감만으로 판단하면 6개월 뒤 회의실에서 "그것을 왜 살렸는가"라는 추궁을 듣게 된다. TIME은 Tolerate·Invest·Migrate·Eliminate 네 글자에서 딴 프레임워크로, 엔터프라이즈 IT 영역에서 10년 넘게 사실상의 표준처럼 쓰여 왔다. 본 글에서는 TIME 모델의 정확한 정의, 점수화를 통한 분류 방식, 그리고 국내 기업 맥락에서 적용할 때 유의할 점을 정리한다.

 

 

TIME 모델은 무엇이며 왜 여전히 쓰이는가

 

Gartner TIME 모델은 2010년대 초 Gartner가 애플리케이션 포트폴리오 관리(APM, Application Portfolio Management) 맥락에서 정립한 프레임워크이다. 사내에 존재하는 모든 애플리케이션을 네 가지 결정 — Tolerate(현상유지), Invest(투자), Migrate(이전/리팩토링), Eliminate(폐기) — 중 하나로 분류하여 IT 예산 배분의 근거로 활용하자는 것이 핵심이다.

 

왜 아직까지 쓰이는가? 무엇보다 단순하다. 두 축으로 자른 뒤 사분면에 던지면 끝이다. CIO가 이사회에서 설명하기 좋고, 개발팀 리드가 "이것은 왜 고치지 않는가"라는 질문에 답하기도 쉽다. 복잡한 점수 모델을 들고 가면 임원들은 졸기 마련이다.

 

두 축은 다음과 같다:

 

• 비즈니스 가치(Business Fit/Value) — 해당 애플리케이션이 회사에 얼마나 중요한지를 평가한다. 매출 기여도, 사용자 수, 전략적 비중이 지표다.
• 기술 적합성(Technical Fit/Quality) — 해당 애플리케이션이 기술적으로 얼마나 건강한지를 평가한다. 기술 부채, 벤더 지원, 운영 안정성이 지표다.

 

두 축으로 2×2 매트릭스를 그리면 네 개의 사분면이 만들어진다. 각 사분면에는 TIME의 글자가 하나씩 매핑된다. 비즈니스 가치가 낮고 기술도 그럭저럭이면 Tolerate, 둘 다 양호하면 Invest, 가치는 높은데 기술이 낡았으면 Migrate, 둘 다 나쁘면 Eliminate이다. 이것이 Gartner TIME 모델의 전부이다. 단순해 보이지만, 실무에 적용하려 하면 점수 기준을 정하는 단계에서 대부분 막힌다.

 

유사한 프레임워크로 Forrester의 TechRadar나 ThoughtWorks Technology Radar도 존재하지만, 그것들은 기술 트렌드 분류용이지 자사 애플리케이션 포트폴리오 분류용은 아니다. APM 용도에서는 TIME이 여전히 1순위이다.

 

TIME 모델의 네 가지 판단 — 어떤 앱이 어디에 들어가는가

 

각 사분면의 의미를 좀 더 깊이 들여다봐야 실무에서 헤매지 않는다. 단순히 "낮음/높음" 매트릭스로만 접근하면 경계에 걸친 케이스를 판단하기 어렵다.

 

Tolerate — 일단 놓아두는 것이 정답인 경우

 

비즈니스 가치 낮음 + 기술 상태 그럭저럭인 앱이다. 쓰지 않는 것은 아니지만 그렇다고 핵심도 아닌 시스템을 가리킨다. 굳이 추가로 돈을 쓰지도, 버리지도 않고 그대로 돌게 두는 것이다.

 

대표적인 예시는 분기에 한 번 도는 정산 배치, 월 1~2회 사용하는 사내 리포팅 툴, 특정 부서만 쓰는 워크플로우 도구 등이다. 이런 시스템에는 새 기능을 추가할 필요가 없다. 보안 패치만 챙기고 운영 인력을 최소로 배치해 두면 된다.

 

다만 Tolerate에는 함정이 있다. "일단 놓아두자"가 5년 이어지면 기술부채가 복리로 누적된다. 이 부분은 뒤에서 다시 다룬다.

 

Invest — 추가 투자 가치가 있는 앱

 

비즈니스 가치 높음 + 기술 상태도 양호한 앱이다. 핵심 매출 채널이거나, 고객 접점 시스템이거나, 회사 전략에 직결되는 시스템이 해당한다. 기술적으로도 아직 건강해서 갈아엎을 필요까지는 없는 상태다.

 

여기에는 적극적으로 자원을 투입한다. 신규 기능 추가, 성능 개선, 인프라 강화, DevOps 파이프라인 투자, 모니터링 강화가 대상이다. 핵심 시스템이므로 SRE 인력을 추가로 배치하고 가용성 99.9% 이상을 보장한다.

 

대표적인 예시는 이커머스 회사의 주문·결제 시스템, 핀테크의 거래 엔진, B2B SaaS의 핵심 제품 백엔드 등이다. 이런 시스템은 Invest 사분면에 영구 거주한다.

 

Migrate — 리호스트부터 리빌드까지의 스펙트럼

 

비즈니스 가치는 높지만 기술이 낡은 앱이다. 회사에 꼭 필요한데 코드가 10년 전 자바 1.6에 멈춰 있거나, 벤더가 이미 지원을 중단했거나, 확장이 불가능한 경우다. 그대로 두면 망가지고, 그렇다고 버릴 수도 없다. 반드시 Migrate 해야 한다.

 

Migrate는 한 가지 방법이 아니다. AWS의 6R 프레임워크(이후 Repurchase, Relocate가 추가되어 7R로 확장됨)와 매핑해 보면 스펙트럼이 드러난다:

 

6R 전략	TIME 매핑	적용 시점
Rehost (리프트앤시프트)	Migrate (최소 변경)	시간적 여유가 없어 일단 클라우드로 이전하는 경우
Replatform	Migrate (중간 변경)	OS·런타임만 교체
Refactor	Migrate (코드 변경)	비즈니스 로직을 유지하며 구조를 정리
Rearchitect	Migrate (구조 변경)	모놀리스에서 마이크로서비스로 전환
Rebuild	Migrate (재작성)	처음부터 재작성
Repurchase	Migrate (SaaS 전환)	자체 개발을 포기하고 SaaS로 대체
Retire	Eliminate	그대로 폐기

 

핵심 비즈니스 로직을 유지하면서 점진적으로 교체하고자 한다면 스트랭글러 패턴(Strangler Fig Pattern)이 정석이다. 신규 기능은 새 시스템에 붙이고, 기존 기능을 하나씩 라우팅을 옮기며 죽여 나가는 방식이다. Martin Fowler가 정리한 패턴으로, 레거시 마이그레이션의 기본기라 할 수 있다.

 

 

출처: samsungsds.com

 

Eliminate — 폐기가 정답인 앱

 

비즈니스 가치 낮음 + 기술도 엉망인 앱이다. 사용자가 거의 없고, 코드는 썩었으며, 운영비만 잡아먹는 시스템이다. 미련 없이 버려야 한다.

 

대표적인 케이스는 다음과 같다:

 

• 중복 기능 — 인수합병으로 동일 기능의 시스템이 2~3개 굴러다니는 경우. 통합하지 않으면 운영비 누수가 발생한다.
• Shadow IT — 특정 부서가 과거에 만들어 쓰던 사이드 시스템. 제작자는 이미 퇴사했고 아무도 모른다.
• EOL 벤더 — 벤더 자체가 사라졌거나 지원이 끊긴 솔루션. 보안 취약점 패치가 불가능하다.
• 사용자 없는 레거시 — 로그상 월 접속자가 5명 미만인데 "혹시 모르니까"라며 살려둔 시스템.

 

Eliminate가 결정됐다면 Decommission 체크리스트를 반드시 챙겨야 한다:

 

• 데이터 백업 및 보존(통상 법적 의무 7년)
• 감사 로그 아카이빙
• 외부 의존 시스템 연결 해제
• 사용자 공지 및 대체 가이드 제공
• 인프라 회수(서버, 라이선스, DB)
• 운영 인력 재배치 계획

 

이 과정을 챙기지 않고 서버를 그대로 끄면 6개월 뒤 감사에서 문제가 터진다.

 

어떻게 점수화할 것인가 — 평가 매트릭스 작성법

 

대부분의 Gartner TIME 모델 설명 글은 여기서 멈춘다. "비즈니스 가치 높음/낮음으로 분류하라"는 안내로 끝이 난다. 다만 실무에서는 "높음/낮음"을 어떻게 정의하느냐가 전부이다. 점수화를 거치지 않으면 회의에서 부서장끼리 서로 자기 시스템이 더 중요하다고 다투게 된다.

 

비즈니스 가치 평가 항목

 

5점 척도로 항목별 점수를 매기고 가중치를 곱해 합산하는 방식이 가장 무난하다. 예시는 다음과 같다:

 

평가 항목	가중치	5점 기준	1점 기준
매출 기여도	30%	월 10억 이상 직접 기여	매출 무관 내부 도구
사용자 수	20%	일 활성 사용자 1만 이상	월 활성 사용자 10명 미만
전략적 중요도	25%	회사 핵심 전략 직결	사라져도 영향 없음
규제 필수성	15%	법적으로 반드시 필요	법적 요구 무관
비즈니스 연속성	10%	다운 시 즉시 매출 손실	며칠 다운돼도 무관

 

이 매트릭스로 점수를 산출하면 시스템별로 1.0~5.0 사이의 값이 도출된다. 일반적으로 3.5 이상을 "비즈니스 가치 높음"으로 자르는 것이 표준적이다.

 

기술 적합성 평가 항목

 

기술 쪽도 마찬가지로 5점 척도를 적용한다:

 

평가 항목	가중치	5점 기준	1점 기준
기술 부채 수준	25%	최신 스택, 부채 없음	10년 이상 묵은 코드, 문서 없음
벤더 지원 상태	20%	활발한 지원, 정기 업데이트	EOL 또는 벤더 사라짐
운영 안정성	20%	가용성 99.9% 이상	월 다운타임 빈번
확장성	15%	수평 확장 자유로움	수직 확장만 가능, 한계 도달
보안 취약점	20%	최신 패치, 취약점 없음	알려진 CVE 다수, 패치 불가

 

마찬가지로 3.5 이상이면 "기술 적합성 양호", 그 미만은 "기술 적합성 불량"으로 분류한다.

 

점수에서 사분면으로의 매핑

 

두 축의 점수가 산출되면 사분면이 자동으로 결정된다:

 

• 비즈 ≥ 3.5 + 기술 ≥ 3.5 → Invest
• 비즈 ≥ 3.5 + 기술 < 3.5 → Migrate
• 비즈 < 3.5 + 기술 ≥ 3.5 → Tolerate
• 비즈 < 3.5 + 기술 < 3.5 → Eliminate

 

다만 경계에 걸친 케이스 — 양쪽 모두 3.4~3.6 사이 — 가 가장 골치 아프다. 이런 경우는 재평가 주기를 짧게(6개월) 잡고 추가 정성 평가를 병행해야 한다. 단순히 임계값만으로 자르면 매년 사분면이 요동치게 된다.

 

임계값은 회사마다 조정해야 한다. 보수적인 기업이라면 4.0으로 올려 Invest 비중을 줄이고, 적극적인 기업이라면 3.0으로 낮춰 Invest를 늘리는 식이다.

 

TIME 모델 적용 실패 사례와 함정

 

Gartner TIME 모델을 적용해 놓고도 실패하는 패턴이 몇 가지 있다. 실무자라면 누구나 한 번쯤 밟아본 지뢰이다.

 

Tolerate 영구 감옥

 

가장 흔한 실패이다. "일단 놓아두자"가 5년간 쌓이면 어떻게 되는가? 해당 시스템에 의존하는 다른 시스템이 4~5개 생기고, 운영자는 모두 퇴사하며, 코드를 짠 사람조차 사라진다. 그러다 보안 사고가 한 번 터진 뒤에야 Migrate를 시도하면 비용이 처음의 10배에 달한다. 기술부채의 복리란 바로 이런 것이다.

 

해결책은 Tolerate 시스템에도 재평가 주기를 강제로 설정하는 것이다. 권장 주기는 12~18개월이다. 해마다 한 번씩 "이 시스템이 여전히 Tolerate가 맞는가"를 되묻는 과정을 둬야 한다. 그렇지 않으면 영구 동결되어 버린다.

 

실제 사례를 보자. 한 제조 대기업은 90년대 ERP 보조 시스템을 "Tolerate"로 분류한 뒤 15년을 방치했다. 결국 마지막 운영자가 정년퇴직하면서 시스템이 멈췄고, 코드를 아는 사람이 아무도 남지 않아 외주 업체를 불러 6개월간 리버스 엔지니어링을 하다가 끝내 Eliminate로 결정됐다. 그동안 투입된 비용은 초기에 Migrate 했을 경우의 약 8배에 달했다.

 

Invest였으나 Eliminate로 귀결되는 케이스

 

비즈니스 가치 평가가 틀린 경우이다. 보통 두 가지 패턴이 관찰된다:

 

1. CIO 애착 시스템 — 임원이 과거에 스스로 도입한 시스템이라는 이유로 "전략적 중요도 5점"을 고정시키는 경우이다. 실제 사용자는 적은데 점수만 인위적으로 올라간다.
2. Sunk cost 오류 — 이미 3년간 10억을 투자했으니 멈출 수 없다는 논리이다. 다만 객관적으로 보면 사용률은 하락하고 있고 시장도 변한 뒤다.

 

이런 시스템은 Invest 분류로 1~2년 더 예산이 투입되다가, 신임 CIO가 오거나 외부 컨설팅이 개입하면 그제야 Eliminate로 결정된다. 그동안 쓰인 돈은 전부 매몰비용이다.

 

방어책은 분기별 사용 지표 추적을 의무화하는 것이다. Invest 사분면의 시스템이라 하더라도 사용자 수, 매출 기여, 트래픽 등 지표가 하락하면 자동으로 재평가 트리거가 걸리도록 해야 한다.

 

Migrate 중도 포기 리스크

 

Migrate가 결정되면 보통 1~2년짜리 프로젝트가 된다. 이 기간 동안 원본 시스템은 계속 돌아가고, 새 시스템도 구축되며, 인력은 두 배로 투입된다. 중간에 회사 사정으로 예산이 삭감되면 어떻게 되는가?

 

가장 흔한 실패는 리호스트만 하고 멈추는 것이다. 클라우드에 일단 옮겨 놨는데 리팩토링 예산이 사라져 그대로 방치되는 케이스다. 결과적으로 클라우드에 레거시가 복제된 꼴이 된다. 클라우드 비용은 더 많이 나오고 기술부채는 그대로 남는, 최악의 결과이다.

 

또 하나는 마이그레이션 기간 동안 원본·신규 시스템을 병행 운영하면서 비용이 폭증하는 문제이다. 원래 1년 걸릴 계획이 2년으로 늘어나면 운영 인력이 두 배로 1년 더 투입된다. 예산을 확보해 두지 않으면 프로젝트 자체가 좌초된다.

 

Migrate 결정 이전에 명확한 cutover 일정과 회수 시나리오를 먼저 정해야 한다. "6개월 안에 끝내지 못하면 자동으로 중단하고 원상복구한다"와 같은 규칙을 못 박아 두어야 좌초하지 않는다.

 

 

국내 맥락에서 TIME 모델을 적용할 때의 주의점

 

해외 자료를 그대로 적용하면 국내에서 통하지 않는 부분이 있다. 산업별로 정리한다.

 

금융권 — 망분리 규제(전자금융감독규정)와 금감원 보고 의무 때문에 Migrate 결정이 기술 판단만으로 끝나지 않는다. 클라우드로 옮기려면 CSP 안전성 평가, 망분리 우회 검토, 데이터 국외 이전 검토까지 모두 거쳐야 한다. 평가 매트릭스에 "규제 적합성" 항목을 별도로 추가해야 한다. 마이데이터 시대에 들어서며 다소 완화됐지만 여전히 까다롭다.

 

공공 — 전자정부프레임워크에 대한 의존성이 발목을 잡는다. eGovFrame 기반으로 구축된 시스템을 Eliminate 하려면 정무적 판단이 개입된다. 더욱이 공공조달은 5년 단위 사업 계약이므로 Migrate 결정도 사업 주기와 맞지 않으면 실행하지 못한다. TIME 분류는 끝났지만 실행은 다음 사업 발주 시점까지 대기하는 경우가 많다.

 

제조 — MES(생산관리)·ERP·SCADA·PLM 같은 시스템이 서로 얽혀 있어 하나만 Migrate 하기가 어렵다. 결과적으로 Tolerate가 장기화되는 경향이 있다. 의존성 맵을 그려 놓고 묶어서 처리할지 단계적으로 진행할지 사전에 결정해야 한다.

 

조직 인력 이슈 — TIME 분류는 기술 결정이지만 실행은 사람의 문제이다. Eliminate가 결정되면 해당 시스템의 운영자 5명을 어디로 재배치할지가 더 큰 문제로 떠오른다. Migrate를 하면 DBA·운영자에게 투입되는 신기술 재교육 비용이 시스템 마이그레이션 비용을 넘어서는 경우도 있다. 평가 매트릭스에 인력 영향도 항목을 추가하는 것이 현실적이다.

 

국내 SI 환경의 특수성도 고려해야 한다. 자체 개발 인력이 적고 외주 의존도가 높은 회사라면 Migrate 결정 시 외주 업체 의존성도 평가에 포함해야 한다. 코드를 아는 외주 업체가 한 곳뿐이라면 이는 사실상 EOL과 유사한 리스크이다.

 

TIME 모델을 넘어서 — APM 툴, 6R, 현대적 대안

 

Gartner TIME 모델은 출발점일 뿐 도착점이 아니다. 한계도 분명하다:

 

• 2축만으로는 부족 — 보안, 컴플라이언스, 인력 문제, 비용 등 다른 축이 누락된다
• 정적 분류 — 한 번 분류하고 끝나는 것이 아니라 6~12개월마다 재평가가 필요하다
• 점수화 자체가 정치적 — 부서장의 입김이 개입되면 점수가 왜곡된다

 

그래서 보완용으로 함께 쓰는 도구·프레임워크가 존재한다:

 

Gartner APM 툴 카테고리 — Magic Quadrant에 등재된 LeanIX, Mega HOPEX, Software AG Alfabet, Planview Mendix 같은 도구들이다. 수백 개 시스템의 메타데이터를 관리하고 점수를 매기며 시각화하는 과정을 자동화해 준다. 시스템이 50개를 넘기면 엑셀로 관리하는 데 한계가 온다.

 

AWS 6R/7R 프레임워크 — TIME의 Migrate 사분면을 더 세분화한 버전이다. Rehost, Replatform, Refactor, Rearchitect, Rebuild, Repurchase, Retire(+Retain)로 구성된다. 클라우드 이전을 결정할 때 TIME과 함께 쓰면 상호 보완이 된다.

 

Microsoft Cloud Adoption Framework — Microsoft판 클라우드 전환 가이드이다. 6R과 유사하지만 Azure 중심이며 거버넌스·운영 모델까지 포괄한다.

 

Forrester TechRadar / ThoughtWorks Tech Radar — 자사 앱 분류용이 아니라 기술 스택 평가용이다. Migrate 결정 이후 어떤 신기술을 도입할지 결정할 때 참고한다.

 

정리하면, TIME으로 큰 분류를 정하고, 6R로 Migrate 세부 전략을 수립하며, APM 툴로 자동화하고, Tech Radar로 신기술을 검토하는 식의 조합이 현실적이다.

 

핵심 정리와 다음 액션

 

여기까지 읽었다면 Gartner TIME 모델을 쓸 준비는 갖춰진 셈이다. 핵심 다섯 가지를 정리한다:

 

1. TIME = Tolerate·Invest·Migrate·Eliminate 네 분류에 모든 앱을 던지는 프레임워크이다. 두 축은 비즈니스 가치 × 기술 적합성이다.
2. 점수화 매트릭스 없이 분류하지 말 것 — 5점 척도와 가중치로 정량화해야 회의에서 다툼이 생기지 않는다.
3. Tolerate에 영구 감금하지 말 것 — 12~18개월마다 재평가를 강제한다.
4. Migrate는 6R로 세분화 — 리호스트만 하고 멈추는 것이 가장 흔한 실패이다. 명확한 cutover 일정을 못 박아 두어야 한다.
5. 국내 맥락 고려 — 망분리·전자정부프레임워크·인력 재배치 같은 비기술 변수를 평가 항목에 포함해야 한다.

 

다음 액션은 이렇다. 자사 시스템 목록을 엑셀로 뽑아 위 매트릭스 항목에 점수를 매기고, T/I/M/E 라벨을 붙여 본다. 50개를 넘어가면 LeanIX 같은 APM 툴 검토를 시작하고, 100개를 넘어가면 무조건 도입한다. 이것이 시작점이다. 한 번 라벨링을 해 두면 다음 1년치 IT 예산 회의에서 근거가 생긴다. 그렇게 하지 않으면 또다시 감으로 다투게 될 뿐이다.

 

레거시 현대화 로드맵을 본격적으로 짤 예정이라면 6R 프레임워크와 스트랭글러 패턴의 적용 사례를 더 깊이 살펴봐야 한다. TIME은 분류 단계이고, 그 다음 실행 단계에서 6R이 필요하다.