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

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

# 이번주는 AI 개발의 실행과 검토 환경을 같이 보자

이번주에는 AI 개발 워크플로와 Agent 기반 개발, 이를 운영하는 백엔드와 플랫폼의 역할을 같이 살펴보려고 한다. 코드를 빠르게 만드는것에서 그 코드를 검토하고 실행하고 운영하는 과정으로 관심이 넓어지고 있다.

구체적으로는 GitHub의 코드 리뷰 환경과 저장소 단위 Copilot 지표가 개선됐고, 모바일에서도 리뷰 의견을 Agent의 수정 작업으로 연결할 수 있게 됐다. Next.js는 보안 릴리스 절차를 예고했고 PostgreSQL 19 Beta 2도 나왔다.

새 도구를 몇개 설치했는지보다 어떤 업무를 맡기고 어떤 결과를 확인할지 정하는게 더 중요해지는것같다. 7월 11일부터 17일까지의 흐름을 여섯가지 주제로 정리해보았다.

| 분야 | 이번주 살펴볼 흐름 | 개발자가 확인할 부분 |
| --- | --- | --- |
| AI Agent | 코드 생성에서 여러 단계의 업무 실행으로 | 도구·문맥·완료 조건 |
| 개발 환경 | Copilot 리뷰·저장소 지표 개선 | 실제 변경과 검증 근거 |
| 프론트엔드 | Next.js 보안 릴리스 계획 | 패치 적용 준비와 회귀 검증 |
| 백엔드 | 모델과 외부 도구를 연결하는 실행 허브 | 작업 상태·권한·재시도 |
| DevOps | 생성 속도와 배포 품질의 연결 | 테스트·관측·중단·복구 |
| 데이터베이스 | PostgreSQL 19 Beta 2 | 베타 검증과 데이터 접근 범위 |

# 1. AI — Agent가 여러 단계의 업무를 수행하는 방향이 구체화됐다

7월 17일 [GitHub Mobile](https://github.blog/changelog/2026-07-17-github-mobile-fix-pull-request-comments-with-copilot-cloud-agent/)에서 Copilot 코드 리뷰 의견을 수정 작업으로 연결하는 기능이 나왔다. iOS·Android의 최신 정식 앱에서 리뷰 댓글의 Fix with Copilot을 사용할 수 있다.

모바일에서 시작할 수 있다는 편의와 실제 수정이 완료됐다는 판단은 나눠야한다. 이번 변화는 채팅에 코드를 요청하는것에서 리뷰와 수정, 검증을 이어가는 업무 흐름으로 범위가 넓어지는 사례로 보면 좋겠다.

## 코드 생성과 업무 완료의 차이는 중간 과정에 있다

함수 하나를 생성하는 작업은 입력과 결과를 비교적 좁게 정의할 수 있다. 저장소를 분석해 기능을 고치는 작업은 관련 코드 탐색과 수정, 테스트와 결과 설명까지 연결된다.

예를 들어 결제 오류를 수정해달라는 요청을 맡겼다고 생각해보자. 그럴듯한 함수가 나오는것만으로는 부족하다. 실제 오류가 생기는 조건을 찾고 기존 동작을 유지하면서 고친 뒤 재현 사례가 통과하는지 확인해야한다.

```text
업무 단위의 완료 흐름
문제 확인 → 관련 정보 탐색 → 수정 → 검증 → 결과와 한계 보고
```

## MCP와 Tool Calling, Workflow는 맡는 역할이 다르다

[MCP](https://modelcontextprotocol.io/specification/2025-11-25)는 AI 애플리케이션에 외부 데이터와 도구를 연결하는 표준 프로토콜이다. Tool Calling은 모델이 사용할 도구와 인자를 제안하고 애플리케이션이 실행 결과를 전달하는 흐름으로 이해하면 좋겠다.

Workflow는 그 호출들을 어떤 순서와 조건으로 이어갈지 다룬다. 도구를 연결한것과 여러 단계를 안정적으로 수행하는것은 다른 문제다.

| 요소 | 이해할 역할 |
| --- | --- |
| MCP | 도구와 정보를 연결하는 인터페이스 |
| Tool Calling | 필요한 기능을 선택하고 결과를 받는 흐름 |
| Workflow | 실행 순서와 분기, 대기와 재시도 |
| Context 관리 | 현재 판단에 필요한 정보와 상태의 유지 |

도구 설명에 적힌 문장은 실행 권한을 대신하지 않는다. 사용자가 볼 수 있는 데이터와 변경할 수 있는 대상을 실제 서버에서 확인해야한다.

## 긴 문맥은 많이 넣는것보다 필요한 내용을 유지하는게 중요하다

코드베이스 전체를 전달할 수 있어도 모든 파일이 같은 중요도를 갖는것은 아니다. 작업에 필요한 계약과 현재 오류, 이미 시도한 방법을 찾기 쉽게 구성해야한다.

중간 요약을 사용한다면 확정된 사실과 아직 검증하지 않은 추측을 구분하면 좋겠다. 처음의 가정이 요약을 거치면서 사실처럼 굳어지면 다음 단계도 잘못된 방향으로 갈 수 있다.

# 2. 개발 환경 — 리뷰 지침과 실행 환경을 함께 관리하게 됐다

7월 17일 [Copilot code review 개선](https://github.blog/changelog/2026-07-17-copilot-code-review-customization-and-configurability-improvements/)이 공개됐다. PR의 head 브랜치에서 지침을 읽고, 리뷰용 준비 단계와 Runner·네트워크 설정을 따로 구성하는 방향이다.

Cursor와 Claude Code, ChatGPT·Codex 같은 도구를 비교할때도 모델 이름만 보는것보다 어떤 정보를 읽고 어떻게 검증하는지 살펴보면 좋겠다. 제품마다 편집기와 CLI, 클라우드 실행 환경의 연결 방식이 다르기 때문이다.

## 지침도 코드처럼 브랜치에서 시험해보자

이번 개선에서는 `AGENTS.md` 등을 변경한 브랜치에서 리뷰 지침의 효과를 확인할 수 있다. 지침을 먼저 병합해야만 시험할 수 있던 흐름의 부담을 줄이는 방향이다.

팀의 지침에는 사용하지 않는 규칙을 길게 모으기보다 실제 저장소의 구조와 검증 방법을 적어두면 좋겠다. 코드를 어디에 추가하고 어떤 테스트로 결과를 확인할지 명확하면 리뷰의 근거도 찾기 쉽다.

다만 PR에서 바꾼 지침은 그 PR이 검토할 대상이기도 하다. 리뷰를 느슨하게 만드는 지시가 들어가지는 않았는지 사람이 확인하고, 권한 정책은 실제 실행 환경에서 별도로 유지해야한다.

```text
지침을 검증하는 흐름
규칙 변경 → 대표 PR에서 시험 → 리뷰 결과 비교 → 팀 기준으로 반영
```

## 리뷰 환경과 코드 작성 환경은 필요한 권한이 다르다

리뷰용 설치와 실행 준비는 `.github/workflows/copilot-code-review.yml`로 구성할 수 있다. 방화벽 설정도 코드 작성 Agent와 분리해 다룰 수 있으며, self-hosted Runner에는 해당 방화벽 지원이 적용되지 않는 점을 확인해야한다.

리뷰가 코드를 읽는 작업이라고 해서 실행하는 도구가 전혀 없다고 가정하면 안되겠다. 의존성 설치와 분석 명령이 어떤 코드와 네트워크에 접근하는지 살펴보면 좋겠다.

필요한 의존성을 받는 권한과 운영 비밀값을 사용하는 권한은 다르다. 리뷰에 필요하지 않은 자격 증명을 전달하지 않는 구성부터 확인하고 싶다.

## 저장소 단위 지표는 사용량을 해석하는 기준이 된다

같은 날 [저장소 단위 Copilot 사용 지표](https://github.blog/changelog/2026-07-17-repository-level-github-copilot-usage-metrics-generally-available/)가 GA로 나왔다. Coding Agent의 PR 생성·병합과 Code review의 활동을 저장소별 일일 보고서로 볼 수 있다.

활동이 많아졌다는것과 품질이 좋아졌다는것은 구분해야한다. PR의 크기와 업무 난이도, 리뷰 대기와 재작업이 함께 달라졌는지 보면 좋겠다.

# 3. 프론트엔드 — Next.js는 운영 점검과 다음 패치를 준비하자

7월 13일 Next.js는 [사전 공지형 보안 릴리스 절차](https://nextjs.org/blog/next-security-release-program)를 발표했다. 다음주 첫 보안 패치를 준비하는 단계이므로 이번주에 수정 패키지와 세부 취약점이 이미 공개된것처럼 받아들이면 안되겠다.

정기 예고를 통해 업데이트를 계획할 수 있게 하면서 긴급한 문제는 별도로 다루는 방향이다. 지금 사용하는 버전과 영향 확인, 회귀 검증과 배포의 담당자를 미리 정해둘 수 있다.

이번주에는 새 기능의 수보다 App Router와 Server Components, 사용하는 Runtime에서 현재 동작을 어떻게 확인할지 정리해보면 좋겠다. 특정 아키텍처를 사용한다는 이유만으로 안정적으로 운영된다고 판단할 수는 없다.

## 직접 진입과 내부 탐색을 나눠서 보자

같은 URL도 주소창에서 직접 열때와 내부 링크로 이동할때 준비된 상태가 다를 수 있다. 이전 화면의 데이터와 캐시, 탐색 중 보이는 로딩 상태가 영향을 준다.

```text
프론트엔드의 대표 검증 경로
직접 진입 / 내부 이동 / 새로고침 / 뒤로 가기 / 느린 응답
```

로그인 전후의 캐시와 권한도 확인해야한다. 사용자가 바뀐 뒤 이전 사용자의 정보가 남지 않는지, 만료된 세션에서 화면과 서버가 같은 상태를 보는지 살펴보는것이다.

## 서버와 클라이언트, Runtime의 경계를 명확히 두자

Server Component를 사용해도 모든 코드가 서버에서만 실행되는것은 아니다. 브라우저에 전달되는 코드와 서버에 남아야하는 자격 증명을 구분해야한다.

외부 라이브러리와 데이터베이스 드라이버도 실제 실행 환경에 맞는지 확인하면 좋겠다. Node.js 환경에서 실행되는 코드와 Edge Runtime의 제약을 같은 조건으로 가정하지 않는것이다.

# 4. 백엔드 — 모델과 도구를 연결하는 실행 허브의 역할이 커진다

AI 기능을 붙인 백엔드는 모델 응답을 전달하는 API에서 여러 실행을 조정하는 계층으로 넓어질 수 있다. 여기서는 특정 프레임워크의 점유율보다 실제 서비스에 필요한 역할을 기준으로 보려고 한다.

Spring Boot나 NestJS에 큐와 Worker, 스트리밍을 조합하는 구조도 선택지다. 다만 모든 서비스에 이 요소를 한번에 넣을 필요는 없다. 작업 시간과 복구 요구를 먼저 확인하면 좋겠다.

## 요청의 수명과 작업의 수명을 분리해보자

짧은 질의는 응답을 기다리는 요청 안에서 처리할 수 있다. 반면 문서를 여러개 읽거나 외부 도구를 순서대로 호출하는 작업은 사용자의 연결보다 오래 실행될 수 있다.

이런 경우 작업 ID를 발급하고 상태를 보관하는 방식을 검토할 수 있다. 클라이언트가 연결을 잃더라도 서버는 어떤 작업이 어디까지 진행됐는지 알아야한다.

```text
긴 작업의 구성 예시
요청 접수 → 작업 ID → Queue → Worker → 상태·결과 저장
                         └─ 진행 상황 조회·스트리밍
```

스트리밍은 진행 상황을 전달하는 통로다. 연결이 끊겼다고 업무도 취소됐는지, 백그라운드에서는 계속 실행되는지 제품의 규칙을 정해야한다.

## 재시도 전에 외부 반영 상태를 확인하자

Worker가 실패한 작업을 다시 받는 상황에서는 같은 요청이 여러번 처리될 수 있다. 모델 호출을 반복하는것과 이메일 발송이나 주문 생성을 반복하는것은 영향이 다르다.

실제 상태를 바꾸는 도구에는 업무 식별자를 연결하면 좋겠다. 이미 완료한 작업을 다시 만들지 않고 기존 결과를 찾을 수 있는지 검토하는것이다.

캐시 역시 답변의 문자열만 저장해서 끝내기 어렵다. 사용자 권한과 데이터의 버전, 모델과 요청 조건이 달라졌을때 같은 결과를 재사용해도 되는지 정해야한다.

## 취소와 실패, 완료를 서로 다른 상태로 남기자

취소 요청을 받은 뒤에도 이미 반영한 외부 작업은 남아있을 수 있다. 무엇을 중단했고 무엇이 완료됐는지 결과에 표시하면 사용자가 같은 작업을 중복 요청하는 일을 줄일 수 있다.

# 5. DevOps — 코드 생성 속도와 배포 품질을 함께 봐야한다

AI가 초안을 빠르게 만든다는것과 서비스 변경이 더 빨리 안전하게 배포된다는것은 다른 결과다. 이번주 개발 흐름을 볼때도 코드 작성 이후의 대기와 검증을 같이 살펴볼 필요가 있다.

변경이 많아졌다면 리뷰와 테스트, 배포를 처리하는 체계가 그 양을 감당할 수 있는지 확인해야한다. 빠르게 만든 코드가 검토 대기열에 오래 쌓이면 전체 완료 시간은 줄지 않을 수 있다.

## 자동 테스트는 생성한 코드의 설명과 독립적으로 보자

Agent가 구현과 테스트를 함께 만들면 둘이 같은 잘못된 가정을 공유할 수도 있다. 테스트가 통과했다는 사실과 요구사항이 검증됐다는 사실을 나눠봐야한다.

수정 전 실제 오류를 재현할 수 있는 사례와 경계 입력을 먼저 준비하면 좋겠다. 정상 요청만 실행하는 테스트보다 어떤 조건에서 실패해야하는지도 확인하는것이다.

## 관측은 AI 요청 전체의 흐름을 연결해야한다

[OpenTelemetry](https://opentelemetry.io/docs/concepts/signals/)의 Trace와 Metric, Log를 생각하면 각각의 기록을 어떤 질문에 사용할지 정리할 수 있다. 요청이 어디서 느려졌는지와 전체 실패율이 어떤지, 특정 오류에서 무슨 일이 있었는지는 서로 다른 질문이다.

AI 기능에서는 모델의 응답 시간 외에도 큐 대기와 외부 도구, 재시도와 승인 대기가 추가될 수 있다. 전체 시간이 길어졌을때 어느 구간을 개선할지 알아야한다.

```text
작업 시간 나누기
큐 대기 + 모델 호출 + 도구 실행 + 재시도 + 검증·승인 대기
```

## Feature Flag와 Rollback은 데이터 변경까지 생각하자

새 AI 기능의 노출을 Feature Flag로 나누면 영향 범위를 작게 시작하는데 도움이 될 수 있다. 다만 화면에서 기능을 껐을때 실행 중인 Worker와 예약된 작업은 어떻게 되는지도 확인해야한다.

코드를 이전 버전으로 돌려도 이미 바뀐 DB 데이터와 외부 시스템은 그대로 남을 수 있다. 되돌릴 수 있는 범위와 별도의 정리가 필요한 범위를 배포 전에 알아야겠다.

# 6. 데이터베이스 — PostgreSQL 중심의 조합은 역할을 나눠서 보자

7월 16일 [PostgreSQL 19 Beta 2](https://www.postgresql.org/about/news/postgresql-19-beta-2-released-3350/)가 공개됐다. 첫 베타 이후의 버그와 회귀를 수정한 테스트 버전이며 운영 DB를 바로 전환할 대상으로 보지는 않는게 좋겠다.

DB의 새 버전과 Agent를 위한 데이터 구조는 다른 결정이다. PostgreSQL을 업무 데이터의 기준으로 두고 캐시와 검색 기능을 조합하더라도 실제로 필요한 역할부터 나눠보면 좋겠다.

## 저장소와 캐시, 접근 도구의 역할을 구분하자

PostgreSQL과 Redis, Prisma와 Supabase는 같은 역할의 대체재로 묶기 어렵다. 데이터를 저장하는 DB와 캐시·큐, 애플리케이션의 데이터 접근 계층과 관리형 플랫폼은 맡는 책임이 다르다.

모든 도구를 넣기 전에 어떤 문제를 해결할지 정하면 좋겠다. Redis를 추가하는것도 느린 조회를 줄이려는지, 짧은 상태를 공유하려는지, 비동기 작업을 전달하려는지에 따라 설계가 달라진다.

```text
데이터의 기준을 정하기
원본 데이터는 어디에 있는가
  → 누가 변경하는가
  → 복사본과 캐시는 언제 갱신되는가
  → 실패하면 무엇과 대조하는가
```

## 벡터 검색도 원본 데이터와 권한이 필요하다

벡터 검색이 필요한 경우 pgvector 같은 확장을 검토할 수 있다. 검색을 붙였다는 이유만으로 모든 데이터를 임베딩할 필요는 없다. 찾으려는 문서와 평가할 질문을 먼저 정하면 좋겠다.

원본 문서가 수정되거나 삭제됐을때 검색용 데이터도 어떻게 바뀌는지 확인해야한다. 오래된 문서를 근거로 답변하는 문제는 생성 모델만 바꿔서는 해결되지 않을 수 있다.

사용자가 읽을 수 없는 문서는 검색 후보와 모델 입력에서도 구분해야한다. 최종 답변에서 내용을 숨기도록 요청하는것만으로 데이터 접근 정책이 완성되는것은 아니다.

## 베타는 대표 데이터와 도구의 호환성을 시험하자

PostgreSQL 19 Beta 2는 테스트 환경에서 기존 쿼리와 결과를 비교할 기회다. ORM과 드라이버, 백업과 복구 도구도 현재 구성에서 동작하는지 함께 확인하면 좋겠다.

성능을 비교할때는 데이터 양과 통계, 캐시 상태를 맞춰야한다. 빈 DB의 짧은 조회와 실제 운영의 복잡한 요청을 같은 기준으로 보기 어렵다.

새 기능을 직접 사용하지 않더라도 기존 쿼리의 결과가 유지되는지 중요하다. 실행 계획이 바뀌었을때 느려진 요청과 달라진 조건을 남겨두면 검토와 피드백에 도움이 된다.

# 7. 이번주에는 작은 업무 하나를 끝까지 연결해보자

이번주 흐름을 적용한다면 여러 도구를 한번에 바꾸기보다 반복하는 업무 하나를 골라보고 싶다. 오류를 재현하고 Agent에게 맡기고 리뷰와 CI, 실제 실행 확인까지 이어보는것이다.

# 마무리

이번주는 모바일의 수정 요청과 코드 리뷰 환경, 저장소 지표가 연결되며 AI 개발의 범위가 넓어지는 흐름을 확인했다. Next.js의 보안 릴리스 계획과 PostgreSQL 베타도 운영과 검증을 미리 준비할 이유가 됐다.

프론트엔드는 실제 탐색과 데이터 경계를, 백엔드는 작업 상태와 권한을, DevOps는 검증과 복구를 기준으로 살펴보면 좋겠다. DB와 플랫폼도 편리하게 연결할수록 누가 어떤 데이터에 접근하는지 분명히 해야한다.

개인적으로는 이번주에 AI에게 맡길 업무 하나의 시작과 끝부터 적어보려고 한다. 코드를 빨리 만드는 능력과 그 결과를 운영할 수 있는 능력을 같이 키워야할것같다..


[2026.07.17 주간 개발 트렌드] AI 업무 실행과 코드 리뷰, 플랫폼·운영의 역할

독자의 메모