B2B 업무 현장에서 문서는 매출과 신뢰를 결정짓는 핵심 자산이다. 제안서, 서비스 소개서, 사업계획서, 기술 문서, IR 자료 등 상대를 설득하거나 정보를 전달하기 위한 문서가 항상 필요하고, 그 작성 과정은 회사마다 형태만 다를 뿐 구조적으로 동일하다. 자료를 모으고, 목차를 잡고, 섹션별로 작성하고, 표현을 다듬고, 검토하고, 내보내는 과정이 반복된다.
문제는 기존 AI 문서 도구가 이 반복 구조를 해결하지 못한다는 점이다. 대부분의 생성형 도구는 "프롬프트 한 줄 입력 → 결과물 한 덩어리 출력"으로 끝난다. 한 번 생성된 결과를 부분적으로 수정하거나, 과거 문서의 패턴을 재활용하거나, 생성된 내용의 사실 관계를 검증하는 구조가 없다.
기존 생성형 AI 도구에는 네 가지 근본적인 한계가 있다. 단발성 생성이라 전체를 한 번에 만들고 끝나서 섹션 단위 편집이 불가능하고, 기업의 과거 데이터나 도메인 지식을 참조하지 못하며, 할루시네이션 체크나 스타일 일관성 검증이 없고, Token 사용량이 보이지 않아 통제할 수 없다.
Reindeers Document AI는 이 문제를 문서를 조작 가능한 섹션 단위로 분리하여 관리하는 운영 플랫폼으로 해결한다. 단순히 AI가 문장을 생성하는 도구가 아니라, 구조화된 데이터 입력 → 섹션별 생성 → 편집 → 품질 검증 → 공유/출력까지 이어지는 문서 운영 체계다.
섹션 기반 데이터 모델
기술 스택은 Next.js App Router 기반이며, Cloudflare Workers에 배포된다. 데이터 저장은 Turso 기반 libSQL과 Drizzle ORM을 사용하고, 인증은 JWT 쿠키 방식으로 구성했다. 핵심은 문서를 "하나의 파일"이 아니라 "프로젝트 → 섹션"의 2레벨 계층 구조로 관리한다는 점이다.
| 엔티티 | 주요 필드 | 역할 |
|---|---|---|
| Project | pattern, language, orientation, title, answers, outline, designSpec | 문서 전체의 메타데이터와 생성 컨텍스트 |
| Section | title, order, htmlContent, textContent, memo, insight, isVisible | 각 섹션의 상태와 콘텐츠 |
| Conversation | projectId, sectionId, role, content, timestamp | AI 채팅 이력 (프로젝트/섹션 단위) |
| TemplateSection | pattern, title, htmlContent, textContent | 과거 좋은 결과물을 자산으로 축적 |
| UsageLog | userId, action, inputTokens, outputTokens, model, cost | Token 사용량 추적 (input/output 분리) |
| PointTransaction | userId, type, amount, balance, referenceId | 포인트 충전/차감 장부 |
이 구조의 핵심 이점은 세 가지다. 첫째, 섹션 단위로 독립적으로 편집, 재생성, 순서 변경, 숨김 처리가 가능하다. 둘째, 각 섹션의 textContent가 RAG 파이프라인의 임베딩 소스가 된다. 셋째, UsageLog가 action 단위로 input/output Token을 분리 기록하므로 정확한 비용 추적이 가능하다.
B2B 문서는 한 번 만들고 끝나는 파일이 아니다. 고객사마다 조금씩 다르게 변형되고, 버전이 바뀌고, 일부 섹션만 교체되거나 숨겨져야 한다. 문서를 하나의 덩어리로 관리하면 부분 수정 시 전체를 재생성해야 하지만, 섹션 단위로 분리하면 필요한 부분만 정확히 조작할 수 있다. 이것이 "문서 생성 도구"와 "문서 운영 플랫폼"의 차이다.
Multi-step LLM 생성 파이프라인
Document AI의 문서 생성은 단일 LLM 호출이 아니라 4단계 Multi-step 파이프라인으로 동작한다. 각 단계는 별도의 시스템 프롬프트와 출력 제약을 갖고, 이전 단계의 결과를 다음 단계의 입력으로 사용한다.
Step 1: Outline Generation (경량 모델)
Input: pattern + language + user context
Output: 목차 후보 3개 (JSON 배열)
Model: lightweight — 빠른 응답, 낮은 비용
Step 2: Question Generation (경량 모델)
Input: 선택된 목차 + pattern
Output: 문서 완성도를 높이기 위한 질문 목록
Model: lightweight — 구조적 질문 생성
Step 3: Section-by-Section Generation (고성능 모델)
Input: 목차 + 답변 + RAG 검색 결과 + 템플릿 참조
Output: 각 섹션의 HTML 콘텐츠 (SSE 스트리밍)
Model: capable — 복잡한 콘텐츠 생성에 적합
Step 4: Post-processing (서버 사이드)
- HTML 구조 검증 (태그 매칭, 중첩 정합성)
- 인라인 스타일 정규화 (출력 일관성 보장)
- 섹션 크기 검증 (overflow 감지)
- textContent 추출 및 저장
Step 1~2에 경량 모델을, Step 3에 고성능 모델을 배치하는 이유는 명확하다. 목차와 질문 생성은 구조적 패턴이 명확한 작업이므로 경량 모델로도 충분한 품질이 나온다. 반면 실제 콘텐츠 생성은 사용자 데이터, 검색 결과, 템플릿을 종합해야 하므로 더 긴 컨텍스트 윈도우와 높은 추론 능력이 필요하다. 이 분리만으로 전체 Token 비용의 30~40%를 절감할 수 있다.
Step 3은 Server-Sent Events 기반으로 섹션을 하나씩 스트리밍한다. 사용자는 현재 어떤 섹션이 생성 중인지 실시간으로 확인할 수 있고, 일부 섹션이 실패해도 전체를 버리지 않고 이어서 편집할 수 있다. 생성 중 이탈 시에도 초안 프로젝트 ID와 중간 결과가 서버에 보존된다.
각 단계의 시스템 프롬프트는 문서 패턴(IR, Proposal, Technical 등)별로 분리되어 있다. 출력 형식(HTML 태그 제한), 길이 제약(섹션당 최대 글자 수), 언어 일관성, 금지 패턴(마크다운 혼용 금지 등)이 프롬프트 레벨에서 강제된다.
생성 후 AI 채팅은 단순 대화가 아니다. 현재 섹션 전체를 수정하거나, 프리뷰에서 특정 블록을 선택하여 그 부분만 교체하도록 지시할 수 있다. 이미지 URL을 함께 전송하면 멀티모달 수정도 가능하다. "이 다이어그램을 표로 바꿔줘", "이 섹션에 경쟁 분석을 추가해줘"처럼 구체적인 편집 요청이 가능한 구조다. 이때도 고성능 모델이 사용되며, 대화 이력은 Conversation 테이블에 프로젝트/섹션 단위로 저장된다.
RAG 파이프라인: 벡터 검색과 계층화된 컨텍스트
Document AI가 기업별로 다른 맥락에 맞는 결과를 생성할 수 있는 이유는 RAG(Retrieval-Augmented Generation) 파이프라인에 있다. 단순히 프롬프트만 LLM에 전달하는 것이 아니라, 관련 과거 데이터를 벡터 검색으로 찾아 컨텍스트에 포함시킨다.
| 단계 | 처리 내용 | 구현 상세 |
|---|---|---|
| 1. 임베딩 생성 | 섹션의 textContent를 벡터로 변환 | 섹션 저장/수정 시 임베딩 모델로 벡터 생성 → 벡터 인덱스에 저장. 메타데이터(projectId, pattern, language, userId) 함께 저장 |
| 2. 쿼리 벡터화 | 새 콘텐츠 생성 시 현재 섹션 제목+목차를 벡터로 변환 | 동일 임베딩 모델 사용. 쿼리 텍스트 = 섹션 제목 + 상위 목차 컨텍스트 |
| 3. 벡터 유사도 검색 | 관련 과거 섹션을 코사인 유사도로 검색 | 메타데이터 필터링(같은 userId, 같은 pattern 우선) → top-K 결과 반환 → 유사도 임계값 이하 제거 |
| 4. 재순위화 | 검색 결과를 비즈니스 로직으로 재정렬 | 최신 프로젝트 가중치 부여 + 같은 패턴 문서 우선 + 사용자 피드백 반영(insight 점수 기준) |
| 5. 컨텍스트 조립 | 우선순위 기반으로 프롬프트에 삽입 | 계층화된 컨텍스트 구조 (아래 상세) |
계층화된 컨텍스트 구조 (Priority-based Truncation)
컨텍스트는 5단계 우선순위로 조립된다. Priority 1은 사용자가 직접 입력한 정보(회사명, 서비스 특징, 핵심 지표, 답변)로 절대 유지된다. Priority 2는 벡터 검색으로 찾은 관련 과거 섹션 top-3이고, Priority 3은 템플릿 라이브러리에서 매칭된 참조 섹션이다. Priority 4는 도메인 지식과 패턴별 가이드라인으로 필요 시 축소되며, Priority 5는 시스템 지시(출력 형식, 길이 제약, 언어, 금지 패턴)로 항상 포함된다.
컨텍스트 윈도우 관리가 중요한 이유는 비용과 품질 모두에 영향을 주기 때문이다. 모든 참조 데이터를 무조건 넣으면 Token 비용이 급증하고, LLM의 주의력(attention)이 분산되어 오히려 품질이 떨어진다. Priority-based Truncation은 컨텍스트 윈도우의 남은 용량에 따라 Priority 4 → Priority 3 → Priority 2 순서로 축소한다. Priority 1(사용자 입력)과 Priority 5(시스템 지시)는 절대 축소되지 않는다.
context_budget = model_max_tokens - system_prompt_tokens - reserved_output_tokens
// Priority 1: 사용자 입력 (절대 유지)
user_context = build_user_context(answers, company_info)
remaining = context_budget - count_tokens(user_context)
// Priority 5: 시스템 지시 (절대 유지)
system_instructions = get_pattern_instructions(pattern, language)
remaining = remaining - count_tokens(system_instructions)
// Priority 2: RAG 검색 결과 (높은 우선순위)
retrieved_sections = vector_search(query, top_k=5, filter={userId, pattern})
rag_context = truncate_to_fit(retrieved_sections, remaining * 0.5)
remaining = remaining - count_tokens(rag_context)
// Priority 3: 템플릿 참조
template_context = truncate_to_fit(matched_templates, remaining * 0.6)
remaining = remaining - count_tokens(template_context)
// Priority 4: 도메인 지식 (나머지 공간)
domain_context = truncate_to_fit(domain_knowledge, remaining)
품질 파이프라인: 검증, 정규화, 할루시네이션 체크
생성된 콘텐츠를 그대로 출력하면 실무에서 쓸 수 없다. Document AI는 생성 후 4단계 품질 파이프라인을 통과시켜 결과물의 신뢰성을 확보한다.
첫 번째 단계는 HTML 구조 검증이다. 태그 매칭 검증, 중첩 정합성 체크, 허용된 태그/속성 화이트리스트 기반 Sanitization을 수행한다. LLM이 생성한 HTML에서 스크립트 삽입이나 비정상 태그를 제거한다.
두 번째는 스타일 정규화다. 인라인 스타일을 프로젝트의 designSpec에 맞게 정규화하고, 폰트 크기, 색상, 간격이 섹션 간에 일관되도록 강제한다. 출력 시 animation, transition, backdrop-filter 등 인쇄에 불필요한 속성은 제거된다.
세 번째는 섹션별 품질 분석이다. 각 섹션에 대해 길이, 예상 발표 시간, 강점, 개선점, 핵심 키워드를 자동 분석하여 insight 필드에 저장한다. 콘텐츠가 섹션 영역을 초과하면 overflow를 감지하고 분할을 제안한다.
네 번째는 할루시네이션 체크다. 생성된 콘텐츠에서 수치, 회사명, 제품명, 날짜 등 사실 관계를 사용자가 입력한 원본 데이터(answers)와 대조한다. 입력에 없는 구체적 수치가 생성된 경우 경고를 표시하고, 해당 부분을 하이라이트한다.
| 검증 항목 | 방법 | 실패 시 처리 | IR 목표 |
|---|---|---|---|
| HTML 구조 | 파서 기반 정적 검증 | 자동 복구 시도 → 실패 시 재생성 | 99%+ 통과율 |
| 스타일 일관성 | designSpec 대조 정규화 | 자동 정규화 적용 | 전 섹션 일관성 |
| 콘텐츠 품질 | 길이/시간/키워드 분석 | insight에 개선 제안 기록 | 90%+ 적정 품질 |
| 할루시네이션 | 사용자 입력 데이터 대조 | 경고 표시 + 하이라이트 | 90%+ 정확도 |
이 파이프라인이 IR 목표인 AI 정확도 90% 이상을 달성하기 위한 핵심 메커니즘이다. 정확도는 단일 지표가 아니라, 구조 정합성 + 스타일 일관성 + 콘텐츠 적정성 + 사실 관계 정확성의 복합 지표로 측정한다. 생성 모델의 성능에만 의존하는 것이 아니라, 후처리 파이프라인이 품질의 하한선을 보장하는 구조다.
Token 비용 관리: 포인트 시스템과 모델 선택 전략
AI 문서 서비스에서 Token 비용은 무시할 수 없는 운영 변수다. 사용자가 비용을 통제할 수 없으면 실무에서 사용이 위축되고, 서비스 제공자가 비용을 흡수하면 수익 구조가 무너진다. Document AI는 이 문제를 포인트 시스템과 모델 선택 전략으로 해결한다.
1. 사용량 기록 (UsageLog)
매 LLM 호출마다 기록:
{ userId, projectId, action, model,
inputTokens, outputTokens, totalCost }
action 종류: outline_gen, question_gen, section_gen,
section_edit, chat_response, insight_analysis
2. 포인트 차감 (PointTransaction)
Token 사용량 → 포인트 환산 → 잔액에서 차감
input/output Token별 단가가 다름 (output이 더 비쌈)
차감 전 잔액 확인 → 부족 시 생성 차단
3. 포인트 충전 (PointTransaction)
충전: 결제 웹훅 + 복귀 후 검증 API (멱등성 보장)
적립: type = 'credit', referenceId = paymentId
차감: type = 'debit', referenceId = usageLogId
| 작업 | 사용 모델 | 이유 | 비용 비율 |
|---|---|---|---|
| 목차 생성 | 경량 모델 | 패턴 기반 구조 작업, 짧은 출력 | 낮음 |
| 질문 생성 | 경량 모델 | 구조적 질문, 짧은 출력 | 낮음 |
| 섹션 콘텐츠 생성 | 고성능 모델 | 긴 컨텍스트 + 복잡한 추론 필요 | 높음 |
| 섹션 수정 (채팅) | 고성능 모델 | 대화 이력 + 기존 콘텐츠 참조 | 높음 |
| 인사이트 분석 | 경량 모델 | 정형화된 분석 항목, 짧은 출력 | 낮음 |
사용자 입장에서 비용 투명성도 중요하게 설계했다. 대시보드에서 프로젝트별 Token 사용량과 포인트 소모 내역을 확인할 수 있고, 각 생성/수정 액션 후 소모된 포인트가 즉시 표시된다. input Token(프롬프트)과 output Token(생성 결과)이 분리 표시되며, 월별 사용 추이 그래프로 비용 예측이 가능하다. 포인트 잔액이 부족하면 생성 전에 안내하여 중간에 끊기는 상황을 방지한다.
이 구조의 핵심은 "누가 얼마를 썼는가"뿐 아니라 "어떤 기능에서 어떤 모델로 얼마의 비용이 발생했는가"를 추적할 수 있다는 점이다. B2B SaaS에서 기능이 되는 것만큼 비용 흐름이 명확한 것도 중요하기 때문에, 과금 시스템은 문서 생성 기능과 같은 수준으로 제품의 핵심에 포함되어 있다.
플랫폼 연결: Workflow AI, REINDEERS 거래 데이터
Document AI는 독립된 서비스가 아니라 REINDEERS 플랫폼 생태계의 일부다. 이 연결이 단순 문서 도구와 근본적으로 다른 지점이다.
| 플랫폼 | Document AI와의 연결 | 데이터 흐름 | 상태 |
|---|---|---|---|
| REINDEERS | 11년간 축적된 실거래 데이터가 RAG의 지식 베이스를 구성 | 거래 패턴, 가격 이력, 납기 데이터 → 벡터 인덱스 | 연결 운영 중 |
| Workflow AI | 문서 생성 완료 이벤트가 후속 업무 자동화를 트리거 | document.completed → 공급사 알림, 승인 요청 Workflow 실행 | 연결 운영 중 |
| DVRP | 견적서에서 확정된 물류 조건이 배차 최적화의 입력이 됨 | quote.confirmed → DO 자동 생성 → 경로 최적화 | BETA |
| POP | 생산 운영 데이터가 향후 RAG의 도메인 지식으로 확장 | 생산 일정, 재고 수준 → 견적 정확도 향상 | 5월 오픈 |
일반적인 AI 문서 도구는 범용 LLM만으로 콘텐츠를 생성한다. Document AI는 REINDEERS 플랫폼의 25,000건 이상 실거래 데이터(PQ, PO, DO, CI)를 벡터 인덱스로 구축하여, 기업이 실제로 거래한 품목의 가격 범위, 납기 패턴, 공급사 정보를 참조한 문서를 생성한다. 예를 들어 견적서를 만들 때 "유사 품목의 최근 3개월 거래 단가"를 자동으로 참조하여 현실적인 가격을 제안할 수 있다. 이것은 공개 데이터를 학습한 범용 LLM으로는 불가능한 영역이다.
여기서 데이터 플라이휠이 작동한다. Document AI에서 문서가 생성되면 REINDEERS 거래로 연결되고, 거래가 발생하면 데이터가 축적되며, 축적된 데이터가 RAG 지식 베이스를 강화하고, 그 결과 AI 정확도가 향상된다. 이 순환이 반복될수록 플랫폼의 가치는 자동으로 올라간다.
IR 목표와 확장 로드맵
Document AI는 Q1에 베타를 출시했고, 현재 Q2 확장 단계에 있다. IR 관점에서 핵심 지표와 기술 로드맵은 다음과 같다.
| 지표 | 현재 | Q2 목표 | 달성 방법 |
|---|---|---|---|
| AI 정확도 | 측정 체계 구축 완료 | 90%+ | RAG 파이프라인 고도화 + 할루시네이션 체크 강화 |
| 문서 유형 | IR, Proposal, Technical 등 6개 | 견적서, 운영 문서 추가 | REINDEERS 거래 데이터 연동 확대 |
| 지원 언어 | 한국어, 영어, 태국어, 중국어 | 동일 (품질 강화) | 언어별 시스템 프롬프트 최적화 |
| 비용 효율 | 모델 분리 적용 | 문서당 비용 30% 절감 | 컨텍스트 윈도우 최적화 + 캐시 레이어 |
현재 Document AI는 제안서, IR 자료, 기술 문서 등 설명형 문서에 집중하고 있다. 다음 단계는 견적서(Quotation)와 운영 문서다. 견적서는 REINDEERS 거래 데이터의 품목별 가격 이력, 납기 패턴, 환율 데이터를 RAG로 참조하여 자동 생성할 수 있다. 운영 문서는 Workflow AI의 프로세스 실행 이력과 POP의 생산/재고 데이터를 기반으로 월간 리포트, 재고 현황표, 생산 일정표를 자동 생성하는 방향이다. 이 확장은 기존 RAG 파이프라인 위에 데이터 소스만 추가하는 구조이므로 별도의 아키텍처 변경 없이 가능하다.
그 외에도 세 가지 방향을 병행하고 있다. 외부 HTML 문서를 파싱하여 섹션 단위로 분리하고 템플릿 라이브러리에 자산으로 저장하는 템플릿 자산 축적, 편집 화면 프리뷰를 iframe 기반으로 분리하고 공개 링크와 PDF 출력이 동일한 HTML 소스를 공유하는 프리뷰-출력 일관성, 기존 문서를 복제하여 새 프로젝트의 출발점으로 활용할 수 있는 복제와 재사용 기능이다. 반복되는 제안서나 소개서 작업에서 구조를 재활용하면서 내용만 교체하는 패턴이 가능해진다.
Reindeers Document AI가 만드는 것은 "더 좋은 문서"가 아니다. 문서 업무 전체를 구조화된 파이프라인 위에 올리는 것이다. 문서를 섹션 단위 상태로 분리하여 관리하고, RAG 파이프라인으로 기업별 과거 데이터를 검색하여 맞춤 결과를 생성하며, Multi-step LLM 호출로 비용과 품질을 동시에 최적화하고, 포인트 시스템으로 Token 비용을 실무에서 통제 가능하게 만들었다. 품질 파이프라인은 생성된 콘텐츠의 구조, 스타일, 사실 관계를 자동 검증하여 AI 정확도 90% 이상이라는 IR 목표의 기술적 기반이 된다.
그리고 이 구조는 Document AI 안에서 완결되지 않는다. REINDEERS의 실거래 데이터, Workflow AI의 업무 자동화, DVRP의 물류 실행, POP의 생산 운영 데이터가 하나의 RAG 지식 베이스로 수렴되면서, 문서 생성의 정확도는 플랫폼 사용이 늘어날수록 자동으로 향상된다. 단순 생성형 AI가 아니라, 데이터가 쌓일수록 강해지는 문서 운영 플랫폼 — 이것이 Document AI의 본질이다.