일회성 프로젝트를 넘어: Migration Factory로 확장하는 레거시 현대화

Migration Factory란 무엇인가

대부분의 기업은 첫 번째 마이그레이션을 프로젝트로 다룹니다. 전담 조직을 꾸리고, 방식을 정하고, 이전하고, 안정 가동을 확인한 뒤 해산합니다. 그 자체로 잘못된 것은 없습니다. 문제는 첫 번째가 마지막인 경우가 거의 없다는 점입니다.

옮겨야 할 애플리케이션이 수십 개, 수백 개인 상황에서 프로젝트 모델을 반복하면 결과는 대체로 예측 가능합니다. 방식이 건건이 달라지고, 품질 기준이 담당자에 따라 바뀌며, 지난번의 교훈이 다음 팀에 닿지 않습니다. 세 번째 이전에서도 첫 번째와 똑같은 조사를 똑같은 비용으로 다시 하고 있게 됩니다.

Migration Factory는 그 구조를 바꿉니다. 일회성 프로젝트의 연속이 아니라 표준화된 패턴, 공유 플랫폼, 반복 가능한 프로세스, 그리고 축적되는 지식을 갖춘 상시 역량으로 마이그레이션을 설계합니다. 여기서 ‘팩토리’라는 비유는 획일적인 대량 생산을 뜻하지 않습니다. 같은 프로세스가 여러 번 돌아간다는 전제를 받아들이고, 그 프로세스 자체에 투자한다는 의미입니다.

분명히 해 둘 것이 있습니다. 이것은 제품명이 아닙니다. 마이그레이션 자동화 도구를 도입한다고 Migration Factory가 되지는 않습니다. 이를 떠받치는 것은 다음 네 가지입니다.

왜 지금 이 모델인가

국내 환경에서 이 논의가 앞당겨지는 데에는 몇 가지 현실적인 이유가 있습니다.

사업 기간은 짧고 일정은 촘촘하다

차세대 시스템 사업은 대체로 정해진 기간 안에 끝내야 합니다. 그 압박 아래에서 속도만 끌어올리면 품질 게이트가 형식이 되고, 반대로 통제만 강화하면 일정이 무너집니다. Migration Factory가 겨냥하는 지점이 정확히 여기입니다. 속도와 안정성 중 하나를 고르는 대신, 반복되는 판단을 표준화해서 둘 다 확보하는 것입니다.

대상이 하나가 아니다

메인프레임이나 온프레미스에서 옮겨야 할 자산은 단독으로 존재하지 않습니다. 서로 호출하고, 같은 기준 데이터를 참조하며, 같은 배치 윈도우를 나눠 씁니다. 애플리케이션 단위로만 판단하면 개별적으로는 최적이지만 전체적으로는 어긋난 시스템이 남습니다.

기한이 한꺼번에 온다

하드웨어·미들웨어 지원 종료, 데이터센터 계약 만료, 클라우드 전환 방침 변경은 차례대로 줄을 서 주지 않습니다. 같은 시기에 몰리고, 순차 처리 방식은 그 시점부터 성립하지 않습니다.

편차가 곧 운영 비용이 된다

웨이브마다 구성이 조금씩 달라지면 운영 조직은 매번 다른 장애 대응 절차와 다른 모니터링 설정을 떠안습니다. 마이그레이션이 끝나는 순간부터 ‘이전 후의 다양성’이 비용을 청구하기 시작합니다.

보안·감독 요건은 나중에 붙이면 비싸다

인증, 암호화, 로깅, 권한 분리는 랜딩 존에 처음부터 포함하면 저렴하고, 가동 후 애플리케이션마다 덧붙이면 비쌉니다. 금융권처럼 감독 요건이 계속 강화되는 영역에서는 이 비용 차이가 특히 큽니다. DevSecOps를 파이프라인에 넣는 이유도 결국 같습니다.

지식이 증발한다

가장 눈에 띄지 않는 손실입니다. 왜 그 방식을 골랐는지, 어디서 막혔는지, 어떻게 해결했는지가 프로젝트 종료와 함께 흩어집니다. 다음 팀은 같은 함정을 같은 값을 치르고 다시 발견합니다.

Migration Factory를 구성하는 6가지 요소

운영 모델로 성립하려면 다음 여섯 가지 기능이 모두 있어야 합니다. 하나가 빠져도 나머지는 돌아가지만, 전체적으로는 개별 프로젝트의 집합으로 조용히 되돌아갑니다.

AI는 어디에 놓아야 하는가

여섯 요소 중 AI의 효과가 가장 큰 곳은 01과 04입니다. 소스 코드 분류, 의존 관계 추출, 사라진 문서 재구성, 테스트 케이스 생성 — 모두 종래에는 전문 인력이 수개월을 들이던 영역이고, 지금은 소요 시간을 크게 압축할 수 있습니다.

반면 AI가 단독으로 결론을 낼 수 없는 영역도 분명합니다. 레거시 코드에 담긴 것은 로직만이 아니라 업무상의 예외와 그렇게 된 경위이기 때문입니다. 특정 거래처에만 적용되는 분기, 회계 정책에서 비롯된 반올림 규칙, 이미 개정된 규정에 맞춰 작성된 날짜 검증 — 정적 분석은 이것들을 코드로 돌려줄 뿐, 의도로 돌려주지 않습니다. 업무를 아는 사람만이 분류할 수 있습니다.

팀 설계와 책임 범위

Migration Factory는 상시 유지되는 역할과 웨이브마다 편성되는 역할을 나눠 봅니다. 누가 무엇을 결정하는지 문서로 명시하는 것은 형식이 아닙니다. 품질 게이트가 판단이 멈추는 지점이 되지 않게 하는 장치입니다.

역할 분담 레퍼런스. 조직 규모에 따라 여러 역할을 겸임하는 경우가 일반적입니다.

역할	주요 책임	지속성
포트폴리오 오너	전체 우선순위 결정, 웨이브 순서 승인, 경영진 보고	상시
마이그레이션 아키텍트	패턴 정의, 방식 적합성 판단, 예외 심의	상시
플랫폼 팀	랜딩 존, CI/CD, 관측성, 공통 기반 구축 및 개선	상시
웨이브 팀	담당 웨이브의 설계·구현·테스트·전환	웨이브 단위
애플리케이션 오너	업무 사양 확인, 예외 규칙 설명, 인수 판단	업무 단위
QA·보안	게이트 기준 수립과 검증, 보안 요건 증적 책임	상시
FinOps	비용 가시화, 방식 비교에 비용 입력, 가동 후 최적화	상시
운영·SRE	모니터링 설계, 전환 시 1차 대응, 안정 가동 확인	상시
PM·브리지 엔지니어	진척과 쟁점 관리, 언어와 시차를 넘는 합의 형성	상시

표준 프로세스 (레퍼런스)

모든 웨이브가 통과하는 표준 공정입니다. 순서를 매번 바꾸지 않는 것이 비교 가능한 진척 관리와 지식 축적의 전제입니다. 주황색 공정은 통과하지 못하면 다음으로 넘어가지 않는 판단 지점입니다.

다국적 환경에서의 운영

오프쇼어와 니어쇼어, 고객사 내부 팀이 함께 움직이는 체제라면 지역마다 일하는 방식의 전제가 다릅니다. 프로젝트 중반에 발견하기보다 처음에 명시해 두는 편이 낫습니다.

한국: 실행 속도와 가시성의 양립

• 커뮤니케이션: 결론과 다음 액션을 먼저, 배경은 뒤에.
• 보고: 짧은 주기의 진척 대시보드로 상시 가시화.
• 의사결정: 짧은 PoC로 방식을 확정하고 빠르게 본 전개로 넘어가는 흐름이 일반적.
• 품질 게이트: 자동화와 DevSecOps를 전제로, 통제가 속도를 깎지 않도록 설계.
• 소구점: 운영 안정성, 비용 최적화, 자동화, 확장성, 운영 효율.

글로벌·분산 팀: 비동기 자율 운영

• 커뮤니케이션: 시차가 겹치지 않는다는 전제로, 의사결정에 필요한 정보를 문서에 모읍니다.
• 보고: 대시보드로 상시 가시화하고, 대면 회의는 예외와 판단 사항에 한정.
• 의사결정: 위임 범위를 사전에 정의하고 그 안에서는 확인 없이 진행.
• 품질 게이트: 자동 기준 준수를 우선하고 사람의 리뷰는 예외에 한정.
• 소구점: 비즈니스 성과, 확장성, 보안·컴플라이언스 내재화, 측정 가능한 딜리버리.

일본: 합의 형성과 증적 중시

• 커뮤니케이션: 결론뿐 아니라 판단에 이른 과정과 검토한 대안까지 공유.
• 보고: 정례의 문서 기반 보고. 과제는 발생 시점에 공유하고 해결 후 몰아서 보고하지 않음.
• 의사결정: 합의에 시간이 걸리는 대신 결정 후 변경이 적습니다. 이 특성을 계획에 반영.
• 품질 게이트: 증적 입도를 세밀하게 설계. 테스트 결과에 비교 대상과 조건까지 남김.
• 소구점: 안정 가동, 업무 중단 없는 전환, 리허설과 롤백 대비, 일본어 대응 체제.

베트남: 단계적 투자와 지식 이전

• 커뮤니케이션: 기술 용어는 영어를 유지하되 업무 요건은 현지어로 확인.
• 보고: 비용과 진척을 같은 화면에서 보는 형식을 선호.
• 의사결정: 기존 자산을 살리며 단계적으로 투자하는 판단이 많고, 전면 교체를 출발점으로 두지 않음.
• 품질 게이트: 자동화와 함께 담당자 지식 이전을 공정에 포함.
• 소구점: 예산에 맞는 로드맵, 기존 시스템 활용, 유연한 팀 확장.

측정해야 할 지표

모델이 작동하고 있는지는 감각이 아니라 지표로 확인합니다. 아래는 측정 항목의 예입니다. 기준값은 조직과 자산의 성격에 따라 크게 달라지므로, 현실적인 출발점은 자사의 첫 웨이브 실적을 기준선으로 삼는 것입니다.

자주 발생하는 실패

1. 운영 모델을 정하기 전에 도구부터 구매한다

마이그레이션 자동화 도구는 통과시킬 공정이 정해져 있어야 효과가 납니다. 프로세스도 패턴도 미정인 상태에서 도입하면 도구에 맞춰 공정을 비틀게 되고 예외 처리가 오히려 늘어납니다. 먼저 정할 것은 누가 무엇을 판단하는가입니다.

2. 컷오버 속도만 최적화한다

전환 당일을 짧게 만드는 데 집중한 나머지 안정화와 구 환경 폐기가 뒤로 밀리는 경우입니다. 구 환경이 멈추지 않으면 비용은 이중으로 계속 나갑니다. 마이그레이션이 끝났다고 말할 수 있는 시점은 폐기까지 완료한 때입니다.

3. 안정되지 않은 공정을 자동화한다

절차가 굳어지지 않은 작업을 자동화하면 예외가 생길 때마다 자동화 자체를 수정하게 되고, 유지보수 부하가 절감 효과보다 빠르게 늘어납니다. 같은 절차를 수동으로 세 번 통과시킨 뒤 자동화하는 순서가 현실적입니다.

4. FinOps를 마지막에 끌어들인다

이전이 끝난 뒤에 비용을 집계하면 태깅도 계정 설계도 뒤따라가는 형태가 되어 어떤 애플리케이션에 얼마가 드는지 분해할 수 없습니다. 비용 가시화는 랜딩 존 표준으로 처음부터 내장해야 합니다.

5. 팀마다 서로 다른 데이터를 갖는다

자산 목록은 아키텍트가, 진척은 PM이, 비용은 재무가 각각 다른 표로 관리하는 상태입니다. 숫자가 맞지 않아 회의가 대사 작업에 소모되고 판단이 늦어집니다. 단일 정보원을 정하는 것은 도구 선정보다 앞서는 합의 사항입니다.

6. 본가동 직후에 프로젝트를 종료한다

가동 개시를 목표선으로 잡으면 최적화, 폐기, 플레이북 갱신이 실행되지 않습니다. 결과적으로 다음 웨이브는 이전과 같은 공수를 요구합니다. 학습을 남기지 않는 이전은 몇 번을 해도 조직의 역량이 되지 않습니다.

BAP의 역할

BAP는 레거시 시스템 현대화, COBOL에서 Java로의 코드 전환, 클라우드 마이그레이션, 데이터베이스 전환을 수행하고 있습니다. Migration Factory 맥락에서는 다음과 같은 형태의 참여를 상정합니다.

• 현황 조사와 자산 가시화: 자산 정리, 의존 관계 정돈, 현업 인터뷰를 통한 사양 재구성.
• PoC를 통한 방식 검증: 본 전개 전에 변환 방침·목표 아키텍처·테스트 방식을 실증하고 공수와 품질의 견적 정밀도를 높입니다.
• 웨이브 단위의 단계적 전환: 업무 단위·데이터 단위의 분할과 실행.
• 개발과 테스트: Java/Spring 개발, 웹 화면·리포트 재구축, 데이터 이전, 단위 테스트부터 UAT까지의 엔드투엔드 품질 보증.
• 딜리버리 체계: 오프쇼어, 온사이트, 하이브리드. 한국어·영어·일본어·베트남어 대응.
• 전환 후 운영과 지식 이전: 안정화 지원과 고객 측 팀으로의 인계.

한 가지는 분명히 해 두는 편이 좋습니다. Migration Factory를 통째로 외부에 맡기는 것은 본래 목적과 모순됩니다. 반복 가능한 역량은 고객 측에 남아야 의미가 있기 때문입니다. 합리적인 협업 형태는 초기 웨이브에서 함께 방식을 정립하고, 표준과 플레이북을 갖춘 뒤, 조직이 스스로 운영할 수 있는 상태로 인계하는 것입니다.

맺으며

Migration Factory는 새로운 도구 범주가 아닙니다. 이전이 여러 번 반복된다는 전제를 받아들이고, 그에 맞는 공정·기반·데이터·체제를 물량이 몰리기 전에 미리 갖춰 두는 운영상의 선택입니다.

판단 자체는 복잡하지 않습니다. 대상이 몇 개라면 개별 프로젝트로 진행하는 편이 빠르고 저렴합니다. 수십 개 이상이고, 기한이 겹치며, 같은 판단이 반복될 전망이라면 표준화 투자에 현실적인 회수 경로가 생깁니다.

어느 쪽을 택하든 첫걸음은 같습니다. 자산 정리와 의존 관계 가시화입니다. 규모와 구조가 보여야 어떤 모델이 적절한지 논의할 수 있습니다.