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

# 이번주는 Agent Plugin과 PostgreSQL 보안 패치를 챙기자

이번주에는 Agent의 기능을 팀에서 공유하는 방식과 실제 운영 시스템을 유지하는 일이 같이 눈에 들어왔다. GitHub은 Agent Plugins 1.0 지원을 공개했고, PostgreSQL은 지원 버전 전체의 보안 업데이트를 내놨다.

8월 10일부터 14일까지의 소식을 중심으로 정리해보았다. Next.js 16.3은 지난주 출시의 연장선에서 보고, Agent Tool과 Sandbox는 실제 서비스에 붙인다면 어떻게 설계할지 같이 생각해보려고 한다.

| 분야 | 살펴볼 내용 | 먼저 확인할 부분 |
| --- | --- | --- |
| AI | Agent Plugins 1.0 지원 | 공통 표준과 제품별 확장 |
| 프론트엔드 | Next.js 탐색·캐시 적용 | 화면 경계와 회귀 검증 |
| 백엔드 | MCP Tool의 운영 | 계약·업무 권한·버전 |
| DevOps | Agent의 실행 환경 | 권한·비밀값·네트워크 |
| 데이터베이스 | PostgreSQL 8월 보안 패치 | 업데이트와 후속 조치 |
| 데이터 운영 | Redis Software 유지보수 | 사용 제품과 토폴로지 |

# 1. AI — Agent 기능을 하나의 패키지로 공유한다

8월 12일 [GitHub의 Agent Plugins 1.0 지원](https://github.blog/changelog/2026-08-12-agent-plugins-1-0-in-vs-code-copilot-cli-and-the-copilot-app/)이 공개됐다. VS Code와 Copilot CLI, Copilot 앱, Copilot SDK에서 사용할 수 있다.

표준 자체는 지난주인 8월 6일 발표됐다. 이번주 소식의 핵심은 GitHub의 여러 클라이언트에서 이를 지원한다는것이다. 공통 표준이 묶는 대상은 Agent Skills와 MCP 서버 설정이다.

## 공통 규격과 제품별 기능은 구분하자

구성에는 `plugin.json`, `skills/`, `mcp.json` 등이 사용된다. Copilot 전용 Custom Agent와 Command, Rule, Hook 등은 `com.github.copilot/` 이름 공간에 둔다.

따라서 같은 패키지를 여러 도구에서 읽을 수 있어도 모든 제품별 기능이 똑같이 실행되는것은 아니다. 다른 클라이언트가 이해하는 공통 부분과 무시할 수 있는 확장을 나눠봐야겠다.

```text
Agent Plugin
├─ 공통 Skill: 작업 절차와 지침
├─ 공통 MCP 설정: 외부 도구 연결
└─ 제품별 확장: 해당 클라이언트의 추가 기능
```

GitHub은 기존 Plugin도 계속 지원한다고 안내한다. 이미 사용하는 구성을 무조건 바꾸기보다 중복 관리가 많은 부분부터 표준화의 이점을 확인하면 좋겠다.

## 팀의 작업 방식도 버전으로 관리할 수 있겠다

예를 들어 장애 조사 방법을 팀에서 공유한다고 생각해보자. 어떤 로그를 먼저 확인하고 결과를 어떤 형식으로 남길지 Skill에 적고, 필요한 조회 기능을 MCP로 연결할 수 있다.

여기서 작업 방법을 설명하는 문서와 실제 호출 권한은 다르다. Skill에 운영 로그를 보라고 적혀있다고 그 문서가 운영 계정의 권한을 만들어주는것은 아니다.

내가 관리한다면 Plugin의 변경 내역에 작업 절차와 도구 계약의 변경을 같이 적을것같다. 도구가 반환하는 필드가 바뀌었는데 Skill은 예전 필드를 기준으로 설명하면 실행 결과가 흔들릴 수 있다.

## 설치하기 쉬워질수록 내용 확인은 필요하다

공유 패키지에는 외부 MCP 서버 주소나 로컬에서 실행할 명령이 포함될 수 있다. 이름이 익숙하다는 이유만으로 어떤 프로세스를 시작하는지 모르고 설치하면 곤란하다.

Plugin을 검토할때는 제공하는 Skill과 연결 대상, 실행 명령, 필요한 권한을 확인하고 싶다. 실제 비밀값은 패키지에 넣지 않고 사용하는 환경에서 별도로 주입하는 편이 좋겠다.

# 2. 프론트엔드 — Next.js 16.3은 탐색 경계부터 확인해보자

[Next.js 16.3의 정식 출시](https://nextjs.org/blog/next-16-3)는 지난주 8월 3일 소식이다. 이번주에는 이를 프로젝트에서 어떻게 적용할지 살펴보면 좋겠다. Instant Navigations와 Partial Prefetching은 명시적으로 도입하는 기능 묶음이다.

모든 화면을 Client Component로 바꾸는 방식보다 Server Component와 Suspense, 캐시의 경계를 어떻게 나눌지 보는 흐름이다. 빠른 탐색과 정확한 데이터 표시를 함께 확인해야겠다.

## 화면 전체가 느린 데이터 하나를 기다리는지 보자

관리자 화면에서 메뉴와 제목, 검색 조건은 빨리 보여줄 수 있는데 통계 쿼리 때문에 아무것도 나타나지 않을 수 있다. 이때 화면이 어떤 데이터에 묶여있는지 살펴보고 싶다.

공통 레이아웃과 느린 본문을 분리할 수 있으면 로딩 상태도 더 구체적으로 표현할 수 있다. 반대로 루트 레이아웃에서 모든 데이터를 기다리면 하위 화면의 경계를 나눠도 효과가 제한될 수 있겠다.

```text
먼저 보여줄 화면
  ├─ 메뉴·제목·기본 구조
  └─ Suspense 경계
       ├─ 로딩 상태
       └─ 사용자별 데이터와 느린 결과
```

## 빠르다는 판단을 테스트로 남길 수 있다

지난주 8월 6일 공개된 [v0의 탐색 개선 사례](https://nextjs.org/blog/making-v0-navigations-instant)는 Agent가 실패하는 테스트를 만들고 수정과 재검증을 반복한 과정을 설명한다. `@next/playwright`의 `instant()` 도우미도 소개한다.

이 도우미는 탐색을 멈춘 상태에서 네트워크 응답 없이 어떤 UI가 보이는지 검증하는 방식이다. 페이지의 모든 데이터가 특정 시간 안에 도착한다고 측정하는 일반 성능 테스트와는 구분하면 좋겠다.

우리 프로젝트에 적용한다면 먼저 핵심 이동 경로를 정하고 싶다. 목록에서 상세로 가는 경로와 설정 화면처럼 자주 사용하는 이동을 고르는것이다.

기대하는 제목과 로딩 화면이 보이는지 확인하고, 데이터가 도착한 뒤에는 내용까지 맞는지 별도 검증을 붙일 수 있다. 빠르게 잘못된 내용을 보여주는 화면은 원하는 결과가 아니기 때문이다.

## 갱신과 권한 변경 뒤의 동작도 중요하다

캐시를 적용했다면 데이터를 수정한 직후와 다른 탭에서 변경한 뒤, 사용자나 조직을 전환한 뒤의 동작을 확인하고 싶다. 같은 URL이라도 표시할 데이터의 범위가 달라질 수 있다.

이번주에는 API 이름을 많이 외우기보다 탐색 하나의 기대 동작을 테스트로 남겨보면 좋겠다. 이후 Agent가 화면을 수정하더라도 같은 기준으로 회귀를 확인할 수 있을것같다..

# 3. 백엔드 — Tool을 배포하면 계약도 관리해야한다

Plugin으로 MCP 연결을 공유할 수 있게 되면 Tool의 사용자가 한 프로젝트 안에만 머물지 않을 수 있다. 서버의 작은 변경이 여러 클라이언트와 작업 절차에 영향을 줄 수 있다는 뜻이다.

## 업무 규칙은 Service에서 공유하면 좋겠다

기존 REST API가 있다면 MCP Handler 안에 같은 로직을 새로 작성하기보다 공통 업무 서비스를 호출하는 구성을 생각할 수 있다.

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

Spring Boot와 NestJS에서 익숙한 계층을 유지하면서 입력과 출력의 표현을 나누는것이다. 어떤 고객을 조회할 수 있는지와 주문 상태를 언제 바꿀 수 있는지는 인터페이스가 달라도 같아야한다.

모델이 입력한 사용자 ID는 인증된 신원과 같지 않다. 실제 요청 주체를 서버에서 확인하고 Service까지 전달해야 기존 권한 검사를 재사용할 수 있다.

## 입력 스키마가 맞아도 업무 요청은 틀릴 수 있다

수량이 정수라는것을 확인했어도 구매 가능한 수량인지는 별도 검사다. 고객 ID의 형식이 맞아도 현재 조직의 고객인지는 다시 확인해야한다.

Tool을 설계한다면 입력 스키마와 업무 검증, 접근 권한을 나눠 생각하면 좋겠다. 스키마 검사를 통과했다는 이유로 요청 전체를 신뢰하지 않는것이다.

오류도 모델이 다음 행동을 고를 수 있도록 구분하고 싶다. 입력 수정이 필요한 오류와 권한 거절, 일시적인 외부 장애가 같은 문자열로 반환되면 불필요한 재시도가 늘 수 있다.

## 쓰기 작업에는 중복 실행과 확인 절차가 필요하다

문서 조회와 환불 실행을 같은 수준의 도구로 다루기는 어렵겠다. 외부 상태가 바뀌는 작업이라면 어떤 내용을 반영할지 검토하고 실행하는 단계를 나눌 수 있다.

요청 ID와 처리 상태를 저장하면 타임아웃 이후 다시 호출됐을때 이미 반영한 작업인지 확인하기 쉽다. 네트워크 응답을 못 받았다고 실제 업무도 실패했다고 단정할 수는 없기 때문이다.

계약 테스트에는 정상 호출뿐 아니라 다른 조직의 자원 조회와 잘못된 상태 변경, 같은 요청의 재전송을 넣고 싶다. REST와 MCP에서 같은 기준으로 거절되는지 확인하는것도 도움이 되겠다.

# 4. Cloud·DevOps — Plugin과 Sandbox의 권한은 별도다

작업 절차와 도구 설정을 공유해도 실제 실행 환경의 보안 경계가 자동으로 정해지지는 않는다. Agent가 Shell과 네트워크, 저장소와 외부 API를 함께 사용한다면 각 경로를 살펴봐야한다.

컨테이너를 사용했다는 사실 하나보다 그 안에 어떤 자격 증명과 마운트, 네트워크 접근이 주어졌는지가 중요하겠다. 실행이 끝난 뒤 남은 자원과 비밀값을 어떻게 정리하는지도 포함된다.

## 권한은 필요한 작업에서 출발하자

문서의 오타를 수정하는 Agent라면 운영 DB에 연결할 이유가 없겠다. 테스트가 필요하다면 테스트용 자원과 제한된 계정을 주는 방법부터 생각할 수 있다.

```text
작업 시작
  → 필요한 저장소와 권한 결정
  → 임시 실행 환경 준비
  → 제한된 도구·네트워크로 실행
  → 테스트·결과물 검토
  → 자격 증명과 임시 자원 정리
```

환경 변수에 비밀값을 넣었다면 로그와 오류 출력, 결과 파일로 복사되지 않는지도 봐야한다. 저장소 접근 토큰을 만들때도 필요한 저장소와 수명, 가능한 작업을 좁히고 싶다.

## 네트워크가 열려있으면 파일 격리만으로 충분하지 않다

파일 시스템을 분리해도 외부로 요청을 보낼 수 있다면 데이터가 밖으로 나가는 경로는 남는다. 반대로 내부망을 폭넓게 허용하면 Agent 작업이 접근할 자원도 늘어난다.

패키지를 설치할때와 외부 자료를 조회할때, 업무 API를 호출할때 필요한 대상은 다를 수 있다. 허용할 목적지를 정하고 실제 차단이 적용되는지 시험하면 좋겠다.

리소스 제한도 필요하다. 반복되는 테스트와 설치가 CPU와 메모리, 저장 공간을 계속 사용할 수 있기 때문이다. 실행 시간과 재시도 횟수, 작업 취소 경로를 같이 정해두고 싶다.

## 작업 하나의 기록을 연결해보자

Agent 세션 ID와 대상 커밋, Plugin 버전, 도구 호출, CI 결과를 연결하면 문제가 생겼을때 원인을 찾기 쉽다. 모델이 완료라고 답한 시점만 남기는것보다 실제 결과물을 확인할 수 있어야한다.

# 5. 데이터베이스 — PostgreSQL 보안 업데이트를 먼저 확인하자

8월 13일 [PostgreSQL 지원 버전의 업데이트](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와 PostgreSQL 19 Beta 3가 함께 공개됐다.

28건의 보안 취약점과 110건 이상의 버그를 수정한 릴리스다. 18.5는 회귀 문제로 배포되지 않아 18.4에서 18.6으로 넘어간다. 빠진 버전을 따로 찾을 필요는 없겠다.

## 먼저 같은 메이저의 패치와 베타를 구분하자

운영 중인 18.x를 18.6으로 올리는것과 19 Beta 3로 옮기는것은 다르다. 이번 보안 패치를 적용하기 위해 차기 메이저의 베타를 도입할 필요는 없다.

일반적인 같은 메이저의 Minor 업데이트에는 dump/restore나 `pg_upgrade`가 필요하지 않다고 안내한다. 다만 이것이 서비스 중단이나 후속 점검도 전혀 없다는 뜻은 아니다.

관리형 DB라면 제공사의 패치 버전과 적용 일정, 확장 지원 범위를 확인하고 싶다. 직접 운영한다면 백업과 복구 가능 여부, 복제 구성과 재시작 계획을 함께 점검하면 좋겠다.

## 18.6은 첫 세 보안 항목의 영향도 확인해야한다

[18.6 릴리스 노트](https://www.postgresql.org/docs/18/release-18-6.html)는 업데이트 뒤 설정 조정과 데이터 정리가 필요할 수 있다고 설명한다. 특히 아래 세 가지는 사용하는 기능에 따라 확인해야한다.

| 항목 | 영향 확인 |
| --- | --- |
| Logical Decoding | 외부 출력 Plugin은 새 `output_plugin_libraries` 허용 목록에 등록 필요 |
| pgcrypto PGP 암호화 | OpenSSL이 거절한 암호 알고리즘으로 생성된 데이터가 있는지 조사 |
| psql의 COPY 스크립트 | 의도적으로 실패하는 `COPY FROM STDIN` 시험 뒤 데이터 종료 표시 점검 |

pgcrypto의 해당 데이터는 암호화가 제대로 적용되지 않았을 수 있다. 릴리스 노트의 복구 절차와 생성 당시 OpenSSL 조건을 확인한 뒤 식별·복구·재암호화 계획을 세워야한다. 복호화 옵션 하나를 전체 서비스에 무조건 켜는 방식으로 이해하면 안되겠다.

우리 환경이 외부 Logical Decoding Plugin을 사용하는지, 암호화 함수와 SQL 복원 스크립트를 사용하는지부터 조사하면 범위를 좁힐 수 있다. 다른 메이저 버전은 해당 버전의 릴리스 노트를 확인해야겠다.

## 인덱스와 통계는 별도의 후속 점검이다

보안 설정 조정과 별개로 병렬 GIN 인덱스 생성에서 잘못된 `reltuples`가 남을 수 있다. GIN이 있는 테이블의 값이 비정상이라면 공식 안내에 따라 `ANALYZE` 등으로 바로잡는지 검토해야한다.

`btree_gist`의 특정 float·bit 인덱스와 매우 많은 라벨을 가진 `ltree` 값의 B-tree 인덱스는 재생성이 필요할 수 있다. 모든 인덱스를 일괄 재생성하라는 안내는 아니다.

내가 점검한다면 확장과 인덱스 목록을 먼저 확인하고, 영향을 받는 대상을 좁힌 뒤 작업 시간과 잠금 영향을 검토할것같다. 업데이트 바이너리만 바꾸면 기존 통계와 인덱스까지 모두 자동 복구된다고 생각하지 않아야겠다.

## PostgreSQL 19 Beta 3는 시험 환경에서 보자

19 Beta 3는 여전히 운영 도입 대상과 구분해야한다. 베타에서는 세부 기능과 동작이 바뀔 수 있으므로 이전 시험에서 기대한 기능도 다시 확인하는 편이 좋겠다.

# 6. Redis — 제품 이름과 버전을 정확히 보자

[Redis Software 8.0.20-96의 8월 유지보수 노트](https://redis.io/docs/latest/operate/rs/release-notes/rs-8-0-releases/rs-8-0-20-96/)에는 Active-Active 업그레이드와 동기화, 노드 간 암호화 인증서, 메트릭 Exporter 등의 수정이 포함됐다.

Kubernetes용 [8.0.20-26](https://redis.io/docs/latest/operate/kubernetes/release-notes/8-0-20-releases/8-0-20-26-august2026/)도 해당 Redis Software 버전을 지원하는 유지보수 릴리스로 안내한다.

이 숫자는 Redis Open Source 서버의 버전과 같지 않다. 내가 사용하는 제품이 Redis Software인지, Kubernetes Operator를 포함한 구성인지부터 확인해야겠다.

## 배포 구조에 따라 확인할 경로가 다르다

단일 지역의 캐시와 여러 지역에서 쓰는 Active-Active 데이터는 업그레이드 검증 범위가 다를 수 있다. 동기화와 인증서, 모니터링 관련 수정이라면 평상시 조회만 확인해서는 부족하겠다.

노드 교체와 재연결, 지표 수집이 정상적으로 이어지는지도 확인하고 싶다. 관리 API와 데이터 요청 경로가 각각 살아있는지 구분하는것도 도움이 된다.

Agent의 문맥 저장에 Redis를 쓰더라도 같은 운영 원칙이 필요하다. 어떤 데이터가 유실돼도 되는 캐시인지, 복구해야하는 업무 상태인지에 따라 보존과 복구 정책을 나눠야겠다.

# 7. 이번주는 운영 패치와 재사용 가능한 Agent 구성을 나눠 챙기자

PostgreSQL을 운영한다면 버전과 확장, 복제와 암호화 사용 여부를 확인하는것부터 시작하고 싶다. 패치 적용 뒤 어떤 항목을 검증했는지 남겨야 다음 배포와 장애 조사에도 도움이 된다.

AI 쪽에서는 작은 Plugin 하나에 작업 절차와 읽기 전용 MCP 연결을 묶어보면 좋겠다. 공통 부분이 여러 클라이언트에서 어떻게 읽히는지, 제품별 확장이 빠지면 무엇이 달라지는지 확인하는것이다.

Next.js에서는 주요 탐색의 기대 화면을 테스트로 남기고 싶다. Agent가 코드를 바꿔도 품질 기준을 유지하려면 어떤 상태를 성공으로 볼지 먼저 정해야하기 때문이다.

이번주에는 도구를 더 많이 연결하는것만큼 연결된 구성의 버전과 권한, 검증 범위를 관리하는 일이 중요해보인다. 재사용하기 편한 환경과 실제 운영을 믿고 맡길 수 있는 환경을 같이 만들어가야할것같다..


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

독자의 메모