TEUM 제품·UX/UI·구현 명세
제품 계약
틈은 1~3인 비의료 예약형 뷰티샵의 빈 시간에 기존 고객의 다음 방문을 연결하는 서비스다. 사용자의 첫 질문은 ‘이번 주 비어 있는 시간을 어떻게 채울까?’이고, 핵심 행동은 ‘초대 한 개 만들기’다. AI 상담·급여·POS·전국 검색 마켓플레이스는 초기 범위에서 제외한다.
현재 구현은 브라우저에서 체험하는 모바일 앱 형태의 인터랙티브 프로토타입이다. 화면은 390px 휴대폰을 기준으로 설계했으며 PC에서도 같은 모바일 화면을 표시한다. 설치 바이너리 제작은 범위에 포함하지 않는다. Python 표준 라이브러리 HTTP 서버 + SQLite와 모바일 전용 HTML/CSS/JavaScript로 동작한다. 의존 패키지 설치 없이 Python 3.10 이상에서 구동한다. 데이터는 SQLite에 영속 저장되고 새로고침·브라우저 종료 뒤 유지된다. localhost 전용 단일 매장 프로토타입이며 실제 고객 서비스 운영 시스템이 아니다.
사용자와 작업
| 사용자 | 상황 | 성공 조건 |
|---|---|---|
| 원장 | 시술 사이 취소 확인, 대부분 스마트폰 사용 | 가격·시간·추천 이유를 짧게 보고 초대 승인. 잘못 발송하지 않음 |
| 재방문 고객 | 원하는 시간에 예약이 어렵거나 재방문을 미룸 | 앱 설치 없이 일시·시술·가격 확인 후 예약. 취소·수신거부 경로 파악 |
| 운영자 | 파일럿 온보딩과 매출 확인 | 수신 동의·권한·데이터 출처를 검증하고 효과와 오작동을 분리 |
| 투자자 | 현실적인 판매·수익 가능성을 평가 | 실제 작동 흐름, 경쟁 압박, 비용·효과 가정, 검증 조건 확인 |
모바일 앱 인터랙션
- 하단 4개 탭: 오늘·예약·고객·성과. PC용 사이드바와 넓은 대시보드는 제거했다.
- 화면 내부 스크롤과 고정 하단 탐색을 분리했다. 바텀시트·고객 예약의 주요 버튼은 하단에 유지한다.
- 초대는 1단계 대상 확인 → 2단계 문구·금액·승인으로 나눴다.
- 고객 목록은 터치 가능한 행, 예약은 시간 카드와 날짜·상태 필터를 사용한다.
- 고객 예약과 예약 완료 영수증을 앱 안에서 이어서 체험한다.
- 바텀시트를 열면 배경 조작을 막고 포커스를 제한한다. 닫기·Escape·뒤로가기를 지원한다.
- 390×844, 360×780, PC 1440×1080에서 검토했다. PC에서는 휴대폰 프레임, 실제 작은 화면에서는 전체 화면으로 표시한다.
- 소스: mobile/index.html, mobile/mobile.css, mobile/mobile.js. 기존 app/ 소스는 보존했다.
정보 구조와 화면
- 랜딩 /: 핵심 가치, 원장 데모, 투자자 자료. 합성 화면이라는 표시와 실제 전송·결제가 없다는 정보.
- 오늘의 틈 /app/#home: 빈 시간 상한 매출, 방문 완료 연결 매출, 초대 예약 건수, 우선 시간. 상한 매출을 ‘예상 회복액’으로 표현하지 않는다.
- 예약 캘린더 #slots: 시작 시간·시술 길이·가격·상태. 직접 등록, 겹치는 시간 오류, 예약 완료와 방문 완료 구분, 시간 종료.
- 고객 #customers: 선호 시술·마지막 방문·수신 동의·동의 버전. 검색·CSV 가져오기·철회. 실제 전화번호를 샘플에 넣지 않는다.
- 2단계 초대 바텀시트: 규칙 설명, 적합/제외 고객, 정가·5%·10% 선택, 광고성 문구 예시, 점주 검토 체크. 처음에는 정가가 기본이다.
- 초대 내역 #campaigns: 초대 링크, 상태, 비교군 수, 메시지 기록. ‘발송 성공’ 대신 ‘링크 준비’로 표현. 외부 발송은 0건이다.
- 고객 /book?token=…: 특정 초대의 매장·시술·일시·총 가격. 필수 예약 내용 확인. 첫 확정 이후 다른 초대 종료, 24시간 만료, 수신거부.
- 성과 #insights: 방문 완료만 연결 매출 반영. 인과적 추가 매출은 ‘아직 미측정’. 다운로드 CSV와 실시간 손익 계산, 활동 로그.
- 설정 #settings (우측 상단 프로필): 매장명·공헌이익률·요금 가정 저장. 연결된/미구현 어댑터 표시, 데모 초기화 확인.
- 투자자 자료 /pitch/: 영문 피치 열람, 한국어 조사·설계·사업 메모, PPTX/PDF 다운로드.
UX 결정
- ‘오늘의 틈’을 첫 화면으로 둔다. 메뉴가 아니라 원장의 현재 손실 상황에서 시작한다.
- 소비자는 로그인·앱 설치 단계를 거치지 않는다. 현재 데모는 소유자 인증 대신 로컬 데모 세션을 사용한다. 운영 서비스는 소유자 로그인과 고객 휴대폰/예약 식별 검증을 추가한다.
- 승인은 초대별 한 번이다. CSV에 있는 연락처만으로 마케팅 동의를 추정하지 않는다. 데모에서 점주가 임의로 동의를 켜는 버튼은 없다.
- 고객별 규칙 점수는 예약 확률이 아니다. 이를 UI에 명시한다. 학습 데이터가 없는 상태에서 ‘AI가 94% 예약 확률 예측’ 같은 문구를 쓰지 않는다.
- 오류는 바텀시트 내부에 표시한다. 중복 시간·동의 미확인·초대 중복·만료·이미 예약된 자리를 처리한다.
- 예약 완료 전에 매출을 늘리지 않는다. 방문 완료 이벤트가 KPI를 바꾼다. 취소 시 매출에서 제외한다.
- 한 자리를 여러 고객이 동시에 눌러도 서버 트랜잭션이 한 건만 확정한다. 현재는 예약금을 받지 않으므로 결제 대기 선점 상태는 없다.
- 첫 실험에는 CSV/직접 입력을 제공한다. 실제 네이버와 양방향 연동이 된 것처럼 보이지 않도록 상태를 표시한다.
시각 디자인
브랜드 ‘틈’은 빈 시간과 다음 방문 사이의 공간을 뜻한다. 상표·도메인 조사는 별도 필요하다. 현재 디자인은 마스코트·광고 영상보다 예약과 금액의 정확한 이해를 우선한다.
| 요소 | 토큰/선택 | 목적 |
|---|---|---|
| 주 색상 | Deep green #174F40 | 완료·확정·핵심 행동 |
| 포인트 | Soft lime #D9ED8C | 빈 시간의 기회·추천 |
| 바탕 | Warm off-white #F5F6F1 | 긴 운영 작업에서 시각 부담 낮추기 |
| 본문 | #203D35 | 따뜻한 대비 |
| 주의 | #BB633F | 미예약·취소 등 설명 |
| 서체 | Segoe UI / 맑은 고딕 / 시스템 대체 | 로컬 실행, 한글·숫자 가독성 |
| 레이아웃 | 224px 왼쪽 메뉴, 유동 본문, 최대 1440px | 매장 운영 도구의 탐색 일관성 |
| 모바일 | 800px 이하 하단 5메뉴·한 열·44px 주요 버튼 | 시술 중 짧은 조작 |
| 간격/모서리 | 8px 계열, 카드 12~17px, 버튼 9px | 시각 위계와 안정감 |
| 모션 | 300ms 등장, reduced-motion 지원 | 상태 변화의 인지 |
접근성: 실제 label, 버튼·링크 의미 태그, 키보드 포커스, dialog/ESC/포커스 복귀, live status, 색뿐 아니라 상태 텍스트, 작은 화면의 가로 스크롤 표를 사용한다. 주요 고객 흐름은 390px 폭에서 검토한다. 정식 접근성 적합성 인증이나 실사용자 연구를 수행했다는 뜻은 아니다.
Higgsfield MCP의 get_host_status 결과: After Effects·Premiere·Blender·3D Blocking Studio 모두 연결되지 않았다. 생성 이미지·영상·캐릭터는 제작하지 않았다. 코드로 만든 실제 UI와 실행 화면을 제품 증거로 사용했다. 추가 브랜드 영상이 필요하면 Blender/Adobe의 Higgsfield 패널 연결 후 생성·검수·비용 기록을 별도 수행한다.
데이터 구조
- settings: 매장명, 월 요금 가정, 공헌이익률.
- customers: 예시 이름, 선호 시술, 마지막 방문 후 일수, 동의 여부·버전, 최근 안내 후 일수.
- slots: 시술, ISO 시작 시간, open/booked/cancelled, 가격, 고객 연결, 방문 완료.
- campaigns: slot 고유 FK, 할인율, 점주 승인 문구, 생성 시각.
- offers: 암호학적 랜덤 토큰, 캠페인/고객 FK, ready/holdout/claimed/closed, 만료시각. 캠페인·고객 조합 UNIQUE.
- events: 생성·예약·방문·철회 등의 로그.
동의 버전과 방문 일수는 데모용 최소 구조다. 실제 서비스에는 UTC 시각과 매장 시간대, 수집 경로·증거·처리방침 버전, 수신 매체별 동의, 권한 부여·철회 시각이 필요하다. 여러 매장·직원·자원 충돌도 실제 DB 제약으로 확장해야 한다.
API와 저장 동작
| API | 역할 |
|---|---|
| POST /api/session | 로컬 데모 입장, HttpOnly SameSite 세션 |
| GET /api/state | 점주 화면 전체 상태 |
| POST /api/slots | 입력 검증과 겹치는 시간 차단 |
| GET /api/candidates?slot=id | 동의·선호·안내 간격 기준 선별 |
| POST /api/campaigns | 슬롯별 한 개 캠페인, 할인·승인 검증, 초대 토큰 생성 |
| GET /api/offer/token | 연락처 없는 고객용 최소 공개 정보 |
| POST /api/claim/token | BEGIN IMMEDIATE로 예약 경쟁 처리 |
| POST /api/unsubscribe/token | 로그인 없는 수신거부, 열린 초대 닫기 |
| POST /api/complete | 방문 완료 한 번만 반영 |
| POST /api/cancel | 진행 중 시간 종료와 초대 닫기 |
| POST /api/import | 헤더·범위·동의 근거 검증, 모든 행 원자적 가져오기 |
| POST /api/settings | 설정 저장 |
| GET /api/export | CSV 리포트, 추가 매출은 not_measured |
| POST /api/reset | 이 로컬 데모 DB만 초기화 |
서버는 127.0.0.1에만 바인딩한다. Host/Origin 검사, JSON 요청 제한, 출력 이스케이프, SQL 바인딩, 파일 경로 제한을 적용했다. 실제 인터넷 배포의 보안·개인정보 심사를 대체하지 않는다. 브라우저를 가진 로컬 사용자는 누구나 데모 세션을 생성할 수 있다.
실제 서비스 구축 순서와 남은 의존성
- 0~2주: 매장 검증, 동의 증거 스키마, 사용자 연구. 진짜 고객 데이터를 넣기 전에 위탁계약·개인정보 처리 체계 확정.
- 3~5주: 관리형 Postgres, tenant_id 기반 격리, 점주 인증/역할, 감사로그, HTTPS·암호화·백업·복구·삭제, 악용방지.
- 4~6주: 발송 공급사와 광고성 메시지 채널 계약, 발신자 등록, 템플릿 심사, 거부 목록, 08~21시 등 적용 규정·채널 정책에 맞춘 시간 제한, 재시도/idempotency/웹훅.
- 5~8주: 권한 확보한 예약 연동만 추가. 범용 네이버 쓰기 API가 누구에게나 열려 있다고 가정하지 않는다. 권한이 없으면 운영자 승인 흐름 유지 또는 틈을 해당 시간의 단일 예약 원장으로 운영.
- 7~10주: 방문·취소·환불·원래 예약 이동을 정합성 있게 대조. 슬롯/영업일 단위 실험 배정과 분석 구현.
- 이후: 필요할 때 PG 예약금·환불·웹훅 구현. 결제 대기 5분 hold, 만료 해제, 결제 성공 뒤 confirm, 실패·늦은 webhook 정합성. 실제 PG 계약과 테스트가 전제.
제품·엔지니어 2명과 현장 운영 1명 기준 8~10주 베타 계획은 추정치다. 파트너 API 승인·메시지 심사·채용이 지연되면 일정이 달라진다. 현재 프로토타입의 실행 성공을 이 전체 일정의 완료로 보지 않는다.