PostgreSQL + Dify RAG로 27만자 전자책 자동 품질 검토 시스템 구축하기

소개

시도하고자 했던 것

한국 전통 명리학을 AI와 결합한 전자책 "명리학의 과학적 재발견"(14장, 27만자)을 집필하면서, 수작업 검토의 한계를 느꼈습니다.

문제점

• 📚 분량: 27만자, 94개 표, 150페이지 - 수동 검토 불가능

• 🚫 금기어: 프로젝트 정책상 사용 금지 용어가 실수로 포함될 위험

• 📊 데이터 정합성: 60갑자, 절기, 원전 인용 등 팩트 검증 필요

• 🔄 일관성: 10,623건 DB 데이터와 본문 내용의 일치 여부 확인

해결 목표

1. 자동 금기어 검사 - 프로젝트 금기어 실시간 검출

2. RAG 기반 팩트 체크 - DB 데이터로 본문 검증

3. 내용 보강 제안 - 누락된 정보 자동 식별

4. 검토 보고서 자동 생성 - Markdown 형식 종합 리포트

ALT

다양한 색깔의 한국 사업 계획

ALT

한국사이트 스크린샷

진행 방법

3.1 사용 도구

3.2 데이터베이스 구성

25테이블 시스템 (총 10,623건)

[A] 통변자료 5테이블: profiles(360건), wonkuks(360건), daeuns(930건), daeun_groups(1,412건), sewuns(312건)

[B] 기초데이터 7테이블: jeolgi_data(2,568건), gapja_60_lookup(60건) 등

[C] 교육콘텐츠 5테이블: classics(2,015건), gwanbeop_ppt(1,593건), ilju_education(60건)

3.3 핵심 SQL 쿼리

A. 60갑자 정보 검증

SELECT ilju_name, ilji_unseong, gongmang, special_traits FROM gapja_60_lookup WHERE ilju_name = '병인';

B. 원전 키워드 검색

SELECT section_number, title, LEFT(content, 300) FROM classics WHERE book_title = '연해자평' AND content LIKE '%식신생재%';

C. 절기 데이터 검증

SELECT year, jeolgi_name, solar_date, solar_time FROM jeolgi_data WHERE year = 2025 AND jeolgi_name = '입춘';

-- 결과: 2025-02-03 23:10 (분 단위 정밀도)

3.4 Dify 자동 검토 워크플로우

워크플로우 구조:

[입력] 검토할 텍스트 (장/절 단위)

  ↓ [노드1] 금기어 검사 (Code) → 프로젝트 금기어 검출

  ↓ [노드2] RAG 지식검색 → 4개 지식베이스 검색

  ↓ [노드3] 팩트 체크 (LLM+RAG) → 절기/갑자/원전 검증

  ↓ [노드4] 내용 보강 제안 (LLM+RAG) → 누락 정보 식별

  ↓ [노드5] 검토 보고서 (Template) → Markdown 보고서

[출력] 종합 검토 결과

노드1: 금기어 검사 (Python 코드)

def main(input_text: str) -> dict:

    """프로젝트 금기어 검사"""

    FORBIDDEN = {

        '금기어1': '[대체어1]',  # 한글

        '金忌語1': '[대체어1]',  # 한자

        '금기어2': '[대체어2]',

        # ... 총 4종 금기어 + 한자 포함

    }

    issues = []

    for word, replacement in FORBIDDEN.items():

        if word in input_text:

            count = input_text.count(word)

            issues.append({'word': word, 'count': count, 'replacement': replacement})

    return {'passed': len(issues) == 0, 'issues': issues}

3.5 Dify 지식베이스 설정

결과와 배운 점

4.1 결과

전자책 최종 스펙

검토 효율성

4.2 배운 점 & 꿀팁

💡 꿀팁 1: SQL 쿼리 템플릿화

자주 쓰는 검증 쿼리를 미리 저장해두면 검토 속도가 10배 빨라집니다.

💡 꿀팁 2: RAG 청크 크기

한국어는 800자 청크 + 150자 오버랩이 최적입니다. 영어 기준(500토큰)보다 크게 잡아야 문맥이 유지됩니다.

💡 꿀팁 3: 금기어 검사 우선

LLM 호출 전에 Code 노드로 금기어 검사를 먼저 하면 API 비용 절약 및 처리 속도가 향상됩니다.

4.3 시행착오

4.4 도움이 필요한 부분

1. 대용량 처리: 27만자를 한번에 검토하면 토큰 한도 초과. 장 단위로 나눠서 처리 중인데, 더 효율적인 방법이 있을까요?

2. 버전 관리: 검토 결과를 반영한 수정본 관리. Git 연동 자동화 방법?

<< 앞으로의 계획 >>

단기 (1개월)

• ☐ Dify 워크플로우 API 연동 → Rails 앱에서 호출

• ☐ 검토 결과 자동 저장 (PostgreSQL)

• ☐ 슬랙 알림 연동 (금기어 발견 시)

중기 (3개월)

• ☐ 112만 조합 데이터 확장 (현재 1만 → 목표 112만)

• ☐ 실시간 협업 검토 기능 (다중 사용자)

• ☐ Claude Projects 연동 (project_knowledge_search)

장기 (6개월)

• ☐ UNESCO 디지털 문화유산 등재 신청

• ☐ 오픈소스 공개 (검토 워크플로우)

• ☐ 다국어 지원 (영어, 일본어, 중국어)

도움 받은 글 (옵션)

• Dify 공식 문서: https://docs.dify.ai

• Anthropic Claude API 문서: https://docs.anthropic.com

• PostgreSQL 공식 문서: https://www.postgresql.org/docs/

• 韓바둑 프로젝트 내부 문서: PostgreSQL 학습로드맵 v7.1