[스나이퍼팩토리] 한컴AI 2기 - 알랭 서비스 통합

아키텍처 흐름도

2차멘토링과 중간발표에서 사용자 흐름에 따른 데이터 이동에 대한 질문을 받았었다. 말로 설명했지만 충분한 전달이 이뤄지지 않았는데, 결국 그림이 필요했다. gemini3.0이 공개되고, 나노 바나나 프로가 사용가능해진 타이밍이 실로 적절했다. 우리의 서비스에 대한 설명을 기반으로 이미지를 만들어달라고 했더니, 꽤 그럴싸하게 만들어줬다. 해당 이미지에서 몇가지 수정 또한 프롬프팅으로 가능했다.

 

비동기 문서 업로드 파이프라인과 질의 응답 파이프라인은 서비스의 중요한 축이고, 전체 흐름도로부터 별도로 보여줄 필요가 있었다.

문서 업로드 흐름도

사용자 → 프론트엔드에 문서 업로드 → 백엔드 FastAPI로 전달 → Celery 워커의 처리(파싱-청킹-임베딩) → DB 의 흐름이 잘 표현되었다.

사용자 질의응답 시나리오

사용자 → 프론트엔드에 질문 → 백엔드 FastAPI로 전달 → 사전필터링과 임베딩 → 벡터DB에서의 검색 → LLM의 응답 까지의 흐름이 역시 잘 표현되었다.

---

환경 분리(Docker Profile)

이 모든 과정이 하나의 파이프라인으로 자동화되어 있고, Docker 환경에서 각 서비스가 독립적으로 동작하면서도 유기적으로 연결되어 있다. 각 도커 프로필의 역할은 다음과 같다.

1. Redis (Message Broker)

• 역할: 비동기 작업 큐(Task Queue)를 관리하는 메시지 브로커.
• 학습: API 서버와 워커 사이의 결합도를 낮추는 핵심 미들웨어다. API가 요청받은 무거운 작업을 Redis 큐에 넣어두면(Push), 워커가 상황에 맞춰 가져가서(Pull) 처리한다. 덕분에 트래픽이 몰려도 요청이 유실되지 않고 큐에 안전하게 쌓인다.

2. FastAPI (API Server)

• 스펙: FastAPI, Port 8000
• 역할: 사용자 요청 수신, 파일 저장, Task 발행, 상태 조회.
• 학습: 무거운 연산(임베딩 등)은 직접 하지 않고 '접수창구' 역할에만 집중하도록 설계했다. 덕분에 동시 접속자가 많아져도 메인 스레드가 차단되지 않고 즉각적인 응답(Non-blocking)을 줄 수 있다.

3. Celery Worker (Task Consumer)

• 역할: 실제 문서 파싱, 청킹, 임베딩(GPU 연산) 수행.
• 학습: Redis에서 대기 중인 작업을 가져와 처리하는 일꾼이다. 가장 중요한 점은 스케일 아웃(Scale-out)이 용이하다는 것이다. 지금은 컨테이너가 하나지만, 향후 문서 처리량이 급증하면 이 워커 컨테이너의 레플리카만 늘려서 병렬 처리 능력을 손쉽게 확장할 수 있다.

4. Celery Flower (Monitoring)

• 스펙: Port 5555
• 역할: 비동기 작업 상태 모니터링 및 대시보드.
• 학습: 눈에 보이지 않는 백그라운드 작업들의 상태(처리 중, 성공, 실패)를 시각화(Observability) 해준다. 비동기 로직 개발 시 디버깅 툴로 매우 유용하다.

환경 분리의 장점

이렇게 분리하면서 얻은 장점들은 위와 같다.

---

문서 파싱 (OWPML)

문서 파싱 파이프라인

파싱되는 문서는 다섯가지의 단계를 거친다. 먼저 확장자를 확인하고, 형식에 맞는 파싱을 한다. 이후 데이터 정규화를 거쳐 문서의 구조정보, 메타데이터 등을 추출한다. 이 결과는 디렉토리에 .txt, .json 형태로 저장된다.

HWP 파일

레거시 바이너리 파일 포맷이다. JPype 브릿지를 통해 hwplib을 활용하여 파싱한다. JVM 환경에서 텍스트를 추출하며, 텍스트 추출은 가능하나 표와 이미지는 제한적이다.

HWPX 파일

HWPX는 ZIP 파일이다. 압축을 풀면 XML 파일들이 나오는데, 이 파일들을 파싱하고, OWPML 스키마를 따라 구조화 시킨다. (표준 라이브러리인 zipfile과 ElementTree를 사용해서 이 XML을 파싱한다.)
HWPX에서는 텍스트뿐만 아니라 표와 이미지도 추출할 수 있다. 표는 행과 열 구조를 그대로 유지한 채 JSON으로 변환하고, 이미지는 원본 포맷 그대로 파일로 저장한다.

파싱 전략

정규식 기반 계층 구조 분석

공공기관의 문서 데이터를 주로 사용하기에, 이러한 공문서의 작성규칙에 맞춘 파싱 전략을 세웠다.

---

근거 추적 메커니즘

청크 메타데이터

• Hierarchy Path 자동 태깅
• 작동 원리: 단순히 문서를 500자, 1000자 단위로 뚝뚝 자르기만 하면, 그 조각(Chunk)이 원래 문서의 어느 소속인지 문맥을 잃어버리기 쉽다. 이를 해결하기 위해 청킹 시점에 상위 헤더를 역추적하는 로직을 구현했다. _find_structure_context 메서드는 현재 청크의 위치에서 가장 가까운 상위 '장(Chapter)'과 '조(Article)'를 찾아내어, 메타데이터에 hierarchy_path("제3장 급여의 지급 > 제15조")를 자동으로 각인시킨다.

RAG 서비스의 핵심은 답변의 신뢰도다. 사용자가 "급여는 언제 나오나요?"라고 물었을 때, AI가 내용을 뭉뚱그려 답하는 것과 "공무원연금규정 제3장 제15조에 따르면..."이라며 정확한 조항을 인용하는 것은 천지 차이다. 메타데이터를 꼼꼼하게 관리한 덕분에, 이제 우리 서비스는 LLM이 답변할 때 정확한 근거(Source)를 함께 제시할 수 있게 되었다. 

---

본 후기는 [한글과컴퓨터x한국생산성본부x스나이퍼팩토리] 한컴 AI 아카데미 2기 (B-log) 리뷰로 작성 되었습니다.