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

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

# 이번주는 날짜와 검색, 음성을 다루는 기반이 넓어졌다

이번주에는 Node.js 26과 Gemini File Search의 멀티모달 지원, OpenAI의 실시간 음성 모델과 TypeScript Agents SDK 업데이트가 나왔다. 서버의 날짜 처리부터 문서 검색과 음성 대화까지 개발자가 연결할 수 있는 기능의 범위가 넓다.

새 API를 사용할 수 있다는것과 서비스의 데이터·작업 흐름이 바로 정리되는것은 다르다. 날짜의 의미와 검색의 근거, 음성 요청의 완료 상태를 명확하게 정해야 실제로 사용할 수 있다.

5월 4일부터 8일까지의 내용을 네가지로 나눠보았다.

| 분야 | 소식 | 먼저 확인할 부분 |
| --- | --- | --- |
| Runtime | Node.js 26 Current | Temporal과 런타임 호환성 |
| AI·검색 | Gemini File Search 확장 | 멀티모달 자료와 메타데이터·페이지 근거 |
| AI·음성 | Realtime 2·Translate·Whisper | 대화와 번역, 전사의 서로 다른 역할 |
| 개발 SDK | TypeScript Agents SDK 확대 | 모델과 하네스, 실행 환경의 연결 |

개인적으로는 이번주에 기능의 이름보다 입력과 결과가 어떤 의미를 갖는지부터 살펴보고 싶다.

# 1. Runtime — Node.js 26에서는 Temporal이 기본 활성화됐다

5월 5일 [Node.js 26.0.0](https://nodejs.org/en/blog/release/v26.0.0)이 나왔다. Temporal API 기본 활성화와 V8 14.6, Undici 8 적용, 오래된 API의 폐기·제거 등이 포함됐다.

이번주 기준 Node.js 26은 Current다. 새 메이저 정식 릴리스라는 의미와 장기 지원 버전이라는 의미는 구분해야한다. 운영 버전을 바로 바꾸기보다 프로젝트의 지원 조건과 호환성을 먼저 확인하면 좋겠다.

## 날짜만 필요한 값과 특정 시각을 나누자

날짜 처리는 문자열을 예쁘게 출력하는 문제만은 아니다. 생일이나 마감일처럼 날짜 자체가 필요한 값과, 로그가 기록된 순간처럼 특정 시각이 필요한 값은 의미가 다르다.

같은 날짜를 임의의 시간대의 자정으로 바꿔 저장하면 다른 지역에서 표시할때 날짜가 달라질 수 있다. 데이터가 원래 무엇을 표현하는지 먼저 정해야한다.

Temporal은 이런 개념을 서로 다른 타입으로 다룰 수 있게 한다. 예를 들어 [PlainDate](https://tc39.es/proposal-temporal/docs/plaindate.html)는 시간대와 독립적인 달력 날짜를 표현한다.

```javascript
const start = Temporal.PlainDate.from("2026-05-08");
const due = start.add({ days: 7 });

console.log(due.toString()); // 2026-05-15
```

이 예시는 달력 날짜에 일주일을 더하는 작업이다. 특정 지역에서 몇시에 실행할지를 정하는 예약 작업과는 필요한 정보가 다르다.

API와 DB에서도 날짜만 받는 필드와 시각을 받는 필드를 구분하면 좋겠다. 프론트엔드의 날짜 입력값을 서버에서 어떤 의미로 해석하는지까지 연결해야한다.

## 시간대는 표시 옵션만의 문제가 아니다

여러 지역에서 같은 순간을 다른 시각으로 보여주는 일과, 각 지역의 오전 9시에 작업을 실행하는 일은 다르다. 전자는 순간의 표현이고 후자는 지역의 달력·시간 규칙이 개입하는 일정이다.

```text
날짜·시간에서 먼저 정할 의미
달력 날짜 / 특정 순간 / 지역의 현지 시각 / 반복 일정
```

모든 값을 한 종류의 문자열로만 다루면 이 구분이 API 계약 밖으로 밀려날 수 있다. 저장된 값은 같아도 사용하는 코드가 다르게 해석하면 결과가 어긋난다.

서비스에 필요한 시간대와 표시 규칙을 정하고, 날짜가 바뀌는 경계와 지역 차이를 시험하면 좋겠다. 한국 시간만 사용하는 로컬 테스트에서는 다른 환경의 문제가 잘 보이지 않을 수 있다.

기존 Date 코드를 한 번에 모두 바꿀 필요는 없겠다. 의미가 명확한 새 기능이나 문제가 반복되는 날짜 계산부터 범위를 정해 비교하는 편이 낫겠다.

## 타입 지원과 실행 환경의 지원은 계속 구분해야한다

Node 26에서 Temporal을 사용할 수 있어도 브라우저와 다른 런타임이 같은 상태라는 의미는 아니다. 같은 TypeScript 코드를 서버와 클라이언트가 공유한다면 각각 확인해야한다.

빌드가 통과하는것은 타입과 문법을 검사한 결과다. 실제 실행 환경에 API가 있는지와는 다른 질문이므로 필요한 변환이나 호환 계층도 검토해야한다.

테스트 환경의 Node 버전과 실제 배포 버전이 다르면 검증 결과도 해석하기 어렵다. 로컬과 CI, 컨테이너와 관리형 런타임의 실제 버전을 함께 남겨두면 좋겠다.

## 새 메이저에서는 제거된 API도 살펴보자

26에는 일부 오래된 API의 제거도 포함된다. 직접 작성한 코드뿐 아니라 사용하는 라이브러리가 어떤 API에 의존하는지도 확인해야한다.

설치와 빌드, 테스트와 실제 요청을 나눠서 확인하면 문제의 위치를 찾기 쉽다. 네이티브 모듈이 있다면 해당 환경에서 설치와 로딩이 되는지도 별도 조건이다.

Undici가 바뀐만큼 HTTP 클라이언트를 사용하는 대표 경로도 살펴볼 수 있다. 정상 요청과 오류, 스트리밍과 취소처럼 실제 서비스에서 사용하는 기능을 기준으로 확인하면 좋겠다.

개인적으로는 Current를 다음 운영 환경을 준비하는 시험 대상으로 보고싶다. 새 기능의 장점과 현재 의존성의 제약을 미리 알고 전환 계획에 반영할 수 있기 때문이다.

# 2. AI·검색 — File Search가 텍스트와 이미지를 함께 다룬다

5월 5일 [Gemini API File Search](https://blog.google/innovation-and-ai/technology/developers-tools/expanded-gemini-api-file-search-multimodal-rag/)에 멀티모달 지원과 사용자 정의 메타데이터, 페이지 단위 인용이 추가됐다. 문서의 텍스트와 시각 정보를 함께 검색하고 근거를 더 구체적으로 연결하는 변화다.

임베딩 모델을 직접 호출해 인덱스를 관리하는 방식과 관리형 File Search를 사용하는 방식은 담당하는 범위가 다르다. 검색 파이프라인의 어느 부분을 직접 운영할지 나눠서 볼 필요가 있다.

## 표와 그림에 있는 정보도 검색 기준이 된다

문서에는 본문에 적히지 않은 정보가 표와 도식, 이미지에 들어있는 경우가 많다. 텍스트만 추출하면 범례와 위치 관계, 화면 예시의 의미가 충분히 남지 않을 수 있다.

멀티모달 검색은 이런 자료를 다루는 선택지를 넓힌다. 다만 우리 문서에서 필요한 내용을 실제로 찾는지는 대표 질문으로 비교해야한다.

예를 들어 매뉴얼의 특정 경고 화면을 찾는 질문과 표의 조건에 맞는 수치를 찾는 질문은 다르다. 그림을 잘 찾는 결과와 표의 행·열을 정확히 이해하는 결과를 같은 점수로만 평가하기 어렵다.

```text
검색에서 확인할 연결
질문 → 관련 자료 → 원본 페이지 → 필요한 정보 → 답변
```

최종 답변이 자연스럽다는 사실만으로 검색 근거가 정확한것은 아니다. 생성 모델이 자료의 빈 부분을 채우는 경우를 구분하려면 검색 결과와 답변을 따로 확인하는게 좋겠다.

## 메타데이터는 검색 범위를 설명하는 정보다

같은 주제의 문서라도 제품과 버전, 작성 시점과 대상 사용자가 다를 수 있다. 메타데이터를 사용하면 어떤 자료 안에서 검색해야하는지 표현하기 쉬워진다.

예를 들어 제품 매뉴얼을 검색할때 현재 제품 버전과 언어를 먼저 제한할 수 있다. 제목이 비슷한 이전 자료가 결과에 섞이는 문제를 줄일 여지가 생긴다.

하지만 메타데이터를 넣는것과 값의 정확성을 유지하는것은 다른 작업이다. 문서를 갱신했는데 버전 값이 그대로면 필터가 잘 동작해도 잘못된 자료를 찾을 수 있다.

필드의 이름과 허용 값, 기본값과 갱신 책임을 정해두면 좋겠다. 검색 결과를 해석하는 규칙이 여러 저장소와 업로드 경로에서 같아야한다.

접근 권한도 별도로 보장해야한다. 사용자가 임의로 필터 값을 바꿀 수 있는 API라면 그 값만으로 자료의 접근 범위를 결정해서는 안되겠다.

## 페이지 인용은 답변을 확인하는 출발점이다

PDF 전체의 이름만 알려주는것보다 실제 페이지로 이동할 수 있으면 사용자가 근거를 찾기 쉽다. 답변의 문장과 원본의 표·그림을 비교할 수 있기 때문이다.

다만 페이지가 연결됐다는 사실과 그 페이지가 주장한 내용을 실제로 뒷받침한다는 사실은 다르다. 질문에 필요한 범위와 버전이 맞는지도 확인해야한다.

문서가 변경되면 페이지 번호가 달라질 수 있으니 원본의 식별 정보와 버전도 함께 연결하면 좋겠다. 오래된 답변이 나중에 다른 페이지를 가리키지 않도록 관리할 필요가 있다.

관련 자료가 없는 질문도 시험해보고 싶다. 모든 요청에 억지로 페이지를 붙이는것보다 근거가 부족한 상태를 정확히 알려주는 결과가 유용하다.

# 3. AI·음성 — 대화와 번역, 전사의 모델이 나뉜다

5월 7일 [GPT-Realtime-2](https://developers.openai.com/api/docs/models/gpt-realtime-2)가 공개됐다. 추론 수준을 조정할 수 있는 실시간 음성 대화 모델이다. 함께 나온 [Realtime-Translate](https://developers.openai.com/api/docs/models/gpt-realtime-translate)는 실시간 번역, [Realtime-Whisper](https://developers.openai.com/api/docs/models/gpt-realtime-whisper)는 실시간 음성 전사를 담당한다.

음성을 입력으로 받는다고 세 기능이 같은 역할은 아니다. 사용자의 말을 이해하고 작업하는 Agent와 번역, 자막을 만드는 시스템은 필요한 출력과 검증이 다르다.

## 무엇을 반환해야하는지부터 정하자

대화형 Agent라면 질문을 이해한 뒤 도구를 호출하고 답을 말할 수 있어야한다. 번역에서는 원문의 의미를 대상 언어로 전달하는것이 중심이고, 전사에서는 들린 내용을 텍스트로 정확하게 표현하는것이 중요하다.

| 목적 | 확인할 결과 |
| --- | --- |
| 음성 Agent | 요청 이해와 도구 실행, 결과 설명 |
| 실시간 번역 | 의미와 대상 언어, 지연과 문장 연결 |
| 실시간 전사 | 내용과 전문 용어, 부분·확정 텍스트 |

서비스가 실제로 필요한 기능을 정하면 모델과 엔드포인트를 선택하기 쉽다. 단순 자막이 필요한데 대화의 판단과 행동까지 같은 경로에 넣을 필요는 없을 수 있다.

반대로 전사 결과가 있다는 이유만으로 사용자의 의도에 맞는 작업이 완료되는것도 아니다. 텍스트를 해석하고 실제 시스템을 실행하는 계층이 별도로 필요하다.

## 추론을 늘릴때는 대화의 대기 시간도 보자

복잡한 요청에서는 더 깊은 판단이 도움이 될 수 있다. 하지만 음성 대화에서는 응답이 시작되기 전의 침묵도 사용자가 체감하는 지연이다.

모든 발화에 같은 연산을 사용하기보다 단순한 안내와 여러 조건을 비교하는 작업을 나눠 평가하면 좋겠다. 판단이 필요한 정도와 허용 가능한 대기 시간을 함께 정하는것이다.

```text
음성 대화의 전체 지연
입력 처리 + 발화 종료 판단 + 모델 판단 + 도구 대기 + 음성 출력
```

모델 응답만 빨라도 외부 조회가 오래 걸리면 전체 경험은 느릴 수 있다. 현재 어떤 작업을 기다리는지 사용자에게 알리는 방식도 서비스 설계에 포함해야한다.

성능 비교에서는 짧은 인사와 복잡한 요청, 도구 호출이 있는 요청을 나눠보면 좋겠다. 서로 다른 작업을 섞은 평균 하나로는 병목을 알기 어렵다.

## 사용자가 말을 끊었을때의 상태를 정하자

음성에서는 사용자가 답변 중간에 새 조건을 말하거나 이전 요청을 취소할 수 있다. 출력 음성을 멈추는것과 이미 시작한 외부 작업을 중단하는것은 다르다.

예를 들어 조회 결과를 말하는 중이라면 새 질문으로 전환하기 쉬울 수 있다. 반면 상태를 바꾸는 작업이 이미 완료됐다면 사용자에게 실제 결과를 알려줘야한다.

중단과 재개를 시험할때는 대화 기록과 도구 상태를 함께 확인하면 좋겠다. 아직 실행중인 요청을 완료된 사실로 남기거나 이미 수행한 변경을 다시 실행하지 않도록 하는것이다.

전사에서도 부분 텍스트와 확정 텍스트를 구분해야한다. 아직 바뀔 수 있는 인식 결과를 최종 명령으로 바로 처리하면 사용자의 실제 발화와 다른 행동이 나올 수 있다.

개인적으로는 자연스러운 목소리만큼 이런 상태 전환이 중요해보인다. 음성 UI는 사용자가 화면의 진행 상태를 계속 읽고 있지 않을 수 있기 때문이다.

# 4. 개발 SDK — TypeScript에서도 Sandbox Agent와 하네스를 다룬다

5월 6일 [OpenAI Agents SDK 업데이트](https://developers.openai.com/api/docs/changelog)가 TypeScript에도 적용됐다. Sandbox Agent와 오픈소스 하네스를 사용할 수 있는 범위가 넓어진 내용이다.

TypeScript로 AI 백엔드를 만드는 팀은 모델 호출 외에 실행과 도구, 작업 상태를 어떤 방식으로 연결할지 비교할 수 있게 됐다.

## SDK와 실행 환경은 서로 다른 구성 요소다

SDK는 Agent의 반복 실행과 도구 연결을 구성하는데 도움을 준다. 실제 코드가 실행되는 환경과 파일의 수명, 네트워크 접근은 별도로 정해야하는 영역이다.

```text
TypeScript Agent 서비스의 연결
요청 API → Agent 하네스 → 모델·도구 → 실행 환경 → 결과와 기록
```

타입이 맞는 도구 정의를 작성했다고 실제 실행 결과의 의미까지 보장되는것은 아니다. 입력 검증과 권한, 실패 상태와 재시도는 서비스의 계약으로 구현해야한다.

예를 들어 도구가 빈 배열을 반환할때 자료가 없는것인지 조회에 실패한것인지 나눠야한다. 모델이 그 차이를 알아야 다음 질문과 설명을 올바르게 선택할 수 있다.

## 하네스를 바꾼 결과도 검증해야한다

오픈소스 하네스를 수정하면 프로젝트의 요구에 맞게 문맥과 도구 실행, 종료 조건을 조정할 수 있다. 대신 기본 동작과 달라진 부분이 어디인지 기록해야한다.

정상 완료 외에 호출 한도와 시간 초과, 사용자의 취소가 어떤 결과로 반환되는지 시험하면 좋겠다. 모두 같은 완료 상태로 반환하면 호출하는 화면과 서버가 결과를 잘못 해석할 수 있다.

작업 기록은 모델의 문장뿐 아니라 실제 도구 결과와 변경 내역을 함께 보관하면 유용하다. 이후 재개하거나 검토할때 근거로 사용할 수 있기 때문이다.

실행 환경에 파일을 전달한다면 필요한 입력만 제공하고 결과 파일을 어떻게 가져올지도 정해야겠다. Sandbox 안에서 생성한 결과가 서비스에 저장됐는지는 별도로 확인해야한다.

# 5. 이번주에는 데이터의 의미와 작업 상태를 같이 정하자

네가지 소식은 서로 다른 기능이지만 잘못 섞기 쉬운 구분이 있다는 공통점이 있다. 날짜와 순간, 관련 페이지와 검증된 근거, 음성 출력과 실제 작업 완료, SDK와 실행 환경은 같은것이 아니다.

| 기능 | 서비스에서 명시할 계약 |
| --- | --- |
| 날짜 API | 날짜와 시각, 시간대의 의미 |
| File Search | 자료 버전과 접근 범위, 근거 위치 |
| 음성 API | 부분·확정 입력과 실행·취소 상태 |
| Agent SDK | 도구의 결과와 종료 조건, 파일 수명 |

이 구분을 먼저 정하면 도구를 바꿀때도 무엇을 유지해야하는지 알기 쉽다. 새 모델이나 런타임의 결과를 기존 계약과 비교할 수 있기 때문이다.

작은 사례부터 검증하되 실패 조건도 함께 넣고 싶다. 잘못된 날짜와 자료가 없는 질문, 중간에 끊긴 음성과 실패한 도구 호출은 정상 데모에서 보이지 않는 문제를 보여줄 수 있다.

# 마무리

이번주는 Node.js 26의 Temporal과 멀티모달 검색, 실시간 음성 모델과 TypeScript Agent 실행 도구가 함께 나왔다. 입력과 작업의 종류가 다양해질수록 데이터의 의미를 명확하게 정하는 일이 중요해진다.

Node 26은 Current로 호환성을 시험하고, 검색은 원본 페이지와 답변을 대조해보면 좋겠다. 음성은 중단과 확정 상태, Agent SDK는 실제 실행 결과와 종료 조건을 함께 확인해야겠다.

개인적으로는 이번주에 날짜와 시각을 같은 필드로 다루고 있지는 않은지부터 살펴보려고 한다. 새로운 API의 장점도 현재 데이터가 무엇을 뜻하는지 알아야 제대로 사용할 수 있는것같다..


[2026.05.08 주간 개발 트렌드] Node.js 26과 멀티모달 검색, 실시간 음성 API

독자의 메모