델타 인코딩 (Delta Encoding) 및 고릴라(Gorilla) 압축 알고리즘

핵심 인사이트 (3줄 요약)

본질: 델타 인코딩 (Delta Encoding)은 시계열 데이터(Time-Series Data)처럼 시간의 흐름에 따라 연속적으로 발생하는 데이터 쌍을 저장할 때, 원본 수치 전체를 저장하지 않고 직전 값과의 '차이(Delta)'만을 기록하여 스토리지 비트(Bit) 수를 극단적으로 줄이는 무손실 압축 기법이다.

가치: 데이터가 1초 단위로 쏟아지는 IoT 센서나 서버 메트릭 모니터링 환경에서, 디스크 용량을 90% 이상 절감할 뿐만 아니라 더 많은 데이터를 메인 메모리(RAM)에 캐싱(In-Memory)할 수 있게 만들어 쿼리(조회) 속도를 수십 배 이상 폭발적으로 끌어올린다.

융합: 이 기본 개념은 2015년 메타(Facebook)가 발표한 Gorilla 알고리즘 논문을 통해 '타임스탬프 이중 델타(Delta-of-Delta)'와 '부동소수점 XOR 압축'이라는 기술로 승화되었으며, 현재 Prometheus, InfluxDB 등 모든 현대적 시계열 데이터베이스(TSDB)의 사실상 표준 압축 엔진으로 융합되어 사용되고 있다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 델타 인코딩은 데이터 스트림 [100, 101, 102, 101, 100]을 저장할 때, 첫 번째 기준점 100만 온전히 저장하고 이후부터는 [+1, +1, -1, -1] 이라는 상대적인 변화량(Delta)만을 저장하는 데이터 직렬화(Serialization) 최적화 기법이다.
필요성: 클라우드 인프라가 거대해짐에 따라 서버의 CPU 사용량, 메모리 점유율 등을 1초 단위로 수집하는 모니터링 시스템의 부하가 통제 불능 상태에 빠졌다. 10만 대의 서버에서 100개의 메트릭을 1초마다 수집하면 초당 1,000만 건의 데이터가 발생한다. 64비트(8바이트) 정수형으로 타임스탬프와 측정값을 각각 저장하면 1시간 만에 테라바이트(TB) 단위의 디스크가 꽉 차버리며, 이를 조회하기 위해 발생하는 디스크 I/O 병목으로 인해 "모니터링 대시보드를 띄우는 데 5분이 걸리는" 주객전도의 상황이 벌어졌다. 이를 해결하기 위해 데이터를 디스크로 내리기 전 메모리 상에서 극한으로 쥐어짜 압축(Compression)하는 전용 알고리즘의 필요성이 대두되었다.
등장 배경 및 기술적 해결: 기존의 ZIP이나 GZIP 같은 범용 압축 알고리즘은 텍스트 문서 블록 전체를 스캔하여 중복 패턴을 찾는 사전(Dictionary) 방식이므로, 실시간으로 1개씩 들어오는 스트리밍 숫자를 압축하는 데는 CPU 오버헤드가 너무 커서 부적합했다. 페이스북 엔지니어들은 서버 메트릭 데이터가 "시간 간격이 일정하며(예: 정확히 60초 간격)", "측정값의 변화폭이 매우 좁다(예: CPU 온도가 1초 만에 40도에서 100도로 뛰지 않음)"는 도메인 특성을 간파했다. 이를 바탕으로 가벼운 비트(Bit) 연산만으로 원본의 1/10 수준까지 용량을 깎아내는 Gorilla 알고리즘을 세상에 내놓게 되었다.

이 다이어그램은 델타 인코딩이 어떻게 메모리 비트 낭비를 제거하는지를 직관적으로 보여준다.

  ┌───────────────────────────────────────────────────────────────┐
  │         일반 저장 방식 vs 델타 인코딩(Delta Encoding) 압축 비교      │
  ├───────────────────────────────────────────────────────────────┤
  │                                                               │
  │  [A. 일반적인 32비트(4Byte) 정수 저장 방식]                      │
  │   원본 데이터: 1000, 1001, 1002                                 │
  │   (메모리 표현: 무조건 32칸의 비트 공간을 할당해야 함)                  │
  │   값1 (1000): 00000000 00000000 00000011 11101000 (32비트)      │
  │   값2 (1001): 00000000 00000000 00000011 11101001 (32비트)      │
  │   값3 (1002): 00000000 00000000 00000011 11101010 (32비트)      │
  │   ▶ 총 사용량: 96 비트 (비효율의 극치)                             │
  │                                                               │
  │  [B. 델타 인코딩 적용 방식]                                       │
  │   저장 데이터: 기준점(1000) 과 변화량(+1, +1)                        │
  │   값1 (기준): 00000000 00000000 00000011 11101000 (32비트)      │
  │   값2 (+1) : 1 (단 1비트만 사용!)                                │
  │   값3 (+1) : 1 (단 1비트만 사용!)                                │
  │   ▶ 총 사용량: 34 비트 (약 65% 압축 달성)                          │
  │                                                               │
  │  ★ 핵심: 앞부분의 0으로 꽉 찬 중복 공간(Prefix)을 통째로 날려버림!      │
  └───────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 도식은 데이터 타입(Data Type) 고정 할당의 낭비를 고발한다. 개발자가 DB 스키마에 INT 타입을 선언하면, 그 안에 숫자 1이 들어가든 21억이 들어가든 무조건 물리적으로 32개의 0과 1의 방(Bit)이 예약된다. 값이 조금씩만 변할 때, 앞쪽의 수십 개 비트(0000...)는 전혀 변하지 않음에도 매번 중복 저장되는 치명적인 오버헤드가 발생한다. 델타 인코딩은 첫 번째 값만 원본 32비트로 저장한 뒤, 다음 값부터는 차이(Delta)만 계산한다. 1이라는 차이 값은 2진수로 표현하면 단 1비트(1)면 족하다. 알고리즘은 가변 길이 인코딩(Variable-length Encoding) 규칙을 달아 "다음 데이터는 1비트 길이입니다"라는 마커만 붙여 저장함으로써, 시계열 데이터의 뚱뚱한 허리둘레를 기적처럼 잘라낸다.

📢 섹션 요약 비유: 마라톤 중계를 할 때 매 1km 구간마다 "현재 위치는 서울시 광화문 기준 동경 몇 도, 북위 몇 도입니다"라고 전체 GPS 좌표를 부르는 대신, 처음에만 전체 좌표를 부르고 그다음부터는 "방금 전보다 북쪽으로 100미터 왔습니다"라고 차이만 무전으로 알리는 것이 통신비를 아끼는 완벽한 방법과 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

시계열 압축의 끝판왕: Gorilla 알고리즘 심층 해부

페이스북이 고안한 Gorilla 알고리즘은 시계열 데이터를 1. **타임스탬프(시간)**와 2. 부동소수점(측정값) 두 가지 트랙으로 완벽히 분리하여 각각 최적의 압축을 가한다.

1. 타임스탬프 압축: Delta-of-Delta (이중 델타) 기법

서버 메트릭은 대개 스케줄러(Cron)에 의해 정확히 60초 간격으로 수집된다.

1차 델타: $T_2 - T_1$을 계산한다. (예: 60초, 60초, 61초, 60초...)
1차 델타만 해도 숫자가 작아지지만, Gorilla는 한 발 더 나아간다.
2차 델타 (Delta-of-Delta): 방금 구한 1차 델타들 간의 차이를 한 번 더 뺀다.
$D_2 - D_1 = 60 - 60 = 0$
$D_3 - D_2 = 61 - 60 = 1$
결과적으로 무거운 타임스탬프 덩어리들이 0, 0, 1, 0, 0 이라는 극단적으로 작은 숫자로 환골탈태한다. 만약 정해진 60초 주기로 완벽히 들어왔다면, 2차 델타값은 무조건 0이 되므로 1비트(0) 하나만으로 시간값을 저장하는 경지에 오른다.

2. 값(Value) 압축: 부동소수점 XOR (배타적 논리합) 기법

온도나 주가처럼 소수점을 포함하는 Double (64비트) 형은 단순 뺄셈(Delta) 연산을 하면 오히려 비트 구조가 복잡해져 압축이 잘 안 된다.

Gorilla는 이전 값과 현재 값을 뺄셈하는 대신 XOR 연산을 수행한다.
64비트 중 앞부분 수십 비트와 뒷부분 수십 비트가 똑같다면, XOR 결과는 양 끝이 모두 0으로 채워지고 가운데 변한 부분만 1이 섞인 형태(000...001101...000)가 된다.
앞쪽의 연속된 0의 개수(Leading Zeros)와, 유의미한 중간 비트의 길이만 메타데이터로 묶어 저장함으로써 64비트짜리 소수점을 평균 1~2바이트 수준으로 난도질해 버린다.

  ┌──────────────────────────────────────────────────────────────────┐
  │        Gorilla 타임스탬프 Delta-of-Delta (이중 델타) 알고리즘 트리      │
  ├──────────────────────────────────────────────────────────────────┤
  │                                                                  │
  │  [ 시간(초) 스트림 인입 ]                                            │
  │    T1: 1680000000 (기준점 - 온전한 64비트 저장)                         │
  │    T2: 1680000060 (정상 수집)                                        │
  │    T3: 1680000120 (정상 수집)                                        │
  │    T4: 1680000182 (네트워크 지연으로 2초 늦게 수집됨 💥)                  │
  │                                                                  │
  │  [ 1단계: 1차 델타 연산 (D = T_n - T_{n-1}) ]                       │
  │    D1 (T2-T1) = 60                                               │
  │    D2 (T3-T2) = 60                                               │
  │    D3 (T4-T3) = 62                                               │
  │                                                                  │
  │  [ 2단계: 2차 델타 연산 (DoD = D_n - D_{n-1}) ]                     │
  │    DoD1 (D2-D1) = 0   ──▶ 💡 완벽히 일치! 마커 비트 '0' (단 1비트로 저장) │
  │    DoD2 (D3-D2) = +2  ──▶ 💡 약간의 지연! 마커 '10' + 값 '2' (총 9비트) │
  │                                                                  │
  │  ★ 파급 효과: 1시간(60건)의 타임스탬프를 저장하는 데 480바이트가 필요했지만,│
  │             이중 델타를 쓰면 약 10바이트 수준으로 압축됨 (98% 압축률).     │
  └──────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 구조는 시간이라는 제약 조건을 역이용하는 기술사적 통찰이다. 2차 델타(Delta-of-Delta) 값이 0이라는 것은 "수집 주기가 한 치의 오차도 없이 직전 주기와 똑같이 떨어졌다"는 의미다. 분산 시스템에서 대부분의 스케줄러는 꽤 정확하게 작동하므로, 저장되는 시간값의 90% 이상은 이 1비트짜리 0으로 치환된다. 만약 GC(가비지 컬렉션) 퍼즈(Pause) 등으로 1~2초 늦게 수집되더라도 2차 델타값은 기껏해야 +2나 -1 수준이다. Gorilla 알고리즘 논문은 이 2차 델타값이 속하는 범위(Range)에 따라 가변 비트 헤더(0, 10, 110, 1110)를 씌워 인코딩하는 규칙표를 만들어, CPU 연산 부하를 제로에 가깝게 유지하면서 극강의 압축률을 달성했다.

📢 섹션 요약 비유: 수학교실에서 선생님이 "구구단 2단 외워봐" 했을 때, 학생이 "2, 4, 6, 8, 10"이라고 말하는 대신, 델타 인코딩은 "2, 그리고 계속 +2"라고 한마디로 압축해서 칠판에 적어야 할 글씨를 없애버리는 원리입니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

시계열 압축 알고리즘 간 비교 매트릭스

데이터베이스 압축은 목적(저장용 vs 통신용)과 데이터 타입에 따라 철저히 분업화되어야 한다.

비교 항목	Gorilla 알고리즘 (TSDB 표준)	LZ4 / Snappy (일반 RDBMS/Hadoop)	Dictionary (Zlib, GZIP)
압축 대상	Float(소수점) 및 Integer(시간)	문자열, 범용 바이너리 블록	반복되는 긴 텍스트 (로그 파일)
압축 방식	앞뒤 값의 차이(XOR, Delta) 연산	블록 내 반복 패턴 포인터 치환	전체 문서를 스캔하여 사전(Dictionary) 매핑
압축/해제 속도	극도로 빠름 (초당 수천만 건)	매우 빠름 (실시간 인메모리 타겟)	느림 (CPU 사용량 극심)
압축 단위	실시간 스트리밍 점 단위 (Point)	청크/블록 단위 (Block)	파일 전체 단위 (File)
압축률	시계열 데이터 한정 최상 (10배 이상)	중간 (2~3배)	텍스트 한정 높음

이 매트릭스에서 알 수 있듯, 일반적인 관계형 DB나 데이터 웨어하우스에서 쓰는 LZ4 압축을 시계열 데이터에 적용하는 것은 넌센스다. 숫자 100과 101은 인간의 눈에는 비슷해 보이지만, 컴퓨터의 바이너리 바이트(Byte) 배열상으로는 전혀 반복 패턴이 없어 범용 압축기(LZ4)는 이를 압축하지 못하고 그냥 통과시켜 버리기 때문이다. 오직 숫자의 '차이'라는 의미론적(Semantic) 접근을 하는 델타/XOR 인코딩만이 시계열 스트림의 허를 찌를 수 있다.

In-Memory 아키텍처와의 폭발적 시너지

메모리(RAM)는 디스크보다 수백 배 빠르지만 GB당 가격이 비싸다. Gorilla 알고리즘을 도입하면, 과거에는 디스크에 내려야 했던 최근 24시간 치 서버 메트릭 데이터(수십 GB)를 압축하여 메모리(수 GB)에 전부 올려놓고 쿼리를 서빙(In-Memory Analytics)할 수 있게 된다. 이는 그라파나(Grafana) 대시보드의 차트 로딩 속도를 분(Minute) 단위에서 밀리초(ms) 단위로 바꾸는 마법을 부린다.

📢 섹션 요약 비유: 이불을 압축팩에 넣을 때 청소기로 공기를 빼는 범용 압축(LZ4)도 좋지만, 델타 인코딩은 아예 이불의 부피를 차지하는 '솜' 자체를 빼버리고 '껍데기'만 남겨 옷장에 10배로 구겨 넣는 마술과 같습니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무 시나리오 및 설계 안티패턴

시나리오 — 센서 데이터 전송 시 대역폭(Bandwidth) 고갈: 사막 한가운데 설치된 태양광 패널의 온도 센서가 위성 통신(초당 과금)을 통해 본사로 데이터를 쏘는데, 1초 단위 생데이터(Raw Data)를 쏘다 보니 통신비가 적자를 내고 있다.
- 의사결정: 엣지 디바이스(센서) 단에서부터 소프트웨어적으로 델타 인코딩 (Delta Encoding) 로직을 구현하여 패킷을 조립한다. 센서는 최초 부팅 시에만 원본 온도(예: 35.1도)를 쏘고, 이후부터는 버퍼에 모아둔 델타값(+0.1, -0.2, 0...) 비트 배열만을 모아서 MQTT나 CoAP 프로토콜로 묶어 쏜다. 이를 통해 위성 통신 페이로드 크기를 90% 삭감하여 인프라 비용을 사수하는 기술적 결단을 내린다.
안티패턴 — 랜덤 액세스(Random Access)가 필요한 도메인에 델타 압축 남용: 주식 거래 시스템에서 과거 10년 치 특정 일자의 주가를 무작위로 뽑아봐야 하는 테이블(OLTP)에 Gorilla 압축 엔진(TSDB)을 메인으로 도입하는 행위.
- 결과: 델타 인코딩의 치명적 단점은 "오늘 값을 알려면 어제 값을 알아야 하고, 어제 값을 알려면 그제 값을 알아야 한다"는 연쇄 의존성(Chain Dependency)에 있다. 즉, 3년 전 특정일 하루 치 주가만 보려고 해도, 압축을 풀기 위해 최상단 기준점(Base)부터 3년 치 데이터를 메모리에 다 퍼올려서 순차적으로 델타 연산을 주르륵 수행해야 하는 디코딩(Decoding) 병목이 발생하여 쿼리가 뻗어버린다.
- 해결책: TSDB는 무한정 델타로 엮지 않고, 통상 2시간~4시간 분량의 데이터(수천 개)를 1개의 **블록(Block)**으로 자른다. 각 블록의 첫머리에 온전한 기준값(Base Value)을 하드코딩하여 독립성을 보장함으로써, 디코딩 연산의 최악 피해를 1개 블록 크기로 제한(Bounded)하는 아키텍처 설계가 필수적이다.

시계열 DB 압축 설계 의사결정 트리

  ┌───────────────────────────────────────────────────────────────────┐
  │           시계열 데이터 압축/저장 아키텍처 의사결정 트리              │
  ├───────────────────────────────────────────────────────────────────┤
  │                                                                   │
  │   [수집되는 스트리밍 데이터의 특성 파악]                               │
  │                │                                                  │
  │                ▼                                                  │
  │      데이터가 순차적인 시간(Time-Series) 흐름을 가지는가?             │
  │          ├─ 아니오 ──▶ [일반 RDBMS 저장 및 LZ4/Snappy 블록 압축]     │
  │          │                                                        │
  │          └─ 예                                                    │
  │                │                                                  │
  │                ▼                                                  │
  │      값(Value)의 변화폭이 점진적이고 완만한가? (온도, 주가, CPU 등)      │
  │          ├─ 예 ──▶ [Gorilla 알고리즘 기반 TSDB (InfluxDB 등) 전격 도입] │
  │          │         - Delta-of-Delta 및 XOR 압축 활성화 보장         │
  │          │                                                        │
  │          └─ 아니오 (값이 매번 완전히 무작위로 튐. 예: UUID 해시값 등)  │
  │                │                                                  │
  │                ▼                                                  │
  │      [델타 인코딩 효율 저하 경고 🚨]                                  │
  │        - 차이(Delta)값이 원본만큼 커져 압축률이 나락으로 떨어짐.          │
  │        - 컬럼 기반(Columnar) 스토리지(ClickHouse, Parquet)로 선회하여 │
  │          사전(Dictionary) 인코딩이나 RLE(Run-Length) 혼합 전략 수립.   │
  │                                                                   │
  │   판단 포인트: "변화의 진폭(Variance)이 좁을수록 델타 압축은 신의 무기다." │
  └───────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 의사결정 트리는 "TSDB를 쓰면 무조건 용량이 줄어든다"는 주니어 엔지니어의 환상을 깨버린다. 만약 로깅 데이터의 값이 1에서 1,000,000으로 널뛰기하는 유저 세션 ID 같은 랜덤 난수라면, 델타(차이) 값 자체가 원본 32비트 공간을 고스란히 차지해 버리므로 델타 인코딩의 이점이 0으로 수렴한다. 압축 알고리즘은 마법이 아니라 수학이다. 따라서 아키텍트는 도입 전 반드시 데이터의 카디널리티(Cardinality)와 연속성(Continuity) 패턴을 샘플링하여 검증해야 하며, 랜덤성 데이터가 많을 경우 Parquet 같은 컬럼 스토어 기반의 범용 빅데이터 에코시스템으로 우회하는 기술적 혜안이 필요하다.

📢 섹션 요약 비유: 지퍼백(델타 인코딩)은 솜이 많이 든 푹신한 패딩(서서히 변하는 수치)을 압축할 때는 기적처럼 얇아지지만, 쇳덩어리(랜덤 난수)를 지퍼백에 넣고 공기를 빼봤자 부피는 1밀리미터도 줄어들지 않는 것과 같은 원리입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	일반 RDBMS 저장 (Raw Data)	Gorilla (델타 인코딩) 적용	개선 효과
정량	1개 포인트당 16바이트(128비트) 소모	타임스탬프 1비트 + 값 수 비트로 가변 저장	스토리지 용량 90% ~ 95% 절감
정량	캐시 히트율 저하로 잦은 디스크 I/O 발생	엄청난 양의 과거 데이터를 메모리(RAM)에 상주	범위 집계 쿼리(Aggregation) 속도 수십 배 향상
정성	늘어나는 데이터 대비 스토리지 증설 비용 급증	메모리 중심의 실시간 인프라(In-Memory) 아키텍처 완성	클라우드 EBS/디스크 TCO 예산의 획기적 다이어트

미래 전망

AI/ML 기반 동적 예측 압축 (Predictive Compression): 단순한 앞뒤 빼기(Delta)를 넘어, TSDB 내장 머신러닝 엔진이 "이 센서는 보통 이런 사인 곡선(Sine Wave)을 그린다"는 함수 모델을 학습한 뒤, 실제 값이 예측 모델과 일치하면 데이터를 아예 버리고(0바이트), 예측에서 벗어난 노이즈(잔차, Residual)만을 디스크에 델타로 기록하는 극한의 3세대 압축 기술이 연구실을 넘어 상용화 목전에 있다.
포맷 유지 이종 호환성 (Arrow/Parquet 연동): 압축된 델타 블록을 푸는 과정 없이, 압축된 바이너리 상태 그대로 아파치 애로우(Apache Arrow) 같은 인메모리 열기반 프레임워크 위에서 곧바로 SIMD 벡터 연산을 꽂아버리는 처리 기술이 데이터 웨어하우스(DW)의 판도를 바꾸고 있다.

참고 표준

Gorilla: A Fast, Scalable, In-Memory Time Series Database (VLDB 2015): 메타(Facebook)가 발표하여 현대 TSDB 압축의 바이블이 된 기념비적 논문
Beringei: Gorilla 논문을 오픈소스로 구현한 프로젝트이며, 이 사상은 Prometheus의 V3 스토리지 엔진에 핵심으로 이식됨

결론적으로 델타 인코딩과 Gorilla 알고리즘은 무식한 '물리적 저장 공간의 싸움'을 지능적인 '수학적 비트 연산의 싸움'으로 바꾼 소프트웨어 엔지니어링의 쾌거다. 우주 팽창 속도로 쏟아지는 기계 생성(Machine-generated) 빅데이터 시대에, 데이터를 얼마나 잘 쌓느냐보다 '어떻게 깎아내어 군더더기 없이 메모리에 욱여넣을 것인가'가 데이터 파이프라인의 생사를 가른다. 값비싼 디스크나 메모리 증설 결재판을 올리기 전에, 아키텍트는 반드시 데이터의 군살을 제거하는 이 극단적인 압축 엔진의 도입을 영순위로 검토해야 한다.

📢 섹션 요약 비유: 수만 권의 백과사전을 컨테이너에 싣고 배로 나르는 대신(과거의 무식한 저장), 백과사전의 글자들을 현미경으로만 볼 수 있는 마이크로필름으로 축소 인쇄하여 작은 서류 가방 하나에 넣어 비행기로 당일 배송해버리는(델타 인코딩) 것이 현대 데이터 아키텍처의 혁신입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
시계열 데이터베이스 (TSDB)	델타 인코딩과 Gorilla 압축이 태생적으로 녹아 들어가 있는 최적의 저장 엔진 (InfluxDB, Prometheus 등)이다.
XOR (배타적 논리합)	두 이진수가 같으면 0, 다르면 1을 뱉는 연산으로, 소수점(Double) 데이터의 변하지 않는 앞부분을 전부 0으로 날려버리는 부동소수점 압축의 핵심 톱니바퀴다.
보간 (Interpolation)	델타 압축이 잘 작동하려면 빈칸이 없어야 하므로, 끊어진 데이터 틈새를 수학적으로 채워주는 보간 쿼리(375번 문서)가 선행되어야 시너지가 극대화된다.
컬럼 스토어 (Columnar Store)	델타 인코딩은 같은 성질의 연속된 데이터가 모여 있을 때 강력하므로, 로우(Row) 방식보다 속성별로 세로로 묶어 저장하는 컬럼 구조와 찰떡궁합을 이룬다.
다운샘플링 (Downsampling)	아무리 압축을 잘해도 10년 치 데이터는 크기 마련이므로, 오래된 1초 데이터를 1시간 단위 평균값으로 뭉쳐버리는 또 다른 차원의 용량 절감 기술이다.

👶 어린이를 위한 3줄 비유 설명

선생님이 칠판에 숫자 100, 101, 102, 101을 매번 다 적으려면 분필이 너무 많이 닳아요.
똑똑한 선생님(델타 인코딩)은 맨 처음에만 100이라고 크게 적고, 그다음부터는 전날보다 얼마나 변했는지 +1, +1, -1이라고 아주 작게 기호만 적는답니다.
이렇게 하면 칠판(디스크) 공간을 엄청나게 아낄 수 있어서, 지우지 않고도 한 달 치 숫자를 거뜬히 다 적어둘 수 있어요!