[2026.07.03 주간 개발 트렌드] Sonnet 5와 서비스 연결, Agent 과금·품질 관리

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

# 이번주는 Agent를 오래 실행하고 운영하는 기능이 넓어졌다

이번주에는 Vercel AI SDK 7과 Deno 2.9가 정식으로 나왔다. 모델 호출을 연결하는 도구에서 실행과 승인, 관측까지 관리하는 방향이 뚜렷해졌고 Deno는 데스크톱 앱 제작까지 범위를 넓혔다.

Next.js는 16.3에 담길 탐색 성능과 AI 개발 도구를 소개했다. 이번주에는 정식 출시로 받아들이기보다 프리뷰의 기술 방향을 살펴보면 좋겠다. GitHub Actions의 캐시 권한과 OpenAI의 안전성 운영 화면도 함께 정리했다.

6월 22일부터 26일까지의 내용을 다섯가지로 나눠보았다.

| 분야 | 이번주 소식 | 먼저 볼 부분 |
| --- | --- | --- |
| TypeScript·AI | AI SDK 7 GA | 실행 재개·승인·관측과 업그레이드 |
| Runtime | Deno 2.9 | 실험적 데스크톱과 잠금 파일 |
| 프론트엔드 | Next.js 16.3 기술 소개 | 탐색 반응성과 Agent의 검증 흐름 |
| CI 보안 | Actions 캐시 읽기 전용 토큰 | 신뢰 경계와 캐시 저장 권한 |
| AI 운영 | Safety Usage Dashboard | 사용자 식별과 차단 요청의 해석 |

개인적으로는 기능이 연결되는 속도만큼 중단과 재시작, 실패한 상태를 다루는 방식도 중요해지고 있다고 느낀다. 한번 성공하는 데모를 넘어 반복해서 운영할 수 있어야하기 때문이다.

# 1. TypeScript·AI — AI SDK 7은 실행과 승인, 관측을 함께 다룬다

6월 25일 [AI SDK 7](https://vercel.com/changelog/ai-sdk-7)이 정식 출시됐다. `WorkflowAgent`를 통한 지속 실행과 도구 호출 승인, MCP Apps와 외부 하네스 연결, OpenTelemetry 관련 기능이 확대됐다.

업그레이드 조건도 확인해야한다. Node.js 22 이상과 ESM이 필요하며 CommonJS의 `require()`를 그대로 사용하는 구성은 검토가 필요하다. 개발 PC뿐 아니라 CI와 배포 환경까지 같은 기준으로 살펴봐야겠다.

## 지속 실행은 멈춘 작업의 상태를 보존하는 문제다

여러 단계를 거치는 Agent는 한 HTTP 요청의 수명보다 오래 실행될 수 있다. 외부 응답을 기다리거나 사람이 승인하는 동안 프로세스가 재시작될 수도 있다.

`WorkflowAgent`는 이런 작업을 이어가기 위한 기반을 제공한다. 실제 애플리케이션에서는 무엇을 완료 상태로 저장하고 어디서 다시 시작할지 업무의 의미와 연결해야한다.

```text
장기 작업의 예시
자료 조회 → 변경안 생성 → 승인 대기 → 외부 반영 → 결과 확인
```

예를 들어 외부 시스템에 주문을 생성한 직후 프로세스가 종료됐다고 생각해보자. 작업을 재개할 수 있어도 주문을 다시 만드는것이 맞는지는 별도로 판단해야한다.

실행 상태를 저장하는것과 외부 부수 효과를 한번만 반영하는것은 다른 보장이다. 도구에 작업 식별자를 전달하고 이미 반영된 결과를 확인하는 방식이 필요할 수 있다.

중간에 실패한 사례를 시험할때는 각 단계 사이에서 의도적으로 중단해보면 좋겠다. 처음부터 끝까지 정상 실행한 결과만으로는 재개 동작의 정확성을 알기 어렵다.

## 승인은 사람이 확인한 내용과 실제 실행을 연결해야한다

도구 실행 전에 사용자에게 승인을 받는 기능은 상태를 바꾸는 작업에서 도움이 된다. 다만 승인 창에 보여준 대상과 실제 도구 인자가 같아야 의미가 있다.

사용자가 승인한 뒤 작업을 재개하기까지 시간이 흐르면 권한과 대상 상태가 달라질 수 있다. 계속 실행해도 되는지 다시 확인할 조건을 정해야겠다.

```text
승인의 연결
실행 대상·변경 내용 표시
  → 사용자 판단
  → 재개 시 조건 확인
  → 같은 내용의 도구 실행
```

모든 조회까지 같은 승인 절차에 넣으면 중요한 변경도 습관적으로 통과시킬 수 있다. 실제 영향과 되돌릴 수 있는 범위를 기준으로 승인할 동작을 구분하고 싶다.

승인을 거절하거나 작업을 취소한 경우도 정상적인 종료 상태로 다뤄야한다. 사용자가 거절한 작업을 기술 오류처럼 계속 재시도하면 안되겠다.

## 관측 데이터는 최종 답변과 실제 실행을 연결한다

긴 작업에서는 모델과 도구 중 어느 단계가 시간을 사용했는지 알아야한다. 전체 소요 시간만 보면 모델 변경이 효과가 있는지조차 판단하기 어려울 수 있다.

Trace와 단계별 기록을 남길때는 같은 작업을 묶을 식별 정보가 필요하다. 재시작 전후의 실행과 승인 대기, 외부 도구 결과가 연결되어야 원인을 찾기 쉽다.

개인정보와 도구 결과 전체를 무조건 기록할 필요는 없다. 상태와 시간, 실패 분류만으로 확인할 수 있는 부분을 먼저 정하고 필요한 원문의 범위를 줄이면 좋겠다.

새 버전의 이름 변경을 자동으로 처리하더라도 이런 실행 의미까지 도구가 결정해주지는 않는다. 코드 변환 후에는 스트리밍과 여러 단계의 결과를 실제 사용자 흐름에서 확인해야겠다.

# 2. Runtime — Deno 2.9에 데스크톱 제작과 잠금 파일 연결이 들어왔다

6월 25일 [Deno 2.9](https://deno.com/blog/v2.9)가 나왔다. 웹 기술로 네이티브 데스크톱 애플리케이션을 만드는 `deno desktop`이 소개됐고 `deno install`은 npm·pnpm·Yarn·Bun의 잠금 파일을 읽을 수 있게 됐다.

Runtime의 정식 버전과 개별 기능의 상태는 구분해야한다. `deno desktop`은 이번 버전에서 실험적 기능이다. 기존 데스크톱 앱을 바로 대체한다고 보기보다 작은 앱을 만들어 동작과 배포 조건을 확인하면 좋겠다.

## 웹 화면이 열리는것과 데스크톱 제품이 완성되는것은 다르다

데스크톱 앱은 웹 화면과 함께 로컬 파일과 창, 프로세스의 생명주기를 다룬다. 서버에서만 실행하던 코드를 로컬에 배포하면 사용자의 환경이 새로운 실행 조건이 된다.

개발 중 창이 열리는것부터 설치 후 실행과 종료, 다시 실행했을때의 데이터 보존까지 나눠 확인할 수 있다. 개발 PC에는 이미 있는 도구가 사용자 PC에는 없을 수도 있다.

```text
데스크톱 앱에서 볼 경계
웹 UI ↔ 로컬 실행 기능 ↔ 파일·운영체제 ↔ 배포와 업데이트
```

특히 UI에서 로컬 기능을 호출하는 통로는 허용할 작업을 좁히면 좋겠다. 화면에 표시한 외부 콘텐츠가 곧 로컬 명령을 실행할 권한을 얻지 않도록 구분해야한다.

사용자가 파일을 선택하는 기능과 앱이 임의의 경로를 읽는 기능도 다른 요구다. 필요한 권한을 기능에 맞게 설명하고 오류가 났을때 처리할 방법을 준비해야겠다.

개인적으로는 개인용 도구처럼 범위가 작은 앱에서 먼저 비교하고 싶다. 제작 편의뿐 아니라 배포 크기와 시작 시간, 사용 중 메모리와 지원 플랫폼도 실제 선택에 영향을 준다.

## 잠금 파일을 읽는 기능은 전환의 출발점을 줄여준다

기존 프로젝트를 다른 Runtime에서 시험할때 의존성을 다시 정리하는 작업은 부담이 된다. 기존 잠금 파일을 활용할 수 있으면 같은 프로젝트를 비교할 출발점을 만들기 쉬워진다.

다만 파일을 읽었다는 사실만으로 설치와 실행의 모든 의미가 동일하다고 가정할 수는 없다. 스크립트와 네이티브 모듈, 플랫폼별 의존성과 모노레포 구성을 함께 확인하면 좋겠다.

시험할때는 원래 잠금 파일을 보존하고 다른 환경에서 어떤 파일이 생성되거나 바뀌었는지 보면 된다. 변경 내용이 실제 의존성 변경인지 관리 형식의 차이인지 구분하는것이다.

설치가 끝난 뒤에는 애플리케이션의 실행과 빌드, 테스트를 이어서 확인해야한다. 패키지 목록이 준비됐다는것과 서비스가 같은 동작을 한다는것은 다른 검증이다.

전환 중에는 로컬과 CI가 어떤 Runtime과 잠금 파일을 쓰는지도 명확히 두고싶다. 각자 다른 방식으로 버전을 해석하면 문제를 재현하기 어려워질 수 있다.

# 3. 프론트엔드 — Next.js 16.3은 탐색과 개발 피드백의 방향을 소개했다

6월 25일 [Instant Navigations](https://nextjs.org/blog/next-16-3-instant-navigations), 26일 [AI 개발 도구 개선](https://nextjs.org/blog/next-16-3-ai-improvements)이 소개됐다. 이번주 기준 16.3 프리뷰의 기능 소개이며 정식 출시로 적지 않는게 맞겠다.

사용자에게는 빠르게 반응하는 탐색을, 개발자와 Agent에게는 수정할 근거와 검증할 정보를 제공하는 흐름이다. 두가지 모두 기다리는 동안 무엇이 보이는지를 개선한다는 공통점이 있다.

## 빠른 화면 전환은 모든 데이터의 즉시 완료와 다르다

링크를 클릭한 뒤 다음 화면의 틀이 먼저 보이면 사용자는 이동이 시작됐음을 알 수 있다. 아직 필요한 데이터가 도착하지 않았더라도 아무 반응이 없는 상태보다 진행 상황을 이해하기 쉽다.

여기서 화면의 틀과 데이터가 도착하는 시점을 나눠봐야한다. 빠르게 보인 로딩 상태를 데이터까지 모두 준비된 상태로 측정하면 성능 비교가 왜곡될 수 있다.

```text
탐색의 시간 나누기
클릭 → 다음 화면의 첫 반응 → 주요 데이터 표시 → 실제 조작 가능
```

상품 목록처럼 이전 데이터를 잠시 보여줄 수 있는 화면과 결제 결과처럼 최신 상태가 중요한 화면은 캐시 요구가 다르다. 빠르게 보이는것과 정확한 데이터를 보여주는것을 함께 설계해야겠다.

사용자가 기다리는 구간을 스트리밍으로 나눌지, 재사용 가능한 부분을 캐시할지, 전체 결과를 기다리게 할지는 제품의 선택이다. 도구가 선택지를 제공해도 화면의 의미는 개발자가 판단해야한다.

## 탐색은 진입 경로를 바꿔가며 확인하자

같은 페이지도 직접 URL을 열때와 내부 링크로 이동할때 동작이 다를 수 있다. 이미 준비된 데이터와 캐시, 이전 화면의 상태가 다르기 때문이다.

로그인 전후와 권한이 바뀐 뒤, 뒤로 가기와 연속 클릭도 시험해볼 수 있다. 한번 빠르게 이동한 장면만으로 모든 경로가 개선됐다고 판단하지 않는게 좋겠다.

느린 네트워크에서는 로딩 영역의 배치와 크기도 중요하다. 내용이 도착할때 화면이 크게 밀리거나 사용자가 클릭하려던 위치가 바뀌지 않는지 확인해야한다.

개인적으로는 실제 사용자가 자주 이동하는 두세 경로부터 기록하고 싶다. 대표 경로에서 첫 반응과 데이터 표시를 구분해 보면 무엇이 좋아졌는지 설명하기 쉽다.

## Agent에게 제공하는 오류도 검증으로 이어져야한다

이번 소개에는 오류를 수정할 문맥과 프롬프트, 프로젝트 버전에 맞는 문서와 개발 도구의 연결이 담겼다. Agent가 오래된 지식으로 설정을 추측하는 일을 줄이는 방향이다.

오류 메시지를 읽고 코드를 수정한 뒤에는 다시 화면을 확인해야한다. 경고가 사라져도 잘못된 데이터를 캐시하거나 필요한 로딩 상태를 없앴을 수 있기 때문이다.

```text
개발 피드백의 연결
실제 오류 → 해당 버전의 설명 → 수정 → 브라우저에서 다시 확인
```

빌드와 타입 검사가 통과한것도 중요한 근거지만 실제 탐색의 완료를 모두 보여주지는 않는다. 서버 로그와 네트워크, 화면의 데이터가 같은 요청에서 맞는지 확인하면 좋겠다.

Agent가 제안한 수정이 렌더링 방식과 데이터의 최신성 중 무엇을 바꿨는지도 리뷰해야한다. 성능 경고를 없애는 일과 우리 제품에 적절한 선택을 하는 일은 다를 수 있다.

# 4. CI 보안 — 신뢰하지 않는 트리거의 캐시 쓰기 권한이 줄었다

6월 26일 [GitHub Actions 캐시 권한](https://github.blog/changelog/2026-06-26-read-only-actions-cache-for-untrusted-triggers/)이 강화됐다. 외부 사용자가 유발할 수 있는 신뢰하지 않는 이벤트와 기본 브랜치의 실행·캐시 범위가 함께 적용되는 경우 읽기 전용 토큰을 사용한다.

외부 영향을 받은 실행이 캐시를 오염시키고 더 높은 권한의 워크플로가 그 내용을 복원하는 경로를 줄이려는 변경이다. 모든 PR의 캐시가 일괄적으로 읽기 전용이 되는것으로 이해하면 안되겠다.

## 캐시도 다음 실행에 들어가는 입력이다

캐시는 설치와 빌드를 빨리 하기 위한 데이터지만 이후 작업이 복원해 사용한다. 누가 그 내용을 만들 수 있는지에 따라 신뢰할 수 있는 범위가 달라진다.

예를 들어 낮은 권한의 작업이 만든 파일을 배포 작업이 실행한다면 두 작업은 캐시를 통해 연결된다. 워크플로 파일이 분리돼 있다는 사실만으로 데이터의 경계가 분리된것은 아니다.

```text
캐시를 볼때의 질문
누가 저장하는가 → 어떤 키와 범위인가 → 누가 복원하는가 → 무엇에 쓰는가
```

패키지 캐시와 빌드 산출물, 실제 배포할 결과를 구분하면 좋겠다. 같은 저장 수단을 사용해도 다음 실행에서 수행하는 역할과 필요한 신뢰 수준은 다를 수 있다.

기본 브랜치와 외부 PR, 댓글 이벤트와 후속 실행의 관계를 그려보면 예상하지 못한 연결을 찾을 수 있다. 각각의 토큰 권한뿐 아니라 서로 전달하는 데이터도 확인하는것이다.

## 저장이 막힌 경고와 빌드 실패를 구분하자

이번 변경에서 제한된 캐시 저장은 경고를 남기고 작업은 계속 진행할 수 있다. 캐시 복원은 영향을 받지 않는다. 로그를 볼때 저장 경고를 곧바로 애플리케이션 오류로 해석하지 않도록 해야겠다.

캐시가 저장되지 않아 느려졌다면 현재 이벤트의 신뢰 범위부터 확인할 수 있다. 편의를 위해 다시 권한을 넓히기보다 신뢰할 수 있는 작업에서 캐시를 준비하는 구성을 검토하면 좋겠다.

실제 검증은 캐시가 있는 실행과 없는 실행을 둘다 포함하고 싶다. 캐시가 없어도 빌드가 정확히 동작해야하고, 복원한 데이터가 현재 의존성과 맞는지도 확인해야한다.

# 5. AI 운영 — Safety Usage Dashboard에서 차단 요청을 볼 수 있다

6월 23일 [OpenAI Safety Usage Dashboard](https://developers.openai.com/api/docs/changelog)가 공개됐다. 요청에 전달한 `safety_identifier`를 기준으로 차단된 Responses API 요청을 확인하는 기능이다.

사용자별 문제를 살펴볼 단서가 생기지만 이 화면의 수치를 전체 서비스의 모든 요청과 동일한 지표로 받아들이지는 않는게 좋겠다. 어떤 요청이 어떤 식별 값으로 전달됐는지 먼저 알아야한다.

## 식별 값은 같은 사용자의 요청을 연결하는 기준이다

사용자를 구분하는 값이 요청마다 달라지면 반복되는 문제를 연결하기 어렵다. 반대로 서로 다른 사용자가 같은 값을 공유하면 한 사용자의 행동처럼 보일 수 있다.

이메일 같은 원문 정보를 그대로 넣기보다 서비스에서 안정적으로 구분할 수 있는 값을 설계하면 좋겠다. 계정과 세션, 익명 사용자의 구분 기준도 우리 서비스에 맞게 정해야한다.

API 호출을 여러 서버나 작업자가 나눠 수행한다면 공통 래퍼에서 전달 여부를 확인할 수 있다. 일부 경로만 식별 값을 보내면 같은 서비스의 지표도 범위가 달라질 수 있기 때문이다.

개인적으로는 운영 화면을 보기 전에 대표 요청 하나가 어떤 값으로 보내지는지 먼저 확인하고 싶다. 수치를 해석할 출발점이 요청에 있기 때문이다.

## 차단 기록은 애플리케이션의 처리 결과와 연결하자

차단된 요청을 찾았더라도 사용자에게 어떤 화면을 보여줬는지와 후속 작업이 실행됐는지 함께 확인해야한다. API의 결과와 제품의 동작이 다른 계층에 남아있을 수 있다.

시간 범위와 요청 식별 정보를 연결하면 사용자 신고를 조사하기 쉬워진다. 전체 입력을 다시 저장하지 않아도 필요한 관계를 남길 방법을 생각해볼 수 있다.

오류와 정책 차단, 사용자의 취소를 구분해 기록하는것도 중요하다. 서로 다른 상태를 모두 실패율 하나로 합치면 개선해야할 원인을 찾기 어려워진다.

# 6. 이번주에는 재개와 캐시의 경계를 시험해보자

이번주 소식을 프로젝트에 적용한다면 정상 경로와 함께 중단된 경로를 확인하고 싶다. 승인 대기 후 재시작, 캐시 없는 빌드, 느린 탐색처럼 평소 데모에서 생략하기 쉬운 조건이다.

| 대상 | 확인할 사례 |
| --- | --- |
| Agent 실행 | 외부 반영 직후 중단하고 재개 |
| 승인 | 거절·취소·대기 중 권한 변경 |
| Deno 전환 | 잠금 파일 보존과 실제 앱 실행 |
| 탐색 | 직접 진입·내부 이동·느린 응답 |
| CI 캐시 | 저장 불가와 캐시 미존재 |
| 안전성 지표 | 식별 값과 실제 사용자 처리 결과 |

# 마무리

이번주는 AI SDK 7이 실행과 승인, 관측을 넓혔고 Deno는 개발 도구와 앱 배포의 영역을 확장했다. Next.js도 빠른 탐색과 Agent의 개발 피드백을 함께 개선하는 방향을 보여줬다.

동시에 캐시와 안전성 운영 화면은 실행 뒤에 남은 데이터를 어떻게 해석할지 생각하게 한다. 편리하게 재사용하는 데이터일수록 누가 만들고 어디에 사용되는지 알아야겠다.

개인적으로는 이번주에 오래 걸리는 작업 하나를 중간에 멈춰보고 싶다. 다시 실행했을때 무엇이 이어지고 무엇이 반복되는지 알아야 운영에 넣을 수 있을것같다..


[2026.06.26 주간 개발 트렌드] AI SDK 7과 Deno 2.9, Next.js의 다음 변화

독자의 메모