수리 견적 앱 개발 비용을 줄이는 MVP 범위 정하기

핵심 요약

1. 사진 접수·관리자 견적 답변·고객 선택을 먼저 만들어 수리 문의부터 견적 수락까지 연결합니다. 2. FastAPI는 사진을 받고, Next.js는 견적 입력을 처리하며, 기존 회원 기능은 재사용 가능성을 확인합니다. 3. 사진 검증·견적 수정·본인 확인·중복 선택 방지는 직접 개발하고, 채팅·자동가격산정·배차는 후속 범위로 둡니다.

수리 견적 앱의 첫 MVP 개발은 고객이 고장 사진을 보내고, 관리자가 답한 견적을 선택하는 흐름에 집중합니다. 창업자는 이 흐름으로 접수 자료가 충분한지, 고객이 견적 내용을 이해하고 선택하는지 확인할 수 있습니다.

앱 개발비용을 비교할 때는 화면 개수와 함께 각 버튼이 처리할 업무를 정해야 합니다. 아래 범위는 새 서비스를 만들 때 적용할 구현안이며, 실제 견적은 재사용할 기능과 검수 조건을 확인한 뒤 산정합니다.

사진 접수와 FastAPI 파일 업로드

고객은 수리할 물건의 종류, 고장 증상, 사진을 입력하고 ‘견적 요청’ 버튼을 누릅니다. FastAPI는 UploadFile로 업로드 파일을 받을 수 있습니다. 사진의 허용 형식과 파일 용량, 필수 입력값 검사, 사진과 접수 건을 연결하는 처리는 별도로 개발합니다.

발주 자료로는 개인정보를 가린 수리 접수 예시를 준비합니다. 예를 들어 물건 전체 사진과 파손 부위 사진에 ‘문이 닫히지 않음’이라는 설명을 붙이면 필요한 입력 항목을 정하기 쉽습니다. 접수 후에는 고객이 보낸 사진과 설명이 확인 화면에 표시되어야 하며, 업로드에 실패하면 접수 완료로 표시하지 않고 재시도를 안내하도록 검수합니다.

관리자 견적 답변과 Next.js 입력 화면

관리자는 접수 사진을 보고 작업 내용, 예상 비용, 포함 항목, 추가 확인 사항을 작성합니다. Next.js는 입력값 묶음인 FormData를 서버 함수로 받아 처리할 수 있습니다. 금액 입력 검사와 필수 안내 누락 확인, 답변을 해당 고객의 접수 건에 연결하는 로직은 직접 만듭니다.

두 번째 발주 자료는 현재 쓰거나 사용하려는 견적서 양식입니다. 부품비·작업비·출장비 구분과 현장 확인 후 달라질 수 있는 조건을 담으면 화면에 필요한 항목이 명확해집니다. ‘견적 보내기’를 누르면 고객 화면에 같은 내용이 표시되어야 하며, 임시 작성한 답변이 고객에게 먼저 노출되지 않는지도 확인합니다.

고객 견적 선택과 수정 내용 확인

고객 화면에는 관리자가 보낸 견적과 ‘이 견적 선택’ 버튼을 둡니다. 첫 범위에서 한 접수 건에 관리자 답변 하나를 제공한다면, 여러 업체의 제안을 비교하는 화면은 제외할 수 있습니다. 선택 처리에는 앞서 만든 입력 처리 구조를 활용하되, 고객이 본 견적 내용과 선택 시점의 내용을 대조하는 로직을 추가합니다.

관리자가 비용이나 작업 내용을 바꿨다면 고객에게 바뀐 내용을 다시 보여주고 선택하도록 만듭니다. 버튼을 연속으로 눌러도 선택 기록은 한 번만 남아야 합니다. 완료 화면에는 선택한 작업과 비용 조건을 표시하고, 이 선택이 방문 예약이나 결제 완료까지 뜻하는지는 운영 정책으로 명확히 정합니다.

접수 내역 접근 제한과 회원 기능 재사용

접수 내역을 열 때는 로그인한 고객과 해당 접수의 작성자를 서버에서 비교하도록 구현합니다. 관리자는 담당 업무에 필요한 접수 건만 조회하도록 권한 범위를 정합니다. 화면에서 버튼을 숨기는 것에 그치지 않고, 조회·답변·선택 요청마다 허용된 사용자인지 검사하는 로직을 넣습니다.

Django authentication은 사용자·그룹·권한을 다루는 인증 체계를 제공합니다. 기존 시스템이 Django를 사용한다면 회원 기능의 재사용 가능성을 검토하되, 이번 앱을 위해 반드시 추가할 기술로 정하지는 않습니다. 검수에서는 다른 고객의 접수 주소로 바꿔 접근하는 실패 사례를 시험하고, 사진과 견적이 노출되지 않아야 통과하도록 정합니다.

후속 기능 분리와 개발 견적의 검수 조건

실시간 채팅은 메시지 교환과 알림 범위가 추가되므로 첫 버전에서는 접수 설명과 관리자 답변으로 대화 범위를 제한합니다. 자동가격산정은 가격 기준과 예외 처리 규칙을 정한 뒤 검토하고, 초기에는 관리자가 견적을 작성합니다. 배차는 견적 선택 이후의 별도 운영 업무로 두며, 담당자 배정과 방문 일정 자동 처리는 후속 개발 항목에 적습니다.

개발 견적에는 사진 접수, 답변 작성, 고객 선택을 나누고 각 기능의 재사용 대상과 통과 조건을 함께 적습니다. 기존 화면이 있어도 입력 항목이나 권한 기준이 다르면 수정 작업이 필요하므로, 보유 화면만으로 비용 절감을 단정하지 않습니다. 앱 개발비용을 비교할 때 같은 접수 예시로 세 단계가 이어지는지 확인하면, MVP 개발에 포함된 작업과 추가 견적이 필요한 작업을 구체적으로 구분할 수 있습니다.

수리 접수 사진·증상 예시와 견적서 양식, 기존 회원 시스템 정보를 준비해 사진 접수부터 고객 선택까지의 개발 범위를 문의해 주세요. 트램스 AI 제작 문의 (https://trams.co.kr/ai-si/contact/#inquiry)