[2026.01.30 주간 개발 트렌드] RSC 보안 패치와 ARM64 CI, Agentic Vision, Bun

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

# 이번주는 요청의 수명과 다시 계산하는 범위를 살펴보자

이번주에는 Kotlin 서버의 요청 처리, 프론트엔드 빌드, 클라우드 규칙 표현식에서 변화가 있었다. 서로 다른 기술이지만 실제로 실행해야하는 작업과 필요한 범위를 더 명확하게 정하는 방향으로 볼 수 있겠다.

1월 19일부터 23일까지의 소식은 다음 세가지다.

| 분야 | 소식 | 확인할 핵심 |
| --- | --- | --- |
| 백엔드 | Ktor 3.4.0 | 문서 생성, 양방향 스트리밍, 요청 취소 |
| 프론트엔드 | Turbopack 증분 계산 설명 | 변경의 영향과 캐시 재사용 |
| 인프라·보안 | Cloudflare 새 표현식 함수 | 해시와 인코딩의 용도와 제공 조건 |

버전이 올라갔다는 소식과 내부 아키텍처를 설명한 글은 구분해서 보면 좋겠다. Ktor는 새 릴리스이고, Turbopack은 기존 빌드 방식을 이해할 수 있는 기술 설명이다.

# 1. 백엔드 — Ktor 3.4.0이 요청 처리 범위를 넓혔다

1월 23일 [Ktor 3.4.0](https://blog.jetbrains.com/kotlin/2026/01/ktor-3-4-0-is-now-available/)이 공개됐다. OpenAPI 생성과 Zstd 압축, OkHttp의 양방향 스트리밍, HTTP 요청 수명과 구조화된 동시성의 연결 등이 개선됐다.

## API 문서를 코드와 가까이 둔다

이번 OpenAPI 생성은 라우팅 트리에 포함된 정보와 컴파일러 플러그인, describe API를 연결하는 방향이다. 코드에서 요청을 처리하는 부분과 문서의 설명을 가까이 관리할 수 있다.

문서를 별도로 수정하는 프로젝트에서는 구현과 설명이 달라지는 문제가 생기기 쉽다. 하지만 코드 가까이에 문서를 둔다고 업무 규칙까지 자동으로 정확하게 설명되는것은 아니다.

예를 들어 주문 취소 API가 있다고 해보자. 문자열을 받는다는 타입 정보와 취소할 수 있는 주문 상태는 서로 다른 계약이다.

```yaml
설명할 계약의 예시:
  요청: 주문 식별자와 취소 사유
  성공: 취소 처리 결과
  실패:
    - 주문을 찾을 수 없음
    - 요청자에게 취소 권한이 없음
    - 이미 출고돼 취소할 수 없음
```

위의 내용은 OpenAPI 문법을 보여주는 코드가 아니라 문서에 담을 의미를 정리한 예시다. 타입과 경로 외에도 실패 조건과 인증, 예시 응답이 있어야 클라이언트가 올바르게 사용할 수 있다.

생성된 문서를 빌드 결과물로 보관하고 변경 전후를 비교하면 좋겠다. 필드가 추가되거나 필수 조건이 바뀌었을때 의도한 변경인지 리뷰할 수 있다.

문서 생성 성공과 API 계약 검증도 나눠보자. 실제 응답이 문서와 맞는지, 오류 응답도 같은 형식인지 확인해야 문서가 사용 가능한 기준이 된다.

## 양방향 스트리밍은 전송 순서를 바꾼다

OkHttp 엔진에서는 HTTP/2 연결의 duplex streaming을 지원한다. 요청 본문을 보내면서 응답도 동시에 받을 수 있는 방식이다.

```text
일반적으로 생각하는 흐름
요청 본문 전송 완료 → 서버 처리 → 응답 수신

양방향 스트리밍
요청 일부 전송 ─────────→ 서버
응답 일부 수신 ←───────── 서버
남은 요청 전송 ─────────→ 서버
```

큰 입력을 단계적으로 처리하거나 입력을 계속 보내면서 결과를 받고싶은 작업에서 검토할 수 있다. 다만 연결 방식과 서버, 중간 프록시의 지원을 같이 확인해야한다.

여기서 WebSocket을 사용한다는 의미로 받아들이면 안된다. HTTP/2 요청과 응답에서 동시에 데이터를 주고받는 동작을 살펴봐야한다.

전송 중 오류가 났을때 어디까지 처리됐는지도 중요하다. 앞부분의 입력은 처리했는데 뒤에서 연결이 끊겼다면 전체를 다시 보낼지, 이어서 보낼지 서비스의 작업 계약이 필요하다.

메모리에 전체 입력을 모아둔 뒤 처리하는 코드라면 연결만 스트리밍으로 바꿔도 기대한 효과가 작을 수 있다. 애플리케이션의 읽기와 처리, 쓰기 흐름까지 살펴보면 좋겠다.

## 압축은 크기와 지연을 함께 비교하자

Zstd 압축 지원도 들어왔다. 이때 압축률만 높게 나오는 설정을 고르는것보다 CPU와 응답 지연, 클라이언트 지원을 같이 확인해야한다.

작은 JSON 응답과 큰 텍스트 응답은 효과가 다를 수 있다. 이미 압축된 파일을 다시 압축하는 작업도 별도로 생각해야한다.

```text
비교할 항목
원본 크기 / 전송 크기 / 압축 CPU / 첫 응답 시간 / 전체 처리 시간
```

중간 프록시가 응답을 모아서 전달한다면 스트리밍의 장점이 줄어들 수도 있다. 압축과 스트리밍을 각각 켰을때, 같이 켰을때의 동작을 나눠서 비교하면 좋겠다.

# 2. 백엔드 — 연결이 끊긴 요청의 작업은 어떻게 끝낼까

이번 Ktor의 HttpRequestLifecycle은 클라이언트 연결이 끊겼을때 진행중인 요청을 취소하는 설정을 제공한다. 발표 기준 지원 엔진은 Netty와 CIO다.

## 요청에 묶인 작업을 정리한다

사용자가 화면을 떠났는데 서버는 오래 걸리는 계산을 계속하는 상황을 생각해보자. 그 결과를 더이상 받을 사람이 없다면 자원을 계속 쓰는것이 불필요할 수 있다.

```text
사용자 요청
    ↓
서버의 요청 코루틴
├── 하위 조회 작업
└── 결과 계산
    ↓
연결 종료 → 요청 취소 → 요청에 연결된 하위 작업 정리
```

구조화된 동시성의 범위 안에서 작업을 연결하면 요청 수명과 하위 작업의 수명을 함께 생각할 수 있다. 반대로 별도 전역 범위에 작업을 띄웠다면 같은 방식으로 정리된다고 가정하면 안된다.

또한 취소가 전달돼도 모든 외부 시스템이 즉시 작업을 멈추는것은 아니다. DB나 외부 API의 취소 지원과 제한 시간, 연결 정리까지 확인해야한다.

취소 예외를 잡아 정상 결과처럼 처리하는 코드도 살펴보면 좋겠다. 요청이 끝났다는 신호와 실제 오류를 구분해야 로그와 지표를 올바르게 읽을 수 있다.

## 완료돼야하는 업무는 별도 작업으로 설계하자

클라이언트가 끊겼다는 이유로 모든 업무를 취소해도 되는것은 아니다. 사용자가 접수한 주문 처리나 장기 보고서 생성은 요청이 사라져도 이어져야할 수 있다.

이런 경우에는 요청 안에서 끝내는 작업과 접수 후 독립적으로 실행하는 작업을 나누는게 좋겠다.

| 작업 성격 | 생각해볼 실행 방식 |
| --- | --- |
| 화면에만 필요한 조회 | 요청 취소와 함께 중단 검토 |
| 아직 접수되지 않은 계산 | 취소와 자원 정리 검토 |
| 접수 완료된 장기 업무 | 작업 식별자와 별도 실행 상태 관리 |

연결이 끊겼다고 이미 완료한 DB 변경까지 자동으로 되돌아가는것도 아니다. 어떤 시점에 업무가 확정됐는지 서비스의 트랜잭션과 상태로 표현해야한다.

따라서 이 기능을 켤때는 취소할 수 있는 요청부터 분류하면 좋겠다. 자원을 줄이는 동작과 사용자가 기대하는 업무 완료가 충돌하지 않아야한다.

# 3. 프론트엔드 — Turbopack은 변경된 계산을 추적한다

1월 20일 Next.js 팀이 [Turbopack의 증분 계산 구조](https://nextjs.org/blog/turbopack-incremental-computation)를 설명했다. 핵심은 이전 결과를 저장하는것과 함께 어떤 입력을 읽었는지 추적해 필요한 계산만 다시 수행하는 구조다.

## 파일 하나와 결과물 하나가 단순하게 연결되지 않는다

프론트엔드 빌드에는 파일 읽기와 파싱, 변환, 의존성 분석, 청크 구성 같은 작업이 있다. 공통 모듈은 여러 페이지에서 사용하고, 하나의 출력 파일에는 여러 입력이 포함될 수 있다.

```text
공통 유틸리티 ─┬→ 화면 A
             └→ 화면 B

화면 A 전용 코드 → 화면 A
```

전용 코드를 바꾸는것과 공통 유틸리티를 바꾸는것은 영향 범위가 다르다. 바뀐 파일만 다시 읽는것만으로 전체 결과를 정확하게 갱신하기는 어렵다.

발표에서는 함수 단위의 계산과 value cell을 통해 실제로 읽은 값의 의존성을 기록하는 구조를 설명한다. 값이 달라지면 영향을 받는 계산을 표시하고 필요한 결과를 다시 만든다.

사용중인 출력이 필요할때 작업을 수행하는 demand-driven 방식도 포함된다. 모든 가능한 페이지의 모든 계산을 매번 같은 우선순위로 끝내는 방식으로 이해하면 안된다.

## 캐시에는 정확성의 조건이 있다

결과가 재사용되려면 그 결과에 영향을 준 입력을 제대로 알아야한다. 소스 파일 외에 설정이나 의존성, 실행 조건이 바뀌었다면 같은 결과를 써도 되는지 판단해야한다.

예를 들어 환경에 따라 생성하는 코드가 있다면 파일 내용만 같은것으로 충분하지 않을 수 있다. 빌드가 읽는 값과 캐시가 추적하는 범위가 맞아야 오래된 결과를 재사용하는 문제를 줄일 수 있다.

캐시를 세밀하게 나누면 저장하고 추적할 정보도 늘어난다. 메모리와 관리 비용이 생기므로 세밀한 캐시가 언제나 공짜 최적화라고 볼 수는 없다.

이번 설명은 이런 구조를 이해할 수 있는 자료다. 프로젝트의 모든 느린 작업을 새로운 설정 하나로 해결하는 릴리스 소식처럼 받아들이기보다는 병목을 해석하는 기준으로 보면 좋겠다.

## 무엇을 수정했는지에 따라 비교하자

성능을 확인한다면 개발 서버의 첫 시작과 반복 시작, 전용 파일 수정과 공통 파일 수정을 나눠보자. 서로 다른 상황의 시간을 하나로 섞으면 어떤 개선인지 설명하기 어렵다.

```text
테스트할 변경
화면 하나의 문구 → 공통 컴포넌트 → 스타일 → 설정 파일
```

시간은 파일 저장부터 서버 로그가 끝날때까지와 실제 브라우저에 반영될때까지를 구분해서 볼 수 있다. 컴파일이 빨라도 데이터 요청이나 브라우저 실행이 느리면 사용 경험은 달라질 수 있다.

캐시가 있는 실행과 없는 실행도 따로 기록하자. 개발자가 재시작하는 상황과 CI에서 처음 빌드하는 상황은 중요한 지표가 다르다.

같은 브랜치와 의존성, 하드웨어 조건에서 결과를 남기면 작은 변경의 영향과 전체 프로젝트 규모의 영향을 나눠보기 쉽겠다.

# 4. 인프라·보안 — Cloudflare에서 해시와 인코딩을 표현한다

1월 22일 [Cloudflare Rulesets의 새 함수](https://developers.cloudflare.com/changelog/post/2026-01-22-sha256-base64-encode-functions/)가 공개됐다. sha256()과 encode_base64()를 규칙 표현식에서 사용할 수 있다.

## 제공 조건부터 구분하자

발표 기준 encode_base64()는 헤더 변환 규칙에서 모든 요금제에 제공된다. sha256()은 별도 권한 활성화가 필요한 Enterprise add-on으로 안내됐다.

따라서 같은 발표에 포함됐다고 두 함수를 어떤 계정에서나 바로 사용할 수 있는것은 아니다. 실제 계정의 기능과 규칙이 적용되는 위치를 먼저 확인해야한다.

요청 속성으로 값을 구성하고 헤더를 변환하는 작업을 엣지에서 표현할 수 있는 범위가 넓어진 변화로 보면 되겠다.

## Base64는 암호화가 아니다

Base64는 데이터를 다른 문자 표현으로 바꾸는 인코딩이다. 값을 감춘 비밀 데이터로 만들어주는 기능이 아니다.

```text
인코딩: 표현을 변환한다
해시: 입력에서 요약값을 계산한다
인증: 누가 만들었는지와 권한을 확인한다
```

세가지 역할을 섞으면 구현이 간단해보여도 의도한 보장이 나오지 않을 수 있다. 민감한 값을 Base64로 바꿔 헤더에 넣었다고 외부에서 읽을 수 없게 되는것은 아니다.

패딩과 URL-safe 형식도 수신 시스템의 기대와 맞춰야한다. 같은 원본을 인코딩해도 표현 규칙이 다르면 비교에 실패할 수 있다.

## SHA-256만으로 요청 인증이 완성되지는 않는다

해시는 입력이 같은지 확인하는 구성 요소로 사용할 수 있다. 하지만 공개된 요청 내용의 해시를 누구나 계산할 수 있다면 그 값만으로 발신자를 증명할 수는 없다.

HMAC이나 공개키 서명처럼 별도의 인증 규격이 필요한 상황에서 일반 해시를 임의로 대체하면 안된다. 사용하는 프로토콜이 정한 입력과 키 처리, 검증 방식을 따라야한다.

요청 속성을 묶는 경우에는 문자열 구성 규칙도 중요하다. 메서드 대소문자와 경로 표현, 쿼리 순서, 인코딩 방식이 달라지면 서버와 엣지가 다른 값을 계산할 수 있다.

```text
송신측과 수신측이 맞춰야할 부분
원본 필드 → 정규화 → 문자열 구성 → 계산 → 전송 표현
```

기존 인증 헤더와 함께 사용한다면 누가 어느 헤더를 신뢰하는지도 정해보자. 클라이언트가 보내는 값과 엣지가 새로 만든 값의 경계를 분명히 해야한다.

## 서버에서 같은 값으로 검증해보자

정상 요청 한개만 확인하지 말고 공백과 한글, 특수문자, 빈 쿼리를 포함한 예시를 준비하면 좋겠다. 문자열 처리의 차이는 이런 경계에서 드러나기 쉽다.

규칙의 미리보기와 실제 원본 서버에서 받은 결과도 비교해야한다. 중간의 다른 규칙이 헤더를 다시 바꾼다면 계산한 값과 전달된 값이 달라질 수 있기 때문이다.

서명을 활용하는 구성이라면 재전송 방지나 유효 시간도 해당 규격에 맞춰 확인해야한다. 새로운 함수가 추가된것과 전체 인증 정책이 완성된것은 다른 이야기다.

# 5. 이번주 변화는 실행 경계로 검증하자

Ktor는 요청이 살아있는 범위, Turbopack은 다시 계산할 범위, Cloudflare는 규칙에서 계산하고 전달하는 범위를 다룬다. 실제 적용에서는 이 경계를 관측할 수 있는지가 중요하다.

| 실험 | 확인할 결과 |
| --- | --- |
| 장기 요청 중 연결 종료 | 하위 작업과 외부 연결이 기대대로 정리되는가 |
| 코드 변경과 재시작 | 필요한 결과가 갱신되고 캐시가 올바른가 |
| 요청 헤더 변환 | 서버가 같은 규칙으로 값을 읽고 검증하는가 |

Ktor에서는 응답을 끝까지 읽는 경우와 중간에 끊는 경우를 나눠보자. 업무가 이미 확정된 뒤 연결이 끊기는 사례도 포함하면 취소와 업무 상태를 구분할 수 있다.

빌드에서는 수정 종류를 바꿔가며 시간과 결과 정확성을 함께 확인하면 좋겠다. 빠르게 반영된 화면이 최신 코드인지까지 봐야 캐시의 효과를 올바르게 판단할 수 있다.

규칙 표현식은 검증용 입력과 예상 결과를 남겨두면 변경 후 비교하기 쉽다. 테스트 요청에 실제 비밀값을 넣을 필요는 없고 동일한 형식의 예시 값으로 구성할 수 있다.

세가지를 한꺼번에 도입하기보다 현재 겪는 문제와 연결되는 항목부터 골라보자. 설정이 적용됐다는것 다음에 어떤 자원이 줄고 어떤 결과가 유지됐는지 확인해야한다.

# 6. 비교 기록은 작업 단계에 맞춰 남기자

새 기능을 적용했는데 좋아진것 같다는 인상만 남으면 이후에 다시 확인하기 어렵다. 이번주 세가지 주제는 각각 다른 시점을 기록하면 비교하기 쉽다.

## 요청은 연결과 업무 완료를 따로 본다

장기 요청이라면 접수, 외부 작업 시작, 연결 종료, 작업 종료를 각각 남길 수 있다. 사용자가 떠난 시점에 실제 자원 사용도 끝나는지 확인하기 위해서다.

```text
request accepted
    ↓
upstream started
    ↓
client disconnected
    ↓
cancellation observed
    ↓
resources released
```

이 흐름은 측정 항목의 예시이며 Ktor가 같은 이름의 이벤트를 자동 제공한다는 뜻은 아니다. 서비스의 로그와 지표에서 연결할 수 있는 항목을 정하면 된다.

취소된 요청을 전부 서버 오류로 집계하면 장애율 해석도 달라질 수 있다. 정상적인 사용자 이탈과 처리 중 실패를 구분해서 기록하는게 좋겠다.

## 빌드는 무엇을 바꿨는지 같이 적는다

측정값 옆에는 캐시 상태와 변경 파일 종류를 남겨보자. 초기 빌드, 캐시가 있는 재시작, 공통 모듈 수정은 서로 다른 사례다.

같은 시간 안에서도 컴파일과 브라우저 반영을 구분하면 개선할 위치가 보인다. 메모리 사용량까지 함께 기록하면 빠른 대신 유지 비용이 커진 경우도 확인할 수 있다.

## 규칙은 입력과 예상 출력을 한쌍으로 둔다

헤더 변환에는 입력 필드와 정규화 방식, 최종 전달값을 같이 기록하면 좋겠다. 한글과 공백이 있는 경로처럼 경계 입력을 포함해서 같은 값을 만드는지 비교하자.

규칙 순서를 바꿨을때도 동일한 입력 묶음을 다시 실행하면 영향을 확인하기 쉽다. 실험에 사용한 예시 값과 운영의 비밀값은 구분해서 관리하면 된다.

이렇게 남긴 기록은 특정 도구에만 쓰이는 자료가 아니다. 이후 프레임워크나 빌드 버전이 바뀌었을때도 같은 동작을 확인할 기준으로 사용할 수 있겠다.

# 마무리

이번주는 서버 요청과 빌드 계산, 엣지 규칙처럼 서로 다른 실행 단계에서 더 구체적인 제어가 가능해지는 변화가 있었다.

개인적으로는 새 기능의 이름보다 언제 시작하고 언제 끝나며 무엇을 다시 사용하는지 설명하는게 중요해보인다. 같은 최적화라는 표현 안에서도 줄이려는 비용이 다르기 때문이다.

우선 우리 서비스에서 취소되지 않는 작업과 반복 계산, 요청 변환 규칙부터 살펴보면 좋겠다. 빠르고 간단한 구성과 올바른 동작을 함께 확인해야겠다..


[2026.01.23 주간 개발 트렌드] Ktor의 요청 처리와 Turbopack, Cloudflare 규칙 개선

독자의 메모