삼문판결 만들기 3편: 재심(appeal)을 기능이 아니라 장치로 설계한 이유

삼문판결의 핵심은 단호함이다. 그런데 단호함만 있으면 한 가지 문제가 생긴다.

한 번의 판결이 너무 절대적으로 보인다는 점.

그래서 3편의 주제는 재심이다. 결론부터 말하면, 재심은 판결을 약하게 만드는 장치가 아니라 오히려 판결의 신뢰를 높이는 장치다.

왜 재심이 필요한가

사용자는 보통 첫 입력에서 중요한 맥락을 빼먹는다.

이 상태에서 나온 판결은 틀렸다기보다 불완전하다. 재심은 이 누락된 맥락을 붙여서 판결을 다시 내리는 절차다.

즉, “감정적 항소”가 아니라 정보 보강 기반 재판에 가깝다.

재심은 단순히 “다시 해줘”로 받지 않았다. 추가 정보 필드를 명시했다.

이렇게 받은 이유는 명확하다. 모델이 잘 답하게 하려면 프롬프트 이전에 입력 구조가 먼저 좋아야 한다.

재심이라고 해서 규칙을 느슨하게 풀지 않았다. 기본 판결과 동일한 계약을 강제한다.

결론: 재심은 ‘봐주기’가 아니라 같은 법정에서 증거만 추가된 재판이다.

재심을 무제한으로 열어두면 서비스는 금방 장난감이 된다. 그래서 운영 관점에서 재심 체인을 분리했다.

이 구조 덕분에 어떤 판결이 몇 번째 재심인지 추적 가능하고, 무료 재심 한도도 정책으로 제어할 수 있다.

핵심은 “많이 생성”이 아니라 의미 있는 재판 기록을 남기는 것이다.

재심은 사용자 만족 장치인 동시에, 제품팀 입장에서는 학습 장치다.

즉, 재심 로그는 단순 CS가 아니라 판결 엔진 개선 데이터셋이다.

판결 서비스에서 재심은 선택 기능이 아니다. 신뢰를 유지하기 위한 기본 장치다.

삼문판결의 재심은 “처음이 틀렸을 수 있다”를 인정하는 방식이 아니라, “처음은 불완전할 수 있다”를 설계로 받아들인 방식이다.

다음 편에서는 재심과 판결 로그를 어떻게 숫자로 묶어 실제 운영 지표로 보는지 정리한다.