AIOEnterprise AI 지식 관리 시스템

프로젝트를 다시 정의하면

기존 설명은 “Hybrid RAG 플랫폼”이라는 방향은 맞았지만, 실제 소스가 보여주는 제품 범위에 비해 너무 좁았습니다. /Users/mean/Downloads/AIO의 백엔드와 프론트엔드를 기준으로 보면 AIO의 핵심은 다음 네 가지를 한 화면 흐름 안에 묶는 데 있습니다.

서비스 표면

AIO는 별도의 기능 데모 모음이 아니라 하나의 운영 콘솔입니다.
프론트엔드 라우팅을 보면 /aio/knowledgeArchive, /aio/knowledgeArchive/:id/dataset, /aio/knowledgeArchive/:id/config, /aio/playground, /aio/agent/graph, /aio/document/public, /aio/document/private, /aio/setting/account/*, /aio/setting/aiModel이 같은 로그인 세션 위에서 동작합니다.

백엔드는 이 화면들을 main.py의 FastAPI application에서 knowl, dataset, config, agent, sse, roles, permissions, acl, account, folder, doc, ai-model, dictionary, conversation router로 나눠 받습니다.
이 분리는 화면 단위와 운영 책임이 거의 일대일로 대응되기 때문에, 프로젝트를 설명할 때 “RAG 엔진”보다 “엔터프라이즈 지식 운영 플랫폼”으로 말하는 편이 정확합니다.

문서가 지식이 되는 경로

문서 처리는 사용자가 파일을 올리는 순간부터 ingestion 작업이 끝날 때까지 긴 비동기 흐름입니다.
프론트엔드의 uploadApi.js는 /doc/upload/begin으로 업로드 세션을 만들고, 파일을 chunk 단위로 전송하며, /subscribe/progress/doc/uploads EventSource로 진행률을 받습니다.
브라우저 쪽에는 IndexedDB 기반 upload queue와 heartbeat cleanup이 있어 새로고침이나 장시간 업로드 상황도 고려합니다.

백엔드의 DocService는 session id, chunk id, file hash, size, count, duplication을 검증하고 Celery finalize_upload_file 작업으로 최종 파일 병합과 문서 레코드 저장을 처리합니다.
이후 DatasetService가 /dataset/ingestion 요청을 받아 DataIngestionTaskProvider와 CeleryTaskLauncher를 통해 dataset ingestion job을 시작합니다.
진행률은 Redis task progress와 /subscribe/progress/dataset/ingestion SSE로 다시 화면에 전달됩니다.

이 구조의 장점은 업로드, 문서 메타데이터, dataset ingestion, 검색 인덱싱이 서로 다른 실패 지점과 재시도 단위를 갖는다는 점입니다.
대용량 문서 처리에서 API request 하나에 모든 일을 묶지 않고, 사용자에게는 진행 상태를 계속 보여주면서 worker 계층에서 오래 걸리는 작업을 처리합니다.

Graph + Vector RAG

AIO의 검색은 “문서를 chunk로 나눠 벡터 검색한다”에서 멈추지 않습니다. core/kg/milvus_vector_storage.py는 지식 저장소별로 {knowl_id}_chunks, {knowl_id}_entities, {knowl_id}_relationships, {knowl_id}_plan2do_chunks collection을 사용합니다.
특히 Plan2Do chunk에는 content_vector, title_vector, domain_vector, structure_vector 같은 다중 벡터 필드가 있어 질의 목적별 검색 신호를 분리할 수 있습니다.

core/graph/graph_query.py와 service/agent_service.py는 Milvus vector search와 Neo4j graph query를 엮어 local, global, hybrid, mix, naive 검색 모드를 제공합니다.
검색 모드가 분리되어 있으므로 단순 QA, 관계 중심 탐색, 문서 내용 중심 검색, graph context가 필요한 질문을 다른 전략으로 처리할 수 있습니다.

검색 계층	소스 기준 역할	제품 가치
Milvus chunks	문서 chunk와 embedding 검색	질문과 의미적으로 가까운 근거 문단을 빠르게 찾습니다.
Milvus entities / relationships	entity, relationship vector 검색	문서에서 추출한 구조적 단서를 벡터 검색에 포함합니다.
Neo4j graph	entity 관계와 graph traversal	단순 유사도 검색으로 놓치는 연결 관계를 추적합니다.
PostgreSQL metadata	knowl, dataset, doc, chunk, answer schema	권한, 상태, 출처, 이력 같은 운영 데이터를 보존합니다.

Agent Workflow Builder

프론트엔드의 AgentGraphPage.vue는 Vue Flow canvas를 사용해 agent workflow를 시각적으로 구성합니다. workflowSerializer.js는 화면의 node와 edge를 백엔드가 이해하는 JSON spec으로 변환하고, spec 안에는 layer1, layer2, layer3, metadata, node data, edge 연결 정보가 포함됩니다.

백엔드에서는 core/agent/agent_factory.py가 YAML 또는 JSON spec을 읽어 LangGraphAgent를 만들고, core/agent/graph.py가 node type을 LangGraph StateGraph에 매핑합니다. pre retrieval, retrieval, post retrieval, generation, Plan2Do, data ingestion 계층이 node로 추상화되어 있어, 고정된 RAG chain 하나가 아니라 업무 목적별 agent graph를 구성할 수 있습니다.

권한과 운영 경계

기업 지식 플랫폼에서 중요한 부분은 “누가 어떤 문서와 지식 저장소를 볼 수 있는가”입니다.
AIO는 로그인 시 bcrypt password 검증과 JWT 발급을 수행하고, role/permission/ACL을 별도 schema와 router로 관리합니다. permission_evaluator.py에는 READ, WRITE, DELETE, FULL bitmask와 Redis ACL cache가 정의되어 있으며, API dependency에서 현재 사용자의 permission context를 평가합니다.

이 권한 모델은 단순 관리자 기능이 아니라 RAG 품질과 보안에 직접 연결됩니다.
검색 인덱스가 잘 만들어져도 사용자가 접근할 수 없는 문서가 답변 근거에 섞이면 엔터프라이즈 시스템으로 사용할 수 없습니다.
AIO는 계정, 역할, 권한, ACL, 공용/개인 문서 저장소를 같은 운영 흐름에서 다루도록 설계되어 있습니다.

코드 기준 기술 소스맵

영역	대표 파일	확인한 구현
API composition	AIO-main/main.py	FastAPI app 생성, CORS, router 등록, RDB 초기화 흐름
문서 업로드	service/doc_service.py, router/doc_router.py	upload begin, chunk upload, finalize task, refer page extraction
데이터셋 ingestion	service/dataset_service.py, router/dataset_router.py	ingestion task 시작, task status mapping, SSE progress
검색 저장소	core/kg/milvus_vector_storage.py	chunk/entity/relationship/Plan2Do collection과 multi-vector schema
Graph query	core/graph/graph_query.py	local/global/hybrid/mix 검색 전략과 Neo4j 연동
Agent runtime	core/agent/agent_factory.py, core/agent/graph.py	JSON/YAML spec 기반 LangGraphAgent 생성과 StateGraph node mapping
권한	service/account_service.py, core/permission_evaluator.py	JWT, role permission, ACL bitmask, Redis permission cache
프론트 라우팅	AIO-Front-main/src/router/index.js	knowledge archive, dataset, config, playground, setting, document, agent graph route
업로드 UX	AIO-Front-main/src/api/uploadApi.js	chunk upload, EventSource progress, upload background manager
Agent 편집	AIO-Front-main/src/pages/agent/AgentGraphPage.vue, utils/workflowSerializer.js	Vue Flow graph editing과 backend workflow spec 직렬화

API와 화면별 기능 매트릭스

사용자 화면	연결 API / 서비스	의미
Knowledge Archive	knowl, dataset, config	지식 저장소를 만들고 dataset/config/playground로 확장합니다.
Document Storage	doc, folder, upload SSE	공용/개인 문서를 업로드하고 폴더 단위로 관리합니다.
Dataset Page	dataset/ingestion, dataset progress SSE	문서를 지식화 작업으로 넘기고 indexing 상태를 확인합니다.
Playground	agent, conversation	지식 저장소와 agent 설정을 실제 질문 답변으로 검증합니다.
Agent Graph	agent, workflow serializer	업무 목적별 LangGraph workflow를 시각적으로 구성합니다.
Settings	account, roles, permissions, acl, ai-model	사용자, 권한, 모델 접속 정보를 운영자가 관리합니다.

검증과 한계

이번 문서는 저장소 소스를 기준으로 다시 작성했습니다.
백엔드는 실제 router/service/core 구현을, 프론트엔드는 route/page/API client를 기준으로 제품 기능을 매핑했습니다.
다만 이 포트폴리오 페이지에서는 보안상 내부 업무 데이터, 실제 운영 데이터, 모델 API key, 고객사별 설정값은 다루지 않았습니다.

결과적으로 AIO는 “문서 기반 RAG”보다 넓은 프로젝트입니다.
문서 저장소, 비동기 ingestion, graph/vector retrieval, agent workflow, ACL 운영이 결합된 엔터프라이즈 AI 지식 관리 시스템이며, 이 페이지는 그 구조를 코드 근거 중심으로 설명하도록 재정리했습니다.