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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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