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

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

# 이번주는 Agent의 작업 능력과 실행 환경이 같이 넓어졌다

이번주에는 코딩 모델과 개발 앱, 코드를 실행하는 인프라 소식이 함께 나왔다. 모델이 긴 작업을 잘하는것과 그 작업을 어디서 어떻게 실행할지는 다른 문제인데, 양쪽에서 선택지가 늘어난 주다.

2월 2일부터 6일까지의 소식을 다섯가지로 나눠보았다.

| 분야 | 소식 | 구분해서 볼 부분 |
| --- | --- | --- |
| AI | GPT-5.3-Codex | 긴 코딩 작업과 제품 제공 범위 |
| AI | Claude Opus 4.6 | 코드 검토와 긴 문맥, Beta 조건 |
| 개발 도구 | Codex macOS 앱 | 여러 작업과 변경 내역 관리 |
| 인프라 | Deno Deploy GA·Sandbox | 배포와 격리 실행의 서로 다른 역할 |
| Kubernetes | Node Readiness Controller | 노드 상태와 실제 의존성 준비 |

같은 Agent 흐름 안에서도 모델, UI, 실행 환경, 배치 조건은 각각의 계층이다. 이번주에는 이 역할을 나눠서 살펴보려고 한다.

# 1. AI — GPT-5.3-Codex가 긴 작업을 강화했다

2월 5일 [GPT-5.3-Codex](https://openai.com/index/introducing-gpt-5-3-codex/)가 공개됐다. OpenAI는 코딩과 추론, 도구를 사용하는 긴 작업의 개선과 함께 Codex에서 약 25% 빠른 실행을 발표했다.

## 사용할 수 있는 위치부터 구분하자

이번주 발표 기준으로 유료 ChatGPT 요금제의 Codex 앱과 CLI, IDE 확장, 웹에서 제공된다. API 접근은 앞으로 제공할 내용으로 안내됐다.

따라서 모델 출시와 자체 서비스의 API 연결 가능 시점을 같은것으로 보면 안된다. 실제 사용할 제품과 계정의 제공 범위를 먼저 확인해야한다.

또한 발표된 속도 개선은 모든 저장소의 전체 작업 시간이 같은 비율로 줄어든다는 의미가 아니다. 모델 응답 외에도 파일 탐색과 설치, 빌드와 테스트, 외부 도구를 기다리는 시간이 포함되기 때문이다.

```text
전체 작업 시간
모델 판단 + 도구 실행 + 검증 + 실패 수정 + 결과 확인
```

어느 부분이 느린지 알아야 새 모델의 효과도 설명하기 쉽다. 테스트가 오래 걸리는 프로젝트와 코드 탐색이 오래 걸리는 프로젝트는 체감이 다를 수 있다.

## 긴 작업의 성공 기준을 정하자

코드를 많이 작성했다는 사실과 요청을 완료했다는 사실은 다르다. 기존 구조를 읽고 필요한 범위만 수정하며 관련 테스트를 실행하는 흐름을 함께 확인해야한다.

예를 들어 기능 하나를 추가하는 작업이라면 API와 데이터 모델, 화면이 같은 요구사항을 반영하는지 볼 수 있다. 한 계층만 완성하고 전체가 끝났다고 설명하지 않는지도 중요하다.

작업 중 사용자가 조건을 추가하는 경우도 생각해보자. 이미 만든 결과와 새 요구사항을 구분해 무엇을 다시 확인해야하는지 판단할 수 있어야한다.

모델 평가에는 정답 코드만 있는 문제뿐 아니라 모호한 요구와 실패하는 테스트도 포함하면 좋겠다. 질문을 해야할 상황과 스스로 확인할 수 있는 상황을 나눠보는것이다.

# 2. AI — Opus 4.6은 코드 검토와 긴 문맥을 강조했다

같은 2월 5일 [Claude Opus 4.6](https://www.anthropic.com/news/claude-opus-4-6)도 공개됐다. Anthropic은 코딩과 계획, 코드 리뷰와 디버깅, 큰 저장소의 긴 작업 개선을 소개했다. Opus 계열의 100만 토큰 문맥도 Beta로 제공된다.

## 문맥 크기와 필요한 정보는 다르다

큰 문맥은 많은 파일과 문서를 함께 읽는 작업에서 도움이 될 수 있다. 하지만 저장소 전체를 아무 기준 없이 넣는것이 항상 좋은 입력은 아니다.

현재 요구사항과 관련없는 생성 파일이나 오래된 문서가 섞이면 중요한 제약이 흐려질 수 있다. 필요한 근거를 찾고 그 근거가 어느 파일과 버전에서 나온것인지 연결하는 과정이 여전히 필요하다.

```text
큰 입력에서 남겨야할 구분
현재 요구사항 / 실제 코드 / 설계 문서 / 이전 결정 / 검증 결과
```

긴 대화를 요약할때도 실패한 시도를 완료된 작업처럼 남기지 않는게 중요하다. 문맥을 줄이는 작업과 중요한 사실을 보존하는 작업을 같이 봐야한다.

100만 토큰은 Beta 조건과 제공 경로를 확인해야한다. 모든 제품에서 기본으로 같은 한도와 비용을 제공한다고 이해하면 안되겠다.

## 코드 리뷰는 지적 개수보다 재현 가능한 문제를 보자

리뷰 모델을 비교할때 많은 항목을 지적한다고 반드시 좋은 결과는 아니다. 실제로 발생할 수 있는 문제인지, 어떤 입력과 조건에서 나타나는지 설명할 수 있어야한다.

문제의 위치와 원인, 영향받는 경로가 연결되는지 확인해보자. 반대로 이미 앞단에서 보장하는 조건을 모른채 같은 검증을 반복 제안할 수도 있다.

```text
리뷰 결과를 확인할 순서
관련 코드 → 발생 조건 → 재현 또는 검증 → 수정의 영향
```

발견한 문제를 수정했다면 원래 동작도 유지되는지 봐야한다. 안전해보이는 수정이 정상적인 사용 흐름까지 막는 경우를 구분해야하기 때문이다.

서로 다른 모델은 같은 저장소와 같은 작업으로 비교하면 좋겠다. 제공자가 발표한 서로 다른 평가의 숫자만 나란히 놓으면 실제 우리 작업에서의 차이를 알기 어렵다.

# 3. 개발 도구 — Codex 앱에서 여러 작업을 관리한다

2월 2일 [macOS용 Codex 앱](https://openai.com/index/introducing-the-codex-app/)이 공개됐다. 프로젝트별 대화와 여러 Agent 작업, diff 검토와 worktree 지원을 통해 긴 작업을 관리하는 인터페이스를 제공한다.

## 작업을 나누는 기준이 중요해진다

여러 작업을 동시에 실행할 수 있으면 처리량을 늘릴 여지가 있다. 다만 같은 파일과 같은 설계 결정을 여러 작업이 동시에 바꾸면 검토와 통합 비용도 생긴다.

예를 들어 문서 정리와 독립된 테스트 보완은 나누기 쉬울 수 있다. 반면 API 계약을 결정하는 작업과 그 계약을 사용하는 화면 구현은 합의가 먼저 필요할 수 있다.

```text
병렬로 나누기 전에 정할것
각 작업의 목표 / 수정 범위 / 공유 계약 / 완료 기준 / 통합 순서
```

동시에 많은 작업을 시작하는것보다 서로 독립적인지 확인하는게 중요하다. 시작은 빨라도 결과가 서로 다른 가정을 사용하면 합치는 과정이 길어질 수 있다.

## worktree는 코드 변경을 나누는 수단이다

worktree를 사용하면 같은 저장소의 작업 디렉터리를 나눌 수 있다. Agent별 변경을 비교하고 각각 다른 방향을 시험하는데 도움이 될 수 있다.

다만 작업 디렉터리가 다르다고 데이터베이스와 외부 서비스, 개발 포트까지 자동으로 분리되는것은 아니다. 같은 테스트 DB를 초기화하는 작업이 있다면 다른 작업에 영향을 줄 수 있다.

실행 환경에서는 포트와 임시 파일, 테스트 계정과 데이터의 범위를 같이 확인하면 좋겠다. 파일 충돌과 외부 자원 충돌은 다른 문제다.

또한 Git 작업 공간의 분리와 운영체제 수준의 코드 격리도 구분해야한다. 코드를 안전하게 실행할 권한과 네트워크 범위는 별도로 관리해야한다.

## 검토할 단위를 작게 유지하자

여러 Agent가 각각 큰 diff를 만들면 사람이 확인해야하는 결과도 늘어난다. 작업 설명에 변경 목적과 예상 검증을 명시하면 검토하기 쉬운 결과를 받는데 도움이 된다.

완료된 작업은 실행한 테스트와 결과물 위치를 확인하고 통합하자. Agent의 완료 메시지와 저장소의 실제 변경이 일치하는지도 볼 필요가 있다.

앱은 이런 흐름을 관리하는 인터페이스다. 여러 작업을 볼 수 있다는것과 각각의 변경이 모두 승인 가능한 상태라는것은 다른 이야기다.

# 4. 인프라 — Deno Deploy와 Sandbox의 역할을 나눠보자

2월 3일 [Deno Deploy가 GA](https://deno.com/blog/deno-deploy-is-ga)에 들어갔다. 다양한 JavaScript 프레임워크와 빌드 환경을 배포하는 플랫폼으로 소개됐고, 같은날 microVM 기반 Deno Sandbox도 공개됐다.

## 애플리케이션 배포와 임의 코드 실행은 다른 작업이다

일반적인 웹 앱 배포는 검토한 코드와 설정을 서비스로 운영하는 과정이다. 반면 사용자가 생성한 코드나 AI가 만든 코드를 즉시 실행하는 서비스는 실행할 내용 자체가 매번 달라질 수 있다.

```text
배포 플랫폼
검토한 애플리케이션 → 빌드 → 서비스 실행

격리 실행 환경
동적으로 받은 코드 → 제한된 환경에서 실행 → 결과 회수와 정리
```

같은 플랫폼에서 연결할 수 있어도 두 작업의 권한과 수명은 구분해서 정하면 좋겠다. 테스트 실행 환경에 필요한 접근과 운영 서비스에 필요한 접근은 다를 수 있다.

배포 플랫폼을 검토한다면 실제 프레임워크와 의존성, 환경 변수, 외부 DB 연결로 확인해야한다. 데모 페이지가 열리는것과 서비스의 주요 기능이 동작하는것은 다른 기준이다.

## Sandbox는 실행과 외부 접근을 함께 다룬다

[Deno Sandbox](https://deno.com/blog/introducing-deno-sandbox)는 가벼운 Linux microVM을 프로그램으로 준비하는 방식이다. 외부 네트워크 허용 목록과 승인된 호스트에 대한 비밀값 처리도 소개됐다.

격리된 CPU와 메모리만으로 충분한것은 아니다. 실행 코드가 외부 API에 접근한다면 어떤 목적지에 어떤 자격 증명으로 요청할 수 있는지도 정해야한다.

```text
실행 정책에서 나눌 부분
계산 자원 / 파일 접근 / 네트워크 목적지 / 비밀값 / 실행 시간
```

비밀값 보호 기능을 사용하더라도 허용한 API가 어떤 작업을 수행할 수 있는지 확인해야한다. 값을 직접 읽지 못하는것과 그 권한으로 할 수 있는 작업의 범위는 별개다.

예를 들어 조회 전용 작업에는 조회에 필요한 권한만 제공하면 좋겠다. 코드 실행의 편의성을 위해 운영 계정 전체를 연결하는 방식은 작업의 목적과 맞지 않을 수 있다.

## 실행이 끝난 뒤의 정리도 설계하자

작업별로 환경을 만든다면 파일과 프로세스, 결과물을 언제 정리할지 정해야한다. 성공한 작업만 정리하고 실패하거나 취소된 작업을 남겨두면 자원과 비용이 쌓일 수 있다.

```text
작업 접수 → 환경 준비 → 코드 실행 → 결과 회수
                              ↓
                    성공·실패·취소 후 자원 정리
```

결과를 회수하기 전에 환경이 사라지는 경우와 환경은 남았는데 결과를 받지 못하는 경우도 구분해야한다. 작업 식별자와 실행 상태가 연결돼있으면 이런 상황을 추적하기 쉽다.

실행 제한은 요청 횟수뿐 아니라 시간과 출력 크기, 저장 공간도 고려하자. 한 작업의 과도한 사용이 다른 작업의 지연으로 이어지지 않는지 확인하면 좋겠다.

특정 서비스가 모든 요구를 해결한다고 가정하기보다 사용중인 언어와 도구, 네트워크 조건을 작은 작업으로 시험해보는게 좋겠다.

# 5. Kubernetes — Node Ready와 의존성 준비를 구분한다

2월 3일 [Node Readiness Controller](https://kubernetes.io/blog/2026/02/03/introducing-node-readiness-controller/)가 소개됐다. 노드의 사용자 정의 상태에 따라 taint를 관리해 실제 인프라 의존성이 준비된 노드에 워크로드를 배치하도록 돕는 프로젝트다.

## 노드가 Ready여도 필요한 준비가 남을 수 있다

네트워크 Agent와 스토리지 드라이버, GPU 관련 준비가 필요한 환경을 생각해보자. 노드가 기본 상태를 충족했다고 애플리케이션의 모든 의존성까지 사용할 수 있는것은 아닐 수 있다.

```text
노드 시작
├── 기본 kubelet 동작
├── 네트워크 준비
├── 저장소 준비
└── 필요한 장치와 드라이버 준비
        ↓
워크로드를 배치해도 되는가?
```

이번 프로젝트는 이런 조건을 선언적으로 표현하고 스케줄링을 제어하는 방향이다. 초기 단계의 별도 컨트롤러를 모든 클러스터에 기본 포함된 GA 기능으로 이해하면 안된다.

## 상태를 보고하는 역할과 판단하는 역할이 다르다

컨트롤러 자체가 모든 하드웨어와 서비스의 상태를 직접 검사하는 구조는 아니다. 보고된 Node Condition을 읽고 규칙에 따라 taint를 적용하거나 제거한다.

따라서 상태를 누가 어떤 기준으로 보고할지가 중요하다. 검사 엔드포인트가 응답한다는것과 실제 GPU 작업이나 볼륨 연결이 가능한지가 같은 조건인지 확인해야한다.

발표에서는 지속적으로 조건을 적용하는 모드와 부트스트랩때만 적용하는 모드를 구분한다. 초기 준비만 확인할지, 이후 의존성 장애에도 새 배치를 제한할지 정할 수 있다.

```text
부트스트랩 확인
처음 준비됐는지 확인 → 완료 후 해당 규칙 감시 종료

지속 확인
준비 상태 계속 확인 → 조건이 바뀌면 배치 제약 조정
```

새로운 스케줄링을 막는것과 이미 실행중인 Pod를 복구하는것도 구분해야한다. taint의 효과와 toleration, 별도의 복구 컨트롤러가 어떤 역할을 하는지 함께 봐야한다.

## 먼저 영향 범위를 관측해보자

규칙을 잘못 정하면 준비된 노드까지 사용하지 못해 작업이 대기할 수 있다. dry run에서 영향을 받을 노드와 예상 동작을 확인하고 범위를 넓히면 좋겠다.

상태 보고가 끊기거나 오래된 상태가 남는 경우도 살펴보자. 검사 자체가 실패했을때와 실제 의존성이 실패했을때를 어떻게 다룰지 필요하다.

노드 그룹마다 조건이 다를 수 있으므로 모든 노드에 같은 규칙을 적용할 필요는 없다. GPU 노드와 일반 웹 서버 노드를 나눠서 필요한 신호를 정하면 이해하기 쉽다.

# 6. 이번주 소식은 계층별로 비교하자

이번주에는 모델 성능과 작업 관리, 코드 격리와 노드 배치가 함께 발전했다. 같은 Agent 서비스 안에서 연결될 수 있지만 각각 다른 완료 기준이 필요하다.

| 계층 | 확인할 결과 |
| --- | --- |
| 모델 | 요청한 작업과 검증을 끝내는가 |
| 개발 앱 | 작업의 범위와 변경 내역을 관리할 수 있는가 |
| 실행 환경 | 필요한 권한으로 실행하고 결과를 회수하는가 |
| 배치 제어 | 실제 준비된 노드에서 작업을 시작하는가 |

모델을 바꾸면서 실행 환경과 평가 사례까지 바꾸면 차이를 설명하기 어렵다. 먼저 같은 작업과 도구로 모델을 비교하고, 실행 인프라는 별도로 실패와 취소를 시험해보면 좋겠다.

노드 준비 제어도 실제 워크로드의 시작 성공률과 대기 시간을 같이 봐야한다. 준비 조건을 엄격하게 만들어 실패는 줄었지만 작업이 과도하게 대기하는 상황도 확인해야한다.

여러 Agent를 사용하는 경우에는 통합까지 포함한 시간을 기록하자. 개별 작업이 빨라져도 충돌을 해결하고 전체 테스트를 다시 수행하는 비용이 늘 수 있다.

각 기능에서 얻고싶은 이점을 먼저 적으면 무엇을 측정할지 정하기 쉽다. 긴 문맥과 빠른 응답, 격리된 실행, 준비된 노드는 서로 다른 문제를 해결하는 수단이다.

## 하나의 실패를 끝까지 따라가보자

예를 들어 Agent가 테스트 코드를 만들고 격리 환경에서 실행하는 작업을 가정해보자. 코드가 틀린 경우와 실행 환경에 필요한 의존성이 없는 경우는 다른 실패다.

모델이 잘못된 테스트를 만들었다면 코드와 요구사항을 다시 확인해야한다. 실행 환경의 네트워크가 막혀 설치에 실패했다면 같은 코드를 반복 수정해도 문제가 해결되지 않는다.

GPU 노드가 준비되지 않아 작업이 대기하는 상황도 모델 응답 오류로 기록하면 안된다. 어느 계층에서 멈췄는지 알아야 재시도와 복구의 책임을 정할 수 있다.

```text
요청 식별자 하나에 연결할 정보
Agent 작업 → 코드 변경 → 실행 환경 → 배치 결과 → 검증 결과
```

이 연결이 있으면 모델이 설명한 상태와 인프라의 실제 상태를 비교할 수 있다. 정상 완료뿐 아니라 설치 실패와 실행 제한, 작업 취소를 한개씩 넣어보면 경계가 더 잘 드러난다.

처음부터 모든 과정을 자동화하기보다 실패를 설명하고 다시 실행할 수 있는 작은 흐름을 만드는게 좋겠다. 이후 작업 수를 늘릴때도 같은 관측 기준을 사용할 수 있다.

# 마무리

이번주는 코딩 Agent의 능력과 이를 관리하고 실행하는 환경이 함께 넓어진 주였다. 모델의 개선을 실제 결과로 연결할 기반도 중요한 개발 영역이 되고있다.

개인적으로는 더 많은 작업을 맡길 수 있을수록 변경 범위와 실행 권한, 완료 기준을 분명히 해야한다고 생각한다. 작업을 시작하는 속도와 검토 가능한 결과를 받는 속도는 다를 수 있기 때문이다.

우선 작은 업무에서 모델과 실행 환경을 각각 비교해보면 좋겠다. 더 오래 일할 수 있는 Agent가 우리 서비스에서도 안정적으로 끝낼 수 있는지 확인해야겠다..


[2026.02.06 주간 개발 트렌드] 코딩 Agent 모델과 개발 도구, 격리 실행 인프라

독자의 메모