RSS Feed of LeeJin's Blog

GitHub 비밀값 탐지 전용 모델 도입: 형식 없는 비밀번호도 잡지만 AI Credits 과금은 따로 봐야 한다

Sun, 11 Oct 2026 00:05:00 GMT

GitHub가 10월 7일 secret scanning에 비밀값 탐지 전용으로 파인튜닝한 모델을 붙였다. 정해진 토큰 형식이 없는 비밀번호처럼 정규식으로는 잡기 어려운 값을, 주변 코드를 읽고 판단해서 찾아낸다. 기존 AI 탐지 비밀번호 알림을 쓰던 곳은 이미 새 모델로 자동 전환됐다. 그런데 같은 발표에 push protection과 Copilot /security-review로 확장되는 기능이 같이 묶여 있고, 이쪽은 AI Credits를 쓴다. 무료로 계속 쓰는 부분과 돈이 나가는 부분을 나눠서 봐야 한다.

새 탐지 모델은 무엇을 더 잡아 주고, 조직에서 켜기 전에 비용과 정책은 어떻게 정리해야 하나?

이 글은 GitHub Changelog의 10월 7일 발표와 10월 5일 탐지 패턴 추가 공지를 읽고 정리했다. AI push protection은 private preview 상태이고 과금 방식도 "앞으로 몇 주 안에" 도입된다고만 적혀 있어서 세부 내용은 바뀔 수 있다.

1. 패턴 탐지와 AI 탐지는 잡는 대상이 다르다

secret scanning은 원래 형식이 정해진 토큰을 찾는 데 강하다. 접두사와 길이, 문자 구성이 정해져 있으면 패턴 하나로 거의 확실하게 잡는다. 10월 5일에도 이런 패턴이 다섯 개 추가됐다.

제공자	토큰 타입
Lovable	`lovable_api_key`
Pydantic	`logfire_token`
Pydantic	`pydantic_ai_gateway_api_key`
Supabase	`supabase_oauth_access_token`
Supabase	`supabase_scoped_personal_access_token`

문제는 비밀번호다. DB 비밀번호나 내부 서비스 계정 비밀번호는 아무 문자열이나 될 수 있어서 패턴으로는 거의 못 잡는다. 이번 모델은 이 빈자리를 노린다. changelog 표현으로는 주변 코드를 읽어서 자격 증명일 가능성이 높은 값을 찾고, 인식 가능한 토큰 형식이 없는 비밀번호도 포함한다. 코드나 문장을 생성하지 않는 분류 전용 모델이라는 점도 따로 적혀 있다.

백엔드 코드에서 떠올려 보면 대략 이런 값들이 대상이 된다.

spring:
  datasource:
    url: jdbc:postgresql://db.internal:5432/orders
    username: orders_app
    password: "<평문 비밀번호>" # 형식은 없지만 문맥상 비밀번호

키 이름이 password이고 DB 접속 설정 안에 있다는 문맥이 판단 근거가 되는 종류다. 위 예시는 설명용으로 값을 비워 둔 것이고, 실제로 어떤 값에서 알림이 뜨는지는 확인해 보지 않았다.

2. 새 모델이 들어가는 세 군데

발표에 나온 적용 범위는 세 곳이다.

적용 위치	하는 일	상태
secret scanning 알림	저장소의 비밀번호를 알림으로 표시	적용됨, 자동 전환
push protection	push 시점에 비정형 자격 증명 검사	private preview
Copilot `/security-review`	CLI·앱의 읽기 전용 리뷰에서 검사	private preview 예정

이 중 실무에서 제일 기대되는 건 push protection이다. 알림은 이미 커밋 히스토리에 들어간 뒤에 뜨니까 결국 비밀번호를 바꾸고 히스토리를 정리해야 한다. push 단계에서 걸리면 히스토리에 들어가기 전에 지울 기회가 생긴다. 다만 changelog에는 탐지됐을 때 push를 막는지, 우회가 가능한지는 나오지 않는다. 기존 push protection처럼 동작할 거라고 짐작은 되지만 문서로 확인한 내용은 아니다.

3. 무료로 남는 것과 과금되는 것

AI 탐지 비밀번호 알림은 GitHub Secret Protection(GHSP)과 GitHub Advanced Security(GHAS)에 계속 추가 비용 없이 포함된다. 지금 쓰고 있다면 바뀌는 건 모델뿐이다.

새로 생기는 두 검사는 AI Credits를 쓴다.

push protection 사용량은 저장소를 소유한 조직에 청구된다. push를 막지 않은 검사도 크레딧을 쓸 수 있다고 적혀 있다.
/security-review 사용량은 쓰고 있는 Copilot 플랜의 결제 계정에 청구된다.
청구 항목 이름은 "Secret Protection AI Credits"다.
과금은 조직이 public preview에 옵트인하고 기능을 켠 뒤부터 시작된다.

개인적으로 가장 눈에 걸린 건 push protection 쪽이다. 막지 않은 push도 비용이 될 수 있다는 건 push가 많은 저장소일수록 사용량이 커진다는 뜻이다. 모노레포나 봇이 자주 push하는 저장소가 있는 조직이라면 켜기 전에 예산부터 잡아 두는 게 맞아 보인다.

플랜별 조건도 갈린다.

AI push protection: GitHub Enterprise Cloud 또는 GitHub Team에 유료 GHSP·GHAS가 있어야 하고, 관리자가 켜야 한다.
보안 리뷰 검사: 개인 Copilot 플랜(Free, Pro, Pro+, Max, Student)은 GHSP·GHAS 라이선스 없이도 대상이다. Copilot Business·Enterprise도 대상이지만 push protection에 필요한 GHSP 라이선스를 대신하지는 않는다.
GitHub Enterprise Server 3.23: AI 탐지 알림만 public preview로 들어가고, AI push protection과 /security-review는 빠졌다.

4. 켜기 전에 관리자가 할 일

예산은 이 순서로 잡는다고 안내돼 있다.

Billing and licensing에서 Budgets and alerts로 들어간다.
SKU 단위 예산을 고르고 Advanced Security 아래 Secret Protection AI Credits를 선택한다.
가능한 경우 "Stop usage when budget limit is reached"를 켠다.

세 번째가 중요하다. 예산 알림만 걸어 두면 사용이 멈추지 않는다. 실제로 상한을 걸려면 이 옵션을 같이 켜야 한다.

보안 리뷰 검사는 기본으로 꺼져 있고, /security-review 명령을 실행한다고 켜지지 않는다. 관리자가 정책으로 막아 두면 개인이 옵트인해도 그 정책을 넘어서지 못한다. 이미 private preview로 AI push protection을 쓰고 있다면 과금이 시작된 뒤에도 그대로 크레딧을 쓰게 되니, 원하지 않으면 그 전에 꺼 두라는 안내도 있다.

5. 우리 조직에서 점검할 것

GHSP·GHAS를 쓰고 있다면 AI 탐지 비밀번호 알림이 켜져 있는지, 새 모델 전환 뒤 알림 양이 달라졌는지
설정 파일에 비밀번호를 직접 넣는 저장소가 남아 있는지, 있다면 환경 변수나 시크릿 매니저로 옮길지
AI push protection을 켤 조직과 저장소 범위, push가 잦은 저장소를 포함할지
Secret Protection AI Credits 예산과 사용 중지 옵션
Copilot /security-review의 보안 리뷰 검사를 조직 정책으로 허용할지
Supabase, Pydantic Logfire 같은 새 패턴 대상 서비스를 쓰고 있다면 기존 알림이 새로 뜨지 않았는지

패턴 탐지는 정확하고 AI 탐지는 넓다. 둘이 겹치지 않는 영역을 맡는 구조라서, 비밀번호를 코드에 넣는 습관이 남아 있는 팀일수록 이번 변화의 영향이 클 것 같다.

참고 자료

JDK 28 Arena.ofConfined() 풀링: 작은 네이티브 할당이 최대 18배 빨라진다

Sat, 10 Oct 2026 00:05:00 GMT

JDK 28부터 Arena.ofConfined()에서 64바이트 이하의 작은 할당은 스레드마다 들고 있는 메모리 풀에서 잘라 쓰게 된다. 소스 코드는 하나도 바꿀 필요가 없다. FFM(Foreign Function & Memory) API로 네이티브 함수를 부를 때마다 confined arena를 열고 닫는 코드라면, 그 오버헤드가 OpenJDK 개발 벤치마크 기준으로 7배에서 18배까지 줄었다.

confined arena를 호출마다 새로 여는 패턴은 왜 느렸고, JDK 28에서는 무엇이 바뀌었나?

이 글은 10월 5일 Inside.java에 올라온 Per-Ake Minborg의 글과 OpenJDK PR #31365 설명을 읽고 정리했다. JDK 28은 아직 정식 출시 전이고, PR 페이지에는 리뷰가 진행 중인 상태로 보여서 세부 동작은 바뀔 수 있다.

1. 원래 무엇이 비쌌나

confined arena는 보통 네이티브 호출 하나를 감싸는 임시 공간으로 쓴다. 결과를 받을 포인터나 int 하나, errno 값, 짧은 문자열 같은 것들이다. 글에 실린 대표 패턴은 이렇다.

try (Arena arena = Arena.ofConfined()) {
    MemorySegment result = arena.allocate(ValueLayout.JAVA_INT);
    nativeFunction.invokeExact(result); // 결과를 segment에 써 준다
    return result.get(ValueLayout.JAVA_INT, 0);
}

문제는 4바이트짜리 int 하나를 받는 데도 JDK 27까지는 일반 네이티브 할당기를 거치고 정리 작업(cleanup action)까지 등록했다는 점이다. 메모리를 실제로 읽고 쓰는 시간보다 이 부가 작업이 더 오래 걸리는 경우가 생긴다.

설계의 근거로 든 데이터가 흥미롭다. OpenJDK 테스트 스위트를 계측해 보니 confined arena 중 일부는 네이티브 메모리를 아예 할당하지 않았고, 할당한 arena의 99.99% 이상이 64바이트 미만이었다고 한다. 대부분이 아주 작은 값을 잠깐 쓰고 버리는 용도였던 셈이다.

2. 풀은 어떻게 동작하나

플랫폼 스레드

각 플랫폼 스레드가 작은 풀 캐시를 지연 생성해서 들고 있다. 기본값은 64바이트 풀 최대 4개다.

arena가 처음으로 풀에 들어갈 만한 할당을 할 때만 캐시에서 풀 하나를 가져온다. 할당을 안 하는 arena는 풀을 건드리지 않는다.
그 풀은 해당 arena 전용이고, 작은 할당은 풀 앞쪽부터 순서대로 잘라 준다.
풀에 안 들어가는 크기이거나 풀이 맞춰 줄 수 없는 정렬을 요구하면 예전처럼 일반 경로로 간다.
arena를 닫으면 쓴 부분을 0으로 지우고 풀을 스레드 캐시에 돌려준다. 캐시가 이미 차 있으면 네이티브 할당기에 반납한다.

중첩된 confined arena는 각자 자기 풀을 가져가기 때문에 서로 섞이지 않는다.

가상 스레드

가상 스레드마다 캐시를 두면 수백만 개 스레드에 캐시가 붙는다. 그래서 가상 스레드는 지금 올라탄 carrier 스레드의 캐시에서 풀을 빌린다. pinning은 캐시에서 풀을 넘겨받는 짧은 순간에만 걸리고, 그 뒤로는 arena가 풀을 소유하니까 arena가 열린 동안 다른 carrier로 옮겨 가도 된다. 닫을 때는 그 시점에 올라탄 carrier의 캐시로 돌아간다.

3. 벤치마크 수치

글에 실린 개발 벤치마크 결과다. 기존 지연 시간을 풀링 후 지연 시간으로 나눈 값이라 클수록 좋다.

플랫폼	5바이트 할당	20바이트 할당
Linux AArch64	12.3배	8.6배
Linux x64	6.8배	7.8배
macOS AArch64	18.6배	16.8배
Windows x64	16.8배	18.9배

Apple M4에서 잰 ns/op 값을 보면 경계가 어디인지 더 잘 보인다.

할당 크기	풀링 (ns/op)	풀링 없음 (ns/op)
5바이트	1.052	15.862
20바이트	1.138	18.139
100바이트	19.044	18.856
500바이트	26.383	26.168

64바이트를 넘는 100바이트부터는 사실상 차이가 없다. 풀이 64바이트라서 그 위로는 기존 경로를 타기 때문이다. 가상 스레드에서는 5바이트 기준 3.222 대 15.672, 20바이트 기준 2.737 대 18.109로 플랫폼 스레드보다 이득이 조금 작았다. carrier를 다루는 비용이 더해지는 탓이다.

물론 마이크로벤치마크다. 글에서도 애플리케이션 전체가 이만큼 빨라진다는 뜻은 아니라고 선을 긋는다. 네이티브 호출 자체는 짧고 arena 생성, 할당, 정리가 시간의 대부분을 차지하는 코드에서 효과가 크다.

4. 바뀌지 않는 것과 조심할 것

segment 생명주기와 접근 규칙은 그대로다. arena를 닫은 뒤 segment에 접근하면 예전처럼 예외가 난다. 재사용 전에 풀을 0으로 지우고, cleanup action도 풀을 지우기 전에 실행된다. 스레드가 끝나면 캐시에 있던 풀도 해제된다.

개인적으로 더 신경 쓰인 건 진단 쪽이다. arena를 닫아도 free가 바로 불리지 않고 JDK 캐시로 돌아갈 수 있다. 그래서 arena 할당과 네이티브 malloc/free 호출이 1:1로 대응한다고 가정하면 안 된다. 네이티브 메모리 추적 도구로 누수를 보거나 malloc 횟수를 세는 테스트가 있다면 JDK 28에서 숫자가 달라질 수 있다.

적용 범위도 정리해 두면 이렇다.

구분	JDK 28 풀링 적용 여부
`Arena.ofConfined()`	64바이트 이하, 일반 정렬이면 적용
64바이트 초과 할당	기존 경로
그 외 arena 종류	영향 없음

PR 설명에는 풀 크기를 내부용 비공식 시스템 프로퍼티로 조절할 수 있고(8바이트에서 1MiB), 음수를 주면 풀링이 꺼진다고 적혀 있다. 다만 프로퍼티 이름은 확인하지 못했고 지원되는 옵션도 아니라서 운영 설정에 넣을 만한 건 아니다.

5. 우리 코드에서 볼 부분

혜택을 보는 쪽은 꽤 분명하다. 네이티브 호출마다 confined arena를 여는 FFM 바인딩, jextract로 생성한 래퍼, 포인터 out 파라미터나 작은 C 구조체를 주고받는 코드, 짧은 문자열을 네이티브로 넘기는 코드다. 백엔드에서는 JNI 대신 FFM으로 압축, 암호화, 시스템 콜 래퍼를 붙인 라이브러리가 여기에 해당한다.

JDK 28 EA 빌드로 넘어가 볼 때 확인할 것만 추리면 이렇다.

confined arena를 하나 열어 큰 버퍼와 작은 값을 같이 할당하던 코드는 작은 값만 짧게 쓰는 arena로 나눌지
호출마다 arena를 재사용하려고 직접 만든 풀이 있다면 JDK 풀과 겹치지 않는지
네이티브 메모리 누수 테스트가 malloc/free 횟수에 기대고 있지 않은지
가상 스레드에서 FFM을 부르는 경로는 플랫폼 스레드와 따로 측정할지

오히려 arena를 오래 들고 다니며 재사용하려고 애쓰던 코드는 이제 단순하게 try로 짧게 여닫는 쪽이 나을 수도 있다. 이건 각자 벤치마크로 확인할 부분이다.

참고 자료

Node.js 26.11 릴리스: 서버 개발자가 챙겨 볼 변경 다섯 가지

Fri, 09 Oct 2026 00:00:00 GMT

Node.js 26.11.0이 10월 7일 나왔다. 같은 날 문서 빌드 관련 변경을 되돌린 26.11.1이 바로 뒤따라 나왔으니 실제로 올릴 버전은 26.11.1이다. 이번 릴리스는 semver-minor 변경이 많은데, 그중 서버 코드를 짜는 입장에서 실제로 손이 갈 만한 건 다섯 개 정도로 추려졌다. 특히 node:sqlite를 쓰고 있다면 클래스 이름이 바뀌었으니 먼저 확인해 두는 게 좋다.

26.11에서 백엔드 코드나 운영 방식에 영향을 주는 변경은 무엇이고, 지금 당장 해야 할 일이 있는가?

이 글은 Node.js 공식 릴리스 노트와 각 변경의 GitHub PR 설명을 읽고 정리했다. 26은 Current 라인이라 API 세부 동작은 바뀔 수 있고, 운영 서버는 보통 LTS를 쓰니 이 기능들이 언제 LTS에 들어오는지는 따로 확인해야 한다.

1. 한눈에 보는 변경

영역	변경	영향
`http`	`isValidHeaderName()`, `isValidHeaderValue()` 추가	헤더 검증을 예외 없이 처리
CLI	`--process-timeout` 플래그 추가	멈춘 프로세스를 진단 후 종료
`node:sqlite`	`DatabaseSync` → `Database`, `StatementSync` → `Statement`	기존 코드 이름 점검 필요
`perf_hooks`	`histogram.snapshot()`, `histogram.diff()` 추가	구간별 지연 측정이 쉬워짐
권한 모델	`Socket(fd)`로 `--allow-net`을 우회하던 문제 수정	권한 모델 사용자는 업데이트

이 밖에 Buffer.stringLength(), process.ref/unref 안정화, Alpine Linux tier 2 승격, OpenSSL 3.5.9 업데이트 같은 변경도 들어갔다.

2. HTTP 헤더 검증이 예외 없이 된다

기존에도 http.validateHeaderName()과 http.validateHeaderValue()가 있었는데, 둘 다 잘못된 값이면 예외를 던진다. 새로 들어온 isValidHeaderName(), isValidHeaderValue()는 같은 검사를 하고 결과를 boolean으로 돌려준다.

const http = require("node:http")

if (!http.isValidHeaderValue(req.headers["x-trace-id"])) {
  res.statusCode = 400
  return res.end()
}

별것 아닌 차이 같지만 PR에 붙은 설명을 보니 이유가 성능이었다. 잘못된 헤더를 거를 때 기존 함수는 에러 객체와 스택 트레이스를 만드느라 몇 마이크로초가 걸리고, boolean 검사는 20ns 정도라고 한다. 사용자 입력을 그대로 헤더에 넣는 프록시나 게이트웨이처럼 잘못된 값이 자주 들어오는 경로라면 차이가 난다. isValidHeaderValue()는 http.createServer()의 httpValidation과 같은 의미의 strict, relaxed 옵션도 받는다고 적혀 있다.

3. --process-timeout: 멈춘 프로세스를 이유와 함께 종료

개인적으로 이번 릴리스에서 제일 반가웠던 건 이 플래그다. 지정한 시간이 지나면 별도 watchdog 스레드가 메인 스레드를 끊고, 그 시점의 JavaScript 스택과 이벤트 루프를 붙잡고 있는 리소스 목록을 출력한 뒤 종료 코드 124로 끝낸다. 메인 스레드가 네이티브 코드 안에서 멈춰 있어도 종료된다.

node --process-timeout=10s scripts/migrate.js
echo $?   # 시간 초과면 124

CI의 job 타임아웃이나 timeout 명령은 프로세스를 죽이기만 하고 무엇에 걸려 있었는지는 알려 주지 않는다. setTimeout으로 직접 감시하는 방법도 이벤트 루프가 바쁜 루프에 묶이면 아예 실행되지 않는다. 배치 작업, 마이그레이션 스크립트, 테스트 러너처럼 가끔 영원히 안 끝나는 프로세스가 있는 팀이라면 원인 찾는 시간이 꽤 줄 것 같다. 시간 단위 표기는 PR 예시의 10s 형식을 따랐으니 정확한 문법은 CLI 문서를 한 번 더 보자.

4. node:sqlite 클래스 이름 변경

DatabaseSync가 Database로, StatementSync가 Statement로 바뀌었다. 릴리스 노트에는 이름 변경만 적혀 있고, PR 설명에는 기존 이름을 alias로 남기고 문서상 deprecated(DEP0210) 처리한다고 돼 있다. 다만 PR 리뷰에서 런타임 경고를 띄울지를 두고 의견이 갈렸던 흔적이 있어서, 올리기 전에 직접 확인해 보는 게 안전하다.

node -e "const s = require('node:sqlite'); console.log(typeof s.Database, typeof s.DatabaseSync)"

둘 다 function이 나오면 기존 코드는 그대로 돌아간다. 새 코드는 처음부터 Database를 쓰는 편이 나중에 덜 귀찮다.

5. 지연 지표를 구간별로 보기

perf_hooks 히스토그램에 snapshot()과 diff()가 생겼다. snapshot()은 지금까지 기록된 값을 복사한 독립 히스토그램을 만들고, diff()는 두 시점 사이에 바뀐 부분만 담은 히스토그램을 돌려준다. monitorEventLoopDelay()로 이벤트 루프 지연을 재고 있다면 "최근 1분 동안의 p99"를 리셋 없이 뽑을 수 있게 된 셈이다.

예전에는 structuredClone()으로 복사하면 네이티브 히스토그램을 공유해 버려서 export()와 importHistogram()으로 직렬화했다가 다시 읽는 수밖에 없었다. 같은 릴리스에서 monitorEventLoopDelay() 해상도가 잘리던 문제도 고쳐졌다. diff()의 정확한 인자 형태는 PR 설명에 나오지 않아서 쓰기 전에 API 문서를 확인할 생각이다.

6. 권한 모델 보안 수정과 올리기 전 점검

--permission으로 권한 모델을 켠 상태에서 new Socket(fd)는 --allow-net 검사를 거치지 않았다. 파일 디스크립터에서 소켓을 만들면 네트워크 권한 없이도 통신할 수 있었다는 얘기다. 이번에 검사가 추가됐고 stdio와 IPC는 기존처럼 동작하도록 예외 처리됐다. 권한 모델로 서드파티 스크립트를 가둬 두고 있다면 이 수정 하나만으로도 올릴 이유가 된다.

올리기 전에 볼 것만 정리하면 이렇다.

설치할 버전은 26.11.0이 아니라 26.11.1
node:sqlite를 쓰면 DatabaseSync 사용처와 deprecation 경고 여부
--permission을 쓰는 서비스는 우선 업데이트
오래 도는 배치나 CI 스크립트에 --process-timeout을 붙일지
헤더를 직접 검증하는 코드가 try/catch로 감싸져 있다면 새 함수로 바꿀지

참고 자료

Aurora PostgreSQL에서 Iceberg·Parquet 직접 조회: 데이터 레이크를 위한 ETL이 하나 줄어든다

Wed, 07 Oct 2026 23:55:00 GMT

AWS가 9월 30일 Aurora PostgreSQL에서 S3에 있는 Apache Iceberg, Parquet 데이터를 직접 조회하는 기능을 발표했다. 운영 DB에 있는 최근 데이터와 데이터 레이크에 쌓인 과거 데이터를 SQL 한 번으로 같이 읽는다. 지금까지는 레이크 데이터를 서비스에서 보여 주려면 배치로 운영 DB에 다시 복사하는 리버스 ETL을 따로 돌리는 경우가 많았는데, 그 파이프라인 일부가 필요 없어지는 변화다.

레이크에 있는 데이터를 서비스 DB로 옮기지 않고, 애플리케이션이 쓰던 PostgreSQL 쿼리 그대로 읽을 수 있을까?

이 글은 AWS News Blog 발표 글을 기준으로 정리했다. 아직 상세 문서에 나오지 않은 동작은 쓰지 않았고, 확인이 필요한 부분은 따로 적었다.

1. 무엇이 추가됐나

새로 생긴 건 aurora_analytics라는 확장이다. 이 확장을 켜면 S3의 Parquet 파일이나 Iceberg 테이블을 PostgreSQL 외부 테이블(foreign table)로 만든다. 발표 글에 따르면 Aurora 안에 DuckDB 엔진이 내장돼 있고, 쿼리 처리는 Aurora 안에서 끝나서 별도 네트워크 홉이 생기지 않는다.

지원 버전과 데이터 소스는 다음과 같다.

구분	내용
엔진 버전	Aurora PostgreSQL 17.11 이상, 18.6 이상
카탈로그	AWS Glue Data Catalog로 관리하는 Iceberg 테이블
저장 위치	Amazon S3의 Parquet·Iceberg, S3 Tables
외부 연동	Iceberg REST Catalog 호환 카탈로그 (Glue 페더레이션 경유)
비용	기능 자체는 무료, Aurora 컴퓨팅과 S3 요청 비용만 발생
리전	모든 상용 리전과 GovCloud (US)

버전 조건이 꽤 최신이라 17.11 아래 마이너 버전을 쓰고 있다면 업그레이드부터 해야 한다.

2. 설정은 세 단계

발표 글에 나온 순서를 그대로 옮기면 이렇다.

Aurora PostgreSQL 클러스터를 만든다(또는 지원 버전으로 올린다).
AuroraAnalytics 기능으로 IAM 역할을 클러스터에 연결한다. 이 역할이 S3와 Glue Data Catalog 접근 권한을 준다.
DB에서 확장을 켠다.

CREATE EXTENSION aurora_analytics;

그다음 외부 테이블을 만든다. Parquet 파일 하나를 붙이는 예시는 이렇다.

CREATE FOREIGN TABLE transaction_history ()
SERVER aurora_analytics_server
OPTIONS (
    location 's3://<my-bucket>/finance/transaction_history.parquet',
    format 'parquet'
);

컬럼 목록이 비어 있는 게 의도된 부분이다. Parquet 메타데이터에서 스키마를 읽어 오기 때문에 컬럼을 직접 적지 않아도 된다. 테이블이 많으면 IMPORT FOREIGN SCHEMA 한 번으로 Glue 데이터베이스에 있는 Iceberg·Parquet 테이블을 전부 외부 테이블로 만든다고 한다. 다만 발표 글에는 이 문장의 정확한 문법이 나오지 않아서, 실제로 쓸 때는 Aurora 사용자 가이드를 확인하는 게 맞겠다.

3. 운영 데이터와 레이크 데이터를 한 쿼리로

발표 글의 예시가 이 기능을 왜 만들었는지 잘 보여 준다. 최근 7일 거래는 Aurora 테이블에, 5년치 이력은 S3 Parquet에 있는 상황이다.

SELECT merchant, category, amount, transaction_date, 'recent' AS source
FROM recent_transactions
WHERE customer_id = 'C-1001'
UNION ALL
SELECT merchant, category, amount, transaction_date, 'historical' AS source
FROM transaction_history
WHERE customer_id = 'C-1001'
  AND transaction_date >= CURRENT_DATE - INTERVAL '5 years'
ORDER BY transaction_date DESC
LIMIT 15;

애플리케이션 입장에서는 그냥 테이블 두 개를 UNION ALL 한 쿼리다. 고객 거래 내역 화면처럼 "최근 것은 빠르게, 오래된 것도 가끔은 보여 줘야 하는" API에서 지금까지 따로 두던 아카이브 조회 경로를 하나로 합치게 된다. 발표 글에는 커밋되지 않은 운영 쪽 쓰기까지 같은 쿼리에서 보인다는 설명도 있다.

4. 자주 읽는 데이터는 Aurora로 가져온다

외부 테이블은 매번 S3를 읽는다. 자주 조회하는 범위라면 Aurora 테이블로 옮겨 두는 편이 낫다. 문법은 평소 쓰던 PostgreSQL 그대로다.

방법	쓰임새
`CREATE TABLE AS SELECT`	레이크 데이터로 새 테이블 생성
`INSERT INTO ... SELECT`	기존 테이블에 범위 단위로 적재
`MERGE INTO`	변경분을 기존 테이블에 반영

여기서 하나 걸리는 게 인스턴스 역할이다. 이런 적재 명령은 Aurora에 쓰기를 하니까 writer 인스턴스에서만 돌아간다. 반대로 외부 테이블 조회는 read replica를 포함한 아무 인스턴스에서나 된다. 분석성 스캔을 replica로 보내면 writer 부하를 건드리지 않고 레이크를 읽는다는 뜻이고, 개인적으로는 이 부분이 실무에서 제일 쓸모 있어 보였다.

5. 성능과 비용은 어디서 보나

발표 글에서 언급한 최적화는 세 가지다. 필터 조건을 스캔 단계로 내려보내는 predicate pushdown, 필요한 컬럼만 읽는 column pruning, 그리고 자주 읽는 데이터를 인스턴스에 캐시하는 것이다. 그래서 WHERE 조건 없이 큰 Parquet을 통째로 읽는 쿼리는 여전히 비싸다.

쿼리별로 얼마나 읽었는지는 함수로 확인한다.

SELECT * FROM aurora_analytics_stat_statements();

스캔한 행 수, S3에서 읽은 바이트, 캐시 적중 같은 지표가 나온다고 한다. 기능 자체는 추가 요금이 없지만 S3 요청 비용과 Aurora 컴퓨팅 사용량은 그대로 붙기 때문에, 도입 초기에 이 지표로 무거운 쿼리를 먼저 찾아 두는 게 좋겠다.

6. 도입 전에 확인할 것

클러스터 버전이 17.11 또는 18.6 이상인지
AuroraAnalytics IAM 역할이 읽어야 할 버킷과 Glue 데이터베이스로만 좁혀져 있는지
외부 테이블 조회가 replica로 가도록 커넥션 라우팅이 나뉘어 있는지
자주 읽는 범위는 INSERT INTO ... SELECT로 옮길지, 외부 테이블로 둘지
기존 리버스 ETL 배치 중 이 기능으로 없앨 수 있는 게 있는지

레이크와 서비스 DB 사이를 잇던 배치가 많은 팀일수록 얻는 게 크다. 반대로 레이크 데이터를 거의 안 읽는 서비스라면 굳이 버전을 올려 가며 쓸 이유는 아직 없어 보인다.

참고 자료

GitHub 비동기 머지 API 정식 출시: 머지 봇이 타임아웃을 기다리지 않아도 된다

Wed, 07 Oct 2026 10:45:00 GMT

GitHub가 10월 1일 PR을 비동기로 머지하는 REST API를 정식(GA)으로 열었다. 요청을 던지면 바로 UUID를 돌려받고, 실제 머지는 백그라운드에서 끝난다. 머지 봇이나 배포 파이프라인에서 PUT .../merge를 호출하고 응답을 붙잡고 있던 코드라면 한 번 볼 만하다. changelog에서는 이 API를 기존 동기 REST·GraphQL 머지 엔드포인트의 권장 대체재로 소개하고 있다.

기존 방식에서 걸리던 부분

지금까지 자동화에서 PR을 머지하는 방법은 보통 PUT /repos/{owner}/{repo}/pulls/{pull_number}/merge 하나였다. 호출하면 그 자리에서 머지를 시도하고 결과를 돌려준다. 단순해서 좋지만 저장소가 바쁠수록 문제가 생긴다.

머지가 복잡하면 응답이 늦어지고 타임아웃이 난다.
일시적인 실패도 그냥 실패로 떨어져서 재시도 로직을 직접 짜야 한다.
머지 큐를 쓰는 저장소에서는 "바로 머지"와 "큐에 넣기"를 따로 처리해야 했다.

새 API는 이 부분을 GitHub 쪽으로 넘긴다. 공식 문서 설명을 그대로 옮기면 백그라운드에서 머지하기 때문에 일부 오류는 재시도될 수 있고, 복잡한 머지에서 타임아웃 위험을 피할 수 있다고 한다.

엔드포인트 두 개가 전부다

요청과 조회, 이렇게 두 개다.

PUT /repos/{owner}/{repo}/pulls/{pull_number}/merge-async
GET /repos/{owner}/{repo}/pulls/{pull_number}/merge-async/{uuid}

PUT 바디에 넣을 수 있는 값은 다음과 같다.

파라미터	내용
`commit_title`	자동 생성되는 머지 커밋 제목
`commit_message`	커밋 메시지 뒤에 붙일 내용
`sha`	PR head가 이 SHA와 같을 때만 머지
`merge_method`	`merge`, `squash`, `rebase`
`merge_action`	`default`, `direct_merge`, `merge_queue`

눈여겨본 건 merge_action이다. direct_merge는 머지 큐를 거치지 않고 바로 머지하고, merge_queue는 큐에 넣는다. default는 GitHub가 상황에 맞는 쪽을 고른다. 머지 큐 도입 여부에 따라 봇 코드를 둘로 나눌 필요가 없어진 셈이다.

sha도 동작이 조금 다르다. 값을 안 넣으면 요청 시점의 PR head를 기준으로 잡는데, 요청과 실제 실행 사이에 누가 push를 하면 머지가 취소된다. 리뷰가 끝난 커밋만 머지되도록 하는 장치로 쓸 수 있다.

응답과 상태 코드

PUT이 새 요청을 받아들이면 202와 함께 이런 응답이 온다.

{
  "status": "pending",
  "details": {
    "message": "string",
    "uuid": "string",
    "merge_method": "squash",
    "merge_action": "default",
    "expected_head_sha": "string"
  }
}

status는 pending, merged, enqueued, failed 넷 중 하나다. GET으로 조회해도 같은 모양이 온다. 상태 코드는 동기 API보다 경우가 많다.

코드	의미
200	이미 머지됐거나 큐에 들어가 있음
202	새 요청 접수, 백그라운드 처리
400	닫혔거나 draft라서 머지 불가
409	이미 진행 중인 비동기 머지 요청이 있음 (기존 UUID 반환)
422	검증 실패

409가 오류가 아니라 "이미 있다"는 뜻이라는 점이 재미있다. 같은 PR에 머지 요청을 두 번 보내도 기존 UUID를 돌려받으니, 봇이 재시작되면서 요청을 중복으로 보내도 크게 문제 될 게 없다. 그리고 결과는 마지막 업데이트 후 24시간만 보관된다. 하루 넘게 지난 UUID로 조회하면 404가 온다.

스택 PR은 이 API로만 머지된다

이번 발표에서 가장 큰 변화는 사실 여기다. 문서에는 스택으로 쌓인 PR을 머지할 때는 이 엔드포인트가 필수라고 적혀 있다. 스택의 중간 PR을 지정하면 그 아래 PR부터 지정한 PR까지 전부 base 브랜치로 머지된다. 기존 /merge로는 이걸 못 한다.

스택 PR을 쓰는 팀이라면 머지 자동화를 이쪽으로 옮겨야 한다는 뜻이고, 아직 안 쓰는 팀이라도 나중에 스택 PR을 도입할 때 봇을 다시 고칠 필요가 없도록 지금 넘어가 두는 게 편해 보인다.

자동화 코드는 이렇게 바뀐다

curl로 흐름만 보면 이렇다.

# 1. 머지 요청
curl -s -X PUT \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "Accept: application/vnd.github+json" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  https://api.github.com/repos/OWNER/REPO/pulls/123/merge-async \
  -d '{"merge_method":"squash","sha":"<리뷰한 head SHA>"}'

# 2. 응답의 details.uuid로 상태 조회
curl -s \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "Accept: application/vnd.github+json" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  https://api.github.com/repos/OWNER/REPO/pulls/123/merge-async/$UUID

옮길 때 신경 쓸 부분은 몇 가지다.

응답을 받았다고 머지가 끝난 게 아니다. status가 merged나 enqueued가 될 때까지 조회하고, failed면 details.message를 로그에 남긴다.
폴링 간격은 넉넉하게 잡는다. 동기 API 문서에도 너무 빠르게 호출하면 secondary rate limit에 걸릴 수 있다고 적혀 있다.
409를 실패로 처리하던 기존 에러 핸들링이 있다면 고친다. 비동기 API에서는 진행 중인 요청의 UUID를 받는 정상 경로다.
리뷰한 커밋만 머지하고 싶다면 sha를 꼭 넣는다.

changelog에는 적절한 권한이 있으면 머지 규칙을 우회하는 옵션도 있다고 나오는데, 이건 자동화에 기본으로 켜 둘 기능은 아니라고 본다. 우회가 필요한 봇이라면 토큰 권한부터 따로 관리하는 게 맞다.

참고 자료

블로그를 다시 시작합니다

Wed, 07 Oct 2026 00:00:00 GMT

블로그를 새로 정비했습니다. 앞으로 백엔드 개발과 기술 이야기를 이곳에 꾸준히 기록하려고 합니다.