벡터 전용 DB vs OpenSearch k-NN vs pgvector
결론: 사내 문서 1,000만 청크·권한 필터 필수·기존 OpenSearch 운영이라는 조건에서는 OpenSearch k-NN이 정답이다. 하이브리드(BM25+nori)·권한 필터(DLS)·벡터 검색을 한 엔진에서 처리하므로 시스템 수와 권한 동기화 지점이 늘지 않는다.
| 기준 | 벡터 전용 DB(Milvus·Qdrant 등) | OpenSearch k-NN | pgvector |
|---|---|---|---|
| 적정 규모 | 수억~수십억 벡터, GPU 가속 | 수천만~수억 벡터 | 수백만 이하 |
| 하이브리드(한국어 BM25) | sparse/BM25 함수는 있으나 한국어 형태소 분석은 외부 필요 | nori + BM25 + k-NN 네이티브, RRF 내장(2.19~) | PostgreSQL FTS(한국어 약함) |
| 권한 필터 | 페이로드/스칼라 필터 | efficient filtering + 엔진 수준 DLS 이중화 | SQL WHERE + RLS |
| 운영 통합 | 별도 클러스터(etcd/MinIO/Pulsar 등) 추가 | 기존 클러스터·운영 경험 재사용 | 기존 RDB에 확장 설치 |
| 지연·고급 양자화 | 최저 지연, PQ/DiskANN/GPU | HNSW(Faiss/Lucene), int8·binary 양자화, 디스크 모드 | HNSW/IVFFlat, pgvectorscale로 보완 |
| 비용 | 전용 인프라 + 두 시스템 동기화 | 메모리 노드 비용(양자화로 완화) | 가장 저렴하나 확장 한계 |
언제 선택 / 피함
- 벡터 전용 DB: 수억 벡터 이상·초저지연·GPU 인덱싱·멀티모달이 핵심 요구일 때 선택. 권한·한국어 키워드 검색을 별도 엔진에서 다시 구현해야 하면 피한다.
- OpenSearch k-NN: 하이브리드·권한·운영 통합이 요구일 때 선택. 수십억 벡터 초고속 전용 워크로드에는 과하다.
- pgvector: 벡터 수백만 이하이고 트랜잭션·관계 데이터와 같은 DB에서 조인해야 할 때 선택. 대규모·고QPS·한국어 BM25가 필요하면 피한다.
트레이드오프(메커니즘): 권한 필터는 반드시 pre-filter여야 하는데, HNSW 그래프 탐색은 필터 조건과 무관하게 이웃을 따라가므로 필터 선택도가 낮으면(허용 문서가 1%뿐) 탐색이 조기 종료되어 재현율이 떨어진다. OpenSearch의 efficient filtering은 필터 결과 크기에 따라 정확 k-NN으로 자동 전환해 이를 방어하고, 엔진 DLS가 애플리케이션 버그 시 2차 방어가 된다. 전용 DB도 필터를 지원하지만 한국어 BM25와 DLS를 한 곳에서 주지 못해 두 시스템 간 ACL 동기화라는 새 실패 지점이 생긴다.
본 시나리오 권고: 1,000만 청크 × 1024차원 × M=16 기준 HNSW 메모리는 fp32 ≈ 46GB, int8 양자화 시 ≈ 12.7GB로 OpenSearch 데이터 노드 수 대로 수용 가능한 규모다. 따라서 OpenSearch k-NN(int8) + DLS를 채택하고, 벡터 전용 DB는 향후 벡터 수가 수억으로 늘거나 p95 수십 ms 요구가 생길 때 재검토한다.
Iceberg vs Delta Lake vs Hudi
결론: 멀티 엔진·멀티 벤더를 전제하는 신규 엔터프라이즈 레이크하우스의 기본값은 Apache Iceberg다. 벤더 중립 REST 카탈로그·파티션 진화·v3 행 계보가 근거이며, Delta·Hudi는 예외 조건이 있을 때만 정당화한다.
| 기준 | Iceberg | Delta Lake | Hudi |
|---|---|---|---|
| 메타데이터 구조 | 스냅샷 → 매니페스트 리스트 → 매니페스트 → 파일(계층형, 엔진 무관) | _delta_log JSON + 체크포인트 Parquet |
타임라인(.hoodie) + 파일 그룹 |
| 파티션 | 히든 파티셔닝·파티션 진화 | 파티션 컬럼 명시(Liquid Clustering 보완) | 명시 + 클러스터링 서비스 |
| 업서트·CDC | COW/MOR, v3 삭제 벡터·행 계보 | COW 기본, 삭제 벡터, CDF | 레코드 키 업서트·증분 쿼리에 최적 |
| 카탈로그·엔진 | REST 사양(Glue/Polaris/Nessie), Spark·Trino·Flink·Athena·Snowflake·BigQuery | Unity Catalog, Spark 중심(UniForm으로 Iceberg 노출) | Hive/Glue, Spark·Flink 중심 |
| 생태계 결합도 | 낮음 | Databricks 높음 | 중간 |
언제 선택 / 피함
- Iceberg: 멀티 엔진, 장기 중립성, 파티션 전략 변경이 예상될 때. 초단위 극고빈도 upsert는 MOR 컴팩션 운영이 부담이다.
- Delta: 조직이 이미 Databricks로 표준화되어 Unity Catalog 거버넌스를 쓰고 있을 때. 비(非)Databricks 엔진의 쓰기 호환이 제약이면 피한다.
- Hudi: IoT·결제 원장처럼 레코드 키 기반 초고빈도 upsert와 자동 테이블 서비스가 핵심일 때. 엔진·커뮤니티 폭이 좁아 범용 플랫폼의 기본값으로는 피한다.
트레이드오프(메커니즘): Delta의 트랜잭션 로그는 단일 파일 시퀀스라 구현이 단순하지만 로그 재생·체크포인트가 Spark 구현에 묶여 있고, Iceberg의 계층형 메타데이터 트리는 매니페스트의 컬럼 min/max 통계로 엔진 무관하게 파일 프루닝이 되는 대신 스냅샷 만료·컴팩션·orphan 파일 정리를 운영자가 자동화해야 한다. 즉 중립성을 얻는 대가가 운영 자동화 책임이다.
본 시나리오 권고: 코어 DB 온프레미스 유지 + 클라우드 분석이라는 하이브리드 구성에서 Athena·Spark·Trino 등 복수 엔진이 같은 테이블을 읽어야 하므로 Iceberg + REST 카탈로그(Glue 연합 또는 Polaris)를 채택한다. 파일 크기 128MB~1GB 목표의 컴팩션과 스냅샷 만료를 S3 Tables 또는 스케줄 잡으로 자동화하고, 스냅샷 보존이 개인정보 삭제 의무와 충돌하는 지점은 삭제 반영 SLA로 통제한다.
Big Bang vs Phased vs Strangler Fig
결론: 1,200개 잡·규제 보고 40개·18개월이라는 금융권 DW 전환에는 Phased + Strangler Fig + Wave별 Parallel Run 조합이 정답이고, Big Bang은 인덱스 alias 스왑처럼 "원자적 전환·즉시 롤백"이 가능한 단위에만 쓴다.
| 기준 | Big Bang | Phased | Strangler Fig |
|---|---|---|---|
| 적합 규모·의존성 | 소규모, 의존성 단순 | 도메인·마트 단위로 분리 가능 | 레거시 앞에 파사드(뷰·API·alias)를 둘 수 있음 |
| 다운타임·롤백 | 다운타임 허용, 롤백은 전체 복귀 | Wave 단위 롤백 | 기능 단위 롤백 |
| 이중 운영 비용 | 없음 | Wave 기간만큼 | 장기 공존 비용 |
| 가치 실현 시점 | 전환 완료 후 | Wave마다 | 신규 기능부터 즉시 |
| 실패 영향 | 전면 장애 | 해당 Wave | 해당 기능 |
언제 선택 / 피함
- Big Bang: 이중 운영이 불가능한 라이선스 조건이거나 시스템이 작고 롤백이 쉬울 때. 다운스트림 수백 개·규제 보고 영향이 있으면 피한다.
- Phased: 의존성 그래프를 약연결 성분으로 자를 수 있을 때. 모든 마트가 하나의 거대 팩트를 참조해 분리가 안 되면 단독으로는 어렵다.
- Strangler Fig: 신 플랫폼이 먼저 가치를 내야 하고 레거시 수정이 위험할 때. 직접 DB 접속 리포트가 많아 파사드를 둘 수 없으면 피한다.
트레이드오프(메커니즘): Phased는 Wave마다 레거시·신규 양쪽에 CDC 동기화와 Reconciliation을 유지해야 하므로 이중 운영 비용이 Wave 수 × 병행 기간에 비례해 커진다. 반대로 Big Bang은 이 비용이 0이지만 실패 시 전체 복귀만 가능하다. Strangler는 파사드(뷰/alias) 뒤에서 기능을 하나씩 가로채므로 롤백 단위가 작지만, 파사드 자체가 새 운영 대상이 된다.
본 시나리오 권고: Retire 30%로 범위를 먼저 줄이고, 의존성이 약한 마트부터 Wave 1~3으로 Phased 전환, 규제 보고 40개는 마지막 Wave에서 N주(예: 2주) 연속 Reconciliation 일치 후 전환하며, 신규 파이프라인은 Strangler 원칙대로 신 플랫폼에만 만든다. 이중 운영 기간은 Wave당 2~4주 상한을 두어 운영 부담을 통제한다.
관리형 RAG(Bedrock Knowledge Bases 등) vs 자체 구축
결론: 파일럿은 관리형, 핵심 경로는 자체 구축 또는 혼합이 현실적 정답이다. 관리형은 수 주 안에 기준선을 만들어 주지만, 권한·한국어·망분리 요건이 확정되면 청킹·ACL·분석기를 세밀히 제어해야 하는 구간이 반드시 생긴다.
| 기준 | 관리형 RAG(Bedrock KB 등) | 자체 구축(LangChain/LlamaIndex/Haystack + OpenSearch) |
|---|---|---|
| 구축 속도·운영 부담 | 인제스천→검색→생성 API로 최소 | 파이프라인·인덱스·평가를 직접 운영 |
| 청킹·한국어·권한 제어 | 제공 옵션 범위(계층 청킹, 메타 필터) 내 | 문서 구조 청킹, nori 사전, DLS 이중 방어 등 자유 |
| 망분리·데이터 레지던시 | 프라이빗 엔드포인트·리전 정책 확인 필요 | 온프레미스·프라이빗 호스팅 가능 |
| 모델 선택 | 플랫폼 제공 모델(Rerank API 등) | 사내 호스팅(bge-reranker 등) 포함 자유 |
| 종속·비용 | 플랫폼 종속, 사용량 과금 | 인력·운영 비용, 통제력 확보 |
언제 선택 / 피함
- 관리형: 표준 요구(문서 Q&A)·짧은 기간·운영 인력 부족일 때. 권한 모델이 복잡하거나 한국어 분석기·청킹 커스텀이 품질을 좌우하면 단독 채택을 피한다.
- 자체 구축: 문서 수준 보안 이중화, 사내 용어 사전, 온프레미스 임베딩·리랭커가 필수일 때. 평가 루프와 운영 인력이 없으면 피한다.
트레이드오프(메커니즘): 관리형은 인제스천 파이프라인이 블랙박스라 파싱 실패·청크 경계 문제를 재현하기 어렵고, 권한은 메타데이터 필터 수준으로만 제어된다. 자체 구축은 트레이스(질의→검색→프롬프트→응답)를 전 구간 저장해 골든셋 회귀 게이트를 걸 수 있지만, 그 평가 체계 자체를 만드는 데 초기 공수가 든다. 통제력과 시간·종속의 교환이다.
본 시나리오 권고: 2개 부서·5만 문서 파일럿을 관리형으로 8~12주 안에 띄워 nDCG@10·faithfulness 기준선을 확보하고, 전사 확산 시 검색 계층(OpenSearch 하이브리드 + DLS)은 자체 구축, 생성·가드레일은 관리형 API를 쓰는 혼합 구성으로 간다. 전환 판단 기준은 "골든셋에서 관리형 대비 nDCG@10 +N pp 이상 개선"처럼 수치로 둔다.
GraphRAG vs 벡터 RAG
결론: 벡터(하이브리드) RAG를 기본으로 두고, 다중 홉·관계·전역 요약 질의만 GraphRAG로 라우팅한다. GraphRAG는 벡터 RAG의 실패 영역을 메우는 추가 수단이지 대체재가 아니다.
| 기준 | 벡터(하이브리드) RAG | GraphRAG |
|---|---|---|
| 강한 질의 유형 | 단일 홉 사실 조회·유사 문서 | 다중 홉(상품→담보→조항→개정), 관계, 전역 테마 요약 |
| 구축 비용 | 임베딩 1회/청크 | 청크당 LLM 호출 1~3회(엔티티·관계 추출), 커뮤니티 요약 |
| 갱신 | 증분 색인 용이 | MS GraphRAG는 커뮤니티 재계산, LightRAG는 증분 지원 |
| 지연 | 낮음 | 그래프 순회·요약 map-reduce로 높음 |
| 설명 가능성 | 인용 청크 | 경로(엔티티–관계)로 설명 가능 |
언제 선택 / 피함
- 벡터 RAG: 사실 조회·FAQ·규정 조항 찾기처럼 단일 홉이 대부분이고 코퍼스가 자주 바뀔 때. 흩어진 관계를 묶어야 하는 질의 비율이 유의미하면 단독으로는 부족하다.
- GraphRAG: 골든셋에서 벡터 RAG 실패 사례가 관계·전역 질의로 확인되고 인덱싱 비용을 감당할 때. 코퍼스가 매일 바뀌고 예산이 민감하면 피한다.
트레이드오프(메커니즘): 벡터 RAG는 청크 단위 유사도만 보므로 “A 상품 특약 B가 참조하는 규정 C의 개정이 D 프로세스에 미치는 영향” 같은 질의에서 중간 노드 청크를 검색하지 못한다. GraphRAG는 엔티티 이웃 탐색(local)·커뮤니티 요약(global)으로 이를 풀지만, 그래프 품질이 한국어 고유명사·조직명 추출 정확도에 좌우되므로 추출 프롬프트에 사내 온톨로지를 주입해야 한다.
본 시나리오 권고: 하이브리드 + 재순위 + 계층 청킹으로 먼저 품질을 올리고, 잔여 실패 중 관계 질의 비중(예: 골든셋의 15% 이상)이 확인되면 보험 온톨로지(상품–담보–약관 조항–개정 이력) 범위에 한정해 GraphRAG를 추가한다. 라우터가 질의 유형을 분류하고, 라우팅 오류에 대비해 멀티 라우트 + RRF 폴백을 둔다.
Lambda vs Kappa
결론: Iceberg 레이크하우스 전제에서는 **“Kappa 지향, 레이크하우스 보정”**이 정답이다. 스트림을 1차 경로로 두되 Iceberg 테이블을 단일 진실로 삼고, 배치 재계산이 필요하면 스냅샷에서 재생성한다.
| 기준 | Lambda | Kappa |
|---|---|---|
| 구조 | 배치 계층 + 속도 계층 + 서빙 병합 | 스트림 단일 계층, 재처리는 로그 재생 |
| 코드 경로 | 로직 이중 구현(불일치 위험) | 단일 구현 |
| 정확성 보정 | 배치로 재계산 쉬움 | 로그 장기 보존·대규모 재처리 시간 필요 |
| 운영 역량 | 배치 역량으로 가능 | 스트리밍(Flink·체크포인트) 역량 필수 |
| 2026년 현실 | 레이크하우스가 서빙 병합 흡수 → 완화된 Lambda | Kafka 계층형 스토리지 + Flink로 실현 가능 |
언제 선택 / 피함
- Lambda: 정합성 규제 리포팅이 핵심이고 배치 자산이 많으며 스트리밍 역량이 부족할 때. 같은 로직을 두 번 유지할 인력이 없으면 불일치가 누적되어 피해야 한다.
- Kappa: 로그·거래 이벤트 중심 도메인, 재처리 요구가 빈번할 때. Kafka 보존 기간을 넘는 재처리가 잦으면 비용이 커진다.
트레이드오프(메커니즘): Kappa의 리플레이는 브로커 로그를 처음부터 다시 소비하므로 재처리 시간이 데이터량에 비례하고 로그 장기 보존 비용이 든다. 레이크하우스 보정은 이 리플레이를 Iceberg 스냅샷 기반 배치 재계산으로 대체해 보존 비용을 객체 스토리지 수준으로 낮추지만, 그 대신 싱크의 멱등성(비즈니스 키 + LSN/ts 기반 MERGE, 구버전 무시)과 체크포인트 단위 커밋을 설계해야 한다.
본 시나리오 권고: 코어 CDC(일 3천만 건)와 웹/앱 이벤트(일 5억 건)는 Kafka/MSK → Flink → Iceberg(MOR + 주기 컴팩션)로 단일 경로 처리하고, 월말 규제 집계는 Iceberg 스냅샷을 고정해 배치로 재계산한다. exactly-once는 Kafka↔Flink↔Iceberg 구간에 한정해 보장하고 전체는 at-least-once + 멱등 소비로 설계한다.
데이터 메시 vs 중앙집중 플랫폼
결론: 데이터 팀 12~15명 규모에서는 중앙 플랫폼 팀이 표준·플랫폼을 세우고, 메시의 4원칙 중 "데이터 프로덕트 + 셀프서비스"만 먼저 도입하는 하이브리드가 정답이다. 도메인 오너십·연합 거버넌스는 Wave 2 이후 점진 확대한다.
| 기준 | 중앙집중 플랫폼 | 데이터 메시 |
|---|---|---|
| 조직 전제 | 중앙 데이터 조직이 강하고 도메인 역량 부족 | 도메인 팀이 데이터 엔지니어링 역량 보유 |
| 표준화·일관성 | 높음(규제 리포팅 중앙 집중에 유리) | 연합 거버넌스로 강제해야 함 |
| 확장성·병목 | 요청이 중앙에 몰리면 병목 | 도메인 병렬 처리 |
| 실패 모드 | 리드타임 증가·백로그 | 표준 없으면 사일로 재발 |
| 도입 비용 | 낮음 | 조직·문화 성숙도 요구 |
언제 선택 / 피함
- 중앙집중: 조직이 작고 표준화·규제 보고 일관성이 우선일 때. 도메인 수가 많아 중앙 리드타임이 주 단위로 늘어나면 한계다.
- 메시: 다수 도메인이 각자 역량을 갖추고 중앙이 병목일 때. 4원칙을 동시 도입하면 중앙의 명확성도 분산의 이점도 잃는 실패 사례가 많아 피한다.
트레이드오프(메커니즘): 자율성과 일관성의 교환이다. 메시는 도메인이 자기 데이터 프로덕트의 스키마·SLO를 책임지므로 변경 속도가 빠르지만, 플랫폼 팀이 표준 스키마·분류·SLO를 policy-as-code로 강제하지 않으면 조인 키·지표 정의가 도메인마다 갈라진다. 중앙집중은 반대로 정의는 하나지만 모든 변경이 중앙 큐를 통과한다.
본 시나리오 권고: 전환 초기(Wave 0~1)는 중앙 플랫폼 팀이 레이크하우스·카탈로그·컨트랙트 표준을 세우고, Wave 2부터 계리·보험금·마케팅 도메인을 데이터 프로덕트 오너로 온보딩한다. 연합 거버넌스의 최소 단위는 "표준 스키마·분류·SLO 정의 + 자동화 정책 강제"이며, 보험사처럼 규제 리포팅이 중앙 집중이면 거버넌스는 패브릭형 카탈로그(DataZone/DataHub)로 중앙에 둔다.
Long-context LLM vs RAG vs 파인튜닝
결론: 엔터프라이즈 기본은 RAG이고, long-context는 RAG가 고른 후보를 더 넉넉히 수용하는 보완재, 파인튜닝은 형식·어휘 학습용이다. 세 가지는 대체가 아니라 조합 대상이다.
| 기준 | Long-context 단독 | RAG | 파인튜닝 |
|---|---|---|---|
| 적합 코퍼스 | 소량(수십 문서)·고정 | 대규모·갱신 잦음 | 스타일·형식·도메인 어휘 |
| 최신 사실 반영 | 매 질의마다 문서를 넣으면 가능하나 비용 | 인덱스 증분 갱신 | 부적합(재학습 필요) |
| 권한 통제 | 사용자별 부분집합 선별이 결국 검색 | ACL pre-filter로 구조적 통제 | 모델에 학습된 지식은 권한 분리 불가 |
| 인용·근거 | 문서 전체 중 근거 위치 불명확 | 청크 단위 인용 | 불가 |
| 비용·지연 | 질의마다 문서 크기에 비례 | 거의 상수 | 학습 비용 1회 + 서빙 |
언제 선택 / 피함
- Long-context: 수십 문서의 고정 코퍼스를 일회성으로 분석할 때. 수백만 청크 코퍼스·권한 상이·최신성 요구에는 피한다(lost-in-the-middle·어텐션 희석 포함).
- RAG: 대규모·갱신·권한·인용이 필요한 사내 지식 검색의 기본. 코퍼스가 수십 문서뿐이면 과한 구성이다.
- 파인튜닝: 답변 형식·톤·사내 용어 학습. 최신 사실 주입이나 권한별 지식 분리 목적에는 피한다.
트레이드오프(메커니즘): long-context는 문서 전체를 넣으므로 검색 실패가 없다는 장점이 있지만, 토큰 비용·지연이 문서 크기에 비례하고 사용자 권한에 맞는 부분집합을 잘라 넣으려면 결국 검색·필터가 필요하다. RAG는 비용이 상수지만 검색이 실패하면 답도 실패하므로 재순위·골든셋 평가가 필수다. 파인튜닝은 지식을 가중치에 넣어 인용·삭제·권한 분리가 불가능해진다.
본 시나리오 권고: 100만 문서·권한 상이·월 2% 갱신 조건에서 RAG가 후보 8~10개를 고르고, 긴 규정은 small-to-big으로 부모 문서를 long-context에 수용한다(프롬프트 캐싱으로 반복 프리픽스 비용 절감). 인용 형식·거부 문구·사내 용어는 경량 파인튜닝 또는 few-shot으로 고정하고, 사실 지식은 절대 파인튜닝으로 넣지 않는다.
