한줄 요약
원본 시스템을 건드리지 않고 데이터를 꺼내 쌓는 것, 그게 레거시 현대화의 시작이다.
레거시 시스템 현대화는 오래된 소프트웨어를 통째로 갈아엎는 일이 아니다. 기존 시스템은 그대로 두고, 거기서 필요한 데이터를 꺼내 새로운 계층에 쌓는 것부터 시작한다. 외주 개발 프로젝트에서 이 방식은 생각보다 훨씬 자주 쓰인다.
왜 원본 시스템을 바꾸지 않는가
현장에서 수십 년간 돌아온 시스템에는 손대기 어려운 이유가 있다. 담당자가 바뀌었거나, 소스 코드가 없거나, 중단되면 업무 자체가 멈춘다. 이런 상황에서 "전면 교체"는 대부분 현실적이지 않다.
그래서 실무에서 자주 선택하는 방법이 읽기 계층 분리다. 원본 시스템은 여전히 데이터를 생성하는 원천으로 유지한다. 개발사가 만드는 것은 그 데이터를 가져와 별도 데이터베이스에 적재하고, 새로운 UI와 API로 노출하는 두 번째 계층이다. 원본 시스템의 운영 데이터는 수정하지 않는다. 읽기만 한다.
이 구조는 리스크를 대폭 줄인다. 원본이 느리거나 불안정해도 새 서비스는 자체 데이터베이스에서 응답하기 때문이다.
브라우저 자동화로 데이터를 꺼내는 현실
API가 없는 시스템에서 데이터를 가져오는 방법은 제한적이다. DB 직접 접근이 불가능하다면, 브라우저 자동화가 현실적인 선택지가 된다. 로그인부터 메뉴 탐색, 화면 파싱까지 자동으로 수행하는 크롤러를 만드는 방식이다.
이 과정에서 성능은 처음부터 신경 써야 한다. 실제로 초기 구현은 기능이 돌아가더라도 속도가 수십 초에 달하는 경우가 많다. 주요 원인은 세 가지다.
- 불필요한 인증 반복: 세션이 살아있는데도 매번 로그인을 다시 수행하는 구조
- 비효율적인 DOM 접근: 수백 개 요소를 개별 호출로 읽는 방식
- 캐시 없는 반복 조회: 변하지 않는 과거 데이터를 매번 원본에서 다시 가져오는 구조
세션을 유지하고, 배치 평가로 DOM을 한 번에 읽고, 갱신 주기를 관리하는 백그라운드 캐시를 두면 응답 속도는 수 초 이내로 줄어든다.
과거 데이터와 현재 데이터를 다르게 다뤄야 한다
데이터 적재 전략에서 흔히 놓치는 부분이 있다. 과거 데이터와 현재 데이터를 동일하게 다루는 것이다.
3년 전 특정 월의 매출 수치는 더 이상 바뀌지 않는다. 그런데 조회할 때마다 원본 시스템에 다시 접속해 긁어온다면, 불필요한 부하와 응답 지연이 반복된다. 이미 확정된 과거 데이터는 한 번 가져오면 데이터베이스에 저장하고 이후엔 DB에서 직접 읽는 것이 맞다.
반면 현재 진행 중인 기간의 데이터는 주기적으로 원본을 다시 조회해 갱신해야 한다. 이 둘을 구분하는 것만으로 시스템의 성격이 달라진다. 단순한 화면 대행 도구가 아니라, 데이터를 자체적으로 보유하고 관리하는 독립적인 서비스가 된다.
UI는 데이터를 배열하는 방식이다
데이터를 쌓고 나면 화면을 어떻게 구성하느냐가 다음 과제다. 기존 시스템의 메뉴와 표를 그대로 옮기는 방식은 대부분 실패한다. 원래 화면은 당시 업무 흐름에 맞게 설계된 것이고, 지금 사용자가 필요한 맥락과 다를 수 있다.
더 나은 접근은 사용자의 질문 순서를 먼저 정의하는 것이다.
- 지금 상황이 어떤가
- 지난 기간과 비교해 달라진 것은 무엇인가
- 어떤 요소가 그 변화를 만들었는가
- 앞으로 어떤 판단을 해야 하는가
이 흐름대로 정보 위계를 설계하면, 같은 데이터라도 사용자가 이해하는 속도가 달라진다. 숫자를 많이 보여주는 화면이 아니라, 판단에 필요한 것부터 보여주는 화면이 목표다.
AI를 붙이기 전에 데이터 구조가 먼저다
요즘 많은 클라이언트가 AI 기능을 요청한다. 자연어로 질문하면 데이터를 분석해주는 기능, 이상 징후를 자동으로 감지하는 기능 등이다. 그런데 이 기능들이 제대로 작동하려면 전제 조건이 있다.
데이터가 정제되어 있어야 하고, 조직의 맥락이 구조화되어 있어야 한다.
LLM에 원시 데이터를 넣고 "인사이트를 알려줘"라고 하면 그럴듯한 답변은 나온다. 하지만 왜 특정 시기에 특정 항목이 변했는지, 어떤 외부 사건이 연관되어 있는지, 이 조직에서 의사결정이 어떻게 이뤄지는지는 데이터만으로 알 수 없다. 그 맥락은 개체와 관계, 이벤트, 규칙, 예외 케이스를 정의하는 과정에서 만들어진다.
