실제 현장은 코드와 다르다
실제로 사업 현장에 들어와 보니, 예상했던 시나리오와 많이 달랐다. 성형, 탈모, 피부는 각각의 다른 사업 분야 인줄 알았으나, 전문의 한명이 케어할 수 있거나 하나의 사업자로 다양한 전문의가 운영하는 사례가 많았다.
특히 뷰티 업종이 그랬다.
그래서 파트너 관리의 로직을 빠르게 업데이트 할 필요성을 느끼고 고민했다.
AI들은 수 많은 가설과 어떻게 하면 수정할 수 있는지 대안들을 내놨다.
그 많은 설계 중에서 나는 빈틈이 보였다.
수 많은 작업들을 하면서, 조각난 데이터를 바라보고 있는 AI들에게는 시나리오를 관통해서 시스템을 하나의 파이프라인으로 볼 수 있는 충분한 데이터가 없었다.
매일 하루에 한번씩은 각 AI들의 토큰이 터져서 새로운 방을 만들고 핵심 8개의 사업 분야를 쪼개서 특화된 부분들을 활용 하고 있었기 때문에 결국엔 내가 찾아내야 했다.
그러다가 머릿속 시스템 설계 중에서 희마하게 빛나는 유일한 통로가 보였다.
완성된 로직으로 가는 가장 빠르고 안전한 길이였다.
옵티스랩의 자회사 중에 피부케어랩,
탈모케어랩 같은 의료 영역 플랫폼이 있다.
그리고 6월 15일 뷰티케어랩(성형) 런칭을 앞두고 있다.
법률은 단순했다. 한 변호사 = 한 사업자 = 한 영역(법률). 데이터 모델이 1:1.
문제는 의료였다.
의료 시장의 구조
현장을 들여다보면 의료는 다중 영역 운영이 흔하다.
- 피부 + 성형을 같은 사업자·같은 의료기관에서 운영
- 피부 + 탈모를 각각 다른 의사가 한 의료기관에서 운영
- 피부 단독, 탈모 단독, 성형 단독으로도 운영
- 셋 다 운영하는 종합 의료기관도 있음
법률 모델(1 파트너 = 1 영역)을 그대로 적용하면 세 번 가입해야 한다.
대시보드도 세 개. 운영자도 파트너도 피곤하다.
그렇다고 한 파트너에 다중 영역을 콤마로 넣으면 시트 구조가 복잡해진다.
영역별 단가가 다르고(피부, 성형, 탈모 각각 다름), 영역별 충전·잔여·CS 담당자도
따로 관리해야 한다.
다른 AI들에게 물어봤다.
방법 A: 한 partner_id에 다중 영역, 콤마로 분리
방법 B: 영역별 partner_id 분리, 가입도 따로
방법 C: sub_master 시트 새로 만들기
모두 시트 구조를 새로 짜야 했다. 운영 중인 시스템에서 기존 시트·Make
시나리오·매칭 로직을 다 건드리는 작업이다.
한 줄로 풀린 자리
며칠을 고민하다가, 결국 완전히 다른 답에 도달했다.
사업자번호를 묶음 키로 쓰면, 시트는 건드릴 게 없다.
- 가입은 사업자번호 1개 + 이메일 1개로 영역을 다중 체크해서 한 번에
- 파트너 ID는 순서대로 자동 발급되고, 영역 수만큼 접미사가 붙는다
(partner_N_skin,partner_N_beauty,partner_N_hair) - 시트엔 영역마다 1행씩 그대로 들어감 (기존 1행 구조 그대로)
- 매칭·충전·잔여·CS는 행 단위로 완전 독립 (Make 시나리오 그대로)
- 대시보드에서 같은 사업자번호·같은 이메일 발견되면 탭으로 분기
partner_master 시트:
partner_N_skin | 김피부과 | 사업자 123-45 | email@x | 피부 | CS1 | 잔여
partner_N_beauty | 김피부과 | 사업자 123-45 | email@x | 성형 | CS2 | 잔여
partner_N_hair | 김피부과 | 사업자 123-45 | email@x | 탈모 | CS3 | 잔여
세 행이지만 같은 사람. 사업자번호가 묶음 키 역할.
변경 비용
이 설계의 진짜 강점은 기존 시스템을 거의 안 건드린다는 점이다.
| 영역 | 변경 |
|---|---|
| Google Sheets 구조 | 사업자번호 컬럼 1개 추가 (끝) |
| Make 매칭 시나리오 | 0 변경 (기존 영역별 매칭 그대로) |
| 파트너 충전·잔여·CS 로직 | 0 변경 (행 단위 독립) |
| 환불 / 불량 신고 시나리오 | 0 변경 |
| 회원가입 폼 | UI에 영역 다중선택만 추가 |
| Make 가입 시나리오 | 라우터 분기 + 행 N개 생성 |
| 대시보드 | 사업자번호 묶음 검색 + 탭 분기 UI 추가 |
운영 중인 시스템에서 가장 위험한 자리(시트·매칭·충전)는 0 변경. 새로 짤 자리(가입 분기·탭 UI)는 추가만.
교훈
AI 셋이 던진 답 — 콤마 / 컬럼 추가 / 별도 시트 — 모두 기존 구조를 바꾸는 방향이었다.
운영자가 본 답은 기존 구조를 안 바꾸는 방향이었다.
복잡한 데이터를 다 1행에 욱여넣지 말고, 자연스러운 묶음 키를 찾으면 된다.
이번엔 그 묶음 키가 사업자번호였다. 시장 현실(한 의료기관이 다중 영역 운영)이 그대로 데이터 모델의 키가 됐다.
다음 글에서는 이 설계를 실제 회원가입 폼으로 옮긴 6시간 디버깅 이야기를 적는다.
