회원 심사 단일 정책¶

문서 역할¶

역할: 규범
문서 종류: policy
충돌 시 우선 문서: 회원 심사 상태·단계별 행위는 이 문서, 관리자 역할·최대 데이터 범위는 security-access-control-policy.md, 실패 응답은 api-error-contract-policy.md
기준 성격: transition
- 최종 목표 기준을 우선 사용한다.
- 미전환 구현과의 차이는 PR/작업 보고에 명시한다.

본 문서는 회원 심사 규칙의 단일 정책 문서다. 가입 단계/설정 수정/Admin 대기 큐/Mobile 제출-재제출 동작을 한 기준으로 고정한다.

목적¶

심사 분류 회귀(가입 심사와 설정 수정 심사 혼재) 방지
Admin/Mobile/API가 같은 판정 기준 사용
제출/재제출 UX와 운영 큐 기준 고정

적용 우선순위¶

신규 구현, 리뷰, 전환 완료 판정의 규범 SoT는 이 문서를 사용한다.
관리자 역할과 GLOBAL·ASSIGNED 최대 범위는 보안/접근통제 정책을 먼저 적용하고, 이 문서는 그 범위 안에서 심사 단계별 조회·처리 행위를 더 좁힌다.
현재 운영 상태를 읽고 설명할 때는 as-is 문서인 회원 심사 FSM, 회원 라이프사이클를 함께 확인한다.
as-is 문서와 transition 목표 사이에 차이가 있으면, 목표 기준을 따르되 현재 운영 차이와 전환 범위를 PR/작업 보고에 명시한다.

기준 분리¶

회원 생애주기 상태 SoT: t_member.status
심사 상태 판정/읽기 SoT: v_member_review_status
큐 라우팅 출처 원천:
- 기본정보/소개: t_member_review_request.request_origin
- 인증: t_member_auth_review_request.request_origin
- 프로필 미디어: t_member_profile_set.request_origin
인증 요청의 현재 활성 건 판정은 t_member_auth_review_request.active_request_slot = 1을 기준으로 한다.
request_origin은 출처/큐 라우팅용 원천 데이터이며, 심사 상태 판정 SoT를 대체하지 않는다.

회원 생애주기 보조 기준¶

t_member.status의 값과 상태 흐름 설명은 회원 라이프사이클에 두되, 신규 구현/리뷰에서 생애주기 상태를 해석할 때는 이 문서의 기준 분리를 우선한다.
재가입 대기 기준은 HOLD 대기 없음, BLOCK 30일, LEAVE 14일이다.
탈퇴/차단 회원의 개인정보 자동 파기와 프로필 버전 보관 기한은 데이터 거버넌스 정책을 따른다.

가입 심사 최종 거절 비노출 계약¶

CMS 관리자의 가입 심사 최종 거절은 RETURN(반려/수정 후 재제출)과 다른 운영 판단이다. 내부 상태와 사용자 표시 상태를 하나의 값으로 취급하지 않고 아래처럼 역할별로 투영한다.

소비자	저장·판정 상태	필수 동작
API/CMS 내부	`t_member.status = REJECTED(-4)`	최종 거절 사실을 유지한다.
CMS 일반회원 심사 목록	`REJECTED` 제외	거절 즉시 처리 대기 목록에서 제거한다.
CMS 거절 회원 탭	`REJECTED` 포함	사용자가 심사 철회하기 전까지 표시한다.
Mobile 사용자	심사중 표시 상태로만 투영	수동로그인·자동로그인·앱 재진입 모두 심사중 화면을 표시한다.

필수 불변조건:

Mobile 화면, 문구, 오류에는 최종 거절 사실을 노출하지 않는다.
내부 REJECTED 회원은 심사 단계, 매니저 배정 여부와 관계없이 Mobile의 SignupReviewScreen 심사중 안내로 진입한다.
REJECTED 제한 세션은 본인 심사 현황 조회와 가입 심사 철회만 허용한다. 매칭을 포함한 일반 private API는 계속 차단한다.
가입 심사 철회는 PENDING과 REJECTED 모두 허용하며, 회원 삭제 트랜잭션이 완료되면 CMS 거절 회원 탭에서도 자동으로 사라져야 한다.
최종 거절을 단계 상태 RETURN으로 변환하거나 재제출 화면으로 연결하지 않는다.
API는 내부 REJECTED 상태와 제한 세션 범위를 판정하고, Mobile의 단일 진입 라우터는 이를 심사중 화면으로만 표시한다.

회귀 차단 시나리오:

CMS 최종 거절 후 내부 회원 상태는 REJECTED다.
해당 회원은 CMS 일반회원 심사 목록에서 제외되고 거절 회원 탭에 포함된다.
이메일·소셜 수동로그인과 저장 자격증명 자동로그인은 모두 성공하며 Mobile 심사중 화면으로 이동한다.
심사중 화면의 본인 상태 갱신은 성공하지만 다른 일반 private API는 거부된다.
사용자가 심사 철회하면 회원이 삭제되고 CMS 거절 회원 탭에서도 사라진다.

필수 인증 표시 기준¶

manager_required_auth는 매니저가 요구한 필수 인증 정책 플래그이며, 회원의 인증 완료 상태가 아니다.
manager_required_auth_types는 인증 버킷별로 어떤 t_member_auth.type이 해당 버킷에 속하는지 정의하는 타입 매핑이며, 버킷이 매니저 요구 대상인지 여부는 manager_required_auth가 나타낸다.
Mobile 설정 화면의 대표 인증 버킷(신분증, 직장/직업, 학력, 소득)은 manager_required_auth만으로 완료 표시를 하지 않는다.
대표 인증 버킷의 완료/심사중/반려 표시는 실제 t_member_auth* 데이터 중 해당 버킷 타입에 속하는 현재 인증 행의 status를 기준으로 한다.
회원이 가입 단계에서 매니저가 요구한 필수 인증을 제출하고 승인받아 준회원이 된 경우, 설정 화면은 동일한 실제 인증 행을 기준으로 해당 대표 버킷을 승인 상태로 표시한다.
type=2는 과거 통합 인증 코드로 DB row 자체는 유지하되, 현재 버킷 의미는 신분증 전용으로 해석한다. manager_required_auth_types.auth_job에는 type=2를 포함하지 않으며, Mobile도 직장/직업 버킷 완료로 중복 표시하지 않는다.
서버의 단계 판정은 계속 v_member_review_status.required_auth_status를 기준으로 하며, Mobile의 버킷별 표시는 서버가 내려준 실제 인증 행을 화면에 투영하는 용도로만 사용한다.

회원 레벨 정의 (운영 용어, v2.0)¶

가입 심사 단계에서 사용하는 레벨은 아래 4단계다.

운영 용어	코드	기준
회원전	`PRE_MEMBER`	가입 심사 진행 중이며 아직 기본정보 승인이 완료되지 않은 상태
일반회원	`GENERAL_MEMBER`	기본정보 승인
준회원	`SEMI_MEMBER`	기본정보 + 필수인증 승인
정회원	`FULL_MEMBER`	기본정보 + 필수인증 + 소개글 승인

SPECIAL_MEMBER는 가입 단계 산출 레벨이 아니다.

SPECIAL_MEMBER: 운영자 사후 수동 부여 레벨
부여 시점: 가입 심사 완료 이후
심사 큐 분류 기준은 동일하게 status/request_origin을 사용한다.
SPECIAL_MEMBER는 FULL_MEMBER 권한과 동일하게 취급한다. 추가 권한은 별도 정책 수립 시 정의한다.

레벨별 심사 정책¶

레벨	가입 단계에서 심사	설정 수정에서 심사	Admin 대기 큐	Mobile 기본 동작
회원전 (`PRE_MEMBER`)	기본정보, 소개글, 필수인증 제출분 심사	가입 미완료 상태 수정은 `SIGNUP_REVIEW`로 유지	가입/승급 심사 큐	단계별 `PENDING/RETURN/REAPPLY` 노출, `RETURN`은 재제출 유도
일반회원 (`GENERAL_MEMBER`)	해당 없음(가입 단계 통과)	심사대상 필드 수정 시 심사 생성(`SETTING_PROFILE_EDIT`)	프로필 수정 심사 큐	제출 시 `PENDING`, 반려 시 `RETURN` + 재제출
준회원 (`SEMI_MEMBER`)	해당 없음(가입 단계 통과)	소개글/기본정보/인증 수정 시 심사 생성(`SETTING_PROFILE_EDIT`)	프로필 수정 심사 큐	동일 규칙(`PENDING/RETURN/REAPPLY`)
정회원 (`FULL_MEMBER`)	해당 없음(가입 단계 통과)	기본정보/소개/인증/프로필 변경 시 심사 생성(`SETTING_PROFILE_EDIT`)	프로필 수정 심사 큐	동일 규칙(`PENDING/RETURN/REAPPLY`)

심사 대상 항목¶

요청 맥락별 심사/비심사 대상은 아래와 같이 고정한다.

구분	일반 심사 제출 (`SIGNUP_REVIEW`)	설정 수정(일반/준/정회원, `SETTING_PROFILE_EDIT`)
기본정보 심사 항목	닉네임, 직업, 키	직업, 키, 거주지, 학력, 결혼경험여부, 결혼계획, 체형, 어필포인트
기본정보 비심사 항목	해당 없음(제출분 심사)	닉네임(설정수정 입력 불가), 가족관계, 주량, 종교, 흡연여부
프로필정보(미디어) 심사 항목	사진 3~7장(최소 3장 필수, 추가 4장 선택), 여성 영상은 선택 제출(미제출 허용)	제출한 이미지/영상만 심사(사진 최소 3장 유지, 여성 영상은 제출 시 심사)
소개글 심사 항목	`about_me`, `intro`(제출분)	`about_me`, `intro`(소개 제출 시)
인증 심사 항목	`t_member_auth`, `t_member_auth_review_request`	`t_member_auth`, `t_member_auth_review_request`
프로필 이미지/영상 저장 SoT	`t_member_profile_set*`	`t_member_profile_set*`

해석 규칙:

일반 심사 제출은 승급 심사 기준으로 기본정보(닉네임/직업/키)와 프로필정보(사진 3~7장, 여성 영상 선택 제출)를 적용한다.
설정 수정은 가입 단계의 필수 묶음을 재강제하지 않고, 위 표의 심사 항목 변경분만 심사를 생성한다.
설정 수정에서 직업/키는 심사 대상이며, 닉네임은 입력 불가 항목으로 심사를 생성하지 않는다.
설정 수정의 나머지 비심사 항목은 즉시 반영한다.
정회원 설정에서 기존 프로필 영상을 삭제하는 행위는 영상 제출·교체와 다른 즉시 반영 명령이다. 영상 삭제 자체는 심사 요청을 만들지 않으며, 같은 제출에서 바뀐 사진만 SETTING_PROFILE_EDIT 심사 대상으로 남긴다.
Admin 가입/승급 심사 큐(일반회원 승급 심사 화면)에서는 닉네임, 직업, 키와 제출된 프로필정보(이미지/영상)를 한 묶음으로 심사한다.

Mobile 미디어 선택/Crop 정책¶

Mobile에서 심사 제출 전에 적용하는 미디어 선택/Crop 기준은 아래와 같이 고정한다.

제출 영역	Mobile 선택/Crop 기준	저장/심사 SoT
인증 서류 이미지	Crop 없이 원본 비율을 유지한다. 직사각형 서류 제출을 허용한다.	`t_member_auth`, `t_member_auth_review_request`
프로필 사진	기존과 같이 정사각형 Crop을 적용한다.	`t_member_profile_set*`
미니프로필 사진	기존과 같이 정사각형 Crop을 적용한다.	`t_member_profile_set*`
프로필/인증 동영상	Crop을 적용하지 않는다.	`t_member_profile_set*` 또는 동영상 업로드 결과
스퀘어/미팅/채팅 등 비심사 이미지	이번 회원 심사 정책 변경 대상이 아니며, 별도 제품 정책이 없으면 기존 Mobile 동작을 유지한다.	각 기능의 기존 저장소

적용 규칙:

인증 서류 이미지는 가입 단계, 설정 수정, 매칭 필수 인증 요청 등 AuthScreen/AuthExamImageScreen 기반 제출 경로에서 모두 같은 no-crop 기준을 사용한다.
프로필 사진과 미니프로필 사진은 정사각형 전제를 유지해 목록/프로필 카드/심사 화면의 기존 표시 비율을 보존한다.
서버/API/Admin는 업로드된 파일 경로와 심사 요청 상태를 판정하며, 클라이언트의 Crop 여부를 다시 추론하지 않는다.
이 정책은 제출 전 Mobile 미디어 선택 기준이며, 심사 큐 라우팅 기준(request_origin, active_request_slot, v_member_review_status)을 변경하지 않는다.

설정 수정 즉시 반영(심사 비대상)¶

기존 프로필 영상의 명시적 삭제
가족관계, 주량, 종교, 흡연여부
appeal_extra
instagram_id, youtube_id, sns_id
i am, i want, Q/A 설정 계열

프로필 영상 삭제 계약¶

Mobile 정회원 본인 삭제와 기존 CMS 삭제 operation은 서버 내부의 같은 원자적 삭제 명령으로 수렴한다. SPECIAL_MEMBER는 기존 정책대로 FULL_MEMBER와 동일하게 허용한다. 프로필 수정 payload의 video: ''를 삭제 신호로 해석하지 않는다.
삭제 명령은 프로필 버전과 레거시 회원 정보에 남은 영상 참조를 함께 제거한다. 같은 프로필 버전의 사진, 사진별 심사 상태와 반려 사유는 변경하지 않는다.
진행 중이거나 반려된 사진 심사와 사진 제출 가능 여부는 기존 영상의 삭제 진입을 막지 않는다. 영상 삭제와 함께 제출 가능한 사진 변경이 있으면 삭제 성공 뒤 사진 변경만 별도 심사 명령으로 처리한다.
삭제 전 영상 심사 상태가 집계에 영향을 주던 프로필 버전은 남은 사진 상태만으로 집계 상태를 다시 계산한다. 따라서 사진 변경이 있으면 사진 심사만 Admin 큐에 유지되고, 영상은 현재 프로필·미리보기·매칭 노출에서 즉시 사라진다.
삭제는 멱등이다. 이미 영상 참조가 없는 재호출도 성공한다.
CMS 삭제는 같은 transaction에서 현재 관리자 레코드의 Super Admin 역할을 다시 확인한다. 일반 클럽매니저는 대상 회원의 CHARGE 배정 여부와 무관하게 UI와 API 모두 NONE이다.

Admin 큐 라우팅 정책¶

큐	포함 조건
가입/승급 심사 큐	`request_origin = SIGNUP_REVIEW`
정회원 승급 심사 큐	`request_origin = SIGNUP_REVIEW` + `required_auth_status = APPROVED`
프로필 수정 심사 큐	`request_origin = SETTING_PROFILE_EDIT` + 처리 가능 상태(`PENDING`, `RETURN`, `REAPPLY`)
반려/재심사 이슈 큐	`RETURN` 상태만 출처(`SIGNUP_REVIEW`, `SETTING_PROFILE_EDIT`)로 분리 표시

소개글 심사의 표준 신규 생성 상태¶

업무 흐름	회원 생애주기	요청 출처	생성 기준
정회원 승급 소개글 심사	`PENDING`	`SIGNUP_REVIEW`	기본정보와 필수 인증이 승인된 준회원의 소개글 요청을 생성한다.
설정의 소개글 수정 심사	`NORMAL`	`SETTING_PROFILE_EDIT`	승급이 끝난 정상 회원의 기존 승인 프로필을 유지하고 수정 요청을 별도로 생성한다.

신규 서비스 write와 정상 합성 데이터는 위 조합만 생성한다.
NORMAL + SIGNUP_REVIEW 소개글 요청은 과거 요청을 조회·처리하기 위한 호환 상태다. 신규 write와 정상 합성 데이터에서 생성하지 않는다.
호환 상태를 제거하려면 실제 잔존 데이터와 요청 처리 가능 여부를 먼저 확인하고 별도 이관·제거 작업으로 진행한다.

필수 원칙:

member_level은 표시 용도이며 큐 필터 기준으로 사용하지 않는다.
request_origin이 없거나 미정의면 어떤 큐에도 넣지 않는다(Fail-closed).
프로필 이미지/영상도 t_member_profile_set.request_origin이 큐 라우팅의 필수 기준이며, 값이 없거나 미정의면 Admin 목록/상세/액션 모두에서 제외한다(Fail-closed).
Admin 정상 회원 목록의 상태 보조 표시는 큐에서 실제 처리 가능한 display_targets가 있을 때만 노출한다. v_member_review_status의 미제출/누락 상태만으로는 정상(심사대기)를 표시하지 않는다.
호환 대상인 정상 회원의 소개글 승급 심사는 SIGNUP_REVIEW intro 항목의 처리 가능 상태(PENDING, RETURN, REAPPLY)가 있을 때만 상태 보조 표시 대상으로 본다.
프로필 이미지/영상의 Admin 표시/큐 판정은 t_member_profile_set의 최신 non-normal 버전(created_at DESC, id DESC) 1건을 기준으로 한다. 과거 non-normal 버전은 현재 처리 대상으로 표시하지 않는다.
인증 심사 큐(full-*, profile-edit)의 대기 판정은 t_member_auth_review_request(active_request_slot=1)의 request_origin/request_status를 필수 기준으로 하며, 필요 시 실제 인증 데이터와 교집합으로 판정한다.
인증 request_origin이 큐 목적과 불일치하거나 누락되면 해당 요청은 큐에서 제외한다(Fail-closed).

CMS 클럽매니저의 `[신청] 일반회원(최초)` 조회 정책¶

클럽매니저 계정에도 CMS 회원관리의 [신청] 일반회원(최초) 탭을 표시한다.
일반 클럽매니저는 가입 신청 시 현재 클럽매니저를 선택한 회원만 이 탭에서 조회한다.
위 범위 안의 신청 회원 목록과 상세 표시 정보는 슈퍼어드민 화면과 같은 기준을 사용한다.
일반 클럽매니저에게는 이 탭의 심사 승인·거절 권한을 부여하지 않는다. Admin은 승인·거절 버튼을 비활성 또는 비노출 처리하고, API는 같은 요청을 권한 실패로 거부한다.
이 제한은 [신청] 일반회원(최초)의 승인·거절 액션에 적용하며, 다른 심사 단계의 담당자 권한을 변경하지 않는다.
기존 [신청] 일반회원(최초) 화면 요구의 완료 범위는 담당 신청 회원 조회와 승인·거절 버튼 비노출이다. 서버 직접 요청 차단은 이 권한 SoT의 전환 범위이며, 기존 화면 요구의 완료 여부를 소급해 바꾸지 않는다.
Admin 테스트는 슈퍼어드민의 버튼 노출, 일반 클럽매니저의 담당 신청 회원 조회, 일반 클럽매니저의 승인·거절 버튼 비노출을 각각 검증한다. API 테스트는 일반 클럽매니저의 직접 승인·거절 요청이 실패하고 슈퍼어드민 요청만 허용되는지 검증한다.

CMS 최초 신청 이외 심사 단계의 권한¶

Super Admin은 이 문서가 처리 가능한 상태로 판정한 모든 심사 단계의 목록·상세 조회와 승인·반려를 GLOBAL 범위에서 수행할 수 있다.
일반 클럽매니저는 현재 자신에게 전담(CHARGE) 배정된 회원만 목록·상세에서 조회한다.
위 범위에서 [일반회원 합격자], [준회원 승급심사 신청], [준회원 합격자], [정회원 승급심사 신청], [심사항목 반려], [프로필 변경 신청]은 이 문서가 처리 가능한 상태로 판정한 승인·반려를 수행할 수 있다.
최종 REJECTED 회원을 모은 [심사거절] 목록·상세는 Super Admin의 GLOBAL 범위이며 일반 클럽매니저에게는 NONE이다.
공유(SHARE) 배정 또는 배정이 없는 회원은 일반 클럽매니저의 심사 조회·처리 범위에 포함하지 않는다.
목록 필터와 별개로 상세 조회, 승인과 반려 operation에서 현재 CHARGE 배정을 다시 확인한다.

전환 기준 (as-is -> to-be)¶

DB/API/Admin/Mobile 전환 완료 전까지 as-is와 to-be 차이를 PR 본문에 명시한다.
클럽매니저 최초 일반회원 신청 조회 전환 완료 조건: Admin이 현재 클럽매니저를 선택한 신청 회원만 표시하고 승인·거절 버튼을 제공하지 않으며, API가 일반 클럽매니저의 직접 승인·거절 요청을 거부하고 역할별 Admin·API 테스트가 같은 결론을 검증한 상태다.
최초 신청 이외 심사 단계 권한 완료 조건: 일반 클럽매니저의 현재 CHARGE 회원은 단계별 허용 상태에서만 조회·승인·반려되고, SHARE·무배정·타 전담 회원의 직접 상세/승인/반려 요청은 거부되며 역할·배정별 Admin·API 테스트가 같은 결론을 검증한 상태다.
큐 중복(동일 요청이 2개 큐에 동시 노출) 0건을 전환 완료 조건으로 둔다.

심사 상태 동기화 호출 정책¶

syncMemberReviewStatusByMemberId 호출은 쓰기 경계(제출/승인/반려/수정 저장)로 제한한다.
조회/미들웨어 경로에서는 sync를 호출하지 않고 v_member_review_status 읽기 결과만 사용한다.
sync 실패 응답은 API 에러 계약 정책의 ErrorData로 통일한다.
sync 실패는 fail-closed를 기본값으로 하며, 트랜잭션 경로에서는 rollback 후 종료한다.

전담 클럽매니저·필수 인증 변경 호환 상태¶

회원 심사 v2.0 전환 전 생성된 회원, 전담 클럽매니저가 없었다가 배정된 회원, 심사 도중 전담 클럽매니저나 클럽매니저의 필수 인증 설정이 바뀐 회원은 아래 세 데이터를 구분해서 판정한다.

데이터	의미	현재 동기화 경로의 역할
현재 전담(`CHARGE`) 클럽매니저의 `manager_required_auth`	현재 클럽매니저 프로필의 필수 인증 설정	동기화 시 클럽매니저 연결과 설정의 준비 상태를 검증한다.
`member-review.required-auth-policy`	해당 회원에게 적용해 온 회원별 필수 인증 정책	`v_member_review_status.required_auth_status` 계산 기준이다. 기존 정책이 있으면 동기화가 현재 클럽매니저 설정으로 자동 덮어쓰지 않는다.
`member-review.auth-state`와 인증 증거	회원이 실제 제출·심사받은 인증 데이터	하나 이상의 처리 상태가 있으면 필수 인증 단계가 시작된 것으로 본다.

현재 구현에서 유효한 회원의 필수 인증 guard로 CMS 저장이 실패하는 전체 조건은 아래 조합이다. 이 중 현재 운영 사례의 정상 진입 상태는 PENDING이다.

member.status != NORMAL
AND 실제 인증 데이터의 처리 상태가 하나 이상 존재
AND 현재 전담 클럽매니저 준비 상태가 유효하지 않음

현재 전담 클럽매니저 준비 상태가 유효하지 않은 경우는 폐쇄형으로 아래 네 가지다.

`guardCode`	조건
`MANAGER_LINK_MISSING`	전담(`CHARGE`) 배정이 없다.
`MANAGER_LINK_AMBIGUOUS`	전담(`CHARGE`) 배정이 2건 이상이다.
`MANAGER_PROFILE_MISSING`	배정된 관리자·클럽매니저 프로필을 확인할 수 없다.
`MANAGER_REQUIRED_AUTH_MISSING`	클럽매니저 프로필의 필수 인증 설정이 모두 비어 있다.

조건별 현재 동작은 아래와 같다.

회원·데이터 상태	현재 동작	해석
`PENDING` + 실제 인증 데이터 있음 + 전담 클럽매니저 준비 실패	`REVIEW_STATUS_REQUIRED_AUTH_GUARD_ISSUE`로 동기화 실패, 같은 트랜잭션의 회원정보·배정 변경 rollback	이 절의 직접 실패 조건
`PENDING` + 실제 인증 데이터 없음 + 전담 클럽매니저 준비 실패	guard 예외는 발생하지 않지만 `NORMAL` 승격 조건을 충족하지 못함	회원별 필수 인증 정책 행의 존재만으로 실패하지 않음
`NORMAL` + 실제 인증 데이터 있음 + 전담 클럽매니저 준비 실패	서버 경고를 남기고 동기화 계속	이미 승격된 회원을 이 guard로 소급 차단하지 않음
`REJECTED` 또는 `INACTIVE` + 실제 인증 데이터 있음 + 전담 클럽매니저 준비 실패	guard 오류로 동기화 실패	가입 승격의 정상 진입 상태가 아니므로 호출 경로와 회원 생애주기를 별도 조사
전담 클럽매니저 준비 성공 + 회원별 필수 인증 정책과 현재 설정 불일치	guard는 통과하며 기존 회원별 정책으로 심사 상태 계산	불일치 자체는 저장 실패 조건이 아니지만 표시 레벨·필수 인증 단계가 현재 설정과 다를 수 있음

전담 클럽매니저나 필수 인증 설정을 변경했다는 사실만으로는 실패하지 않는다. 변경 결과가 위 직접 실패 조건을 만들었는지와, 기존 회원별 필수 인증 정책과 현재 설정이 달라졌는지를 각각 확인한다. CMS의 심사 상태 동기화에 실패했습니다. 잠시 후 다시 시도해주세요. 문구는 여러 error_code가 함께 사용하는 공통 문구이므로 이 문구만으로 전담 클럽매니저 문제라고 단정하지 않는다.

CMS 회원정보 저장은 닉네임처럼 필수 인증과 무관한 필드를 수정해도 같은 쓰기 경계에서 심사 상태를 동기화한다. 따라서 이 조합에서 닉네임 값 자체가 거부되는 것이 아니라, 저장 뒤 전체 심사 불변조건을 확인하는 동기화가 실패해 회원정보와 배정 변경이 함께 rollback된다.

운영 진단 순서:

실패 응답의 error_code와 request_id를 확보한다.
error_code = REVIEW_STATUS_REQUIRED_AUTH_GUARD_ISSUE이면 서버 로그의 guardCode, stageStatus, authRowCount를 확인한다. REVIEW_STATUS_SYNC_FAILED나 다른 error_code이면 이 호환 조건으로 추정하지 않고 해당 실패 원인을 조사한다.
회원 생애주기가 PENDING, NORMAL, REJECTED, INACTIVE 중 어디에 해당하는지와 v_member_review_status의 단계 상태를 확인한다.
현재 전담(CHARGE) 배정이 정확히 1건인지, 배정된 클럽매니저 프로필이 존재하는지, 필수 인증 설정이 하나 이상인지 확인한다.
회원별 필수 인증 정책과 현재 클럽매니저 설정을 비교하고, 실제 인증 데이터의 타입·상태가 어느 정책에 따라 제출됐는지 확인한다.
직접 guard 실패와 과거 정책 불일치를 분리해 처리한다.

운영 처리와 Exit Gate:

직접 guard 실패는 의도한 전담 클럽매니저를 정확히 1명으로 복구하고 유효한 필수 인증 설정을 확정한 뒤 같은 저장을 다시 검증한다.
회원별 필수 인증 정책과 현재 설정이 다르면 회원에게 적용할 정책을 먼저 확정한다. 현재 클럽매니저 설정만 보고 기존 회원별 정책이나 승인 이력을 자동 덮어쓰지 않는다.
영속 데이터 정정이 필요하면 대상 회원, 의도한 정책, 인증 타입 매핑, 변경 전후 값과 검증 결과를 남기는 별도 데이터 정정 작업으로 수행한다. 파생 조회인 v_member_review_status나 표시용 member_level을 직접 수정하지 않는다.
호환 상태의 Exit Gate는 전담 클럽매니저 준비 상태가 유효하고, 의도한 회원별 정책과 실제 인증 데이터의 관계가 확인되며, 동기화 후 v_member_review_status가 의도한 심사 단계를 표시하고 t_member.status가 기대한 생애주기를 유지하거나 PENDING -> NORMAL로 전이하며, 재시도한 저장이 성공한 상태다.
자동 정책 재기준화나 기존 회원 일괄 이관이 제품 요구로 확정되기 전까지 이 절은 현행 호환·운영 판정으로 유지한다. 해당 자동화가 확정되면 별도 구현 범위와 제거 가능한 호환 조건을 추적한다.

API 에러 계약 (`MEMBER`)¶

공통 응답 envelope은 API 공통 응답 계약 정책을, 실패 ErrorData는 API 에러 계약 정책을 단일 SoT(단일 기준)로 따른다. 이 문서는 도메인 적용 범위와 도메인별 error_code 예시만 기록한다.

적용 범위:

POST /app/member/request-review/auth
POST /app/member/deleteAuth

응답 계약:

API 서버는 descriptor-first ErrorData 응답 경계를 사용한다.
실패 응답은 공통 응답 envelope의 { ok: false, error: ErrorData }와 request_id를 사용한다.
Mobile/Admin 공통 실패 처리와 릴리스 근거 연결은 기술 부채 정리의 API 응답 공통 계약 cutover 인덱스 잔여 범위로 추적한다.

규칙:

이 도메인의 error_source는 MEMBER다. MEMBER_AUTH_REVIEW는 error_code segment로만 사용한다.
error_code, error_action, error_context 예시는 아래 표만 사용한다.
Mobile/Admin 분기 우선순위는 API 에러 계약 정책을 따른다.
응답 body에서 error_context 밖의 legacy top-level 상세 필드는 사용하지 않는다.

예시:

`error_source`	`error_code` 예시	`error_action`	`error_context` 예시
`MEMBER`	`MEMBER_AUTH_REVIEW_REQUIRED_AUTH_DELETE_FORBIDDEN`	`FIX_REQUEST`	`{}`
`MEMBER`	`MEMBER_AUTH_REVIEW_REQUIRED_AUTH_MANAGER_PROFILE_MISSING`	`CONTACT_SUPPORT`	`{}`

member_id, manager_id, required_auth_types 같은 내부 식별자와 진단값은 서버 로그에만 남기고 public ErrorData.error_context에는 넣지 않는다.

Mobile 제출/재제출 정책¶

단계 상태	화면 동작	사용자 액션
`UNSUBMITTED`	미제출 안내	제출 가능
`PENDING`	심사중 안내	중복 제출 차단
`RETURN`	반려 사유 표시	재제출 가능
`REAPPLY`	재심사중 안내	추가 중복 제출 차단
`APPROVED`	승인 상태 표시	다음 단계 진행

재제출 규칙:

RETURN 상태 항목만 재제출 허용
재제출 시 상태는 REAPPLY로 전이
제출/재제출 UI 판단은 data.access_context.review_status 기준만 사용

운영 안내 문구¶

Admin 심사 적용 완료 토스트(pending_complete_notice): 심사 이력이 반영되어 정회원으로 승급되었습니다.

회귀 방지 금지 사항¶

t_member_review_stage_snapshot 직접 조회로 심사 판정 금지
member_level로 심사 큐 분류 금지
request_origin fallback(coalesce)로 출처 추측 금지
클라이언트가 서버 심사 판정을 재구현하는 로직 금지