DevOn 연계 기능 소개
DevOn 연계 모듈이 전문 변환·거래 로그·Load Balancer·Adaptor·Timer로 기관 연계를 표준화하는 방법과 동기·비동기·Bid 거래 패턴을 정리합니다.
1. 개요
기관 연계 업무는 업무 시스템이 외부 기관 시스템, EAI, FEP, MCI, 채널 시스템 등과 데이터를 주고받으며 하나의 거래를 완성하는 구조입니다. 업무 시스템은 고객 조회, 신청, 승인, 검증, 결과 통지와 같은 업무 처리를 수행하기 위해 기관 시스템에 요청을 보내고, 기관 시스템의 응답을 기준으로 후속 업무를 처리합니다.
Java/Spring 계열에서도 외부 시스템 호출을 위해 HttpClient, Feign Client, WebClient 등 다양한 HTTP 유틸과 클라이언트 기술을 사용할 수 있습니다. 그러나 이러한 기술들은 주로 개별 서비스나 개발자가 직접 호출 방식을 구현하는 데 초점이 있습니다. 실제 엔터프라이즈 연계 환경에서는 단순 HTTP 호출뿐만 아니라 기관별 전문 변환, 거래 로그, 타임아웃, 재시도, 부하 분산, Adaptor 선택, 비동기 응답 매핑, 장애 대응 정책 등을 일관된 기준으로 제어해야 합니다.
DevOn 연계 모듈은 이러한 요구를 프레임워크 레벨에서 공통화하기 위해 LinkManager와 같은 설정 기반 연계 제어 기능을 제공합니다. 업무 서비스는 기관별 통신 방식이나 전문 규격을 직접 구현하지 않고, LinkManager를 통해 표준화된 방식으로 연계 거래를 요청할 수 있습니다. 연계 대상, 거래 유형, 송수신 방식, 타임아웃 정책, Adaptor 정보 등은 설정 기반으로 관리되며, 업무 서비스는 연계 처리의 세부 구현보다 업무 로직에 집중할 수 있습니다.
즉, DevOn 연계 기능은 단순한 HTTP 호출 유틸이 아니라 다양한 기관 연계 환경을 표준화하고 통제하기 위한 공통 연계 프레임워크입니다. 연계 모듈은 전문 변환, 거래 로그 기록, Load Balancer를 통한 대상 선정, Adaptor를 통한 송수신, Timer를 통한 비동기 거래 타임아웃 관리 등을 수행합니다. 이를 통해 기관별 인터페이스 차이를 흡수하고, 안정성과 성능을 고려한 연계 아키텍처를 구현할 수 있습니다.
DevOn 연계 거래 패턴은 크게 동기 거래, 비동기 거래, Bid 거래로 구분할 수 있습니다. 동기 거래는 요청 후 실제 응답을 기다리는 방식이고, 비동기 거래는 요청 후 실제 응답을 기다리지 않고 ACK 또는 Dummy 응답만 받은 뒤 요청 프로세스를 종료하는 방식입니다. Bid 거래는 Push 알람과 같이 단말 또는 MCI로 응답 메시지를 Request에 담아 요청하는 방식의 거래입니다.
2. DevOn 연계 모듈 메커니즘
DevOn에서 제공하는 연계 모듈은 다양한 인터페이스에 맞게 연계 기능을 제공하는 공통 모듈입니다. 업무 서비스는 기관별 통신 방식이나 전문 규격을 직접 처리하지 않고, DevOn 연계 모듈을 통해 연계 거래를 요청합니다.
연계 모듈은 업무 서비스로부터 전달받은 요청 데이터를 기관 연계에 적합한 전문으로 변환하고, 거래 로그를 기록하며, Load Balancer를 통해 송신 대상 또는 처리 경로를 결정합니다. 이후 Adaptor를 통해 EAI, FEP, 기관 시스템 등 외부 연계 대상과 실제 송수신을 수행합니다. 비동기 거래의 경우에는 Timer를 통해 실제 응답 지연 여부를 관리하고, 일정 시간 내 응답이 없을 경우 Timeout 처리를 수행합니다.
DevOn 연계 모듈의 기본 구조는 다음과 같습니다.
이 구조의 핵심은 업무 로직과 연계 로직을 분리하는 것입니다. 업무 서비스는 "어떤 거래를 요청할 것인지"에 집중하고, DevOn 연계 모듈은 "어떤 전문으로, 어떤 경로를 통해, 어떤 방식으로 송수신하고, 어떻게 추적할 것인지"를 담당합니다.
2-1. 전문 변환
전문 변환은 업무 서비스에서 사용하는 내부 데이터 구조를 기관 또는 외부 연계 시스템이 요구하는 전문 형식으로 변환하는 기능입니다. 반대로 외부 시스템에서 수신한 응답 전문을 업무 서비스가 사용할 수 있는 표준 응답 구조로 변환하는 역할도 수행합니다.
기관 시스템마다 전문 구조, 필드명, 데이터 길이, 코드 체계, 헤더 구성, 송수신 포맷이 다를 수 있습니다. 업무 서비스가 이러한 기관별 전문 규격을 직접 처리하면 기관이 추가되거나 전문이 변경될 때마다 업무 로직도 함께 수정되어야 합니다. DevOn 연계 모듈은 전문 변환 기능을 통해 이러한 기관별 차이를 흡수합니다.
전문 변환의 주요 역할은 다음과 같습니다.
| 구분 | 설명 |
|---|---|
| 요청 전문 변환 | 업무 서비스의 요청 데이터를 기관 또는 EAI/FEP 전문 형식으로 변환 |
| 응답 전문 변환 | 기관 응답 전문을 업무 서비스가 사용할 수 있는 표준 구조로 변환 |
| 헤더 생성 | GlobalID, 기관 코드, 거래 구분, 전문 구분 등 공통 헤더 구성 |
| 코드 매핑 | 기관 결과 코드와 내부 표준 결과 코드 간 매핑 |
| 데이터 검증 | 필수값, 길이, 형식, 코드값 등 전문 송신 전 기본 검증 |
| 전문 파싱 | 수신 전문에서 업무 처리에 필요한 항목 추출 |
전문 변환을 공통화하면 업무 서비스는 기관별 전문 규격을 몰라도 표준 인터페이스를 통해 연계를 요청할 수 있습니다. 또한 기관 전문 변경 시에도 전문 변환 영역만 수정하면 되므로 유지보수성이 높아집니다.
2-2. 거래 로그
거래 로그는 연계 요청과 응답의 전체 흐름을 추적하기 위한 핵심 기능입니다. 기관 연계는 외부 시스템과의 송수신을 포함하므로 장애 발생 시 어느 구간에서 문제가 발생했는지 확인할 수 있어야 합니다. 이를 위해 DevOn 연계 모듈은 요청 전문, 응답 전문, 송신 시각, 응답 시각, 거래 상태, 결과 코드, 오류 정보 등을 기록합니다.
거래 로그는 단순한 기록이 아니라 운영과 장애 대응의 기준 데이터입니다. 운영자는 거래 로그를 통해 요청이 정상적으로 생성되었는지, EAI 또는 FEP로 송신되었는지, ACK를 수신했는지, 기관의 실제 응답이 도착했는지, 업무 후처리와 Bid 처리가 완료되었는지를 확인할 수 있습니다.
거래 로그에서 관리하는 주요 항목은 다음과 같습니다.
| 항목 | 설명 |
|---|---|
| GlobalID | 요청 거래를 식별하기 위한 고유 거래 ID |
| 요청 전문 | 업무 시스템에서 외부 시스템으로 전달한 요청 전문 |
| 응답 전문 | 외부 시스템 또는 기관 시스템에서 수신한 응답 전문 |
| 거래 상태 | 요청접수, 송신요청, ACK수신, 응답대기, 응답수신, 완료, 실패, Timeout 등 |
| 송신 시각 | EAI, FEP, 기관 시스템 등으로 요청을 송신한 시각 |
| 응답 시각 | ACK 또는 실제 응답을 수신한 시각 |
| 결과 코드 | 기관 결과 코드 및 내부 표준 결과 코드 |
| 오류 정보 | 통신 오류, 전문 오류, 변환 오류, 후처리 오류 등 |
특히 비동기 거래에서는 요청 프로세스와 실제 응답 프로세스가 분리되기 때문에 거래 로그가 매우 중요합니다. 실제 응답이 나중에 도착했을 때 GlobalID를 기준으로 최초 요청 거래와 매핑해야 하며, 매핑된 거래를 기준으로 업무 후처리와 Bid 처리를 수행해야 합니다.
2-3. Load Balancer
Load Balancer는 연계 요청을 적절한 처리 노드, 송신 경로 또는 외부 연계 채널로 분산하는 기능입니다. 기관 연계 업무에서는 특정 기관이나 특정 인터페이스에 요청이 집중될 수 있고, 일부 경로에 장애가 발생할 수도 있습니다. Load Balancer는 이러한 상황에서 부하 분산과 가용성 확보를 담당합니다.
Load Balancer는 기관 코드, 업무 구분, 전문 구분, 송신 대상, 시스템 상태, 처리량 제한 등을 기준으로 요청을 분산할 수 있습니다. 이를 통해 특정 서버나 특정 연계 경로에 부하가 집중되는 것을 방지하고, 장애가 발생한 경로를 우회하여 안정적인 연계 처리를 지원합니다.
Load Balancer의 주요 역할은 다음과 같습니다.
| 구분 | 설명 |
|---|---|
| 부하 분산 | 여러 연계 처리 노드 또는 송신 경로로 요청을 분산 |
| 가용성 확보 | 일부 노드 또는 경로 장애 시 정상 경로로 우회 |
| 기관별 라우팅 | 기관 코드, 업무 구분, 전문 구분에 따라 송신 대상 결정 |
| 운영 정책 반영 | 기관 운영 시간, 장애 상태, 우선순위 등을 고려한 라우팅 |
Load Balancer는 단순히 트래픽을 나누는 기능이 아니라, 기관 연계 업무의 안정성과 성능을 함께 고려하는 제어 지점입니다. 특히 대량 거래, 비동기 거래, 기관 처리량 제한이 있는 업무에서는 Load Balancer를 통해 연계 부하를 적절히 제어해야 합니다.
2-4. Adaptor
Adaptor는 외부 시스템과 실제 통신을 수행하는 기능입니다. 기관 시스템 또는 중계 시스템은 HTTP, TCP/IP, MQ, EAI, FEP, 파일 등 다양한 방식으로 연계될 수 있습니다. Adaptor는 이러한 통신 방식의 차이를 흡수하여 DevOn 연계 모듈이 일관된 구조로 외부 시스템과 송수신할 수 있도록 합니다.
업무 서비스는 기관이 어떤 프로토콜을 사용하는지 직접 알 필요가 없습니다. 업무 서비스는 DevOn 연계 모듈에 거래를 요청하고, 연계 모듈은 해당 거래에 맞는 Adaptor를 선택하여 외부 시스템과 통신합니다.
Adaptor의 주요 역할은 다음과 같습니다.
| 구분 | 설명 |
|---|---|
| 송신 처리 | EAI, FEP, 기관 시스템 등으로 요청 전문 송신 |
| 수신 처리 | ACK, 실제 응답, 역방향 Request 등 수신 |
| 프로토콜 처리 | HTTP, TCP, MQ, 파일 등 통신 방식 처리 |
| 전문 송수신 제어 | 전문 길이, 인코딩, 헤더, 세션, 연결 상태 관리 |
| 오류 처리 | 연결 실패, 타임아웃, 송신 실패, 수신 오류 처리 |
| 재시도 연계 | 송신 실패 시 재처리 또는 오류 상태 기록과 연계 |
Adaptor를 통해 통신 처리를 분리하면 신규 기관 추가나 연계 방식 변경 시 업무 서비스 수정 없이 연계 모듈과 설정 중심으로 대응할 수 있습니다.
2-5. Timer
Timer는 비동기 거래에서 실제 응답이 지연되는 경우 Timeout을 발생시켜주는 역할을 합니다. 비동기 거래는 업무 서비스가 요청 후 실제 응답을 기다리지 않기 때문에, 기관 시스템의 실제 응답이 정상적으로 도착했는지 별도로 관리해야 합니다. 이때 Timer는 비동기 요청 거래의 응답 지연 여부를 확인하고, 정해진 시간 내 응답이 도착하지 않으면 Timeout 처리를 수행합니다.
비동기 거래 요청 시 DevOn 연계 모듈은 요청 전문과 GlobalID를 Timer 테이블에 저장합니다. Timer 테이블에는 요청 거래의 기준 시각, 제한 시간, 거래 상태, 응답 수신 여부 등이 함께 관리될 수 있습니다. 이후 Timer는 주기적으로 대상 거래를 확인하여 응답 제한 시간이 초과된 거래를 찾아 Timeout 상태로 변경합니다.
Timer의 기본 처리 흐름은 다음과 같습니다.
Timer에서 관리하는 주요 항목은 다음과 같습니다.
| 항목 | 설명 |
|---|---|
| GlobalID | 비동기 요청 거래를 식별하는 요청거래ID |
| 요청 전문 | 기관으로 송신한 요청 전문 |
| 요청 시각 | 비동기 거래 요청이 발생한 시각 |
| Timeout 기준 시각 | 응답을 기다릴 수 있는 최대 기준 시각 |
| 거래 상태 | 응답대기, 응답수신, 완료, Timeout 등 |
| 응답 수신 여부 | 실제 응답 도착 여부 |
| 후처리 여부 | Timeout 또는 정상 응답에 따른 후처리 수행 여부 |
Timer는 비동기 거래의 안정성을 보장하는 중요한 장치입니다. 실제 응답이 오지 않는 거래를 무기한 대기 상태로 남겨두지 않고, 일정 시간이 지나면 Timeout 상태로 전환하여 운영자가 확인하거나 후속 처리를 수행할 수 있도록 합니다.
3. 연계 거래 패턴
DevOn 연계 모듈은 업무 특성과 기관 응답 방식에 따라 여러 거래 패턴을 제공할 수 있습니다. 대표적인 거래 패턴은 동기 거래, 비동기 거래, Bid 거래입니다.
동기 거래는 요청과 실제 응답이 하나의 흐름 안에서 처리되는 방식입니다. 비동기 거래는 요청 프로세스와 실제 응답 프로세스가 분리되는 방식입니다. Bid 거래는 단말 또는 MCI로 응답 메시지를 Request 형태로 전달하는 방식입니다.
업무 서비스는 기관 응답을 즉시 기다려야 하는지, 실제 응답이 나중에 도착하는지, 응답이 아예 없는지, 단말로 결과를 Push해야 하는지에 따라 적절한 거래 패턴을 선택해야 합니다.
3-1. 동기 거래
동기 거래는 업무 서비스가 기관 시스템으로 요청을 보낸 뒤, 기관 시스템의 실제 응답을 받을 때까지 기다리는 방식의 거래입니다. 업무 서비스는 DevOn 연계 모듈을 통해 기관에 요청을 송신하고, 기관 시스템의 응답을 수신한 후 그 결과를 기준으로 업무 처리를 완료합니다.
동기 거래에서는 업무 서비스의 요청 프로세스가 기관 응답 수신 시점까지 유지됩니다. 따라서 기관 응답 시간이 짧고, 사용자에게 즉시 결과를 반환해야 하는 업무에 적합합니다.
예를 들어 단건 조회, 즉시 검증, 상태 확인, 실시간 승인 여부 확인과 같은 업무는 동기 거래로 처리하기 적합합니다. 사용자는 요청 후 바로 결과를 받아야 하며, 업무 서비스도 기관 응답을 기준으로 후속 처리를 즉시 수행해야 하기 때문입니다.
동기 거래의 주요 특징은 다음과 같습니다.
| 구분 | 설명 |
|---|---|
| 처리 방식 | 요청 후 실제 응답을 기다림 |
| 요청/응답 구조 | 하나의 요청 프로세스 안에서 요청과 응답 처리 |
| 업무 서비스 상태 | 기관 응답 수신까지 대기 |
| 장점 | 구조가 단순하고 즉시 결과 확인 가능 |
| 고려사항 | 기관 응답 지연 시 업무 서비스 처리 시간이 길어짐 |
| 적합 업무 | 단건 조회, 즉시 검증, 실시간 처리 업무 |
동기 거래에서는 응답 시간 관리가 중요합니다. 기관 응답이 지연되면 업무 서비스의 처리 스레드가 대기 상태로 유지되고, 동시 요청이 증가할 경우 전체 시스템 성능에 영향을 줄 수 있습니다. 따라서 기관별 타임아웃, 오류 처리 등을 함께 고려해야 합니다.
3-2. 비동기 거래
비동기 연계 거래 패턴은 업무 서비스에서 기관 시스템으로 요청 후 실제 응답을 기다리지 않는 방식의 거래를 의미합니다. 업무 서비스는 DevOn 연계 모듈에 비동기 처리를 요청하고, 연계 모듈은 EAI 또는 FEP를 통해 기관 시스템으로 전문을 생성하여 요청합니다.
이때 EAI 또는 FEP는 기관의 실제 업무 처리 결과가 아니라 요청을 정상적으로 접수했다는 의미의 ACK 또는 Dummy 응답을 반환합니다. 업무 서비스는 이 ACK를 받은 뒤 요청 프로세스를 종료합니다. 즉, 업무 서비스는 기관 시스템의 실제 응답을 기다리지 않습니다.
실제 응답은 별도의 응답 프로세스에서 처리됩니다. 기관 시스템은 요청받은 거래에 대한 실제 처리 결과를 역방향 거래 형태의 Request 방식으로 EAI 또는 FEP에 전달합니다. EAI 또는 FEP는 해당 응답 전문을 업무 시스템의 DevOn 연계 모듈로 전달하고, 연계 모듈은 GlobalID, 즉 요청거래ID를 기준으로 최초 요청 거래에 해당하는 응답으로 간주합니다. 이후 업무 후처리, 결과 상태 변경, 필요 시 Bid 처리를 수행합니다.
비동기 거래는 Async, Deferred, Immediate 방식으로 구분할 수 있습니다.
비동기(Async)
Async 거래는 일반적인 비동기 연계 거래 패턴을 의미합니다. 업무 서비스에서 기관으로 거래 요청이 성공하면 ACK 또는 Dummy 응답을 받고 요청 프로세스는 종료됩니다. 이후 요청을 받은 기관 시스템은 실제 응답을 역방향 거래 형태로 요청하여 업무 시스템으로 응답을 전달합니다.
이 단계에서 업무 서비스가 받는 ACK는 최종 결과가 아닙니다. ACK는 요청이 정상적으로 접수되었거나 송신 요청이 수행되었다는 의미의 Dummy 응답입니다. 따라서 업무 서비스는 ACK를 기준으로 "요청 완료" 또는 "접수 완료" 상태까지만 처리하고, 실제 업무 결과는 이후 응답 프로세스에서 처리합니다.
Async 거래의 핵심은 요청 프로세스와 실제 응답 프로세스가 분리된다는 점입니다. 요청 시점에는 실제 결과를 기다리지 않고 ACK만 수신하며, 실제 결과는 기관 시스템이 별도 Request 방식으로 전달합니다. 따라서 GlobalID를 통한 거래 매핑과 Timer를 통한 Timeout 관리가 중요합니다.
Async 거래의 주요 특징은 다음과 같습니다.
| 구분 | 설명 |
|---|---|
| 요청 프로세스 | 업무 서비스가 기관으로 요청 후 ACK를 받고 종료 |
| 응답 프로세스 | 기관 시스템이 실제 응답을 역방향 Request로 전달 |
| 업무 서비스 대기 여부 | 실제 응답을 기다리지 않음 |
| 거래 식별 기준 | GlobalID, 요청거래ID |
| Timeout 관리 | Timer 테이블을 통해 응답 지연 여부 확인 |
| 후처리 시점 | 실제 응답 수신 후 수행 |
| 적합 업무 | 처리 시간이 길거나 기관 응답이 별도 거래로 전달되는 업무 |
Async 거래는 기관 처리 시간이 길거나, 기관이 즉시 결과를 반환하지 않고 나중에 별도 응답을 보내는 구조에서 효과적입니다. 또한 업무 서비스의 요청 처리 시간을 짧게 유지할 수 있어 시스템 자원을 안정적으로 사용할 수 있습니다.
디퍼드(Deferred)
Deferred 거래는 비동기 요청 후 실제 응답이 없는 거래를 의미합니다. 업무 서비스가 기관 시스템으로 거래를 요청하고 ACK 또는 Dummy 응답을 받은 뒤 요청 프로세스를 종료하지만, 이후 기관 시스템으로부터 별도의 실제 응답 거래가 오지 않는 형태입니다.
Deferred 거래에서는 요청이 정상적으로 송신되었는지 여부가 중요합니다. 실제 응답이 없기 때문에 업무 시스템은 기관의 최종 처리 결과를 즉시 알 수 없습니다. 따라서 업무적으로 요청 전달 자체가 의미 있는 거래이거나, 기관에서 별도 응답 없이 자체 처리하는 업무에 적합합니다.
Deferred 거래의 주요 특징은 다음과 같습니다.
| 구분 | 설명 |
|---|---|
| 처리 방식 | 비동기 요청 후 ACK를 받고 종료 |
| 실제 응답 | 없음 |
| 업무 서비스 대기 여부 | 대기하지 않음 |
| 후처리 방식 | ACK 수신 기준으로 요청 완료 처리 |
| Timeout 관리 | 실제 응답을 기대하지 않으므로 Async와 다르게 관리 |
| 적합 업무 | 통지성 거래, 단방향 전달성 거래, 결과 응답이 필요 없는 업무 |
Deferred 거래를 사용할 때는 실제 응답이 없어도 업무적으로 문제가 없는지 명확히 정의해야 합니다. 기관의 최종 처리 결과를 반드시 알아야 하는 업무라면 Deferred 거래보다는 Async 거래를 사용해야 합니다.
즉시 발송(Immediate)
Immediate 거래는 비동기 거래 요청 시점에 즉시 기관 거래를 요청하는 방식입니다. 일반적인 비동기 거래는 업무 서비스와 하나의 Transaction으로 묶어서 처리되며, 요청 정보와 거래 로그를 저장한 뒤 후속 처리 단계에서 송신이 이루어질 수 있습니다. 반면 Immediate 거래는 비동기 거래 요청 시점에 즉시 EAI 또는 FEP로 전문 송신을 요청한다는 차이가 있습니다.
즉, Immediate 거래는 비동기 구조를 유지하면서도 송신 시점을 앞당기는 방식입니다. 업무 서비스는 실제 응답을 기다리지 않지만, 연계 모듈은 비동기 요청이 발생한 시점에 즉시 외부 시스템으로 요청을 전달합니다.
Immediate 거래는 요청 즉시 기관으로 전문을 발송해야 하는 업무에 적합합니다. 예를 들어 업무 처리 지연을 최소화해야 하거나, 사용자의 요청 시점과 기관 송신 시점을 최대한 일치시켜야 하는 경우 사용할 수 있습니다.
Immediate 거래의 주요 특징은 다음과 같습니다.
| 구분 | 설명 |
|---|---|
| 처리 방식 | 비동기 요청 시점에 즉시 외부 시스템으로 송신 |
| 업무 서비스 대기 여부 | 실제 응답을 기다리지 않음 |
| 일반 비동기와의 차이 | 요청 저장 후 별도 송신이 아니라 요청 시점에 즉시 송신 |
| 응답 처리 | 실제 응답이 있는 경우 Async 응답 프로세스와 동일하게 처리 |
| 적합 업무 | 송신 지연을 최소화해야 하는 비동기 업무 |
Immediate 거래를 사용할 때는 업무 Transaction과 연계 송신 시점의 관계를 주의해야 합니다. 업무 Transaction이 아직 확정되지 않은 상태에서 외부 기관으로 송신이 먼저 이루어질 수 있으므로, 롤백 가능성, 중복 송신, 오류 보정, 거래 상태 관리 기준을 명확히 설계해야 합니다.
3-3. Bid 거래
Bid 거래는 Push 알람과 같이 단말 또는 MCI로 응답 메시지를 Request에 담아 요청하는 방식의 거래입니다. 일반적인 응답은 요청을 보낸 주체에게 Response 형태로 반환되지만, Bid 거래는 업무 결과나 기관 응답 결과를 단말 또는 MCI로 별도 Request 형태로 전달한다는 점이 특징입니다.
예를 들어 비동기 거래에서 기관의 실제 응답이 나중에 도착한 경우, 업무 시스템은 해당 응답을 처리한 뒤 단말에 결과를 알려야 할 수 있습니다. 이때 단말이 결과를 조회하러 오기를 기다리는 방식이 아니라, 업무 시스템 또는 연계 모듈이 단말이나 MCI로 결과 메시지를 Request 형태로 전달할 수 있습니다. 이러한 방식이 Bid 거래입니다.
Bid 거래의 주요 특징은 다음과 같습니다.
| 구분 | 설명 |
|---|---|
| 처리 방식 | 응답 메시지를 Request에 담아 단말 또는 MCI로 전달 |
| 주요 용도 | Push 알람, 비동기 결과 통지, 단말 상태 갱신 |
| 연계 기준 | GlobalID 또는 업무 결과 식별 정보 |
| 처리 시점 | 업무 후처리 완료 후 필요 시 수행 |
| 대상 | 단말, MCI, 채널 시스템 등 |
| 특징 | 단말이 먼저 조회하지 않아도 결과를 전달할 수 있음 |
Bid 거래는 비동기 거래와 함께 사용되는 경우가 많습니다. 비동기 거래에서는 업무 서비스가 실제 응답을 기다리지 않기 때문에 최종 결과를 사용자나 단말에 전달하는 별도 방식이 필요합니다. 이때 Bid 거래를 사용하면 기관의 실제 응답이 도착한 이후 업무 후처리 결과를 단말 또는 MCI에 능동적으로 전달할 수 있습니다.
Bid 거래를 설계할 때는 중복 통지, 단말 미접속, MCI 장애, Push 실패, 재시도 정책 등을 고려해야 합니다. 또한 Bid 메시지가 어떤 업무 결과를 의미하는지 식별할 수 있도록 GlobalID, 업무 결과 ID, 사용자 식별 정보, 결과 코드 등을 함께 관리해야 합니다.
마무리
DevOn 연계 기능은 다양한 기관 연계 환경에서 안정성과 성능을 고려한 연계 아키텍처를 설계하기 위한 공통 기반을 제공합니다. 업무 서비스는 DevOn 연계 모듈을 통해 기관별 전문 형식과 통신 방식을 직접 처리하지 않고, 표준화된 방식으로 연계 거래를 요청할 수 있습니다.
전문 변환은 기관별 전문 차이를 흡수하고, 거래 로그는 요청부터 응답까지의 흐름을 추적할 수 있도록 합니다. Load Balancer는 연계 부하를 분산하고 가용성을 높이며, Adaptor는 다양한 외부 통신 방식을 공통 구조로 처리합니다. Timer는 비동기 거래에서 실제 응답 지연 여부를 감지하고 Timeout을 발생시켜 비동기 거래가 무기한 대기 상태로 남지 않도록 관리합니다.
연계 거래 패턴 측면에서는 즉시 결과가 필요한 업무에는 동기 거래를 적용하고, 실제 응답을 기다리지 않아도 되는 업무나 기관 응답이 역방향 거래로 전달되는 업무에는 비동기 거래를 적용할 수 있습니다. 비동기 거래 중 Async는 실제 응답을 별도 Request 방식으로 수신하는 구조이고, Deferred는 요청 후 실제 응답이 없는 구조이며, Immediate는 비동기 요청 시점에 즉시 외부 시스템으로 송신하는 구조입니다. 또한 Bid 거래를 통해 비동기 처리 결과를 단말 또는 MCI로 능동적으로 전달할 수 있습니다.
결과적으로 DevOn 연계 모듈은 기관별 연계 복잡성을 공통 기능으로 분리하고, 거래 유형별 처리 패턴을 표준화함으로써 안정적이고 확장 가능한 연계 아키텍처를 구현할 수 있도록 지원합니다.
※ 본 게시글의 이미지는 AI를 활용해 제작되었습니다.