레거시 시스템 전환 2026 — 새로 만들지 고칠지 판단 7단계

10년 넘게 돌아가는 윈도우 프로그램을 앞에 두고 발주처가 묻는 질문은 늘 같다. "이걸 고쳐서 쓸 수 있나요, 아니면 새로 만들어야 하나요?" 그리고 대부분의 견적서는 이 질문에 답하지 않고 "전면 재구축"으로 직행한다. 재작성이 업체 입장에서 계산이 쉽고 금액이 크기 때문이다.

실제로는 갈림길이 하나가 아니라 여섯 갈래다. 그리고 그 갈래를 가르는 것은 기술 스택이 아니라 소스 코드의 유무와 종류, 그리고 데이터가 어디에 어떤 형태로 쌓여 있는가다. 이 글은 WinForms·VB6·MS 액세스 기반 업무 프로그램을 기준으로, 판단에 필요한 7단계와 소스가 없을 때의 대응, 그리고 화면 캡처만 보고 재작성할 때 반드시 빠지는 것들을 다룬다.

판단을 가르는 것은 스택이 아니라 소스의 컴파일 형태다

"VB6니까 무조건 재작성"은 틀린 판단이다. 반대로 "C#이니까 그냥 올리면 된다"도 틀렸다. 실무에서 비용을 3배 이상 벌리는 변수는 원본이 어떤 형태로 컴파일되어 있느냐다. 소스가 사라진 현장은 생각보다 흔하다. 원 개발자가 퇴사하며 저장소를 남기지 않았거나, 개발사가 폐업했거나, 백업 서버가 교체되며 통째로 날아간 경우다.

이때 복구 가능성은 언어마다 극단적으로 다르다.

같은 "소스 없음"인데 .NET 실행 파일은 며칠이면 원본에 준하는 코드를 얻고, VB6 네이티브 실행 파일은 아무리 돈을 써도 못 얻는다. 견적을 받기 전에 확인해야 할 첫 번째 항목이 이것이다.

⚠️ 실행 파일 하나를 놓고 "소스 복구 가능합니다"라고 답하는 업체는 어떤 형태로 컴파일됐는지 확인하지 않았을 가능성이 높다. 파일을 열어 보지도 않고 답이 나올 수 없는 질문이다. 최소한 실행 파일을 전달하고 판정을 받은 뒤에 견적을 요청하라.

전환 판단 7단계

순서가 중요하다. 앞 단계 결과에 따라 뒤 단계의 답이 바뀌기 때문이다.

1단계 — 소스 존재가 아니라 빌드 가능 여부를 확인한다. "소스는 있습니다"라는 답의 절반은 빌드가 안 된다. 참조하는 라이브러리 버전이 없거나, 서드파티 컨트롤 라이선스가 만료됐거나, 빌드 스크립트가 특정 개발자 PC 경로에 고정돼 있다. 소스를 받은 첫날 빌드가 되는지부터 시도해야 한다.

2단계 — 실행 환경 종속성을 전부 나열한다. 32비트 COM/OCX 컴포넌트, 액티브X, 크리스탈 리포트 같은 리포팅 엔진, 장비 제조사가 준 32비트 DLL, 오피스 인터롭. 이 목록이 곧 이식 난이도다. 하나라도 64비트 대응판이 없으면 이식 경로가 막힌다.

3단계 — 전체 화면 수와 실사용 화면 수를 분리한다. 대부분의 오래된 업무 프로그램은 화면의 30~50%가 사실상 사용되지 않는다. 만들어졌다가 업무가 바뀌며 버려진 화면들이다. 실사용 화면만 세면 범위가 절반으로 줄고, 그만큼 견적도 줄어든다. 확인 방법은 간단하다. 로그가 있으면 화면별 접근 로그, 없으면 각 화면이 쓰는 테이블의 최종 갱신일을 본다.

4단계 — 데이터의 위치·규모·형태를 잰다. 액세스 파일이면 파일 크기가 2GB 한계에 얼마나 근접했는지, 테이블 수와 최대 테이블 건수는 얼마인지. SQL Server면 저장 프로시저와 트리거의 개수. 여기에 로직이 얼마나 들어 있는지가 이행 난이도를 결정한다.

5단계 — 최근 12개월 변경 요청 건수를 센다. 0건이면 고칠 이유도, 새로 만들 이유도 약하다. 반대로 월 2건 이상이면 이식으로 수명을 늘리는 선택이 손해다. 계속 손댈 시스템은 손대기 쉬운 형태로 만들어 두는 게 싸다.

6단계 — 남은 사용 수명을 정한다. 3년 뒤 ERP로 흡수될 시스템에 1억을 쓰는 결정은 그 자체로 틀렸다. 수명이 2년 미만이면 최소 수리가 정답이다.

7단계 — 판정표에 대입한다.

⚠️ 7단계를 건너뛰고 3단계 결과만으로 견적을 내면 거의 항상 과소 산정된다. 화면 수는 눈에 보이지만 종속성과 데이터는 안 보이고, 실제 공수는 뒤쪽에 몰려 있다.

소스 코드가 없을 때 — 실행 파일과 DB만 남은 시스템

소스가 없다고 해서 정보가 없는 것은 아니다. 오히려 소스보다 정확한 근거가 세 군데 남아 있다.

첫째, 데이터베이스가 가장 정직한 명세다. 테이블의 제약 조건, 인덱스, 기본값, 트리거, 저장 프로시저에는 지금 실제로 강제되고 있는 규칙이 그대로 들어 있다. 문서에는 "금액은 필수"라고 적혀 있는데 컬럼이 NULL 허용이면, 진실은 컬럼 쪽이다. 여기서 뽑은 구조를 정리하는 방식은 테이블 정의서·ERD 작성법에서 다뤘으니 반복하지 않는다.

둘째, 실데이터의 분포가 분기 조건을 드러낸다. 상태 코드 컬럼에 실제로 존재하는 값의 종류를 세어 보면 화면에 노출된 상태보다 항상 많다. 취소, 반품, 보류, 이관 같은 값이 데이터에는 있는데 화면 캡처에는 없다. 그 값들이 곧 누락된 업무 흐름이다.

셋째, 출력물이 계산식을 드러낸다. 사용자가 매달 뽑는 엑셀 파일과 인쇄 양식에는 합계·할인·세액 계산 결과가 찍혀 있다. 입력값과 결과값을 여러 건 대조하면 계산식을 역산할 수 있다.

이 세 가지를 모으는 데 보통 3~6주가 걸린다. 이 기간을 별도 단계로 계약하지 않고 개발 기간 안에 넣으면, 개발자는 추측으로 만들기 시작한다.

⚠️ 디컴파일 결과물을 그대로 납품물에 넣자고 제안하는 업체는 피하라. 원 개발사와의 계약에 역설계 금지 조항이 있는 경우가 많고, 서드파티 컨트롤은 대부분 라이선스로 명시 금지한다. 역설계는 동작 파악용 참고 자료로 쓰고, 산출물은 새로 작성한 명세와 코드여야 법적으로 안전하다.

화면 캡처만으로 재작성할 때 반드시 누락되는 것

가장 흔한 발주 방식이 "이 화면들 그대로 만들어 주세요"다. 그리고 가장 흔한 분쟁 원인이기도 하다. 화면은 결과물이지 규칙이 아니기 때문이다.

마지막 항목을 가볍게 보는 경우가 많은데, 현장 저항이 가장 큰 지점이다. 15년간 마우스 없이 숫자만 두드려 온 사용자에게 탭 순서가 바뀐 화면은 "기능은 같지만 못 쓰는 프로그램"이다.

⚠️ 화면 캡처를 넘기기 전에 권한 등급별로 각각 캡처하라. 관리자 화면만 넘기면 일반 사용자 화면은 추측으로 만들어진다. 등급이 3개면 캡처도 3벌이다.

액세스 DB와 VB6가 특별히 어려운 이유

이 둘은 "오래된 기술"이라서 어려운 게 아니다. 업무 로직이 코드가 아닌 곳에 흩어져 있어서 어렵다.

액세스는 폼, 쿼리, 매크로, VBA 모듈 네 곳에 로직이 나뉜다. 특히 쿼리에 계산과 조건이 들어 있는 경우가 많고, 이걸 SQL Server나 PostgreSQL로 옮기면 함수 이름과 널 처리 방식이 달라 결과가 미묘하게 틀어진다. 날짜도 문제다. 액세스는 1899년 12월 30일을 기준으로 하는 실수형으로 날짜를 저장하기 때문에, 단순 변환하면 이틀 어긋나는 사고가 실제로 난다.

여기에 32/64비트 드라이버 충돌이 겹친다. ACE 드라이버는 32비트와 64비트를 동시에 설치할 수 없고, 설치된 오피스의 비트 수를 따라간다. 사무실 PC마다 오피스 버전이 다르면 같은 프로그램이 어떤 자리에서는 되고 어떤 자리에서는 안 된다. 파일 용량 2GB 한계도 있다. 한계에 근접하면 압축·복구 중 파일이 깨지는 사고가 나며, 이 시점에서야 전환이 급해진다.

VB6는 별개의 문제를 낸다. IDE가 현행 윈도우에서 지원되지 않아 한 줄도 고칠 수 없다. 런타임은 여전히 돌아가므로 프로그램은 멀쩡히 실행된다. 그래서 "잘 돌아가는데 왜 바꾸냐"는 인식이 생기고, 정작 규정이 바뀌어 수정이 필요해진 순간 아무것도 못 하는 상태가 된다. 데스크톱 스택 선택 기준은 WPF 외주 개발 가이드에 정리해 뒀다.

⚠️ 액세스 파일이 여러 사람의 PC에 복사본으로 흩어져 있는지 반드시 확인하라. 공유 폴더의 파일 하나만 보고 이행했는데 실제 최신 데이터는 팀장 노트북에 있었던 사례가 드물지 않다. 이행 착수 전에 파일 전수 조사와 정본 확정이 먼저다.

유형별 비용과 기간

화면 40~60개, 테이블 30~60개 규모의 중소 업무 시스템 기준이다. 화면 수가 2배면 비용은 1.6~1.8배 정도로 늘어난다.

같은 시스템에 5,000만 원과 1억 5,000만 원 견적이 함께 오는 이유는 대부분 범위 정의의 차이지 단가 차이가 아니다. 싼 견적은 데이터 이행, 병행 운영, 인쇄 양식, 권한 체계를 빼고 계산한 경우가 많다.

⚠️ 견적서에 데이터 이행이 "포함"이라고만 적혀 있으면 반드시 되물어라. 이행 대상 테이블 수, 검증 방식, 재이행 횟수 상한이 명시돼 있지 않으면 그 항목은 사실상 견적에 없는 것이다.

발주처가 착수 전에 확정해야 할 항목

업체가 정해 줄 수 없고 발주처만 답할 수 있는 것들이다. 이게 안 정해진 채로 착수하면 개발 중간에 범위가 흔들린다.

• 실사용 화면 목록 — 전체 화면 중 실제로 쓰는 것을 표시한 목록. 애매하면 "유지"가 아니라 "폐기"로 두고 시작하는 편이 낫다
• 권한 등급과 등급별 가능 동작 — 등급 수, 등급별로 보이는 화면과 누를 수 있는 버튼
• 이행할 데이터의 시작 시점 — 전 기간인지, 최근 3년인지. 이 결정 하나로 이행 기간이 절반이 된다
• 정본 데이터 파일의 위치 — 복사본이 여러 개면 어느 것이 기준인지
• 인쇄·출력 양식 실물 — 화면이 아니라 실제 인쇄된 종이. 관공서·거래처 제출용은 규격이 고정돼 있다
• 외부 연동 대상과 담당자 — 장비, ERP, 회계, 결제. 상대측 담당자 이름까지
• 병행 운영 기간과 컷오버 날짜 — 마감일과 겹치지 않는 날짜여야 한다
• 기존 시스템 종료 조건 — 언제, 어떤 상태가 되면 옛 시스템을 끄는지
• 원 개발사 접촉 가능 여부 — 30분 통화 한 번이 2주 조사를 대신하는 경우가 있다

요구사항을 문서로 옮기는 형식과 항목은 요구사항 정의서 작성법에 정리했다. 여기서는 레거시 전환에만 해당하는 항목만 다뤘다.

⚠️ "기존과 동일하게"라는 문구를 요구사항에 쓰지 마라. 기존이 무엇인지 아무도 정확히 모르기 때문에 이 전환이 필요한 것이다. 이 문구는 검수 단계에서 100% 분쟁이 된다.

데이터 이행은 별도 프로젝트로 취급한다

레거시 전환에서 일정이 무너지는 지점은 거의 항상 데이터다. 개발은 예측이 되지만 남의 데이터는 예측이 안 된다. 15년 치 데이터에는 규칙을 벗어난 값이 반드시 들어 있다.

이행은 최소 3회 돌려야 한다. 1차는 구조 검증, 2차는 전체 데이터로 성능·오류 확인, 3차는 컷오버 리허설이다. 그리고 회차마다 아래 항목을 기계적으로 검증한다.

⚠️ 1차 이행을 개발 후반부에 잡는 일정은 거의 반드시 지연된다. 실데이터를 처음 넣는 순간 드러나는 설계 결함이 있는데, 그 시점이 오픈 2주 전이면 고칠 시간이 없다. 1차 이행은 개발 착수 후 4주 이내에 배치해야 한다.

흔한 실패 5가지

1. 화면 캡처를 명세로 착각한다. 앞에서 다룬 8가지가 통째로 빠진 채 개발이 끝나고, 인수 테스트에서 한꺼번에 터진다. 이 시점의 추가 개발은 초기 대비 3~4배 비싸다.

2. 이식으로 될 것을 재작성으로 발주한다. 소스가 있고 종속성이 깨끗한 .NET Framework 앱을 최신 .NET으로 올리는 작업은 3~6주짜리다. 이걸 4개월짜리 재작성으로 발주하면 5,000만 원 이상을 그냥 쓴다. 반대 경우도 있다. 32비트 장비 SDK에 묶인 시스템을 이식으로 발주했다가 두 달 뒤 재작성으로 되돌리는 사례다.

3. 원본을 아는 사람이 사라진 뒤 착수한다. 문서가 없는 시스템의 유일한 명세는 사람이다. 담당자 퇴사가 예정돼 있으면 전환보다 인터뷰가 먼저다. 화면별로 30분씩만 확보해도 조사 기간이 절반으로 준다.

4. 컷오버를 하루에 끝내려 한다. 병행 운영 없이 금요일 저녁에 끄고 월요일에 켜는 계획은, 문제가 생겼을 때 되돌릴 방법이 없다. 최소 2~4주는 두 시스템이 같은 데이터를 보며 함께 돌아야 한다.

5. 안 쓰는 화면까지 그대로 옮긴다. 실사용 조사를 건너뛰면 폐기해도 될 화면 20개를 만드느라 두 달과 3,000만 원을 쓴다. 그리고 그 화면들은 새 시스템에서도 안 쓰인다.

⚠️ 다섯 가지 중 넷은 개발이 아니라 착수 전 조사 단계의 실패다. 조사 비용을 아끼면 개발 비용에서 몇 배로 돌려받는다.

AI-Native 팀이 레거시 전환을 다루는 방식

레거시 전환의 공수는 개발이 아니라 조사에 몰려 있다. 실행 파일 역설계 결과, DB 스키마, 저장 프로시저, 실데이터 분포, 출력물 샘플을 전부 읽고 "이 화면이 어떤 테이블의 어떤 컬럼을 어떤 조건으로 건드리는가"를 매핑하는 일이다. 사람이 하면 화면 50개 기준 3~4주가 든다.

나무숲(TreeSoop)은 팀원 전원이 Claude Code Max 플랜을 기본 개발 환경으로 쓰고, 이 조사 단계를 코딩 에이전트에 맡긴다. 디컴파일 산출물과 스키마 덤프, 저장 프로시저 전문, 상태 코드 분포 집계를 한꺼번에 넣고 화면-테이블-규칙 매핑표 초안을 뽑은 뒤, 사람이 실데이터로 검증하는 순서다. 3~4주짜리 인벤토리가 며칠로 줄고, 남은 시간을 실사용 화면 판별과 예외 분기 확인처럼 사람이 판단해야 하는 곳에 쓴다. 이런 AI-Native 개발 방식이 특히 잘 맞는 영역이 레거시 전환이다. 근거 자료가 이미 텍스트로 존재하고, 양이 많고, 사람이 읽으면 지루하지만 놓치면 치명적인 종류의 일이기 때문이다.

⚠️ 매핑표 초안은 가설이지 결론이 아니다. 실데이터로 검증하지 않은 자동 생성 명세를 그대로 개발에 넘기면, 사람이 추측으로 만든 것과 결과가 같아진다. 검증 단계를 일정에서 빼는 순간 이 방식의 이점이 사라진다.

자주 묻는 질문

Q. 소스 코드가 없어서 디컴파일했는데, 법적으로 문제가 되나요?

원 개발사와의 계약서에 역설계 금지 조항이 있는지부터 확인해야 한다. 상용 서드파티 컨트롤은 라이선스로 명시 금지하는 경우가 대부분이다. 안전한 경로는 디컴파일 결과를 동작 파악용 참고 자료로만 쓰고, 산출물은 새로 작성한 명세와 코드로 구성하는 것이다. 복구된 코드를 그대로 납품물에 넣는 방식은 권하지 않는다.

Q. 액세스를 그냥 계속 쓰면 안 되나요?

파일 크기가 1GB 미만이고 동시 사용자가 3~4명 이하며 변경 요청이 거의 없다면 당장 바꿀 이유는 없다. 다만 2GB 한계 근접, 동시 접속 5명 이상, 원격 근무 요구, 파일 손상 이력 중 하나라도 해당되면 DB 계층 분리를 먼저 하는 편이 낫다. 화면을 그대로 두고 DB만 바꾸는 것은 6~10주, 2,500만 원 선에서 가능하다.

Q. 웹으로 바꾸는 게 나을까요, 데스크톱을 유지하는 게 나을까요?

장비 제어, 로컬 파일 대량 처리, 바코드·프린터 직결, 초당 수십 건의 키보드 입력이 있으면 데스크톱이 유리하다. 반대로 외근·다지점 접속·태블릿 사용이 필요하면 웹이다. 웹 전환은 데스크톱 재작성보다 보통 1.5~2배 비싸므로, 접속 위치 요구가 실제로 있는지부터 확인하고 결정하라.

Q. 원래 만든 개발사에 맡기는 게 안전하지 않나요?

소스를 가지고 있다면 조사 비용이 줄어 유리하다. 다만 당시 개발자가 남아 있는지, 지금도 그 기술을 다루는지를 확인해야 한다. VB6로 만든 회사가 15년 뒤에도 VB6 인력을 유지하고 있는 경우는 드물다. 소스와 문서를 넘겨받는 조건만 확보되면 다른 업체를 쓰는 것도 문제없다.

Q. 옛 시스템을 언제까지 켜 둬야 하나요?

결산 주기를 한 바퀴 돌 때까지다. 월 마감만 있는 업무면 최소 2개월, 분기 마감이 있으면 4개월, 연말정산이나 연 단위 정산이 걸리면 다음 연도 마감까지 켜 둔다. 병행 기간을 짧게 잡아 아낀 돈보다, 마감 하루 전에 옛 시스템이 필요해졌을 때 드는 비용이 훨씬 크다. 병행 중에는 입력은 새 시스템에만 받고 옛 시스템은 조회 전용으로 잠가야 두 벌 관리가 안 생긴다.

여러 업체 견적을 같은 자로 재는 방법은 제안서 평가 기준에 배점표로 정리했다.

정리

레거시 전환의 결과를 가르는 지점은 세 가지다.

첫째, 소스의 컴파일 형태를 먼저 판정한다. .NET 실행 파일과 VB6 네이티브 실행 파일은 같은 "소스 없음"이지만 선택지가 완전히 다르다. 이 판정 없이 나온 견적은 근거가 없다.

둘째, 화면이 아니라 데이터와 출력물에서 규칙을 뽑는다. 화면 캡처에는 검증 규칙, 권한 차이, 배치, 예외 분기가 안 보인다. DB 제약 조건과 실데이터 분포, 실제 인쇄물이 더 정확한 명세다.

셋째, 데이터 이행과 병행 운영을 처음부터 일정에 넣는다. 1차 이행은 착수 4주 이내, 병행 운영은 최소 2~4주. 이 두 항목이 빠진 견적은 싼 게 아니라 나중에 청구되는 것이다.