회의에서 이런 질문을 받았다고 해보자.

“SCAN 지원하나요?”

Oracle을 조금 아는 사람은 RAC의 접속 주소를 떠올린다. Exadata를 공부하던 사람은 Storage Cell의 Smart Scan을 떠올릴 수 있다. 이름은 닮았지만 둘은 하는 일이 완전히 다르다.

한쪽은 데이터베이스로 들어가는 입구이고, 다른 한쪽은 데이터가 있는 곳에서 미리 걸러주는 처리 방식이다.

형제는커녕 같은 부서도 아니다.

이 차이를 이해하면 Exadata, RAC, ASM, SCAN, Smart Scan처럼 한꺼번에 쏟아지는 용어가 의외로 쉽게 정리된다. 더 중요한 것도 보인다.

“연결됐다”와 “운영 가능한 조합으로 검증됐다”는 같은 말이 아니다.

오늘은 이 두 문장을 중심으로 Exadata의 큰 그림을 풀어보려 한다.

Exadata는 새로운 데이터베이스가 아니다

먼저 가장 흔한 오해부터 풀자.

Exadata는 Oracle Database를 대체하는 새로운 종류의 데이터베이스가 아니다. 사용자는 여전히 Oracle SQL을 실행하고, table과 index를 만들고, transaction을 처리한다.

특별한 점은 그 아래와 주변이다.

Oracle은 Database Server, 지능형 Storage Server, 빠른 내부 network를 하나의 시스템처럼 함께 설계했다. 서버와 스토리지를 따로 사서 조립한 뒤 “이제부터 한 팀이야”라고 선언한 것이 아니라, 처음부터 서로 잘 협력하도록 만든 구성에 가깝다.

큰 도서관으로 비유해보자.

  • Database Server는 이용자의 질문을 이해하고 검색 전략을 세우는 사서다.
  • Storage Cell은 지하 서고에서 조건에 맞는 자료를 먼저 추려주는 서고 담당자다.
  • RDMA Network Fabric은 열람실과 지하 서고를 잇는 초고속 책 운반 통로다.
  • ASM은 책을 어느 서가에 나눠 놓고 어떻게 복제할지 관리하는 배치 담당자다.
  • RAC은 여러 안내 데스크가 같은 도서관 서비스를 함께 처리하는 구조다.
  • SCAN은 어느 안내 데스크가 열려 있는지 이용자가 외우지 않아도 되는 대표 안내 번호다.

이제 등장인물은 모였다. 문제는 이름이 비슷한 두 SCAN이다.

Smart Scan: 서고에서 먼저 골라 보내기

주문 데이터가 10억 건 있고, 우리가 필요한 것은 이번 달의 고액 주문 1만 건뿐이라고 해보자.

SELECT customer_id, order_total
FROM orders
WHERE order_date >= DATE '2026-07-01'
  AND order_total >= 1000000;

일반적인 block 중심 읽기에서는 관련 data block을 Database Server로 많이 보낸 뒤, Database Server가 필요한 row와 column을 골라낼 수 있다.

Smart Scan이 가능한 상황에서는 일부 일이 달라진다.

Storage Cell이 filter 조건과 필요한 column을 이해하고, 저장장치 가까이에서 먼저 데이터를 추린다. 조건에 맞지 않는 데이터까지 모두 위로 올려 보내지 않아도 된다.

일반적인 흐름
Storage → 많은 block → Database Server가 필터링

Smart Scan 흐름
Storage Cell이 일부 필터링 → 줄어든 결과 → Database Server가 최종 처리

도서관으로 돌아가면 이렇다.

“2026년 7월 이후, 100만 원 이상 주문 자료를 주세요”라는 요청을 받았을 때 지하 서고의 모든 상자를 열람실로 보내는 대신, 서고 담당자가 조건에 맞는 자료부터 추려 보내는 것이다.

이 과정은 전송량과 Database Server의 처리 부담을 줄일 수 있다.

하지만 여기서 광고 문구처럼 들리기 쉬운 함정이 하나 있다.

Smart Scan은 모든 SQL을 빠르게 만드는 터보 버튼이 아니다.

실제 적용과 효과는 실행 계획, scan 방식, 연산의 offload 가능 여부, 저장 방식, index 사용 여부, 현재 부하에 따라 달라진다. 적절한 index로 주문 한 건을 찾는 짧은 조회라면 대규모 scan을 줄이는 Smart Scan보다 index access와 cache가 더 중요할 수 있다.

그래서 성능 PoC에서 “쿼리가 빨라졌다”만 보면 부족하다. 실제로 offload가 일어났는지, Storage와 Database Server 사이의 데이터 이동이 얼마나 줄었는지 실행 통계로 확인해야 한다.

SCAN: RAC의 대표 출입구

이번에는 Smart가 없는 SCAN이다.

SCAN은 Single Client Access Name의 약자다. Oracle RAC에서 client가 여러 node의 주소를 일일이 외우지 않고 cluster에 접근하도록 돕는 대표 진입점이다.

쉽게 말하면 여러 안내 데스크의 직통번호를 공개하는 대신 대표번호 하나를 알려주는 것이다.

그러나 대표번호가 있다고 해서 모든 장애 대응이 자동으로 해결되는 것은 아니다.

  • DNS가 어떤 IP들을 반환하는가?
  • 각 IP에 network로 접근할 수 있는가?
  • listener에 service가 제대로 등록됐는가?
  • 새 연결은 다른 node로 재시도되는가?
  • 이미 실행 중인 session과 transaction은 어떻게 되는가?
  • client driver는 failover를 어떻게 처리하는가?

이 질문들은 따로 확인해야 한다.

SCAN을 한 줄로 “RAC load balancer”라고 설명하면 편하지만, 그 한 줄이 client와 listener, service 설정의 책임까지 모두 설명해주지는 않는다.

이름만 닮은 두 SCAN

표로 놓으면 차이가 더 선명하다.

용어 어디에서 일하는가 무슨 문제를 푸는가
SCAN client와 RAC 접속 경로 여러 RAC 진입점을 대표 이름으로 단순화
Smart Scan Exadata Storage Cell의 데이터 처리 경로 저장장치 가까이에서 일부 scan과 filter를 처리

기억법은 간단하다.

SCAN은 어디로 들어갈지 돕고, Smart Scan은 무엇을 올려 보낼지 줄인다.

여기에 RAC와 ASM까지 붙이면 이렇게 정리할 수 있다.

용어 담당하는 문제
RAC 여러 Oracle instance의 처리 확장과 가용성
ASM database file의 배치·분산·복제
SCAN RAC client의 대표 접속 진입점
Smart Scan Storage Cell의 SQL 처리 offload

같이 등장할 뿐, 서로 대신할 수 있는 기능은 아니다.

“Oracle 연결 성공”이 운영 지원을 뜻하지 않는 이유

여기서 실무 이야기가 시작된다.

어떤 DB client에서 Oracle 연결에 성공했다고 해보자. 그러면 다른 client와 application도 모두 괜찮을까?

그렇지 않다.

Oracle 연결의 실제 동작은 하나의 제품 이름보다 조합에 가깝다.

DB version과 patch
× single instance 또는 RAC
× SID 또는 Service Name
× node, VIP 또는 SCAN
× TCP, native encryption 또는 TCPS
× client와 driver version
× direct 연결 또는 중간 proxy

이 중 하나가 바뀌면 packet 형식, connection descriptor, 인증, timezone, failover, session 처리 방식이 달라질 수 있다.

A client에서 연결된다는 사실은 A 조합의 성공을 보여준다. B client의 성공까지 대신 증명하지 않는다.

그래서 “Oracle 지원”이라는 넓은 문장보다 다음과 같은 문장이 훨씬 정확하다.

이 DB version과 endpoint, protocol, client·driver, account mode, 접속 경로의 조합에서 연결과 업무 시나리오를 검증했다.

길어 보이지만 운영에서는 이 문장이 사람을 살린다.

PoC는 정상 연결부터 장애 장면까지 계단식으로

복잡한 Oracle 환경을 처음부터 SCAN, failover, 대량 DML까지 한꺼번에 시험하면 실패 원인을 찾기 어렵다.

좋은 PoC는 계단을 오른다.

1단계: 가장 단순한 기준선

먼저 단일 node 또는 VIP와 명확한 SID/Service Name으로 연결한다.

  • 로그인되는가?
  • 간단한 SELECT가 실행되는가?
  • 한글과 날짜·시간이 정상인가?
  • session timezone이 기대와 같은가?

이 기준선이 있어야 복잡한 경로에서 실패했을 때 차이를 비교할 수 있다.

2단계: 실제 client 조합

운영에서 사용할 client와 driver version을 그대로 시험한다.

  • GUI client
  • JDBC나 ODP.NET application
  • Web SQL editor
  • 중간 proxy 경유 경로

“비슷한 client”는 “같은 client”가 아니다.

3단계: 통제와 감사

접속만 보지 않는다.

  • 허용·차단 정책이 의도대로 동작하는가?
  • 민감정보 masking이 실제 SQL 형태에서도 유지되는가?
  • 개인 계정과 공용 DB 계정의 실행자가 구분되는가?
  • SQL 실행과 승인·감사 기록이 연결되는가?

보안 제품 앞단에서는 성능만큼 기록의 정확성도 중요하다.

4단계: 실제 크기의 부하

짧은 조회, 장시간 query, 대량 결과, batch DML을 분리한다.

이때 client 응답 시간만 보지 말고 DB session, wait event, open cursor, proxy 자원, network 방향을 함께 본다.

5단계: 장애 장면

마지막에 node와 network 장애를 넣는다.

  • 새 연결은 어디로 가는가?
  • 기존 session은 어떻게 되는가?
  • transaction은 commit됐는가, rollback됐는가?
  • 장애 전후 감사 기록은 빠지거나 중복되지 않는가?

“HA 됩니다”라는 형용사보다 “node 하나를 중단했을 때 신규 연결이 어떻게 움직였다”는 동사가 더 믿을 만하다.

지원 문서는 이력이 아니라 경계선이어야 한다

복잡한 기술을 다루다 보면 문서가 과거 장애 목록으로 변하기 쉽다.

하지만 독자가 정말 알고 싶은 것은 세 가지다.

  1. 지금 일반적으로 기대할 수 있는 것은 무엇인가?
  2. 어떤 조합은 실제 환경에서 따로 검증해야 하는가?
  3. 무엇은 현재 보장한다고 말하면 안 되는가?

그래서 좋은 지원 문서는 사례를 그대로 쌓지 않는다. 사례에서 반복되는 판단 기준을 꺼내 제품 도메인의 정본으로 올린다.

고객별 증상은 case record에 남기고, 재사용 가능한 연결 matrix와 PoC 절차는 제품 문서에 둔다. 그래야 다음 사람이 오래된 티켓 하나를 읽고 현재 지원 범위를 과장하지 않는다.

이 구조는 Oracle에만 해당하지 않는다. Kubernetes, Redis Cluster, TLS, browser 호환성처럼 “지원”이 여러 구성요소의 조합으로 결정되는 모든 기술에 적용된다.

마지막으로 기억할 다섯 문장

  • Exadata는 새로운 DB가 아니라 Oracle Database와 server·storage·network를 함께 최적화한 시스템이다.
  • SCAN은 RAC의 접속 진입점이고 Smart Scan은 Storage Cell의 처리 offload다.
  • RAC, ASM, SCAN은 함께 등장하지만 서로 다른 문제를 푼다.
  • 한 client의 연결 성공은 다른 client·driver·protocol 조합을 보장하지 않는다.
  • PoC는 단순 연결에서 시작해 실제 client, 통제·감사, 부하, 장애 순으로 올라가야 한다.

다음 회의에서 누군가 “SCAN 지원하나요?”라고 묻는다면 바로 답하기 전에 한 번 되물어보자.

“접속을 위한 SCAN인가요, 데이터를 거르는 Smart Scan인가요?”

그 질문 하나만으로도 회의의 절반은 이미 성공한 셈이다.