EAI(Enterprise Application Integration) 간단하게 알아보기

EAI 에 대해서 너무 모르는 것 같아 개념 같은 것을 알아보고자 합니다

GPT를 통해 검색하면서 내용을 정리해보았고, 먼가 개념은 알지만 실제로 실무에 활용할 때는 전문가가 아니고 회사 시스템마다 상황이 디테일한 상황은 다르다보니 헤맬 것 같긴 하지만 어느정도 개념은 알게 되었습니다

1️⃣ EAI란 무엇인가? — API 연동과 뭐가 다를까?

개발자 입장에서 통합(Integration)이라고 하면 흔히 떠오르는 게 REST API, Webhook, 혹은 gRPC 같은 방식이죠. 하지만 대기업이나 공공 시스템처럼 수십~수백 개의 시스템이 존재하는 환경에서는 이 방식만으로는 감당이 안 됩니다.

EAI(Enterprise Application Integration)는 기업 내 여러 시스템 간의 데이터 및 프로세스를 통합하는 아키텍처입니다.

단순히 API를 호출하는 게 아니라, 시스템 간의 이질적인 데이터 포맷, 전송 방식, 운영 시간, 트랜잭션 처리 방식 등을 통합하는 미들웨어 허브 역할을 합니다.

항목	API Integration	EAI Integration
통신 방식	REST/HTTP 등 요청-응답	비동기 메시지 기반 + 어댑터
통합 구조	1:1 연결 (Point-to-Point)	허브-스포크 구조 또는 메시지 버스(Message Bus) 기반
메시지 처리	단순 JSON 또는 Payload 전달	메시지 포맷 매핑 및 트랜스포메이션(변환) 수행
장애 내성	시스템 다운 시 요청 실패	메시지 큐 기반으로 비동기 처리 및 재처리(Replay) 가능
주 용도	외부 연동 또는 단일 기능 호출	ERP, CRM, 레거시 등 기업 내부 시스템 간 연동/통합

 

 

[System A] → Adapter A → Transformation → Routing → Adapter B → [System B]

예를 들어, SAP에서 생성된 출고 데이터를 CRM 시스템으로 보내려면:

1. SAP에서 Adapter A를 통해 데이터를 추출
2. Transformation에서 포맷 변환 및 필드 매핑
3. Routing 룰에 따라 CRM 시스템으로 전달 결정
4. Adapter B를 통해 CRM의 API에 맞는 형식으로 호출

 

🏗️ EAI 아키텍처 스타일

1. Hub-and-Spoke

• 중앙 허브가 모든 메시지를 받아 처리 후 각 시스템으로 전달
• 단순하고 관리 용이, 허브 장애 시 전체 영향 있음

2. Message Bus (ESB, Enterprise Service Bus)

• 모든 시스템이 공통 메시지 버스를 통해 통신
• 확장성 높음, 비동기 처리와 이벤트 기반 아키텍처 가능

EAI를 구성할 때는 이 네 가지 요소(Adapter, Transformation, Routing, Messaging)을 기반으로 전체 흐름을 설계해야 하며, 기업 규모가 크고 시스템이 다양할수록 ESB 기반의 메시지 중심 설계가 많이 활용됩니다.

 

 

2️⃣ 대기업에서 개발자가 겪는 통합 문제

실제 기업에서는 다음과 같은 상황이 많습니다:

• 고객 정보는 CRM, 결제 내역은 ERP, 마케팅 이력은 DMP에 따로 저장
• 레거시 시스템은 FTP로 파일 주고받고, 최신 시스템은 REST API만 지원
• 시스템마다 포맷이 달라 JSON, XML, CSV, Proprietary Format 뒤섞임
• 업무 프로세스는 한 번에 끝나지 않고 여러 시스템을 거쳐야 최종 결과 생성

🙋‍♂️ API 하나 만들면 되지 않나요?

단일 API 호출로 끝나지 않는 문제가 대부분입니다.

예를 들어, "고객 주문이 들어오면 → CRM에 등록 → ERP에 전달 → 배송시스템에 생성 → 결제시스템에 통보"와 같은 다단계 워크플로우가 필요하죠.

 

3️⃣ EAI는 어떤 구조로 동작하는가? (Hub & Spoke vs Message Bus)

🎯 핵심 개념: EAI는 중앙 통합 허브

EAI는 모든 시스템 간 연결을 1:1로 만들지 않고, 중앙 미들웨어 허브를 통해 오가는 구조입니다. 대표적인 구조는 두 가지입니다.

💡 ① Hub-and-Spoke 모델

• 중앙 허브가 모든 시스템과 어댑터로 연결됨
• 포맷 변환, 라우팅, 로깅, 트랜잭션 처리 등을 허브에서 통제
• 중소형 조직 또는 연결 수가 복잡하지 않은 경우 적합

💡 ② Message Bus (ESB, Enterprise Service Bus)

• 메시지를 중앙 메시지 버스를 통해 분산 처리
• 여러 시스템 간 이벤트 기반 메시지 교환 가능
• 마이크로서비스나 대규모 확장형 조직에 적합

 

4️⃣ 개발자가 EAI에 어떻게 참여하는가?

기업 환경에서 EAI는 단순한 메시지 전달기를 넘어, 비즈니스 프로세스 중심의 오케스트레이션, 이기종 시스템 간 호환 처리, 그리고 운영 안정성 확보까지 포괄하는 복합 통합 플랫폼입니다. 개발자는 다음과 같은 핵심 구성요소별 역할에서 깊게 관여하게 됩니다.

 

🛠 어댑터(Adapter) 개발 – 시스템별 인터페이스 작성

어댑터란, 각 시스템의 프로토콜과 포맷을 EAI 플랫폼이 이해할 수 있도록 중간 계층을 담당하는 구성 요소입니다. 다음을 수행하게 됩니다:

어댑터	역할 구성 성명
Transport Adapter	FTP, SFTP, MQ, SOAP, JDBC 등 물리적 전송 방식 연동
Application Adapter	SAP, Oracle EBS, Salesforce 등 패키지 시스템 전용 어댑터
Custom Adapter	자체 개발 시스템(DB, API 등)을 위한 사용자 정의 모듈

 

예시: ERP에서 매일 생성되는 송장 데이터를 Oracle DB에 저장 → MQ를 통해 EAI에 전달 → CRM 시스템으로 전송

⛏ 개발자는 이때 MQ Producer, JDBC Adapter, CSV 파서 등을 개발하거나 설정

 

🧾 메시지 포맷 매핑 (Message Transformation & Mapping)

EAI에서는 단순 전달이 아닌 데이터 포맷과 필드 간 매핑이 필수입니다.
이를 위해 보통 다음 도구나 방식이 활용됩니다:

구성 요소	역할
Mapping Rule	Field1 → Field2, date_format 변경, null → default 처리 등
Transformation Engine	XSLT(XML 변환), DataWeave(Mule), ESQL(IBM) 등
Canonical Data Model	중간 통합 스키마를 정의하여 N:N → 1:N 매핑 처리

 

EAI는 어떤 언어로 구성되어 있을까? (개발자 입장에서 보는 EAI의 언어 생태계)

EAI 솔루션은 대부분 기업용 미들웨어이기 때문에 다음과 같은 언어 기반으로 개발되거나 연동 어댑터가 구성되어 있습니다:

 

플랫폼	주요 언어	비고
WebMethods	Java 기반	어댑터, 맵핑 툴도 Java 환경
Tibco	자체 스크립팅(도식적), Java 사용 가능	내부는 Java 기반
BizTalk	.NET / C#	Visual Studio와 강하게 통합
IBM App Connect	Java, ESQL	통합 흐름 설계 UI 존재
MuleSoft	Java (Spring 기반) + DataWeave DSL	개발자 친화적
WSO2	Java 기반 + Ballerina 언어	경량 오픈소스 EAI
Apache Camel	Java or Kotlin + XML/DSL	코드 기반 메시지 라우팅

🔧 공통점: 대부분 Java 기반이며, 어댑터/플러그인 형태로 확장 가능

 

✅ 서로 다른 언어인데 어떻게 연결이 되는가?

EAI 시스템이 Java로 구성되어 있어도, 다음과 같은 공통 인터페이스를 통해 Python 기반 FastAPI와 연결됩니다:

통신 방식	설명	Python 연결 방식	Java (EAI 측) 처리 방식
REST API	HTTP 기반 요청/응답	httpx, requests	Spring Controller, JAX-RS, Servlet
Message Queue (MQ)	비동기 메시지 교환	pymqi, aio-pika 등	JMS, ActiveMQ, Kafka, RabbitMQ
파일 (CSV/XML)	디렉토리에 파일 저장 후 읽기	pandas, xml.etree, openpyxl	Java File I/O, FTP 서버 접근
DB 공유	DB 테이블을 통해 메시지 전달	sqlalchemy, psycopg2	JDBC로 동일 DB 조회
SOAP	XML 기반 RPC 호출	zeep, suds	JAX-WS, Axis2 등 SOAP 엔진
iPaaS	API Gateway or 중계 플랫폼 통해 연결	httpx, requests	Boomi, Mulesoft 등의 연결 노드 사용

 

📌 핵심 요약

• Java 기반 EAI와 Python 기반 FastAPI는 직접 코드로 호출하지 않고, HTTP/MQ/DB/파일 같은 표준 통신 경로를 통해 연결
• 이는 언어 독립적인 구조이며, 현실에서 가장 흔한 이기종 시스템 연동 방식
• 연결 방식은 기업의 인프라 보안, 응답 요구 속도, 신뢰성 요구에 따라 결정됨

EAI를 통해 TOOL로 접근 한다면 (가안) - AI가 생성함

핵심 요약: “FastAPI는 요청을 만들고, EAI는 연결해준다.”

🎯 이해를 돕는 3줄 요약

구성 요소	하는 일	비유
FastAPI (Python)	LLM의 명령을 받아서 "요청서"를 작성함	비서가 요청서 작성
EAI (Java, 미들웨어)	요청서를 받아 해당 시스템에 "업무 처리" 요청	인사팀/총무팀에 전달하는 경유 창구
레거시 시스템 (ERP, 언더라이팅 등)	진짜 일을 하는 시스템	실제 창고/계산서/보험 심사 부서

🔗 실제 연동 흐름 예시

LLM → FastAPI → EAI → ERP (또는 심사 시스템 등)

 

예시 시나리오

사용자가 "A 고객의 계약을 심사해줘"라고 명령

1. LLM이 "심사 툴"을 사용하라고 판단함
2. FastAPI는 EAI에 POST 요청 보냄: POST /eai/uw
3. EAI는 기존에 설정된 흐름대로 내부 심사 시스템을 호출
4. 심사 시스템이 결과를 응답 → EAI → FastAPI → LLM에게 전달

🛠️ 그럼 개발자가 뭘 해야 하냐?

📌 FastAPI 개발자는:

• EAI가 받아들일 수 있는 요청 포맷을 맞춰서 전달
• 인증 처리 / 실패 시 로깅
• 결과 받아서 LLM이 이해할 수 있는 형태로 변환

@app.post("/call-uw/")
async def call_underwriting(data: dict):
    transformed = transform_to_eai_format(data)
    resp = await httpx.post(EAI_ENDPOINT, json=transformed)
    return transform_to_llm_format(resp.json())

 

📌 EAI 쪽은 이미 구성되어 있다면:

• FastAPI가 호출할 수 있도록 인터페이스/API를 열어줌
• 어떤 데이터를 받아서 → 어떤 시스템에 → 어떻게 호출할지 연동 흐름(BPM) 구성되어 있어야 함

🧱 핵심 실무 고려사항 (현실 버전)

항목	고려할 것
EAI가 API 지원 안 함	MQ, 파일 업로드 방식으로 요청해야 할 수 있음
인증 문제	FastAPI ↔ EAI 사이 인증토큰, IP 제한 등 필요
LLM에 데이터 직접 노출 ❌	주민번호, 이름 등은 마스킹해서 보여주기
로그 추적	누가 어떤 시스템을 호출했는지 로그화 필요

✅ 결론: LLM → FastAPI → EAI → 시스템 호출이라는 구조를 따르되

• FastAPI는 가볍고 스마트하게 요청을 만들고
• EAI는 기업 내부 통합과 보안 흐름을 따라 처리하고
• 레거시 시스템은 원래 하던 일만 집중하게 하자