[2025.09.12 주간 개발 트렌드] Gemini CLI 확장 정리 (보안 분석, Cloud Run 배포, DevSecOps)

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

# PostgreSQL 18을 미리 확인해볼 시점이다

데이터베이스 버전이 올라온다고 운영 환경을 바로 바꾸기는 어렵다. 쿼리가 잘 돌아가는것도 중요하지만 확장 모듈이나 백업, 업그레이드 시간까지 같이 확인해야하기 때문이다.

이번주 9월 4일에 [PostgreSQL 18 RC1](https://www.postgresql.org/about/news/postgresql-18-rc-1-released-3130/)이 공개됐다. 정식 출시 전 마지막 검증에 가까운 단계로, 현재 정식 출시 예정일은 9월 25일이다. 발견되는 문제에 따라 일정은 달라질 수 있다.

그래서 이번주에는 새 기능을 전부 외우기보다 우리 서비스에서 무엇을 테스트하면 좋을지 정리해보려고 한다.

# 1. 우선 RC가 어떤 단계인지 보자

RC는 Release Candidate의 줄임말이다. 정식 버전 후보라는 뜻이고, 큰 기능을 계속 추가하기보다는 출시 전에 문제를 찾고 수정하는 단계로 보면 된다.

그렇다고 운영 데이터베이스에 바로 올려도 된다는 뜻은 아니다. 실제 서비스와 비슷한 환경에서 호환성과 성능을 확인하는 용도로 접근하는게 좋겠다.

```text
기능 소개 확인
    ↓
테스트 환경에 PostgreSQL 18 RC1 준비
    ↓
데이터와 쿼리, 확장 모듈 검증
    ↓
정식 버전의 결과와 변경 사항 재확인
    ↓
운영 전환 여부 결정
```

평소 느린 쿼리가 있다면 지금부터 비교 대상을 남겨둘 수 있다. 정식 출시 소식을 보고 테스트를 시작하는것보다 어떤 지표를 볼지 먼저 정해두면 판단하기가 수월하다.

# 2. 이번 버전에서는 무엇이 달라지나

18에서 준비된 변화는 [Beta 1 발표](https://www.postgresql.org/about/news/postgresql-18-beta-1-released-3070/)에서도 확인할 수 있다. 애플리케이션 개발과 운영 양쪽에 걸쳐있다.

| 변화 | 확인해볼 부분 |
| --- | --- |
| Async I/O | 데이터를 읽는 작업의 대기 시간을 줄일 수 있는가 |
| UUIDv7 | 시간 정보를 포함한 UUID를 기본키 후보로 쓸 수 있는가 |
| Virtual Generated Columns | 계산값을 저장하지 않고 조회할때 만들 수 있는가 |
| OAuth 2.0 인증 | 기존 인증 체계와 연결할 여지가 있는가 |
| 인덱스 활용 개선 | 기존 쿼리의 실행 계획이 어떻게 달라지는가 |
| 메이저 업그레이드 개선 | 전환 작업과 전환 직후의 부담이 줄어드는가 |

이름만 보면 기능이 많아보이는데, 전부 우리 서비스에 필요한것은 아닐 수 있다. UUID를 사용하지 않는 서비스라면 UUIDv7보다 실행 계획이나 업그레이드 시간이 더 중요한 변화일 수도 있다.

새 기능을 몇개 쓰는지보다 현재 겪는 문제와 연결해서 살펴보는게 좋겠다.

# 3. Async I/O가 있으면 모든 쿼리가 빨라질까

이번에 들어오는 비동기 I/O는 여러 읽기 요청을 진행하면서 저장장치를 기다리는 시간을 더 효율적으로 다루려는 변화다. 순차 스캔이나 비트맵 힙 스캔, VACUUM 같은 작업이 대상에 포함된다.

다만 데이터베이스가 느린 원인은 하나가 아니다.

```text
응답 시간이 긴 이유
├── 디스크 읽기 대기
├── CPU 연산
├── 잠금 대기
├── 비효율적인 쿼리와 인덱스
└── 애플리케이션에서 반복하는 DB 호출
```

디스크 읽기를 개선해도 잠금을 오래 기다리는 쿼리까지 해결되지는 않는다. 이미 메모리에 대부분의 데이터가 올라와있는 경우도 별도로 봐야한다.

그래서 테스트할때는 같은 데이터와 같은 쿼리로 비교하는게 중요하다. 캐시가 비어있는 경우와 충분히 데워진 경우를 섞으면 버전 차이인지 캐시 차이인지 구분하기 어렵다.

평균 응답 시간만 보지말고 느린 요청의 지연 시간, CPU와 디스크 사용량, 동시에 처리하는 요청 수를 같이 남겨보자. 단일 쿼리 한번이 빨라지는것과 여러 요청이 들어왔을때 안정적인것도 다르다.

# 4. 실행 계획과 데이터 구조도 같이 보자

인덱스 활용 방식이 달라진다면 기존 쿼리가 같은 계획을 고를거라고 가정하면 안된다. 자주 사용하는 검색 조건부터 비교해보면 좋겠다.

```sql
EXPLAIN (ANALYZE, BUFFERS)
SELECT id, created_at
FROM orders
WHERE customer_id = 42
ORDER BY created_at DESC
LIMIT 20;
```

위의 코드는 실행 계획과 실제 실행 결과, 버퍼 사용량을 확인하기 위한 예시다. ANALYZE 옵션은 쿼리를 실제로 실행한다. 부하를 재현할 수 있는 테스트 환경에서 사용하는게 좋다.

같은 조건에서 어떤 인덱스를 선택했는지, 예상 행 수와 실제 행 수가 얼마나 차이나는지 확인해보자. 쿼리의 총 시간만 기록하는것보다 원인을 설명하기가 쉽다.

UUIDv7이나 가상 생성 컬럼도 작은 테이블에서 먼저 확인해볼 수 있다. 기본키 전략을 바꾸는 일은 새 함수 하나를 호출하는것보다 범위가 크다. ORM의 기본값 처리나 외부 시스템에 전달하는 ID 형식까지 연결되기 때문이다.

가상 생성 컬럼은 계산값을 읽을때 만드는 방식이므로 저장 공간과 읽기 연산 사이의 선택이 생긴다. 자주 읽는 무거운 계산이라면 저장하지 않는게 항상 유리하다고 보기는 어렵겠다.

# 5. 업그레이드는 별도의 작업이다

PostgreSQL 17에서 18로 이동하는건 메이저 업그레이드다. 컨테이너 이미지 태그만 바꾼다고 기존 데이터 디렉터리를 그대로 사용할 수 있는 작업으로 생각하면 안된다.

우선 pg_upgrade나 dump/restore 중 어떤 경로를 사용할지 정하고 실제 데이터 크기에 맞춰 시간을 재보는게 좋겠다.

1. 사용중인 확장 모듈과 드라이버의 지원 여부를 확인한다.
2. 복구 가능한 백업을 준비하고 복원 과정을 확인한다.
3. 대표 쿼리와 배치, 마이그레이션 작업을 실행한다.
4. 업그레이드 소요 시간과 전환 직후의 성능을 기록한다.
5. 문제가 있을때 이전 환경으로 돌아가는 절차를 정한다.

18에는 업그레이드 후 사용할 플래너 통계를 보존하는 개선도 준비돼있다. 전환 직후 통계가 부족해서 생기는 부담을 줄이는 방향이다. 그래도 실제 운영 쿼리의 실행 계획을 확인하는 과정은 필요하다.

특히 확장 모듈이 중요한 서비스라면 PostgreSQL 본체만 정상 실행되는지 확인하고 끝내면 안된다. 검색이나 공간 데이터처럼 확장 기능을 사용하는 쿼리까지 테스트에 포함해야한다.

# 마무리

이번 PostgreSQL 18 RC1은 운영 환경을 바로 바꾸라는 신호보다는 정식 출시 전에 검증을 시작하기 좋은 시점으로 보인다.

개인적으로는 기능 목록보다 기존 쿼리와 업그레이드 과정이 어떻게 달라지는지 먼저 확인해보고싶다. 데이터베이스는 새로운 문법을 쓸 수 있다는것만큼 전환 후에도 서비스가 안정적인지가 중요하기 때문이다.

지금 사용하는 버전의 기준 성능을 남겨두고 RC에서 비교해보면 좋겠다. 정식 버전이 나왔을때 막연히 빨라졌다는 이야기보다 우리 서비스에서 무엇이 달라지는지 설명할 수 있어야겠다..


[2025.09.05 주간 개발 트렌드] PostgreSQL 18 RC1 정리 (비동기 I/O, UUIDv7, 업그레이드)

독자의 메모