RIAHN CONNECT — 기능 상세 (16-A~O) — 234개

목적: 시술 중 추가된 분을 결제에 반영하고, 그 분의 담당자를 원 시술과 분리해 귀속한다
트리거: 결제 화면에서 항목 추가. 또는 디자이너가 시술 기록(G-01)에 추가분을 입력
입력: 원 시술 라인 · 추가 메뉴(K-03) · 추가분 담당 디자이너
규칙: 추가분은 별도 라인으로 쌓는다. 담당자가 원 시술과 다를 수 있으므로 라인 단위로 귀속을 잡는다. 소요시간이 늘면 후속 예약과 충돌하는지 A-05로 확인한다
결과: 결제 라인 추가, C-10 귀속에 라인별 담당 반영
예외: 추가로 인해 후속 예약이 밀리면 경고를 띄우고 A-03 변경으로 넘긴다

RC-C-03결제수단1차

목적: 실제 수납 수단을 기록해 정산(C-09)과 대사가 가능하게 한다
트리거: 금액 확정 후 수단 선택
입력: 사용 가능한 수단 목록(K-15 PG·VAN 설정) · 카드 단말 연결 상태(K-10)
규칙: 카드·현금·간편결제·인앱결제·계좌이체. 수단별로 정산 주기·수수료·입금 주체가 다르므로 수단은 금액과 함께 반드시 저장한다 — C-09 대사가 여기에 의존한다. 카드는 승인번호와 카드사, 간편결제는 세부 수단까지 남긴다. 두 개 이상 섞이면 C-23으로 넘어간다
결과: 결제 수단별 금액 확정. 카드는 승인번호, 간편결제는 세부 수단까지 남긴다
예외: 단말 미연결·승인 거절·통신 실패를 구분해 표시한다. 거절과 실패는 대응이 다르다

RC-C-23분할 결제1차

목적: 회원권·포인트·카드·현금이 섞인 실제 결제를 한 건으로 처리한다. 미용실에서 단일 수단 결제가 오히려 드물다
트리거: C-03에서 두 번째 수단을 추가
입력: 각 수단의 가용 한도 — 회원권 잔액(C-16), 포인트 잔액(B-21), 카드 승인 가능액
규칙: 잔액성 수단(회원권·포인트)을 먼저 차감하고 나머지를 현금성 수단으로 받는다. 차감 순서를 화면에 노출해 고객이 확인할 수 있게 한다. 각 수단의 금액 합이 총액과 일치하는지 확정 직전에 검증한다
결과: 수단별 금액 배분 확정. 각 라인이 C-10 귀속과 C-09 정산에 각각 반영
예외: 잔액 차감은 성공했는데 카드가 거절되면 차감을 되돌려야 한다. 부분 성공 상태로 두지 않는다. 부분취소(C-05)는 수단별 역순으로 복원한다

RC-C-11예약금 정산1차

R2SC-M08 SC-M14

목적: 미리 받은 예약금을 최종 결제에서 차감해 이중 수납을 막는다
트리거: 예약금이 있는 예약을 결제 화면으로 불러올 때 자동
입력: 예약금 결제 이력(A-12, C-22) · 취소/노쇼 정책(K-05)
규칙: 예약금은 두 경로로 들어온다 — 현장 선결제(A-12)와 비대면 링크(C-22). 어느 쪽이든 선수금이므로 방문이 완료된 시점에 매출로 전환한다. 취소·노쇼 시에는 K-05 정책에 따라 몰수 또는 환불로 분기한다. 몰수분을 매출로 볼지는 D-16 집계 기준을 따르며, 환불은 C-05 경로를 탄다
결과: 최종 결제금액에서 차감, 예약금의 매출 전환 확정
예외: 예약금이 있는데 방문이 완료되지 않은 채 기간이 지난 건은 목록으로 남긴다

RC-C-22비대면 결제 링크1차

R2SC-M14 SC-M02

목적: 전화·채널 예약 고객에게 예약금이나 잔금을 대면 없이 받는다. A-12 예약금의 실행 수단
트리거: 예약 등록(SC-M06) 또는 결제 화면에서 링크 발송
입력: PG 링크결제 설정(K-15) · 발송 채널과 발신번호(K-13) · 미입금 자동취소 시간(K-05)
규칙: 링크 생성 시 예약 슬롯을 결제대기(홀드) 로 잡는다(A-08). 유효기간이 지나면 홀드를 풀고 예약을 자동 취소한다. 입금 확인은 PG 웹훅으로 받으며 수동 확인 경로도 둔다
결과: 입금 확인 시 예약 확정, 결제 이력에 선결제로 기록
예외: 웹훅 유실에 대비해 조회로 대사할 수 있어야 한다. 홀드가 방치되면 슬롯이 잠기므로 만료 임박 건을 SC-M02에 노출한다

RC-C-06할인·쿠폰·타임딜 적용1차

목적: 할인을 규칙대로 적용하고 최종가가 임의로 변형되지 않게 한다
트리거: 결제 화면에서 할인 적용
입력: 쿠폰 보유 현황(E-09) · 타임딜 조건(K-08) · 가격·할인 상한(K-04)
규칙: 중복 할인 가능 여부를 규칙으로 판정한다. 매장이 임의로 내릴 수 있는 하한을 K-04가 정하고 그 아래로는 못 내린다 — 가맹사업법 확인 대상이다. 할인 유형과 적용 근거(쿠폰ID·이벤트ID)를 반드시 남긴다
결과: 정가·할인액·실매출액 3종을 분리 저장. D 도메인 매출 분석이 이 분리에 의존한다
예외: 상한 초과 할인은 승인(SC-M43)을 태우거나 차단한다 — 어느 쪽인지 미결
미결: 매장 할인 재량 범위와 초과 시 처리 (승인 vs 차단)

RC-C-07영수증·현금영수증1차

목적: 법정 증빙을 발행하고 재발행 요청에 응한다
트리거: 결제 확정 직후 자동, 또는 사후 재발행 요청
입력: 결제 건 · 고객 식별정보(현금영수증) · 프린터 연결(K-10)
규칙: 분할 결제는 수단별 내역이 한 장에 보이게 발행한다. 재발행은 원본과 동일 번호로 하되 재발행 표시를 남긴다
결과: 발행 이력 저장
예외: 프린터 미연결 시 전자 발행으로 대체하고 나중에 출력할 수 있게 한다

C-2. 선불 상품 — 회원권·정기권 — 9개

[정책 전제] 회원권·정기권·선불권은 1차 구현 범위로 확정됐다(2026-08-10 이원섭). 미창조의 목표가 헤어짱·핸드SOS 대체이고, 회원권은 미용실 매출의 상당 부분을 차지하는 선수금 상품이라 이것 없이는 외부 CRM을 끊을 수 없다.

규제 분기점은 "누가 발행하고 어디서 쓰는가"다. 매장이 발행하고 그 매장에서만 쓰면 자가발행 성격이지만, 본사가 발행해 490개 가맹점(각각 별개 사업자)에서 쓰게 하면 제3자 사용이 되어 선불업 등록·선불충전금 별도관리 의무 검토 대상이 된다. → 데이터 모델에 사용가능범위(매장전용 / 브랜드공용) 필드를 1차부터 넣되 기본값은 매장전용으로 한다. 나중에 붙이면 발행된 회원권 전체를 마이그레이션해야 한다.

RC-C-04회원권·정기권 판매1차

R2SC-M15 SC-M14

목적: 선불 상품을 팔고 발급한다. 이 도메인의 진입점
트리거: 고객이 회원권 구매 의사를 밝힘. 또는 결제 화면에서 상품으로 추가
입력: 상품 정책(K-14 — 권종·유효기간·환불율·사용가능범위) · 결제수단(C-03)
규칙: 횟수권 / 금액권 / 기간권 3종을 구분해 발급한다. 세 종의 차감 방식이 서로 다르므로 발급 시점에 권종을 확정한다. 사용가능범위는 기본값 매장전용으로 발급하며, 브랜드공용은 규제 검토 통과 후 스위치를 켜는 구조로 둔다
결과: 회원권 1건 발급, 잔액 원장 생성, 미상환잔액(C-20)에 즉시 반영
예외: 판매 시점과 사용 시점 중 어느 쪽을 매출로 볼지는 D-16 집계 기준을 따른다
미결: 발행 주체(매장 vs 본사) — 선불업 등록 해당 여부의 분기점. 법무 확인 필요

RC-C-15잔액 차감·사용 처리1차

R2SC-M14 SC-M35

목적: 시술 결제 시 잔액을 정확히 한 번만 차감한다
트리거: 결제 화면에서 회원권·포인트를 수단으로 선택
입력: 보유 잔액 · 권종별 차감 규칙 · 로컬 서버 락 상태(L-01)
규칙: 이중 차감 방지 락으로 직렬화한다. 포인트(B-21)에도 동일하게 적용한다. 횟수권은 횟수, 금액권은 금액, 기간권은 기간 내 무제한으로 차감 방식이 갈린다. 대체시술(다른 시술로 차감)은 정가 환산 후 차감한다
결과: 잔액 갱신, 사용 명세(C-16)에 1행 추가, 매장·디자이너별 사용 이력 기록
예외: 네트워크가 끊기면 차감하지 않고 "보류"로 남긴 뒤 재연결 시 확정한다. 계획서의 "인터넷 단절 시에도 동작"을 잔액 차감까지로 읽으면 안 된다. 동시 차감 시도는 락으로 직렬화하고 뒤 요청에 안내를 띄운다

RC-C-16잔액 조회·사용 명세1차

목적: 고객에게 잔액과 사용 내역을 제시한다. 분쟁의 1차 방어선
트리거: 고객 문의, 결제 전 확인, 회원권 관리 화면 진입
입력: 회원권 원장 · 사용 이력 · 포인트 원장(B-21)
규칙: 고객에게 보여줄 명세와 내부용 이력을 구분한다. 내부용은 매장·디자이너별 사용 이력까지 본다. 거울앞 태블릿(D4)에 띄울 때는 다른 고객 정보가 섞이지 않게 한다
결과: 조회만. 상태 변경 없음
예외: 보류 중인 차감(단절 중 발생분)이 있으면 확정 전임을 명시한다

RC-C-17만료 예정 알림1차

목적: 만료를 미리 알려 잔액이 그냥 소멸되는 것을 막는다
트리거: 만료 예정일 도래(자동)
입력: 유효기간(K-14) · 알림 시점(K-12) · 발송 인프라(E-14)
규칙: 정보성으로 분류해 야간 차단·발송 상한의 예외로 둔다(K-06). 알림 시점은 K-12 파라미터이며 만료 30일·7일 같은 복수 시점을 허용한다. 고객 알림과 별개로 매장에도 띄워 다음 방문 때 소진을 유도한다
결과: 알림 발송, 매장 표시
예외: 만료 경과분의 처리는 소비자 분쟁이 잦다. 자동 소멸 여부와 시점을 정책으로 명시한다
미결: 유효기간 파라미터 — 미창조 약관 확정 필요

RC-C-27연장 처리1차

R2 / R1 승인SC-M35

목적: 만료를 앞둔 회원권의 기간을 늘린다
트리거: 고객 연장 요청
입력: 연장 정책 범위(K-14) · 잔여 잔액 · 승인 권한(J-04)
규칙: 정책에 정의된 범위 안에서만 연장하고 그 밖은 승인(SC-M43)을 탄다. 연장은 미상환잔액(C-20)의 소멸 예정 시점을 미루므로 회계에 영향을 준다 — 무제한 연장은 선수금이 영구히 남는다는 뜻이다
결과: 만료일 갱신, 연장 이력
예외: 이미 만료된 건의 소급 연장은 별도 정책이 필요하다
미결: 연장 가능 횟수·기간 상한 — 약관 확정 필요

RC-C-18중도 환불 계산1차

R1 승인SC-M35

목적: 사용하다 만 회원권의 환불액을 계산한다
트리거: 고객의 중도 해지 요청
입력: 사용 이력(C-16) · 환불 기준 정책(K-14) · 시술 정가(K-03, 판매 시점 가격은 K-16 이력 참조)
규칙: 사용분을 정가로 환산한 뒤 잔액을 환불하는 것이 실무 표준이다. 계산식을 화면에 노출해 분쟁을 줄인다. 서비스(보너스)로 얹어준 금액·횟수는 환불 대상에서 제외하되 그 사실을 명시한다
결과: 환불 실행(C-05 경로), 회원권 종료, C-20 미상환잔액 감소
예외: 이미 유효기간이 지난 건의 환불 기준은 별도다
미결: 환불율 파라미터 — 약관 확정 필요

RC-C-19명의변경(양도)1차

목적: 회원권의 소유자를 다른 사람으로 바꾼다
트리거: 고객의 양도 요청
입력: 원 보유자 · 양수자 고객 카드(B-01) · 양수자 동의(J-01)
규칙: 소유자를 바꾸므로 잔액 귀속도 함께 넘어간다. 양수자의 개인정보 수집 동의가 선행돼야 한다. 양도 이력을 남겨 나중에 환불 대상자를 판정할 수 있게 한다
결과: 소유자 변경, 변경 이력 기록
예외: 양도 후 환불 요청 시 환불 대상자를 누구로 볼지 정책 필요

RC-C-28동반 사용자 지정1차

목적: 소유자는 그대로 두고 가족 등이 함께 쓰게 한다
트리거: 고객 요청
입력: 소유자 · 동반 사용자 · 사용 한도
규칙: 소유자를 유지한 채 사용자를 추가한다 — 양도(C-19)와 달리 잔액 귀속이 원 소유자에게 남는다. 이 차이 때문에 환불(C-18) 대상자와 미상환잔액(C-20) 귀속이 갈린다. 동반 사용자별 사용 이력을 구분해 남긴다
결과: 사용자 목록 추가, 사용 이력 구분
예외: 동반 사용자가 쓴 뒤 소유자가 환불을 요청하면 사용분 처리 기준이 필요하다

RC-C-20미상환잔액(선수금) 리포트1차

R1SC-M36

목적: 아직 제공하지 않은 서비스의 총액을 본다. 회계·규제 대응 근거
트리거: 월마감(C-26), 본사 요청, 정기 조회
입력: 회원권 잔액 원장 + 미사용 포인트(B-21) 합산
규칙: 미상환잔액은 재무제표상 선수금이다. 매장별 총액과 추이를 낸다. 유효기간 경과분은 별도로 구분해 보여준다 — 회계 처리가 다르다
결과: 조회·내보내기(J-11 반출 통제 적용)
예외: 보류 중인 차감이 있으면 잠정치임을 표시한다

RC-C-21잔액 이관·검증1차

R1 승인SC-M36 SC-M43

목적: 외부 CRM의 회원권·포인트 잔액을 옮기고 틀린 건을 잡아낸다. 이관 항목 중 위험도가 가장 높다
트리거: 매장 온보딩(M-05) 시 1회, 재이관 시 반복
입력: 외부 CRM 이관 원장 · 스테이징 적재분(I-07)
규칙: 건별로 대조하고 차이 건은 승인을 태운다. 자동 반영을 금지한다. 예약·시술 데이터는 틀려도 나중에 고치면 되지만 잔액은 틀리는 순간 고객이 현장에서 항의한다. 승인 전에는 잔액을 사용할 수 없게 잠근다
결과: 잔액 원장 확정, 차이 건의 처리 이력 기록
예외: 이관 실패·부분 반영은 I-14 롤백으로 되돌린다
미결: 이관 원장 확보 — 헤어짱·핸드SOS에서 잔액을 어떤 형식으로 받는지 CRM사 협의 필요. 포인트 원장이 협의 항목에 포함됐는지 확인 필요

RC-C-14매장 간 회원권 사용2차

SC-M35

목적: 타 가맹점에서 회원권을 쓸 때의 정산 규칙
규칙: 사용가능범위 = 브랜드공용(C-04)인 건에 한해 허용한다. 사용 매장과 발행 매장이 다르면 매장 간 채권·채무가 발생하므로 정산 대상으로 기록한다
미결: ⚠️ 정산 규칙 미정. 490개 가맹 구조에서 누가 언제 정산하는지, 그리고 브랜드공용 전환이 선불업 등록 요건에 걸리는지 법무 확인 필요

C-3. 취소·환불·보상 — 2개

RC-C-05부분환불·취소1차

R1 승인SC-M16 SC-M43

목적: 잘못된 결제나 고객 불만을 금전으로 되돌린다
트리거: 환불 요청 접수. 클레임(B-08)에서 진입하는 경로 포함
입력: 원거래 · 사유 코드 · 승인 권한(J-04, 부재 시 J-13 위임)
규칙: 전체 취소와 부분 환불을 먼저 가른다. 전체 취소는 원거래 전부를 무효로 하고, 부분 환불은 라인을 지정해 그만큼만 되돌린다 — 어느 라인인지 지정해야 C-10 귀속이 정확해진다. 원거래를 반드시 연결한다. 분할 결제(C-23) 건은 수단별 역순으로 복원한다 — 카드부터 취소하고 잔액성 수단을 마지막에 되돌린다. 승인 권한은 J-04, 점주 부재 시 J-13 위임을 탄다
결과: 환불 실행, 매출 차감, D-16 집계 기준에 따라 반영 시점 결정
예외: 시점에 따라 경로가 셋으로 갈린다 — 마감 전이면 그 자리에서, 마감(C-08) 이후면 C-24 정정 경로로, 월마감(C-26) 잠금 구간이면 잠금 해제 승인이 선행된다. 카드 취소는 원 승인 후 기간이 지나면 매입 취소가 아니라 환불 거래로 바뀌어 수수료가 남는다

RC-C-25재시술·무상 처리1차

R2 등록 / R1 승인SC-M16 SC-M14 SC-M11 SC-M43

목적: 잘못 나온 시술을 다시 해주는 건을 기록한다. 미용실 표준 관행인데 기록할 자리가 없으면 성과 지표가 왜곡된다
트리거: 클레임 접수(B-08) 또는 현장 판단
입력: 원 시술 라인 · 사유 코드 · 재시술 담당 디자이너
규칙: 0원으로 기록하되 좌석·시간은 소모된 것으로 남긴다. 원거래를 연결하고, 담당 디자이너의 매출 귀속에서는 제외하되 재시술 건수는 별도로 집계한다 — 그래야 재시술이 잦은 디자이너가 지표상 유리해지지 않는다. 재시술 예약은 A-02에서 유형을 구분해 잡는다
결과: 0원 결제 1건, 원거래 연결, C-10에 재시술 표기, B-08 클레임 상태 갱신
예외: 재시술에 약제가 들어가면 O-07 재고는 실제로 소진된다. 매출 0과 원가 발생이 어긋나는 지점

C-4. 마감·정산 — 7개

RC-C-08일마감1차

R2SC-M17 (D2 POS)

목적: 하루의 현금과 카드를 실물과 맞춘다
트리거: 영업 종료
입력: 당일 결제 전체 · 현금 시재 실사값 · 카드 승인 내역
규칙: 시재 차이가 나면 사유 입력 없이는 마감할 수 없다. 카드 대사는 승인 건수·금액을 단말 집계와 맞춘다. 마감은 매장 1일 1회를 전제한다
결과: 일마감 확정, 차이와 사유 기록
예외: 보류 중인 결제(단절 중 발생분)가 있으면 마감을 막고 먼저 확정하게 한다

RC-C-24마감 정정1차

R1 승인SC-M17

목적: 마감 후 발견된 오류를 고친다
트리거: 마감 후 오류 발견
입력: 마감 건 · 정정 사유 · 승인 권한(J-04)
규칙: 정정에는 권한·사유·이력이 모두 필수다. 정정분의 리포트 재반영은 D-17을 따른다. 마감 자체를 취소하는 것이 아니라 값을 고치고 흔적을 남긴다
결과: 마감 값 갱신, 정정 이력 기록, 재집계 트리거
예외: 월마감(C-26)으로 잠긴 기간은 잠금 해제 승인이 선행된다

RC-C-29교대 시재 인수인계1차

R2SC-M17 (교대 시재 탭)

목적: 근무 교대 시 현금 책임을 넘긴다
트리거: 캐셔 교대
입력: 인계자 시재 실사값 · 인수자 확인 · 로그인 계정(N-01)
규칙: 로그인 계정 기준으로 누가 언제까지 책임졌는지 남긴다. 인수자가 실사값을 확인해야 넘어간다. 계정을 공유하면 이 기능이 무의미해지므로 교대 시 세션 전환(N-09)이 강제되어야 한다. C-08 일마감은 매장 1일 1회 전제라 이 경우를 다루지 않는다
결과: 시재 인수인계 기록, 책임 구간 확정
예외: 차이가 나면 사유 없이 넘길 수 없다. 교대 중 차이는 일마감 차이와 별도로 집계한다

RC-C-26월마감·기간 잠금1차

R1 또는 본사SC-M18

목적: 월 매출을 확정하고 그 뒤로 숫자가 흔들리지 않게 한다
트리거: 월 종료 후 확정 작업
입력: 해당 월 일마감 전체 · 미확정 건 목록
규칙: 잠금 이후 정정은 별도 승인을 탄다. D-16 재집계는 잠금 구간을 건드리지 못한다. K-11 요율로 수수료를 지급한 뒤 숫자가 바뀌면 분쟁이 되므로, 정산 지급 전에 잠그는 것이 원칙이다
결과: 기간 잠금, 확정 매출 고정, 수수료 산정(F-08) 기준 확정
예외: 미확정 일마감이 남아 있으면 월마감을 막는다

RC-C-09정산 리포트1차

R1SC-M18

목적: 기간 매출과 실제 입금을 맞춘다
트리거: 정기 조회, 월마감 전 확인
입력: 기간 결제 내역 · PG·카드사 입금 통보 · 수수료율(K-15)
규칙: 결제일과 입금일이 다르므로 발생 기준과 입금 기준을 나눠 본다. 수수료와 입금 예정일을 수단별로 계산한다. 미입금 건은 경과일수와 함께 남긴다
결과: 대사 결과, 미입금 목록
예외: 입금액이 예상과 다르면 차이 사유를 기록한다

RC-C-10디자이너 매출 귀속1차

R1SC-M18 SC-M28

목적: 매출을 담당자에게 배분한다. 수수료 정산(F-08)의 원천
트리거: 결제 확정 시 자동
입력: 결제 라인별 담당·보조 · 배분 규칙(K-11) · 적용 기준일(K-16)
규칙: 시술 라인 단위로 담당·보조를 배분한다. 재시술(C-25)은 매출 0이지만 좌석·시간을 쓰므로 성과 지표에서 별도로 표기한다. 제품 판매(O-02)의 담당은 시술 담당과 다를 수 있어 따로 잡는다. ⚠️ 열람 권한 분리 필수 — 디자이너는 본인 것만(SC-D16)
결과: 귀속 확정, F-08 정산 기초자료 생성
예외: 요율이 바뀌면 K-16 적용 기준일에 따라 과거 거래는 소급하지 않는다

RC-C-12결제–시술 정합 보정1차

R2SC-M19

목적: 결제는 있는데 시술 기록이 없거나 어긋나는 건을 찾아 고친다
트리거: 일 단위 자동 점검, 또는 수동 실행
입력: 결제 내역 · 시술 기록(G-01) · 기록 완료율(G-06)
규칙: 불일치 유형을 나눈다 — ①결제만 있고 시술 기록 없음 ②시술 기록만 있고 결제 없음 ③금액·시술 내용 불일치. 신뢰도 플래그를 붙이고 기간별 가중 보정 규칙을 정의한다. 보정은 사람이 확인 후 확정한다
결과: 보정 이력, 데이터 신뢰도 지표 갱신
예외: 과거 이관 데이터는 원본이 이미 어긋나 있을 수 있어 보정 대상과 인정 대상을 구분한다

[8/7 미팅 근거] 파수 발언 — CRM의 결제 데이터와 시술 데이터가 일치하지 않아 "아웃풋에 결정적인 타격"이 될 수 있다. 결제는 남지만 무슨 시술을 했는지 기록이 없거나 어긋나는 건이 상당수라는 뜻이다. 정합 보정은 데이터 품질의 출발점이므로 화면으로 반드시 만들어야 한다.

RC-C-13미수·외상2차

R2SC-M44

목적: 당장 못 받은 금액을 남기고 회수한다
규칙: 미수는 매출로 잡되 입금은 별도로 추적한다. 고객 카드(B-02)에 미수 보유가 보이게 한다

5. 이 초안에서 드러난 확인 필요 항목

#	항목	관련	왜
1	회원권 발행 주체 (매장 vs 본사)	C-04 · C-14	선불업 등록·별도관리 의무의 분기점. 법무 확인
2	유효기간·환불율 정책 파라미터	C-17 · C-18	K-14 입력값. 미창조 약관 확정 필요
3	이관 원장 형식, 포인트 포함 여부	C-21	CRM사 협의 항목에 포인트가 있는지 확인
4	매장 간 회원권 정산 규칙	C-14	미정. 브랜드공용 전환은 법무 검토 후
5	네트워크 단절 시 결제 처리 범위	C-01 · C-15 · K-15	"인터넷 단절 시에도 동작"의 결제 포함 여부. 무승인 거래 가능 여부는 VAN·카드사 계약
6	매장 할인 재량 범위와 초과 시 처리	C-06	승인 vs 차단. 가맹사업법 확인
7	재시술의 약제 원가 처리	C-25 · O-07	매출 0인데 재고는 소진된다
8	예약금 몰수분의 매출 인식	C-11 · D-16	집계 기준에 포함할지

항목

16-D. 매출·리포트 기능 상세 — 17개

15번 목록의 D 도메인을 와이어프레임 작성자가 화면에 무엇을 놓을지 판단할 수 있는 수준까지 폈다. 기능 하나를 여섯 줄(목적·트리거·입력·규칙·결과·예외)로 정의한다.

17개1차152차2미결 22차 미작성 2

상위: 15. RIAHN CONNECT 기능 목록 · 화면 목록 — D 도메인
필드 정의와 표기(⚑ 분리 검토 · ▷ 2차 상세 미작성)는 16-C 0-1과 같다
작성: 이원섭 PM · 2026-08-11

0. 이 도메인은 스스로 데이터를 만들지 않는다

전부 파생이다. 결제(C)·시술 기록(G)·예약(A)·고객(B)에서 나온 값을 다르게 잘라 보여줄 뿐이다. 그래서 원천이 틀리면 여기서 고칠 방법이 없다.

제약 넷

집계 기준이 먼저다. 취소·환불·마감 정정·재시술·회원권을 언제 매출로 잡는지가 정해지지 않으면 모든 숫자가 자의적이다. D-16이 이 도메인의 실질적 1번이다.
확정된 숫자는 흔들리지 않는다. 월마감 잠금(C-26) 구간은 재집계 대상에서 빠진다. 요율로 수수료를 지급한 뒤 숫자가 바뀌면 분쟁이 된다.
더미 매출이 섞이면 모델이 붕괴한다. 마감용 가짜 매출은 계획서 인프라2에 명시된 항목이며, CLV(B-09)·이탈(B-10) 예측의 입력을 오염시킨다.
내보내기는 개인정보 반출이다. PDF·엑셀 내보내기에 마스킹·사유·로그를 적용한다(J-11).

0-2. 군집

군집	기능	주 화면
D-1 기준·품질	3	SC-M18 정산 리포트 · SC-M19 정합 보정 · SC-M32 설정
D-2 핵심 지표	4	SC-M20 매출 대시보드
D-3 분해 분석	4	SC-M21 매출 상세 분석
D-4 진단·리포팅	5	SC-M22 경영 리포트 · SC-M31 알림센터

군집

기능

주 화면

D-1 기준·품질

SC-M18 정산 리포트 · SC-M19 정합 보정 · SC-M32 설정

D-2 핵심 지표

SC-M20 매출 대시보드

D-3 분해 분석

SC-M21 매출 상세 분석

D-4 진단·리포팅

SC-M22 경영 리포트 · SC-M31 알림센터

16-D. 매출·리포트 — RIAHN CONNECT 기능 상세

D-1. 기준·품질 — 3개

RC-D-16집계 기준 정의1차

R1/본사SC-M18

목적: 무엇을 언제 매출로 볼지 정한다. 이 도메인의 모든 숫자가 이 정의 위에 서 있다
트리거: 기준 설정, 소급 사건 발생(환불·정정·재시술)
입력: 결제(C-01) · 환불(C-05) · 마감 정정(C-24) · 재시술(C-25) · 회원권 판매·사용(C-04·C-15) · 잠금 구간(C-26)
규칙: 다섯 가지를 정의한다. ①취소·환불을 원 거래일에 차감할지 발생일에 잡을지 ②마감 정정분의 반영 시점 ③재시술(0원)을 건수로만 셀지 ④회원권을 판매 시점과 사용 시점 중 어디서 매출로 볼지 ⑤예약금 몰수분을 매출로 볼지. 소급 사건이 생기면 재집계를 실행하되 C-26 잠금 구간은 건드리지 못한다. 재집계 이력을 남긴다
결과: 집계 기준 확정, 재집계 실행, 이력
예외: 기준을 바꾸면 과거 리포트가 달라진다. 변경 전후를 비교할 수 있게 하고 변경 시점을 리포트에 표시한다
미결: 회원권 매출 인식 시점 — 회계 처리와 맞물린다. 판매 시점 인식이면 미상환잔액(C-20)과 이중 계상 위험

RC-D-17재집계 실행1차

R1SC-M18

목적: 소급 사건이 생겼을 때 과거 수치를 다시 계산한다
트리거: 환불(C-05)·마감 정정(C-24)·재시술(C-25) 발생
입력: 소급 사건 · 집계 기준(D-16) · 잠금 구간(C-26)
규칙: C-26 잠금 구간은 재집계 대상에서 제외한다 — 요율로 수수료를 지급한 뒤 숫자가 바뀌면 분쟁이 된다. 재집계 이력을 남기고 어느 리포트가 갱신됐는지 표시한다. 잠금 구간에 소급 사건이 걸리면 재집계 대신 다음 기간에 조정 항목으로 반영한다
결과: 수치 갱신, 재집계 이력
예외: 재집계 중에는 해당 기간 리포트를 잠정치로 표시한다

RC-D-14더미 매출 이상치 탐지1차

자동 → R1 확인SC-M19

목적: 마감용으로 만든 가짜 매출을 걸러낸다. 계획서 인프라2 명시 항목
트리거: 일·주 단위 자동 점검
입력: 결제 패턴 · 시술 기록 유무(C-12) · 탐지 기준(K-12)
규칙: 의심 패턴을 찾는다 — 마감 직전 몰림, 시술 기록 없는 결제, 동일 금액 반복, 즉시 환불. 탐지는 자동이되 판정은 사람이 한다. 확정된 더미는 CLV(B-09)·이탈(B-10) 모델 입력에서 제외하되 회계 매출에서는 임의로 빼지 않는다 — 그건 별개 문제다
결과: 이상치 플래그, 모델 입력 제외 표시
예외: 정상 거래를 더미로 오판하면 매장이 반발한다. 탐지 근거를 반드시 함께 보여준다

RC-D-15매출 목표 설정1차

R1/본사SC-M32

목적: 달성률(D-07)의 기준값을 넣는다. 이게 없으면 D-07이 성립하지 않는다
트리거: 월·분기 초 목표 수립
입력: 매장·디자이너·기간 단위 목표액 · 과거 실적(D-08)
규칙: 매장 목표와 디자이너 개인 목표를 따로 둔다. 개인 목표는 본인에게만 보인다(F-03, J-08). 본사가 하달하는지 매장이 자율로 잡는지에 따라 화면 위치와 권한이 달라진다 — 하달이면 M-06 표준 배포 대상
결과: 목표 확정, D-07·F-03의 입력
예외: 목표 미설정 시 달성률 대신 추이만 낸다
미결: 목표 수립 주체 (본사 하달 vs 매장 자율)

D-2. 핵심 지표 — 4개

RC-D-01매출 대시보드 (일/주/월)1차

R1/R2SC-M20 SC-M02

목적: 지금 얼마 벌고 있는지 본다. 점주가 가장 자주 보는 화면
트리거: 로그인, 수시 조회
입력: 결제(C-01) · 집계 기준(D-16) · 목표(D-15) · 이상 변동(D-09)
규칙: 일/주/월을 전환한다. 당일은 진행 중 값이므로 확정치와 구분해 표시한다. 목표 대비 달성률(D-07)과 전기 대비(D-08)를 함께 낸다 — 절대값만으로는 판단이 안 된다
결과: 조회. 상세 분석(D-03~05)으로 진입
예외: 마감 전 값과 마감 후 값이 다를 수 있다. 마감 여부를 표시한다

RC-D-02디자이너별 매출1차

목적: 누가 얼마나 만들었는지 본다
트리거: 대시보드에서 분해
입력: 매출 귀속(C-10) · 근태(F-13) · 재시술 건수(C-25)
규칙: 귀속 규칙(C-10)에 따라 배분된 값을 쓴다. 재시술은 매출 0이므로 건수로 별도 표기한다 — 빼놓으면 재시술이 많은 디자이너가 유리해 보인다. 근무시간 대비 생산성도 함께 볼 수 있게 한다. ⚠️ 디자이너 뷰에서는 본인 것만(J-08)
결과: 디자이너별 매출·건수·생산성
예외: 퇴사자도 해당 기간 실적은 남는다(F-15)

RC-D-06객단가·재방문율·신규/재방문 비중1차

R1SC-M20

목적: 매출의 질을 본다. 총액이 같아도 구성이 다르면 다른 사업이다
트리거: 대시보드 조회
입력: 결제 건수·금액 · 고객 방문 이력(B-04) · 신규 등록(B-03)
규칙: 객단가는 총매출/방문건수다. 재방문율의 기준 기간을 명시한다 — 3개월인지 6개월인지에 따라 값이 크게 다르다(K-12). 신규/재방문 비중은 유입과 유지의 균형을 보여준다
결과: 세 지표
예외: 회원권 사용 방문은 결제액이 0으로 잡혀 객단가를 낮춘다. 정가 환산값을 병기할지 정해야 한다

RC-D-07목표 대비 달성률1차

R1SC-M20

목적: 잘 가고 있는지 판단한다
트리거: 대시보드 조회
입력: 실적 · 목표(D-15) · 기간 경과율
규칙: 단순 달성률과 함께 기간 경과 대비 진도를 낸다 — 월 중순에 50%면 정상이다. 목표는 D-15에서 오고 여기서는 계산만 한다
결과: 달성률·진도
예외: 목표 미설정이면 표시하지 않는다

D-3. 분해 분석 — 4개

RC-D-03시술별 매출1차

목적: 어떤 시술이 돈이 되는지 본다
트리거: 상세 분석 진입
입력: 시술 기록(G-01) · 메뉴(K-03) · 약제 원가(O-07)
규칙: 시술 대·중분류로 묶어 본다. 원가가 있으면 마진까지 낸다 — 약제 소진(O-07)이 연결되면 가능하다. 재시술은 매출 0·원가 발생이므로 별도 표기
결과: 시술군별 매출·건수·마진
예외: 기록되지 않은 시술은 집계에서 빠진다. 기록률(G-06)을 함께 보여야 신뢰도를 안다

RC-D-04채널별 매출1차

목적: 어느 채널이 돈이 되는지 본다. 채널 슬롯 배분(A-18)의 근거
트리거: 상세 분석 진입
입력: 예약 채널(A-09) · 결제 · 채널 수수료
규칙: 채널별 매출과 함께 수수료를 빼고 본다 — 네이버 예약은 수수료가 있고 워크인은 없다. 채널별 객단가·재방문 전환율까지 봐야 어느 채널을 키울지 판단된다
결과: 채널별 매출·순매출·전환
예외: 채널 미매핑 건(A-09 "기타")이 많으면 분석이 왜곡된다

RC-D-05시간대·요일별 매출1차

목적: 언제 비는지 본다. 슬롯 최적화(A-15)와 타임딜(K-08)의 근거
트리거: 상세 분석 진입
입력: 결제 시각 · 예약 시각 · 영업시간(K-01)
규칙: 히트맵으로 낸다. 비수기·공백 구간이 프로모션(E-11)과 타임딜의 대상이 된다. 예약 시각과 결제 시각이 다르므로 어느 쪽 기준인지 명시한다
결과: 시간대×요일 분포
예외: 영업시간이 바뀌면 과거 비교가 어긋난다

RC-D-08전년·전월 동기 비교1차

R1SC-M20

목적: 좋아지고 있는지 나빠지고 있는지 본다
트리거: 대시보드·상세 조회
입력: 현재 기간 · 비교 기간 실적
규칙: 전년 동월·전월을 기본으로 하되 영업일 수 차이를 보정한다 — 2월과 3월을 그냥 비교하면 안 된다. 신규 매장은 비교 기간이 없으므로 개점 후 경과로 표시
결과: 증감률·차이
예외: 집계 기준(D-16)이 중간에 바뀌었으면 비교에 경고를 붙인다

D-4. 진단·리포팅 — 5개

RC-D-09이상 변동 알림1차

자동 → R1SC-M20 SC-M02

목적: 나빠지는 것을 늦기 전에 안다
트리거: 일·주 단위 자동 점검
입력: 매출 추이 · 이상 판정 기준(K-12) · 알림 라우팅(K-17)
규칙: 급락·급등을 감지해 알린다. 무엇이 얼마나 변했는지와 함께 보낸다 — "매출 하락"만 오면 아무도 안 본다. 임계값은 K-12, 수신자는 K-17. 본사 이상징후(M-02)와 기준을 맞춘다
결과: 알림 발송, 알림센터 표시
예외: 휴무일·임시 휴업(A-19)을 이상으로 오판하지 않게 제외한다

RC-D-10매출 원인 자동 진단1차

R1SC-M22

목적: 왜 그렇게 됐는지 설명한다(S11)
트리거: 이상 변동 감지, 월간 리포트 생성
입력: 분해 지표(D-02~06) · 고객 세그먼트(B-11) · 채널·시술 구성 변화
규칙: 변동을 요인별로 분해한다 — 객수 감소인지 객단가 하락인지, 어느 채널·시술·디자이너에서 났는지. 자연어로 요약하되 근거 수치를 함께 낸다
결과: 원인 진단 문장 + 근거
예외: 표본이 적은 매장은 진단이 과적합된다

RC-D-13리포트 내보내기 (PDF·엑셀)1차

R1SC-M20 SC-M21 SC-M22

목적: 밖으로 가져간다
트리거: 내보내기 실행
입력: 조회 중인 리포트 · 반출 통제 규칙(J-11)
규칙: 개인정보 반출 경로이므로 J-11 통제를 탄다 — 마스킹 적용·사유 입력·반출 로그. 고객 단위 데이터가 포함되면 대량 반출 승인이 필요하다. 집계 기준(D-16)과 생성 시각을 파일에 박아 나중에 숫자가 달라도 추적되게 한다
결과: 파일 생성, 반출 로그
예외: 잠금 전 데이터를 내보내면 나중에 값이 달라진다. 잠금 여부를 파일에 표시한다

RC-D-11포지셔닝 진단2차

R1SC-M22

목적: 우리 매장이 상권에서 어디쯤인지 본다(S12)
규칙: 가격대·시술 구성·고객층으로 위치를 잡는다. 상권 분석(M-12)과 데이터를 공유한다

RC-D-12월간 경영 리포트2차

R1SC-M22

목적: 한 달을 요약해 읽을거리로 만든다(S15)
규칙: 자연어 리포트와 이슈 3개를 낸다. 월마감(C-26) 이후 확정 데이터로 생성한다

미창조㈜ · AX 사업추진 TF

16-E. 마케팅 기능 상세 — 17개

15번 목록의 E 도메인을 와이어프레임 작성자가 화면에 무엇을 놓을지 판단할 수 있는 수준까지 폈다. 기능 하나를 여섯 줄(목적·트리거·입력·규칙·결과·예외)로 정의한다.

17개1차142차3미결 32차 미작성 2

상위: 15. RIAHN CONNECT 기능 목록 · 화면 목록 — E 도메인
필드 정의와 표기(⚑ 분리 검토 · ▷ 2차 상세 미작성)는 16-C 0-1과 같다
작성: 이원섭 PM · 2026-08-11

0. 이 도메인은 사업 모델의 접점이다

[8/7 미팅 근거] 본부장 — "저희는 이거를 카카오로 좀 돌리면… 어차피 문자는 열지도 않고 비용도 높은데 핸드[SOS]는 개발을 안 해요. 지금도 카카오로 전환할 생각이 없어요."

미용실당 문자 수수료가 월 약 5만 원이고, 이 시장을 알림톡으로 직접 겨냥하는 것이 CRM 진입 전략의 차별화 지점이다. E-05·E-10은 단순 기능이 아니라 사업 모델의 접점이다.

제약 다섯

발송 인프라는 마케팅 전용이 아니다. E-14(발송 결과)·E-15(수신거부)·E-06(발송 큐)은 예약 알림(A-13)·브리핑(B-13)·재진단(B-20)·본사 공지(M-13)가 모두 함께 쓴다. 정보성과 광고성을 K-06 유형으로 구분해 규칙을 달리 적용한다.
법정 의무가 여럿이다. 야간 광고 차단(21~08시), (광고) 표기, 수신거부 처리와 결과 통지, 발신번호 사전등록. 하나라도 빠지면 발송 자체가 위법이다.
보내는 것과 닿는 것은 다르다. 알림톡은 카톡 미가입·차단 시 실패한다. 대체발송과 건별 결과 추적이 없으면 "보냈다고 믿었는데 안 간" 건이 그대로 쌓인다.
자동 제안이지 자동 발송이 아니다. 계획서 인프라2에 "발송은 디자이너 검토·승인 후"가 명시돼 있다. AI는 제안하고 사람이 승인한다.
정책 숫자는 K-12에, 유형은 K-06에, 발신 자격은 K-13에 있다. 화면에 시간·상한을 박지 않는다.

0-2. 군집

군집	기능	주 화면
E-1 캠페인 기획·작성	5	SC-M23 제안함 · SC-M24 작성·발송
E-2 발송 통제	5	SC-M24 · SC-M32 설정
E-3 발송 인프라	3	SC-M25 성과·발송 로그
E-4 성과·부가	3	SC-M25 · SC-M26 쿠폰 · SC-M45

군집

기능

주 화면

E-1 캠페인 기획·작성

SC-M23 제안함 · SC-M24 작성·발송

E-2 발송 통제

SC-M24 · SC-M32 설정

E-3 발송 인프라

SC-M25 성과·발송 로그

E-4 성과·부가

SC-M25 · SC-M26 쿠폰 · SC-M45

16-E. 마케팅 — RIAHN CONNECT 기능 상세

E-1. 캠페인 기획·작성 — 5개

RC-E-01AI 캠페인 제안함1차

R1SC-M23 SC-M43

목적: 무엇을 보낼지 매장이 고민하지 않게 한다. 마케팅을 실제로 돌아가게 만드는 진입점
트리거: 배치 산정(일·주 단위), 세그먼트 변화 감지
입력: 세그먼트(B-11) · 이탈 위험(B-10) · CLV(B-09) · 비수기 감지(E-11)
규칙: 4종을 자동 제안한다 — Win-back(이탈 위험) · 휴면 · 업셀 · 신규 재방문. 카드 형태로 쌓고 승인 대기 상태로 둔다. 자동 발송하지 않는다. 4종이 동시에 제안되므로 대상이 겹치는 것이 필연이고, 이는 E-16 피로도 관리로 거른다
결과: 제안 카드, 승인 대기함(SC-M43)에 표시
예외: 제안을 거절한 이력을 남겨 다음 제안 품질에 반영한다

RC-E-02세그먼트 선정·편집1차

R1/R2SC-M24

목적: 제안된 대상을 확인하고 조정한다
트리거: 제안 카드 채택, 또는 직접 캠페인 작성
입력: 저장 세그먼트(B-18) · 동의 상태(B-16) · 발송 이력(E-16)
규칙: 대상을 가감할 수 있다. 미동의자는 자동 제외되며 제외 인원을 함께 보여준다(E-07). 최근 발송받은 고객은 피로도 규칙으로 걸러진다(E-16). 최종 발송 대상 수가 확정되어야 비용(E-10)이 계산된다
결과: 발송 대상 명단 확정
예외: 제외 후 대상이 너무 적으면 경고한다 — 조건을 잘못 걸었을 가능성이 높다

RC-E-03문구 초안·편집1차

R1/R2SC-M24

목적: 보낼 내용을 만든다
트리거: 대상 확정 후
입력: AI 초안 · 템플릿(K-06) · 카카오 템플릿 심사 상태(K-06)
규칙: AI 초안을 주고 수동 편집을 허용한다. 알림톡은 사전 승인된 템플릿만 발송 가능하므로 심사 통과 템플릿 안에서 변수만 바꾸는 방식과, 심사가 필요한 신규 문구를 구분한다. 광고성이면 (광고) 표기와 수신거부 안내가 자동으로 붙는다(E-07). 자주 쓰는 문구는 템플릿으로 저장
결과: 발송 문구 확정
예외: 심사 대기 중인 템플릿으로는 발송할 수 없다. 상태를 화면에 표시한다

RC-E-04예상 효과 표시1차

R1SC-M23

목적: 보낼지 말지 판단할 근거를 준다
트리거: 대상·문구 확정 후
입력: 과거 유사 캠페인 성과(E-08) · 대상 세그먼트 특성 · 발송 비용(E-10)
규칙: 예상 반응률·예약 전환·매출 기여를 낸다. 비용과 함께 보여준다 — 기대 매출이 발송 비용보다 낮으면 보낼 이유가 없다. 근거가 되는 과거 캠페인을 함께 표시한다
결과: 예상치 표시
예외: 유사 이력이 없으면 예측하지 않고 "이력 부족"으로 둔다

RC-E-11프로모션 설계2차

R1SC-M23

목적: 비수기를 감지해 프로모션 유형을 추천한다
규칙: 매출 추이(D-05 시간대·요일별)에서 비수기를 감지하고 유형을 제안한다(S14)

E-2. 발송 통제 — 5개

RC-E-05승인·발송1차

R1 승인SC-M24

목적: 실제로 내보낸다. 사업 모델의 접점
트리거: 캠페인 작성 완료 후 승인
입력: 대상(E-02) · 문구(E-03) · 채널 · 발신 자격(K-13) · 잔여 건수(E-10)
규칙: 알림톡·문자·앱 푸시 중 채널을 고른다. 알림톡 우선, 실패 시 문자 대체가 기본 전략이다(E-14). 발송 전 최종 검증을 통과해야 한다(E-07). 발신번호가 사전등록되지 않았으면 발송 자체가 막힌다(K-13). 승인은 J-04 권한, 부재 시 J-13 위임
결과: 발송 실행, 발송 큐(E-06)에 적재
예외: 잔여 건수가 부족하면 발송을 막고 충전을 안내한다(E-10)

RC-E-06발송 예약·야간 차단1차

자동SC-M24

목적: 언제 나갈지 통제한다. 법정 의무와 운영 편의가 함께 걸린다
트리거: 발송 승인 후
입력: 발송 시각 지정 · 야간 차단 시간대(K-12) · 메시지 유형(K-06) · 큐 상태
규칙: 21~08시 광고 전송을 강제로 차단한다 — 시간대 값은 K-12 파라미터다. 차단 시간에 걸리면 다음 허용 시각으로 자동 이월한다. 정보성 메시지(예약 알림·브리핑·재진단)는 차단과 상한의 예외이며 유형 판정은 K-06 템플릿 분류를 따른다. 대량 발송은 큐에 쌓아 우선순위대로 내보낸다 — 정보성이 광고성보다 앞선다
결과: 발송 예약 또는 즉시 발송, 큐 적재
예외: 큐가 밀리면 예약 리마인더(A-13)가 늦어져 실효가 없어진다. 정보성은 지연 임계값을 두고 초과 시 알린다

RC-E-17발송 큐·우선순위1차

자동SC-M24

목적: 대량 발송이 밀릴 때 무엇을 먼저 내보낼지 정한다
트리거: 발송 요청 적재
입력: 대기 중인 발송 건 · 메시지 유형(K-06) · 지연 임계
규칙: 정보성이 광고성보다 앞선다 — 예약 리마인더(A-13)가 캠페인에 밀려 늦어지면 실효가 없어진다. 지연 임계값을 두고 초과 시 알린다(K-17). 큐 상태를 볼 수 있어야 발송이 안 나가는 이유를 안다
결과: 발송 순서 확정, 큐 현황
예외: 큐가 계속 밀리면 채널 처리량 한계다. 분산 발송으로 전환한다

RC-E-07수신동의·(광고) 표기 검증1차

자동SC-M24

목적: 위법 발송을 원천 차단한다
트리거: 발송 직전 자동
입력: 동의 상태(B-16, J-01) · 수신거부 이력(E-15) · 문구(E-03) · 메시지 유형(K-06)
규칙: 광고성이면 셋을 검사한다. ①미동의자 자동 제외 ②(광고) 표기 존재 ③무료 수신거부 안내 존재. 하나라도 없으면 발송을 차단한다 — 경고가 아니라 차단이다. 정보성은 이 검사를 타지 않는다
결과: 검증 통과 시 발송, 실패 시 차단 + 사유 표시
예외: 이관 고객은 동의 이력이 없을 수 있다. "미동의"로 처리해 제외하고 재동의 대상으로 분류한다 — 있다고 가정하면 위법이다

RC-E-13디자이너 개별 메시지 승인·발송1차

R3 승인SC-D14

목적: 담당 디자이너 명의의 개별 메시지를 보낸다. 계획서 인프라2 명시 항목
트리거: 이탈 위험 감지(B-10) → 담당 디자이너 알림
입력: 위험 고객 · 추천 문구 · 담당 관계(B-04)
규칙: 계획서 문언대로 발송은 디자이너 검토·승인 후에만 이뤄진다. 셋 중 하나를 고른다 — 발송 / 수정 후 발송 / 발송 안 함. 발송 안 함도 유효한 선택이며 사유를 남기면 다음 제안에 반영한다. 캠페인 발송(E-05)과 별개 경로지만 피로도(E-16)는 함께 계산한다
결과: 개별 발송 또는 보류, 선택 이력
예외: 디자이너가 응답하지 않으면 발송하지 않는다. 미응답 건이 쌓이면 점주에게 알린다(K-17 라우팅)

RC-E-16발송 피로도 관리1차

자동SC-M24 SC-M25

목적: 같은 고객이 여러 캠페인에 겹쳐 시달리지 않게 한다
트리거: 대상 확정 시 자동
입력: 최근 발송 이력 · 기간당 상한(K-12) · 메시지 유형(K-06)
규칙: 캠페인 간 중복 대상을 제거하고 고객별 기간당 발송 상한을 적용한다. E-01이 4종을 동시 제안하므로 중복은 필연이다. 상한 초과 시 제외할지 다음 회차로 이월할지는 설정으로 둔다. 정보성은 상한에서 제외한다 — 예약 알림까지 막으면 안 된다
결과: 최종 대상 축소, 제외·이월 사유 표시
예외: 디자이너 개별 메시지(E-13)도 상한에 포함해 계산한다

E-3. 발송 인프라 — 3개

RC-E-14발송 결과·재발송1차

R1/R2SC-M25

목적: 보낸 것이 닿았는지 안다. 이게 없으면 발송은 밑 빠진 독이다
트리거: 발송 후 결과 수신(콜백), 재발송 실행
입력: 건별 발송 요청 · 채널 결과 코드 · 대체발송 정책 · 발신번호(K-13)
규칙: 건별로 상태·실패 사유를 남긴다. 알림톡 실패 시 SMS로 대체발송한다 — 카톡 미가입·차단이 주 실패 사유다. 대체발송도 광고성이면 (광고) 표기가 필요하다(E-07). 재발송은 비용이 다시 들므로 잔여 건수(E-10)를 차감한다. 정보성·광고성 공통 인프라다
결과: 건별 전송 상태, 성공률·대체발송률 집계
예외: 결과 콜백이 유실될 수 있으므로 조회로 대사하는 경로를 둔다. 반복 실패하는 번호는 유효하지 않은 것으로 표시해 다음 발송에서 제외한다
미결: 알림톡 실패 시 SMS 대체발송의 비용 부담 주체 — 대체발송을 켜면 비용 절감 논리가 일부 상쇄된다

RC-E-15수신거부 처리1차

자동SC-M11 SC-M24 SC-M25

목적: 거부 의사를 즉시 반영한다. 법정 의무
트리거: 080 수신거부 전화, 알림톡 수신거부 링크 클릭, 문자 회신
입력: 수신거부 유입 · 고객 매칭 · 동의 원장(J-01)
규칙: 유입되면 동의 상태(B-16)에 자동 반영하고 이후 발송 대상에서 즉시 제외한다. 처리 결과를 통지해야 한다 — 법정 의무다. 080 번호 개설과 알림톡 수신거부 링크는 K-13에서 관리한다. 정보성 알림은 수신거부와 무관하게 계속 발송한다
결과: 동의 철회 반영, 처리 결과 통지, 발송 대상 제외
예외: 번호로만 들어와 고객 매칭이 안 되는 건은 번호 단위로 차단하고 매칭은 나중에 한다 — 매칭될 때까지 발송하면 위법이다

RC-E-10발송 비용·잔여 건수1차

R1SC-M24

목적: 얼마 쓰고 얼마 남았는지 안다. 사업 모델의 접점
트리거: 캠페인 작성 시, 정기 조회
입력: 채널별 단가 · 잔여량 · 충전·사용 내역
규칙: 알림톡·문자 단가를 표시하고 발송 전 예상 비용을 계산한다. 잔여 건수가 부족하면 발송을 막는다(E-05). 충전과 사용 내역을 남겨 정산이 가능하게 한다. 대체발송(E-14)은 단가가 달라 비용이 예상보다 늘 수 있다 — 이 차이를 보여준다
결과: 비용 표시, 잔여량 갱신
예외: 충전 주체가 매장인지 본사인지에 따라 화면 위치가 달라진다
미결: 알림톡 발신프로필·템플릿 심사 주체와 비용 부담 주체 (미창조 vs 매장)

E-4. 성과·부가 — 3개

RC-E-08캠페인 성과 추적2차

R1SC-M25

목적: 보낸 것이 매출로 이어졌는지 본다
트리거: 발송 후 일정 기간 경과
입력: 발송 건(E-14) · 예약 발생(A-02) · 결제(C-01) · 쿠폰 사용(E-09)
규칙: 발송·오픈·예약 전환·매출 기여를 단계별로 낸다. 귀속 기간을 정해야 한다 — 발송 후 며칠 안의 방문을 캠페인 성과로 볼지. 이 값이 성과를 크게 좌우한다
결과: 캠페인별 성과, E-04 예상 효과의 학습 데이터
예외: 여러 캠페인을 받은 고객의 전환을 어디에 귀속할지 규칙이 필요하다
미결: 성과 귀속 기간과 중복 귀속 규칙

RC-E-09쿠폰 발급·사용 관리1차

R1/R2SC-M26

목적: 쿠폰을 발급하고 사용을 추적한다
트리거: 캠페인 발송 시 첨부, 개별 발급
입력: 쿠폰 유형 · 할인 조건 · 유효기간 · 할인 상한(K-04)
규칙: 발급 시 고객·캠페인과 연결한다. 결제 시 적용(C-06)되며 할인 상한(K-04)을 넘지 못한다. 사용 현황을 캠페인 성과(E-08)로 되먹인다
결과: 쿠폰 원장, 사용 이력
예외: 유효기간 만료 쿠폰의 재발급 정책이 필요하다. 중복 사용 방지는 결제 시점 검증

RC-E-12A/B 테스트2차

R1SC-M45

목적: 문구·채널·타이밍 중 무엇이 나은지 비교한다
규칙: 대상을 무작위 분할해 변형을 보내고 성과(E-08)를 비교한다

미창조㈜ · AX 사업추진 TF

16-F. 디자이너 운영 기능 상세 — 16개

15번 목록의 F 도메인을 와이어프레임 작성자가 화면에 무엇을 놓을지 판단할 수 있는 수준까지 폈다. 기능 하나를 여섯 줄(목적·트리거·입력·규칙·결과·예외)로 정의한다.

16개1차72차9미결 32차 미작성 8

상위: 15. RIAHN CONNECT 기능 목록 · 화면 목록 — F 도메인
필드 정의와 표기(⚑ 분리 검토 · ▷ 2차 상세 미작성)는 16-C 0-1과 같다
작성: 이원섭 PM · 2026-08-11

0. 이 도메인은 다른 도메인이 가장 많이 참조한다

15개뿐이지만 다른 도메인에서 F를 가리킨 횟수가 31회로 전 도메인 중 1위다. 매출 귀속(C-10)·정산(K-11)·예약 배치(A-06·A-16)·성과 지표(D-02)가 전부 여기에 물려 있다. 여기가 흔들리면 넓게 흔들린다.

제약 넷

노무 수용성이 설계 제약이다. 성과와 정산 데이터를 누가 보느냐가 도입 저항을 만든다. 디자이너는 본인 것만 보고(SC-D16), 타 디자이너 성과와 수수료는 마스킹된다(J-08). 이건 UI 옵션이 아니라 권한 설계다.
사람은 들어오고 나간다. 미용업 이직률을 전제로 설계한다. 퇴사자 계정은 삭제가 아니라 비활성이고 과거 시술 이력의 담당자 표기는 남는다(F-15).
지표는 비교되는 순간 압력이 된다. 기록률(G-06)·만족도(G-05)·재방문율을 평가에 쓰면 형식적 입력과 점수 관리가 시작된다. 코칭용과 평가용의 경계를 문서에 명시한다.
2차년도 항목이 많다. 15개 중 8개가 2차다. 1차에 필요한 것은 근무표·프로필·성과·정산기초·근태·입퇴사 일곱이다.

0-2. 군집

군집	기능	주 화면
F-1 인사·근무	5	SC-M27 근무표 · SC-M38 근태 · SC-D12 · SC-D13
F-2 성과·정산	4	SC-D08 본인 성과 · SC-D16 내 정산 · SC-M28 디자이너 관리
F-3 성장·배치	6	SC-D09~D11 · SC-M28 · SC-H15

군집

기능

주 화면

F-1 인사·근무

SC-M27 근무표 · SC-M38 근태 · SC-D12 · SC-D13

F-2 성과·정산

SC-D08 본인 성과 · SC-D16 내 정산 · SC-M28 디자이너 관리

F-3 성장·배치

SC-D09~D11 · SC-M28 · SC-H15

16-F. 디자이너 운영 — RIAHN CONNECT 기능 상세

F-1. 인사·근무 — 5개

RC-F-01근무표 편성1차

R1 승인 / R3 신청SC-M27 SC-D12

목적: 누가 언제 일하는지 정한다. 예약 가능 슬롯의 원천
트리거: 주·월 단위 근무 편성. 휴무 신청 발생
입력: 근무 패턴 · 영업시간(K-01) · 디자이너 정원 · 휴무 신청
규칙: 근무 패턴을 등록하면 캘린더의 가용 슬롯이 된다(A-01). 휴무 신청은 승인을 타며 승인 대기함(SC-M43)에 모인다. 승인된 휴무 구간에 이미 예약이 있으면 재배정(A-16)으로 넘긴다. 점주 부재 시 승인은 J-13 위임
결과: 근무표 확정, 예약 가능 슬롯 갱신
예외: 승인 전 신청분은 슬롯을 막지 않는다 — 막으면 승인이 늦어질 때 예약을 못 받는다

RC-F-16휴무 신청·승인1차

R3 신청 / R1 승인SC-D12 SC-M43 SC-M27

목적: 디자이너의 휴무 요청을 받아 처리한다
트리거: 디자이너 휴무 신청
입력: 신청 기간 · 사유 · 해당 기간 예약 현황 · 승인 권한(J-04, 부재 시 J-13)
규칙: 신청은 승인 대기함(SC-M43)에 모인다. 승인 전 신청분은 슬롯을 막지 않는다 — 막으면 승인이 늦어질 때 예약을 못 받는다. 승인된 기간에 이미 예약이 있으면 A-16 재배정으로 넘긴다
결과: 휴무 확정, 근무표(F-01) 반영, 재배정 트리거
예외: 당일 결근·조퇴는 신청이 아니라 사후 등록이며 즉시 A-16을 탄다

RC-F-02디자이너 프로필1차

R1/R3SC-M28

목적: 디자이너의 기본 정보와 전문성을 정의한다. 가격·배정·추천이 여기서 갈린다
트리거: 입사 등록(F-15), 승급, 전문분야 변경
입력: 직급 · 전문분야 · 지명료 · 포트폴리오 연결(F-05)
규칙: 직급이 메뉴 가격을 바꾼다(K-03 디자이너 직급별 가격). 지명료는 결제 시 옵션으로 붙는다(C-02). 전문분야는 역매칭·추천(SFR-A~C)의 입력이 된다. 승급 시 가격이 바뀌므로 적용 기준일을 둔다(K-16)
결과: 프로필 확정, 가격·배정·추천에 반영
예외: 직급 변경이 소급되면 과거 결제가 재계산된다 — K-16 기준일로 막는다

RC-F-13출퇴근·근태 기록1차

R3 기록 / R1 조회SC-M38 SC-D13 SC-D16

목적: 실제 근무 시간을 남긴다. 수수료 정산의 기초 데이터
트리거: 출근·퇴근 체크
입력: 체크 시각 · 근무표(F-01) 대비
규칙: 근무시간을 집계해 F-08 정산 기초자료로 넘긴다. 근무표와 실제의 차이(지각·조퇴·연장)를 구분해 남긴다. 디자이너는 본인 기록만 조회한다(SC-D13). 조퇴는 A-16 결원 재배정을 트리거한다
결과: 근태 기록, 근무시간 집계
예외: 체크 누락을 사후 보정할 수 있어야 하되 보정은 승인과 이력을 남긴다

RC-F-15입·퇴사·이동 처리1차

R1SC-M28

목적: 사람이 들어오고 나갈 때 데이터를 정리한다. 상시 발생하는 일
트리거: 입사, 퇴사, 매장 이동
입력: 계정(K-07) · 담당 고객 · 미래 예약 · 미정산 잔여(F-08) · 단말 세션(L-09)
규칙: 퇴사는 계정 비활성이지 삭제가 아니다 — 과거 시술 이력(B-04)의 담당자 표기는 보존된다. 처리 항목이 넷이다. ①담당 고객 승계 ②미래 예약 일괄 이관 ③미정산 잔여 처리 ④단말 원격 로그아웃(L-09). 지명 예약은 고객 동의가 필요하므로 개별 연락 대상으로 분리한다(A-16과 같은 원칙)
결과: 계정 비활성, 고객·예약 승계, 정산 마감
예외: A-16(당일 결원)과 다르다 — 이건 영구 처리다. 임직원 개인정보의 보관기간은 J-06 대상
미결: 이동 시 고객·예약이 디자이너를 따라가는가. 위 규칙은 매장에 남기는 승계·이관으로 적었다. 디자이너 중심으로 가면 이 규칙이 통째로 바뀐다. 15번 5장 26번

RC-F-14다중 매장 근무 디자이너2차

R5 본사SC-H07

목적: 프리랜서·순회 디자이너의 복수 매장 소속을 처리한다
규칙: 한 사람이 여러 매장에 소속될 수 있게 하고, 매출 귀속(C-10)과 정산(F-08)을 매장별로 분리한다

F-2. 성과·정산 — 4개

RC-F-03본인 성과 대시보드1차

R3SC-D08 SC-M28

목적: 디자이너가 자기 성과를 스스로 본다
트리거: 앱 진입, 주·월 마감
입력: 매출 귀속(C-10) · 재방문율 · 만족도(G-05) · 역매칭 노출 · 개인 목표(D-15)
규칙: 본인 것만 보인다. 타 디자이너 성과는 마스킹(J-08). 개인 목표 대비 달성률을 함께 낸다(D-15) — 절대값만 주면 잘하고 있는지 알 수 없다. 재시술(C-25)은 매출 0이므로 건수로 별도 표기한다
결과: 조회
예외: 목표가 설정되지 않았으면 달성률 대신 추이만 낸다

RC-F-08수수료 정산 기초자료1차

R1 / R3(본인)SC-M28 SC-D16

목적: 수수료 계산의 근거를 만든다. 급여와 직결되므로 오차가 곧 분쟁
트리거: 월마감(C-26) 이후
입력: 매출 귀속(C-10) · 요율(K-11) · 근태(F-13) · 적용 기준일(K-16)
규칙: 월마감 잠금(C-26) 이후의 확정 매출로 산정한다 — 잠기기 전 숫자로 지급하면 나중에 바뀌어 분쟁이 된다. 요율이 바뀌면 K-16 기준일에 따라 소급하지 않는다. ⚠️ 열람 권한 분리 필수 — 점주는 전체, 디자이너는 본인만(SC-D16)
결과: 정산 기초자료. 실제 지급은 외부 급여 시스템
예외: 재시술(C-25)은 매출 0이지만 시간을 썼다. 시간 기반 요소가 있으면 반영 방식을 정해야 한다
미결: 요율 데이터를 CONNECT가 보유할지 — 급여 정보는 노무 민감 항목이다. 보유하지 않으면 매출 귀속까지만 제공하고 계산은 외부에서

RC-F-09디자이너 관리(점주)2차

R1SC-M28

목적: 점주가 소속 디자이너를 비교하고 코칭 포인트를 잡는다
트리거: 주·월 단위 리뷰
입력: 디자이너별 지표(F-03) · 코칭 포인트 자동 제안(S13)
규칙: 지표 비교와 함께 무엇을 개선하면 되는지 제안을 낸다. ⚠️ 코칭용과 평가용의 경계를 명시한다 — 평가에 쓰이는 순간 기록률(G-06)이 형식화된다
결과: 비교 뷰, 코칭 제안
예외: 표본이 적은 신입은 비교에서 제외하거나 별도 구간으로 둔다

RC-F-06익명 벤치마킹2차

R3SC-D09

목적: 매장·전국 평균 대비 본인 위치를 본다
규칙: 타인을 식별할 수 없게 익명 집계로만 낸다. 표본이 적으면 역산이 가능하므로 최소 표본 수를 둔다
미결: 익명 집계 원칙에서 본사를 예외로 둘지. 이 문장은 디자이너끼리를 전제로 쓴 것인데, 본사가 개별 디자이너 성과를 보기로 결정됐다(15번 5장 27번). 예외로 둔다면 누구에게 익명인지를 문장에 명시해야 한다

F-3. 성장·배치 — 6개

RC-F-04강점 분석·자가인식 갭2차

R3SC-D09

목적: 스스로 생각하는 강점과 데이터가 말하는 강점의 차이를 보여준다
규칙: 자가 인식 입력과 실제 시술·만족도 데이터를 비교한다(S7)

RC-F-05포트폴리오 업로드·태깅2차

R3SC-D10

목적: 시술 결과 사진을 모아 강점을 시각화한다
규칙: Vision AI가 카테고리를 자동 태깅한다(S8). 이미지는 저장하지 않는다 — 태깅 결과만 남긴다. 고객 사진(G-04)을 쓰려면 별도 동의가 필요하다

RC-F-07교육 추천2차

R3SC-D11

목적: 부족한 영역의 교육 과정을 연결한다
규칙: 강점 분석(F-04) 결과를 MCZONE 과정에 매칭한다(S9)

RC-F-10신입 콜드스타트 배정2차

R2SC-M28

목적: 이력이 없는 신입에게 무리한 고객이 가지 않게 한다
규칙: "무난한 고객 패턴"을 우선 배정한다. 소요시간 보정(A-06)도 이력이 쌓일 때까지 표준값을 쓴다

RC-F-11스케줄 최적화2차

R1/R2SC-M27

목적: 소요시간 패턴을 학습해 배치를 제안한다
규칙: 실측 소요시간(A-06)을 학습해 배치안을 낸다(S10). 제안이며 실행은 사람이 정한다

RC-F-12에스컬레이션 L1~L42차

R1 → R4/R5SC-H15

목적: 고객과 디자이너의 미스매치를 단계적으로 해소한다
규칙: L1 감지 → L2 매장 상담 → L3 본사 개입 → L4 매장 간 매칭. 클레임 반복(B-08)이 감지 신호

미창조㈜ · AX 사업추진 TF

16-G. 시술 기록·상담 기능 상세 — 9개

15번 목록의 G 도메인을 와이어프레임 작성자가 화면에 무엇을 놓을지 판단할 수 있는 수준까지 폈다. 기능 하나를 여섯 줄(목적·트리거·입력·규칙·결과·예외)로 정의한다.

9개1차92차0미결 02차 미작성 0

상위: 15. RIAHN CONNECT 기능 목록 · 화면 목록 — G 도메인
필드 정의와 표기(⚑ 분리 검토 · ▷ 2차 상세 미작성)는 16-C 0-1과 같다
작성: 이원섭 PM · 2026-08-11

0. 이 도메인이 사업 전체를 좌우한다

계획서·과업지시서 어디에도 독립 항목으로 없지만, 이 사업의 데이터 품질 전체가 여기서 결정된다.

[8/7 미팅 근거] 본부장 — "쓰는 매장이 있고, 안 쓰는 매장이 있고 그런 차이가 좀 있습니다… 메모를 쓰는 매장이 많지는 않고… 워낙 이 핸드[SOS]에 데이터 만들어 놓은 건 많은데 사실 다 쓰는 게 아니거든요."

즉 기존 CRM은 기록 필드가 있어도 안 쓰인다. 데이터가 없는 게 아니라 입력이 안 되는 것이 문제다. RIAHN CONNECT가 헤어짱·핸드SOS를 대체해도 입력 UX가 같으면 결과도 같다.

제약 넷

입력 시간이 3탭을 넘으면 안 쓰인다. 이 도메인의 성패는 기능 개수가 아니라 G-02 하나에 달려 있다. 젖은 손으로, 시술 중에, 서서 입력한다.
정량 입력과 빠른 입력은 상충한다. 약제 소진(O-07)을 재려면 g/ml 단위가 필요한데 그걸 손으로 넣으라고 하면 아무도 안 쓴다. 배합 프리셋 선택 = 정량 자동 산출로 푼다.
기록되지 않은 것은 없는 것이다. 결제는 남는데 시술이 안 남는 건이 상당수다(C-12). 기록률 자체를 지표로 관리한다(G-06).
사진과 상담 내용은 동의에 걸린다. 촬영 전 동의 확인이 선행되고, 원본은 보관하지 않는다.

1. 기록 입력 (4)

RC-G-01시술 기록 입력1차

R3 디자이너SC-D04 (D3 모바일태블릿)

목적: 실제로 무엇을 어떻게 했는지 남긴다. 추천·레시피·이탈 예측 모델의 유일한 원천 데이터
트리거: 시술 완료 직후. 또는 시술 중 단계별로
입력: 예약·고객(A-10) · 메뉴(K-03) · 약제 마스터(O-07) · 직전 시술 이력(B-04)
규칙: 실제 시술 내용·약제·배합비·소요시간을 남긴다. 예약된 시술과 실제가 다르면 실제를 기준으로 하고 차이를 남긴다 — 결제(C-01)가 이 값을 쓴다. 소요시간은 자동 측정을 우선하고 수기 보정을 허용한다(A-06 실측 보정의 입력). 약제는 O-07 코드 체계를 쓴다
결과: 시술 기록 1행, B-04 타임라인에 추가, C-01 결제의 확정 근거, I-08 레시피 환류 입력, O-07 재고 소진
예외: 미입력 상태로 결제가 끝나면 C-12 정합 보정 대상이 된다. 네트워크가 끊겨도 입력은 계속되고 재연결 시 동기화한다

RC-G-02빠른 입력 UX1차

R3SC-D04

목적: 기록을 실제로 하게 만든다. 와이어프레임의 성패가 여기 달려 있다
트리거: G-01 입력 시작
입력: 표준 태그 · 직전 시술(B-04) · 음성 입력 · 배합 프리셋(O-07)
규칙: 3탭 이내 완료를 목표로 한다. 세 가지 수단을 병용한다 — ①표준 태그 선택 ②직전 시술 복사 후 수정 ③음성 입력. 터치 타깃은 최소 44px, 시술 중 사용을 전제로 조작 단계를 최소화한다. ⚠️ 약제 정량 입력과 상충하므로 배합 프리셋을 고르면 정량이 자동 산출되게 하고 수기 계량을 강요하지 않는다
결과: G-01 기록 완료
예외: 프리셋에 없는 배합은 수기 입력을 허용하되 그 건은 별도 표시해 프리셋 보완에 쓴다

RC-G-03상담 기록1차

R3SC-D07 SC-C01

목적: 고객이 무엇을 원했는지 남긴다. 시술 결과와 요구의 차이가 클레임의 근원
트리거: 시술 전 상담
입력: 상담 내용 · STT 음성 · 고객 요구사항
규칙: 텍스트와 STT 둘 다 받는다. 요구사항을 구조화해 다음 방문 때 브리핑(B-13)에 실린다. 고객 확인 화면(SC-C01)에 오늘 할 시술·예상 금액·소요시간을 띄워 합의를 남긴다
결과: 상담 기록, 고객 확인, 시술 기록(G-01)의 참조
예외: STT는 매장 소음에서 정확도가 떨어진다. 원문과 교정본을 함께 두고 교정을 강제하지 않는다

RC-G-04시술 전후 사진 촬영1차

R3SC-D06

목적: 결과를 시각으로 남긴다. 클레임 근거이자 포트폴리오(F-05) 원천
트리거: 시술 전, 시술 후
입력: 카메라 · 동의 상태(J-01, B-16)
규칙: 촬영 → 동의 확인 → 업로드 순서를 지킨다. 동의가 없으면 촬영 단계에서 막는다 — 찍고 나서 묻는 순서면 이미 늦다. 원본은 보관하지 않는다(비식별 처리 후 저장). 전후를 쌍으로 묶는다
결과: 사진 저장, B-06 고객 카드에 연결
예외: 동의 철회 시 기존 사진 열람이 즉시 막힌다. 삭제 요청(J-10)은 별도 절차

2. 수집·품질 (5)

RC-G-05만족도 수집1차

R6 고객SC-C04

목적: 결과에 대한 고객 반응을 즉시 받는다
트리거: 시술 직후 거울앞 태블릿. 또는 사후 링크 발송
입력: 별점 · 간단 코멘트
규칙: 시술 직후 태블릿이 응답률이 가장 높다. 항목을 늘리지 않는다 — 별점 하나와 선택 코멘트면 충분하다. 사후 링크는 응답률이 낮지만 솔직도가 높으므로 병행한다
결과: 만족도 1행, B-04 이력에 표시, B-10 이탈 위험 입력, F-03 디자이너 성과 입력
예외: 저점 응답은 클레임(B-08)으로 전환할 수 있게 한다. 담당 디자이너 앞에서 입력하는 구조라 점수가 관대해지는 편향이 있다 — 사후 링크 응답과 분리해 본다

RC-G-06기록 완료율 표시1차

R1SC-M19 SC-M28

목적: 기록이 실제로 되고 있는지 본다. 이 도메인이 작동하는지 판정하는 지표
트리거: 일·주 단위 집계
입력: 결제 건수 대비 시술 기록 건수 · 디자이너별·매장별 분해
규칙: 디자이너별·매장별 기록률을 낸다. 낮은 쪽을 벌하는 용도가 아니라 입력 UX가 어디서 막히는지 찾는 용도로 쓴다 — 특정 시술군에서만 기록률이 낮으면 그 입력 흐름에 문제가 있는 것이다. 8/7 미팅의 "메모 작성 우수 매장 식별"(랩큐 액션 26번)이 여기 걸린다
결과: 기록률 지표, 저조 구간 식별
예외: 표본 편향에 주의한다. 기록이 잘 되는 매장의 데이터만 모델에 들어가면 결과가 왜곡된다

RC-G-07미기록 리마인더1차

자동 → R3SC-M19 SC-D01

목적: 빠뜨린 기록을 그날 안에 채우게 한다
트리거: 결제 완료 + 시술 기록 없음이 일정 시간 지속
입력: C-12 정합 검사 결과 · 담당 디자이너
규칙: 담당 디자이너에게 먼저 보낸다. 매니저에게 먼저 가면 대신 입력하게 되고 그러면 내용이 부정확해진다. 퇴근 전 한 번 모아서 보내는 편이 건별 알림보다 낫다. 알림 라우팅은 K-17
결과: 리마인더 발송, 미기록 목록
예외: 며칠 지난 건은 기억에 의존하므로 정확도가 떨어진다. 경과일을 함께 표시해 신뢰도 판단에 쓴다

RC-G-08시술 레시피 뷰1차

R3SC-D05(경계 — SFR-I)

목적: 시술 중 무엇을 어떻게 할지 태블릿으로 본다
트리거: 시술 시작
입력: 확정 레시피(SFR-I) · 고객 이력(B-04) · 진단(B-05)
규칙: 단계 체크리스트와 타이머를 제공한다. 방치 시간(A-07)이 타이머와 연동된다. 스펙 소유는 SFR-I이며 여기서는 표시와 데이터 계약만 정의한다 — 와이어프레임에 점선 박스 + "타 모듈 연동" 라벨
결과: 조회. 실제 값과 다르면 G-01에서 실제를 기록
예외: 레시피가 없는 시술은 빈 상태로 둔다

RC-G-09레시피 확정 갱신1차

자동SC-D04(경계 — I-08)

목적: 실제 시술값을 레시피에 되먹인다. 레시피가 현실과 멀어지지 않게 하는 장치
트리거: G-01 기록 완료
입력: 실제 시술값(약제·배합비·소요시간) · 기존 레시피 버전
규칙: 실제값으로 확정 버전을 갱신한다. 개별 시술 한 건으로 바로 바꾸지 않고 누적된 실제값의 경향으로 판단한다. 버전을 남겨 되돌릴 수 있게 한다
결과: 레시피 확정 버전 갱신, I-08 환류
예외: 기록 신뢰도가 낮은 건(G-07 지연 입력 등)은 환류에서 가중치를 낮춘다

미창조㈜ · AX 사업추진 TF

16-H. 자연어 운영 에이전트 기능 상세 — 7개

15번 목록의 H 도메인을 와이어프레임 작성자가 화면에 무엇을 놓을지 판단할 수 있는 수준까지 폈다. 기능 하나를 여섯 줄(목적·트리거·입력·규칙·결과·예외)로 정의한다.

7개1차62차1미결 02차 미작성 1

상위: 15. RIAHN CONNECT 기능 목록 · 화면 목록 — H 도메인
필드 정의와 표기(⚑ 분리 검토 · ▷ 2차 상세 미작성)는 16-C 0-1과 같다
작성: 이원섭 PM · 2026-08-11

0. 여섯 개가 한 화면에서 한 흐름으로 돈다

H 도메인은 다른 도메인과 성격이 다르다. 여섯 기능이 SC-M30 한 화면에서 하나의 대화 흐름을 이룬다. 질의 입력 → 권한 필터 → 답변 생성 → 근거 표시 → 액션 제안 → 실행. 그래서 군집을 나누지 않는다.

제약 넷

에이전트는 새 권한을 만들지 않는다. 사람이 화면에서 못 보는 것을 대화로는 볼 수 있으면 권한 설계가 무너진다. J-04 권한이 그대로 적용된다.
근거 없는 답변은 쓰지 않는다. 숫자만 말하면 현장이 믿지 않고, 틀렸을 때 검증할 방법도 없다. 어떤 데이터를 어느 기간으로 봤는지 항상 붙인다.
실행은 승인을 탄다. 타임딜 생성·캠페인 발송·슬롯 조정은 되돌리기 어렵다. 제안하고 사람이 확인한 뒤 실행한다.
스펙 소유는 SFR-D(ELLM)다. 여기서는 운영 에이전트로 내장된 형태와 데이터 계약만 정의한다. 모델 내부는 범위 밖이다.

1. 기능 (6)

RC-H-01질의 입력1차

R1/R2SC-M30

목적: 리포트 화면을 찾아다니지 않고 물어서 답을 얻는다
트리거: 에이전트 화면 진입, 다른 화면에서 호출
입력: 자연어 질의 · 추천 질문 칩 · 현재 맥락(보고 있던 화면)
규칙: 추천 질문 칩을 제공한다 — 빈 입력창만 주면 무엇을 물어야 할지 몰라 아무도 안 쓴다. 자주 쓰이는 질의를 칩으로 노출하고, 실제 사용 이력에서 칩을 갱신한다. 다른 화면에서 호출하면 그 맥락(매장·기간·디자이너)을 물려받는다
결과: 질의 접수
예외: 답할 수 없는 질의는 모른다고 말한다. 추측으로 답하면 신뢰가 한 번에 무너진다

RC-H-05권한 기반 범위 제한1차

자동SC-M30

목적: 대화가 권한 우회 통로가 되지 않게 한다. 답변 생성보다 먼저 걸린다
트리거: 질의 접수 직후 자동
입력: 질의 · 역할(J-04) · 필드 마스킹 규칙(J-08) · 매장 범위
규칙: 역할별 조회 가능 데이터만 응답 대상에 넣는다. 디자이너가 타인의 정산을 물으면 답하지 않고, 매장 계정이 타 매장을 물으면 범위 밖임을 알린다. 집계로는 답할 수 있는 경우(전국 평균 등)와 개별로는 답할 수 없는 경우를 구분한다
결과: 조회 범위 확정
예외: 범위를 좁힌 사실을 답변에 명시한다 — 모르고 부분 답변을 전체로 오해하면 판단이 틀어진다

RC-H-02근거 데이터 동반 답변1차

자동SC-M30

목적: 말로만이 아니라 숫자와 함께 답한다
트리거: 질의 처리
입력: 범위 제한된 데이터(H-05) · 집계 기준(D-16)
규칙: 답변에 표·차트를 함께 낸다. 문장은 요약이고 근거는 데이터다. 집계 기준(D-16)이 적용된 값을 쓰며, 마감 전 잠정치면 그 사실을 표시한다. 개인정보가 포함되는 답변은 마스킹(J-08)을 적용한다
결과: 답변 + 근거 데이터
예외: 데이터가 부족하면 부족하다고 말한다. 표본이 적은 매장의 비율 지표는 오해를 부른다

RC-H-04근거 출처 표시1차

자동SC-M30

목적: 어디서 온 숫자인지 밝힌다. 검증 가능성의 근거
트리거: 답변 생성 시
입력: 참조한 데이터 원천 · 기간 · 집계 기준
규칙: 어떤 데이터를 어느 기간으로 썼는지 명시한다. 해당 원천 화면으로 이동할 수 있게 링크한다 — 의심되면 직접 확인할 수 있어야 한다. 지식베이스(M-10) 문서를 참조했으면 문서와 버전을 밝힌다
결과: 출처 표시, 원천 화면 링크
예외: 여러 원천을 조합한 답변은 어느 부분이 어디서 왔는지 나눠 표시한다

RC-H-03실행 액션 제안1차

R1 승인SC-M30

목적: 답변에서 끝나지 않고 조치까지 연결한다
트리거: 답변 후 액션 제안, 사용자 실행 지시
입력: 제안 가능한 액션 목록 · 권한(J-04) · 승인 절차
규칙: 타임딜 생성(K-08)·캠페인 발송(E-05)·슬롯 조정(A-18) 같은 액션을 제안한다. 제안과 실행 사이에 반드시 확인 단계를 둔다 — 무엇이 어떻게 바뀌는지 보여주고 사람이 승인한다. 실행은 해당 기능의 정상 경로를 그대로 타므로 그 기능의 검증도 그대로 적용된다(예: 발송이면 E-07 수신동의 검증)
결과: 액션 실행, 실행 이력
예외: 되돌리기 어려운 액션은 확인 단계를 강화한다. 실행 결과를 반드시 회신한다

RC-H-07액션 실행1차

R1 승인SC-M30

목적: 제안된 조치를 실제로 실행한다. 이 도메인에서 유일하게 시스템을 바꾸는 지점
트리거: 사용자가 제안을 승인
입력: 제안된 액션 · 권한(J-04) · 대상 기능의 검증 규칙
규칙: 해당 기능의 정상 경로를 그대로 탄다 — 발송이면 E-07 수신동의 검증을, 타임딜이면 K-04 할인 상한을 그대로 거친다. 에이전트를 통했다고 검증을 건너뛰면 안 된다. 실행 전 무엇이 어떻게 바뀌는지 보여주고, 실행 후 결과를 회신한다
결과: 액션 실행, 실행 이력(J-05)
예외: 되돌리기 어려운 액션은 확인 단계를 강화한다. 실행 실패 시 부분 적용 상태로 두지 않는다

RC-H-06질의 이력·즐겨찾기2차

R1/R2SC-M30

목적: 반복해 쓰는 질의를 저장한다
규칙: 이력을 남기고 자주 쓰는 질의를 즐겨찾기로 고정한다. 이력은 추천 질문 칩(H-01)의 재료가 된다

미창조㈜ · AX 사업추진 TF

16-I. 채널 연동·데이터 이관 기능 상세 — 14개

15번 목록의 I 도메인을 와이어프레임 작성자가 화면에 무엇을 놓을지 판단할 수 있는 수준까지 폈다. 기능 하나를 여섯 줄(목적·트리거·입력·규칙·결과·예외)로 정의한다.

14개1차132차1미결 02차 미작성 1

상위: 15. RIAHN CONNECT 기능 목록 · 화면 목록 — I 도메인
필드 정의와 표기(⚑ 분리 검토 · ▷ 2차 상세 미작성)는 16-C 0-1과 같다
작성: 이원섭 PM · 2026-08-11

0. 이 도메인은 전제가 흔들린 채로 설계된다

[8/7 미팅 근거 — 네이버] 네이버클라우드 정홍석 매니저 확인 — API 개방은 ①기본 검토 요건 매장 1만 개 이상, ②"얘기라도 되는" 선 5,000개 이상, ③500~1,000개는 명시적 거절선. 리안헤어는 490개다. 유일한 현실적 우회로는 네이버페이 결제 집중 → 파이낸셜 조직 경유 개방 요청.

[8/7 미팅 근거 — 기존 CRM] 본부장 — "데이터를 API 공유 받는 것까지는 협의를 해 놨어요." 다만 시장이 커지면 "기존 CRM사와 충돌이 있을 수 있다" 고 인정했다. 미창조가 CRM 시장에 진입하면 같은 상대가 경쟁자가 되어 API가 닫힐 위험이 구조적으로 존재한다.

제약 다섯

채널 어댑터는 플러그인이다. 네이버가 열리지 않아도 헤어짱·핸드SOS 어댑터로 대체 가능해야 한다. 화면에서 채널은 데이터로 관리하고 하드코딩하지 않는다. 이 원칙만 지키면 전제가 바뀌어도 화면은 그대로 쓴다.
이관은 단방향이 기본이다. 외부 CRM이 쓰기(write) API를 줄 가능성은 낮고 계획서의 이관 전제도 CSV 추출이다. 양방향(I-11)은 2차 옵션으로 둔다.
이관은 한 번에 성공하지 않는다. 스테이징 → 검증 → 승인 → 반영 4단계를 거치고 롤백이 가능해야 한다.
잔액은 자동 반영하지 않는다. 회원권·포인트는 건별 대조와 승인을 거친다(C-21). 틀리면 현장에서 항의가 들어온다.
API가 닫힐 때를 대비한다. 병행 운영(I-10)과 로컬 서버 직수집(L)이 그 시점의 보험이다.

0-2. 군집

군집	기능	주 화면
I-1 채널 연동	6	SC-M33 채널 연동 상태 · SC-M34 동기화 오류 큐
I-2 데이터 이관	6	SC-H13 데이터 이관 콘솔
I-3 검증	2	SC-H13

군집

기능

주 화면

I-1 채널 연동

SC-M33 채널 연동 상태 · SC-M34 동기화 오류 큐

I-2 데이터 이관

SC-H13 데이터 이관 콘솔

I-3 검증

SC-H13

16-I. 채널 연동·데이터 이관 — RIAHN CONNECT 기능 상세

I-1. 채널 연동 — 6개

RC-I-01채널 연동 설정1차

R1/R5SC-M33

목적: 어떤 채널을 붙일지 정하고 켠다. 플러그인 구조가 이 기능의 본체
트리거: 채널 도입, 어댑터 교체
입력: 채널 목록 · 인증 정보(K-09) · 어댑터 종류
규칙: 채널을 데이터로 관리한다 — 네이버·카카오·헤어짱·핸드SOS를 같은 인터페이스로 다룬다. 어댑터가 바뀌어도 상위 화면(A-09 채널 뱃지, D-04 채널별 매출, A-18 슬롯 배분)은 그대로 동작해야 한다. 채널별로 지원 기능이 다르므로(예약 수신만 / 양방향) 역량을 선언하고 화면이 그에 맞춰 접힌다
결과: 채널 활성화, 웹훅 수신 개시
예외: 네이버 API가 열리지 않으면 헤어짱·핸드SOS 어댑터로 대체한다. 이때 화면 변경이 없어야 설계가 성공한 것이다

RC-I-02웹훅 수신 모니터1차

R1/R5SC-M33

목적: 들어오고 있는지 실시간으로 본다
트리거: 상시, 이상 감지 시
입력: 채널별 수신 건수 · 지연 · 실패율
규칙: 수신이 멈추면 예약이 안 들어오는데 화면에는 그냥 한가해 보인다 — 끊김을 적극적으로 알려야 한다. 채널별 평시 수신량 대비 급감을 감지해 알린다(K-17 라우팅)
결과: 수신 현황, 이상 알림
예외: 실제로 예약이 없는 것과 수신이 끊긴 것을 구분해야 한다. 하트비트가 있으면 쓴다

RC-I-03매핑·정규화 규칙1차

목적: 채널마다 다른 표현을 우리 체계로 옮긴다
트리거: 채널 연동 개시, 미매핑 건 발생
입력: 채널별 메뉴·시간·고객 필드 · 우리 마스터(K-03, B)
규칙: 채널 메뉴명을 우리 메뉴(K-03)에 대응시킨다. 미매핑 건은 버리지 않고 "기타"로 받아 목록으로 남긴다(A-09) — 버리면 매출이 사라진다. 매핑 규칙은 매장별로 다를 수 있다
결과: 매핑 테이블, 정규화된 데이터
예외: 채널이 메뉴를 바꾸면 매핑이 깨진다. 신규 미매핑 발생을 알린다

RC-I-04실패·충돌 큐1차

R2/R5SC-M34

목적: 실패한 것을 모아 사람이 해소한다. 버려지는 데이터가 없게 하는 안전망
트리거: 동기화 실패, 충돌 발생
입력: 실패 건 · 사유 · 원본 데이터
규칙: 실패 유형별로 묶어 보여준다 — 매핑 없음·중복·검증 실패·전송 오류. 재처리 시 중복 생성을 막는다(멱등 키). 수동 해소 경로를 반드시 둔다. 큐가 쌓이면 알린다
결과: 해소 처리, 재처리
예외: A-18 슬롯 역동기화 실패는 오버부킹 위험이 있으므로 해당 슬롯을 보수적으로 잠근다

RC-I-05채널 간 중복 예약 탐지1차

자동 → R2SC-M34

목적: 같은 고객이 여러 채널로 넣은 예약을 하나로 본다
트리거: 예약 수신 시 자동
입력: 동일 고객·시간대 예약 · 고객 매칭 규칙(I-06)
규칙: 동일 고객·근접 시간의 예약을 후보로 잡는다. 자동 병합하지 않고 확인을 받는다 — 진짜 두 건일 수도 있다(가족 예약 등). 병합 시 어느 채널 건을 남길지 정한다
결과: 중복 후보 목록, 병합 결과
예외: 채널마다 고객 식별자가 달라 매칭이 불확실하다. 확신도를 함께 보여준다

RC-I-12채널 가용 슬롯 역동기화1차

자동SC-M40

목적: 우리 쪽 예약을 외부 채널에 반영해 오버부킹을 막는다. A-18의 전제
트리거: 자체 예약 발생·취소 시 자동
입력: 슬롯 상태 변화 · 채널별 배분(A-18)
규칙: 예약이 잡히면 해당 슬롯을 외부 채널에서 마감 처리한다. 채널이 쓰기 API를 지원해야 성립하므로 채널 역량(I-01)에 따라 동작이 갈린다. 지원하지 않는 채널은 배분량을 보수적으로 잡아 위험을 줄인다
결과: 외부 채널 슬롯 마감
예외: push 실패는 I-04 큐로 보내고 슬롯을 잠근다. 실패를 무시하면 오버부킹이 난다

I-2. 데이터 이관 — 6개

RC-I-07이관 마법사1차

목적: 외부 CRM 데이터를 안전하게 옮긴다
트리거: 매장 온보딩(M-05)
입력: 원본 데이터(CSV·API) · 스키마 매핑(I-08)
규칙: 스테이징 적재 → 검증 → 승인 → 반영 4단계를 거친다. 원본 스냅샷을 보존해야 롤백(I-14)이 가능하다. 검증 단계에서 형식 오류·필수값 누락·중복을 잡는다. 잔액(회원권·포인트)은 이 경로가 아니라 C-21 건별 대조를 탄다
결과: 이관 완료, 단계별 이력
예외: 대량 데이터는 배치로 나눠 처리하고 중단·재개가 가능해야 한다

RC-I-08스키마 매핑 편집1차

목적: 매장마다 다른 CRM 스키마를 우리 구조에 맞춘다
트리거: 이관 준비
입력: 원본 컬럼 목록 · 대상 필드 · 변환 규칙
규칙: 컬럼 대 필드를 매핑하고 변환 규칙(날짜 형식·코드값 대응)을 정의한다. 코드값 대응표가 없으면 데이터 해석이 불가능하므로 미제공 시 이관을 진행하지 않는다. 매핑을 템플릿으로 저장해 같은 CRM을 쓰는 매장에 재사용한다
결과: 매핑 정의, 재사용 템플릿
예외: 원본에 없는 필수 필드는 기본값을 넣을지 비울지 정한다. 임의로 채우면 나중에 진짜 값과 구분이 안 된다

RC-I-09이관율 리포트1차

목적: 얼마나 옮겨졌는지 본다. 1차 70% / 2차 95% 목표 추적
트리거: 이관 진행 중·후
입력: 원본 건수 · 이관 건수 · 실패 건수 · 항목별 완성도
규칙: 전체 이관율과 항목별 완성도를 나눠 본다 — 고객은 100%인데 시술 이력이 40%면 의미가 다르다. 매장별 진척을 온보딩(M-05)의 다음 단계 진입 조건으로 쓴다
결과: 이관율, 미이관 사유 분포
예외: 원본 자체가 비어 있는 것과 이관에 실패한 것을 구분한다

RC-I-10병행 운영 모드1차

R1/R5SC-H13

목적: 외부 CRM과 동시에 쓰면서 안전하게 넘어간다. API가 닫힐 때의 보험이기도 하다
트리거: 전환 준비 단계 진입
입력: 병행 기간 설정 · 이중 수집 대상
규칙: 일정 기간 양쪽에 데이터를 남긴다. 어느 쪽이 정본인지 명시해야 한다 — 둘 다 정본이면 충돌이 난다. 기간 종료 시 전환 판정을 하고, 판정 기준(이관율·정합성)을 미리 정한다
결과: 병행 상태, 전환 판정
예외: 병행 중 매장이 외부 CRM에만 입력하면 우리 데이터가 비게 된다. 입력 경로를 통제해야 한다

RC-I-13채널 인증 갱신·만료 알림1차

자동 → R1SC-M33

목적: 토큰이 끊겨 연동이 죽는 것을 막는다. I-01의 운용 루프
트리거: 만료 예정일 도래, 인증 실패 발생
입력: 채널별 토큰 만료일 · 인증 상태
규칙: 만료 전에 예고하고 재인증을 유도한다. 만료되면 연동 중단 배너를 띄운다 — 조용히 죽으면 예약이 안 들어오는 걸 며칠 뒤에 안다. 알림 수신자는 K-17
결과: 재인증, 연동 상태 표시
예외: 재인증에 외부 계정 접근이 필요하면 매장이 직접 해야 한다. 절차를 안내한다

RC-I-14이관 롤백·재실행1차

목적: 잘못된 이관을 되돌린다. 이관은 한 번에 성공하지 않는다
트리거: 이관 오류 발견
입력: 이관 배치 ID · 원본 스냅샷(I-07)
규칙: 배치 단위로 취소·되돌리기·부분 재실행을 한다. 이미 사용된 데이터는 롤백할 수 없다 — 이관된 고객으로 예약이 잡혔으면 그 예약이 먼저다. 롤백 가능 범위를 판정해 보여준다
결과: 롤백 실행, 재실행 대상 확정
예외: 잔액 이관(C-21)의 롤백은 특히 위험하다. 승인 전 상태로만 되돌릴 수 있게 한다

I-3. 검증 — 2개

RC-I-06통합 고객 ID 병합 규칙1차

목적: 채널마다 따로 만들어진 고객을 한 사람으로 묶는다
트리거: 이관 시, 채널 유입 시
입력: 채널별 고객 레코드 · 매칭 키(전화번호·이름) · 확신도 기준
규칙: 매칭 규칙을 정의하고 확신도에 따라 자동 병합과 확인 요청을 가른다(B-03). 전화번호가 주 키인데 가족이 공유하는 경우가 있어 이름을 함께 본다. 잘못 합치면 두 사람의 이력이 섞이므로 취소 가능해야 한다
결과: 병합 규칙, 통합 고객 ID
예외: 채널이 마스킹된 번호만 주면 매칭이 불가능하다. 이 경우 별도 레코드로 두고 나중에 합친다

RC-I-11정합성 검증 리포트2차

목적: 양방향 동기화의 차이를 검출한다
규칙: 우리 데이터와 외부 CRM 데이터를 대조해 차이를 낸다

미창조㈜ · AX 사업추진 TF

16-J. 프라이버시·권한 기능 상세 — 16개

15번 목록의 J 도메인을 와이어프레임 작성자가 화면에 무엇을 놓을지 판단할 수 있는 수준까지 폈다. 기능 하나를 여섯 줄(목적·트리거·입력·규칙·결과·예외)로 정의한다.

16개1차132차3미결 32차 미작성 3

상위: 15. RIAHN CONNECT 기능 목록 · 화면 목록 — J 도메인
필드 정의와 표기(⚑ 분리 검토 · ▷ 2차 상세 미작성)는 16-C 0-1과 같다
작성: 이원섭 PM · 2026-08-11

0. 이 도메인은 다른 기능을 잠그는 일을 한다

J의 기능들은 대부분 스스로 무엇을 만들지 않고 다른 기능의 동작을 제한한다. 동의가 없으면 발송이 막히고(E-07), 권한이 없으면 필드가 가려지고(J-08), 삭제 요청이 들어오면 데이터가 사라진다(J-10). 그래서 화면보다 규칙이 본체다.

제약 넷

법정 의무가 여럿이고 위반 시 발송·수집 자체가 불법이 된다. 동의 없는 마케팅, 수신거부 미처리, 미성년자 동의 누락, 정보주체 권리 미대응이 모두 제재 대상이다.
삭제와 보존이 충돌한다. 결제·세금 기록은 법정 보존 의무가 있어 삭제 요청이 와도 전부 지울 수 없다. 어디까지 지우고 무엇을 남길지를 정하지 않으면 요청이 올 때마다 즉흥 판단하게 된다.
권한은 조직이 아니라 데이터 민감도로 갈린다. 디자이너에게 가려야 할 것은 타인의 정산·성과이고, 본사에 가려야 할 것은 고객 개인정보다. 역할 계층만으로는 안 되고 필드 단위가 필요하다.
동의는 상태가 아니라 이력이다. 언제 어떤 경로로 받았고 언제 철회됐는지가 남아야 분쟁에서 쓸 수 있다.

0-2. 군집

군집	기능	주 화면
J-1 동의	3	SC-C02 동의 서명 · SC-M11 동의 탭
J-2 접근 통제	4	SC-H07 권한 · 전 화면 규칙
J-3 정보주체 권리	3	SC-H08 감사·개인정보 관리
J-4 추적·파기	3	SC-H08 · SC-H09

군집

기능

주 화면

J-1 동의

SC-C02 동의 서명 · SC-M11 동의 탭

J-2 접근 통제

SC-H07 권한 · 전 화면 규칙

J-3 정보주체 권리

SC-H08 감사·개인정보 관리

J-4 추적·파기

SC-H08 · SC-H09

16-J. 프라이버시·권한 — RIAHN CONNECT 기능 상세

J-1. 동의 — 3개

RC-J-01동의 관리1차

R2SC-M11 SC-C02

목적: 무엇을 해도 되는지의 원장. 이 시스템의 여러 기능이 여기에 걸려 있다
트리거: 신규 등록(B-03), 동의 갱신, 철회
입력: 동의 항목 · 동의 경로 · 일시 · 서명(J-02)
규칙: 항목별로 관리한다 — 수집·마케팅·사진·재학습 옵트아웃. 각 항목이 무엇을 잠그는지 명확하다. 수집 미동의면 등록 자체가 불가, 마케팅 미동의면 캠페인 제외(E-07), 사진 미동의면 열람 차단(B-06), 재학습 옵트아웃이면 학습셋 제외(J-12). 상태가 아니라 이력으로 남긴다 — 언제 어떤 경로로 받았는지
결과: 동의 원장, 다른 기능의 게이트
예외: 이관 고객은 동의 이력이 없다. "미동의"로 처리해 보수적으로 막고 재동의 대상으로 분류한다
미결: 외부 CRM 이관 시 동의 이력이 함께 오는지 — 없으면 이관 직후 마케팅 발송이 전면 불가

RC-J-02동의서 서명1차

R6 고객SC-C02 (D4 거울앞 태블릿)

목적: 동의의 증거를 남긴다
트리거: 신규 등록, 동의 항목 추가
입력: 동의 항목 · 서명 · 스캔 문서
규칙: 태블릿 서명을 기본으로 하고 종이 스캔 보관도 허용한다. 거울앞 태블릿이므로 다른 고객 정보가 보이면 안 된다. 항목별로 선택 동의가 가능해야 한다 — 전부 아니면 전무는 위법 소지가 있다. 필수와 선택을 구분해 표시한다
결과: 서명 저장, 동의 원장(J-01) 갱신
예외: 만 14세 미만은 J-09로 분기한다

RC-J-09미성년자 법정대리인 동의1차

R2SC-C02

목적: 만 14세 미만 고객의 동의를 법정대리인에게 받는다. 법정 의무
트리거: 생년월일 입력 시 만 14세 미만 판정
입력: 고객 생년월일 · 법정대리인 정보 · 대리인 동의
규칙: 만 14세 미만이면 일반 동의 절차를 막고 대리인 동의로 분기한다. 대리인 확인 기록을 남긴다. 대리인 정보 자체도 개인정보이므로 최소 수집한다
결과: 대리인 동의 기록, 동의 원장 갱신
예외: 생년월일을 받지 않으면 판정 자체가 불가능하다. 미용실에서 연령대만 받는 관행과 충돌하므로 수집 항목 결정이 선행되어야 한다

J-2. 접근 통제 — 4개

RC-J-04권한(Role) 설정1차

R5/R1SC-H07

목적: 역할별로 무엇을 보고 무엇을 할 수 있는지 정한다
트리거: 역할 체계 설계, 계정 부여(K-07·M-08)
입력: 역할 정의(R1~R5) · 메뉴 접근 · 필드 접근 · 액션 권한
규칙: 메뉴·필드·액션 세 층으로 통제한다. 승인 권한(환불 C-05, 휴무 F-01, 발송 E-05)이 여기서 나온다. 부재 시 위임은 J-13이 처리한다. 역할 체계는 본사가 정의하고 매장은 부여만 한다
결과: 권한 매트릭스, 화면·기능 접근 제어
예외: 권한 변경은 즉시 반영되어야 한다. 세션에 캐시된 권한으로 계속 접근하면 안 된다

RC-J-08필드 단위 마스킹1차

자동전 화면SC-D03

목적: 같은 화면에서도 민감 필드를 역할별로 가린다
트리거: 화면 렌더링 시 자동
입력: 역할(J-04) · 필드 민감도 정의
규칙: 역할 계층만으로는 부족한 지점을 메운다. 디자이너에게는 타인의 정산·성과를 가리고(F-08, D-02), 본사에는 고객 개인정보를 가린다. 마스킹은 표시만이 아니라 조회 자체를 막아야 한다 — 화면에서 가리고 API로는 나가면 의미가 없다
결과: 필드별 표시·조회 제어
예외: 마스킹된 값으로도 검색은 되어야 한다(B-01 전화 뒷자리)

RC-J-03PII 마스킹 표시1차

자동전역 컴포넌트

목적: 개인정보가 가려져 있다는 것과 왜 가려졌는지를 보여준다
트리거: 마스킹된 필드 표시 시
입력: 마스킹 규칙(J-08) · 현재 역할
규칙: 전화번호·주소는 기본 마스킹이고 열람하려면 사유를 남긴다(J-05). 마스킹 상태를 시각으로 구분해 사용자가 "데이터가 없는 것"으로 오해하지 않게 한다. 거울앞 태블릿(D4)은 마스킹 수준이 가장 높다
결과: 마스킹 표시, 열람 시 사유 로그
예외: 열람 사유 입력이 잦으면 형식화된다. 업무상 상시 필요한 필드는 마스킹 대상에서 빼는 편이 낫다

독립 화면이 아니라 모든 화면에 얹히는 공통 요소다 (15번 문서 4장 9번)

RC-J-13권한 위임·대리 승인1차

R1SC-H07 SC-M43

목적: 점주가 없어도 승인이 돌아가게 한다. SC-M43 승인 대기함의 전제
트리거: 휴가·병가 등 부재 예정
입력: 위임 대상자 · 위임 기간 · 위임 범위(승인 항목)
규칙: 기간을 지정한 위임이며 기간이 끝나면 자동 해제된다. 위임 범위를 항목별로 정한다 — 환불 승인은 위임하되 요율 변경은 안 되게. 위임 이력을 감사 로그(J-05)에 남긴다. 위임받은 사람이 한 승인은 원 권한자 이름이 아니라 실제 승인자로 기록한다
결과: 위임 활성화, 승인 권한 이전
예외: 위임 없이 부재하면 환불·휴무·발송 승인이 전부 막힌다. 부재가 감지되면 위임을 유도하는 편이 낫다

J-3. 정보주체 권리 — 3개

RC-J-10열람·정정 요청1차

R2 접수 / R5 처리SC-H08 SC-M11

목적: 고객의 열람·정정·삭제·처리정지 요청에 대응한다. 법정 의무
트리거: 고객 요청 접수
입력: 요청 유형 · 본인 확인 · 대상 데이터 · 법정 보존 의무 목록
규칙: 본인 확인이 선행된다 — 확인 없이 처리하면 그 자체가 유출이다. 처리 기한을 관리하고 회신 기록을 남긴다. 삭제 요청은 법정 보존 의무 데이터(결제·세금)와 충돌하므로 부분 삭제 규칙이 필요하다 — 어디까지 지우고 무엇을 남기는지. 재학습 옵트아웃 반영은 J-12로 이어진다
결과: 요청 처리, 회신 기록, 처리 기한 준수
예외: 삭제 후에도 결제 이력이 남아 있으면 고객이 "안 지웠다"고 볼 수 있다. 무엇을 왜 남기는지 회신에 명시한다
미결: 접수 창구 (고객 앱 Look.K vs 매장 접수) 및 법정 보존 데이터의 부분 삭제 기준

RC-J-14삭제·처리정지 요청1차

R2 접수 / R5 처리SC-H08

목적: 지워달라는 요청에 대응한다. 법정 보존 의무와 정면으로 충돌하는 지점
트리거: 고객의 삭제·처리정지 요청
입력: 본인 확인 · 대상 데이터 · 법정 보존 의무 목록 · 처리 기한
규칙: 결제·세금 기록은 보존 의무가 있어 전부 지울 수 없다. 어디까지 지우고 무엇을 남기는지 부분 삭제 규칙을 미리 정해 두지 않으면 요청마다 즉흥 판단하게 된다. 처리정지는 삭제가 아니라 이용 중단이므로 데이터는 남기고 활용만 막는다. 재학습 옵트아웃 반영은 J-12로 이어진다
결과: 부분 삭제 또는 처리정지, 회신 기록
예외: 삭제 후에도 결제 이력이 남으면 고객이 "안 지웠다"고 본다. 무엇을 왜 남기는지 회신에 명시한다
미결: 법정 보존 데이터의 부분 삭제 기준

RC-J-11데이터 반출 통제1차

자동 → R1 승인SC-H08

목적: 개인정보가 파일로 새어 나가는 것을 통제한다. 유출의 주 경로
트리거: 리포트 내보내기(D-13), 세그먼트 전달(B-18)
입력: 반출 대상 데이터 · 요청자 역할 · 사유
규칙: 반출 시 마스킹을 적용하고 사유를 입력받는다. 고객 단위 데이터의 대량 반출은 승인을 탄다. 모든 반출은 감사 로그(J-05)에 남는다. 파일에 반출 일시·요청자를 박아 추적 가능하게 한다
결과: 반출 실행, 반출 로그
예외: 업무상 반출이 잦으면 승인이 형식화된다. 임계 건수를 정해 그 이하는 로그만 남긴다

RC-J-15위탁·제3자 제공 현황1차

R5SC-H08

목적: 데이터를 누구에게 맡기고 있는지 관리한다. 개인정보 처리방침 명시 항목
트리거: 수탁 계약 체결·변경, 처리방침 갱신
입력: 수탁사 · 위탁 업무 · 제공 항목 · 목적 · 보유 기간
규칙: 파수·랩큐 등 컨소시엄 참여사가 데이터를 다루므로 위탁 현황을 관리하고 처리방침에 반영한다. 제3자 제공(동의 필요)과 위탁(고지 필요)은 법적 요건이 다르므로 구분한다. 계약 종료 시 파기 확인까지 추적한다
결과: 위탁 현황, 처리방침 반영 근거
예외: 수탁사가 재위탁하면 그것도 관리 대상이다

RC-J-16동의 재수집1차

R2SC-M11 SC-M24

목적: 이관 고객의 없는 동의를 다시 받는다. 이게 끝나야 마케팅이 돌아간다
트리거: 이관 완료 후, 동의 이력 부재 확인
입력: 동의 이력 없는 고객 목록(J-01) · 재동의 경로
규칙: 재동의 완료 전까지 광고성 발송을 차단한다(E-07). 재동의는 방문 시 태블릿 서명(J-02)이 가장 확실하고, 정보성 알림에 동의 링크를 얹는 방식도 병행한다 — 다만 동의를 구하는 메시지 자체가 광고성이 되지 않게 문구를 관리한다(K-06)
결과: 동의 원장 갱신, 발송 가능 대상 확대
예외: 재동의율이 낮으면 마케팅 모수가 크게 줄어 사업 논리가 흔들린다. 진척을 지표로 관리한다

RC-J-12학습 데이터 제외 반영2차

R5SC-H09

목적: 옵트아웃과 삭제 요청이 실제 학습셋에 반영됐는지 확인한다
규칙: 재학습 옵트아웃(J-01)·삭제 요청(J-10) 건이 학습 데이터에서 빠졌는지 대조한다. 동의 항목만 있고 반영 확인 수단이 없으면 옵트아웃은 선언에 그친다

J-4. 추적·파기 — 3개

RC-J-05감사 로그1차

R5SC-H08

목적: 누가 무엇을 봤고 무엇을 했는지 남긴다
트리거: 감사 대상 행위 발생 시 자동
입력: 행위자 · 대상 · 시각 · 사유
규칙: 남기는 대상이 넷이다. ①고객카드 열람 기록 ②데이터 반출 기록(J-11) ③승인·위임(J-13) ④확정 이후 수정(C-24·C-26). 로그 자체는 수정·삭제가 불가능해야 한다. 조회는 R5만
결과: 감사 로그
예외: 로그가 폭증하면 조회가 안 된다. 유형별 보관기간을 달리 둔다

RC-J-06보관기간·파기2차

R5SC-H08

목적: 보관 기간이 지난 것을 지운다
규칙: 항목별 보관기간을 정하고 만료분을 자동 파기한다. 대상이 셋이다 — 고객, 임직원(F-15 퇴사자), 백업본(L-08). 백업에만 남아 있으면 파기한 것이 아니다

RC-J-07human review 분리2차

R5SC-H09

목적: AI가 처리한 것과 사람이 검토해야 할 것을 가른다
규칙: 자동 처리 대상과 사람 검토 대상을 분리해 표시한다. 자동화된 의사결정에 대한 설명 요구와 맞물린다

미창조㈜ · AX 사업추진 TF

16-K. 매장 마스터·설정 기능 상세 — 19개

15번 목록의 K 도메인을 와이어프레임 작성자가 화면에 무엇을 놓을지 판단할 수 있는 수준까지 폈다. 기능 하나를 여섯 줄(목적·트리거·입력·규칙·결과·예외)로 정의한다.

19개1차192차0미결 52차 미작성 0

상위: 15. RIAHN CONNECT 기능 목록 · 화면 목록 — K 도메인
필드 정의와 표기(⚑ 분리 검토 · ▷ 2차 상세 미작성)는 16-C 0-1과 같다
작성: 이원섭 PM · 2026-08-11

0. 여기 있는 값이 다른 도메인의 동작을 정한다

다른 도메인에서 K를 가리킨 횟수가 27회다. 이 도메인은 기능이라기보다 나머지 전부의 입력값 저장소에 가깝다. 그래서 성격이 다르다 — 화면은 대부분 폼이고, 규칙은 "무엇을 저장하는가"보다 "언제부터 적용되는가" 가 중요하다.

제약 넷

설정 화면이 1차 세트의 병목이다. SC-M32에 K-01~17이 모두 모이고, 여기 값이 없으면 회원권 판매는 정책 없이(K-14), 캠페인은 발송 자격 없이(K-13), 대시보드는 하드코딩된 숫자로(K-12) 돌아간다. 그래서 SC-M32를 1차년도 핵심 세트의 선행 조건으로 둔다.
과거 거래를 소급 재계산하지 않는다. 가격·요율·정책이 바뀌면 적용 기준일을 갖는다(K-16). 이게 없으면 지난달 결제 금액이 오늘 바뀐다.
본사 표준과 매장 재량의 경계가 명시돼야 한다. 무엇을 매장이 바꿀 수 있고 무엇이 잠기는지가 항목마다 다르다. 표준 배포(M-06)가 매장 값을 덮어쓸지도 항목별로 갈린다.
일부 항목은 미등록 시 기능이 아예 막힌다. 발신번호(K-13)가 없으면 발송이 불가하고, PG 설정(K-15)이 없으면 링크결제가 불가하다. 설정 누락을 경고가 아니라 차단으로 다룬다.

0-2. 군집

군집	기능	성격
K-1 매장 실체	3	물리적 자원 — 영업시간·좌석·장비
K-2 상품·가격	4	돈에 직결. 변경 시 기준일 필수
K-3 운영 정책	4	자동화가 참조하는 임계값·규정
K-4 연동 자격	4	미등록 시 해당 기능 차단
K-5 계정·이력	2	권한과 변경 추적

군집

기능

성격

K-1 매장 실체

물리적 자원 — 영업시간·좌석·장비

K-2 상품·가격

돈에 직결. 변경 시 기준일 필수

K-3 운영 정책

자동화가 참조하는 임계값·규정

K-4 연동 자격

미등록 시 해당 기능 차단

K-5 계정·이력

권한과 변경 추적

16-K. 매장 마스터·설정 — RIAHN CONNECT 기능 상세

K-1. 매장 실체 — 3개

RC-K-01매장 정보·영업시간1차

목적: 매장의 기본 정보와 언제 문을 여는지 정한다. 예약 가능 시간의 바깥 테두리
트리거: 개점 시 1회, 영업시간 변경 시
입력: 매장 기본 정보 · 요일별 영업시간 · 휴무일 · 특별 영업시간
규칙: 영업시간이 예약 캘린더(A-01)의 표시 범위와 가용 슬롯을 정한다. 휴무일은 사전 계획용이며 갑작스러운 휴업은 A-19가 다룬다. 특별 영업시간(명절·연장)은 기간 지정으로 덮어쓴다. 매장 마스터(M-17)의 하위 정보이며 본사가 관리하는 항목과 매장이 관리하는 항목이 갈린다
결과: 영업시간 확정, 캘린더·예약 가능 범위 갱신
예외: 영업시간을 줄이면 그 시간대의 기존 예약과 충돌한다. 충돌 건을 보여주고 처리하게 한다

RC-K-02좌석·장비 마스터1차

목적: 점유 가능한 물리 자원을 정의한다. 충돌 방지(A-05)의 3중 검증 중 둘
트리거: 개점, 좌석·장비 증감
입력: 좌석 수·번호 · 펌·컬러 장비 대수 · 장비별 사용 시술
규칙: 좌석과 장비를 각각 개체로 관리한다. 장비는 시술과 연결되어야 한다 — 어떤 시술이 어떤 장비를 쓰는지 모르면 점유 검증이 안 된다(A-05). 좌석·장비 레인 뷰(SC-M05)의 축이 여기서 나온다
결과: 자원 마스터 확정, 충돌 검증 기준
예외: 장비 고장 시 일시 사용 불가로 표시해야 배치에서 빠진다. 장기 고장은 A-19 임시 휴업으로 갈 수 있다

RC-K-10POS 주변기기 설정1차

R2SC-M32

목적: POS에 물린 기기를 연결한다
트리거: 기기 설치·교체
입력: 영수증 프린터 · 바코드 스캐너 · 고객 표시기 · 카드 단말
규칙: 기기별 연결 상태를 표시한다. 결제·PG 설정(K-15)과는 별개다 — 이건 물리 기기, 저건 결제 계약이다. 프린터 미연결이면 영수증(C-07)이 전자 발행으로 대체된다
결과: 기기 연결, 상태 표시
예외: 연결 실패 시 어떤 기능이 제한되는지 명시한다

K-2. 상품·가격 — 4개

RC-K-03메뉴·소요시간·버퍼1차

목적: 무엇을 얼마에 얼마 동안 하는지 정한다. 예약과 결제 양쪽의 기준
트리거: 메뉴 개편, 가격 조정, 신규 시술 추가
입력: 시술 메뉴 · 디자이너 직급별 가격 · 표준 소요시간 · 정리 버퍼
규칙: 하나의 메뉴가 직급별로 다른 가격을 갖는다(F-02 직급). 표준 소요시간은 A-06의 기준값이 되고 실측으로 보정된다. 본사 표준 메뉴가 배포되면(M-06) 매장 추가 메뉴와 병합되는데, 덮어쓸지 병합할지 규칙이 필요하다. 가격 변경은 K-16 기준일을 갖는다
결과: 메뉴 마스터 확정, 예약·결제·매출 분석의 기준
예외: 사용 중인 메뉴를 지우면 과거 이력이 깨진다. 삭제가 아니라 비활성으로 처리한다

RC-K-04가격·할인 상한1차

본사/R1SC-M32

목적: 매장이 임의로 가격을 흔들지 못하게 한다
트리거: 본사 정책 수립, 매장 조정 시도
입력: 본사 표준가 · 매장 조정 허용 범위 · 할인 하한
규칙: 본사 표준 대비 매장이 조정할 수 있는 범위를 정한다. 할인은 이 하한 아래로 내려갈 수 없고, 초과 시 승인(SC-M43)을 태우거나 차단한다(C-06). ⚠️ 가맹사업법 확인 대상 — 가맹본부가 가맹점의 판매가격을 강제하면 문제가 될 수 있다
결과: 조정 범위 확정, C-06 할인 검증 기준
예외: 상한 초과를 승인으로 풀지 차단할지가 미정
미결: 가맹사업법상 가격 구속 범위 — 법무 확인 필요

RC-K-14회원권·포인트 상품 정책1차

본사/R1SC-M32

목적: 선불 상품의 규칙 숫자를 넣는다. C-04·17·18과 B-21의 계산식 입력값
트리거: 상품 설계, 약관 확정, 정책 변경
입력: 권종(횟수/금액/기간) · 유효기간 · 환불율 · 사용가능범위 · 포인트 적립률·소멸기간·사용 단위·상한
규칙: 회원권과 포인트를 한 곳에서 관리한다. 사용가능범위는 기본값 매장전용이며 브랜드공용 전환은 규제 검토 통과 후 스위치를 켠다(C-04). 환불율은 C-18 계산식의 입력이고, 소멸기간은 B-21 소멸 처리의 기준이다. 변경은 K-16 기준일을 갖는다 — 이미 발급된 회원권에 소급 적용하면 안 된다
결과: 정책 확정, 선불 상품 도메인 전체의 기준
예외: 정책 없이 회원권을 팔면 나중에 환불 계산이 불가능하다. 미설정 시 C-04 판매를 막는다
미결: 유효기간·환불율 파라미터 — 미창조 약관 확정 필요

RC-K-11수수료·인센티브 요율1차

본사/R1SC-M32 SC-D16

목적: 디자이너 정산의 계산 근거를 넣는다. F-08의 입력값
트리거: 요율 정책 수립·변경, 승급
입력: 직급별 요율 · 시술군별 요율 · 인센티브 구간
규칙: 직급과 시술군의 교차로 요율이 정해진다. 인센티브는 구간별 누진 구조를 허용한다. ⚠️ 열람 권한 분리 필수 — 점주와 본사만 보고 디자이너는 본인 적용분만(SC-D16). 변경은 K-16 기준일을 갖는다. 월마감(C-26) 이후 지급된 기간의 요율은 바꿔도 소급되지 않는다
결과: 요율 테이블 확정, F-08 정산 기초자료의 계산 근거
예외: 요율은 급여와 직결되므로 변경 이력이 반드시 남아야 한다
미결: 요율 데이터를 CONNECT가 보유할지 (노무 민감 항목)

K-3. 운영 정책 — 4개

RC-K-05예약 규정1차

목적: 예약의 시간·금전 규칙을 정한다
트리거: 정책 수립·변경
입력: 취소·노쇼 정책 · 예약금 비율 · 최소 예약 리드타임 · 당일예약 마감 · 최대 선예약 기간 · 예약금 미입금 자동취소 시간
규칙: 여섯 값이 예약 도메인 전반을 통제한다. 리드타임은 A-02 등록 가능 범위를, 미입금 자동취소 시간은 A-08 결제대기 홀드의 만료를 정한다. 취소·노쇼 시 예약금 몰수/환불 분기(A-04)도 여기서 온다
결과: 예약 규정 확정
예외: 정책을 강화하면 기존 예약에 소급될 수 있다. 신규 예약부터 적용이 기본

RC-K-12자동화 규칙·임계값1차

본사/R1SC-M32

목적: 여기저기 흩어질 뻔한 숫자를 한 곳에 모은다. 없으면 전부 하드코딩된다
트리거: 정책 수립, 운영 중 조정
입력: 휴면 기준 일수(B-11) · 리마인더 시점(A-13) · 재진단 주기(B-20) · 야간차단 시간(E-06) · 이상 변동 기준(D-09) · 더미 탐지 기준(D-14) · 발송 상한(E-16) · 재방문율 기준 기간(D-06)
규칙: 본사 표준값을 두고 매장 조정 범위를 정한다. 변경 시 적용 시점과 이미 예약 대기 중인 건의 처리를 명시한다 — 리마인더 시점을 바꾸면 이미 큐에 든 발송은 어떻게 되는지. 값 변경이 세그먼트를 소급 재분류하므로 진행 중 캠페인은 스냅샷을 쓴다(B-11)
결과: 파라미터 확정, 자동화 기능 전반에 반영
예외: 임계값을 바꾸면 알림 양이 급변한다. 변경 전 영향 미리보기(대상 인원 수)를 보여주는 편이 안전하다

RC-K-17알림·승인 라우팅 규칙1차

R1/본사SC-M32 SC-M43

목적: 어떤 이벤트가 누구에게 가는지 정한다. K-12가 언제를 정하고 여기가 누구를 정한다
트리거: 라우팅 설계, 역할 변경
입력: 이벤트 목록 · 역할(J-04) · 미처리 시 상위 통보 규칙
규칙: 이벤트별로 수신 역할을 지정한다 — 미기록 리마인더(G-07)는 담당 디자이너, 이상 변동(D-09)은 점주, 이관 차이(C-21)는 점주+본사. 미처리 상태가 일정 시간 지속되면 상위로 통보한다. 개인이 끄는 설정(N-07)은 이 라우팅 위에 얹히되 필수 알림은 끌 수 없게 한다
결과: 라우팅 규칙 확정, 알림센터(N-02)·승인 대기함(SC-M43)의 분배 기준
예외: 라우팅이 없으면 전원에게 가거나 아무에게도 안 간다. 미지정 이벤트의 기본 수신자를 반드시 둔다

RC-K-08타임딜 조건 설정1차

R1SC-M32 SC-M29 (경계 — E-01)SC-M43

목적: 매장별 타임딜 할인 조건을 정한다
트리거: 타임딜 운영 시작, 조건 조정
입력: 대상 시간대(D-05 공백 구간) · 할인율 · 대상 시술 · 전용 슬롯(A-18)
규칙: 공백 시간대를 타깃으로 조건을 건다. 할인율은 K-04 하한을 넘지 못한다. 타임딜 전용 슬롯은 A-18 채널 배분에서 별도로 잡힌다. 스펙 소유는 SFR-E이며 여기서는 조건 입력과 데이터 계약만 정의한다
결과: 타임딜 조건 확정, 승인함(SC-M29)으로 제안 전달
예외: 정가 고객과 타임딜 고객이 같은 시술을 받으면 형평성 문제가 생긴다. 노출 범위를 제한할지 정책 필요

K-4. 연동 자격 — 4개

RC-K-13발신번호 사전등록1차

본사/R1SC-M32

목적: 메시지를 보낼 자격을 갖춘다. 미등록이면 발송 자체가 불가능하다
트리거: 서비스 개시 전 1회, 번호 변경 시
입력: 문자 발신번호 · 카카오 발신프로필 · 080 수신거부 번호 · 증빙 서류
규칙: 셋을 등록·관리한다. ①문자 발신번호 사전등록(전기통신사업법 의무) ②카카오 발신프로필 ③080 수신거부 번호(E-15의 유입 창구). 등록 상태를 표시하고 미등록·만료 시 E-05·E-14·E-15를 막는다 — 경고가 아니라 차단이다
결과: 발신 자격 확보, 발송 기능 활성화
예외: 490개 매장이 각자 등록하면 행정 부담이 크고, 본사 대표번호로 통합하면 고객 회신이 본사로 몰린다
미결: 발신번호 등록 주체 (매장별 vs 본사 통합)

RC-K-18카카오 발신 자격1차

본사/R1SC-M32

목적: 알림톡을 보낼 자격을 갖춘다
트리거: 발신프로필 등록, 템플릿 심사 신청·결과 수신
입력: 발신프로필 · 템플릿(K-06) · 심사 상태
규칙: 사전 승인된 템플릿만 발송 가능하므로 심사 상태를 표시하고 미승인 템플릿으로는 발송을 막는다. 심사에 시일이 걸리므로 신규 문구는 미리 신청한다. K-13(문자 발신번호)과 근거 법령·심사 주체가 다르다
결과: 알림톡 발송 자격, 템플릿별 승인 상태
예외: 심사 반려 시 사유를 보고 문구를 고쳐 재신청한다

RC-K-15결제·PG 설정1차

목적: 결제를 받을 계약 정보를 넣는다
트리거: PG·VAN 계약, 링크결제 도입
입력: PG·VAN 가맹점 정보 · 수수료율 · 링크결제 사용 여부 · 결제 웹훅 수신 설정
규칙: 수수료율이 정산 리포트(C-09)의 입금 예정액 계산에 쓰인다. 링크결제(C-22)를 켜야 비대면 결제가 가능하다. 웹훅 수신 설정이 없으면 입금 확인이 수동이 된다. K-10(주변기기)과 별개
결과: 결제 계약 확정, C-03 사용 가능 수단 결정
예외: 미설정 시 해당 결제수단을 화면에서 감춘다

RC-K-09외부 채널 계정1차

목적: 채널 연동의 인증 정보를 넣는다
트리거: 채널 연동 개시, 토큰 만료(I-13)
입력: 채널별 계정·인증 정보
규칙: 채널을 데이터로 관리한다 — 네이버가 열리지 않아 헤어짱 어댑터로 대체돼도 화면 구조는 같다(I-01 플러그인). 인증 만료는 I-13이 감지해 재인증을 유도한다. 인증 정보는 마스킹 저장
결과: 채널 연동 활성화
예외: 인증 만료 시 해당 채널의 예약 유입이 끊긴다. 연동 중단 배너를 띄운다

RC-K-06알림 템플릿1차

본사/R1SC-M32

목적: 보낼 문구를 관리하고 유형을 판정한다
트리거: 템플릿 작성, 카카오 심사 신청·결과 수신
입력: 문구 · 변수 · 유형 분류(정보성/광고성) · 카카오 심사 상태
규칙: 유형 분류가 이 기능의 핵심이다 — 정보성이면 야간 차단(E-06)과 발송 상한(E-16)의 예외가 되고, 광고성이면 (광고) 표기와 수신거부 안내가 강제된다(E-07). 알림톡은 사전 승인된 템플릿만 발송 가능하므로 심사 상태를 표시하고 미승인 템플릿으로는 발송을 막는다
결과: 템플릿 확정, 유형 판정 기준, 심사 상태
예외: 유형을 잘못 분류하면 위법이 된다. 광고성인데 정보성으로 표시하는 것을 막는 검증이 필요하다

K-5. 계정·이력 — 2개

RC-K-07사용자 계정 관리1차