미창조㈜ · 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차

R5SC-H13

목적: 채널마다 다른 표현을 우리 체계로 옮긴다
트리거: 채널 연동 개시, 미매핑 건 발생
입력: 채널별 메뉴·시간·고객 필드 · 우리 마스터(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차

R5SC-H13

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

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

R5SC-H13

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

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

R5SC-H13

목적: 얼마나 옮겨졌는지 본다. 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차

R5SC-H13

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

I-3. 검증 — 2개

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

R5SC-H13

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

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

R5SC-H13

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