[2026.06.12 주간 개발 트렌드] Spring Boot 4.1과 Spring AI 2.0, Agent 하네스

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

# 이번주는 언어와 프레임워크의 기본기가 넓어졌다

이번주에는 Angular 22와 Kotlin 2.4가 정식으로 나왔고 PostgreSQL 19는 첫 베타를 공개했다. AI 쪽에서는 생성 요청에 Moderation 결과를 함께 받는 방식과 Copilot의 경량 모델, Bedrock의 OpenAI 호환 인터페이스가 눈에 들어왔다.

한번에 보면 모두 개발 도구 업데이트지만 적용하는 순서는 조금 다르다. 정식 버전은 기존 코드의 호환성을 확인하며 도입할 수 있고, DB 베타는 별도 환경에서 실제 쿼리와 운영 도구를 시험하는 대상으로 봐야겠다.

6월 1일부터 5일까지의 내용을 주제별로 정리해보았다.

| 분야 | 이번주 소식 | 먼저 볼 부분 |
| --- | --- | --- |
| 프론트엔드 | Angular 22 | 폼·비동기 상태·접근성의 안정화 |
| 언어 | Kotlin 2.4 | 문법과 표준 API, 빌드 환경 |
| DB | PostgreSQL 19 Beta 1 | 새 쿼리 기능과 복제본 읽기 |
| AI API | Moderation 통합 | 점수를 받은 뒤의 처리 정책 |
| 개발 도구 | MAI-Code-1-Flash | 가벼운 코딩 작업과 제공 범위 |
| 클라우드 | Bedrock Responses 호환 | 모델·리전·기능의 실제 지원 |

개인적으로는 새 문법을 바로 많이 쓰는것보다 기존에 복잡했던 상태와 의존성을 얼마나 명확하게 표현할 수 있는지 보고싶다.

# 1. 프론트엔드 — Angular 22에서 상태와 접근성의 기반이 안정화됐다

6월 3일 [Angular 22](https://angular.dev/events/v22)가 정식 출시됐다. Signal Forms와 Asynchronous Signals, Angular Aria가 안정화됐고 템플릿과 API도 개선됐다.

폼과 서버 요청, 키보드 조작은 화면에서 따로 떨어진 문제가 아니다. 사용자가 입력하고 응답을 기다리며 다음 동작을 선택하는 하나의 흐름이다. 이번 업데이트도 이런 연결을 기준으로 살펴보면 좋겠다.

## 폼은 값보다 상태의 조합이 더 어렵다

회원가입 화면을 생각하면 입력값만 저장해서는 끝나지 않는다. 필수값 검증과 서버 중복 확인, 제출 중 상태와 서버 오류를 같이 다뤄야한다.

폼을 Signal 기반으로 표현할 수 있다는 점은 상태를 연결하는 방법의 선택지가 넓어졌다는 의미다. 기존 화면을 옮길때는 코드 줄 수보다 같은 상태를 여러곳에서 따로 관리하고 있지는 않은지 먼저 보고싶다.

```text
입력값 변경
  → 동기 검증
  → 필요한 비동기 확인
  → 제출 가능 여부
  → 제출 결과와 오류 표시
```

예를 들어 서버에서 이메일 중복 오류를 받은 뒤 사용자가 이메일을 수정했을때 그 오류를 언제 없앨지 정해야한다. 새 값에도 오래된 오류가 남거나 아직 확인하지 않은 값을 정상으로 표시하면 사용자가 헷갈릴 수 있다.

기존 Reactive Forms를 쓰는 큰 프로젝트라면 모든 화면을 한번에 바꾸기보다 독립적인 폼 하나에서 비교하면 좋겠다. 공통 입력 컴포넌트와 오류 메시지, 테스트 도구의 연결을 확인한 뒤 범위를 넓히는것이다.

## 비동기 상태에서는 늦게 도착한 응답을 보자

검색창에 빠르게 다른 값을 입력하면 먼저 보낸 요청이 나중에 도착할 수 있다. 비동기 API를 사용하는것과 화면이 현재 입력의 결과만 보여주는것은 따로 확인할 동작이다.

로딩과 성공, 오류를 표시할때 이전 결과를 유지할지도 결정해야한다. 이전 결과를 남겨두는 화면이라면 그것이 새 요청의 결과처럼 보이지 않도록 표현할 필요가 있다.

작은 테스트에서는 응답 순서를 의도적으로 뒤집어볼 수 있다. 첫 요청은 늦게, 두번째 요청은 빨리 끝나게 만들어 현재 화면에 어떤 결과가 남는지 보는것이다.

## 접근성은 컴포넌트가 제공한 동작과 화면의 연결을 함께 보자

Angular Aria의 안정화는 접근 가능한 상호작용을 구성하는 기반을 제공한다. 실제 제품에서는 레이블과 설명, 포커스 이동이 화면 문맥에 맞는지도 확인해야한다.

키보드로 메뉴를 열고 항목을 선택한 뒤 어디로 포커스가 돌아오는지 보면 마우스만 사용할때 놓친 문제를 찾을 수 있다. 오류를 보여준 뒤 그 오류를 사용자가 인지할 수 있는지도 중요하다.

화면의 색과 모양이 맞다는것과 보조 기술이 같은 상태를 읽는다는것은 다른 검증이다. 새 API를 도입할때 기존 동작의 접근성도 함께 비교해보면 좋겠다.

# 2. 언어 — Kotlin 2.4는 의존성과 데이터 표현을 더 명확하게 만든다

6월 3일 [Kotlin 2.4.0](https://kotlinlang.org/docs/releases.html)이 정식으로 나왔다. Context Parameters와 Explicit Backing Fields, UUID API 안정화, Kotlin/Wasm 증분 컴파일 등이 주요 내용이다. 세부 기능은 [2.4 변경 내용](https://kotlinlang.org/docs/whatsnew24.html)에서 확인할 수 있다.

새 언어 기능은 반복 코드를 줄이기도 하지만 읽는 사람이 의존성을 찾는 방식도 바꾼다. 짧아진 코드가 어떤 값을 필요로 하는지 여전히 이해하기 쉬운지 살펴보면 좋겠다.

## Context Parameters는 숨겨진 전역 상태와 구분해서 사용하자

여러 함수가 같은 서비스나 실행 문맥을 필요로 할때 매번 인자로 전달하는 코드는 반복될 수 있다. Context Parameters는 이런 의존성을 주변 문맥과 연결해 선언하는 방법이다.

다만 전달 문법을 줄였다고 의존성 자체가 사라진것은 아니다. 어떤 문맥이 함수의 동작에 영향을 주는지 선언과 호출 지점에서 이해할 수 있어야한다.

예를 들어 요청마다 다른 권한 정보나 테넌트 문맥을 사용한다면 잘못된 범위의 값이 연결되지 않도록 확인해야한다. 테스트에서도 필요한 문맥을 명시적으로 준비하면 함수의 전제 조건이 드러난다.

개인적으로는 반복되는 인자가 있다는 이유만으로 모두 옮기기보다 동일한 생명주기를 공유하는 의존성부터 비교하고 싶다. 데이터 자체를 입력하는 인자와 실행 환경을 제공하는 의존성은 읽는 방식이 다르기 때문이다.

## 저장하는 값과 외부에 공개하는 타입은 다를 수 있다

Explicit Backing Fields는 프로퍼티의 외부 표현과 내부 저장을 다룰때 눈여겨볼 부분이다. 내부에서 변경 가능한 데이터를 관리하더라도 외부에 같은 변경 권한을 노출할 필요는 없다.

여기서 읽기 전용 타입으로 보인다는것과 내부 객체가 절대로 변하지 않는다는것은 구분해야한다. 다른 참조가 같은 데이터를 변경할 수 있는지에 따라 사용자가 관찰하는 값도 달라질 수 있다.

UUID API 안정화 역시 단순한 타입 변경으로 끝내기 어렵다. 기존 라이브러리와 문자열 변환, DB 드라이버, 직렬화 경계가 같은 표현을 주고받는지 확인해야한다.

```text
UUID를 주고받는 경계
생성 → 도메인 값 → JSON·문자열 → DB 저장 → 다시 읽기
```

## 컴파일러와 플러그인의 조합도 같이 기록하자

멀티플랫폼 프로젝트에서는 공통 코드만 컴파일된다고 끝나지 않는다. JVM과 JS·Wasm 등 사용하는 대상별 빌드와 실행을 확인해야한다.

증분 컴파일의 효과를 볼때는 처음 전체 빌드와 작은 수정 후 빌드를 나눠 측정하면 좋겠다. 캐시가 비어있는 실행과 이미 준비된 실행을 섞으면 개선 원인을 설명하기 어렵다.

Kotlin 버전과 Gradle, 관련 플러그인과 직렬화 라이브러리의 조합도 남겨두자. 로컬 IDE의 성공과 CI의 성공이 다르면 JDK와 플러그인 해석부터 비교할 수 있다.

# 3. DB — PostgreSQL 19는 운영 전환보다 베타 검증을 시작할 시점이다

6월 4일 [PostgreSQL 19 Beta 1](https://www.postgresql.org/about/news/postgresql-19-beta-1-released-3313/)이 공개됐다. SQL/PGQ 그래프 쿼리와 `WAIT FOR LSN`, `GROUP BY ALL`, 파티션 분할·병합 등이 소개됐다.

이번주 기준 베타이며 운영 환경에 적용할 정식 버전은 아니다. 새 기능을 살펴보면서 우리 쿼리와 드라이버, 백업·복구 도구가 어떻게 동작하는지 별도 환경에서 시험하면 좋겠다.

## 그래프 쿼리의 추가와 데이터 모델의 선택은 별개다

관계형 데이터에서 연결 관계를 탐색하는 요구는 자주 생긴다. 조직의 소속이나 추천 관계, 여러 단계를 거치는 연결처럼 행 하나의 조건만으로 표현하기 어려운 작업이다.

SQL/PGQ 지원은 이런 관계를 SQL의 표준 문법으로 다루는 선택지를 제공한다. 하지만 새 문법이 있다고 모든 관계 데이터를 다른 모델로 다시 설계할 필요는 없다.

우리 쿼리가 실제로 탐색하는 깊이와 반환하는 결과, 데이터의 변경 빈도를 기준으로 기존 쿼리와 비교하면 좋겠다. 읽기 쉬운 표현과 실행 비용을 함께 보는것이다.

관계에 순환이 있거나 같은 대상에 여러 경로로 도달하는 경우도 시험해야한다. 결과의 중복과 경로의 의미를 먼저 정해야 예상한 답과 실제 결과를 비교할 수 있다.

## 복제본 읽기는 기다리는 기준이 중요하다

사용자가 저장한 직후 복제본에서 조회하면 아직 변경이 반영되지 않았을 수 있다. 읽기를 분산했다는 구성만으로 저장 직후의 일관성이 보장되지는 않는다.

`WAIT FOR LSN`은 특정 로그 위치까지 복제본에 반영되기를 기다리는 방식으로 이런 요구를 다룬다. 애플리케이션에서는 어떤 쓰기와 어떤 위치를 연결할지 알아야한다.

```text
쓰기 완료
  → 반영을 확인할 로그 위치
  → 읽을 복제본에서 대기
  → 필요한 변경 이후의 조회
```

기다릴 수 있는 시간도 제품의 요구사항이다. 복제 지연이 커졌을때 계속 대기할지, 오류를 반환할지, 다른 읽기 경로를 선택할지 정해야한다.

모든 조회에 같은 대기를 넣기보다 저장 직후 확인처럼 일관성이 필요한 요청을 구분하고 싶다. 오래된 값을 허용하는 목록과 방금 변경한 권한을 확인하는 요청은 요구가 다를 수 있다.

## 쿼리 편의 기능은 결과의 의미가 유지되는지 보자

`GROUP BY ALL`은 집계하지 않는 출력 컬럼을 그룹 기준에 포함하는 표현을 줄여준다. SELECT 목록이 바뀌면 집계의 단위도 달라질 수 있으므로 코드 리뷰에서 결과의 의미를 함께 봐야겠다.

파티션 분할과 병합도 명령의 실행 성공만 확인해서는 부족하다. 작업 중의 잠금과 동시 요청, 작업 후 데이터의 범위와 인덱스 상태를 대표 데이터로 시험하면 좋겠다.

# 4. AI API — 생성과 Moderation 결과를 한 응답에서 받을 수 있다

6월 4일 [OpenAI API](https://developers.openai.com/api/docs/changelog)에 Responses와 Chat Completions의 입력·출력 Moderation 점수를 함께 받는 기능이 추가됐다. 생성 요청에 `moderation` 객체를 지정하는 방식이다.

별도 분류 요청을 조합하던 호출 흐름을 줄일 수 있다. 다만 결과를 받는 기능과 그 결과로 무엇을 허용할지는 애플리케이션이 연결해야한다. [Moderation 문서](https://developers.openai.com/api/docs/guides/moderation#moderate-generated-content)도 점수를 정책의 신호로 다루도록 설명한다.

## 점수는 후속 동작을 결정하는 입력이다

모델이 텍스트를 생성한 뒤 분류 점수를 받았다고 이미 보여준 내용이 회수되는것은 아니다. 사용자가 보는 시점과 점수를 확인하는 시점을 먼저 설계해야한다.

특히 스트리밍 화면은 부분 출력이 먼저 전달될 수 있다. 전체 결과를 확인한 뒤 표시할지, 어떤 버퍼링과 제한을 둘지에 따라 사용자 경험과 처리 지연이 달라진다.

분류 결과가 누락되거나 오류가 발생한 경우도 정상 통과와 구분해야한다. 점수가 없다는것을 문제가 없다는 결과로 처리하지 않도록 응답의 상태를 먼저 확인하면 좋겠다.

운영 로그에는 요청 식별 정보와 적용한 정책 버전, 분류 결과와 실제 처리 결과를 연결할 수 있다. 사용자의 원문을 불필요하게 반복 저장하지 않고도 결정 과정을 추적하는 방법을 생각해야겠다.

## 콘텐츠 판단과 도구의 권한은 다른 계층이다

분류 점수가 낮은 요청이라도 사용자가 다른 사람의 데이터를 삭제할 권한을 얻는것은 아니다. 텍스트의 내용과 시스템의 접근 권한을 함께 판단할 필요가 있다.

Agent가 도구를 호출한다면 실행 전에 서버에서 대상과 권한, 허용된 동작을 다시 확인해야한다. 생성된 설명이 안전해 보이는지와 실제 실행의 영향은 별도로 검토할 부분이다.

# 5. 개발 도구 — 가벼운 코딩 작업을 위한 모델이 Copilot에 들어왔다

6월 2일 [MAI-Code-1-Flash](https://github.blog/changelog/2026-06-02-mai-code-1-flash-is-now-available-for-github-copilot/)의 Copilot 제공이 시작됐다. Microsoft가 경량 코딩 작업에 맞춘 모델이며 VS Code부터 일부 사용자에게 순차적으로 제공하는 방식이다.

모든 계정과 도구에서 바로 보이는것으로 이해하면 안되겠다. 이번주에는 사용하는 플랜과 모델 선택 화면의 실제 제공 상태부터 확인하면 좋겠다.

## 작은 작업에는 수정과 검토의 시간을 같이 보자

짧은 함수 수정과 반복 코드 정리, 테스트 초안처럼 범위가 분명한 작업은 응답 속도의 영향을 많이 받는다. 하지만 빠르게 나온 코드라도 다시 고치는 시간이 길면 전체 작업은 빨라지지 않는다.

기존에 정답과 요구가 분명한 작업 몇개를 준비해 같은 조건으로 비교할 수 있다. 첫 결과의 정확도와 변경 범위, 테스트 실행 여부, 사람이 수정한 내용을 함께 남기는것이다.

```text
작업에 든 시간
요청 준비 + 응답 대기 + 코드 검토 + 수정 + 검증
```

모델마다 모든 업무를 맡겨보기보다 실패를 알아보기 쉬운 작업부터 시작하고 싶다. 저장소 전체의 설계 변경과 작은 타입 오류 수정은 필요한 정보와 완료 판단이 다르다.

# 6. 클라우드 — Bedrock에서 Responses 호환 호출을 검토할 수 있다

6월 1일 [OpenAI의 변경 내역](https://developers.openai.com/api/docs/changelog)에 Amazon Bedrock의 OpenAI 호환 Responses API 지원이 추가됐다. 실제 지원 모델과 기능은 AWS 리전에 따라 다르다.

같은 호출 형식을 활용할 수 있다는 점은 통합 비용을 줄일 수 있다. 다만 인터페이스가 호환된다는것과 모든 모델·도구·운영 조건이 같다는것은 구분해야한다.

## 모델 이름보다 필요한 기능부터 표로 만들자

애플리케이션이 사용하는 기능을 먼저 적으면 비교가 쉬워진다. 일반 텍스트 생성과 스트리밍, 도구 호출, 구조화 출력 등 실제로 의존하는 항목별로 확인하는것이다.

현재 사용하는 요청이 다른 엔드포인트에서도 같은 의미로 처리되는지 대표 사례를 보내볼 수 있다. 성공 응답만 보는 대신 오류 형식과 재시도, 타임아웃도 함께 비교해야한다.

운영 설정에서는 인증과 접근 정책, 리전과 로깅, 비용의 집계 위치를 다시 확인하면 좋겠다. 호출 코드를 재사용할 수 있어도 배포 환경의 권한과 관측 경로는 달라질 수 있다.

개인적으로는 공급자를 추상화할때 모든 차이를 숨기기보다 공통 기능과 개별 설정을 분리하고 싶다. 지원하지 않는 기능을 조용히 생략하면 같은 요청이 서로 다른 일을 할 수 있기 때문이다.

# 7. 이번주에는 새 기능의 상태와 검증 범위를 나눠보자

이번주는 정식 버전과 베타, 단계적 제공과 호환 API가 함께 나왔다. 출시라는 단어 하나로 묶으면 실제로 사용 가능한 범위와 우리가 시험해야할 부분을 놓치기 쉽다.

| 작업 | 작은 검증의 시작 |
| --- | --- |
| Angular 업데이트 | 폼 제출·요청 순서·키보드 흐름 비교 |
| Kotlin 업데이트 | 대상별 빌드와 직렬화 경계 확인 |
| PostgreSQL 베타 | 별도 환경의 대표 쿼리·복제 지연 시험 |
| Moderation 통합 | 결과 오류·표시 시점·후속 실행 정책 |
| 경량 코딩 모델 | 수정과 검토를 포함한 완료 시간 |
| Bedrock 호출 | 리전·모델·사용 기능의 지원 대조 |

# 마무리

이번주는 Angular와 Kotlin의 기반 기능이 안정화되고 PostgreSQL 차기 버전을 시험할 기회가 열렸다. AI API와 개발 도구도 생성 자체에서 정책 확인과 실제 실행 환경의 연결로 범위를 넓히고 있다.

프론트엔드는 상태 전이를, 언어 업데이트는 의존성과 경계를, DB는 쿼리 결과와 운영 동작을 기준으로 보면 좋겠다. AI 기능도 모델의 설명보다 우리 애플리케이션이 실제로 받은 결과와 처리한 동작을 확인해야겠다.

개인적으로는 이번주에 가장 복잡했던 폼과 자주 쓰는 DB 조회부터 작은 기준 사례로 남겨보려고 한다. 새 도구의 장점을 비교하려면 먼저 현재 동작을 정확히 알아야할것같다..


[2026.06.05 주간 개발 트렌드] Angular 22와 Kotlin 2.4, PostgreSQL 19 Beta

독자의 메모