[2026.02.20 주간 개발 트렌드] Sonnet 4.6과 Gemini 3.1 Pro, PostgreSQL 후속 패치 예고

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

# 이번주는 새로운 기능과 전환 준비를 같이 봐야겠다

이번주에는 TypeScript의 다음 세대 준비와 PostgreSQL의 보안 업데이트, AI가 개발 환경을 이해하는 방식에 대한 소식이 나왔다. Gemini의 추론 모드도 과학과 엔지니어링 문제를 중심으로 업데이트됐다.

이름만 보면 전부 버전을 올리고 새 모델을 사용하면 될것같지만 실제로 확인할 부분은 조금씩 다르다. Beta를 시험하는 일과 운영 DB를 패치하는 일은 같은 기준으로 처리하기 어렵다.

2월 9일부터 13일까지의 내용을 네가지 주제로 나눠보았다.

| 분야 | 이번주 소식 | 먼저 확인할 부분 |
| --- | --- | --- |
| TypeScript | 6.0 Beta | 설정 변화와 다음 컴파일러를 위한 준비 |
| Database | PostgreSQL 정기 업데이트 | 보안 수정, 확장과 운영 구성 |
| Frontend | Next.js의 Agent 지원 방향 | 코드와 실행 상태를 연결하는 방법 |
| AI | Gemini 3 Deep Think 업데이트 | 추론이 필요한 문제와 접근 조건 |

개인적으로 이번주에는 무엇이 새로 생겼는지와 함께 지금 우리 프로젝트에서 어디까지 적용할 수 있는지를 구분하는게 중요해보인다.

# 1. TypeScript — 6.0 Beta는 다음 세대를 위한 연결 단계다

2월 11일 [TypeScript 6.0 Beta](https://devblogs.microsoft.com/typescript/announcing-typescript-6-0-beta/)가 공개됐다. 현재 JavaScript 기반 컴파일러에서 앞으로의 Go 기반 TypeScript 7로 넘어가기 위한 연결 단계라는 설명이 눈에 띈다.

여기서 6.0 자체가 Go로 바뀌었다고 이해하면 안된다. 이번 Beta는 기존 기반 위에서 설정과 동작을 정리하는 릴리스다. 네이티브 컴파일러에 대한 기대와 지금 설치해서 확인할 버전은 나눠서 봐야한다.

## 옵션을 생략한 프로젝트의 의미가 달라질 수 있다

이번 변경에는 기본값 조정이 포함된다. `strict`가 기본적으로 켜지고, `types`는 빈 배열을 기본으로 삼는다. `rootDir`도 tsconfig 위치를 기준으로 정해지는 방향으로 바뀐다.

기존 설정에 명시한 값과 기본값에 맡긴 값의 차이를 먼저 확인하면 좋겠다. 파일에 옵션이 없다는것은 해당 옵션을 사용하지 않는다는 의미가 아니다. 설치한 컴파일러가 제공하는 기본 동작을 사용한다는 의미이기 때문이다.

예를 들어 서버 코드에서 Node 전역 타입이 필요하다면 의도를 명시할 수 있다.

```json
{
  "compilerOptions": {
    "strict": true,
    "types": ["node"],
    "rootDir": "./src"
  },
  "include": ["src/**/*.ts"]
}
```

또한 `types`는 전역으로 포함할 타입 패키지의 범위와 관련된다. 빈 배열이라고 일반적인 모듈 import의 타입까지 전부 사라진다고 이해하면 안되겠다.

## 실행 주체를 기준으로 모듈 설정을 보자

`baseUrl`과 오래된 `node`·`node10` 모듈 해석 설정의 deprecated 안내도 있다. 경고만 없애기보다 현재 설정이 어떤 실행 환경을 표현하고 있는지 확인할 시점이다.

Node가 빌드 결과를 직접 실행하는 서버와 번들러가 모듈을 처리하는 프론트엔드는 해석 조건이 다르다. Node 쪽은 `nodenext`, 번들러 중심 프로젝트는 `bundler` 같은 선택지를 실제 도구와 맞춰 검토할 수 있다.

```text
확인할 연결
소스의 import → TypeScript 해석 → 빌드 도구 → 실제 런타임
```

에디터에서 경로를 찾는것과 배포된 JavaScript가 그 경로를 실행하는것도 구분해야한다. 타입 검사만 통과하고 실행 단계에서 모듈을 못찾는다면 설정의 일부만 맞은것이다.

경로 별칭을 사용한다면 TypeScript와 번들러, 테스트 러너가 같은 규칙을 공유하는지 살펴보자. 한곳에서만 `@/`를 이해하는 구조는 업그레이드할때 문제를 찾기 어렵다.

## Beta 검증은 변경 원인을 나눌 수 있게 하자

처음부터 컴파일러와 프레임워크, 타입 패키지를 한꺼번에 바꾸면 오류의 출처를 알기 어렵다. 먼저 별도 브랜치에서 컴파일러 변화만 확인하고 필요한 설정 수정을 모으는 편이 설명하기 쉽다.

발생한 오류도 종류를 나눠보자. 실제 코드의 불명확한 타입이 드러난것인지, 전역 타입이 빠진것인지, 파일 포함 범위가 달라진것인지에 따라 해결 방법이 다르다.

임시로 경고를 숨기는 설정이 필요할 수는 있다. 다만 그 설정과 제거할 조건을 함께 남겨야 다음 업그레이드에서 같은 문제를 다시 마주하지 않겠다.

# 2. Database — PostgreSQL은 지원 버전 전반의 보안을 수정했다

2월 12일 [PostgreSQL 업데이트](https://www.postgresql.org/about/news/postgresql-182-178-1612-1516-and-1421-released-3235/)가 나왔다. 대상은 18.2, 17.8, 16.12, 15.16, 14.21이며 다섯가지 보안 취약점과 65개가 넘는 버그를 수정했다.

여기에는 `pgcrypto`, `intarray`, 텍스트 처리와 관련된 문제 등이 포함된다. 새 메이저 버전의 기능 소개와 달리, 이미 운영하고 있는 지원 버전의 패치 수준을 확인해야하는 소식이다.

## 메이저 버전이 같아도 패치 수준은 다르다

서비스 문서에 PostgreSQL 17을 사용한다고 적혀있어도 실제 패치 버전은 인스턴스마다 다를 수 있다. 운영과 스테이징, 읽기 복제본과 개발 환경을 따로 확인해야한다.

우선 현재 버전과 설치한 확장 목록부터 정리해볼 수 있다.

```sql
SELECT version();

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

이 결과만으로 모든 취약점의 영향 여부를 판정할 수 있는것은 아니다. 다만 어떤 구성과 비교해야할지 알기 위한 출발점이 된다.

DB를 직접 관리한다면 서버 바이너리와 패키지의 버전을 확인하고, 관리형 서비스라면 제공자의 적용 가능 버전과 유지보수 절차를 확인해야한다. 같은 이름의 업데이트라도 적용 방식은 환경마다 다를 수 있다.

## 작은 버전 업데이트도 운영 절차는 필요하다

같은 메이저 안에서의 마이너 업데이트는 일반적으로 dump와 restore나 `pg_upgrade`가 필요한 작업은 아니다. 그렇다고 실행중인 서버가 아무 절차 없이 바뀐다는 의미도 아니다.

재시작과 연결 복구, 복제 구성의 순서와 점검 항목을 환경에 맞춰 준비해야한다. 업데이트 직후 애플리케이션의 커넥션 풀이 정상적으로 연결을 회복하는지도 확인 대상이다.

특히 이번 안내에는 일부 `ltree` 인덱스의 collation 조건에 따라 재색인이 필요한 경우가 있다. 우리 환경이 해당되는지는 릴리스 안내와 인덱스 구성을 함께 봐야한다.

운영에서 필요한것은 “패키지 설치 성공” 다음의 상태다. 읽기와 쓰기가 가능하고, 복제와 백업이 기대한 상태이며, 주요 기능이 정상적으로 동작해야 업데이트를 마무리할 수 있다.

## 실제 서비스의 대표 쿼리를 준비하자

연결 확인용 `SELECT 1`은 서버가 응답하는지 보여준다. 하지만 주문 조회나 검색, 배치 집계가 정상인지를 대신 확인해주지는 않는다.

예를 들어 다음처럼 서비스에서 자주 사용하는 경로를 골라둘 수 있다.

| 확인 대상 | 비교할 내용 |
| --- | --- |
| 로그인과 사용자 조회 | 결과, 응답 시간, 연결 오류 |
| 검색과 정렬 | 문자열 처리, collation, 인덱스 사용 |
| 쓰기 트랜잭션 | 제약 조건과 트리거, 실패 시 되돌림 |
| 읽기 복제본 | 복제 지연과 조회 가능 상태 |
| 배치와 백업 | 종료 결과와 다음 실행 가능 여부 |

모든 쿼리를 같은 무게로 확인하기 어렵다면 사용자 영향이 큰 경로부터 우선순위를 정하면 된다. 데이터 크기가 다른 빈 스테이징에서만 확인하고 끝내는것도 피하는게 좋겠다.

백업 파일이 존재하는지와 실제 복구가 가능한지도 다른 질문이다. 복구 절차와 걸리는 시간을 알아야 업데이트 중 문제가 생겼을때 선택할 수 있는 대응을 설명할 수 있다.

이번주에는 새 기능을 평가하는 작업과 별개로 지원 중인 DB의 패치 현황을 확인해야겠다. 보안 수정의 내용과 우리 서비스의 노출 조건을 연결해 적용 계획을 잡는것이 먼저다.

# 3. Frontend — Next.js는 Agent가 실행 상태를 읽는 방향을 설명했다

2월 12일 Next.js가 [Agent를 고려한 개발 방향](https://nextjs.org/blog/agentic-future)을 소개했다. 핵심은 Agent가 소스 파일뿐 아니라 브라우저 오류와 라우트, 실행 상태를 이해할 수 있어야한다는것이다.

이 글은 모든 기능을 이번주에 처음 출시했다는 발표는 아니다. 이전부터 진행한 로그 개선과 MCP 통합의 경험을 정리하고 앞으로의 방향을 설명한 내용으로 보면 되겠다.

## 코드만 읽어서는 브라우저의 실패를 모를 수 있다

개발할때 “이 오류 고쳐줘”라고 말하는 상황을 생각해보자. 사람은 지금 보고 있는 브라우저의 오류를 알고 있지만 Agent는 저장소 파일만 읽고 있을 수 있다.

HTML을 받았다고 클라이언트 JavaScript 오류와 비동기 실패까지 모두 알 수 있는것도 아니다. 어떤 페이지에서 어떤 조작을 한 뒤 문제가 생겼는지 연결할 정보가 필요하다.

Next.js는 구조화된 오류 복사, 브라우저 로그의 터미널 전달, MCP를 통한 내부 상태 제공 등의 접근을 설명했다. `next-devtools-mcp`에는 실행중인 개발 서버를 찾고 연결하는 역할도 포함된다.

```text
코드 수정
    ↓
개발 서버와 브라우저에서 실행
    ↓
오류·라우트·현재 상태 확인
    ↓
원인 수정과 같은 경로 재확인
```

이 흐름에서 중요한것은 정보가 많아졌다는 사실보다 현재 문제와 관련있는 상태를 얻을 수 있다는 점이다. 오래된 터미널 로그와 방금 발생한 브라우저 오류를 섞으면 잘못된 원인을 고칠 수 있다.

## 빌드 성공과 사용자 흐름의 성공을 나누자

폼을 수정한 작업이라면 빌드가 통과하는지와 함께 실제 제출 흐름도 확인해야한다. 입력 오류가 보이는지, 요청이 실패했을때 다시 시도할 수 있는지, 성공 후 데이터가 화면에 반영되는지 살펴보는것이다.

코드 검사를 통과해도 인증 상태나 캐시, 서버와 클라이언트의 데이터 차이 때문에 사용자가 기대한 결과를 못볼 수 있다. 이 부분은 실행 환경을 관찰해야 알기 쉽다.

반대로 브라우저에서 한번 잘 보였다고 모든 변경이 검증된것도 아니다. 수정한 경로와 관련된 타입 검사와 테스트를 함께 묶어야 다른 입력이나 라우트의 문제도 찾을 수 있다.

Agent에게 줄 완료 조건도 구체적으로 적으면 좋겠다. “화면을 고쳐줘”보다 “잘못된 입력에서는 오류를 표시하고, 성공하면 저장된 값을 다시 보여줘”처럼 관찰 가능한 결과를 정하는것이다.

## 프레임워크 지식과 프로젝트 규칙을 구분하자

Next.js는 프레임워크 지식을 제공하는 문서와 워크플로도 함께 다룬다. 하지만 프레임워크의 일반적인 권장 방식이 우리 프로젝트의 모든 의사결정을 대신하는것은 아니다.

예를 들어 데이터 접근을 어디에 모으는지, 권한을 어떤 계층에서 검사하는지, API 오류 형식을 어떻게 통일하는지는 저장소의 규칙이 필요하다.

문서가 여러곳에 있다면 현재 유효한 규칙을 찾기 쉽게 해야한다. 이전 버전의 예제와 현재 코드를 모두 같은 기준으로 읽으면 Agent가 기존 구조를 잘못 바꿀 수 있다.

개인적으로는 AI 기능을 하나 더 붙이는것보다 이런 관찰과 연결이 더 실무적으로 느껴진다. 사람이 전달하던 오류의 문맥을 도구가 읽을 수 있게 되면 수정과 검증 사이의 왕복을 줄일 여지가 생긴다.

# 4. AI — Gemini Deep Think는 복잡한 추론 문제를 겨냥했다

2월 12일 [Gemini 3 Deep Think 업데이트](https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-deep-think/)가 발표됐다. 과학과 연구, 엔지니어링 문제를 위한 특화 추론 모드의 개선이다.

이번주 기준 업데이트된 모드는 Google AI Ultra 구독자의 Gemini 앱에서 제공된다. Gemini API는 선택된 연구자와 엔지니어, 기업을 위한 early access 신청 단계로 안내됐다. 일반 API에서 누구나 바로 같은 조건으로 사용할 수 있다고 보면 안되겠다.

## 어려운 질문은 입력 조건부터 정리해야한다

추론이 필요한 문제는 긴 답변이 필요한 문제와 꼭 같지는 않다. 여러 제약이 서로 충돌하거나, 주어진 정보가 불완전하거나, 결과를 비교할 기준이 명확하지 않은 상황이 더 어렵다.

예를 들어 처리량을 늘리면서 비용과 지연을 제한해야하는 시스템 설계를 생각해보자. 최대 처리량 하나만 높이면 되는 문제가 아니다. 부하의 형태와 허용 가능한 실패, 운영 인력까지 조건에 들어간다.

이때 모델에 “최적 구조를 만들어줘”라고만 요청하면 서로 다른 가정이 섞인 답변을 받을 수 있다. 현재 확인된 사실과 가정, 바꿀 수 없는 제약을 나누는 편이 낫겠다.

```text
문제 입력에서 나눌것
확인된 값 / 아직 모르는 값 / 고정 조건 / 비교 기준 / 허용 오차
```

값의 단위도 중요하다. 초당 요청과 분당 작업, 평균 지연과 상위 지연을 섞으면 그럴듯한 계산도 실제 설계와 다른 결과를 낼 수 있다.

## 긴 설명보다 검증할 수 있는 결과를 받아보자

모델이 결론을 제안했다면 어떤 가정에서 성립하는지, 어떤 입력에서 깨지는지 확인하는 질문을 이어갈 수 있다. 특히 코드와 수식이 함께 있는 답변은 둘이 같은 조건을 표현하는지 봐야한다.

시뮬레이션을 만들었다면 극단값과 작은 예제에서 먼저 결과를 비교하면 좋겠다. 이미 답을 아는 간단한 경우도 통과하지 못한다면 큰 결과를 해석하기 어렵다.

모델이 작성한 검증 코드도 확인 대상이다. 제안한 방법과 같은 잘못된 가정을 테스트에 그대로 넣으면 실행에 성공해도 독립적인 검증이 되지 않을 수 있다.

예를 들어 큐의 처리량을 계산하면서 대기 작업이 하나도 없는 상황만 시험했다면, 혼잡할때의 지연을 설명하기 어렵다. 테스트 입력은 우리가 알고 싶은 실패 조건을 포함해야한다.

추론 모드는 모든 요청에 같은 비용과 시간을 쓰기보다 필요한 작업에 배치하는 편이 좋겠다. 단순 형식 변환과 복잡한 설계 비교는 요구하는 검증 수준도 다르기 때문이다.

# 5. 실무에서는 변경의 종류마다 다른 완료 기준이 필요하다

이번주 네가지 소식을 하나의 “업데이트”로 묶으면 필요한 점검이 흐려진다. 컴파일러 설정과 DB 패치, Agent 연결과 추론 모델은 실패했을때 나타나는 방식이 다르다.

| 변경 | 완료 여부를 볼 근거 |
| --- | --- |
| TypeScript Beta 시험 | 설정 차이, 타입 검사와 빌드, 배포 결과 실행 |
| PostgreSQL 패치 | 적용 버전, 주요 쿼리, 복제와 복구 상태 |
| Agent 개발 도구 연결 | 현재 서버 발견, 오류 확인, 사용자 흐름 재현 |
| 추론 모드 평가 | 가정과 단위, 반례, 독립적인 결과 검증 |

## 작은 프로젝트에서도 기록은 도움이 된다

혼자 관리하는 프로젝트라면 거창한 문서보다 변경 전후의 값과 확인한 결과만 남겨도 도움이 된다. 무엇을 바꿨고 어떤 조건에서 확인했는지가 있으면 다음 문제에서 비교할 기준이 생긴다.

컴파일러 업데이트라면 버전과 설정 차이, 남아있는 오류를 적어둘 수 있다. DB 패치라면 인스턴스와 적용 시점, 연결 회복과 주요 쿼리 결과를 묶어두는것이다.

Agent가 작업한 경우에는 실행했다고 설명한 내용과 실제 남은 결과도 비교해보자. 테스트 이름만 나열한 답변보다 어떤 경로가 확인됐고 어떤 부분은 확인하지 못했는지가 유용하다.

## 실패를 구분할 수 있는 단위로 적용하자

새 모델과 컴파일러, DB 패치를 같은 배포에 몰아넣으면 문제가 생겼을때 원인을 좁히기 어렵다. 서로 의존하지 않는 변경은 적용과 확인의 시점을 나눌 수 있겠다.

# 마무리

이번주는 새로운 기능을 사용하는 속도만큼 현재 환경을 정확하게 설명하는 능력이 중요하게 느껴졌다. TypeScript는 다음 컴파일러를 준비하고 있고, PostgreSQL은 지금 운영하는 버전의 수정을 제공했다.

Next.js는 Agent가 코드와 실행 상태를 연결하는 방향을 보여줬고, Deep Think는 더 복잡한 문제를 다루는 선택지를 넓혔다. 각각의 역할과 제공 상태를 구분해서 적용해야겠다.

개인적으로는 이번주에 tsconfig의 암묵적인 설정과 DB의 실제 패치 버전부터 확인해보려고 한다. 새 도구를 잘 사용하는 일도 결국 현재 프로젝트가 어떻게 동작하는지 아는것에서 시작하는것같다..


[2026.02.13 주간 개발 트렌드] TypeScript 6 Beta와 PostgreSQL 패치, AI 개발 환경

독자의 메모