출제기준 세세항목: 내외부 송수신 · 데이터 명세화 · 오류 처리방안 명세화 · 인터페이스 설계 · 미들웨어 솔루션
대상 식별에서 '누가 누구에게 무엇을 보낸다'까지 정했다면, 상세 설계에서는 그 약속을 실제로 만들 수 있을 만큼 구체적으로 적습니다. 택배로 치면 보내는 사람과 받는 사람을 정한 뒤, 어떤 상자에 어떤 순서로 담고, 언제 어떤 방법으로 보내며, 배송이 실패하면 어떻게 할지까지 정하는 단계입니다.
이 항목의 세세항목이 그대로 상세 설계의 내용입니다. 어떤 방식으로 주고받을지(내외부 송수신), 데이터를 어떤 모양으로 담을지(데이터 명세화), 문제가 생기면 어떻게 할지(오류 처리방안 명세화), 이것들을 어떤 문서와 구현 방식으로 묶을지(인터페이스 설계), 그리고 이 연결을 무엇이 받쳐 줄지(미들웨어 솔루션)를 차례로 보겠습니다.
송수신 방식은 몇 가지 기준으로 나눠 정합니다. 첫째는 시점입니다. 실시간(온라인) 방식은 일이 생길 때마다 바로 보내고, 배치(일괄) 방식은 일정 시간 동안 모아 두었다가 정해진 시각에 한꺼번에 보냅니다. 결제 승인처럼 바로 결과가 필요하면 실시간, 하루 매출 집계처럼 늦어도 되는 대량 데이터는 배치가 어울립니다.
둘째는 응답을 기다리는지입니다. 동기 방식은 요청을 보낸 뒤 응답이 올 때까지 기다렸다가 다음 일을 합니다. 비동기 방식은 요청을 보내 놓고 기다리지 않고 다른 일을 하다가, 응답이 오면 그때 처리합니다. 동기는 흐름이 단순하지만 상대가 느리면 함께 멈추고, 비동기는 효율적이지만 처리 흐름을 관리하기가 더 복잡합니다.
셋째는 방향입니다. 한쪽이 보내기만 하는 단방향과, 요청하고 응답을 받는 양방향이 있습니다. 이 밖에 소켓, HTTP, 파일 전송 등 어떤 통신 수단을 쓸지, 몇 분 또는 하루에 몇 번 보낼지(주기), 무엇이 전송을 시작시키는지(사용자 요청, 정해진 시각, 데이터 변경 등)도 함께 정합니다. 내부 인터페이스는 우리 쪽 사정에 맞춰 고르면 되지만, 외부 인터페이스는 상대 시스템이 지원하는 방식에 맞춰야 하는 경우가 많습니다.
데이터 명세화는 주고받을 데이터를 항목 단위로 정확히 정의하는 일입니다. 항목마다 이름, 자료형(문자, 숫자, 날짜), 길이, 반드시 있어야 하는지(필수 여부), 허용되는 값의 범위나 코드값, 그리고 송신 쪽 항목이 수신 쪽 어느 항목에 들어가는지(매핑)를 적습니다. 여기서 한 글자라도 어긋나면 연결이 깨지므로 가장 꼼꼼해야 하는 부분입니다.
주고받는 한 덩어리의 메시지를 흔히 전문이라고 부르며, 보통 세 부분으로 나눠 구성합니다. 공통부(헤더)에는 인터페이스 ID, 송신·수신 시스템, 전송 일시, 일련번호처럼 모든 메시지에 공통으로 들어가는 정보가, 개별부(바디)에는 실제 업무 데이터가, 종료부(트레일러)에는 메시지의 끝을 알리는 표시나 건수 같은 확인 정보가 들어갑니다.
데이터를 어떤 문법으로 표현할지도 정합니다. JSON은 '이름: 값' 쌍을 중괄호로 묶어 표현하는 가벼운 텍스트 형식으로, 자바스크립트의 객체 표기법에서 출발했고 웹에서 가장 널리 쓰입니다. XML은 시작 태그와 끝 태그로 데이터를 감싸 구조를 표현하며, 사용자가 태그를 직접 정의할 수 있는 확장 가능한 마크업 언어입니다. 구조가 엄격해 검증에 유리하지만 JSON보다 길어집니다. YAML은 들여쓰기로 구조를 나타내 사람이 읽기 쉬워 설정 파일에 많이 쓰이고, CSV는 값을 쉼표로 구분해 표 형태 데이터를 간단히 담습니다.
인터페이스는 혼자 동작하지 않으니 실패할 지점도 많습니다. 네트워크가 끊길 수도, 상대 시스템이 점검 중일 수도, 데이터 형식이 어긋날 수도 있습니다. 그래서 오류가 났을 때의 대처를 미리 정해 문서에 적어 두는데, 이것이 오류 처리방안 명세화입니다.
먼저 오류를 유형별로 나눕니다. 연결 실패나 응답 시간 초과 같은 통신 오류, 필수 항목 누락이나 길이·형식 불일치 같은 데이터 오류, 존재하지 않는 회원 번호처럼 형식은 맞지만 업무 규칙에 어긋나는 업무 오류, 수신 쪽 데이터베이스 장애 같은 시스템 오류 등입니다. 그리고 유형마다 오류 코드와 오류 메시지를 정해, 양쪽이 같은 코드를 보고 같은 원인을 떠올릴 수 있게 합니다.
다음으로 오류별 처리 방법을 정합니다. 몇 번까지, 어떤 간격으로 다시 보낼지(재전송), 일부만 반영된 데이터를 어떻게 되돌릴지(롤백), 담당자에게 어떻게 알릴지(알림), 무엇을 기록할지(오류 로그)입니다. 오류 내용을 송수신 기록과 함께 남겨 두면 원인을 찾고 나중에 다시 처리하기가 쉬워집니다. 오류 처리를 정해 두지 않으면, 데이터가 조용히 사라지고 한참 뒤에야 알게 되는 일이 생깁니다.
앞에서 정한 송수신 방식, 데이터 명세, 오류 처리를 인터페이스 하나하나에 대해 문서로 묶은 것이 인터페이스 정의서(또는 인터페이스 명세서)입니다. 인터페이스 ID, 송수신 시스템, 송수신 방식과 주기, 데이터 항목과 매핑, 오류 코드와 처리 방법 등이 담깁니다. 개발자와 상대 시스템 담당자는 이 문서를 기준으로 구현하고 테스트합니다.
구현 방식도 이 단계에서 정합니다. 대표적인 두 가지가 있습니다. 데이터 통신을 이용한 방식은 애플리케이션이 네트워크로 데이터를 직접 주고받는 방식으로, 웹에서는 AJAX(페이지 전체를 새로 고치지 않고 비동기로 서버와 데이터를 주고받는 기술)로 JSON이나 XML 데이터를 보내고 받는 경우가 많습니다. 인터페이스 엔티티를 이용한 방식은 송신 쪽과 수신 쪽 사이에 인터페이스 전용 테이블(연계 테이블)을 두고, 송신 쪽이 그 테이블에 데이터를 쓰면 수신 쪽이 읽어 가 처리하는 방식입니다. 송신 테이블과 수신 테이블을 따로 두고 처리 상태를 함께 기록하기도 합니다.
설계할 때는 보안도 함께 챙깁니다. 주고받는 경로를 암호화할지, 데이터 자체를 암호화할지, 상대가 정말 약속한 시스템인지 어떻게 확인(인증)할지를 정해 두어야 합니다.
미들웨어는 운영체제와 애플리케이션 사이, 또는 서로 다른 시스템 사이에서 통신과 데이터 교환을 대신 맡아 주는 소프트웨어입니다. 덕분에 애플리케이션은 상대가 어떤 환경인지 자세히 몰라도 정해진 방법으로 연결할 수 있습니다. 시험에는 종류의 이름과 특징이 자주 나옵니다.
DB 미들웨어는 애플리케이션과 데이터베이스를 이어 주어, 데이터베이스 종류가 달라도 같은 방식으로 접근하게 돕습니다(ODBC 등). RPC(원격 프로시저 호출)는 다른 컴퓨터에 있는 함수를 마치 내 프로그램 안의 함수처럼 불러 쓰게 해 줍니다. MOM(메시지 지향 미들웨어)은 메시지를 큐에 넣어 두고 상대가 가져가게 하는 비동기 방식으로, 즉시 응답이 필요 없고 상대가 잠시 멈춰도 메시지를 잃지 않아야 할 때 알맞습니다. TP-Monitor(트랜잭션 처리 모니터)는 은행이나 항공 예약처럼 많은 사용자의 트랜잭션을 빠르고 안정적으로 처리하도록 감시하고 관리합니다. ORB(객체 요청 브로커)는 네트워크에 흩어진 객체들이 서로를 호출하게 중개하며, 표준으로 CORBA가 있습니다. WAS(웹 애플리케이션 서버)는 사용자 요청에 따라 그때그때 결과를 만들어 내는 동적 웹 콘텐츠를 처리합니다.
여러 시스템을 묶는 솔루션으로는 EAI가 있습니다. EAI는 기업 안의 여러 애플리케이션을 연결해 데이터와 업무를 통합하는 솔루션이며, 연결 구조에 따라 네 유형으로 나뉩니다. Point-to-Point는 시스템끼리 1:1로 직접 잇는 가장 단순한 방식으로, 연결이 늘면 선이 거미줄처럼 많아지고 재사용이 어렵습니다. Hub & Spoke는 가운데 허브를 두고 모든 시스템이 허브를 거치게 해 관리가 쉽지만, 허브가 멈추면 전체가 멈춥니다. Message Bus는 시스템들 사이에 공용 통로(버스) 역할의 미들웨어를 두어 확장성이 좋고 대용량 처리에 유리합니다. Hybrid는 그룹 안에서는 Hub & Spoke를, 그룹 사이에서는 Message Bus를 쓰는 혼합 방식입니다.
ESB(엔터프라이즈 서비스 버스)는 버스를 중심으로 표준 기반의 서비스들을 연결하는 방식입니다. EAI가 애플리케이션을 통합하는 데 초점을 둔다면, ESB는 기능을 서비스 단위로 나눠 연결하는 서비스 지향 아키텍처(SOA)에 초점을 둡니다. 애플리케이션 사이의 결합도를 약하게(느슨하게) 유지해, 한 서비스를 바꿔도 다른 서비스가 덜 흔들리게 하는 것이 장점입니다.
쇼핑몰과 물류 시스템을 연결하면서, 주문 접수는 바로 출고 준비를 해야 하므로 실시간·비동기 방식으로 메시지 큐(MOM)에 넣도록 설계했습니다. 반면 하루 출고 실적 집계는 밤 12시에 한 번 배치로 파일을 보내도록 했습니다. 같은 두 시스템 사이라도 데이터 성격에 따라 송수신 방식을 다르게 정한 예입니다.
회원 번호 1024, 이름 홍길동을 JSON으로 쓰면 {"id": 1024, "name": "홍길동"}처럼 이름과 값의 쌍으로 짧게 표현됩니다. XML로 쓰면 <member><id>1024</id><name>홍길동</name></member>처럼 각 값을 시작 태그와 끝 태그로 감싸므로 조금 더 길어지지만, 구조를 엄격하게 검증하기에 좋습니다.
급여 시스템으로 근태 데이터를 보내는 인터페이스에서, 연결 실패 시 5분 간격으로 3번까지 다시 보내고, 그래도 실패하면 오류 코드와 함께 로그 테이블에 기록한 뒤 담당자에게 알림을 보내도록 명세했습니다. 상대 서버 점검으로 전송이 실패했던 날에도 로그를 보고 빠짐없이 다시 처리할 수 있었습니다.