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

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

# 이번주는 보안 점검과 DB 운영의 자동화가 눈에 들어왔다

이번주에는 Anthropic의 Project Glasswing과 Supabase의 DB 운영·개발 연동 소식이 나왔다. AI가 소프트웨어의 취약점을 찾는 작업과 데이터베이스의 운영·스키마 변경을 자동화하는 이야기가 함께 이어졌다.

자동화가 가능한 범위는 넓어지고 있지만 결과를 받아들이는 기준까지 자동으로 정해지는것은 아니다. 취약점 후보가 실제 문제인지, Operator가 변경한 DB가 정상인지, 배포된 마이그레이션이 애플리케이션과 맞는지는 각각 확인해야한다.

4월 6일부터 10일까지의 내용을 세가지로 나눠보았다.

| 분야 | 이번주 소식 | 구분해서 볼 부분 |
| --- | --- | --- |
| AI·보안 | Project Glasswing | 제한 접근 연구와 실제 수정 검증 |
| DB·Kubernetes | Multigres Operator 공개 소식 | DB 프로세스 관리와 데이터의 수명 |
| DB·CI/CD | Supabase GitHub 연동 확대 | 스키마 변경의 검토와 적용 순서 |

개인적으로는 이번주 소식을 보면서 작업을 실행하는 자동화보다 결과를 검증하고 이어가는 과정이 더 중요해진다는 생각이 들었다.

# 1. AI·보안 — Glasswing은 제한된 기관이 참여하는 보안 협력이다

4월 7일 Anthropic이 [Project Glasswing](https://www.anthropic.com/glasswing)을 발표했다. AWS와 Apple, Google과 Microsoft 등 주요 소프트웨어·인프라 기업이 참여해 AI를 방어적 보안 작업에 활용하는 협력이다.

Claude Mythos Preview라는 연구 모델을 참여 기관 등에 제한적으로 제공한다. 이번주에 일반 사용자가 선택해 쓰는 새 범용 모델이 정식 출시됐다는 의미는 아니다.

## 코드를 이해하는 능력이 보안 분석으로 이어진다

취약점을 찾는 작업에서는 함수 하나의 내용보다 입력이 어디서 오고 어떤 검사와 변환을 거쳐 사용되는지가 중요하다. 여러 파일과 계층에 흩어진 조건을 연결해야하는 경우가 많다.

예를 들어 사용자가 보낸 값이 처음에는 검증되지만 뒤의 변환 과정에서 의미가 바뀔 수 있다. 반대로 위험해보이는 코드도 앞단의 조건 때문에 실제로는 해당 입력이 도달하지 못할 수 있다.

AI가 저장소를 탐색하고 관련 경로를 연결하는 능력은 이런 분석에 도움을 줄 수 있다. 하지만 의심스러운 코드의 발견과 재현 가능한 취약점의 확인은 다른 단계다.

```text
보안 분석의 흐름
의심 지점 → 입력과 실행 경로 → 재현 → 영향 판단 → 수정 → 재검증
```

결과에는 문제가 있는 위치뿐 아니라 발생 조건이 필요하다. 어떤 권한과 설정, 입력에서 실제로 영향을 받는지 알아야 우선순위를 정할 수 있기 때문이다.

이 점은 일반 코드 리뷰에서도 비슷하다. 지적의 개수가 많다는 사실보다 실제로 발생하는 문제를 정확히 찾는것이 중요하다.

## 모델이 제안한 수정도 같은 기준으로 보자

AI가 취약점 후보와 수정안을 함께 제시하면 검토를 시작하기 쉬워질 수 있다. 그렇다고 수정 코드가 문제를 해결하면서 정상 사용도 유지하는지까지 확인한것은 아니다.

예를 들어 입력을 모두 거절하게 만들면 문제의 재현은 막을 수 있다. 하지만 원래 제공하던 기능도 사용할 수 없게 된다면 적절한 수정으로 보기 어렵다.

문제를 재현하는 입력과 정상적인 입력을 함께 준비하면 좋겠다. 오류가 사라지는지와 기존 계약이 유지되는지를 같은 변경에서 확인하는것이다.

수정된 코드가 새로운 우회 경로나 과도한 비용을 만들지 않는지도 살펴봐야한다. 한 경로의 검사를 추가하는 작업이 다른 계층의 규칙과 충돌할 수 있기 때문이다.

보안 수정의 완료 조건에는 테스트와 영향 범위, 적용 대상이 포함되면 좋겠다. 코드가 병합된것과 실제 사용중인 버전에 수정이 반영된것도 서로 다른 상태다.

## 일반 개발팀은 현재의 대응 절차부터 정리할 수 있다

제한 접근 모델을 당장 사용할 수 있는지와 별개로, 발견된 문제를 어떻게 다룰지는 지금도 정리할 수 있다. 확인할 코드와 실행 버전, 담당자와 수정 경로가 있어야한다.

의심되는 결과를 전달할때는 재현 환경과 조건을 남겨두면 좋겠다. 설명만 길고 필요한 버전과 설정이 없으면 검토자가 같은 문제를 확인하기 어렵다.

이미 알려진 취약점의 패치를 적용하는 흐름도 중요하다. 새로운 문제를 잘 찾는 도구가 있어도 오래된 의존성을 실제 배포에서 계속 사용한다면 다른 과제가 남아있는것이다.

개인적으로는 AI 보안 분석을 기존 절차에 붙일때 탐지와 검증, 수정과 배포를 각각 구분하고 싶다. 모델의 분석 결과를 어느 단계의 근거로 사용할지 명확해지기 때문이다.

# 2. DB·Kubernetes — Multigres Operator가 운영의 반복 작업을 다룬다

4월 9일 [Supabase 개발자 업데이트](https://supabase.com/changelog/44713-developer-update-april-2026)에서 Multigres Kubernetes Operator의 오픈소스 공개 소식을 소개했다. Pod 직접 관리와 롤링 업그레이드, pgBackRest 기반 PITR 백업과 OpenTelemetry 추적 등이 안내됐다.

이 공지는 지난 한달의 변화를 모은 개발자 업데이트다. 모든 구현이 4월 9일 하루에 처음 만들어졌다는 의미로 읽기보다 이번주 소개된 운영 도구의 범위를 살펴보면 되겠다.

## Operator는 원하는 상태와 현재 상태를 맞추는 역할이다

Kubernetes에서 선언한 상태와 실제 상태가 다르면 이를 맞추는 제어 흐름이 필요하다. DB Operator는 그 과정에 데이터베이스를 운영하는 절차를 담는다.

예를 들어 인스턴스를 교체하거나 버전을 바꾸는 작업은 단순히 프로세스를 새로 시작하는것보다 조건이 많다. 연결과 복제, 데이터의 위치와 준비 상태를 함께 고려해야한다.

```text
DB 운영에서 볼 상태
원하는 구성 ↔ 실제 인스턴스 ↔ 복제·데이터 ↔ 서비스 연결
```

Pod가 Running이라는 상태는 컨테이너의 상태를 보여준다. DB가 필요한 데이터를 갖고 정상적인 읽기·쓰기를 제공한다는것까지 같은 의미로 보장하는것은 아니다.

Operator가 어떤 조건에서 준비됐다고 판단하는지와 애플리케이션이 어느 주소로 연결하는지를 확인해야겠다. 제어 계층과 실제 사용 경로가 연결되는 지점이다.

## 롤링 업그레이드는 전체 서비스에서 확인하자

중단을 줄이는 업그레이드 기능은 반가운 부분이다. 다만 도구의 지원을 우리 서비스에서 어떤 오류도 발생하지 않는다는 보장으로 확대하면 안되겠다.

연결이 바뀌거나 인스턴스가 교체되는 동안 애플리케이션이 요청을 어떻게 처리하는지 확인해야한다. 진행중인 트랜잭션과 커넥션 풀, 재시도 조건도 영향을 줄 수 있다.

테스트에는 업그레이드 중의 대표 읽기·쓰기 요청을 포함할 수 있다. 정상 종료 뒤의 상태만 보는것보다 전환 구간에 어떤 일이 있었는지 알기 쉽다.

재시도 가능한 읽기와 중복 실행을 주의해야하는 쓰기를 나눠보자. 연결이 잠깐 실패했다고 같은 변경을 무조건 다시 수행하면 애플리케이션의 결과가 달라질 수 있다.

업그레이드가 끝난 뒤에도 실제 버전과 복제 지연, 오류율을 확인해야겠다. 제어 작업의 완료와 서비스의 정상 상태를 함께 봐야하기 때문이다.

## 백업의 존재와 복구 가능성은 다르다

PITR은 필요한 시점으로 복구하는 운영 선택지다. 하지만 백업 작업이 성공했다는 메시지와 목표 시점으로 실제 복구할 수 있다는 사실은 따로 확인해야한다.

데이터와 로그가 보관되는 위치, 보존 범위와 복구 절차를 알아야한다. 복구할 환경을 준비하는 시간과 실제 데이터를 되살리는 시간도 운영 목표에 들어간다.

```text
복구 확인의 흐름
백업 확인 → 격리된 환경 준비 → 복구 → 데이터 검증 → 앱 연결 확인
```

서비스에서 중요한 테이블과 관계, 최근 변경이 의도한 시점에 맞는지 확인해보면 좋겠다. DB가 실행됐다는 사실만으로 복구한 데이터의 의미가 맞는지 알 수는 없다.

복구 연습에서 얻은 시간과 필요한 수동 작업을 기록하면 이후 장애 대응의 기준이 된다. 자동화 기능의 목록보다 실제로 복구한 근거가 더 유용할 수 있다.

## 추적은 제어 작업과 사용자 요청을 나눠보자

Operator가 수행하는 작업과 사용자의 DB 쿼리는 관찰할 질문이 다르다. 왜 Pod를 교체했는지와 왜 검색 요청이 느린지는 서로 다른 원인을 가질 수 있다.

제어 작업의 시작과 종료, 실패와 재시도 기록을 볼 수 있으면 상태 변화의 이유를 찾기 쉽다. 여기에 같은 시점의 애플리케이션 오류와 복제 상태를 연결해볼 수 있다.

운영에서 자주 묻는 질문을 기준으로 관측 항목을 정하면 좋겠다. 로그가 많아도 어느 작업이 현재 인스턴스를 바꿨는지 찾을 수 없다면 중요한 연결이 빠진것이다.

# 3. DB·CI/CD — Supabase GitHub 연동이 전체 요금제로 넓어졌다

같은 4월 9일 업데이트에서는 GitHub 연동의 전체 요금제 제공도 안내했다. 무료 요금제에서도 저장소를 연결해 메인 브랜치의 마이그레이션을 CI/CD로 배포할 수 있다.

DB 변경을 코드와 함께 검토하는 진입 장벽이 낮아진것이다. 다만 저장소와 연결했다고 모든 스키마 변경이 안전한 배포로 바뀌는것은 아니다.

## 마이그레이션 파일은 변경의 순서를 표현한다

목표 스키마가 같아도 기존 데이터에서 거기까지 가는 방법은 다를 수 있다. 빈 DB에서 테이블을 만드는 일과 많은 데이터가 있는 테이블의 제약을 바꾸는 일은 조건이 다르다.

마이그레이션을 리뷰할때는 SQL의 최종 모양과 함께 적용 중의 동작을 봐야한다. 어느 쿼리가 잠금을 기다리는지, 시간이 얼마나 걸릴지, 애플리케이션의 이전 버전과 함께 동작하는지가 중요하다.

```text
스키마 변경의 검토
현재 데이터 → 적용 과정 → 새 스키마 → 이전·새 앱과의 호환성
```

예를 들어 새 필수 컬럼을 추가하는 작업을 생각해보자. 기존 행의 값을 채우는 작업과 새 애플리케이션이 값을 쓰는 시점, 제약을 강화하는 시점을 나눠야할 수 있다.

한 파일에 모두 넣으면 짧아보여도 실제 서비스의 배포 순서를 표현하지 못할 수 있다. 검토자는 결과뿐 아니라 전환 중의 상태를 이해할 수 있어야한다.

## 확장한 뒤 전환하고 마지막에 정리하자

기존 컬럼을 새 컬럼으로 옮기는 경우에는 먼저 두 형식을 함께 사용할 수 있는 상태를 만들 수 있다. 이후 데이터를 옮기고 읽는 경로를 전환한 뒤 더이상 필요없는 구성을 정리하는식이다.

```text
전환을 나누는 예시
새 구조 추가 → 데이터 채우기 → 앱 전환 → 사용 확인 → 이전 구조 정리
```

이 방식도 모든 변경의 만능 해법은 아니다. 두 값을 동시에 유지할때 어느쪽이 기준인지와 중간 실패를 어떻게 처리할지 정해야한다.

데이터를 채우는 작업이 길다면 작은 단위로 진행하고 완료 범위를 확인할 수 있게 만들면 좋겠다. 중단 후 다시 시작했을때 같은 행을 잘못 처리하지 않는지도 검토 대상이다.

구조를 제거하는 작업은 실제로 더이상 읽거나 쓰지 않는지 확인한 뒤 수행해야한다. 코드 검색 외에도 배치와 운영 스크립트, 별도 소비자가 있는지 살펴볼 필요가 있다.

## 컬럼 이름 변경도 앱 배포와 함께 생각하자

예를 들어 `display_name`을 `nickname`으로 바꾼다고 생각해보자. 이름만 바꾸는 SQL은 짧지만 이전 앱은 여전히 `display_name`을 조회할 수 있다.

앱과 DB가 정확히 같은 순간에 바뀐다고 가정하기 어렵다면 중간 상태를 설계해야한다. 새 구조를 추가하고 데이터를 옮기는 동안 어느 필드에 쓰고 어느 필드에서 읽을지 정하는것이다.

이때 두 필드가 서로 다른 값을 가질 수 있는 조건도 확인해야한다. 전환 중의 쓰기를 놓치면 과거 데이터를 한 번 복사한 결과만으로는 최신 상태를 보장하기 어렵다.

정리가 끝난 뒤 이전 필드를 제거할 수 있는지는 실제 소비 경로를 기준으로 판단하면 좋겠다. SQL 한줄의 변경도 서비스 전체에서는 여러 단계의 작업일 수 있다.

## 빈 DB와 기존 데이터가 있는 DB를 나눠서 시험하자

새 개발 환경에서 마이그레이션 전체가 실행되는지는 중요한 확인이다. 하지만 운영과 비슷한 상태에서 이번 변경만 적용되는지도 별도로 봐야한다.

기존 데이터에는 빈 값과 오래된 형식, 예상보다 긴 문자열과 중복이 있을 수 있다. 새 제약과 변환이 이런 입력을 어떻게 처리하는지 알아야한다.

| 시험 환경 | 확인할 질문 |
| --- | --- |
| 빈 DB | 처음부터 같은 스키마를 만들 수 있는가? |
| 기존 스키마와 데이터 | 이번 변경이 실제 자료에 적용되는가? |
| 이전 앱 버전 | 배포 전환 중에도 동작하는가? |
| 새 앱 버전 | 새 구조와 제약을 정확히 사용하는가? |
| 중단된 작업 | 완료 범위를 알고 다시 진행할 수 있는가? |

운영 데이터를 그대로 복사해야한다는 뜻은 아니다. 중요한 분포와 경계 조건을 재현할 수 있는 테스트 자료를 준비하면 된다.

마이그레이션의 실행 기록과 실제 스키마가 맞는지도 확인해야겠다. 저장소 밖에서 직접 바꾼 설정이 있다면 이력이 설명하는 상태와 DB의 현재 상태가 달라질 수 있다.

# 4. DB 변경에서는 되돌림의 의미도 구체적이어야한다

애플리케이션 코드는 이전 빌드를 다시 배포하는 방식으로 되돌릴 수 있는 경우가 있다. 하지만 이미 바꾼 데이터와 제거한 컬럼은 같은 방식으로 복원되지 않을 수 있다.

따라서 마이그레이션의 대응 계획은 “문제가 생기면 롤백” 한줄보다 구체적이면 좋겠다. 이전 앱이 새 스키마와 함께 동작하는지, 데이터 복구가 필요한지, 수정 마이그레이션으로 진행할지 나눠보는것이다.

## 자동 실행할 단계와 검토할 단계를 정하자

테스트와 정적 점검을 자동으로 실행할 수 있어도 모든 변경의 운영 영향까지 같은 기준으로 판단하기는 어렵다. 테이블의 크기와 사용 빈도, 잠금과 배포 순서를 알아야하기 때문이다.

작은 추가 변경과 큰 데이터 변환을 구분하면 검토 시간을 알맞게 쓸 수 있다. 자동화의 목적은 모든 SQL을 똑같이 처리하는것보다 반복 가능한 확인을 놓치지 않는것에 가깝다.

CI 결과에는 어떤 DB 상태에서 검증했는지 남겨두면 좋겠다. 빈 테스트 DB만 통과한 결과인지, 기존 데이터의 경계 조건까지 확인했는지 알아야 해석할 수 있다.

실제 배포 후에는 마이그레이션 완료와 사용자 기능의 정상 여부를 함께 보자. 로그인과 검색, 쓰기와 배치처럼 영향을 받는 경로가 기대한 결과를 내는지가 마지막 확인이다.

## 실행 주체가 달라져도 책임은 연결되어야한다

GitHub에서 변경을 검토하고 플랫폼이 DB에 적용하더라도 누가 결과를 확인할지 정해두면 좋겠다. 자동 실행이 성공한 상태와 팀이 변경을 받아들인 상태는 다를 수 있다.

실패 알림과 실행 로그를 볼 위치도 명확해야한다. 문제가 발생했는데 저장소와 플랫폼 중 어디서 확인할지 모르면 대응이 늦어질 수 있다.

개인적으로는 코드 변경과 DB 변경의 기록을 같은 요구사항으로 연결하고 싶다. 어떤 기능을 위해 어떤 스키마를 바꿨는지 알아야 이후 정리와 복구에서도 판단하기 쉽기 때문이다.

# 5. 이번주 세 소식에서 공통으로 남길것

Glasswing의 보안 분석과 DB Operator, 마이그레이션 CI/CD는 모두 작업을 더 빠르고 반복 가능하게 수행하는 방향이다. 그 결과를 받아들이는 근거는 각 영역에서 따로 필요하다.

| 자동화 대상 | 결과를 받아들일 근거 |
| --- | --- |
| 취약점 탐지 | 재현 조건과 영향, 수정 후 정상 동작 |
| DB 인스턴스 관리 | 데이터와 복제, 실제 연결과 요청 결과 |
| 백업 | 목표 상태로 복구한 기록 |
| 마이그레이션 | 적용 과정과 기존·새 앱의 호환성 |

이 기준을 먼저 정해두면 도구의 결과를 과대평가하지 않고 활용하기 쉽다. 자동화가 수행한 단계를 정확히 알고 다음 검토를 이어갈 수 있기 때문이다.

새로운 기능을 전부 적용하기보다 현재 반복해서 어려움을 겪는 작업 하나부터 골라보고 싶다. 취약점 검증의 재현 환경인지, DB 복구 연습인지, 스키마 배포의 순서인지에 따라 필요한 도구가 달라질 수 있다.

# 마무리

이번주는 AI 보안 연구와 DB 운영 자동화가 함께 눈에 띄었다. Glasswing은 제한된 참여 기관의 방어적 연구로, 일반 모델 출시와 구분해서 봐야겠다.

Multigres Operator는 반복되는 운영 절차를 살펴볼 선택지이고, Supabase GitHub 연동은 스키마 변경을 코드 검토와 연결하기 쉬워지는 변화다. 각각의 실행 결과를 서비스의 실제 상태까지 이어서 확인하면 좋겠다.

개인적으로는 자동으로 처리할 수 있는 작업이 늘어날수록 완료의 의미를 구체적으로 적는 습관이 필요하다고 느낀다. 이번주에는 실행 성공 다음에 무엇을 확인해야하는지부터 정리해봐야겠다..


[2026.04.10 주간 개발 트렌드] AI 보안 연구와 PostgreSQL 운영 자동화

독자의 메모