[2026.04.24 주간 개발 트렌드] Kubernetes 1.36과 Spring 패치, GPT-5.5 API

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

# 이번주는 Agent를 실행하는 기반과 서버 보안을 함께 봐야겠다

이번주에는 Spring Framework 보안 패치와 pg-delta 공개 알파, Claude Opus 4.7이 나왔다. Cloudflare와 OpenAI에서도 Agent가 코드를 실행하고 상태를 유지하는 도구를 소개했다.

소식이 많지만 모두 같은 계층의 변화는 아니다. 지금 운영하는 웹 서버의 수정과 실험적인 스키마 도구, 모델의 능력과 실행 인프라를 나눠서 봐야한다.

4월 13일부터 17일까지의 내용을 정리해보았다.

| 분야 | 소식 | 제공 상태와 확인할 부분 |
| --- | --- | --- |
| Backend·보안 | Spring Framework 패치 | 사용중인 버전과 웹 처리 경로 |
| Database | pg-delta | Public Alpha, 생성 SQL의 검토 |
| AI | Opus 4.7 | 정식 제공, 긴 개발 작업의 비교 |
| 실행 환경 | Cloudflare Sandboxes | GA, 파일·프로세스와 격리 실행 |
| 브라우저·Agent | Browser Run·Project Think | 관찰 도구와 Preview 실행 기반 |
| 개발 SDK | OpenAI Agents SDK 확장 | 격리 실행과 하네스·메모리 제어 |

개인적으로는 Agent가 더 많은 작업을 할 수 있게 되는만큼 어떤 환경에서 무엇을 실행했는지 확인하는 구조가 중요해보인다.

# 1. Backend·보안 — Spring Framework의 웹 처리 취약점이 수정됐다

4월 17일 [Spring Framework 6.2.18과 7.0.7](https://spring.io/blog/2026/04/17/spring-framework-6-2-18-and-7-0-7-available-now/)이 공개됐다. WebFlux의 multipart 임시 파일 처리 DoS, MVC·WebFlux의 정적 리소스 캐시 오염, Windows의 정적 리소스 처리 DoS 등 세건의 보안 수정을 포함한다.

Spring 기반 서버라면 직접 선언한 버전과 실제 포함된 Framework 버전을 확인해야겠다. Spring Boot를 사용한다면 관리되는 의존성의 조합도 함께 살펴봐야한다.

## 사용하는 기능과 실제 실행 버전을 연결하자

프로젝트 파일에 적힌 버전만으로 배포 상태를 판단하기 어렵다. 빌드 결과에 포함된 라이브러리와 현재 실행중인 애플리케이션이 같은 상태인지 알아야한다.

이번 공지와 관련해서는 파일 업로드와 정적 리소스 제공 경로를 먼저 확인해볼 수 있다. WebFlux와 MVC 중 무엇을 사용하는지, Windows에서 실행하는 구성인지에 따라 검토할 부분이 달라진다.

```text
패치 대상의 확인
의존성 해석 → 배포 결과 → 실행 환경 → 실제 사용하는 웹 기능
```

공식 영향 조건을 코드와 설정에 대조해 적용 계획을 잡으면 좋겠다. 프레임워크 이름이 같다는 이유로 모든 서비스의 노출과 우선순위를 같은 수준으로 판단할 필요는 없다.

반대로 현재 사용하지 않는다고 생각한 리소스 경로가 기본 설정으로 열려있는지도 살펴볼만하다. 기능의 존재와 외부 요청이 도달하는 경로를 구분해서 확인하는것이다.

## 정상 업로드와 실패 이후의 정리도 보자

파일 처리에서는 정상 완료뿐 아니라 취소와 중간 실패를 함께 확인하면 좋겠다. 임시 파일과 관련 자원이 요청 종료 뒤 어떤 상태로 남는지도 운영에서 중요하다.

테스트에는 크기가 다른 파일과 잘못된 입력, 클라이언트가 연결을 중단하는 조건을 포함할 수 있다. 실제 공격을 운영에 재현하기보다 격리된 환경에서 정상 동작과 자원 정리를 보는것이다.

정적 리소스는 예상한 파일과 캐시 헤더, 오류 응답을 비교할 수 있다. 패치 이후 프록시와 CDN이 사용하는 경로에서도 같은 결과인지 확인해야겠다.

업데이트가 끝나면 적용 버전과 배포 범위, 확인한 경로를 기록해두면 좋다. 의존성을 바꾼것과 운영 인스턴스에 반영한것은 다른 단계이기 때문이다.

# 2. Database — pg-delta는 목표 스키마에서 마이그레이션을 만든다

4월 16일 Supabase가 [pg-delta 기반 선언적 스키마 관리](https://supabase.com/changelog/44938-public-alpha-declarative-schema-management-with-pg-delta)를 공개 알파로 소개했다. SQL 파일로 원하는 스키마를 표현하면 CLI가 차이를 계산해 마이그레이션을 생성하는 방식이다.

이번주 기준 실험적 플래그 뒤의 Alpha다. 지원 범위가 완성된 정식 도구로 이해하면 안되겠다. 목표 상태를 작성하는 편의성과 실제 적용 과정을 나눠서 봐야한다.

## 스키마 차이와 데이터 변환은 같은 문제가 아니다

두 스키마를 비교하면 무엇이 추가되거나 제거됐는지 알 수 있다. 하지만 어떤 변경이 이름 변경이고 어떤 변경이 삭제 후 생성인지 사용자의 의도를 항상 알 수 있는것은 아니다.

예를 들어 컬럼 이름을 바꾼것과 같은 타입의 새 컬럼을 추가한것은 최종 모양이 비슷해보일 수 있다. 실제로 기존 값을 유지해야하는지는 별도의 판단이 필요하다.

```text
선언적 스키마 작업에서 나눌것
목표 상태 → 차이 계산 → 적용 SQL → 데이터 변환 → 서비스 검증
```

생성된 SQL은 검토할 결과물이다. 삭제와 타입 변환, 제약 추가가 포함됐다면 현재 데이터와 배포 순서에서 어떤 영향을 주는지 확인해야한다.

도구가 SQL을 생성해주면 반복 작업을 줄일 수 있다. 대신 그 SQL이 어떤 가정을 담고 있는지 읽을 수 있어야 운영에 적용할 근거가 생긴다.

## 알파 시험은 대표 객체와 전환 경로를 고르자

간단한 테이블 하나만 비교하면 실제 프로젝트에서 필요한 범위를 알기 어렵다. 뷰와 함수, 인덱스와 정책 등 현재 사용하는 객체를 작은 예제에 포함해볼 수 있다.

대상 객체를 모두 지원한다고 가정하지 말고 인식한 차이와 놓친 차이를 비교하자. 지원하지 않는 부분은 수동 마이그레이션과 어떻게 함께 관리할지도 생각해야한다.

빈 DB에서 목표 스키마를 만드는 경우와 기존 데이터가 있는 DB를 바꾸는 경우를 나눠보면 좋겠다. 같은 SQL이라도 실행 시간과 실패 조건은 달라질 수 있기 때문이다.

개인적으로는 이번 알파를 운영 배포의 자동 판단자보다 스키마 변경 초안을 만드는 도구로 시험해보고 싶다. 기존 마이그레이션과 결과를 대조하면 도움이 되는 범위가 보이겠다.

# 3. AI — Opus 4.7은 긴 소프트웨어 작업과 시각 정보를 강화했다

4월 16일 [Claude Opus 4.7](https://www.anthropic.com/news/claude-opus-4-7)이 정식 제공됐다. Anthropic은 복잡한 소프트웨어 개발과 장기 작업의 일관성, 지시 준수와 결과 검증, 시각 정보 처리의 개선을 강조했다.

발표 내용은 모델의 방향을 이해하는 자료로 보고, 우리 프로젝트의 작업에서는 같은 요구사항으로 결과를 비교해보면 좋겠다.

## 긴 작업은 중간의 조건을 잃지 않는지 보자

여러 파일을 수정하는 작업에서는 초기에 정한 제약과 나중에 발견한 문제가 함께 유지되어야한다. 테스트를 통과시키기 위해 원래 요구를 바꾸면 결과를 받아들이기 어렵다.

예를 들어 기존 API의 호환성을 지켜야하는 리팩터링이라면 최종 코드와 함께 공개 계약이 유지됐는지 확인해야한다. 내부 코드가 단순해졌다는 사실만으로 작업이 끝나지는 않는다.

중간에 실패가 생겼을때 어떤 가정을 바꿨는지도 중요하다. 모델이 필요없는 구조를 계속 추가하기보다 원인을 좁히고 수정 범위를 설명하는지 살펴볼 수 있다.

```text
긴 작업의 검토 기준
원래 제약 / 현재 변경 / 실패 원인 / 검증 결과 / 남은 질문
```

작업이 길어질수록 마지막 설명의 정확성도 함께 평가하고 싶다. 실행하지 않은 검증을 완료했다고 말하지 않는지, 남은 문제를 구분하는지가 실무 비용에 영향을 주기 때문이다.

## 화면 이해와 실제 조작은 연결해서 확인하자

시각 정보 처리의 개선은 복잡한 화면과 자료를 읽는 작업에 도움이 될 수 있다. 그래도 이미지에서 내용을 이해하는것과 실제 UI를 조작해 작업을 완료하는것은 다른 단계다.

스크린샷에 버튼이 보였어도 현재 앱에서는 로딩중이거나 다른 대화상자가 열려있을 수 있다. 조작을 수행한 뒤에는 바뀐 화면의 상태를 다시 확인해야한다.

UI 수정 작업에서도 예쁜 결과와 사용자 흐름의 완료를 나눠보자. 입력과 저장, 오류와 재시도가 실제로 연결되는지 확인하는것이다.

큰 저장소와 작은 저장소, 이미지가 포함된 작업과 코드만 있는 작업을 나눠 평가하면 모델의 장단점을 설명하기 쉽겠다. 모든 작업에서 같은 정도의 개선을 기대하기보다 반복되는 차이를 찾아보고 싶다.

# 4. 실행 환경 — Cloudflare Sandboxes가 GA가 됐다

4월 13일 [Cloudflare Sandboxes](https://blog.cloudflare.com/sandbox-ga/)가 정식 제공됐다. Agent가 파일을 읽고 코드를 실행하며 프로세스를 다룰 수 있는 격리된 환경이다.

코딩 Agent를 서비스로 제공한다면 모델 API와 별도로 이런 실행 계층이 필요하다. 생성한 코드를 어디서 실행하고 결과를 어떻게 가져올지 해결하는 영역이다.

## 실행 공간과 작업 상태의 수명을 나눠보자

프로세스가 살아있는 동안의 상태와 다음 실행까지 보관할 상태는 다를 수 있다. 설치한 의존성과 생성 파일, 실행중인 서버와 대화 기록을 같은 수명으로 취급하기 어렵다.

```text
Agent 작업 공간의 구성
입력 파일 + 의존성 + 수정 결과 + 실행 프로세스 + 작업 기록
```

실행 환경이 종료된 뒤에도 보관해야할 결과가 무엇인지 정해야한다. 수정 diff와 테스트 로그, 최종 파일처럼 사용자가 확인할 결과는 작업의 산출물로 연결할 수 있다.

반대로 임시 파일과 더이상 사용하지 않는 프로세스는 정리할 수 있어야한다. 작업이 끝났는데 자원이 계속 남으면 비용과 운영 상태를 설명하기 어려워진다.

세션을 다시 시작할때도 어떤 상태를 복원하는지 확인해야겠다. 파일이 남았다는 사실과 이전 프로세스가 같은 상태로 실행중이라는 사실은 다르다.

## 격리 실행과 외부 접근 정책은 함께 보자

코드를 격리된 환경에서 실행해도 외부 서비스에 접근하는 경로는 별도로 관리해야한다. 네트워크와 자격 증명, 사용자별 데이터의 범위를 정해야하기 때문이다.

작업에 필요한 연결만 제공하고 결과를 반환하는 인터페이스를 명확하게 하면 좋겠다. 모델이 생성한 코드에 모든 운영 비밀값을 직접 전달하는 방식과는 구분해서 설계할 수 있다.

실패한 작업이 다른 사용자의 환경이나 파일을 참조하지 않도록 작업 공간도 나눠야한다. 같은 프로젝트 이름을 사용해도 요청별 실행 범위가 분명해야 검토할 수 있다.

운영 시험에서는 정상 완료뿐 아니라 시간 초과와 취소, 실행중인 프로세스가 남은 경우를 포함해보고 싶다. 격리 환경이 있다는것과 서비스가 그 수명을 제대로 관리하는것은 다른 문제다.

# 5. 브라우저·Agent — 관찰과 영속 실행을 위한 도구가 넓어졌다

4월 15일 Cloudflare는 [Browser Run](https://blog.cloudflare.com/browser-run-for-ai-agents/)과 [Project Think](https://blog.cloudflare.com/project-think/)를 소개했다. Browser Run은 기존 Browser Rendering의 이름을 바꾸고 실시간 관찰과 사람의 개입, 세션 기록 같은 Agent용 기능을 강화했다.

Project Think는 긴 실행과 하위 Agent, 영속 세션 등을 위한 구성 요소를 제공한다. 이번주 기준 Preview이며 API가 바뀔 수 있는 단계다. Sandboxes의 GA와 같은 제공 상태로 묶으면 안되겠다.

## 브라우저 작업에는 관찰 가능한 근거가 필요하다

웹 자동화는 명령을 실행한 순서만 남겨서는 결과를 알기 어렵다. 사이트가 입력을 거절하거나 예상과 다른 페이지를 보여줄 수 있기 때문이다.

실시간 화면과 기록은 실패한 지점을 이해하는데 도움이 된다. 어느 단계에서 다른 상태가 나왔는지 알아야 같은 행동을 반복할지, 조건을 바꿀지 판단할 수 있다.

사람이 개입하는 흐름도 “Agent가 멈췄다”보다 구체적이어야한다. 어떤 정보를 기다리고 있는지, 사용자가 무엇을 결정해야하는지와 이후 어느 상태에서 이어갈지 알 수 있어야한다.

```text
브라우저 작업의 확인
현재 상태 읽기 → 행동 → 변경된 상태 확인 → 다음 판단
```

작업을 재개할때 오래된 화면 정보를 그대로 사용하면 안되겠다. 사람이 개입하는 동안 페이지와 로그인 상태, 선택된 항목이 바뀔 수 있기 때문이다.

## 긴 실행은 중단 뒤의 행동을 설계해야한다

영속 세션과 복구 기능은 작업을 이어가는데 도움이 된다. 다만 중단 직전에 외부 변경이 실제로 완료됐는지 확인하지 못했다면 재시작할 행동을 조심해서 정해야한다.

예를 들어 등록 요청을 보낸 뒤 응답을 받기 전에 연결이 끊겼다고 생각해보자. 무조건 다시 등록하기보다 현재 상태를 조회해 중복 변경을 피할 수 있어야한다.

하위 Agent로 작업을 나누는 경우에는 결과와 근거를 어떻게 모을지도 필요하다. 각 작업의 완료 설명만 합치는것보다 공유하는 계약과 최종 통합 결과를 확인해야한다.

Preview를 평가할때는 멋진 정상 데모 외에 취소와 재시작, 일부 실패가 있는 흐름을 시험해보고 싶다. 장기 실행의 장점은 중간에 문제가 생겼을때 더 분명하게 드러날 수 있다.

# 6. 개발 SDK — OpenAI는 하네스와 메모리의 제어를 넓혔다

4월 15일 [OpenAI Agents SDK 업데이트](https://developers.openai.com/api/docs/changelog)에는 격리 실행 환경과 오픈소스 하네스 수정, 메모리 생성 시점과 저장 위치의 제어가 안내됐다.

모델을 호출하는 코드 외에 Agent의 실행 과정을 어떻게 구성할지 다루는 변화다. 적용할때는 사용중인 SDK와 언어의 제공 범위도 함께 확인해야겠다.

## 하네스는 모델 주변의 실행 규칙이다

Agent는 요청을 이해한 뒤 도구를 선택하고 결과를 읽고 다음 행동을 결정한다. 이 반복과 문맥 구성, 종료 조건과 오류 처리를 이어주는 실행 틀이 필요하다.

하네스를 수정할 수 있으면 프로젝트에 맞게 제어할 여지가 생긴다. 대신 기본 동작을 바꾼 뒤 어떤 조건에서 종료하고 실패를 보고하는지 확인해야한다.

예를 들어 도구 호출 횟수만 제한하면 긴 작업이 중간에 끝날 수 있다. 종료 상태를 완료와 한도 도달로 나눠서 반환해야 사용자가 결과를 오해하지 않는다.

테스트에서도 정상 답변뿐 아니라 도구 실패와 빈 결과, 반복되는 호출을 포함하면 좋겠다. 모델의 판단과 실행 규칙의 문제가 어느쪽인지 나눠서 볼 수 있다.

## 메모리는 저장할 내용과 유효 범위를 정하자

대화의 모든 문장을 장기 정보로 남기는것이 항상 좋은 방법은 아니다. 임시 요청과 검증되지 않은 가정, 현재 프로젝트의 결정은 수명이 다르다.

메모리를 생성할때는 무엇을 근거로 저장했는지와 어느 작업에서 사용할지 정하면 좋겠다. 잘못된 정보를 오래 유지하면 다음 작업에서도 같은 오류가 이어질 수 있기 때문이다.

저장 위치의 제어도 사용자와 프로젝트의 경계에 연결된다. 다른 작업의 기록을 섞지 않고 필요한 경우 수정과 삭제, 재평가할 수 있는 구조가 있어야한다.

개인적으로는 메모리가 많다는것보다 현재 요청에 유효한 정보를 정확히 꺼내는지가 중요해보인다. 장기 기억과 현재 실행 결과를 구분해야 Agent가 과거의 성공을 지금의 완료로 착각하지 않겠다.

# 7. 이번주에는 도입 상태와 실행 책임을 함께 적자

Spring 보안 패치는 실제 운영 버전과 영향 조건을 기준으로 계획한다. pg-delta는 Alpha에서 생성 SQL을 비교하고, Opus 4.7은 같은 개발 작업으로 평가할 수 있다.

Cloudflare와 OpenAI의 도구는 실행 환경과 세션, 관찰과 기억을 나눠서 살펴보면 좋겠다. 비슷한 기능 이름이 있어도 어떤 상태를 보관하고 어디까지 복구하는지는 다를 수 있다.

각 도구를 시험할때 입력과 실행 공간, 실제 변경과 검증 결과를 함께 남기고 싶다. 모델과 SDK, 인프라를 동시에 바꾸면 실패한 위치를 찾기 어려우니 독립적으로 비교할 수 있는 단위를 정하는것이다.

# 마무리

이번주는 Agent가 코드를 쓰는 능력에 더해 실행하고 관찰하고 이어가는 기반이 눈에 띄었다. 동시에 Spring의 웹 처리 보안 패치처럼 지금 운영하는 서비스에서 확인할 수정도 나왔다.

Alpha와 Preview, GA를 나눠서 보고 각 도구의 실제 제공 범위에 맞춰 시험하면 좋겠다. 실행이 시작됐는지보다 요청한 작업이 어떤 결과로 끝났는지를 확인해야겠다.

개인적으로는 이번주에 Agent의 정상 경로 외에 중단과 재시작을 한번 그려보고 싶다. 오래 실행할 수 있는 시스템은 오래 실패하지 않는것뿐 아니라 실패 뒤에 어디서 이어갈지 아는 구조인것같다..


[2026.04.17 주간 개발 트렌드] Spring 보안 패치와 Agent 실행 인프라

독자의 메모