검색과 열람을 지키는 운영과 협업
DocSuri
AI/ML 논문을 수집·구조화·임베딩·색인하는 파이프라인을 만들고 운영했습니다. 대량 백필로 발생한 검색 503 장애를 복구하고, 사용자 열람용 문서를 생성하는 큐와 워커를 분리했습니다.
문제
DocSuri는 AI/ML 논문을 탐색하고 원문에 근거한 한국어 요약을 제공하는 서비스입니다. 제가 맡은 수집 데이터는 검색, 문서 열람, 요약에 사용됩니다. 출처가 다른 논문의 중복과 버전, 철회를 처리하면서, 과거 데이터를 대량으로 채우는 백필이 사용자 응답을 방해하지 않도록 해야 했습니다.
백필이 검색에 미친 영향
2026년 7월 AWS 운영 중 대량의 arXiv 백필이 OpenSearch 조회를 늦추면서 k-NN 검색이 2초 제한을 넘겨 타임아웃 503 오류를 반환했습니다. 사용자 열람용 문서 생성 작업도 약 3.3만 건의 백필 뒤에서 대기했습니다. 각 프로세스가 요청 한도를 지켜도 워커를 3개 실행하면 전체 요청량은 늘어난다는 점을 확인했습니다.
역할
AWS AI School 2기 4인 팀의 데이터 엔지니어로서 논문 코퍼스의 수집·구조화·임베딩·색인 파이프라인과 인프라 운영, 후속 개선을 맡았습니다. 검색·요약·에이전트의 초기 구현과 GROBID TEI 구조 파서는 다른 팀원이 담당했습니다.
데이터를 주고받는 규칙과 협업
수집 데이터의 필드나 의미를 바꿀 때 공용 JSON Schema와 Python DTO뿐 아니라 그 데이터를 쓰는 요약 기능과 프런트엔드도 함께 수정했습니다. 호출 동작은 Protocol 인터페이스로 분리하고, 데이터를 만드는 쪽과 쓰는 쪽의 작업·검토 책임을 정리했습니다. 문서 추적성 도구에는 한국어 요구사항 ID, 모노레포 경로, 유닛 계획을 해석하는 기능을 보완해 검토할 문서 간 연결을 찾을 수 있게 했습니다.
핵심 결정
수집량을 제한하고 사용자 작업을 분리
7월 1일 수집 워커를 3개에서 1개로 줄여 검색을 복구하고, 사용자 열람 문서 생성 작업에 전용 우선순위 큐를 마련했습니다. 7월 2일 별도 워커 서비스로 옮겨 실행 자원을 분리했습니다. 외부 데이터 소스의 요청 한도에 맞춰 확장 상한을 정하고, bulk 작업은 30분, 열람 문서 생성은 5분 이상 대기하면 알람이 울리게 했습니다. DLQ 재처리 절차에는 검색 지연도 함께 확인하도록 명시했습니다.
핵심 결정 자세히 보기
서비스 예산과 사용자별 사용량을 별도로 관리
팀이 만든 공통 비용 제어 기능을 바탕으로 에이전트가 warning과 critical 상태를 처리하는 방식을 보완하고, 실행 비용을 관측 지표에 기록했습니다. Redis 기반 사용자 쿼터를 연결해 서비스 전체 예산과 사용자별 사용량 제한을 구분했습니다.
구조
논문 수집부터 검색·열람·요약까지
arXiv, Semantic Scholar, OpenAlex에서 가져온 논문을 수집 큐에 넣고, 문서 구조화와 청크·임베딩 생성을 거쳐 OpenSearch에 색인했습니다. AWS 운영 당시에는 Python, PostgreSQL, SQS, ECS/Fargate, S3, Bedrock, CDK, CloudWatch, Redis를 사용했고, 사용자 열람용 문서 생성은 별도 큐와 워커로 처리했습니다.
구조 자세히 보기
본문과 검색 청크의 기준이 되는 DocModel
문서의 섹션과 블록을 공통 구조로 표현하고, 이를 바탕으로 읽기 순서에 맞춘 본문과 검색 청크를 만들었습니다. 문단·표·수식·그림 캡션에는 논문·버전·섹션·블록 식별자를 연결하고, 검색 토큰과 원문 블록을 참조하는 blockRefs를 분리했습니다. 저장 데이터의 호환성은 파서와 스키마 버전으로 판단하며, 파생 캐시에서도 DocModel 세대를 구분합니다.
결과
장애를 재현한 질의로 검색 복구 확인
7월 1일 워커를 3개에서 1개로 줄인 뒤, 장애를 재현했던 질의가 정상 응답하는 것을 확인했습니다. 다음 날 추가로 안정화하면서는 큐를 보존한 채 수집과 자동 확장을 일시 정지했고, 검색은 기능 저하 상태가 아닌 정상 결과 20건을 반환했습니다. 아래 수치는 당시 문서와 커밋에 남아 있는 관측값입니다.
혼합 부하에서 측정한 응답 시간과 오류율
조치 후 가상 사용자 20명(20 VU)으로 실행한 k6 기록에서 검색 p95는 664.9 ms, 전체 HTTP 오류율은 0.01%였습니다. 프런트엔드, readyz, 검색 요청을 섞은 테스트이며 하나의 질의를 반복했으므로 캐시의 영향이 있을 수 있습니다. 이전에 측정한 검색 p95 9,061 ms는 요청 12회·동시성 3이라는 다른 조건에서 나온 값이므로, 두 결과로 개선율을 계산하지 않았습니다.
배운 점
작업의 성공과 데이터의 활용을 각각 검증
작업이 성공했는지, 결과가 저장됐는지, 데이터 품질이 적절한지, 사용자가 실제로 활용할 수 있는지는 따로 확인해야 합니다. 재처리와 온라인 조회의 목표를 나누고, 처리량뿐 아니라 실패가 미치는 범위, 복구 방법, 데이터를 사용하는 쪽의 요구까지 함께 살피는 기준을 얻었습니다.
배운 점 자세히 보기
아직 해결해야 할 데이터 품질과 접근 권한 문제
최신 감사에서는 코퍼스에 테스트용 데이터가 섞인 문제, 공유 캐시가 해당 원문과 정확히 연결되는지의 문제, 사용자 문서의 읽기 권한 문제가 남아 있었습니다. 일부 타입 생성 작업의 실패를 상위 단계에 전달하는 처리와 빈 결과를 degraded 상태로 표시하는 문제도 확인됐습니다. 후속 검증에서는 원본과 색인의 ID·내용 일치, 실패 건수와 종료 상태, 출처 식별과 소유권에 따른 접근 범위, 호스트 장애 이후의 복원을 확인 기준으로 삼았습니다.