레거시 DB 인벤토리 — pms (테스트 서버)

조사일: 2026-05-18 대상: db.malgn.co.kr:3306/pms (테스트 서버, 읽기 권한 계정) 목적: AI 챗봇 학습 자산화 가능성 평가 및 인제스트 매핑 정의

자격 증명은 본 문서에 기록하지 않는다. 운영 시크릿 채널로 관리.

1. 결론 요약

• 이 DB는 CS 전용 DB가 아니라 맑은소프트의 사내 PMS(프로젝트 관리 시스템).
• 그러나 tb_post + tb_post_comment에 고객 문의와 맑은소프트 직원의 답변이 함께 누적되어 있어 CS Q&A 자산으로 가치가 있다.
• 합리적 필터를 적용하면 약 1,358건의 Q&A 후보가 확보된다 (Site 1: 1,146, Site 2: 212).
• HTML 본문·테스트 글·이미지 전용 글 등 정제가 필요. 정제 후 OpenSearch 인덱싱 대상으로 활용 가능.

2. DB 메타

3. 테이블 인벤토리 (행수 기준 상위)

tb_chat_message 샘플: "네~^^", "감사합니다ㅎㅎ" 등 사내 메신저 대화 — CS 자산으로 활용 부적합.

4. 핵심 테이블 스키마 (관련 컬럼만)

tb_post (질문/요청 본문)

tb_post_comment (답변 본문)

tb_site, tb_project, tb_user, tb_post_label

• 메타데이터 결합용 — 작성자명·사이트명·프로젝트명·라벨명을 인덱스 메타 필드로 첨부.

5. Q&A 후보 데이터 규모

적용 필터

WHERE p.status = 1
  AND p.comm_cnt >= 1
  AND p.is_task = 0
  AND p.is_schedule = 0
  AND p.is_poll = 0
  AND p.is_notice = 0
  AND p.subject NOT LIKE '테스트%'
  AND CHAR_LENGTH(p.content) >= 20

결과

Site 1이 외부 고객 문의 + 내부 글이 섞여 있을 가능성 있음. 표본 검수 후 site별 채택 여부 재결정 필요.

6. 데이터 품질 이슈

이미지 처리 전략

본 DB의 게시글 본문은 <p> 텍스트와 <img src="/data/..."> 이미지가 함께 들어 있다. 가치 있는 Q&A는 보통 텍스트 본문이 충분하고, 이미지만 있는 글은 테스트·사내 스크린샷이 대부분이라 단계별 도입으로 비용과 복잡도를 통제한다.

공통 원칙

• 모든 단계에서 이미지 URL을 메타 필드로 보존 → 챗봇 답변에서 "관련 화면 참고: <링크>"로 인용 가능.
• 이미지 경로(/data/...)는 외부 접근 가능한 URL로 치환 (R2 서명 URL 또는 프록시).
• 단계 전환은 미커버 질문 분석 결과로 결정. 이미지 정보 없이 풀리지 않는 질문이 의미 있게 쌓이면 B 도입.

트레이드오프: 텍스트만은 단순·저비용이지만 "이 화면에서 어떻게 해요?" 같은 시각 의존 질문을 놓침. OCR/Vision은 잡을 수 있지만 복잡도·비용 증가.

스레드 처리 전략

게시글당 댓글 수 분포 (status=1 + 테스트 제외 후, 1,358건 후보 기준):

약 64%가 스레드형 — 단일 Q&A 페어로 가정하면 안 된다. 후속 질의·재확인·해결 과정을 모두 활용해야 답변 품질이 살아난다.

원칙: 스레드를 하나의 Q&A 도큐먼트로 압축해서 인덱싱한다.

비잡담 검증: 댓글 노이즈("ddddd", "xxxxxx") 검출 룰 — 동일 문자 반복, 길이 5자 미만, 의미 없는 단일 단어 등.

비공개 댓글 처리 전략

tb_post_comment.private_yn = 'Y' 댓글은 활성 댓글 5,021건 중 513건 (약 9.3%).

관찰: 일부 스레드는 알맹이 답변이 비공개에만 존재한다 (예: post 94221 — 공개 댓글은 잡담, 비공개 댓글이 실제 답변). 따라서 단순 제외하면 답변 자산을 잃는다. 그러나 비공개는 의도적으로 고객 비노출이므로 챗봇 노출은 금지.

해결: 가시성(visibility) 메타 필드로 계층 인덱싱.

같은 게시글에 대해 두 개 변형을 만들지 않고, 하나의 도큐먼트에 두 본문 필드를 유지하는 방식도 가능:

Phase별 사용:

금지: 비공개 댓글 본문이 Phase 2 챗봇 응답에 직접 인용되거나 출처로 노출되어선 안 됨.

첨부파일 처리 전략

tb_post_file은 게시글/댓글에 첨부된 파일 메타. 활성 78,784건이 존재하고 Q&A 후보 1,358건 중 881건(64.9%)이 첨부 보유 — 무시 시 답변 자산의 절반 손실.

스키마 핵심: module(post/editor) + module_id(게시글 id) + realname(원본 파일명) + filetype(file/image/movie) + filesize.

파일 종류 분포 (확장자 상위):

한국어 환경 특이점: HWP(한컴) 5,094건 — 별도 추출기(hwp.js 등) 필요.

종류별 처리 정책

공통 원칙

• 원본은 R2에 보관. DB의 realname/filename을 R2 키로 매핑. 답변 인용 시 R2 서명 URL 발급.
• 가시성 상속: 댓글에 첨부된 파일은 그 댓글의 private_yn 값을 상속.
  • 공개 댓글 첨부 → 텍스트는 body_public·body_internal 모두에 부착
  • 비공개 댓글 첨부 → body_internal에만 부착, Phase 2 챗봇에서 노출 금지
  • 게시글 본문 첨부 → 공개 취급
• 크기 상한: Phase 1에서는 50MB 초과 파일은 Queue 도입 전까지 보류. 메타만 인덱스에 보존.
• 추출 실패 허용: 손상된 파일·미지원 포맷은 메타만 남기고 extraction_status: failed. 인덱싱 중단 사유 아님.
• PII: 추출 텍스트에도 PII 검출·마스킹 적용 (이메일·전화·주민번호).
• 챗봇 인용: 답변에 "참고: filename.pdf" 형식으로 출처 첨부 명시.

라이브러리 후보 (선정 보류)

Cloudflare Workers의 CPU/메모리 제한으로 동기 추출은 일부 포맷·소형 파일만 가능. 대용량/복잡 추출은 별도 인덱서(로컬 백필 스크립트 또는 Phase 2 Queue Worker)에서 처리.

트레이드오프

• 텍스트 문서 추출만 도입해도 답변 자산이 크게 늘어남(881건의 첨부 중 상당수가 매뉴얼·로그·샘플).
• 그러나 추출 라이브러리·실패 케이스·대용량 처리 인프라 비용 증가.
• 동영상 트랜스크립트는 즉시 도입 시 비용이 가장 크므로 Phase 2 Queue 도입과 정합.

7. 권장 인제스트 매핑 (초안)

OpenSearch chunks 인덱스 한 도큐먼트당:

청킹 전략: 스레드를 1 도큐먼트로 압축. 결합 본문(스레드 + 추출 첨부 텍스트)이 2000자 이상이면 의미 단위 분할 (동일 doc_id 유지). 짧은 단일 Q&A는 분할 없이 그대로. 첨부 추출 텍스트는 본문 결합 시 [첨부:{filename}] 헤더 뒤에 부착해 LLM이 출처를 인지 가능하게.

Phase별 쿼리: Phase 1은 body_internal + embedding_internal, Phase 2는 body_public + embedding_public을 검색 대상으로. 색인은 같은 도큐먼트라 운영 동기화 비용 1배수.

8. 표준 답변 후보 식별 전략

• 동일/유사 질문에 같은 답변이 반복 등장 → 표준 답변 후보로 자동 추출.
• 댓글 작성자가 맑은소프트 직원(tb_user에서 staff 플래그/도메인으로 식별) → 신뢰도 가중치 상향.
• 후보 답변은 ROADMAP.md 1.9 피드백 루프의 자동 추천 흐름과 연결.

9. 다음 단계 (실행 항목)

1. 표본 검수: site 1의 Q&A 후보 30~50건 추출 → 실제 CS 답변/내부 잡담 비율 확인 → 추가 필터 도출. 스레드형/단일형 분포와 비공개 댓글 영향도 함께 평가.
2. HTML 정제 PoC: 5건 정도를 직접 정제해서 토큰 수·내용 유효성 측정.
3. 노이즈 댓글 필터 룰 작성: 5자 미만, 동일 문자 반복(ddddd 등), 의미 없는 단일 단어 탐지.
4. PII 검출 룰 작성: 이메일/전화/주민번호 정규식 + 마스킹 규칙.
5. 가시성 정책 합의: Phase 1에서 비공개 댓글 활용 범위·노출 경로(상담사 화면에서만) 명문화. 첨부파일도 동일 정책 상속.
6. 첨부 추출기 선정 PoC: PDF/DOCX/HWP/XLSX 추출 라이브러리 후보 평가 (한국어·표·이미지 포함 PDF에서의 정확도, Worker 적합성).
7. R2 마이그레이션 계획: 78,784개 첨부의 R2 이관 전략 (전체 백필? 인덱싱 대상만? URL 매핑 테이블 유지?).
8. 인제스트 파이프라인 설계: 일회성 백필 + 증분 동기화 (reg_date 기준) 정책. 스레드는 마지막 댓글 갱신 시 재인덱싱. 첨부 추출 실패는 메타만 보존.
9. 사이트 채택 범위 합의: site 1만? 1+2? 다른 site는 외부 고객사 데이터라 사용 가능 여부 별도 확인 필요.
10. 법적/내부 검토: 고객 문의 본문에 포함된 회사명·개인정보 사용 가능 범위, 비공개 댓글의 학습 자산화 가능 여부, 첨부 파일(특히 고객사 자료) 활용 가능 범위 확인.

10. 미사용 결정

다음은 본 DB에서 사용하지 않음으로 결론:

• tb_chat_message — 짧은 사내 메신저, CS 자산 아님
• tb_post_template — 양식/템플릿이라 답변 데이터 부재
• 이미지만 있는 게시글 (Stage A 한정) — §6 이미지 처리 전략 참조. Stage B/C 도입 시 재평가
• 노이즈 댓글 (5자 미만, 동일 문자 반복 등) — §6 스레드 처리 전략의 노이즈 필터로 제외
• 압축파일(zip)·동영상·디자인/실행 파일 (Phase 1 MVP 한정) — §6 첨부파일 처리 전략 참조. zip은 검토 후 결정, 동영상은 Phase 2 Queue 도입 시 트랜스크립트 처리

비공개 댓글·첨부는 사용하지 않음이 아님. Phase 1 한정으로 활용. §6 비공개 댓글 / 첨부파일 처리 전략 참조.