레거시 시스템을 건드리지 않고 데이터를 살리는 법
목차(6)
한줄 요약
원본 시스템을 건드리지 않고 데이터를 꺼내 쌓는 것, 그게 레거시 현대화의 시작이다.
레거시 시스템 현대화는 오래된 소프트웨어를 통째로 갈아엎는 일이 아니다. 기존 시스템은 그대로 두고, 거기서 필요한 데이터를 꺼내 새로운 계층에 쌓는 것부터 시작한다. 외주 개발 프로젝트에서 이 방식은 생각보다 훨씬 자주 쓰인다.
왜 원본 시스템을 바꾸지 않는가
현장에서 수십 년간 돌아온 시스템에는 손대기 어려운 이유가 있다. 담당자가 바뀌었거나, 소스 코드가 없거나, 중단되면 업무 자체가 멈춘다. 이런 상황에서 "전면 교체"는 대부분 현실적이지 않다.
그래서 실무에서 자주 선택하는 방법이 읽기 계층 분리다. 원본 시스템은 여전히 데이터를 생성하는 원천으로 유지한다. 개발사가 만드는 것은 그 데이터를 가져와 별도 데이터베이스에 적재하고, 새로운 UI와 API로 노출하는 두 번째 계층이다. 원본 시스템의 운영 데이터는 수정하지 않는다. 읽기만 한다.
이 구조는 리스크를 대폭 줄인다. 원본이 느리거나 불안정해도 새 서비스는 자체 데이터베이스에서 응답하기 때문이다.
브라우저 자동화로 데이터를 꺼내는 현실
API가 없는 시스템에서 데이터를 가져오는 방법은 제한적이다. DB 직접 접근이 불가능하다면, 브라우저 자동화가 현실적인 선택지가 된다. 로그인부터 메뉴 탐색, 화면 파싱까지 자동으로 수행하는 크롤러를 만드는 방식이다.
이 과정에서 성능은 처음부터 신경 써야 한다. 실제로 초기 구현은 기능이 돌아가더라도 속도가 수십 초에 달하는 경우가 많다. 주요 원인은 세 가지다.
- 불필요한 인증 반복: 세션이 살아있는데도 매번 로그인을 다시 수행하는 구조
- 비효율적인 DOM 접근: 수백 개 요소를 개별 호출로 읽는 방식
- 캐시 없는 반복 조회: 변하지 않는 과거 데이터를 매번 원본에서 다시 가져오는 구조
세션을 유지하고, 배치 평가로 DOM을 한 번에 읽고, 갱신 주기를 관리하는 백그라운드 캐시를 두면 응답 속도는 수 초 이내로 줄어든다.
과거 데이터와 현재 데이터를 다르게 다뤄야 한다
데이터 적재 전략에서 흔히 놓치는 부분이 있다. 과거 데이터와 현재 데이터를 동일하게 다루는 것이다.
3년 전 특정 월의 매출 수치는 더 이상 바뀌지 않는다. 그런데 조회할 때마다 원본 시스템에 다시 접속해 긁어온다면, 불필요한 부하와 응답 지연이 반복된다. 이미 확정된 과거 데이터는 한 번 가져오면 데이터베이스에 저장하고 이후엔 DB에서 직접 읽는 것이 맞다.
반면 현재 진행 중인 기간의 데이터는 주기적으로 원본을 다시 조회해 갱신해야 한다. 이 둘을 구분하는 것만으로 시스템의 성격이 달라진다. 단순한 화면 대행 도구가 아니라, 데이터를 자체적으로 보유하고 관리하는 독립적인 서비스가 된다.
UI는 데이터를 배열하는 방식이다
데이터를 쌓고 나면 화면을 어떻게 구성하느냐가 다음 과제다. 기존 시스템의 메뉴와 표를 그대로 옮기는 방식은 대부분 실패한다. 원래 화면은 당시 업무 흐름에 맞게 설계된 것이고, 지금 사용자가 필요한 맥락과 다를 수 있다.
더 나은 접근은 사용자의 질문 순서를 먼저 정의하는 것이다.
- 지금 상황이 어떤가
- 지난 기간과 비교해 달라진 것은 무엇인가
- 어떤 요소가 그 변화를 만들었는가
- 앞으로 어떤 판단을 해야 하는가
이 흐름대로 정보 위계를 설계하면, 같은 데이터라도 사용자가 이해하는 속도가 달라진다. 숫자를 많이 보여주는 화면이 아니라, 판단에 필요한 것부터 보여주는 화면이 목표다.
AI를 붙이기 전에 데이터 구조가 먼저다
요즘 많은 클라이언트가 AI 기능을 요청한다. 자연어로 질문하면 데이터를 분석해주는 기능, 이상 징후를 자동으로 감지하는 기능 등이다. 그런데 이 기능들이 제대로 작동하려면 전제 조건이 있다.
데이터가 정제되어 있어야 하고, 조직의 맥락이 구조화되어 있어야 한다.
LLM에 원시 데이터를 넣고 "인사이트를 알려줘"라고 하면 그럴듯한 답변은 나온다. 하지만 왜 특정 시기에 특정 항목이 변했는지, 어떤 외부 사건이 연관되어 있는지, 이 조직에서 의사결정이 어떻게 이뤄지는지는 데이터만으로 알 수 없다. 그 맥락은 개체와 관계, 이벤트, 규칙, 예외 케이스를 정의하는 과정에서 만들어진다.
AI는 이 구조 위에서 작동할 때 실제로 유용하다. 도구부터 붙이는 게 아니라, 현장의 구조를 먼저 담는 것이 순서다.
자주 묻는 질문
Q.API가 없는 오래된 시스템에서도 데이터를 가져올 수 있나요?
가능하다. 브라우저 자동화 기반의 크롤링이 현실적인 방법이다. 다만 원본 시스템의 화면 구조에 의존하기 때문에, 화면이 바뀌면 크롤러도 수정이 필요하다. 장기적으로는 원본 시스템의 DB에 직접 접근하거나 공식 API를 요청하는 방향이 더 안정적이다. 외주 개발사와 협의할 때 유지보수 범위를 명확히 해두는 것이 중요하다.
Q.레거시 현대화 프로젝트는 비용이 얼마나 드나요?
범위에 따라 크게 다르다. 데이터 수집 자동화와 DB 적재만 구현하는 경우와, 새로운 UI와 분석 기능까지 포함하는 경우는 공수 차이가 수 배에 달한다. 전면 시스템 교체 없이 읽기 계층만 분리하는 방식은 리스크와 비용을 낮추면서 실질적인 개선을 이끌 수 있다. 정확한 견적은 현재 시스템 구조와 원하는 결과물을 확인한 후 산정된다.
Q.데이터를 쌓고 나서 AI 분석 기능을 추가하려면 어떤 준비가 필요한가요?
데이터 정제와 구조 정의가 먼저다. 컬럼 이름과 단위가 일관되게 정리되어 있어야 하고, 업무 맥락을 반영한 분류 체계가 있어야 한다. 어떤 이벤트가 어떤 데이터 변화와 연결되는지 정의해두면 AI가 더 정확하게 작동한다. 데이터를 단순히 많이 쌓는 것보다, 조직의 판단 흐름을 담은 구조로 쌓는 것이 핵심이다.
관련 아티클
관련 사례
이 글의 키워드와 맞닿은 실제 개발 사례를 함께 보세요.
프랜차이즈 교육 ERP/LMS 플랫폼 — 레거시 ASP 전면 현대화
20년 된 ASP 레거시 시스템을 Next.js/Node.js 기반으로 전면 재구축한 프랜차이즈 교육 ERP/LMS 플랫폼. 수천만 건 DB 이관, 교사·학부모 전용 앱 분리 구축
유전자 분석 결과 조회 및 디지털 리포트 플랫폼
QR코드 기반 건강검진 접수부터 유전자 분석 결과 시각화, 고해상도 PDF 리포트 자동 생성까지 의료 데이터 전 과정을 디지털화한 플랫폼
합성 데이터 거래 AI 플랫폼 UX 기획·설계
민감 데이터를 비식별 합성 데이터로 변환·거래하는 AI 플랫폼의 서비스 기획 및 UX/UI 설계