[2026.06.19 주간 개발 트렌드] Spring AI 실행 루프와 Actions 실행·이미지 정책

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

# 이번주는 Spring의 정식 버전과 Agent의 실행 구조를 같이 보자

이번주에는 Spring Boot 4.1과 Spring AI 2.0이 정식으로 나왔다. Java 백엔드에서 gRPC와 관측 가능성, AI 도구 호출을 연결할 기반이 함께 정리된 주다.

AI 쪽에서는 Claude Fable 5와 Mythos 5 발표가 있었지만 같은 주에 접근 중단 공지도 나왔다. OpenAI 웹 검색에는 이미지 결과가 추가됐고 Vercel은 코딩 Agent의 하네스를 공통 인터페이스로 다루는 기능을 실험적으로 공개했다.

6월 8일부터 12일까지의 내용을 정리해보았다. 출시 소식과 실제 사용 가능한 상태를 함께 보는게 특히 중요한 주인것같다.

| 분야 | 소식 | 확인할 부분 |
| --- | --- | --- |
| 백엔드 | Spring Boot 4.1 GA | gRPC·SSRF 완화·관측·로그 |
| 백엔드·AI | Spring AI 2.0 GA | 도구 실행 루프와 MCP 통합 |
| AI 모델 | Fable 5·Mythos 5 | 발표 내용과 접근 중단 공지 |
| AI 검색 | 웹 검색의 이미지 결과 | 출처와 실제 이미지의 연결 |
| 개발 프레임워크 | HarnessAgent 실험적 공개 | 하네스·세션·권한의 차이 |

개인적으로는 새로운 모델 하나보다 실행 과정이 어디에서 관리되고 어디까지 확인할 수 있는지가 더 궁금하다. 서비스에 넣으려면 결과뿐 아니라 중간에 어떤 일이 있었는지도 알아야하기 때문이다.

# 1. 백엔드 — Spring Boot 4.1이 정식으로 나왔다

6월 10일 [Spring Boot 4.1.0](https://spring.io/blog/2026/06/10/spring-boot-4/)이 출시됐다. Spring gRPC 지원과 HTTP 클라이언트의 `InetAddressFilter` 기반 SSRF 완화, OpenTelemetry 관련 개선, Log4j 파일 로테이션 등이 포함됐다.

마일스톤에서 살펴봤던 기능을 이제 정식 버전의 업그레이드 대상으로 검토할 수 있다. 다만 버전 번호만 바꾸기보다 현재 프로젝트의 의존성과 설정을 같이 확인하면 좋겠다.

## gRPC는 통신 문법보다 계약의 관리가 중요하다

gRPC를 사용하면 서비스 사이의 요청과 응답을 명시적인 계약으로 정의할 수 있다. 여기서 서버가 실행되는것과 기존 호출자가 계속 정상적으로 동작하는것은 다른 확인이다.

새 필드를 추가하고 오래된 클라이언트가 요청하는 경우, 클라이언트를 먼저 배포하고 서버가 아직 이전 버전인 경우를 나눠 시험할 수 있다. 여러 서비스가 동시에 교체된다고 가정하면 실제 순차 배포에서 문제가 생길 수 있다.

```text
서비스 계약의 검증
스키마 변경 → 생성 코드 → 서버·클라이언트 조합 → 배포 순서
```

실패 상태도 계약의 일부다. 요청 시간 초과와 취소, 서버의 처리 오류를 호출자가 어떻게 구분하는지 확인해야한다. 재시도 가능한 오류라고 하더라도 같은 쓰기 작업을 여러번 실행해도 되는지는 별도 문제다.

개인적으로는 작은 내부 API 하나에서 기존 HTTP 호출과 비교해보고 싶다. 응답 속도뿐 아니라 디버깅과 배포, 오류 분석에 필요한 작업까지 함께 보는것이다.

## SSRF 완화는 실제 접속 대상에 대한 방어다

사용자가 준 URL이나 외부 데이터의 주소를 서버가 대신 요청하는 기능은 내부 자원에 접근하는 통로가 될 수 있다. 링크 미리보기와 문서 수집, Agent의 웹 요청에서도 생길 수 있는 문제다.

`InetAddressFilter` 같은 주소 필터를 검토할때는 우리 애플리케이션이 어느 HTTP 클라이언트를 쓰는지부터 확인하면 좋겠다. 일부 요청만 필터를 통과하고 다른 라이브러리의 요청은 별도 경로를 사용할 수도 있기 때문이다.

허용한 호스트 이름과 실제 연결하는 주소의 관계, 리디렉션을 따라가는 동작도 테스트할 부분이다. 문자열에 특정 단어가 없는지만 보는 방식으로 실제 접속 범위를 판단하기 어렵다.

설정 하나로 전체 네트워크 정책이 완성됐다고 생각하기보다 요청 경로와 외부 통신 정책을 함께 확인해야겠다. 정상적으로 허용할 목적지도 막히지 않는지 비교해야 실제로 적용할 수 있다.

## 로그와 Trace는 같은 요청을 연결할 수 있어야한다

OpenTelemetry 관련 개선은 요청과 외부 호출을 추적하는 흐름에서 살펴볼 수 있다. 특히 비동기 처리가 있는 서비스는 다른 스레드로 넘어간 뒤에도 같은 작업을 찾을 수 있는지 보고싶다.

로그가 많아지는것보다 필요한 구간이 연결되는지가 중요하다. 요청 식별 정보와 실패한 외부 호출, 실제 처리 시간을 한 흐름으로 찾을 수 있어야한다.

파일 로테이션은 로그가 쌓이는 환경에서 운영 조건과 연결된다. 파일을 언제 나누고 얼마나 남길지, 수집기가 회전한 파일을 어떻게 읽는지 같이 확인하면 좋겠다.

# 2. 백엔드·AI — Spring AI 2.0은 도구 호출을 확장할 기반을 정리했다

6월 12일 [Spring AI 2.0.0](https://spring.io/blog/2026/06/12/spring-ai-2-0-0-GA-available-now/)이 정식 출시됐다. Spring Boot 4와 Spring Framework 7을 기반으로 도구 호출 구조와 MCP 통합이 개선됐다.

도구 실행 루프를 `ChatClient`의 Advisor 체인에서 다룰 수 있게 된 점이 눈에 들어온다. 모델에 한번 질문하는 코드와 여러 도구를 실행하며 작업을 이어가는 구조를 구분해서 이해하면 좋겠다.

## Agent의 결과는 여러번의 호출로 만들어진다

일반적인 도구 호출은 모델이 도구를 선택하고 애플리케이션이 실행한 뒤 결과를 다시 전달하는 흐름이다. 최종 응답이 나오기 전까지 이 과정이 여러번 반복될 수 있다.

```text
사용자 요청
  → 모델의 도구 선택
  → 서버의 검증과 도구 실행
  → 실행 결과 전달
  → 추가 실행 또는 최종 응답
```

실행 과정이 조합 가능한 구조에 놓이면 반복마다 필요한 기록과 정책을 연결하기 쉬워진다. 어떤 도구를 호출했고 얼마나 기다렸으며 어떤 결과가 다음 판단에 사용됐는지 살펴볼 수 있다.

다만 확장할 수 있는 지점이 생겼다는것과 적절한 운영 정책이 자동으로 만들어졌다는것은 다르다. 반복 횟수와 실행 시간, 비용과 오류 처리 기준은 서비스에 맞게 정해야한다.

예를 들어 검색 도구가 계속 같은 오류를 반환할때 무한히 다시 부르지 않도록 종료 조건을 둘 수 있다. 모델이 다른 표현으로 같은 요청을 반복하는 경우도 관찰할 필요가 있다.

## 도구의 인자와 권한은 서버에서 확인하자

도구가 노출됐다는 이유만으로 모든 사용자가 그 기능을 실행할 수 있는것은 아니다. 사용자와 테넌트, 실제 대상 자원에 대한 권한을 도구 실행 지점에서 검사해야한다.

형식에 맞는 JSON도 업무적으로 잘못된 요청일 수 있다. 날짜 범위가 너무 넓거나 허용되지 않은 대상에 접근하는 경우처럼 스키마 바깥의 조건이 있기 때문이다.

조회 도구와 상태를 바꾸는 도구도 구분하고 싶다. 같은 실패라도 조회는 다시 시도할 수 있지만 주문 생성이나 외부 발송은 이미 반영됐는지 먼저 확인해야할 수 있다.

실행 결과가 모델에게 전달되기 전에 민감한 정보를 줄이는 방법도 생각해보자. 도구가 DB에서 가져온 모든 컬럼을 그대로 반환할 필요는 없다.

## MCP 통합에서는 프로토콜과 접근 정책을 함께 보자

Spring AI 2.0은 MCP Java SDK 2.0과 관련 통합을 포함한다. Spring 서비스를 도구와 리소스로 연결하는 개발 방식도 함께 정리됐다.

도구의 설명이 좋아지면 모델이 어떤 기능을 선택할지 판단하는데 도움이 된다. 하지만 설명문이 인증과 권한 검사를 대신하지는 않는다. 서버가 실제로 허용할 작업을 결정해야한다.

원격 연결에서는 연결 수명과 인증, 오류가 난 세션의 처리도 확인할 수 있다. 개발 PC에서 정상 호출한것과 여러 사용자의 요청이 동시에 들어오는 서버의 동작은 조건이 다르다.

기존 1.x 프로젝트를 옮긴다면 모델 호출 코드만 보지 말고 옵션과 설정 키, 도구 실행과 메모리 연결을 함께 비교하고 싶다. 컴파일 성공 이후에도 대화 중간의 상태가 같은 의미로 유지되는지 확인해야겠다.

# 3. AI 모델 — Fable 5와 Mythos 5는 발표와 이용 상태를 나눠봐야한다

6월 9일 Anthropic이 [Claude Fable 5와 Mythos 5](https://www.anthropic.com/news/claude-fable-5-mythos-5)를 발표했다. Fable 5는 범용 사용을 위한 모델로, Mythos 5는 보안 연구 중심의 제한 접근 모델로 소개됐다.

다만 6월 12일 [접근 중단 공지](https://www.anthropic.com/news/fable-mythos-access)가 나왔다. 이번주 글에서는 발표 시점의 제공 계획을 그대로 현재 이용 가능 상태로 적으면 안되겠다. 실제 서비스 연결은 최신 상태를 확인해야한다.

## 모델의 성능과 서비스의 이용 가능성은 서로 다른 조건이다

좋은 성능을 보이는 모델이라도 호출할 수 없다면 현재 업무의 실행 경로로 사용할 수 없다. 평가와 실제 서비스 배포를 나눠야하는 이유다.

새 모델을 시험할때는 모델 ID와 응답 결과뿐 아니라 시험한 날짜와 계정의 접근 상태도 남기면 좋겠다. 같은 코드가 나중에 실패했을때 기능 오류와 이용 상태의 변화를 구분하는데 도움이 된다.

제한 접근 모델을 일반 개발자가 바로 선택할 수 있는 모델처럼 설명하지 않는것도 중요하다. 발표에 등장하는 성능과 실제 제공 대상은 같은 정보가 아니다.

개인적으로는 이런 소식을 볼때 벤치마크보다 현재 사용 조건을 먼저 확인하고 싶다. 긴 작업에 넣으려면 실행 중 사용할 수 없는 상황도 처리해야하기 때문이다.

## 대체 모델은 이름만 바꿔서 끝내기 어렵다

모델을 교체하는 기능이 있더라도 도구 선택과 응답 형식, 긴 문맥을 처리하는 방식이 달라질 수 있다. 같은 프롬프트를 보냈다는 사실만으로 같은 업무를 수행한다고 말하기 어렵다.

대체 경로를 준비한다면 최소한 유지해야하는 동작을 정해두면 좋겠다. 구조화 결과의 스키마와 필수 필드, 금지된 도구 실행 같은 조건이다.

```text
이용 불가 상황의 처리 예시
실패 감지 → 작업 상태 보존 → 재시도 여부 판단 → 검증된 대체 경로
```

여기서 재시도는 이미 실행한 외부 작업을 다시 수행하지 않도록 연결되어야한다. 모델 호출이 실패한 시점과 실제 도구의 반영 시점이 다를 수 있기 때문이다.

사용자에게도 완료와 지연, 실패를 구분해서 보여주는게 좋겠다. 내부에서는 중단됐는데 화면에 계속 실행 중이라고 남으면 사용자가 같은 작업을 다시 요청할 수 있다.

이용 상태가 바뀌는 상황에서 전체 업무를 멈추지 않으려면 중간 결과와 외부 반영을 분리해 기록하는게 도움이 될 수 있다. 모델이 대화를 기억하는것과 서비스가 작업 상태를 보관하는것은 다른 책임이다.

# 4. AI 검색 — 웹 검색에서 이미지 결과도 받을 수 있다

6월 9일 [OpenAI Responses API의 웹 검색](https://developers.openai.com/api/docs/changelog)에 이미지 결과 지원이 추가됐다. 텍스트와 함께 웹 기반의 시각 자료를 찾는 애플리케이션에서 살펴볼 변화다.

텍스트 설명만으로 이미지를 추측하는 흐름과 실제 검색 결과의 이미지를 연결하는 흐름은 다르다. 화면에서는 어떤 이미지가 어느 출처와 연결되는지 보존해야겠다.

## 이미지의 내용과 검색 결과의 설명을 함께 확인하자

장소와 제품, 행사처럼 시각 자료가 필요한 검색에서는 비슷해 보이는 이미지가 잘못 연결될 수 있다. 사용자가 요청한 대상과 날짜, 버전이 맞는지 함께 확인해야한다.

예를 들어 제품 이름이 같아도 출시 연도와 색상이 다를 수 있다. 검색 문장의 일부가 맞는다는 이유만으로 원하는 제품의 사진이라고 확정하기 어렵다.

결과를 저장하는 구조에는 이미지 주소와 출처 페이지, 관련 설명을 연결해두면 좋겠다. 카드의 순서를 다시 정렬한 뒤 설명과 이미지가 서로 어긋나지 않는지도 확인할 수 있다.

이미지 주소가 만료되거나 외부 사이트가 응답하지 않는 경우의 표시도 필요하다. 빈 영역만 남기는 대신 어떤 결과였는지 알 수 있는 대체 텍스트와 실패 상태를 준비하면 좋겠다.

## 검색으로 찾은것과 다시 사용할 수 있는것은 별개다

검색에서 발견한 이미지가 공개 웹페이지에 있다는 사실만으로 서비스가 자유롭게 재배포할 수 있다고 가정하면 안되겠다. 실제 사용 방식에 맞는 조건과 출처를 확인할 필요가 있다.

링크를 보여주는 기능과 이미지를 내려받아 장기간 저장하는 기능은 운영 방식도 다르다. 우리 서비스가 어느 동작을 하는지 먼저 정하면 검토할 범위가 명확해진다.

모델이 작성한 캡션도 원본 페이지의 확정 정보와 구분해서 다루고 싶다. 이미지에서 추론한 설명이 사실처럼 검색 결과에 붙으면 사용자가 출처의 내용으로 오해할 수 있다.

검색 결과는 외부에서 온 데이터이므로 그 안의 문장을 실행 지시로 취급하지 않는것도 중요하다. Agent가 검색과 다른 도구를 함께 사용할때는 외부 콘텐츠와 실제 사용자의 요청을 분리해야겠다.

# 5. 개발 프레임워크 — HarnessAgent는 모델 위의 실행 환경을 연결한다

6월 12일 Vercel이 [HarnessAgent](https://vercel.com/changelog/program-agent-harnesses-with-ai-sdk)를 실험적으로 공개했다. Claude Code와 Codex, Pi 등 기존 코딩 Agent 하네스를 공통 API로 실행하는 방향이다.

이번주 기준 canary의 실험적 패키지이며 변경 가능성이 있다. 안정된 인터페이스라고 가정해 큰 서비스에 바로 묶기보다 작은 작업으로 동작과 차이를 확인하면 좋겠다.

## 하네스는 모델 호출 바깥의 실행 흐름을 관리한다

모델은 다음 응답과 도구 호출을 판단하지만 실제 작업에는 파일과 프로세스, 세션과 권한, 문맥 정리 같은 요소가 필요하다. 하네스는 이런 실행 구조를 관리하는 계층으로 이해하면 좋겠다.

따라서 하네스 교체는 모델 이름 교체보다 많은 차이를 만들 수 있다. 같은 모델을 쓰더라도 파일을 읽는 방식과 도구의 결과, 세션을 이어가는 규칙이 다르면 최종 행동도 달라질 수 있다.

```text
애플리케이션
  → 공통 Agent 인터페이스
  → 선택한 하네스
  → 모델·도구·세션·실행 환경
```

공통 인터페이스는 반복되는 연결 코드를 줄이는데 도움이 될 수 있다. 다만 각 하네스의 기능과 제한까지 모두 같아지는것으로 이해하지는 않는게 좋겠다.

## 세션의 시작과 종료도 테스트에 포함하자

코딩 Agent를 실행하는 작업에서는 저장소의 시작 상태와 설치된 의존성, 필요한 환경 변수가 결과에 영향을 준다. 비교할때는 같은 작업 공간과 완료 조건을 사용해야한다.

세션이 끝났을때 파일 변경과 로그를 어떻게 가져오고 실행 환경을 언제 정리할지도 정해야한다. 최종 텍스트만 받아서는 실제 수정 결과를 검토하기 어렵다.

권한 요청이 발생한 경우와 명령이 실패한 경우, 실행을 중간에 취소한 경우도 시험하면 좋겠다. 정상 종료 경로만 맞춰두면 오래 실행되는 작업에서 자원이 남을 수 있다.

개인적으로는 간단한 버그 수정 하나를 대상으로 시작 코드와 패치, 테스트 결과를 함께 비교하고 싶다. 어떤 하네스가 더 많은 일을 했는지보다 완료 조건을 정확히 충족했는지 보는것이다.

# 6. 이번주에는 실행의 경계를 먼저 그려보자

Spring의 도구 호출과 외부 하네스, 검색 기능은 모두 다른 계층을 연결한다. 각 계층이 무엇을 받아 무엇을 실행하고 어디에 결과를 남기는지 적어보면 전체 구조를 이해하기 쉽다.

| 경계 | 남겨둘 질문 |
| --- | --- |
| HTTP·gRPC | 실제 접속 대상과 요청 계약은 무엇인가 |
| 모델·도구 | 실행 전 권한은 어디서 확인하는가 |
| 모델 이용 상태 | 실패한 작업을 어떻게 보존하는가 |
| 검색·이미지 | 결과와 출처가 계속 연결되는가 |
| 하네스·세션 | 파일과 실행 결과를 어떻게 검토하는가 |

# 마무리

이번주는 Spring Boot 4.1과 Spring AI 2.0의 정식 출시가 가장 큰 기준점이다. Java 백엔드의 운영 기능과 AI 도구 실행을 같은 개발 흐름 안에서 설계할 기반이 강화됐다.

새 모델은 발표와 접근 상태를 함께 확인하고, 검색과 하네스는 외부 데이터와 실행 권한의 경계를 명확히 해야겠다. 기능이 연결될수록 중간 과정을 볼 수 있어야 문제를 고치기도 쉽다.

개인적으로는 이번주에 작은 도구 호출 하나부터 요청과 실행, 결과의 흐름을 그려보려고 한다. 최종 답변만 읽을때 보이지 않았던 운영 조건을 찾을 수 있을것같다..


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

독자의 메모