문서에서 답변까지 이어지는 AI 지식 시스템

AI 지식 시스템은 문서를 검색 가능한 근거로 준비하고, 질문에 맞는 근거를 골라 답변하거나 도구를 실행하는 과정입니다.

문서 준비와 질문 처리

운영 문서를 넣고 장애 대응 방법을 묻는 시스템을 생각해 봅니다. 문서에서 텍스트를 읽는 작업, 관련 내용을 찾는 작업, 답변을 만드는 작업은 서로 다른 입력과 결과를 가집니다. 각 단계의 역할을 구분하면 어느 부분에서 정보가 사라지거나 잘못됐는지 확인할 수 있습니다.

전체 흐름은 문서를 준비하고 갱신하는 과정과 질문을 처리하는 과정으로 나눌 수 있습니다. 문서 준비 과정은 원본을 보존하고 검색 단위를 만듭니다. 질문 처리 과정은 그 단위에서 근거를 골라 생성 모델에 전달합니다.

flowchart TD
    subgraph PREP["문서 준비와 갱신"]
        SRC["PDF · 오피스 문서 · 웹 · Markdown"]
        RAW["원본과 출처 보존"]
        PARSE["파싱 · 필요 시 OCR"]
        CHUNK["정제 · 청킹 · 메타데이터"]
        EMB["문서 임베딩"]
        INDEX["키워드 및 벡터 인덱스"]
        EXTRACT["개념 · 관계 추출과 검증"]
        KG["지식그래프와 근거"]
        ONT["온톨로지의 유형 · 관계 규칙"]
        SRC --> RAW --> PARSE --> CHUNK
        CHUNK --> EMB --> INDEX
        CHUNK --> INDEX
        CHUNK -. "선택적 추출" .-> EXTRACT --> KG
        ONT -. "규칙 적용" .-> EXTRACT
    end
    subgraph ANSWER["질문 처리"]
        Q["사용자 질문"]
        RET["하이브리드 검색"]
        RANK["필요 시 리랭킹"]
        CTX["근거 선택 · 문맥 구성"]
        GEN["LLM 답변 생성"]
        OUT["답변 · 출처"]
        Q --> RET --> RANK --> CTX --> GEN --> OUT
    end
    INDEX --> RET
    KG -. "선택적 관계 탐색" .-> CTX

이 그림은 가능한 구성 예입니다. OCR, 리랭킹, 지식그래프는 문서 형식과 질문에 따라 선택하며, 모든 시스템에 필요한 단계는 아닙니다. 에이전트는 이런 검색과 생성 기능을 도구로 사용하면서 다음 행동을 선택할 수 있습니다.

LLM이 담당하는 일

대규모 언어 모델(LLM) 중 자기회귀 생성 모델은 문맥을 바탕으로 다음 토큰의 분포를 계산합니다. 선택한 토큰을 문맥에 추가하고 이 과정을 반복해 문장을 만듭니다. 토큰은 단어와 정확히 같지 않으며, 단어 일부나 문자에 대응할 수 있습니다.

Transformer의 attention은 문맥 안의 정보 사이에서 관련성을 계산하는 데 쓰입니다. 요약, 번역, 분류, 관계 추출은 입력과 출력 형식을 달리해 수행할 수 있습니다. 다만 자연스러운 문장이 생성됐다는 사실만으로 내용의 진위가 보장되지는 않습니다. Google의 Transformer 설명

문서를 임베딩하거나 검색 인덱스에 추가하는 일은 일반적으로 생성 LLM의 가중치를 학습시키지 않습니다. RAG에 학습된 검색기나 리랭커를 결합할 수는 있습니다. 그러나 새 문서를 답변에 반영하려고 항상 생성 모델을 파인튜닝해야 하는 것은 아닙니다.

파싱으로 보존해야 하는 구조

문서 파싱은 파일 형식에서 내용과 구성 요소를 읽는 작업입니다. 텍스트가 추출됐어도 제목 계층, 읽는 순서, 표의 열 관계까지 복원됐다고 볼 수는 없습니다. 광학 문자 인식(OCR)은 이미지 속 글자를 읽는 기능이며, 표나 문서 전체의 구조 복원과 구분합니다.

웹 페이지를 가져오는 수집과 HTML에서 본문을 읽는 파싱도 별도 작업입니다. PDF가 이미지 중심이면 OCR이 필요할 수 있습니다. 텍스트 레이어가 있으면 텍스트 파서를 사용할 수 있지만, 추출된 내용과 순서를 확인해야 합니다.

가격표에서 상품명과 숫자만 모으면 어떤 가격이 어느 상품에 속하는지 잃을 수 있습니다. 다음 JSON은 문서·페이지·절과 표의 행·열을 함께 표현하는 설명용 예시입니다. 특정 파서의 출력이나 실제 저장 스키마를 뜻하지 않습니다.

{
  "document_id": "guide-001",
  "source_page": 3,
  "section_path": ["서비스 안내", "요금"],
  "block_type": "table",
  "columns": ["플랜", "월 요금", "통화"],
  "rows": [["기본", 10000, "KRW"]]
}

ETL과 청킹으로 검색 단위 만들기

ETL은 추출(Extract), 변환(Transform), 적재(Load) 순서로 데이터를 처리합니다. ELT는 추출한 데이터를 대상 저장소에 먼저 적재한 뒤 그 환경에서 변환합니다. 둘의 차이를 설명하려면 어떤 저장소를 적재 대상으로 보는지 정해야 합니다. AWS의 ETL·ELT 비교

문서를 파싱·정제·청킹·임베딩한 뒤 검색 인덱스에 넣는 흐름은 ETL로 볼 수 있습니다. 수집 데이터를 데이터 레이크에 먼저 적재하고 그 안에서 가공한다면 ELT에 해당합니다. 원본 파일을 별도로 백업했다는 사실만으로 전체 과정이 ELT가 되지는 않습니다.

청킹은 긴 문서를 검색과 생성에 사용할 단위로 나눕니다. 청크가 너무 크면 여러 주제가 섞이고, 너무 작으면 정의와 조건이 분리될 수 있습니다. 크기와 경계는 문서 구조, 모델 입력 길이, 실제 질문으로 평가합니다.

제목과 절 경계를 활용하거나 일정 길이로 나누고 일부 구간을 겹치게 할 수 있습니다. 겹침은 경계의 문맥을 보완하지만 검색 결과 중복과 저장량을 늘립니다. "이 설정을 켜면 됩니다" 같은 문장에는 해당 설정을 식별할 절 정보와 앞뒤 문맥이 필요합니다.

문서 수정·삭제는 이전 청크와 파생 관계에도 반영해야 합니다. 같은 입력을 다시 처리할 때 중복이 쌓이지 않도록 식별자와 갱신 규칙을 정합니다. 원문에서 추출하지 못한 페이지나 위치는 임의로 채우지 않습니다.

임베딩과 벡터 저장소

임베딩 모델은 입력을 [0.12, -0.08, ...] 같은 실수 배열로 표현합니다. 검색용 모델은 질문과 관련 문서가 호환되는 벡터 공간에서 비교되도록 학습됩니다. 높은 유사도는 관련 후보라는 신호이며, 그 문장이 사실이거나 정답이라는 증명은 아닙니다.

문서 벡터는 주로 수집·적재 과정에서 계산하고, 질문 벡터는 검색 요청 때 계산합니다. 모델에 따라 질문과 문서에 서로 다른 입력 형식이나 프롬프트가 필요합니다. 두 입력은 해당 모델이 정의한 검색 규약을 따라야 합니다.

벡터 차원 수가 같아도 서로 다른 모델의 벡터를 그대로 섞을 수는 없습니다. 모델, 리비전, 입력 형식, 정규화가 바뀌면 호환성을 확인하고 필요하면 재임베딩합니다. 모델 이름만 바꾸고 이전 인덱스를 계속 쓰면 검색 품질을 보장할 수 없습니다.

벡터 데이터베이스(Vector DB)는 벡터와 ID·메타데이터를 저장하고 유사도 검색을 제공합니다. 전용 제품뿐 아니라 기존 검색 엔진이나 데이터베이스가 이 기능을 제공할 수도 있습니다. Elasticsearch는 키워드 검색과 벡터 검색을 함께 제공합니다. Elastic의 검색과 랭킹 설명

정확한 최근접 이웃 검색과 근사 최근접 이웃 검색(ANN)은 탐색 비용과 재현율에서 차이가 납니다. ANN은 탐색 비용을 줄이는 대신 관련 후보 일부를 놓칠 수 있어 실제 데이터로 평가해야 합니다. 원본, 청크, 벡터를 서로 다른 저장소에 둔다면 안정적인 ID로 연결하고, 벡터만으로 원문을 복원하려고 설계하지 않습니다.

하이브리드 검색과 리랭킹

키워드 검색과 벡터 검색은 서로 다른 신호를 사용합니다. 오류 코드 ECONNREFUSED는 정확한 용어 일치가 중요하고, "접속이 계속 거부돼" 같은 질문은 비슷한 의미의 표현을 찾는 데 임베딩이 도움이 될 수 있습니다. 하이브리드 검색은 이런 신호를 결합합니다. Elastic의 하이브리드 검색 설명

RRF(Reciprocal Rank Fusion)는 여러 검색 목록에서 얻은 순위를 합치는 방법입니다. 한 후보의 점수는 그 후보가 등장한 목록마다 1 / (k + 순위)를 더하는 방식으로 계산할 수 있습니다. k는 순위의 영향도를 조절하는 상수이며, RRF 계산 자체는 생성 LLM을 호출하지 않습니다. Elastic의 RRF 설명

리랭킹은 검색으로 확보한 후보를 다시 평가합니다. 예를 들어 후보 50개를 찾은 뒤 상위 5개를 고를 수 있지만, 이 숫자는 설명용입니다. CrossEncoder 리랭커는 질문과 후보를 함께 입력받아 관련성을 평가합니다.

LLM으로 후보를 비교하는 방법도 있지만 모든 리랭킹이 생성 LLM을 사용하지는 않습니다. 추가 계산에 따른 지연과 실제 순위 개선을 함께 측정해야 합니다. 초기 검색에서 빠진 문서를 리랭킹만으로 복구할 수는 없습니다. Elastic의 의미 기반 리랭킹 설명

RAG가 답변을 만드는 과정

검색 증강 생성(RAG)은 외부 자료를 검색하고 선택한 근거를 생성 모델에 제공합니다. 질문, 근거 본문, 출처를 문맥으로 구성한 뒤 모델이 답변을 만듭니다. Lewis 등의 논문은 검색과 생성 모델을 결합한 대표적인 초기 연구입니다. RAG 원 논문

flowchart LR
    Q["질문"] --> S["관련 후보 검색"]
    S --> C["필요 시 리랭킹 · 중복 제거"]
    C --> P["근거 본문 · 출처로 문맥 구성"]
    P --> G["LLM 답변 생성"]
    G --> V["답변의 주장과 근거 대조"]

"이 프로젝트에서 리랭킹이 켜져 있습니까?"라는 질문에는 현재 설정이나 운영 상태를 확인한 근거가 필요합니다. 리랭킹의 일반 설명은 해당 프로젝트의 상태를 증명하지 못합니다. 과거 설정을 정확하게 설명한 문서라도 현재 상태에 대한 답에는 맞지 않을 수 있습니다.

답변 품질은 검색 성공, 문맥 구성, 생성의 근거 충실도를 나누어 확인합니다. 출처 링크가 있어도 그 문서가 모든 문장을 뒷받침하는 것은 아닙니다. 근거가 없거나 충돌하면 답변에도 그 한계를 반영해야 합니다.

에이전트의 판단과 도구 실행

워크플로는 개발자가 정한 경로에 따라 작업을 진행합니다. 에이전트는 모델이 상황과 도구 결과를 보고 다음 행동을 선택하는 비중이 큽니다. 한 시스템에서 두 구조를 함께 사용할 수 있습니다. Anthropic의 워크플로·에이전트 구분

flowchart TD
    USER["사용자 요청"] --> MODEL["모델이 다음 행동 선택"]
    MODEL --> CHECK["실행기가 인자 · 권한 · 제약 확인"]
    CHECK --> TOOL["검색 · 파일 · 외부 API 실행"]
    TOOL --> RESULT["결과 또는 오류 반환"]
    RESULT --> MODEL
    MODEL --> DONE["종료 조건 확인 후 결과 전달"]

모델이 search_knowledge를 호출하겠다는 데이터를 출력해도 실제 검색은 프로그램이 실행합니다. 실행기는 인자 형식과 권한을 검사하고, 오류 처리와 재시도 규칙을 적용합니다. 종료 조건과 중복 실행 방지도 실행 구조에 포함해야 합니다.

문서를 찾아 요약하고 초안을 저장하는 작업은 검색, 근거 읽기, 작성, 저장, 재조회로 이어집니다. 에이전트는 이 과정을 조정하고 실제 저장 결과를 확인할 수 있습니다. RAG는 그 안의 검색·생성 구성 요소가 될 수 있으며, 검색 후 답변만 하는 RAG가 반드시 에이전트인 것은 아닙니다.

API와 MCP로 기능 연결하기

API는 프로그램 사이의 호출 계약입니다. HTTP API에서는 주소, 메서드, 요청·응답 형식과 오류 처리가 계약에 포함됩니다. 임베딩, 생성, 검색은 각각 다른 기능을 노출합니다.

Ollama는 모델을 실행하고 API로 제공하는 런타임입니다. Model Context Protocol(MCP)은 AI 애플리케이션과 도구·자원 제공 서버를 연결하는 프로토콜입니다. 접근 정책과 실제 실행은 호스트와 서버 구현이 담당합니다. MCP 아키텍처

다음은 Ollama의 임베딩과 생성 요청 형식을 비교하는 설명용 JSON입니다. EMBEDDING_MODEL과 CHAT_MODEL은 설치한 모델 태그로 바꿀 자리 표시자입니다. 이 글에서 API 요청을 실행한 것은 아니며, 검색 입력은 선택한 모델의 규약에 맞춰야 합니다.

POST /api/embed는 입력별 벡터를 요청합니다. 응답의 embeddings에는 각 입력에 대응하는 숫자 배열이 들어갑니다. Ollama Embed API

{
  "model": "EMBEDDING_MODEL",
  "input": ["검색할 문서 내용", "사용자의 질문"]
}

POST /api/chat은 메시지를 입력받아 답변을 생성합니다. stream: false는 응답을 한 번에 받도록 지정합니다. Ollama Chat API

{
  "model": "CHAT_MODEL",
  "messages": [
    {
      "role": "user",
      "content": "근거: 예시 시스템은 BM25와 벡터 검색 결과를 결합합니다. 질문: 검색은 어떻게 구성됩니까? 제공된 근거로만 답하세요."
    }
  ],
  "stream": false
}

실제 RAG에서는 예시의 근거 문자열을 검색한 본문과 출처로 구성합니다. 생성 API 호출만으로 검색이나 출처 검증이 자동 수행되지는 않습니다. MCP로 검색 도구를 연결한 경우에도 결과를 읽고 답변에 사용하는 과정이 필요합니다.

데이터 모델과 지식그래프

데이터 모델링은 어떤 정보를 어떤 단위와 관계로 저장할지 정합니다. 문서와 청크를 구분해야 문서 전체의 버전과 개별 근거의 위치를 함께 관리할 수 있습니다. 개념에는 이름뿐 아니라 식별자, 유형, 별칭을 두어 동명이의어와 표현 차이를 다룹니다.

지식그래프는 개체나 개념과 그 관계를 저장합니다. "서비스 A가 저장소 B를 사용한다"는 관계를 원문 근거와 연결하면 저장된 관계를 따라 탐색할 수 있습니다. 문서에 이름이 함께 등장했다는 이유만으로 사용 관계를 만들어서는 안 됩니다.

벡터 검색은 관련 표현을 가진 후보를 찾고, 그래프 탐색은 명시적으로 저장된 관계를 따라갑니다. 그래프에서 얻은 관계·부분 그래프·요약을 생성의 근거로 쓰는 GraphRAG 설계도 가능합니다. 품질 개선 여부는 관계 추출 품질과 질문 유형으로 평가해야 하며, 관계 저장에 반드시 전용 그래프 DB가 필요한 것은 아닙니다.

온톨로지는 도메인의 개념 유형과 관계의 의미를 정의합니다. 예를 들어 software와 algorithm을 구분하고 implements가 어떤 관계인지 정할 수 있습니다. OWL은 온톨로지를 형식적으로 표현하는 표준 언어 중 하나이며, 모든 온톨로지가 OWL을 사용하는 것은 아닙니다. W3C OWL 2 Primer

애플리케이션은 유형과 관계 방향에 대한 검증 규칙을 별도로 적용할 수 있습니다. 유형 검사를 통과한 관계도 원문과 다를 수 있습니다. 관계의 구조를 검사하는 일과 원문이 그 관계를 뒷받침하는지 확인하는 일은 구분해야 합니다.

추출 모델이 제공한 confidence도 보정과 검증 없이는 진실의 확률로 취급할 수 없습니다. 관계에는 근거 청크와 입력 버전을 연결해야 합니다. 그래야 문서가 바뀌었을 때 이전 내용에서 만든 관계를 찾아 갱신할 수 있습니다.

personal-docs에 대응시키기

이 절은 원문 자료에 있는 2026-10-22 확인 기록을 요약합니다. 기준 커밋은 54bd65f3f529d41316c4d2bdcff66518e21349c9입니다. 이 글을 작성하면서 해당 프로젝트의 코드나 운영 환경을 다시 검사한 것은 아니므로, 아래 내용은 그 기록의 범위에서 읽어야 합니다.

personal-docs는 개인 지식 저장소(PKB)의 문서를 검색 도구로 제공하는 사례입니다. 원문은 문서 준비, 검색, 그래프 추출, 호스트 AI의 답변 생성을 구분합니다. 이를 위에서 설명한 구성에 대응시키면 다음과 같습니다.

원문이 인용한 코드는 고정 커밋의 문서 처리, 검색, 그래프 처리 디렉터리에 있습니다. 링크를 읽으려면 저장소 접근 권한이 필요할 수 있습니다.

기록상 graph_query는 이름·별칭과 임베딩으로 시작 개념을 찾고 저장된 관계를 확장합니다. 결과의 evidence는 원문 본문이 아니라 doc_id, chunk_index 같은 위치 정보입니다. 실제 근거 문장을 확인하려면 get_document의 chunk_range로 해당 청크를 읽어야 합니다.

원문에는 Windows Ollama의 시험 요청 성공도 기록돼 있습니다. 그러나 Mac의 curl 요청 성공과 별개로 프로젝트 Python에서는 No route to host가 관찰됐습니다. 이 기록으로 전체 문서 처리의 안정성이나 프로젝트 연결 완료를 주장할 수는 없습니다.

모델 서버가 응답하는지, 애플리케이션에서 접근할 수 있는지, 실제 처리 경로가 그 서버를 사용하는지는 각각 확인해야 합니다. 문서 수집이 끝났다는 사실도 모든 개념과 관계의 추출 완료를 뜻하지 않습니다. 각 단계의 상태를 따로 기록해야 완료 범위를 설명할 수 있습니다.

단계별로 검증하기

문서 파이프라인의 모든 단계가 생성 LLM을 사용하는 것은 아닙니다. 파일 파싱, 해시 계산, BM25, RRF, 유형 검사는 일반 코드나 검색 알고리즘으로 처리할 수 있습니다. 임베딩과 리랭킹에 모델을 쓰더라도 생성 모델과 역할을 구분합니다.

운영 PDF에서 장애 대응 절차를 찾는다면 먼저 표와 페이지가 제대로 추출됐는지 확인합니다. 다음으로 질문에 필요한 절이 청크에 남았는지, 검색 후보에 들어왔는지, 모델이 그 근거를 사용했는지 차례로 확인합니다. 표가 잘못 파싱됐다면 생성 프롬프트나 임베딩 모델만 바꿔도 원래 관계가 복원되지는 않습니다.

성능도 파싱, 임베딩, 검색, 생성으로 나누어 측정합니다. 임베딩 처리량은 청크 수·길이·배치 구성의 영향을 받고, 생성 시간은 입력·출력 길이와 모델 적재 상태 등의 영향을 받습니다. 짧은 시험 요청 한 번으로 전체 문서 처리 시간을 단정할 수 없습니다.

검색 재현율과 순위 품질, 답변의 근거 충실도, 단계별 지연과 실패율은 서로 다른 지표입니다. 하나의 모델 점수로 전체 시스템의 품질을 대신하지 않습니다. 세부 검색 구조는 DPR 기반 밀집 검색과 크로스 인코더 재순위에서 이어서 볼 수 있습니다.

정리

AI 지식 시스템은 원본 문서에서 검색 단위와 근거를 만들고, 이를 질문과 연결해 답변이나 작업 결과를 제공합니다. 파싱, 청킹, 임베딩, 검색, 생성은 서로 다른 역할을 맡으며 각 단계의 입력과 출력을 확인해야 합니다. 지식그래프와 에이전트도 필요한 질문과 작업에 맞춰 추가합니다.

RAG는 검색한 근거를 생성 모델에 제공하지만 답변의 정확성을 자동으로 보장하지 않습니다. 관계 유형이 맞거나 API 요청이 성공했다는 사실만으로 원문 충실도나 전체 처리 완료를 판단할 수도 없습니다. 품질과 완료 여부는 원본 근거, 실제 사용 경로, 단계별 검증 결과로 설명해야 합니다.