한신대 개선 계획 대레드팀 검토

작성일: 2026-07-03 대상: docs/ops/hanshin-feedback-improvement-plan-2026-07-03.md, docs/redteam/hanshin-feedback-plan-redteam-2026-07-03.md 상태: 대레드팀 1차 완료 / 계획 균형 보정 반영

1. 판정

기존 레드팀은 실제 위험을 잘 잡았다. 다만 몇 조건이 “1차 개선을 안전하게 작게 낸다”가 아니라 “최종형을 한 번에 닫는다”로 비대해졌다.

본래 목적은 한신대 사용자가 실제로 겪은 반복 발화, 문맥 오해, 리뷰 UX 혼란, 교수자 설명 부족을 빠르게 줄이는 것이다. 그래서 레드팀 경고는 유지하되, 사용자 가치 기준으로 등급화해야 한다.

핵심 판정:

P1 내부의 role mapping + history injection은 반드시 원자 패치다.
P2/P3/P4는 P1과 같은 원자 배포 단위가 아니다. 독립적으로 빠르게 배포할 수 있다.
privacy proof는 API·저장·export 계약이지, 리뷰 화면 자연어화를 막는 조건이 아니다.
synthetic fallback은 fallback을 저장할 때 필요한 계약이다. 1차 품질 게이트는 fallback 저장 없이도 낼 수 있다.
교수자 설명은 임상 확정 표현을 피해야 하지만, 현재 구현과 한계를 설명하는 패널은 오히려 지금 필요하다.

2. 과잉 방어 지점

C1. P2 fallback 경고가 품질 게이트 전체를 늦출 위험

레드팀의 “fallback을 실제 내담자 발화처럼 저장하면 안 된다”는 경고는 맞다. 하지만 이것이 “품질 게이트를 구현하지 말라”로 번지면 과잉이다.

1차에서는 fallback을 저장하지 않으면 된다. 역할 메타발화, 2턴 이후 재인사, 직전 내담자 발화와 거의 같은 응답처럼 명백한 결함은 먼저 감지하고 1회 재생성한다. 재생성 후에도 실패하면 client turn을 저장하지 않고 사용자에게 재시도 가능한 오류를 보여준다.

저장형 fallback, synthetic metadata, 평가 제외 규칙은 2차다.

C2. P3 privacy proof가 UI 개선을 누르면 안 된다

API/저장/export에서 [NAME], [ORG], [PHONE] 같은 마스킹 토큰을 보존하는 건 맞다. 하지만 사람이 보는 리뷰 화면의 일반 transcript까지 반드시 토큰 그대로 보여야 하는 건 아니다.

1차에서는 API와 evidence quote는 마스킹을 유지하고, 일반 UI 렌더링에서만 자연어화한다. 이 방식이 privacy proof와 사용자 경험을 동시에 만족한다.

C3. P4 임상 경고가 설명 패널을 늦추면 안 된다

교수자 질문은 제품 신뢰와 직결된다. “임상 확정 전이라 말할 수 없다”만 반복하면 한신대가 궁금해한 지점을 해결하지 못한다.

설명 패널은 현재 구현과 임상팀 검수 필요 범위를 분리하면 안전하게 먼저 낼 수 있다.

예시:

DSM: 진단이 아니라 페르소나 행동 차원과 증상 차원을 구성하는 참고 축.
CBT: 선택 이론 모드가 프롬프트/평가에 반영되는 수준.
개방도: LLM 감이 아니라 state machine 기반 시뮬레이션 상태값.
약물/검사: 처방·진단 도구가 아니므로 권유 기준은 임상팀 확정 전 자동화하지 않음.

C4. 테스트 제안이 전체 회귀 게이트처럼 읽힌다

P1 차단 테스트는 다음으로 충분하다.

persona role mapping
gateway client-only history injection
evaluator/structured output no-history
기존 gateway split 계약 갱신

voice, 전체 review, Playwright, stream buffering 장기 매트릭스는 통합 검증 또는 2차 안정화에 둔다.

3. 유지해야 하는 레드팀 경고

P1 내부 원자성은 유지한다. role mapping 또는 gateway history injection 중 하나만 고치면 역효과가 날 수 있다.
resident session은 1차에서 켜지 않는다. client/eval context 혼선 위험이 현실적이다.
API/저장/export 마스킹 불변식은 유지한다.
저장되는 fallback은 실제 내담자 발화처럼 섞으면 안 된다.
임상 표현은 보수적으로 둔다. 설명 패널은 진단/처방 판단이 아니라 교육용 시뮬레이션의 현재 구현과 한계를 설명해야 한다.

4. 균형 잡힌 1차 MVP

P1a. 컨텍스트

counselor -> user, client -> assistant 매핑 수정.
client 요청에서만 최근 대화 history를 라벨링해 마지막 user payload에 주입.
evaluator/structured 요청에는 client history를 주입하지 않는 단위 테스트.

P3a. 리뷰 UX

API는 masked token 유지.
리뷰 화면 일반 transcript는 렌더링 단계 자연어화 허용.
raw error는 학습자용 문구로 매핑.
fast-loop/deep-loop 라벨 추가.
clientFeedback 라벨을 “마지막 내담자 반응”처럼 사실에 맞게 수정.

P2a. 출력 품질

역할 메타발화 차단.
2턴 이후 재인사 차단.
직전 내담자 발화와 거의 동일한 응답 차단.
1회 재생성 후 실패하면 client turn 미저장 + 재시도 가능 오류.

P4a. 교수자 설명

SessionReview에 “현재 구현 / 임상팀 확정 필요” 2열 또는 “현재 구현됨 / 제품 한계 / 임상팀 검수 필요” 3단 패널 추가.
임상 루브릭·약물 권유 기준·골든셋은 미확정으로 표시하되, 현재 제품이 실제로 하는 일은 명확히 답한다.

5. 2차로 미룰 것

resident session namespace
prompt caching 복구
cleanup/restart recovery
complete K-pair window 정교화
synthetic fallback 저장 스키마와 모든 read-model exclusion
stream 첫 문장 버퍼링 전면 도입
fast-loop/deep-loop 충돌 reconciliation
CBT chain/citation/rubric
H2 골든셋

6. 계획 문서 반영 문장

“레드팀 차단 조건은 사용자 가치 기준으로 등급화한다. P1 내부의 role mapping + history injection은 원자 패치로 유지하되, P2/P3/P4는 독립적으로 빠르게 배포 가능한 1차 개선으로 분리한다.”
“P1 차단 테스트는 persona role mapping, gateway client-only history injection, evaluator no-history 계약으로 한정한다. voice/Playwright/전체 review 회귀는 P1 필수 차단이 아니라 통합 검증 단계로 둔다.”
“마스킹 토큰 보존은 API·저장·export 계약이다. 리뷰 화면의 일반 transcript 표시에서는 동일 데이터를 렌더링 단계에서 자연어화할 수 있다.”
“1차 품질 게이트는 fallback 저장을 목표로 하지 않는다. 재생성 후에도 역할 메타발화가 남으면 client turn을 저장하지 않고 사용자에게 재시도 가능한 오류로 표시한다.”
“교수자 설명은 ‘못 한다’가 아니라 ‘현재 제품이 하는 것’과 ‘임상팀 확정이 필요한 것’을 분리해 답한다.”
“resident session, synthetic fallback 저장, stream buffering, fast/deep reconciliation은 P1/P3 이후 2차 안정화 범위로 둔다.”

6.9 KiB Raw Blame History