완전관리형 RAG는 우리가 만든 파이프라인을 이겼을까

학교 보건교사용 의료자문 챗봇을 운영하고 있다. 규칙은 하나다. 공식 공문서에 적힌 내용만 근거로 답한다. 감염병 예방·위기대응 매뉴얼, 학교보건 기본방향 같은 문서들이다. 근거가 없으면 지어내지 않고, 답을 거절한 뒤 전문 교수에게 넘긴다.

그래서 이 서비스의 품질은 LLM의 문장력에서 갈리지 않는다. 검색에서 갈린다. "수두 등교중지 기준"을 물으면 표 셀에 박힌 "모든 수포가 가피화될 때까지(발진 후 최소 5일)"를 정확히 끌어와야 한다. 그걸 못 끌어오면 챗봇은 입을 다문다.

이 검색을 우리는 직접 만든 파이프라인으로 돌려 왔다. 그런데 2026년 6월 Amazon Bedrock의 완전관리형 Knowledge Base가 GA됐고, 진입 장벽이던 고정비가 사라졌다. 그래서 궁금해졌다. AWS가 통째로 관리해 주는 RAG가 우리가 손으로 만든 파이프라인을 이길까? 솔직히 반쯤은 질 거라 봤다.

먼저 고르는 기준

결론부터 고르면 이렇다. 운영 인프라를 없애고 빠르게 시작하는 일이 우선이면 관리형 KB, 파싱·청킹·검색을 제품 도메인에 맞게 바꾸는 일이 우선이면 pgvector가 유리하다. AWS도 관리형 KB는 저장·인덱싱·검색 인프라를 서비스가 맡고, 고객 관리형은 벡터 저장소를 직접 운영하며 접근한다고 구분한다.¹

이 표는 제품 전체의 승패표가 아니다. 아래 결과는 한국어 표 공문서와 우리가 이미 운영하던 Aurora라는 조건에서 나온 결정이다.

우리 파이프라인

평범한 구조다. 그게 장점이다.

PDF가 들어오면 opendataloader로 파싱한다. 단순 텍스트 추출이 아니라 제목·문단·표 구조를 살려서 뜯어낸다. 다음 단계가 핵심이다. 한국어 구조 인식 청킹. 토큰 N개씩 기계적으로 자르는 대신 문서의 섹션·제목 경계를 따라 자른다. "등교중지 기준" 표가 헤더와 함께 한 덩어리로 남도록.

자른 조각은 Titan Text Embeddings v2로 임베딩해 Aurora PostgreSQL의 pgvector에 넣는다. 인덱스는 HNSW, 거리는 코사인. 질의가 들어오면 상위 k개 청크를 뽑아 컨텍스트 블록을 만들고, "발췌에 있는 내용만 쓰고 문장 끝에 [n]으로 출처를 달라"는 시스템 프롬프트와 함께 Claude에 넘긴다.

자르는 방식, k값, 어떤 문서를 켜고 끌지가 전부 우리 코드 안에 있다. 무엇이든 직접 만질 수 있다.

완전관리형

반대편은 인프라 운영의 대부분을 AWS에 맡긴다. 파싱·청킹·임베딩·검색이 한 서비스에 묶인다. 관리형 KB는 기본 300토큰·20% 오버랩, 사용자 지정 고정 길이, 미리 나눈 문서를 그대로 쓰는 NONE 청킹을 지원한다.² 검색 결과 수, 메타데이터 필터와 리랭킹도 조정할 수 있다.³ 대신 애플리케이션이 임의의 도메인 경계 함수나 저장소의 검색 점수식을 직접 끼워 넣는 구조는 아니다. 벡터 저장소의 프로비저닝과 확장 부담을 없애는 대신 생기는 경계다.

띄우는 것부터 걸렸다. 이 완전관리형 KB는 서울 리전에 없어서 비교 환경을 도쿄에 두었다.⁴ corpus를 S3로 도쿄에 복제하고 거기에 KB를 세웠다. 기본 임베딩은 서비스 관리형이라 별도 모델을 고르거나 액세스를 신청할 필요가 없었다. 여기까지는 편했다.

공정하게 비교하려고 생성 단계는 양쪽 모두 같은 Claude, 같은 프롬프트로 못 박았다. 관리자 화면에 비교 엔드포인트를 하나 만들고 질문 하나를 세 갈래로 동시에 쐈다. ① 우리 파이프라인, ② 관리형에서 검색만 떼어 같은 Claude에 물린 것, ③ 관리형 통짜 RAG. 각 갈래의 답·출처·지연을 한 표에 적었다.

실험

대표 질문 30개를 단일 질의로 던졌다. 발열 대응 절차, 질병별 등교중지 기간, 위기경보 단계별 조치, 보고 체계까지. 현장에서 실제로 들어오는 질문들이다.

세 구성의 질의별 응답과 근거, 지연시간은 학교 보건 문서 RAG 벤치마크에서 원본 엑셀과 함께 공개했다.

여기에 후속 질의 8세트를 더해 맥락을 기억하는지 확인했다. "인플루엔자 등교중지는?"이라 묻고, 답이 나오면 곧장 "그럼 수두는?"이라 되묻는다. "수두" 뒤에 생략된 "등교중지 기간"을 직전 턴에서 복원해야만 제대로 답할 수 있다.

질문 목록을 검색·생성·대화 평가로 나누고 변경마다 다시 실행하는 방법은 RAG 품질 회귀 평가에 따로 정리했다.

결과

맥락 기억은 무승부였다. 8세트 전부 양쪽 다 "그럼 수두는?", "그건 누구한테 보고하지?" 같은 지시어를 직전 대화에서 정확히 메웠다. 대화 이력만 제대로 넘기면 모델이 알아서 한다.

승부는 표에서 났다. 우리 파이프라인은 셀 값을 그대로 짚었다. 구강검진 "3~11월", 수두 "가피화될 때까지, 발진 후 최소 5일", 페이지 번호까지 정확했다. 관리형은 같은 표를 "텍스트를 읽을 수 없다"며 자주 흘렸다. 지연은 평균 5.4초 대 4.8초로 관리형이 조금 빨랐지만, 못 읽으면 빨라야 소용이 없다.

③번 통짜 RAG는 30문항 전부 실패했다. 처음엔 "관리형은 검색과 생성을 묶는 모드를 아예 지원하지 않는다"고 적었다. 틀린 판단이었다. 나중에 공식 문서를 보니 내가 부른 RetrieveAndGenerate API가 애초에 관리형 KB를 지원하지 않았다.⁵ 관리형의 한계가 아니라 내가 엉뚱한 문을 두드린 착오다.

결과는 분명했다. 한국어 표 문서에서는 직접 만든 쪽이 앞선다. 다만 그 이유를 제대로 짚기까지 헛다리를 몇 번 더 짚었다.

내가 틀린 곳

처음 진단은 이랬다. "관리형이 단순한 기본 파서로 떨어져서 표를 못 읽는다. OCR을 안 돌린다."

문서를 다시 읽으니 틀린 진단이었다. 이 관리형 KB는 처음부터 가장 똑똑한 파서로 돌고 있었다. 그게 기본값이고 다른 선택지도 없다.⁶ 파서를 의심한 게 헛다리였다.

확인 차 같은 문서를 똑똑한 파서로 명시해 재인제스트했다. 30개 중 6개가 "못 찾음"에서 정답으로 살아났다. 홍역 등교중지는 "찾을 수 없음"에서 "7일간 등교 중지"로 복원됐다. 그런데 바로 옆 같은 표의 수두 행은 그대로 안 나왔다.

두 번째 가설은 기본 청킹이었다.

비교 환경은 기본값인 약 300토큰, 20% 오버랩으로 적재했다. 처음 결과만 보면 이 길이가 질병 표를 행 한복판에서 잘랐다고 의심할 만했다. 홍역 행은 한 청크에 담기고 수두 행은 경계에 걸친 것처럼 보였다.

다만 관리형 KB에 청킹 선택지가 하나뿐인 것은 아니다. 고정 길이를 지정할 수 있고, API에서는 사전 분할한 문서에 NONE을 쓸 수 있다.² 우리가 부족하다고 본 것은 한국어 표의 헤더와 행을 묶는 임의의 도메인 규칙을 코드로 주입하는 제어권이었다. 그리고 이 가설조차 뒤의 직접 검색에서 다시 수정됐다.

한 번 더 틀린 곳

기본 청킹만이 범인이라는 것도 절반만 맞았다. 글을 닫기 전에 KB를 다시 세워 검색을 직접 찔러봤더니 결과가 또 한 번 나를 정정했다.

핵심 행은 인덱스에 멀쩡히 있었다. "모든 수포에 가피가 형성될 때까지, 발진 후 최소 5일." 잘려 사라진 게 아니었다.

문제는 회수였다. "수두 격리 기준은?"이라는 자연어 질문으로는 그 행이 상위에 뜨지 않았다. 결과 개수를 20개로 늘리고 매니지드 리랭커도 켜봤지만³ 순위는 그대로였다. 리랭킹은 회수가 빠뜨린 걸 끌어올리지 못한다. 없는 걸 재정렬할 수는 없으니까.

그러니 정확히는 이렇다. 인덱스에는 있는데 자연어 질문이 그걸 안정적으로 끌어오지 못한다. 결과 수와 리랭킹은 조정할 수 있었지만, 애플리케이션에서 관리형 저장소의 후보 생성과 점수식을 직접 바꿀 수는 없었다. 챗봇 사용자는 키워드를 욱여넣지 않는다. 그냥 "수두는 며칠 쉬어요?"라고 묻는다.

돈은 어디서 새는가

겉만 보면 완전관리형이 싸 보인다. 벡터 DB를 직접 띄우지 않고, 관리형 파서·임베딩·리랭커는 인덱스 저장량과 검색 호출 요금 안에 별도 모델 요금 없이 포함된다.⁷ 서비스 전체가 무료라는 뜻은 아니다. 함정은 "벡터 DB를 직접 안 띄운다"는 전제에 있다.

우리는 이미 띄우고 있다. 이 서비스는 RAG가 없어도 Aurora를 돌린다. pgvector는 그 위에 컬럼 하나와 HNSW 인덱스 하나를 더 얹는 정도다. 이미 돌아가는 DB 위에 얹으니 RAG가 새로 무는 고정비는 거의 없다. 완전관리형은 인덱스 저장량과 검색 호출이 별도 비용으로 잡힌다. 관리형 파서·임베딩·리랭커는 추가 요금 없이 포함된다.⁷ 우리 건 도쿄에 있었으니 리전 간 전송까지 붙는다.

그래서 비교는 질문 하나로 갈린다. DB를 이미 돌리고 있나. 우리는 기존 Aurora의 여유 용량을 써 pgvector의 추가 비용이 작았다. DB 한 대 없는 맨바닥에서 시작했다면 계산은 뒤집힌다. 전용 벡터 스토어 운영비가 부담이 되고, 검색당 과금하는 완전관리형이 저트래픽에서는 더 쌀 수도 있다.

관리형 KB와 pgvector 자주 묻는 질문

어느 쪽이 더 저렴한가

기존 PostgreSQL의 여유 용량을 쓸 수 있으면 pgvector의 한계비용이 작다. 반대로 벡터 저장소와 적재 파이프라인을 새로 만들어야 한다면 관리형 KB의 사용량 과금이 유리할 수 있다. 관리형 KB는 현재 인덱스 저장량과 검색 호출에 과금하고, 기본 파싱·임베딩·리랭킹은 포함한다.⁷ 실제 선택은 같은 저장량·월 검색량·리전 전송량을 넣어 두 안의 월 비용을 계산해야 한다.

어느 쪽이 제어권이 큰가

pgvector가 크다. 애플리케이션이 청크 스키마, SQL, 필터, 하이브리드 점수, 후보 수와 리랭킹 순서를 직접 소유한다. 관리형 KB도 결과 수, 메타데이터 필터, 리랭킹과 여러 청킹 전략을 제공하지만 저장소의 점수식이나 임의의 도메인 경계 함수를 애플리케이션 코드로 대체하지는 못한다.³ 특히 데이터 소스를 연결한 뒤에는 청킹 전략을 바꿀 수 없으므로 첫 적재 전에 평가 세트를 돌려야 한다.²

한국어 표 문서에는 무엇을 골라야 하나

제품명보다 실제 표를 대상으로 한 회수 평가로 고른다. 표 제목, 열 헤더와 대상 행이 같은 청크에 남는지 먼저 보고, 사용자가 말할 자연어 질문으로 정답 행이 top-k에 들어오는지 측정한다. 기본 300토큰뿐 아니라 사용자 지정 고정 길이와 사전 분할 문서도 후보로 비교해야 한다. 관리형 Smart Parsing이 표를 처리하더라도 검색 결과가 업무 기준을 통과한다는 보장은 없다. 우리 문서에서는 도메인 경계와 검색 점수를 더 직접 제어해야 해 pgvector를 택했다. 다른 코퍼스라면 같은 평가가 다른 결론을 낼 수 있다.

세 번째 선택지, OpenSearch

비교에서 일부러 뺀 후보가 하나 더 있다. OpenSearch다. KB의 파싱·청킹은 그대로 쓰면서 검색만 직접 제어하는 중간 지점이다. 끌리는 이유는 분명하다. 우리가 막혔던 회수 문제를 정면으로 겨냥한다. BM25 키워드 점수와 kNN 벡터 점수를 함께 섞고, 한국어 형태소 분석기 nori를 붙이면 "수두"·"등교중지" 같은 단어의 키워드 매칭이 정확해진다.

비용 판단에는 세대 구분이 필요하다. OpenSearch Serverless Classic 컬렉션은 첫 컬렉션에 최소 OCU가 있어 유휴 시간에도 컴퓨트 비용 바닥이 생긴다. 반면 NextGen 컬렉션은 최소 OCU를 두지 않으면 10분 비활성 뒤 인덱싱·검색 OCU가 0으로 내려간다.⁸ 그래서 "Serverless는 항상 최소 유닛이 돈다"는 말은 이제 Classic에만 맞는다. NextGen은 상시 컴퓨트 바닥을 없애지만 저장 비용, 콜드 스타트, 리전과 기능 적합성은 별도로 계산해야 한다. 문서 2개인 우리 프로젝트는 그 운영 면적까지 늘릴 이유가 없었다. 코퍼스가 커지고 자연어 회수 정확도가 사업적으로 중요해지면 OpenSearch 하이브리드를 다시 비교할 수 있다.

결정

운영은 우리 파이프라인을 유지하기로 했다.

관리형은 똑똑했고 여러 청킹·검색 설정도 제공했다. 다만 우리에게 필요했던 임의의 한국어 표 경계 규칙과 저장소 검색 점수 제어까지 주지는 않았다. 자연어 질문에서 핵심 행의 회수가 불안정했고, 지원되는 애플리케이션 수준 조정만으로는 기준을 맞추지 못했다. 게다가 서울 리전 대신 도쿄를 써야 했고 인덱스 저장 비용과 사용량 기반 검색 비용이 별도로 생겼다. 이처럼 기능 시연 뒤 운영 기준을 통과시키는 과정은 AI PoC를 운영 시스템으로 넘기는 게이트와 같다.

남는 것

RAG 품질은 파싱 × 청킹 × 검색이다. 더하기가 아니라 곱이라 한 항이 0에 가까우면 나머지가 아무리 좋아도 결과는 0이다. 이번에도 파싱을 풀자마자 청킹이 다음 0으로 튀어나왔고, 청킹인 줄 알았더니 회수가 또 발목을 잡았다.

"완전관리형이니 알아서 최적이겠지"라는 기대는 빗나갔다. 관리형은 지원되는 설정 안에서 운영 부담을 줄이는 선택이지, 도메인별 청킹 코드와 검색 점수식까지 넘겨주는 선택은 아니다. 영어 산문이었다면 기본값으로 충분했을지 모른다. 표로 짜인 한국어 공문서 앞에서는 실제 질문 세트로 그 경계를 확인해야 했다.

끝으로, 틀린 진단은 지우지 않고 그대로 남겨 뒀다. "파서 문제"라던 첫 판단을 두 번 뒤집는 과정이야말로 이 비교에서 건진 제일 쓸모 있는 기록이다.

이런 한국어·규제 도메인의 RAG 설계와 검증은 AX 컨설팅과 데이터 & ML 엔지니어링에서 다루는 일의 일부다. "AI로 자동화하고 싶다"를 운영에서 살아남게 만드는 게 핵심이다.

참고 자료

본문의 AWS 동작·제약은 아래 공식 문서로 확인했다. 비교 수치(단일턴 30문항, 후속 8세트, retrieve 실측)는 우리 코퍼스로 직접 측정한 값이다.