[2026.09.04 주간 개발 트렌드] Agent 보안과 Turbopack Chunking, Actions·npm 공급망

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

# 이번주는 오래 실행되는 Agent의 뒷부분이 궁금해졌다

이번주에는 Agent를 어디서 실행하고, 중간에 멈추면 무엇을 남길지 생각하게 하는 소식이 많았다. Slack은 팀이 Agent 작업을 같이 검토하는 공간을 소개했고, Google Cloud는 오래 살아있는 실행 환경과 격리·장애 시험을 다루는 기능을 내놨다.

8월 24일부터 28일까지의 소식을 정리해보았다.

# 1. AI — 혼자 쓰던 코딩 Agent가 팀의 작업 공간으로 들어온다

8월 24일 [Salesforce의 Slack Code 발표](https://www.salesforce.com/ap/news/press-releases/2026/08/24/salesforce-launches-slack-code-to-make-ai-software-development-multiplayer/)는 프로젝트별 Code Channel에서 개발자와 Agent가 함께 일하는 구성을 소개했다. 대화와 실행 계획, 코드 Diff와 미리보기를 각각 확인할 수 있다.

발표에서는 모든 Slack 플랜에 제공하되 연동하는 파트너 Agent는 별도의 접근 권한이 필요하다고 안내한다. 작업 중 사람이 방향을 바꾸거나 멈출 수 있고, 최종 운영 반영에는 사람의 승인을 요구한다.

## 대화에서 합의한 내용과 실제 변경을 연결해보자

팀에서는 요구사항을 대화로 정했는데 Agent에게 전달하는 과정에서 조건이 빠질 수 있다. 같은 공간에서 계획과 변경 내용을 볼 수 있다면 이런 차이를 확인하기 쉬워지겠다.

```text
팀의 요청 → Agent 계획 → 코드 변경 → 테스트·미리보기 → 검토·승인
```

## 사용률과 실제 위임 범위는 구분해야겠다

[JetBrains의 개발자 조사](https://blog.jetbrains.com/research/2026/08/ai-coding-agent-adoption-2026/)는 15,000명 이상의 전문 개발자를 대상으로 한 결과를 소개했다. 5~7월 기준 주 1회 이상 사용이 90%, 매일 사용이 68%라고 보고한다.

이 수치를 모든 팀이 운영 배포까지 자율 Agent에 맡긴다는 뜻으로 읽지는 않아야겠다. 우리 팀에서는 어떤 작업을 맡겼고 얼마나 수정했는지, 리뷰와 검증에 드는 시간까지 비교해보고 싶다.

27일에는 [WIRED가 Codex의 Persistent mode 시험을 보도](https://www.wired.com/story/openai-is-developing-a-persistent-ai-agent/)했다. 기사에서는 아직 널리 제공되거나 출시 발표된 기능이 아니라고 명시한다. 현재 쓸 수 있는 제품 기능으로 전제하기보다 지속 실행을 탐색하는 소식으로 구분하면 좋겠다.

# 2. 프론트엔드 — Agent에게도 기능의 입구를 설명한다

지난주 20일 [Telerik·Kendo UI 발표](https://investors.progress.com/news-releases/news-release-details/progress-software-announces-new-telerik-and-kendo-ui-release)에는 WebMCP를 통한 Agent 상호작용 지원이 포함됐다. 이번주 새 프레임워크 발표처럼 다루기보다 이어지는 UI 설계의 변화로 보면 좋겠다.

26일 공개된 [Chrome의 WebMCP 도구 설계 문서](https://developer.chrome.com/docs/ai/webmcp/build-tools)는 사용자의 목표와 초기 상태, 필요한 도구를 먼저 정의하도록 설명한다. 버튼을 어디서 누를지만 알려주는것보다 어떤 일을 완료할지 설명하는 접근이다.

## 화면 아래의 업무 기능을 드러내는것이다

예를 들어 주문 목록에서 고객 이름을 찾아 상세 화면을 여는 작업을 생각해보자. Agent가 화면의 위치만 추측하는 대신 검색 조건과 결과 형식이 정의된 기능을 호출할 수 있다.

```text
사람 → 검색 UI ─────┐
                    ├─ 주문 조회 API → 업무 Service
Agent → 웹 도구 ────┘
```

WebMCP는 웹 애플리케이션이 브라우저 Agent에 구조화된 도구를 제공하는 방향이다. 서버 사이의 MCP 연결을 그대로 웹페이지에 옮겼다고 생각하기보다는 실행 문맥을 구분해야겠다.

[Chrome은 Origin Trial로 시험을 제공](https://developer.chrome.com/blog/ai-webmcp-origin-trial)하고 있다. 모든 브라우저에서 이미 동일하게 지원하는 기능으로 전제하지 않고, 지원 환경과 기존 UI 경로를 같이 확인하는 편이 좋겠다.

## Tool 호출 뒤 화면도 같은 상태를 보여줘야한다

검색 도구는 성공했는데 화면에는 예전 필터가 남아있으면 사용자가 결과를 이해하기 어렵다. 도구의 반환값뿐 아니라 선택한 자원과 현재 화면이 어떻게 바뀌는지도 정해야한다.

별도 도구 연결이 없는 경로에서도 사용할 수 있도록 Semantic HTML과 Label, 접근성은 계속 챙겨야겠다.

# 3. 백엔드 — 긴 작업에는 중간 상태가 필요하다

Agent가 문서를 모으고 외부 도구를 호출한 뒤 사람의 확인을 기다린다면 한 HTTP 요청보다 업무가 오래 지속될 수 있다. 이때 Controller에서 응답을 기다리는것만으로 전체 실행을 관리하기는 어렵겠다.

```text
API → 작업 저장·Queue 또는 Workflow → Agent Worker → Tool·업무 DB
```

모든 작은 모델 호출에 Queue가 필요한것은 아니다. 응답 시간과 재실행 비용, 사람이 기다리는 단계가 있는지를 보고 실행을 분리할지 결정하면 좋겠다.

## 프로세스가 다시 시작돼도 다음 행동을 알아야한다

예를 들어 외부 API에 보고서를 저장한 직후 Worker가 종료됐다고 생각해보자. 마지막 저장이 성공했는지 모른 채 처음부터 다시 실행하면 같은 보고서를 두 번 만들 수 있다.

Checkpoint에는 현재 단계뿐 아니라 이미 발생한 외부 변경을 확인할 정보가 필요하다. 요청 ID와 외부 결과 ID를 남기고, 다시 실행할때 실제 상태를 조회하는 방법을 생각할 수 있다.

| 저장할 상태 | 확인하려는 내용 |
| --- | --- |
| 작업 ID·요청 주체 | 누구의 어떤 업무인지 |
| 현재 단계·결과 ID | 어디까지 반영됐는지 |
| 재시도·대기 상태 | 언제 어떤 조건으로 이어갈지 |
| 취소·완료 기록 | 더 실행해도 되는지 |

## 취소와 비용 한도도 작업 전체에서 보자

사용자가 취소를 눌러도 이미 끝난 외부 작업이 자동으로 취소되지는 않는다. 다음 도구 호출을 중단하는것과 기존 변경을 되돌리는 절차를 구분하고 싶다.

비용도 모델 요청 한 번으로 끝나지 않는다. 반복 호출과 실패한 재시도, Sandbox 실행 시간과 저장 공간을 작업 단위로 묶어볼 필요가 있다.

내가 확인한다면 반복 횟수와 전체 실행 시간, 동시 작업 수를 함께 제한할것같다. 오래 실행하는 능력과 끝없이 실행하도록 두는것은 다르게 다뤄야겠다.

# 4. Cloud·DevOps — 실행 시간과 격리 수준에 맞는 환경을 고르자

8월 27일 [Cloud Run instances](https://cloud.google.com/blog/products/serverless/introducing-cloud-run-instances)가 Preview로 공개됐다. 자동 확장 없이 하나의 인스턴스를 실행하는 Singleton 환경으로, 지속적인 개인용 Agent 등을 사용 사례로 제시한다.

최대 7일 연속 실행과 기본 자동 재시작 정책을 안내하며, 업데이트와 재시작 뒤에도 같은 HTTPS 주소를 제공한다. 오래 실행할 수 있어도 프로세스가 영원히 유지된다고 가정하지 않아야겠다.

## 실행 모델과 데이터 수명은 따로 정하자

요청 중심의 자동 확장 서비스와 단일 지속 실행 환경은 운영 방식이 다르다. 다만 모든 Agent를 Singleton으로 만들어야한다는 규칙은 아니다.

짧은 작업과 독립적인 병렬 작업, 사용자별로 계속 살아있는 작업은 필요한 구조가 다르다. 동시성 요구와 복구 방식에 따라 실행 환경을 고르면 좋겠다.

발표의 비용 예시는 1 vCPU·1GiB를 30일 계속 실행할때 5.70달러이며 공유 CPU와 Burst 예산을 사용한다. 모델 호출과 저장소, 네트워크 등을 포함한 Agent 전체 비용과는 구분해야한다.

## Ray Sandbox는 실험적 라이브러리다

25일 [Google Cloud와 Anyscale의 Ray Sandboxing 소개](https://cloud.google.com/blog/products/containers-kubernetes/gvisor-sandboxes-for-ray-clusters-on-gke)는 gVisor를 이용한 실험적 라이브러리를 설명한다. Ray Actor가 수명을 관리하고 Scheduler가 자원을 배치하는 구성이다.

CPU·메모리와 네트워크 설정 등을 다루며 gVisor가 호스트 커널과의 사이에 추가 격리 경계를 제공한다. 대량의 생성 코드와 Tool 상호작용을 관리하는 사례로 보면 좋겠다.

격리 환경을 쓴다고 그 안에 준 Secret과 네트워크 권한까지 자동으로 안전해지는것은 아니다. 읽기 전용 작업에 운영 쓰기 권한을 넣을 이유가 있는지, 실행이 끝나면 자원을 정리하는지 확인해야겠다.

## 장애를 일으켜 복구를 시험하는 도구도 나왔다

26일 공개된 [Fault Injection Testing Preview](https://cloud.google.com/blog/products/networking/introducing-google-cloud-fault-injection-testing-in-preview)는 Cloud SQL HA Failover와 Application Load Balancer를 통한 지연·HTTP 오류 주입을 지원한다.

대상을 확인하는 Dry Run과 중단·되돌리기 기능이 있으며, Google은 Preview에서 비운영 환경 사용을 권한다. 모든 종류의 장애를 자동 검증하는 서비스로 이해하지는 않아야겠다.

# 5. CI — 프로젝트 Node 버전과 Action 런타임은 다르다

8월 25일 수정된 [GitHub Actions의 Node 20 종료 안내](https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/)는 Runner의 Node 20 제거일을 9월 23일로 변경했다. JavaScript Action을 Node 24로 옮기는 흐름이다.

여기서 `setup-node`로 설치한 프로젝트의 Node와 Action 자체를 실행하는 Node는 구분해야한다. 프로젝트를 새 버전으로 빌드한다고 사용 중인 모든 Action의 실행 런타임까지 바뀌는것은 아니다.

```text
Action 내부 런타임: action.yml의 runs.using 등
프로젝트 런타임: setup-node·버전 파일·실제 빌드 명령
```

우리 CI에서는 사용하는 Action과 재사용 Workflow의 버전을 먼저 정리하면 좋겠다. Node 24를 지원하는 버전인지 확인하고, Major 업데이트의 입력값과 출력값 변경도 검토해야한다.

Self-hosted Runner라면 Runner 버전과 OS·아키텍처 호환성도 볼 부분이다. 공식 안내에는 구형 macOS와 ARM32 관련 제약도 포함된다.

# 6. 데이터 — Agent 상태의 보존 기준부터 정하자

8월 24일 [Redis의 HIMPORT 소개](https://redis.io/blog/efficient-bulk-hash-insertion-with-redis-810s-himport/)는 Redis 8.10의 대량 Hash 적재를 다룬다. 같은 필드 이름을 반복 전송하는 부담을 줄이기 위해 필드 집합을 준비하는 방식이다.

준비한 필드 집합은 해당 연결에만 유효하므로 재연결과 Connection Pool을 사용하는 경우를 확인해야한다. 기능 소개일을 Redis 8.10 전체의 출시일과 같은 의미로 보지는 않아야겠다.

26일에는 [MongoDB Atlas의 Cloud Foundation Fabric 연동](https://www.mongodb.com/company/blog/technical/mongodb-atlas-joins-google-cloud-foundation-fabric-fast-secure-private-data-infrastructure-minutes)이 소개됐다. Terraform 기반 클라우드 기반 환경에 Atlas를 구성하는 모듈과 Private Service Connect 연결을 설명한다.

## 영속 업무 상태를 임시 캐시처럼 다루지 말자

Agent 상태라고 모두 Redis에 넣어야하는것은 아니다. 결제 처리 여부와 승인 기록처럼 잃어버리면 안되는 정보는 영속성과 복구 기준을 먼저 정해야한다.

PostgreSQL에 업무 상태를 두고 Redis를 짧은 수명의 진행 표시나 캐시에 사용하는 구성을 생각할 수 있다. Redis를 영속 저장이나 Queue로 쓴다면 그에 맞는 보존·복제·재처리 정책이 필요하다.

의미 검색이 필요해 임베딩을 추가한다면 원본의 갱신·삭제 기준도 같이 맞춰야겠다.

# 이번주에는 재시작해도 이어지는 작은 작업을 만들어보고 싶다

중간에 Worker를 멈췄다가 다시 실행해보면 좋겠다. 이미 끝난 일을 반복하는지와 취소한 작업을 이어가는지 확인하는것이다.

Agent가 오래 일할 수 있게 될수록 잘 멈추고 정확하게 이어가는 설계가 중요해지는것같다. 이번주는 실행 시간을 늘리는 기능과 그 시간을 책임질 운영 구조를 같이 봐야겠다..


[2026.08.28 주간 개발 트렌드] Slack Code와 지속 실행 Agent, Cloud Run·Sandbox·CI

독자의 메모