[2026.05.22 주간 개발 트렌드] 관리형 Agent와 Deno 2.8, npm 공급망 보안

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

# 이번주는 새 기능보다 현재 서비스의 지원 상태를 확인할 주다

이번주에는 PostgreSQL의 정기 보안 업데이트와 OpenAI 구형 API의 제거, CodeQL 분석 개선 소식이 나왔다. 새로운 모델을 시험하는것과 별개로 지금 서비스가 무엇에 의존하는지 확인해야할 내용이 많다.

DB의 메이저 버전이 같아도 패치 수준은 다르고, API를 호출할 수 있었던 코드도 지원 종료 뒤에는 같은 방식으로 동작하지 않을 수 있다. 문서의 의도와 실제 실행 상태를 대조해볼 시점이다.

5월 11일부터 15일까지의 내용을 세가지로 나눠보았다.

| 분야 | 이번주 소식 | 먼저 확인할 부분 |
| --- | --- | --- |
| Database·보안 | PostgreSQL 지원 버전 업데이트 | 서버와 도구의 패치, 실제 영향 조건 |
| AI API | DALL·E·Realtime Beta 제거 | 남아있는 호출과 후속 인터페이스 전환 |
| 코드 보안 | CodeQL 2.25.4 | 분석 모델의 범위와 실제 검토 결과 |

개인적으로는 이번주에 기능 목록을 늘리기보다 현재 운영 경로와 버전을 정리하는것이 먼저라고 생각한다.

# 1. Database·보안 — PostgreSQL이 11건의 취약점을 수정했다

5월 14일 [PostgreSQL 18.4, 17.10, 16.14, 15.18, 14.23](https://www.postgresql.org/about/news/postgresql-184-1710-1614-1518-and-1423-released-3297/)이 공개됐다. 지원 버전 전반에서 11건의 보안 취약점과 60건이 넘는 버그를 수정했다.

정수 오버플로와 메모리 처리, SQL 인젝션과 인증 등 여러 경로가 포함된다. 숫자가 크다는 설명에서 끝내기보다 현재 사용하는 기능과 버전이 어느 조건에 해당하는지 확인해야겠다.

## 먼저 실제 버전과 구성을 정리하자

서비스 문서에 PostgreSQL 17이라고 적혀있어도 실제 패치 수준은 인스턴스별로 다를 수 있다. 운영과 복제본, 테스트 환경과 관리 도구를 나눠서 봐야한다.

현재 접속한 서버의 버전과 확장 목록은 다음처럼 확인할 수 있다.

```sql
SELECT version();

SELECT extname, extversion
FROM pg_extension
ORDER BY extname;
```

이 결과만으로 영향 여부를 모두 판정할 수는 없다. 어떤 공지와 비교해야할지 알기 위한 출발점이다. 사용하는 기능과 접근 권한, 실제 요청 경로도 함께 확인해야한다.

관리형 서비스라면 제공자가 적용하는 버전과 유지보수 절차를 확인하고, 직접 관리한다면 패키지와 이미지의 버전까지 대조하면 좋겠다.

환경 이름만으로 대상을 묶지 않는것도 중요하다. 같은 운영 환경 안에서도 읽기 복제본이나 배치용 인스턴스가 다른 시점에 업데이트됐을 수 있기 때문이다.

## 서버 외에 클라이언트 도구도 살펴보자

이번 보안 안내에는 `libpq`와 `pg_dump`, `psql` 등 클라이언트 경로와 관련된 내용도 있다. DB 서버의 패치 버전만 확인하면 운영 도구의 상태를 놓칠 수 있다.

백업과 복구, 데이터 이동을 수행하는 컨테이너나 관리용 서버에 어떤 도구가 설치되어 있는지 확인해보자. 애플리케이션과 다른 이미지에서 실행될 수 있다.

```text
DB 시스템의 업데이트 범위
서버 + 복제본 + 확장 + 백업·복구 도구 + 연결 클라이언트
```

같은 제품 이름을 쓰더라도 실행하는 위치와 버전이 다르면 별도 관리 대상이다. 언제 어떤 환경에서 도구가 사용되는지 기록해두면 패치 범위를 정하기 쉽다.

업데이트 후에는 도구가 시작되는지뿐 아니라 실제 백업 결과와 복구 경로를 확인하면 좋겠다. 파일이 생성된것과 필요한 데이터를 되살릴 수 있는것은 다른 확인이다.

## 인증 기본값과 기존 저장 상태를 구분하자

인증 관련 수정에서는 기존 DB가 어떤 이력을 갖고 있는지도 중요하다. 새 버전의 기본 인증 방식과 과거 업그레이드에서 유지된 사용자 설정이 항상 같은 상태는 아니기 때문이다.

이번 안내의 MD5 인증 관련 문제도 이런 구분과 연결된다. 현재 지원 버전의 기본값만 보고 오래된 환경에서 남아있는 설정까지 같은것으로 가정하지 않는게 좋겠다.

인증 방식을 정리할때는 서버 설정과 클라이언트 지원을 함께 확인해야한다. 한쪽만 바꾸면 정상 사용자의 연결이 실패할 수 있기 때문이다.

실제 비밀값을 공유하거나 로그에 남길 필요는 없다. 사용중인 방식과 지원 버전, 연결 결과를 기준으로 현재 상태를 확인하고 전환 절차를 검토할 수 있다.

# 2. DB 운영 — 패치의 완료는 서비스와 복구까지 연결된다

같은 메이저 안의 마이너 업데이트와 메이저 업그레이드는 다른 작업이다. 그렇다고 마이너 패치에서 재시작과 연결 회복, 추가 절차를 확인하지 않아도 되는것은 아니다.

현재 환경의 공식 적용 절차와 릴리스 안내를 확인하고, 실제 서비스가 사용하는 경로를 기준으로 검증 범위를 잡으면 좋겠다.

## 연결 확인용 쿼리와 대표 업무 쿼리를 나누자

간단한 조회는 서버가 응답하는지 보여준다. 하지만 로그인과 검색, 주문 처리와 배치가 기대한 결과를 반환하는지까지 대신 확인해주지는 않는다.

대표 쿼리에는 현재 데이터의 경계 조건을 넣어보자. 빈 값과 긴 문자열, 다양한 문자와 오래된 데이터가 포함될 수 있다. 실제 서비스에서 자주 사용하는 정렬과 필터도 비교 대상이다.

| 경로 | 비교할 결과 |
| --- | --- |
| 사용자 조회 | 데이터와 연결 복구, 오류 |
| 검색·목록 | 필터와 정렬, 응답 시간 |
| 쓰기 트랜잭션 | 제약과 트리거, 실패 시 상태 |
| 복제본 읽기 | 복제 상태와 실제 라우팅 |
| 배치·백업 | 실행 결과와 다음 작업 가능 여부 |

복제본이 정상이라고 표시돼도 애플리케이션이 실제로 그 복제본에 요청을 보내는지 확인해야한다. 장애 우회가 남아있으면 사용자 응답만 보고 상태를 오해할 수 있다.

업데이트 시점과 앱 배포 시점을 따로 기록하면 이후 문제의 원인을 좁히기 쉽다. 여러 변경을 같은 시간에 몰아넣으면 어느 변경이 영향을 줬는지 설명하기 어려워진다.

## 복구 절차는 실행해본 근거가 필요하다

백업이 있다는 사실과 목표 시간 안에 복구할 수 있다는 사실은 다르다. 실제 복구에 필요한 계정과 환경, 파일과 절차를 확인해야한다.

격리된 환경에서 복구하고 주요 데이터의 관계와 앱 연결을 확인해보면 좋겠다. 서버가 실행된것만으로 올바른 시점의 데이터가 준비됐다고 판단하기 어렵다.

문제가 생겼을때 이전 버전으로 돌아가는 방법도 환경별로 다를 수 있다. 단순히 패키지를 낮추면 모든 상태가 복원된다고 가정하지 않고 지원되는 절차를 확인해야겠다.

개인적으로는 패치 적용 기록에 실제 확인한 범위와 남아있는 제약을 함께 남기고 싶다. 이후 운영자가 같은 시스템의 상태를 다시 해석하지 않아도 되기 때문이다.

# 3. AI API — DALL·E와 Realtime Beta는 이번주 제거됐다

5월 12일 `dall-e-2`와 `dall-e-3`가 API에서 제거됐다. 같은 날 Realtime API의 Beta 인터페이스도 제거됐다. [공식 지원 종료 안내](https://developers.openai.com/api/docs/deprecations)에 포함된 내용이다.

이번주 금요일 기준으로는 앞으로 대비할 예정이라는 단계가 아니다. 아직 해당 모델과 Beta 인터페이스를 사용하는 경로가 있다면 현재 동작 여부와 전환을 확인해야한다.

## 저장소의 모델 이름 검색만으로 끝내지 말자

모델 이름이 소스 코드에 직접 들어있을 수도 있지만 환경 변수와 DB 설정, 관리자 화면과 오래된 배치에 남아있을 수도 있다. 실제 요청이 어떤 값을 사용했는지 연결해야한다.

예를 들어 메인 화면은 새 모델로 바꿨는데 재생성 버튼이나 야간 배치가 이전 설정을 사용할 수 있다. 코드가 배포됐다는 사실과 모든 호출 경로가 전환됐다는 사실은 다르다.

```text
API 의존성의 확인
코드·설정 → 배포된 값 → 실제 요청 → 오류와 사용 기록
```

대체 경로와 실패 후 재시도 설정도 살펴보자. 기본 모델을 바꿨더라도 fallback이 제거된 모델을 가리키면 일부 요청에서만 문제가 나타날 수 있다.

오래된 클라이언트와 장기 실행 프로세스가 설정을 언제 읽는지도 확인해야겠다. 서버의 환경 변수를 바꾼 뒤 기존 프로세스가 같은 상태로 계속 실행될 수 있기 때문이다.

## 이미지 모델 전환은 이름 변경 이상이다

OpenAI는 GPT Image 계열을 후속 선택지로 안내한다. 하지만 기존 요청에서 모델 이름만 바꾸면 모든 입력과 출력이 같은 계약을 유지한다고 가정해서는 안되겠다.

지원하는 크기와 입력 방식, 편집과 출력 형식, 비용과 결과 품질을 실제 사용하는 기능에서 비교해야한다. 현재 SDK와 공식 인터페이스의 필드도 함께 확인할 필요가 있다.

예를 들어 이미지 파일을 저장하는 코드와 사용자에게 URL을 반환하는 코드가 특정 응답 형태에 의존할 수 있다. 생성에 성공해도 후처리가 결과를 읽지 못하면 서비스는 실패한다.

```text
이미지 기능의 전환 범위
입력 준비 → 생성·편집 요청 → 응답 해석 → 파일 저장 → 화면 표시
```

새 모델에서 원래 이미지의 일부를 수정하는 기능도 따로 확인하면 좋겠다. 처음 생성한 결과가 좋아도 편집에서 유지해야할 요소가 달라질 수 있기 때문이다.

성공 사례와 함께 잘못된 입력과 실패 응답을 시험해야한다. 기존 오류 파서가 새 인터페이스의 오류를 정상 응답처럼 처리하지 않는지도 확인할 수 있다.

## 제거된 모델은 되돌림의 선택지가 아닐 수 있다

전환 계획을 세울때 “문제가 생기면 이전 모델로 돌아간다”는 설명은 현재 지원 상태와 맞아야한다. 이번주 제거된 모델을 실제 사용할 수 있는 fallback으로 남겨두면 대응 계획이 성립하지 않는다.

지원되는 다른 경로에서 어떤 기능을 제공할 수 있는지와 실패시 사용자에게 어떻게 안내할지를 정하는 편이 낫겠다. 단순 재시도로 해결되지 않는 오류를 구분하는것이다.

운영 기록에는 요청한 모델과 기능, 실패 유형을 남겨두면 좋겠다. 이전 모델을 가리키는 호출이 더이상 없는지 확인하는 근거가 된다.

## 큐에 저장된 요청과 재처리 경로도 확인하자

비동기 작업의 요청 본문에 모델 이름을 저장하는 서비스라면 코드 변경 뒤에도 이전 값이 큐에 남아있을 수 있다. 새 요청은 정상이지만 오래된 실패 작업을 재처리할때만 같은 오류가 반복되는식이다.

이 경우에는 작업의 생성 시점과 실제 실행 시점, 요청 형식의 버전을 함께 봐야한다. 모델 이름만 새 값으로 덮어쓰면 기존 입력의 의미와 옵션이 새 인터페이스에 맞는지 놓칠 수 있다.

재처리할 수 있는 요청과 사용자에게 다시 입력을 받아야하는 요청을 구분해두면 좋겠다. 운영 화면의 재시도 버튼도 현재 지원하는 API 계약을 사용하는지 확인하는것이다.

오래된 작업이 더이상 실행되지 않는지까지 확인하면 전환의 범위를 설명하기 쉽다. 메인 기능의 정상 동작과 과거 작업의 처리 가능성을 함께 보는 기준이 된다.

## Realtime은 세션과 이벤트의 계약을 확인하자

Beta에서 정식 인터페이스로 옮길때는 연결 성공만 확인해서는 부족하다. 세션 설정과 이벤트, 입력과 출력의 상태를 현재 인터페이스에 맞춰 확인해야한다.

음성 대화라면 발화 시작과 종료, 응답 재생과 중단, 도구 호출과 결과가 모두 연결된다. 실제 마이크와 재생 장치를 사용하는 사용자 흐름도 검증 대상이다.

사용자가 답변 중간에 말을 끊었을때 이전 응답이 다시 재생되는지, 도구가 실패했을때 대화가 이어지는지 같은 조건을 시험해볼 수 있다.

장기 연결에서는 네트워크 중단과 재연결도 중요하다. 새 세션을 만들었다는 사실과 이전 작업의 상태를 올바르게 이어갔다는 사실은 다르기 때문이다.

API의 종료 일정은 기능 개발과 별도로 관리하면 좋겠다. 새 기능이 없어도 의존 인터페이스의 상태가 바뀌면 운영 코드의 수정이 필요할 수 있다.

# 4. 코드 보안 — CodeQL은 Vercel 함수의 분석 범위를 넓혔다

5월 12일 [CodeQL 2.25.4](https://github.blog/changelog/2026-05-12-codeql-2-25-4-adds-swift-6-3-1-support-improvements-to-c-and-java-and-more/) 업데이트가 소개됐다. Vercel Serverless Functions의 보안 분석 지원과 여러 언어의 데이터 흐름 모델 개선이 포함된다.

JavaScript·TypeScript에서는 `@vercel/node`의 요청·응답 타입을 사용하는 핸들러를 인식하는 범위가 추가됐다. 분석 도구가 프레임워크의 입력 지점을 이해하는것이 탐지 범위와 연결된다는 사례다.

## 도구가 어떤 입력을 외부 데이터로 보는지 중요하다

정적 분석은 코드의 모든 줄을 같은 의미로 읽는것이 아니다. 외부에서 들어오는 값과 그 값이 전달되는 경로, 위험한 사용 지점을 모델링해야한다.

예를 들어 요청에서 읽은 값이 여러 함수를 거쳐 SQL이나 외부 요청, 명령 실행에 사용되는 흐름을 생각해보자. 중간의 래퍼와 검증을 어떻게 이해하는지에 따라 결과가 달라질 수 있다.

```text
데이터 흐름 분석에서 보는 연결
외부 입력 → 전달·변환 → 검증 → 민감한 사용 지점
```

이번 지원 확대가 모든 Vercel 애플리케이션의 모든 보안 문제를 찾는다는 의미는 아니다. 사용하는 핸들러와 언어, 프레임워크와 커스텀 래퍼가 분석 범위에 어떻게 들어오는지 확인해야한다.

분석 결과가 없다는 사실도 해석이 필요하다. 문제가 없어서인지, 필요한 파일과 언어를 분석하지 못해서인지 실행 로그와 설정을 함께 봐야한다.

## 정확도가 좋아져도 경고의 의미는 검토해야한다

도구가 지적한 경로에서는 실제 입력이 해당 위치까지 도달할 수 있는지 확인해야한다. 앞단의 인증과 타입 변환, 검증 조건이 영향을 줄 수 있다.

반대로 코드에 검증 함수가 있다고 그 함수가 모든 위험한 입력을 처리하는것도 아니다. 이름이 `sanitize`라는 이유만으로 안전하다고 판단할 수는 없겠다.

커스텀 데이터 흐름 모델과 barrier를 사용하는 경우에는 어떤 입력을 차단한다고 설명하는지 검토해야한다. 경고를 줄이기 위한 설정이 실제 문제까지 숨기지 않는지 확인하는것이다.

변경 전후에는 알고 있는 기준 사례를 분석해볼 수 있다. 탐지해야하는 코드와 정상 코드를 함께 두면 누락과 잘못된 경고의 차이를 설명하기 쉽다.

## 스캔 결과를 수정과 검증으로 이어가자

발견한 항목에는 발생 조건과 영향 범위, 수정 방향이 필요하다. 경고 목록만 쌓아두면 실제 서비스의 위험과 연결하기 어렵다.

우선순위는 점수 하나뿐 아니라 외부 입력의 도달 여부와 현재 노출, 사용 권한과 데이터의 중요도를 함께 보고 정할 수 있다.

수정 후에는 같은 분석을 다시 실행하고 실제 입력 경로의 테스트도 확인하면 좋겠다. 경고가 사라졌다는 사실과 정상 기능이 유지되는것은 서로 다른 근거다.

개인적으로는 보안 분석의 완료를 스캔 성공이 아니라 검토한 결과와 실제 수정의 적용까지 연결해서 보고싶다. 탐지 범위가 넓어질수록 처리할 결과의 의미도 명확해야겠다.

# 5. 이번주에는 지원 상태를 한곳에서 찾을 수 있게 하자

DB 패치와 API 제거, 분석 도구 개선은 모두 현재 시스템이 무엇에 의존하는지 알아야 적용할 수 있다. 버전과 설정이 흩어져있으면 공지가 나올때마다 처음부터 찾아야한다.

| 대상 | 남겨둘 정보 |
| --- | --- |
| DB | 인스턴스·확장·관리 도구 버전과 적용 기록 |
| 외부 API | 실제 모델·인터페이스와 호출 경로 |
| 음성 세션 | SDK와 이벤트 계약, 연결·중단 시험 |
| 보안 분석 | 대상 언어·프레임워크·규칙과 검토 결과 |

정보를 모으는 목적은 문서를 늘리는것이 아니다. 현재 영향과 수정할 위치를 빠르게 찾기 위한것이다. 실제 배포와 연결되는 기록이면 작은 목록으로 시작해도 도움이 된다.

변경 후에는 적용한 범위와 확인하지 못한 부분도 남겨두면 좋겠다. 누가 다음 검증을 이어가야할지 분명해지고, 이미 끝낸 작업을 반복해서 해석할 필요도 줄어든다.

# 마무리

이번주는 PostgreSQL 운영 서비스의 패치와 구형 AI API의 지원 종료를 먼저 확인해야할 주다. CodeQL의 분석 확대도 현재 사용하는 코드 경로에 어떻게 적용되는지 살펴볼만하다.

DB는 서버 외의 도구까지, API는 모델 이름 외의 요청·응답 계약까지 확인하면 좋겠다. 분석 도구의 결과도 실제 발생 조건과 수정 검증으로 이어가야한다.

개인적으로는 이번주에 지금 배포된 서비스가 실제로 호출하는 모델과 DB 버전을 다시 적어보려고 한다. 기능이 정상일때 이런 정보를 알아두는것이 변경에 대응하는 시간을 줄여주는것같다..


[2026.05.15 주간 개발 트렌드] PostgreSQL 보안 패치와 API 지원 종료

독자의 메모