AWS 관련 참고자료 : 'JSCODE의 AWS입문'도서 강의영상
1. NoSQL이란?
NoSQL은 "Not Only SQL"의 줄임말로, 관계형 데이터베이스(RDBMS)의 한계를 극복하기 위해 등장한 비관계형 데이터베이스를 지칭하는 개념이다. 스키마 없이 사용하거나, 느슨한 스키마 구조를 제공하며, 대량의 분산 데이터 처리에 특화된 저장소를 의미한다.
전통적인 SQL 기반의 RDBMS는 고정된 구조와 복잡한 조인을 바탕으로 정합성을 유지하는 데 중점을 두는 반면, NoSQL은 유연성, 확장성, 대규모 분산 처리 등을 더 중시한다.
스키마란 데이터베이스에서 자료의 구조, 표현 방식, 자료 간 관계를 정의한 형식 언어 구조를 의미하며, 외부 스키마 / 개념 스키마 / 내부 스키마로 구성된다.
2. NoSQL의 주요 유형
| 유형 | 설명 | 사용 시기 | 대표 기술 |
|---|---|---|---|
| Document Store | JSON, XML 문서 단위 저장 | 다양한 속성과 계층 구조를 가진 데이터 저장 시 | MongoDB, CouchDB |
| Key-Value Store | Key로 Value 조회 | 캐시, 세션, 사용자 구성 정보 저장 등 | Redis, DynamoDB |
| Wide-Column Store | 컬럼 패밀리 구조 | 대규모 쓰기, 분산 환경 | Cassandra, HBase |
| Graph Store | 노드 간 관계(엣지)를 표현 | 소셜 네트워크, 추천 엔진, 지식 그래프 등 관계 탐색이 중요한 경우 | Neo4j, Amazon Neptune |
3. NoSQL 간 비교
| 항목 | Document | Key-Value | Wide-Column | Graph |
|---|---|---|---|---|
| 성능 | 높음 | 높음 | 높음 | 가변적 |
| 확장성 | 높음 | 높음 | 높음 | 가변적 |
| 유연성 | 높음 | 높음 | 보통 | 높음 |
| 복잡성 | 낮음 | 매우 낮음 | 낮음 | 높음 |
| 주요 특징 | 계층형 문서 구조 | 단순 조회 | 컬럼 패밀리 구조 | 관계 기반 쿼리 |
4. MySQL과 NoSQL 조합 전략
4-1. 역할 분담
| 데이터 유형 | 저장소 | 이유 |
|---|---|---|
| 사건번호, 판례명, 선고일 등 | MySQL (RDB) | 정형 구조에 적합하며 검색, 필터링, 정렬에 강하다 |
| 판례 본문, 요약, 분석 결과 | NoSQL (DynamoDB) | 구조가 유동적인 문서 기반 데이터 저장에 적합하다 |
| 유사도 벡터, 색인 | FAISS | RAG 기반 검색을 위한 벡터 기반 색인에 적합하다 |
4-2. 검색 시나리오 및 동작 방식
- 사용자가 판례를 검색하면, 사건번호, 피고, 원고, 판결 요지 등 요약 정보는 MySQL에서 바로 조회된다.
- 검색된 결과에서 사용자가 특정 판례를 클릭하면, MySQL에 저장된 NoSQL 매핑 키(PK/SK) 정보를 바탕으로 DynamoDB에서 해당 판례의 전문, 요약, 분석 결과를 조회한다.
- 이 구조는 RAG 시스템과 연계되어, 유사 판례 검색 → 목록 출력 (MySQL 기반) → 세부 조회 (NoSQL 기반) 흐름으로 작동한다.
5. AWS 기반 NoSQL 선택 기준
| 조건 | 추천 NoSQL | 이유 |
|---|---|---|
| 서버리스 및 자동 확장 | Amazon DynamoDB | 관리가 필요 없고 트래픽에 따라 자동 확장된다 |
| JSON 문서 저장 | Amazon DocumentDB | MongoDB 호환 문서 저장소, 유연한 구조 지원 가능 |
| 유사도 기반 검색 | FAISS | 텍스트 및 벡터 색인을 통한 검색 기능 제공 |
| 비용 절감 + 대용량 저장 처리 | S3 + Lambda + NoSQL | 저장, 트리거, 처리 자동화 구성에 유리 |
6. 왜 DynamoDB를 선택했는가?
- AWS 인프라와의 자연스러운 연동 (Lambda, S3 등)
- 서버리스 아키텍처로서 자동 확장과 고가용성을 기본 제공
- 운영 리소스 부담이 적고 비용 예측이 가능
- 판례 데이터는 구조가 고정되어 있지 않지만 정형화 가능하며, PK-SK 설계로 충분히 문서 구조를 표현할 수 있다.
- MySQL과의 연계 저장 구조를 통해 단순 정보는 RDB, 전문/분석은 NoSQL에서 분리 처리 가능
7. MongoDB vs DynamoDB 비교
| 항목 | MongoDB | DynamoDB |
|---|---|---|
| 데이터 모델 | Document (BSON) | Key-Value + JSON |
| 운영 방식 | Atlas 기반 클러스터 (또는 자체 관리) | 완전관리형 AWS 서버리스 서비스 |
| 쿼리 기능 | 복잡한 집계/조인 가능 | 단일 테이블 설계에 적합한 간단 쿼리 중심 |
| 확장성 | 샤딩 기반 수평 확장 | 자동 수평 확장 지원 |
| 비용 예측성 | 상대적으로 명확함 | 요청량 기반 과금으로 변화폭이 큼 |
| AWS 통합성 | 외부 연동 필요 | IAM, CloudWatch 등 AWS 서비스와 통합 용이 |
| 유지보수 리소스 | 중간 수준 (Atlas 자동화 일부 제공) | 매우 낮음 (전체 자동 관리) |
7-2. 우리 서비스에 더 적합한 선택은?
본 플랫폼은 판례 데이터 구조가 복잡하게 변화하지 않고, 내용의 길이 차이만 존재한다. 또한 검색-조회 흐름이 명확히 분리되어 있으며, AWS 환경에서의 통합성과 운영 효율성을 중시한다.
DynamoDB가 적합한 이유는 다음과 같다.
- 고정된 구조: 판례 데이터 구조가 통일되어 있으므로, 중첩 JSON이나 자유 스키마가 필요하지 않다. 이는 PK-SK 기반 구조 설계에 적합하다.
- 서버리스 운영과 자동 확장성: 데이터가 많아지고 조회량이 급증해도 자동으로 확장되며, 운영 비용 예측이 가능하다.
- MySQL 연계 흐름과의 간결한 통합: 검색 결과는 MySQL에서 처리하고, 상세 조회는 DynamoDB에서 처리하는 구조와 자연스럽게 연결된다.
- AWS 기반 인프라에 최적화: Lambda, S3, GitHub Actions 기반 CI/CD와의 통합성이 뛰어나며, 운영 복잡도가 낮다.
→ 결론적으로, 문서 길이는 길지만 구조가 고정되어 있는 판례 데이터를 저장하고, 검색/조회/분석 파이프라인을 명확히 분리하는 본 서비스 아키텍처에서는 DynamoDB가 MongoDB보다 명확히 더 적합한 선택이다.
8. RAG 및 파인튜닝 모델 CI/CD 배포 전략
법률 AI 플랫폼에서는 RAG 기법과 파인튜닝된 모델을 운영하며, 이를 자동화하기 위해 GitHub Actions 기반 CI/CD 파이프라인을 구축할 예정이다. 웹 서버와 AI 서버는 서로 독립적인 서비스로 구성되며, 각 서버에 대해 별도의 CI/CD 파이프라인을 설계한다.
8-1. 자동 배포 구성 요소
| 구성 요소 | 설명 |
|---|---|
| GitHub Actions | 코드 푸시 시 자동 실행되는 파이프라인 정의 |
| Docker + ECR | 학습/서빙 모델을 Docker로 컨테이너화하여 ECR에 저장 |
| ECS 또는 Lambda | 웹 서버 또는 AI API 배포 대상. 무중단 배포 가능 |
| 모델 저장소 | 학습된 모델은 S3, EFS 또는 SageMaker 환경에서 로딩 가능 |
8-2. 전체 흐름 예시
1. GitHub에 웹 서버 또는 AI 서버 코드 수정 후 Push
2. GitHub Actions가 트리거되어 웹/AI 각각의 파이프라인 실행
3. Docker 이미지 빌드 → Amazon ECR 푸시
4. ECS 또는 Lambda로 자동 배포
5. API 호출 시 최신 모델 또는 웹 기능이 반영된 서비스 제공8-3. 모델 저장소 전략
파인튜닝된 모델 또는 sLLM은 크기와 배포 방식에 따라 다음과 같은 저장 방식을 고려할 수 있다.
| 저장 방식 | 사용 상황 | 장단점 요약 |
|---|---|---|
| Amazon ECR (Docker 포함) | 모델 크기가 작고 코드와 함께 컨테이너화할 때 적합 | 배포 간편, 이미지 크기 제한 주의 필요 |
| Amazon S3 | 수 GB 이상 대용량 모델을 개별 파일로 관리할 때 적합 | 로딩 시점 제어 가능, 비용 효율적 |
| Amazon EFS 또는 FSx | 여러 서버에서 동시에 모델 공유할 때 적합 | I/O 성능 확보 필요, EC2/ECS 마운트 전제 조건 |
| Amazon SageMaker | 추론 API 엔드포인트가 필요하고 모델 서빙을 별도 관리할 때 | GPU/메모리 설정 유연, 자동 확장 지원, 비용 고려 필요 |
SageMaker는 고성능 LLM을 GPU 기반으로 API 형태로 서빙할 수 있는 관리형 환경을 제공한다. 서버리스 환경에서도 추론 기능을 바로 배포하고 모니터링할 수 있으며, 지속 운영 환경에 적합하다.
9. 결론
- 정형 데이터는 MySQL, 비정형 문서형 데이터는 DynamoDB로 이원화 저장
- 사용자는 MySQL에서 판례 목록을 확인하고, 상세 내용은 매핑된 DynamoDB에서 조회
- 검색 최적화를 위해 FAISS 기반의 벡터 색인을 활용하며, 색인 갱신은 수동 또는 비정기 처리
- 웹 서버와 AI 서버는 독립적으로 CI/CD 자동 배포 구조를 갖추며 GitHub Actions로 자동화
- 따라서 DynamoDB + FAISS + 분리된 CI/CD 파이프라인 구조는 본 법률 AI 플랫폼에 가장 적합한 아키텍처로 판단된다.
