[2026.04.10 주간 개발 트렌드] AI 보안 연구와 PostgreSQL 운영 자동화

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

# 이번주는 직접 실행하고 관리하는 범위가 넓어졌다

4월 첫 주에는 Gemma 4 오픈 모델과 GitHub Actions의 실행·인증 관련 업데이트가 나왔다. 모델을 자체 환경에서 실행하는 선택지와 CI에서 컨테이너와 클라우드 접근을 관리하는 방법이 함께 넓어진 주다.

도구가 더 많은 설정을 제공하면 선택의 폭도 커진다. 동시에 어떤 설정을 누가 바꾸고, 실제 실행 결과가 기대와 같은지 확인할 기준도 필요해진다.

3월 30일부터 4월 3일까지의 내용을 세가지로 나눠보았다.

| 분야 | 이번주 소식 | 구분해서 볼 부분 |
| --- | --- | --- |
| AI | Gemma 4 오픈 모델 | 모델 선택과 자체 추론 환경 운영 |
| CI·컨테이너 | 서비스 컨테이너 시작 설정 | 이미지의 기본 동작과 워크플로 재정의 |
| CI·인증 | OIDC 사용자 정의 속성 GA | 토큰의 정보와 클라우드의 신뢰 정책 |

이번주에는 기능이 추가됐다는 설명에서 조금 더 들어가서, 우리가 직접 관리하게 되는 부분을 살펴보려고 한다.

# 1. AI — Gemma 4는 자체 실행의 선택지를 넓혔다

4월 2일 Google이 [Gemma 4](https://blog.google/innovation-and-ai/technology/developers-tools/gemma-4/)를 공개했다. 추론과 코딩, Agent 작업을 강조하는 오픈 모델군이며 Apache 2.0 라이선스로 제공된다.

출시 구성은 E2B와 E4B, 26B MoE와 31B Dense로 나뉜다. 같은 Gemma 4라는 이름 안에서도 실행 환경과 작업의 요구에 맞춰 선택할 모델이 달라진다.

## 오픈 모델과 관리형 API는 담당하는 범위가 다르다

관리형 API에서는 요청을 보내고 결과를 받는 인터페이스를 먼저 사용하게 된다. 자체 실행에서는 모델을 내려받는 단계 이후의 추론 서버와 자원, 배포와 관측도 직접 구성할 수 있다.

이 차이는 장단점을 한줄로 정하기 어렵다. 데이터가 처리되는 위치를 직접 정하고 특정 작업에 맞춰 조정할 수 있는 대신, 운영 상태와 성능도 설명해야하기 때문이다.

```text
자체 실행에서 연결할 요소
모델 파일 → 추론 엔진 → 서비스 API → 작업 처리 → 관측과 갱신
```

모델이 공개됐다는 사실과 바로 서비스 가능한 시스템이 준비됐다는 사실은 다르다. 어떤 엔진과 형식으로 실행하고 어떤 요청을 받을지 정해야한다.

예를 들어 사내 문서를 요약하는 기능이라면 문서를 읽을 권한과 입력 크기, 실패한 요청의 처리, 결과를 저장할 위치가 필요하다. 모델을 로컬에서 실행하는것만으로 이 규칙이 자동으로 생기지는 않는다.

개인적으로는 오픈 모델의 의미를 단순히 호출료가 없어진다는 관점보다 실행과 데이터의 경계를 선택할 수 있다는 관점에서 보고싶다.

## 모델 크기만으로 실제 메모리를 계산하면 부족하다

실행 가능한 하드웨어를 볼때 파라미터 수와 가중치의 저장 형식이 중요한 출발점이다. 하지만 가중치 파일만 메모리에 올라가는것은 아니다.

입력 문맥과 동시 요청, 추론 엔진의 버퍼와 실행 방식에 따라 추가 자원이 필요하다. 같은 모델이라도 짧은 요청 하나와 긴 요청 여러개는 다른 환경을 요구할 수 있다.

예를 들어 31B개의 가중치를 각각 2바이트로 저장한다고 단순 계산하면 원시 값만 약 62GB다. 이 숫자는 모델 전체의 실제 실행 메모리를 보장하는 사양표가 아니다.

```text
추론 환경에서 비교할 자원
가중치 + 문맥 관련 메모리 + 실행 버퍼 + 동시 처리 여유
```

양자화를 사용한다면 메모리와 속도 외에 결과 품질도 비교해야한다. 파일 크기가 줄어드는것과 우리 작업의 정확도가 유지되는것은 별도의 확인 대상이다.

작은 샘플이 한번 실행되는지보다 목표 입력 길이와 동시 요청에서 안정적으로 동작하는지 살펴보면 좋겠다. 서비스의 한도는 실제 사용할 조건에서 정해야한다.

## MoE의 활성 크기와 전체 저장 크기도 나눠보자

MoE 모델은 전체 파라미터와 한 번의 처리에 활성화하는 부분을 구분해서 봐야한다. 처리량을 비교하는 숫자와 모델을 보관하고 적재하는데 필요한 자원이 같은 의미는 아니다.

“활성 파라미터가 작다”는 설명만 보고 전체 가중치의 저장과 배포 비용까지 같은 수준이라고 가정하지 않는게 좋겠다. 실제 엔진이 지원하는 배치와 실행 방식도 확인해야한다.

처음에는 팀이 반복하는 작업을 기준으로 작은 모델과 큰 모델을 비교해볼 수 있다. 짧은 추출과 분류, 복잡한 코드 수정과 긴 문서 분석이 요구하는 능력은 다를 수 있기 때문이다.

공개 벤치마크 순위는 방향을 이해하는 자료로 보고, 도입 판단은 같은 입력과 같은 출력 기준에서 해보고 싶다. 한국어 문서와 코드, 도구 호출처럼 실제 사용할 자료를 포함하는것이 좋겠다.

# 2. AI 운영 — 자체 실행의 완료 기준을 미리 정해두자

오픈 모델을 서비스에 넣는 과정에서는 모델 파일과 실행 설정을 함께 버전으로 관리하는 편이 좋겠다. 모델 이름만 남기면 같은 결과를 재현하기 어렵다.

어떤 체크포인트와 형식을 사용했는지, 어떤 추론 엔진과 주요 옵션을 적용했는지 알아야한다. 출력의 차이가 모델의 변화인지 실행 조건의 변화인지 구분할 수 있기 때문이다.

## 첫 토큰 속도와 전체 작업 시간을 나눠보자

사용자가 보는 대기 시간에는 요청 대기와 입력 처리, 출력 생성이 함께 들어간다. 토큰이 생성되기 시작한 뒤의 속도만으로 전체 경험을 설명하기 어렵다.

짧은 응답을 많이 처리하는 서비스와 긴 문서를 읽는 서비스는 병목도 다를 수 있다. 입력 길이와 출력 길이, 동시 요청 수를 나눠서 비교하면 좋겠다.

| 확인 항목 | 알고 싶은 내용 |
| --- | --- |
| 요청 대기 | 자원이 부족할때 얼마나 기다리는가? |
| 입력 처리 | 긴 문맥이 시작 시간에 어떤 영향을 주는가? |
| 출력 생성 | 필요한 답변 길이에서 얼마나 걸리는가? |
| 동시 처리 | 요청이 겹쳐도 지연과 오류가 허용 범위인가? |
| 취소와 실패 | 중단한 작업의 자원이 회수되는가? |

출력이 빨라도 실제 작업을 여러번 수정해야한다면 완료 시간은 길어질 수 있다. 속도와 함께 필요한 결과를 얻기까지의 반복 횟수를 남겨두고 싶다.

## 기능 지원과 실행 권한은 다르다

Gemma 4는 함수 호출과 구조화된 출력 같은 Agent 관련 능력도 소개했다. 모델이 도구 호출 형식을 생성하는것과 실제 외부 도구를 실행하는 권한은 구분해야한다.

함수의 인자를 검사하고 현재 사용자의 범위에 맞춰 실행하는 부분은 애플리케이션이 담당한다. 모델이 자체 환경에 있다고 이 검사가 필요없어지는것은 아니다.

예를 들어 파일을 요약하는 도구와 파일을 수정하는 도구를 같은 권한으로 취급할 필요는 없다. 작업에 필요한 기능을 구분해 제공하면 검증할 범위도 줄어든다.

실행 결과에는 성공과 실패, 자료가 없는 상태를 분리해 담으면 좋겠다. 빈 결과가 무엇을 의미하는지 알아야 모델이 다음 작업을 정확히 선택할 수 있다.

## 파인튜닝 전에 현재 입력과 검색을 먼저 보자

자체 조정이 가능한 모델이라고 모든 문제의 첫 해결책이 파인튜닝일 필요는 없다. 필요한 사내 자료를 제공하지 않았거나 도구 설명이 모호한 문제일 수도 있기 때문이다.

우선 실패한 사례를 입력과 출력, 기대 결과로 묶어보자. 지식이 부족한것인지, 형식을 지키지 못한것인지, 여러 제약을 동시에 유지하지 못한것인지 구분하면 대응이 달라진다.

자료를 검색해 제공하는 방법과 프롬프트 정리, 모델 조정은 각각 해결하는 문제가 다를 수 있다. 기준 데이터 없이 여러 방법을 동시에 바꾸면 무엇이 도움이 됐는지 알기 어렵다.

변경 뒤에는 원래 잘하던 작업도 다시 확인해야겠다. 특정 업무의 형식이 좋아졌어도 다른 입력에서 결과가 나빠질 수 있으니 같은 평가 묶음으로 비교하는 편이 낫겠다.

## 서비스가 받을 입력의 한도를 정하자

모델의 최대 문맥과 서비스에서 허용할 입력 길이는 꼭 같을 필요가 없다. 긴 요청 하나가 다른 사용자의 대기 시간을 크게 늘릴 수 있기 때문이다.

문서 수와 파일 크기, 출력 길이와 동시 작업 수를 실제 자원에 맞춰 정해보자. 한도를 넘은 요청은 조각으로 나눌지, 별도 비동기 작업으로 처리할지 선택할 수 있다.

사용자에게는 요청이 접수됐는지와 아직 처리중인지, 실패했다면 어떤 입력을 줄이면 되는지 알려주면 좋겠다. 추론 서버의 기술적인 오류를 그대로 보여주는것보다 다음 행동을 안내하는 결과가 필요하다.

# 3. CI·컨테이너 — 시작 명령을 YAML에서 재정의할 수 있다

4월 2일 [GitHub Actions 업데이트](https://github.blog/changelog/2026-04-02-github-actions-early-april-2026-updates/)에 서비스 컨테이너의 `entrypoint`와 `command` 재정의가 추가됐다. 이미지의 기본 시작 설정을 워크플로 YAML에서 조정할 수 있다.

테스트용 DB나 캐시 서비스의 시작 옵션을 바꾸기 위해 별도 이미지나 우회 스크립트를 관리하던 구성을 살펴볼만한 변화다.

## 이미지의 기본 동작과 추가 옵션을 구분하자

컨테이너의 시작 설정을 바꾸면 원하는 프로세스 옵션을 전달하기 쉬워진다. 하지만 이미지가 기본으로 수행하던 초기화와 종료 처리가 그대로 유지되는지도 확인해야한다.

예를 들어 데이터 디렉터리를 준비하거나 환경 변수를 해석하는 초기화 과정이 있다면 새 설정에서 같은 경로가 실행되는지 살펴보는것이다.

```text
서비스 컨테이너의 준비
이미지 선택 → 시작 설정 → 초기화 → 서비스 응답 → 테스트 실행
```

변경 목적이 옵션 하나를 전달하는것인지, 시작 프로그램 자체를 바꾸는것인지 먼저 정하면 좋겠다. 필요 이상으로 기본 동작을 교체하면 관리해야할 부분이 늘어날 수 있다.

워크플로에 설정이 모이는것은 읽기 쉽다는 장점이 있다. 다만 같은 설정이 여러 저장소에 복사되면 이후 갱신도 반복되므로 공통화할 범위도 함께 생각해야겠다.

## 프로세스가 실행됐다고 테스트 준비가 끝난것은 아니다

컨테이너가 시작된 시점과 실제 요청을 받을 수 있는 시점은 다를 수 있다. 시작 옵션을 바꾼 뒤에는 준비 상태를 확인하는 조건도 같이 봐야한다.

고정된 몇초를 기다리는 방식만 사용하면 머신과 데이터 상태에 따라 불안정해질 수 있다. 서비스가 기대한 응답을 반환하는지 확인하는 기준이 있으면 좋겠다.

DB라면 포트가 열렸는지와 테스트에 필요한 데이터·스키마가 준비됐는지도 구분할 수 있다. 연결은 가능하지만 초기화가 끝나지 않은 상태에서 테스트가 시작되는 경우를 피해야하기 때문이다.

실패했을때는 애플리케이션 테스트 로그와 컨테이너 시작 로그를 함께 남기면 원인을 좁히기 쉽다. 테스트 코드가 틀린것인지 의존 서비스가 준비되지 않은것인지 구분하는것이다.

## 로컬과 CI가 같은 조건인지 비교하자

새 키의 동작은 Docker Compose와 익숙한 이름을 사용하도록 안내됐다. 그래도 로컬 Compose 파일과 CI YAML이 자동으로 같은 구성을 공유하는것은 아니다.

이미지 태그와 시작 옵션, 포트와 환경 변수, 초기 데이터의 차이를 비교해야한다. 같은 DB 제품을 쓴다는 사실만으로 같은 테스트 조건이라고 볼 수는 없다.

별도 이미지를 없앨 수 있다면 제거 전에 그 이미지가 수행하던 역할을 목록으로 남겨보자. 시작 옵션 외에 인증서나 추가 도구, 파일을 포함하고 있었다면 단순히 명령만 옮겨서는 같아지지 않는다.

개인적으로는 이번 기능으로 우회 설정을 줄일 수 있는지 확인해보고 싶다. 다만 YAML이 짧아졌다는 사실과 테스트 환경이 단순해졌다는 사실은 구분해야겠다.

# 4. CI·인증 — OIDC에 저장소의 분류 정보를 넣을 수 있다

같은 업데이트에서 GitHub Actions OIDC의 저장소 사용자 정의 속성 Claim이 GA가 됐다. 저장소별 속성을 토큰에 포함해 클라우드의 신뢰 정책에서 사용할 수 있다.

저장소 이름을 하나씩 나열하는 방식 외에 팀과 환경 같은 조직의 분류 기준을 접근 정책에 연결할 수 있다는 의미다. 토큰에 정보가 들어가는것과 실제 접근이 허용되는것은 나눠봐야한다.

## 토큰 발급과 클라우드 권한 부여는 다른 단계다

OIDC 토큰은 현재 실행의 신원을 전달하는데 사용된다. 클라우드가 그 토큰을 신뢰하고 어떤 역할을 허용할지는 클라우드 쪽 정책의 판단이다.

```text
Actions 실행
    ↓
저장소 속성을 포함한 OIDC 토큰
    ↓
클라우드 신뢰 정책의 조건 검사
    ↓
허용된 범위의 접근 권한
```

속성이 추가됐다고 클라우드 정책이 자동으로 원하는 범위로 좁아지는것은 아니다. 현재 신뢰 조건과 새 속성의 값이 어떤 의미로 연결되는지 확인해야한다.

또한 저장소의 팀 분류와 실제 배포 환경이 항상 같은 의미는 아닐 수 있다. 같은 팀이 개발·운영 저장소를 함께 관리한다면 속성 하나만으로 모든 권한을 결정하기 어려울 수 있다.

접근 정책에는 조직과 저장소, 실행 조건과 대상 환경의 관계를 함께 검토하면 좋겠다. 속성 기반 분류는 그 기준을 표현하는 하나의 도구로 보는것이다.

## 속성을 바꿀 수 있는 사람도 확인하자

저장소의 속성이 접근 판단에 쓰이면 그 속성을 변경하는 권한도 중요해진다. 단순한 관리용 라벨처럼 생각하고 아무나 값을 바꾸게 두면 정책의 의미가 달라질 수 있다.

예를 들어 운영 접근을 허용하는 분류를 누가 지정하고 어떤 절차로 바꿀지 정해야한다. 속성의 이름과 허용 값, 변경 이력을 함께 관리하면 해석이 분명해진다.

이름이 비슷한 값과 비어있는 값의 처리도 확인할 부분이다. 기본값이 없는 저장소와 새로운 저장소가 생겼을때 접근이 어떻게 결정되는지 알아야한다.

정책을 시험할때는 허용해야하는 사례와 거절해야하는 사례를 함께 보면 좋겠다. 정상 배포 하나가 성공했다는것만으로 조건이 충분히 좁은지 확인하기 어렵다.

## 기존 정책에서 작은 범위부터 전환하자

많은 저장소의 클라우드 역할을 한꺼번에 바꾸면 실패 원인을 찾기 어렵다. 먼저 영향을 설명할 수 있는 작은 범위에서 토큰과 정책의 연결을 확인하는 편이 좋겠다.

토큰 전체를 로그로 남기는 대신 필요한 Claim의 존재와 정책 판단 결과를 안전하게 확인할 수 있는 절차를 사용하면 된다. 실제 자격 증명을 복사해 공유하는 방식은 피해야겠다.

전환 기록에는 어떤 속성으로 어떤 접근을 허용하는지 남겨두면 좋다. 새로운 저장소를 추가하거나 팀이 바뀌었을때 클라우드 권한이 어떻게 달라지는지 설명할 수 있기 때문이다.

## 정책 비교에는 실패해야하는 실행도 넣어보자

운영 권한을 허용할 저장소와 개발 환경에만 접근할 저장소를 준비해 같은 워크플로 조건에서 결과를 비교할 수 있다. 속성이 없는 저장소도 따로 확인하면 기본 처리의 의미가 보인다.

속성을 변경한 뒤 새 실행에서 어떤 판단이 나오는지도 살펴보자. 현재 실행의 상태와 다음에 발급될 신원 정보가 같은 시점의 정보라고 가정하지 않는게 좋겠다.

이런 사례를 작은 정책 검증 기록으로 남겨두면 새로운 분류 값을 추가할때 기존의 허용·거절 범위가 유지되는지 비교하기 쉽다. 정책의 길이보다 실제로 구분하는 조건이 중요하다.

# 5. 이번주에는 관리 책임의 위치를 정리해보자

Gemma 4의 자체 실행과 Actions의 시작 설정, OIDC 속성은 모두 더 직접적인 제어를 제공한다. 제어할 수 있는 범위가 넓어질수록 누가 유지하고 어떤 근거로 바꿀지 정해두면 좋겠다.

| 대상 | 관리할 정보 | 확인할 결과 |
| --- | --- | --- |
| 자체 모델 | 체크포인트·형식·추론 설정 | 품질과 자원, 실제 처리 한도 |
| 서비스 컨테이너 | 이미지·시작 명령·초기화 | 준비 상태와 테스트 재현성 |
| OIDC 속성 | 이름·값·변경 권한 | 허용과 거절의 정책 결과 |

이 정보가 한 사람의 로컬 환경에만 있으면 이후 같은 조건을 재현하기 어렵다. 저장소에서 확인할 수 있는 설정과 운영 기록으로 남겨두는 편이 좋겠다.

새로운 기능을 도입할때도 기존에 무엇을 대체하는지 분명히 해보자. 관리형 API를 자체 모델로 일부 바꾸는지, 커스텀 이미지를 YAML 설정으로 줄이는지, 저장소별 정책을 속성 기준으로 묶는지에 따라 확인 범위가 다르다.

작게 시작하되 끝까지 확인하는 기준을 잡고싶다. 모델이 응답했고 컨테이너가 시작됐고 토큰이 발급됐다는 단계 다음에, 실제 서비스의 목표가 달성됐는지 봐야하기 때문이다.

# 마무리

이번주는 Gemma 4로 오픈 모델의 자체 실행 선택지가 늘었고, GitHub Actions는 컨테이너 시작과 클라우드 신원 정보를 더 세밀하게 관리할 수 있게 됐다.

자체 모델은 성능과 운영 범위를 함께 평가하고, 컨테이너는 초기화와 준비 상태를 확인하면 좋겠다. OIDC 속성은 정보를 넣는것과 권한을 허용하는 정책을 구분해서 적용해야겠다.

개인적으로는 편해진 설정 뒤에 어떤 관리 책임이 옮겨오는지 먼저 적어보려고 한다. 직접 제어할 수 있다는 장점을 오래 유지하려면 그 설정을 설명하고 갱신할 수 있어야하는것같다..


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

독자의 메모