COBOL부터 GPT까지: 레거시 시스템과 LLM을 연결하는 3단계 아키텍처 패턴 가이드

"우리 회사 핵심 비즈니스 로직은 COBOL로 짜여진 메인프레임에 있습니다. 그런데 최신 LLM을 도입해서 고객 문의를 자동화하고 싶은데, 이 두 세계를 어떻게 연결해야 할까요?"

이 질문을 던지신 분이라면, 당신은 이미 기업의 가장 가치 있는 자산(핵심 비즈니스 로직)과 가장 뜨거운 기술 트렌드(생성형 AI)의 교차점에 서 계신 것입니다.

하지만 현실은 녹록지 않습니다. 메인프레임의 복잡한 트랜잭션 코드, 수십 년간 쌓인 XML 기반의 데이터 포맷, 그리고 최신 LLM이 요구하는 깔끔한 JSON API 호출 방식 사이에는 거대한 '시간의 벽'이 존재합니다. 이 간극을 메우는 것이 바로 엔터프라이즈 AI 아키텍처의 핵심 과제입니다.

이 글은 추상적인 개념 나열이 아닙니다. 수많은 IT 아키텍트들이 겪는 '레거시-LLM 연결'의 난제를 해결하기 위해, **실제 적용 가능한 3단계 아키텍처 패턴(Blueprint)**을 제시합니다. 이 로드맵만 이해하신다면, 기술 부채를 두려워할 필요 없이 AI 혁신을 가속화할 수 있습니다.

🧱 1단계: 데이터 추출 및 표준화 (The Extraction Layer)

가장 먼저 해결해야 할 문제는 '데이터의 형태'입니다. LLM은 텍스트를 가장 잘 이해하지만, 레거시 시스템의 데이터는 그저 '바이트 스트림'이나 '특정 필드 순서'로 존재합니다.

레거시 데이터의 딜레마: 구조화, 비정형, 반구조화

레거시 데이터는 다음과 같은 형태로 존재합니다.

• 구조화 (Structured): DB 테이블 (하지만 접근 방식이 복잡함).
• 반구조화 (Semi-structured): XML, JSON (하지만 스키마가 매우 복잡하거나 비일관적임).
• 비정형 (Unstructured): 과거 트랜잭션 로그 파일, 스캔된 문서 (OCR 필요).

이 데이터를 LLM이 이해할 수 있는 **'표준화된 스키마(Standardized Schema)'**로 변환하는 과정이 1단계의 목표입니다.

💡 해결 패턴: API Gateway와 변환 계층(Transformation Layer)

이 단계의 핵심은 **'직접 접근 금지'**입니다. 레거시 시스템의 코어 로직에 LLM을 직접 연결하는 것은 시스템 안정성을 심각하게 위협합니다. 대신, 우리는 안전한 '관문(Gateway)'을 세워야 합니다.

1. API Gateway 역할: 외부 요청을 받아들이고, 이 요청이 레거시 시스템이 이해할 수 있는 형식(예: 특정 레거시 API 호출 규약)으로 변환하는 역할을 합니다.
2. Transformation Layer: 이 계층은 가장 지능적인 '번역가' 역할을 합니다. 예를 들어, COBOL에서 넘어온 CUST_ID 필드와 XML에서 넘어온 <CustomerID> 필드를 모두 받아, 내부적으로 통일된 customer_uuid라는 JSON 스키마로 매핑하는 로직이 여기에 구현됩니다.

graph LR
    A[외부 요청 (LLM/UI)] --> B(API Gateway);
    B --> C{Transformation Layer};
    C --> D[레거시 시스템 (COBOL/DB)];
    D --> C;
    C --> E[표준화된 JSON 응답];

핵심 기술 스택 제안: API Gateway (Kong, Apigee), Message Queue (Kafka, RabbitMQ)를 사용하여 비동기적 데이터 처리를 보장해야 합니다.

⚙️ 2단계: 지능형 중개자 구축 (The Orchestration Layer)

데이터를 추출하고 표준화했다면, 이제 '요청의 흐름'을 제어해야 합니다. LLM은 '무엇을 할지'에 대한 추론 능력은 뛰어나지만, '실제로 어떻게 실행할지'에 대한 실행 권한은 없습니다.

이 간극을 메우는 것이 바로 **오케스트레이션 레이어(Orchestration Layer)**입니다. 이 레이어는 LLM과 레거시 시스템 사이의 '지휘자(Conductor)' 역할을 수행합니다.

🔍 Function Calling의 레거시 버전 적용

최신 LLM은 Function Calling 기능을 통해 외부 API를 호출할 수 있습니다. 우리는 이 개념을 레거시 환경에 맞게 재해석해야 합니다.

오케스트레이션 레이어는 LLM의 답변을 받으면, "사용자가 A라는 질문을 했으니, 1단계에서 표준화한 get_customer_status(customer_uuid) 함수를 호출해야겠다"라고 판단하고, 이 함수를 실행하는 코드를 실행합니다.

⚠️ 경고: 직접 연결(Bad) vs. 오케스트레이션 경유(Good)

핵심 기술 스택 제안: LLM 프레임워크 (LangChain, LlamaIndex), Workflow Engine (Temporal, Apache Airflow)를 사용하여 복잡한 비즈니스 로직의 순서와 예외 처리를 코드로 정의해야 합니다.

🧠 3단계: LLM의 활용 극대화 (The Intelligence Layer)

데이터가 표준화되고, 시스템 호출 흐름이 제어되었다면, 이제 LLM의 진가를 발휘할 차례입니다. 단순히 "고객 번호가 뭐야?"라는 질문에 답하는 것을 넘어, **'왜?'**와 **'그래서 어떻게 해야 하나?'**에 답해야 합니다.

이 단계의 핵심은 RAG (Retrieval-Augmented Generation) 패턴을 레거시 지식 베이스에 적용하는 것입니다.

📚 레거시 매뉴얼 기반 답변 생성 시나리오

만약 고객이 "지난달에 발생한 이 비정상 트랜잭션 로그(XML 첨부)가 의미하는 비즈니스 로직이 뭔가요?"라고 물었다고 가정해 봅시다.

1. 검색 (Retrieval): 시스템은 첨부된 로그를 분석하고, 내부적으로 저장된 수백 페이지의 **운영 매뉴얼(PDF, Wiki)**에서 관련 키워드와 패턴을 검색합니다.
2. 증강 (Augmentation): 검색된 매뉴얼의 조항(Context)을 가져와서, 사용자의 질문과 함께 프롬프트에 첨부합니다.
3. 생성 (Generation): LLM은 이 **[질문 + 매뉴얼 조항]**을 기반으로, "이 로그는 매뉴얼 3.2.1에 따라 처리되어야 하며, 담당 부서에 이의 제기가 필요합니다."와 같이 근거 기반의 답변을 생성합니다.

이 과정은 LLM이 **환각(Hallucination)**을 일으키는 것을 막고, **'근거가 있는 답변'**을 제공하는 핵심 메커니즘입니다.

🚀 종합 요약: 3단계 데이터 흐름도

이 세 단계를 유기적으로 연결하는 것이 바로 **'AI 에이전트(Agent)'**의 역할이며, 이것이 레거시 시스템에 AI를 성공적으로 접목하는 핵심 열쇠입니다.