AI 제작 가이드

시설 점검 앱 개발업체를 고를 때 확인할 기능과 검수 기준

시설점검 앱 개발 외주를 준비하는 담당자를 위해 체크리스트, 오프라인 저장, 사진 업로드 복구, 재점검과 관리자 수정이력의 구현 범위 및 인수 기준을 설명합니다.

핵심 요약

1. 체크리스트·사진·재점검을 연결해 미조치 항목을 끝까지 확인하는 시설점검 앱을 만듭니다. 2. Flutter의 오프라인 설계, FastAPI의 파일 수신, OpenTelemetry의 운영 관측을 업무 흐름에 연결합니다. 3. 필수항목 검사, 업로드 재시도, 수정이력은 직접 개발할 범위와 인수 조건을 함께 정합니다.

시설점검 앱은 체크리스트 화면만으로 인수 여부를 결정하기 어렵습니다. 앱 개발업체를 고를 때에는 통신이 끊기거나 사진 전송이 실패해도 점검 기록이 이어지는지 확인해야 합니다. 아래 내용은 앱 개발 외주 발주 시 협의할 구현 범위와 검수 조건입니다.

필수항목을 확인하는 체크리스트와 제출 버튼

첫 번째 요청 자료는 현재 사용하는 시설점검표입니다. 예를 들어 시설번호·점검 위치·항목별 정상 여부·이상 내용이 적힌 점검표를 받으면, 각 칸을 앱의 입력 항목으로 옮깁니다. 항목마다 필수 여부와 사진이 필요한 조건을 정해 검사 규칙을 직접 만듭니다.

‘이상 있음’을 선택하면 설명과 사진을 요구하고, 빠진 항목은 제출 버튼을 누를 때 해당 위치에 표시합니다. 같은 규칙을 서버에서도 확인하도록 개발 범위에 넣습니다. 검수에서는 빈 필수항목이 있는 기록은 제출되지 않고, 임시저장은 가능한지 확인합니다.

Flutter의 오프라인 설계로 이어가는 현장 입력

Flutter 문서는 기기 내부 데이터와 원격 API를 함께 다루는 오프라인 우선 설계 예시를 제공합니다. 이를 적용할 때에는 입력한 점검 내용과 사진을 기기에 보관하고, 연결이 돌아오면 서버로 보내는 로직을 별도로 만듭니다. 화면에는 ‘기기에 저장됨’과 ‘제출 완료’를 구분해 보여줍니다.

앱 개발업체 기능 구현 요약
자료: 트램스 · 앱 개발업체 기능 구현 요약

현장 입력과 관리자 수정이 겹치면 변경 내용을 비교하고 관리자가 선택하도록 업무 규칙을 정합니다. 검수할 때에는 통신을 끊고 작성한 뒤 앱을 닫았다 열어도 내용과 사진이 남는지 확인합니다. 재연결 후에는 다른 사람이 수정한 내용이 자동으로 덮어써지지 않아야 합니다.

FastAPI로 사진을 받고 업로드 실패를 복구하기

FastAPI의 UploadFile은 서버에서 업로드 파일을 받을 수 있는 기능입니다. 그 위에 허용할 파일 형식과 크기, 점검 건별 접근 권한, 보관 기간을 확인하는 처리를 직접 개발합니다. 사진마다 고유번호를 부여하고 서버의 저장 확인을 받아, 재전송된 같은 사진을 중복 등록하지 않도록 합니다.

사진별 전송 결과를 보관하면 실패한 사진만 ‘다시 보내기’ 버튼으로 재시도할 수 있습니다. 인수 시험에서는 사진 세 장 중 두 번째 사진 전송 도중 통신을 끊었다가 다시 연결합니다. 재시도 후 관리자 화면에 사진 세 장과 점검 한 건만 나타나고, 임시저장 사진도 누락되지 않는지 확인합니다.

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

미조치 항목을 다음 재점검으로 연결하기

두 번째 요청 자료는 사진·담당자·조치 기한이 포함된 기존 미조치 관리대장입니다. 예를 들어 ‘지하 1층 소화전함 파손’이라는 예시 항목을 발견부터 재점검까지 어떻게 관리할지 정합니다. 앱에서는 이 정보를 받아 담당자와 기한에 따라 재점검 목록을 만드는 로직을 개발합니다.

재점검 화면에는 최초 발견 사진과 이전 점검 내용을 함께 보여주고, 새 사진과 조치 내용을 입력하게 합니다. 완료 조건은 시설 운영 담당자가 정하며, 필요한 증빙이 채워져야 항목을 닫도록 만듭니다. 검수에서는 미완료 항목이 목록에 남고, 완료 후에도 이전 기록을 조회할 수 있는지 확인합니다.

관리자 수정 권한과 변경 이력 남기기

관리자가 점검 결과를 고칠 때에는 수정 대상과 사유를 함께 입력하게 합니다. 수정자·수정 시간·변경 전후 값을 남기는 기능은 업무 기록용으로 직접 개발합니다. 원래 점검 내용과 관리자 변경 내용을 나란히 볼 수 있으면 인수 후 잘못된 수정의 경위를 확인하기 쉽습니다.

앱 개발업체 기술별 역할
자료: 트램스 · 앱 개발업체 기술별 역할

점검자와 관리자의 수정 가능 범위도 발주 단계에서 구분합니다. 검수에서는 점검자 계정으로 관리자용 수정 요청을 보내도 기록이 바뀌지 않는지 확인합니다. 관리자 수정이 허용되는 경우에는 저장된 값과 변경 이력이 함께 남아야 합니다.

OpenTelemetry로 오류를 확인하고 인수 기준 맞추기

OpenTelemetry는 처리 흐름을 추적하는 트레이스, 수치로 보는 지표, 사건을 남기는 로그 등의 운영 관측 신호를 다룹니다. 이를 연결할 때에는 사진 전송 실패와 재시도 결과를 점검 건에 연결해 확인하는 로직을 추가합니다. 운영 담당자가 어느 단계에서 문제가 생겼는지 찾을 수 있도록 필요한 기록 범위를 정합니다.

업무상 제출 성공의 기준은 별도로 정의합니다. 점검 내용과 필수 사진이 모두 저장되고 관리자 화면에서도 조회될 때 성공으로 판정하도록 맞춥니다. 앱 개발업체와 실제 사용할 기기에서 오프라인 저장, 재전송, 필수항목 누락, 권한별 수정 시나리오를 실행해 계약한 결과가 나오는지 확인합니다.

시설점검 앱 개발 외주를 준비한다면 현재 점검표와 사진이 포함된 미조치 관리대장, 현장에서 통신이 끊기는 상황을 정리해 주세요. 트램스 AI에 체크리스트·사진 복구·재점검·수정이력의 개발 범위와 인수 기준을 문의해 주세요. 트램스 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://opentelemetry.io/docs/concepts/signals/
TRAMS AI

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

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

프로젝트 문의