개요

1.1. 주제 정의

“디지털 포워딩 기업 매칭 플랫폼”이라는 주제로 국제 물류 시장에서 포워딩 기업과 수출 기업이 활용할 수 있는 서비스를 개발하고자 하였다. 포워딩 기업과 수출 기업 사이의 쉽고 간편한 견적 요청 및 입찰 환경을 구축하는 서비스이다.

1.2. 배경

수출 기업이 화물을 수출하기 위해선 선사, 관세사, 운송사 등을 통해 복잡한 절차를 거쳐야 한다. 포워딩 기업은 이러한 일들을 일괄적으로 대행해주는 역할을 한다. 따라서 수출 기업은 포워딩 기업을 통해 수출 업무를 편리하게 처리할 수 있다. 디지털 포워딩으로의 전환이 빠르게 이루어지고 있는 국제 물류 시장과는 달리 국내 포워딩 업계는 디지털 포워딩 도입에 더딘 모습을 보이고 있다. 그 원인으로는 기존 포워딩 업체들이 원래 갖고 있던 시스템을 디지털화 하는 데에 어려움을 겪고 있다는 점과 보수적인 국내 시장의 분위기, 국내 해운업계의 API 개발이 막 시작하는 단계라는 점이 지목된다. 현재 국내에 수출기업과 포워더를 매칭해 견적을 제공하는 기능만을 집중적으로 다루는 앱 서비스는 존재하지 않는다. 또한 특정 포워딩 기업에서 서비스를 제공하기 때문에 수출기업에게는 한 플랫폼에서 여러 포워딩 기업으로부터 견적을 받아볼 수 없다는 불편함이 존재한다. 한편, 포워더는 수출하려는 화물의 통관 처리를 대행하는데, 관세사에게 보내려는 화물에 대한 정확한 품목분류코드(HSCODE)를 제시하고 통관을 허가받아야 한다. 이를 위해서 포워더는 제품과 매칭되는 HSCODE를 찾기 위해 11,000개가 넘는 HSCODE-품명정의 쌍 데이터를 탐색하는 번거로운 과정을 거친다.

1.3. 개발 동기

포워딩 기업과 수출 기업이 활용할 수 있는 디지털 플랫폼을 개발함으로써 상기한 문제점을 해결하고자 하였다. 물류 시장의 디지털 전환을 돕는 것이다. 전통적인 포워더들은 본 서비스를 사용함으로써 디지털 포워더로 전환할 수 있고, 수출 기업은 여러 포워딩 업체로부터 쉽고 빠르게 견적을 받을 수 있다. 빅데이터, AI (NLP) 기술을 활용하여 포워더가 입력하는 제품에 맞는 HSCODE를 자동으로 추천해주는 시스템을 개발하여 포워더가 통관 과정에서 겪는 어려움을 해결하고자 하였다.

1.4. 기대 및 효과

기존 포워딩 기업들이 활용할 수 있는 디지털 플랫폼을 제공함으로써 글로벌 시장에 비해 국내 시장은 디지털 포워딩 전환이 더디다는 문제의 해결을 기대한다. 또한 매칭 플랫폼을 통해 수출기업과 포워딩 기업이 서로 거래하기 까지 정보를 찾고 탐색하는 비용을 줄일 수 있다. 그리고 직관적인 모바일 앱을 통해 높은 접근성을 가지는 디지털 포워딩 서비스를 제공하며, HSCODE 추천시스템을 개발하여 포워더가 수출 업무를 편리하게 처리할 수 있도록 한다.

개발 내용

2.1. 개발 플랫폼: Android

2.2. 비기능적 요구사항

• 성능 요구사항
  • 사용자가 요청한 시간으로부터 3초 이내에 최초 결과값을 보여주도록 함.
  • 평균적으로 동시 사용자 접속 수 200명 이상 지원 및 성능이 저하되지 않아야 함.
  • 08:00~22:00 서비스 가용시간 동안 CPU 사용률은 90% 넘지 않도록 함.
• 데이터 요구사항
  • DB 설계방안: DB구조의 설계는 기능 요구사항을 반영하여 구조화하고 향후 개발 상황에 따른 확장성을 고려하여야 한다.
  • 데이터의 정합성을 유지하면서 시스템의 성능을 저하시키지 않도록 DB 설계가 이루어져야 한다.
  • 사용자는 ID로 식별한다.
  • 사용자에 대한 ID, 패스워드, 유저 타입(수출회사/포워딩회사), 회사이름, 담당자 이름, 연락처, 이메일 주소를 유지해야 한다.
  • 수출회사 사용자는 화물을 등록할 수 있다.
  • 화물은 화물 번호로 식별한다.
  • 화물에 대한 상품명, 출발지, 도착지, 예상 출발일, 예상 배송완료일, 크기, 중량, 개수 정보를 유지해야 한다.
  • 포워딩회사 사용자는 각 화물에 대한 견적을 등록할 수 있다.
  • 견적은 견적 번호로 식별하고, 작성자와 화물을 운송할 선박회사, 선박명, 운임, 출발일, 도착일 정보를 유지해야 한다.
  • AI모델 구축을 위해 HSCODE 정보가 필요하다.
• 인터페이스 요구사항
  • 언어 선택 화면: 원하는 언어 선택(4개 국어), 선택에 따라 이후 표시 언어가 달라짐
  • 로그인 화면: ID, 비밀번호 입력 / 회원가입 기능 포함
  • 회원가입 화면: ID, 패스워드, 유저 타입(수출회사/포워딩회사), 회사 이름, 담당자 이름, 연락처, 이메일 주소 입력
  • 기본 화면: 사용자 정보 표시 (각종 화물 정보, 출발 일자)
  • 화물 추가: 화물 정보 해당하는 사항 체크, 일정 선택
  • 가격 확인 및 결정 화면: 가격 표시, 일정 입력
  • 포워딩 업체 기본 화면: 견적을 등록할 화물을 표시
  • 포워딩 업체 정보 입력: 견적 정보 입력 2.3. 기능적 요구사항
• 언어 선택
  • 로그인 화면: 회원 가입 기능, 로그인 기능
  • 회원가입: 아이디, 패스워드, 회사, 연락처, 수출기업/포워딩 기업 여부(체크박스)
  • 수출기업 기본 화면: 등록한 화물의 목록, 예상 출발일자 표시, 새 화물 추가 기능
  • 화물 눌렀을 때, 입력한 정보 전부 표시
  • 수출기업 화물 추가기능
  • 출발지, 도착지, 출발일(화물 출발 항구 도착)/배송완료일(화물 도착 항구 도착 선택)
  • 원하는 견적 마감 일자
  • 모든 화물 정보
    • 요청사항: 수출 담당자가 품목의 특성을 고려해 요청사항 및 주의사항 메시지를 보내는 기능
    • 수출기업 정보 확인 및 최종 결정: 출발/도착 정보를 다시 한 번 확인하고 최종 결정하는 화면
  • 완료 화면: 완료 표시 기능, 메인 화면 복귀
    • 포워딩 기업 기본 화면: 견적서 작성
    • 견적서 작성 화면: 기업별 리스트업, 기업에서 요청한 화물 리스트업(수출기업 화면과 표시정보 동일, 견적입력 기능)
  • 견적서 화면: 달러/원화 등 여부, 출발지/해상/도착 운임, 총 가격, 해운업체, 선박이름, 출발일/도착일(수출기업 일정에 맞는지 여부 확인)
  • 설정: 로그아웃, 알림(수출기업-견적서 수신, 포워더-견적서 승인 확인), 언어설정

개발 방법

3.1. 적용 기술

개발 언어 Python, JavaScript, Java, React-native

개발 도구 Android Studio, Visual Studio Code, Django

플랫폼 Android

서버 구름IDE

3.2. 개발 과정

이름	역할
김창우	프론트엔드 개발, 사용자 인터페이스 구현
고강희	AI, HSCODE 추천시스템, 4개국어 지원 서비스 개발
정여진	백엔드 개발, DB 설계

프론트엔드 개발 과정

• Figma를 활용해 필요한 모든 화면을 정리 및 디자인

  확정된 기획을 바탕으로 일단 필요한 모든 화면부터 정리하였다. 이는 개발 범위를 명확히 하기 위함이다. 그 뒤에 공통 화면, 수출 기업 화면, 포워딩 기업 화면 순서대로 Figma를 이용해 디자인하였다. 해당 디자인은 모든 팀원과 공유함으로써 누구나 언제든 앞으로의 디자인 및 화면 구성을 확인할 수 있도록 하였다. 해당 화면들을 대략적으로 구성함으로써 기획상 누락된 부분이나 잘못 이해한 부분은 없는지 확인할 수 있었고, 입력해야 할 정보의 개수를 확정함으로써 API 구성이 차질없이 진행될 수 있도록 하였다.

• UI Prototype 제작 및 중간 확인

  Figma를 통해 대략적으로 구성한 각 화면의 유기적 연결과 작동을 최종 확인하기 위해 프로토타입을 완성하였다. 각 화면의 버튼과 이동할 대상을 정하고, 흐름에 어색함이 없는지 확인하였다. 프로토타입을 직접 작동시켜 보며 화면 크기나 동작에 무리가 없는지 등을 테스트해보았다. 본격적인 개발 과정에 앞서 최종적으로 앱의 화면이 어떻게 구성될지를 확정지었다.

• DB와 상호작용하는 주요 기능 개발 및 UI 제작

  데이터베이스와 상호작용하는 주요 기능들에 대해 본격적인 화면 구성 및 기능 개발을 진행하였다. 앱을 정상적으로 사용하기 위한 필수적인 기능으로는 로그인, 회원가입이 있고, 본 앱의 목적을 달성하는 핵심 기능으로는 화물 등록, 화물 조회, 견적 등록, 견적 조회, 견적 수락이 있다.

  먼저 모든 코드는 React Native 문법을 따라 TypeScript(tsx) 파일로 작성하였다. 모든 과정에서는 서버(클라우드)와 통신하여야 하는데, Bearer token으로 사용자 정보를 담아보내고, axios를 사용하여 GET/POST/DELETE 등 필요한 작업을 요청 및 전달하였다.

  로그인 시 토큰을 저장하여 계속 사용하기 위해 react-native-async-storage 라이브러리를, 보안을 위해 비밀번호를 암호화하여 저장하는 용도로 react-native-keychain 라이브러리를, 화면 간 이동을 위해 react-navigation 라이브러리를, 언어 번역을 위해 react-i18next 라이브러리를 사용하였다.

  개발 과정에서 오류가 발생한 대부분의 경우에는 프론트에서 서버의 응답을 잘못된 형식으로 처리하거나, 서버에서 프론트의 응답을 잘못 처리하는 경우였는데 로컬 터미널에서는 정보 획득에 제한이 있어 직접 클라우드 컨테이너의 터미널을 확인하고 이 정보를 백엔드와 공유해 문제를 해결하였다.

• 기획한 모든 기능 개발 및 UI 제작

  로그아웃, 화물 삭제 등 나머지 기능을 구현하고 UI를 다듬었다.

  일관된 UX를 전달하기 위해 같은 컴포넌트에 대해 일관된 디자인을 적용하였다.

  실제 모습을 확인하기 위해, 이 시기부터는 에뮬레이터가 아닌 실제 안드로이드 기기를 이용해 테스트를 진행하였다.

  표는 react-native-table-component 라이브러리를, 설정 등의 아이콘은 react-native-vector-icons 라이브러리를, 체크박스는 react-native-elements 라이브러리를 사용하여 보다 나은 화면을 구성하였다.

  또한 업무 상에서 메일이 여전히 널리 쓰이고 있다는 점에 착안하여 메일로 견적 등록 및 수락 알림을 보내는 것으로 기능이 변경되었는데, 그 내용과 구성도 함께 확정지었다.

• 배포 및 최종 테스트

  HSCODE 시스템을 클라우드 혹은 사용자의 환경에 즉각 구현/설치하기에는 어려운 점이 많아 배포가 이루어지지는 않았지만, 해당 시스템의 실질적인 동작을 제외한 나머지 모든 부분을 구현해 실제 모바일 기기에 설치하여 테스트를 진행하였다.

  실제 사용 과정의 시나리오를 따라 전 과정을 진행, 화면 표시에 특별한 오류나 경고 없이 진행되는 것을 확인하였다. 모든 버튼은 정상 작동하며, 의도한 대로 표시되는 것을 확인하였다.

백엔드 개발 과정

• DB 설계 및 API 명세서 작성

  프로젝트 시작 단계에서 기능을 정의하고, 요구사항에 따라 DB를 구상하였다.

  프론트엔드와 백엔드 개발을 동시 진행하기 위해 API 명세서를 작성하였다.

  URI에서 자원을 구분짓고 명명할 때, 모호성을 최소화하고 직관적으로 이해하기 쉽도록 일관된 형식을 사용하였다.

• 회원가입/로그인 기능 구현

  본 프로젝트는 API 서비스가 모바일에서 사용되기 때문에 보안을 위해 JWT 인증 방식을 사용하였다.

  API 키를 모바일 기기 내에 저장할 필요가 없기 때문에 신뢰하기 어려운 모바일 환경에서 적합하다고 생각했다.

  API 서버가 사용자 정보를 받으면 이를 검증한 후 일정 시간 동안만 유효한 액세스 토큰을 발급한다.

  회원가입을 할 때 이름, 회사명, 연락처, 이메일을 입력받고 포워더인지, 수출기업 사용자인지를 체크한다. 로그인을 할 때 액세스 토큰과 함께 사용자 유형 정보를 반환하여 포워딩기업 사용자와 수출기업 사용자가 서로 다른 메인 화면으로 리다이렉트 될 수 있도록 하였다.

• 화물과 견적 관련 기능 구현

  화물의 조회, 등록, 삭제와 견적의 조회, 등록, 수정, 수락, 삭제 기능을 구현하였다. POSTMAN을 통해 각 요청에 대해 정상적으로 응답함을 확인했다.

  django가 지원하는 django.core.email 모듈을 이용해 이메일로 알림을 전송하는 기능을 구현하였다.

  어떤 화물에 대해 견적이 등록되면 회원 정보에 저장된 화물 작성자의 이메일로 견적이 등록되었음을 알리는 메일이, 견적이 수락되면 견적 작성자의 이메일로 견적이 수락되었음을 알리는 메일이 전송되도록 하였다.

• 배포 및 프론트엔드와 백엔드 연결 및 기능 테스트

  구름IDE로 서버를 배포했다.

AI 개발 과정

AI 파트에서는 최신 AI 기술을 활용해 본 어플에 차별점을 주기위해 노력했다. HSCODE 자동 추천서비스와 최신 인공신경망 기반 번역 API를 활용한 다국어 지원 기능을 개발했다.

• HSCODE 자동 추천 서비스 개발 개요

실제로 Cello Square(첼로 스퀘어) 에서는 본 어플과 같은 디지털 포워딩 서비스를 제공하는 웹 사이트이며, 이와 동시에 최신 빅데이터, AI 기술을 적극적으로 활용해 차별점을 준 좋은 예시이다. 해당 사이트에서는 IoT 기술, 블록체인 등등 다양한 최신 기술을 적용해 포워딩 서비스를 제공한다. 하지만 챗봇을 제외하고 최신 NLP 기술을 적극적으로 활용해 편의를 주는 플랫폼은 많지 않았다. 특히 HSCODE는 무역 업무에서 관세 신고를 위해서 빠져서는 안될 부분이기도 하며, NLP 기술에서 무역 업무 편의성을 위해서 가장 활발하게 연구가 진행되고 있는 분야이기도 하다. 실제로 HS 오토팬: HS Code 조회 과 같이 NLP 기술을 활용해 HSCODE를 자동으로 조회할 수 있는 웹 서비스가 존재하기도 한다. 하지만 앞서 언급한 첼로 스퀘어, 우선로지스틱스와 같은 물류 서비스 자체 내부에서 HSCODE 조회를 바로바로 할 수 있는 웹 서비스가 많지 않을 뿐더러 앱을 통해서 직관적으로 볼 수 있는 경우도 없다. 따라서 AI 파트에서는 본 무역 어플에 NLP 기술을 적용한 HSCODE 자동 추천 서비스를 제공함으로써 다른 물류 서비스들과의 차별점을 주기 위해 노력했다.

• 최신 번역기를 활용한 다국어 지원 서비스 개발 개요

AI 파트에서는 다국어 지원 서비스도 개발했다. 실제로 글로벌한 무역 업무 특성상 다국어 지원 서비스는 거의 필수적이라고 볼 수 있으며, 실제로 다양한 물류 서비스에서는 다국어 지원 기능을 거의 기본적으로 제공해준다. 본 어플에서 역시 다국어 지원 기능을 추가했으며 DeepL API를 활용해 개발했다. DeepL 번역기는 2017년에 처음 출시되었지만, 오랫동안 한국어를 지원하지 않았기 때문에 국내에서는 잘 알려지지 않았다. 하지만 2022년 12월에 한국어 지원이 시작되었으며 DeepL Pro는 2023년 8월에 지원이 시작되었다. 기존에 있던 다양한 물류 서비스는 아직까지 다국어 지원 기능을 Google Translate를 활용해 개발했을 것으로 추정된다. 하지만 본 어플에서는 DeepL을 실험적으로 활용해 다른 어플과 차별점을 두었다. DeepL은 규칙기반 번역인 Google Translate과 달리 고급 인공 신경망을 활용해 번역하기 때문에 훨씬더 자연스러운 번역을 제공해준다. 본 어플에서는 한국어, 영어, 일본어, 중국어 총 4개국어를 지원해준다.

HSCODE 자동 추천시스템 개발 과정

HSCODE 자동 분류는 국내 NLP에서 활발하게 연구되고 있는 분야이다.

2019년 KCC에서는 “단어 임베딩을 활용한 빅데이터 기반의 지능형 HS코드 식별”을 주제로 논문이 발표된바 있다.

해당 논문에서는 HSCODE 추천 알고리즘을 제시해준다. 먼저 관세청에서 정의한 HSCODE-품명 데이터를 수집해 HS데이터 파일을 만들고 NLTK의 word_tokenizer()를 활용해 품명을 토큰화한다. 그 다음 Word2vec으로 토큰들에 대한 임베딩 vector를 추출후 Sklearn 라이브러리의 TfidfVectorizer 모듈을 활용해 각 토큰들의 벡터에서 전체 품명에 대한 벡터값으로 전환한다. 이렇게 얻어낸 품명 벡터들과 사용자 입력 상품의 벡터간의 Cosine Similarity를 계산해 상품명에 맞는 HSCODE를 추출해준다.

2019년에 발표된 논문이기 때문에 최신 언어모델이 아닌 Word2vec을 사용했지만 추천 알고리즘 자체는 괜찮아 보였고, 무엇보다도 Word2vec이 아닌 최신 언어모델인 BERT를 활용할 경우 더욱 높은 성능을 보일 수 있을 것이라 생각했다.

하지만 결과적으로 상품명을 입력받고, 해당 상품에 맞는 HSCODE를 추출한다는 과정 자체가 NLP Classification 과정이라고 생각한다면, 굳이 Cosine Similarity 계산 없이 바로 언어모델을 활용해 HSCODE를 추출할 수 있다고 생각했다. 또한 해당 방식으로 HSCODE를 추출할 경우에는 관세청에서 정의한 HSCODE-품명 쌍 데이터만 사용하기 때문에 실제 사람들이 무역과정에서 신고했던 HSOCDE 분류 사례를 고려해서 추천할 수 없다는 단점이 존재했다. 따라서 실제 품목 사례로 Fine-tuning한 BERT의 Classification으로 HSCODE를 추천하도록 구현하는 쪽으로 방향성을 잡았다. 하지만 나올 수있는 모든 HSCODE의 경우의 수는 약 11,000개 정도이기 때문에 Classification Task로 구현한다면 분류 LABEL을 무려 11,000로 설정해야 한다는 문제점이 존재한다.

HSCODE 추천을 BERT로 구현했던 관련 논문을 찾아본 결과 HCLT 2022의 “언어모델 전이학습 기반 해외 직접 구매 상품군 분류” 에서는 한번에 11,000개의 LABEL로 분류하는것이 아니라 HSCODE 앞 2자리(류)를 먼저 분류 한 후 나머지 10자리를 추론하는 계층적 방식을 제시했다. 따라서 해당 아이디어로부터 영감을 받아 BERT모델 3개를 쌓아 류, 호, 소호 순 계층적으로 분류하는 방법으로 시도해보기로 했다.

하지만 해당 방법 역시 LLM모델 3개를 쌓은 특성상 너무 많은 시간적, 공간적 자원이 필요할 것으로 예상되기 때문에 앞선 HCLT논문의 내용과 KCC논문의 방법 두개를 엮어 HSCODE 앞 두자리(류)를 BERT 분류 모델을 통해 출력하고, 해당하는 류의 품목 코드내에서 Cosine Similarity 기반 추천을 제공하도록 계획했다.

하지만 해당 방법 역시도 명확한 문제점이 존재했다. BERT를 Fine-tuning한 결과 test 데이터셋에 대한 Classification 성능이 80%를 넘지 못했다는 것이었다. 즉 5개를 입력하면 1개는 HSCODE 첫 두자리인 상품군(류)에서부터 잘못 분류하기 때문에, 나머지 코사인 유사도 기반으로 추천한 것이 비슷한 품목조차도 나오지 않을 수 있다는 것이다. 해당 방식은 품목 분류 사례를 고려해서 추천 해줄 수도 있지만 이와 동시에 BERT로 HSCODE의 앞 두자리를 확정 지어버리기 때문에 오히려 오답률이 높아질수 있다는 분석이었다. 따라서 결국 그림4의 방법이 아니라 처음으로 돌아오기로 했다.

기존 방법의 문제점은 실제 분류 사례를 고려해서 추천해줄 수 없다는 것이었다. 만약 “Smartphone”의 HSCODE를 알고 싶을 경우에 언어 모델은 “Smartphone”과 같은 대중적인 단어를 이해하고 있을 확률이 높기 때문에 HS 데이터 내에 “전자제품” 이라는 단어가 있을 경우 해당 제품에 대한 Cosine Similarity가 높게 책정될 가능성이 높다. 하지만 만약 사용자가 “samsung galaxy note”를 입력할 경우 언어모델이 “samsung galaxy note”라는 제품명 이해하지 못한다면, 해당 제품에 대한 Embedding 값을 제대로 추출하지 못하기 때문에 “전자제품”이라는 단어와 Cosine Similarity는 낮게 책정될 가능성이 높다. 하지만 만약 HS 데이터 파일 내에 실제 품목 분류 사례데이터를 추가해서 “samsung galaxy tab”이라는 품명이 추가되어 있을경우 얘기가 달라진다. “samsung galaxy note”와 “samsung galaxy tab”은 서로 다르고 두 단어 모두 언어모델이 어떤 것인지 이해할 수 없지만 단어의 형태가 비슷하기 때문에 높은 Cosine Similarity를 가질 것이다. 따라서 HS 데이터 파일을 관세청에서 각 HSCODE 마다 1:1로 정의한 품명데이터로만 구성하는 것이 아니라 실제 사례데이터도 추가해 구성한다면 실제 품목 분류 사례를 고려한 추천이 가능할 것이다.

“관세법령정보포털”에는 HSCODE와 그에따른 정의, 또 해당 HSCODE로 분류되었던 품목명 사례 데이터를 제공한다. Selenium python library를 통해 “관세법령정보포털”을 Crawling 했으며 총 51,000개의 HSCODE-품명 쌍 데이터 셋을 구축했다. 그 후 해당 데이터 셋에 있는 품목명을 Sentence-transformers에 입력해 Embedding을 추출했다. 결과적으로 약 51,000개의 HSCODE-품명-Embedding으로 연결된 데이터셋을 구축했다.

embedding 모델은 Hugging Face에서 제공된 “sentence-transformers/all-MiniLM-L6-v2” 모델을 활용했다. 해당 모델은 사전훈련된 “nreimers/MiniLM-L6-H384-uncased” 를 약 10억 개의 문장 쌍 데이터 셋에 대해 Fine-tuning해 만들어 졌다. 기존 기획에서는 BERT를 활용해 Embedding을 추출할 계획이었지만 sentence-transformers는 Cosine Similarity task에 특화된 모델이기 때문에 더욱 높은 성능을 보일 것으로 예상되었다.

Embedding 파일을 구축 했기 때문에, 그림5의 구현 알고리즘과 같이 사용자 입력에 대한 Embedding 값을 얻어내고, Embedding 파일내의 값과 Cosine Similarity를 계산해 추천을 진행했다. 추천 결과 만약 “Drone”을 입력할경우, “장난감”, “무인기”, “전동기”, “항공기”, “산업용 로봇”등을 추천해주는 것이 확인되었다. 만약 NLP 기술이 아닌 전통적인 문자열 Searching 알고리즘을 사용할경우 추천해줄 수 없는 리스트이다. 또한 “Samsung galaxy tab”을 입력할 경우 8471.30-0000이 실제 tablet pc의 HSCODE인데, 8471호로 시작되는 관련 전자제품들이 추천되는 것이 확인되었다. Embedding 파일에 실제 품목 사례데이터가 없을 때 “Samsung galaxy tab”을 입력하면 9101호의 엉뚱한 “손목 시계”를 추천해주는 데에 반해 사용자 입력과 관련성 높은 추천을 해주는 것이 확인 되었다.

입력을 하나하나 넣어보는 것만으로는 정확한 성능 분석이 어렵다. 따라서 임베딩 파일에 없는 실제 품목 분류 사례 데이터를 활용해, 그 정답률을 분석해보았다.

HSCODE 추천 시스템의 성능 평가를 진행했다. 품목 분류 사례 데이터를 사용 했으므로 해당 데이터에는 품명과 해당 제품에 대해 실제 신고되었던 HSCODE가 있다. 해당 HSCODE를 정답이라고 했을 때, 제품을 입력해서 자동 추천 시스템으로 총 10개를 추천 받고, 그 10개안에 정답이 있는 경우가 전체 Test 데이터의 82%를 차지하는 것을 확인했다. 하지만 앞선 “Samsung galaxy tab”의 입력사례를 통해 알 수 있듯이, HSCODE가 정확히 10자리 일치하지 않고 앞 4자리(호)만 일치해도 어느정도 비슷한 품목이 추천되는 것을 알 수 있다. 이를 고려했을 때 앞 4자리가 정확히 일치한 HSCODE를 추천해주는 경우가 전체 Test 데이터의 91%를 차지하는 것이 확인되었고, 이는 추천 시스템이 꽤 관련성 높은 제품을 추천 해준 다는 것을 알 수 있다.

Django를 통해 로컬환경에서 AI 서버를 구축했고, React-native를 활용해 간단한 UI틀을 구현하였다. 사용자 입력을 받으면 10개의 HSCODE가 출력되고, HSCODE를 클릭하면 해당 HSCODE에 대한 상세정보가 나온다. 해당 화면을 다른 화면들과 연결하고, 디자인적 통일성을 주는 부분은 Front-End 파트에서 전부 구현했다.

4개국어 지원 서비스 개발 과정

Front-end 파트에서는 화면에 나오는 모든 Text를 Json형태의 파일로 관리할 수 있다. 미리 여러 언어로 번역된 Json 파일을 관리해서 다국어 지원 기능을 구현하면 빠른 속도로 기능을 제공 해줄 수 있다. 따라서 AI에서는 DeepL API를 활용한 Json to Json 번역 Tool을 개발 해 여러 언어의 Json 파일을 Front-End 파트에 제공해 주었다. 번역된 Json 파일이 Front-End 파트에서 정상 동작해 다국어 지원 기능이 문제없이 제공 되는 것이 확인되었다.

주요 실행 화면

시연 동영상 : https://youtu.be/OmesGL35LIU

최종 평가

5.1. 요구사항 평가

프로젝트 시작 단계에서 정의한 요구사항을 충족하였는지를 고려해보았다. 기능적 요구사항은 크게 로그인 및 로그아웃, 화물 등록 기능, 견적 등록 및 수락 기능, 알림 전송 기능, HSCODE 추천 기능으로 모두 완벽히 구현되었다. 서버와 클라이언트의 연결도 원활히 이루어짐을 확인하였다. 인터페이스 요구사항으로서 정의한 언어 선택 화면, 로그인 화면, 회원가입 화면, 기본화면, 화물 추가, 가격 확인 및 결정 화면, 포워딩 업체 기본 화면, 포워딩 업체 정보 입력 화면을 모두 구현하였다. 앞서 첨부한 주요 실행 화면을 통해 확인할 수 있다. 데이터 요구사항을 반영하여 데이터베이스를 설계하였다. 사용자, 화물, 견적 테이블이 관리되며 클라이언트의 CRUD 요청을 수행한다. 보안 요구사항을 충족하기 위해 JWT기반 인증시스템을 통해 로그인 기능을 구현하였다. 로그인 시 액세스 토큰을 발급하고, 클라이언트가 서버에 요청을 보낼 때 액세스 토큰도 함께 전송하게 하여 인증된 클라이언트만 정보를 요청할 수 있도록 하였다. 토큰의 만료기간을 짧게 설정하여 보안성을 높였다. 프로젝트 관리 요구사항에 따라 9월 이후 매주 3회 팀 회의를 진행하였고, 파트별 진행사항을 Notion과 Github를 통해 공유하였다. 성능 요구사항과 품질 요구사항, 테스트 요구사항을 충족하는지 확인하기 위해 Apache JMeter를 통해 간단한 성능 테스트를 진행하였다. 가상의 동시접속자 200명이 화물 정보를 조회하는 상황을 가정하여 부하 테스트를 수행했다. 결과는 다음과 같이 1.1433초의 평균 응답시간으로 나타났다.

HSCODE 추천 시스템의 경우 로컬환경에서 돌려야 했기에 성능 요구사항 테스트를 따로 진행했다. 그 결과 사용자 입력부터 출력까지 1.5초 ~ 2초사이의 수행시간이 걸리는 것으로 확인되었다.

5.2. 팀원별 목표 달성도 평가

김창우(프론트엔드): 95% 기획 및 프로토타입 구성: 20%, 공통 부분 화면 개발: 20%, 수출 기업 화면 개발: 15%, 포워딩 기업 화면 개발: 10% (견적 삭제 및 수정 기능 미구현), 다른 파트와 연결: 20%, 구동 테스트 및 이상 여부 확인: 10%

정여진(백엔드): 100% DB 설계 및 API 명세서 작성, 회원가입/로그인 기능 구현, 화물 등록 기능 구현, 견적 등록 기능 구현, 프론트엔드와 백엔드 연결 및 기능 테스트, 배포 및 최종 테스트 100% 완료함

고강희(AI) 평가기준: 다국어 지원 기능 구현(20%), HSCODE 추천 시스템 개발(50%), FE 파트와 연결(20%), 테스트 및 오류 검증(10%) 목표 달성도: 20%+50%+15%+10% = 95% 다국어 지원 기능 구현(20%): 20% HSCODE 추천 시스템 개발(50%): 50% FE 파트와 연결(20%): 15% - 로컬환경에서 AI 서버 구축시 HSCODE 화면이 잘 동작하는 것을 확인했으나 goorm ide에서 gpu서버를 제공해주지 못해 원격 AI 서버를 배포해 해당 기능을 수행하지는 못했음. 테스트 및 오류 검증 (10%): 10%

5.3. 팀원별 기여도 평가

김창우(프론트엔드): 33.3%, 정여진(백엔드): 33.3%, 고강희(AI): 33.3%

결론

‘디지털 포워딩 기업 매칭 플랫폼’을 주제로 마켓 플레이스 형태의 물류 플랫폼 앱을 개발하였다. 앱을 통해 포워딩 기업과 수출 기업 사이의 간편한 견적 요청 및 입찰 환경을 구축했고 HSCODE 추천시스템을 통해 포워더의 편의를 도모하였다. 프로젝트 중간에 주제가 변경되면서 초기에 정의한 요구사항과 다소 달라진 부분이 있으나 이를 제외한 모든 요구사항을 구현했다. 본 프로젝트는 HSCODE 추천시스템을 자체적으로 개발함으로써 경쟁력을 확보하였다. 또한 성장하고 있는 디지털 포워딩 시장의 규모를 고려했을 때 포워더와 수출 기업이 유용하게 사용할 수 있는 이 앱이 긍정적인 역할을 할 수 있을 것이라 기대한다.

향후 활용 방안

수출 기업과 포워딩 기업의 견적 체결 실제 업무에 활용할 수 있고, 데이터가 누적된다면 수출 기업이 예상되는 요금을 받아볼 수도 있을 것이다. HSCODE 추천 시스템만 별도로 이용하게 하여, 세율 정보를 확인할 수 있게 활용할 수도 있을 것이다.

참고문헌

김재황, “디지털 포워딩, 전문가에게 묻다”, 물류신문, 2022.07.18, , https://www.klnews.co.kr/news/articleView.html?idxno=305125 김진희, “디지털 기술과 편이성으로 무장한 ‘디지털 포워딩’, 헬로T, 2023.02.11, https://hellot.net/mobile/article.html?no=75069 김재황, “디지털 포워딩, 국내에서는 왜 더딜까?”, 물류신문, 2022.07.18, https://www.klnews.co.kr/news/articleView.html?idxno=305123 김재황, “글로벌 포워딩 물류, 디지털 포워딩이 이끈다.”, 2022.07.18, http://www.klnews.co.kr/news/articleView.html?idxno=305124 김재황, “국내 해운업계, ‘EDI’ 저물고 ‘API’ 뜬다”, 2023.05.18, https://www.klnews.co.kr/news/articleView.html?idxno=308196 우효창(Hyo-Chang Woo),and 이영구(Young-Koo Lee). "단어 임베딩을 활용한 빅데이터 기반의 지능형 HS코드 식별." 한국정보과학회 학술발표논문집 2019.6 (2019): 212-214. 오교중(Kyo-Joong Oh), 최호진(Ho-Jin Choi), 차원석(Wonseok Cha), 김일구(Ilgu Kim), 우찬균(Chankyun Woo), “언어모델 전이학습 기반 해외 직접 구매 상품군 분류”, 한글 및 한국어 정보처리 학술대회 논문집 (2022년): 571-575 HS 오토팬, https://www.hs-tariff.com/main/hs_mti_ai_main/?device=pc Cello Square(첼로 스퀘어) https://www.cello-square.com/kr-ko/index.do https://huggingface.co/nreimers/MiniLM-L6-H384-uncased https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2 관세법령정보포털, https://unipass.customs.go.kr/clip/index.do