프로덕션 풀스택 애플리케이션에서 RAG 파이프라인 실행 (벡터 데이터베이스 없이)
Source: Dev.to
Note: 아직 첫 번째 글을 읽지 않으셨다면, 여기에서 확인하실 수 있습니다: [Insert link to previous post]
개요
이 게시물에서는 백엔드‑전용 버전의 RAG 파이프라인을 가져와 완전한 프런트‑엔드 애플리케이션으로 감쌉니다. 그 결과 전체 스택 앱이 생성되어 다음을 할 수 있습니다:
- 회원가입 / 로그인 (AWS Cognito 사용).
- PDF 문서 업로드.
- 문서가 인덱싱될 때까지 대기 (비동기적으로).
- 질문하기 – 업로드된 PDF 내용만을 기반으로 답변이 제공됩니다.
목표는 숨겨진 지연 트릭이나 대규모 가정 없이 실제 사용자와 트래픽에서 저예산 RAG 파이프라인이 어떻게 동작하는지 보여주는 것입니다. 초기 단계 실험, 내부 도구, 또는 기능 검증이 최고 성능보다 중요한 MVP에 이상적입니다.
소스 코드는 이전 게시물과 동일한 GitHub 저장소의 full-stack-implementation 브랜치에 있습니다.
기술 스택
| 계층 | 기술 | 목적 |
|---|---|---|
| 프론트엔드 | Next.js (App Router) | 서버 사이드 렌더링 및 라우팅을 지원하는 React 프레임워크 |
| Tailwind CSS 4 | 유틸리티 퍼스트 스타일링 | |
| shadcn/ui | Radix UI 프리미티브를 기반으로 만든 컴포넌트 라이브러리 (New York 스타일) | |
| NextAuth.js | Next.js용 인증 통합 | |
| Lucide React | 아이콘 세트 | |
| 백엔드 | AWS Lambda | 서버리스 API 레이어 |
| AWS Cognito | 사용자 풀 및 인증 | |
| Amazon S3 (presigned URLs) | PDF 저장소 | |
| Amazon DynamoDB | 임베딩 및 메타데이터 저장소 | |
| Amazon Bedrock | LLM 및 임베딩 모델 | |
| Amazon EventBridge + SQS | 분리된 비동기 문서 인덱싱 |
사용자 흐름
-
Authentication – 랜딩 페이지에 Sign‑up / Login 양식이 표시됩니다.
Authentication 스택(Cognito + Login / Register Lambda)으로 구동됩니다. -
Upload PDFs – 로그인 후 사용자는 PDF를 끌어다 놓을 수 있습니다.
파일은 사전 서명된 URL을 통해 S3에 업로드됩니다; EventBridge 규칙이 메시지를 SQS 큐에 푸시하고, 이는 인덱싱 Lambda를 트리거합니다. -
Indexing – Lambda가 텍스트를 추출하고, 임베딩을 생성(Bedrock 사용)하며, 벡터와 메타데이터를 DynamoDB에 저장합니다.
이 단계는 완전히 비동기식이며, 사용자는 차단되지 않습니다. -
Chat UI – 인덱싱이 완료되면 문서가 채팅 인터페이스에 표시됩니다.
하나 이상의 문서를 선택하고 질문을 입력하면 Ask‑Questions Lambda가 관련 청크를 가져와 Bedrock LLM 추론을 수행하고 답변을 반환합니다.
데모 GIF
PDF 업로드 흐름을 보여주는 GIF를 삽입하세요
아키텍처 다이어그램
여기에 Lambda 인덱싱 흐름 다이어그램을 삽입하세요 (S3 → EventBridge → SQS → Lambda → DynamoDB)
성능 하이라이트
문서 인덱싱
| PDF 크기 | PDF 수 | 평균 Lambda 실행 시간 |
|---|---|---|
| ~400 KB | 1 | ~8 s |
| ~200 KB each | 2 | ~8 s 전체 |
인덱싱은 여전히 편안하게 비동기적으로 진행되며, 사용자는 절대 차단되지 않습니다.
20개 이상의 문서를 유사한 크기로 인덱싱했으며, 인덱싱 Lambda(및 DynamoDB 쓰기 포함)당 대략 4 s가 소요되는 것을 확인했습니다.
Get‑Documents API
Postman을 사용한 테스트
- 첫 번째 요청: 콜드 스타트 때문에 느림.
- 이후 요청: 워밍 스타트이며 지속적으로 빠름.
Insert screenshot of Postman response & Lambda duration here
콜드 스타트는 다중 사용자 환경에서 드물게 발생하므로 대부분의 사용자는 빠른 응답을 경험합니다.
Ask‑Questions Lambda
| 시나리오 | 입력 | 평균 실행 시간 (콜드) | 평균 실행 시간 (워밍) |
|---|---|---|---|
| 1 document | “What is this document about?” | ~1.2 s | ~0.6 s |
| 4 documents | 동일 질문, 여러 문서에 적용 | ~2.0 s | ~1.1 s |
Insert graph of Lambda execution times (cold vs. warm) here
Lambda는 선택된 문서 ID와 사용자의 질문을 포함한 페이로드를 받아 DynamoDB에서 관련 임베딩을 가져오고, Bedrock LLM 추론을 실행한 뒤 답변을 반환합니다.
비용 및 운영 이점
- 장기 실행 서비스 없음 → 고정 월 요금 0.
- 서버리스 전용 (Lambda, S3, DynamoDB, Bedrock) → 사용량 기반 과금.
- 인증 및 문서 처리용 별도 스택 → 독립적인 스케일링 및 쉬운 API‑gateway 보호 (Cognito User Pool ID 가져오기).
모든 아키텍처 결정은 비용 및 운영 오버헤드 최소화를 목표로 하면서도 기능적인 RAG 경험을 제공하도록 설계되었습니다.
다음 단계
- Add caching (예: DynamoDB TTL 또는 CloudFront) 를 추가하여 콜드 스타트 영향을 더욱 줄이세요.
- Implement pagination 대규모 문서 세트를 위해 페이지네이션을 구현하세요.
- Explore fine‑tuning 도메인 특화 정확도를 위해 Bedrock 모델을 파인튜닝해 보세요.
레포를 자유롭게 클론하고, full-stack-implementation 브랜치로 전환한 뒤, 직접 PDF를 실험해 보세요!
즐거운 개발 되세요!
네 개 문서 요약
하나의 문서를 조회할 때, 콜드 스타트 소요 시간은 약 3 초이며, 워밍된 Lambda는 1.5 초 이하에 실행됩니다.
네 개의 문서를 조회할 경우, 콜드 스타트 소요 시간은 4 초 약간이고, 워밍 스타트 소요 시간은 4 초 미만입니다.
핵심 요점: 일반 사용자는 Lambda 콜드 스타트를 많이 경험하지 않을 것입니다. 복잡성을 최소화하기 위해 AWS 서비스를 거의 사용하지 않는 저예산 RAG 시스템의 경우, 이러한 성능은 충분히 허용됩니다.
이 애플리케이션은 첫 번째 블로그 포스트가 이론화한 바를 확인시켜 줍니다 — DynamoDB 기반 RAG 시스템은 저렴할 뿐만 아니라 실용적이며, 그 한계를 이해한다면 충분히 허용 가능한 성능을 제공합니다.
트레이드‑오프
- Lambda 콜드 스타트는 실제로 존재합니다.
- 문서 조회 지연 시간은 예상대로 동작하며 문서 수가 증가함에 따라 늘어납니다.
초기 단계 애플리케이션, 내부 도구, 실험, 혹은 비용을 크게 들이지 않으면서도 작동하는 RAG 시스템이 필요한 해커톤 대회 등에서도 이 설정은 제 역할을 잘 수행합니다. 제품을 출시하고 사용자 피드백을 수집하며, 데이터가 필요에 따라 손을 내밀 때까지 비용이 많이 드는 아키텍처 결정을 미룰 수 있게 해줍니다.