2024년 10월 4일(금) 주간 개발 트렌드

![image](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/2a3741f8-626e-4237-b985-d52de10bb444_thumbnail_1.png)

## Database — PostgreSQL 17 GA

PostgreSQL이 **9월 26일 PostgreSQL 17**을 정식 출시했습니다.

PostgreSQL 17에는 **VACUUM 메모리 관리 개선, 고동시성 Workload 성능 향상, Bulk Loading 개선, `JSON_TABLE()` 지원, Logical Replication 강화** 등 Database 운영과 개발 양쪽에 영향을 주는 변화가 포함됐습니다.

특히 PostgreSQL을 장기간 운영하는 환경에서는 **VACUUM의 새로운 메모리 관리 방식**이 중요한 개선점이었습니다.

[PostgreSQL - PostgreSQL 17 Released](https://www.postgresql.org/about/news/postgresql-17-released-2936/)

---

### PostgreSQL과 MVCC

PostgreSQL은 MVCC(Multi-Version Concurrency Control)를 사용합니다.

여러 Transaction이 동시에 데이터를 읽고 수정할 수 있도록 기존 Row를 즉시 덮어쓰지 않고 새로운 Version을 생성하는 방식입니다.

```text
UPDATE

Old Row
   ↓
새로운 Row Version 생성
   ↓
Old Row는 일정 기간 유지
```

이 구조 덕분에 높은 동시성을 확보할 수 있지만, 더 이상 필요하지 않은 Row Version이 Database 내부에 남게 됩니다.

```text
Table

├─ Active Row
├─ Active Row
├─ Dead Tuple
├─ Dead Tuple
└─ Active Row
```

이러한 Dead Tuple을 정리하는 역할이 바로 **VACUUM**입니다.

---

### VACUUM이 중요한 이유

PostgreSQL 운영에서 VACUUM은 단순한 정리 작업이 아닙니다.

```text
INSERT / UPDATE / DELETE
          ↓
       MVCC
          ↓
    Dead Tuple 발생
          ↓
       VACUUM
          ↓
불필요한 Tuple 정리
```

VACUUM이 제대로 동작하지 않으면 Table과 Index의 불필요한 데이터가 증가하면서 Storage 사용량과 Query 성능에 영향을 줄 수 있습니다.

특히 대규모 Database에서는 VACUUM 자체가 상당한 Resource를 사용하는 작업이 될 수 있습니다.

---

### PostgreSQL 17의 VACUUM 개선

PostgreSQL 17에서는 VACUUM이 사용하는 내부 메모리 관리 방식이 개선됐습니다.

기존 VACUUM은 Dead Tuple 정보를 관리하는 과정에서 Table Size에 따라 상당한 Memory를 사용할 수 있었습니다.

PostgreSQL 17에서는 새로운 메모리 관리 구조가 도입되면서 **VACUUM이 사용하는 Memory를 크게 줄일 수 있게 됐습니다.**

```text
기존 VACUUM

Large Table
     ↓
많은 Dead Tuple
     ↓
높은 Memory 사용


PostgreSQL 17

Large Table
     ↓
개선된 Memory Management
     ↓
더 효율적인 VACUUM
```

대규모 Table을 운영하는 환경에서는 Maintenance 작업의 Resource 부담을 줄이는 데 직접적인 영향을 줄 수 있는 변화입니다.

---

### 고동시성 Workload 개선

PostgreSQL은 Web Application이나 Backend Service에서 여러 Transaction을 동시에 처리하는 경우가 많습니다.

```text
Client A ─┐
Client B ─┤
Client C ─┼→ PostgreSQL
Client D ─┤
Client E ─┘
```

사용자가 많아질수록 동시에 실행되는 Query와 Transaction도 증가합니다.

PostgreSQL 17에서는 이러한 **High Concurrency Workload에서 발생할 수 있는 내부 Contention과 처리 성능을 개선하는 작업**이 이어졌습니다.

즉 단순한 Single Query Benchmark뿐 아니라 실제 Production 환경처럼 많은 Connection과 Transaction이 동시에 발생하는 상황에서도 성능을 개선하려는 방향입니다.

---

### Bulk Loading 성능 개선

대량 데이터를 Database에 넣어야 하는 상황도 자주 발생합니다.

예를 들어 다음과 같은 작업입니다.

```text
CSV
 ↓
Import
 ↓
PostgreSQL

Millions of Rows
```

Data Migration, ETL, 초기 Dataset 적재 같은 작업에서는 수백만 건 이상의 Row를 한 번에 넣어야 할 수 있습니다.

PostgreSQL 17에서는 이러한 **Bulk Loading 과정의 성능도 개선**됐습니다.

```text
Large Dataset
     ↓
Bulk Insert / COPY
     ↓
PostgreSQL 17
     ↓
Improved Loading Performance
```

대규모 데이터 Migration이나 Data Pipeline을 운영하는 환경에서 의미가 있는 변화입니다.

---

### JSON_TABLE()

PostgreSQL 17에서는 SQL/JSON 표준의 **`JSON_TABLE()`** 기능이 추가됐습니다.

JSON 데이터를 Relation 형태로 변환해 일반적인 SQL Query처럼 다룰 수 있습니다.

예를 들어 다음과 같은 JSON 데이터가 있다고 하면,

```json
{
  "users": [
    {
      "name": "Park",
      "age": 30
    },
    {
      "name": "Kim",
      "age": 28
    }
  ]
}
```

`JSON_TABLE()`을 이용해 이를 Table 형태로 변환해 조회할 수 있습니다.

```text
JSON

{
  users: [...]
}

      ↓

JSON_TABLE()

      ↓

name | age
------------
Park | 30
Kim  | 28
```

PostgreSQL에서 Relational Data와 JSON Data 사이의 경계가 더욱 줄어드는 것입니다.

---

### PostgreSQL의 JSON 지원

PostgreSQL은 오래전부터 `json`과 `jsonb` Type을 제공했습니다.

```text
PostgreSQL

Relational Data
      +
JSON / JSONB
```

따라서 Application에서는 모든 데이터를 완전히 정규화된 Table 형태로 저장하지 않고 일부 Flexible Data를 JSON으로 저장하는 Architecture도 사용할 수 있습니다.

```text
users

id
name
email
metadata JSONB
```

여기에 `JSON_TABLE()` 같은 SQL 표준 기능이 추가되면서 JSON 데이터를 SQL Query 안에서 다루는 방식도 더욱 강력해지고 있습니다.

---

### Logical Replication 강화

PostgreSQL 17에서는 **Logical Replication** 기능도 개선됐습니다.

Logical Replication은 Database의 물리적인 Storage Block을 그대로 복제하는 방식이 아니라 데이터 변경 내용을 논리적인 단위로 전달합니다.

```text
Primary PostgreSQL
       ↓
INSERT / UPDATE / DELETE
       ↓
Logical Replication
       ↓
Subscriber PostgreSQL
```

이를 활용하면 다음과 같은 Architecture를 만들 수 있습니다.

- Database Migration
- Version Upgrade
- Data Distribution
- 일부 Table 복제
- Zero / Low Downtime Migration
- 새로운 Database Cluster로 데이터 이전

---

### Physical Replication과 Logical Replication

PostgreSQL에는 대표적으로 두 가지 Replication 접근 방식이 있습니다.

```text
Replication

├─ Physical Replication
│      ↓
│   Storage / WAL 기반
│
└─ Logical Replication
       ↓
    Data Change 기반
```

Physical Replication은 전체 Database Cluster를 복제하는 데 적합합니다.

반면 Logical Replication은 특정 Database Object나 데이터 변경 내용을 선택적으로 전달할 수 있기 때문에 더 유연한 Migration과 Data Integration에 사용할 수 있습니다.

---

### Major Upgrade에서도 중요한 이유

PostgreSQL Major Version을 변경하는 것은 단순히 Package Version을 바꾸는 작업으로 끝나지 않습니다.

```text
PostgreSQL 16
      ↓
Migration
      ↓
PostgreSQL 17
```

특히 규모가 큰 Database에서는 Downtime이 큰 문제가 됩니다.

Logical Replication을 활용하면 새로운 Version의 PostgreSQL Cluster를 별도로 구축한 뒤 데이터를 동기화하는 방식도 사용할 수 있습니다.

```text
PostgreSQL 16
      ↓
Logical Replication
      ↓
PostgreSQL 17

      ↓

Traffic 전환
```

따라서 Logical Replication의 개선은 Database Upgrade와 Migration 전략에도 직접적인 영향을 줄 수 있습니다.

---

### PostgreSQL은 단순한 RDBMS가 아니다

PostgreSQL의 변화에서 중요한 흐름은 PostgreSQL이 단순한 Relational Database를 넘어 점점 더 많은 데이터 Workload를 처리하고 있다는 점입니다.

```text
PostgreSQL

├─ Relational Database
├─ JSON
├─ Replication
├─ High Availability
├─ Analytics
├─ Full Text Search
└─ Extensions
```

특히 Extension 생태계를 활용하면 PostgreSQL의 역할을 더욱 확장할 수 있습니다.

```text
PostgreSQL
    +
Extensions
```

대표적으로 다양한 기능을 Extension 형태로 추가할 수 있습니다.

```text
PostGIS
→ GIS / Spatial Data

pgvector
→ Vector Search

TimescaleDB
→ Time Series

Extensions
→ 다양한 Database 기능 확장
```

하나의 PostgreSQL 환경에서 여러 종류의 Workload를 처리할 수 있는 선택지가 커지고 있는 것입니다.

---

### Backend 관점에서의 장점

Backend Architecture를 구성할 때 Database가 늘어날수록 운영 Complexity도 증가합니다.

예를 들어 각각의 데이터 유형마다 별도의 Database를 사용한다면,

```text
Application

├─ PostgreSQL
├─ Redis
├─ Elasticsearch
├─ Vector DB
└─ Time Series DB
```

각 시스템을 별도로 운영해야 합니다.

```text
Backup
Monitoring
Scaling
Security
Connection
Upgrade
```

반대로 PostgreSQL Extension과 JSON 기능을 활용하면 일부 Workload는 하나의 Database에서 처리할 수도 있습니다.

```text
Application
     ↓
PostgreSQL

├─ Relational
├─ JSON
├─ Vector
├─ Search
└─ Spatial
```

물론 모든 Workload를 PostgreSQL 하나에 넣는 것이 항상 정답은 아니지만, **초기 Architecture에서 불필요하게 많은 Database를 도입하지 않을 수 있는 선택지**가 생깁니다.

---

### 범용 Data Platform으로의 발전

PostgreSQL은 전통적으로 안정성과 SQL 표준 지원이 강한 Open Source RDBMS였습니다.

하지만 최근에는 역할이 더욱 확장되고 있습니다.

```text
기존 PostgreSQL

Relational Database
        ↓
Transaction / SQL


현재 PostgreSQL

Relational
+
JSON
+
Replication
+
HA
+
Analytics
+
Extensions
```

이런 확장성 때문에 PostgreSQL은 단순한 Application Database를 넘어 **다양한 Data Workload의 중심 Platform**으로 활용할 수 있게 됐습니다.

---

### 실무 영향

PostgreSQL 17의 변화는 특히 규모가 큰 Database를 운영하는 환경에서 의미가 있습니다.

운영 측면에서는

```text
VACUUM
+
Memory Efficiency
+
High Concurrency
```

가 개선됐고,

데이터 처리 측면에서는

```text
Bulk Loading
+
JSON_TABLE()
```

이 강화됐으며,

Database Architecture 측면에서는

```text
Logical Replication
+
Migration
+
Major Upgrade
```

관련 기능이 발전했습니다.

결국 PostgreSQL 17은 단순한 기능 추가 Release라기보다,

> **PostgreSQL이 대규모 Production 환경의 운영 효율을 개선하면서 동시에 다양한 데이터 형태와 Architecture를 지원하는 범용 Data Platform으로 계속 발전하고 있음을 보여주는 Release**

라고 볼 수 있습니다.

Backend 개발자 입장에서도 PostgreSQL을 단순히 CRUD를 위한 RDBMS로만 보는 것이 아니라 **Transaction, JSON, Replication, Extension, Vector, Analytics까지 포함하는 하나의 Data Platform으로 이해할 필요가 점점 커지고 있습니다.**

2024년 9월 27일(금) 주간 개발트렌드

독자의 메모