출제기준 세세항목: 시스템 아키텍처 · 인터페이스 시스템
인터페이스 요구사항을 모았다면, 이제 실제로 어떤 시스템과 어떤 시스템이 연결되는지 하나씩 짚어 낼 차례입니다. 이 작업을 인터페이스 대상 식별이라고 합니다. 이사할 때 짐을 싸기 전에 어느 방의 어떤 물건을 새집의 어느 방으로 옮길지 목록부터 만드는 것과 비슷합니다.
대상이 빠지면 개발 막바지에 '이 데이터는 어디서 받아 오죠?' 같은 질문이 터져 나옵니다. 반대로 대상을 처음에 꼼꼼히 찾아 두면, 이후 상세 설계와 구현, 테스트의 범위가 분명해집니다.
대상을 찾으려면 두 가지를 알아야 합니다. 하나는 시스템 전체가 어떤 모양인지(시스템 아키텍처), 다른 하나는 데이터를 실제로 주고받는 구성이 어떻게 되어 있는지(인터페이스 시스템)입니다.
시스템 아키텍처는 시스템을 이루는 구성 요소들과 그들 사이의 연결 관계를 큰 그림으로 나타낸 것입니다. 어떤 서버가 있고, 각 서버에서 어떤 애플리케이션이 돌며, 데이터베이스는 어디에 있고, 네트워크는 어떻게 이어져 있는지가 담깁니다. 이 내용을 그림으로 그린 것을 시스템 구성도라고 부르기도 합니다.
아키텍처를 볼 때는 경계에 주목합니다. 우리 시스템의 경계 안쪽에서 일어나는 연결은 내부 인터페이스, 경계를 넘어 바깥과 이어지는 연결은 외부 인터페이스가 됩니다. 사내 다른 부서의 시스템, 협력사 시스템, 공공기관 시스템처럼 경계 바깥의 상대를 하나씩 표시해 두면 빠뜨리는 일이 줄어듭니다.
아키텍처에서 또 하나 확인할 것은 각 시스템의 기술 환경입니다. 운영체제, 데이터베이스 종류, 사용하는 통신 방식, 방화벽 같은 네트워크 제약에 따라 쓸 수 있는 연계 방법이 달라지기 때문입니다. 예를 들어 상대 데이터베이스에 직접 접속할 수 없는 환경이라면 파일이나 API로 주고받는 방법을 찾아야 합니다.
데이터를 주고받는 구성을 인터페이스 시스템이라고 하며, 보통 세 부분으로 나눠 봅니다.
송신 시스템은 데이터를 보내는 쪽입니다. 자기 데이터베이스에서 보낼 데이터를 꺼내, 약속한 형식으로 바꾼 뒤 내보냅니다. 송신용 데이터를 따로 모아 두는 연계 테이블이나 파일을 두기도 합니다.
수신 시스템은 데이터를 받는 쪽입니다. 받은 데이터를 자기 형식에 맞게 바꾸고, 올바른지 확인한 다음 자기 데이터베이스에 반영합니다. 받은 데이터를 바로 업무 테이블에 넣지 않고 수신용 연계 테이블에 먼저 받아 두었다가 처리하기도 합니다.
중계 서버는 송신과 수신 사이에서 데이터를 받아 전달하는 역할을 합니다. 단순히 건네주는 것뿐 아니라 형식 변환, 전송 기록 남기기, 실패 시 재전송, 송수신 상태 감시 같은 일을 맡기도 합니다. 연결되는 시스템이 많아질수록 중계 서버가 있어야 관리가 쉬워집니다. 모든 인터페이스에 중계 서버가 있는 것은 아니며, 두 시스템이 직접 연결되는 경우도 있습니다.
송신·수신 시스템을 찾았다면 이름만 적고 넘어가지 않습니다. 나중에 실제로 연결하려면 그 시스템에 대해 알아야 할 것이 많기 때문입니다. 대표적으로 시스템 이름과 담당 조직·담당자, 서버가 있는 위치와 네트워크 정보, 운영체제와 데이터베이스 종류, 이미 사용 중인 연계 솔루션이 있는지 등을 함께 조사해 둡니다.
또 그 시스템이 데이터를 어떻게 다루는지도 확인합니다. 보낼 데이터가 어느 테이블에서 언제 만들어지는지, 받은 데이터를 어떤 업무 처리에 쓰는지, 하루에 몇 건 정도가 오가는지 같은 정보입니다. 데이터 양이 많다면 한꺼번에 모아 보내는 방식이, 건수는 적지만 바로 반영되어야 한다면 그때그때 보내는 방식이 어울릴 가능성이 높습니다. 이런 판단은 상세 설계에서 내리지만, 근거가 되는 정보는 이 단계에서 모아 두어야 합니다.
외부 시스템이라면 운영 시간과 점검 일정, 상대가 허용하는 접속 방법, 보안 정책도 중요합니다. 상대가 새벽에 정기 점검을 한다면 그 시간에는 데이터를 보낼 수 없으므로, 처음부터 이를 고려해야 나중에 일정이 꼬이지 않습니다.
대상 식별은 대략 다음 순서로 진행합니다. 먼저 시스템 아키텍처를 분석해 연결 지점을 찾습니다. 다음으로 각 연결에서 어느 쪽이 보내고 어느 쪽이 받는지 송신 시스템과 수신 시스템을 정합니다. 그런 다음 무엇을 주고받는지, 즉 송수신 데이터를 찾습니다.
송수신 데이터를 식별할 때는 데이터를 성격별로 나눠 보면 편합니다. 한 건 한 건의 거래나 업무 처리 결과처럼 계속 쌓이는 업무 데이터, 상품 목록이나 지점 정보처럼 기준이 되는 데이터, 상태 코드처럼 양쪽이 같은 뜻으로 써야 하는 코드 데이터 등이 있습니다. 특히 코드 데이터는 양쪽의 코드 체계가 다르면 서로 맞춰 주는 대응표(코드 매핑)가 필요해집니다.
이렇게 찾은 결과를 인터페이스 목록으로 정리합니다. 인터페이스마다 고유 번호(인터페이스 ID)를 붙이고, 이름, 송신 시스템, 수신 시스템, 주요 데이터, 대략의 주기와 방식을 적습니다. 이 목록이 다음 단계인 상세 설계의 출발점이 되며, 상세 설계에서 항목 하나하나를 인터페이스 정의서로 구체화합니다.
대상을 찾았다면 둘을 어떤 방식으로 이을지도 큰 틀에서 정해 둡니다. 연계 방식은 두 시스템이 바로 맞닿는 직접 연계와, 중간에 다른 장치를 두는 간접 연계로 나뉩니다.
직접 연계는 중계 없이 송신과 수신이 바로 연결되는 방식입니다. 상대 데이터베이스에 바로 접근하는 DB Link, 미리 만들어 둔 데이터베이스 연결을 재사용하는 DB Connection(Pool), 자바 프로그램에서 데이터베이스에 접속하는 JDBC, 상대가 공개한 기능을 호출하는 API/Open API, 상대 화면으로 바로 이동시키는 화면 링크 등이 있습니다. 구조가 단순하고 빠르게 만들 수 있지만, 두 시스템이 서로를 자세히 알아야 하므로 결합도가 높아지고, 연결이 늘어날수록 관리가 복잡해집니다.
간접 연계는 중간에 연계 솔루션을 두고 그것을 통해 주고받는 방식입니다. 여러 애플리케이션을 통합하는 EAI, 서비스 중심으로 연결하는 ESB, 표준 프로토콜로 서비스를 주고받는 웹 서비스 등이 대표적이며, 자료에 따라 소켓(Socket) 통신을 간접 연계로 분류하기도 합니다. 중간 솔루션이 변환과 관리를 맡아 주므로 시스템끼리의 결합도가 낮아지고 여러 시스템을 다루기 좋지만, 솔루션을 갖추고 운영하는 부담이 생깁니다. EAI와 ESB의 자세한 구조는 인터페이스 상세 설계의 미들웨어 솔루션에서 다룹니다.
대학교 학사 시스템을 새로 만들면서 아키텍처를 그려 보니, 경계 바깥에 도서관 시스템, 등록금을 받는 은행, 교육부 보고 시스템이 있었습니다. 학생 정보는 학사 시스템이 송신하고 도서관이 수신, 등록금 납부 결과는 은행이 송신하고 학사 시스템이 수신하는 식으로 방향을 정하고, 각각에 인터페이스 ID를 붙여 목록을 만들었습니다.
인사 시스템은 재직 상태를 'A, L, R'로, 급여 시스템은 '01, 02, 03'으로 관리하고 있었습니다. 송수신 데이터를 식별하는 단계에서 이 차이를 발견해 대응표를 만들었고, 중계 서버가 전달하면서 코드를 바꿔 주도록 했습니다.