[2026.03.13 주간 개발 트렌드] Vite 8과 멀티모달 임베딩, Sora API

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

# 이번주는 AI의 작업 능력과 개발 환경이 같이 바뀌었다

3월 첫 주에는 GPT-5.4와 GPT-5.4 Pro, TypeScript 6.0 RC, Codex Windows 앱 소식이 나왔다. 하나는 모델이고 하나는 컴파일러, 또 하나는 작업을 관리하는 앱이라서 같은 업데이트처럼 보기는 어렵다.

그래도 개발자 입장에서 연결되는 부분은 있다. AI가 코드를 작성한 뒤 그 코드를 어떤 설정으로 검사하고, 어디서 실행하며, 변경 결과를 어떻게 확인할것인가에 대한 이야기다.

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

| 분야 | 이번주 소식 | 먼저 구분할 부분 |
| --- | --- | --- |
| AI | GPT-5.4·Pro | 추론과 코딩, 도구 실행의 연결 |
| TypeScript | 6.0 RC | 정식 출시 전 기존 프로젝트의 호환성 확인 |
| 개발 도구 | Codex Windows 앱 | 여러 작업과 실행 환경, 변경 검토 |

개인적으로는 새 도구의 성능만큼 그 도구가 현재 프로젝트의 규칙을 얼마나 정확히 이해할 수 있는지가 중요해보인다. 이번주에는 실제로 확인할 기준까지 함께 정리해보려고 한다.

# 1. AI — GPT-5.4는 추론과 코딩, 도구 사용을 연결한다

3월 5일 GPT-5.4와 GPT-5.4 Pro가 공개됐다. [GPT-5.4](https://developers.openai.com/api/docs/models/gpt-5.4)는 추론과 코딩, 도구를 사용하는 업무를 함께 다루는 모델이고, [Pro](https://developers.openai.com/api/docs/models/gpt-5.4-pro)는 더 많은 연산이 필요한 어려운 문제를 위한 선택지다.

API에서는 기본 모델을 Chat Completions와 Responses에서, Pro를 Responses에서 제공한다. 같은 계열이라도 모든 호출 경로와 기능을 같은 조건으로 제공한다고 가정하지 않는게 좋겠다.

## 코드 생성 이후의 과정까지 봐야한다

개발 작업은 보통 요구사항을 코드로 바꾸는 단계에서 끝나지 않는다. 관련 파일을 찾고 기존 계약을 읽고, 수정한 결과를 실행해서 문제가 해결됐는지 확인하는 과정이 붙는다.

예를 들어 검색 필터를 추가한다고 생각해보자. 화면에 입력창 하나를 만들더라도 요청 파라미터와 서버 검증, DB 조회와 페이지 이동이 같은 조건을 유지해야한다.

AI가 각 파일의 코드만 그럴듯하게 작성하면 이 연결을 놓칠 수 있다. 필터를 바꿨는데 이전 페이지 번호를 유지하거나, 화면에서는 선택됐지만 서버에는 전달되지 않는식이다.

```text
개발 작업의 연결
요구사항 → 코드 탐색 → 수정 → 실행 → 결과 확인
                          ↑             ↓
                          └── 오류 수정 ──┘
```

모델을 평가할때도 첫 코드의 길이보다 이 흐름을 끝까지 유지하는지 보면 좋겠다. 실패한 테스트를 읽고 원인을 좁히는지, 결과를 확인한 뒤 완료 여부를 판단하는지가 중요하다.

또한 필요한 수정과 관계없는 정리를 구분해야한다. 작은 버그를 고치면서 프로젝트의 구조 전체를 바꿔버리면 결과가 맞더라도 검토하기 어려워질 수 있다.

## Pro를 선택하는 기준도 작업에서 찾아보자

더 많은 연산을 사용하는 모델이 있다고 모든 요청을 그 모델로 보내야하는것은 아니다. 단순한 형식 변환과 여러 제약을 비교하는 설계 작업은 요구하는 판단이 다르다.

먼저 현재 사용하는 모델이 자주 실패하는 작업을 모아볼 수 있다. 실패 원인이 추론 부족인지, 필요한 파일을 제공하지 않았기 때문인지, 도구가 실행되지 않았기 때문인지 나눠보는것이다.

입력에 없는 사내 규칙을 모델이 모르는 문제는 모델 이름만 바꿔서 해결하기 어렵다. 반대로 필요한 근거가 있어도 여러 조건을 함께 유지하지 못하는 문제라면 모델 비교의 의미가 커진다.

비용을 볼때도 요청 한건의 가격과 완료된 작업 하나의 비용을 구분하면 좋겠다. 재시도와 도구 실행, 사람이 검토하고 수정한 시간까지 포함하면 선택 기준이 달라질 수 있다.

| 비교할 작업 | 확인할 결과 |
| --- | --- |
| 작은 버그 수정 | 재현 조건 해결과 주변 기능 유지 |
| 설계 비교 | 제약과 가정, 선택 이유의 일관성 |
| 여러 파일 수정 | API와 타입, 사용 코드의 연결 |
| 최종 리뷰 | 실제 문제와 잘못된 지적의 구분 |

한번의 성공 사례로 기본 모델을 정하기보다는 팀이 반복하는 작업에서 차이가 계속 나타나는지 확인하고 싶다. 좋은 답변과 도입할 가치가 있는 결과 사이에는 운영 조건도 들어가기 때문이다.

# 2. AI API — 도구가 많아질수록 상태를 잘 나눠야한다

이번주 Responses API에는 도구 검색과 GPT-5.4의 컴퓨터 조작, 긴 작업을 위한 문맥 관리 관련 개선도 안내됐다. 자세한 제공 항목은 [공식 변경 내역](https://developers.openai.com/api/docs/changelog)에서 확인할 수 있다.

이런 기능은 Agent가 할 수 있는 일의 범위를 넓힌다. 다만 도구를 선택하는 능력과 도구를 실제로 실행할 시스템은 다른 역할이다.

## 도구 설명과 실행 결과를 구분하자

모델에 파일 읽기 도구가 있다고 설명했다고 실제 저장소가 연결되는것은 아니다. 어떤 작업 공간에서 어떤 파일을 읽었는지, 호출이 실패했는지까지 실행 결과로 돌려줘야한다.

예를 들어 명령 실행 결과가 비어있다면 성공해서 출력이 없는것인지, 아직 실행중인지, 결과를 가져오지 못한것인지 구분할 수 있어야한다. 같은 빈 문자열이라도 의미가 다르다.

```text
도구 호출에서 남길 상태
요청됨 / 실행중 / 완료 / 실패 / 결과 확인 필요
```

모델이 이 상태를 구분하지 못하면 아직 실행중인 테스트를 통과했다고 설명할 수 있다. 반대로 완료된 작업을 다시 실행해 시간을 낭비할 수도 있다.

특히 파일 수정이나 외부 시스템 변경은 재시도할때 주의가 필요하다. 조회를 다시 하는것과 이미 수행한 변경을 반복하는것은 결과가 다를 수 있기 때문이다.

작업 기록에는 호출한 도구와 입력뿐 아니라 종료 상태와 확인한 결과를 함께 남겨야겠다. 그래야 중간에 연결이 끊겨도 어디까지 진행됐는지 알 수 있다.

## 컴퓨터 조작은 화면의 실제 상태가 기준이다

화면을 사용하는 작업에서는 소스 코드의 의도와 현재 UI가 다를 수 있다. 저장 버튼을 눌렀어도 검증 오류가 표시되거나 다음 단계에 머물러 있을 수 있다.

따라서 행동 뒤에는 바뀐 상태를 다시 읽어야한다. 클릭을 실행한 사실만으로 저장과 발행, 제출이 완료됐다고 판단하면 안되겠다.

개발자가 확인할 결과도 구체적이면 좋다. “화면을 수정했다”보다 “잘못된 입력에서는 오류가 보이고, 정상 입력 후 저장된 값이 다시 표시된다”처럼 관찰할 수 있는 조건을 정하는것이다.

도구 사용이 늘어날수록 마지막 설명의 정확성이 중요해진다. 모델이 시도한 작업과 실제 완료한 작업, 아직 확인하지 못한 부분을 나눠 보고해야 검토자가 다음 결정을 할 수 있다.

# 3. TypeScript — 6.0 RC에서는 우리 설정의 의미를 확인하자

3월 6일 [TypeScript 6.0 RC](https://devblogs.microsoft.com/typescript/announcing-typescript-6-0-rc/)가 공개됐다. 정식 출시 후보 버전이며, 현재 JavaScript 기반 구현에서 앞으로의 네이티브 TypeScript 7로 넘어가기 위한 전환 단계다.

이번주 기준 6.0은 아직 RC다. 6.0 자체가 Go 기반 컴파일러로 바뀐것도 아니다. 새로운 컴파일러에 대한 기대와 지금 검증할 버전의 성격을 나눠서 봐야한다.

## 설정을 생략한 부분부터 살펴보자

6.0에서는 `strict`, `types`, `rootDir` 등 기본 동작의 변화가 있다. 이전 버전의 기본값에 의존한 프로젝트는 설정 파일의 내용이 같아도 결과가 달라질 수 있다.

설정에 옵션이 없다는것은 기능을 사용하지 않는다는 의미가 아니다. 설치한 컴파일러의 기본값을 선택하고 있다는 의미다. 업그레이드 전에 그 가정을 확인하면 문제를 분류하기 쉽다.

예를 들어 Node 서버에서 전역 Node 타입이 필요하고 소스가 `src`에 모여있다면 의도를 명시할 수 있다.

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

이 예시는 전체 설정이 아니다. 브라우저 코드와 테스트 코드, 빌드 스크립트가 어떤 범위에 포함되는지에 따라 별도 설정이 필요할 수 있다.

특히 `types`는 전역 타입 패키지의 포함 범위와 관련된다. 일반 모듈을 import하면서 사용하는 타입까지 전부 차단하는 옵션으로 이해하면 안되겠다.

## 출력 경로는 배포 명령과 연결된다

타입 검사가 통과해도 출력 디렉터리 구조가 달라지면 실행 명령이 잘못된 파일을 가리킬 수 있다. `dist/index.js`를 실행하도록 설정했는데 결과가 다른 하위 디렉터리에 생기는 경우를 생각해보자.

확인할 대상에는 `tsc` 결과뿐 아니라 패키지의 실행 스크립트와 Docker 이미지, 배포 설정도 포함된다. 에디터에서 오류가 없어졌다는 사실만으로 전체 전환이 끝나지는 않는다.

```text
설정 검증의 끝
타입 검사 → 출력 파일 → 패키징 → 실제 실행 경로
```

라이브러리라면 생성한 선언 파일과 패키지 export 경로도 확인해야한다. 작은 소비자 프로젝트에서 빌드된 패키지를 import해보면 저장소 내부에서 놓친 연결을 찾을 수 있다.

출력물 비교에서는 의미있는 변경과 단순한 표시 순서 차이를 구분하는것도 필요하다. diff의 줄 수만으로 실제 호환성 문제의 크기를 판단하기 어렵기 때문이다.

## 폐기 예정 옵션은 이유를 알고 정리하자

6.0에서는 `baseUrl`과 오래된 모듈 해석 방식 등 여러 설정의 deprecated 안내가 있다. 경고를 없애는것만 목표로 삼기보다 현재 실행 환경에 맞는 선택을 확인하면 좋겠다.

Node가 결과 파일을 직접 실행하는 프로젝트와 번들러가 모듈을 처리하는 프로젝트는 조건이 다르다. 에디터가 경로를 찾는 규칙과 런타임이 import를 실행하는 규칙을 맞춰야한다.

임시로 폐기 경고를 무시할 수 있더라도 제거할 조건은 남겨두고 싶다. 경고를 숨긴 설정이 영구히 남으면 다음 전환에서 어떤 가정이 있었는지 알기 어렵다.

RC 시험은 별도 브랜치에서 컴파일러와 설정의 변경을 먼저 확인하는 방식이 좋겠다. 프레임워크와 의존성까지 한꺼번에 올리면 어느 변경이 오류를 만들었는지 좁히기 어려워진다.

# 4. 개발 도구 — Codex 앱을 Windows에서도 사용할 수 있다

3월 4일 Codex Windows 앱이 제공됐다. [공식 업데이트](https://learn.chatgpt.com/docs/whats-new#move-chats-between-local-and-worktree)에서 소개한 흐름처럼, 프로젝트별 작업과 여러 Agent 대화, 변경 결과의 검토를 앱 안에서 관리하는 선택지가 Windows로 넓어진것이다.

모델과 개발 앱은 역할이 다르다. 같은 모델을 사용하더라도 작업 공간과 실행 환경, 변경을 검토하는 UI가 다르면 실제 개발 과정도 달라질 수 있다.

## 여러 작업을 나누기 전에 의존성을 확인하자

여러 Agent를 동시에 실행할 수 있으면 독립적인 작업을 나누기 쉽다. 하지만 같은 파일과 같은 API 계약을 동시에 바꾸면 검토와 통합 비용이 늘어날 수 있다.

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

```text
작업을 나눌 기준
공유하는 파일 / 먼저 정할 계약 / 독립적인 검증 / 통합할 결과
```

작업 공간을 분리해도 설계의 충돌까지 없어지는것은 아니다. 각 작업이 어떤 기준 코드에서 시작했고 무엇을 바꿨는지 알 수 있어야한다.

여러 결과를 합칠때는 개별 작업의 테스트 통과와 통합 후 결과를 구분해야겠다. 각각 정상이어도 함께 적용하면 같은 설정이나 데이터 구조를 다르게 가정했을 수 있다.

## 운영체제가 달라지면 명령과 경로도 확인하자

Windows 개발 환경에서는 셸과 파일 경로, 실행 도구의 위치를 확인해야한다. macOS에서 동작한 스크립트를 같은 문자열로 실행한다고 동일한 결과가 보장되지는 않는다.

Agent에게 명령을 맡기기 전 저장소가 안내하는 설치와 테스트 절차를 분명히 해두면 좋겠다. 팀에서 지원하는 셸과 런타임 버전, 필요한 환경 변수를 알 수 있어야한다.

특히 환경 변수 설정과 경로 구분, 줄바꿈처럼 작은 차이가 설치나 테스트에 영향을 줄 수 있다. 모델의 코드 판단과 환경 준비의 실패를 나눠서 보게 된다.

앱이 여러 작업을 관리해주더라도 현재 어느 작업 공간에서 실행하는지는 확인해야한다. 다른 브랜치나 폴더의 로그를 읽고 현재 수정의 결과로 오해하면 검증이 어긋날 수 있다.

개인적으로는 Windows 지원이 단순히 앱을 설치할 수 있는 운영체제가 늘어난것보다 개발 팀의 작업 환경을 맞추는데 의미가 있다고 생각한다. 다만 공통 명령과 완료 기준은 저장소에서 관리해야겠다.

# 5. 이번주에는 작은 변경 하나를 끝까지 연결해보자

세가지 소식이 모두 관련있는 TypeScript 프로젝트라면 무엇부터 시험할지 고민할 수 있다. 한번에 모든 도구를 바꾸기보다는 각각의 변경 효과를 설명할 수 있는 단위로 나눠보면 좋겠다.

우선 현재 버전에서 통과하는 작은 작업을 기준으로 남긴다. 타입 검사와 빌드, 실제 실행 경로와 간단한 사용자 흐름이 무엇인지 확인하는것이다.

그다음 TypeScript RC는 별도 브랜치에서 설정과 출력의 차이를 본다. AI 모델은 같은 기준 코드와 같은 요구사항으로 비교하고, Windows 앱은 그 환경에서 설치와 검증 명령이 동작하는지 확인한다.

| 시험 대상 | 남겨둘 근거 |
| --- | --- |
| GPT-5.4·Pro | 입력 조건, 수정 범위, 검증 결과와 반복 횟수 |
| TypeScript RC | 설정 차이, 오류 종류, 출력과 실행 결과 |
| Windows 앱 | 작업 공간과 셸, 실행한 명령과 결과 |
| 여러 작업의 통합 | 공유 계약과 충돌, 통합 후 재검증 |

이렇게 나누면 오류가 생겼을때 원인을 찾기 쉽다. 모델이 필요한 조건을 놓친것인지, 컴파일러 설정이 바뀐것인지, 운영체제의 명령 차이인지 구분할 수 있기 때문이다.

## 완료 기준은 사람이 확인할 수 있는 형태로 적자

완료라는 표현이 도구마다 다르면 검토자가 다시 해석해야한다. 코드 생성 완료와 빌드 완료, 기능 확인 완료는 같은 상태가 아니다.

예를 들어 검색 필터 작업이라면 필터를 바꿨을때 요청과 결과가 달라지고, 새로고침과 페이지 이동에도 선택이 유지되는지까지 적을 수 있다. 그러면 코드와 테스트가 같은 목표를 향하는지 보기 쉽다.

검증하지 못한 환경이 있으면 그 범위도 남겨야겠다. 로컬에서 확인한 결과를 모든 운영 환경에서 동작한다고 확대하지 않으면 다음 확인할 작업이 분명해진다.

모델에게 마지막 설명을 요청할때도 무엇을 바꿨는지와 무엇을 실제로 실행했는지 구분해달라고 할 수 있다. 작업 결과를 다음 사람이나 다음 대화로 넘길때 유용한 기록이 된다.

## 명령이 실패한 이유를 코드 문제와 나눠보자

예를 들어 Agent가 테스트를 실행했는데 패키지가 설치되지 않아 시작조차 못했다면, 아직 수정한 코드의 동작을 평가한것은 아니다. 의존성을 준비한 뒤 같은 검증을 다시 해야한다.

반대로 테스트가 실행되어 특정 입력에서 실패했다면 그때는 재현 조건과 변경 내용을 연결할 수 있다. 두 경우를 모두 “테스트 실패”로만 기록하면 다음 작업에서 필요한 조치가 달라진다.

도구가 내놓는 상태를 사람이 다시 해석하지 않아도 되게 만드는것이 작업 관리의 중요한 부분이라고 생각한다. 완료 보고에는 명령의 시작 여부와 종료 결과, 실제 확인한 동작을 구분해 남기면 좋겠다.

# 마무리

이번주는 AI 모델의 판단과 도구 사용, TypeScript의 전환 준비, Windows 개발 앱의 제공이 함께 이어졌다. 서로 다른 계층의 변화지만 개발 작업을 끝까지 실행하고 확인하는 흐름에서 만난다.

당장 모든 프로젝트를 바꿀 필요는 없겠다. 현재 설정과 실행 절차를 정리하고, 작은 작업에서 새 모델과 RC, 앱의 차이를 각각 확인해보면 좋을것같다.

개인적으로는 새 도구를 붙이는 속도보다 변경의 결과를 설명할 수 있는지가 더 중요해지고 있다고 느낀다. 이번주에는 코드와 실행 결과를 함께 남기는 습관부터 챙겨봐야겠다..


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

독자의 메모