[2026.07.31 주간 개발 트렌드] MCP 새 사양과 Agent 연결, Sandbox·실행 관측

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

# 이번주는 Agent를 실행하는 플랫폼과 운영 기준이 중요해졌다

이번주에는 GitHub Issues의 Agent 자동화 제어와 Copilot Impact Dashboard, Cloudflare의 MCP·Sandbox 업데이트가 나왔다. Agent가 코드 편집을 돕는 도구에서 저장소와 인프라 안의 작업을 수행하는 주체로 넓어지는 흐름이다.

동시에 Next.js에서는 보안 패치가 공개됐다. 새로운 Agent 기능을 공부하는 일도 좋지만 현재 운영 서비스의 취약점을 확인하는것부터 우선순위를 잡아야겠다.

7월 20일부터 24일까지의 내용을 AI와 프론트엔드, 백엔드와 인프라, 데이터 관점으로 나눠 정리해보았다.

| 분야 | 이번주 소식 | 먼저 확인할 부분 |
| --- | --- | --- |
| AI 개발 | Issues 자동화 제어 Preview | 제안·적용과 실제 권한의 차이 |
| 팀 운영 | Copilot Impact Dashboard | 사용 패턴과 품질 지표의 해석 |
| 프론트엔드 | Next.js 보안 릴리스 | 지원 버전과 실제 배포 상태 |
| 백엔드 | Cloudflare·GitHub MCP 개선 | 도구 노출과 프로토콜 호환성 |
| 인프라 | Cloudflare의 Devin Outposts | 실행 격리와 자원·비밀값 관리 |
| DB | PostgreSQL 19 Beta 2 검토 | 운영 데이터와 Agent 문맥의 경계 |

# 1. AI — GitHub Issues에서 Agent의 변경을 검토할 수 있다

7월 23일 [GitHub Issues의 Agent 자동화 제어](https://github.blog/changelog/2026-07-23-agent-automation-controls-in-github-issues-in-public-preview/)가 공개 프리뷰로 나왔다. 라벨과 필드, 이슈 유형과 담당자, 종료 같은 지원 작업에 제안과 신뢰도, 변경 이유를 연결하는 기능이다.

Agent가 어떤 변경을 왜 하려는지 이슈 화면에서 확인할 수 있다. 다만 GitHub도 이 승인 기능을 보안 경계로 설명하지 않는다. 이슈 변경 권한이 있는 Agent는 제안 대신 직접 적용할 수도 있다.

## 제안을 검토하는 화면과 실행 권한은 다르다

자동화를 시작할때는 우선 제안을 보면서 결과를 비교하는 방식이 유용할 수 있다. 잘못된 분류를 바로 반영하기보다 어떤 기준으로 판단했는지 확인하는것이다.

예를 들어 버그 이슈에 라벨을 붙이는 작업과 이슈를 종료하는 작업은 영향이 다르다. 같은 신뢰도라도 되돌릴 수 있는 범위와 누락했을때의 비용을 함께 봐야겠다.

```text
자동화의 두가지 판단
변경 제안이 적절한가 → 검토 화면과 근거
그 변경을 실행할 권한이 있는가 → 서버와 저장소의 접근 정책
```

높은 신뢰도가 실제 정답 확률과 같다고 가정하지는 않는게 좋겠다. 우리 저장소의 이슈에서 올바르게 분류하는지와 어떤 사례에서 잘못 판단하는지 직접 비교해야한다.

## 이슈에서 PR까지 이어지는 과정에 완료 조건을 두자

이슈를 Agent에게 할당했다고 기능 구현이 완료된것은 아니다. 필요한 수정과 테스트, 리뷰와 실제 반영이 각각 다른 상태로 남을 수 있다.

`AGENTS.md`에는 저장소의 빌드 방법과 검증 명령, 지켜야할 구조를 정리하면 좋겠다. 다만 문서에 적은 제약과 실제 토큰의 권한은 별도로 관리해야한다.

테스트도 어떤 명령을 실행했는지와 무슨 결과가 나왔는지 확인할 수 있어야한다. 완료 설명만 있고 실행 근거가 없으면 사람이 다시 처음부터 조사해야할 수 있다.

## Impact Dashboard는 효과를 해석할 출발점이다

7월 22일 [Copilot Impact Dashboard](https://github.blog/changelog/2026-07-22-new-copilot-usage-metrics-impact-dashboard/)도 공개됐다. 관리자가 AI 사용 단계별 집단과 PR 처리량·병합 속도 등의 지표를 살펴보는 화면이다.

사용한 사람과 사용하지 않은 사람의 숫자가 다르다고 그 차이가 전부 AI 때문에 생겼다고 말할 수는 없다. 맡은 업무와 팀 구성, 저장소의 크기가 다를 수 있기 때문이다.

PR 수와 코드 줄 수가 늘어도 오류나 재작업이 함께 늘었는지 확인해야한다. 작은 PR로 나누는 팀과 큰 PR로 모으는 팀도 같은 방식으로 비교하기 어렵다.

개인적으로는 도입 지표에 리뷰 대기와 수정 요청, 배포 후 문제를 함께 연결하고 싶다. 많이 사용했다는 사실과 실제로 일이 더 잘 끝났다는 사실을 구분해서 보는것이다.

# 2. 프론트엔드 — Next.js 사용자는 이번주 보안 패치를 먼저 보자

이번주 공개된 [Next.js 7월 보안 릴리스](https://nextjs.org/blog/july-2026-security-release)는 High 4건과 Medium 5건, 총 9건을 다룬다. 안내된 정식 패치 버전은 16.2.11과 15.5.21이다.

지원 중인 버전 계열과 사용하는 기능에 맞춰 영향 범위를 확인해야한다. 16.3 프리뷰·canary에도 수정 버전이 안내됐지만 보안 업데이트를 이유로 정식 운영 서비스를 프리뷰로 옮길 필요는 없다.

## 취약점의 전제 조건을 현재 구성과 대조하자

이번 수정에는 Server Actions 관련 DoS와 Middleware·Proxy 우회, SSRF와 캐시 혼동 등이 포함됐다. 각각의 영향 조건이 다르므로 제목만 읽고 모든 서비스가 같은 상태라고 판단하지는 않는게 좋겠다.

예를 들어 Middleware·Proxy 우회 항목은 App Router와 Turbopack, 단일 locale 구성이 연결된다. 현재 빌드와 라우팅 설정이 어떤 조합인지 확인할 필요가 있다.

패치를 적용하는것과 애플리케이션의 권한 검사를 설계하는것도 함께 봐야한다. 데이터에 접근하는 서버의 실제 처리 지점에서 사용자의 권한을 검증하는 구조가 중요하다.

## package.json과 실제 배포 버전을 구분하자

`package.json`의 버전 범위만 보고 수정됐다고 판단하기 어렵다. 잠금 파일과 실제 설치 결과, 배포한 산출물이 어떤 버전을 포함하는지 연결해야한다.

```bash
# npm 프로젝트에서 설치된 의존성 확인 예시
npm ls next
```

모노레포라면 앱마다 다른 Next.js 버전을 사용할 수 있다. 저장소 루트의 설정 하나만 바꾸고 모든 서비스가 갱신됐다고 생각하지 않도록 앱 단위로 확인하면 좋겠다.

업데이트 후에는 로그인과 권한, Server Action과 이미지 처리, 요청 캐시 같은 사용 경로를 대표 사례로 시험할 수 있다. 빌드가 통과한것과 실제 요청이 정상 처리되는것은 다른 확인이다.

배포를 마친 뒤에는 실행 중인 버전과 배포 식별 정보를 남기고 싶다. 수정한 코드를 저장소에 올렸지만 이전 인스턴스가 계속 요청을 처리하는 상황도 구분해야하기 때문이다.

## 정기 보안 릴리스는 운영 일정에 넣어두자

Next.js는 지난주 [사전 공지형 보안 릴리스 절차](https://nextjs.org/blog/next-security-release-program)를 소개했다. 월 단위의 예고를 통해 업데이트를 계획할 수 있게 하되 긴급한 문제는 별도 패치로 다루는 방향이다.

이번 일정도 처음 예고 뒤 조정 공지가 있었다. 특정 요일에 무조건 배포된다고 고정하기보다 공지와 실제 패키지 제공 상태를 함께 확인하면 좋겠다.

팀에서는 영향 확인과 업데이트, 회귀 검증과 배포를 누가 맡는지 정해둘 수 있다. 패치가 나올때마다 담당자를 처음 찾는것보다 작은 운영 절차로 만들어두는게 수월하다.

# 3. 백엔드 — MCP의 도구 연결과 업무 권한을 나눠보자

7월 22일 [Cloudflare Agents SDK 업데이트](https://developers.cloudflare.com/changelog/post/2026-07-22-mcp-codemode-updates/)는 같은 도구 목록이 유지되는 연결에서 변환된 MCP 스키마를 재사용하도록 개선했다. 매 Agent turn마다 같은 변환을 반복하는 부담을 줄이는 방향이다.

`@cloudflare/think`에는 `includeMcpTools`도 추가됐다. 다른 방식으로 MCP 도구를 제공하는 경우 Think의 자동 도구 노출을 끌 수 있다. 이 설정이 MCP 연결과 직접 호출 자체를 차단하는것은 아니다.

## 도구 목록에 보이는것과 호출을 허용하는것은 다르다

자동 노출을 줄이면 모델에게 전달하는 도구의 범위를 정리할 수 있다. 하지만 목록에서 감췄다는 사실만으로 다른 경로의 호출까지 막았다고 생각하면 안되겠다.

```text
도구 연결에서 구분할것
발견·노출 → 모델의 선택
인증·권한 → 실행 허용 여부
입력 검증 → 업무적으로 적절한 요청인지
```

예를 들어 고객 조회 도구를 모델에게 하나만 보여주더라도 그 도구가 모든 고객의 데이터를 반환하면 범위가 너무 넓을 수 있다. 사용자와 테넌트의 조건을 서버에서 확인해야한다.

## 기존 Service Layer를 두 인터페이스에서 사용해보자

NestJS와 Spring 프로젝트라면 REST Controller와 MCP Tool이 같은 업무 서비스를 호출하는 구조를 생각해볼 수 있다. HTTP 응답과 도구 응답의 형식은 달라도 핵심 업무 규칙을 중복 구현할 필요는 없다.

```text
REST Controller ─┐
                 ├─ 업무 Service → DB·외부 API
MCP Tool ────────┘
```

공유할 부분은 조회 조건과 권한, 상태 변경의 업무 규칙이다. 각 인터페이스는 입력을 검증하고 현재 사용자의 신원을 전달하며 결과를 적절한 형식으로 변환할 수 있다.

도구 인자에 사용자가 임의로 넣은 테넌트 ID를 그대로 신뢰하지 않는게 좋겠다. 인증된 사용자와 실제 허용된 대상을 연결하는 과정이 필요하다.

## GitHub는 다음 MCP 명세를 먼저 지원했다

7월 23일 [GitHub MCP Server](https://github.blog/changelog/2026-07-23-github-mcp-server-supports-the-next-mcp-specification/)는 다음 MCP 명세의 선지원 소식을 발표했다. 이번주 기준 다음 명세의 공식 공개에 앞선 지원으로 구분해서 보면 좋겠다.

GitHub는 stateless 코어에 맞춰 Redis 세션 의존성을 줄이는 등의 변경을 설명했다. 다만 프로토콜의 연결 상태가 줄어드는것과 애플리케이션이 업무 상태를 저장하지 않아도 되는것은 다른 이야기다.

장기 작업의 진행 상황과 사용자별 권한, 이미 실행한 외부 작업은 여전히 서비스가 관리할 수 있다. 서버 확장과 재시작을 시험할때 이런 상태를 어디서 다시 읽는지 확인해야겠다.

클라이언트와 서버의 SDK 조합도 검증하면 좋겠다. 새 명세를 지원한다는 소식만으로 현재 쓰는 인증과 도구 호출, 오류 처리가 모두 같은 방식으로 동작한다고 가정하지 않는것이다.

# 4. Cloud·DevOps — Agent의 실행 환경이 관리 대상이 됐다

7월 21일 [Devin Outposts의 Cloudflare 실행](https://developers.cloudflare.com/changelog/post/2026-07-21-devin-outposts/)이 소개됐다. 각 Devin 세션이 Cloudflare Containers 기반의 독립된 Sandbox에서 실행되는 구성이다.

코딩 Agent가 패키지를 설치하고 빌드와 테스트, 셸 명령을 실행하려면 실제 작업 공간이 필요하다. 모델의 능력과 별개로 이 환경의 수명과 자원, 접근 정책을 관리해야한다.

## 격리된 환경에도 실행 범위를 정해야한다

Sandbox 안에 있다는 사실만으로 외부 통신과 비밀값의 범위까지 자동으로 적절해지지는 않는다. 저장소를 읽고 의존성을 설치하는 권한과 운영 시스템을 변경하는 권한은 다르다.

작업에 필요한 자격 증명을 좁혀서 전달하고 불필요한 운영 비밀값을 넣지 않는 구성을 검토하면 좋겠다. 세션이 끝났을때 환경과 남은 데이터를 어떻게 정리하는지도 중요하다.

```text
Agent 실행 환경의 흐름
저장소 준비 → 제한된 환경 구성 → 작업 실행 → 결과 수집 → 환경 정리
```

CPU와 메모리, 디스크와 실행 시간도 제한할 수 있어야한다. 잘못된 설치와 반복 명령이 계속 자원을 쓰는 경우에는 모델 요청을 멈추는것과 프로세스를 멈추는것을 함께 다뤄야한다.

Docker와 Kubernetes 경험도 이런 설계에 연결된다. 다만 이 서비스를 사용한다고 별도의 Kubernetes 클러스터까지 반드시 만들어야하는것은 아니다. 필요한 격리와 운영 조건을 기준으로 관리형 환경과 직접 운영을 비교하면 된다.

## 결과물은 실행 환경 밖에서도 검토할 수 있어야한다

임시 환경을 정리하기 전에 패치와 테스트 결과, 필요한 산출물을 가져와야한다. 최종 답변만 있고 실제 변경이 남아있지 않으면 검토를 다시 시작해야할 수 있다.

어떤 시작 커밋과 의존성, 명령으로 실행했는지도 기록하면 좋겠다. 같은 패치가 로컬에서는 실패한다면 환경 차이를 비교할 출발점이 된다.

## 비용과 관측은 모델 호출 바깥까지 포함하자

긴 작업의 비용에는 모델 사용량뿐 아니라 환경 준비와 패키지 설치, 빌드와 테스트 시간이 들어갈 수 있다. 최종 비용을 토큰 숫자 하나로만 설명하기 어렵다.

작업 ID를 기준으로 모델 호출과 Sandbox 세션, 실행 명령과 PR을 연결하면 좋겠다. 어느 작업이 왜 오래 걸렸는지 조사할 수 있어야한다.

# 5. 데이터베이스 — 엔진의 신기능과 Agent 문맥 저장을 구분하자

PostgreSQL은 지난주인 7월 16일 [19 Beta 2](https://www.postgresql.org/about/news/postgresql-19-beta-2-released-3350/)를 공개했다. 이번주에는 새 정식 버전처럼 받아들이기보다 별도 환경에서 호환성을 시험할 대상으로 보면 좋겠다.

베타에는 기능과 동작의 변경 가능성이 있다. 우리 애플리케이션의 대표 쿼리와 드라이버, 백업·복구 도구를 비교하는것과 운영 DB를 바로 전환하는것은 구분해야한다.

## 대화 메모리와 업무의 사실은 다른 데이터다

Agent가 기억할 문맥에는 대화 요약과 사용자 선호, 작업 중간 결과가 들어갈 수 있다. 하지만 주문 상태와 권한처럼 업무의 기준이 되는 사실은 원본 시스템에서 확인해야한다.

모델의 요약에 작업이 끝났다고 적혀있어도 DB의 실제 상태와 다를 수 있다. 특히 중단과 재시도 뒤에는 이미 반영된 결과를 대조할 수 있어야한다.

```text
데이터의 역할 나누기
업무 원본 → 실제 상태의 기준
작업 이력 → 무엇을 시도하고 반영했는지
문맥·캐시 → 다음 판단을 돕는 정보
```

PostgreSQL과 Redis를 조합하는것도 어떤 데이터를 어디에 보관할지부터 정하면 좋겠다. 짧게 재사용하는 캐시와 장기 보존할 업무 이력에 같은 수명 규칙을 적용할 필요는 없다.

## 벡터 검색은 검색 요구가 있을때 비교하자

Agent 기능을 추가한다고 반드시 Vector DB가 필요한것은 아니다. 정확한 키로 상태를 찾는 조회와 의미가 비슷한 문서를 찾는 검색은 요구가 다르다.

pgvector 같은 선택지는 의미 검색이 필요할때 평가하면 좋겠다. 그때도 원본의 수정과 삭제, 사용자별 접근 조건이 검색 결과에 어떻게 반영되는지 확인해야한다.

# 6. 이번주에는 읽기 전용 MCP Tool 하나를 연결해보자

이번주 소식을 공부한다면 기존 서비스의 조회 기능 하나를 도구로 노출해보면 좋겠다. 예를 들어 사용자가 자신에게 허용된 프로젝트의 작업 상태만 조회하는 작은 기능이다.

처음부터 DB에 자유롭게 SQL을 실행하는 도구보다 업무 범위가 분명한 도구가 결과를 평가하기 쉽다. 필요한 입력과 반환할 필드, 거절할 조건을 좁혀두는것이다.

| 단계 | 확인할 내용 |
| --- | --- |
| 업무 규칙 | 어떤 사용자에게 어떤 프로젝트를 허용하는가 |
| 도구 입력 | 식별자와 조회 범위를 어떻게 검증하는가 |
| 결과 | 필요한 필드만 반환하고 원본과 일치하는가 |
| 실패 | 권한 부족·미존재·연결 오류를 구분하는가 |
| 실행 기록 | 요청과 실제 조회를 연결할 수 있는가 |

정상 사용자와 권한 없는 사용자, 존재하지 않는 프로젝트를 각각 시험하면 좋겠다. Agent가 기대한 도구를 골랐는지와 서버가 실제로 올바르게 허용·거절했는지를 나눠 확인하는것이다.

# 마무리

이번주는 GitHub와 Cloudflare가 Agent의 실행과 검토, 도구 연결과 작업 환경을 실제 플랫폼 기능으로 넓혔다. Agent를 잘 쓰는 역량에 저장소와 권한, 검증과 관측을 설계하는 능력이 더해지고 있다.

Next.js 보안 패치는 지금 운영하는 서비스에서 확인할 일이고, MCP와 Sandbox는 앞으로의 실행 구조를 준비할 주제다. PostgreSQL 베타와 문맥 저장도 실제 업무 데이터의 책임을 기준으로 구분하면 좋겠다.

개인적으로는 이번주에 읽기 전용 도구 하나부터 권한과 결과를 끝까지 연결해보려고 한다. 호출에 성공했다는것에서 멈추지 않고 허용하지 않은 요청도 정확히 거절하는지 확인해야할것같다..


[2026.07.24 주간 개발 트렌드] Agent 자동화와 MCP·Sandbox, Next.js 보안 패치

독자의 메모