EAI 정리

Hun·2일 전

commit

목록 보기

1/3

📌 EAI란?

EAI(Enterprise Application Integration, 전사적 애플리케이션 통합) 는
기업 안에 흩어져 있는 서로 다른(이기종) 애플리케이션과 시스템들을 연결해서, 데이터와 업무 프로세스가 하나의 흐름처럼 동작하도록 만드는 기술이자 아키텍처, 방법론을 말합니다.

쉽게 말하면,

서로 다른 언어를 쓰고, 서로 다른 DB를 쓰고, 서로 다른 시대에 만들어진 시스템들이
서로 대화할 수 있게 해주는 통역사 + 교통정리 담당

이라고 볼 수 있어요.

🤔 왜 필요해졌을까?

1. 시스템이 너무 많아졌다

기업이 성장하면서 업무별로 시스템을 하나씩 도입합니다.

인사/회계/구매 → ERP
고객 관리 → CRM
공급망 관리 → SCM
생산 관리 → MES
그리고 수십 년 전에 만든 레거시 시스템들..

각 시스템은 도입 시기도, 개발 언어도, DB도, 통신 방식도 다 다릅니다.
그런데 업무는 이 시스템들을 가로질러서 일어나죠.

예) 주문이 들어오면 → 재고 확인 → 생산 계획 반영 → 회계 처리 → 고객에게 알림

2. 시스템끼리 1:1로 붙이다 보니 스파게티가 됐다

처음엔 필요할 때마다 시스템끼리 직접 연결했습니다. 이를 Point-to-Point(P2P) 방식이라고 합니다.

시스템이 몇 개 없을 땐 괜찮지만, 늘어날수록 연결 수가 폭발합니다.

연결 수 = n(n-1) / 2

시스템 5개  → 최대 10개 연결
시스템 10개 → 최대 45개 연결
시스템 50개 → 최대 1,225개 연결

어떤 시스템 하나를 바꾸면 연결된 모든 곳을 수정해야 하고
어디서 어디로 데이터가 흐르는지 아무도 전체를 모르게 되고
장애가 나면 원인 추적이 지옥이 됩니다

이런 구조를 흔히 스파게티 아키텍처라고 부릅니다.
EAI는 이 문제를 해결하기 위해 1990년대 후반부터 본격적으로 등장했습니다.

🏗️ 연계 아키텍처 유형

1. Point-to-Point

[A] ──── [B]
 │ ╲    ╱ │
 │  ╲  ╱  │
 │   ╳    │
 │  ╱  ╲  │
[C] ──── [D]

시스템끼리 직접 연결
✅ 단순하고 초기 구축이 빠름
❌ 시스템이 늘면 관리 불가, 재사용성 없음

2. Hub & Spoke

      [A]
       │
[D] ─ [HUB] ─ [B]
       │
      [C]

가운데 허브(Hub) 를 두고 모든 시스템이 허브하고만 통신
연결 수가 n개로 줄어듦
✅ 중앙 집중 관리, 모니터링 용이, 변환/라우팅을 한곳에서 처리
❌ 허브가 죽으면 전체가 멈춤 (SPOF, Single Point Of Failure), 허브에 부하 집중

3. Message Bus (Bus 방식)

[A]    [B]    [C]    [D]
 │      │      │      │
═══════════════════════════  Bus

공통 통신 채널(버스)에 각 시스템이 어댑터를 통해 붙는 구조
메시지를 버스에 올리면 필요한 시스템이 받아감
✅ 확장성이 좋고 허브 병목이 덜함
❌ 구조가 분산되어 있어 설계·관리가 상대적으로 복잡

4. Hybrid

그룹 내부는 Hub & Spoke, 그룹 간은 Bus로 연결하는 식의 혼합형
실제 대규모 기업 환경에서는 대부분 이런 형태에 가깝습니다

🧩 EAI의 구성 요소

구성 요소	역할
어댑터 (Adapter)	각 시스템(DB, ERP, 파일, 소켓 등)과 EAI를 연결하는 플러그. 시스템마다 다른 접속 방식을 흡수
메시지 브로커 / 통합 엔진	메시지를 받아서 어디로 보낼지 결정하고 전달하는 핵심 엔진
메시지 큐 / 미들웨어	메시지를 안전하게 저장·전달. 수신 측이 죽어 있어도 유실되지 않게 보장
변환 (Transformation / Mapping)	A 시스템 포맷 → B 시스템 포맷으로 데이터 구조·형식 변환
라우팅 (Routing)	메시지 내용이나 조건에 따라 목적지를 결정
프로세스 관리 (BPM / Workflow)	여러 시스템을 거치는 업무 흐름을 순서대로 조율
모니터링 / 관리 도구	인터페이스 상태, 처리 건수, 에러, 재처리 등을 관리

🪜 통합 수준 (Integration Level)

EAI는 어느 층에서 연결하느냐에 따라 나눠 보기도 합니다.

데이터 레벨 — DB와 DB를 직접 연계. 가장 흔하고 단순하지만 비즈니스 로직을 우회함
애플리케이션 인터페이스(API) 레벨 — 시스템이 제공하는 API/인터페이스를 통해 연계 (ERP의 BAPI/RFC 등)
메서드 레벨 — 비즈니스 로직 자체를 공유
UI 레벨 — 화면을 긁어서 연계 (스크린 스크래핑). 레거시 최후의 수단
비즈니스 프로세스 레벨 — 여러 시스템을 하나의 업무 흐름으로 묶어 조율

📡 통신 방식

동기 vs 비동기

구분	동기 (Synchronous)	비동기 (Asynchronous)
동작	요청 후 응답이 올 때까지 대기	보내고 바로 다음 일 처리
예시	실시간 조회, 승인 요청	주문 전달, 대량 데이터 전송
장점	결과를 즉시 확인	결합도가 낮고 장애에 강함
단점	상대가 느리거나 죽으면 같이 멈춤	결과 확인/순서 보장이 복잡

메시지 패턴

Request-Reply — 요청하고 응답을 받는 방식
Fire-and-Forget (One-way) — 보내기만 하고 응답은 안 받음
Publish-Subscribe (Pub/Sub) — 발행자가 토픽에 메시지를 올리면 구독자들이 각자 받아감
Point-to-Point Queue — 큐에 들어간 메시지를 소비자 하나가 가져감

실시간 vs 배치

실시간(Online) — 이벤트가 발생하면 즉시 연계
배치(Batch) — 정해진 시간에 모아서 한 번에 연계 (야간 정산 등)

🔌 자주 쓰이는 연계 방식 (프로토콜)

방식	특징
DB (JDBC 등)	테이블 폴링, 송신 테이블/수신 테이블 방식. 가장 흔함
File (FTP / SFTP)	파일을 떨궈두면 가져가는 방식. 배치에 많이 사용
Socket (TCP/IP)	전문을 소켓으로 주고받음. 금융권·레거시에서 여전히 많음
HTTP (REST / SOAP)	웹 서비스 기반. 최근 신규 연계는 REST 비중이 큼
MQ / JMS	메시지 큐 기반 비동기 연계. 신뢰성 있는 전달 보장

📄 연계 업무에서 자주 나오는 용어

인터페이스(IF) — 하나의 연계 단위. 보통 인터페이스 ID로 관리 (예: IF_ORDER_0001)
인터페이스 정의서 — 송신/수신 시스템, 연계 방식, 주기, 데이터 항목 등을 정리한 문서
송신 시스템 / 수신 시스템 — 데이터를 보내는 쪽 / 받는 쪽
전문(電文) — 시스템 간에 주고받는 정해진 형식의 메시지. 국내에선 특히 고정 길이 전문이 많음
헤더 / 바디 — 전문의 공통부(인터페이스 ID, 일시, 응답코드 등)와 실제 데이터부
매핑 — 송신 필드를 수신 필드로 연결·변환하는 작업
재처리 — 실패한 건을 다시 보내는 것. 연계 운영의 핵심 업무 중 하나
트랜잭션 처리 — 연계 도중 실패 시 롤백/보상 처리

🆚 비슷한 개념들과 비교

EAI vs ESB

구분	EAI	ESB
등장	1990년대 후반	2000년대 초중반 (SOA와 함께)
구조	주로 Hub & Spoke	Bus 기반 분산 구조
표준	벤더 독자 방식 비중이 큼	웹 서비스(SOAP, XML) 등 표준 기반
관점	애플리케이션 간 연결	서비스 단위 재사용 (SOA의 백본)

실무에서는 제품들이 양쪽 기능을 다 가지게 되면서 경계가 많이 흐려졌고, 현장에서는 EAI/ESB를 섞어서 부르는 경우도 많습니다.

국내 금융권에서 자주 보는 구분

MCI (Multi Channel Integration) — 인터넷뱅킹, 모바일, 창구 등 채널계와 내부를 연계
EAI — 대내 시스템 간 연계
FEP (Front End Processor) — 타 은행, 카드사, 금융결제원 등 대외 기관과 연계

EAI vs ETL

EAI — 업무 트랜잭션 단위, 실시간/준실시간 프로세스 연계 중심
ETL (Extract, Transform, Load) — 대용량 데이터를 추출·변환해 DW 등에 적재하는 데이터 이관 중심, 주로 배치

EAI vs API Gateway / iPaaS

API Gateway — 외부/내부 API 호출의 인증, 라우팅, 트래픽 제어 담당
iPaaS — 클라우드 기반 통합 플랫폼 (SaaS 간 연계에 강함)

⚖️ 장점과 단점

✅ 장점

연결 구조 단순화 → 유지보수 비용 감소
기존 시스템을 거의 수정하지 않고 연계 가능
데이터 변환, 라우팅, 에러 처리를 한곳에서 표준화
연계 현황을 중앙에서 모니터링
신규 시스템 추가 시 어댑터만 붙이면 됨

❌ 단점

초기 도입 비용이 큼 (상용 솔루션 라이선스, 구축 인력)
중앙 구조일 경우 장애 파급 범위가 넓음
솔루션 의존성(벤더 종속)이 생김
연계 담당 인력에게 도메인 + 솔루션 + 인프라 지식이 동시에 요구됨

🛠️ 대표 솔루션

솔루션	비고
TIBCO BusinessWorks	대표적인 EAI/ESB 솔루션. TIBCO는 현재 Cloud Software Group 소속
webMethods	Software AG의 통합 솔루션이었으나 2024년 IBM에 인수됨
IBM App Connect	구 IBM Integration Bus / WebSphere Message Broker 계열
Oracle SOA Suite	오라클의 SOA/통합 플랫폼
Microsoft BizTalk Server	MS 계열 통합 서버
MuleSoft Anypoint	API 중심 통합 플랫폼, Salesforce 소속

국내에도 SI사나 솔루션사가 자체 개발한 연계 솔루션이 많이 쓰입니다.

🌊 최근 흐름

EAI → ESB/SOA → MSA 로 이어지며 "중앙 집중형 거대 통합"에서 "작은 서비스 + API" 중심으로 이동
이벤트 스트리밍 (Kafka 등) 을 활용한 이벤트 기반 아키텍처(EDA) 확산
클라우드와 온프레미스를 함께 쓰는 하이브리드 통합, iPaaS 증가
그럼에도 금융, 제조, 공공, 대기업 그룹사처럼 레거시와 ERP가 많은 곳에서는 EAI가 여전히 핵심 인프라로 운영 중

기술 이름은 바뀌어도 "서로 다른 시스템을 안전하게 연결한다" 는 문제는 사라지지 않는다.

📝 한 줄 정리

EAI = 이기종 시스템들 사이에 서서, 연결·변환·전달·관리를 전담하는 통합 계층

Hun

구른다

다음 포스트