8/7 미팅 노트네이버클라우드 정홍석 매니저(네이버 예약 초창기 멤버) 확인 사항 — 네이버 예약 API 개방은 ①기본 검토 요건 매장 1만 개 이상, ②"얘기라도 되는" 선 5,000개 이상, ③500~1,000개는 명시적 거절선. 리안헤어는 490개다. 분기별 1개 업종씩 개방하며 신청 업체를 정량 가중치로 줄 세워 순위표를 내부 공개한다("얘네를 했을 때 우리한테 얼마나 예약이 더 증가할 것인가"). 현재 확보된 것은 헤어짱·핸드SOS API 공유 협의이고, 유일한 현실적 우회로는 네이버페이 결제 집중 → 파이낸셜 조직 경유 개방 요청이다.

설계 반영: 채널 어댑터를 플러그인 구조로 설계해 네이버가 열리지 않아도 헤어짱·핸드SOS 어댑터로 대체 가능하게 한다. 화면상 채널은 데이터로 관리하고 하드코딩하지 않는다. 이 한 가지 원칙만 지키면 전제가 바뀌어도 화면은 그대로 쓴다.

모바일 퍼스트. D1·D5는 웹이므로 데스크톱·모바일 양쪽을 다 그린다. CSS의 base가 모바일이고 데스크톱을 얹는다.
매니저 PC 화면이 복잡해 모바일에 다 들어가지 않으면 꼭 봐야 할 것만 담되, 뺀 기능을 화면에 명시한다 — 2차년도 화면을 지우지 않고 2차로 표기해 두는 것과 같은 이유다.
D2·D4는 고정 설치 단말이라 단일 뷰포트다. 화면 84개 → 뷰포트 148컷(D1 74 · D1/D2 12 · D2 4 · D3 16 · D4 4 · D5 38).

기능 하나의 단위 — 트리거·규칙·결과가 모두 다르면 나눈다. 셋이 같으면 한 카드다.
의존이 많은 것(C-01 결제 화면)은 오케스트레이션이고, 예외가 많은 것(C-23 분할 결제)은 실패 경로라 나누지 않는다.

나누는 이유는 화면 설계 때문이다. 트리거가 다르면 진입점이 다르고, 결과가 다르면 확인 화면이 다르다 —
한 카드에 묶어 두면 화면에서 같은 버튼이 두 가지 일을 하게 된다.

정책 결정회원권·정기권·선불권을 1차 구현 범위로 확정한다. 미창조의 사업 목표가 헤어짱·핸드SOS 대체이고, 회원권은 미용실 매출의 상당 부분을 차지하는 선수금 상품이라 이것 없이는 외부 CRM을 끊을 수 없다. 다만 이 결정에는 네 가지가 따라온다.

① 규제 분기점은 "누가 발행하고 어디서 쓰는가"다. 전자금융거래법상 선불전자지급수단은 "발행인 외의 제3자로부터 재화·용역을 구입하는 데 사용되는 것"을 요건으로 한다. 매장이 발행하고 그 매장에서만 쓰면 자가발행 성격이라 규제 강도가 낮지만, 본사가 발행해 490개 가맹점(각각 별개 사업자)에서 쓰게 하면 제3자 사용이 되어 선불업 등록·선불충전금 별도관리(신탁·예치·보증보험) 의무 검토 대상이 된다. 등록 면제에는 발행잔액·연간 총발행액 기준이 있으나 최근 개정으로 강화되었으므로 정확한 적용 여부는 법무 확인 필요.
→ 설계 반영: 회원권 데이터 모델에 사용가능범위(매장전용 / 브랜드공용) 필드를 1차부터 넣되 기본값은 매장전용으로 한다. 나중에 붙이면 발행된 회원권 전체를 마이그레이션해야 한다. 브랜드공용 전환은 규제 검토 통과 후 스위치만 켜는 구조로 만든다. (RC-C-14와 직결)

② 이관 잔액 오차 = 즉시 클레임. 예약·시술 데이터는 틀려도 나중에 고치면 되지만 회원권 잔액은 틀리는 순간 고객이 현장에서 항의한다. 외부 CRM 이관 항목 중 가장 위험도가 높다. → RC-C-21을 최우선으로 두고, 이관 후 건별 대조 + 차이 건 승인 절차를 반드시 화면으로 만든다. 자동 반영 금지. 포인트·적립금(RC-B-21)도 같은 성격의 잔액이므로 이관 원장 확보·대조 대상에 함께 넣는다.

③ 네트워크 단절 중 차감은 이중 차감을 부른다. 잔액 차감은 로컬 서버 락으로 직렬화하고, 단절 상태에서는 차감 대신 "보류 처리" 후 재연결 시 확정하는 구조로 한다. 포인트(RC-B-21)도 동일 규칙을 적용한다. 계획서의 "인터넷 단절 시에도 동작"을 잔액 차감까지로 읽으면 안 된다. (도메인 L과 연결)

④ 미사용 잔액은 회계·소비자 이슈를 동시에 만든다. 미상환잔액은 재무제표상 선수금이고, 유효기간 경과 잔액의 환불 기준은 소비자 분쟁이 잦은 영역이다. RC-C-18(환불 계산)은 "사용분을 정가로 환산한 뒤 잔액 환불"이 실무 표준이므로 계산식을 화면에 노출해 분쟁을 줄인다. 구체적 환불율·유효기간 정책은 미창조 약관 확정 후 파라미터로 주입한다.

8/7 미팅 노트RC-C-12의 근거 파수 발언: CRM의 결제 데이터와 시술 데이터가 일치하지 않아 "아웃풋에 결정적인 타격"이 될 수 있다 [21:30]. 결제는 남지만 무슨 시술을 했는지 기록이 없거나 어긋나는 건이 상당수라는 뜻이다. 신뢰도 플래그·기간별 가중 보정 규칙 정의가 랩큐 액션(24번)으로 잡혀 있다. 정합 보정은 데이터 품질의 출발점이므로 화면으로 반드시 만들어야 한다.

8/7 미팅 노트알림톡이 전략의 핵심 본부장: "저희는 이거를 카카오로 좀 돌리면… 어차피 문자는 열지도 않고 비용도 높은데 핸드[SOS]는 개발을 안 해요. 지금도 카카오로 전환할 생각이 없어요" [11:32]. 미용실당 문자 수수료가 월 약 5만 원이고, 이 시장을 알림톡으로 직접 겨냥하는 것이 CRM 진입 전략의 차별화 지점이다. RC-E-05·E-10은 단순 기능이 아니라 사업 모델의 접점이므로 와이어프레임에서 비중 있게 다룬다. 단, 알림톡은 카카오 발신프로필 등록과 템플릿 사전 승인이 필요하므로 템플릿 심사 상태 관리 화면이 함께 필요하다(RC-K-06). 또한 알림톡은 카톡 미가입·차단 시 발송이 실패하므로 SMS 대체발송과 건별 결과 추적(RC-E-14)이 없으면 "보냈다고 믿었는데 안 간" 건이 그대로 쌓인다. 비용 절감 효과도 대체발송률을 재야 검증된다.

8/7 미팅 노트왜 이 도메인을 신설했나 본부장: "쓰는 매장이 있고, 안 쓰는 매장이 있고 그런 차이가 좀 있습니다… 메모를 쓰는 매장이 많지는 않고… 여기에 이제 그동안 시술 이력을 다 남겨 놓더라고요… 하다 못해 '진상이다' 뭐 이런 메모도 다 남겨 놓습니다. 워낙 이 핸드[SOS]에 데이터 만들어 놓은 건 많은데 사실 다 쓰는 게 아니거든요" [00:00~01:18].

즉 기존 CRM은 기록 필드가 있어도 안 쓰인다. 데이터가 없는 게 아니라 입력이 안 되는 것이 문제다. RIAHN CONNECT가 헤어짱·핸드SOS를 대체해도 입력 UX가 같으면 결과도 같다. 따라서 시술 기록은 부가 기능이 아니라 핵심 화면이며, 와이어프레임의 성패가 RC-G-02(빠른 입력)에 달려 있다. 별도 액션(26번 "메모 작성 우수 매장 식별 — 표본 편향 방지")도 이 문제를 가리킨다.

8/7 미팅 노트연동의 현재 상태 본부장: "저희가 본사가 CRM사한테는 그래도 힘이 있을 거잖아요. 데이터를 API 공유 받는 것까지는 협의를 해 놨어요" [02:23]. 미창조 플랫폼의 예약이 기존 헤어짱·핸드SOS 예약판에 그대로 들어가게 할 수 있다는 것이 현재 확보된 경로다. 매장별 CRM 계정을 파수·랩큐에 개방해 필요한 항목을 직접 보고 지목하게 하는 방식으로 진행 중이다(액션 3·16·17번).

다만 RC-I-11(양방향 동기화)은 외부 CRM이 쓰기(write) API를 제공해야 성립하는데, 그 가능성은 낮다. 계획서의 이관 전제도 CSV 추출(단방향)이다. 와이어프레임은 단방향 + 수기 보정 플로우를 기본으로 그리고, 양방향은 2차 옵션으로 표기한다.

→ RC-I-11 존치 여부는 우리가 판단할 사안이다. 전제가 성립하지 않으면 화면을 그려도 쓸 수 없다. 와이어프레임 착수 전에 존치·삭제를 정한다.

또한 본부장은 "시장이 커지면 기존 CRM사와 충돌이 있을 수 있다"고 인정했다. 미창조가 CRM 시장에 진입하면 같은 상대가 경쟁자가 되어 API가 닫힐 위험이 구조적으로 존재한다. → RC-I-10(병행 운영)과 로컬 서버 직수집(RC-L)이 그 시점의 보험이다.

[설계 노트] 네트워크가 끊기면 카드 승인을 받을 수 없다. 매장 로컬 서버는 매장 안 디바이스가 데이터를 나눠 갖는 장치이고, 카드 승인은 매장 밖 VAN·카드사와의 왕복 통신이라 로컬로 대체되지 않는다. 승인번호를 매장이 발급할 수는 없다.

단절 시 보장 범위는 예약·고객 조회·시술 기록까지로 한다. 잔액 차감(C-15·B-21)은 차감하지 않고 "보류"로 남긴 뒤 재연결 시 확정한다 — 기술적으로는 로컬에서 되지만 두 단말이 각자 차감하면 잔액이 깨진다.

단말이 자체 승인 후 사후 전송하는 방식(무승인 거래)이 가능한지는 VAN·카드사 계약에 달려 있다(K-15에서 확인). 한국 리테일에서 표준은 아니므로 된다고 전제하지 않는다.

⚠️ 계획서 문언 자체가 재검토 대상이다. 원본을 대조하면 두 문서가 다르게 적혀 있다.

시나리오는 주어가 동기화이고 범위가 매장 내 디바이스 간이라 기술적으로 성립한다. 계획서는 "동작"으로 뭉뚱그렸고 그 디바이스 목록에 POS 가 들어 있어 결제까지 되는 것으로 읽힌다. 전사 과정에서 한정어가 빠진 것으로 보인다.

네트워크가 끊겼는데 카드 승인을 받을 방법은 없다. 따라서 이 문언은 그대로 두면 이행 불가 약속이 된다. → 계획서 문언을 시나리오 원문 수준(“매장 내 디바이스 간 동기화”)으로 한정하도록 파수·미창조와 정리한다(5장 30번). 계획서를 부정하는 것이 아니라 원래 범위로 되돌리는 것이다.

실무 중요도: 미용실은 샴푸·트리트먼트 등 제품 판매가 실제 매출원이다. 과업지시서상 F-10은 2차이나 POS에서 제품을 결제하는 것 자체는 1차에 필요하다 — 결제 화면이 시술만 처리하면 매장이 기존 POS를 못 버린다.

성격이 다른 두 물품이 한 도메인에 있다. 판매 제품(O-01~06·09)은 매출을 만들고 고객이 가져가지만, 시술 약제(O-07·08)는 원가이고 배합비(G-01)로 소진된다. 단위·소진 경로·고객 접점이 모두 다르고 공유하는 것은 재고(O-03)뿐이다. → O-07·08을 G 도메인으로 옮기거나 별도 도메인으로 뺄지 판단이 필요하다. 지금은 재고를 한 화면에서 보는 이점 때문에 붙여 둔다.

연결 기능이 화면에서 값을 정하거나 그 일을 하는 기능 다른 화면의 설정을 읽어 오거나 참조만 하는 것은 걸지 않는다.
그러면 설정 화면 하나에 전 도메인이 붙고, 어느 화면을 그려야 그 기능이 완성되는지 알 수 없게 된다.
예 — SC-M33 채널 연동 상태는 채널 목록을 K-09에서 읽어 오지만 K-09를 걸지 않는다. 설정 UI 는 SC-M32에 있다.

차수는 과업지시서상 구현 연차다. 2차년도 화면도 정의는 해 두고 차수 열에 2차로 표기한다 —
파수가 누락으로 읽지 않게 하고, 1차년도 화면을 그릴 때 확장 지점을 알 수 있게 하기 위함이다.

이미 정해진 것 — 회원권·정기권·선불권은 1차 구현 범위로 확정했다(2026-08-10 이원섭).
미창조의 사업 목표가 헤어짱·핸드SOS 대체이고 회원권은 미용실 매출의 상당 부분을 차지하는 선수금 상품이라,
이것 없이는 외부 CRM을 끊을 수 없다. 아래 법무·회계 항목의 상당수가 이 결정에서 따라온 것이다.

결정권유 수락 확률은 미창조 본사가 본다 27번 항목에 답이 나왔다(2026-08-12 이원섭).
매장 매니저가 아니라 본사가 개별 디자이너의 권유 성과를 확인한다.
따라오는 것이 넷이다 — 이 결정은 화면 하나가 아니라 권한 설계를 건드린다.

마지막 것이 가장 무겁다. 디자이너가 자기 수락률로 평가받으면 확실한 것만 권하거나 권유를 기록하지 않는다.
추천 모델(SFR-A~C)이 그 데이터로 학습하므로 모델 품질이 함께 내려간다.
13번(성과·정산 데이터 열람 범위)은 매장 안을 전제로 쓴 것이라, 본사까지로 넓혀 노무 협의에 다시 올려야 한다.