2월 4일 회의

1) 프로젝트 한 줄 방향

• 통신사(LG U+) 고객 데이터 기반으로
  1. 고객 특성 요약/프로파일링, 2) 추천(요금제/부가서비스/혜택), 3) 검색(상담/이력/필터링) 을 결합한 서비스 아이디어가 중심축으로 잡힘.

2) 만들고 싶은 핵심 기능

A. 고객 특성(프로파일) 생성/요약

• 고객의 **기본 정보 + 상담 이력 + 이용/행동 데이터(로그)**를 바탕으로
  • “이 고객은 어떤 유형인지”를 짧게 요약해 상담원/관리자가 빠르게 파악하도록.
• 지표 예시로는 자주 문의하는 유형, 상담 빈도, 상담 시간/패턴 등이 언급됨.

B. 이탈 위험/Next Best Action(추천)

• 고객의 불만/패턴을 기반으로 이탈 위험군 분석 → “요금 불만이 높으니 어떤 혜택/요금제를 안내” 같은 추천.
• 더 나아가 최적 행동을 제안하는 에이전트(Next Best Action) 형태까지 확장 아이디어가 나옴.

C. 검색 엔진(상담/이력/요금제 탐색)

• 상담 이력/고객 정보를 검색·필터링하고,
• “구글처럼” 추천 검색어/자동완성까지 있으면 좋겠다는 논의.

---

3) 데이터 범위/타겟에 대한 논의

• “고객”을 어떻게 정의할지(개인/특정 서비스 사용자 등) 구체화가 필요하다는 의견이 반복됨.
• 소상공인(자영업) 타겟을 잡으면 페르소나가 명확해져 기획이 쉬울 수 있다는 제안.
  • 예: 인터넷/CCTV 결합 상품, 매장 환경에 맞는 요금제/부가서비스 추천

---

4) 상담(채팅/전화/음성) 포함 여부

• 상담이 “주제의 핵심”이라기보다 추천·검색을 강화하기 위한 데이터/맥락으로 보는 분위기.
• 다만 현실적으로 통신 상담은 전화 비중이 크다는 의견이 있어,
  • *음성 데이터(STT)**를 섞어보자는 제안이 나옴.
• 전화/음성은 구현 난도가 높으니:
  • 처음엔 크게 잡되, 시간 부족하면 후순위로 절삭 가능하다는 합의적 톤.

---

5) 화면/사용자 구도(관리자 vs 고객)

• 요구사항을 보면 관리자 화면 비중이 크다는 인식이 공유됨.
• 방향성 후보:
  1. 고객은 최소 CRUD(내 정보/상담 이력 조회·작성) 위주로 얇게,
  2. *관리자 쪽을 메인(고객 상세/특성/추천/검색)**으로 두껍게.
• 관리자/고객을 분리 운영하는 설계(서버 분리, 라우팅) 아이디어가 나왔고, 접근 제어는 스프링 시큐리티/리버스 프록시(예: nginx) 등으로 막는 방식이 언급됨.

---

6) 기술/구현 아이디어(현실 제약 포함)

• LLM/추천은 RAG(벡터DB 검색 + 답변 생성) 방식 경험담이 공유됨.
• 비용 이슈로 유료 OpenAI API는 부담이라는 의견 → Hugging Face 기반 오픈 모델 활용 가능성 언급.
• 클릭/이용 로그 수집 → Apache Kafka 파이프라인 아이디어가 나왔고,
  • 실시간 “학습”은 어렵고, 보통 로그 적재 후 배치/주기 학습·갱신 쪽이 현실적이라는 정리가 있었음.
• 음성 파이프라인 예시로는 “통화 녹음 → S3 저장 → Google STT로 텍스트화 → DB 저장 → LLM 입력” 흐름 경험 공유.

---

7) 당장 남은 결정 포인트(미확정)

• 고객 정의/타겟(개인 vs 소상공인 등)과 데이터 스키마 범위
• “이용 정보”가 정확히 무엇인지(요금/부가서비스 사용 vs 클릭/행동 로그)
• 전화/음성 상담을 MVP에 넣을지, 아니면 후순위 옵션으로 둘지
• 관리자/고객을 둘 다 구현할지 vs 관리자 중심으로 갈지
• 추천의 형태: 룰 기반 + 간단 통계 vs 임베딩/RAG 중심 vs ML 모델(이탈 예측)

---

8) 다음 액션(회의에서 나온 합의 흐름)

• 오늘은 아이디어 더 모으고 요구사항을 세분화한다.
• 백엔드/프론트가 각자 1시간 정도 따로 논의 후 합치자는 제안.
• 기능을 우선순위로 나누자(필수/선택/제거 가능):
  • “무조건 구현해야 하는 것 vs 시간 되면 하는 것 vs 빼도 되는 것”으로 정리.
• (MVP 관점) 로그인은 소셜 로그인(구글)만으로 단순화하는 방향이 언급됨.