AI와 함께 20년된 레거시 프로그램을 통째로 새로 만든 후기

소개

저희 사무실 직원의 업무 중 하나로,

거래처(고객사) 담당자 정보를 관리하고, 일정 주기마다 갱신·만료를 안내해야 하는 일이 있습니다.

이 작업을 위해 20년 가까이 써온 데스크톱 프로그램이 있었는데, 원래 만든 개발자와 더 이상 쉽게 연락이 닿지 않아서 컴퓨터를 새로 설치하거나 문제가 생길 때마다 저희 직원이 매우 곤란한 상황에 처하곤 하는 걸 보면서, 제가 바이브 코딩으로 직접 만들어봐야겠다는 생각을 하였습니다.

기존 프로그램을 통째로 ai에게 던져주고 db를 로컬로 해서 똑같이 만들어보면 어떨까? 라고 생각했지만, 사실 솔직히 진짜로 가능할지는 몰랐습니다. 그런데 되더군요..

AI(Claude Code)와 함께 여러 차례 대화 세션을 거쳐, 이 레거시 프로그램을 분석 → 재설계 → 실데이터 이관 → 배포까지 전 과정을 진행했습니다.

결론부터 말하면, 기존 프로그램의 실제 데이터(거래처 약 3,000곳, 담당자 약 1만 명)를 한 건도 재입력하지 않고 그대로 옮겼고, 완성된 프로그램은 설치 과정 없이 폴더만 복사하면 바로 실행되는 독립 실행파일 형태로 만들었습니다. 추가 비용은 0원이었습니다. (기존 AI 서비스 이용료는 제외)

가장 흥미로웠던 부분은 "새 프로그램 만들기"보다 "20년 전 포맷으로 잠긴 옛날 데이터베이스를 안전하게 열어서 실제 값을 검증하는 과정"이었습니다.

배경: 왜 시작했나

문제 상황

• 기존 프로그램이 재설치되거나 서버 연결이 끊길 때마다, 원래 개발자에게 비용을 주고 도움을 받아야 했습니다.

• 별도의 데이터베이스 서버 프로그램을 함께 설치해야 하는 구조라, 컴퓨터를 바꿀 때마다 손이 많이 갔습니다.

• 담당자마다 갱신 주기가 2년·3년·4년 등으로 제각각이라, 이 부분을 정확히 반영하지 못하면 실무에서 못 쓰는 프로그램이 될 위험이 컸습니다.

• 기존 데이터베이스 안에는 수천 건의 실제 거래처·담당자 정보가 들어 있어서, 이걸 살리지 못하면 처음부터 다시 입력해야 하는 상황이었습니다.

목표

• 서버·인터넷 연결 없이 컴퓨터 한 대에서 완전히 독립적으로 동작하는 프로그램

• 재설치가 "폴더 복사" 수준으로 쉬워서, 더 이상 외부 도움이 필요 없을 것

• 갱신 주기는 자동 계산을 "제안"만 하고, 최종 값은 사람이 직접 확정·수정할 수 있을 것 (자동계산을 강제하지 않음)

• 기존 데이터베이스의 실제 데이터를 한 건도 잃지 않고 그대로 이관할 것

사용 도구

역할은 이렇게 나눴습니다.

기존 프로그램 = 분석 대상 · Claude Code = 판단과 구현 · 새 프로그램 = 최종 결과물 · UI 자동화 = 배포 전 최종 검증

진행 방법

Step 1. 기존 프로그램을 코드 없이 역분석했습니다

소스코드가 없는 상태에서 실행파일과 데이터베이스 파일만 가지고 시작했습니다. 실행파일의 헤더, 문자열, 데이터베이스 내부의 테이블·컬럼명을 직접 추출해서 "이 프로그램이 실제로 무엇을 하고 있는지"부터 재구성했습니다.

시행착오 1: 데이터베이스가 너무 오래된 버전이었습니다

최신 데이터베이스 도구로 열려고 하니 다음과 같은 오류가 났습니다.

unsupported on-disk structure for file ...
found 10.1, support 12.2

원인은 이 파일이 20년 가까이 된 초기 버전 포맷으로 저장되어 있었기 때문이었습니다. 최신 엔진은 그렇게 오래된 포맷을 아예 열 수가 없었습니다.

해결: 정확히 그 버전에 맞는 엔진을 찾아야 했습니다. 공식 배포처는 접속 자체가 막혀 있었는데, 다행히 한 오픈소스 저장소에 테스트 목적으로 올려둔 그 옛날 버전의 실행파일이 대용량 파일 저장소(Git LFS)에 남아 있어서, 이를 내려받아 문제를 해결했습니다.

시행착오 2: 32비트/64비트 불일치

옛날 버전 엔진은 32비트 전용이었는데, 최근 환경은 기본이 64비트라 다음 오류가 났습니다.

%1은(는) 올바른 Win32 응용 프로그램이 아닙니다

해결: 32비트용 보조 실행 환경을 별도로 준비해 우회했습니다. 그래도 일부 호환성 문제가 남아서, 최종적으로는 그 옛날 버전에 포함된 명령줄 조회 도구로 데이터를 안전하게 뽑아내는 방식으로 정리했습니다.

이 과정에서 실제 값 몇 건을 직접 대조해 컬럼의 의미(예: 담당자 이름, 시작일, 만료일에 해당하는 컬럼이 각각 무엇인지)를 정확히 확인했습니다. 예를 들어 "시작일 + N년 = 만료일"인 사례와, 특정 조건에서 만료일이 며칠 앞뒤로 보정되어 있는 실제 사례까지 발견해서, 기존 업무 규칙이 데이터에 그대로 남아 있는 것을 확인할 수 있었습니다.

Step 2. 요구사항을 구체화했습니다

처음에는 "서버 없이 로컬에서 동작"하는 정도로만 생각했는데, 대화를 거치며 다음 조건이 추가됐습니다.

• 갱신 주기가 2년·3년·4년 등으로 제각각이라, 자동 계산은 "제안"까지만 하고 최종 확정은 사람이 직접 수정할 수 있어야 함

• 로컬 단독의 유일한 약점인 데이터 유실을 막기 위한 자동 백업

• 문서 결과물을 인쇄물뿐 아니라 워드프로세서 파일 형식으로도 내보낼 수 있어야 함 (실무자가 직접 다시 편집해서 보낼 수 있도록)

Step 3. 새 프로그램의 뼈대를 구현했습니다

거래처 목록·검색, 담당자(갱신 주기) 관리, 갱신 임박 대상 조회, 안내 문서 생성(인쇄/PDF/워드프로세서 파일), 백업·복원 화면을 순서대로 구현했습니다.

시행착오 3: 워드프로세서 파일이 실제로 열리지 않음

문서 형식을 직접 만들어보니, 파일 자체는 만들어지는데 실제 편집기에서 열면 오류가 나거나 내용이 깨졌습니다.

해결: 그 편집기의 자동화 기능으로 표준 샘플 파일을 하나 직접 만들게 한 뒤, 그 내부 구조를 그대로 재사용하고 본문 내용만 채워 넣는 방식으로 바꿨습니다. 이후 만든 파일을 다시 그 편집기로 열어서 검증하는 절차까지 자동화했습니다.

Step 4. 기존 데이터를 실제로 이관했습니다

Step 1에서 확보한 방법으로 기존 데이터베이스 전체를 텍스트로 추출한 뒤, 새 프로그램의 데이터베이스 구조에 맞게 옮겨 담았습니다.

이 과정에서 컬럼에 저장된 숫자 코드(직위 구분 등)가 무엇을 의미하는지 문서가 전혀 없었습니다. 각 코드별 등장 빈도와, 같은 거래처 안에서 그 코드가 몇 명에게 붙는지를 통계로 확인해서 의미를 추정했고, 혹시 잘못 추정했을 경우를 대비해 원본 코드값을 비고란에 그대로 남겨 실무자가 나중에 확인할 수 있게 했습니다.

이관 후 실제 값 몇 건을 원본과 하나하나 대조해서 이름, 날짜, 주소, 등록번호가 정확히 일치하는지 확인했습니다.

Step 5. 배포용 실행파일로 묶었습니다

.NET 런타임까지 통째로 포함하는 단일 실행파일로 패키징해서, 실무자 컴퓨터에 별도 설치 없이 그대로 복사만 하면 실행되게 했습니다.

시행착오 4: 배포판에서만 데이터가 텅 비어 보임

개발 중에는 잘 되던 프로그램이, 배포용으로 묶은 버전에서는 실행할 때마다 데이터가 하나도 없는 것처럼 보였습니다. 실제 데이터베이스 파일은 멀쩡한데도 그랬습니다.

해결: 원인은 배포 옵션 하나가 실행할 때마다 임시 폴더에 내용을 다시 풀어내는 방식이었고, 프로그램이 "내 파일이 어디 있는지"를 판단할 때 그 임시 폴더를 보고 있었던 것이었습니다. 실행 중인 프로세스의 실제 경로를 직접 확인하도록 코드를 고치고, 문제의 배포 옵션도 제거해서 해결했습니다.

Step 6. 실사용 중 나온 버그 리포트에 대응했습니다

실무자가 검색창에 거래처 이름을 입력했는데 "아무 반응이 없다"는 피드백을 받았습니다.

시행착오 5: 처음엔 원인을 잘못 짚었습니다

한글은 입력 도중 여러 번 상태가 바뀌기 때문에(조합 중 문자가 계속 바뀜), 처음에는 이 타이밍 문제로 결과가 꼬이는 것이라 짐작하고 자동으로 검색이 실행되는 타이밍을 조정하는 방향으로 고쳤습니다.

그런데 실제 화면을 다시 받아보니, 검색 결과가 0건이 아니라 화면 하단에 "거래처 0곳" 이라고 나와 있었습니다. 검색 문제가 아니라 Step 5에서 고쳤어야 할 문제(데이터가 안 보이는 문제)가 재발한 것이었습니다.

해결: 사람이 실제로 타이핑하는 속도로 입력이 들어왔을 때 어떤 값으로 검색되는지, 자동화 도구로 여러 차례 정밀 재현해서 진짜 원인을 확인한 뒤 근본 원인을 수정했습니다. "그럴듯한 추측"으로 고치고 넘어가지 않고, 실제 화면 상태를 다시 확인하는 과정에서 진짜 원인을 찾을 수 있었습니다.

Step 7. 오래된 데이터의 자잘한 흠집을 정리했습니다

이관된 거래처명 중 약 4분의 1 정도가 이름 끝에 마침표가 붙어 있는 것을 실무자가 발견했습니다. 확인해보니 새 프로그램의 문제가 아니라, 기존 데이터베이스에 원래부터 그렇게 입력되어 있던 것이었습니다. 실무자와 상의해서 정식 명칭에는 필요 없는 부분이라 판단해 일괄로 정리했습니다.

Step 8. 이름을 직접 짓고, 메신저로 전달했습니다

프로그램 이름은 실무자가 직접 지었습니다. 완성된 프로그램은 폴더째로 압축해서 메신저로 바로 전달할 수 있는 크기(약 56MB)로 정리했고, 압축 안에 간단한 사용 안내문도 함께 넣었습니다.

결과와 배운 점

정량적 결과

정성적 결과

• 더 이상 특정 개발자 한 사람에게 의존하지 않아도 됩니다.

• 실무자가 프로그램 이름을 직접 지을 만큼, "내가 쓰는 프로그램"이라는 감각이 생겼습니다.

• 실제 사용 중 나온 피드백("검색이 안 돼요", "마침표가 이상해요")이 그때그때 반영되는 것을 실무자가 직접 확인했습니다.

배운 점

소스코드가 없어도 정확히 검증하며 분석할 수 있습니다. 실행파일 헤더, 문자열, 데이터베이스 내부 구조만으로도 프로그램의 동작 방식을 상당히 정확하게 재구성할 수 있었습니다. 다만 추측에서 멈추지 않고, 실제 값 몇 건을 반드시 대조 검증하는 절차가 필요했습니다.

"버그처럼 보이는 현상"의 원인은 짐작하지 말고 재현해서 확인해야 합니다. 검색 문제를 처음엔 한글 입력 타이밍 문제로 짐작했지만, 실제로는 전혀 다른 곳(배포 방식)의 문제였습니다. 그럴듯한 첫 번째 가설에 안주하지 않고 실제 화면 상태를 다시 확인한 것이 결정적이었습니다.

데이터 이관은 "옮겨졌다"가 끝이 아닙니다. 건수가 맞는다고 끝난 게 아니라, 실제 값 몇 개를 원본과 하나하나 대조해야 진짜로 옮겨졌다고 말할 수 있었습니다.

사용자의 실제 업무 규칙을 정확히 반영해야 합니다. "자동 계산이 가능은 하지만, 예외가 많아서 사람이 최종 확인해야 한다"는 실무자의 요구를 처음부터 정확히 반영하지 않았다면, 아무리 보기 좋아도 실제로는 못 쓰는 프로그램이 됐을 것입니다.

다음 계획

• 실무자가 몇 주간 직접 사용하며 나오는 피드백을 계속 반영

• 자동 백업이 실제로 문제없이 쌓이고 있는지 주기적으로 점검

• 추가 기능 요청이 있으면 그때그때 확장

전체 흐름 요약

기존 레거시 프로그램·데이터베이스 파일만 확보 ↓ 소스코드 없이 실행파일·데이터베이스 구조 역분석 ↓ 옛날 버전 전용 데이터베이스 엔진 확보 및 데이터 추출 ↓ 요구사항 구체화 (로컬 단독 · 수동 확정 가능한 자동계산 · 자동 백업) ↓ 새 프로그램 뼈대 구현 (조회 · 관리 · 안내문 생성) ↓ 기존 데이터 실이관 + 원본 대조 검증 ↓ 단일 실행파일 배포판 제작 ↓ 배포 후 실사용 피드백 재현·수정 (반복) ↓ 이름 직접 짓기 + 압축 파일로 전달

총 소요 기간: 여러 차례의 대화 세션에 걸쳐 진행 (하루 만에 끝나는 작업은 아니었습니다) 총 추가 비용: 0원 (기존 AI 서비스 이용료 제외)

도움 받은 것들

• 오픈소스로 공개된 옛 버전 데이터베이스 엔진 저장소 (Git LFS)

• 각 기술 요소(웹 프레임워크, 데이터베이스, 문서 포맷)의 공식 문서

레거시 프로그램을 통째로 새로 만드는 일은 "요즘 기술로 예쁘게 다시 만들기"보다, 20년 치 실제 데이터와 업무 습관을 있는 그대로 존중하면서 옮기는 일에 가까웠습니다. 데이터베이스 구조를 역추적하고, 옛날 코드 하나하나의 의미를 통계로 추정하고, 실사용 중 나온 사소한 피드백까지 그때그때 반영하는 과정에서, 단순히 "기능이 되는 프로그램"이 아니라 "그 사무소만의 프로그램"이 만들어진다는 느낌을 받았습니다.

비개발자 입장에서 AI와 함께 레거시 시스템을 교체해보신 분들의 경험담도 궁금합니다. 피드백 환영합니다!