수리

수리수리AI

플랫폼 개발 현황 보고서

2026-07-08 KST · 타크온 검수 요청 대응 자료 · 계약서 제2조 산출물 기준

지금 어디까지 만들어졌는지,
무엇을 어떻게 구현했는지 한 장으로 정리했습니다.

본 문서는 계약서 제2조 산출물 8개 항목을 기준으로, 현재 저장소에서 검수 가능한 구현 사실과 각 기능의 구현 방식, 그리고 현재 진척 수준을 정리한 기술 현황 보고서입니다. 모든 항목은 실제 소스 파일과 검증 결과에 근거하며, 운영 계정(OpenAI·Supabase·PG·FCM)이 필요한 부분은 과장 없이 "운영 연동 대기"로 분리해 표기합니다. 계약 해석·대금 판단 등 법률 의견은 포함하지 않습니다.

30앱 화면·상태 (소비자 18 · 파트너 12)

7Backend API 함수

11DB 테이블 + RLS

5에스크로 정산 단계

보고서 작성 기준
앱/웹/AI/매칭/에스크로/DB는 로컬 검수 모드로 실제 동작하도록 구현되어 있습니다. 외부 실계정 없이도 소비자·파트너 앱, 관리자 웹, 코어 엔진(AI 견적·매칭·에스크로), Supabase 스키마 구조를 화면과 테스트로 확인할 수 있습니다. 운영 OpenAI·Supabase·PG·FCM 계정 정보가 필요한 항목은 동일 인터페이스 뒤에 실서비스 adapter를 연결하는 "운영 전환" 단계로 분리합니다. 최종 브랜드/화면 컨셉은 발주자 선호안 또는 디자인팀 방향 수령 시 즉시 반영 가능한 작업 항목입니다.

현재 현황 한눈에 보기

"완료 예정일" 약속이 아니라, 지금 어느 단계까지 실제로 구현·검수 가능한지를 진척도로 표기

Current delivery position

핵심 기능은 로컬 검수 제출 단계까지 구현됨

수리 요청 생성 → AI 사진 분석/견적 → 특허 다중 숙련도 매칭 → 5단계 에스크로 → 관리자 조회까지 하나의 흐름으로 동작하며, DB/RLS/Edge Function 구조와 단위 테스트로 확인 가능합니다. 운영 실계정이 필요한 부분만 연결 대기 상태로 분리했습니다.

Backend / Core

7개 API + AI 견적·매칭·에스크로 엔진. 단위 테스트 포함.

검수 가능

DB / RLS / ERD

11개 테이블, PostGIS, RLS 초안, ERD 시각화 완료.

구조 정리

앱 / 관리자

소비자 18 · 파트너 12 화면, 관리자 5 메뉴 흐름 구성.

디자인 최종화 대기

운영 연동

OpenAI·PG·FCM·Supabase 실계정 수령 후 adapter 연결.

정보 대기

검수자료 기준 진척도

백엔드 / Core

API, AI 견적, 매칭, 에스크로 상태 전이 · 단위 테스트 92%

DB / 보안

PostgreSQL/PostGIS, RLS, 감사 로그, ERD 90%

앱 / 웹 기능

소비자·파트너·관리자 흐름 구성, 최종 디자인 조정 82%

운영 전환

외부 연동 정보, 배포 URL, PG/FCM 실검수 56%

진척도는 계약 산출물 대비 "로컬 검수 가능 + 운영 연동 필요"를 함께 반영한 내부 추정치이며, 대금·완료 판단이 아닙니다.

1. 계약 산출물(제2조) ↔ 구현 대응

계약 기준 8개 산출물 항목별 현재 구현 상태와 근거 파일

계약 산출물	구현 현황	근거 파일	상태
① 소비자 앱 (Flutter, 최소 7화면)	계약 최소 7화면 대비 18개 화면/상태로 확장 구현. 요청 wizard·사진 업로드·AI 결과·매칭·에스크로·마이페이지 흐름 연결.	`apps/consumer_app`	확장 구현
② 파트너 앱 (Flutter, 최소 6화면)	계약 최소 6화면 대비 12개 화면/상태. 요청 피드·상세·견적 제안·작업 단계·정산 흐름 연결.	`apps/partner_app`	확장 구현
③ 관리자 웹 (React+TS, 최소 5메뉴)	5개 메뉴(대시보드·사용자·파트너·요청/견적·정산/에스크로) 구현, 대시보드 스냅샷 연동.	`apps/admin-web/src/main.tsx`	5메뉴 구현
④ AI 사진 분석/견적 (GPT-4o Vision 구조)	결정적 로컬 estimator + OpenAI GPT-4o Responses adapter 이중 구조, 스키마 검증 포함. 운영 시 키만 연결.	`packages/core/src/aiEstimator.ts`	구조 구현 키 필요
⑤ 특허 다중 숙련도 가중치 매칭 엔진	특허 `10-2026-0010208` 명칭 기준, 7개 요인 가중치 매칭 + 점수/순위/근거 산출. 단위 테스트 있음.	`packages/core/src/matchingEngine.ts`	구현·테스트
⑥ 단계별 에스크로 정산 (PG 연동 구조)	5단계 상태 전이 + 착수금 30%/잔금 70% 분할, 선행단계 검증. `PgProvider` 인터페이스로 PG 교체 가능.	`packages/core/src/escrow.ts`	로직 구현 PG 실계정
⑦ Backend 인프라 (Supabase/PostGIS/Edge/FCM)	PostgreSQL/PostGIS 스키마, RLS, REST view, Edge Function(fail-closed 인증), 알림 데이터 구조 구현.	`supabase/migrations/001_initial_schema.sql`, `supabase/functions/platform-api`	구조 구현 프로젝트 연결
⑧ 보안 (JWT·RLS·HTTPS·PCI-DSS 위임)	Bearer 토큰 검증, RLS 정책 초안, `is_admin()` security definer, 감사 로그 테이블. 실결제는 PG PCI-DSS 외부 위임 구조.	`supabase/…`, `packages/backend`	초안 구현 운영 검수

근거: docs/evidence/contract-deliverable-matrix.md, docs/submission/technical-specification.md, ultragoal-brief.md. 특허 번호는 ultragoal-brief.md 명칭 기준.

2. 발주자 요청 3건 대응 요약

타크온(김희태 대표) 측 요청 항목별 준비 상태

요청 항목	현재 대응 자료	송부 전 필요한 조치	상태
1. 기능별 기술 명세서	`docs/submission/technical-specification.md` + 본 HTML 현황 보고서(ERD·API·화면 인벤토리 포함)	본 HTML 또는 PDF 출력본 첨부	정리 완료
2. 실제 구동 테스트 주소	현황보고서 공개 URL `surisuri-tarkon-report.pages.dev` + 로컬 검수 주소(소비자 `8091`, 파트너 `8092`, 관리자 `8194`)	앱/웹 외부 검수가 필요하면 임시 서버 또는 정적 호스팅 배포 URL 생성	로컬 검수 가능
3. GitHub 소스코드 링크	`surisuri-ai-platform` 로컬 Git 저장소, 소스 전달 가이드 준비	Private GitHub repository 생성 · remote 연결 · push · 접근 권한 부여	링크 생성 전

3. 백엔드 / Core — 어떻게 구현했는가

각 핵심 엔진의 실제 로직·수식·파일 근거 (로컬 검수 provider 기준)

AI 사진 분석 / 견적

이미지(URL/base64)·카테고리·설명을 입력받아 손상 유형·심각도·작업 항목·금액 범위·신뢰도를 산출.

이중 providerOpenAI 키

파트너 매칭 엔진 (특허)

7개 요인을 0~1로 정규화 후 가중합해 0~100점 산출, 순위·근거 문구 생성.

로직·테스트

에스크로 상태 전이

5단계, 착수금 30%/잔금 70%, 선행단계 미완료 시 전이 차단.

5단계 구현PG 실계정

3-1. AI 견적 산출 로직 (`packages/core/src/aiEstimator.ts`)

운영 오설정을 숨기지 않도록 설계: 로컬 provider 기본값, SURISURI_USE_LOCAL_PROVIDERS=false인데 OPENAI_API_KEY가 없으면 예외를 던집니다. OpenAI provider는 GPT-4o /v1/responses 응답을 파싱·스키마 검증(assertOpenAIEstimateShape)합니다.

카테고리별 기준 금액 · 심각도

카테고리	기준금액(원)	심각도
배관(plumbing)	320,000	critical
타일(tile)	260,000	high
전기(electric)	240,000	high
바닥(floor)	210,000	medium
도배(wallpaper)	180,000	medium
가전(appliance)	150,000	medium
문/도어(door)	120,000	low

금액 산출 수식

textFactor   = min(90000, 설명길이 × 1800)
severityFactor = { critical 1.45, high 1.25,
                   medium 1.08, low 0.92 }

minAmount = round((기준금액 + textFactor)
                  × severityFactor)
maxAmount = round(minAmount × 1.32)
confidence = 0.82  (로컬 provider)

작업 항목(tasks)은 현장 사진 검수 · 보양/철거 · 자재 산정 · 숙련공 배정 · 완료 검수로 구성되고, 주의사항(cautions) 2건이 함께 반환됩니다.

3-2. 다중 숙련도 가중치 매칭 (`packages/core/src/matchingEngine.ts` · 특허 10-2026-0010208)

요인별 가중치 (합계 1.00)

요인	가중치	정규화(0~1)
숙련도(skill)	0.28	카테고리 skill.level ÷ 5
거리(distance)	0.16	1 − min(거리km,25)÷25 (haversine)
평점(rating)	0.14	rating ÷ 5
완료율(completionRate)	0.14	값 그대로
응답속도(responseSpeed)	0.12	1 − min(분,180)÷180
가용성(availability)	0.08	가능 1 / 불가 0
견적적합(estimateFit)	0.08	1 − min(\|파트너가−견적중앙값\|÷중앙값, 1)

점수·순위 산출

score(0~100) = Σ(요인 × 가중치) × 100  (반올림)
정렬: score 내림차순 → rank 부여
저장: match_results(total_score, rank,
        breakdown JSON, reason)

근거 문구(reason)는 "숙련도 우수 / 현장 근접 / 평점 우수 / 응답 빠름 / 즉시 배정 가능" 중 강점을 자동 생성합니다. 가중치는 defaultMatchingWeights로 노출되어 운영 시 조정 가능합니다.

단위 테스트: matchingEngine.test.ts

3-3. 5단계 에스크로 상태 전이 (`packages/core/src/escrow.ts`)

① 견적 확정
quote_confirmed→ ② 착수금 예치
deposit_held→ ③ 작업 진행
work_in_progress→ ④ 완료 확인
completion_confirmed→ ⑤ 잔금 정산
balance_released

금액 분할 · 상태 규칙

착수금 = round(총액 × 0.3), 잔금 = 총액 − 착수금 (금액은 ②·⑤에만 배정)
초기: ① ready, 나머지 pending
상태값: pending · ready · held · released
②(착수금) 완료는 held 또는 released로 판정

전이 검증 (`advanceEscrow`)

이전 단계 미완료 시 예외(Cannot advance … before …)로 건너뛰기 차단
대상 단계 → ②면 held, 그 외 released
다음 단계 pending → ready 자동 전환
PG 경계: PgProvider 인터페이스 · 로컬은 LocalPgProvider(실결제 미수행), 운영은 동일 인터페이스에 live PG adapter 연결

단위 테스트: escrow.test.ts

3-4. Backend API 함수 (`packages/backend/src/platformApi.ts`)

함수(action)	입력 → 출력	효과	구현/근거
`createRepairRequest`	소비자·카테고리·주소·좌표·사진 → `RepairRequest`	`repair_requests`, `repair_photos` 생성	구현
`analyzeRepairPhoto`	requestId → `AiEstimate`	로컬/OpenAI estimator 호출, 상태 `ai_analyzed`	구현
`calculateEstimate`	requestId → 저장된 `AiEstimate`	견적 조회	구현
`matchPartnersForRequest`	requestId → `MatchResult[]`	가중치 매칭 점수 산정, 상태 `matched`	구현
`createEscrowStagesForRequest`	requestId·amount → `EscrowStage[]`	5단계 에스크로 생성	구현
`updateRepairStatus`	requestId·status → `RepairRequest`	소비자/파트너/관리자 공통 상태 갱신	구현
`adminListRequests`	— → 요청 + 견적 + 매칭수	관리자 목록/견적 데이터	구현

저장소 경계: PlatformRepository 인터페이스 — 로컬 검수 MemoryPlatformRepository / 운영 SupabaseRestPlatformRepository. Edge Function(supabase/functions/platform-api/index.ts)은 위 action만 허용하고 Bearer 토큰 검증(실패 401 · 알 수 없는 action 404 · 비POST 405 · 환경변수 없으면 503 fail-closed).

4. 전체 요청 흐름 (견적 → 매칭 → 결제 → 시공 → 정산)

요청 상태 전이 RepairStatus와 3개 앱/웹이 공유하는 단일 상태 기준

draft→ ai_analyzed→ matched→ quote_confirmed→ deposit_held→ in_progress→ completed→ settled

소비자 여정

로그인/회원가입 → 약관·개인정보 동의
홈 → 카테고리 → 주소/방문시간/설명 wizard
사진 업로드 → AI 분석 진행 → 결과/예상 견적
파트너 매칭 목록 → 파트너 상세/점수 근거
견적 확정 → 5단계 에스크로/결제 → 진행 타임라인
완료 확인 → 잔금 정산(settled)

파트너 · 관리자 여정

파트너: 요청 피드 → 상세 → 견적 제안(금액·소요시간·메모)
파트너: 수락 → 작업 단계(방문예정→작업진행→완료요청→정산대기)
파트너: 정산/에스크로 상태 확인
관리자: 대시보드 요약 → 사용자·파트너 관리
관리자: 요청/견적(AI 결과·매칭 근거) → 정산/에스크로 관리

백엔드 단위 흐름 검증: createRepairRequest → analyzeRepairPhoto → matchPartnersForRequest → createEscrowStagesForRequest → adminListRequests (packages/backend/test/platformApi.test.ts).

5. Backend ERD / DB 구조

Supabase migration 기준 11개 테이블 + RLS

supabase/migrations/001_initial_schema.sql

profiles

id uuid PK / auth.users FK
role: consumer / partner / admin
name, phone, status
created_at

repair_requests

id uuid PK
consumer_id FK → profiles.id
category, title, description
address, location(PostGIS)
status: draft~settled

repair_photos

id uuid PK
request_id FK → repair_requests.id
storage_path, label
created_at

ai_estimates

id uuid PK
request_id FK → repair_requests.id
damage_type, severity
tasks, amount range, confidence
provider, raw_summary

partner_profiles

id uuid PK
user_id FK → profiles.id
display_name, service_areas
location(PostGIS), rating
response, completion, available

partner_skills

id uuid PK
partner_id FK → partner_profiles.id
category
level 1~5
years

match_results

id uuid PK
request_id FK → repair_requests.id
partner_id FK → partner_profiles.id
total_score, rank
breakdown JSON, reason

escrow_stages

id uuid PK
request_id FK → repair_requests.id
code, label, sequence
amount
status: pending/ready/held/released

payments

id uuid PK
request_id FK → repair_requests.id
stage_code
provider, provider_reference
amount, status

notifications

id uuid PK
user_id FK → profiles.id
channel, title, body
payload JSON
sent_at

audit_logs

id uuid PK
actor_id FK → profiles.id
action
target_table, target_id
metadata JSON

views / functions

platform_repair_requests
platform_partner_profiles
public.is_admin()
RLS policies

profiles 1 → N repair_requests: 소비자 요청 소유

repair_requests 1 → N repair_photos / ai_estimates / escrow_stages / payments

profiles 1 → N partner_profiles: 파트너 사용자 확장

partner_profiles 1 → N partner_skills / match_results

repair_requests N ↔ N partner_profiles: match_results를 통한 추천/매칭

profiles 1 → N notifications / audit_logs: 알림과 감사 추적

DB 보안 / 운영 구조

항목	구현 내용	남은 운영 확인
PostGIS	수리 요청·파트너 위치를 geography(point, 4326)로 저장, 거리 매칭에 사용	실제 주소 → 좌표 변환 API 연결
RLS	소비자 본인 요청, 파트너 매칭 요청, 관리자 전체 권한 정책 초안 + `is_admin()`	Supabase Auth role 동기화 trigger 검수
Storage	`repair_photos.storage_path`로 사진 저장 경로 관리	bucket policy · 업로드 URL 정책 설정
Audit	`audit_logs`로 관리자/시스템 이벤트 기록 구조	로그 보존 기간 · 개인정보 파기 정책 확정

6. 앱 / 웹 화면 인벤토리 (전체)

디자인 최종안과 별개로 각 화면의 기능 흐름을 검수 가능. 근거: docs/evidence/app-screen-inventory.md

6-1. 소비자 앱 — 18개 화면/상태

01Splash/브랜드 02온보딩·사진진단 03온보딩·신뢰매칭 04온보딩·에스크로 05로그인/회원가입 06약관/개인정보 동의 07홈 대시보드 08요청·카테고리 09요청·주소/시간/설명 10사진 업로드/촬영 11AI 분석 진행 12AI 결과/예상 견적 13파트너 매칭 목록 14파트너 상세/점수근거 15견적 상세/비교 16에스크로/결제 상태 17진행 타임라인/알림 18마이페이지/개인정보

마이페이지 내부: 프로필 요약, 내 수리 요청, 결제/에스크로, 개인정보·동의 관리(동의 상태·일자·약관 버전·철회 요청), 주소/연락처, 알림 설정, 보안/계정(데이터 다운로드·계정 삭제 요청), 고객지원/문서. 민감정보(주소·연락처)는 데모 모드 마스킹.

6-2. 파트너 앱 — 12개 화면/상태

01Splash/파트너 브랜드 02로그인 03파트너 약관 동의 04프로필/인증 상태 05숙련도/카테고리/지역 06작업 요청 피드 07요청 상세(사진·AI분석) 08견적 제안/수락·거절 09작업 단계 업데이트 10정산/에스크로 상태 11알림/공지 12계정/개인정보/정산정보

계정 내부: 프로필 완성도(상호·대표자·사업자번호·인증), 정산정보(은행/계좌 masked), 숙련도/서비스 지역, 가용성 toggle·최소 견적금액·평균 응답시간, 리뷰/성과(평점·완료율·응답속도), 개인정보·동의 관리·철회 요청.

6-3. 관리자 웹 — 5개 메뉴

메뉴	기능
대시보드	활성 요청·AI 견적 범위(min~max+신뢰도)·추천 파트너(+점수)·에스크로 단계 통계, 요청 흐름·에스크로 단계 요약 strip
사용자 관리	소비자/파트너/관리자 상태 관리
파트너 관리	숙련도·가용성(평점·응답속도·완료율, 배정 가능/대기)
요청/견적	수리 요청 상세, AI 분석 결과, 매칭 근거(파트너 테이블)
정산/에스크로	단계별 에스크로 정산, stage label/상태(로컬 검수 adapter 기준)

데이터 소스: apps/admin-web/src/adminPlatformClient.ts loadDashboardSnapshot(). 근거: apps/admin-web/src/main.tsx.

7. 개인정보 / 동의 설계

전체동의 → 필수·선택 구분 → 개별 토글 → 상세보기 → 마이페이지 철회. 근거: docs/evidence/privacy-and-consent-design.md

소비자 동의 항목 (10)

만 14세 이상서비스 약관개인정보 위치수리 사진주소/연락처 결제/에스크로푸시마케팅 품질개선 분석

파트너 동의 항목 (10)

파트너 약관개인정보사업자정보 정산정보작업 위치/일정고객 사진/주소 확인 전자세금계산서/정산작업 푸시공지/프로모션 운영 품질 분석

명시적 경계 — 현재 약관/동의 본문은 개발 증빙용 mock이며 확정 약관이 아닙니다. 개인정보 처리방침·이용약관·위치정보·결제/에스크로·파트너 정산정보 보관·삭제 정책은 실제 법률 검토가 필요하고, 개인정보 다운로드/계정 삭제는 UI만 준비(운영 API 연결 필요)됩니다. 앱스토어 심사 전 처리방침 URL·권한 설명·삭제 처리 API 보완이 필요합니다.

8. 기술 스택 & 아키텍처

모듈별 실제 사용 스택(근거: pubspec.yaml / package.json)과 설계 원칙

모듈	스택	비고
소비자 앱 · 파트너 앱	Flutter (Dart SDK ^3.11.4), 공용 `surisuri_flutter_design` 패키지	iOS/Android 단일 코드베이스
관리자 웹	React 19 + TypeScript 5.7 + Vite 6, Vitest 2.1	`@surisuri/core` 공유
Core 엔진	TypeScript (aiEstimator, matchingEngine, escrow, models, sampleData)	앱·웹·백엔드 공용 로직
Backend	TypeScript (platformApi, platformRepository) + Supabase Edge Function	interface 기반 repository
DB	Supabase PostgreSQL / PostGIS, RLS, migration SQL	11 테이블 + view + 함수

로컬 검수 우선 (local-verification-first)

외부 credential 없이도 mock/로컬 provider로 전 기능이 동작 → 발주자가 계정 없이 즉시 검수 가능.

adapter / interface 분리

VisionEstimator·PgProvider·PlatformRepository를 인터페이스로 두고 로컬 ↔ 운영(OpenAI/PG/Supabase) 구현을 교체.

source-based 위젯 패턴

SurisuriScaffold·AppShell·AppPage·InfoCard·FormBlock·AmountCard·PartnerScoreCard 등 공용 디자인 컴포넌트로 일관성 확보.

9. 실행 / 검증 현황

단위 테스트와 통합 검증 명령 기준

검증 항목	명령 / 자료	결과
Backend/Core/Admin 통합 검증	`npm run verify` (typecheck + test + build)	2026-07-08 01:30 KST 통과
Core 단위 테스트	`aiEstimator.test.ts · matchingEngine.test.ts · escrow.test.ts`	포함
Backend 단위 테스트	`platformApi.test.ts` (요청→분석→매칭→에스크로→관리자)	포함
관리자 웹 데이터 테스트	`adminData.test.ts`	포함
소비자/파트너 Flutter 앱	`flutter analyze && flutter test` (widget_test.dart)	통과 기록
운영 의존성 audit	`npm audit --omit=dev`	2026-07-08 취약점 0건
로컬 웹 검수 주소	`127.0.0.1:8091 / 8092 / 8194`	HTTP 200 기록
코드 내 TODO/FIXME	앱·패키지 소스 grep	0건

송부 전 권장
보내기 직전 현재 PC에서 npm run verify와 앱 build를 다시 실행해 최신 검증 시각을 갱신하고, 외부 검수 링크가 필요하면 임시 호스팅 URL을 생성하는 것을 권장합니다.

10. 지금까지의 진행과 남은 항목

"언제까지" 확약이 아니라, 무엇이 끝났고 무엇이 정보 수령 후 바로 이어지는지 정리

완료

계약 산출물 8개 항목 로컬 구현
소비자 18·파트너 12 화면, 관리자 5 메뉴, AI 견적·매칭·에스크로 엔진, Backend 7 API, DB 11 테이블/RLS/ERD를 로컬 검수 기준으로 구현하고 단위 테스트·통합 검증까지 통과했습니다.

현재

검수 자료 패키지화 + 공개 현황 URL
본 HTML 현황 보고서(ERD·API·화면 인벤토리·검증 결과)와 기술 명세서를 묶고, 현황 보고서는 surisuri-tarkon-report.pages.dev로 열람 가능하게 배포했습니다.

정보 수령 시

운영 연동 즉시 진행
OpenAI·Supabase·PG·FCM 실계정과 최종 디자인 방향을 받으면 동일 인터페이스 뒤에 live adapter를 연결하고 외부 검수 링크·GitHub private 링크를 생성합니다. 날짜 확약보다 "정보 수령 → 연결" 순서로 진행합니다.

남은 항목 구분 (운영 전환)

구분	현재 상태	필요 정보/협의
최종 디자인	검수용 UI는 있으나 발주자 톤앤매너/레퍼런스 반영 필요	선호 디자인, 로고 확정안, 색상/문구 방향
외부 검수 링크	로컬 실행 가능, 외부 접속 링크는 별도 배포 필요	배포 방식, 임시 서버/호스팅 계정
OpenAI Vision	GPT-4o adapter·스키마 검증 구현, 운영 key smoke test 필요	OpenAI API key, 사용할 Vision 모델명
Supabase	schema/RLS/Edge Function 구조 완비, 실제 프로젝트 연결 필요	URL, anon/service role key, Storage bucket
PG / 에스크로	5단계 상태 전이 구현, 실결제/정산은 PG 정보 필요	PG사 계약, 테스트/운영 key, 결제창/정산 정책
FCM 알림	알림 데이터 구조·화면 준비, 실제 push는 Firebase 설정 필요	Firebase project, iOS/Android bundle, 서버 연동
약관/법률	동의 UX·mock 약관 구현, 확정 약관은 법률 검토 대상	확정 약관/처리방침 원문, 삭제/보관 정책

11. 카카오톡 발송 문안

상대방에게 먼저 보낼 짧은 문안. 필요하면 HTML/PDF와 함께 전송

김희태 대표님, 연락 주셔서 확인했습니다. 기능 구현 범위를 말로만 설명드리기보다, 실제 검수 가능한 자료로 정리해서 드리는 것이 맞다고 판단했습니다. 현재 백엔드/Core 쪽은 로컬 검수 기준으로 수리 요청 생성, AI 사진 분석/견적, 특허 다중 숙련도 매칭(요인 7개 가중치), 5단계 에스크로 상태 전이, 관리자 조회, Supabase DB/RLS 구조까지 실제 동작·단위 테스트로 확인 가능하게 정리되어 있습니다. 소비자 앱 18개, 파트너 앱 12개 화면과 관리자 웹 5개 메뉴 흐름도 구성했습니다. 다만 최종 디자인 컨셉과 외부 운영 연동(OpenAI, Supabase, PG, FCM)은 상호 연락 공백 동안 확정되지 않은 부분이 있어, 원하시는 디자인 방향이나 레퍼런스, 운영 계정을 주시면 바로 맞춰 반영할 수 있도록 인터페이스로 분리해 두었습니다. 요청하신 1) 기능 기술 명세, 2) 테스트용 구동 주소/검수 방법, 3) GitHub 소스 전달 준비 상태는 HTML 현황 보고서로 묶어 정리했고, 지금 어디까지 구현됐는지 진척도까지 함께 보실 수 있습니다. ERD와 백엔드 API 현황, 화면 인벤토리도 포함했습니다. 외부 접속 링크와 GitHub private repository 링크는 송부 전 생성해 기입하면 되고, 우선 현재 구현 현황과 남은 연동/디자인 협의 항목을 구분해서 확인하실 수 있게 자료를 보내드리겠습니다.

메일 제목/첨부 안내

제목: 수리수리AI 플랫폼 구현 현황 및 검수 자료 송부의 건 첨부/링크: 1. 수리수리AI 기술 현황 보고서 HTML/PDF (본 문서) 2. 기술 명세서: docs/submission/technical-specification.md 3. 테스트 접속 안내: docs/submission/test-access-guide.md 4. GitHub 소스 전달 가이드: docs/submission/github-source-handover-guide.md 송부 전 기입 필요: - 소비자/파트너/관리자 외부 검수 URL - GitHub private repository URL

12. 제출 전 체크리스트

상대방에게 보내기 전 마지막 확인 항목

체크	항목	현재 상태
□	본 HTML을 브라우저에서 열어 화면/인쇄 확인	작성 완료
□	최신 검증 재실행: `npm run verify`, Flutter analyze/test	송부 직전 권장
□	외부 접속 가능한 테스트 URL 생성	필요 시 배포
□	GitHub private repository 생성 및 링크 기입	송부 전 필요
□	디자인 컨셉/레퍼런스 요청 문구 포함	문안 포함
□	법률 판단/대금 확정으로 읽히는 문구 제거	보고서 기준 반영

문서 위치: docs/submission/tarkon-status-report-2026-07-07.html
작성 기준: 2026-07-08 KST, 현재 저장소 파일·소스 코드·Backend/Core/Admin 검증 기준
주의: 본 문서는 기술 현황 보고서이며 법률 의견서가 아닙니다. 계약 해석과 대금 지급 의무 판단은 별도 법률 검토 대상이며, 진척도(%)는 내부 추정치입니다.

인쇄 시 배경 그래픽이 빠지면 브라우저 인쇄 설정에서 "배경 그래픽"을 켜면 됩니다.

지금 어디까지 만들어졌는지,무엇을 어떻게 구현했는지 한 장으로 정리했습니다.

현재 현황 한눈에 보기

핵심 기능은 로컬 검수 제출 단계까지 구현됨

1. 계약 산출물(제2조) ↔ 구현 대응

2. 발주자 요청 3건 대응 요약

3. 백엔드 / Core — 어떻게 구현했는가

AI 사진 분석 / 견적

파트너 매칭 엔진 (특허)

에스크로 상태 전이

3-1. AI 견적 산출 로직 (packages/core/src/aiEstimator.ts)

카테고리별 기준 금액 · 심각도

금액 산출 수식

3-2. 다중 숙련도 가중치 매칭 (packages/core/src/matchingEngine.ts · 특허 10-2026-0010208)

요인별 가중치 (합계 1.00)

점수·순위 산출

3-3. 5단계 에스크로 상태 전이 (packages/core/src/escrow.ts)

금액 분할 · 상태 규칙

전이 검증 (advanceEscrow)

3-4. Backend API 함수 (packages/backend/src/platformApi.ts)

4. 전체 요청 흐름 (견적 → 매칭 → 결제 → 시공 → 정산)

소비자 여정

파트너 · 관리자 여정

5. Backend ERD / DB 구조

DB 보안 / 운영 구조

6. 앱 / 웹 화면 인벤토리 (전체)

6-1. 소비자 앱 — 18개 화면/상태

6-2. 파트너 앱 — 12개 화면/상태

6-3. 관리자 웹 — 5개 메뉴

7. 개인정보 / 동의 설계

소비자 동의 항목 (10)

파트너 동의 항목 (10)

8. 기술 스택 & 아키텍처

로컬 검수 우선 (local-verification-first)

adapter / interface 분리

source-based 위젯 패턴

9. 실행 / 검증 현황

10. 지금까지의 진행과 남은 항목

남은 항목 구분 (운영 전환)

11. 카카오톡 발송 문안

메일 제목/첨부 안내

12. 제출 전 체크리스트

지금 어디까지 만들어졌는지,
무엇을 어떻게 구현했는지 한 장으로 정리했습니다.

3-1. AI 견적 산출 로직 (`packages/core/src/aiEstimator.ts`)

3-2. 다중 숙련도 가중치 매칭 (`packages/core/src/matchingEngine.ts` · 특허 10-2026-0010208)

3-3. 5단계 에스크로 상태 전이 (`packages/core/src/escrow.ts`)

전이 검증 (`advanceEscrow`)

3-4. Backend API 함수 (`packages/backend/src/platformApi.ts`)