지식 관리를 위한 AI: 실제로 작동하는 워크플로우

AI는 지식 관리 (Knowledge Management)를 대체하는 것이 아니라, 개인과 팀 모두를 위해 그 형태를 변화시키고 있습니다.

Microsoft의 Work Trend Index는 인간과 에이전트 (Agents)가 결합된 하이브리드 팀으로의 이동을 설명하며, NIST의 AI RMF는 신뢰할 수 있는 AI 시스템이 모호한 자동화보다는 명시적인 역할, 평가 및 감독이 필요하다고 주장합니다. 이러한 아이디어들은 어떤 모델이 개입하기 훨씬 전부터 도구와 방법에 집중하는 이 사이트의 2026년 지식 관리 기둥 (Knowledge Management in 2026 pillar) 내 인간 중심적 관행과 잘 맞닿아 있습니다.

이것이 바로 지식 노동 (Knowledge work)에 대한 정확한 프레임워크입니다. AI는 구조 없이 작동하는 마법 같은 제2의 뇌가 아니라, 노트, 문서 (Docs), 런북 (Runbooks), 그리고 연구 자료 위에 얹혀진 풍부화 계층 (Enrichment layer)으로 취급될 때 가장 효과적입니다. 유용한 멘탈 모델은 PKM vs RAG vs Wiki vs Memory Systems에서 개발된 것으로, 여기서 인간의 노트 시스템, 공유 위키 (Wikis), 검색 파이프라인 (Retrieval pipelines), 그리고 에이전트 메모리 (Agent memory)는 하나의 도구로 통합되는 대신 각각 고유한 역할을 수행합니다.

약간의 주관적인 견해를 덧붙이자면 다음과 같습니다. 만약 당신의 노트가 혼란스럽다면, AI는 그것을 구원하지 못할 것입니다. 오히려 그 혼란을 더 유창하게 만들 뿐입니다. 훌륭한 지식 관리는 여전히 캡처 (Capture), 명명 (Naming), 소유권 (Ownership), 그리고 출처 규율 (Source discipline)에서 시작됩니다. AI가 변화시키는 것은 캡처 이후에 당신이 할 수 있는 일들입니다. 즉, 정보를 유용한 속도로 압축 (Compress), 추출 (Extract), 연결 (Link), 검색 (Retrieve) 및 재포장 (Repackage)하는 것입니다. 이러한 관점은 작고 범위가 명확한 작업을 권장하는 현대적인 프롬프팅 (Prompting) 가이드라인과, 모든 것을 하나의 덩어리로 평탄화하는 대신 검색을 위해 의미론적 단위 (Semantic units)를 보존하는 청킹 (Chunking) 가이드라인 모두와 일치합니다.

왜 AI가 지식 관리를 변화시키는가

핵심적인 변화는 정적인 아카이브 (Static archives)에서 능동적인 메모리 (Active memory)로의 전환입니다. 임베딩 (Embeddings)은 텍스트를 관련성을 반영하는 벡터 (Vectors)로 변환하며, 이는 검색 (Search), 클러스터링 (Clustering), 추천 (Recommendations)에 흔히 사용됩니다. 이를 통해 검색 시스템은 쿼리 (Query)가 원문과 공유하는 키워드가 거의 없거나 전혀 없더라도 의미론적으로 유사한 자료를 찾아낼 수 있습니다. 실질적인 관점에서 이는 "장애 검토 (incident review)"에 관한 노트가 경직된 정확한 일치 (Exact-match) 규칙 없이도 "배포 후 중단 단계 (post-deployment outage steps)"라는 제목의 런북 (Runbook) 청크 (Chunk)를 찾아낼 수 있음을 의미합니다.

이것이 바로 AI로 강화된 지식 관리 (AI-augmented knowledge management)를 지금 실행할 가치가 있는 이유입니다. 이를 가능하게 하는 요소들은 더 이상 생소하지 않습니다. 임베딩 API (Embedding APIs)는 주류가 되었고, 벡터 저장소 (Vector stores)는 표준이 되었으며, 로컬 임베딩 모델 (Local embedding models)은 실행하기 쉽습니다. 또한 Postgres와 같은 프로덕션 데이터베이스 (Production databases)는 pgvector를 통해 정확한 근접 이웃 검색 (Exact nearest-neighbour search)과 근사 근접 이웃 검색 (Approximate nearest-neighbour search)을 모두 수행할 수 있습니다. 그 결과는 철학적 의미에서의 인공 지식이 아닙니다. 훨씬 더 실용적인 것, 즉 누군가가 사고가 필요한 순간에 더 나은 회상 (Recall), 더 나은 압축 (Compression), 그리고 더 나은 컨텍스트 (Context)를 제공하는 것입니다. 특히 Retrieval vs Representation in Knowledge Systems와 같은 작업에서 얻은 견고한 표현 (Representation) 선택과 결합될 때 더욱 그러합니다. 다음 단계가 구현 세부 사항이라면, RAG cluster에서 청킹 (Chunking), 검색 (Retrieval), 재순위화 (Reranking), 그리고 프로덕션 패턴 (Production patterns)을 심도 있게 다룹니다.

실제로 작동하는 워크플로우 패턴 (Workflow patterns that actually work)

실제 운영 환경에서 견고하게 작동하는 패턴들은 가장 좋은 의미에서 '지루한' 것들입니다. 이들은 모호한 자율성 (autonomy)이 아니라, 제한된 범위 내의 변환 (bounded transformations)을 위해 AI를 사용합니다. 실제로 세 가지 패턴이 반복해서 나타납니다: 요약 (summarisation), 추출 (extraction), 그리고 연결 제안 (linking suggestions)입니다. 이들은 현재 도구들이 잘 수행하는 작업들과 깔끔하게 매칭됩니다: 명확한 범위 내에서의 요약, 스키마 (schemas)를 통한 구조화된 데이터 추출, 그리고 임베딩 (embeddings)과 검색 (retrieval)을 통한 의미적 관련성 (semantic relatedness) 계산입니다. 또한, 이는 second brain workflows 및 LLM Wiki style compiled knowledge와 같은 개념 이면에 있는 지식 시스템의 계층적 관점과도 명확하게 일치합니다.

의사결정을 보존하는 요약 (Summaries that preserve decisions)

요약은 소스에 밀착되어 있으며, 나중에 인간에게 실제로 필요한 부분들, 즉 의사결정 (decisions), 미결 질문 (unresolved questions), 담당자 (owners), 날짜 (dates)

재사용 가능한 필드를 생성하는 추출 (Extraction)

추출 (Extraction)은 AI가 진정으로 인프라적인 역할을 하기 시작하는 지점입니다. 단순히 산문 (prose) 형태만 저장하는 대신, 모델에게 엔티티 (entities), 시스템 (systems), API, 담당자 (owners), 실행 항목 (action items), 제품 (products), 날짜 (dates), 주장 (claims), 또는 리스크 태그 (risk tags)와 같이 재사용 가능한 필드를 채우도록 요청하는 것입니다. OpenAI의 구조화된 출력 (Structured Outputs) 기능은 응답을 JSON 스키마 (JSON Schema)에 맞게 유지하도록 설계되었으며, Ollama는 스키마 기반의 JSON 출력을 통해 로컬에서도 동일한 패턴을 제공합니다. 이것이 중요한 이유는 유용한 지식 시스템은 단순히 그럴듯하게 들리는 문단이 아니라, 정렬, 필터링, 비교 및 검증이 가능한 필드들로 구성되기 때문입니다.

OpenAI의 긴 문서 엔티티 추출 (long-document entity extraction) 예시는 올바른 운영 패턴을 따릅니다. 즉, 문서를 청크 (chunk)로 나누고, 각 청크에서 관련 사실을 추출한 다음, 결과들을 결합하는 방식입니다. 이와 동일한 워크플로우 (workflow)는 사후 분석 보고서 (postmortems), 연구 논문 (research papers), 제품 문서 (product docs), 고객 인터뷰 (customer interviews), 그리고 지원 상담 기록 (support transcripts)에도 적용될 수 있습니다. 실제로 저는 명명된 엔티티 (named entities) 이상의 것을 추출할 것입니다. 저는 "후속 조치 필요 (needs follow-up)", "기존 노트와 모순됨 (contradicts existing note)", "에버그린 노트 후보 (candidate for evergreen note)"와 같은 항목들도 추출할 것인데, 이러한 필드들이 단순한 메타데이터 (metadata)를 넘어 실행 (action)을 만들어내기 때문입니다.

{
  "source_id": "note-2026-05-22-incident-review",
  "summary": "여기에 짧은 요약.",
...

노트를 그래프로 변환하는 연결 (Linking)

연결 제안 (Link suggestions)은 지식 관리를 위한 AI의 조용한 일꾼입니다. 임베딩 (Embeddings)은 검색 (search), 클러스터링 (clustering), 그리고 추천 (recommendations)을 위해 명시적으로 사용되며, 이는 관련 노트 (related notes), 유사한 사고 (similar incidents), '함께 보기 (see also)', 그리고 '두 문서 병합 (merge these two docs)' 기능에 자연스럽게 부합합니다. 의미론적 검색 (Semantic retrieval)은 표현 방식이 다르더라도 개념적으로 관련된 콘텐츠를 찾아내는 데 특히 탁월합니다. 덕분에 대규모 노트 세트와 기술 문서 (technical documentation)를 다룰 때 단순한 폴더 계층 구조 (folder hierarchies)보다 훨씬 더 뛰어난 성능을 발휘합니다.

하지만 밀집 의미 검색 (Dense semantic search)이 유일한 검색 신호 (retrieval signal)가 되어서는 안 됩니다. 함수 이름, 패키지 이름, 이슈 ID, 에러 코드, SKU, 규정 번호와 같은 정확한 식별자 (Exact identifiers)는 여전히 중요합니다. Google Research는 의미론적 신호 (semantic signals)와 어휘적 신호 (lexical signals)를 결합한 하이브리드 검색 (hybrid retrieval)이 재현율 (recall)을 향상시킨다는 것을 보여주었는데, 이는 각 방법이 상대방이 놓치는 관련 자료를 찾아내기 때문입니다. 기술 지식 베이스 (technical knowledge base)에서 이것은 단순한 학술적 세부 사항이 아닙니다. 개념적으로 관련된 설계 노트를 찾는 것과, 새벽 2시에 누군가에게 꼭 필요한 정확한 마이그레이션 명령어를 찾는 것 사이의 차이입니다.

이미 Postgres를 사용 중이라면, pgvector가 실용적인 선택지입니다. pgvector는 나머지 데이터와 함께 벡터를 저장하며, 기본적으로 정확한 검색 (exact search)을 지원합니다. 또한 더 빠른 속도가 필요하고 약간의 재현율 (recall) 저하를 감수할 수 있는 경우, HNSW 및 IVFFlat을 통해 근사 인덱싱 (approximate indexing)을 제공합니다. 이는 첫날부터 별도의 벡터 데이터베이스 (vector database)를 추가하지 않고도 관련 콘텐츠 추천, 의미 검색, 노트 중복 제거 기능을 구축하기에 충분합니다.

인간과 AI의 루프 (The human plus AI loop)

실제로 작동하는 모델은 인간 혹은 AI 중 하나가 아닙니다. 그것은 '캡처(capture) -> AI 강화(AI enrich) -> 인간 정제(human refine)'입니다. Microsoft는 이러한 광범위한 변화를 인간이 어시스턴트(assistants)와 협업하고, 나아가 에이전트 팀(agent teams)과 협업하는 과정으로 설명합니다. 반면 NIST의 AI RMF 및 플레이북 (Playbook)은 인간-AI 구성 (human-AI configurations)에서 명확하게 정의된 인간의 역할, 책임 및 감독을 강조합니다. 지식 관리 (knowledge management) 측면에서 이는 인간이 정전 (canonical note), 즉 진실의 원천 (source of truth)과 최종 병합 또는 게시 결정에 대해 책임을 진다는 것을 의미합니다. AI는 1차 압축 (first-pass compression)과 교차 링크 (cross-linking)를 수행하고, 인간은 판단 (judgement)을 수행합니다.

capture -> parse -> chunk -> embed -> enrich -> review -> publish
             |         |        |
             |         |        +-> related notes
...

이러한 분업은 단순히 신중한 프로세스 설계 그 이상입니다. 이는 리스크가 축적되는 방식과 일치합니다. NIST는 인간-AI 상호작용 (human-AI interaction)의 한계를 이해하는 것이 AI 리스크 관리 (AI risk management)를 개선하며, 감독과 사용의 역할이 명확하게 구분되어야 한다고 언급합니다. 실제로 이는 모델이 제목, 태그, 요약 및 후보 링크를 초안할 수는 있지만, 분류 체계 (taxonomy)를 변경하거나, 외부 콘텐츠를 게시하거나, 기존 노트를 덮어쓰는 모든 작업은 반드시 사람이 승인해야 함을 의미합니다. 만약 모델이 당신의 지식 베이스 (knowledge base)를 조용히 재작성하도록 방치한다면, 당신은 기억을 구축하는 것이 아닙니다. 당신은 편집권 (editorial control)을 확률적 시스템 (probabilistic system)에 외주 주는 것입니다.

중요한 도구 선택

기본 레이어는 임베딩 (embeddings)과 검색 (retrieval)입니다. OpenAI의 임베딩은 텍스트 문자열 간의 관련성을 측정하는 방법으로서 프레임 임베딩 (frames embeddings)을 안내하며, 검색 API (Retrieval API)는 벡터 저장소 (vector stores)를 통해 데이터에 대한 시맨틱 검색 (semantic search)을 처리합니다. 많은 팀에게 이것은 AI 증강 지식 관리 (AI-augmented knowledge management)를 위한 최소 기능 스택 (minimum viable stack)입니다: 콘텐츠를 파싱 (parse)하고, 잘 청킹 (chunk)하고, 임베딩 (embed)한 다음, 합성 (synthesis) 전에 적절한 파편들을 검색 (retrieve)하는 것입니다. 이번 분기에 단 한 가지 중요한 일을 한다면, 가공되지 않은 문서 위에 얹은 채팅 래퍼 (chat wrapper) 대신 검색 기반의 회상 (retrieval-backed recall)을 구축하십시오.

개인정보 보호, 오프라인 사용 또는 비용 제어가 우선시될 때는 로컬 모델 (Local models)이 정답입니다. Ollama는 로컬 임베딩 (local embeddings)과 구조화된 출력 (structured outputs)을 모두 지원하며, 제품 페이지에서는 데이터가 귀하의 소유로 유지되고 워크로드 (workloads)가 완전히 오프라인에서 실행될 수 있음을 강조합니다. 이는 내부 노트, 엔지니어링 런북 (engineering runbooks), 민감한 연구 아카이브에 로컬 우선 파이프라인 (local-first pipelines)을 사용하는 것이 합리적임을 보여줍니다. 저의 견해는 간단합니다: 인덱싱 (indexing), 분류 (classification), 일상적인 풍부화 (routine enrichment)에는 로컬 모델을 사용하고, 더 강력한 추론 (reasoning), 멀티모달 추출 (multimodal extraction) 또는 사용 가능한 최고의 모델 품질이 필요할 때는 호스팅된 API (hosted APIs)를 활용하십시오.

파싱 (parsing)과 청킹 (chunking)을 무시하지 마십시오. Unstructured의 청킹 문서는 가능한 경우 원시 문자 경계 (raw character boundaries)보다는 의미론적 문서 요소 (semantic document elements)로부터 청크를 구축할 것을 권장하며, OpenAI의 PDF 쿡북 (cookbook)은 왜 풍부한 문서 파싱 (rich-document parsing)이 RAG (Retrieval-Augmented Generation)에 중요한지를 보여줍니다. 구조 인식 (structure-aware) PDF 작업은 한 단계 더 나아갑니다. 단순한 파싱 (naive parsing)은 표를 파괴하고, 읽기 순서를 뒤섞으며, 계층적 헤딩 (hierarchical headings)을 제거할 수 있는 반면, 구조 인식 파싱 (structure-aware parsing)은 단락, 표, 그리고 문서 계층 구조를 보존합니다. 지식 관리 (knowledge management)에서 이는 여러분의 코퍼스 (corpus)를 이해하는 인덱스와 단순히 토큰화 (tokenise)만 하는 인덱스의 차이입니다.

존중해야 할 한계점들

환각 (Hallucination)은 여전히 명백한 위험이지만, 더 유용한 프레임워크는 불충분한 컨텍스트 (insufficient context)입니다. RAG가 존재하는 이유는 대규모 언어 모델 (LLM)이 환각을 일으키고, 오래된 지식을 사용하며, 추적 가능성이 낮은 답변을 생성할 수 있기 때문이며, 검색 (retrieval)은 외부 지식에 생성 과정을 근거하게 함으로써 이를 돕습니다. 그럼에도 불구하고, Google Research는 제공된 컨텍스트가 충분하지 않을 때 모델이 답변을 유보하는 대신 종종 부정확하게 답변한다는 사실을 발견했습니다. 이는 지식 관리에서 매우 중요한데, "유사한 것을 찾았습니다"는 "답변할 만큼 충분한 것을 찾았습니다"와 같지 않기 때문입니다. 여러분의 시스템은 출처 참조 (source references)를 보존하고, 불확실성을 드러내며, 자신감 있게 꾸며내는 것보다 답변을 유보하는 것을 선호해야 합니다.

긴 컨텍스트 (Long context)가 검색 규율 (retrieval discipline)의 필요성을 없애지는 않습니다. 2023년 "Lost in the Middle" 논문은 관련 정보가 긴 입력값의 중간에 위치할 때 모델의 성능이 저하될 수 있음을 보여주었으며, 최신 Google의 연구 결과는 적어도 일부 최신 모델들이 컨텍스트 제한 근처에서의 단순한 '건초더미 속 바늘 찾기 (needle-in-a-haystack)' 검색 성능을 상당히 개선했음을 보여줍니다. 냉철한 교훈은 "긴 컨텍스트가 문제를 해결한다"거나 "긴 컨텍스트는 쓸모없다"가 아닙니다. 위치 효과 (position effects), 작업 유형 (task type), 그리고 문서 구조가 여전히 중요하다는 점을 고려하여, 여러분의 실제 워크플로우 (workflows)와 코퍼스 (corpus)를 테스트해야 한다는 것입니다.