[2026.05.29 주간 개발 트렌드] Opus 4.8과 API 인증·캐시, 데이터 수집

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

# 이번주는 Agent를 서비스에 연결하는 방법이 넓어졌다

이번주에는 Google I/O의 Gemini 모델과 관리형 Agent, Stitch 업데이트가 나왔다. OpenAI는 내부 MCP 연결을 위한 터널을 소개했고 Deno와 npm도 도구·공급망 관리 기능을 넓혔다.

모델이 더 잘 판단하는것과 그 모델을 어디서 실행하고 어떤 시스템에 연결할지는 다른 문제다. 이번주에는 이 여러 계층의 선택지가 함께 늘어난것이 눈에 띈다.

5월 18일부터 22일까지의 내용을 여섯가지로 나눠보았다.

| 분야 | 소식 | 구분해서 볼 역할 |
| --- | --- | --- |
| AI 모델 | Gemini 3.5 Flash | 코딩과 긴 작업의 판단 |
| AI 실행 | Gemini Managed Agents | 격리된 클라우드 실행 환경 |
| 내부 연결 | Secure MCP Tunnel | 외부 서비스와 비공개 MCP의 통신 |
| Runtime | Deno 2.8 | 설치·변환·보안 도구의 통합 |
| 패키지 보안 | npm staged publishing | 준비한 패키지와 실제 공개의 분리 |
| 디자인 | Stitch 실시간 협업 | 시안의 반복과 구현 단계 연결 |

비슷한 Agent라는 이름이 붙어도 무엇을 대신하는지 다르다. 이번주에는 기능을 한 덩어리로 보기보다 실행 흐름에서의 위치를 나눠보려고 한다.

# 1. AI 모델 — Gemini 3.5 Flash는 긴 작업과 속도를 강조했다

5월 19일 Google이 [Gemini 3.5 Flash](https://blog.google/intl/en-africa/products/explore-get-answers/gemini-3-5/)를 공개했다. 복잡한 코딩과 Agent 작업, 긴 실행에서의 판단과 응답 속도를 함께 강조하는 모델이다.

제공자가 발표한 성능은 개선 방향을 읽는 자료로 보고, 우리 작업에서는 같은 입력과 도구를 기준으로 비교하면 좋겠다. 응답 생성 속도와 전체 업무의 완료 시간은 다른 지표다.

## 빠른 판단이 도움이 되는 작업부터 찾아보자

Agent는 한번 답하고 끝나는것보다 여러번 파일을 읽고 도구 결과를 확인하는 작업이 많다. 각 판단의 대기가 줄면 반복 작업의 왕복 시간에도 영향을 줄 수 있다.

다만 도구 실행과 설치, 테스트가 대부분의 시간을 쓰면 모델의 속도 개선이 전체에서 차지하는 비중은 달라진다. 어느 구간이 느린지 먼저 알아야한다.

```text
긴 작업의 시간
모델 판단 + 도구 실행 + 실패 수정 + 검증 + 사람의 검토
```

예를 들어 코드 탐색은 빨라졌는데 필요한 파일을 놓쳐 다시 수정한다면 첫 응답 시간만으로 결과를 평가하기 어렵다. 요구를 끝까지 유지하는지와 재작업 횟수도 함께 보고싶다.

모델 비교에는 실제로 반복하는 작은 작업 묶음을 사용하면 좋겠다. 버그 수정과 코드 리뷰, UI 작업과 자료 분석처럼 성격이 다른 작업을 나누면 차이가 보인다.

## 도구를 잘 사용하는지와 결과를 검증하는지 보자

많은 도구를 호출했다고 필요한 근거를 얻었다는 의미는 아니다. 현재 문제와 관련된 상태를 찾고 그 결과를 다음 판단에 반영해야한다.

실패한 명령을 같은 조건으로 반복하거나 자료를 찾지 못한 상태에서 추측으로 코드를 바꾸는지를 확인할 수 있다. 반대로 모르는 부분을 정확히 남기는것도 유용한 결과다.

작업 완료 보고에는 실제 변경과 실행한 검증, 확인하지 못한 범위를 구분하면 좋겠다. 모델의 설명이 실제 diff와 도구 결과에 맞는지도 평가할 수 있다.

개인적으로는 더 빠른 모델의 가치를 검토자의 시간을 포함해 보고싶다. 코드가 일찍 나오는것과 받아들일 수 있는 결과가 일찍 준비되는것은 다를 수 있기 때문이다.

# 2. AI 실행 — Gemini API에서 관리형 Agent를 시작할 수 있다

같은 5월 19일 [Gemini API Managed Agents](https://blog.google/innovation-and-ai/technology/developers-tools/managed-agents-gemini-api/)가 소개됐다. 격리된 임시 Linux 환경에서 도구를 사용하고 코드를 실행하는 Agent를 API로 구동하는 방식이다.

모델 호출 외에 실행 공간을 직접 준비하던 부분을 관리형 서비스로 다룰 수 있다는 의미다. 사용하려는 API와 제품 경로의 제공 조건은 각각 확인해야겠다.

## 모델과 실행 환경을 구분하면 선택이 쉬워진다

모델은 다음 행동과 도구 사용을 판단한다. 실행 환경은 실제 파일과 프로세스, 명령과 의존성이 동작하는 장소다. 어느 모델을 사용할지와 환경을 누가 운영할지는 다른 결정이다.

```text
관리형 Agent의 연결
요청과 지시 → Agent 실행 → 격리 환경의 도구 → 결과와 산출물
```

예를 들어 파일을 분석하는 서비스라면 어떤 입력을 전달하고 어떤 결과를 가져올지 정해야한다. 실행 환경 안에 파일이 생성됐다는 사실과 서비스에 최종 저장됐다는 사실은 다르다.

임시 환경의 수명도 확인할 부분이다. 다음 요청까지 필요한 데이터와 이번 작업에서만 필요한 파일을 나눠야 상태를 잃거나 불필요하게 보관하는 일을 줄일 수 있다.

관리형이라는 이유로 모든 애플리케이션의 규칙이 자동으로 적용되는것은 아니다. 사용자별 입력 범위와 실행 한도, 결과의 검토 조건은 서비스의 계약으로 남아있다.

## 긴 작업의 취소와 결과 회수를 시험하자

정상 작업이 끝나는 데모 외에 시간 초과와 취소, 도구 실패가 있는 경우를 시험하면 좋겠다. 요청이 중단됐을때 환경과 결과가 어떤 상태로 남는지 알아야한다.

코드 생성이 완료됐어도 테스트가 남아있다면 최종 결과에서 구분해야한다. 작업 한도에 도달한 상태를 요구사항 완료로 표시하면 사용자가 결과를 잘못 해석할 수 있다.

관측 기록에는 요청과 실행, 도구와 산출물을 연결할 식별 정보가 필요하다. 문제가 생긴 작업을 다시 확인할 수 있어야 관리형 인프라의 운영 효과도 설명하기 쉽다.

# 3. 내부 연결 — Secure MCP Tunnel은 공개 노출을 줄이는 선택지다

5월 19일 기업 고객을 위한 [OpenAI Secure MCP Tunnel](https://developers.openai.com/api/docs/guides/secure-mcp-tunnels)이 공개됐다. 내부망이나 온프레미스 MCP 서버를 인터넷에 직접 공개하지 않고 지원되는 OpenAI 제품과 연결하는 방식이다.

내부에서 MCP에 접근할 수 있는 `tunnel-client`가 외부로 연결을 시작해 요청과 결과를 전달한다. MCP 서버에 공개 수신 포트를 여는 방식과 구분해서 볼 수 있다.

## 연결 경로와 접근 권한은 다른 문제다

터널은 통신을 연결한다. 누가 어떤 데이터와 도구를 사용할 수 있는지는 내부 MCP와 애플리케이션의 권한 설계가 담당해야한다.

```text
연결의 역할
OpenAI 제품 ↔ 터널 경로 ↔ 내부 MCP ↔ 허용된 시스템·데이터
```

예를 들어 내부 문서를 찾는 도구와 운영 상태를 바꾸는 도구는 필요한 범위가 다르다. 같은 연결을 사용한다고 같은 권한을 제공할 필요는 없다.

사용자와 프로젝트의 접근 범위를 요청마다 확인하고 필요한 결과만 반환하면 좋겠다. 네트워크를 비공개로 유지하는것과 결과 데이터가 외부 서비스로 전달되는 범위를 정하는것은 별개의 판단이다.

도구 정의도 역할을 명확하게 설명해야한다. 이름만 비슷한 조회와 변경을 모델이 구분할 수 있어야 실제 실행 계약과 연결된다.

## 운영에서는 실패 지점을 구분할 수 있어야한다

내부 서버가 응답하지 않는것과 터널 연결이 끊긴것, 호출 권한이 없는것은 다른 실패다. 모두 자료가 없다는 결과로 반환하면 모델이 잘못된 설명을 할 수 있다.

요청 식별자와 호출한 도구, 결과 상태를 연결해두면 어느 계층에서 문제가 생겼는지 찾기 쉽다. 내부 시스템과 외부 작업의 시점을 비교할 근거가 된다.

처음에는 읽기 위주의 작은 도구부터 연결해 권한과 응답, 실패 처리를 확인하고 싶다. 연결이 가능하다는 사실 다음에 어떤 작업을 허용할지 정하는 과정이 필요하기 때문이다.

# 4. Runtime — Deno 2.8은 개발 도구의 역할을 더 넓혔다

5월 22일 [Deno 2.8](https://deno.com/blog/v2.8)이 출시됐다. `deno audit fix`, `deno transpile`, `deno ci` 등 새로운 명령이 추가됐다. 런타임이 설치와 변환, 보안 점검까지 한 도구 안에서 다루는 방향이 이어지고 있다.

도구가 통합되면 프로젝트마다 별도 스크립트를 조합하는 부담을 줄일 여지가 있다. 그래도 각 명령이 어디까지 수행하는지는 구분해야한다.

## 보안 수정은 자동 변경의 결과를 확인하자

`deno audit fix`는 의존성의 취약점을 수정하는 버전 변경을 돕는다. 현재 버전 제약 안에서 처리할 수 있는 수정과 더 큰 전환이 필요한 항목은 다를 수 있다.

자동으로 바뀐 잠금 파일과 의존성을 확인하고 관련 기능을 검증하면 좋겠다. 패치 버전이라는 이유만으로 우리 코드의 모든 사용 방식이 검증된것은 아니다.

보안 보고서의 항목이 줄어든것과 서비스에 실제 수정된 의존성이 배포된것도 구분해야한다. 빌드와 배포, 실행중인 환경까지 연결해서 확인하는것이다.

## 변환과 타입 검사, 번들링은 다르다

`deno transpile`은 TypeScript·JSX·TSX를 JavaScript로 내보내는 작업을 제공한다. 타입을 제거해 파일을 만든것과 프로젝트의 타입 검사를 통과한것은 다른 결과다.

번들러가 필요한 작업과 파일별 변환만 필요한 작업도 구분할 수 있다. 현재 스크립트가 어떤 산출물과 모듈 경로를 기대하는지 확인한 뒤 바꾸는게 좋겠다.

```text
빌드 단계의 구분
타입 검사 / 문법 변환 / 모듈 묶기 / 패키징 / 실제 실행
```

CI에서 명령 하나가 성공했다고 전체 검증을 완료한것으로 처리하지 않도록 단계별 역할을 적어두면 좋겠다. 도구가 통합되어도 완료 기준까지 하나로 섞을 필요는 없다.

## CI 설치는 잠금 파일의 의미를 유지하자

`deno ci`는 잠금 파일과 설정이 일치하는 설치를 CI에서 분명하게 표현하는 명령이다. 개발중 의존성을 갱신하는 작업과 정해진 상태를 재현하는 작업을 나눠볼 수 있다.

설치가 실패했을때 CI에서 자동으로 잠금 파일을 바꾸는 방식보다 변경을 별도 검토로 남기면 원인을 설명하기 쉽다. 같은 커밋에서 무엇이 설치됐는지 알아야하기 때문이다.

런타임과 설치 명령의 버전, 입력한 잠금 파일을 함께 관리하면 로컬과 CI의 차이를 좁히는데 도움이 되겠다.

# 5. 패키지 보안 — npm 게시를 준비와 공개로 나눌 수 있다

5월 22일 안내된 [npm staged publishing GA](https://github.blog/changelog/2026-05-29-staged-publishing-and-new-install-time-controls-for-npm/)는 패키지를 즉시 공개하는 대신 준비된 tarball을 대기열에 올리고 maintainer의 승인으로 공개하는 방식이다. 승인에는 2FA 확인이 필요하다.

설치 출처를 제어하는 `--allow-file`, `--allow-remote` 등의 옵션도 추가됐다. 사용하려는 npm CLI 버전과 옵션의 지원 범위는 확인해야겠다.

## CI의 신원과 사람이 검토한 결과를 연결하자

Trusted Publishing의 OIDC는 어느 워크플로가 게시를 요청하는지 확인하는 역할이다. staged publishing은 준비된 결과를 실제로 공개하는 단계를 나누는 역할이다.

```text
CI에서 패키지 준비
    ↓
stage 대기열
    ↓
maintainer 확인과 2FA 승인
    ↓
사용자가 설치할 수 있는 버전
```

승인 절차가 생겼다고 자동으로 좋은 검토가 이루어지는것은 아니다. 버전과 변경 내역, 포함된 파일과 검증 결과를 확인할 수 있어야한다.

특히 저장소의 소스와 실제 게시할 tarball을 구분해보자. 빌드 결과와 파일 선택 규칙에 따라 사용자가 받는 내용은 저장소 화면과 다를 수 있다.

예상한 코드와 선언 파일, 필요한 문서가 포함됐는지 확인하고 비밀값이나 불필요한 산출물이 들어가지 않았는지 살펴볼 수 있다. 검토의 대상은 최종 배포물이다.

## 대기와 승인, 공개 상태를 사용자 흐름에 반영하자

CI가 stage를 올렸다고 패키지가 이미 배포됐다고 표시하면 혼동이 생긴다. 준비 완료와 승인 대기, 실제 공개를 구분해 릴리스 절차에 연결해야한다.

승인 담당자와 확인할 결과, 실패한 게시를 다시 처리하는 방법을 정해두면 좋겠다. 자동화의 마지막에 사람을 추가하는것보다 명확한 검토 지점을 만드는것이 중요하다.

설치 출처 제한도 현재 의존성의 형태와 비교해야한다. 레지스트리 외의 URL과 로컬 경로, Git 의존성을 어디서 사용하는지 알아야 새로운 정책의 영향을 설명할 수 있다.

개인적으로는 게시 요청의 신원과 배포물의 검토를 함께 다룰 수 있다는 점에서 의미가 있다고 생각한다. 둘은 같은 보장을 제공하는 기능이 아니기 때문이다.

# 6. 디자인 — Stitch는 실시간으로 시안을 조정하는 흐름을 넓혔다

5월 19일 [Stitch 실시간 디자인 업데이트](https://blog.google/innovation-and-ai/models-and-research/google-labs/stitch-updates/)가 공개됐다. Agent가 디자인을 만드는 과정을 보고 중간에 방향을 바꾸는 협업을 강화했고, Antigravity로 결과를 내보내 구현 단계와 연결하는 흐름도 소개했다.

시안을 빨리 만드는것과 제품의 기능이 완성되는것은 다르다. 디자인 결과를 실제 코드와 데이터, 사용자 흐름에 연결하는 과정이 필요하다.

## 수정할 조건과 유지할 조건을 나눠보자

실시간으로 결과를 조정할 수 있으면 작은 방향 수정을 일찍 전달하기 쉽다. 다만 여러 요구를 동시에 바꾸면 어떤 변경이 결과에 영향을 줬는지 알기 어려워질 수 있다.

예를 들어 정보의 우선순위를 바꾸는 작업과 색을 바꾸는 작업, 반응형 배치를 조정하는 작업을 구분해볼 수 있다. 현재 시안에서 유지할 요소도 함께 알려주면 비교하기 쉽다.

결과를 볼때는 정상 데이터가 가득한 화면 외에 빈 상태와 긴 제목, 오류와 로딩도 확인하고 싶다. 실제 서비스에서는 이런 상태가 사용자 경험의 일부이기 때문이다.

## 내보낸 화면의 계약을 확인하자

구현 도구로 화면을 전달해도 실제 API와 권한, 데이터 모델의 규칙은 별도로 연결해야한다. 보기 좋은 폼이 서버에서 허용하는 입력과 맞는지 확인하는것이다.

버튼을 눌렀을때 무엇이 저장되고 어떤 오류를 보여줄지, 새로고침 뒤 어떤 값이 유지될지도 제품의 요구에 포함된다.

디자인과 구현의 연결 기록에는 화면의 의도와 데이터 계약을 함께 남기면 좋겠다. 시안의 모양을 그대로 옮기는것보다 사용자가 수행해야할 작업을 유지하는것이 중요하다.

# 7. 이번주에는 Agent 시스템의 계층을 나눠보자

Gemini 3.5 Flash는 판단을, Managed Agents는 실행 공간을, MCP Tunnel은 내부 도구와의 통신을 다룬다. Deno는 개발 명령을 정리하고 npm은 배포 경계를, Stitch는 시안과 구현의 연결을 다룬다.

| 선택 | 함께 정할 기준 |
| --- | --- |
| 모델 | 같은 작업의 품질·속도·완료 비용 |
| 실행 환경 | 파일 수명과 취소, 실제 산출물 |
| 내부 연결 | 사용자 권한과 반환 데이터의 범위 |
| 개발 명령 | 설치·검사·변환의 역할 |
| 패키지 게시 | 최종 배포물과 승인·공개 상태 |
| 디자인 도구 | 정상·실패 상태와 실제 기능 계약 |

한 계층의 편의 기능이 다른 계층의 책임을 모두 없애주지는 않는다. 무엇을 도구에 맡기고 무엇을 서비스의 규칙으로 보장할지 정하면 선택지를 비교하기 쉽겠다.

# 마무리

이번주는 모델 발표만큼 Agent를 실행하고 내부 시스템과 연결하며 결과를 배포하는 기반의 변화가 많았다. 개발 도구와 디자인도 이 흐름에 가까워지고 있다.

새로운 기능을 전부 한꺼번에 붙이기보다 현재 필요한 계층부터 작은 작업으로 시험해보면 좋겠다. 실행과 검토, 승인과 공개의 상태를 명확히 나누는것도 함께 필요하다.

개인적으로는 이번주에 모델과 실행 환경, 권한과 결과물을 한 장의 흐름으로 그려보고 싶다. 어떤 도구를 쓰는지보다 각 도구가 어디까지 책임지는지 알아야 서비스로 연결하기 쉬운것같다..


[2026.05.22 주간 개발 트렌드] 관리형 Agent와 Deno 2.8, npm 공급망 보안

독자의 메모