[2026.06.26 주간 개발 트렌드] AI SDK 7과 Deno 2.9, Next.js의 다음 변화

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

# 이번주는 Agent의 실행 과정과 CI의 시작 조건을 살펴보자

이번주에는 Spring AI 2.0의 도구 호출 설계가 구체적으로 소개됐고 Spring Tools도 새 버전이 나왔다. 코드 작성과 프로젝트 분석, 실제 실행의 연결이 조금씩 더 명확해지고 있다.

GitHub Actions에서는 워크플로를 누가 어떤 이벤트로 시작할지 제한하는 정책과 사용자 정의 이미지의 계층화가 공개됐다. Copilot의 경량 코딩 모델도 더 많은 개발 환경으로 확대됐다.

6월 15일부터 19일까지의 내용을 다섯가지로 나눠 정리해보았다.

| 분야 | 소식 | 확인할 부분 |
| --- | --- | --- |
| 백엔드·AI | Spring AI 도구 호출 설계 | 실행 루프와 Advisor의 위치 |
| 개발 도구 | Spring Tools 5.2 | 프로젝트 분석과 실험적 플러그인 |
| CI 보안 | Actions 실행 보호 Preview | 실행 주체와 이벤트 허용 정책 |
| CI 환경 | Runner 이미지 계층화 | 공통 기반과 팀별 의존성 |
| 코딩 모델 | MAI-Code-1-Flash 확대 | 도구별 제공 상태와 검토 흐름 |

개인적으로는 이번주 소식이 모두 실행 전후의 정보를 더 잘 관리하려는 방향으로 보인다. AI가 어떤 과정을 거쳤는지, CI가 어떤 조건과 환경에서 시작됐는지 알아야 결과를 믿고 받아들일 수 있다.

# 1. 백엔드·AI — Spring AI의 도구 호출은 조합할 수 있는 실행 구조다

6월 15일 Spring 팀이 [Spring AI 2.0의 도구 호출 아키텍처](https://spring.io/blog/2026/06/15/spring-ai-composable-tool-calling/)를 설명했다. 모델 구현 내부에 있던 실행 루프를 `ChatClient`의 Advisor 체인으로 옮긴 설계가 중심이다.

지난주 정식 버전의 기능을 살펴봤다면 이번주에는 그 구조를 조금 더 이해할 수 있다. 모델의 응답을 감싸는 처리와 반복되는 도구 호출을 어디에 연결하는지가 중요한 부분이다.

## 전체 요청을 보는것과 매 반복을 보는것은 다르다

Agent가 사용자 질문 하나를 처리하면서 검색과 조회 도구를 여러번 부를 수 있다. 전체 작업의 시작과 끝만 기록하면 최종 시간은 알 수 있지만 어느 단계가 느리거나 실패했는지는 찾기 어렵다.

Advisor가 도구 호출 루프의 바깥에 있는지 안쪽에 있는지에 따라 보는 범위가 달라진다. 메모리나 관측 코드를 연결할때는 우리가 필요한 정보가 전체 결과인지 중간의 반복인지 먼저 정하면 좋겠다.

```text
사용자 요청 전체
  └─ 도구 실행 루프
       ├─ 모델 응답
       ├─ 도구 실행
       └─ 결과를 반영한 다음 판단
```

예를 들어 최종 응답의 지연만 기록하면 모델이 오래 생각한것인지 DB 조회가 느린것인지 구분하기 어렵다. 반복별 시간과 도구 실행 시간을 분리하면 개선할 위치를 찾을 수 있다.

반대로 모든 중간 데이터를 항상 저장하면 양과 민감도가 커질 수 있다. 필요한 식별 정보와 상태를 남기고 원문과 도구 결과를 어느 범위까지 기록할지 정해야겠다.

## 대화 메모리와 작업 이력은 같은 요구가 아니다

대화를 다음 요청에 이어주려는 메모리와 장애 원인을 찾으려는 실행 기록은 목적이 다르다. 사용자의 질문과 최종 답만 보관하는 구조로는 도중에 실패한 외부 작업을 설명하기 어려울 수 있다.

도구 호출과 응답까지 보관한다면 저장소가 그 메시지 형식을 지원하는지 확인해야한다. 텍스트 대화만 저장한다고 생각하고 만든 구조에 여러 종류의 메시지가 들어올 수 있기 때문이다.

개인적으로는 다음 요청의 문맥에 필요한 정보와 운영자가 확인할 이력을 따로 정의하고 싶다. 모든 로그를 모델에게 다시 보내는것이 항상 좋은 문맥은 아니다.

대화가 길어져 일부 내용을 줄일때도 실행된 작업의 사실은 잃지 않아야한다. 요약문에 주문을 생성했다고 적힌것과 서버에 남은 실제 주문 상태를 대조할 수 있어야한다.

## 반복 실행의 종료 조건을 업무 기준으로 정하자

모델이 최종 답변을 반환하는것은 기본적인 종료 조건이 될 수 있다. 실제 서비스에서는 실행 시간과 도구 사용량, 오류 반복 같은 조건도 필요하다.

예를 들어 검색 결과가 없을때 조건을 넓혀 재검색할 수는 있다. 하지만 권한이 없는 데이터에 대한 요청을 표현만 바꿔 반복하는것은 다른 처리다. 오류의 종류에 맞춰 중단과 재시도를 나눠야겠다.

실행을 중간에 취소하면 이미 완료한 도구와 아직 실행하지 않은 도구의 상태를 구분할 수 있어야한다. 모델 응답 생성을 멈추는것만으로 외부 작업까지 모두 되돌아간다고 가정하면 안된다.

테스트도 정상 경로 한개보다 실패를 넣은 작은 흐름이 유용할 수 있다. 두번째 도구가 시간 초과됐을때 첫번째 작업을 다시 실행하지 않는지 확인하는것이다.

## 도구를 많이 등록할때는 선택의 품질도 살펴보자

도구의 수가 늘어나면 모델에게 전달할 설명과 스키마도 많아진다. 필요한 도구를 찾아 단계적으로 노출하는 방식은 이런 부담을 다루는 선택지가 될 수 있다.

다만 검색으로 도구를 찾는것과 그 도구를 실행할 권한이 있다는것은 별개다. 검색 결과에 들어오는 도구와 실제 실행 시의 권한 검사를 같은 정책으로 연결해야한다.

이름이 비슷한 도구와 오래된 설명을 가진 도구도 시험해보면 좋겠다. 잘못된 도구를 고른 이유가 모델의 판단인지 설명의 모호함인지 구분할 수 있다.

# 2. 개발 도구 — Spring Tools가 프로젝트 정보를 Agent에 전달한다

6월 15일 [Spring Tools 5.2.0](https://spring.io/blog/2026/06/15/spring-tools-5-2-0-released/)이 나왔다. VS Code와 Cursor, Eclipse 등의 지원과 함께 실험적인 Claude Code 플러그인이 소개됐다.

플러그인은 내장 MCP 서버를 통해 Spring 프로젝트의 정적 분석과 문제·수정 정보를 전달하는 방향이다. Spring AI 프로젝트의 인덱싱·검증 지원도 포함됐다.

## 저장소 파일만 읽는것과 프로젝트 구조를 아는것은 다르다

Spring 프로젝트에는 코드뿐 아니라 빈 구성과 설정, 의존성 조합이 실제 동작에 영향을 준다. Agent가 파일 몇개만 읽으면 이 연결을 잘못 추측할 수 있다.

도구가 분석한 프로젝트 정보를 제공하면 판단에 필요한 근거를 더 명확히 전달할 수 있다. 다만 정적 분석이 확인한 범위와 실제 실행에서 확인해야하는 부분은 구분해야한다.

예를 들어 설정 키가 잘못됐다는 분석은 수정의 단서가 된다. 수정 후 애플리케이션이 어떤 프로파일로 실행되고 실제 외부 서비스에 연결되는지는 별도의 실행 검증이 필요하다.

```text
수정의 근거를 연결하는 흐름
프로젝트 분석 → 문제 확인 → 변경 제안 → 코드 수정 → 빌드·실행 확인
```

Agent가 분석 도구를 불렀다는 사실만으로 문제를 해결했다고 말하기는 어렵다. 어떤 진단을 받았고 무엇을 바꿨으며 그 진단이 어떻게 달라졌는지 연결하면 리뷰하기 쉽다.

## 실험적 플러그인은 작은 프로젝트에서 흐름을 확인하자

이번주 기준 Claude Code 플러그인은 실험적 기능이다. 프로젝트 분석이 유용해도 사용하는 환경과 버전에 따라 동작을 확인할 필요가 있다.

실제 설정 오류 하나를 준비해 진단과 수정 제안이 맞는지 볼 수 있다. 자동 수정 후 변경 범위가 필요한 파일에 한정됐는지도 함께 확인하면 좋겠다.

기업 내부 Maven 저장소를 쓰는 프로젝트라면 의존성을 찾는 기준도 중요하다. 공개 저장소에 없다는 이유로 사용 중인 버전을 잘못된것으로 판단하지 않도록 현재 빌드 설정을 기준으로 봐야한다.

분석 결과가 오래된 상태인지도 확인할 수 있다. 브랜치를 바꾸거나 의존성을 수정한 뒤 인덱스가 갱신됐는지 알아야 이전 프로젝트 상태를 근거로 고치는 일을 줄일 수 있다.

개인적으로는 Agent가 추측해서 고친 부분과 도구의 진단을 근거로 고친 부분을 구분해 보고싶다. 리뷰할때 다시 확인할 지점을 찾기 쉬워지기 때문이다.

# 3. CI 보안 — 워크플로의 실행 주체와 이벤트를 제한할 수 있다

6월 18일 [GitHub Actions 실행 보호](https://github.blog/changelog/2026-06-18-control-who-and-what-triggers-github-actions-workflows/)가 공개 프리뷰로 나왔다. 관리자가 허용 목록으로 실행 주체와 이벤트를 제어하는 기능이다.

워크플로 파일 자체가 바뀌는 상황에서도 실행 전에 정책을 평가하는것이 핵심이다. YAML에 적힌 이벤트 조건과 조직이 허용한 실행 범위를 함께 볼 수 있게 됐다.

## 실행을 허용하는 정책과 작업의 권한을 나눠보자

워크플로를 시작할 수 있다는것과 운영 배포 권한을 사용할 수 있다는것은 서로 다른 결정이다. 실행 보호 정책이 있다고 토큰과 비밀값의 권한까지 자동으로 적절해지는것은 아니다.

```text
CI에서 나눠볼 경계
누가 시작하는가
  → 어떤 이벤트인가
  → 어떤 코드를 실행하는가
  → 어떤 권한과 환경을 사용하는가
```

예를 들어 외부 PR의 검증과 내부 브랜치의 배포는 다른 조건을 가져야할 수 있다. 같은 저장소 안에서도 테스트에 필요한 권한과 배포에 필요한 권한이 다르기 때문이다.

사람의 실행뿐 아니라 봇과 자동화 계정이 만드는 이벤트도 목록에 넣어보면 좋겠다. 정책을 적용한 뒤 정상적인 정기 작업과 의존성 업데이트가 막히지 않는지 확인해야한다.

허용 범위를 검토할때는 넓은 예외 하나로 모든 작업을 통과시키기보다 실제 필요한 흐름을 먼저 정리하고 싶다. 차단이 불편하다는 이유로 예외를 계속 늘리면 정책의 의미를 설명하기 어려워진다.

## 거절된 실행도 운영자가 이해할 수 있어야한다

정책이 의도대로 작동해도 개발자에게 이유가 보이지 않으면 CI 장애로 받아들일 수 있다. 어떤 실행이 어떤 정책으로 거절됐는지 확인할 경로가 필요하다.

도입 전에는 허용될 실행과 거절될 실행을 한쌍으로 시험하면 좋겠다. 정상 사용자의 정상 이벤트가 성공했다는것만으로 허용 범위가 충분히 좁은지 알 수는 없다.

팀마다 저장소와 자동화 방식이 다르다면 작은 범위에서 먼저 적용해볼 수 있다. 공통 정책을 만들더라도 각 저장소가 실제로 사용하는 이벤트의 차이는 확인해야겠다.

Preview 기능이므로 현재 제공 조건과 정책의 적용 범위도 읽어보자. 발표를 봤다는 사실과 우리 조직에 필요한 설정을 사용할 수 있다는 사실은 별도로 확인할 부분이다.

# 4. CI 환경 — 공통 Runner 이미지 위에 팀별 이미지를 쌓을 수 있다

6월 18일 [Actions 사용자 정의 이미지](https://github.blog/changelog/2026-06-18-actions-build-custom-images-from-custom-images/)의 계층화가 가능해졌다. 공통 도구를 담은 기반 이미지 위에 팀의 의존성을 추가하는 구성이다.

각 팀이 같은 설치 과정을 반복하는 일을 줄일 수 있다. 하지만 이미지가 여러 단계로 연결되면 어떤 기반에서 만들어졌는지와 변경을 전파하는 방법도 관리해야한다.

## 공통 도구와 프로젝트 의존성을 나눠보자

조직 공통 인증서와 빌드 도구, 보안 정책에 필요한 설정은 기반 이미지에 두는것을 검토할 수 있다. 팀마다 자주 바뀌는 패키지와 프로젝트 설정은 그 위에서 관리하는 방식이다.

```text
조직 기반 이미지
  ├─ 팀 A 이미지 → 프로젝트 A의 CI
  └─ 팀 B 이미지 → 프로젝트 B의 CI
```

공통으로 올릴 항목은 사용하는 팀의 범위와 변경 빈도를 같이 보면 좋겠다. 일부 프로젝트만 쓰는 무거운 도구를 모두의 기반에 넣으면 이미지 관리와 배포의 부담이 커질 수 있다.

매 실행마다 받는 프로젝트 의존성과 이미지에 미리 설치한 도구의 버전이 충돌하지 않는지도 확인해야한다. 설치 시간을 줄였지만 실제로 어떤 실행 파일을 쓰는지 모호해질 수 있기 때문이다.

개인적으로는 이미지의 목적을 한 문장으로 설명할 수 있게 만들고 싶다. 어떤 프로젝트든 실행되는 거대한 이미지보다 필요한 환경과 갱신 책임이 드러나는 구성이 관리하기 쉽다.

## 기반 이미지의 수정이 팀 이미지에 전달되는지 확인하자

기반의 취약한 패키지를 고쳤다고 이미 만들어진 팀 이미지가 자동으로 새 내용이 되는것은 아니다. 어떤 버전을 기반으로 빌드했고 언제 다시 만들었는지 알아야한다.

이미지의 버전과 생성 워크플로, 사용하는 프로젝트를 연결해두면 영향을 찾기 쉽다. 문제가 생겼을때 지난 정상 이미지로 돌아갈 수 있는지도 확인하면 좋겠다.

새 이미지를 만들때는 도구가 설치됐는지만 보지 말고 대표 프로젝트의 실제 빌드와 테스트를 실행해볼 수 있다. 명령은 존재하지만 필요한 라이브러리나 인증서가 빠질 수 있기 때문이다.

속도를 비교할때도 이미지 생성 시간과 CI 실행 준비 시간을 나눠야한다. 팀 이미지가 자주 바뀐다면 준비 비용이 다른곳으로 옮겨간것일 수도 있다.

## 이미지에 비밀값을 남기지 않도록 생성 경로를 보자

빌드 중 필요한 인증 정보가 설치 결과와 함께 저장되지 않는지 확인해야한다. 실행 시점에 주입할 값과 이미지에 포함할 공개 설정을 나누는것이다.

설치 로그와 캐시, 사용자 디렉터리에 남은 설정도 검토할 수 있다. 기반 이미지가 여러 팀으로 퍼지면 한곳에 남은 정보의 영향 범위도 넓어질 수 있다.

이 부분은 이미지 계층화의 단점이라기보다 재사용하는 실행 환경을 만들때 함께 설계할 책임이다. 누가 만들고 검증하고 갱신하는지 분명하면 반복 작업을 줄인 장점을 살리기 쉽다.

# 5. 코딩 모델 — MAI-Code-1-Flash를 더 많은 환경에서 쓸 수 있다

6월 18일 [MAI-Code-1-Flash의 제공 환경](https://github.blog/changelog/2026-06-18-mai-code-1-flash-available-on-more-copilot-surfaces/)이 확대됐다. Copilot CLI와 Visual Studio, JetBrains IDE 등으로 범위가 넓어졌으며 계정별 제공은 단계적으로 진행된다.

같은 모델을 여러 도구에서 선택할 수 있어도 작업 환경이 모두 같아지는것은 아니다. 도구가 전달한 문맥과 실행 가능한 명령, 사용자에게 보여주는 검토 화면이 다를 수 있다.

## 비교할때는 모델과 도구의 영향을 나눠보자

IDE에서는 현재 파일과 진단 정보가 연결되고 CLI에서는 명령과 저장소 탐색의 흐름이 달라질 수 있다. 같은 요청 문장만으로 완전히 같은 조건이라고 보기 어렵다.

비교할 작업의 시작 커밋과 완료 조건, 실행할 테스트를 먼저 고정하면 좋겠다. 어떤 정보를 자동으로 제공했고 어떤 명령을 실제로 실행했는지도 남겨볼 수 있다.

경량 모델은 범위가 작은 수정에서 먼저 평가하고 싶다. 응답이 빠른지와 함께 패치가 정확한지, 검토에 얼마나 걸렸는지를 볼 수 있기 때문이다.

모델 선택 화면에 보이지 않는다면 출시 자체가 없었다고 판단하기보다 플랜과 순차 제공 상태를 확인해야겠다. 팀 내 사용자마다 같은 날에 같은 선택지가 보인다고 가정하지 않는게 좋겠다.

# 6. 이번주에는 실행 기록을 서로 연결해보자

이번주 소식을 실제 프로젝트에 연결한다면 하나의 수정이 어떤 근거와 환경에서 검증됐는지 남기는것부터 시작하고 싶다. Agent의 분석과 패치, CI 정책과 Runner 이미지가 같은 변경에 연결되면 재현하기 쉬워진다.

| 기록 | 연결할 대상 |
| --- | --- |
| 도구 실행 이력 | 요청·반복·실제 반영 상태 |
| 프로젝트 진단 | 분석한 코드와 수정 결과 |
| 워크플로 정책 | 실행 주체·이벤트·허용 이유 |
| Runner 이미지 | 기반 버전·생성 작업·검증 결과 |
| 코딩 모델 평가 | 시작 코드·문맥·최종 패치 |

모든 정보를 한 로그에 쏟아넣기보다 서로 찾을 수 있는 식별 정보를 두면 좋겠다. 조사에 필요한 관계를 남기는것과 원문을 무제한 저장하는것은 다른 일이다.

# 마무리

이번주는 Spring AI의 도구 호출이 어떻게 구성되는지 이해할 자료가 나왔고 개발 도구도 프로젝트 분석을 Agent와 연결하기 시작했다. GitHub Actions는 실행을 허용하는 조건과 실행 환경을 더 세밀하게 관리할 수 있게 됐다.

기능이 늘어날수록 누가 무엇을 어떤 환경에서 실행했는지 중요해진다. 최종 성공 표시뿐 아니라 중간 과정과 실패한 상태를 찾을 수 있어야 운영에서도 사용할 수 있다.

개인적으로는 이번주에 CI 이미지의 기반 버전과 Agent의 도구 실행 기록부터 확인해보려고 한다. 결과가 달라졌을때 원인을 찾을 수 있는 정보가 남아있는지 한번 봐야할것같다..


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

독자의 메모