[2025.10.03 주간 개발 트렌드] React 19.2 정리 (Activity, Effect, SSR)

![주간 개발 트렌드](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/b28d786c-9ec3-46ec-8055-adcd53a303c5_thumbnail_2.png)

# PostgreSQL 18이 정식 출시됐다

이번달 초에는 PostgreSQL 18 RC1을 보면서 정식 출시 전에 무엇을 확인하면 좋을지 정리했다. 이번주에는 정식 버전 소식이 나왔다.

9월 25일에 [PostgreSQL 18](https://www.postgresql.org/about/news/postgresql-18-released-3142/)이 출시됐다. 비동기 I/O와 업그레이드 개선도 들어왔지만, 애플리케이션을 작성하는 입장에서는 uuidv7()이 먼저 눈에 들어왔다.

이번주에는 UUID 기본키와 생성 컬럼을 중심으로 실제 테이블을 설계할때 달라질 부분을 정리해보려고 한다.

# 1. 우선 성능 발표의 범위를 보자

PostgreSQL 프로젝트는 새로운 I/O 시스템으로 특정 읽기 작업에서 최대 3배의 성능 향상을 확인했다고 발표했다. 순차 스캔이나 비트맵 힙 스캔, VACUUM 등에서 여러 I/O 요청을 동시에 진행할 수 있는 변화다.

여기서 중요한건 특정 작업이라는 조건이다. 모든 API가 버전만 올리면 3배 빨라진다는 뜻으로 읽으면 안된다.

캐시와 저장장치, 동시 요청 수에 따라 체감은 달라진다. CPU나 잠금이 병목인 작업도 따로 봐야한다. 오래 걸리는 조회와 배치를 같은 데이터로 비교하고 실행 시간과 자원 사용량을 같이 남겨보면 좋겠다.

# 2. UUIDv7은 왜 눈에 들어올까

기본키로 UUID를 쓰면 여러 시스템에서 ID를 만들기 편하다. 다만 랜덤한 UUIDv4는 B-tree의 여러 위치에 삽입이 발생해 인덱스 페이지와 캐시 사용에 영향을 줄 수 있다.

[UUIDv7](https://www.postgresql.org/docs/18/functions-uuid.html)은 시간 정보를 포함하는 UUID다. 생성 시점이 가까운 값이 인덱스에서도 모이는 방향이라 삽입 지역성을 개선할 여지가 있다. PostgreSQL 18에서는 uuidv7() 함수로 직접 생성할 수 있다.

```sql
CREATE TABLE reading_logs (
    id UUID PRIMARY KEY DEFAULT uuidv7(),
    title TEXT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

INSERT INTO reading_logs (title)
VALUES ('PostgreSQL 18 정리')
RETURNING id, created_at;
```

위의 코드에서는 애플리케이션이 ID를 전달하지 않으면 데이터베이스가 UUIDv7을 만든다. ID를 생성하는 함수가 DB에 들어왔으니 이를 위해 별도의 생성 라이브러리를 사용하는 구성은 줄일 여지가 있다.

단, 애플리케이션에서 저장 전에 ID가 필요한 경우도 있다. 이벤트를 만들거나 여러 객체를 묶는 과정에서 미리 식별자를 사용한다면 DB 기본값만으로 요구사항이 해결되는지 확인해야한다.

# 3. 시간순 UUID가 모든 순서를 보장할까

UUIDv7은 시간 정보를 바탕으로 정렬되는 특성이 있지만, 서비스의 모든 이벤트 순서를 대신하는 값으로 보면 안된다.

여러 서버의 시계와 ID 생성 위치, 트랜잭션이 완료되는 순서가 다를 수 있기 때문이다. ID가 만들어진 시간과 실제 저장이 확정된 시간도 같은 개념은 아니다.

```text
구분해서 생각할 값
id           : 데이터의 식별자
created_at   : 서비스에서 정한 생성 시각
이벤트 순번  : 별도 순서 보장이 필요할때 사용하는 기준
```

created_at을 무조건 지우기보다는 각 컬럼의 의미를 정하고 조회 정렬과 페이지네이션 조건도 명시해야한다.

또한 UUIDv7에는 대략적인 생성 시각을 알 수 있는 정보가 들어간다. 추측하기 어려운 문자열처럼 보인다고 인증 토큰이나 접근 권한을 대신하게 만들면 안된다.

중복은 PRIMARY KEY나 UNIQUE 제약으로 관리하고 데이터 접근은 권한 검사로 확인해야한다.

기존 UUIDv4 데이터를 전부 다시 생성하는 작업도 신중해야한다. 외래키와 외부 시스템의 참조까지 바뀔 수 있으니 새 테이블이나 새 데이터의 생성 전략부터 비교해볼 수 있겠다.

# 4. Virtual Generated Columns는 언제 쓸까

다른 컬럼으로 계산할 수 있는 값을 테이블에서 다루고싶을때 생성 컬럼을 생각할 수 있다. PostgreSQL 18에는 값을 조회할때 계산하는 가상 생성 컬럼이 들어왔고, 생성 컬럼의 기본 방식도 가상 방식이다.

예를 들어 수량과 단가로 합계를 계산하는 테이블을 만들어보자.

```sql
CREATE TABLE order_items (
    id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    quantity INTEGER NOT NULL,
    unit_price NUMERIC(12, 2) NOT NULL,
    subtotal NUMERIC GENERATED ALWAYS AS
        (quantity * unit_price) VIRTUAL
);
```

subtotal은 조회할때 quantity와 unit_price를 이용해 계산된다. 값을 저장하는 STORED 방식과 계산 시점이 다르다. [생성 컬럼의 규칙](https://www.postgresql.org/docs/18/ddl-generated-columns.html)에는 표현식과 사용할 수 있는 함수에 대한 제약도 있으니 확인해야한다.

위의 예시는 단순한 산술 계산이다. 실제 결제 금액은 할인과 세금, 반올림 정책에 따라 의미가 달라질 수 있다. 모든 금액을 이 예시처럼 처리할 수 있다는 뜻은 아니다.

읽는 횟수와 계산 비용, 저장 공간을 비교해서 VIRTUAL과 STORED를 선택하면 좋겠다. 과거 거래에서 확정한 가격과 현재 가격도 구분해야한다. 생성 컬럼이 이력 관리 정책까지 대신 정해주지는 않는다.

# 5. 운영 전환에서는 무엇을 확인할까

18에는 플래너 통계를 보존하는 메이저 업그레이드 개선과 OAuth 2.0 인증 지원도 포함됐다. OAuth는 관련 확장과 인증 환경을 연결하는 구성이 필요하다. DB 버전만 올렸다고 로그인 체계가 자동으로 바뀌는것은 아니다.

RC에서 확인한 결과가 있다면 다시 비교하고 확장 모듈과 드라이버, ORM의 동작도 확인해보자.

```text
새 버전 검증
├── 기존 쿼리의 결과와 실행 계획
├── ORM의 기본값과 생성 컬럼 처리
├── 백업 복원과 업그레이드 소요 시간
└── 전환 후 모니터링과 복구 절차
```

새 함수가 SQL에서 동작하는것과 애플리케이션 전체에서 원하는 값이 전달되는것은 다르다. 예를 들어 INSERT 후 생성된 ID를 ORM이 돌려주는지, 생성 컬럼을 수정하려는 쿼리가 나오지는 않는지 살펴볼 수 있겠다.

운영 전환은 메이저 업그레이드 절차에 맞춰 준비해야한다. 실제 전환 시간과 인덱스 동작을 비교할 수 있도록 테스트 데이터의 규모도 고려하자.

# 마무리

이번 PostgreSQL 18에서는 성능과 운영 개선에 더해 애플리케이션의 데이터 모델에 바로 연결되는 기능이 눈에 들어온다.

개인적으로는 uuidv7()을 DB 기본값으로 사용할 수 있다는 점이 흥미롭다. 다만 UUID를 고르는 이유와 ID가 필요한 시점, 정렬 기준까지 같이 정해야 의미있는 선택이 될것 같다.

우선 작은 테이블에서 생성과 조회를 확인하고 실제 서비스의 쿼리와 데이터 크기로 비교해보면 좋겠다. 정식 출시라는 소식을 바로 버전 변경으로 연결하기보다 우리 서비스에서 얻는 이점을 확인해봐야겠다..


[2025.09.26 주간 개발 트렌드] PostgreSQL 18 정리 (UUIDv7, 생성 컬럼, 비동기 I/O)

독자의 메모