인터페이스 연계 방식과 기술

소프트웨어 설계 · 인터페이스 설계

이 페이지의 목차

핵심 요약

직접·간접 연계 방식과 API·웹 서비스·EAI·ESB·미들웨어의 역할을 비교한다.

본문

직접 연계와 간접 연계

전체 맞춤새 창 보기
연계 방식 비교도를 설명하는 교육용 도식
연계 방식 비교도
구분직접 연계간접 연계
구조송신과 수신 시스템이 직접 연결중계·허브·버스·미들웨어를 경유
장점구조가 단순하고 초기 구축이 빠를 수 있음표준화·변환·라우팅·모니터링을 공통화 가능
단점연결 증가, 시스템별 변환, 변경 영향 확대중계 구간의 비용·운영 복잡성·장애 영향
적합소수 시스템의 단순 연계다수·이기종 시스템의 통합

직접 연계가 항상 동기식이고 간접 연계가 항상 비동기식인 것은 아니다. 연결 구조와 처리 시점은 다른 분류 기준이다.

대표 연계 방식

방식특징적합한 예
API/웹 서비스기능 계약을 호출하고 응답을 받음실시간 조회·처리
파일 연계정해진 파일을 주기적으로 교환대용량 일괄 처리
데이터베이스 연계테이블·뷰·DB 연결을 통해 데이터 접근강하게 통제된 내부 환경
메시지 연계큐·브로커를 통해 메시지 전달비동기 처리, 송수신 시간 분리

선택 시 실시간성, 처리량, 순서·중복 허용, 네트워크, 장애 복구, 보안, 변경 가능성을 함께 검토한다.

API·웹 서비스·데이터 형식

  • API: 다른 소프트웨어가 기능을 사용하기 위한 호출 규칙과 계약
  • HTTP: 웹에서 요청·응답 메시지를 전달하는 대표 프로토콜
  • REST: 자원과 표현, 통일된 인터페이스 등의 제약을 사용하는 아키텍처 스타일. 웹에서는 URI와 HTTP를 이용해 적용하는 경우가 많다
  • JSON/XML: 데이터를 표현·교환하는 형식

REST가 곧 JSON을 뜻하는 것은 아니며, API와 데이터 형식은 같은 계층의 개념이 아니다.

SOAP·WSDL·UDDI

기술역할
SOAPXML 기반 웹 서비스 메시지 교환 규약
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 고려

기술 이름만으로 결정하지 않고 인터페이스 요구사항과 오류 처리 조건을 기준으로 선택한다.

동기·비동기 연계 선택 사례

사용자가 즉시 잔액을 확인해야 하는 요청은 동기 질의가 자연스럽지만, 주문 후 영수증 발송처럼 지연을 허용하고 급증을 흡수해야 하는 작업은 메시지 큐가 유리할 수 있다. 비동기 방식은 실패를 없애지 않으므로 재시도, 중복 처리, 순서, 보관 기간과 실패 큐를 설계한다.

복습 문제

답을 생각한 뒤 정답과 근거를 펼쳐 보세요.

01

메시지 브로커를 쓰면 발신부터 외부 부작용까지 정확히 한 번 처리되는가?

정답과 근거

자동으로 보장되지 않는다. 전달 보장과 소비자 멱등성, 상태 저장·외부 시스템의 원자성을 함께 봐야 한다.

02

실시간 요구가 있다는 이유만으로 모든 연계를 동기 호출로 만들어야 하는가?

정답과 근거

아니다. 사용자가 기다려야 하는 결과와 지연 가능한 후속 작업을 분리할 수 있다.