콘텐츠로 이동

내Law남불 — 팀 피드백 (그룹 2)

내Law남불의 목표는 사건을 처음 접했을 때와 필요한 정보를 확인한 뒤의 판단을 나란히 보여주는 것입니다. 사용자·AI·재판부 중 누가 맞는지를 가리기보다, 판단 근거가 어떻게 달라졌는지 살펴보게 합니다. 화면과 AI를 만들기 전에 사건 자료를 확보하고, 가공 뒤에도 판단에 필요한 사실이 보존되는지 확인해야 합니다.

flowchart TB
    P[사건을 처음 접했을 때와 충분히 살펴본 뒤의 판단은 어떻게 달라질까] --> V[사용자 · AI · 재판부의 판단 근거를 같은 요소로 비교]
    V --> M[사건 선정 · 단계별 정보 공개 · 판결 기록 · 근거 비교]
    M --> D[판례 확보 · 비식별화 · 중립성 · 양형기준 버전 확인]
    D --> E[사건별 출처표 · 2인 검수 · AI 근거 검증]
    E --> Q[검수에서 발견한 누락이나 편향을 사건·화면 설계에 반영]
    Q --> M

제안 서비스 구성

기획서에는 기술 스택과 배포 환경이 아직 정해져 있지 않습니다. 아래 구조는 리뷰에서 제안한 Spring Boot·PostgreSQL·pgvector를 바탕으로 그린 초안입니다. 실제로 채택할 기술과 클라우드 제공자는 팀에서 정해야 합니다.

flowchart TB
    U[사용자 브라우저] -->|HTTPS| API[Spring Boot 4 제안<br/>Spring MVC · 사용자 API]
    API --> CASE[(PostgreSQL 제안<br/>사건 · 단계별 정보)]
    API --> JUDGE[(PostgreSQL 제안<br/>사전·최종 판단 · AI 결과)]
    API --> CACHE[(Redis 제안<br/>진행 상태 · 비교 결과 캐시)]
    API -->|비교 요청| COMPARE[비교 서비스 제안<br/>저장된 판단 근거 조회]
    COMPARE --> JUDGE
    BATCH[오프라인 AI 생성·검수 제안<br/>모델 · 프롬프트 버전 기록] -->|검수 완료 결과 적재| JUDGE
    SOURCE[허가·출처 확인된 판례<br/>비식별화 · 2인 검수] -->|승인본만 적재| INDEX[(PostgreSQL + pgvector 제안<br/>사건 · 근거 청크 · 기준 버전)]
    API -->|유사 근거 검색| INDEX
    TARGET[체험 대상 사건의 실제 판결] -.->|검색 인덱스에 넣지 않음| EXCLUDED[검색 대상에서 제외]

판례 수집·비식별화·검수가 끝난 승인본만 검색 인덱스에 넣고, 체험 대상 사건의 실제 판결은 검색 대상에서 제외하는 구조입니다. Redis와 pgvector는 리뷰 제안이며 현재 구현 사실을 뜻하지 않습니다.

설계에서 잘 된 점

  • “누가 맞았나”보다 사용자의 판단이 어떻게 바뀌었는지 보여주는 데 무게를 둡니다. 사전 판단을 먼저 받고 나중에 고칠 수 없게 해 비교 기준을 보존했습니다.
  • 판단 요소를 주체·시점·방향으로 구조화하고 사건 정보를 단계별로 공개해, 기획 의도를 데이터와 화면에 연결했습니다.
  • AI 판결을 미리 생성·검수해 같은 사건에는 같은 결과를 제공하고, 대상 사건의 판결 결과가 검색에 섞이지 않도록 설계했습니다. 일관성과 정보 격리를 위한 구체적인 선택입니다.

우선 해결할 위험

현재 기획서에는 필요한 조건을 갖춘 상해·사기 사건을 확보하지 못한 것으로 나옵니다. 사건 자료가 없으면 화면, 판단 요소, 양형기준, AI 결과도 확정하기 어렵습니다. 첫 주 안에 실제 사용할 사건을 확보할 수 있을지 결정하세요. 서비스에 넣을 사건 1건을 가공하고 후보 2건도 마련하세요. 출처·확정 여부·적용 기준의 버전·이용 조건·비식별화 검수 결과를 사건별 표에 적어 두면 다음 결정을 내리기 쉽습니다. 확보가 어렵다면 판례를 더 찾을지, 이용 조건에 맞는 공개 자료를 쓸지, 대상 사건 유형을 바꿀지와 전환 시점까지 미리 정하세요.

사건 3건으로 전체 체험을 완성하도록 범위를 좁히세요. 회원 기능, 통계, 사건 확장, 실시간 AI 생성은 뒤로 미루고, 사건 선택 → 사전 판단 → 단계별 정보 확인 → 사용자 판결 → AI·실제 판결 비교까지 실제 자료로 이어지게 하세요. AI 결과를 오프라인에서 만든다면 사건 JSON, 프롬프트·모델 버전, 검수자와 수정 기록을 남겨 같은 결과를 다시 확인할 수 있게 하세요. 비교 화면의 AI 설명은 저장된 판결 근거만 사용하고, 사건 원문이 입력되지 않는지 데이터와 테스트로 확인하세요.

비식별화는 이름만 가리는 작업으로 끝나지 않습니다. 지역·기관·직업·사건 경위 조합으로 당사자를 알아볼 수 있는지, 가공 전후에 판단에 중요한 사실이 바뀌지 않았는지 두 사람이 확인할 체크리스트를 만드세요. 사건별 체크 결과와 수정 이력을 보관하면 신뢰와 구현 근거를 함께 보여줄 수 있습니다.

참고할 실제 자료

후속 검토 요청 프롬프트

최신 기획서, 비식별화된 사건 자료, 출처·검수표, AI 생성 및 비교 결과를 함께 첨부하고 아래 항목을 작성해 후속 리뷰를 요청하세요. 원본 판결문과 개인정보는 첨부하지 말고 검수된 자료만 공유하세요.

내Law남불 팀입니다. 첨부한 최신 기획서와 검수된 산출물을 기준으로, 우리 프로젝트에서 다음에 고칠 부분을 찾아 주세요.

[이번 버전의 실제 진행 상황]
- 확보한 사건과 후보 수 / 각 사건의 출처 및 확정 여부:
- 사건 이용 조건을 확인한 내용:
- 비식별화 체크리스트와 2인 검수 결과:
- 첫 주 데이터 확보 판정과, 실패 시 선택한 대안:
- MVP에 포함한 체험 단계와 뒤로 미룬 기능:
- AI 판결 생성에 사용한 모델·프롬프트 버전 및 검수·수정 내역:
- 대상 사건 판결 제외와 양형기준 버전 필터 검증 결과:
- 판단 요소 검색 재현율@k 또는 수동 검수 결과:

[리뷰 요청]
1. 이 사건 자료가 실제 체험에 쓰일 만큼 출처·이용 조건·비식별화·중립성 면에서 준비됐는지 근거를 들어 검토해 주세요.
2. 사전 판단에서 정보 공개, 최종 비교까지 이어지는 경험이 “내 판단 기준의 변화”를 보여주는지 기획서와 화면으로 확인해 주세요.
3. AI 판결과 비교 설명이 입력 자료의 근거를 벗어나지 않는지, 대상 사건의 실제 판결이 검색에 노출되지 않는지 점검해 주세요.
4. 지금 남은 가장 큰 위험 3개를 제시하고, 각각 다음 행동과 완료를 확인할 자료·테스트 기준을 적어 주세요.
5. 첨부 자료로 확인할 수 없는 내용은 사실처럼 채우지 말고, 무엇을 더 기록해야 하는지 알려 주세요.