[2026.04.03 주간 개발 트렌드] Gemma 4와 GitHub Actions 실행·인증 관리

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

# 이번주는 새 버전의 도입과 운영 패치를 나눠봐야겠다

3월 마지막 주에는 TypeScript 6.0 정식 버전과 Node.js 보안 릴리스가 나왔다. Spring Boot의 마일스톤도 다시 업데이트됐고, GitHub에서는 Runner 이미지와 Agent 작업의 가시성에 변화가 생겼다.

새로운 버전을 시험하는 일과 지금 운영중인 런타임을 패치하는 일은 우선순위가 다를 수 있다. 이번주에는 기능의 크기보다 현재 서비스에 어떤 영향을 주는지부터 보고싶다.

3월 23일부터 27일까지의 내용을 다섯가지로 나눠보았다.

| 분야 | 이번주 소식 | 확인할 부분 |
| --- | --- | --- |
| TypeScript | 6.0 정식 출시 | 기본 설정과 폐기 예정 옵션 |
| Runtime·보안 | Node.js 보안 패치 | 실제 실행 버전과 영향 경로 |
| Backend | Spring Boot 4.1 M4 | M3에서 달라진 구성과 회귀 수정 |
| CI | Runner 사용자 정의 이미지 GA | 환경의 표준화와 갱신 책임 |
| 개발 관리 | Issues·Projects의 Agent 상태 | 진행과 검토, 최종 완료의 구분 |

개인적으로는 버전 숫자가 올라갔다는 사실보다 적용 후 무엇을 확인해야 끝났다고 말할 수 있는지가 더 중요하게 느껴지는 주다.

# 1. TypeScript — 6.0이 정식으로 나왔다

3월 23일 [TypeScript 6.0](https://devblogs.microsoft.com/typescript/announcing-typescript-6-0/)이 정식 출시됐다. 현재 JavaScript 기반 구현의 마지막 세대로 의도된 릴리스이며, 앞으로의 Go 기반 TypeScript 7을 준비하는 연결 단계다.

이번주에 정식 출시된것은 6.0이다. 6.0 자체를 네이티브 컴파일러로 이해하면 안되겠다. RC에서 확인한 프로젝트도 정식 버전으로 다시 검증할 시점이 됐다.

## 타입 검사와 실제 런타임의 역할을 구분하자

6.0에는 `es2025` 타깃과 라이브러리 설정, Temporal 관련 타입 등이 들어간다. 여기서 타입이 제공되는것과 실행 환경에 해당 API가 존재하는것은 다르다.

코드가 타입 검사를 통과해도 런타임이 API를 지원하지 않으면 실행할 수 없다. 브라우저와 서버, 테스트 환경이 서로 다른 버전을 쓰는 프로젝트라면 각각 확인해야한다.

```text
새 API를 사용하기 전의 확인
타입 선언 → 출력 코드 → 런타임 지원 → 실제 실행
```

타깃을 올리는것도 같은 관점으로 볼 수 있다. 컴파일러가 어떤 문법을 남길지와 사용자 환경이 그 문법을 실행할 수 있는지를 연결해야한다.

예를 들어 서버의 Node 버전만 확인하고 브라우저 지원 범위를 놓치면 일부 사용자에게만 문제가 생길 수 있다. 빌드 도구가 별도로 변환하는 부분이 있는지도 함께 봐야겠다.

## 암묵적인 설정을 의도적인 선택으로 바꾸자

`strict`와 `types`, `rootDir` 기본값 변화, `baseUrl` 등 폐기 예정 설정은 기존 프로젝트에서 확인할 부분이다. 설정 파일이 그대로여도 컴파일러의 해석은 달라질 수 있다.

오류가 생기면 먼저 종류를 나눠보자. 실제 코드의 타입 문제가 드러난것인지, 전역 타입을 명시해야하는지, 포함 파일과 출력 경로가 달라진것인지에 따라 수정 방법이 다르다.

| 증상 | 먼저 확인할 조건 |
| --- | --- |
| 전역 이름을 찾지 못함 | 필요한 타입 패키지와 `types` |
| 출력 위치가 달라짐 | `rootDir`와 포함한 파일의 범위 |
| 모듈을 찾지 못함 | 모듈 해석과 실제 실행 환경 |
| 추론 결과가 달라짐 | 공개 계약과 명시적인 타입의 필요성 |

모든 오류를 타입 단언으로 덮으면 설정의 문제를 코드 전체로 퍼뜨릴 수 있다. 먼저 어떤 규칙이 달라졌는지 이해하고 필요한 범위만 수정하는게 좋겠다.

## 라이브러리는 소비하는 쪽까지 확인하자

애플리케이션 내부에서 타입 검사가 통과하는것과 배포한 패키지의 타입을 다른 프로젝트가 읽을 수 있는것은 다르다. 선언 파일과 export 경로를 함께 확인해야한다.

작은 소비자 프로젝트에서 실제 패키지 결과물을 설치해보면 저장소의 경로 별칭에만 의존한 타입을 찾기 쉽다. 소스 파일을 직접 참조하는 테스트와 다른 조건이기 때문이다.

모노레포라면 루트 설정과 패키지별 설정의 관계도 살펴보자. 일부 패키지만 다른 컴파일러를 사용하거나 공유 설정을 다르게 해석하면 로컬과 CI의 차이가 커질 수 있다.

이번 정식 버전의 도입은 다음 컴파일러로 가기 전 현재 설정의 의미를 정리하는 기회라고 생각한다. 경고만 없애기보다 실행과 배포까지 연결되는 규칙을 남겨두면 좋겠다.

# 2. Runtime·보안 — Node.js는 운영 버전부터 확인하자

3월 24일 [Node.js 보안 릴리스](https://nodejs.org/en/blog/vulnerability/march-2026-security-releases)가 20·22·24·25 계열에 제공됐다. TLS 오류 처리와 HTTP 헤더, HTTP/2 메모리 누수, 권한 모델 등 여러 경로의 문제가 수정됐다.

같은 Node 계열을 사용해도 모든 취약점의 영향 조건이 같은것은 아니다. 공지의 대상 버전과 기능을 현재 서비스의 실행 경로에 맞춰 확인해야한다.

## 개발 컴퓨터의 버전과 운영 프로세스는 다를 수 있다

로컬에서 `node --version`을 확인했다고 운영 런타임까지 확인한것은 아니다. 컨테이너 이미지와 CI, 서버리스 플랫폼, 장기 실행 서버가 각각 다른 버전을 사용할 수 있다.

배포 문서에 Node 22라고 적혀있어도 실제 패치 버전은 인스턴스마다 다를 수 있다. 실행중인 이미지와 프로세스의 버전을 확인해야 적용 대상을 정할 수 있다.

```text
런타임 패치에서 볼 연결
기반 이미지 → 빌드 결과 → 배포 이미지 → 실행중인 프로세스
```

이미지를 다시 만들었어도 기존 인스턴스가 계속 살아있을 수 있다. 새 배포가 전체 인스턴스에 반영됐는지와 이전 프로세스가 남아있는지도 확인해야겠다.

직접 관리하지 않는 실행 환경이라면 플랫폼이 제공하는 런타임과 패치 정책을 살펴보면 된다. package.json의 버전 범위와 실제 제공되는 런타임이 같은 의미는 아니다.

## HTTP와 TLS의 실제 종료 위치를 확인하자

서비스 앞에 프록시가 있다고 모든 프로토콜 관련 문제가 자동으로 무관해지는것은 아니다. 어떤 연결을 프록시가 처리하고 어떤 요청이 Node까지 도달하는지 확인해야한다.

예를 들어 TLS를 어느 계층에서 종료하는지, 내부 통신에서 HTTP/2를 사용하는지, 헤더를 애플리케이션이 어떤 방식으로 읽는지에 따라 관련 경로가 달라질 수 있다.

이때 확인할것은 공격 요청을 운영에 보내보는 일이 아니다. 구성과 코드, 공식 영향 조건을 대조하고 필요한 검증은 격리된 환경에서 수행하는 방식이 좋겠다.

권한 모델을 사용하는 작업은 별도로 살펴봐야한다. 프로세스가 어떤 플래그로 시작되고 실제로 어떤 접근을 허용하는지 알아야 공지와 연결할 수 있다.

## 패치 후에는 연결과 장기 동작을 함께 보자

업데이트 후 서버가 시작됐다는 사실은 첫 확인이다. 이후 주요 요청과 외부 연결, 오류 처리와 장시간 동작을 살펴봐야한다.

HTTP 연결과 재사용, 스트리밍과 취소, 서버 종료 과정처럼 런타임의 역할이 드러나는 경로를 골라볼 수 있다. 패키지 설치 성공만으로 실행 호환성을 설명하기 어렵다.

메모리와 재시작 횟수, 요청 실패율은 정상 상태와 비교하면 좋겠다. 한순간의 정상 응답만으로 장기 실행의 문제가 없는지 판단할 수는 없기 때문이다.

운영 기록에는 적용한 패치 버전과 배포 범위, 확인한 경로를 남겨두고 싶다. 다음 보안 공지가 나왔을때도 어느 인스턴스가 어떤 상태인지 찾기 쉬워진다.

# 3. Backend — Spring Boot M4는 프리릴리스의 변경 가능성을 보여준다

3월 26일 [Spring Boot 4.1.0-M4](https://spring.io/blog/2026/03/26/spring-boot-4-1-0-M4-available-now/)가 공개됐다. M3에 들어간 Rabbit·AMQP 변경 일부를 되돌리고, `application.properties`와 `application.yaml` 처리의 회귀 문제를 수정했다.

지난주 새 기능으로 소개된 내용도 마일스톤 사이에서 달라질 수 있다는 사례다. 이번주 기준 M4 역시 정식 4.1 릴리스가 아니다.

## M3에서 바꾼 의존성을 그대로 유지해도 되는지 보자

새 마일스톤을 시험하면서 starter 구성을 바꿨다면 M4 안내에 맞춰 다시 비교해야한다. 버전 숫자만 올리고 의존성은 이전 실험 상태를 유지하면 의도하지 않은 조합이 될 수 있다.

현재 프로젝트의 dependency tree와 자동 설정 결과를 함께 보면 좋겠다. 직접 추가한 의존성과 starter가 가져오는 의존성을 구분해야 무엇을 되돌릴지 판단할 수 있다.

메시징 기능에서는 애플리케이션 시작 외에도 연결과 소비, 실패 처리와 재연결을 확인해야한다. 샘플 메시지를 한번 보냈다고 운영의 동작 범위가 모두 확인되는것은 아니다.

```text
마일스톤 비교 기록
변경한 의존성 → 자동 설정 → 연결 → 메시지 처리 → 실패 복구
```

설정 이름과 기본값의 차이는 테스트 환경에서 먼저 드러나게 하는 편이 좋겠다. 코드 수정 없이도 실행 결과가 달라질 수 있는 영역이기 때문이다.

## 설정 파일은 프로파일 조합까지 확인하자

설정 처리의 회귀 수정은 기본 파일 하나만 사용하는 프로젝트와 여러 프로파일을 결합하는 프로젝트에서 확인 범위가 다를 수 있다.

개발과 테스트, 운영에서 어떤 파일이 선택되고 어떤 값이 최종 적용되는지 살펴보자. 환경 변수와 외부 설정이 덮어쓰는 순서도 실제 실행 조건이다.

민감한 값을 로그에 출력할 필요는 없다. 활성화된 프로파일과 기능의 상태, 연결 대상의 식별 가능한 비밀이 아닌 정보를 통해 기대한 설정이 적용됐는지 확인할 수 있다.

개인적으로는 프리릴리스의 도입 기록에 기능 설명과 함께 되돌릴 변경도 남겨두고 싶다. 시험 브랜치의 변경을 정식 버전에 그대로 가져가도 되는지 나중에 비교하기 쉬워진다.

# 4. CI — 사용자 정의 Runner 이미지가 GA가 됐다

3월 26일 [GitHub-hosted Runner의 사용자 정의 이미지](https://github.blog/changelog/2026-03-26-custom-images-for-github-hosted-runners-are-now-generally-available/)가 정식 제공됐다. GitHub의 기반 이미지에서 필요한 도구와 의존성, 인증서와 구성을 미리 준비하는 방식이다.

매번 실행할때 같은 도구를 설치하는 시간을 줄이고 환경을 표준화할 수 있다. 다만 현재 계정과 Runner 유형에서 사용할 수 있는 범위는 확인해야겠다.

## 준비 시간을 줄이는만큼 이미지 갱신을 관리해야한다

도구를 미리 설치하면 워크플로의 준비 단계가 짧아질 수 있다. 하지만 설치 절차가 사라진것이라기보다 이미지 생성 단계로 옮겨간것으로 보는게 좋겠다.

이미지 안의 런타임과 빌드 도구도 시간이 지나면 패치가 필요하다. 새 이미지를 언제 만들고 어떤 검증을 거쳐 작업에 적용할지 정해야한다.

```text
환경 표준화의 흐름
기반 이미지 → 도구 설치 → 이미지 검증 → 버전 지정 → CI 실행
```

예를 들어 이번 Node 보안 패치가 Runner 이미지의 런타임에도 관련된다면 기존 이미지를 계속 사용해도 되는지 확인해야한다. 애플리케이션 컨테이너와 CI의 Node는 서로 다른 관리 대상일 수 있다.

이미지를 고정하면 재현성이 좋아질 여지가 있지만 갱신하지 않으면 오래된 환경이 반복된다. 고정할 버전과 갱신 주기를 함께 정하는것이 중요하다.

## 모든 의존성을 이미지에 넣을 필요는 없다

조직 공통 도구와 프로젝트별 의존성은 변경 주기가 다를 수 있다. 자주 바뀌는 패키지까지 모두 이미지에 넣으면 작은 변경마다 이미지 생성과 검증이 필요해진다.

반대로 매번 설치하는 큰 공통 도구는 미리 준비하는 효과가 클 수 있다. 설치 시간과 변경 빈도, 여러 저장소에서 공유하는 범위를 기준으로 나눠보면 좋겠다.

장기 비밀값을 이미지에 넣는 방식은 피하고 실행 시점의 인증과 구분해야한다. 인증서를 미리 준비하는것과 외부 서비스의 자격 증명을 이미지에 보관하는것은 다른 문제다.

실제 절감 효과는 이미지 생성과 보관, 다운로드 시간을 포함해서 비교하고 싶다. 워크플로의 설치 단계만 짧아져도 전체 비용은 다른 구간에서 늘어날 수 있기 때문이다.

# 5. 개발 관리 — Agent의 진행 상태가 이슈와 프로젝트에 보인다

3월 26일 [GitHub Issues·Projects의 Agent 작업 표시](https://github.blog/changelog/2026-03-26-agent-activity-in-github-issues-and-projects/)가 발표됐다. 이슈에 할당한 코딩 Agent의 세션과 상태를 담당자 아래에서 보고 로그로 이동할 수 있다.

프로젝트의 테이블과 보드에서도 연결된 세션을 확인할 수 있다. 작업의 진행을 관리하는 화면과 실제 실행 세션 사이의 거리가 줄어드는 변화다.

## 실행 완료와 이슈 완료는 구분해야한다

Agent가 작업을 마쳤다는 상태와 요구사항이 검토되어 해결됐다는 상태는 다를 수 있다. 코드가 생성됐어도 테스트와 리뷰, 병합이 남아있을 수 있기 때문이다.

진행 표시는 누가 무엇을 기다리는지 파악하는데 도움이 된다. 하지만 완료의 의미는 팀의 작업 흐름에서 정해야한다.

```text
구분할 상태
실행 대기 → 작업중 → 결과 검토 → 수정 반영 → 요구사항 확인
```

검토 대기 상태라면 담당자가 어떤 결과를 확인해야하는지도 연결해두면 좋겠다. 변경 diff와 실행 로그, 테스트 결과와 남은 제약을 볼 수 있어야 검토를 시작하기 쉽다.

여러 세션이 같은 이슈를 처리할때는 어느 결과가 최종 후보인지 구분할 필요가 있다. 이전 시도의 완료 상태가 현재 작업의 완료로 오해되지 않게 해야한다.

## 이슈의 완료 조건이 더 중요해진다

Agent에게 할당할 수 있다고 모호한 요청이 명확한 작업으로 바뀌지는 않는다. 재현 조건과 기대 동작, 변경 가능한 범위가 있어야 결과를 비교할 수 있다.

예를 들어 “검색 오류 수정”보다 어떤 입력에서 어떤 결과가 나오고 무엇을 기대하는지 적는것이 낫겠다. 관련 로그나 테스트가 있으면 시작 위치도 찾기 쉽다.

다만 구현 방법을 모든 줄까지 정해둘 필요는 없다. 지켜야할 계약과 확인 가능한 결과를 주고, 제안한 방법이 그 조건을 만족하는지 검토하는 방식으로 사용할 수 있다.

개인적으로는 Agent의 진행을 더 잘 볼 수 있게 된만큼 결과를 받아들이는 기준도 명확하게 남겨야겠다는 생각이 든다. 상태 표시와 검증 근거가 함께 있어야 관리 화면의 의미가 생기기 때문이다.

# 6. 이번주에는 변경의 목적에 따라 순서를 정하자

운영 Node 패치와 TypeScript 마이그레이션, Spring 마일스톤 평가와 CI 이미지 전환은 성격이 다르다. 모두 한 번의 배포에 넣기보다 현재 영향과 검증 범위에 맞춰 나누면 좋겠다.

운영 런타임은 공지의 영향 조건과 실제 버전을 확인하고 적용 계획을 세운다. TypeScript는 설정과 출력, 배포 결과를 비교하고, Spring M4는 실험 브랜치에서 M3와의 차이를 정리할 수 있다.

CI 이미지는 공통 환경과 갱신 절차를 정한 뒤 작은 저장소에서 시험해보면 좋겠다. Agent 작업 표시는 기존 리뷰 절차와 연결해 실제로 검토 대기가 줄어드는지 확인할 수 있다.

이 변경들이 만나는 지점도 있다. TypeScript를 검사하는 CI의 Node와 실제 서비스의 Node가 다르면 검증 결과를 운영까지 확대하기 어렵다. 버전과 실행 환경을 한곳에서 찾아볼 수 있게 정리하고 싶다.

# 마무리

이번주는 TypeScript 6.0의 정식 출시와 Node.js 보안 패치가 먼저 눈에 들어왔다. 동시에 Spring 마일스톤은 기능 구성이 달라질 수 있음을 보여줬고, GitHub는 실행 환경과 Agent 진행을 관리하는 기능을 넓혔다.

새 버전을 선택하는 일과 현재 시스템을 패치하는 일을 나눠서 진행하면 좋겠다. 각 변경의 목적과 실제 확인한 범위를 남겨야 다음 작업에서도 결과를 믿고 이어갈 수 있다.

개인적으로는 이번주에 운영과 CI의 런타임 버전부터 다시 확인해보려고 한다. 문서에 적힌 버전과 실제 실행중인 버전이 같은지 아는것이 업데이트의 시작인것같다..


[2026.03.27 주간 개발 트렌드] TypeScript 6과 Node.js 패치, CI 환경 표준화

독자의 메모