핵심 인사이트 (3줄 요약)
- 본질: 규칙 기반 옵티마이저 (RBO, Rule-Based Optimizer)는 SQL (Structured Query Language) 실행 계획을 고를 때 통계가 아니라 미리 정해 둔 규칙 서열을 따르는 방식이다.
- 가치: 데이터 양이 작고 패턴이 단순하던 시절에는 예측 가능성이 높아, 개발자가 인덱스와 SQL 문법만 보고도 어떤 계획이 나올지 쉽게 짐작할 수 있었다.
- 판단 포인트: 현대 환경에서는 선택도 (Selectivity), 카디널리티 (Cardinality), 입출력 비용을 반영하지 못해 쉽게 비효율이 생기므로, RBO는 "역사적 이해와 레거시 해석"의 관점으로 기억하는 것이 맞다.
Ⅰ. 개요 및 필요성
규칙 기반 옵티마이저 (RBO, Rule-Based Optimizer)는 데이터베이스가 쿼리를 실행할 때 "어떤 길로 읽을지"를 사전 정의된 우선순위 규칙으로 결정하는 구형 최적화 방식이다. 핵심은 "얼마나 많이 읽는가"보다 "어떤 접근 경로가 더 높은 서열인가"를 먼저 보는 것이다. 따라서 RBO는 비용 계산기라기보다, 정해진 교통 법규집에 따라 움직이는 정적 라우터에 가깝다.
이 방식이 필요했던 이유는 초기 상용 데이터베이스가 지금처럼 풍부한 통계 수집과 복잡한 비용 모델을 돌리기 어려웠기 때문이다. CPU (Central Processing Unit)와 메모리 자원이 제한된 환경에서는 복잡한 최적화보다 빠르고 일관된 판단이 중요했다. 또한 온라인 거래 처리 (OLTP, Online Transaction Processing) 중심의 비교적 작은 업무에서는 기본키 인덱스나 유니크 인덱스를 우선하는 단순 규칙이 꽤 잘 맞아떨어졌다.
이 그림은 RBO가 "현재 교통량"이 아니라 "도로 등급표"만 보고 경로를 정하는 구조임을 보여준다.
┌──────────────────────────────────────────────────────────────────┐
│ RBO decision path: syntax first │
├──────────────────────────────────────────────────────────────────┤
│ SQL parse │
│ │ │
│ ├─ check ROWID / UNIQUE / INDEX existence │
│ │ │
│ ├─ apply fixed rank order │
│ │ │
│ └─ choose access path without table statistics │
└──────────────────────────────────────────────────────────────────┘
즉 RBO는 "빠르게 계산하는 똑똑함"보다 "항상 같은 규칙으로 판단하는 단순함"에 최적화된 설계였다. 문제는 데이터가 커지고 분포가 달라질수록, 이 단순함이 곧 맹목성으로 바뀐다는 점이다.
- 📢 섹션 요약 비유: RBO는 실시간 교통 앱이 아니라 오래된 종이 지도와 같다. 도로 등급은 잘 알지만, 오늘 그 길이 막혔는지는 전혀 모른 채 늘 같은 길로 안내한다.
Ⅱ. 아키텍처 및 핵심 원리
RBO의 입력은 주로 SQL 문법 구조와 인덱스 존재 여부다. 테이블에 10건이 있든 1억 건이 있든, 조건절에 어떤 인덱스를 탈 수 있는지가 더 중요하다. 그래서 결정 과정은 "통계 수집 → 비용 비교"가 아니라 "후보 경로 확인 → 규칙 순위 적용"으로 매우 짧다.
| 판단 요소 | RBO에서 보는 것 | RBO가 놓치는 것 |
|---|---|---|
| 접근 경로 | ROWID, UNIQUE 인덱스, 일반 인덱스, 전체 스캔 | 실제 행 수와 분포 |
| 조인 선택 | 문법과 규칙 기반 우선순위 | 조인 결과 크기 예측 |
| 계획 안정성 | 같은 SQL이면 비슷한 계획 유지 | 데이터 성장에 따른 자동 적응 |
대표적인 사고방식은 "고서열 인덱스가 있으면 일단 그 길을 탄다"이다. 예를 들어 주문 테이블 1,000만 건 중 900만 건이 조건에 맞더라도, 조건 컬럼에 일반 인덱스가 있으면 RBO는 여전히 인덱스 경로를 선호할 수 있다. 이 경우 랜덤 I/O (Input/Output)가 과도하게 늘어 전체 테이블을 순차적으로 읽는 것보다 느려질 수 있다.
아래 그림은 RBO가 선택도보다 규칙 서열을 우선하기 때문에 생기는 구조적 한계를 보여준다.
┌──────────────────────────────────────────────────────────────────┐
│ Example: rank wins over actual volume │
├──────────────────────────────────────────────────────────────────┤
│ Query: WHERE order_date >= '2025-01-01' │
│ Matching rows: 9000000 / 10000000 │
│ Index on order_date exists? YES │
│ │
│ RBO thought: "Index rank > Full scan rank" │
│ Actual effect: millions of index probes + table lookups │
│ Better choice in many cases: sequential full table scan │
└──────────────────────────────────────────────────────────────────┘
이 때문에 과거에는 개발자가 SQL 문장 순서, 힌트, 표현식 변형으로 RBO를 사실상 "유도"하는 일이 많았다. 옵티마이저가 똑똑해서 맡기는 구조가 아니라, 개발자가 규칙집을 이해하고 그 위에서 우회로를 만드는 구조였던 셈이다.
- 📢 섹션 요약 비유: RBO는 서류에 적힌 직급표만 보고 일을 맡기는 관리자와 같다. 실제 업무량이 얼마나 큰지는 보지 않고, 직급이 높아 보이는 사람에게 먼저 일을 몰아준다.
Ⅲ. 비교 및 연결
RBO를 이해하려면 비용 기반 옵티마이저 (CBO, Cost-Based Optimizer)와 함께 봐야 경계가 선명해진다. RBO는 예측 가능성이 강하지만 적응력이 약하고, CBO는 통계 품질에 영향을 받지만 대규모 데이터에서 훨씬 현실적인 결정을 내린다. 즉 둘의 차이는 단순한 "구형 vs 신형"이 아니라, "규칙의 안정성"과 "통계의 적응성" 중 어디에 무게를 두느냐의 차이다.
| 항목 | RBO | CBO |
|---|---|---|
| 판단 기준 | 사전 정의 규칙 순서 | 통계 기반 비용 계산 |
| 장점 | 단순함, 예측 가능성 | 데이터 규모 변화에 적응 |
| 약점 | 분포 변화에 둔감 | 통계 부정확 시 오판 가능 |
| 잘 맞는 환경 | 단순·소규모·고정 패턴 | 중대형·복합 조인·가변 패턴 |
이 차이는 인덱스 선택도와 직접 연결된다. 선택도가 높은 조건, 즉 결과가 극히 적을 때는 인덱스 접근이 유리하지만, 많은 행을 읽을 때는 전체 스캔이 더 효율적일 수 있다. RBO는 이 분기점을 계산하지 못하므로, 현대 SQL 튜닝에서는 통계 수집, 실행 계획 확인, 힌트 최소화가 더 중요한 원칙이 되었다.
또한 RBO는 데이터베이스 과목 안에서만 끝나지 않는다. 소프트웨어 공학 관점에서는 "하드코딩된 정책의 한계"를 보여주고, 시스템 성능 관점에서는 "측정 없이 규칙만 믿는 최적화"가 얼마나 위험한지 보여주는 사례가 된다.
- 📢 섹션 요약 비유: RBO와 CBO의 차이는 고정 시간표 버스와 실시간 배차 택시의 차이와 같다. 버스는 예측은 쉽지만 막힌 도로를 피해 가지 못하고, 택시는 상황을 보며 더 유리한 길을 바꿔 탄다.
Ⅳ. 실무 적용 및 기술사 판단
실무에서 RBO는 새로 도입할 기술이 아니라, 오래된 Oracle 기반 시스템을 해석할 때 만나는 레거시 개념이다. 특히 옛 애플리케이션에 RULE 힌트가 남아 있거나, 통계 갱신을 일부러 꺼 둔 환경이라면 RBO적 사고방식이 튜닝 습관에 남아 있을 수 있다. 이때 중요한 판단은 "과거의 예측 가능성을 유지할 것인가"가 아니라, "현대 비용 기반 환경으로 안전하게 옮길 것인가"다.
실무 체크리스트
- 쿼리에
RULE힌트나 과도한 인덱스 유도 문법이 남아 있는가? - 통계 정보가 최신인지, 그리고 실행 계획이 통계에 따라 바뀌는지 검증했는가?
- RBO 시절 튜닝 꼼수(불필요한 함수 적용, 문장 순서 의존)가 아직도 남아 있는가?
판단 포인트
- 채택보다 이해가 목적: 신규 설계에서는 RBO 사고방식을 채택할 이유가 거의 없다.
- 마이그레이션 시 주의: RBO 기반 SQL을 CBO 환경으로 옮길 때는 같은 결과라도 실행 계획이 완전히 달라질 수 있으므로, 배치·대량 조회 구간을 반드시 재검증해야 한다.
- 안티패턴: 인덱스를 타게 하려고 컬럼 표현식을 억지로 바꾸거나, 실행 계획을 문장 순서에 의존하게 만드는 튜닝은 유지보수성을 크게 떨어뜨린다.
결국 기술사 관점의 답안 포인트는 명확하다. RBO는 "왜 예전 시스템이 그렇게 작성되었는가"를 설명하는 키워드이지, 오늘의 권장 해법이 아니다. 실무 판단은 RBO를 미화하는 것이 아니라, 그 한계를 이해하고 통계 기반 최적화로 넘어가는 데 있다.
- 📢 섹션 요약 비유: RBO 레거시를 다루는 일은 오래된 수동 변속차를 모는 것과 같다. 왜 그런 조작이 필요했는지는 알아야 하지만, 지금 새 차를 설계하면서 굳이 불편한 방식을 고집할 이유는 없다.
Ⅴ. 기대효과 및 결론
RBO가 남긴 가장 큰 유산은 옵티마이저의 본질을 단순하게 드러냈다는 점이다. 실행 계획은 결국 "무엇을 읽고, 어떤 순서로 조인하며, 어디서 비용이 커지는가"를 결정하는 문제라는 사실을 RBO가 교과서처럼 보여준다. 규칙이 단순했기 때문에 오히려 접근 경로의 의미를 배우기 쉬웠다는 장점도 있었다.
하지만 현대 데이터베이스는 데이터량, 분포, 동시성, 하드웨어 특성이 계속 변한다. 이런 환경에서는 고정 규칙보다 측정과 비용 모델이 훨씬 중요하다. 따라서 RBO는 "단순해서 좋았던 시절의 방법"이 아니라, "규칙만으로는 최적화를 끝낼 수 없음을 증명한 역사적 단계"로 기억해야 한다.
앞으로의 확장 포인트는 세 가지 정도로 정리할 수 있다. 첫째, 통계 품질 관리가 실행 계획 안정성의 핵심이라는 점이다. 둘째, 힌트는 최후 수단이어야 한다는 점이다. 셋째, 옵티마이저를 이해할수록 SQL 작성과 인덱스 설계가 함께 좋아진다는 점이다.
- 📢 섹션 요약 비유: RBO는 초보 운전자에게 길의 종류를 가르쳐 주는 오래된 교본과 같다. 기본은 배우게 해 주지만, 실제 도심 주행에서는 교통 상황까지 보는 더 나은 도구가 필요하다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| 실행 계획 (Execution Plan) | SQL이 실제로 어떤 접근 경로를 타는지 보여주는 결과물 |
| 선택도 (Selectivity) | 조건이 얼마나 적은 행을 남기는지 판단하는 핵심 지표 |
| 카디널리티 (Cardinality) | 각 단계에서 예상되는 결과 행 수 |
| 비용 기반 옵티마이저 (CBO, Cost-Based Optimizer) | 현대 데이터베이스의 기본 최적화 방식 |
| 힌트 (Hint) | 옵티마이저 선택을 강제로 유도하는 수단 |
📈 관련 키워드 및 발전 흐름도
규칙 우선 접근
│
▼
RBO (Rule-Based Optimizer)
│
▼
인덱스 우선 규칙 · 고정 실행 계획
│
▼
통계 수집 · 선택도 · 카디널리티
│
▼
CBO (Cost-Based Optimizer) · 현대 SQL 튜닝
이 흐름은 "고정 규칙"에서 "통계 기반 판단"으로 최적화 패러다임이 이동한 과정을 보여준다.
👶 어린이를 위한 3줄 비유 설명
- RBO는 길이 얼마나 막혔는지 안 보고, 큰길이면 무조건 좋다고 생각하는 오래된 내비게이션이에요.
- 그래서 사람이 너무 많아도 좁은 길보다 큰길만 고집해서 오히려 더 늦어질 수 있어요.
- 요즘은 길 상태를 같이 보는 더 똑똑한 내비게이션이 필요하답니다.