[2026.08.14 주간 개발 트렌드] Agent Plugins 1.0과 MCP 운영, PostgreSQL 보안 패치

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

# 이번주는 Agent 자동화와 Next.js 16.3을 같이 봐야겠다

이번주에는 GitHub의 Coding Agent가 댓글을 받아 작업을 시작하고, 작업에 사용할 추론 수준을 선택할 수 있게 됐다. AI에게 질문하는 과정이 저장소 이벤트를 처리하는 개발 흐름으로 이어지고 있다.

프론트엔드에서도 변화가 있다. 8월 3일 Next.js 16.3이 정식 출시됐다. 지난달부터 살펴본 탐색 성능과 Turbopack 개선을 실제 프로젝트에서 검토할 수 있는 시점이다.

8월 3일부터 7일까지의 소식을 주제별로 정리해보았다. Spring Boot의 지원 정책과 PostgreSQL 베타는 이번주 신규 발표와 구분해서, 지금 개발 환경에서 챙길 배경으로 같이 보려고 한다.

| 분야 | 이번주 살펴볼 내용 | 실무에서 볼 부분 |
| --- | --- | --- |
| AI | 댓글 기반 Copilot 자동화 | 실행 조건·중복 요청·완료 기준 |
| AI 모델 | 추론 수준 선택과 Kimi K3 | 품질·대기 시간·비용 |
| 프론트엔드 | Next.js 16.3 정식 출시 | 탐색·캐시·개발 서버 |
| 백엔드 | Spring Boot 4.x 전환 준비 | 지원 범위·의존성·관측 |
| DevOps | Coverage 설정과 CodeQL | 검증 파이프라인·조직 정책 |
| 데이터 | PostgreSQL 19 Beta 2 | 운영 패치와 차기 버전 시험 |

# 1. AI — 댓글이 Agent의 작업 시작점이 됐다

8월 3일 [Copilot Cloud Agent의 댓글 기반 Automation](https://github.blog/changelog/2026-08-03-trigger-copilot-automations-with-comments/)이 공개됐다. Issue나 Pull Request에 설정한 문구의 댓글이 작성되면 자동화를 실행하는 방식이다.

GitHub은 변경된 코드에 맞춘 문서 생성, 오류 로그 조사, 후속 Issue 생성 등을 예로 들었다. 유료 Copilot 플랜에서 제공하며 조직에서는 Cloud Agent 정책이 활성화돼 있어야한다.

## 이제 시작 조건도 개발자가 설계해야한다

이 흐름을 우리 저장소에 적용한다면 단순히 댓글을 읽고 코드를 만드는 기능으로만 보기는 어렵겠다. 어떤 이벤트를 처리하는 Worker와 비슷하게 실행 조건을 정해야하기 때문이다.

```text
Issue·PR 댓글
  → 허용된 실행 요청인지 확인
  → 대상 저장소·변경 버전 확인
  → Agent 분석·수정
  → 테스트와 결과 정리
  → PR 또는 후속 작업 검토
```

위 구조는 내가 생각하는 도입 예시다. 댓글 하나로 배포까지 자동 승인된다는 의미는 아니다. 코드 변경과 검증, 병합과 배포의 권한은 각각 정할 수 있다.

처음에는 문서 초안이나 오류 원인 분석처럼 결과를 확인하기 쉬운 작업부터 맡기면 좋겠다. 결제 로직 수정처럼 영향이 큰 작업은 요구사항과 검증 방법을 더 구체적으로 준비해야한다.

## 댓글 내용은 업무 입력으로 다뤄야한다

Issue에는 외부 사용자가 남긴 로그와 재현 코드가 들어올 수 있다. 여기에 적힌 명령문을 저장소 관리자의 실행 지시처럼 신뢰하면 곤란하다.

예를 들어 오류 로그에 외부 URL로 환경 변수를 보내라는 문장이 섞여있어도, 그것은 분석 대상 텍스트다. 실제 실행 권한을 부여하는 설정과 사용자가 제공한 자료의 내용은 구분해야한다.

자동화를 구성할때는 호출한 사용자의 권한과 대상 브랜치, 허용하는 작업을 서버 쪽에서 확인하면 좋겠다. 모델에게 조심하라고 적는것과 실제로 실행을 제한하는것은 다르다.

## 같은 요청이 다시 들어오면 어떻게 할까

댓글을 연속해서 작성하거나 작업 중에 다시 요청할 수 있다. 이때 문서 PR이 여러 개 생기거나 이미 처리한 Issue를 또 생성하지 않도록 기준을 정해보자.

저장소와 댓글 ID, 대상 커밋을 작업 식별 정보로 남기는 방법을 생각할 수 있다. 진행 중인 작업이 있으면 현재 상태를 보여주고, 새로운 커밋이 들어오면 어느 버전을 분석했는지도 표시하는것이다.

재실행을 무조건 막을 필요는 없다. 실패한 요청을 다시 실행하는것과 동일한 변경을 두 번 반영하는것을 구분해야겠다. 이 부분은 AI 모델보다 일반적인 백엔드 작업 처리 경험과 더 가까운것같다..

# 2. AI 모델 — 추론 수준도 작업의 설정이 됐다

같은 날 [Copilot Cloud Agent의 reasoning level 선택](https://github.blog/changelog/2026-08-03-customize-the-reasoning-level-for-copilot-cloud-agent/)도 추가됐다. 해당 기능을 지원하는 모델에서는 작업을 시작할때 모델과 함께 추론 수준을 지정할 수 있다.

GitHub은 높은 수준의 추론이 복잡한 문제에 도움이 될 수 있지만 토큰과 크레딧 사용량도 늘어난다고 설명한다. 가장 높은 값을 모든 작업에 고정하는 방식이 항상 효율적이지는 않겠다.

## 모델 이름보다 작업이 끝나는 비용을 보자

문서의 오타를 수정하는 작업과 여러 모듈의 트랜잭션 문제를 분석하는 작업은 다르다. 입력이 짧다고 쉬운 작업인것도 아니고, 파일이 많다고 반드시 어려운것도 아니다.

내가 비교한다면 다음과 같이 같은 작업 묶음을 준비할것같다.

| 작업 예시 | 확인할 결과 | 같이 기록할 값 |
| --- | --- | --- |
| 문서 수정 | 의미와 코드 예제가 맞는지 | 완료 시간·수정 횟수 |
| 오류 재현 | 실패하는 조건을 찾았는지 | 도구 호출·재시도 |
| 기능 변경 | 기존 동작과 새 요구를 만족하는지 | 테스트 결과·전체 비용 |
| 리팩터링 | 외부 동작을 유지했는지 | 회귀 오류·리뷰 수정량 |

응답 한 번의 가격보다 검토 가능한 결과까지 도달하는 비용을 보는것이다. 저렴한 설정으로 시작했지만 같은 오류를 반복하면 전체 작업 비용은 오히려 늘 수 있다.

## Kimi K3 추가는 선택지가 넓어지는 소식이다

8월 6일 [Kimi K3의 Copilot 제공](https://github.blog/changelog/2026-08-06-kimi-k3-is-now-available-in-github-copilot/)이 발표됐다. GitHub은 open-weight 모델로 소개하며 지원 환경에 단계적으로 배포한다고 안내했다.

조직용 Business·Enterprise에서는 관리자가 모델 정책을 활성화해야 사용할 수 있다. 발표가 나왔다고 모든 계정의 모델 목록에 즉시 보이는것으로 생각하지 않는게 좋겠다.

팀에서는 새 모델의 이름만 비교하기보다 사용하는 언어와 저장소 크기, 도구 호출 성공률을 같은 조건에서 살펴보면 좋겠다. 외부 모델을 사용할때 적용되는 데이터 처리 정책도 확인할 부분이다.

모델을 바꾸더라도 작업 로그와 테스트, 권한 정책은 유지할 수 있어야한다. 이렇게 만들어두면 특정 모델의 응답 스타일에 개발 프로세스 전체가 묶이는것을 줄일 수 있겠다.

# 3. 프론트엔드 — Next.js 16.3이 정식 출시됐다

8월 3일 [Next.js 16.3](https://nextjs.org/blog/next-16-3)이 나왔다. 개발 서버의 메모리 사용 개선, 빌드용 파일 캐시, 서버 렌더링 개선과 Instant Navigations가 주요 내용이다.

Turbopack의 메모리 회수와 반복 빌드 캐시가 기본 개선에 포함된다. Instant Navigations는 별도 설정으로 도입하는 기능 묶음이며, 실험적인 Rust React Compiler와도 상태를 구분해서 봐야한다.

## 버전 업데이트와 캐시 구조 변경을 나눠보자

먼저 현재 프로젝트의 빌드와 주요 화면이 새 버전에서 정상 동작하는지 확인하고 싶다. 그다음 탐색과 캐시 관련 옵션을 적용하면 어떤 변경이 문제를 만들었는지 추적하기 쉽다.

개발 서버가 빨라진것과 사용자의 페이지 이동이 빨라진것도 다른 측정이다. 로컬의 메모리 사용량, CI의 반복 빌드 시간, 실제 서비스의 탐색 지연을 각각 비교하면 좋겠다.

## Instant Navigations는 기다리는 부분을 나누는 문제다

16.3의 기능에는 Partial Prefetching, 탐색을 확인하는 개발 도구와 Playwright 테스트 도우미가 포함된다. Server Components와 Suspense, 명시적인 캐시 경계를 이용해 이동 전에 준비할 화면을 나누는 방향이다.

예를 들어 프로젝트 상세 화면이 아래와 같다고 생각해보자.

```text
프로젝트 상세
├─ 공통 레이아웃과 제목 영역
├─ 현재 사용자의 접근 권한
├─ 프로젝트 기본 정보
└─ 느린 통계·외부 연동 결과
```

통계 응답 하나가 느리다고 전체 화면이 같이 기다려야하는지 살펴볼 수 있다. 먼저 보여줄 영역과 로딩 상태를 분리하면 사용자가 무엇을 기다리는지 이해하기도 쉽겠다.

그렇다고 모든 영역을 무조건 미리 가져오면 서버 요청과 데이터 전송량이 늘 수 있다. 이동 가능성이 낮은 링크와 자주 사용하는 경로를 같은 방식으로 처리할 필요는 없다.

## 개인화 데이터의 범위도 같이 봐야한다

캐시를 추가할때는 무엇을 키로 구분하고 언제 갱신할지부터 생각해보자. 사용자와 조직, 권한에 따라 달라지는 데이터를 공용 정보처럼 취급하면 안되겠다.

로그인과 로그아웃, 조직 전환 뒤에도 화면이 올바르게 갱신되는지 확인하고 싶다. 한 번 빠르게 열린 화면보다 상태가 바뀌었을때 맞는 정보를 보여주는지가 더 중요하다.

설정 이름을 외우는것보다 실제 탐색 경로 하나를 고르고, 어디까지 즉시 보이며 어느 부분이 네트워크를 기다리는지 확인하는 방식이 도움이 될것같다..

# 4. 백엔드 — Spring Boot 전환은 지원 범위부터 확인하자

이번주 새 릴리스는 아니지만 Spring 프로젝트에서는 지원 정책을 다시 볼 필요가 있다. [6월 25일의 Spring Boot 3.5.16 발표](https://spring.io/blog/2026/06/25/spring-boot-3-5-16-available-now/)는 3.5.x의 마지막 OSS 릴리스라고 명시했다.

OSS 지원을 이어가려면 4.0.x 또는 4.1.x로 이동하거나 별도의 상용 지원을 검토하는 선택지가 있다. 현재 서비스가 잘 실행된다는 사실과 앞으로 수정 사항을 받을 수 있다는 사실은 구분해야한다.

## 메이저 버전 숫자만 바꾸면 끝나지는 않겠다

먼저 사용하는 Java 버전과 라이브러리, 빌드 플러그인, 프레임워크 연동 모듈을 정리하면 좋겠다. 팀에서 직접 작성한 코드보다 외부 Starter의 호환성이 일정에 영향을 줄 수도 있다.

업그레이드 브랜치에서는 애플리케이션 시작뿐 아니라 인증과 직렬화, DB 접근, 배치와 메시징을 확인하고 싶다. 설정 파일을 읽는것과 실제 운영 경로가 정상 동작하는것은 다르다.

| 확인할 경로 | 놓치기 쉬운 부분 |
| --- | --- |
| HTTP 요청 | 인증·인가·오류 응답 |
| 데이터 처리 | 트랜잭션·직렬화·날짜 형식 |
| 비동기 작업 | 재시도·중복 처리·종료 시점 |
| 운영 연동 | 메트릭·트레이스·로그 수집 |

## Agent가 호출하는 HTTP Client도 외부 입력을 받는다

[Spring Boot 4.1](https://spring.io/blog/2026/06/10/spring-boot-4/)에는 Spring gRPC 지원과 OpenTelemetry 개선, `InetAddressFilter`를 이용한 HTTP Client의 SSRF 완화 등이 포함됐다.

AI 기능에서 모델이 만든 URL을 서버가 조회한다면 대상 주소를 검사하는 구조가 필요하다. 사용자가 직접 입력한 URL과 마찬가지로 내부 자원 접근 여부를 확인해야하기 때문이다.

필터 기능 하나가 서비스 전체의 SSRF 방어를 완성해주는것은 아니다. 사용하는 HTTP Client에 정책이 적용됐는지, 리다이렉트와 네트워크 접근 범위는 어떻게 제한하는지 같이 봐야겠다.

관측도 비슷하다. 모델 요청과 도구 호출, DB 조회를 연결해서 볼 수 있다면 Agent 작업이 오래 걸리는 원인을 구분하기 쉬워진다. 다만 수집하는 로그에 비밀값과 원문 데이터를 무조건 넣지는 않아야겠다.

# 5. DevOps — 코드를 만드는 자동화에 검증 자동화도 붙는다

8월 4일 [GitHub Code Quality의 Coverage 자동 설정](https://github.blog/changelog/2026-08-04-code-coverage-automatic-enablement-in-code-quality-settings/)이 공개 프리뷰로 나왔다. 저장소에 맞는 빌드·테스트·리포트 업로드 Workflow를 Agent가 작성해 PR로 제안하는 방식이다.

설정을 검토하고 병합하는 과정은 남아있다. 발표에서는 GitHub.com의 Code Quality 사용자를 대상으로 안내하며 Enterprise Server는 아직 지원 대상이 아니라고 설명한다.

## Workflow 생성과 테스트 품질은 나눠서 보자

설정 파일이 생겼다고 중요한 동작을 검증하는 테스트까지 자동으로 갖춰진것은 아니다. 어떤 테스트 명령이 실행되는지와 리포트에서 빠진 디렉터리가 있는지 확인해야겠다.

특히 커버리지 수치가 높아도 권한 검사와 오류 경로가 빠질 수 있다. 파일의 줄을 실행했다는 사실과 업무 결과가 맞다는 사실은 다르기 때문이다.

Agent가 만든 PR이라면 변경한 기능의 정상 경로와 실패 경로를 같이 확인하고 싶다. 기존 테스트만 모두 통과하는것보다 이번 변경을 잘못 구현했을때 실패하는 검증이 있는지가 중요하다.

## CodeQL 설정도 조직 단위로 맞출 수 있다

같은 날 [Code Scanning 기본 설정의 사용자 정의](https://github.blog/changelog/2026-08-04-customize-code-scanning-default-setup-at-scale/)가 추가됐다. `github-codeql-config-file` 저장소 속성으로 별도 설정 파일을 지정해 조직의 여러 저장소에 적용할 수 있다.

또 [CodeQL 2.26.2](https://github.blog/changelog/2026-08-04-codeql-2-26-2-adds-swift-6-3-3-and-kotlin-2-4-10-support/)는 Swift 6.3.3과 Kotlin 2.4.10 지원, 일부 쿼리의 정확도 개선을 알렸다. 언어 도구를 올릴때 분석 도구의 지원 버전도 같이 맞춰야하는 이유다.

조직 공통 설정을 만든다면 제외 경로와 사용하는 쿼리, 설정 변경의 검토 책임을 정해보자. 공통 설정 하나의 변경이 여러 저장소의 분석 범위를 바꿀 수 있기 때문이다.

내가 구성한다면 Agent의 코드 생성 뒤에 테스트와 정적 분석, 필요한 리뷰를 연결할것같다. 분석 결과가 없다는것과 보안 문제가 없다는것은 같지 않으므로, 통과한 검증의 범위를 함께 남기면 좋겠다.

# 6. 데이터베이스 — 운영 패치와 PostgreSQL 19 시험을 구분하자

현재 PostgreSQL 19는 [7월 16일 공개된 Beta 2](https://www.postgresql.org/about/news/postgresql-19-beta-2-released-3350/) 단계다. 공식 안내는 운영 사용을 권하지 않으며 일반적인 애플리케이션 부하로 시험하고 피드백을 제공하도록 설명한다.

발표에서는 정식 릴리스를 9월에서 10월 무렵으로 예상하지만, 시험 결과에 따라 일정과 세부 기능이 달라질 수 있다. 특정 날짜에 확정 출시된다고 전제하지 않는게 좋겠다.

## 차기 버전은 우리 쿼리로 확인해보자

새 기능 목록만 읽는것보다 실제로 사용하는 쿼리와 확장, 드라이버를 시험해보면 좋겠다. 같은 SQL이 실행돼도 실행 계획과 응답 시간, 메모리 사용이 달라질 수 있다.

시험 데이터는 민감한 정보를 제거한 별도 환경에 준비하고, 현재 버전과 같은 조건으로 비교하고 싶다. 베타 환경을 만들면서 운영 연결 정보가 섞이지 않도록 하는것도 필요하다.

새 메이저 버전으로 이전하는 시험과 기존 메이저의 유지보수 패치는 다른 작업이다. 지금 운영하는 버전의 업데이트를 미뤄두고 베타만 살펴보는 순서는 피하고 싶다.

## Agent의 데이터도 원본과 문맥을 나누면 좋겠다

관계형 업무 데이터는 PostgreSQL에 두고, 짧은 수명의 상태나 캐시는 Redis에 두는 구성을 생각할 수 있다. 이것은 모든 서비스가 반드시 따라야하는 표준은 아니다.

문서의 의미를 기준으로 검색해야할때는 벡터 검색을 검토할 수 있다. 고객 ID와 주문 상태로 정확히 찾을 수 있는 데이터까지 임베딩으로 바꿀 필요는 없겠다.

Agent가 기억하는 내용에도 소유자와 유효 기간이 필요하다. 대화에서 나온 오래된 추정을 업무 시스템의 확정된 상태처럼 사용하지 않도록 원본 조회 경로를 두면 좋겠다.

# 7. 이번주에는 자동화 하나의 완료 기준을 정해보고 싶다

이번주 공부할것을 하나 고른다면 댓글로 시작해서 검토 가능한 결과를 남기는 작은 자동화가 좋겠다. 처음에는 오류를 조사하고 재현 테스트를 제안하는 정도로 범위를 좁혀볼 수 있다.

시작할때는 요청한 사람과 대상 커밋을 남기고, 끝날때는 실행한 검증과 남은 불확실성을 기록해보자. 실패했을때 다시 실행할 수 있는지와 비용을 어디서 확인할지도 같이 보면 좋겠다.

Next.js를 사용한다면 16.3 업데이트 검토도 이번주의 할 일이다. 주요 탐색 하나를 고르고 변경 전후의 화면과 요청 흐름을 비교하면 캐시 설정의 의미를 이해하기 쉬울것같다.

Agent가 코드를 작성하는 속도만 보는것보다 그 결과를 안전하게 확인하고 다음 작업으로 연결하는 구조를 만들어보고 싶다. 이번주 소식은 그 실행과 검증의 기준을 개발자가 더 구체적으로 정해야한다는 느낌이다..


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

독자의 메모