[TIL] 유레카 sw교육과정 백엔드 24주차 내용 정리

02.09

요구사항 정리

팀 프로젝트 주제

주제

고객 상담 기록 관리 서비스

세부과업

• 상담 대화 내용과 상담 정보를 등록하고 조회할 수 있는 기능 구현
• 상담 기록을 저장하고 조회하기 위한 백엔드 API 설계 및 연동
• 상담 기록에 대한 요약 결과를 함께 저장하고 조회하는 기능 구현
• 상담 유형이나 키워드를 기준으로 상담 기록을 검색·필터링하는 기능 구현
• (선택) Google 로그인 기반 사용자 인증 기능 적용

---

본 프로젝트는 LG유플러스의 상담 업무를 지원하는 서비스를 가정하여 상담 기록을 저장·관리하고, 필요한 정보를 빠르게 조회할 수 있는 기능을 구현하는 통합 프로젝트입니다. 상담 기록은 대화 내용과 상담 메타데이터(유형/시간/처리 결과) 등으로 구성되며, 서비스 구조 관점에서 데이터 모델링과 API 설계, 프론트·백엔드 연동을 경험할 수 있습니다. 수강생은 협업 기반 개발을 통해 인증, 데이터 흐름, 기능 확장(선택 과제)을 포함한 실제 서비스 개발 방식에 가까운 역량을 습득할 수 있습니다.

세부과업

• 상담 대화 내용과 상담 정보를 등록하고 조회할 수 있는 기능 구현

상담 기록을 저장하고 조회하기 위한 백엔드 API 설계 및 연동

 

📊 추가 기능 요구사항 (확장)

6.1 상담 결과 활용 - 데이터 분석 대시보드

REQ-ID 요구사항명 상세 설명

REQ-6-01	이슈 트렌드 분석	키워드별 상담 건수 추이 (시계열)
REQ-6-02	카테고리별 통계	상담 유형별 건수, 비율, 추이
REQ-6-03	재문의율 분석	카테고리별 재문의율 및 원인 분석
REQ-6-04	고객 니즈 분석	제안/요청 유형별 빈도 분석
REQ-6-05	상담사 성과 분석	상담사별 처리 건수, 해결률, 만족도

6.2 고객 이력 타임라인

REQ-ID 요구사항명 상세 설명

REQ-6-06	고객별 상담 이력	특정 고객의 전체 상담 이력을 타임라인으로 조회
REQ-6-07	이력 요약	고객별 주요 이슈, 처리 현황 요약 제공

6.3 인수인계 지원

REQ-ID 요구사항명 상세 설명

REQ-6-08	원클릭 인수인계	상담 기록을 다른 상담사/부서로 이관
REQ-6-09	인수인계 알림	이관 시 담당자에게 알림 발송

아이디어 기반 요구사항 정의

1. 상담사 업무 지원 및 이력 관리 (Counselor & History)

REQ-ID 요구사항명 상세 설명 우선순위

REQ-1-01	상담 요약 자동 생성	상담 종료 시 AI가 내용을 [상황-요청-조치-다음액션] 구조로 자동 요약한다.	필수
REQ-1-02	고객별 상담 타임라인	특정 고객의 전체 상담 이력을 시간 순서에 따른 타임라인 형태로 조회한다.	필수
REQ-1-03	고객별 주요 이슈 요약	고객별 주요 이슈, 처리 현황, 미해결 과제 등을 한눈에 볼 수 있는 요약을 제공한다.	필수
REQ-1-04	원클릭 인수인계	작성된 상담 기록을 다른 상담사나 부서로 즉시 이관하며 담당자에게 알림을 발송한다.	필수
REQ-1-05	처리 누락 자동 감지	상담 중 언급된 핵심 처리 사항(요금제 변경 등)의 전산 미반영 시 경고를 띄운다.	필수
REQ-1-06	액션 아이템 추출	상담 일지 내 사후 조치 문구를 인식해 To-Do 리스트에 자동 등록한다.	보류
REQ-1-07	상담 대응 가이드 추천	유사 사례 분석을 통해 최적의 대응 스크립트를 추천한다.	보류

2. 관리자용 전략 분석 및 리포트 (Managerial Analytics)

REQ-ID 요구사항명 상세 설명 우선순위

REQ-2-01	이슈 트렌드 분석	특정 키워드별 상담 건수 추이를 시계열 차트로 분석하여 이상 징후를 탐지한다.	필수
REQ-2-02	카테고리별 통계	상담 유형별 건수, 비율, 증감 추이를 대시보드 형태로 제공한다.	필수
REQ-2-03	재문의율 분석	카테고리별 재문의 발생 빈도와 주요 원인을 분석하여 프로세스 개선 근거를 마련한다.	필수
REQ-2-04	고객 니즈/제안 분석	고객의 제안 및 요청 사항 유형별 빈도를 분석하여 신규 서비스 기획에 활용한다.	필수
REQ-2-05	상담사 성과 분석	상담사별 처리 건수, 해결률, 고객 만족도 점수를 지표화하여 관리한다.	필수
REQ-2-06	해지 방어 패턴 분석	해지 방어 성공/실패 패턴을 분석하여 고객 세그먼트별 최적 혜택(NBA)을 도출한다.	필수
REQ-2-07	상담사 강점 기반 배정	상담사별 특화 카테고리를 분석하여 최적의 상담 건을 배정하는 로직을 구현한다.	보류

3. 시스템 및 데이터 공정 (System Infrastructure)

REQ-ID 요구사항명 상세 설명 우선순위

REQ-3-01	비동기 배치 분석 파이프라인	상담 기록 저장 시 Redis와 Batch를 통해 AI 요약 및 키워드 추출을 비동기로 수행한다.	필수
REQ-3-02	폴리글랏 저장소 구축	MySQL(메타), MongoDB(로그), Elasticsearch(통계/검색)로 데이터를 분산 적재한다.	필수
REQ-3-03	대용량 데이터 성능 최적화	500만 건 이상의 데이터를 대상으로 한 시계열 분석 및 필터링 검색 성능을 확보한다.	필수
REQ-3-04	검색 필터 라벨링 저장	자주 사용하는 분석 조건을 라벨로 저장하여 기획 부서의 데이터 접근성을 높인다.	선택

1. 백업 시스템

REQ-ID 요구사항명 상세설명 우선순위

REQ04-01

백업 시스템

녹음 파일의 버전을 관리하고 필요시 복구에 사용한다

필수

 

질문(2/9)

1. 콜센터에서는 soft delete 방식을 사용하는지, hard delete 사용하는지(음성 녹음 파일)
   1. 경우에 따라 다름
   2. hard delete 하는 경우 백업 필요, 추적 가능하도록 history 남김
   3. soft delete 기간 설정, ex) N개월 후 삭제(정책)
   4. 음성 녹음 파일의 목적: 이력 확인, 증거 활용
2. 백업 시스템에서 다루어야하는 데이터의 범위
   • 세부내용고려사항: 음성 녹음 파일만 백업할 경우 누구의 상담인지, 어떤 상담사가 응대했는지 같은 데이터가 없어서 MYSQL데이터 백업을 같이 할지, nosql에 저장된 로그성 데이터들이나 요약된 내용을 백업을 해야될지
   • 기존 : 음성 녹음 파일만 백업
   • meta data 저장 필요함
3. (선택) Google 로그인 인증 → 고객 로그인 지원을 위해 필요한 기능? 상담사, 운영자 로그인만 지원한다면?
   • 세부내용
   • (선택) Google 로그인 기반 사용자 인증 기능 적용
4. 상담 기록을 저장하고 조회하기 위한 백엔드 API 설계 및 연동

• 원천 데이터(콜센터 수집 데이터)를 가공→처리 및 저장하는 것

1. 통신사(콜센터 업체)에 우리 서비스를 등록할 수 있는 기능 제공

---

• 콜센터 데이터 → (프로젝트에 의해) 부가적으로 생성한 데이터 / 각 기능 구별이 명확하게 되어야 함
• 콜센터 데이터는 더미데이터로 해도 충분
• STT X

질문(2/11)

1. 세부과업 중
   1. 상담 대화 내용과 상담 정보를 등록하고 조회할 수 있는 기능 구현
      1. 콜센터상 상담기록부터 구현해야하는건지
      → 콜센터 시스템에서 상담기록을 저장하게되면 실시간으로 요약/분석시스템으로 데이터를 바로 가져오거나 할 수 있음→ 콜센터 시스템과는 독립적이지만 협업을 한다고 생각함
   2. → 콜센터 시스템의 데이터와 요약/분석시스템이 연계가 되는것을 의미하는것

강사님 답변

콜센터 시스템 ≠ 우리 시스템

실시간 상담하는 동안 상담하는 동안은 콜센터를 쓰고, 우리 시스템은 안 쓴다. 상담 내용을 실시간으로 저장하고 하는 건 콜센터의 기능이고, 콜센터 쪽에서 관리되고 있는 내용들이 우리 시스템으로 넘어오는 것이다.

우리가 만드는 건 콜센터 시스템이 아니다. 콜센터와는 별개의 시스템을 만드는 것인데, 이미 있는 콜센터 시스템과 연계해서 실시간으로 좀 더 빠르게 뭔가 처리하는 인터페이스를 만드는 것이다.

"등록이 되야 되고 조회가 되야 한다"의 의미:

• 콜센터에서 인터페이스를 통해 저장하게 되면, 그 저장하는 것에 맞춰서 실시간으로 우리 쪽으로 이벤트가 전달됨
• 우리는 그 이벤트를 통해 콜센터에 저장된 내용을 바로 가져와서 조회할 수 있는 것
• 반드시 이런 표현은 아니고, 콜센터 상담원이 누를 때 우리 시스템으로 들어와야 된다

콜센터와는 독립적이지만, 콜센터 시스템과의 협업을 통해서 연계하는 것이다.

---

요약하면, 우리는 콜센터를 만드는 게 아니라 콜센터에서 상담이 끝나면 그 데이터를 받아서 관리/분석/검색하는 별도 시스템을 만드는 거예요. "등록"은 콜센터에서 이벤트로 넘어오는 데이터를 우리 시스템에 저장하는 것이고, "조회"는 그걸 우리 시스템에서 보는 것이라는 뜻입니다.

1. 4조 주제에 대한 질문과 답변 중
   • 기록을 관리하는것이라고 하면 기본 저장/조회
     • 너무 범위가 적은거 아닌지
     → 콜센터는 아니다→ 데이터를 활용하는 기능까지는 필요 없지만 분석 가능한 상태로는 만들어야함→ 여러 관점으로 데이터 처리 가능해야 & 킥 포인트가 있어야 함
   • → 의미 있는 활동을 할 수 있다는 것을 보여주는 화면을 부가적으로 구현하면 됨
   • → 상담 데이터(다량) 고객의 소리를 단순히 저장하는게 아니고 다양한 관점으로 정제하여 의미 있는 데이터를 만들어야

 

강사님 답변

핵심은 "콜센터의 1차 데이터를 더 의미 있는 데이터로 만드는 것"이다.

콜센터의 일차원적인 데이터를 조금 더 의미 있는 데이터로 만들 수 있느냐가 포인트다. 우리가 만들어 낸 결과적으로 데이터밖에 없잖아요.

데이터를 가지고 실제로 뭔가 이 데이터가 유의미한 것들을 우리가 좀 보여줘야 된다.

그 결과물이 쓰이는 곳은 다양할 수 있다:

• 상담원이 우리 시스템이 없었을 때는 이런 화면만 보고 일했겠지만, 우리가 분류하고 분석한 결과 때문에 콜센터 화면에 이런 게 추가되어서 상담을 더 잘할 수 있다거나
• 다른 부서(마케팅 등)에서 콜센터와 관련된 데이터를 가지고 고객의 소리를 분석하는 데 도움을 줄 수 있다거나

단, 이런 다양한 화면들은 부가적으로 필요할 수도 있겠지만, 그것이 핵심은 아니라는 것을 답변에서 하고 있습니다.

---

정리하면 강사님이 말씀하시는 프로젝트 핵심은 **"콜센터 원천 데이터 → 의미 있는 데이터로 가공 → 유의미한 결과를 보여주는 것"**이고, 화면이나 부가 기능은 그 결과물을 보여주는 수단일 뿐 핵심이 아니라는 거예요.

 

상담 내용을 분리해서 저장하는 것에 대해

• RDBMS와 NoSQL는 별개의 데이터인 경우 주로 구별하여 저장함
  • RDBMS와 NoSQL을 연결하고 어떻게 책임질것인지(어플리케이션에서 책임 등) 고려해야함
  • MongoDB 비정형을 다루기는 편리함
  • MySQL varchar, text 사용하면 가변 텍스트 사용으로도 충분

개발 환경

• 인프라
  • 로컬호스트 - git repository - amazon 서버 CI/CD 구축
  • DB 서버 공유
• 개발 표준
  • IDE 호환
  • 개발 표준
• 협업
  • github 운영 규칙
  • branch 및 pr 전략
  • commit 메시지 구격화
• 회의 구조
  • 전체회의는 최대한 줄이고 파트별 회의를 이용
  • 회의 결과, 필요한 공유는 반드시 공유 문서를 이용
• 문서 관리
  • Single Source Of Truth 원칙 - 문서는 최소화, 응집화
  • resource id 화 소통 (요구사항 ID, 화면 ID, REST API ID, ...)
• 근태
  • 지각, 근태 이탈 미공유 등 벌칙 ( 노래부르기, 벌금 천원 등 )
  • 인원 비상 부재 대안 마련
• 진척 관리
  • WBS or Jira
  • Daily
• 역할 분담
  • 1인 1역할 보다 2인 2역할
• 소회의실 활용
  • 부분 이슈는 관련자만 소회의실로 이동 진행

<강사님 피드백>

1. AWS 배포 및 인프라

• 로컬호스트 개발 후 어느 시점에 AWS에 배포하게 될 텐데, 처음부터 AWS 배포 세팅 + CI/CD까지 구축하는 방법도 있음
• 최소한 기타 미파지토리(repository)까지는 전부 동일하게 세팅해두고, AWS 연결은 나중에 해도 됨
• 개인적으로는 AWS도 가볍게 서버 하나 만들어서 CI/CD로 배포까지 구축해놓는 것을 권장
• 로컬호스트로만 유지하는 건 너무 오래 끌지 말 것

2. DB 서버

• 공유 DB 서버 사용을 권장
• JPA를 쓰면 repository 쪽 DB 코드가 자주 변경되어 충돌이 많아짐
• 로컬 DB로 각자 개발하다 합치면 일정 기간 뒤 문제가 생기는 걸 많이 목격함

3. 개발 도구 및 표준

• Docker 사용 여부는 자유지만, 각자 쓰는 개발 도구 때문에 Repository에서 쓸데없는 충돌이 생기지 않도록 할 것
• 개발 표준을 최소한으로 유지하여 품질 같은 부분을 관리할 수 있도록 할 것

4. 협업 방식

• 종합 프로젝트이니 협업에 대해 잘 정리해볼 것
• 전체회의는 최대한 줄이고, 실전에서는 연단계(기획 단계)에서만 다 같이 하면 됨
• 각자 역할이 정해지면 파트별 회의를 하고, 관련자들만 소인지를 이용할 것
• 회의 결과 공유가 필요하면 반드시 문서로 할 것 (구두, 휘발성 매체 의존 금지)

5. 문서화 원칙

• 문서에 기록하지 않으면 아무 의미가 없음 — 실제 프로젝트에서는 무조건 문서로 함
• 문서도 코드처럼 Single Source of Truth 원칙 준수: 같은 내용이 A 문서, B 문서에 흩어지면 업데이트할 때 두 곳 다 해야 하고 오해가 생김
• 주제별로 분리된 문서를 임팩트 있게 만들고, 한 곳에 정리를 명확하게 해둘 것

6. ID 체계 및 소통

• 리소스 아이디를 최대한 사용할 것 — 요구사항에도 ID 부여, 화면에도 ID 부여, REST API 엔드포인트에도 ID 부여
• 문서 작성 시 "무슨무슨 기능"이라고 두리뭉실하게 쓰지 말고, 요구사항 ID 몇 번, 화면 ID 몇 번 식으로 명확하게 텍스트로 소통할 것
• ID를 활용한 문서 기반 소통이 실제 프로젝트의 방식

7. 기타 당부

• 문제가 생기면 사전에 공유해줄 것
  
  

2월20일 추가 회의 관련 회의록

1. 배치 주기 및 실시간성 검토

• 핵심 쟁점: 상담 요약 및 분석 데이터의 업데이트 주기 결정
  • 방안 1 (하루 주기): 시스템 부하가 적고 안정적이지만, 당일 데이터 검색이 불가능함.
  • 방안 2 (단건/실시간): 즉각적인 검색을 지원하나, 서버 부하와 비용(AI API)이 증가함.
• 멘토링 질문 사항: * "상담 종료 즉시 검색이 필요한 도메인인가?" vs "하루 단위 통계 중심인가?"에 대한 실무적 조언 구하기.
  • 분석은 배치로 하되(상담후-배치), 검색 인덱싱만 실시간으로 처리(상담중-즉시 반영) 하이브리드 방식 검토

<상담사UI>

• 추가기능 ) 상담 결과서 기록 기능 - 상담사가 작성하는 화면
• 콜센터 기능

<개발자 UI는 없음 & api로 트리커 시킴>

→ (필요할 때마다 트리거) 검색 인덱싱 사전 업데이트 — 사전만 업데이트

개발자가 작성하는 영역 > 사용자 변경?

• LG U+ > 요금제 개편: 사전을 미리 준비, 언제부터 적용할것인지
• 사전 변경후 별도로 개발팀이나 … 알아서 트리거하여 반영

2. 데이터베이스 및 분석 로직(배치로직1)

• 분석 상태 관리: 상담 분석 상태 관리 테이블(consultation_analysis_status) 구현
• 해지/방어 분석 테이블: AI가 추출한 해지 의사, 방어 시도, 성공 여부 데이터를 담을 전용 테이블(retention_analysis) MySQL에 구축.

3. 키워드 추출 (상담사 성과 지표 측정)

1. 상담 원문 —> 키워드 추출
2. IAM —> 키워드 추출
3. 키워드 비교(일치율 & 요약 품질 검증)
   • 상담 원문의 주요 키워드 vs 상담사가 작성한 IAM 메모 키워드 비교.
   • 두 데이터 간의 차이를 통해 요약의 정확도 및 상담사의 숙련도 측정 지표로 활용.

3. 서버 아키텍처 (서버 분리)

• 결정 사항: 배치 서버와 관리용 컨트롤러(프론트 모듈) 서버 분리 권장.
• 이유: * 배치 작업 시 대량의 CPU 코어 점유로 인한 사용자 서비스 성능 저하 방지.
  • 배포 시 배치 작업 중단 위험 최소화 및 각 모듈별 유연한 확장성 확보.

4. 검색 및 인덱싱 전략(배치로직2)

• 키워드 설정: 개발자가 사전 정의한 키워드를 바탕으로 인덱싱 진행.
• 재인덱싱(Re-indexing) 로직: * 키워드 사전이 변경될 경우, 과거 데이터를 새로운 키워드로 다시 인덱싱하는 심야 배치 로직 필요.
  • 시스템 부하가 가장 적은 시간대(새벽)에 전체 혹은 증분 재인덱싱 수행.

5. 기능 제외 및 컨택 사항

• 인수인계 히스토리: 일반적인 콜센터 업무 범위로 판단되어 프로젝트 범위에서 제외 고려.
• 확인 필요: 하람 님께 해당 기능 제외 여부 최종 확인 후 노션 반영 예정.인수인계 구현x —> 인수인계를 하는 기능(버튼) + 인수인계 기록하는 테이블(히스토리 테이블) 둘다 삭제.
• 상담결과서 - 컬럼 상태(이관됨)
• 결론,

---

2/21(토) 회의 사항

아래 테이블 고려

인수인계 관련 테이블 삭제 + 기능 제거 —> 상담결과서에 컬럼만 남기기로.

• 인수인계 히스토리: 일반적인 콜센터 업무 범위로 판단되어 프로젝트 범위에서 제외 고려.
• 확인 필요: 하람 님께 해당 기능 제외 여부 최종 확인 후 노션 반영 예정.인수인계 구현x —> 인수인계를 하는 기능(버튼) + 인수인계 기록하는 테이블(히스토리 테이블) 둘다 삭제.
• 상담결과서 - 컬럼 상태(이관됨)
• 결론,FE관련
  • 관리자 페이지 : 관리자가 메인 기능을 관리(수정 조회 등록 등)을 수행
  • 상담사 페이지 : 관리자가 수정한 결과를 확인하는 용도(상담 등록x)
  • —> 위 내용을 기준으로, API 문서 작성하기

부서 관련

회의록(2/22)

1. 백엔드 서버 2개
   • 배치 서버
   • API 모듈 서버
2. swagger, zookeeper(kafka) 등 필요한 인프라 —> docker 설정 완료
3. (노션) 기능 별 ERD(mysql) MYSQL ERD
   • 테이블 몇 개 수정 및 삭제(공통 코드 등)
   • 테이블 이름 옆, 빨간 색으로 표시된 부분 = 테이블 구조 변경 가능성 o→ 구글 공유 문서함(excel sheet) —> “테이블 정의서 양식(수정)-테이블 목록(최종)페이지 - 확정 컬럼 체크 X”
   • —> 팀별로 자체적으로 수정 가능 & 수정 이후 공지 필요 git pr 혹은 discord로
   • 테이블 이름 옆, 빨간 색으로 표시되지 않은 부분 = 테이블 구조(컬럼) 변경 가능성 x
   • → 구글 공유 문서함(excel sheet) —> “테이블 정의서 양식(수정)-테이블 목록(최종)페이지 - 확정 컬럼 체크 O”
4. 구글 공유 문서함(excel sheet)→ 테이블 마다 인덱스 설정 x → 기능구현 담당 팀별로 회의하고, 각 팀별로 인덱스 추가하는 것으로!
5. +_인덱스를 많이 추가하는 것이 좋은 것은 아님 (성능 저하) & 꼭 필요한 부분에만 추가하기로!
6. -> “테이블 정의서 양식(수정)” 페이지를 기반으로 테이블 매핑 거의 완료
7. 깃헙 pr 템플릿 및 깃헙 협업규칙 정의→ 깃헙 협업 규칙 : 각 레포의 README에 나와있음
8. → pr 템플릿 꼼꼼하게 읽어보기
9. 대충 구상한 아키텍처 구조도
10.  

 

저번주까지 진행해서 완결된 기능 명세서 및 db 관련

 

로그인 및 권한

리프레시 토큰 (refresh_token)

로그인/세션 등을 위해 필요

Unique 제약조건 : refresh_token(기기별 멀티 로그인을 허용x)

컬럼명 논리명 타입 제약조건 nullable 설명

refresh_token_id	토큰 아이디	INT	PK, AI	x	식별자
emp_id	직원 아이디	INT	FK	x	employees.emp_id 참조
refresh_token	리프레시 토큰 값	VARCHAR(255)	UK	x	값 지정 필요
expired_at	만료시간	DATETIME	INDEX	x	만료된 토큰 삭제하는 배치 작업 고려
created_at	생성일	DATETIME		x

공통 권한 코드(permissions)

모든 기능별 권한을 정의

검색 - 시스템, 고객

삽입 - 데이터

SEARCH_SYS - api

SEARCH_LOG

컬럼명 논리명 타입 제약조건 nullable 설명

perm_id	권한 아이디	INT	PK, AI	x	식별자
perm_code	권한 코드명	VARCHAR(100)	UK	x	’ORDER_CREATE’ 등
perm_desc	권한 설명	TEXT
is_deleted	삭제 유무	TINYINT(1)	DEFAULT(0)		삭제 : 1

부서 단위 권한(dept_permissions)

부서 전체에 해당하는 권한(해당 부서원 전체에게 적용)

INDEX : dept_id + perm_id

컬럼명 논리명 타입 제약조건 nullable 설명

id	ID	INT	PK, AI	x	식별자
dept_id	부서 아이디	INT	FK	x	departments.dept_id 참조
perm_id	권한 아이디	INT	FK	x	permissions.perm_id 참조
assigned_at	권한 부여일	DATETIME
is_deleted	권한 삭제유무	TINYINT(1)	default(0)		삭제: 1

개별 권한(emp_permissions)

부서 단위로 허용되는 권한과 별도로, 개별 개인에게 추가로 허용하는 권한(특별 지정)

INDEX : emp_id + perm_id

컬럼명 논리명 타입 제약조건 nullable 설명

id	ID	INT	PK, AI	x	식별자
emp_id	직원 아이디	INT	FK	x	employees.emp_id 참조
perm_id	권한 아이디	INT	FK	x	permissions.perm_id 참조
assigned_at	권한 부여일	DATETIME
is_deleted	권한 삭제유무	TINYINT(1)	default(0)		1:삭제

필터 & 통합검색

• 검색 API 예시
  • filter_key
    • keyword
    • selected
    • etc
    • order
  • filter_value
    • 각 키에 연결된 값
• http://api/search?keyword=키워드&selected=1,2,3,4,5&ect=CODE&is_exist=false&order=title.desc,name.asc (GET)

필터*검색-조건값(filter) - 미확정(수정필요)_필터 대안 코드&필터키

모든 필터 항목들이 들어있는 원본

컬럼명 논리명 타입 제약조건 nullable 설명

filter_id	필터 아이디	INT	PK, AI	x	식별자
filter_key	필터 키	VARCHAR(50)	UK		공통에 없음
filter_alternative_code	필터 대안 코드	VARCHAR(50)			공통 코드에 없는 경우, 이 컬럼을 참조
filter_name	필터 이름	VARCHAR(50)		x	예: "상담 유형", "상담사 ID"
is_deleted	삭제유무	TINYINT(1)	default(0)		1: 삭제됨

미리 정의한 key값

filter_name (사람용) filter_key (시스템용) 비고

상담 상태	CONSULT_STATUS	공통 코드 그룹명과 일치시킴
상담 채널	CONTACT_CHANNEL	공통 코드 그룹명과 일치시킴
키워드 검색	FREE_KEYWORD	시스템 예약어 (공통 코드에 없음)
날짜 범위	CONSULT_DATE	시스템 예약어 (공통 코드에 없음)
상담사 검색	COUNSELOR_ID	시스템 예약어 (공통 코드에 없음)

커스텀 필터 즐겨찾기(filter_custom)

필터 그룹 안의 내용물 역할

상담사/관리자가 자주 쓰는 필터링 조건(재사용성)

복합 INDEX = filter_group_id

Unique key = filter_id + filter_group_id

컬럼명 논리명 타입 제약조건 nullable 설명

filter_custom_id	식별자	INT	PK, AI	x	식별자
filter_group_id	필터 그룹 아이디	INT	FK, Unique(1)	x	filter_groups.filter_group_id 참조
filter_id	속한 필터 아이디	INT	FK, Unique(2)	x	filter.filter_id 참조
created_at	생성일시	DATETIME
filter_value	필터 값	TEXT		x	[핵심] 사용자가 선택/입력한 값 (ex: "아이폰", "TERMINATE", "20260201-20260228")

필터 그룹 (filter_groups)

필터 그룹을 묶는 폴더 역할

컬럼명 논리명 타입 제약조건 nullable 설명

filter_group_id	그룹 아이디	INT	PK, AI	x	식별자
emp_id	생성 직원	INT	FK	x	Employees.emp_id 참조
group_name	그룹 이름	VARCHAR(100)		x	사용자가 지정한 그룹 명칭
sort_order	정렬순서	INT	DEFAULT(0)		사용자 화면에 노출될 순서
created_at	생성일시	DATETIME
is_deleted	삭제유무	TINYINT(1)	DEFAULT(0)		(1: 삭제됨, 0: 사용중)

직원

직원 신상 정보(employees)

직원 신상정보

컬럼명 논리명 타입 제약조건 nullable 설명

emp_id	직원 아이디	INT	PK, AI	x	시스템 전체에서 사용하는 식별자
login_id	로그인 아이디	VARCHAR(50)	UK	x	사번 혹은 사용자 ID
login_token	로그인 토큰	VARCHAR(225)		x
password	비밀번호	VARCHAR(255)		x	암호화 필요
name	이름	VARCHAR(30)		x
email	이메일	VARCHAR(100)		x
phone	전화번호	VARCHAR(20)
birth	생년월일	DATE			2000-10-21
gender	성별	VARCHAR(10)			male, female, other
is_active	계정 활성화 상태	TINYINT(1)	default(1)		1: 활성화 / 0:비활성화
created_at	생성일시	DATETIME	DEFAULT(now())	x

직원 업무 정보(employee_details)

d직원 운영데이터 - 상담사(consult), 관리자(admin), 다른 부서의 직원들(이관 가능성) 저장

컬럼명 논리명 타입 제약조건 nullable 설명

emp_id	직원 아이디	INT	PK, FK	x	employee.emp_id 참조
dept_id	부서 아이디	INT	FK	x	departments.dept_id 참조
job_role_id	직무 그룹 아이디	INT	FK	x	job_roles.job_role_id 참조
joined_at	입사일	DATE
updated_at	수정일시	DATETIME	on update now()

부서명(departments)

부서명 정의 - admin, consult, marketing, sale, account(회계), hr, legal, RnD 등등

컬럼명 논리명 타입 제약조건 nullable 설명

dept_id	부서 아이디	INT	PK, AI	x	식별자
dept_name	부서명	VARCHAR(30)		x
location	부서 위치	VARCHAR(225)
phone	부서 전화번호	VARCHAR(20)

역할군 그룹(job_roles)

직원의 역할(상담사, 관리자 등)을 정의

컬럼명 논리명 타입 제약조건 nullable 설명

job_role_id	직무 아이디	INT	PK, AI	x	식별자
role_name	직무 명칭	VARCHAR(50)		x	상담사, 관리자, 슈퍼관리자, 일반직원(다른부서)
role_desc	직무 설명	VARCHAR(200)			해당 직무 상세 설명
is_active	사용 여부	TINYINT(1)	default(1)		1: 사용

고객

고객 테이블(customers)

컬럼명 논리명 타입 제약조건 nullable 설명

customer_id	식별자	BIGINT	PK, AI	x	테이블 식별자
identification_num	고객 고유 번호/코드	VARCHAR(30)	UUID	x
name	고객 이름	VARCHAR(50)		x
customer_type	고객 유형	ENUM(’personal’, ‘corporate’)		x	개인 / 법인
gender	성별	VARCHAR(10)			comon_codes.code_val 참조
birth_date	생년월일	DATE		x	2000-10-21
grade_code	고객 등급	VARCHAR(20)	FK		customer_grade.grade_code 참조
preferred_contact	선호하는 연락 수단	VARCHAR(10)			call, email, push
email	이메일	VARCHAR(255)	UNIQUE
phone	전화번호	VARCHAR(20)
created_at	등록일	DATETIME		x

고객 등급(customer_grade) — 미확정(표시될 등급명 필요한지 아닌지, FE와 이야기 필요)

컬럼명 논리명 타입 제약조건 nullable 설명

grade_code	등급 코드	VARCHAR(20)	PK	x	’VVIP’, ‘VIP’, ‘DIAMOND’
grade_name	표시될 등급명	VARCHAR(20)		x	프레스티지, 일반 등
min_points	최소 가격	INT		x	등급을 책정하는 데에 필요한 금액
priority_level	응대순위	INT			숫자가 낮을수록 우선 배정
description	등급 상세 설명	TEXT

고객 위험 발생 히스토리(customer_risk_logs) — mongoDB 분석결과 이후 로우가 추가됨..?

위험 요소가 감지될 때마다 ‘새로운 로우가 추가됨(insert only)’

INDEX : customer_id + created_at ←———특정 고객의 변동추이 확인(로그성)

컬럼명 논리명 타입 제약조건 nullable 설명

log_id	로그 ID	BIGINT	PK,AI	x	고유 식별자
consult_id	상담 ID	BIGINT	FK	x	consultation_results.consult_id 참조
emp_id	상담사 ID	INT	FK	x	employees.emp_id 참조
customer_id	고객 ID	BIGINT	FK	x	고객 테이블 참조
type_code	위험 유형	VARCHAR(20)	FK	x	risk_type_policy.type_code 참조
level_code	판정된 등급	VARCHAR(20)	FK	x	risk_level_policy.level_code 참조
created_at	발생 일시	DATETIME	NOT NULL		로그가 기록된 시점

상담 운영

위험 등급 마스터 테이블(risk_level_policy)

LOW, HIGH 같은 등급의 명칭, 정렬 순서, 상담사에게 보여줄 지침 등을 정리한 정책 테이블

컬럼명 논리명 타입 제약조건 nullable 설명

level_code	등급 코드	VARCHAR(20)	PK	x	LOW, MEDIUM, HIGH, CRITICAL 등
level_name	등급명	VARCHAR(50)	NOT NULL	x	실무용 명칭(주의, 경고, 심각)
sort_order	정렬 순서	INT			등급의 높낮이 순서
description	등급 설명	TEXT			해당 등급의 정의 및 판정 기준

위험 유형 마스터 테이블(risk_type_policy)

CHURN, ABUSE 등의 위험 종류를 정의

컬럼명 논리명 타입 제약조건 nullable 설명

type_code	유형 코드	VARCHAR(20)	PK	x	ABUSE, CHURN, REPEAT 등
type_name	유형명	VARCHAR(50)	NOT NULL	x	폭언/욕설, 정책악용, 보상요구, 반복민원, 해지위험, 피싱피해
is_active	사용 여부	BOOLEAN	default(true)		더이상 사용하지 않는 코드 관리
applied_policy_id	적용될 지침 id	BIGINT	FK		customer_policy.policy_id 참조

고객 우대/제약 정책(customer_policy)- 내부 메뉴얼(관리자가 추가가능) — 미확정

** 내부 정책 표시/수정/삭제 & 해지방어 전략(mongoDB) 인사이트 도출 이후에 관리자가 수정 가능 **

** 고객 테이블과 연결관계x & 지침 정보 정도로만 작성 **

블랙리스트 관리나 VIP전담 배정 등 고객별 맞춤 정책 관리

customer_policy는 ‘대응 지침’

INDEX : customer_id + is_enabled ← 특정 고객에게 현재 활성화된 우대/제약 정책 조회created_at

컬럼명 논리명 타입 제약조건 Nullable 설명

policy_id	정책 ID	BIGINT	PK, AI	x
emp_id	관리자 ID	INT	FK	x	정책을 등록한 관리자 ID 명시
policy_type	정책 유형	VARCHAR(30)		x	진상방지, 고객 우대 등
config_json	정책 상세	JSON		x	정책 적용 상세 사유 및 설정
is_deleted	활성 여부	TINYINT(1)	DEFAULT(1)	x
created_at	생성 일시	DATETIME	TIMESTAMP(now())	x
updated_at	수정 일시	DATETIME	on update now()		다른 관리자가 기존의 정책을 수정한 시점

사내 전체공지(notice)

내부 공지 게시글(관리자 작성)

특정 업무/이슈 공지

INDEX : status + is_pinned DESC + visible_from DESC ← 상단고정&최신순 전체공지 조회

컬럼명 논리명 타입 제약조건 Nullable 설명

notice_id	공지 ID	INT	PK, AI	x
title	제목	VARCHAR(200)		x
content	본문	TEXT		x
emp_id	관리자 ID	INT	FK	x	employees.emp_id 참조
is_pinned	상단 고정	TINYINT(1)	DEFAULT(0)	x	1: 고정
view_count	조회수	INT	DEFAULT(0)	x
status	상태	ENUM	default(’draft’)	x	DRAFT(임시저장), SCHEDULED(예약 게시), ACTIVE(게시중), ARCHIVED(게시종료), DELETED(삭제)
created_at	생성 일시	DATETIME		x
visible_from	노출 시작	DATETIME			예약 게시 가능
visible_to	노출 종료	DATETIME			특정 기간만 공지할 경우

상품

인터넷/TV 상품(product_home)

인터넷, IPTV, 스마트홈 등의 상품

컬럼명 논리명 타입 제약조건 Nullable 설명

product_code	상품 코드	VARCHAR(30)	PK	x	NET-100M, TV-BASIC 등
category	상품 분류	VARCHAR(20)		x	인터넷, IPTV, 결합상품(세트), 스마트홈 등
product_name	상품명	VARCHAR(100)		x	U+인터넷 100M 등
monthly_fee	월정액	INT		x	월 이용료 (원)
speed_limit	최대 속도	VARCHAR(20)			100Mbps, 1Gbps 등 (해당 시)
contract_period	약정 기간	VARCHAR(10)			3년 등
description	비고/설명	TEXT			상품 상세 특징 및 혜택
결합할인인 경우 ‘[세트상품]’ 텍스트가 포함되어야 함

모바일 상품(product_mobile)

데이터, 음성, 문자, 멤버십

컬럼명 논리명 타입 제약조건 Nullable 설명

product_code	상품코드	VARCHAR(30)	PK	x	MOB-5G-SIG, MOB-NGT-01 등
category	분류	VARCHAR
plan_name	요금제명	VARCHAR(100)		x	5G 시그니처, 유쓰 스탠다드 등
monthly_fee	월정액	INT		x	공시가 (원)
contract_fee	선택약정가	INT			25% 할인 적용가 (원)
data_amount	데이터 제공량	VARCHAR(20)		x	무제한, 150GB, 1GB 등
qos_speed	소진 후 속도	VARCHAR(20)			속도제한 없음, 5Mbps, 400Kbps 등
voice	음성	VARCHAR(20)		x	무제한, 집/이동전화 무제한 등
sms	문자	VARCHAR(20)		x	무제한 등
sharing_data	테더링/공유	VARCHAR(20)			120GB, 10GB 등 공유 데이터 양
benefits	부가혜택	VARCHAR			VVIP멤버십, 영화 혜택 등
target_group	가입 대상	VARCHAR(30)		x	일반, 만 34세 이하, 군인, 실버 등
description	상세 설명	TEXT			요금제 특징 요약

부가 서비스 상품(product_additional)

영상, 데이터, 로밍 등 모바일 부수 서비스

consult_transfer_history

컬럼명 논리명 타입 제약조건 Nullable 설명

service_code	서비스 코드	VARCHAR(30)	PK	x	ADD-MTVI, ADD-ROAM-3G 등
category	분류	VARCHAR(20)		x	영상, 데이터, 로밍, 안심/안전 등
service_name	서비스명	VARCHAR(100)		x	티빙, 데이터 쉐어링 등
monthly_fee	월정액	INT		x	이용료 (0원 포함)
description	서비스 설명	TEXT			서비스 혜택 및 가입 조건 상세

고객 구독중인 부가서비스(customer_subscriptions_additional)

고객별 부가서비스 가입 현황을 별도로 분리하여 관리

컬럼명 논리명 타입 제약조건 Nullable 설명

subscription_id	구독 식별자	BIGINT	PK, AI	x	구독 이력 고유 ID
contract_id	통합 계약 ID	BIGINT	INDEX, FK		결합상품 등 묶기 위한 ID
customer_contracts.contract_id 참조
customer_id	고객 식별자	BIGINT	FK, INDEX	x	customers.customer_id참조
service_code	서비스 식별자	VARCHAR(30)	FK	x	product_additional.service_code 참조
join_date	가입일시	DATETIME		x	서비스 가입 시점
extinguish_date	해지일시	DATETIME			서비스 해지 시점 (미해지 시 NULL)

고객이 구독중인 모바일 상품(customer_subscription_mobile)

컬럼명 논리명 타입 제약조건 Nullable 설명

asset_id	자산 식별자	BIGINT	PK, AI	x	자산 고유 식별자
contract_id	통합 계약 ID	BIGINT	FK		customer_contracts.contract_id 참조
mobile_plan_code	모바일 상품 코드	VARCHAR(30)	FK	x	product_mobile.plan_code 참조
joined_at	가입/개통일	DATETIME		x	해당 상품 개통 일시
extinguish_at	해지일	DATETIME			해당 상품 해지 일시

고객이 구독중인 인터넷/TV 상품(customer_subscription_home)

컬럼명 논리명 타입 제약조건 Nullable 설명

asset_id	자산 식별자	BIGINT	PK, AI	x	자산 고유 식별자
contract_id	통합 계약 ID	BIGINT	FK		customer_contracts.contract_id 참조
home_product_code	홈 상품 코드	VARCHAR(30)	FK	x	product_home.product_code 참조
joined_at	가입/개통일	DATETIME		x	해당 상품 개통 일시
extinguish_at	해지일	DATETIME			해당 상품 해지 일시

고객 계약 결합상품 정의(customer_contracts)

어떤 결합 할인이 적용될 지 정의

컬럼명 논리명 타입 제약조건 Nullable 설명

contract_id	통합 계약 ID	BIGINT	PK, AI	x	계약 고유 식별자
customer_id	고객 식별자	BIGINT	FK	x	customers.customer_id 참조
combo_code	적용 결합 코드	VARCHAR(30)	FK		combination_discount.combo_code 참조
created_at	계약 생성일	DATETIME		x	최초 계약 체결 시점
updated_at	변경 일시	DATETIME		x	결합 구성 변경 등 최종 수정일
extinguish_at	해지일	DATETIME			해당 상품 해지 일시

결합할인 혜택 정보(combination_discount)

결합 조건과 할인혜택

컬럼명 논리명 타입 제약조건 Nullable 설명

combo_code	결합 코드	VARCHAR(30)	PK	x	BND-TOGETHER, BND-FMLY-01 등
combo_name	결합 상품명	VARCHAR(100)		x	U+투게더 결합, 참 쉬운 가족결합 등
composition	결합 구성	VARCHAR(200)		x	모바일 + 인터넷 등 결합 대상
max_discount	최대 할인액	INT		x	월 최대 할인 금액 (원)
max_lines	최대 회선	VARCHAR(50)			모바일5 + 인터넷5 등 제한 수
description	비고	TEXT			결합 혜택 상세 설명

상담 시 발생한 변경 내역(consult_product_logs)

컬럼명 논리명 타입 제약조건 Nullable 설명

log_id	테이블 식별자	int	PK,AI	x	로그식별자
consult_id	상담결과서 id	BIGINT	fk	x	어떤 상담결과와 연결되는지
customer_id	고객 id	BIGINT	fk	x	customers.customer_id 참조
created_at	생성일	DATETIME	Default Now
product_type	상품 타입	VARCHAR(20)		x	mobile, home, additional
new_product_home	새로 가입한 홈 상품	VARCHAR(30)	FK		product_home.product_code 참조
new_product_mobile	새로 가입한 모바일 상품	VARCHAR(30)	FK		product_mobile.product_code 참조
new_product_service	새로 가입한 부가 서비스 상품	VARCHAR(30)	FK		product_additional.service_code 참조
canceled_product_home	해지한 홈 상품	VARCHAR(30)	FK		product_home.product_code 참조
canceled_product_mobile	해지한 모바일 상품	VARCHAR(30)	FK		product_mobile.product_code 참조
canceled_product_service	해지한 부가 서비스 상품	VARCHAR(30)	FK		product_additional.service_code 참조

상담

상담 카테고리 정책(consultation_category_policy)

컬럼명 논리명 타입 제약조건 nullable 설명

category_code	분류코드	VARCHAR(20)	PK	x	M-FEE-01, M-TRB-01 등
large_category	대분류	VARCHAR(50)		x	요금/납부, 기기변경 등
medium_category	중분류	VARCHAR(50)		x	요금제 변경, 미납안내 등
small_category	소분류	VARCHAR(50)		x	5G 요금제 안내, 속도 저하 등
is_active	사용 여부	TINYINT(1)	default(1)	x	1: 사용 / 0: 미사용
sort_order	노출 순서	INT	default(0)		상담 화면 선택창에서의 정렬 순서

상담 원문(consultation_raw_texts)

텍스트로 변환된 상담 원본 데이터

컬럼명 논리명 타입 제약조건 Nullable 설명

raw_id	원문 식별자	BIGINT	PK, AI	x	식별자
consult_id	상담 식별자	BIGINT	FK	x	consultation_records.consult_id 참조
raw_text_json	대화 원문 JSON	JSON		x	화자별 발화 내용 및 타임스탬프
created_date	생성 일시	DATETIME			원문이 생성된 시기

상담 결과서(consultation_results) — 추후 컬럼이 추가될 수도…?(미확정)

상담의 발생 기록 : consultation_records ←→ 상담 종료 후 확정된 최종 리포트(consultation_results)

INDEX : created_at + duration_sec ← 지난달 평균 상담시간 통계

INDEX : group_id ← 이관이 여러 번 일어난 전체 상담 시퀀스를 조회

데이터가 입력되는 로직(예시)

첫 번째 상담 (ID: 1): refer_id = NULL / group_id = 1 ->처리 종료or이관

두 번째 상담 (ID: 2, 1번에서 이관됨): refer_id = 1 / group_id = 1

세 번째 상담 (ID: 3, 2번에서 이관됨): refer_id = 2 / group_id = 1

컬럼명 논리명 타입 제약조건 Nullable 설명

consult_id	상담 식별자	BIGINT	PK	x	식별자
emp_id	직원 아이디(상담사 or 이관부서의 직원)	INT	FK	x	employees.emp_id 참조
customer_id	고객 아이디	BIGINT	FK	x	customer.customer_id 참조
category_code	상담 카테고리	VARCHAR(20)	FK	x	consultation_category_policy.category_code 참조
duration_sec	상담 소요 시간	INT		x	초 단위 (end_at - start_at)
consult_round	상담 차수	INT	DEFAULT 1	x	동일 건에 대한 재통화 횟수
iam_issue	[I] 상담 메모	TEXT			[I]ssue: 고객 문의 핵심 요약
iam_action	[A] 조치 사항	TEXT			[A]ction: 상담사 조치 및 안내
iam_memo	[M] 특이 사항	TEXT			[M]emo: 고객 성향 등 특이점
is_transferred	이관 여부	TINYINT(1)	DEFAULT 0	x	이관 이력이 존재하는지 여부
refer_id	직전 상담 ID	BIGINT	self-join FK		consultation_results(consult_id) 참조
group_id	원본 상담 ID	BIGINT	self-join FK, INDEX	x	consultation_results(consult_id) 참조 (최초 상담 ID)
created_at	생성일시	DATETIME	INDEX	x	리포트 확정 시점 (파티셔닝 기준)
contact	연락 수단	VARCHAR(20)	FK	x	common_codes.code_val 참조

상담 분석 상태 관리 테이블(consultation_analysis_status) - 배치제어용 —미확정

컬럼명 논리명 타입 제약조건 설명

consult_id	상담 식별자	BIGINT	PK, FK	consultation_results.consult_id 참조
analysis_status	분석 상태	VARCHAR(20)	NOT NULL	PENDING(대기), COMPLETED(완료), FAILED(실패)
keyword_match_rate	키워드 일치율	DECIMAL(5,2)	DEFAULT 0	1차 필터링 시 계산된 점수 (0~100)
error_msg	에러 메시지	TEXT	Nullable	배치 실패 시 원인 기록
last_run_at	최근 실행 시각	DATETIME	Nullable	배치가 마지막으로 시도된 시간
updated_at	수정 일시	DATETIME	NOT NULL	상태 변경 시 자동 갱신

AI 해지/방어 분석 결과 (retention_analysis) —미확정

컬럼명 논리명 타입 제약조건 설명

consult_id	상담 식별자	BIGINT	PK, FK	consultation_results.consult_id 참조
has_intent	해지 의사 여부	TINYINT(1)	NOT NULL	고객의 해지 의사가 감지되었는지 (Y:1/N:0)
defense_attempted	방어 시도 여부	TINYINT(1)	NOT NULL	상담사가 방어 액션을 수행했는지 (Y:1/N:0)
defense_success	방어 성공 여부	TINYINT(1)	NOT NULL	결과적으로 해지를 철회했는지 (Y:1/N:0)
defense_actions	방어 액션 유형	JSON	Nullable	사용된 방어 기법 리스트 (예: ["할인", "사은품"])
created_at	생성 일시	DATETIME	NOT NULL	분석 결과가 저장된 시간

상담 종료 후 고객 만족도(client_review)

컬럼명 논리명 타입 제약조건 Nullable 설명

review_id	식별자	BIGINT	PK	x	식별자
consult_id	상담 결과서 id	BIGINT	FK	x	consultation_results. consult_id 참조
score_1	1번 항목 점수	TINYINT(1)			각 질문에 대한 점수
score_2	2번 항목 점수	TINYINT(1)			각 질문에 대한 점수
score_3	3번 항목 점수	TINYINT(1)			각 질문에 대한 점수
score_4	4번 항목 점수	TINYINT(1)			각 질문에 대한 점수
score_5	5번 항목 점수	TINYINT(1)			각 질문에 대한 점수
personal_answer	주관식	json			6번 항목에 대한 사용자의 주관식 답변
created_at	생성일시	DATETIME

질문 항목 5가지

1. 전반적인 만족도: 오늘 받으신 상담 서비스에 대해 전반적으로 얼마나 만족하시나요?
2. 상담사의 친절도: 상담사가 고객님의 의견을 경청하고 친절하게 응대하였나요?
3. 정보의 정확성 및 전문성: 상담사가 제공한 답변은 이해하기 쉽고 전문적이었나요?
4. 처리 속도 및 신속성: 상담 연결 및 문의 사항에 대한 처리 과정이 신속했나요?
5. 문제 해결 및 유용성: 제공된 상담이 고객님의 문제를 해결하거나 궁금증을 해소하는 데 도움이 되었나요?
6. 추가로 남기실 말씀이 있을까요? ← elastic & ai 활용해서 인사이트 도출할 수도..?

AI분석 —> 유사 메뉴얼 및 대응 가이드(manuals) — 변경가능(미확정)

—> 관리자가 직접 “상담 분석 결과 확인 → 메뉴얼 수정”하는 하드코딩은 의미가 없어보임..

—> “해지 방어& 상담사 위협” 키워드 추출 —> AI —> 분석결과 —> “메뉴얼&대응 가이드” 로우 생성

대응 메뉴얼 업데이트(ai기반 분석 내용+통계 활용) ← 가장 고객의 만족도 + 해결 성공률이 높았던 메뉴얼로 업데이트

컬럼명 논리명 타입 제약조건 Nullable 설명

manual_id	매뉴얼 ID	INT	PK, AI	x
type_code	유형 코드	VARCHAR(20)	FK	x	ABUSE, CHURN, REPEAT 등
title	제목	VARCHAR(200)		x
content	상세 내용	LONGTEXT or json		x	마크다운 또는 HTML 형식 지원
is_active	활성화 여부	TINYINT(1)	DEFAULT 1	x	1: 사용중, 0: 미사용
updated_at	최종 수정일	DATETIME	ON UPDATE NOW()	x

상담 내 제안이력(suggestion_history) — 추후 확장(현재x)미확정

시스템이 추천한 메뉴얼을, 상담사가 얼마나 수용했는 지 기록

INDEX : manual_id + is_accepted ← 어떤 메뉴얼이 가장 많이 채택되었는 지 확인

INDEX : consult_id ← 상담 상세화면에서 해당 상담 중 제안되었던 목록 불러오기

컬럼명 논리명 타입 제약조건 Nullable 설명

suggestion_id	제안 ID	BIGINT	PK, AI	x
consult_id	상담 ID	BIGINT	FK	x	consultation_records.consult_id 참조
manual_id	매뉴얼 ID	INT	FK	x	manuals.manual_id 참조
suggestion_type	제안 종류	VARCHAR(20)		x	CHURN_PREVENTION, UPSELLING 등
is_accepted	채택 여부	TINYINT(1)		x	상담사가 클릭/적용 했는지 여부
created_at	제안 시점	DATETIME		x

시스템 운영

상담사/관리자 감사로그(audit_logs) ← 슈퍼 관리자가 조회가능 — 확장<보류>미확정

보안 관리를 위해, 관리자의 민감 행위(조회, 수정, 삭제)를 모두 기록

INDEX : emp_id + created_at DESC ← 특정 관리자가 오늘 수행한 작업 목록 조회

INDEX : target_table + target_id ← 특정 상담 기록이 누구에 의해 삭제되었는 지 조회

컬럼명 논리명 타입 제약조건 Nullable 설명

log_id	로그 식별자	BIGINT	PK, AI	x
emp_id	수행 관리자 ID	INT	FK	x	employees.emp_id 참조 (행위자)
action_type	행위 구분	VARCHAR(20)		x	VIEW, UPDATE, DELETE, EXCEL_DOWN
target_table	대상 테이블	VARCHAR(50)		x	예: consultation_records
target_id	대상 레코드 ID	VARCHAR(50)			영향을 받은 행의 PK(문자열 PK도 허용)
reason	수행 사유	TEXT		x	(필수) 행위의 정당성 근거
ip_address	접속 IP	VARCHAR(45)		x	접속 기기 IP 주소
created_at	기록 시각	DATETIME	INDEX	x

• 일단 배제(생성하지 않기로)비동기 작업 이력(async_tasks) — 비동기작업 + “쓰는 로직” - 추후 확장 고려(spring batch meta table 사용고려하면, 필요 없을 수도?)컬럼명 논리명 타입 제약조건 Nullable 설명

  task_id	작업 식별자	BIGINT	PK, AI	x	작업 고유 ID
  task_type	작업 유형	VARCHAR(50)	INDEX	x	KEYWORD_EXTRACT, ES_INDEXING 등
  status	진행 상태	VARCHAR(20)	INDEX	x	ready, running, completed, failed
  request_params	요청 파라미터	JSON			재시도 및 추적용 입력값
  result_summary	결과 요약	TEXT			성공 요약 또는 에러 메시지
  process_result	처리 결과	TINYINT(1)			비동기 작업 처리 결과(성공:true)
  worker_node	수행 서버	VARCHAR(50)			작업을 수행한 서버 ID
  started_at	시작 시각	DATETIME			실제 작업 시작 시각
  ended_at	종료 시각	DATETIME			작업 완료 시각

  공통 코드 없앰

  공통 코드 관리(common_codes)복합키 : group_code + code_val컬럼명 논리명 타입 제약조건 Nullable 설명

  code_id	코드 식별자	INT	PK, Auto increase
  group_code	그룹 코드	VARCHAR(50)	Unique(group_code, code_val)	x	필드명 (status, channel_type 등)
  code_val	코드값	VARCHAR(50)	Unique(group_code, code_val)	x	’pending’,’processing’, ‘complete’, ‘call’, ‘email’, ‘push’, ,’active’, ‘inactive’, ‘blocked’, ‘chat_log’, ‘summary’, ‘grant’, deny’, ‘requested’, ‘accepted’, ‘rejected’, ‘completed’,’ready’, ‘running’, ‘completed’, ‘failed’, ‘male’, ‘female’, ‘other’,’active’, ‘suspended’, ‘terminated’, ‘ready’, ‘expired’
  code_name	코드 한글명	VARCHAR(100)		x	표시 명칭 (대기중, 전화상담 등)
  code_desc	코드 설명	VARCHAR(255)			상세 용도 설명
  use_yn	사용 여부	TINYINT(1)	DEFAULT 1	x	1: 사용, 0: 미사용
  disp_order	정렬 순서	INT	DEFAULT 0	x	화면 출력 순서

  공통 코드가 쓰이는 부분그룹 명칭(group_code) 코드값 (code_val) 사용되는 테이블 (컬럼명) 설명

  CONSULT_STATUS	pending, processing, complete	consultation_records (status)	상담의 현재 진행 단계 관리
  CONTACT_CHANNEL	call, email, push	customers (preferred_contact)	고객이 선호하는 연락 수단
  FILE_SOURCE	chat_log, summary	file_lifecycle (source_type)	저장된 파일이 채팅 원문인지 AI 요약본인지 구분

  ---

• 시스템 전반에서 사용하는 코드값(상담 상태, 채널 구분 등)을 통합 관리
• 키워드 추출 등 시간이 걸리는 작업의 상태를 추적
• 아래 테이블은 일단 생성하지 않기로(meta table 사용하기)

 

API 명세서

이렇게 작업 완료

이번주부턴 개발시작