누구를 위한 개발인지?
구매사의 요청
당사에서 상품을 구매하는 건설사들은 자신들의 구매 정보 및 차량관제의 정보를 제공받고자 했습니다.
그러나 당사의 보안상 문제로 출하&관제 시스템은 사내에서만 사용할 수 있어 외부에 공개를 할 수 없었으므로, 해당 정보 제공 기능을 갖고 있는 A사의 웹&모바일 시스템을 이용하기로 결정하였습니다.
왜 개발하게 되었는지?
기존: 배치 시스템 관리
기존 출하&관제 배치 시스템의 경우 외부 업체를 통해 관리되고 있었습니다.
그러나 기존 출하&관제 배치 시스템은 DB to DB 방식을 사용하여 비용 발생이 되지 않지만, A사의 웹&모바일 시스템의 경우 RestAPI를 이용한 전달과 데이터 전달의 순서를 통해서 실시간 정보를 제공받는 방식이기에 기존 시스템과 비교하여 비용이 증가한다는 문제점이 있습니다.
비용 절감을 위한 자체 개발을 고려
기존 출하&관제 시스템과 A사의 웹&모바일 연동과정에서 비용이 발생한다는 문제점을 해결해야 했고, 두 시스템 간 연동을 위한 개발 기간이 정해지지 않아 시간적 여유가 있는 상황이었기에 당사는 외주가 아닌 자체 개발을 선택하였습니다.
요구사항은 무엇인지?
회의: 요구사항 파악을 통한 가능성 확인
A사의 웹&모바일 시스템의 정보 연동 방법으로 실시간 데이터 전달을 고려했지만, 배치 서버 자원의 한계와 기존 출하&관제 배치 시스템이 30초 간격으로 데이터를 전송한다는 것을 토대로 30초 간격으로 정보를 전달하는 배치 시스템을 만드는 것이 좋겠다고 판단되었습니다.
이후 배치 시스템을 통한 데이터 전달 방법과 출하&관제 배치 시스템 이외에 입력은 어디서 이루어지는지 확인이 필요했습니다. 그래서 책임님과의 회의를 통해 다음의 3가지를 정리했습니다.
1. 출하 & 관제 데이터 흐름 정리
2. RestAPI 테스트를 통한 연동 데이터간의 차이 파악
3. 데이터 입력 흐름 정리
1. 출하 & 관제 데이터 흐름 정리
전달할 데이터 흐름은 당사와 A사 시스템의 테이블을 기준으로 간략히 정리하였습니다.
사업소의 영업 사원들과 건설사들의 협의를 통해 주문을 넣습니다.
당일이 되어 주문이 확정되면 송장 발행 및 상품 상세 정보를 등록하고, 상품을 전달할 기사님을 배정합니다.
기사님을 배정한 뒤 해당 차량을 관제하고, 배정 받은 차량이 현장을 도착하면 모든 업무가 완료됩니다.
로그인 대상은 영업사원, 건설사 담당자, 차량 기사님들이며, 영업 사원과 건설사 담당자의 경우 협의를 본 대상들만 제공된 정보를 확인할 수 있습니다.
이 데이터 흐름에서 가장 중요한 점은 주문 > 송장 > 위치 관제 > 상품 상세 정보 순서대로 정보가 전달되어야 한다는 것입니다.
A사 시스템의 경우 전달 받은 정보를 시각화시키는 프로그램이기에 만약 없는 주문에 대해 송장 정보만 있다면 프로그램 사용자는 주문 없이 송장 정보만을 확인하는 모순이 생기기에 정보 순서가 매우 중요했습니다.
그렇지만 건설사, 상품 등과 같은 기초 테이블의 정보는 업무 시작전과 후 정보 입력/수정이 발생하기에 동시에 데이터를 전달해도 문제가 되는 부분은 없었습니다.
2. RestAPI 테스트를 통한 연동 테이블간 차이 파악
IP 등록과 토큰 발급 후, postman을 통해 A사에 전달할 정보를 테스트하였습니다.
테스트를 진행하며 연동되는 테이블과 데이터간의 차이가 발생하여 해당 내용을 정리하였습니다.
1. 주문 관리 차이
당사의 경우 다음날 현장으로 향할 주문을 예정하고, 확정되면 송장을 만드는 방식이었습니다. 그러다 보니 주문이 있다해도 확정되지 않은 주문은 송장이 없을 수도 있었습니다.
이에 당사의 주문 흐름대로 A사에 정보 전달가능한지 확인했고, 결과적으로 문제가 없을 것이라 판단하였습니다.
또한 당사는 하나의 주문으로 관리하지만 A사의 경우 주문과 주문 상태를 구분하여 관리하였습니다. 이러다보니 원본 테이블만으로는 정보 전달의 한계가 있었습니다.
이외에도 기본키(=PK)에 대한 차이가 있는데 이는 아래에 자세하게 다루었습니다.
2. 송장 관리 차이
당사의 경우 상품 상세를 콜론(:)으로 구분하여 데이터를 저장했습니다.
하지만 A사의 경우 상품 상세 컬럼들이 나뉘어져있어 데이터 전달시 구분이 필요해 보였습니다.
이외에 모든 것을 다룰 순 없지만, 테이블 구성과 정보 관리의 차이가 생기다 보니 원본 테이블만으로 A사 시스템에 전달이 어려울 것이라 판단했고, 결국 모든 테이블에 대해 A사로 전달할 Interface 테이블을 만들어 정보를 연동하자는 결론이 났습니다.
주문 기본키(=PK)에 대한 차이
위의 주문 관리 차이에서 기본키 차이에 대한 내용을 자세히 풀어봤습니다.
주문 테이블간 기본키(PK) 차이
먼저 당사의 경우 1개의 주문에 여러 상품이 들어갈 수 있습니다.
그러나 A사 시스템은 같은 현장일지라도 1개의 주문에 1개의 상품만 보내고 있습니다.
위와 같은 기본키(=PK) 차이로 인해, A사로 전달할 주문키를 주문일+주문코드+상품으로 전달할지 아니면 주문일+주문코드+상품에 대한 대리키를 만들어 전달할지에 대한 문제가 있었습니다.
문제를 해결하기 위해 책임님과 이야기를 나누었고, 책임님께서는 만약 주문 코드가 비지니스적 의미를 가진다면 그것은 주문일+주문코드+상품를 하나의 주문키로 전달하지만, 만일 단순한 주문 구분일 경우 주문일+주문코드+상품에 대한 대리키를 전달하는 것이 좋다는 의견을 주셨습니다.
그래서 해당 내용을 토대로 A사 담당자와 연락을 통해 주문 코드의 의미를 확인했고, A사 담당자는 단순한 주문 구분을 위해 사용한다고 전달해주었습니다.
이렇게 인터페이스의 대리키를 A사의 주문 코드로 전달하는 것으로 결정하였습니다.
3. 데이터 입력 흐름 정리
모든 차이점을 파악한 뒤 시스템의 입력 출발지가 배치 시스템 이외에 다른 시스템이 있는지를 확인해보았습니다.
확인 결과 배치 외에 웹 시스템에서 정보를 전달하는 부분이 있다는 것을 확인했습니다.
그래서 출발지부터 도착지까지의 정보 흐름을 정리하고, 각 과정에서의 실패 처리는 어떻게 할 것인지 정리했습니다.
1) 원본 시스템 → 로그 저장 → I/F 테이블 입력
처음 원본 시스템에서 데이터를 입력할 때 I/F 테이블에 저장할 데이터를 입력합니다.
그러나 I/F 테이블에 제대로 저장되지 않은 데이터는 오류 로그 테이블로 관리하였습니다.
여기서 아쉬운 점은 오류 로그 테이블로 오류 내역을 확인할 수 있었지만 오류가 발생할 경우 곧바로 확인할 수 없다는 한계가 있었습니다.
그래서 운영 초반에는 하루에 한번씩 오류 로그를 확인하고, 이후 오류에 대한 즉각적인 조치를 고려해보자는 의견이 나왔습니다.
2) I/F 연동 시스템 → I/F 테이블 조회 후 전송 → 로그 저장 → A사 시스템
I/F 테이블의 데이터를 조회합니다.
조회한 데이터를 A사 시스템으로 전달하면 API 전송 결과를 반환하게 됩니다.
API 전송 결과는 전송한 I/F 테이블의 행에 전송 결과를 입력하도록 만들었습니다.
그러나 데이터 흐름대로 테스트를 진행하며 A사 시스템으로 실시간 정보 전송을 하지 않고, 30초 간격 배치로 정보를 전송하다 보니 순서대로 정보가 입력되지 못하는 문제가 있었습니다.
문제에 대한 이해를 돕기 위해 정상적으로 데이터를 넣었을 때의 흐름을 먼저 정리해보았습니다.
1. 원본 시스템에서 주문으로 I/F 주문에 데이터를 입력합니다.
2. I/F 연동 시스템에서 I/F 주문 정보를 A사 시스템으로 전송합니다.
3. 모든 작업을 완료하면 다음 작업을 시작합니다.
4-6. 1-3번 과정을 반복합니다.
여기서 4번 과정은 2번, 3번 순서에서 입력될 수도 있지만 문제가 없습니다.
그러나 문제는 다음의 상황에서 발생하게 됩니다.
1. 원본 시스템에서 주문으로 I/F 주문에 데이터를 입력합니다.
2. I/F 연동 시스템에서 I/F 주문 정보를 A사 시스템으로 전송합니다.
3. 모든 작업을 완료하면 다음 작업을 시작합니다.
4. 원본 시스템에서 주문으로 I/F 주문에 데이터를 입력합니다.
5-7. 1-3번 과정을 반복합니다.
문제는 1-3번까지 모든 주문 처리를 완료한 후 한번 더 주문이 들어간다면 6번의 I/F 연동 시스템에서 I/F 송장 정보 전송시 2번 과정에서 전송되지 못한 주문에 대한 송장건은 처리되지 못합니다.
그래서 다음과 같은 방법을 도입해 문제를 해결하고자 했습니다.
1번째 배치
모든 주문 완료 후 한번 더 I/F 주문 정보가 입력됐을 경우 A사 시스템으로 송장 전송시 I/F 송장 테이블에 실패한 송장에 대한 실패 카운트를 +1 합니다.
2번째 배치
현재 I/F 주문 정보 + 이전 I/F 주문 정보를 함께 A사 시스템으로 전달 뒤 주문을 완료합니다.
그리고 송장 처리 과정에서 현재 I/F 주문 정보에 해당하는 송장 정보 + 이전 실패한 I/F 주문 정보에 해당하는 송장 정보를 A사로 전송하고 실패 카운트를 0으로 업데이트합니다.
만약 또 다시 I/F 주문 정보 전송을 못했을 경우 실패 카운트를 +1 하고, 최대 3번 실패한 데이터를 전송하고도 문제가 있다면 오류 로그를 남기고 다음 작업을 진행합니다.
추가적으로 책임님께선 일시적으로 발생할 수 있는 네트워크 오류나 데이터베이스 오류에 대해선 최대 3번의 재시도를 진행할 것을 알려주었습니다.
개발 기간 산출
모든 정리를 마친 후 개발 가능성을 따져보았을 때, 가능하다..! 라는 결론이 났습니다.
이후 얼마 만큼의 개발 기간이 필요할 것인가에 대한 고민을 했습니다.
총 테이블은 10개 정도로 테이블당 등록/수정/삭제 API가 있었습니다.
그래서 10개의 테이블에 평균적으로 API 기능 구현 및 테스트를 1.5일을 잡아서 45 영업일 정도의 시간이 걸릴 것으로 판단했고, 아키텍처 구성은 10영업일이 소요될 것으로 예상했습니다.
이렇게 요구 사항 파악 기간 0.5(M) + 개발 기간 2.5(M)을 더해 총 3(M)의 개발 기간을 산출했습니다.
'Project&기능개선 > 출하 정보 연동 프로젝트' 카테고리의 다른 글
| [출하 정보 연동 프로젝트] Listener 연결시 TIME_WAIT 발생 (2) | 2025.04.24 |
|---|---|
| [출하 정보 연동 프로젝트] Keyset Pagination을 통한 조회 기능 구현 (0) | 2025.04.22 |
| [출하 정보 연동 프로젝트] Redis Stream을 도입하기까지 (0) | 2025.04.21 |
