EAI와 ESB (기업 애플리케이션 통합)
1. 개요
EAI(Enterprise Application Integration, 기업 애플리케이션 통합)란 기업 내부에 흩어져 있는 이기종 애플리케이션·데이터·프로세스를 표준화된 연계 기반 위에서 상호 연결하여, 마치 하나의 시스템처럼 데이터를 주고받고 업무 흐름을 이어 주는 통합 기술이자 전략이다. 그리고 ESB(Enterprise Service Bus, 기업 서비스 버스)는 이 EAI를 서비스 지향(SOA) 관점에서 구현한 표준 메시지 버스형 미들웨어로, 라우팅·변환·프로토콜 중계·오케스트레이션 같은 연계 기능을 중앙 버스에 모아 느슨하게 결합된 서비스 간 통신을 매개한다.
EAI가 등장한 배경에는 기업 정보화가 "부문별 최적화"의 결과로 남긴 사일로(silo)와 스파게티 인터페이스 문제가 있다. 1980~1990년대 기업들은 회계·인사·영업·생산·물류 영역마다 패키지나 자체 개발 시스템을 따로 도입했고, 그 결과 ERP·CRM·SCM·레거시 메인프레임이 서로 다른 DB·프로토콜·데이터 포맷으로 난립하게 되었다. 이들을 연결하려고 시스템마다 1:1 인터페이스를 만들다 보니, n개의 시스템을 모두 연결하는 데 이론상 n(n−1)/2개의 연결선이 필요해졌다. 예컨대 시스템 10개를 완전 연결하면 45개의 점대점(point-to-point) 인터페이스가 생기고, 하나가 바뀌면 연결된 모든 상대가 영향을 받아 유지보수 비용이 기하급수적으로 증가했다. 이 "스파게티 통합"의 한계를 중앙 집중형 연계 허브로 풀자는 것이 EAI의 출발점이다.
ESB는 EAI가 성숙하면서 SOA(서비스 지향 아키텍처)와 만난 결과물이다. 2000년대 초 기업들은 통합의 단위를 단순한 "데이터 연계"에서 재사용 가능한 "서비스"로 끌어올리려 했고, 이때 서비스들이 서로의 위치·프로토콜·포맷을 몰라도 통신할 수 있게 버스(bus)라는 매개체가 필요했다. ESB는 바로 이 역할을 맡아, 메시지를 받아 적절한 서비스로 라우팅하고, 서로 다른 포맷을 변환하며, SOAP·REST·JMS·FTP 같은 이질적 프로토콜을 중계한다. 즉 EAI가 "무엇을 왜 통합하는가"라는 목표라면, ESB는 "어떻게 표준화된 버스로 통합하는가"라는 대표적 구현 방식이다.
EAI/ESB의 필요성은 세 가지 축에서 분명해진다. 첫째는 유지보수성으로, 연계 로직을 각 애플리케이션에서 떼어내 중앙으로 모으면 변경의 파급 범위가 줄어든다. 둘째는 민첩성으로, 신규 시스템을 붙일 때 기존 n개 모두와 연결하는 대신 허브·버스에 한 번만 연결하면 되므로 비즈니스 요구 변화에 빠르게 대응할 수 있다. 셋째는 데이터 정합성과 거버넌스로, 연계 지점을 한곳에서 관측·통제함으로써 어떤 데이터가 어디로 흐르는지 추적하고 보안·감사 정책을 일관되게 적용할 수 있다. 최근에는 클라우드·SaaS·모바일이 늘면서 연결 대상이 사내를 넘어 외부로 확장되었고, 이에 따라 EAI의 무게 중심이 전통적 ESB에서 API 관리·iPaaS·이벤트 기반 통합으로 옮겨 가고 있다.
EAI가 다루는 통합의 층위는 흔히 데이터·애플리케이션·프로세스·사용자 인터페이스의 네 수준으로 구분된다. 가장 낮은 데이터 수준 통합은 DB 간 데이터를 직접 동기화하는 방식으로 구현이 단순하지만 애플리케이션의 비즈니스 규칙을 우회해 정합성 위험이 있다. 애플리케이션(API) 수준 통합은 각 시스템이 노출한 인터페이스를 통해 기능을 호출하므로 규칙이 보존되며, 오늘날 통합의 주류다. 프로세스 수준 통합은 여러 시스템에 걸친 업무 흐름을 하나의 프로세스로 엮는 것으로 ESB의 오케스트레이션이 담당한다. 이처럼 통합은 "어느 층위에서 묶느냐"에 따라 비용과 위험이 달라지므로, 목적에 맞는 층위를 고르는 것이 EAI 설계의 첫 결정이 된다.
EAI/ESB를 다른 연계 방식과 구별 짓는 특징은 느슨한 결합(loose coupling), 중개(mediation), 선언적 연계로 요약된다. 송신자와 수신자가 서로를 직접 알 필요 없이 버스가 중개하므로 한쪽의 변경이 다른 쪽에 숨겨지고, 라우팅·변환 규칙을 코드가 아닌 설정으로 선언해 변경 비용을 낮춘다. 이 특징들이 왜 ESB가 한때 SOA의 중추로 각광받았는지, 그리고 왜 뒤에서 다룰 "중앙 버스의 병목·단일 장애점" 문제로 비판받게 되었는지를 동시에 설명한다.
한편 EAI/ESB는 단순한 기술 도입이 아니라 전사 아키텍처 거버넌스의 일부라는 점도 처음부터 분명히 해야 한다. 연계 기반을 중앙에 두면 "누가 연계 규칙을 정하고 변경을 승인하는가", "공통 포맷의 표준을 누가 관리하는가" 같은 조직적 질문이 따라오기 때문이다. 기술적으로 아무리 훌륭한 버스를 구축해도 이 거버넌스가 없으면 각 팀이 제각각 연계를 만들어 결국 중앙 버스 위에 또 다른 스파게티가 쌓인다. 즉 EAI는 미들웨어 선택 이전에 표준·책임·변경 절차를 정하는 통합 거버넌스 설계에서 출발해야 한다.
2. EAI 통합 유형과 아키텍처
EAI를 이해하는 핵심은 "연결 토폴로지"가 통합의 비용과 확장성을 좌우한다는 점이다. 같은 시스템들을 연결하더라도 점대점이냐, 허브-스포크냐, 메시지 버스냐에 따라 유지보수 난이도와 장애 전파 양상이 완전히 달라진다. 아래 전체 구조도는 세 가지 토폴로지의 연결 형태를 대비해 보여 준다.
flowchart LR
subgraph P2P["점대점(Point-to-Point)"]
A1["ERP"] --- A2["CRM"]
A1 --- A3["SCM"]
A2 --- A3
A1 --- A4["레거시"]
A2 --- A4
A3 --- A4
end
subgraph HUB["허브-스포크(Hub & Spoke, EAI)"]
H(("통합 허브"))
B1["ERP"] --> H
B2["CRM"] --> H
B3["SCM"] --> H
B4["레거시"] --> H
end
subgraph BUS["메시지 버스(ESB)"]
BUSLINE["서비스 버스"]
C1["ERP"] --> BUSLINE
C2["CRM"] --> BUSLINE
C3["SCM"] --> BUSLINE
C4["레거시"] --> BUSLINE
end
세 토폴로지는 통합 역사에서 순차적으로 등장했지만, 오늘날 한 기업 안에서도 영역에 따라 공존한다는 점을 먼저 짚어 둘 필요가 있다. 레거시 코어는 여전히 점대점으로 묶여 있고, 전사 공통 데이터는 허브나 버스를 거치며, 신규 클라우드 서비스는 API·이벤트로 연결되는 식이다. 따라서 토폴로지 선택은 "무엇이 옳은가"의 문제라기보다 "어느 영역에, 어떤 변경 빈도와 성능 요구에 맞춰 무엇을 쓸 것인가"라는 영역별 적합성의 문제다.
점대점(Point-to-Point) 방식은 가장 단순하지만 가장 위험한 토폴로지다. 두 시스템을 직접 연결하므로 초기에는 구현이 빠르고 직관적이지만, 시스템 수가 늘면 연결선이 n(n−1)/2로 폭증해 앞서 말한 스파게티 구조가 된다. 각 연결이 상대의 포맷·프로토콜에 강하게 결합되어, 한 시스템의 스키마가 바뀌면 그와 연결된 모든 인터페이스를 손봐야 한다. 실무에서는 "연계 담당자가 퇴사하면 아무도 손대지 못하는" 블랙박스 인터페이스가 쌓이는 전형적 안티패턴으로 나타난다. 소수 시스템의 단발성 연계에는 여전히 합리적이지만, 전사 통합 전략으로는 부적합하다.
허브-스포크(Hub & Spoke) 방식은 전통적 EAI의 핵심 형태로, 중앙에 통합 허브(브로커)를 두고 모든 시스템이 허브에만 연결되는 구조다. 각 시스템은 상대가 누구인지 몰라도 허브에 메시지를 보내면 허브가 변환·라우팅을 거쳐 목적지로 전달한다. 연결 수가 n개로 선형화되어 신규 시스템 추가 비용이 급감하고, 변환·라우팅 로직이 허브에 집중되어 거버넌스가 쉬워진다. 다만 허브가 모든 트래픽을 통과시키므로 성능 병목과 단일 장애점(SPOF) 위험이 있고, 허브 자체가 거대해지면 유지보수가 어려워진다. 한 제조 기업이 15개 시스템을 점대점으로 연결하며 100개가 넘는 인터페이스를 운영하다 허브-스포크 EAI로 전환해 연결 관리 포인트를 15개로 줄인 사례는 이 방식의 효과를 전형적으로 보여 준다.
메시지 버스(Message Bus) 방식, 즉 ESB는 허브의 집중을 완화하기 위해 통합 기능을 분산된 버스로 재구성한 형태다. 각 시스템은 버스에 연결된 어댑터를 통해 표준 메시지를 주고받고, 라우팅·변환은 버스 위의 분산된 연계 노드들이 처리한다. 허브-스포크가 "중앙의 큰 뇌"라면 ESB는 "여러 정류장을 잇는 노선"에 가까워, 특정 노드 장애가 전체로 번지는 위험을 줄이고 수평 확장을 꾀한다. 실제로는 허브-스포크와 버스의 경계가 명확하지 않고, 상용 ESB 제품 다수가 내부적으로 허브 요소를 품고 있어 둘을 통합 미들웨어의 진화 단계로 보는 편이 실무에 가깝다.
| 구분 | 점대점 | 허브-스포크(EAI) | 메시지 버스(ESB) |
|---|---|---|---|
| 연결 수(n 시스템) | n(n−1)/2 | n | n |
| 결합도 | 강결합 | 중간(허브 의존) | 느슨함 |
| 확장성 | 매우 낮음 | 중간 | 높음 |
| 장애 전파 | 국소적 | 허브 SPOF | 상대적 분산 |
| 거버넌스 | 분산·불투명 | 중앙 집중 | 중앙 정책+분산 실행 |
표는 세 토폴로지를 한눈에 비교하지만, 핵심은 "연결 수가 제곱에서 선형으로 줄어드는 지점"에서 통합 투자 회수가 발생한다는 점이다. 시스템이 적을 때는 점대점이 저렴하지만, 임계 수를 넘으면 중앙 연계 기반의 초기 구축비를 상쇄하고도 남는 유지보수 절감이 생긴다. 따라서 EAI 도입 결정은 "지금 몇 개를 연결하느냐"가 아니라 "앞으로 몇 개로, 얼마나 자주 바뀌며 늘어날 것이냐"라는 성장 전망에 기반해야 한다.
3. ESB의 구조와 핵심 기능
ESB의 가치는 단순히 "메시지를 전달한다"가 아니라, 송·수신 서비스가 서로의 차이를 몰라도 통신하도록 중개(mediation) 계층이 그 차이를 흡수한다는 데 있다. 서로 다른 포맷·프로토콜·주소를 가진 서비스들이 버스를 통해 결합되므로, 한쪽을 교체해도 다른 쪽은 영향을 받지 않는다. 아래 아키텍처 세부도는 메시지가 ESB를 통과하며 거치는 중개 파이프라인을 나타낸다.
flowchart TB
SRC["송신 서비스(예: 주문 시스템)"] --> IN["인바운드 어댑터(프로토콜 수신)"]
IN --> ROUTE["라우팅(내용 기반 라우팅)"]
ROUTE --> TRANS["메시지 변환(포맷/스키마 매핑)"]
TRANS --> ORCH["오케스트레이션(다중 서비스 조합)"]
ORCH --> SEC["보안/정책(인증·감사)"]
SEC --> OUT["아웃바운드 어댑터(프로토콜 송신)"]
OUT --> DST1["수신 서비스 A(배송)"]
OUT --> DST2["수신 서비스 B(재고)"]
MON["모니터링·로깅"] -.-> ROUTE
MON -.-> TRANS
MON -.-> ORCH
어댑터와 프로토콜 중계는 ESB의 가장 바깥 관문이다. 레거시 메인프레임은 MQ나 파일(FTP)로, 최신 서비스는 REST/JSON으로, 금융 코어는 전용 TCP 전문으로 통신하는 식으로 프로토콜이 제각각인데, 어댑터는 이 이질적 프로토콜을 받아 버스 내부의 표준 메시지 형식(canonical message)으로 정규화한다. 이렇게 함으로써 버스 내부 로직은 외부 프로토콜의 변화로부터 격리된다. 예컨대 한 수신 시스템이 SOAP에서 REST로 바뀌어도, 어댑터만 교체하면 라우팅·변환 규칙은 그대로 재사용된다. 이 "프로토콜 독립성"이 ESB를 단순 메시지 큐와 구별 짓는 첫 번째 능력이다.
라우팅(routing)은 메시지를 내용·헤더·규칙에 따라 적절한 목적지로 보내는 기능이다. 가장 강력한 형태는 내용 기반 라우팅(content-based routing)으로, 메시지 본문의 값(예: 주문 금액 1,000만 원 이상이면 승인 서비스로)을 보고 분기한다. 송신자는 수신자가 누구인지 전혀 몰라도 되고, 라우팅 규칙이 바뀌어도 송신 코드는 그대로다. 이처럼 "누가 받을지"에 대한 결정을 송신자에서 버스로 옮기는 것이 느슨한 결합의 핵심 메커니즘이며, 수신자 추가·교체를 설정 변경만으로 처리할 수 있게 한다.
메시지 변환(transformation)은 서로 다른 데이터 스키마를 매핑하는 기능으로, 통합 현장에서 가장 많은 공수가 드는 부분이다. 송신 시스템이 고객을 custNo로, 수신 시스템이 customer_id로 부른다면 버스가 이를 변환해 양쪽이 각자의 모델을 유지하도록 한다. 대규모 통합에서는 모든 시스템이 서로의 포맷을 알 필요 없이 표준 공통 포맷(canonical data model)으로만 변환하도록 설계하는데, 이렇게 하면 n개 시스템 간 변환 규칙이 n×n이 아니라 n×1(각 시스템↔공통 포맷)으로 줄어 유지보수가 크게 단순해진다. 이 공통 데이터 모델의 설계 품질이 EAI 프로젝트 성패를 좌우한다 해도 과언이 아니다. 다만 공통 포맷을 지나치게 크고 포괄적으로 설계하면 어느 시스템도 온전히 쓰지 않는 "거대한 공통 모델"이 되어 변환 규칙이 오히려 복잡해지는 역효과가 있으므로, 실제로는 도메인별로 적정 범위의 공통 모델을 나누어 관리하는 것이 바람직하다.
오케스트레이션(orchestration)은 여러 서비스를 하나의 비즈니스 흐름으로 엮는 기능이다. 예컨대 "주문 접수 → 재고 확인 → 결제 → 배송 지시"라는 업무를 버스가 중앙에서 순서대로 호출·조율한다. 이는 각 서비스가 자율적으로 이벤트에 반응하는 코레오그래피(choreography)와 대비되는데, 오케스트레이션은 흐름이 한곳에 모여 가시성과 통제가 쉬운 반면 중앙 조정자에 로직이 집중돼 결합도가 올라간다. 반대로 코레오그래피는 느슨하지만 전체 흐름을 한눈에 보기 어렵다. ESB 시대에는 중앙 오케스트레이션이 주류였으나, 마이크로서비스 시대로 오면서 코레오그래피·이벤트 기반으로 무게추가 옮겨 간 것은 이 트레이드오프의 재조정이다.
보안과 모니터링은 ESB가 전사 데이터의 길목이라는 사실에서 비롯되는 필수 기능이다. 모든 메시지가 버스를 통과하므로, 인증·인가·암호화를 버스에서 일괄 적용하면 각 시스템이 개별적으로 보안을 구현할 때보다 정책 일관성과 감사 추적성이 크게 높아진다. 또한 버스는 메시지 흐름을 중앙에서 관측하기에 유리한 지점이므로, 처리량·지연·오류율 같은 지표를 수집해 연계 장애를 조기에 탐지하고 영향 범위를 분석할 수 있다. 다만 이 중앙 관측의 이점은 버스가 과부하 없이 안정적으로 동작할 때만 유효하므로, 모니터링 자체가 버스 성능을 갉아먹지 않도록 샘플링·비동기 로깅 같은 설계 배려가 함께 필요하다.
| 핵심 기능 | 역할 | 느슨한 결합 기여 |
|---|---|---|
| 어댑터·프로토콜 중계 | 이기종 프로토콜 정규화 | 프로토콜 변화 격리 |
| 라우팅 | 내용 기반 목적지 결정 | 송신자·수신자 분리 |
| 변환 | 스키마/포맷 매핑 | 각자 데이터 모델 유지 |
| 오케스트레이션 | 다중 서비스 흐름 조합 | 프로세스 로직 중앙화 |
| 보안·모니터링 | 인증·감사·추적 | 정책 일관 적용 |
4. 비교와 사례: EAI/ESB · API Gateway · MOM · 마이크로서비스
EAI/ESB를 둘러싼 흔한 혼동은 "ESB·API Gateway·메시지 큐가 다 비슷한 중간 계층 아닌가"라는 물음이다. 결론부터 말하면 세 가지는 설계 의도와 결합 모델이 다르다. ESB는 "이기종 시스템을 중앙 버스로 중개·변환·오케스트레이션"하는 헤비웨이트 통합에 초점이 있고, API Gateway는 "외부에 API를 노출하고 인증·속도제한·라우팅으로 보호"하는 경량 진입점에 초점이 있으며, MOM(메시지 지향 미들웨어, 예: Kafka·RabbitMQ)은 "비동기 메시지의 안정적 전달·버퍼링"에 특화된 전송 기반이다. ESB가 변환·오케스트레이션까지 포함하는 "지능형 버스"라면, Kafka는 그보다 얇지만 처리량·내구성에서 압도적인 "굵은 파이프"다.
세 수단의 결합 모델 차이는 장애가 번지는 양상에서도 드러난다. ESB는 동기 호출과 중앙 오케스트레이션 비중이 높아 한 수신 서비스의 지연이 버스 스레드를 점유하며 다른 흐름까지 느리게 만드는 연쇄 지연이 생기기 쉽다. 반면 Kafka 같은 이벤트 스트림은 발행과 소비가 분리되어 있어 수신 측이 느려도 메시지가 버퍼에 쌓일 뿐 발행 측은 영향을 덜 받는다. API Gateway는 그 사이에서 속도제한·타임아웃·서킷 브레이커로 장애를 국소화한다. 따라서 "어떤 수단이 더 좋은가"는 평상시 처리량만이 아니라 장애 시 전파 양상까지 함께 보고 판단해야 하며, 즉시성이 필요 없는 흐름을 굳이 동기 ESB 호출로 묶어 장애 취약성을 키우는 설계는 피해야 한다.
이 차이가 실무에 주는 함의는 분명하다. ESB에 과도하게 많은 비즈니스 로직을 넣으면 버스가 거대한 모놀리식 병목이 되어 "ESB 안티패턴"이라 불리는 상황, 즉 모든 변경이 중앙 팀을 거쳐야 하는 조직적 병목이 생긴다. 실제로 많은 기업이 2010년대 중반 마이크로서비스로 전환하면서, 로직을 버스에서 걷어내 각 서비스로 분산하고 통신은 가벼운 API·이벤트 스트림으로 대체했다. 이것이 "Smart endpoints, dumb pipes(똑똑한 종단, 멍청한 파이프)"라는 마이크로서비스 원칙으로, 변환·오케스트레이션을 중앙 버스가 아니라 각 서비스가 담당하게 한다. 어떤 금융사는 전사 ESB로 수백 개 연계를 운영하다 릴리스 주기가 분기 단위로 느려지자, 핵심 흐름을 API Gateway + Kafka 기반으로 재편해 배포 빈도를 주 단위로 끌어올렸다.
규모의 관점에서 보면 선택의 분기점은 수치로 가늠된다. 예를 들어 연계 대상이 5개 안팎이고 변경이 드물다면 점대점 15개 이하의 인터페이스로도 관리가 가능하지만, 대상이 20개로 늘고 요구가 분기마다 바뀌는 환경에서는 점대점이 이론상 190개의 연결로 폭증해 사실상 유지보수가 불가능해진다. 바로 이 구간에서 중앙 연계 기반의 초기 투자가 회수되며, 통합 수단 선정은 현재 규모가 아니라 향후 2~3년의 연계 증가·변경 빈도 전망에 근거해야 한다. 어떤 공공기관이 대민 서비스 채널(웹·앱·콜센터·창구)을 늘리며 백엔드 연계가 수십 개로 불어나자, 채널별 중복 연계를 Experience/Process API 계층으로 재편해 신규 채널 추가 시 재사용률을 70% 이상으로 끌어올린 사례는 이 전망 기반 판단의 효과를 보여 준다.
그렇다고 ESB가 폐기된 것은 아니다. 수십 년 된 레거시, 전용 프로토콜, 복잡한 포맷 변환이 얽힌 환경에서는 ESB의 어댑터·변환 자산이 여전히 가장 현실적인 해법이다. 요점은 "ESB냐 마이크로서비스냐"의 이분법이 아니라, 연계의 복잡도와 변경 빈도에 맞춰 적정 무게의 통합 수단을 고르는 것이다. 변환이 복잡하고 레거시가 많으면 ESB가, 변경이 잦고 확장이 중요하면 API·이벤트 기반이 유리하다는 식의 상황 적합성이 판단 기준이 되어야 한다.
5. 심화: 통합 아키텍처의 현대화 — iPaaS와 API-led·이벤트 기반
전통적 ESB가 사내(on-premise) 중심이었다면, 오늘날 통합의 전장은 클라우드와 SaaS로 이동했다. 기업이 수십 개의 SaaS(세일즈·메신저·회계 등)를 쓰면서, 이들을 사내 시스템·클라우드와 엮는 수요가 폭증했고, 이를 겨냥한 것이 iPaaS(Integration Platform as a Service)다. iPaaS는 ESB의 라우팅·변환·커넥터 기능을 클라우드 관리형 서비스로 제공해, 서버 설치 없이 수백 종의 사전 제작 커넥터로 SaaS·DB·API를 끌어다 연결한다. MuleSoft Anypoint, Dell Boomi, Microsoft Azure Logic Apps·Integration Services, SAP Integration Suite 등이 대표적이며, 노코드·로우코드로 연계 흐름을 구성한다는 점에서 개발자 외 인력의 참여도 넓힌다.
동시에 통합의 설계 사상도 바뀌었다. MuleSoft가 제시해 널리 퍼진 API-led Connectivity는 API를 System API(레거시·DB 접근)·Process API(비즈니스 로직 조합)·Experience API(채널별 노출)의 3계층으로 나누어, 재사용 가능한 API 자산을 쌓아 올리는 방식이다. 이는 과거 ESB가 하던 중개·오케스트레이션을 "재사용 가능한 API의 계층적 조립"으로 재해석한 것으로, 중앙 버스 대신 API 관리 플랫폼이 거버넌스의 중심이 된다. 또 다른 흐름은 이벤트 기반 통합으로, Kafka 같은 이벤트 스트리밍을 중추로 삼아 시스템들이 이벤트를 발행·구독하며 느슨하게 반응하는 구조다. 이는 실시간성·확장성에서 전통 ESB를 능가해, 주문·결제·물류처럼 즉시성이 중요한 영역에서 빠르게 확산되고 있다.
이러한 현대화가 실제 수치로 나타나는 지점은 배포 민첩성이다. 전사 ESB에 모든 변경이 집중되던 시절 릴리스가 분기 단위에 머물던 조직이, API·이벤트 기반으로 로직을 분산한 뒤 주 단위 혹은 일 단위 배포로 전환하는 사례가 보고된다. 이는 통합 계층이 더 이상 모든 팀이 공유하는 단일 자원이 아니라, 각 도메인 팀이 독립적으로 소유·변경할 수 있는 자산으로 바뀌었기 때문이다. 다만 분산이 능사는 아니어서, 연계가 수십 개 서비스로 흩어지면 전체 흐름의 가시성과 데이터 정합성 관리가 오히려 어려워지므로, 분산 추적(distributed tracing)·스키마 레지스트리·계약 테스트 같은 보완 장치를 함께 갖추어야 현대화의 이점이 유지된다.
최근에는 생성형 AI·LLM이 통합 계층과 만나는 흐름도 나타난다. 자연어로 연계 요구사항을 기술하면 매핑·변환 규칙 초안을 생성하거나, 에이전트가 여러 SaaS API를 조합해 업무를 수행하도록 하는 시도가 그것이다. 특히 AI 에이전트가 외부 도구·데이터와 표준 방식으로 연결되도록 하는 프로토콜 논의가 활발해지면서, "애플리케이션 통합"의 개념이 사람이 설계한 정적 연계에서 에이전트가 동적으로 조합하는 연계로 확장될 조짐이 보인다. 다만 이 영역은 표준·보안·신뢰성이 아직 정립 중이므로, 기술사 관점에서는 "방향성은 분명하되 적용에는 신중한 검증이 필요한 단계"로 이해하는 것이 적절하다.
정리하면 통합 아키텍처는 점대점 → 허브-스포크 EAI → ESB → API 관리·iPaaS·이벤트 기반으로 진화해 왔으며, 이는 기술의 교체라기보다 "중앙 집중 중개"에서 "분산·재사용·실시간"으로 무게 중심이 이동하는 연속적 변천이다. 기업은 보통 이 단계들이 공존하는 하이브리드 상태에 있으므로, 현대화는 단절적 전환이 아니라 스트랭글러(strangler) 패턴처럼 레거시 연계를 점진적으로 새 방식으로 대체해 나가는 전략이 현실적이다.
6. 고려사항 및 시사점
첫째, 적정 무게(right-weight)의 통합 수단 선택이 핵심이다. ESB·iPaaS·API Gateway·이벤트 스트림은 경쟁재가 아니라 상황별 최적해가 다른 보완재다. 레거시·복잡 변환이 많으면 ESB/iPaaS의 어댑터·변환 자산이, 외부 API 노출·보호가 중요하면 API Gateway가, 실시간·고확장이 중요하면 이벤트 스트림이 유리하다. 기술사는 "유행하는 아키텍처"가 아니라 연계의 복잡도·변경 빈도·실시간성 요구를 정량적으로 평가해 수단을 조합해야 한다.
둘째, 중앙 집중의 트레이드오프를 경계해야 한다. 중앙 버스는 거버넌스·가시성에서 유리하지만, 과도한 로직 집중은 성능 병목·단일 장애점·조직적 병목(모든 변경이 중앙 팀을 경유)을 낳는다. "Smart endpoints, dumb pipes" 원칙에 따라 비즈니스 로직은 가능한 한 종단 서비스로 분산하고, 버스는 중개·전달이라는 본연의 역할에 집중시키는 것이 지속가능하다. 아울러 중앙 요소에는 반드시 다중화·장애 격리(서킷 브레이커·벌크헤드)를 설계해야 한다.
셋째, 공통 데이터 모델과 연계 거버넌스에 투자해야 한다. 통합의 실제 비용 대부분은 스키마 변환과 의미 불일치에서 발생하므로, 표준 공통 포맷(canonical model)·데이터 사전·연계 카탈로그를 선제적으로 정비해야 n×n 복잡도를 n×1로 낮출 수 있다. 또한 어떤 데이터가 어디로 흐르는지에 대한 데이터 계보(lineage)·감사 추적을 통합 계층에서 확보해, 개인정보·규제 준수와 장애 영향도 분석을 가능하게 해야 한다.
넷째, 점진적 현대화 전략을 취해야 한다. 대규모 EAI/ESB는 수백 개 연계가 얽혀 있어 일괄 교체(big-bang)는 위험이 크다. 스트랭글러 패턴으로 가치가 높고 변경이 잦은 흐름부터 API·이벤트 기반으로 이관하고, 레거시 전용 연계는 안정적으로 유지하며 공존시키는 하이브리드 접근이 현실적이다. 이 과정에서 연계 자산의 가시화(인벤토리)·테스트 자동화·점진적 트래픽 전환(카나리)이 위험을 관리하는 핵심 도구가 된다.
다섯째, 보안·신뢰성을 통합 계층의 1급 요구사항으로 다뤄야 한다. 통합 지점은 전사 데이터가 모이는 길목이므로, 인증·인가·암호화·속도제한·멱등성(idempotency) 보장이 필수다. 특히 비동기·이벤트 기반에서는 중복 전달·순서 역전·부분 실패에 대비한 재처리·보상 트랜잭션(사가) 설계가 데이터 정합성을 지키는 관건이다.
여섯째, 조직과 운영 모델도 함께 설계해야 한다. 중앙 통합팀이 모든 연계를 소유하면 조직적 병목이 되고, 각 도메인 팀에 전적으로 맡기면 표준이 무너지기 쉽다. 플랫폼 엔지니어링 관점에서 중앙은 커넥터·공통 포맷·보안 정책 같은 "셀프서비스 통합 플랫폼"을 제공하고, 실제 연계 구성과 변경은 도메인 팀이 수행하는 연합형(federated) 거버넌스가 현대 통합의 지향점이다. 기술만 현대화하고 조직 모델을 그대로 두면 아키텍처는 분산되어도 변경 속도는 여전히 중앙에 묶이는 역설이 생긴다.
참고자료
- Martin Fowler, "Microservices" — Smart endpoints and dumb pipes: https://martinfowler.com/articles/microservices.html
- MuleSoft, "What is API-led connectivity?": https://www.mulesoft.com/resources/api/what-is-api-led-connectivity
- Gartner, "Integration Platform as a Service (iPaaS)" 용어 설명: https://www.gartner.com/en/information-technology/glossary/information-platform-as-a-service-ipaas
- Enterprise Integration Patterns (Hohpe & Woolf): https://www.enterpriseintegrationpatterns.com/
한 줄 요약: EAI는 이기종 시스템을 중앙 연계 기반으로 묶어 점대점 스파게티를 선형 구조로 바꾸는 통합 전략이고 ESB는 그 SOA식 구현(버스형 중개·변환·오케스트레이션)이며, 오늘날 통합의 무게 중심은 중앙 버스에서 API 관리·iPaaS·이벤트 기반으로 이동해 "적정 무게의 수단을 상황에 맞게 조합하고 점진적으로 현대화"하는 것이 기술사 관점의 핵심이다.