레거시 시스템 전환, 고쳐 쓸 것인가 다시 만들 것인가 — 재구축 판단 기준과 데이터 이관 체크포인트

레거시 시스템 전환을 본격적으로 검토하게 되는 순간은 대개 거창한 디지털 전환 계획에서 시작되지 않습니다. 현업 부서에서 기능 하나만 추가해 달라는 요청이 올라오고, 유지보수를 맡고 있는 개발사로부터 “그건 지금 구조상 어렵습니다”라는 답이 돌아오는 날입니다. 요청받은 기능 자체는 복잡하지 않습니다. 화면 하나를 더하고 조건 하나를 거는 수준입니다. 그런데 돌아온 견적은 예상보다 크고, 일정은 몇 달 뒤로 잡히며, 담당자는 그제서야 이 시스템이 더 이상 고쳐 쓰는 단계가 아닐 수도 있다는 가능성을 처음으로 마주합니다.

10년 가까이 운영해 온 사내 시스템, 학사 시스템, 빌딩 관리 시스템, ERP는 대부분 비슷한 경로를 지나갑니다. 처음에는 잘 만들어진 시스템이었고, 몇 년 동안은 작은 수정으로 충분했습니다. 문제는 그 수정이 쌓인 다음에 나타납니다. 기능을 덧붙일 때마다 예외 처리가 늘고, 예외 처리가 늘수록 다음 수정의 범위를 아무도 자신 있게 말하지 못하게 됩니다. 어느 시점부터는 “이 정도 수정이면 얼마나 걸립니까”라는 질문에 개발사도 정확히 답하지 못합니다. 그 상태가 1년 이상 이어지고 있다면, 그것은 기능의 문제가 아니라 구조의 문제입니다.

디비컨설팅은 이런 구조 문제를 다뤄 온 회사입니다. 지금까지 100개 이상의 프로젝트를 수행했고, 50개 이상의 글로벌 파트너사와 함께 일하고 있으며, 고객 만족도는 98%입니다. 가천대학교 학사관리 시스템, 센터필드·센트로폴리스·그랑서울의 프라임 오피스 빌딩 관리 시스템처럼 기관과 대형 건물의 운영을 실제로 떠받치는 시스템을 구축했고, 삼성물산 홈닉 주거 플랫폼 앱, GS건설 엘리시안 리조트 웹·앱, LS일렉트릭 테크스퀘어 B2B 거래 플랫폼처럼 대기업의 사업용 플랫폼도 함께 만들었습니다. 이 모든 프로젝트의 공통 구조는 하나입니다. 한국인 PM이 요구사항 정의와 일정, 검수를 책임지고, 검증된 글로벌 개발팀이 구현을 맡습니다.

이 글은 RFP를 준비하고 있거나 준비를 앞둔 담당자를 위한 것입니다. 지금 시스템을 계속 고쳐 쓸 것인지 다시 만들 것인지 판단하는 기준, 세 가지 발주 방식이 실제로 무엇이 다른지, 그리고 레거시 시스템 전환에서 가장 자주 사고가 나는 지점인 데이터 이관을 발주 조건에 어떻게 반영해야 하는지를 순서대로 정리했습니다. 웹 개발 외주를 포함한 전면 재구축을 검토 중이라면 특히 네 번째 항목부터 보시기 바랍니다.

왜 “조금만 고치자”가 가장 비싼 선택이 되는가

기능이 아니라 구조가 한계에 닿은 것이다

담당자가 받는 요청은 대개 기능 단위입니다. 결재선을 한 단계 더 추가해 달라, 특정 부서만 볼 수 있는 조회 화면을 하나 만들어 달라, 엑셀로 내려받는 항목을 늘려 달라. 요청 자체는 작습니다. 그런데 개발사에서 돌아오는 답은 “그 화면만 바꾸면 되는 게 아닙니다”입니다. 이 대답은 핑계가 아닌 경우가 많습니다. 오래된 시스템은 화면과 업무 로직과 데이터가 분리되어 있지 않은 경우가 흔하고, 한 군데를 건드리면 전혀 다른 화면에서 오류가 납니다.

이 단계에 들어서면 개발 비용의 성격이 바뀝니다. 기능을 만드는 데 드는 시간보다, 그 기능이 다른 곳을 망가뜨리지 않는지 확인하는 데 드는 시간이 더 커집니다. 요청 하나를 처리하기 위해 관련 없어 보이는 화면까지 전부 다시 확인해야 한다면, 그것은 테스트가 꼼꼼해서가 아니라 구조가 기능을 지탱하지 못하고 있다는 신호입니다.

여기서 담당자가 흔히 하는 판단이 “일단 이번 건만 처리하고 넘어가자”입니다. 합리적인 결정처럼 보이지만, 이 결정은 다음 요청이 들어올 때 똑같은 비용을 다시 치르게 만듭니다. 구조는 그대로이기 때문입니다.

고칠 사람이 남아 있지 않다 — 문서 없는 시스템의 인수인계 비용

오래된 시스템의 두 번째 문제는 사람입니다. 처음 구축을 맡았던 개발사의 담당자가 퇴사했고, 그 다음 유지보수를 맡은 업체도 바뀌었습니다. 내부에서는 처음 도입을 주도했던 담당자가 다른 부서로 이동했거나 이미 회사를 떠났습니다. 지금 이 시스템이 왜 이렇게 동작하는지를 전체로 설명할 수 있는 사람이 조직 안에 한 명도 없는 상태가 드물지 않습니다.

이 상태에서 새로운 업체에 유지보수를 맡기면, 그 업체는 먼저 시스템을 읽는 데 시간을 씁니다. 문서가 없으면 소스코드와 데이터베이스를 직접 열어 보면서 업무 규칙을 역으로 추정해야 합니다. 이 과정은 눈에 보이는 산출물을 만들지 않지만 실제로는 가장 큰 비용 항목입니다. 그리고 추정은 틀릴 수 있습니다. 틀린 추정 위에 기능을 얹으면 그 오류는 몇 달 뒤 현업에서 발견됩니다.

더 중요한 사실은, 이 비용을 한 번 치렀다고 끝나지 않는다는 점입니다. 업체가 또 바뀌면 처음부터 다시 시작합니다. 문서가 없는 시스템은 유지보수 업체를 바꿀 때마다 같은 학습 비용을 반복해서 청구하게 되어 있습니다.

매번의 수정이 다음 수정을 더 비싸게 만든다

정상적인 시스템이라면 수정을 거듭할수록 그 시스템을 다루는 난이도가 낮아져야 합니다. 구조를 이해한 사람이 늘고, 반복되는 작업이 정리되기 때문입니다. 레거시 시스템에서는 반대 방향으로 움직입니다. 수정할 때마다 예외가 하나씩 추가되고, 그 예외는 어디에도 기록되지 않습니다.

현장에서 이 현상은 견적의 모양으로 드러납니다. 2년 전에는 2주면 되던 수준의 요청이 지금은 한 달 이상으로 잡힙니다. 기능이 더 복잡해진 것이 아니라, 건드려야 할 범위와 확인해야 할 범위가 넓어진 것입니다. 담당자 입장에서는 개발사가 비싸졌다고 느끼기 쉽지만, 실제로 비싸진 것은 시스템입니다.

이 곡선은 시간이 지나도 완만해지지 않습니다. 그래서 “조금만 고치자”는 선택은 매년 같은 비용을 쓰는 선택이 아니라, 매년 더 많이 쓰면서 자산은 늘지 않는 선택이 됩니다. 시스템 재구축을 검토해야 하는 이유는 지금 당장 불편해서가 아니라, 이 곡선이 꺾이지 않기 때문입니다.

고도화할 것인가, 재구축할 것인가 — 판단 기준

레거시 시스템 전환에서 가장 위험한 결정 방식은 감각에 의존하는 것입니다. 현업의 불만이 임계점을 넘었을 때, 또는 장애가 한 번 크게 났을 때 재구축을 결정하면 판단의 근거가 사건이 됩니다. 사건은 시스템의 상태를 정확히 반영하지 않습니다. 운이 좋아 장애가 나지 않은 시스템도 구조적으로는 이미 한계에 와 있을 수 있고, 반대로 한 번의 장애가 구성 설정 문제인 경우도 있습니다.

반대로 흔한 또 하나의 패턴은 재구축을 무기한 미루는 것입니다. 지금 당장 돌아가고 있고, 전환에는 리스크가 따르며, 담당자 개인에게는 재구축을 추진했다가 문제가 생기는 쪽이 더 부담스럽기 때문입니다. 이 판단도 근거가 아니라 심리에서 나옵니다. 결과적으로 결정은 다음 담당자에게 넘어가고, 그 사이 시스템 고도화의 비용은 계속 올라갑니다. 웹사이트 리뉴얼에서도 같은 구조가 반복됩니다.

그래서 이 결정은 기준으로 내려야 합니다. 아래 신호는 기능의 불편이 아니라 구조의 한계를 가리키는 항목들입니다. 경영진에게 보고할 때도 이런 형태의 체크리스트가 훨씬 설득력이 있습니다. 다음 중 3개 이상에 해당하면 재구축 검토 단계로 보시면 됩니다.

• 신규 기능을 하나 추가할 때마다 시스템 전체에 대한 회귀 테스트가 필요하다
• 운영 서버 구성과 배포 절차를 정확히 아는 사람이 사내외를 통틀어 한 명뿐이다
• 외부 시스템이나 신규 솔루션과 연동할 때마다 매번 별도 개발 건으로 잡힌다
• 모바일 대응이 화면 조정이 아니라 구조 변경 없이는 불가능하다
• 사용 중인 프레임워크나 서버 환경이 보안 패치 지원이 종료된 버전이다
• 어떤 데이터가 어디에 어떤 형태로 저장되어 있는지 전체를 설명할 수 있는 사람이 없다
• 현업에서 시스템 밖의 엑셀로 관리하는 업무가 해마다 늘고 있다

세 가지 발주 방식 — 무엇이 실제로 다른가

RFP를 준비하는 단계에서 담당자가 비교하게 되는 선택지는 보통 두 가지로 좁혀집니다. 국내 개발사에 맡기거나, 비용을 줄이기 위해 해외 개발팀에 직접 발주하는 것입니다. 그런데 실제 선택지는 세 가지입니다. 세 번째는 한국인 PM이 요구사항 정의와 일정 관리, 검수를 맡고 글로벌 개발팀이 구현을 담당하는 구조입니다. 디비컨설팅이 운영하는 IT 아웃소싱 방식이 이것이고, 국내 채용 대비 평균 40~60%의 비용 절감이 가능한 것도 이 구조 덕분입니다.

세 방식을 비교할 때 담당자들이 가장 먼저 보는 행은 개발 단가입니다. 그런데 레거시 시스템 전환에서 결과를 가르는 행은 단가가 아닙니다. 요구사항 정의 책임과 재작업 리스크, 그리고 발주사 담당자의 투입 시간입니다.

	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
개발 단가	높음	낮음	낮음
요구사항 정의 책임	개발사	발주사 본인	한국 PM
커뮤니케이션 언어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	매우 많음	적음
재작업 리스크	낮음	높음	낮음
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

요구사항 정의 책임부터 보겠습니다. 신규 서비스 구축이라면 요구사항은 기획서로 전달할 수 있습니다. 하지만 레거시 전환은 다릅니다. 전달해야 하는 것은 “무엇을 만들고 싶은가”가 아니라 “지금 시스템이 무엇을 어떤 규칙으로 처리하고 있는가”입니다. 10년 치 예외 처리와 부서별 운영 관행이 전부 여기에 포함됩니다. 해외 개발팀에 직접 발주하면 이 설명은 발주사 담당자가 영어로 해야 합니다. 본인 업무를 하면서, 한국어로도 문서화된 적 없는 업무 규칙을 영어로 정리해 전달하고, 질문에 답하고, 결과물을 검수해야 한다는 뜻입니다. 단가는 낮아지지만 담당자 한 사람이 사실상 PM 역할을 떠안게 되고, 이것이 해외 직접 발주가 기대만큼 저렴해지지 않는 가장 큰 이유입니다.

재작업 리스크는 그 결과로 따라옵니다. 업무 규칙이 부정확하게 전달되면 개발은 정상적으로 끝나지만 결과물이 현업의 실제 업무와 어긋납니다. 이 어긋남은 대개 QA가 아니라 현업 사용 단계에서 발견되고, 그 시점의 수정은 처음부터 제대로 정의했을 때보다 훨씬 비쌉니다. 한국인 PM 구조가 하는 일은 단가를 깎는 것이 아니라 이 재작업 구간을 없애는 것입니다. 요구사항을 한국어로 정의하고, 그 정의를 개발팀이 실행할 수 있는 형태로 번역하는 책임을 발주사가 아니라 PM이 집니다. 총비용 관점에서 실질 절감이 나오는 지점도 바로 여기입니다.

데이터 이관에서 실제로 터지는 문제

레거시 시스템 전환 프로젝트가 일정을 넘기거나 오픈 직후 혼란을 겪는 원인은 대부분 신규 개발이 아닙니다. 데이터 이관입니다. 개발은 범위가 보이고 진척이 측정되지만, 이관은 기존 시스템의 실제 상태에 전적으로 좌우되고 그 상태는 열어 보기 전까지 아무도 정확히 모릅니다.

쓰이지 않는 줄 알았던 데이터가 쓰이고 있다

이관 범위를 정할 때 보통 “지금 쓰는 데이터만 옮긴다”는 원칙을 세웁니다. 문제는 쓰는지 아닌지를 판단하는 기준입니다. 화면에 노출되지 않는 항목, 몇 년째 신규 입력이 없는 테이블은 자연스럽게 제외 대상이 됩니다. 그런데 특정 부서가 분기마다 한 번씩 조회하거나, 외부 기관 제출 자료를 만들 때만 참조하는 데이터가 여기에 섞여 있는 경우가 자주 나타납니다.

이런 누락은 전환 직후가 아니라 몇 달 뒤 해당 업무 시점에 발견됩니다. 그때는 기존 시스템이 이미 내려가 있거나 접근 권한이 정리된 뒤일 수 있습니다. 그래서 이관 범위는 개발팀이 데이터만 보고 정할 수 없고, 현업 부서별 확인 절차가 일정에 들어가 있어야 합니다.

같은 항목이 부서마다 다른 의미로 입력돼 있다

두 번째 문제는 더 조용히 진행됩니다. 비고, 구분, 상태값 같은 항목이 부서마다 다른 규칙으로 쓰이고 있는 경우입니다. 시스템이 강제하지 않는 자유 입력 항목에 각 부서가 자기 방식의 약속을 넣어 운영해 왔고, 그 약속은 어디에도 문서화되어 있지 않습니다. 담당자가 바뀌면서 같은 부서 안에서도 시기별로 규칙이 달라진 경우도 있습니다.

신규 시스템은 보통 이 항목들을 정규화합니다. 선택 목록으로 바꾸고 필수 값으로 지정합니다. 이때 과거 데이터를 어떤 기준으로 매핑할지 결정해야 하는데, 원래의 의미를 모르면 매핑은 추정이 됩니다. 잘못 매핑된 과거 데이터는 통계와 보고서를 조용히 틀리게 만들고, 오류를 알아차렸을 때는 이미 그 데이터를 기준으로 의사결정이 몇 번 내려진 뒤입니다. 그래서 이관 설계 전에 현행 업무 규칙을 문서로 복원하는 작업이 반드시 선행되어야 합니다.

전환 당일, 두 시스템이 동시에 돌아가는 구간

세 번째는 전환 시점의 문제입니다. 운영 중인 시스템은 전환 작업 중에도 데이터가 계속 쌓입니다. 이관을 시작한 시점과 신규 시스템을 여는 시점 사이에 입력된 데이터를 어떻게 처리할지 정해 두지 않으면, 두 시스템에 서로 다른 내용이 남습니다. 업무가 멈추지 않는 조직일수록 이 구간이 길어지고 위험도 커집니다.

이 구간은 기술로만 해결되지 않습니다. 전환 시점을 업무량이 적은 시기로 잡을 것인지, 특정 기능부터 단계적으로 넘길 것인지, 전환 중 입력을 일시적으로 제한할 것인지는 현업과 합의해야 하는 운영 결정입니다. 그래서 발주 조건에는 개발 일정만이 아니라 이관 리허설과 롤백 계획이 반드시 포함되어야 합니다. 실제 데이터로 한 번 이상 예행연습을 하고, 문제가 생겼을 때 기존 시스템으로 되돌릴 절차가 문서로 있어야 한다는 뜻입니다. RFP에 이 두 항목이 들어 있는지 여부만으로도 제안사의 수준이 꽤 갈립니다.

디비컨설팅은 이 과정을 어떻게 관리하는가

디비컨설팅은 모든 프로젝트를 다섯 단계로 진행합니다. 레거시 시스템 전환에서는 각 단계에서 확인하는 내용이 신규 구축과 달라집니다.

1단계 — 상담 및 요구 분석. 비즈니스 목표와 기술 요구사항을 한국어로 문서화합니다. 레거시 전환에서 이 단계의 핵심은 새 기능을 정의하는 것이 아니라 현행 업무 규칙을 먼저 문서로 복원하는 일입니다. 지금 시스템이 어떤 조건에서 무엇을 어떻게 처리하고 있는지, 부서별로 다르게 운영되는 항목은 무엇인지, 외부 시스템과 주고받는 데이터는 무엇인지를 확인해 정리합니다. 요구사항 정의서를 어디까지 써야 하는지도 이 단계에서 함께 정합니다. 이 작업을 건너뛰면 이후 모든 단계가 추정 위에서 진행됩니다. 뒤에서 발생하는 재작업의 대부분이 이 단계에서 제거됩니다.

2단계 — 개발팀 구성. 확정된 요구사항에 맞춰 전담팀을 2~4주 안에 구성합니다. 50개 이상의 글로벌 파트너사 네트워크를 통해 해당 기술 스택과 도메인 경험이 있는 인력을 배치합니다. 발주사는 인력을 검색하거나 면접을 보는 과정에 들어가지 않습니다.

3단계 — 프로젝트 개발. 애자일 방식으로 진행하며 진행 상황을 투명하게 공유합니다. 발주사 담당자는 한국인 PM하고만 한국어로 소통하고, 개발팀과의 일정 조율이나 기술 커뮤니케이션은 PM이 처리합니다. 발주사 담당자가 하루를 조율에 쓰지 않는 구조를 만드는 것이 이 단계의 목표입니다.

4단계 — 테스트 및 배포. QA를 거쳐 릴리스합니다. 레거시 전환에서는 여기에 데이터 이관 리허설이 포함됩니다. 실제 데이터를 사용해 이관을 수행하고, 건수와 주요 집계 항목, 핵심 업무 시나리오가 기존 시스템과 일치하는지 대조합니다. 롤백 절차도 이 단계에서 확인합니다.

5단계 — 운영 및 유지보수. 문서와 함께 인계합니다. API 명세, DB 스키마, 배포 절차까지 포함합니다. 레거시 시스템 전환에서 가장 중요한 단계가 바로 여기입니다. 앞의 네 단계를 아무리 잘 수행해도 문서 없이 인계되면 새 시스템은 몇 년 뒤 똑같은 레거시가 됩니다. 지금 겪고 있는 문제의 원인이 과거의 기술 선택이 아니라 과거의 인계 방식이었다는 점을 생각하면, 이 단계를 계약 조건에 명시하는 것이 다음 전환을 막는 가장 확실한 방법입니다.

실제 구축 사례

• 가천대학교 학사관리 시스템 — 다수의 사용자 유형과 학사 일정에 따라 업무 규칙이 달라지는 기관 핵심 시스템을 구축했습니다. 운영 중단이 허용되지 않는 환경에서의 구축 경험입니다. 교육기관 대상 LMS 구축과도 이어집니다.
• 센터필드 · 센트로폴리스 · 그랑서울 프라임 오피스 빌딩 관리 시스템 — 대형 오피스 빌딩의 운영 업무를 다루는 관리 시스템을 구축했습니다. 복수의 대형 자산에 적용되는 공통 구조를 설계한 사례이며, BMS 구축으로 이어지는 영역입니다.
• LS일렉트릭 테크스퀘어 — 산업 B2B 거래 플랫폼을 구축했습니다. 기업 간 거래 절차와 권한 체계가 복잡하게 얽힌 업무를 시스템으로 옮긴 프로젝트입니다.
• 삼성물산 홈닉 — 주거 플랫폼 앱을 구축했습니다. 다수의 실사용자가 일상적으로 사용하는 서비스의 설계와 운영 경험입니다.
• GS건설 엘리시안 리조트 — 리조트 웹과 앱을 통합 구축했습니다. 웹과 모바일을 하나의 구조로 함께 설계한 사례입니다.

그 밖의 구축 사례는 포트폴리오에서 확인하실 수 있습니다.

이런 기업에 적합합니다 / 반대로 권하지 않습니다

적합한 경우

• 운영 중인 시스템을 멈추지 않은 상태에서 전환해야 하는 곳
• 내부에 개발 조직이 없거나 담당 인력이 1~2명뿐인 곳
• 업무 규칙이 문서가 아니라 담당자 머릿속에 남아 있어, 요구사항 정의부터 함께 해야 하는 곳
• 기존 유지보수 업체와의 계약 종료를 앞두고 있고 다음 구조를 결정해야 하는 곳
• 비용은 줄여야 하지만 영어로 해외 개발팀을 직접 관리할 여력은 없는 곳

권하지 않는 경우

• 이미 충분한 내부 개발 조직과 아키텍트가 있고 설계를 스스로 통제하고 있는 곳. 이 경우에는 외부 PM 구조가 한 단계를 더 만드는 결과가 됩니다.
• 화면 디자인이나 UI 일부 수정만 필요한 곳. 구조를 건드릴 필요가 없다면 현재 유지보수 체계를 유지하는 편이 낫습니다.
• 요구사항을 확정할 내부 의사결정자가 없는 곳. 부서 간 이견을 정리할 주체가 없으면 어떤 발주 방식도 일정 안에 끝나지 않습니다.
• 수개월 내 조직 개편이나 사업 구조 변경이 예정되어 있어 업무 프로세스 자체가 바뀔 가능성이 큰 곳. 이 경우에는 프로세스가 확정된 뒤 시작하는 편이 안전합니다.

자주 묻는 질문

Q. 해외 개발팀인데 의사소통은 어떻게 하나요?
A. 발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의와 일정 관리, 검수는 PM의 책임입니다. 개발팀과의 기술 커뮤니케이션, 작업 지시, 진척 관리는 PM이 처리하므로 발주사 담당자가 영어로 개발팀을 상대할 일은 없습니다. 회의, 산출물, 보고 문서도 한국어로 제공됩니다.

Q. 기존 시스템 문서가 하나도 없는데 견적이 가능한가요?
A. 가능합니다. 현행 기능 목록, 주요 사용자 유형, 반드시 유지되어야 하는 필수 기능 3~5개, 그리고 희망하는 일정 범위만 있으면 개략 견적을 드릴 수 있습니다. 문서가 없는 상태는 레거시 전환에서 예외가 아니라 일반적인 출발점입니다. 오히려 현행 업무 규칙을 문서로 복원하는 작업 자체가 1단계에 포함되므로, 지금 문서가 없다는 사실이 프로젝트를 시작하지 못할 이유가 되지는 않습니다.

Q. 전환 중에 현재 시스템을 멈춰야 하나요?
A. 원칙적으로 병행 운영을 전제로 설계합니다. 신규 시스템을 구축하는 동안 기존 시스템은 그대로 운영되고, 전환은 기능 단위 또는 부서 단위로 단계적으로 진행하는 방식을 우선 검토합니다. 전면 전환이 필요한 경우에도 업무량이 적은 시점을 택하고, 사전에 실제 데이터로 이관 리허설을 수행하며, 문제 발생 시 기존 시스템으로 되돌리는 롤백 절차를 문서로 준비한 뒤 진행합니다.

Q. 팀 규모를 중간에 조정할 수 있나요?
A. 가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택할 수 있고 진행 중 조정도 가능합니다. 레거시 전환은 초기 분석 단계와 개발 집중 단계, 이관 및 안정화 단계에서 필요한 인력 구성이 다르기 때문에 단계별로 규모를 조정하는 편이 일반적입니다. 비용은 투입 인력 등급과 투입 기간을 기준으로 산정하며, 기획·디자인·QA·배포·유지보수를 항목별로 구분해 제시합니다.

Q. 소스코드와 데이터 소유권은 누구에게 있나요?
A. 발주사에 귀속됩니다. 소스코드와 데이터는 물론이고 API 명세, DB 스키마, 배포 절차 문서까지 인계합니다. 이후 유지보수를 다른 업체에 맡기거나 내부 인력이 직접 운영하는 선택이 모두 가능합니다. 지금 겪고 있는 문제가 반복되지 않도록 하려면 이 조건을 개발 외주 계약서에 명시해 두시는 것을 권합니다.

정리

레거시 시스템 전환의 성패는 개발 인력 단가에서 갈리지 않습니다. 사람 머릿속에만 남아 있는 현행 업무 규칙을 문서로 복원하고, 데이터 이관의 범위와 매핑과 롤백까지 책임지는 구조가 있느냐에서 갈립니다. 이 책임을 발주사 담당자가 떠안으면 단가가 아무리 낮아도 총비용은 줄지 않고, 실패하면 운영 중인 업무가 멈춥니다. 한국인 PM이 요구사항 정의와 이관을 책임지고 검증된 글로벌 개발팀이 구현을 맡는 구조는, 바로 그 책임을 발주사에서 떼어내기 위한 구조입니다. 지금 운영 중인 시스템의 상태를 기준으로 전환 범위와 일정을 함께 검토해 보고 싶으시면 견적을 요청해 주시기 바랍니다.