정보관리기술사 학습 노트
← 목록으로
데이터베이스
#인메모리DB#Redis#SAP HANA#지속성#HTAP
최종 업데이트 · 2026-10-18

인메모리 데이터베이스(In-Memory Database, IMDB)

1. 개요

가. 정의

인메모리 데이터베이스(In-Memory Database, IMDB 또는 MMDB, Main-Memory Database)는 데이터의 1차 저장소(primary store)를 디스크가 아닌 주기억장치(RAM)에 두고, 질의 처리·연산·버퍼링을 모두 메모리상에서 수행하도록 설계된 데이터베이스 관리 시스템이다. 디스크 기반 DBMS가 "디스크에 있는 데이터를 버퍼 풀로 올려와 처리"하는 것과 달리, IMDB는 데이터가 항상 메모리에 상주한다는 가정하에 자료구조·질의 처리기·회복 기법 전체를 재설계하므로, 단순히 "버퍼를 크게 잡은 디스크 DB"와는 근본적으로 다르다.

여기서 핵심은 디스크의 역할이 "작업 저장소"에서 "지속성(durability)을 위한 백업·로그 저장소"로 강등된다는 점이다. 즉 IMDB에서도 디스크는 사라지지 않는다. 다만 읽기·쓰기의 정상 경로(hot path)에서 디스크 접근이 제거되고, 디스크는 장애 복구를 위한 로그와 스냅샷을 남기는 보조 매체로만 쓰인다.

나. 등장 배경 및 필요성

전통적 디스크 기반 DBMS의 성능 모델은 "디스크 I/O가 가장 비싼 자원"이라는 전제 위에 세워졌다. B-Tree 인덱스([[btree-bplus-index]]), 버퍼 풀, 페이지 기반 저장, 선기록 로그([[write-ahead-logging]])는 모두 느린 디스크 접근을 줄이거나 순차화하기 위한 장치다. 그러나 이 전제는 하드웨어의 변화로 흔들렸다. 2010년대 이후 서버 한 대가 수백 GB~수 TB의 DRAM을 탑재하게 되면서, 상당수의 운영 데이터셋(OLTP 워킹셋)이 통째로 메모리에 들어갈 수 있게 되었다. 데이터가 메모리에 있다면, 디스크 I/O를 전제로 최적화된 구조는 오히려 불필요한 오버헤드가 된다.

실제로 디스크 DB에서 데이터가 이미 버퍼 풀에 캐시된 "메모리 히트" 상황을 측정한 연구(예: VoltDB 진영의 Shore 분석)는, 트랜잭션 수행 시간의 대부분이 버퍼 풀 관리·래치(latch)·로깅·락(lock) 등 디스크를 전제로 한 부가 작업에 소비되고, 정작 실질 연산 비중은 10% 안팎에 불과함을 보였다. 다시 말해 "느린 디스크를 감추기 위해 쌓아 올린 계층"이, 디스크가 병목이 아닌 세상에서는 그대로 비용이 되어버린 것이다.

필요성은 비즈니스 요구에서도 커졌다. 증권 체결·실시간 광고 입찰(RTB)·게임 세션·통신 과금(OCS)·추천 피처 서빙처럼 수십만~수백만 TPS와 밀리초 이하 지연을 요구하는 워크로드가 늘었고, 동시에 "운영 데이터를 즉시 분석"하려는 수요([[htap]])가 커졌다. 디스크 기반 구조로는 이 지연·처리량 목표를 비용 효율적으로 달성하기 어려웠고, 그 결과 메모리를 1차 저장소로 삼는 설계가 주류 선택지로 올라섰다. Redis(캐시 겸 데이터 저장)·SAP HANA(엔터프라이즈 HTAP)·VoltDB(초고속 OLTP)·Apache Ignite·Oracle TimesTen 등이 대표적이다.

또 하나 간과할 수 없는 배경은 지연의 "꼬리(tail latency)"에 대한 요구다. 평균 응답이 빠른 것만으로는 부족하고, 상위 99.9퍼센타일(p99.9)까지 예측 가능하게 짧아야 하는 서비스가 늘었다. 디스크 기반 구조는 버퍼 미스·체크포인트·백그라운드 머지 등으로 인해 간헐적 지연 스파이크가 발생하기 쉽다. IMDB는 정상 경로에서 디스크 접근을 없애 이 꼬리 지연을 구조적으로 억제하므로, "느리지 않음"을 넘어 "일관되게 빠름(결정적 지연)"을 요구하는 금융·통신 영역에서 특히 선호된다. 바로 이 점이 "버퍼 풀을 키운 디스크 DB"로는 대체되지 않는 IMDB의 고유 가치다.

다. 특징

IMDB의 성질은 "메모리가 1차 저장소"라는 단 하나의 설계 결정에서 모두 파생된다. 메모리는 빠르지만 휘발성(volatile)이고 용량 대비 비싸며, 디스크처럼 블록 단위로 순차 접근할 이유가 없다. 따라서 IMDB는 속도를 얻는 대신 지속성·용량·비용이라는 세 가지 과제를 설계로 해결해야 한다.

  • 포인터 기반 직접 접근: 레코드를 메모리 주소로 직접 가리키므로, 디스크 페이지 번역·버퍼 조회 단계가 사라진다.
  • 디스크 I/O 제거(정상 경로): 읽기·쓰기 모두 메모리에서 끝나고, 디스크는 로그·스냅샷 기록에만 관여한다.
  • 휘발성 보완을 위한 지속성 설계: 스냅샷(체크포인트) + 트랜잭션 로그로 재시작 시 상태를 복원한다.
  • 경량 동시성 제어: 디스크 대기가 없으므로 락 보유 시간이 짧아, 단일 스레드 직렬 실행이나 낙관적·[[mvcc-snapshot-concurrency-control|MVCC]] 방식이 유리하다.
  • 메모리 친화 자료구조: B-Tree 대신 T-Tree·해시·스킵리스트, 행 저장 외 컬럼 저장([[columnar-storage]])을 함께 활용한다.
  • 용량·비용 제약: RAM 가격·용량 한계로, 전체 데이터를 담기보다 핫 데이터만 메모리에 두는 하이브리드가 흔하다.

2. 인메모리 데이터베이스의 전체 구조

아래 구조도는 IMDB가 "메모리에서 모든 처리를 끝내되, 지속성만은 디스크로 보장"하는 이중 경로를 보여준다. 정상 질의는 메모리 영역에서 완결되고(파란 경로), 커밋된 변경은 로그·스냅샷을 통해 디스크로 비동기 영속화(점선 경로)된다.

flowchart TB
  APP["애플리케이션/클라이언트"] --> QE["질의 처리기<br/>(컴파일·실행)"]
  QE --> CC["동시성 제어<br/>(직렬·낙관·MVCC)"]
  subgraph MEM["주기억장치(RAM) — 1차 저장소"]
    DATA[("인메모리 데이터<br/>행/컬럼 영역")]
    IDX["인메모리 인덱스<br/>T-Tree·해시·스킵리스트"]
    UNDO["버전/언두 영역"]
  end
  CC --> DATA
  CC --> IDX
  DATA -. "커밋 로그 기록" .-> LOG["트랜잭션 로그<br/>(WAL, append-only)"]
  DATA -. "주기적 체크포인트" .-> SNAP["스냅샷/체크포인트"]
  LOG -. "비동기 flush" .-> DISK[("디스크/SSD<br/>영속 매체")]
  SNAP -. "비동기 flush" .-> DISK
  DISK -. "재시작 시 복원" .-> DATA
  CC -. "동기 복제" .-> REP["복제본(HA)<br/>대기 노드"]

구조의 요점은 세 가지다. 첫째, 데이터·인덱스·버전 정보가 모두 RAM에 상주하므로 질의 처리기는 디스크 페이지를 의식하지 않고 포인터를 따라간다. 둘째, 지속성은 로그와 스냅샷으로 분리되어 정상 처리 성능을 해치지 않는다. 셋째, 단일 노드 메모리의 휘발성·용량 한계를 복제본(HA)과 디스크 영속화로 보완한다. 이 세 축이 IMDB 설계의 골격이다.

3. 핵심 메커니즘 — 지속성·동시성·저장구조

가. 지속성(Durability) 보장 — 로그와 스냅샷

IMDB의 가장 큰 숙제는 "메모리는 전원이 꺼지면 사라진다"는 사실이다. ACID([[transaction-acid]])의 D(지속성)를 메모리 위에서 지키려면, 커밋된 트랜잭션의 효과를 반드시 비휘발성 매체에 남겨야 한다. 표준 해법은 두 가지 수단의 조합이다. 하나는 트랜잭션 로그(WAL, append-only)로, 커밋 시점에 변경 내역(또는 명령)을 디스크에 순차 기록한다. 순차 쓰기는 랜덤 쓰기보다 훨씬 빠르므로 로깅 비용이 상대적으로 작다. 다른 하나는 스냅샷(체크포인트)으로, 메모리 전체 상태를 일정 주기마다 디스크로 떠낸다.

재시작(crash recovery) 시에는 가장 최근 스냅샷을 메모리로 적재한 뒤, 그 이후의 로그만 재생(replay)하여 커밋 상태를 복원한다. 이는 [[write-ahead-logging|ARIES]]의 "로그 선기록 + 체크포인트" 원리를 메모리 환경에 맞춘 것이다. 아래 다이어그램은 이 쓰기·회복 경로를 시계열로 보여준다.

sequenceDiagram
  participant T as 트랜잭션
  participant M as 인메모리 상태
  participant L as 트랜잭션 로그(디스크)
  participant S as 스냅샷(디스크)
  T->>M: 데이터 변경(메모리)
  T->>L: 커밋 로그 append (순차 쓰기)
  L-->>T: fsync 완료 → 커밋 확정
  Note over M,S: 주기적 체크포인트
  M->>S: 스냅샷 기록(비동기)
  Note over M,L: 장애 발생 후 재시작
  S->>M: 최근 스냅샷 적재
  L->>M: 스냅샷 이후 로그 재생(redo)

로그의 "입도(granularity)"에도 선택지가 있다. 디스크 DB의 ARIES는 물리적(또는 physiological) 로그 — 바뀐 바이트·페이지 이미지 — 를 남겨 재생 비용이 예측 가능하다. 반면 VoltDB류는 명령 로그(command logging)를 택해, "실행된 트랜잭션(저장 프로시저)과 입력"만 기록한다. 기록량이 극적으로 작아 로깅 오버헤드가 최소화되지만, 회복 시 스냅샷 이후의 트랜잭션을 다시 실행해야 하므로 재생 시간이 길어질 수 있고, 트랜잭션이 결정적(deterministic)이어야 한다는 제약이 붙는다. 이는 "쓰기 비용을 줄이는 대신 회복 비용을 감수"하는 전형적 설계 선택으로, 워크로드 특성에 따라 갈린다.

지속성 설계에는 트레이드오프가 있다. 커밋마다 로그를 fsync로 즉시 디스크에 내리면(동기 커밋) 완전한 지속성을 얻지만 지연이 늘고, 로그를 모아 지연 flush하면(그룹 커밋·비동기) 처리량은 커지되 마지막 수 밀리초의 커밋을 장애 시 잃을 수 있다. Redis의 AOF everysec(초당 flush)·RDB 스냅샷, VoltDB의 Command Logging이 모두 이 스펙트럼 위의 선택이다. 그래서 IMDB 도입 시에는 "얼마만큼의 데이터 손실을 허용할 것인가([[rpo-rto-disaster-recovery|RPO]])"를 반드시 명시적으로 설계해야 한다. 추가로, 배터리 백업 메모리(NVDIMM)나 뒤에서 다룰 지속성 메모리(SCM)를 쓰면 로그 비용 자체를 크게 줄일 수 있다.

나. 동시성 제어 — 왜 "직렬 실행"이 빨라지는가

디스크 DB의 동시성 제어는 "느린 I/O를 기다리는 동안 다른 트랜잭션을 돌려 CPU를 놀리지 않는다"는 목적이 컸다. 락·래치를 세밀하게 걸어 동시성을 끌어올리는 대신, 그 관리 비용 자체가 상당했다. 그런데 IMDB에서는 트랜잭션이 디스크를 기다리지 않으므로 수행 시간이 마이크로초 단위로 짧다. 이때는 역설적으로 락을 거는 비용 > 그냥 순서대로 빨리 처리하는 비용이 되는 구간이 생긴다.

VoltDB(H-Store 계열)는 이 통찰을 극단화해, 데이터를 파티션으로 나누고 각 파티션을 단일 스레드가 직렬(serial)로 실행한다. 락·래치가 아예 없으므로 오버헤드가 사라지고, 파티션 내 트랜잭션은 결정적으로 빠르게 끝난다. 반면 SAP HANA·Oracle TimesTen·MemSQL(SingleStore)은 MVCC([[mvcc-snapshot-concurrency-control]])를 채택해, 읽기는 스냅샷을 보고 쓰기는 새 버전을 만들어 읽기-쓰기 충돌을 제거한다. 어느 방식이든, 디스크 대기가 사라졌다는 전제가 "무거운 락 관리를 걷어내도 된다"는 결론으로 이어진다는 점이 핵심이다.

다. 메모리 친화 자료구조와 저장 모델

디스크 B-Tree는 "한 번의 I/O로 많은 키를 읽어온다"는 목적에 맞춰 노드를 크게(페이지 크기) 설계한다. 메모리에는 I/O 개념이 없으므로 이 전제가 무의미하다. 대신 캐시 효율(CPU 캐시 라인·TLB)이 성능을 좌우한다. 그래서 IMDB는 포인터 오버헤드가 작은 T-Tree, 균형 유지가 단순한 스킵리스트, 점 조회에 유리한 해시 인덱스를 즐겨 쓴다. 저장 모델도 용도에 따라 갈린다. OLTP 중심이면 행 저장(row store)이, 분석 중심이면 컬럼 저장([[columnar-storage]])이 유리하며, SAP HANA처럼 둘을 한 엔진에 둬 [[htap|HTAP]]를 실현하기도 한다.

구분 디스크 기반 DBMS 인메모리 DBMS(IMDB)
1차 저장소 디스크(버퍼 풀 경유) 주기억장치(RAM)
접근 방식 페이지→버퍼 조회→주소 포인터 직접 접근
주 인덱스 B+Tree(큰 노드) T-Tree·해시·스킵리스트
지속성 디스크가 곧 영속 매체 로그+스냅샷으로 별도 보장
동시성 비용 락·래치 관리 큼 직렬·낙관·MVCC로 경량화
병목 디스크 I/O 메모리 대역폭·용량·CPU 캐시
비용 특성 GB당 저렴 GB당 고가(RAM)

라. 확장성 — 분산 인메모리와 파티셔닝

단일 서버의 메모리 용량(수백 GB~수 TB)을 넘어서는 데이터셋을 다루려면 수평 확장(scale-out)이 필요하다. 이때 IMDB는 데이터를 여러 노드로 나누는 파티셔닝(샤딩)([[db-sharding]])을 적용하는데, 키 범위나 해시로 데이터를 분산하고 각 노드가 자기 파티션을 메모리에 상주시킨다. Redis Cluster는 16,384개의 해시 슬롯으로 키 공간을 나누어 노드에 배정하고, Apache Ignite·Hazelcast는 인메모리 데이터 그리드(IMDG) 형태로 JVM 힙을 가로질러 데이터를 분산·복제한다.

분산 IMDB의 설계 난점은 파티션을 넘나드는 트랜잭션에 있다. 단일 파티션 트랜잭션은 해당 노드가 직렬로 빠르게 끝내지만, 두 파티션에 걸친 트랜잭션은 [[two-phase-commit|2단계 커밋(2PC)]] 같은 분산 합의가 필요해 지연이 급증한다. 그래서 분산 IMDB 설계의 핵심은 "함께 접근하는 데이터를 같은 파티션에 모으는 데이터 지역성(co-location) 설계"다. VoltDB가 파티션 키를 신중히 고르도록 강조하는 이유가 여기에 있다.

  • 해시 파티셔닝: 키를 해시해 균등 분산하되, 범위 질의에는 불리하다.
  • 범위 파티셔닝: 범위 스캔에 유리하나 핫스팟(hot partition)이 생길 수 있다.
  • 복제(replica): 각 파티션을 2~3벌로 복제해 노드 장애 시 가용성과 읽기 확장을 확보한다.
  • 리밸런싱: 노드 증설·축소 시 슬롯/파티션을 재분배하며, [[consistent-hashing|일관된 해싱]]으로 이동량을 최소화한다.

4. 디스크 기반 DB와의 비교 및 활용 사례

표만으로는 "왜" 이런 차이가 나는지 설명되지 않으므로 맥락을 덧붙인다. 디스크 DB와 IMDB의 성능 격차는 단순히 "RAM이 디스크보다 빠르다"에 그치지 않는다. 병목의 위치 자체가 이동하기 때문이다. 디스크 DB에서 병목은 I/O였지만, IMDB에서는 메모리 대역폭과 CPU 캐시 지역성, 그리고 로깅의 동기화 지점으로 옮겨간다. 따라서 IMDB 튜닝은 "인덱스를 어떻게 걸까"보다 "데이터를 어떻게 파티션해 코어별로 캐시 친화적으로 배치할까", "로그 flush를 어떻게 묶을까"에 집중된다.

실제 수치로 보면 격차는 더 구체화된다. 동일 하드웨어에서 데이터가 모두 메모리에 상주하는 조건일 때, IMDB의 단순 키 조회는 보통 수수십 마이크로초 수준으로, 네트워크 왕복을 포함해도 1밀리초 이내에 응답하는 반면, 디스크 DB는 버퍼 미스가 한 번이라도 나면 SSD 기준 수백 마이크로초수 밀리초, HDD 기준 수 밀리초~수십 밀리초로 급증한다. 단건 지연의 차이는 작아 보여도, 초당 수십만 건을 처리할 때는 누적 처리량과 꼬리 지연에서 수십 배 차이로 벌어진다. 이 때문에 IMDB의 경제성은 "서버 대수 절감"으로도 환산된다 — 같은 TPS를 디스크 DB 열 대로 감당할 것을 IMDB 한두 대로 처리하면, RAM 단가가 비싸도 총소유비용(TCO)에서 역전되는 구간이 생긴다.

활용 사례는 지연·처리량 요구가 극단적인 영역에 집중된다.

  • 실시간 세션·캐시·피처 서빙: Redis는 밀리초 이하 응답으로 세션 스토어·리더보드·[[caching-strategy|분산 캐시]]·AI 피처 스토어([[feature-store]])에 광범위하게 쓰인다. 예컨대 대규모 커머스의 장바구니·재고 카운터는 초당 수십만 건의 갱신을 견뎌야 하는데, 디스크 DB로는 비용이 폭증한다.
  • 초고속 OLTP: 통신사 실시간 과금(OCS)은 통화 1건마다 잔액을 차감·검증해야 하며, VoltDB류는 파티션별 직렬 실행으로 수십만 TPS를 결정적 지연으로 처리한다.
  • 운영·분석 통합(HTAP): SAP HANA는 ERP 운영 데이터를 메모리 컬럼 저장으로 두어, 별도 ETL 없이 실시간 경영 분석을 제공하며 — 과거 야간 배치로 만들던 리포트를 초 단위로 끌어내린다.
  • 시계열·텔레메트리: 최근 구간을 메모리에, 과거를 디스크에 두는 계층화는 [[time-series-database|시계열 DB]]의 표준 패턴이 되었다.
  • 실시간 분석·스트림 상태 저장: 스트림 처리([[stream-processing-windowing]]) 엔진의 윈도 집계 상태, 실시간 리스크 계산의 중간 결과처럼 "짧게 살지만 매우 빈번히 갱신되는 상태"를 두기에 적합하다.

이들 사례의 공통점은 "데이터가 작지 않아도 워킹셋(실제로 자주 접근하는 부분)이 메모리에 들어온다"는 조건이 성립한다는 데 있다. 반대로 워킹셋이 메모리를 크게 초과하거나, 대용량 콜드 데이터를 순차 스캔하는 분석이 주라면 IMDB의 이점은 희석되고 비용만 커진다. 사례 선정의 본질은 기술의 화려함이 아니라 "이 워크로드에서 I/O가 정말 병목인가"라는 질문에 대한 정량적 답이다.

5. 심화 — 최신 동향과 하드웨어 변화

IMDB는 "하드웨어 전제의 변화가 소프트웨어 구조를 바꾼다"는 명제를 가장 선명하게 보여주는 분야다. 따라서 최신 동향 역시 메모리·인터커넥트 하드웨어의 발전과 떼어놓고 볼 수 없다.

IMDB의 미래는 메모리 계층의 진화와 맞물린다. 첫째, 지속성 메모리(Persistent Memory)·스토리지 클래스 메모리(SCM)의 등장이다([[emerging-nvm-scm]]). Intel Optane PMem으로 대표되던 이 계층은 "DRAM급 지연 + 전원이 꺼져도 유지"라는 성질로, IMDB의 가장 큰 약점인 휘발성과 로깅 비용을 동시에 완화한다. 데이터를 지속성 메모리에 직접 두면 스냅샷·로그 부담이 줄고 재시작도 빨라진다. 다만 Optane 단종(2022) 이후에는 CXL(Compute Express Link) 기반 메모리 확장·풀링([[cxl-compute-express-link]])이 그 자리를 이어, 노드 경계를 넘어 테라바이트급 메모리를 유연하게 붙이는 방향으로 전개되고 있다.

둘째, 클라우드 매니지드·서버리스화다. Amazon ElastiCache·MemoryDB(Redis 호환이면서 로그 복제로 지속성 강화), Azure Cache, Redis Enterprise 등은 IMDB를 "관리형 서비스"로 제공하며, 용량·복제·백업을 운영자가 직접 다루지 않게 한다. 특히 MemoryDB는 "인메모리의 속도 + 다중 AZ 로그 기반 내구성"을 결합해, 캐시를 넘어 1차 데이터베이스로 쓸 수 있는 IMDB라는 포지션을 제시했다.

셋째, HTAP·트랜스라이티컬(translytical)의 확산이다. 운영과 분석의 경계가 흐려지면서, 하나의 인메모리 엔진에서 OLTP와 OLAP를 함께 처리하는 아키텍처([[htap]])가 금융·리테일을 중심으로 확산 중이다. 예상 출제 방향으로는 ① IMDB의 지속성 보장 메커니즘(로그+스냅샷)과 RPO 설계, ② 디스크 DB 대비 동시성 제어 차이(직렬 vs MVCC)의 근거, ③ SCM/CXL이 IMDB 아키텍처에 주는 변화, ④ Redis를 "캐시"가 아닌 "1차 저장소"로 승격할 때의 고려사항이 유력하다. 답안은 "하드웨어 전제의 변화 → 소프트웨어 구조의 재설계"라는 인과를 축으로 구성하면 설득력이 높다.

6. 고려사항 및 시사점

  • 지속성·가용성 설계가 본질이다(트레이드오프): IMDB 도입의 성패는 속도가 아니라 "메모리가 날아갔을 때 무엇을 잃는가"에 달렸다. 동기/비동기 커밋, 스냅샷 주기, 복제본 수를 RPO·RTO 목표([[rpo-rto-disaster-recovery]])에 맞춰 명시적으로 결정하고, 단일 노드 메모리에 모든 것을 의존하지 않도록 복제([[database-replication-high-availability]])를 전제해야 한다.
  • 전면 전환보다 하이브리드·핫데이터 전략: RAM은 GB당 비싸고 용량이 한정적이므로, 전체 데이터를 메모리에 올리는 설계는 대개 비경제적이다. 핫 데이터는 메모리, 콜드 데이터는 디스크/오브젝트 스토리지로 계층화하고, 캐시-어사이드·라이트-스루 같은 [[caching-strategy|캐시 전략]]으로 일관성을 관리하는 편이 현실적이다.
  • 워크로드 적합성 판별이 우선: 디스크 DB도 버퍼 풀이 충분하면 상당히 빠르다. IMDB는 극단적 지연·처리량 요구, 예측 가능한 결정적 지연, HTAP 같은 특성이 뚜렷할 때 진가를 발휘한다. "무조건 빠르니 좋다"가 아니라, I/O가 실제 병목인지, 워킹셋이 메모리에 들어오는지를 먼저 정량 검증해야 한다.
  • 운영·관측·보안 관점: 메모리 상주 데이터는 재시작마다 웜업(warm-up)이 필요하고, 덤프·스왑으로 민감정보가 디스크에 노출될 위험이 있으므로 암호화·스왑 비활성화·접근통제가 필요하다. 또한 메모리 사용률·단편화·복제 지연을 상시 관측([[observability]])해, OOM으로 인한 전면 장애를 예방해야 한다.
  • 하드웨어 로드맵과의 정렬: SCM 단종과 CXL 부상처럼 메모리 계층은 빠르게 변한다. 특정 하드웨어(예: Optane)에 강하게 결합된 설계는 수명 위험이 있으므로, 추상화된 지속성 계층을 두어 하드웨어 교체에 유연하도록 설계하는 것이 기술사 관점의 전략적 판단이다.

참고자료

한 줄 요약: 인메모리 데이터베이스는 데이터의 1차 저장소를 RAM으로 옮겨 디스크 I/O를 정상 경로에서 제거하고, 자료구조·동시성 제어·회복 기법을 메모리 전제로 재설계한 DBMS로, 속도를 얻는 대신 로그·스냅샷·복제로 휘발성을 보완하며 지속성(RPO)과 비용·용량의 트레이드오프를 설계하는 것이 핵심이다.