삼문판결 만들기 2편: 만든 다음부터가 진짜 시작이었다

1편에서 나는 ‘좋은 말’ 대신 ‘판결문 형식’을 만들었다. 그런데 MVP를 실제로 돌려보니, 문제는 판결 생성 이전이 아니라 운영 정책에서 터졌다.

판결은 잘 나오는데, 서비스는 쉽게 흔들렸다.

그래서 2편의 핵심은 모델 튜닝이 아니라, MVP를 버티게 만드는 운영 설계다.

1) 정책 먼저: “무제한 체험”을 버리고, 무료 쿼터로 전환

초기에는 한 번만 쓰게 막는 강한 제한이 있었다. 그런데 이 방식은 간단한 대신, 학습 데이터가 너무 적게 쌓였다.

그래서 지금은 세션 기준으로 이렇게 바꿨다.

• FREE_JUDGE_QUOTA (기본 1)
• FREE_JUDGE_WINDOW_HOURS (기본 24)

즉, “평생 1회”가 아니라 **“24시간 롤링 윈도우 내 N회”**로 바꾼 것.

핵심은 사용자 입장에서 공정하고, 운영자 입장에서도 실험이 가능한 균형점이었다.

2) 기능보다 전환: 결제 대신 베타 대기 등록 UX

아직 제품이 날카롭게 고정되지 않았는데 결제부터 열면, 돈은 받을 수 있어도 학습은 느려진다.

그래서 유료 버튼을 전면 오픈하는 대신, 프리미엄 베타 대기 등록 플로우로 바꿨다.

결과 페이지에서 확장 기능을 누르면:

• 결제 화면으로 직행하지 않고
• 연락처 + 지불 의향 + 필요한 기능 1개를 받는 모달이 뜬다

이건 매출 버튼이 아니라, 수요 검증 폼을 제품 안으로 붙인 구조다.

3) 모델 실전 적용: Gemini 연동 + 실패 시 폴백

이번 라운드에서 생성부는 Gemini 호출을 붙였다. 다만 LLM 앱의 기본은 항상 같다.

성공 경로만 설계하면 반드시 깨진다.

그래서 지금 구조는 다음처럼 잡았다.

• Gemini 호출
• JSON 파싱 + badge/axis 정규화
• 길이/금지표현/단일 axis 등 가드레일 검사
• 위반 시 1회 재생성
• 그래도 실패하면 deterministic fallback 생성

한마디로, 모델 성능에 기대는 게 아니라 출력 계약을 강제하는 방식이다.

4) 저장소도 MVP답게: 파일에서 DB 중심으로 이동

초기 파일 저장은 빠르게 시작하기엔 좋다. 하지만 쿼터, 중복 입력 캐시, 재심 체인 같은 기능이 늘어나면 결국 데이터 모델이 필요해진다.

지금은 verdict/limit 저장이 DB 스키마 기반으로 움직이게 바꿨고, 세션 사용량·입력 해시·재심 인덱스를 서버에서 일관되게 다룬다.

즉, “돌아가는 데모”에서 운영 가능한 MVP로 한 단계 올라온 셈이다.

5) UI 리프레시: 화려함보다 판결 전달력

최근 커밋에서 랜딩/결과 페이지 비주얼을 여러 번 손봤다. 포인트는 장식이 아니라 전달력이다.

• 판결 배지 인지성 강화
• 문장 위계 정리(1문장 우선)
• 입력 피드백 개선
• 결과 카드 임팩트 조정

결국 목표는 하나다. 읽은 뒤 남는 감정이 “예쁘다”가 아니라, “그래서 지금 뭘 할지 알겠다.”

이번 라운드에서 얻은 결론

MVP의 핵심은 기능 수가 아니라 운영 규칙 + 출력 규격 + 학습 루프다.

삼문판결은 지금, 판결 생성기에서 조금 더 나아가 ‘판결 포맷을 중심으로 한 실험 시스템’이 되어가고 있다.

다음 편에서는 재심(appeal) 흐름을 어떻게 제품화할지, 그리고 어떤 지표로 “계속/중단”을 진짜 결정할지 정리해볼 생각이다.