IT 인프라·아키텍처·데이터 기술사 답안 세트 1

IT 인프라·아키텍처·데이터 기술사 답안 — 세트 1

플랫폼 엔지니어링 · AP2 · LOD · IaC · Data Lake · Lakehouse · FaaS · EDA · 데이터 전처리 · B-Tree/B+Tree | 정보관리기술사 대비

플랫폼 엔지니어링 (Platform Engineering)

내부 개발자 플랫폼(IDP) 설계·운영 · Gartner 2023 10대 전략 트렌드

개념

정의: 개발자가 셀프 서비스 방식으로 인프라와 도구를 사용할 수 있도록 내부 개발자 플랫폼(IDP: Internal Developer Platform)을 제품으로 설계·구축·운영하는 전문 분야

등장 배경: DevOps 확산 → "You Build It, You Run It" → 개발자 인지 부하(Cognitive Load) 폭증 → 인도셀보(인지부하·도구복잡성·셀프서비스부재·보안갈등) 4대 한계 극복

개념도 — IDP 계층 구조

개발자 (Developer) — 셀프 서비스 소비자

Developer Portal (Backstage 등)

인프라
오케스트레이션
Crossplane

배포
자동화
ArgoCD

환경
관리
vcluster

관측
가능성
OTel

인프라 계층 (K8s · Cloud · On-prem)

IDP 4대 기능 — "인배환관" (인프라오케·배포자동·환경관리·관측가능성)

주요 구성 요소 — 설계 원칙 "제셀골추"

두문자	원칙	핵심 내용	구현 예시
제	제품 사고 (Product Thinking)	플랫폼을 내부 제품으로 설계. 개발자가 고객 — 기존 인프라 팀의 "도구 제공"과 결정적 차이	NPS 측정, 로드맵 공개, 사용자 인터뷰
셀	셀프 서비스 (Self-Service)	Ops 티켓 없이 개발자가 직접 인프라를 프로비저닝	Backstage 서비스 카탈로그, 골든패스 템플릿
골	골든 패스 (Golden Path)	검증된 베스트 프랙티스 경로를 기본값으로 제공	표준 스캐폴딩, CI/CD 템플릿
추	추상화 (Abstraction)	인프라 복잡성을 플랫폼 뒤에 숨김. 개발자는 비즈니스 로직에만 집중	PaaS 레이어, 원클릭 환경 생성

DevOps vs 플랫폼 엔지니어링 비교

DevOps vs 플랫폼 엔지니어링

DevOps: 문화·철학 — 개발과 운영의 협업
플랫폼 엔지니어링: 그 문화를 제품으로 구체화

Conway 법칙: 조직 구조 → 시스템 구조. 플랫폼 팀이 별도 존재 시 플랫폼이 독립 제품화
Gartner: 2026년까지 대규모 SW 조직 80%가 플랫폼 팀 구성 전망

적용 사례

Spotify: Backstage 오픈소스화 — 서비스 카탈로그 표준
Mercedes-Benz: IDP로 배포 시간 80% 단축
Humanitec 2024: 개발자 30~40% 시간이 인프라 작업에 낭비

💡 킬러 문장: "DevOps가 문화라면, 플랫폼 엔지니어링은 그 문화를 제품으로 구체화한 것이다. IDP는 개발자의 인지 부하를 줄이는 내부 SaaS다."

AUTOSAR Adaptive Platform (AP) Protocol

자율주행·커넥티드카 미들웨어 표준 · SOME/IP 기반 서비스 지향 통신

개념

정의: 자율주행·고성능 컴퓨팅이 필요한 차량용 소프트웨어를 위한 AUTOSAR Adaptive Platform의 통신 프로토콜 체계. 기존 Classic Platform(정적·OSEK 기반)의 한계를 극복하고 SOA(Service-Oriented Architecture) 기반 동적 통신 지원

핵심: ara::com API + SOME/IP 프로토콜로 차량 내 서비스 검색·호출·이벤트 구독을 유연하게 구현

개념도 — AP 통신 구조

Service Provider
ara::com
OfferService()

→

Service Discovery
SOME/IP-SD
Find/Offer

→

Service Consumer
ara::com
FindService()

주요 구성 요소 — "아이서이직"

두문자	요소	핵심 내용	Classic Platform 대비
아	ara::com API	AP의 표준 통신 API. Service, Method, Event, Field 4가지 통신 패턴 제공	CP는 COM 모듈 정적 구성 — AP는 런타임 동적
이	SOME/IP 프로토콜	Scalable service-Oriented MiddlewarE over IP. UDP/TCP 기반 차량 이더넷 통신	CP는 CAN 버스 기반 — AP는 이더넷 기반
서	서비스 지향 통신	서비스 검색(SD), 메서드 호출(RPC), 이벤트 구독(Pub/Sub) 지원	CP는 신호 기반 통신 — AP는 서비스 기반
이	이더넷 기반	100Mbps~10Gbps 차량 이더넷. 자율주행 센서 데이터 처리 가능	CAN은 최대 1Mbps — 자율주행에 대역폭 부족
직	직렬화·역직렬화	SOME/IP, DDS, 사용자 정의 등 다양한 직렬화 바인딩 지원	CP는 RTE 자동 생성 정적 코드

Classic Platform vs Adaptive Platform 비교

CP vs AP 핵심 비교

CP: 정적 구성, OSEK/VDX RTOS, CAN 버스, 결정론적, 소형 ECU
AP: 동적 구성, POSIX OS(Linux), Ethernet, 유연함, 고성능 SoC

공존: CP가 안전 크리티컬, AP가 고성능 AI 처리

ISO 26262 연계 및 적용

기능안전: AP도 ASIL-B 이상 지원
사이버보안: ISO 21434와 연계. TLS 기반 암호화 통신
적용: BMW iX — AP 기반 자율주행. Mercedes EQS — OTA 업데이트 AP 활용

💡 킬러 문장: "AUTOSAR AP는 차량 소프트웨어를 CAN 신호에서 이더넷 서비스로 전환시킨 패러다임이다. 자율주행 AI의 실시간 데이터 처리는 AP 없이는 불가능하다."

Linked Open Data (LOD)

웹 상의 데이터를 연결·개방하는 시맨틱 웹 실현 기술 · W3C 표준

개념

정의: 웹 표준(URI·RDF·SPARQL·HTTP)을 사용하여 구조화된 데이터를 서로 연결하고 공개하는 방법론. Tim Berners-Lee가 제안한 시맨틱 웹(Semantic Web)의 실현 형태

4원칙: ①모든 것에 URI 사용 ②HTTP URI 사용 ③URI 조회 시 유용한 정보 제공 ④다른 URI로의 링크 포함

개념도 — LOD 5성급 모델

★★★★★ 5성: 다른 LOD와 연결 (owl:sameAs 등)

★★★★ 4성: 데이터에 URI 사용 (RDF, SPARQL)

★★★ 3성: 비독점 형식 (CSV, XML, JSON)

★★ 2성: 기계 판독 가능 구조 (Excel)

★ 1성: 오픈 라이선스 (PDF·이미지)

주요 구성 요소 — "유알스온"

두문자	기술	핵심 내용	예시
유	URI	웹의 모든 자원(사람·장소·개념)에 고유 식별자 부여	http://dbpedia.org/resource/Seoul
알	RDF	주어-술어-목적어 트리플로 지식 표현	<Seoul> <capitalOf> <Korea>
스	SPARQL	RDF 데이터 질의 언어. SQL과 유사하나 그래프 탐색 가능	SELECT ?name WHERE {?s foaf:name ?name}
온	온톨로지	도메인 개념·관계 정의. OWL·RDFS로 지식 계층 구조 표현	FOAF, Dublin Core, Schema.org

활용 사례 및 GraphRAG 연계

주요 LOD 데이터셋

DBpedia: Wikipedia RDF 변환 — 450억 트리플
Wikidata: 위키미디어 재단 지식 그래프
공공 LOD: 행정안전부 공공데이터포털 LOD 서비스
의료: SNOMED CT, UMLS 온톨로지

GraphRAG · AI와의 연계

GraphRAG: LOD 지식 그래프를 LLM 검색 기반으로 활용
지식 그래프 AI: Neo4j + LOD로 추론 가능 AI 구축
한계: 데이터 이질성, 링크 부정확, SPARQL 복잡성
Schema.org: Google·Bing이 채택한 LOD 온톨로지

💡 킬러 문장: "LOD는 웹을 문서의 바다에서 데이터의 그래프로 전환시키는 기술이다. URI·RDF·SPARQL의 삼각형이 기계가 이해할 수 있는 웹을 만든다."

코드형 인프라 (IaC: Infrastructure as Code)

인프라를 코드로 정의·관리·자동화 · DevOps 핵심 실천

개념

정의: 서버·네트워크·데이터베이스 등 인프라 자원을 코드(선언형·명령형 파일)로 정의하고, 버전 관리·자동화·테스트 방법론을 적용하여 인프라를 프로비저닝·관리하는 방법론

핵심 장점: "스노우플레이크 서버" 제거 → 불변 인프라(Immutable Infrastructure) 실현

개념도 — IaC 작동 방식

코드 작성
HCL·YAML
선언형 정의

→

버전 관리
Git 저장소
코드 리뷰

→

CI/CD 실행
Plan→Apply
자동 검증

→

인프라 생성
클라우드 자원
멱등성 보장

주요 구성 요소 — "선멱버불테"

두문자	특성	핵심 내용	대표 도구
선	선언형 vs 명령형	선언형: "원하는 상태" 기술. 명령형: "수행할 절차" 기술	Terraform(선언), Ansible(명령)
멱	멱등성 (Idempotency)	동일 코드를 여러 번 실행해도 결과가 같음	Terraform State 파일로 현재 상태 추적
버	버전 관리	인프라 변경 이력 추적. PR 기반 코드 리뷰로 인프라 거버넌스 실현	Git + GitHub Actions / GitLab CI
불	불변 인프라	변경 시 기존 서버 수정이 아닌 새 서버 생성 후 교체	Packer + AMI + Terraform
테	테스트 가능성	인프라 코드에 단위·통합 테스트 적용. Dry-run(plan)으로 사전 검증	Terratest, Checkov, tfsec

주요 도구 비교 및 GitOps 연계

IaC 도구 비교

Terraform: HashiCorp HCL, 멀티클라우드, 가장 널리 사용
Pulumi: Python·TypeScript·Go 등 범용언어 사용
Ansible: 에이전트리스, 구성관리 특화
Crossplane: K8s 기반 멀티클라우드 제어

GitOps와 IaC 결합

GitOps: Git 저장소를 단일 진실 원천(SSOT)으로. 선언형 상태를 자동 동기화
ArgoCD + Terraform: 앱(ArgoCD) + 인프라(Terraform) 모두 Git 기반
Atlantis: Terraform PR 자동화

💡 킬러 문장: "IaC는 인프라에 소프트웨어 개발의 규율을 적용한 것이다. 서버는 더 이상 아끼는 '펫(Pet)'이 아니라 언제든 교체 가능한 '소(Cattle)'다."

Data Lake (데이터 레이크)

원시 데이터를 스키마 없이 저장하는 대규모 중앙 저장소 · ELT 패러다임

개념

정의: 정형·반정형·비정형 데이터를 원시 형태(Raw Format)로 대규모 저장하는 중앙 집중형 저장소. "스키마 온 리드(Schema-on-Read)" 방식으로 분석 시점에 스키마 적용

Data Warehouse와 차이: DW는 "스키마 온 라이트(Schema-on-Write)" — 저장 전에 스키마 정의. Data Lake는 일단 저장, 나중에 스키마 적용

개념도 — Medallion Architecture

데이터 소스: RDB · 로그 · IoT · SNS · 문서

Bronze Layer
원시 데이터
변환 없음

→

Silver Layer
정제·정규화
품질 검증

→

Gold Layer
집계·비즈니스
분석 준비

주요 구성 요소 — "저처카거보"

두문자	요소	핵심 내용	대표 기술
저	저장소	객체 스토리지 기반. 저비용 대용량. Parquet·ORC 파일 포맷	AWS S3, Azure Data Lake Storage Gen2
처	처리 엔진	배치(Spark), 스트리밍(Flink·Kafka), SQL(Presto·Athena)	Apache Spark, Databricks
카	카탈로그	메타데이터 관리 — 어떤 데이터가 어디 있는지 추적	AWS Glue, Apache Atlas, DataHub
거	거버넌스	데이터 품질·접근 제어·감사 로그. "데이터 스웜프" 방지	Apache Ranger, Unity Catalog
보	보안	열·행 수준 접근 제어. 암호화. PII 마스킹	AWS Lake Formation, Privacera

DW vs Data Lake vs Lakehouse 비교

비교 기준	Data Warehouse	Data Lake	Lakehouse
스키마	온 라이트 (고정)	온 리드 (유연)	온 리드 + ACID
데이터 유형	정형만	모든 유형	모든 유형
비용	높음	낮음	중간
ML 지원	제한적	우수	최고

💡 킬러 문장: "Data Lake는 '일단 저장, 나중에 생각'의 철학이다. 하지만 거버넌스 없는 Data Lake는 Data Swamp(데이터 늪)가 된다."

Lakehouse (레이크하우스)

Data Lake + Data Warehouse 통합 · Delta Lake · Apache Iceberg · 2021 Databricks 제안

개념

정의: Data Lake의 저비용·유연성과 Data Warehouse의 ACID 트랜잭션·성능·거버넌스를 하나의 플랫폼에서 제공하는 차세대 데이터 아키텍처

핵심 기술: 오픈 테이블 포맷(Delta Lake·Apache Iceberg·Apache Hudi)이 객체 스토리지 위에 ACID 트랜잭션·스키마 진화·타임 트래블을 제공

개념도 — Lakehouse 아키텍처

오픈 테이블 포맷 레이어 (Delta Lake / Iceberg / Hudi)

ACID 트랜잭션 · 스키마 강제 · 타임 트래블 · 데이터 스키핑

객체 스토리지 (S3 / ADLS / GCS) — Parquet 파일

SQL 분석
Spark SQL · Presto

ML/AI
MLflow · TensorFlow

스트리밍
Structured Streaming

주요 구성 요소 — "산타스거오"

두문자	특성	핵심 내용	구현 기술
산	산업 표준 포맷	오픈 테이블 포맷으로 벤더 종속 없는 개방형 데이터	Apache Iceberg (Netflix), Delta Lake (Databricks)
타	타임 트래블	과거 시점 데이터 조회. 실수로 삭제된 데이터 복원	Delta Lake: DESCRIBE HISTORY, VERSION AS OF
스	스키마 진화	기존 데이터 영향 없이 컬럼 추가·변경 가능	Schema Evolution (ADD COLUMNS 등)
거	거버넌스 통합	Unity Catalog로 전사 데이터 카탈로그·접근 제어·계보 관리 통합	Unity Catalog, Apache Atlas
오	ACID 트랜잭션	객체 스토리지 위에서 ACID 보장	Delta Log (트랜잭션 로그), Optimistic Concurrency

오픈 테이블 포맷 비교

Delta Lake vs Iceberg vs Hudi

Delta Lake: Databricks 주도, Spark 최적화, ZORDER 클러스터링
Iceberg: Netflix 개발, 멀티엔진(Spark·Flink·Trino), hidden partitioning
Hudi: Uber 개발, 증분 처리·스트리밍 업서트 특화

Data Mesh와의 관계

Data Mesh: 도메인 중심 분산 데이터 소유권 아키텍처
Lakehouse: Data Mesh의 인프라 구현체
AI 연계: Feature Store → ML 학습을 Lakehouse에서 직접 수행

💡 킬러 문장: "Lakehouse는 Data Lake의 자유로움과 Data Warehouse의 신뢰성을 합쳤다. '저장은 레이크처럼, 분석은 웨어하우스처럼'이 핵심이다."

FaaS (Function as a Service)

서버리스 컴퓨팅의 핵심 · 이벤트 기반 함수 실행 · AWS Lambda 대표

개념

정의: 개발자가 개별 함수 단위로 코드를 배포하면, 클라우드 공급자가 서버 관리·스케일링·OS 패치를 모두 처리하는 서버리스(Serverless) 실행 모델

과금 방식: 요청 수 × 실행 시간 × 메모리 — 유휴 상태에서는 비용 0

개념도 — FaaS 실행 흐름

이벤트 트리거
HTTP·S3·DB
스케줄러

→

Cold Start
컨테이너
초기화 (~100ms)

→

함수 실행
비즈니스 로직
최대 15분

→

결과 반환
응답·이벤트
다음 서비스

주요 구성 요소 — "이무상콜스"

두문자	특성	핵심 내용	AWS Lambda 예시
이	이벤트 기반	HTTP 요청·DB 변경·파일 업로드·스케줄러 등 다양한 이벤트가 함수를 트리거	API Gateway·S3·DynamoDB Streams 트리거
무	무상태 (Stateless)	함수 호출 간 상태 미공유. 영구 상태는 외부 저장소에 보관	Lambda는 실행마다 새 컨테이너 인스턴스
상	자동 스케일링	동시 요청 수에 따라 자동으로 인스턴스 수 조정	AWS Lambda: 기본 1000 동시 실행 한도
콜	Cold Start	장시간 미호출 시 컨테이너 재초기화 지연(100ms~수초)	Provisioned Concurrency로 Cold Start 제거
스	세분화 과금	100ms 단위 과금. 유휴 비용 없음	월 100만 건 무료 + 실행 시간 요금

클라우드 서비스 모델 비교

IaaS·PaaS·FaaS·SaaS 비교

IaaS: VM 제공 (EC2) — 관리 많음, 유연성 최고
PaaS: 플랫폼 제공 (Elastic Beanstalk) — 코드만 배포
FaaS: 함수 제공 — 관리 최소
추상화 수준: IaaS < PaaS < FaaS < SaaS

FaaS 한계 및 적합 시나리오

한계: Cold Start 지연, 최대 실행시간 제한, 벤더 종속
적합: 이벤트 처리·API 백엔드·배치·이미지 리사이징·IoT
부적합: 장시간 실행, 레이턴시 극도 민감
Knative: K8s 기반 오픈소스 FaaS 플랫폼

💡 킬러 문장: "FaaS는 '서버를 생각하지 마라'는 서버리스 철학의 극한이다. 이벤트가 있을 때만 존재하고, 없으면 사라지는 함수형 컴퓨팅이다."

Event Driven Architecture (EDA)

이벤트를 중심으로 시스템을 느슨하게 결합 · MSA의 핵심 패턴 · Kafka 대표

개념

정의: 시스템 내에서 이벤트(사실의 기록)의 생성·감지·소비·반응을 중심으로 구성요소 간 통신을 설계하는 아키텍처 패턴. 생산자와 소비자가 직접 연결 없이(비동기) 이벤트 브로커를 통해 통신

이벤트: "과거에 발생한 사실" (Order Placed, Payment Completed) — 요청·명령과 구별

개념도 — EDA 구조

이벤트 생산자
주문서비스
결제서비스

→

이벤트 브로커
Kafka·RabbitMQ
AWS EventBridge

→

이벤트 소비자
알림서비스
재고서비스

주요 구성 요소 — "생브소토코"

두문자	요소	핵심 내용	대표 기술
생	이벤트 생산자	이벤트를 발생시키는 서비스. 소비자를 알지 못함 — 느슨한 결합의 출발점	MSA 마이크로서비스, IoT 센서
브	이벤트 브로커	이벤트를 수신·저장·라우팅. Topic 기반 Pub/Sub 또는 Queue 방식	Apache Kafka, RabbitMQ, AWS SQS/SNS
소	이벤트 소비자	관심 이벤트를 구독하여 처리. 생산자와 독립적으로 배포·스케일링	Consumer Group(Kafka), Lambda Trigger
토	토픽·파티션	이벤트 분류 채널. 파티션으로 병렬 처리. 오프셋으로 순서 보장	Kafka Topic·Partition·Offset
코	이벤트 스키마	이벤트 구조 계약. CloudEvents 표준, Schema Registry로 버전 관리	Confluent Schema Registry, Avro

EDA 패턴 및 Saga 패턴

EDA 핵심 패턴

Pub/Sub: 1:N 브로드캐스트
Event Sourcing: 상태 대신 이벤트 시퀀스 저장. 재생으로 어떤 시점의 상태도 복원
CQRS: 명령(쓰기)과 조회(읽기) 모델 분리
Dead Letter Queue: 처리 실패 이벤트 격리·재처리

Saga 패턴 (분산 트랜잭션)

문제: MSA에서 2PC 사용 불가 → 분산 트랜잭션 처리 필요
Choreography Saga: 이벤트로 보상 트랜잭션 자동 연쇄
Orchestration Saga: 중앙 오케스트레이터가 흐름 제어
보상 트랜잭션: 실패 시 이전 단계 취소 이벤트 발행

💡 킬러 문장: "EDA는 시스템 컴포넌트가 서로를 몰라도 협력할 수 있게 한다. 이벤트는 시스템의 과거 사실이며, 그 사실이 미래 행동을 만드는 것이다."

데이터 전처리 (Data Preprocessing)

ML·AI 학습 전 데이터 품질 확보 핵심 단계 · "Garbage In, Garbage Out" 방지

개념

정의: 원시 데이터(Raw Data)를 ML 모델 학습에 적합한 형태로 변환하는 일련의 과정. 데이터 품질이 모델 성능을 결정하므로 전체 ML 파이프라인에서 60~80% 시간이 소요되는 핵심 단계

원칙: "Garbage In, Garbage Out" — 품질 낮은 데이터로는 아무리 좋은 모델도 쓸모없음

개념도 — 전처리 파이프라인

수집
Raw Data

→

정제
결측·이상치

→

변환
정규화·인코딩

→

특성공학
Feature 선택

→

분할
Train·Val·Test

주요 구성 요소 — "결이정인특분"

두문자	단계	핵심 기법	주의사항
결	결측값 처리	삭제(Listwise), 평균·중앙값 대치, KNN 대치, MICE(다중 대치)	MCAR·MAR·MNAR 메커니즘 파악 후 방법 선택
이	이상치 탐지	Z-score(±3σ), IQR 방법, DBSCAN, Isolation Forest, LOF	이상치 = 오류 vs 정상 극단값 구별 필요
정	정규화·표준화	Min-Max 정규화[0,1], Z-score 표준화(μ=0,σ=1), Robust Scaler(IQR)	테스트셋에는 학습셋 통계값 적용 (Data Leakage 방지)
인	인코딩	Label Encoding(순서형), One-Hot Encoding(명목형), Target Encoding	고카디널리티 변수에 One-Hot → 차원의 저주
특	특성 선택·공학	Filter(상관계수), Wrapper(RFE), Embedded(LASSO). 파생변수 생성	도메인 지식 활용 필수
분	데이터 분할	Train(60~80%)/Validation(10~20%)/Test(10~20%). K-Fold CV	시계열 데이터는 시간 순서 유지 분할 (shuffle 금지)

Data Leakage 및 불균형 데이터 처리

Data Leakage (데이터 누출)

정의: 학습 시 미래 정보·테스트셋 정보가 학습에 개입 → 과낙관적 성능
방지: Pipeline 사용 — fit()은 Train에만, transform()은 Test에 적용
결과: 실제 배포 시 성능 급락

클래스 불균형 처리

Over-sampling: SMOTE(소수 클래스 합성), ADASYN
Under-sampling: Random, Tomek Links, ENN
평가지표: 불균형 시 Accuracy 대신 F1, AUC-ROC 사용
임계값: PR-Curve로 최적 임계값 결정

💡 킬러 문장: "데이터 전처리는 ML의 요리 준비다. 좋은 재료(데이터)를 제대로 손질해야 맛있는 요리(모델)가 나온다."

B-Tree / B+Tree

DBMS 인덱스의 핵심 자료구조 · 디스크 I/O 최소화 · O(log n) 탐색

개념

B-Tree 정의: 모든 노드에 키와 데이터를 함께 저장하는 균형 다진 탐색 트리(Balanced Multiway Search Tree). 차수 m에서 각 노드는 최대 m-1개 키와 최대 m개 자식 보유

B+Tree 정의: B-Tree의 변형. 리프 노드에만 실제 데이터를 저장하고, 내부 노드는 키만 보유. 리프 노드들이 링크드 리스트로 연결 → 범위 탐색 O(n) 효율

개념도 — B+Tree 구조

내부 노드 (키만 저장, 라우팅용)

20 | 40

10 | 15

25 | 30

45 | 50

리프 노드 (실제 데이터 저장, 링크드 리스트로 연결)

10·D1 | 15·D2

→

25·D3 | 30·D4

→

45·D5 | 50·D6

B-Tree vs B+Tree 핵심 비교

비교 기준	B-Tree	B+Tree
데이터 위치	모든 노드에 키+데이터	리프 노드에만 키+데이터
내부 노드	키+데이터 포함	키만 포함 (라우팅용)
범위 탐색	중위 순회 필요 — 비효율	리프 링크드 리스트 순회 — O(n) 효율
탐색 깊이	데이터가 내부에 있을 수 있어 빠름	항상 리프까지 — 일관된 O(log n)
노드 용량	데이터 저장으로 팬아웃 낮음	키만 저장으로 팬아웃 높음 → 트리 낮음
DBMS 사용	MongoDB (B-Tree 변형)	MySQL InnoDB, PostgreSQL, Oracle

DBMS 인덱스 설계 실무

연산 복잡도

탐색: O(log n) — 균형 보장
삽입: O(log n) + 노드 분할(Split) 가능
삭제: O(log n) + 노드 병합(Merge) 가능
범위 탐색 (B+Tree): O(log n + k) — k는 결과 수

DBMS 인덱스 설계

Clustered Index: 데이터 자체가 B+Tree 리프에 저장 (InnoDB PK)
Non-clustered: 리프에 PK 참조값 저장
복합 인덱스: 선두 컬럼 기준 정렬 — 선두 생략 시 인덱스 미사용
Index Only Scan: 인덱스에서만 데이터 해결

💡 킬러 문장: "B+Tree가 DBMS 인덱스의 표준이 된 이유는 두 가지다. 내부 노드의 팬아웃을 높여 트리 높이를 줄이고, 리프의 링크드 리스트로 범위 탐색을 선형화했다."