모바일 SaaS · 중고 거래

타죽 (TAJOOK)

매물 사진 업로드 → AI 분석 리포트와 라이더 유틸리티, 운영자가 웹에서 프롬프트를 직접 수정 가능한 PWA 프로토타입입니다.

타죽 모바일 PWA 홈 — 매물 사진 분석 CTA + 라이더 도구 + AI가 봐주는 항목

문제

중고 오토바이 구매 시 비전문가는 사진만으로 위험 요소를 파악하기 어렵고, 커뮤니티에서 '이 매물 어때요?' 류 질문이 반복적으로 발생하지만 빠른 전문가 피드백이 어려웠습니다.

접근

매물 사진 1~10장 → AI 분석 리포트(차종 추정·커스텀 감지·외관 상태·위험도·현장 체크리스트)를 만듭니다. 분석은 단일 호출이 아니라 시각 검사·진단·지식 교차검증을 분담하는 멀티에이전트(4-Agent + Synthesizer) 구조로 설계했습니다. 여기에 라이더 유틸리티(윌리각/린앵글 실시간 센서 계산기)와 운영자가 웹에서 프롬프트를 직접 수정 가능한 관리자 페이지를 더했습니다.

결과

PWA 기반 모바일 퍼스트 프로토타입을 출시했습니다. AI 매물 분석 엔진은 중고 자동차 등 다른 정보 비대칭 시장에 일반화할 수 있습니다.

Architecture

어떻게 동작하는가

  1. 01
    매물 사진 업로드Next.js PWA

    정면·후면·측면 카테고리별 최대 10장 + 연식·모델명·판매글을 받습니다.

  2. 02
    멀티에이전트 분석Claude API · 4-Agent

    시각 검사 → 진단 → 나무위키·매뉴얼 RAG 교차검증 → 합성으로 이어집니다. '판매자 주장 vs 사진'도 대조합니다.

  3. 03
    리포트 생성

    솔직/정중 톤을 선택하고 1크레딧을 차감합니다. 결과를 히스토리에 저장합니다.

  4. 04
    사용자·크레딧·데이터Supabase

    인증·크레딧·분석 히스토리를 관리합니다.

  5. 05
    운영자 프롬프트 수정

    웹 관리자에서 분석 프롬프트를 직접 수정해 코드 배포 없이 정확도를 지속 개선합니다.

사진 → AI 분석 → 리포트. 운영자가 프롬프트를 직접 고쳐 정확도를 계속 끌어올립니다. 라이더 유틸리티(실시간 센서)로 리텐션을 확보합니다.

Decisions · 4

왜 이렇게 설계했는가

기술 선택의 근거와 트레이드오프 — 코드 대신 의사결정으로 설계를 설명합니다.

  • ?고정 분석 로직 vs 운영자 프롬프트 수정 관리자?

    선택
    분석 프롬프트를 운영자가 웹에서 직접 수정 가능한 관리자 페이지
    근거
    중고 바이크 고질병·커스텀 패턴은 차종·연식마다 계속 바뀝니다 — 코드 배포 없이 운영자가 프롬프트만 고쳐 분석 정확도를 지속 개선하게 설계했습니다('운영자가 직접 손볼 수 있는 구조' 원칙).
    트레이드오프
    잘못된 프롬프트 수정 위험이 있습니다. 대신 비개발자 운영자가 모델 품질을 직접 운용합니다.

  • ?네이티브 앱 vs PWA?

    선택
    모바일 퍼스트 PWA
    근거
    매물 보러 간 현장에서 설치 없이 링크로 바로 카메라를 띄워 쓰는 시나리오라 — 앱스토어 심사·설치 마찰을 제거합니다.
    트레이드오프
    네이티브 센서·성능에 제약이 있습니다. 대신 즉시 접근·배포합니다.

  • ?매물 분석 SaaS에 왜 라이더 유틸리티를?

    선택
    윌리각/린앵글 실시간 센서 계산기를 같이 탑재
    근거
    분석은 매물 살 때 가끔 쓰지만 유틸리티는 라이더가 평소 자주 씁니다 — '항상 켜둔 앱'으로 재방문 동기를 만드는 차별점입니다.
    트레이드오프
    핵심(분석)과 무관한 기능을 추가합니다. 대신 리텐션을 확보합니다.

  • ?단일 LLM 호출 vs 멀티에이전트 검증 파이프라인?

    선택
    시각검사·진단·지식 교차검증을 분담하는 4-Agent + Synthesizer 구조
    근거
    단일 호출은 그럴듯하게 틀리기 쉽습니다 — 역할을 쪼개고 매뉴얼·위키 기반 지식베이스로 교차검증해 환각을 거르도록 설계했습니다('AI를 의심하는 검증'을 취미 프로젝트에도 적용).
    트레이드오프
    호출이 늘어 비용이 올라갑니다. 수익화 전 단계라 RAG를 촘촘히 못 잡아 정확도는 아직 한계입니다 — 구조는 잡혔고 데이터 밀도가 다음 과제입니다.

Gallery · 5

실제 화면

  • AI 분석 결과 — 차종 식별 + 위험 항목(소모품 주기·상태)을 등급·근거와 함께 정리
    01AI 1차 필터링 결과 — 사진만으로 차종(Honda PCX 125)을 식별하고, CVT 벨트 교체 주기·패널 품질·주행거리 같은 위험 항목을 높음/낮음 등급 + 근거 + 현장 체크 포인트로 정리합니다. 현장 가기 전에 거르는 용도입니다.
  • 운영자 관리자 — 4-Agent + Synthesizer 멀티에이전트 파이프라인 + 프롬프트 직접 수정
    02분석은 단일 호출이 아니라 멀티에이전트 파이프라인입니다 — Agent 0(맥락) → 1(시각검사) → 2(진단) → 3(지식검증) → Synthesizer. 운영자가 각 에이전트 프롬프트를 코드 배포 없이 웹에서 직접 수정합니다. (프롬프트 완성도는 계속 다듬는 중)
  • Agent 3 나무위키 박사 — 매뉴얼·위키 지식베이스로 모델 고질병을 RAG 교차검증
    03Agent 3 '나무위키 박사' — 웹에서 모은 매뉴얼·위키 정보를 백업한 지식베이스로 모델별 고질병을 교차검증하는 RAG 레이어입니다. "AI를 의심하고 검증한다"는 발상을 취미 프로젝트에도 적용했습니다. 단 비용·RAG 밀도 제약으로 정확도는 아직 한계입니다 — 구조 먼저, 데이터는 다음 과제입니다.
  • 윌리각 계산기 — 기기 내장 센서 활용 라이더 유틸리티
    04윌리각 계산기 — 폰 내장 센서(가속도·자이로)로 전후 피치각을 실시간 측정해 게이지로 표시하고, 영점 캘리브레이션 + 최대 기록을 지원합니다. 라이더 커뮤니티의 반복 질문을 도구로 만든 제품 발상입니다(구현은 AI, 구상은 라이더 관점).
  • 린앵글 계산기 — 좌우 롤각 측정, 한계를 명시한 정직한 유틸
    05린앵글 계산기 — 좌우 롤각을 실시간 측정해 좌/우 최대 뱅크각을 기록합니다. "핸들바 거치 시 조향 오차, 재미로 보는 참고값"이라고 한계를 솔직히 표기한 톤이 오히려 신뢰를 만드는 디테일입니다.

Tech · 6

사용 기술

구현: AI (Claude 등) · 구조 결정과 검증: Ray Moon

  • Next.js 14
  • Supabase
  • Tailwind
  • shadcn/ui
  • PWA
  • Claude API

다른 케이스도 같은 (문제 → 접근 → 결과 → 아키텍처 → 의사결정) 구조로 정리되어 있습니다.

← 케이스 목록 보기