[2026.09.11 주간 개발 트렌드] Agent 권한 통제와 React 19.3, Kubernetes 작업 스케줄링

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

# 이번주는 Agent가 실행하는 코드의 출처를 봐야겠다

이번주에는 모델의 성능보다 Agent가 개발자 PC에서 실제로 무엇을 실행하는지가 더 신경쓰였다. 저장소의 상태를 확인하는 평범한 Git 호출도 설정에 따라 다른 프로그램을 실행할 수 있다는 연구가 공개됐다.

GitHub Actions와 npm에서는 실행한 Workflow의 출처와 배포 권한을 더 구체적으로 관리하는 변화가 나왔다. 프론트엔드에서는 Turbopack의 Chunking 설명과 지난주 보안 패치를 함께 챙기면 좋겠다.

8월 31일부터 9월 4일까지의 소식이다. 새 기능을 켜는것보다 현재 쓰는 도구의 버전과 입력, 실행 권한을 먼저 확인할 주로 보인다.

# 1. AI·보안 — 저장소를 읽는 단계에서도 코드가 실행될 수 있다

이번주 공개된 [Manifold Security의 GitSpawn 연구](https://www.manifold.security/blog/ai-coding-agents-git-hijack)는 여러 CLI Coding Agent가 저장소 문맥을 수집하는 과정의 취약점을 설명한다. 모델이 위험한 명령을 선택한 상황보다 그 아래의 도구 실행 경로가 핵심이다.

일부 Agent는 시작하거나 변경 파일을 확인하면서 Git을 내부 프로세스로 호출했다. 이때 저장소의 로컬 설정에 지정된 프로그램이 사용자 권한으로 실행될 수 있었고, 연구에서는 Sandbox와 승인 경로 밖에서 실행되는 사례를 확인했다.

## 일반적인 Git Clone과 폴더 전달은 구분해야한다

핵심 조건은 공격자가 준비한 `.git/config`가 함께 전달되는것이다. 압축파일과 공유 드라이브, 동기화 폴더처럼 `.git`을 보존한 채 디렉터리를 전달하는 경우를 생각할 수 있다.

일반 `git clone`은 원본 저장소의 로컬 `.git/config`를 그대로 가져오지 않는다. 따라서 이번 공격 경로를 모든 원격 저장소의 Clone에 동일하게 적용되는 문제처럼 설명하면 부정확하다.

```text
받은 프로젝트 폴더의 로컬 Git 설정
  → Agent의 백그라운드 Git 호출
  → Git이 지정된 외부 프로그램 실행
  → 실행 사용자의 파일·자격 증명에 접근 가능
```

그렇다고 Clone한 프로젝트의 설치 Script와 실행 코드까지 안전하다는 뜻은 아니다. 이번 취약점의 유입 조건과 프로젝트 코드를 실행할때의 일반적인 위험은 따로 봐야겠다.

## 공개 시점에도 제품과 경로별 상태가 달랐다

연구진은 9월 1일 재검증 기준 일부 문제가 남아있다고 설명했다. Codex와 Cursor는 패치됐다고 명시했고, Claude Code도 한 경로의 수정과 별도의 미해결 경로를 구분했다.

CLI와 데스크톱 앱의 버전, 실제 실행 기능별 공지를 확인해야겠다. 제품 이름만으로 패치 여부를 판단할 수는 없다.

Codex의 경우 [Git 메타데이터 조회 수정 PR](https://github.com/openai/codex/pull/22652)에서도 저장소의 `core.fsmonitor` 설정과 내부 조회 프로세스를 분리하는 변경을 확인할 수 있다. 명령의 이름뿐 아니라 그 명령이 어떤 설정을 읽는지가 중요하다는 사례다.

## 격리는 시작 프로세스부터 적용해야겠다

내가 환경을 점검한다면 Agent가 띄운 Tool만 격리하는지, Agent와 그 백그라운드 프로세스도 같은 경계 안에 있는지 먼저 보고 싶다. Shell Tool에만 정책을 걸고 내부 Git 호출을 놓치면 기대한 보호가 적용되지 않을 수 있다.

Container나 VM을 사용하더라도 홈 디렉터리와 SSH Agent, 클라우드 자격 증명을 그대로 연결했다면 접근 범위가 넓어진다. 테스트에 필요한 파일과 제한된 계정부터 제공하고 싶다.

# 2. AI 모델 — 비용 절감은 어떤 요청에서 생기는지 보자

9월 1일 [GitHub Copilot의 Claude Fable 5.1 제공](https://github.blog/changelog/2026-09-01-claude-fable-5-1-generally-available-in-github-copilot/)이 발표됐다. 장시간의 코딩과 지식 작업을 대상으로 소개하며, 플랜과 조직 정책에 따라 사용 가능 여부를 확인하도록 안내한다.

[Anthropic의 Fable 5.1·Mythos 5.1 설명](https://www.anthropic.com/claude-fable-and-mythos-5-1)에서 비용과 관련해 눈에 띄는 부분은 캐시 읽기 가격 변화다. 일반적인 작업은 약 25%, Agent 사용이 많은 작업은 최대 약 45%의 절감을 추정한다.

모든 입력과 출력 토큰의 단가가 똑같이 45% 내려간다는 의미는 아니다. 긴 문맥을 얼마나 재사용하는지와 새로 생성하는 출력의 비중에 따라 우리 작업의 절감 폭은 다를 수 있다.

## 성공한 작업 하나의 비용으로 비교해보고 싶다

모델 요청 비용과 함께 실행 시간, 검토 수정량과 성공률을 기록해보면 좋겠다. 결과가 틀려 다시 수행한 작업까지 포함해야 실제로 위임할만한지 판단할 수 있다.

Copilot 공지는 Fable 5.1의 기본 데이터 보존 요구와 일부 기업 고객의 예외도 별도로 설명한다. 팀에 도입할때는 가격과 성능 외에 사용하는 경로의 데이터 처리 조건도 같이 확인해야겠다.

# 3. 프론트엔드 — Turbopack은 어떤 코드를 같이 내려줄지 다룬다

9월 3일 [Next.js의 Turbopack Chunking 글](https://nextjs.org/blog/turbopack-chunking)이 공개됐다. Next.js 16.3 이상에서 시험할 수 있는 실험적 기능과 코드 분할의 절충점을 설명한다.

방문자가 이미 가져온 코드를 활용하는 Chunk 요청, 실제 탐색 패턴을 반영한 그룹화, 공통 Runtime과 CJS Tree Shaking 등이 소개됐다. 이번주 새 정식 메이저 버전이 나온것으로 이해하지는 않아야겠다.

## 초기 로딩과 다음 화면 이동은 다른 측정이다

상품 소개 화면과 통계 대시보드를 같은 애플리케이션에서 제공한다고 생각해보자. 첫 화면에서 무거운 차트 코드까지 가져오면 불필요한 전송이 생길 수 있다.

반대로 모든 모듈을 잘게 나누는것만으로 해결되지는 않는다. 요청 수와 압축 효율, 여러 화면에서 공유하는 코드의 재사용도 같이 고려해야하기 때문이다.

```text
첫 화면: 지금 필요한 코드가 얼마나 내려오는가
화면 이동: 이미 받은 코드를 얼마나 다시 활용하는가
전체 경로: 요청 수·전송량·실제 대기 시간이 어떻게 변하는가
```

내가 비교한다면 첫 방문과 자주 사용하는 이동 경로를 따로 기록할것같다. 개발 서버의 체감 속도만 보기보다 Production Build를 같은 조건으로 비교하고 싶다.

## 옵션을 한 번에 모두 켜지는 말자

소개된 `experimental.turbopackChunking` 설정에는 첫 페이지의 우선순위와 중요한 Route, 함께 방문하는 Route 묶음 등을 전달하는 옵션이 있다.

Analytics가 있다면 사용자가 실제로 이동하는 경로를 기준으로 검토할 수 있겠다. 추측으로 그룹을 많이 추가하기보다 기본 동작을 측정하고 필요한 부분부터 바꿔보는 편이 좋겠다.

## 아직 적용하지 않았다면 지난주 보안 패치가 우선이다

[8월 25일 Next.js 보안 릴리스](https://nextjs.org/blog/august-2026-security-release)는 16.3.3과 15.5.24에서 Critical 문제 두 건을 다뤘다. 이번주 새 Chunking 실험보다 운영 버전의 패치 여부를 먼저 확인하고 싶다.

하나는 공격자가 제어하는 AVIF 이미지를 최적화할때의 기반 라이브러리 문제다. 해당 패치에서는 상위 라이브러리 수정이 반영될때까지 AVIF 최적화를 비활성화한다.

다른 하나는 Windows 파일 시스템을 사용하는 서버에서 특정 Pages Router·App Router 조합에 영향을 주는 문제다. 공식 설명은 Cache Components를 사용하지 않는 구성을 명시하며 Linux와 macOS는 이 두 번째 문제의 대상이 아니라고 안내한다.

운영 OS만 보고 전체 릴리스와 무관하다고 판단하지 않고 이미지 처리와 Router 구성도 확인해야겠다. 설치한 버전과 실제 배포된 Artifact의 버전이 같은지도 점검할 부분이다.

# 4. 백엔드 — Worker의 실행 권한과 업무 권한은 다르다

이번주 보안 소식을 백엔드 설계에 연결한다면 Agent Worker가 실행할 수 있는 기능을 다시 보고 싶다. Queue로 비동기 실행을 분리해도 Worker에 준 운영 권한이 자동으로 줄어들지는 않는다.

```text
API → Queue·Workflow → Agent Worker → Tool·MCP → 업무 Service → DB
```

짧은 요청은 동기 호출로 충분할 수 있다. 실행 시간과 재시도, 확인 대기 때문에 작업의 수명을 분리해야할때 위 구조를 검토하면 좋겠다.

## 허용된 Tool이어도 모든 자원에 접근하면 안된다

Tool Allowlist는 사용할 수 있는 기능을 좁히는 기준이다. 그 기능으로 현재 사용자가 다른 조직의 주문을 조회해도 되는지는 Service에서 다시 판단해야한다.

모델이 입력한 조직 ID와 인증된 요청 주체를 구분하고, 쓰기 작업에는 대상과 반영할 내용을 명확히 남겨야겠다. 입력 스키마가 맞다는것만으로 업무 요청이 허용되는것은 아니다.

외부 응답이 늦어 다시 실행하는 경우에도 동일 요청이 이미 반영됐는지 확인할 수 있어야한다. 작업 ID와 외부 결과 ID, 처리 상태를 연결하면 재시도 뒤의 판단에 도움이 되겠다.

작업을 요청한 사용자와 실제 사용한 권한, Tool 호출과 변경 결과를 연결하고 싶다. 모델이 완료라고 답한것과 DB의 상태 변경이 끝난것도 구분해서 기록해야한다.

# 5. DevOps — 공통 Workflow가 어디서 실행됐는지 확인한다

9월 3일 [GitHub Actions 업데이트](https://github.blog/changelog/2026-09-03-github-actions-early-september-2026-updates/)에는 Runner 지원 종료 조회 API와 Dependabot Alert 읽기 권한, Reusable Workflow의 출처를 확인하는 Context가 추가됐다.

Runner API는 등록 지원 종료와 실행 지원 종료를 나눠 반환한다. Self-hosted Runner를 운영한다면 버전 목록과 종료 일정을 연결해 업그레이드 순서를 정하는데 활용할 수 있겠다.

## 최소 권한을 항목별로 선언할 수 있다

새 `vulnerability-alerts` 권한은 `read`와 `none`을 지원한다. 취약점 알림을 읽는 Workflow에 더 넓은 권한의 토큰을 따로 주는 대신 필요한 접근을 지정할 수 있다.

```yaml
permissions:
  contents: read
  vulnerability-alerts: read
```

코드와 Alert 조회가 필요한 경우의 예시다. 쓰기와 배포 권한은 필요한 Job에만 별도로 지정해야겠다.

## 호출한 저장소와 Job을 정의한 저장소는 다를 수 있다

조직 공통 Workflow를 호출한다면 현재 실행한 Job의 정의가 어느 저장소와 파일에 있는지 확인하고 싶다. 이번에 추가된 값은 아래와 같다.

| Context | 확인할 값 |
| --- | --- |
| `job.workflow_ref` | Job을 정의한 Workflow의 Ref |
| `job.workflow_sha` | 해당 Workflow의 Commit SHA |
| `job.workflow_repository` | 원본 `owner/repo` |
| `job.workflow_file_path` | 저장소 안의 파일 경로 |

이 값은 Job을 정의한 Workflow를 가리킨다. Reusable Workflow에서는 기존 `github.workflow_ref`·`github.workflow_sha`와 다를 수 있고, GitHub Enterprise Server에는 제공되지 않는다고 안내한다.

확인한 출처를 로그에 남기는것과 허용된 출처만 실행하게 강제하는것은 다르다. 조직 정책에 사용한다면 허용할 저장소와 Commit, 변경 검토 기준을 따로 정해야겠다.

## CodeQL 업데이트도 이번주 흐름과 연결된다

같은 날 [CodeQL 2.26.4](https://github.blog/changelog/2026-09-03-codeql-2-26-4-improves-github-actions-security-detections/)는 Go 1.27 지원과 여러 언어의 분석 개선을 알렸다. Java·Kotlin 쪽에는 Spring R2DBC 등의 SQL Injection 분석 모델이 추가됐다.

Actions 분석에서는 해당 이벤트에 실제 존재하는 Actor 필드인지 구분하고, Reusable Workflow의 변경 가능한 참조도 탐지하도록 개선했다.

예전에 Alert가 없던 Workflow에서 새 결과가 나왔다면 단순히 오탐이 늘었다고 판단하지 않아야겠다. 조건문이 읽는 필드가 실제 이벤트에 있는지와 참조가 고정돼있는지 확인해볼 이유가 있다.

# 6. npm — Trusted Publishing 설정은 서로 더해진다

9월 3일 [npm의 복수 Trusted Publishing 설정](https://github.blog/changelog/2026-09-03-multiple-trusted-publishing-configurations-for-npm/)이 정식 제공됐다. 한 패키지에서 안정 버전과 Prerelease, Staging 등에 맞춰 여러 OIDC 구성을 둘 수 있다.

각 설정은 저장소와 Workflow, Environment 조건을 독립적으로 가진다. 들어온 토큰이 하나의 설정에라도 맞으면 허용되며, 설정끼리 서로를 제한하지 않는다.

## 설정을 추가한다고 기존 권한이 좁아지지는 않는다

예를 들어 운영 배포만 허용하는 설정 옆에 시험용 저장소의 직접 배포 설정을 추가했다면 실행 경로가 넓어질 수 있다. 더 엄격한 설정이 다른 설정을 덮어쓴다고 생각하면 안되겠다.

발표에서는 각 설정의 직접 Publish를 별도로 켜도록 하고 Staging 위주 사용을 권한다. 악성코드 검사가 끝나기 전에는 Staged Package를 승인할 수 없도록 바뀐 점도 포함됐다.

OIDC는 장기 토큰을 보관하는 부담을 줄이는 방식이다. 하지만 허용한 Workflow가 잘못된 코드를 배포하면 인증 방식만으로 그것을 막을 수는 없다. 코드 검토와 배포 승인, 실행 권한을 같이 연결해야겠다.

# 7. 데이터베이스 — PostgreSQL 14는 이전 연습을 시작할 시점이다

PostgreSQL에서는 [8월 13일 보안 업데이트](https://www.postgresql.org/about/news/postgresql-186-1711-1615-1519-1424-and-19-beta-3-released-3365/)의 적용 여부와 지원 정책을 계속 챙기면 좋겠다. 18.6·17.11·16.15·15.19·14.24에서 28건의 보안 취약점과 110건 이상의 버그를 수정했다.

같은 공지는 PostgreSQL 14의 지원 종료일을 11월 12일로 안내한다. 이번주 금요일 기준으로 약 10주 남았다. 그날 DB가 갑자기 멈추는것은 아니지만 이후 수정 사항을 계속 받는다는 전제로 운영해서는 안되겠다.

## 목표 버전보다 먼저 호환성을 정리해보자

17이나 18 등 지원되는 버전을 검토한다면 드라이버와 확장, 관리형 서비스의 제공 범위를 먼저 확인하고 싶다. 메이저 이전을 현재 14.x의 유지보수 패치와 같은 작업으로 생각하지 않아야한다.

운영과 비슷한 데이터로 이전 시간을 재고 주요 쿼리와 배치, 백업과 복구를 시험해보자. 확장 모듈의 바이너리와 Collation, 인증 방식처럼 애플리케이션 밖의 조건도 확인할 수 있다.

이전 후 쓸 수 있다는것과 실패했을때 돌아갈 수 있다는것은 다르다. 쓰기 전환 시점과 데이터 차이를 어떻게 처리할지, 허용할 중단 시간을 얼마로 잡을지도 리허설에서 정해야겠다.

지원 종료 직전까지 기다리기보다 실패해볼 시간이 남아있을때 한 번 수행해보는 편이 좋겠다. 업그레이드 절차를 실제 시간과 검증 기록으로 바꾸는것이 이번주의 실무 과제다.

# 이번주는 새 기능보다 실행의 출처와 경계를 먼저 보자

내 개발환경에서는 Agent 버전과 받은 프로젝트의 전달 방식부터 확인하고 싶다. 운영에서는 Next.js 보안 패치와 CI의 실제 Workflow 출처, npm 배포 경로를 차례로 살펴보면 좋겠다.

이번주에는 자동화가 내놓은 결과와 그 결과가 만들어진 경로를 함께 확인해보고 싶다. 편리한 실행을 믿고 쓰려면 이 뒷부분을 이해하는 일이 계속 중요해지는것같다..

이번주는 자동화의 결과와 실행 경로를 같이 확인해보고 싶다. 어떤 설정과 권한으로 만들어진 결과인지 설명할 수 있어야 믿고 사용할 수 있을것같다..


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

독자의 메모