[2026.08.07 주간 개발 트렌드] 댓글로 실행하는 Agent, Next.js 16.3과 CI 검증

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

# 이번주는 Agent를 연결하고 실행하는 기반을 봐야겠다

이번주에는 Cloudflare Agents SDK와 제품별 MCP 서버가 MCP 2026-07-28 사양을 지원하는 업데이트를 내놨다. 지난주 GitHub의 선지원에 이어 실제 개발 플랫폼의 연결 방식이 새 명세로 맞춰지는 흐름이다.

새 프레임워크 하나보다 Agent가 어떤 도구에 접근하고 어디서 코드를 실행하며 어떤 상태를 남기는지가 더 궁금해지는 주다. 프론트엔드와 백엔드, 인프라와 데이터가 이 실행 흐름 안에서 연결되고 있다.

7월 27일부터 31일까지의 새 소식과 지난주부터 이어지는 변화를 주제별로 정리해보았다. AI SDK의 버전 호환성과 Sandbox도 이번주에 처음 나온 기능처럼 섞지 않고 배경을 나눠보려고 한다.

| 분야 | 살펴볼 변화 | 실무에서 볼 부분 |
| --- | --- | --- |
| AI 표준 | Cloudflare의 MCP 새 사양 지원 | 연결 호환성과 상태 관리 |
| 프론트엔드 | AI SDK 연결과 빌드 환경 | 스트리밍 상태·의존성 조합 |
| 백엔드 | MCP Tool과 기존 서비스의 연결 | 도구 노출·업무 권한·입력 검증 |
| DevOps | Sandbox와 실행 관측 | 자원·비밀값·완료 시점 |
| 데이터 | Agent가 사용하는 업무 상태와 문맥 | 원본·캐시·검색의 책임 |

# 1. AI — MCP 새 사양 지원이 실제 플랫폼으로 넓어졌다

7월 27일 [Cloudflare Agents SDK v0.20.0](https://developers.cloudflare.com/changelog/post/2026-07-27-agents-sdk-v0.20.0-mcp-sdk-v2/)이 MCP 2026-07-28의 클라이언트·서버 지원을 추가했다. 이어 28일에는 [Cloudflare 제품별 MCP 서버](https://developers.cloudflare.com/changelog/post/2026-07-28-cloudflare-mcp-servers-mcp-2026-07-28/)도 새 사양 지원을 발표했다.

GitHub MCP Server의 관련 발표는 [지난주인 7월 23일](https://github.blog/changelog/2026-07-23-github-mcp-server-supports-the-next-mcp-specification/)에 나왔다. 이번주에는 같은 연결 규칙이 SDK와 실제 서버에 이어지는 흐름으로 보면 좋겠다.

## MCP는 모델 API보다 외부 기능의 연결 방식을 맞춘다

MCP가 있다고 모든 LLM의 추론 API와 가격, 응답 형식이 같아지는것은 아니다. AI 애플리케이션과 외부 도구·데이터를 연결하는 인터페이스를 표준화하는것으로 이해하면 좋겠다.

모델이 도구를 고르는 과정과 애플리케이션이 실제 호출을 수행하는 과정을 나누면 구조가 더 분명해진다. LLM 자체가 모든 서비스의 인증 정보를 직접 가져야하는것도 아니다.

```text
LLM을 사용하는 애플리케이션
  → MCP Client
  → 서비스별 MCP Server
  → GitHub·DB·문서·업무 API
```

각 서비스에는 실제 기능을 MCP로 제공하는 서버가 필요하다. 연결 방식이 같아져도 조회 조건과 반환값, 허용되는 작업과 인증은 서비스에 따라 다를 수 있다.

Tool Calling과 MCP도 같은 용어로 쓰지 않는게 좋겠다. 모델이 어떤 기능을 요청할지 판단하는 흐름과 그 기능을 외부 서버에서 제공하는 프로토콜은 서로 다른 계층이다.

## Stateless는 업무 상태를 없애라는 의미가 아니다

[새 MCP 명세의 설명](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/)에서 중요한 변화는 프로토콜 계층의 stateless 구조다. 전송 세션에 묶인 처리를 줄이고 요청을 일반적인 HTTP 인프라에서 다루는 방향이다.

그렇다고 장기 작업의 상태와 사용자별 권한, 이미 반영된 변경을 저장하지 않아도 되는것은 아니다. 서버 인스턴스가 바뀌어도 필요한 업무 정보를 다시 찾을 수 있어야한다.

예를 들어 문서 분석을 시작한 뒤 진행 상황을 확인한다면 작업 ID와 소유자, 현재 상태를 관리할 수 있다. 이 ID를 안다는것만으로 다른 사용자의 결과에 접근하게 만들어서는 안되겠다.

```text
업무 상태의 연결 예시
작업 생성 → 작업 ID 반환 → 사용자·소유권 확인 → 진행 상황·결과 조회
```

## 호환성은 실제 클라이언트 조합으로 시험하자

Cloudflare는 새 프로토콜을 확인하고 기존 방식으로도 연결하는 호환 경로를 설명한다. 제품별 서버에서는 새 연결에 `/mcp`를 사용하도록 안내한다.

기존 `/sse` 주소가 남아있어도 예전 HTTP+SSE 전송을 그대로 제공하는것으로 해석하면 안된다. 클라이언트가 특정 전송 방식을 강제로 사용하고 있다면 실제 연결 설정을 확인해야한다.

업데이트를 검증할때는 도구 목록을 가져오는것과 도구 호출, 인증과 오류 처리를 각각 확인하면 좋겠다. 한번 연결됐다는 표시만으로 전체 기능의 호환성을 알 수는 없다.

# 2. 프론트엔드 — 스트리밍 화면과 Agent의 업무 상태를 연결하자

Cloudflare Agents 패키지의 [AI SDK v6·v7 동시 지원](https://developers.cloudflare.com/changelog/post/2026-07-23-ai-sdk-v6-v7-support/)은 지난주인 7월 23일 발표됐다. 기존 v6 구성을 유지하거나 v7을 도입할때 관련 패키지의 조합을 확인할 수 있게 된 변화다.

화면에서 AI Chat과 도구 실행, 스트리밍을 연결하려면 모델의 텍스트뿐 아니라 실제 작업의 상태도 표현해야한다. 생성된 문장이 곧 업무의 완료를 의미하지는 않기 때문이다.

## SDK의 버전 조합부터 맞춰보자

해당 안내는 AI SDK v6와 `@ai-sdk/react` v3, AI SDK v7과 `@ai-sdk/react` v4를 맞춰 사용하도록 설명한다. 서버와 클라이언트 패키지를 각각 최신으로 바꾸는 방식보다 지원되는 조합을 먼저 확인하면 좋겠다.

| 서버 쪽 AI SDK | 대응하는 React 패키지 |
| --- | --- |
| v6 | `@ai-sdk/react` v3 |
| v7 | `@ai-sdk/react` v4 |

설치 성공과 실제 스트림의 호환성도 나눠봐야한다. 텍스트와 도구 결과, 오류와 종료 이벤트를 화면이 예상한 형태로 처리하는지 확인하는것이다.

## 응답을 보여주는 시점과 실행이 끝난 시점은 다르다

Next.js를 사용한다면 Server Components가 전달하는 초기 화면과 이후의 AI 스트림을 구분해보자. React의 화면 스트리밍과 모델 텍스트의 스트리밍, 도구 실행의 진행 상황은 같은 사건이 아니다. 각각 무엇을 기다리는지 사용자에게 이해할 수 있게 보여주면 좋겠다.

예를 들어 Agent가 자료를 조회한 뒤 보고서를 저장하는 작업이라면 텍스트가 먼저 도착할 수 있다. 아직 저장이 끝나지 않았다면 화면에 완료라고 표시하지 않도록 해야한다.

```text
화면에서 구분할 상태
접수 → 모델 처리 → 도구 실행 → 필요한 확인 대기 → 완료·실패·취소
```

브라우저가 연결을 잃었을때도 현재 작업을 다시 확인할 수 있는지 중요하다. 사용자가 새로고침했다는 이유로 동일한 외부 작업을 또 시작하지 않도록 연결하면 좋겠다.

## 이번주에는 빌드 환경의 기본값도 바뀌었다

7월 30일 [Workers Builds의 기본 Node.js](https://developers.cloudflare.com/changelog/post/2026-07-30-workers-builds-nodejs-24/)가 24.18.0으로 바뀌었다. `NODE_VERSION`이나 `.nvmrc`, `.node-version`을 이용해 버전을 지정하는 방법도 안내됐다.

이것은 빌드 환경의 기본값에 대한 소식이다. 배포된 Workers의 실행 환경이 그대로 Node.js 프로세스가 된다는 의미로 이해하면 안되겠다.

빌드 중 사용하는 도구와 실제 요청을 처리하는 Runtime의 호환성을 나눠 확인하면 좋겠다. 의존성 설치와 빌드가 통과해도 배포한 코드가 필요한 API를 지원하는지는 별도 검증이다.

# 3. 백엔드 — MCP Tool은 기존 업무 서비스를 연결하는 인터페이스다

지난주 [Cloudflare의 MCP 업데이트](https://developers.cloudflare.com/changelog/post/2026-07-22-mcp-codemode-updates/)에는 변환한 스키마 재사용과 Think의 `includeMcpTools` 설정이 포함됐다. 이번주 새 프로토콜 지원과 함께 이해하면 도구 연결의 계층을 나누기 좋다.

자동으로 노출하는 도구를 줄이는 설정과 실제 호출을 거절하는 접근 정책은 다르다. 화면이나 모델에 도구가 보이지 않는것만으로 모든 경로의 호출이 막혔다고 판단하면 안되겠다.

## REST와 MCP가 같은 업무 규칙을 사용하게 만들자

Spring Boot나 NestJS에서는 기존 Service Layer를 REST Controller와 MCP Tool에서 함께 호출하는 구성을 생각해볼 수 있다. 인터페이스마다 업무 규칙을 복사하면 수정할때 서로 달라질 수 있다.

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

공유할 부분은 사용자가 어떤 자원에 접근할 수 있는지와 업무 상태를 어떻게 바꾸는지다. HTTP 상태 코드와 모델에게 전달할 도구 결과는 각 인터페이스에서 적절히 표현할 수 있다.

도구의 입력 스키마가 맞아도 업무적으로 허용되지 않는 요청일 수 있다. 존재하는 고객 ID를 받았다는 사실과 현재 사용자가 그 고객을 조회할 수 있다는 사실을 구분해야한다.

인증된 사용자 정보를 Service에 전달하는 경로도 명확히 두면 좋겠다. 모델이 인자에 넣은 사용자 ID를 현재 로그인한 신원처럼 신뢰하는 구조는 피하고 싶다.

## 읽기 전용 도구부터 범위를 좁혀보자

처음에는 프로젝트 상태 조회처럼 입력과 결과를 확인하기 쉬운 도구가 좋겠다. DB 전체에 자유로운 쿼리를 실행하는 도구보다 필요한 범위를 정의하기 쉽다.

프로젝트 ID와 조회할 기간, 반환할 필드를 좁히고 페이지 크기도 정할 수 있다. 작은 조회 요청이 예상보다 많은 데이터를 가져오지 않는지 확인하는것이다.

개인적으로는 REST에서 거절되는 요청이 MCP에서도 같은 업무 기준으로 거절되는지 비교하고 싶다. 새로운 인터페이스를 추가하면서 기존 정책의 우회 경로가 생기지 않아야하기 때문이다.

## 긴 작업에는 Queue와 재시도 정책이 필요할 수 있다

문서 수집이나 여러 외부 도구를 호출하는 작업은 한 요청보다 오래 걸릴 수 있다. 필요한 경우 작업 ID와 Queue, Worker를 사용해 실행과 응답의 수명을 나눌 수 있다.

다만 큐를 넣었다고 중복 실행이 자동으로 사라지는것은 아니다. 다시 받은 작업이 이미 반영한 변경을 반복하지 않도록 업무 식별자와 실제 상태를 확인해야한다.

# 4. Cloud·DevOps — Sandbox와 관측은 실제 실행의 수명을 다뤄야한다

지난주인 7월 21일 소개된 [Devin Outposts의 Cloudflare 실행](https://developers.cloudflare.com/changelog/post/2026-07-21-devin-outposts/)은 세션마다 독립된 Container 기반 Sandbox를 제공하는 사례다. Agent의 작업 공간이 별도의 관리 대상이 된다는 흐름으로 볼 수 있다.

이번주에는 실행을 추적할 도구도 나왔다. 7월 28일 [Workers tracing](https://developers.cloudflare.com/changelog/post/2026-07-28-start-active-span/)은 `tracing.startActiveSpan()`과 `span.end()`를 추가해 콜백 반환 이후에도 이어지는 작업을 관측할 수 있게 했다.

## 응답을 반환한 순간에 작업이 끝나는것은 아니다

스트림을 생성해 반환하는 함수는 빨리 끝나도 사용자가 결과를 받는 과정은 계속될 수 있다. 함수 반환까지만 측정하면 실제 대기 시간을 놓칠 수 있다.

수동으로 종료할 수 있는 Span을 사용한다면 정상 완료와 오류, 취소 경로에서 언제 닫을지 정해야한다. 시작만 하고 끝나지 않은 기록이 쌓이면 지표의 의미도 흐려질 수 있다.

```text
관측할 수명을 나눠보기
요청 접수 → 스트림 생성 → 도구 실행·출력 전달 → 소비 완료 또는 취소
```

모델 호출과 셸 명령, DB 조회를 같은 작업 식별 정보로 연결하면 좋겠다. 최종 실패 하나를 조사할때 여러 서비스의 로그를 서로 찾을 수 있어야한다.

## Sandbox의 격리와 비밀값의 범위는 따로 확인하자

독립된 환경에서 실행한다고 그 안에 넣은 자격 증명이 자동으로 최소 권한이 되는것은 아니다. 작업에 필요한 저장소와 외부 서비스에만 접근하도록 설계해야한다.

패키지를 설치하는 네트워크와 운영 시스템에 접근하는 네트워크도 역할이 다르다. 도입할 환경에서 필요한 제한과 감사 기능을 어떻게 제공하는지 확인하면 좋겠다.

자원 제한에는 CPU·메모리뿐 아니라 실행 시간과 디스크 사용도 포함할 수 있다. 반복 명령이 끝나지 않는 경우 모델 요청과 실제 프로세스를 각각 어떻게 멈출지 정해야한다.

Docker와 Kubernetes 경험은 이런 자원과 실행 환경의 설계에 연결된다. 다만 Agent 기능을 추가한다는 이유만으로 클러스터를 새로 운영할 필요는 없다. 필요한 조건을 관리형 환경과 비교하는것부터 시작하면 된다.

## 임시 환경을 없애기 전에 검토할 결과를 남기자

작업 공간의 수명이 끝나도 패치와 테스트 결과, 필요한 산출물은 검토할 수 있어야한다. 무엇을 바꿨는지 없는 상태에서 완료 설명만 남으면 결과를 받아들이기 어렵다.

시작 커밋과 의존성, 실행한 명령도 기록하면 재현에 도움이 된다. 같은 패치를 로컬에서 실행했을때 결과가 다르면 환경 차이를 비교할 수 있다.

# 5. 데이터 — Agent의 문맥과 업무 원본을 같은것으로 보지 말자

이번주 MCP 지원 소식을 새로운 DB 엔진의 출시처럼 받아들일 필요는 없다. 중요한것은 Agent가 어떤 데이터에 어떤 규칙으로 접근하게 할지다.

PostgreSQL과 Redis를 조합할 수도 있고 기존 DB 하나로 시작할 수도 있다. 모든 AI 서비스가 같은 구성을 사용한다거나 반드시 벡터 검색이 필요하다고 단정하지 않는게 좋겠다.

## 원본과 작업 이력, 캐시는 목적이 다르다

주문 상태와 권한 같은 업무 원본은 실제 시스템에서 확인해야한다. 대화 요약에 완료했다고 적혀있는것만으로 외부 변경이 반영됐다고 판단하기 어렵다.

```text
업무 원본 → 현재 사실의 기준
작업 이력 → 무엇을 시도하고 반영했는지
문맥·캐시 → 다음 판단과 조회를 돕는 정보
```

캐시의 수명이 끝나도 원본을 다시 조회할 수 있는지와 어떤 조건에서 결과를 재사용하는지 확인하면 좋겠다. 사용자와 데이터 버전이 달라졌는데 같은 값을 돌려주면 문제가 될 수 있다.

## 벡터 검색은 실제 질문으로 필요성을 비교하자

정확한 식별자로 업무 상태를 찾는 조회와 의미가 비슷한 문서를 찾는 검색은 다르다. 전자의 문제를 해결하려고 바로 Vector DB부터 도입할 필요는 없다.

의미 검색이 필요하다면 실제 질문과 기대하는 문서를 먼저 준비하면 좋겠다. 기존 검색과 비교해 결과가 좋아지는지, 권한에 맞는 후보만 모델에 전달되는지 확인하는것이다.

문서가 수정되거나 삭제됐을때 검색 데이터도 어떻게 바뀌는지 중요하다. 오래된 문맥을 모델에게 전달하는 문제는 모델만 교체해서 해결하기 어려울 수 있다.

# 6. 이번주에는 작은 MCP 프로젝트를 끝까지 연결해보자

하나를 공부한다면 기존 서비스의 읽기 전용 조회를 MCP Tool로 제공해보면 좋겠다. 문법을 구현하는 단계에서 현재 사용하는 클라이언트의 호출과 서버의 권한 검사까지 이어가는것이다.

| 순서 | 만들어볼 결과 |
| --- | --- |
| 개념과 경계 정리 | Host·Client·Server·업무 Service의 역할 |
| 서버와 도구 구현 | 입력과 반환 범위가 좁은 조회 하나 |
| 클라이언트 연결 | 실제 전송·인증·SDK 조합의 확인 |
| 권한 검증 | 허용 사용자와 다른 사용자의 결과 비교 |
| 오류와 중단 | 잘못된 입력·시간 초과·연결 종료 처리 |
| 관측과 재현 | 요청·도구·DB 조회·결과의 연결 |

호출 성공 하나보다 정상과 거절, 실패 사례를 함께 만들면 배울 부분이 많다. 새 프로토콜의 이름을 아는것에서 우리 서비스의 동작을 설명할 수 있는 수준으로 넘어가는것이다.

# 마무리

이번주는 MCP 새 사양이 Cloudflare SDK와 실제 서버에 적용되며 표준화의 흐름이 구체화됐다. 빌드 환경과 실행 관측의 변화도 Agent 기능을 운영하기 위해 확인할 기반이다.

프론트엔드는 사용자에게 보이는 상태를, 백엔드는 업무 규칙과 권한을, 인프라는 실행 환경과 수명을 다룬다. 연결 방식이 통일될수록 각 계층의 책임을 분명히 해두는게 중요해지는것같다.

개인적으로는 이번주에 작은 조회 도구 하나를 연결하고 실패 조건까지 확인해보려고 한다. 도구가 많아지는것보다 어떤 조건에서 정확하게 실행되는지 설명할 수 있어야할것같다..


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

독자의 메모