핵심 요약
직접·간접 연계 방식과 API·웹 서비스·EAI·
본문
직접 연계와 간접 연계

| 구분 | 직접 연계 | 간접 연계 |
|---|---|---|
| 구조 | 송신과 수신 시스템이 직접 연결 | 중계·허브·버스·미들웨어를 경유 |
| 장점 | 구조가 단순하고 초기 구축이 빠를 수 있음 | 표준화·변환·라우팅·모니터링을 공통화 가능 |
| 단점 | 연결 증가, 시스템별 변환, 변경 영향 확대 | 중계 구간의 비용·운영 복잡성·장애 영향 |
| 적합 | 소수 시스템의 단순 연계 | 다수·이기종 시스템의 통합 |
직접 연계가 항상 동기식이고 간접 연계가 항상 비동기식인 것은 아니다. 연결 구조와 처리 시점은 다른 분류 기준이다.
대표 연계 방식
| 방식 | 특징 | 적합한 예 |
|---|---|---|
| API/웹 서비스 | 기능 계약을 호출하고 응답을 받음 | 실시간 조회·처리 |
| 파일 연계 | 정해진 파일을 주기적으로 교환 | 대용량 일괄 처리 |
| 데이터베이스 연계 | 테이블·뷰·DB 연결을 통해 데이터 접근 | 강하게 통제된 내부 환경 |
| 메시지 연계 | 큐·브로커를 통해 메시지 전달 | 비동기 처리, 송수신 시간 분리 |
선택 시 실시간성, 처리량, 순서·중복 허용, 네트워크, 장애 복구, 보안, 변경 가능성을 함께 검토한다.
API·웹 서비스·데이터 형식
- API: 다른 소프트웨어가 기능을 사용하기 위한 호출 규칙과 계약
- HTTP: 웹에서 요청·응답 메시지를 전달하는 대표 프로토콜
- REST: 자원과 표현, 통일된 인터페이스 등의 제약을 사용하는 아키텍처 스타일. 웹에서는 URI와 HTTP를 이용해 적용하는 경우가 많다
- JSON/XML: 데이터를 표현·교환하는 형식
REST가 곧 JSON을 뜻하는 것은 아니며, API와 데이터 형식은 같은 계층의 개념이 아니다.
SOAP· WSDL· UDDI
| 기술 | 역할 |
|---|---|
| SOAP | XML 기반 웹 서비스 메시지 교환 규약 |
| WSDL | 웹 서비스의 기능·메시지·접근 방법을 기술 |
| UDDI | 웹 서비스를 등록·검색하기 위한 저장소 규격 |
| XML | 구조화된 데이터를 표현하는 마크업 형식 |
SOAP은 서비스 설명서가 아니고, WSDL은 메시지 전송 프로토콜이 아니다.
EAI 구축 유형
| 유형 | 구조 | 특징 |
|---|---|---|
| Point-to-Point | 시스템끼리 개별 연결 | 단순하지만 연결이 늘면 관리가 복잡 |
| Hub & Spoke | 중앙 허브를 통해 연결 | 변환·라우팅 집중, 허브 의존 |
| Message Bus | 공통 버스를 통해 연결 | 확장성과 표준화에 유리 |
| Hybrid | 여러 유형을 혼합 | 환경에 맞게 유연하지만 관리 기준 필요 |
EAI와 ESB
- EAI(Enterprise Application Integration): 기업 내 여러 애플리케이션을 통합하는 기술·구조의 총칭
- ESB(Enterprise Service Bus): 서비스 중심으로 연결·변환·라우팅·중재를 제공하는 버스형 통합 기반
두 용어는 제품과 문헌에 따라 범위가 겹칠 수 있으나, 시험에서는 EAI의 구축 유형과 ESB의 표준화된 서비스 중재 역할을 구분한다.
미들웨어

미들웨어는 서로 다른 시스템·응용프로그램 사이에서 통신·데이터 교환·공통 서비스를 지원하는 소프트웨어 계층이다.
| 유형 | 핵심 기능 |
|---|---|
| RPC | 원격 프로시저를 로컬 호출처럼 요청 |
| MOM | 메시지 큐를 통한 비동기 메시지 전달 |
| TP Monitor | 다수 사용자와 분산 트랜잭션의 처리·감시 |
| ORB | 분산 객체 사이의 요청 전달·중개 |
| DB 미들웨어 | 애플리케이션과 데이터베이스 연결·접근 지원 |
| WAS | 웹 응용 실행과 트랜잭션·세션 등 공통 서비스 제공 |
미들웨어 종류는 주로 무엇을 중개하는지와 어떤 공통 서비스를 제공하는지로 판별한다.
선택 사례
- 주문 상태 즉시 조회 → API 방식 고려
- 하루 한 번 대량 정산 자료 → 파일 연계 고려
- 결제 완료 후 여러 후속 처리 → 메시지 기반 간접 연계 고려
- 많은 이기종 시스템의 변환·라우팅 → EAI/ESB 고려
기술 이름만으로 결정하지 않고 인터페이스 요구사항과 오류 처리 조건을 기준으로 선택한다.
동기·비동기 연계 선택 사례
사용자가 즉시 잔액을 확인해야 하는 요청은 동기 질의가 자연스럽지만, 주문 후 영수증 발송처럼 지연을 허용하고 급증을 흡수해야 하는 작업은 메시지 큐가 유리할 수 있다. 비동기 방식은 실패를 없애지 않으므로 재시도, 중복 처리, 순서, 보관 기간과 실패 큐를 설계한다.
복습 문제
답을 생각한 뒤 정답과 근거를 펼쳐 보세요.
메시지 브로커를 쓰면 발신부터 외부 부작용까지 정확히 한 번 처리되는가?
정답과 근거
자동으로 보장되지 않는다. 전달 보장과 소비자 멱등성, 상태 저장·외부 시스템의 원자성을 함께 봐야 한다.
실시간 요구가 있다는 이유만으로 모든 연계를 동기 호출로 만들어야 하는가?
정답과 근거
아니다. 사용자가 기다려야 하는 결과와 지연 가능한 후속 작업을 분리할 수 있다.