사내 레거시 시스템에 AI를 연결하는 현실적인 방법

"우리 시스템이 너무 오래돼서 AI는 못 붙여요"

이 말을 현장에서 가장 많이 듣습니다.

20년 된 ERP. 2000년대 초반 기술로 만든 사내 프로그램. 엑셀 매크로로 돌아가는 업무 프로세스. 10년 넘게 업그레이드가 멈춘 데이터베이스. 폐쇄망에 갇힌 온프레미스 서버.

이런 환경을 보면, AI 도입은 불가능해 보입니다. 하지만 그렇지 않습니다.

"안 되는" 게 아니라 "안 해본" 것입니다

먼저 오해를 바로잡겠습니다.

레거시 시스템에 AI를 연결하는 것은 기술적으로 거의 항상 가능합니다. "거의"라는 단서를 붙인 이유는, 물리적으로 데이터가 존재하지 않거나 법적으로 접근이 완전히 차단된 극단적 경우만 제외하면 — 방법은 있기 때문입니다.

기술적으로 되느냐 안 되느냐를 따지는 것은, 극히 특수한 경우를 제외하면 이제 중요하지 않습니다. 진짜 중요한 것은 리더가 "반드시 한다"는 의지를 갖고 있느냐입니다.

요즘의 기술 환경에서 사내 시스템 연동, 데이터 파이프라인 구축, API 래핑은 표준화된 방법론이 존재합니다. "기술적 한계"를 이유로 미루는 것은, 대부분의 경우 결정의 부재를 기술 탓으로 돌리는 것에 불과합니다.

리더가 "한다"고 결정하면, 엔지니어는 방법을 찾습니다. 리더가 "검토해보자"고 말하면, 엔지니어는 "안 되는 이유"를 찾습니다.

기술보다 어려운 것 — 기존 구조의 저항

현실적으로 이야기해야 할 부분이 있습니다.

레거시 시스템을 변경하기 어려운 이유는 기술만이 아닙니다. 그 시스템을 수년간 유지·관리해온 기존 업체와 담당자들의 저항이 존재합니다. 이들에게 시스템 변화는 곧 자신의 역할과 이익에 대한 위협입니다.

"이 시스템은 건드리면 안 됩니다", "구조가 특수해서 외부에서는 이해하기 어렵습니다", "변경하면 책임은 누가 집니까" — 이런 말들의 이면에는 기술적 판단이 아닌 이해관계의 방어가 깔려 있는 경우가 적지 않습니다.

무엇이 옳고 그른지 단정할 수는 없습니다. 오랜 기간 시스템을 안정적으로 유지해온 것도 분명한 공로입니다.

하지만 냉정하게 물어야 합니다: 이 저항이 회사의 발전 속도에 어떤 영향을 주고 있는가? 경쟁사가 AI로 업무 효율을 2배, 3배 끌어올리는 동안 우리는 "기존 시스템을 건드릴 수 없다"는 이유로 제자리에 머물러 있다면 — 그 비용은 누가 지불하게 될까요?

레거시 시스템의 진짜 문제는 내부적인 변화를 주기 어렵다는 점입니다. 선택지는 두 가지입니다:

갈아엎기 — 레거시를 폐기하고 새로운 시스템으로 DX·AI를 처음부터 설계
우회 — 기존 시스템은 그대로 두고, 외부에서 AI를 연결

갈아엎는 것은 비용과 리스크가 크지만, 장기적으로 깔끔합니다. 우회는 빠르고 안전하지만, 한 가지 현실이 있습니다: 우회조차 기존 업체의 협력이 필요한 경우가 많습니다. DB 접근 권한, 데이터 포맷 문서, 인터페이스 명세 — 이런 정보를 기존 유지보수 업체가 쥐고 있기 때문입니다.

협력을 얻기 어려운 경우, 선택지가 더 좁아집니다. 하지만 그렇다고 불가능한 것은 아닙니다. 이 글에서 제안하는 전략들은 최소한의 의존으로 연결하는 방법 — 가능한 한 기존 업체의 협조 없이도 진행할 수 있는 경로를 포함합니다.

레거시 시스템의 현실적인 유형 분류

AI 연동 전략은 레거시 시스템의 접근 가능성에 따라 달라집니다.

유형	특징	접근 난이도	대표 예시
Type A — API 존재	REST/SOAP API가 이미 있음	낮음	최신 ERP, CRM, 그룹웨어
Type B — DB 직접 접근 가능	API는 없지만 DB 쿼리 가능	중간	구형 ERP, 자체 개발 시스템
Type C — 화면만 존재	API도 DB 접근도 불가, UI만 있음	높음	레거시 웹 시스템, 터미널 기반
Type D — 파일 기반	엑셀, CSV, PDF로만 데이터 존재	중간	수기 보고서, 엑셀 매크로 업무
Type E — 폐쇄망	외부 네트워크 완전 차단	높음	공공기관, 금융, 국방

핵심은 어떤 유형이든 연결 방법이 존재한다는 점입니다. 다만 접근 방식이 다릅니다.

유형별 AI 연동 전략

Type A: API가 있는 경우 — 가장 빠른 경로

API가 이미 존재하면, AI 연동은 상대적으로 단순합니다.

구현 방식:

기존 API를 호출하여 데이터를 가져옴
AI 모델(LLM, 분류 모델 등)이 데이터를 처리
결과를 다시 API로 원래 시스템에 반영

실제 사례 패턴:

[ERP API] → 발주 데이터 조회 → [AI 에이전트] → 이상 탐지 → [Slack 알림]

주의할 점은 API 호출 제한(Rate Limit)과 인증 방식입니다. 오래된 시스템의 API는 문서화가 부실한 경우가 많아, 실제 동작을 확인하며 연동해야 합니다.

Type B: DB에 직접 접근하는 경우 — 미들웨어를 세운다

API가 없지만 데이터베이스에 접근할 수 있다면, 중간 레이어(미들웨어)를 만들어 AI와 연결합니다.

구현 방식:

Read-only DB 연결로 데이터 추출
미들웨어(API Gateway)가 데이터를 정제/변환
AI 모델이 처리 후, 결과를 별도 DB 또는 대시보드에 저장

아키텍처:

[레거시 DB] ← Read Only
      ↓
[미들웨어 API] → 데이터 정제/변환
      ↓
[AI 처리 레이어] → 분석/예측/분류
      ↓
[결과 저장소] → 대시보드, 알림, 리포트

핵심 원칙: 레거시 시스템을 건드리지 않는다.

기존 시스템에 Write하거나 구조를 변경하면, 예측 불가능한 사이드 이펙트가 발생합니다. 레거시는 읽기 전용(Read-Only)으로 접근하고, AI의 결과물은 별도 시스템에 적재하는 것이 안전합니다.

Type C: 화면만 있는 경우 — RPA + AI 하이브리드

API도 없고 DB 접근도 안 되는 최악의 상황. 하지만 화면(UI)이 있다면 방법이 있습니다.

구현 방식:

RPA(Robotic Process Automation)로 화면 데이터를 수집
수집된 데이터를 AI 파이프라인으로 전달
AI가 분석/처리 후, 다시 RPA로 결과를 입력

실제 적용 예시:

구형 웹 시스템에서 매일 실적 데이터를 자동 추출
AI가 이상치를 탐지하고 요약 리포트 생성
리포트를 이메일/메신저로 자동 발송

RPA 단독은 "로봇이 사람의 클릭을 대신하는 것"에 불과하지만, RPA + AI 조합은 "데이터를 읽고, 판단하고, 행동하는 것"까지 확장됩니다.

Type D: 파일 기반 업무 — 문서 AI의 영역

엑셀, PDF, 이미지 스캔 문서가 업무의 핵심인 경우입니다. 한국 기업에서 가장 흔한 유형이기도 합니다.

구현 방식:

파일 시스템 또는 공유 폴더를 모니터링
새 파일이 들어오면 자동으로 파싱 (OCR, 엑셀 파서, PDF 추출)
AI가 내용을 분류/요약/검증
결과를 DB에 저장하거나 후속 워크플로우 트리거

활용 사례:

견적서 자동 검증: 거래처 견적서(PDF)를 AI가 읽고, 기존 단가표와 비교하여 이상 항목 플래그
보고서 자동 요약: 주간 엑셀 보고서 50개를 AI가 읽고, 핵심 지표만 추출하여 경영진 대시보드에 표시
계약서 리스크 탐지: 스캔된 계약서를 OCR + LLM으로 분석, 불리한 조항 자동 하이라이트

Type E: 폐쇄망 환경 — 온프레미스 AI 배포

외부 네트워크가 완전히 차단된 환경에서도 AI를 운용할 수 있습니다.

구현 방식:

온프레미스 GPU 서버에 AI 모델 직접 배포
모든 데이터 처리가 내부 네트워크 안에서 완결
외부 API 호출 없이 자체 추론(inference) 수행

핵심 기술:

경량 오픈소스 LLM (외부 API 없이 자체 구동 가능한 모델)
자체 호스팅 추론 서버 및 벡터 데이터베이스

폐쇄망 AI의 핵심은 모델 선정입니다. 클라우드 기반 AI 서비스는 사용할 수 없으므로, 용도에 맞는 오픈소스 모델을 선택하고 사내 환경에 최적화하는 역량이 필요합니다.

연동할 때 반드시 지켜야 할 원칙 5가지

1. 레거시를 건드리지 마라

기존 시스템의 코드나 DB 스키마를 수정하는 순간, 사이드 이펙트의 늪에 빠집니다. 항상 외부에서 읽고, 외부에 쓴다.

2. 작은 파이프라인부터 시작하라

"전사 데이터 통합"부터 시작하면 실패합니다. 하나의 데이터 소스 → 하나의 AI 처리 → 하나의 출력으로 시작하세요.

3. 실시간이 아니어도 된다

많은 기업이 "실시간 연동"을 요구하지만, 실제로 실시간이 필요한 업무는 생각보다 적습니다. 배치(Batch) 처리로 충분한 경우가 80%입니다. 1시간 간격, 하루 1회로도 충분한 업무부터 시작하세요.

4. 에러 처리를 설계하라

레거시 시스템은 예측 불가능하게 동작합니다. 네트워크 끊김, 타임아웃, 데이터 형식 변경 — 모든 실패 시나리오에 대한 폴백(fallback)과 알림을 설계해야 합니다.

5. 사람을 루프에 포함하라

초기에는 AI 결과를 사람이 검증하는 Human-in-the-Loop 구조로 운영합니다. 신뢰가 쌓이면 점진적으로 자동화 범위를 확장합니다.

실전 아키텍처: "20년 된 ERP + AI 발주 자동화"

가상의 제조업 중견기업. 2000년대 초반 도입한 ERP를 20년간 사용 중. 매일 50건의 발주서를 수동으로 생성하고 있습니다.

AS-IS (현재)

담당자가 ERP에서 재고 확인 → 엑셀로 발주량 계산 → ERP에 수동 입력 → 상신

소요 시간: 1건당 15분 × 50건 = 일 12.5시간 (2인 전담)

TO-BE (AI 연동 후)

[ERP DB] ← Read Only (재고/발주 이력)
      ↓
[미들웨어] → 데이터 정제 + 피처 추출
      ↓
[AI 예측 모델] → 적정 발주량 산출
      ↓
[발주 제안 대시보드] → 담당자 확인 → 원클릭 ERP 반영

소요 시간: 담당자 검토 10분 + 일괄 승인 = 일 30분
절감 효과: 12시간/일 → 0.5시간/일 (96% 절감)

ERP 자체는 한 줄도 수정하지 않았습니다. Read-Only로 데이터를 읽고, AI의 결과물을 별도 대시보드에 표시하며, 최종 반영만 기존 ERP 입력 인터페이스를 통해 수행합니다.

"할 수 있느냐"가 아니라 "하겠느냐"의 문제

다시 한번 강조합니다.

레거시 시스템 환경에서 AI 연동이 기술적으로 불가능한 경우는 거의 없습니다. API가 없으면 DB에 접근하고, DB에 접근 못하면 RPA로 화면을 읽고, 화면도 없으면 파일을 파싱합니다. 폐쇄망이면 온프레미스에 모델을 올립니다.

방법은 항상 있습니다.

문제는 기술이 아니라 결정입니다. 그리고 그 결정은 현장 담당자가 아닌, 의사결정권자의 의지에서 시작됩니다.

"검토 중", "내년에 다시 논의", "우리 시스템이 특수해서" — 이런 말들이 반복되는 조직은, 기술의 한계가 아니라 결정의 부재가 진짜 병목입니다.

VANF의 접근 — 레거시를 살리면서 AI를 심는다

VANF는 시스템 구축과 플랫폼 개발을 핵심 역량으로 보유한 AX 전문 기업입니다.

레거시 환경에서 AI를 연동할 때, 우리의 접근 방식은 명확합니다:

현행 시스템을 건드리지 않습니다 — 기존 시스템 위에 레이어를 얹는 방식으로, 운영 리스크를 최소화합니다.
가장 임팩트 큰 한 곳부터 시작합니다 — 50개 업무를 동시에 하지 않습니다. ROI가 가장 명확한 한 곳에서 성과를 증명합니다.
현장에서 끝까지 붙습니다 — 아키텍처 문서만 전달하고 떠나지 않습니다. 실제로 데이터가 흐르고, AI가 결과를 내고, 담당자가 "이거 편하다"고 말할 때까지 현장에 있습니다.

레거시 시스템 때문에 AI 도입을 미루고 계신다면, VANF에 문의하세요. 현재 시스템 환경을 진단하고, 가장 현실적인 연동 방안을 함께 설계합니다.