[2026.03.06 주간 개발 트렌드] GPT-5.4와 TypeScript 6 RC, Codex Windows 앱

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

# 이번주는 데이터 계층의 패치와 AI 도구의 확장을 같이 봤다

2월의 마지막 주다. 이번주에는 PostgreSQL의 후속 수정과 pgvector 보안 업데이트가 나왔고, AI 개발 도구 쪽에서는 Copilot CLI가 GA에 도달했다. GPT-5.3-Codex의 API 제공과 새로운 이미지 모델 소식도 함께 나왔다.

같은 AI 서비스 안에서도 모델을 사용하는 부분과 데이터를 저장하고 검색하는 부분은 역할이 다르다. 새 모델을 붙이는 작업을 하면서 DB와 확장의 패치 현황도 같이 확인해야할 주라고 생각한다.

2월 23일부터 27일까지의 내용을 다섯가지로 나눠보았다.

| 분야 | 소식 | 구분해서 확인할 부분 |
| --- | --- | --- |
| Database | PostgreSQL 후속 수정 | 지난 업데이트의 회귀 해결과 추가 절차 |
| 벡터 검색 | pgvector 0.8.2 | 병렬 HNSW 인덱스 생성의 보안 수정 |
| 개발 도구 | Copilot CLI GA | 터미널에서 계획·수정·검증하는 흐름 |
| AI API | GPT-5.3-Codex | 제품 출시와 API 제공의 서로 다른 시점 |
| 이미지 | Nano Banana 2 | 생성과 편집의 반복, 실제 결과 검토 |

# 1. Database — PostgreSQL의 후속 수정이 나왔다

2월 26일 [PostgreSQL 18.3, 17.9, 16.13, 15.17, 14.22](https://www.postgresql.org/about/news/postgresql-183-179-1613-1517-and-1422-released-3246/)가 공개됐다. 지난주 예고한 비정기 릴리스가 이번주에 실제로 제공된것이다.

2월 12일 업데이트 이후 보고된 비ASCII 컬럼 값의 `substring()` 오류와 standby가 멈추는 문제 등을 수정했다. `pg_trgm`의 함수 문제와 일부 JSON 함수의 속성 수정도 포함된다.

## 이번주에는 적용 후 같은 경로를 다시 확인하자

지난주에는 영향을 받는 환경과 재현 조건을 정리할 단계였다면, 이제는 후속 버전을 적용한 뒤 이전 오류가 사라졌는지 비교할 수 있다.

문자열 문제는 실제 컬럼에서 값을 가져오는 쿼리로 확인해야한다. 복제 문제는 primary에서 간단한 조회를 하는것만으로 확인할 수 없으니 standby 상태와 읽기 요청도 함께 봐야겠다.

```text
수정 전의 재현 조건
버전 + 데이터 출처 + 쿼리 + 복제 구성
                 ↓
수정 후 같은 조건에서 결과와 로그 비교
```

패치 후 오류가 안보인다는 설명에도 조건이 필요하다. 같은 작업을 다시 실행하지 않았거나 요청이 다른 인스턴스로 우회됐다면 문제가 해결됐다는 근거로 삼기 어렵다.

예를 들어 읽기 복제본이 정상으로 돌아왔는지 확인할때는 애플리케이션이 그 복제본으로 다시 요청을 보내는지도 봐야한다. DB의 상태와 서비스의 실제 사용 경로를 연결하는것이다.

## 서버 바이너리 외에 추가 절차도 확인해야한다

이번 업데이트는 같은 메이저 버전 안에서 적용하는 누적 마이너 릴리스다. 일반적으로 dump·reload나 `pg_upgrade`가 필요하지 않지만, 릴리스별 추가 절차까지 없어지는것은 아니다.

특히 PostgreSQL 18.0~18.2에서 올라오는 경우 `json_strip_nulls()`와 `jsonb_strip_nulls()`의 함수 속성을 바로잡는 절차가 안내되어 있다. 대상 DB와 template DB도 안내 범위에 포함된다.

운영 카탈로그를 수정하는 SQL을 맥락 없이 복사해서 실행하기보다 현재 메이저 버전과 적용 이력을 먼저 확인해야겠다. 관리형 서비스라면 제공자가 수행하는 부분과 사용자가 해야할 부분도 구분해야한다.

중간 업데이트를 건너뛰었다면 앞선 릴리스의 사후 작업이 있는지도 살펴보자. 최종 버전 숫자가 같더라도 거기까지 올라온 경로에 따라 확인할 항목이 남아있을 수 있다.

# 2. 벡터 검색 — pgvector의 인덱스 생성 경로도 패치 대상이다

같은 2월 26일 [pgvector 0.8.2 보안 업데이트](https://www.postgresql.org/about/news/pgvector-082-released-3245/)도 안내됐다. 병렬 HNSW 인덱스 생성 과정의 버퍼 오버플로 문제인 CVE-2026-3172를 수정했다.

공지에 따르면 다른 relation의 민감한 데이터가 노출되거나 DB 서버가 중단될 수 있는 문제다. PostgreSQL로 벡터 검색을 운영한다면 DB 본체와 별도로 확장 버전도 확인해야겠다.

## 검색 API만 정상이라고 끝내기 어렵다

벡터 검색을 쓰는 서비스에서는 질문을 보내고 비슷한 문서를 찾는 경로를 먼저 떠올리기 쉽다. 하지만 인덱스를 만드는 작업은 평소 조회와 다른 실행 경로다.

새 환경을 구성하거나 많은 데이터를 적재한 뒤 인덱스를 생성하는 작업, 데이터와 인덱스를 다시 준비하는 운영 작업도 살펴봐야한다. 이번 보안 수정의 대상은 특히 병렬 HNSW 생성 경로다.

```text
벡터 검색 운영에서 볼 범위
데이터 적재 → 인덱스 생성 → 검색 → 변경 반영 → 유지보수
```

검색 응답의 정확도만 평가하면 이중 일부만 확인하게 된다. 운영 기록에는 인덱스가 어떤 방식으로 생성되는지와 누가 그 작업을 실행할 수 있는지도 함께 정리하면 좋겠다.

## DB 버전과 확장 버전은 따로 적어두자

PostgreSQL 본체를 업데이트했다고 pgvector의 버전까지 자동으로 원하는 상태가 됐다고 가정하면 안되겠다. 배포 방식에 따라 확장 패키지와 DB에 등록된 확장의 갱신 절차를 따로 확인해야한다.

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

```sql
SELECT extname, extversion
FROM pg_extension
WHERE extname = 'vector';
```

이 결과는 현재 DB에 대한 정보다. 다른 DB와 인스턴스도 같은 상태인지는 따로 확인해야한다. 컨테이너 이미지나 관리형 서비스에서 제공하는 확장 빌드도 함께 비교할 필요가 있다.

업데이트 명령 하나를 모든 환경의 공통 절차로 삼기보다는 지원되는 설치 방식과 확장 업데이트 순서를 확인하는게 좋겠다. 운영에서 실제로 사용할 버전이 준비되어 있어야 DB 안의 갱신도 계획할 수 있다.

적용 후에는 대표 벡터 질의의 결과와 실행 계획, 응답 시간을 비교해보자. 기능이 동작하는지와 기존에 기대한 검색 범위와 성능이 유지되는지를 나눠서 확인하는것이다.

## RAG 품질과 데이터 계층의 안정성은 서로 다른 문제다

검색 결과가 답변에 도움이 되는지와 DB가 안전하고 안정적으로 동작하는지는 다른 기준이다. 임베딩 모델을 바꾸는 평가만 진행하면 저장과 인덱스 계층의 수정은 놓칠 수 있다.

반대로 DB 패치를 적용했다고 검색 품질의 문제가 해결되는것도 아니다. 문서 분할과 필터 조건, 임베딩과 재정렬의 역할은 따로 확인해야한다.

# 3. 개발 도구 — GitHub Copilot CLI가 GA에 도달했다

2월 25일 [GitHub Copilot CLI의 정식 제공](https://github.blog/changelog/2026-02-25-github-copilot-cli-is-now-generally-available/)이 발표됐다. 터미널에서 계획을 세우고 파일을 수정하며 명령과 테스트를 실행하는 코딩 Agent다.

MCP와 Skills, 커스텀 Agent를 통한 확장도 지원한다. 작업 계획과 diff·리뷰를 터미널에서 이어갈 수 있다는 점에서 단순한 명령어 설명 도구보다 담당하는 범위가 넓다.

## 터미널은 이미 개발 작업이 모이는 곳이다

터미널에는 빌드와 테스트, Git과 패키지 관리 명령이 모여있다. 여기에 Agent가 들어오면 코드 작성과 실행 결과 확인 사이의 왕복을 줄일 수 있다.

예를 들어 실패하는 테스트를 고치는 작업이라면 테스트 출력을 읽고 관련 파일을 찾고 수정한 뒤 다시 실행하는 흐름을 같은 자리에서 이어갈 수 있다.

```text
요청 이해 → 관련 파일 탐색 → 수정
                      ↑       ↓
               결과 판단 ← 테스트 실행
```

여기서 중요한것은 명령을 많이 실행하는 능력보다 결과를 다음 판단에 반영하는 능력이다. 같은 실패를 설명 없이 반복하거나 테스트를 무시하고 끝내면 작업이 완료됐다고 보기 어렵다.

작업을 맡길때는 수정 가능한 범위와 원하는 결과를 정해두면 좋겠다. “테스트를 통과시켜줘”만 주면 테스트 자체를 약하게 바꿔버리는 결과도 구분하기 어렵다.

## MCP와 Skills, 커스텀 Agent의 역할을 나눠보자

세 기능이 모두 확장 수단이라고 해서 같은 역할은 아니다. 도구와 데이터의 연결, 반복 작업의 절차, 특정 역할에 맞춘 지시를 나눠서 이해하면 구성하기 쉽다.

MCP는 외부 도구와 상태에 접근하는 연결로 볼 수 있고, Skills는 반복하는 작업의 절차와 지식을 제공하는데 사용할 수 있다. 커스텀 Agent에는 역할에 맞는 도구와 지시를 묶을 수 있다.

예를 들어 릴리스 확인 작업이라면 저장소와 이슈의 정보를 읽는 연결, 변경 내역을 확인하는 절차, 검토 담당 역할을 구분할 수 있겠다.

이름을 많이 붙이는것보다 실제로 중복되는 지시가 없는지 확인하는게 중요하다. 여러 설정이 서로 다른 테스트 명령을 안내하면 Agent가 어느 절차를 따라야할지 불명확해진다.

## 수정 후에는 diff와 실제 결과를 연결하자

도구가 제공하는 리뷰와 diff는 검토의 출발점이다. 요청과 관계없는 파일이 바뀌었는지, 기존 계약을 바꿨는지, 테스트가 실제 문제를 확인하는지 살펴봐야한다.

검토할때는 파일별 목록만 보기보다 하나의 사용자 흐름을 따라가면 좋겠다. 입력에서 API와 DB, 응답과 화면까지 요구사항이 연결되는지 보는것이다.

Agent가 남긴 마지막 설명도 변경 내역과 비교해보자. 실행한 명령과 결과, 확인하지 못한 범위가 정확해야 다음 작업으로 이어가기 쉽다.

# 4. AI API — GPT-5.3-Codex를 직접 연결할 수 있게 됐다

2월 24일 [GPT-5.3-Codex가 Responses API에 제공](https://developers.openai.com/api/docs/changelog)됐다. 이달 초 Codex 제품에서 공개된 모델을 이제 자체 API 통합의 선택지로 볼 수 있게 됐다.

2월 5일 모델 공개와 이번주 API 제공은 다른 사건이다. 제품을 통해 사용하는것과 우리 서비스의 코드에서 호출하는것은 접근 방식과 구현 범위가 다르기 때문이다.

## 모델 호출과 완성된 개발 환경을 구분하자

코딩 모델을 API로 호출할 수 있다고 제품의 작업 환경이 자동으로 함께 생기는것은 아니다. 저장소를 어디서 읽고 명령을 어디서 실행할지, 결과를 어떻게 보관할지는 통합하는 시스템의 역할이다.

예를 들어 사내 저장소의 오류를 수정하는 서비스를 만든다면 모델 외에도 작업 공간과 의존성 설치, 테스트 실행과 변경 검토가 필요하다.

```text
자체 코딩 Agent에 필요한 연결
모델 ↔ 도구 호출 ↔ 작업 공간 ↔ 실행 결과 ↔ 변경 검토
```

모델이 파일을 수정할 계획을 제안하는것과 실제 파일이 바뀐것도 구분해야한다. 각 단계가 남기는 상태를 확인할 수 있어야 긴 작업이 어디까지 진행됐는지 설명할 수 있다.

## 실패 이후의 상태도 설계에 포함하자

긴 작업에서는 모델 응답보다 테스트나 외부 도구를 기다리는 시간이 더 길 수 있다. 요청이 중단됐을때 이미 파일을 수정했는지, 명령이 아직 실행중인지 알 수 있어야한다.

작업 상태를 단순한 성공과 실패만으로 표현하면 중간 결과를 잃기 쉽다. 준비중인지, 도구 실행을 기다리는지, 검증이 실패했는지 구분하면 다시 시작할 위치도 정하기 쉽다.

재시도 역시 주의해서 설계할 부분이다. 조회를 다시 하는것과 외부 상태를 바꾸는 명령을 다시 실행하는것은 결과가 다르다. 이미 완료한 변경을 중복해서 수행하지 않도록 작업 기록이 필요하다.

완료 조건에는 코드 생성 외에 관련 검증과 변경 내역을 포함하고 싶다. 출력된 설명만 저장하는것보다 실제 diff와 명령 결과를 함께 남기면 검토와 재현에 도움이 되겠다.

## 기존 자동화와 비교할 단위부터 정하자

API를 통해 연결하는 목적은 제품과 같은 화면을 다시 만드는것만은 아닐것이다. 사내 절차나 특수한 도구, 특정 저장소의 규칙과 결합할 수 있다는 점을 생각해볼 수 있다.

다만 단순한 포맷 변경이나 정해진 명령 실행은 기존 스크립트가 더 명확할 수 있다. 판단이 필요한 부분과 이미 규칙이 정해진 부분을 나누면 모델을 배치할 위치도 보인다.

예를 들어 실패 원인을 찾고 수정 방향을 선택하는 과정에는 모델을 사용하더라도, 최종 검증 명령과 결과 수집은 정해진 절차로 실행할 수 있다. 판단과 반복 실행의 역할을 나눠보는것이다.

# 5. 이미지 — Nano Banana 2는 빠른 생성과 편집을 강조했다

2월 26일 [Nano Banana 2](https://blog.google/innovation-and-ai/technology/ai/nano-banana-2/)가 공개됐다. 모델 이름은 Gemini 3.1 Flash Image이며, Google은 Pro 계열의 기능과 Flash의 속도를 결합한 이미지 생성·편집을 소개했다.

텍스트 표현과 피사체 일관성, 다양한 비율과 해상도 지원도 강조했다. Gemini 앱 등으로 제공 범위가 넓어지고, AI Studio와 Gemini API·Vertex AI에서는 Preview로 안내됐다.

## 이미지 작업은 반복 수정의 품질도 중요하다

한장의 결과가 좋아보이는것과 여러번 수정해도 의도한 부분이 유지되는것은 다른 문제다. 제목만 바꾸고 싶었는데 구도와 색, 인물의 모습까지 함께 달라지면 다시 손봐야한다.

따라서 평가할때는 처음 생성한 이미지와 후속 편집 결과를 함께 보면 좋겠다. 바꿔야할 요소와 유지할 요소를 나눠 요청하고 실제 결과가 그 구분을 지키는지 확인하는것이다.

예를 들어 블로그 썸네일이라면 제목이 들어갈 여백과 작은 화면에서의 가독성, 시리즈 안에서의 일관성을 확인할 수 있다. 큰 원본에서는 괜찮아도 목록 크기로 줄이면 핵심이 안보일 수 있다.

## 이미지 안의 글자와 정보는 따로 읽어보자

텍스트 표현의 개선은 반가운 부분이다. 하지만 문장이 들어갔다고 맞춤법과 숫자, 단위와 도표 관계까지 모두 맞는다고 가정하면 안되겠다.

개발 문서용 이미지라면 라이브러리 이름과 명령, 버전 숫자를 실제로 읽어봐야한다. 인포그래픽에서는 화살표 방향이나 비교 항목의 위치도 의미를 바꿀 수 있다.

특히 데이터 시각화는 원본 값과 결과를 대조해야한다. 보기 좋은 막대와 곡선이 있어도 값의 비율과 축이 틀리면 내용을 잘못 전달하게 된다.

정확한 수치와 코드를 전달하는 목적이라면 편집 가능한 표와 코드 블록을 함께 사용하는 방법도 있겠다. 이미지가 설명을 돕는 역할과 정보 자체를 전달하는 역할을 구분하는것이다.

이미지 모델이 빨라질수록 생성 뒤 검토하는 과정도 작업 흐름에 포함해야겠다. 결과를 실제 사용할 크기와 위치에 넣어보면 생성 화면에서 놓친 문제를 찾기 쉽다.

# 6. 이번주 적용 순서는 서비스의 영향으로 정하자

소식이 많을때는 발표 순서대로 모든 도구를 적용하기 어렵다. 개인적으로는 현재 운영에 영향을 주는 패치와 새 도구의 평가를 나눠 우선순위를 잡고싶다.

PostgreSQL과 pgvector는 현재 버전과 구성, 영향을 받는 경로부터 확인한다. Copilot CLI와 Codex API는 작은 개발 작업으로 연결과 검증을 시험하고, 이미지 모델은 실제 사용 목적에 맞춰 결과를 비교하는식이다.

| 작업 | 남겨둘 결과 |
| --- | --- |
| PostgreSQL 패치 | 적용 버전, 추가 절차, 기존 오류 재확인 |
| pgvector 업데이트 | 확장 버전과 설치 상태, 검색·인덱스 작업 확인 |
| 터미널 Agent 시험 | 요구사항, diff, 실행한 검증과 결과 |
| API 통합 시험 | 작업 상태, 도구 결과, 재시도와 완료 조건 |
| 이미지 모델 비교 | 원본 요청, 수정 조건, 실제 크기의 최종 결과 |

새 도구를 연결할때 기존에 잘 동작하던 작은 기준 사례를 남겨두는것도 좋겠다. 검색 결과와 API 계약, 폼의 사용자 흐름처럼 변경 전후를 비교할 기준이 있으면 문제를 좁히기 쉽다.

# 마무리

이번주는 AI 도구의 사용 위치가 터미널과 API, 이미지 작업까지 넓어지는 흐름이 눈에 띄었다. 동시에 그 도구와 서비스를 받치는 DB·벡터 검색 계층의 패치도 함께 나왔다.

PostgreSQL의 후속 수정은 적용 후 같은 실패 경로를 다시 확인하고, pgvector는 본체와 구분해서 확장 상태를 점검해야겠다. 새 Agent 도구는 생성한 코드와 실행 결과를 함께 보는 방식으로 시험하면 좋을것같다.

2월을 정리하면서 개인적으로 남는 기준은 도구의 이름보다 작업의 끝을 확인하는것이다. 이번주에도 무엇을 연결했는지만큼 어떤 결과까지 확인했는지 기록해봐야겠다..


[2026.02.27 주간 개발 트렌드] PostgreSQL·pgvector 패치와 터미널 Agent, 이미지 모델

독자의 메모