2월 5일 회의

세부과업 3번째줄 질문 api 인지 아니면

상담사랑 관리자랑 어떻게 나눌지

상담 키워드 1.

상담 전화 / 채팅 → 답변 오면 정하기

상담, 관리자 웹사이트만, 고객은 앱 크기

지도 → 추천의 일부로 (주변에 유플러스 사용하는 매장이 있다 가보는게 어떠냐)

추천 상품 → 요금제만 하면 X , 추가로 부가서비스, 인터넷, 기기, 혜택 등

⇒ 유플러스에서 추천해주는 서비스

→ 요금제만 했을때도 응답속도가 느리면 못할수도

고객 카테고리 분류

• 고객 페이지 → mbti처럼 간단하게 확인할 수 있는 페이지 ex) 데이터 많이 쓰는 유형

• 관리자 페이지 → 더 세세하게 분류

세부과업은 전부 관리자 페이지

오후 회의

• 고객

• 유형: 개인 하나로 줄임 + 개인 내에 소상공인 여부 포함

• 통계 결과를 통해서 고객에게 표기해줄 유형을 캐릭터 형태로 보여주기

• STT 로직

• 녹음파일을 거쳐서 저장됨 (실시간 X)

• 전화 상담 내용을 녹음파일로 저장 → 녹음파일을 요약 페이지로 전달

• 전화 방식

• 회선 따서 다이얼로 걸기

• Like 보이스톡

• FAQ 기능

• 정적페이지에 자주하는 질문으로 마련

• 새로운 아이디어

• 유플러스 사용자가 유플러스 소상공인에게 가면 할인해주는 기능

• 유플러스 홍보 기능

• UI

• 고객: 웹앱

• 상담사/관리자: 웹사이트

회의록 녹음 요약본

1) 서비스 타겟/범위 정리

• 고객 주체를 **개인 / 기업 / 소상공인**으로 잡았던 걸 재검토.

• 결론 분위기: **“기업은 제외”** 쪽으로 기울었고,

• **개인 중심**으로 가되 **개인 안에 ‘소상공인’ 케이스를 포함**하는 형태가 현실적이라는 의견 다수.

---

2) 상담 기능 범위 (전화/챗)

전화 상담

• “실시간 STT(통화 중 자막)”은 **난이도/리스크가 높음** →

**MVP는 ‘통화 녹음 파일 → STT 변환(후처리)’**로 가자.

• 실시간 STT는 **가능하면 나중에 고도화**(옵션)로 두자.

채팅 상담

• AI 답변형(LLM/OpenAI 활용) 가능성 언급.

• 다만 범위가 커질 수 있어,

• 너무 버거우면 **키워드 클릭형 상담(FAQ/정적 답변)**도 대안으로 논의됨.

• “게시판처럼 문의 남기고 며칠 뒤 답” 형태는 **안 하자**는 공감대.

---

3) “상담 이력 / 요약”을 누가 보나? (핵심 정리)

• 논쟁 포인트:

“고객이 본인 상담 이력/요약을 다시 볼까?” → **굳이 안 볼 것 같다**는 의견 우세.

• “상담 이력 요약”이라는 표현이

• **1건 요약**인지,

• *누적 상담 기반 통계(상담 횟수/주요 유형)**인지

혼동을 만들고 있음.

• 결론 분위기:

• “상담 이력 요약”은 **고객용이 아니라 관리자/상담사용(통계/인사이트)** 성격이 강하다.

• 고객 화면엔 굳이 깊은 히스토리보단 **필요 최소(요약 정도)**만.

---

4) 관리자 vs 상담사: 분리/통합 방향

• “상담사와 관리자 역할을 합칠지” 논의.

• 의견 흐름:

• **역할은 다르니 분리하는 게 자연스럽다**(관리자=제재/권한/운영, 상담사=응대/후속처리).

• 단, UI/페이지 레벨에서 상담사는 기능이 매우 단순해질 수 있음:

• 전화 받으면 **해당 고객 정보만 뜨고**

• 통화 종료 후 **후속 조치 기록/태깅 정도**

• 개인정보 관점도 언급됨:

• 상담사가 **모든 고객 이력에 상시 접근**은 과함 →

**“상담 발생 시점에 해당 고객만 조회”** 같은 단방향 접근이 더 적절.

---

5) 분석(Analysis)이 정확히 뭔가? (정의 합의 필요)

• “데이터 기반 고객 분석 서비스”인데,

• 분석을 **전체 통계(남/여 비율, 이용 분포)**로 볼지,

• **개인 단위 유형화(캐릭터/MBTI처럼 ‘당신은 ○○형’)**

로 볼지 의견이 갈림.

• 현실적 합의 방향:

• **관리자**: 더 세세한 통계/유형 분류/리스크 파악

• **고객**: 1페이지 정도로 가볍게 “내 유형” 보여주는 수준(캐릭터/타입)

---

6) 추천(Recommendation) 범위 조정 논의

• “요금제 추천”만 하면 **기존 사례와 중복**이 많아 식상할 수 있음.

• 확장 아이디어:

• 요금제뿐 아니라 **부가서비스/인터넷/기기/혜택** 등으로 추천 카테고리를 넓히자.

• 지도(소상공인 매장 혜택 노출)는 “추천의 일부”로는 넣을 수 있지만,

• 기능이 커져서 서비스가 두 개 붙은 느낌이 날 수 있어 **MVP엔 보류 가능**.

• AI 사용 관련:

• 추천에도 AI(LLM) 쓰면 좋지만, **상담까지 AI를 다 넣으면 개발 부담 큼**.

• 선택지로 “추천은 가벼운 알고리즘(가중치/교집합 등) + 나중에 AI 고도화”도 논의됨.

---

7) 화면/플랫폼 방향

• 상담사/관리자: **웹(PC)**

• 고객: **웹앱(모바일 화면 중심, 반응형/앱처럼 보이게)** 방향 공감대.

• 네이티브(React Native)는 부담이 있어 **웹앱으로 가자** 쪽.

---

8) 남은 미결정(내일까지 확정 필요로 언급됨)

1. **분석에 사용할 데이터 범위 확정**

• (예: 요금제, 데이터 사용량, 약정 만료, 상담 유형/불만, 부가서비스 등)

1. **MVP에서 추천 범위**

• 요금제만 vs 카테고리 확장(부가/인터넷/기기/혜택/지도)

1. **전화 상담 MVP의 정의**

• “전화 연결만” vs “녹음 저장 + STT 후처리까지”

1. 고객 화면 구성

• 첫 화면/마이페이지/상품(요금제) 리스트/추천 페이지/내 유형 페이지 등

---

9) 액션 아이템 (회의에서 나온 ‘다음 스텝’)

• **오늘~내일**: “고객이 들어와서 어떤 흐름으로 움직이는지” **시나리오(사용자 여정)**를 먼저 잡자.

• 시나리오가 나오면 자연스럽게

• 필요한 페이지,

• 필요한 데이터,

• 필요한 API/ERD 범위가 결정됨.

10) MVP 범위 합의(포함/보류 정리)

• **고객 기본 정보/이용 정보 조회**: **MVP 포함** (요금제/혜택/가입 서비스/이용기간/이용량 등)

• **실시간 이용 현황**: **추가 검토 후 결정**

• 기술/비용/부하 이슈 → **월 단위/정적(집계) 데이터**로 가는 쪽이 우세

• **요금제 추천**: 필요성은 공감, **MVP 포함 여부는 보류**

• **요금제 변경(즉시 변경)**: 방향성만 합의

• “추천 카드 → 자세히 보기 + 즉시 변경”처럼 **한 화면 내 완결 UX** 선호

• 실제 변경을 **내부 처리 vs 외부 페이지 이동**은 추후 결정

• **상담 만족도 평가**: 통화 종료 UX가 관건

• 다이얼 통화는 즉시 팝업이 어려움 → **앱 알림/문자/푸시** 논의

• 앱 내 통화(보이스톡)면 **종료 직후 평가 UI 노출 가능**

11) 관리자/상담사 화면 개인정보 이슈(핵심 쟁점)

• **관리자 고객 상세 조회/검색 UI**는 **법적/보안 리스크가 큼** → 강한 공감대

• 결론 방향:

• **검색 자체 제거 고려**

• 노출하더라도 **이름/전화번호/이메일은 마스킹 전제**

• **권한 분리(관리자 vs 상담사)** 필요

12) 알림 기능 논의(보류 결론)

• 푸시/알림은 범위 확장(이벤트버스/파이어베이스 등) 위험 → **전체적으로 보류**

• 단일 알림(요금제 변경 완료 등)은 프론트 **모달/토스트로 대체 가능**하나, 우선순위 낮음

13) 추천/분석 기술 난이도 인식

• 벡터 DB + 코사인 유사도 기반 추천은 “화려하지만”

• **직접 구현/커스터마이징 많음**

• 팀이 RDB 중심이라 **러닝커브/리스크** 존재

• *추천 투자를 얼마나 할지(= MVP 포함 여부)**를 월/화까지 내부 결론 내기로 언급

14) 다음 액션 아이템

• 실시간 이용 현황: **정적/집계 설계안 확정**

• 요금제 변경: **내부 처리 vs 외부 이동** 결정

• 만족도 평가: **다이얼 vs 앱 내 통화** 선택에 따른 구현 전략 확정

• 개인정보 정책: **관리자 화면 데이터 노출 범위/마스킹/검색 정책** 명세화

• 추천: **MVP 포함 여부 + 기술 스택** 최종 결정