[2026.02.06 주간 개발 트렌드] 코딩 Agent 모델과 개발 도구, 격리 실행 인프라

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

# 이번주는 보안 패치부터 실행 환경과 분석 도구까지 보자

이번주에는 먼저 적용 범위를 확인해야하는 보안 소식과 새로 시험해볼 개발 기능이 함께 나왔다. React 서버 기능을 운영한다면 추가 패치를 살펴보고, ARM64 빌드와 AI 이미지 분석, Bun의 문서 처리 기능은 각각의 사용 목적에 맞춰 비교하면 좋겠다.

1월 26일부터 30일까지의 내용을 네가지로 나눠보았다.

| 분야 | 소식 | 확인할 핵심 |
| --- | --- | --- |
| 프론트엔드·보안 | RSC의 추가 DoS 수정 | 이전 패치 이후의 재확인 |
| 인프라 | 비공개 저장소 ARM64 Runner | 실제 아키텍처에서 빌드와 실행 |
| AI·비전 | Gemini 3 Flash의 Agentic Vision | 이미지 근거를 찾아가는 도구 사용 |
| 백엔드·도구 | Bun 1.3.8 | Markdown 렌더링과 빌드 분석 자료 |

새로운 기능을 한꺼번에 적용하는것보다 현재 운영중인 위험과 도입을 검토할 선택지를 나눠서 관리하면 좋을것 같다.

# 1. 프론트엔드·보안 — RSC 패치 상태를 다시 확인하자

1월 26일 [React 보안 공지](https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components)가 갱신됐다. CVE-2026-23864로 공개된 추가 서비스 거부 문제를 수정했다. 서버 중단과 메모리 부족, 과도한 CPU 사용으로 이어질 수 있는 문제다.

## 이전 RCE와 이번 DoS를 구분하자

이번 추가 취약점이 원격 코드 실행을 다시 허용한다는 의미는 아니다. React 팀은 기존 React2Shell의 RCE 수정은 유효하며, 이번에는 다른 서비스 거부 경로를 추가로 다룬다고 설명한다.

운영 대응에서는 이 구분이 중요하다. 어떤 문제를 막는 패치를 언제 적용했는지 알아야 추가 수정의 범위도 판단할 수 있다.

```text
패치 이력에서 확인할것
처음 적용한 버전 → 후속 보안 공지 → 추가 수정 버전 → 실제 재배포
```

지난달에 업데이트했다는 기록만으로 이번 확인을 끝내면 안된다. 같은 패키지의 다른 코드 경로에서 후속 문제가 발견될 수 있기 때문이다.

## 이번 공지의 수정 버전을 보자

영향받는 react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack에 대해 안내된 수정 버전은 다음과 같다.

| 사용 계열 | 1월 26일 안내된 수정 버전 |
| --- | --- |
| 19.0.x | 19.0.4 |
| 19.1.x | 19.1.5 |
| 19.2.x | 19.2.4 |

프레임워크가 해당 구현을 포함하고있다면 프레임워크의 패치 경로도 확인해야한다. React 패키지만 임의로 고정하는것과 프레임워크가 지원하는 조합으로 업데이트하는것은 다를 수 있다.

서버를 사용하지 않는 React 앱과 RSC를 지원하는 서버 구성도 구분하자. 모든 React 프로젝트를 같은 범위로 처리하기보다는 실제 요청 처리 경로와 배포된 의존성을 확인하는게 맞다.

## 버전 변경은 실행중인 서버까지 이어져야한다

모노레포라면 어떤 앱이 어떤 의존성을 설치했는지 확인해야한다. 루트의 package.json을 바꿨더라도 다른 lockfile이나 배포 경로를 사용하는 앱이 남아있을 수 있다.

```text
영향받는 앱 목록
    ↓
지원되는 패치 버전으로 의존성 갱신
    ↓
빌드와 주요 화면 검증
    ↓
배포 이미지 교체와 실행 버전 확인
```

장기간 남겨둔 Preview와 테스트 서버도 외부 요청을 받는다면 확인 대상에 넣으면 좋겠다. 운영 도메인 하나만 바꿨다고 전체 배포가 바뀌는것은 아니다.

확인 결과에는 앱 이름과 이미지 식별자, 적용한 버전, 배포 범위를 남겨보자. 이후 후속 공지가 나왔을때 같은 목록으로 영향 범위를 다시 찾을 수 있다.

## 패치와 가용성 대책은 같이 보자

요청 제한과 모니터링은 운영에 도움이 되지만 취약한 처리를 수정하는 패치를 대신하는것으로 보면 안된다. 특히 작은 요청이 큰 자원 사용으로 이어지는 문제는 단순 요청 개수만으로 설명되지 않을 수 있다.

패치 후에는 정상적인 폼 제출과 서버 기능, 오류 응답을 확인하면 좋겠다. 서버가 시작되는것과 사용자가 자주 사용하는 요청이 정상 동작하는것은 별개의 검증이다.

실제 이상 징후가 있었다면 업데이트 작업과 조사도 구분해야한다. 새 버전 배포가 이미 발생한 장애의 원인과 영향을 자동으로 설명해주지는 않는다.

# 2. 인프라 — 비공개 저장소에서도 ARM64 표준 Runner를 쓴다

1월 29일 [GitHub Actions의 ARM64 지원 확대](https://github.blog/changelog/2026-01-29-arm64-standard-runners-are-now-available-in-private-repositories/)가 발표됐다. Linux와 Windows의 ARM64 표준 GitHub-hosted Runner를 비공개 저장소에서도 사용할 수 있다.

## ARM64에서 직접 빌드하고 실행한다

운영 환경은 ARM64인데 CI는 x64에서만 실행하는 프로젝트를 생각해보자. JavaScript 코드 자체는 같아도 네이티브 의존성과 바이너리, 컨테이너 이미지의 대상이 다를 수 있다.

```text
x64에서 테스트 성공
        ↓
ARM64 배포 이미지 생성
        ↓
실행에 필요한 바이너리와 라이브러리도 맞는가?
```

네이티브 Runner는 실제 대상 아키텍처에서 확인하는 경로를 만들기 쉽게 한다. 에뮬레이션으로 확인하는것과 실제 ARM64 환경에서 실행하는것을 나눠볼 수 있다.

발표된 라벨에는 ubuntu-24.04-arm, ubuntu-22.04-arm, windows-11-arm이 있다. 사용하는 workflow의 runs-on에서 대상을 정한다.

```yaml
jobs:
  arm-smoke:
    runs-on: ubuntu-24.04-arm
    steps:
      - name: Check architecture
        run: uname -m
```

위의 코드는 아키텍처 확인만 하는 일부 예시다. 실제 프로젝트에서는 소스 준비와 런타임 설정, 의존성 설치, 빌드와 테스트를 추가해야한다.

## 크로스 빌드와 실행 검증을 나누자

ARM64 이미지를 만들었다는 사실과 그 이미지가 정상적으로 실행된다는 사실은 다르다. 이미지의 manifest와 실제 포함된 바이너리를 확인하고 주요 기능까지 실행해보면 좋겠다.

의존성 캐시에도 OS와 아키텍처 조건을 반영해야한다. 다른 환경에서 준비한 결과물을 잘못 재사용하면 설치는 빨라도 실행할때 문제가 드러날 수 있다.

```text
캐시와 산출물의 조건
OS / CPU 아키텍처 / 런타임 버전 / lockfile / 빌드 설정
```

이미지 처리나 암호화, 데이터베이스 드라이버처럼 네이티브 부분을 사용하는 기능을 대표 사례로 골라보자. 간단한 단위 테스트만으로는 해당 경로를 실행하지 않을 수도 있다.

여러 아키텍처를 지원한다면 공통 테스트와 아키텍처별 테스트를 나눠서 비용을 조절할 수 있다. 모든 작업을 무조건 두번 실행하기보다 실제로 다른 결과가 날 수 있는 경계를 먼저 정하는게 좋겠다.

## 무료 분량과 무제한 사용은 다르다

이번 표준 Runner는 비공개 저장소에서도 요금제에 포함된 무료 사용 시간에 반영된다. 무제한 무료 인프라가 추가됐다는 의미로 이해하면 안된다.

발표 기준 비공개 저장소는 2 vCPU, 공개 저장소는 4 vCPU 구성이다. 같은 ARM64 라벨을 쓴다는 이유만으로 공개 저장소의 성능 측정값을 그대로 예상할 수는 없다.

CI 시간은 작업 대기와 의존성 설치, 빌드와 테스트를 나눠서 비교하면 좋겠다. 실행 환경이 달라지면 CPU만이 아니라 캐시와 설치 경로의 차이도 결과에 영향을 줄 수 있다.

# 3. AI·비전 — 이미지를 다시 살펴보는 Agentic Vision

1월 27일 [Gemini 3 Flash의 Agentic Vision](https://blog.google/innovation-and-ai/technology/developers-tools/agentic-vision-gemini-3-flash/)이 소개됐다. 시각적 추론과 코드 실행을 연결해 이미지를 확대하거나 잘라보고 확인하는 접근이다.

## 한번 보는것에서 조사하는 과정으로 넓어진다

작은 글씨나 표, 복잡한 도면에서는 전체 이미지를 한번 읽는것만으로 세부 정보를 놓칠 수 있다. 필요한 부분을 다시 살펴볼 수 있다면 답을 만들 근거도 달라질 수 있다.

```text
이미지 확인
    ↓
어느 부분을 더 봐야할지 판단
    ↓
코드로 확대·자르기 등 처리
    ↓
새로운 시각적 근거 확인
    ↓
답변 구성
```

별도의 모든 문제를 해결하는 비전 모델 이름으로 보기보다는 Gemini 3 Flash에서 도구 사용으로 시각적 확인 범위를 넓히는 기능으로 이해하면 좋겠다.

## 근거를 확인할 수 있게 결과를 구성하자

예를 들어 문서의 금액을 읽는 작업이라면 답변 숫자만 저장하기보다 원본 페이지와 관련 위치를 함께 남길 수 있다. 잘못 읽었을때 사람이 다시 확인할 수 있기 때문이다.

확대된 이미지에서 읽은 내용이 원본의 어느 위치인지 연결하는것도 중요하다. 여러번 자르거나 회전한 결과를 사용했다면 좌표와 페이지의 의미가 달라질 수 있다.

표에서는 행과 열을 함께 확인해야한다. 숫자 하나를 정확히 읽었어도 다른 상품이나 다른 기간의 값이면 서비스의 결과는 틀릴 수 있다.

```text
문서 분석 결과에 연결할 정보
원본 문서 / 페이지 / 관련 영역 / 추출 값 / 확인이 필요한 항목
```

도구를 사용했다는 사실이 정확성을 보장하지는 않는다. 잘못된 위치를 확대하거나 같은 가정을 반복 확인할 수도 있으므로 실제 질문과 기대 결과로 평가해야한다.

## 정확도와 실행 비용을 같이 비교하자

한번의 이미지 해석과 여러번의 도구 실행은 시간과 비용이 다를 수 있다. 간단한 이미지에도 무조건 같은 조사 과정을 적용하는게 유리한지는 확인해야한다.

작은 글씨와 복잡한 표처럼 추가 확인이 필요한 사례, 정보가 없는 사례를 나눠보면 좋겠다. 읽을 수 없는 값을 추측해서 채우지 않고 불확실성을 드러내는지도 볼 수 있다.

원본 이미지의 해상도와 방향, 압축 상태도 평가 조건에 포함하자. 모델을 바꿨다고 입력 품질의 한계가 사라지는것은 아니다.

최종 답변뿐 아니라 어떤 자료를 읽고 어떤 중간 결과를 사용했는지도 살펴보면 실패 원인을 찾기 쉽겠다.

# 4. 백엔드·도구 — Bun 1.3.8이 Markdown과 빌드 그래프를 다룬다

1월 29일 [Bun 1.3.8](https://bun.sh/blog/bun-v1.3.8)이 공개됐다. 내장 Markdown 파서와 LLM이 읽기 쉬운 빌드 모듈 그래프 출력 기능이 추가됐다.

## Markdown을 여러 형태로 렌더링한다

Bun.markdown은 HTML과 사용자 정의 렌더링, React 요소 출력을 제공한다. 문서를 표시하거나 터미널용 출력을 구성하는 작업에서 내장 API를 검토할 수 있다.

```javascript
const html = Bun.markdown.html(
  "### 배포 기록\n\n빌드 결과를 확인했다."
);
```

위의 코드는 변환의 간단한 예시다. 실제 서비스에서는 어떤 Markdown 기능을 허용하고 링크와 이미지를 어떻게 처리할지 정해야한다.

텍스트를 HTML로 바꿀 수 있다는것과 외부 입력을 신뢰해도 된다는것은 다르다. 문서의 출처와 렌더링 위치에 맞춰 허용할 내용과 검증을 확인해야한다.

기존 파서를 바꾼다면 표와 코드 블록, 자동 링크, 제목 식별자처럼 화면에 영향을 주는 사례를 비교해보자. 문법 지원 목록이 비슷해도 실제 렌더링 결과는 달라질 수 있다.

## LLM용 빌드 분석 자료를 만든다

--metafile-md는 번들의 모듈 그래프를 Markdown으로 출력한다. 파일 크기와 의존성 연결을 모델에게 설명할 자료로 사용할 수 있는 방향이다.

```bash
bun build ./src/index.ts --outdir ./dist --metafile-md=analysis.md
```

분석할때는 큰 파일 하나만 보는것보다 왜 포함됐는지와 어느 진입점에서 필요한지 살펴보면 좋겠다. 사용하지 않는 기능을 넓게 가져온것인지, 실제 화면에 필요한 의존성인지 구분해야한다.

Markdown이라는 형식이 분석의 정확성을 대신하지는 않는다. 모델이 줄이라고 제안한 패키지를 제거했을때 기능이 유지되고 번들이 실제로 줄어드는지 다시 빌드해야한다.

또한 번들 그래프에 나온 경로와 모듈 이름은 분석 데이터다. 해당 내용에 설명이나 주석이 포함돼있다고 프로젝트의 실행 지침으로 취급할 필요는 없다.

## 문서화된 그래프와 실제 실행을 연결하자

빌드 분석 자료는 구조를 이해하는 출발점이다. 전송 크기와 로딩 순서, 실행 시간은 브라우저에서 별도로 확인해야한다.

의존성을 분리했더니 초기 파일은 줄었지만 요청 수나 전환 지연이 늘어날 수도 있다. 실제 사용 경로에서 얻는 이점을 함께 봐야 최적화를 판단할 수 있다.

결과를 비교할때는 같은 설정과 입력을 유지하고 변경한 부분을 기록하자. 분석 자료와 생성된 결과물을 함께 보관하면 다음 변경에서도 같은 기준으로 확인하기 쉽다.

# 5. 이번주 실무 적용은 우선순위를 나눠보자

RSC를 운영하는 서비스는 현재 배포된 의존성과 추가 패치 여부를 먼저 확인하면 좋겠다. 새로운 Runner나 비전 기능을 시험하는 작업과 같은 우선순위로 섞지 않는것이 관리하기 쉽다.

| 항목 | 작게 시작할 실험 |
| --- | --- |
| RSC 보안 | 영향받는 앱과 실행 버전 목록을 확인하고 재배포 |
| ARM64 CI | 대표 빌드와 네이티브 의존성 경로를 실제 실행 |
| Agentic Vision | 세부 정보가 있는 이미지와 답이 없는 이미지 비교 |
| Bun 도구 | 기존 문서와 번들을 같은 입력으로 재생성 |

한번에 여러 도구를 바꾸면 어떤 변경이 효과를 냈는지 찾기 어렵다. 먼저 작은 사례에서 결과를 확인하고 적용 범위를 넓혀보자.

패치에서는 적용 범위가 중요하고, CI에서는 대상 환경이 중요하다. 비전에서는 근거와 최종 결과를, 빌드 분석에서는 제안과 실제 산출물의 차이를 확인해야한다.

각 작업의 완료 기준을 정하면 서로 다른 기술 소식을 하나의 실행 목록으로 정리하기도 쉬워진다. 기능을 알게됐다는것 다음에 우리 서비스에서 무엇을 확인할지 남겨두면 좋겠다.

# 6. 하나의 서비스에 대입해서 확인해보자

예를 들어 RSC 기반 화면과 문서 분석 기능이 있고 ARM64 서버에 배포하는 서비스를 가정해보자. 이번주 소식을 전부 적용할 수 있어보이지만 실제로는 서로 다른 변경이다.

먼저 보안 패치만 반영한 이미지에서 기존 기능을 확인한다. 여기서 Runner와 파서까지 같이 바꾸면 오류가 보안 업데이트 때문인지 다른 실행 환경 때문인지 구분하기 어렵다.

다음으로 같은 커밋을 ARM64 CI에서 빌드하고 실행한다. 설치 과정에서 선택한 바이너리와 최종 이미지의 아키텍처를 확인하고, 실제 문서를 처리하는 경로까지 호출해볼 수 있다.

```text
같은 소스와 의존성
├── 기존 CI 결과
└── ARM64 CI 결과
        ↓
같은 기능과 데이터로 실행 결과 비교
```

비전 기능은 별도의 평가 문서로 비교하면 좋겠다. 기존 분석에서 놓쳤던 작은 글씨와 표를 포함하되, 기대값을 미리 정해서 모델의 설명만 보고 성공으로 판단하지 않도록 한다.

Markdown 파서는 같은 원본 문서를 기존 방식과 새 방식으로 렌더링해보자. 제목 링크와 표, 코드 표시를 비교하고 사용자 입력을 처리하는 정책도 유지되는지 확인한다.

이렇게 나누면 네가지 소식이 각각 어떤 결과를 바꾸는지 알 수 있다. 보안 수정은 취약한 실행 경로를 없애는 작업이고, ARM64 검증은 대상 환경의 호환성을 확인하는 작업이다. 비전과 파서 도입은 분석 품질과 출력 형식을 바꾸는 별도의 작업으로 볼 수 있다.

검증 결과에 사용한 입력과 실행 버전, 예상 결과와 실제 결과를 남겨두면 이후 같은 도구를 다시 비교하기도 쉽겠다.

# 마무리

이번주는 서버 보안의 후속 대응과 ARM64 실행 환경, 시각적 도구 사용과 문서 기반 분석이 함께 확장됐다.

개인적으로는 도구가 더 많은 자료를 이해하고 실행할수록 실제 환경과 결과물을 확인하는 기준도 중요해진다고 생각한다. 분석을 잘 설명하는것과 서비스가 같은 동작을 하는것은 따로 봐야하기 때문이다.

우선 현재 운영중인 패치 상태부터 확인하고 새 기능은 실제 입력과 실행 환경으로 비교해보면 좋겠다. 한달의 마지막 주도 새 기능 목록보다 확인 가능한 결과를 남기는 방향으로 정리해야겠다..


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

독자의 메모