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

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

# 이번주는 모델의 성능과 운영 설정을 함께 봐야겠다

이번주에는 Claude Opus 4.8과 OpenAI의 신원 연동·캐시 정책 변화, Databricks의 쿼리 기반 데이터 수집, GitHub PR의 커버리지 표시 소식이 나왔다.

AI 모델을 바꾸는 일과 그 모델을 호출하는 인증·보존 설정은 서로 다른 작업이다. 데이터를 수집하고 코드 품질을 확인하는 과정에서도 제공된 기능과 실제 보장되는 결과를 나눠서 봐야한다.

5월 25일부터 29일까지의 내용을 다섯가지로 정리해보았다.

| 분야 | 소식 | 먼저 확인할 부분 |
| --- | --- | --- |
| AI | Opus 4.8 | 긴 작업의 판단과 Dynamic Workflows 제공 상태 |
| AI·인증 | Workload Identity Federation | 외부 신원과 단기 접근 토큰의 연결 |
| AI·운영 | 프롬프트 캐시 기본값 변화 | 캐시 재사용과 보존 설정 |
| 데이터 수집 | Databricks Query-Based Connector GA | 커서 기반 수집과 원본 DB의 영향 |
| 개발 도구 | PR 커버리지 Preview | 실행된 코드와 검증된 동작의 차이 |

개인적으로는 이번주에 새 모델을 평가하는것과 함께 현재 요청의 인증·데이터 처리 조건도 다시 확인해보고 싶다.

# 1. AI — Opus 4.8과 큰 작업을 위한 실행 흐름이 나왔다

5월 28일 [Claude Opus 4.8](https://www.anthropic.com/news/claude-opus-4-8)이 공개됐다. Anthropic은 코딩과 Agent 작업, 전문 업무에서의 판단과 일관성 개선을 소개했다.

함께 발표한 Claude Code의 Dynamic Workflows는 큰 작업을 나누고 실행하는 기능이다. 이번주 기준 연구 프리뷰이며 Enterprise·Team·Max 등 제공 조건이 있다. 모델의 일반 제공과 이 기능의 제공 상태를 같은것으로 묶지 않는게 좋겠다.

## 큰 작업은 분할보다 통합 기준이 먼저다

저장소 전반의 마이그레이션이나 여러 기능을 바꾸는 작업에서는 병렬 실행이 도움이 될 수 있다. 다만 작업을 많이 나눈다고 결과가 자동으로 하나의 설계로 모이는것은 아니다.

공유하는 API와 데이터 모델, 먼저 결정해야하는 계약을 정해두면 좋겠다. 같은 파일의 독립적인 줄을 바꿨더라도 서로 다른 가정에 의존하면 통합 후 문제가 생길 수 있다.

```text
큰 작업의 연결
완료 조건 → 공유 계약 → 독립 작업 → 결과 통합 → 전체 검증
```

예를 들어 인증 방식의 변경이라면 서버의 검증과 클라이언트의 요청, 배치의 자격 증명이 같은 전환 계획을 따라야한다. 각 작업이 자기 파일에서 테스트를 통과한것만으로 전체 완료를 말하기 어렵다.

작업을 맡기기 전에 무엇을 바꿀 수 있고 무엇을 유지해야하는지 적으면 결과를 비교하기 쉽다. 구현 방법을 모두 정해두기보다 지켜야할 계약과 관찰 가능한 결과를 명시하는것이다.

## 모델 비교는 성공한 사례와 실패한 사례를 함께 보자

새 모델을 평가할때 인상적인 결과 하나만 보면 실제 반복 작업의 차이를 놓칠 수 있다. 기존에 어려웠던 사례와 자주 하는 작은 작업을 함께 묶어보면 좋겠다.

코드가 맞는지와 수정 범위가 적절한지, 검증 결과가 정확히 보고됐는지를 나눠볼 수 있다. 많은 파일을 바꾸는 결과가 항상 더 좋은 결과는 아니기 때문이다.

실패한 작업에는 추가로 준 정보와 다시 실행한 횟수를 남겨두면 좋겠다. 첫 시도에 완료한 결과와 여러번 방향을 알려준 결과는 검토 비용이 다르다.

개인적으로는 장기 작업의 성능을 처리한 코드 줄 수보다 최종 변경의 검토 가능성으로 보고싶다. 무엇을 왜 바꿨고 어떤 근거로 완료했다고 판단하는지 알아야 실제로 받아들일 수 있다.

# 2. AI·인증 — 외부 신원으로 단기 OpenAI 토큰을 받을 수 있다

5월 26일 [OpenAI Workload Identity Federation](https://developers.openai.com/api/docs/guides/workload-identity-federation)이 도입됐다. 신뢰하는 실행 환경이 외부에서 발급받은 신원 토큰을 단기 OpenAI 접근 토큰으로 교환하는 방식이다.

서버와 CI에 장기 API 키를 직접 보관하던 구성을 검토할 수 있다. 다만 토큰의 수명이 짧아지는것과 허용되는 권한이 자동으로 적절해지는것은 다른 문제다.

## 어느 실행을 신뢰할지 구체적으로 정하자

외부 발급자를 신뢰한다는 설정만으로는 범위가 너무 넓을 수 있다. 실제로 어떤 저장소와 워크플로, 서비스가 어떤 OpenAI 프로젝트의 권한을 사용할지 연결해야한다.

```text
실행 환경의 신원
    ↓
신뢰 조건과 토큰 교환
    ↓
연결된 서비스 계정의 단기 접근 토큰
    ↓
허용된 API 작업
```

여기서 외부 신원과 내부 권한의 매핑이 중요하다. 같은 CI 플랫폼을 쓰는 모든 작업이 운영 프로젝트의 권한을 얻도록 구성할 필요는 없다.

개발과 운영, 읽기와 변경처럼 실제 업무의 경계에 맞춰 접근을 나누면 좋겠다. 토큰을 안전하게 받는 경로와 그 토큰으로 무엇을 할 수 있는지는 함께 검토해야한다.

정책을 시험할때는 허용할 실행과 거절할 실행을 모두 준비할 수 있다. 정상 요청 하나가 성공했다는것만으로 신뢰 범위가 충분히 좁은지 알기 어렵다.

## 토큰 갱신과 실패 상태도 애플리케이션의 일부다

단기 토큰은 수명이 끝나면 새 신원을 사용해 다시 받아야한다. 장기 실행 작업에서는 만료와 갱신 시점이 실제 API 호출에 어떤 영향을 주는지 확인해야한다.

동시에 여러 요청이 토큰을 필요로 할때 갱신이 어떻게 이루어지는지도 볼 수 있다. 인증 실패를 무조건 같은 토큰으로 재시도하면 작업만 반복될 수 있기 때문이다.

운영 기록에는 실제 토큰 값 대신 신원과 정책의 식별 정보, 교환과 호출의 결과를 연결하면 좋겠다. 비밀값을 노출하지 않고도 실패한 계층을 찾을 수 있어야한다.

기존 키를 쓰는 경로와 새 방식을 쓰는 경로가 전환 중에 함께 있다면 어느 요청이 어떤 인증을 사용하는지 구분해야겠다. 코드를 바꿨다는 사실과 오래된 자격 증명의 의존성이 사라졌다는 사실은 다르다.

# 3. AI·운영 — 프롬프트 캐시의 기본 보존 설정이 바뀌었다

5월 29일 [OpenAI API 변경 내역](https://developers.openai.com/api/docs/changelog)에 따르면 ZDR을 사용하지 않는 조직에서 `prompt_cache_retention`의 기본값이 `in_memory`에서 `24h`로 변경됐다.

이번주에는 명시적으로 설정하지 않은 요청이 어떤 기본 동작을 사용하는지 확인할 필요가 있다. API의 필드를 생략하는것은 기능을 사용하지 않는다는 의미가 아니라 현재 기본값을 따른다는 의미다.

## 캐시가 재사용하는 단위를 이해하자

[프롬프트 캐시](https://developers.openai.com/api/docs/guides/prompt-caching)는 여러 요청에서 공유하는 입력의 앞부분에 대한 계산을 재사용하는 기능이다. 같은 지시와 도구 설명, 공통 자료가 반복될때 입력 처리 비용과 대기에 영향을 줄 수 있다.

하지만 세션이 같거나 문서 주제가 비슷하다는 이유만으로 캐시가 항상 적중하는것은 아니다. 실제로 공유되는 입력과 요청 구성, 모델의 지원 조건을 함께 봐야한다.

```text
요청 입력의 구성 예시
공통 지시와 도구 + 재사용할 문맥 + 이번 요청의 자료
```

순서를 바꾸거나 매번 다른 값을 앞에 붙이면 재사용 조건이 달라질 수 있다. 캐시를 고려한다면 의미를 유지하면서 공통 부분을 안정적으로 구성할 수 있는지 살펴보면 좋겠다.

다만 캐시 적중률만 높이는것이 목적은 아니다. 오래된 자료를 계속 재사용하거나 필요한 최신 정보를 빠뜨리면 비용이 줄어도 답변의 품질이 나빠질 수 있다.

## 보존 설정은 데이터 처리 조건으로 함께 검토하자

이번 변경은 성능 옵션과 함께 데이터 보존의 조건을 확인하게 한다. 현재 조직의 설정과 요청별 값, 사용하는 모델의 지원 범위가 무엇인지 알아야한다.

캐시 보존과 다른 로그·애플리케이션 저장 정책을 같은 항목으로 묶지 않는게 좋겠다. 각각 어느 데이터와 어느 시스템에 적용되는지 분리해서 확인할 필요가 있다.

기본값에 의존하는 호출이 있다면 설정을 한곳에서 관리하고 의도를 남겨두면 유용하다. 서비스별로 다른 값을 사용한다면 그 이유도 설명할 수 있어야한다.

API를 감싼 내부 SDK가 필드를 생략하거나 덮어쓰는지도 확인해야겠다. 요청 코드에 적은 값과 실제 전송되는 값이 같아야 설정의 효과를 해석할 수 있다.

## 효과는 캐시 적중과 전체 비용을 나눠서 보자

공통 문맥이 큰 작업과 매번 입력이 완전히 다른 작업은 효과가 다를 수 있다. 실제 요청에서 재사용된 입력과 전체 응답 시간을 비교하면 좋겠다.

모델 호출 외에도 검색과 파일 준비, 도구 실행이 포함되므로 캐시가 전체 대기를 모두 줄여주는것은 아니다. 어느 구간의 비용이 바뀌었는지 나눠서 기록하는것이다.

개인적으로는 이번주에 기본값의 변경을 계기로 요청 설정을 명시적으로 정리해보고 싶다. 비용과 속도, 보존 조건을 같은 요청 구성에서 설명할 수 있어야겠다.

# 4. 데이터 수집 — Databricks는 쿼리 기반 커넥터를 GA로 제공한다

5월 29일 [Lakeflow Connect Query-Based Connectors](https://docs.databricks.com/aws/en/release-notes/product/2026/may)가 정식 제공됐다. 소스 DB를 커서 컬럼으로 직접 조회해 수집하며 CDC 설정이나 별도 수집 게이트웨이를 요구하지 않는 방식이다.

PostgreSQL과 MySQL, MariaDB와 Oracle, SQL Server 등 여러 소스를 지원한다. 계정과 플랫폼의 실제 제공 시점·지원 범위는 확인해야겠다.

## 설정 부담이 줄어도 원본 DB의 역할은 남는다

직접 조회하는 방식은 소스 DB에서 쿼리가 실행된다. 수집 주기와 조회 범위, 인덱스에 따라 운영 요청과 자원을 공유할 수 있다.

예를 들어 큰 테이블을 자주 넓게 읽으면 데이터 수집의 편의성과 별개로 원본 시스템의 부하를 확인해야한다. 적절한 커서와 조회 경로가 필요한 이유다.

```text
쿼리 기반 수집의 연결
소스 테이블 → 커서 조건의 조회 → 수집 결과 → 대상 데이터
```

수집 자체의 처리량과 소스 DB가 감당할 수 있는 부하를 함께 측정하면 좋겠다. 대상에 데이터가 빨리 들어왔다는 사실만으로 원본 서비스에도 영향이 없었다고 말할 수는 없다.

가능하다면 대표 테이블과 실제와 비슷한 변경량에서 시험하고, 수집 중의 쿼리 시간과 지연을 함께 확인하고 싶다.

## 커서의 의미와 변경 이력을 구분하자

커서는 어디까지 읽었는지 판단하는 기준이다. 선택한 컬럼이 새 행과 수정된 행을 어떤 규칙으로 나타내는지 알아야한다.

같은 커서 값을 가진 행이 여러개 있거나 늦게 반영된 변경이 있다면 어떻게 수집되는지 확인해보자. 순서와 경계 조건을 알아야 누락과 중복을 해석할 수 있다.

또한 주기적인 조회와 모든 변경 이벤트의 보관은 다른 요구다. 중간에 여러번 바뀐 행의 최종 상태만 필요한지, 각 변경의 순서까지 필요한지 먼저 정해야한다.

삭제 반영과 재수집, 초기 적재와 증분 처리의 관계도 확인할 부분이다. 도구가 지원하는 기능과 현재 소스가 제공할 수 있는 정보를 함께 봐야겠다.

테스트 데이터는 의도적으로 경계를 만들면 좋겠다. 같은 시각을 가진 두 행을 넣고 한 행만 수정한 경우, 조회 직후 늦게 커밋한 경우, 수집한 행을 삭제한 경우를 따로 비교하는것이다. 이때 기대하는 대상 상태를 먼저 적어두면 실제 도구의 동작과 우리 요구를 구분할 수 있다.

커서 값이 변하지 않는 수정도 중요한 사례다. 애플리케이션의 갱신 코드가 특정 경로에서 수정 시각을 바꾸지 않는다면 조회 조건이 변경을 알아채지 못할 수 있다. 도구 설정만 보는 대신 쓰기 경로의 규칙까지 같이 확인해야겠다.

초기 적재와 증분 수집이 만나는 구간에서는 동시에 발생한 변경을 어떻게 다루는지도 볼 수 있다. 재시작 후의 결과를 원본과 대조할때는 테스트를 위해 고정한 시점이나 비교 범위를 남겨야한다. 계속 변하는 두 테이블을 서로 다른 시점에 조회하면 정상 동작도 오류처럼 보일 수 있기 때문이다.

## 재시작과 데이터 대조를 포함해보자

작업이 중간에 실패했을때 어느 지점부터 이어가는지와 이미 수집한 행을 어떻게 처리하는지 확인해야한다. 정상 실행 한번만으로 운영의 반복 가능성을 알기 어렵다.

대상 데이터의 행 수뿐 아니라 중요한 키와 값, 갱신 시점도 비교하면 좋겠다. 행 수가 같아도 오래된 값이나 잘못된 중복이 남아있을 수 있기 때문이다.

CDC를 설정하지 않아도 된다는 장점은 분명한 선택 기준이 될 수 있다. 다만 우리 데이터의 변경 의미와 지연 요구에 맞는지는 별도로 비교하고 싶다.

# 5. 개발 도구 — PR에서 테스트 커버리지를 볼 수 있다

5월 26일 [GitHub PR 커버리지 표시](https://github.blog/changelog/2026-05-26-code-coverage-in-pull-requests-is-now-in-public-preview/)가 공개 프리뷰로 나왔다. 기존 CI가 생성한 Cobertura 리포트를 올려 PR에서 전체 커버리지 정보를 확인하는 기능이다.

GitHub Code Quality의 제공 요금제와 Preview 조건을 확인해야한다. 모든 저장소에서 아무 설정 없이 자동으로 수집되는 지표로 이해하면 안되겠다.

## 커버리지는 실행된 코드에 대한 정보다

높은 커버리지는 어떤 코드가 테스트에서 실행됐는지 이해하는데 도움이 된다. 하지만 실행했다는 사실만으로 동작을 충분히 검증했다는 의미는 아니다.

함수를 호출해도 결과를 확인하는 assertion이 약할 수 있고, 정상 입력만 반복했을 수도 있다. 중요한 오류와 경계 조건을 시험하는지가 함께 필요하다.

```text
테스트 리뷰에서 같이 볼것
실행한 코드 + 확인한 결과 + 실패 조건 + 요구사항과의 연결
```

예를 들어 권한 검사의 정상 경로만 실행하면 코드 줄은 커버될 수 있다. 권한이 없는 사용자가 거절되는지도 확인해야 실제 요구를 시험했다고 말할 수 있다.

따라서 커버리지 수치는 리뷰를 시작할 단서로 보고싶다. 수치가 변한 이유와 새 기능의 테스트가 어떤 동작을 확인하는지 함께 살펴보는것이다.

## 리포트가 어느 코드에서 나왔는지 확인하자

PR에 표시할 수치가 유용하려면 현재 변경의 테스트 결과와 연결되어야한다. 다른 커밋이나 이전 실행의 리포트를 올리면 숫자는 있어도 검토할 근거가 맞지 않는다.

모노레포와 여러 테스트 작업이 있는 구성에서는 리포트의 범위와 합치는 방법도 확인해야한다. 일부 패키지의 결과만으로 전체 저장소를 평가하지 않도록 하는것이다.

생성 코드와 제외한 파일, 테스트 종류에 따라 분모가 달라질 수 있다. 같은 기준으로 비교해야 변화의 의미를 알 수 있다.

정적 분석과 커버리지, 실제 사용자 흐름의 검증도 각각 다른 정보를 제공한다. 하나의 지표가 다른 검증을 전부 대신하는것으로 사용하지 않는게 좋겠다.

# 6. 이번주에는 기본값과 지표의 의미를 같이 적자

이번주 소식은 모두 편의 기능을 제공하지만 설정과 결과의 의미를 이해해야 제대로 사용할 수 있다. 모델의 성능과 실행 분할, 신원과 권한, 캐시와 보존, 수집과 변경 이력, 커버리지와 검증은 각각 구분할 부분이다.

| 선택 | 함께 남겨둘 기준 |
| --- | --- |
| 모델·워크플로 | 시작 코드와 완료 조건, 통합 검증 |
| 단기 인증 | 신뢰할 실행과 연결된 권한 |
| 캐시 | 요청 구성과 보존 값, 실제 재사용 |
| 데이터 수집 | 커서와 변경의 의미, 재시작·대조 |
| 커버리지 | 리포트의 코드·범위와 검증한 동작 |

새 기능을 사용하기 전에 작은 기준 사례를 남기면 변경의 효과를 설명하기 쉽다. 성공한 결과만 모으기보다 실패했거나 아직 확인하지 못한 조건도 함께 기록하면 좋겠다.

# 마무리

이번주는 Opus 4.8의 성능 개선과 함께 API 인증·캐시, 데이터 수집과 테스트 검토 같은 운영 요소가 넓어졌다. 새 모델을 잘 쓰는 일과 요청의 조건을 정확히 관리하는 일이 가까워지고 있다.

WIF는 신뢰와 권한을, 캐시는 재사용과 보존을 함께 확인하면 좋겠다. 쿼리 기반 수집과 PR 커버리지도 편리한 표시 뒤에 어떤 데이터와 기준이 있는지 살펴봐야겠다.

개인적으로는 이번주에 생략한 설정의 기본값부터 다시 읽어보려고 한다. 따로 값을 적지 않았다는 사실도 현재 도구의 정책을 선택하고 있는것이라는 점을 잊지 말아야겠다..


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

독자의 메모