AI 제작 가이드

배송 사진을 빠짐없이 전송하는 모바일 앱 개발하기

배송 사진접수부터 업로드완료, 관리자수신, 납품확정까지 구분하는 모바일 앱 개발과 API 개발 방법을 설명합니다. 앱 종료·중복 재전송·배송번호 불일치를 처리할 자체 개발 로직과 검수 기준을 정리합니다.

핵심 요약

1. 배송 사진을 휴대폰에 보관하고 전송 결과와 관리자 확인 여부를 구분해 보여줍니다. 2. Flutter의 오프라인 우선 구조, FastAPI의 파일 접수, BullMQ의 중복 작업 제어를 업무에 맞게 연결합니다. 3. 앱 종료 후 재전송, 배송번호 대조, 중복 저장 방지와 납품확정 조건은 직접 개발합니다.

배송 기사가 사진을 찍었는데 관리자에게 보이지 않으면 현장에서는 다시 촬영해야 하는지 판단하기 어렵습니다. 모바일 앱 개발과 API 개발에서는 사진을 보관한 위치와 담당자가 확인할 수 있는 범위를 구분해야 합니다. 사진을 찍은 뒤 통신이 끊겨도 기록을 이어갈 수 있도록 저장과 재전송을 연결하는 방법을 살펴봅니다.

Flutter로 배송 사진을 휴대폰에 보관하기

기사가 배송목록에서 배송 건을 선택하고 ‘사진 등록’을 누르면 사진과 배송번호를 함께 받습니다. Flutter 공식 문서는 로컬 데이터와 원격 API를 저장소 계층에서 함께 다루는 오프라인 우선 설계 예시를 제공합니다. 이를 참고해 화면과 데이터 보관 처리를 분리하고, 사진 파일과 전송에 필요한 정보를 휴대폰에 저장하는 부분을 직접 만듭니다.

사진접수는 이 앱에서 ‘휴대폰에 사진을 보관했다’는 의미로 정합니다. 파일 저장을 확인한 뒤 사진 미리보기와 배송번호를 보여주고, 통신이 끊겨도 전송할 사진을 다시 찾을 수 있게 합니다. 촬영 직후 화면을 나갔다가 돌아와도 같은 배송 건에 사진이 남아 있는지가 첫 검수 기준입니다.

모바일 앱 개발 기능 구현 요약
자료: 트램스 · 모바일 앱 개발 기능 구현 요약

FastAPI로 사진과 배송번호 확인하기

앱은 사진 파일에 배송번호와 사진 접수번호를 붙여 서버로 보냅니다. FastAPI는 UploadFile로 업로드 파일을 받을 수 있습니다. 파일이 열리는지, 허용한 형식과 크기인지, 요청한 기사가 해당 배송 건을 처리할 권한이 있는지는 별도 검증 기능으로 구현합니다.

배송번호는 입력값이 있다는 이유만으로 통과시키지 않고 서버의 배송목록과 대조합니다. 기사가 선택한 건과 배정 내역이 맞지 않으면 사진을 다른 배송에 붙이지 않고 확인 안내를 돌려줍니다. 파일 보관과 배송 연결 기록이 모두 확인된 경우에만 ‘업로드완료’를 표시하며, 잘못된 배송번호로 보낸 사진이 관리자 목록에 정상 건으로 섞이지 않아야 합니다.

앱이 꺼진 뒤에는 전송 결과부터 확인하기

전송 도중 앱이 종료되면 휴대폰에는 결과가 없어도 서버에는 사진이 도착했을 수 있습니다. 따라서 앱을 다시 열었을 때 무조건 새 사진으로 전송하지 않고, 보관한 접수번호로 기존 처리 결과를 조회하는 API를 직접 만듭니다. 서버에 정상 접수 기록이 있으면 화면을 갱신하고, 없다면 남아 있는 파일로 재전송합니다.

모바일 앱 개발 업무 처리 순서
자료: 트램스 · 모바일 앱 개발 업무 처리 순서

결과 조회 자체가 실패하면 ‘전송 결과 확인 필요’와 ‘다시 확인’ 버튼을 보여줍니다. 검수할 실패 사례는 사진이 서버에 저장된 직후, 앱이 응답을 받기 전에 앱을 종료하는 상황입니다. 재실행 후 같은 사진을 다시 보내더라도 관리자 목록에는 한 건만 남고, 기사 화면에서도 완료 여부를 확인할 수 있어야 합니다.

BullMQ와 접수 기록으로 사진 중복 막기

사진 업로드 뒤 관리자 목록에 반영하는 작업을 별도 대기열로 처리한다면 BullMQ를 연결할 수 있습니다. BullMQ의 Simple Mode는 같은 중복방지 ID의 미완료 작업이 있으면 추가 작업을 무시합니다. 이 기능은 대기 중인 동일 작업을 줄이는 데 사용하고, 완료된 작업의 재요청이나 실제 사진의 중복 저장은 자체 접수 기록으로 판단합니다.

재전송에는 처음 발급한 사진 접수번호를 그대로 사용하고, 서버는 기존 결과가 있는지 확인합니다. 같은 사진을 새로 선택한 경우도 처리하려면 배송번호와 파일 내용의 동일 여부를 비교하는 규칙이 필요합니다. 같은 배송의 동일 파일은 기존 결과를 돌려주되, 다른 각도로 촬영한 사진은 추가로 받을 수 있게 하며, 같은 접수번호에 다른 배송번호가 붙으면 덮어쓰지 않고 확인을 요청합니다.

모바일 앱 개발 기술별 역할
자료: 트램스 · 모바일 앱 개발 기술별 역할

관리자가 사진을 확인한 뒤 납품 확정하기

업로드완료는 서버에 사진과 배송 연결 기록을 저장한 단계로 정의합니다. 관리자수신은 담당 관리자의 조회 목록에 해당 사진이 반영되어 열람할 수 있는 단계로 구분합니다. 목록 반영이 지연되면 그 사실을 기사 화면에 안내하고, 다시 처리할 때도 사진을 재촬영하도록 요구하지 않게 연결합니다.

관리자가 실제로 사진을 열어봤는지는 별도의 열람 기록으로 남길 수 있습니다. 납품확정은 담당자가 배송번호, 사진 내용, 필요한 업무 항목을 확인한 뒤 ‘납품확정’을 눌렀을 때만 처리합니다. 사진만 올라왔다고 배송을 자동 확정하지 않으며, 잘못된 사진은 재촬영 요청으로 돌려보내고 기존 사진과 교체 이력을 확인할 수 있게 합니다.

이 흐름의 모바일 앱 개발과 API 개발을 문의하실 때는 배송번호·배정 기사·배송지 항목이 담긴 배송목록 샘플과 정상 사진·재촬영 대상 사진을 구분한 검수 예시를 준비해 주세요. 연결할 배송관리 시스템과 납품확정 담당자의 승인 조건을 함께 알려주시면 필요한 화면과 연동 범위를 구체화할 수 있습니다. 트램스 AI 제작 문의 (https://trams.co.kr/ai-si/contact/#inquiry)

참고 자료

  1. https://trams.co.kr/ai-si/
  2. https://docs.flutter.dev/app-architecture/design-patterns/offline-first
  3. https://fastapi.tiangolo.com/tutorial/request-files/
  4. https://docs.bullmq.io/guide/jobs/deduplication
TRAMS AI

비슷한 AI 서비스를
사업에 적용하고 싶으신가요?

아이디어와 필요한 기능을 알려주시면 제작 범위와 방법을 검토합니다.

프로젝트 문의