ENPROJECT OVERVIEW
올린 문서를 LLM이 Wiki로 정리하고, RAG로 원문 근거를 찾아 답하거나 자연어로 문서를 편집하는 AI 워크스페이스입니다. 지금은 AWS EKS에 배포해 QA를 진행하고 있습니다.
팀원이 겪던 문서 관리의 불편함을 디자인 싱킹으로 구체화하며 시작했습니다. 문서를 저장만 해 두고 정작 필요할 때 찾지 못하는 불편을 없애는 게 목표였습니다.
Python 기반 PDF 변환, Wiki 생성, RAG 검색과 근거 답변, 문서 편집 Agent 등 AI 서비스
팀 발표 자료의 서비스 화면과 구조입니다. 각 설명에 제 담당 범위를 표시했습니다. 이미지를 누르면 원본 크기로 볼 수 있습니다.
CASE 01 AI Agent, RAG, Jev
Fruition은 사용자가 올린 문서를 근거로 답하는 서비스라, 근거가 틀리면 답변 전체를 믿을 수 없게 된다고 생각했습니다. 앞서 요청을 질문, 편집 등으로 분류하는 라우팅에서 Jev의 정확도와 속도 개선을 확인했고, 이를 계기로 답변 근거 선택에도 적용해 근거 충족률을 66.25%에서 91.25%로 높였습니다. 늘어난 처리 시간은 후보 수와 병렬 처리 조정으로 줄였습니다.
CASE 02 AI Agent, 사용자 정의 Skill, HITL, Prompt Injection
회의록 생성과 같이 반복되는 작업을 사용자가 직접 정의하고 재사용할 수 있도록 Agent Skill을 구현했습니다. 다만 AI가 바꾼 문서를 사용자가 매번 믿을 수 있어야 한다고 생각해, 검사, 게시, 변경 승인을 한 흐름으로 설계했고 구현은 AI 코딩 도구로 진행했습니다.
CASE 03 AI Agent, 보상 복구, 감사 이력
AI가 문서를 바꾸는 서비스에서 취소가 확실하지 않으면, 사용자는 AI에게 작업을 맡길 수 없다고 생각했습니다. 실행만 멈추면 이미 저장한 문서, 폴더, Wiki, Skill 변경이 그대로 남아, 커밋한 변경까지 역순으로 되돌리는 경로를 만들었습니다. 이때 다른 작업이 정상적으로 남긴 기여는 지우지 않도록, 대상 기여만 빼고 복원했습니다.
CASE 04 PDF 문서 변환, 데이터 파이프라인
주로 PDF로 제공되는 논문을 지식으로 활용하려면, Markdown으로 변환할 때 표의 수치와 수식이 먼저 보존돼야 했습니다. 이를 위해 변환 결과를 AI로 고치는 과정에서 생기는 누락을 추적하고, 원본 배치와 내용 유형에 맞춰 처리 경로를 나눴습니다.
CASE 05 Kafka 비동기 병렬 처리, AI 파이프라인
문서를 활용한 Wiki 생성이 순차 처리로 구성되어 있어, 대형 문서의 Wiki 생성 시 처리 시간이 증가해 사용자의 부정적 경험을 우려했습니다. 이에 Worker를 늘린 효과와 자원 사용을 확인하고, 문서 분석과 벡터 생성에 서로 다른 확장 기준을 세웠습니다.
CASE 06 코딩 에이전트 운용, MSA 전환
MSA 전환을 일주일 안에 마쳐야 일정대로 배포하고 피드백을 받을 수 있었습니다. 사람이 직접 하기엔 시간이 부족하다고 판단해 이식은 코딩 에이전트에 맡기고, 저는 작업 계획과 검토 기준을 정하고 병합을 판단했습니다. 순서와 우선순위는 조정 에이전트가 관리하도록 루프를 구성했습니다.