Hugo PaperMod 블로그 구축에서 시작한 블로그를 Hugo에서 Docusaurus로 마이그레이션했어요. 원래 한 도메인에서 블로그 2개와 문서 노트 5개, 모두 Hugo 사이트 7개를 따로 돌렸는데 영역마다 빌드와 설정을 챙기는 일이 점점 무거워졌어요.

Docusaurus 소개​

Docusaurus는 Meta가 만든 React 기반 오픈소스 정적 사이트 생성기입니다. 코드는 facebook/docusaurus에 공개되어 있습니다. 일반 블로그보다 버전 관리, 사이드바, 문서 탐색 같은 문서 사이트 기능에 초점을 맞춥니다. docs 플러그인을 여러 인스턴스로 구성할 수 있어 한 사이트 안에서도 문서 영역별 경로와 사이드바를 독립적으로 운영합니다. 블로그 플러그인 역시 여러 개를 띄울 수 있으므로 성격이 다른 블로그를 분리하기 좋습니다. Mermaid, 로컬 검색 플러그인, 다크 모드까지 문서 사이트에 필요한 기능을 생태계 안에서 함께 구성할 수 있습니다.

후보와 선택 기준​

첫 번째 후보는 Hugo를 유지하고 Hextra 단일 사이트로 합치는 방식이었습니다. 기존 도구를 그대로 쓰므로 마이그레이션 비용은 가장 적지만, 문서 중심 테마라 블로그 2개의 레이아웃을 나누어 살리기에는 아쉬웠습니다.

Docusaurus는 독립된 문서 영역 여러 개와 블로그 여러 개를 공식 플러그인의 다중 인스턴스로 구성할 수 있습니다. 문서 노트 5개와 블로그 2개라는 저의 구조에 이 방식이 정확히 맞았습니다.

Astro Starlight도 빠르고 깔끔한 문서 도구였지만 기본 구조는 단일 문서 사이트에 가깝고, 블로그에는 서드파티 플러그인이 필요했습니다. 결국 새 기술의 화려함보다 지금 가진 영역을 무리 없이 한 프로젝트에 담을 수 있는지를 기준으로 Docusaurus를 골랐습니다.

힘들었던 점​

첫 번째는 자동 변환의 사각지대였습니다. 변환 작업이 커밋된 파일을 기준으로 진행되면서 커밋하지 않은 글 11개가 결과에서 빠졌고, 배포 후 운영에서 404로 드러났습니다. 전체 변환을 다시 돌리면 이미 손본 글까지 덮을 수 있어 변환 스크립트에 증분 모드를 추가하고 누락된 글만 복구했습니다.

두 번째는 구 URL 보존이었습니다. 기존 주소 1,100여 개를 새 경로로 보내는 301 map을 만들었는데, URL 인코딩된 한글 태그 주소가 긴 key가 되면서 Nginx의 map_hash_bucket_size 기본값을 넘겼습니다. 설정 자체는 정상이었지만 reload가 실패했고, bucket 크기를 늘린 뒤에야 기존 주소를 유지한 채 전환할 수 있었습니다.

통합 후 모습​

홈은 일곱 영역을 안내하는 카드로 바꿨습니다. 상단 메뉴에서 블로그와 문서 노트를 오갑니다.

문서 영역은 좌측 사이드바와 우측 목차가 있는 Docusaurus 기본 문서 레이아웃을 그대로 씁니다.

이제 빌드와 배포가 하나로 줄었어요. 예전 URL의 색인이 새 주소로 안정적으로 재구축되는지는 조금 더 지켜보는 중이에요.

버전 번호가 하나 비어 있으면 신경이 쓰여요. 8월 13일에 나온 PostgreSQL 마이너 릴리스는 18.6인데, 그 앞은 18.5가 아니라 18.4입니다. 제 경우엔 패키지 목록을 보다가 "내가 하나 놓쳤나" 싶어 한참을 되짚었습니다. 결론부터 적으면 놓친 것은 없습니다. 18.5는 만들어졌지만 세상에 나오지 않았습니다.

공식이 말한 것은 한 줄뿐입니다​

사유를 언급한 곳은 두 군데인데, 표현이 미묘하게 다릅니다.

18.6 릴리스 노트에는 이렇게 적혀 있습니다.

18.5 was never released, due to a regression discovered post-wrap.

릴리스 공지는 좀 더 건조합니다.

This release skips PostgreSQL 18 versions from PostgreSQL 18.4 to 18.6. 18.5 was not shipped due to a regression.

공지는 "shipped"라고만 했고, 릴리스 노트는 post-wrap이라는 단어를 하나 더 얹었습니다. 이 단어가 사실상 전부를 설명합니다. 무엇이 wrap이고, 그 이후라는 게 왜 중요한지 알면 18.5가 사라진 경로가 그대로 보입니다.

마이너 릴리스는 이런 순서로 만들어집니다​

PostgreSQL의 Release process 위키에 절차가 공개돼 있습니다. 요약하면 committer가 버전을 찍고, 서버에서 tarball을 말고, packager들이 먼저 써 보고, 마지막에 태그를 미는 순서입니다.

2단계가 wrap입니다. pgsql 계정으로 borka.postgresql.org에 들어가 mk-release-bundle을 실행하면 tarball과 체크섬이 staging 디렉토리에 만들어집니다. 이 단계를 특정 서버에서만 하는 이유는 재현성 때문입니다. bison, flex, docbook 버전이 다르면 결과물이 달라지니 빌드 환경을 한 곳으로 고정해 둔 것입니다.

주목할 곳은 3단계와 4단계 사이입니다. 위키가 태그를 두고 분명하게 적어 뒀습니다.

Pushing a tag is more or less irreversible, so don't do this until packager preliminary testing is over.

태그를 밀면 되돌리기 어렵습니다. 그래서 packager들이 최소 24시간 먼저 만져 보고, 이상이 없어야 태그가 나갑니다. 18.5는 그 구간을 통과하지 못했습니다.

취소는 되는데 번호는 돌아오지 않습니다​

같은 위키에 사고 처리 절차도 한 줄로 적혀 있습니다.

In event of disaster, fix code as needed then repeat the wrap process, with or without a version number bump as seems appropriate.

문제가 생기면 코드를 고쳐 wrap을 다시 하되, 번호를 올릴지 말지는 그때 적절히 판단하라는 뜻입니다. 규정이 아니라 재량입니다. 18.5 건에서는 올리는 쪽을 택했습니다.

왜 그랬을까요. version_stamp.pl이 이미 Stamp 18.5. 커밋을 남겼고 그 번호로 tarball이 만들어졌기 때문입니다. staging에 있던 물건이라 일반 사용자에게 내려간 것은 아니지만, packager들 손에는 18.5라는 이름표가 붙은 파일이 이미 가 있었습니다. 같은 번호로 내용이 다른 tarball을 한 번 더 돌리는 것보다 번호를 하나 올리는 편이 안전합니다. 태그를 밀기 전이라 릴리스 자체는 멈출 수 있었지만, 번호는 그 시점에 이미 쓰인 것입니다.

8월 9일까지는 18.5였습니다​

타임라인도 이 해석과 맞습니다. Jonathan Katz(조너선 카츠)가 pgsql-hackers에 올린 8월 13일 릴리스 공지 초안은 2026년 8월 9일자인데, 거기 적힌 버전은 아직 18.5입니다.

마이너 릴리스는 관례상 목요일에 공개하고 tarball은 그 주 초에 맙니다. 8월 13일이 목요일이니 wrap은 10일 전후, 공지 초안은 그 직전에 돌린 셈입니다. 초안이 나가고 며칠 사이에 번호가 하나 올라갔습니다.

결번은 여섯 개뿐입니다​

그럼 이런 일이 자주 있었을까요. 세어 봤습니다. bucardo가 모든 버전의 릴리스 노트를 한 페이지에 모아 두는데, 여기서 never released를 전수 검색하면 여섯 건이 나옵니다.

여섯 개지만 사건은 두 건입니다. 위의 다섯은 대체 릴리스 날짜가 전부 2008년 6월 12일로 같습니다. 한 번의 사고로 당시 지원하던 브랜치가 통째로 결번된 것입니다.

18.5는 혼자입니다. 같은 날 나온 17.11, 16.15, 15.19, 14.24는 번호가 정상입니다. 회귀가 18 브랜치에만 있었다는 뜻입니다.

2008년에는 무슨 일이 있었나​

8.3.2 릴리스 노트를 열면 Release Date 필드가 never released입니다. 그런데 본문은 멀쩡합니다. "This release contains a variety of fixes from 8.3.1"로 시작하고, Migration to Version 8.3.2 절도 붙어 있고, Changes 목록에 마흔 건 가까운 수정이 그대로 나열돼 있습니다. Windows에서 UTF-8 인코딩일 때 나던 크래시, %r 매크로의 archive 절단 지점 오산, GIN의 "too many LWLocks taken" 실패, SIGTERM으로 backend를 개별 종료했을 때 shared memory가 오염되던 문제가 보입니다.

그중 %r 항목은 지금 봐도 아찔합니다. warm standby 스크립트가 그 값을 믿고 WAL segment 파일을 버리면 데이터를 잃을 수 있었습니다. 이런 수정을 담은 릴리스가 문턱까지 갔다가 멈췄습니다.

노트에 사유는 적혀 있지 않습니다. 대신 대체 버전 노트의 첫 문장이 단서를 흘립니다.

세상에 나온 적 없는 버전을 기준점으로 삼아 "그 대비 몇 건"이라고 적었습니다. 결번본이 실재했다는 자백입니다. 그리고 여기서 말하는 "one serious"가 무엇인지는 다섯 브랜치 공통 항목으로 노트에 남아 있습니다.

Make pg_get_ruledef() parenthesize negative constants (Tom Lane)

Before this fix, a negative constant in a view or rule might be dumped as, say, -42::integer, which is subtly incorrect: it should be (-42)::integer due to operator precedence rules. Usually this would make little difference, but it could interact with another recent patch to cause PostgreSQL to reject what had been a valid SELECT DISTINCT view query. Since this could result in pg_dump output failing to reload, it is being treated as a high-priority fix.

view나 rule 안에 들어 있는 음수 상수를 괄호 없이 덤프하던 문제입니다. 연산자 우선순위상 (-42)::integer여야 하는데 -42::integer로 나왔습니다. 그 자체로는 대개 차이가 없지만, 당시 함께 들어간 다른 패치와 맞물리면 멀쩡하던 SELECT DISTINCT view 쿼리를 PostgreSQL이 거부했습니다.

여기서 심각도가 뛴 지점은 마지막 문장입니다. pg_dump 출력이 다시 적재되지 않을 수 있다는 결론이었습니다. 백업 파일이 복원되지 않는 문제는 다른 어떤 버그와도 무게가 다릅니다. 준비돼 있던 다섯 개 tarball을 버리고 이 수정을 얹어 다시 낸 이유로 충분합니다.

두 사건이 남긴 기록의 차이​

구조는 같습니다. wrap이 끝난 뒤 회귀가 잡혔고, 고쳐서 번호를 올려 다시 냈습니다. 달라진 것은 그 사실을 어떻게 적어 두느냐입니다.

18.6 노트는 결번 사유를 한 줄로 명시했습니다. 짧지만 왜 번호가 비었는지가 문서 안에 적혀 있습니다. 2008년 노트들은 never released라는 사실만 남기고 사유를 적지 않았습니다. 지금 그 이유를 재구성할 수 있는 것은 대체본이 "over 8.3.2"라는 표현을 쓴 덕분입니다. 의도한 기록이라기보다 흔적에 가깝습니다.

공통점도 있습니다. 여섯 개 전부 릴리스 노트 페이지가 지금도 살아 있습니다. 나오지 않은 버전의 문서를 지우지 않는 관행이 적어도 2008년부터 이어지고 있습니다. 덕분에 18년 전 사건을 1차 출처로 따라갈 수 있었습니다.

검색하면 섞여 나오는 이야기 하나​

18.5 결번을 검색하면 "standby가 구버전 마이너의 WAL을 재생하다 self-deadlock에 빠진다"는 내용이 사유처럼 딸려 나옵니다. 별개 사건입니다.

credativ가 정리한 그 버그는 MultiXactOffsetSLRU deadlock이고, 2026년 5월 14일에 나온 14.23, 15.18, 16.14에서 유입됐습니다. 17과 18은 영향이 없습니다. 증상은 standby의 startup 프로세스가 pg_stat_activity에서 LWLock/MultiXactOffsetSLRU 대기로 멈추는 형태입니다.

같은 8월 13일 릴리스에서 함께 고쳐졌을 뿐, 18.5를 취소시킨 원인이 아닙니다. 두 이야기를 붙여 쓰면 틀린 글이 됩니다.

지금 확인할 것​

운영 관점에서 할 일은 많지 않습니다.

1. 18.4에서 18.6으로 바로 올립니다. 중간에 빠뜨린 버전은 없습니다
2. 자동화 스크립트가 마이너 번호를 순차 증가로 가정하고 있다면 확인합니다. 18.4 + 1 = 18.5를 기대하는 코드는 여기서 멈춥니다
3. 사내 문서나 지원 버전 표에 18.5를 적어 둔 곳이 있으면 지웁니다

3번은 사소해 보이지만 실제로 혼란을 만듭니다. "18.5 적용 예정"이라고 써 둔 계획서가 남아 있으면 나중에 읽는 사람이 없는 버전을 찾게 됩니다.

남은 질문​

18.5를 취소시킨 회귀가 정확히 무엇이었는지는 공개되지 않았습니다. 공식 문구는 "a regression"이 전부입니다. 2008년 사건에서도 회귀를 유발한 "another recent patch"가 무엇인지는 노트에 적혀 있지 않습니다.

저는 이 공백이 문제라고 보지는 않아요. 세상에 나가지 않은 코드의 버그를 상세히 적는 것은 그 자체로 이상한 일이니까요. 다만 번호가 하나 비면 사람은 반드시 이유를 찾습니다. 18.6 노트가 한 줄이라도 남겨 둔 덕분에 저 같은 사람이 패키지 목록 앞에서 오래 헤매지 않았습니다. 기록은 그 정도만 해 줘도 충분히 일을 합니다.

참고​

• PostgreSQL 18.6 릴리스 노트 - "18.5 was never released, due to a regression discovered post-wrap"
• PostgreSQL 18.6, 17.11, 16.15, 15.19, 14.24 and 19 Beta 3 Released! - PostgreSQL News, 2026-08-13
• Release process - PostgreSQL wiki, wrap/tag 절차와 사고 처리
• Versioning Policy - 마이너 릴리스 주기와 번호 규칙
• Release 8.3.2 - Release Date가 never released인 노트
• Release 8.3.3 - "one serious and one minor bug fix over 8.3.2"
• Postgres Release Notes - All Versions - 결번 전수 조사에 사용
• 2026-08-13 release announcement draft - 8월 9일 시점 표기는 18.5
• Replication Deadlock Bug in Current Postgres Releases 14-16 - credativ, 18.5 결번과는 별개 사건

벤더가 "패치를 빨리 적용하세요"라고 말하는 건 새롭지 않아요. 그런데 그 이유가 "AI가 우리 패치를 분석해서 공격 방법을 알아낼 수 있어서"라면 성격이 다릅니다.

2026년 8월 18일 오라클이 Prepare Now: Apply Oracle Database Release Update Immediately Upon Availability를 냈습니다. 지원 중인 모든 릴리스, 19c와 Oracle AI Database 26ai를 포함해, 데이터베이스 자산 전체에 최신 분기 Release Update를 테스트하고 배포할 준비를 지금 하라는 내용입니다.

권고의 근거가 달라졌다​

주목할 부분은 요구 사항이 아니라 근거입니다. 오라클이 든 이유는 frontier AI 모델이 소프트웨어 취약점을 찾고 악용하는 장벽을 크게 낮추고 있다는 것입니다. 그 모델들이 하는 일로 네 가지를 꼽았습니다. 약점 식별, 소프트웨어 변경 분석, 보안 패치의 리버스 엔지니어링, 그리고 잠재적 공격 경로 개발입니다. 속도와 규모가 전례 없다고 표현했습니다.

이 목록에서 세 번째가 핵심입니다. 보안 패치의 리버스 엔지니어링입니다.

패치는 무엇이 잘못됐는지를 알려 줍니다. 코드의 어느 줄이 어떻게 바뀌었는지 보면 그 전에 무엇이 가능했는지 역산할 수 있습니다. 이걸 patch diffing이라고 부르고, 오래된 기법입니다. 새로운 건 그 작업의 비용입니다. 숙련된 분석가가 며칠 걸리던 일을 모델이 훨씬 빨리 해내면, 패치 공개와 실제 적용 사이의 구간이 그만큼 위험해집니다.

패치를 늦게 적용하는 쪽이 더 위험해지는 구조는 원래 있었습니다. 달라진 것은 그 위험이 커지는 속도입니다.

8월 CSPU의 물량​

같은 주에 나온 숫자가 이 권고의 배경을 보여 줍니다. Qualys 분석에 따르면 8월 Critical Security Patch Update는 943개 취약점을 다뤘습니다.

무인증 원격 악용이 가능한 것들이 제품군별로 이렇게 나왔습니다.

E-Business Suite에서 CVSS 9.8인 CVE-2026-60782와 CVE-2026-70926이 나왔습니다.

DBA 관점에서 궁금한 것은 Database 쪽 물량입니다. 943개 중 데이터베이스 제품군은 17개였습니다.

전체 943개에 비해 17개는 적어 보입니다. 하지만 Database Server의 최고 점수가 9.6이라는 게 중요합니다. 개수가 아니라 그 6개가 무엇인지가 판단 근거입니다.

월간 체제와 즉시 적용이 만나면​

오라클이 분기 패치를 버리고 월간 CSPU 체제로 옮긴 이야기를 다룬 적이 있습니다. 이번 권고를 그 흐름 위에 놓으면 실무 부담이 선명해집니다.

분기 체제에서는 1년에 네 번 패치 시기가 왔습니다. 한 번마다 테스트에 몇 주를 쓸 여유가 있었습니다. 월간 체제에서는 열두 번입니다. 여기에 "나오는 즉시 적용하라"가 붙으면, 테스트 기간을 얼마로 잡을지가 실질적인 문제가 됩니다.

권고와 현실 사이의 간격을 어떻게 좁힐지가 결국 각 조직의 판단입니다. 몇 가지 방향은 이렇습니다.

RU 종류를 구분하는 것이 먼저입니다. 오라클의 Release Update와 Release Update Revision은 성격이 다릅니다. 전체를 같은 절차로 다루면 열두 번을 감당하지 못합니다.

테스트 자동화의 범위를 다시 볼 필요도 있습니다. 회귀 검증을 사람이 도는 구조라면 월간 주기를 못 따라갑니다. 이 부분은 패치 정책 이전에 검증 파이프라인 문제입니다.

그리고 적용 순서를 노출도로 정하는 방법이 있습니다. 무인증 원격 악용이 가능한 구성요소를 앞에 두는 식입니다. 위 표에서 Fusion Middleware의 182개가 왜 먼저인지는 숫자가 설명합니다.

AI가 양쪽에서 일한다​

Anthropic의 Project Glasswing을 다룰 때는 AI가 핵심 인프라의 취약점을 찾아 주는 쪽 이야기였습니다. 이번 오라클 공지는 같은 능력의 반대쪽입니다.

두 사례를 나란히 놓으면 구도가 정리됩니다. 방어 측은 AI로 코드를 감사해 취약점을 미리 찾습니다. 공격 측은 AI로 패치를 분석해 이미 고쳐진 취약점을 역산합니다. 전자는 패치 이전, 후자는 패치 이후입니다. 그래서 패치 공개 시점이 양쪽의 경계선이 됩니다.

벤더가 이 판단을 공식 문서로 낸 것이 이번 공지의 의미라고 봅니다. "AI 때문에 패치 정책을 바꿉니다"를 제품 블로그에 적은 사례가 아직 흔하지 않습니다. 오라클이 자사 데이터베이스 고객 전체를 향해 그렇게 적었습니다.

실무에서 확인할 것​

Oracle Database Appliance를 쓰는 환경이라면 릴리스 19.32에 7월 Database Release Update와 19c, 26ai 클론 파일이 들어 있습니다. 계획, 테스트, 배포 일정을 지금 시작하라는 것이 공지의 요구입니다.

정리하면 확인 항목은 셋입니다. 현재 운영 중인 데이터베이스의 RU 수준이 어디인지, 다음 RU가 나올 때 테스트에 며칠을 쓸 계획인지, 그리고 그 며칠이 이번 공지의 논리에 비추어 감당할 만한 구간인지입니다.

마지막 항목이 답하기 어렵습니다. 패치 공개 후 며칠이 안전한지 아무도 숫자로 말해 주지 않으니까요. 저는 이 공지가 그 숫자가 줄어들고 있다는 신호로 읽혔어요.

참고​

• Prepare Now: Apply Oracle Database Release Update Immediately Upon Availability (Oracle Database Blog, 2026-08-18)
• Oracle Critical Patch Update, August 2026 Security Update Review (Qualys, 2026-08-19)
• August 2026 Critical Security Patch Update Released (Oracle Security Blog, 2026-08-18)
• Oracle Database Appliance 릴리스 정보

병렬 쿼리를 켰는데 빨라지지 않는 경험, 집계 쿼리에서 특히 잦습니다. 이유가 구조에 있고, 그 구조를 바꿔 보려는 실험 결과가 나왔어요.

pgEdge의 Andrei Lepikhov(안드레이 레피호프)가 Do Global Hash Tables Strike Back in PostgreSQL?에서 공유 해시 테이블 기반 병렬 집계를 직접 구현하고 측정했습니다. 결론이 흥미롭습니다. 되기는 되는데, 값이 너무 비쌉니다.

지금 구조: 나눠서 세고, 하나가 합친다​

PostgreSQL의 병렬 집계는 두 단계입니다. 각 워커가 자기가 읽은 행을 Partial HashAggregate로 부분 집계합니다. 그 결과를 Gather가 모으고, 리더 프로세스 하나가 Finalize HashAggregate로 합칩니다.

그룹 수가 적으면 이 구조가 잘 돕니다. 워커 넷이 각각 100개 그룹의 부분 합계를 만들면, 리더는 400개 행만 합치면 됩니다.

그룹 수가 많으면 이야기가 달라집니다. 그룹이 500만 개면 각 워커의 부분 집계 결과도 수백만 행이고, 리더가 그걸 다 받아 다시 해시 테이블을 만들어야 합니다. 저자가 든 예시에서 스캔은 252ms인데 Finalize 단계가 전체 25초 중 18초를 썼습니다. 병렬을 끄면 13초였으니, 병렬 계획이 직렬보다 거의 두 배 느렸습니다.

직접 재 봤다​

PostgreSQL 18에서 확인했습니다. 워커를 8개까지 쓸 수 있게 두고, 500만 행 테이블 셋을 만들어 그룹 수만 달리했습니다.

-- 그룹 100개
create table agg_few as select (i % 100) as g, i as v
  from generate_series(1,5000000) i;

-- 그룹 500만개 (모든 행이 각자 그룹)
create table agg_many (g bigint, v bigint);
insert into agg_many select i, i from generate_series(1,5000000) i;

그룹 100개짜리는 예상대로 병렬 계획이 나왔습니다.

Finalize GroupAggregate (actual time=851.515..855.136 rows=100.00)
  ->  Gather Merge (actual time=851.509..855.094 rows=400.00)
        Workers Planned: 3
        Workers Launched: 3
        ->  Sort (actual time=837.048..837.052 rows=100.00 loops=4)

Gather Merge가 400행을 올리고 Finalize가 4ms 안에 끝납니다. 워커 넷이 각각 100개 그룹을 만들었으니 정확히 400행입니다.

그룹 500만개에서는 계획 자체가 달라졌습니다.

HashAggregate (actual time=3860.148..8242.441 rows=5000000.00)
  Group Key: g
  Batches: 17  Memory Usage: 135313kB  Disk Usage: 161920kB
  ->  Seq Scan on agg_many (actual time=0.023..569.741 rows=5000000.00)
Execution Time: 8488.126 ms

병렬이 아예 없습니다. planner가 워커를 하나도 쓰지 않기로 결정했습니다. 비용 모형이 이미 "이 경우 병렬 집계는 손해"라고 판단한 것입니다. 저자가 지적한 문제를 planner가 회피하는 방식으로 대응하고 있다는 뜻입니다.

그래서 억지로 병렬을 켜 봤습니다. parallel_setup_cost와 parallel_tuple_cost를 0으로 낮췄습니다.

HashAggregate (actual time=2438.858..6180.438 rows=5000000.00)
  Batches: 17  Memory Usage: 135313kB  Disk Usage: 161936kB
  ->  Gather (actual time=0.263..300.906 rows=5000000.00)
        Workers Planned: 3
        Workers Launched: 3

여기가 이 실험에서 가장 선명한 부분입니다. Gather가 500만 행을 300ms에 올립니다. 읽기는 병렬로 잘 됐습니다. 그런데 그 위의 HashAggregate가 6,180ms를 씁니다. 스캔은 병렬인데 집계는 단일 프로세스입니다.

주목할 것은 Partial HashAggregate가 아예 붙지 않았다는 점입니다. 그룹이 너무 많아 부분 집계가 아무 이득이 없다고 보고, 워커는 스캔만 하고 집계 전부를 리더에게 넘겼습니다. 저자가 지적한 "단일 프로세스 병목"이 계획에 그대로 나타납니다.

디스크 spill도 눈에 걸립니다. work_mem을 64MB로 뒀는데 17개 batch로 나뉘고 161MB를 디스크에 썼습니다. 리더 하나가 500만 그룹의 해시 테이블을 메모리에 못 담아서입니다. 워커들이 나눠 담았다면 각자 125만 그룹이니 상황이 달랐을 것입니다.

프로토타입: 공유 해시 테이블​

저자가 만든 것은 DSM(Dynamic Shared Memory)에 해시 테이블 하나를 두고, 모든 워커가 lock을 잡고 그 테이블을 갱신하는 방식입니다. 부분 집계와 Finalize 단계가 통째로 사라집니다.

구현 규모가 이 실험의 성격을 보여 줍니다. nodeAgg.c 밖에 약 800줄, planner에 약 600줄(비용 모형과 적용 여부 판단), executor 코어에 일곱 줄이 들어갔습니다. nodeAgg.c에서 가져와 고친 static 함수가 여덟 개입니다.

새로 만들어야 했던 것들이 있습니다. Parallel Hash Join의 해시 테이블 설계를 재사용할 수 없어서 전용 해시 테이블을 만들었습니다. numeric이나 text처럼 가변 타입의 상태를 다루려고 DSM 안팎으로 복사하는 계층을 별도로 짰습니다. 메모리 한도 계산은 로컬에 모았다가 일괄 반영하는 방식으로 처리했고, 집계 함수마다 공유 방식이 안전한지 표시하는 aggsharedsafe 플래그를 새로 넣었습니다.

기존 기계장치도 꽤 썼습니다. spill 처리에 SharedTuplestore, by-value 상태에 32KB 단위 DSA 할당자, 단계 동기화와 임시 파일, 그리고 대기 이벤트 다섯 개와 LWLock tranche 두 개입니다.

균등 분포에서는 통한다​

측정은 GCP VM에서 했습니다. 48코어를 주로 쓰고 16코어, 14코어도 함께 봤습니다. 전부 메모리 안에서 돌았고 디스크 spill은 없었습니다.

그룹이 고르게 분포하고 워커가 8개일 때 결과입니다. by-value 집계는 약 4.8배, numeric 같은 by-reference 집계는 약 2.0배 빨라졌습니다. 같은 조건에서 두 배 차이가 나는 이유가 DSM 안팎으로 상태를 복사하는 비용입니다.

집계 함수 개수를 늘려 보면 곡선이 나옵니다. 그룹당 집계 2개면 4.64배, 12개면 5.80배로 정점을 찍고, 32개가 되면 4.40배로 내려갑니다. lock을 한 번 잡고 여러 집계를 갱신하니 개수가 늘면 lock 비용이 분산되고, 너무 늘면 critical section이 길어져 다시 나빠집니다.

skew에서 무너진다​

문제는 여기입니다. 한 그룹이 전체를 얼마나 차지하는지에 따라 결과가 이렇게 변합니다.

95%에서 0.04배는 25배 느려진다는 뜻입니다. 이유가 명확합니다. 모든 워커가 같은 그룹의 상태를 갱신하려고 같은 lock을 두고 줄을 섭니다. 병렬이 아니라 순차가 되고, 여기에 lock 획득 비용이 얹힙니다.

현실 데이터에서 흔한 80대 20 분포에서는 by-value 집계가 대략 동등, by-reference는 통상적인 워커 수에서 이득이 거의 없었습니다. 실무 데이터가 대개 고르지 않다는 점을 생각하면 이 결과가 결정적입니다.

세 가지 장애물​

저자는 lock 경합 자체보다 더 근본적인 문제 셋을 지목했습니다.

첫째, LWLock의 입도입니다. "LWLock은 이 크기의 critical section에 맞는 primitive가 아니다"라고 적었습니다. count(*)조차 나노초 단위 증가 연산을 하려고 마이크로초 단위 LWLockAcquire()를 부릅니다. 보호하려는 작업보다 보호 장치가 비쌉니다.

둘째, JIT 컴파일이 불가능해집니다. 지금의 비공유 경로는 ExecBuildAggTrans()가 만든 마이크로프로그램 하나를 JIT으로 함수 하나로 컴파일합니다. 공유 경로에서는 lock을 잡기 전에 인자를 계산하고 lock 안에서 transition 함수를 호출해야 하니, 이 통합 컴파일이 성립하지 않습니다. 병렬로 얻은 이득을 컴파일 손실로 반납하는 구조입니다.

셋째, lock 안에서 임의 코드가 돕니다. enum_cmp_internal() 같은 함수는 카탈로그를 조회하고, 그 과정에서 table_open()과 buffer 읽기가 일어날 수 있습니다. LWLock을 잡은 상태에서 다른 lock을 잡는 상황이 만들어집니다.

프로세스 모델이 청구서를 보낸다​

저자의 결론 문장이 셉니다. "프로세스 모델이 공유 모델로 가는 길의 주된 장애물이다."

스레드 기반 엔진과 비교하면 차이가 구체적입니다. DSM 안에서는 직접 포인터를 쓸 수 없어서 palloc, repalloc, MemoryContext를 쓸 수 없습니다. by-reference 상태는 복사해 넣고 복사해 나와야 합니다. TOAST를 제자리에서 압축 해제할 수 없습니다. 집계 함수 구현이 표준적인 가변 상태 패턴을 쓸 수 없습니다.

정리하면 이렇습니다. "PostgreSQL은 스레드를 가진 엔진보다 공유 가변 상태에 훨씬 많은 값을 치르고, 돌려받는 것은 같다."

pgrust가 Volcano 모델의 청구서를 뜯어 보여 준 이야기와 같은 종류의 결론입니다. 30년 전에 정한 실행 모델이 지금 어떤 최적화를 막고 있는지 확인하는 작업입니다. Momjian이 짚은 코어의 빈칸들에도 같은 성격의 항목이 여럿 있었습니다.

그럼 어디에 쓸까​

저자는 포기하지 않고 적용 범위를 좁히자고 제안합니다.

고정 폭 by-value 상태로 한정합니다. count, sum(integer), sum(float)이 여기 들어갑니다. 이런 상태는 원자적 병합 연산 하나로 처리할 수 있으니 lock 없이 갱신할 수 있습니다. 위 세 장애물 중 첫째와 둘째가 상당히 완화됩니다.

그리고 MCV 통계로 skew를 미리 감지해 병리적인 경우를 피합니다. planner가 pg_stats의 most common values를 보고 "이 그룹 키는 한 값이 지배적이다"라고 판단하면 공유 방식을 고르지 않는 식입니다. 통계가 이미 있는 정보라서 추가 비용이 낮습니다.

더 유망한 쪽으로 두 곳을 꼽았습니다. SetOp 연산자는 현재 병렬화가 아예 없습니다. 그리고 단순 SELECT DISTINCT입니다. 둘 다 by-reference 상태의 복잡성이 걸리지 않는 영역입니다.

남는 생각​

이 글의 값은 4.8배라는 숫자가 아니라 그 숫자가 왜 못 남는지에 있습니다. 균등 분포 벤치마크만 보면 도입할 이유가 충분해 보이는데, skew 하나로 25배 역행이 나옵니다. 벤치마크 조건을 고르는 일이 결과 자체보다 중요하다는 사례입니다.

제 실측에서 planner가 500만 그룹에 병렬을 아예 안 붙인 것도 같은 맥락으로 읽힙니다. 비용 모형이 이미 이 지점을 알고 회피하고 있습니다. 새 실행 방식을 넣는다면 planner가 그것을 언제 고를지 판단하는 부분이 구현의 절반이 됩니다. 저자가 planner에 600줄을 쓴 이유겠죠.

참고​

• Do Global Hash Tables Strike Back in PostgreSQL? (Andrei Lepikhov, pgEdge, 2026-08-20)
• PostgreSQL 병렬 계획 문서
• PostgreSQL 집계 함수 확장 문서

일주일 전에 pg_walviz로 WAL segment 내부를 들여다봤는데, 같은 저자가 이번엔 공유 메모리를 열었어요. Bertrand Drouvot(베르트랑 드루보)이 2026년 8월 20일 pg_shmemviz v0.1.0-beta.1을 공개했습니다.

두 도구의 성격이 닮았습니다. 이미 있는 뷰로도 요약은 볼 수 있는데, 정작 "그게 메모리 어디에 어떤 모양으로 놓여 있나"는 안 보인다는 문제를 같은 방식으로 풉니다. 스냅샷을 떠서 브라우저에서 바이트 단위로 걸어 다니게 하는 방식입니다.

pg_shmem_allocations는 어디까지 보여 주나​

먼저 기존 뷰의 한계를 실측으로 확인했습니다. PostgreSQL 18 컨테이너를 기본 설정으로 띄우고 pg_shmem_allocations를 조회했습니다.

$ docker run -d --name shmemtest -e POSTGRES_PASSWORD=pw postgres:18
$ docker exec shmemtest psql -U postgres -Atc "show shared_buffers"
128MB

select name, off, size, allocated_size
  from pg_shmem_allocations
 order by size desc limit 8;

         name         |    off    |   size    | allocated_size
----------------------+-----------+-----------+----------------
 Buffer Blocks        |   6785664 | 134221824 |      134221824
 <anonymous>          |           |   4747776 |        4747776
 XLOG Ctl             |     60928 |   4208200 |        4208256
 AioHandleIOV         | 150482816 |   2850816 |        2850816
                      | 154760064 |   2280576 |        2280576
 AioHandle            | 148879232 |   1603584 |        1603584
 AioHandleData        | 153333632 |   1425408 |        1425408
 Buffer Descriptors   |   5737088 |   1048576 |        1048576

전체는 75개 항목, 합계 150MB였습니다. 여기서 볼 수 있는 것과 볼 수 없는 것이 꽤 선명하게 갈립니다.

보이는 것은 이름, 시작 오프셋, 요청 크기, 실제 할당 크기입니다. XLOG Ctl이 4,208,200바이트를 요청했는데 4,208,256바이트가 할당된 것을 보면 56바이트가 정렬 때문에 붙었다는 사실까지는 읽힙니다. PostgreSQL 18에서 비동기 I/O가 들어오면서 AioHandle, AioHandleIOV, AioHandleData 세 항목이 합쳐 5.8MB를 차지하는 것도 확인됩니다. 비동기 I/O 글에서 다룬 io_uring 구조가 메모리에서 이 정도 자리를 쓴다는 뜻입니다.

안 보이는 것이 문제입니다. 위 출력에서 이름 칸이 빈 행이 하나 있는데, 이건 아직 아무에게도 배정되지 않은 여유 공간입니다. <anonymous>는 이름 없이 잡힌 익명 할당이라 오프셋조차 안 나옵니다. 그리고 XLOG Ctl 안에 XLogCtlData 구조체의 어떤 필드가 몇 번째 바이트에 앉아 있는지, 필드 사이에 컴파일러가 끼워 넣은 padding이 몇 바이트인지는 이 뷰의 관심사가 아닙니다.

정리하면 이렇습니다.

실행 중인 서버에 붙지 않고 구조체를 읽는 방법​

여기가 이 도구에서 가장 흥미로운 부분입니다. 공유 메모리의 바이트 배열을 읽는 것 자체는 어렵지 않습니다. 어려운 건 그 바이트가 무슨 구조체의 어느 필드인지 알아내는 일입니다. 그 정보는 소스 코드에만 있고 실행 중인 서버의 메모리에는 없습니다.

pg_shmemviz는 이 문제를 postgres 실행 파일의 DWARF 디버그 정보로 해결합니다. 컴파일된 바이너리에는 각 구조체의 필드 이름, 타입, 오프셋이 DWARF 형식으로 들어 있습니다. macOS에서는 LLDB, 그 외 환경에서는 GDB를 써서 이 메타데이터를 읽습니다. 중요한 건 디버거를 실행 중인 서버에 attach하지 않는다는 점입니다. 실행 파일의 메타데이터만 읽습니다.

복사 단계에는 lock을 걸지 않습니다. 덕분에 서버를 멈추지 않지만, 대가가 있습니다. 스냅샷 안의 필드들이 서로 다른 순간의 값일 수 있습니다. 저자도 이 점을 문서에 명시했습니다. 그러니 "이 두 카운터의 차이가 정확히 몇인가"를 따지는 용도로는 맞지 않고, 구조와 배치를 파악하는 용도입니다.

설치와 사용​

extension과 CLI 두 부분으로 되어 있습니다.

cd ~/pg_shmemviz
make PG_CONFIG=/path/to/postgres-install/bin/pg_config
make PG_CONFIG=/path/to/postgres-install/bin/pg_config install

psql -d postgres -c 'CREATE EXTENSION pg_shmemviz'

스냅샷을 뜨는 명령입니다.

~/pg_shmemviz/bin/pg_shmemviz capture \
  --pg-config /path/to/postgres-install/bin/pg_config \
  --dbname postgres \
  /path/to/new-snapshot

뜬 스냅샷을 브라우저로 봅니다. 기본값은 127.0.0.1:8765이고 로컬 브라우저가 열립니다.

~/pg_shmemviz/bin/pg_shmemviz serve /path/to/new-snapshot

원격 서버에서 뜬 스냅샷을 SSH 포트 포워딩으로 볼 때는 브라우저 자동 실행을 끕니다.

~/pg_shmemviz/bin/pg_shmemviz serve --no-open --port 8765 /path/to/new-snapshot

화면이 보여 주는 것​

뷰가 여러 개인데 서로 연동됩니다. 한쪽에서 할당을 고르면 다른 쪽이 같은 지점을 따라갑니다.

공유 메모리 맵은 main segment와 DSM, DSA 영역을 통틀어 이름 있는 할당, padding, 미사용 구간을 늘어놓습니다. 위 실측에서 이름 칸이 비어 있던 2.2MB가 어디에 어떤 이웃과 붙어 있는지가 여기서 드러납니다.

Structure Fields 패널이 이 도구의 핵심입니다. 중첩된 C 구조체를 펼쳐 필드별 오프셋과 값, 컴파일러가 끼운 padding, 배열의 stride padding을 보여 줍니다. 경계를 알 수 있는 포인터는 가리키는 영역을 참조 구간으로 표시합니다. 통계, WAL, 프로세스 배열, SLRU, dynahash, DSM registry 같은 PostgreSQL 특유의 구조에는 전용 해석이 들어가 있습니다.

Physical Bytes 뷰는 주소, 오프셋, 값, 어느 구조체 필드에 속하는지, 어느 NUMA 노드에 놓였는지를 함께 보여 주는 바이트 창입니다. Buffer Cache 뷰는 선택 사항인데, buffer별 식별자와 database, relation, fork, block 번호, 그리고 그 buffer를 pin하고 있는 backend까지 나옵니다. pg_buffercache로 보던 내용을 물리적 배치 위에 겹쳐 놓은 셈입니다.

NUMA 노드가 여러 개인 장비에서는 페이지 배치를 그림으로 봅니다. pg_shmem_allocations_numa 뷰가 숫자로 알려 주던 것을 눈으로 확인하는 용도입니다.

스냅샷 두 개를 비교한다​

이 기능이 실무 관점에서 가장 쓸모 있어 보입니다. 서로 다른 시점의 스냅샷 두 개를 나란히 열어 할당 단위, 필드 단위, 바이트 단위로 차이를 봅니다.

~/pg_shmemviz/bin/pg_shmemviz serve \
  /path/to/before-snapshot \
  /path/to/after-snapshot

설정 하나를 바꿨을 때 공유 메모리가 실제로 어떻게 달라지는지 확인하는 데 쓸 수 있습니다. 위 실측에서 PostgreSQL 18의 AIO 관련 세 할당이 5.8MB를 차지했는데, io_method를 바꾸기 전후로 스냅샷을 떠서 비교하면 그 5.8MB의 내부 구성이 어떻게 변하는지가 필드 단위로 보일 것입니다.

운영 인스턴스에서는 쓰지 않는다​

저자가 문서 앞쪽에 강하게 못 박은 부분이라 그대로 옮깁니다.

Do not run pg_shmemviz on a production PostgreSQL instance.

이유가 몇 겹입니다. 스냅샷은 공유 메모리 전체를 복사한 파일이라 크고, 그 안에 실제 데이터가 그대로 들어갑니다. buffer에 올라온 테이블 내용이 파일로 떠지는 셈이니 민감 정보가 그대로 흘러나갑니다. viewer에는 인증도, 권한 검사도, TLS도 없습니다. loopback 밖으로 내보내면 안 됩니다.

구조체 해석에는 캡처한 서버가 쓰던 것과 정확히 같은 postgres 실행 파일이 필요합니다. 빌드가 다르면 필드 오프셋이 어긋나 엉뚱한 값을 읽습니다. 검증은 PostgreSQL 20devel 기준으로 되어 있고, 어느 버전까지 되는지는 저장소 README를 봐야 합니다. 제가 위에서 실측한 PostgreSQL 18 컨테이너 이미지에는 디버그 정보가 없으니, 실제로 붙여 보려면 디버그 심볼을 켜서 직접 빌드한 인스턴스가 필요합니다.

어디에 쓰면 좋을까​

용도가 좁습니다. 운영 진단 도구가 아니고, extension이나 코어 패치를 개발하면서 "내가 잡은 공유 메모리 구조가 실제로 어떻게 배치됐나"를 확인하는 도구입니다. 그리고 학습 자료로서의 가치가 따로 있습니다. XLogCtlData나 PGPROC 배열이 메모리에서 어떤 모양인지 소스만 읽어서 상상하던 것을 눈으로 확인하는 경험은 소스 독해 속도를 꽤 올려 줍니다.

PostgreSQL 내부를 3D 도시로 걸어 본 글에서 시각화 도구가 학습에 어떤 도움이 되는지 이야기했는데, pg_shmemviz는 그보다 훨씬 실무 쪽에 가깝습니다. 비유가 아니라 실제 주소와 실제 바이트를 보여 주니까요.

pg_walviz와 pg_shmemviz가 한 주 간격으로 나왔습니다. 저는 이 흐름이 반갑습니다. PostgreSQL 내부는 소스를 읽을 수 있는 사람에게만 열려 있었는데, 그 문턱을 낮추는 도구가 늘고 있어요.

참고​

• pg_shmemviz 공개 글 (Bertrand Drouvot, 2026-08-20)
• pg_shmemviz 저장소
• pg_shmem_allocations 공식 문서

Claude Code 응답에서 제일 자주 걸러내고 싶은 게 뭘까요. 저는 "먼저 파일을 확인해 보겠습니다" 같은 예고 문장이었어요. v2.1.237에 그걸 기본으로 지워 주는 출력 스타일이 들어왔습니다.

이름은 Concise입니다. 변경 로그 한 줄은 이렇습니다.

Added built-in "Concise" output style: Claude leads with results, skips preamble/narration, works thoroughly

내장 스타일이 다섯 개가 됐다​

출력 스타일은 원래 Default에 Explanatory와 Learning 둘이 붙은 구성이었습니다. 지금은 Proactive와 Concise가 더해져 Default 외에 네 개입니다.

Concise를 두고 오해하기 쉬운 부분이 하나 있습니다. 짧게 답하라는 게 작업을 덜 하라는 뜻은 아닙니다. 공식 문서는 "doing the engineering work as thoroughly as in the Default style"이라고 적어 뒀습니다. 설명을 요청하면 그때는 길게 답합니다. 그리고 짧게 만들지 않는 예외가 정해져 있습니다. 오류 보고, 보안 경고, 파괴적 작업의 확인 문구는 내용을 온전히 유지합니다. 이 예외 목록이 있다는 게 스타일 설계에서 제일 중요한 부분이라고 봅니다. 짧게 쓰다가 위험 신호를 줄여 버리면 절약이 아니라 사고니까요.

Proactive는 성격이 좀 다릅니다. 톤이 아니라 행동 방침을 바꿉니다. auto mode보다 강한 자율 실행 지침인데, 권한 모드는 그대로 둡니다. 무엇을 물어보지 않고 실행할지는 여전히 권한 모드가 결정하고, Proactive는 "판단을 사용자에게 넘기지 말고 스스로 하라"는 쪽만 건드립니다.

스타일을 바꾸는 방법이 달라졌다​

여기서 한 번 헤맬 수 있습니다. /output-style 명령이 없어졌습니다. v2.1.73에서 deprecated 되고 v2.1.91에서 제거됐습니다. 지금은 두 가지 방법뿐입니다.

터미널에서는 /config를 실행해 Output style 항목에서 고릅니다. 선택 결과는 프로젝트 로컬 설정 파일에 저장됩니다.

.claude/settings.local.json

설정 파일을 직접 고쳐도 됩니다.

{
  "outputStyle": "Concise"
}

데스크톱 앱에서는 /config가 메뉴 대신 Settings 화면을 엽니다. 그래서 데스크톱에서는 위 필드를 직접 넣는 쪽이 확실합니다.

바꾼 뒤 바로 안 바뀐다고 당황하지 않아도 됩니다. 출력 스타일은 시스템 프롬프트의 일부이고, 시스템 프롬프트는 세션이 시작할 때 한 번 읽습니다. /clear를 실행하거나 새 세션을 열어야 적용됩니다.

CLAUDE.md와 어디서 갈라지나​

이게 문서에서 가장 값이 나가는 대목입니다. 둘 다 "Claude가 이렇게 행동하게 만드는 장치"인데 붙는 위치가 다릅니다.

출력 스타일은 시스템 프롬프트 끝에 붙습니다. CLAUDE.md는 시스템 프롬프트 뒤에 오는 user message로 들어갑니다. 이 차이가 실무에서 세 갈래 결과를 만듭니다.

첫째, 커스텀 출력 스타일은 기본 소프트웨어 엔지니어링 지침을 빼 버립니다. 변경 범위를 어떻게 잡고, 주석을 어떻게 쓰고, 작업을 어떻게 검증하라는 내장 지침 전체가 사라집니다. 그걸 유지하려면 frontmatter에 keep-coding-instructions: true를 넣어야 합니다. 기본값이 false라는 걸 모르고 커스텀 스타일을 만들면, 톤만 바꾸려던 게 코딩 행동까지 바꿔 버립니다.

둘째, 서브에이전트에는 적용되지 않습니다. 서브에이전트는 자기 시스템 프롬프트로 돕니다. 예외가 fork인데, fork는 부모의 시스템 프롬프트를 통째로 물려받기 때문입니다. Concise로 세션을 돌리면서 서브에이전트에게 요약을 맡겼는데 서브에이전트 응답이 장황한 이유가 여기 있습니다.

셋째, 프롬프트 캐시입니다. 시스템 프롬프트가 바뀌면 캐시 접두사가 깨집니다. 토큰 절약 가이드 글에서 모델과 effort를 세션 시작 시점에 고정하라는 권고를 다뤘는데, 출력 스타일도 같은 부류의 설정입니다. 세션 도중에 바꿀 값이 아닙니다.

커스텀 스타일은 파일 하나다​

내장 다섯 개로 부족하면 마크다운 파일을 만듭니다. 위치는 세 곳이고, 파일명이 스타일 이름이 됩니다. frontmatter에 name을 적으면 그쪽이 이깁니다.

~/.claude/output-styles/          # 사용자 전역
.claude/output-styles/            # 프로젝트

공식 문서 예시가 성격을 잘 보여 줍니다.

---
name: Diagrams first
description: Lead every explanation with a diagram
keep-coding-instructions: true
---

When explaining code, architecture, or data flow, start with a Mermaid diagram
showing the structure, then explain in prose.

프로젝트 스타일은 작업 디렉터리부터 저장소 루트까지의 모든 .claude/output-styles/에서 읽습니다. 같은 이름이 여러 층에 있으면 작업 디렉터리에 가까운 쪽이 이깁니다. 플러그인도 output-styles/ 디렉터리로 스타일을 배포할 수 있는데, 플러그인 전용 필드인 force-for-plugin: true를 켜면 사용자의 outputStyle 설정을 덮어쓰고 강제 적용됩니다. 플러그인을 깔았는데 응답 톤이 갑자기 변했다면 이 필드를 의심해 볼 만합니다.

frontmatter 필드는 네 개입니다.

토큰은 어느 쪽으로 움직이나​

방향이 둘로 갈립니다. 입력 토큰은 스타일 지침이 시스템 프롬프트에 붙는 만큼 늘어납니다. 다만 첫 요청 이후에는 프롬프트 캐시가 이 비용을 상당히 덮습니다. 출력 토큰은 스타일이 결정합니다. Explanatory와 Learning은 설계상 응답이 길어지고, Concise는 반대로 갑니다.

그러니 Concise의 절약 효과는 출력 쪽입니다. 응답 길이가 짧아지는 만큼 출력 토큰이 줄고, 그 짧은 응답이 다음 턴의 입력으로 다시 들어가니 대화가 길어질수록 차이가 누적됩니다. 반대로 Learning 스타일로 긴 세션을 돌리면 그 반대 방향으로 누적됩니다. 제가 지금 이 글을 쓰는 세션이 Learning 스타일인데, 확실히 응답 길이가 기본보다 깁니다.

같은 주에 들어온 나머지​

Concise만 있던 주가 아닙니다. v2.1.234에 실무에서 체감될 항목이 둘 붙었습니다.

사용량 한도 자동 재개입니다. claude.ai 사용량 한도가 초기화되면 세션을 자동으로 이어서 진행합니다. /config에서 켜고 끕니다. 장시간 작업을 돌려 두고 자리를 비우는 사용 방식이라면 이 항목 하나로 흐름이 달라집니다. Routines처럼 사람이 안 보는 동안 도는 작업과 결이 같습니다.

GitLab merge request 배지도 들어왔습니다. GitLab remote가 걸린 저장소에서 glab으로 인증돼 있으면 MR !N 형태로 draft, pending, green 상태를 상태줄에 표시합니다. GitHub PR 배지만 있던 자리에 GitLab이 붙은 셈입니다.

이후 버전도 흐름이 이어집니다. v2.1.238에는 커스텀, 프로젝트, 플러그인 출력 스타일이 세션 도중에 기본 목소리로 되돌아가던 버그 수정이 들어갔습니다. 출력 스타일 자체를 손보는 작업이 한 주 내내 계속됐다는 뜻입니다. v2.1.239에서는 사용량 한도 안내가 세션, 주간, 월간 중 무엇이 초기화되는지 구분해 알려 주게 바뀌었습니다.

어떤 스타일로 쓸까​

정답은 작업 성격에 달렸습니다. 제 기준으로는 이렇게 갈립니다.

익숙한 코드베이스에서 반복 작업을 돌릴 때는 Concise가 맞습니다. 무엇을 할지 이미 알고 있으니 예고가 필요 없습니다. 처음 보는 코드베이스를 파악하는 중이라면 Explanatory가 낫습니다. "왜 이 파일을 골랐나"가 정보이기 때문입니다. 새 기술을 배우려고 붙었다면 Learning이 값을 합니다. TODO(human) 표시가 남으면 직접 손을 대야 하고, 그 지점이 대개 판단이 필요한 자리입니다.

Proactive는 조심스럽습니다. 권한 모드를 안 건드린다지만 "묻지 말고 판단하라"는 지침 자체가 리스크입니다. 되돌리기 쉬운 작업에만 쓰는 쪽이 안전합니다.

그리고 이 다섯 개는 서로 배타적입니다. 한 세션에 하나만 걸립니다. 작업 성격이 바뀌면 /clear하고 다시 고르는 게 정석입니다.

참고​

• Claude Code CHANGELOG
• Output styles 공식 문서
• Permission modes 공식 문서

에이전트에게 "이 PDF 읽고 저 웹 포털에 대신 입력해 줘"를 시키는 데 필요한 조각이 셋인데, 그 셋이 같은 날 정식 출시됐습니다. 2026년 8월 20일입니다.

Anthropic이 computer use, Skills API, Files API 세 가지의 정식 출시를 발표했습니다. 각각 따로 보면 기능 추가인데, 셋을 붙여 놓으면 성격이 달라집니다.

세 조각이 각각 맡는 일​

발표문이 든 예시가 구성을 잘 보여 줍니다. 보험 청구 처리 에이전트입니다. Files API에서 접수 문서를 읽고, 팀의 접수 절차를 담은 skill을 따라, browser use tool로 보험사 웹 포털에서 제출을 마치고, 확인서를 다시 파일로 저장합니다.

역할 분담이 사람의 업무 구조와 닮았습니다. 문서, 절차서, 그리고 소프트웨어를 조작하는 손입니다. 지금까지는 이 셋 중 손 쪽이 가장 불안했습니다.

computer use: 도구 식별자가 toolset으로 바뀌었다​

여기가 실무에서 가장 먼저 걸리는 부분입니다. 도구 타입 문자열이 바뀌었습니다.

{
  "type": "computer_toolset_20260801",
  "name": "computer"
}

Claude API에서는 beta 헤더가 필요하지 않습니다. 이전 버전인 computer_20251124는 anthropic-beta: computer-20251124-api 헤더가 필요했고, 지금은 구형 모델용으로 남았습니다.

지원 모델이 갈립니다. computer_toolset_20260801은 claude-opus-5, claude-sonnet-5, claude-opus-4-8, claude-fable-5, claude-mythos-5에서 동작합니다. Opus 4.7과 4.6, Sonnet 4.6, Opus 4.5는 이전 computer_20251124를 써야 합니다.

파라미터에서 사라진 게 하나 있습니다. 화면 너비와 높이입니다. 이전 버전은 display_width_px 같은 값을 받았는데, computer_toolset_20260801은 받지 않습니다. 좌표를 돌려주는 스크린샷에서 직접 읽습니다. 기존 코드를 옮길 때 이 두 파라미터를 그대로 두면 거부됩니다.

이름이 tool에서 toolset으로 바뀐 이유는 안에 든 것이 하나가 아니기 때문입니다. member tool이 17개입니다.

zoom이 눈에 띕니다. 지정한 영역을 원본 해상도로 다시 캡처합니다. 전체 화면 스크린샷은 축소되어 작은 글자를 놓치기 쉬운데, 그 문제를 영역 재촬영으로 풉니다. hold_key와 wait는 최대 300초까지 받습니다.

turn당 한 동작에서 여러 동작으로​

베타에서 정식 출시로 오면서 가장 크게 바뀐 지점입니다. 이전에는 모델 호출 한 번에 동작 하나였습니다. 지금은 한 응답에 여러 tool_use 블록을 담습니다.

로그인 폼을 채우는 작업을 생각해 보면 차이가 큽니다. 아이디 칸 클릭, 입력, 비밀번호 칸 클릭, 입력, 로그인 클릭이면 모델 호출 5회였던 것이 1회가 됩니다. 지연과 비용이 함께 줄어듭니다.

대신 실패 처리 규칙을 알아야 합니다. 동작은 순서대로 실행되고 첫 실패에서 멈춥니다. 실행되지 않은 나머지 동작에는 이런 결과를 돌려줘야 합니다.

{
  "type": "tool_result",
  "tool_use_id": "toolu_01...",
  "toolset_name": "computer",
  "is_error": true,
  "content": "Not executed: an earlier computer action in this turn failed."
}

toolset_name 필드가 모든 결과에 들어가야 합니다. 값은 "computer"입니다. 예전 방식으로 tool_use_id와 content만 채우면 통과하지 않습니다.

한 동작씩 진행하고 싶으면 병렬 도구 사용을 끕니다.

{
  "tool_choice": { "type": "tool", "disable_parallel_tool_use": true }
}

화면 상태를 매 단계 확인해야 하는 작업이라면 이쪽이 안전합니다. 화면이 예상과 달라졌는데 나머지 클릭이 그대로 나가면 엉뚱한 곳을 누릅니다.

browser use tool은 여기서 한 겹 더 갑니다. 픽셀 좌표만 쓰는 것보다 웹 요소를 안정적으로 겨냥하도록 페이지 구조 분석을 더했습니다. 웹 애플리케이션만 다룰 거라면 이쪽이 맞습니다.

의료 쪽 이야기도 붙었습니다. computer use가 BAA 아래 HIPAA 규제 대상 워크로드에 쓸 수 있게 됐습니다.

Skills API: skill이 저장 객체가 됐다​

Claude Code의 Skills를 다룬 적이 있는데, 그때는 로컬 디렉터리에 마크다운 파일을 두는 구조였습니다. 이제 API 층으로 올라와 저장되고 버전이 붙는 객체가 됐습니다.

skill은 지시문과 스크립트, 템플릿이 든 폴더입니다. 작업이 필요할 때만 Claude가 읽어 들이고, Claude의 코드 실행 sandbox 안에서 돕니다. 직접 호스팅할 서버가 없습니다.

엔드포인트 구성입니다.

POST   /v1/skills                                    # 생성 (multipart/form-data)
GET    /v1/skills                                    # 목록
GET    /v1/skills/{skill_id}                         # 조회
DELETE /v1/skills/{skill_id}                         # 삭제
POST   /v1/skills/{skill_id}/versions                # 새 버전 업로드
GET    /v1/skills/{skill_id}/versions                # 버전 목록
GET    /v1/skills/{skill_id}/versions/{version}      # 버전 조회
DELETE /v1/skills/{skill_id}/versions/{version}      # 버전 삭제

버전 참조에 latest 리터럴을 쓸 수 있습니다. latest_version_id 필드가 가리키는 곳으로 해석됩니다. 다만 skills-2025-10-02 beta 헤더를 붙인 요청은 버전을 Unix epoch 타임스탬프로 주소지정합니다. 예시가 "1759178010641129" 형태입니다. beta 경로와 정식 경로에서 버전 식별 방식이 다르니 여기서 한 번 헤맬 수 있습니다.

name 필드의 성격이 중요합니다. 첫 업로드의 SKILL.md frontmatter에 있는 name(없으면 그 폴더 이름)에서 kebab-case slug로 정해지고, 이후 바뀌지 않습니다. 나중 업로드도 같은 값으로 해석돼야 합니다. 이 slug가 마운트된 파일의 최상위 디렉터리 이름이 되고, 내려받을 때 아카이브 파일명이 됩니다.

skill의 출처는 네 종류로 구분됩니다.

요청에 붙이는 방법에서 혼동이 잘 생깁니다. Skills를 쓰려면 세 가지를 함께 넣습니다.

client.beta.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    container={"skills": [{"skill_id": "skill_01...", "version": "latest"}]},
    tools=[{"type": "code_execution_20260521", "name": "code_execution"}],
    betas=["code-execution-2025-08-25", "skills-2025-10-02"],
    messages=[...],
)

container에 skill을 얹고, 코드 실행 도구를 선언하고, beta 두 개를 붙입니다. skill이 sandbox 안에서 도니까 코드 실행 도구가 함께 필요합니다.

Managed Agents와 헷갈리지 않기​

여기가 정말 자주 어긋나는 지점입니다. Skills는 Managed Agents가 아닙니다.

Managed Agents는 별개 표면입니다. POST /v1/agents로 에이전트 설정을 저장해 두고, 세션을 만들어 실행합니다. 세션마다 컨테이너가 workspace로 할당되고 에이전트 루프 자체를 Anthropic이 돌립니다. beta 헤더도 다릅니다. managed-agents-2026-04-01입니다.

반면 Skills로 문서를 만들게 하려면 위처럼 client.beta.messages.create에 container와 코드 실행 도구를 얹으면 끝입니다. client.beta.agents나 세션 API를 쓰는 게 아닙니다. Skills가 Managed Agents 안에서도 쓰이기 때문에 문서를 훑다 보면 두 경로가 섞여 보입니다.

Files API: 한 번 올리고 ID로 부른다​

성격은 단순합니다. PDF나 스프레드시트를 한 번 올려 두고, 이후 요청에서는 다시 보내지 않고 ID로 참조합니다.

POST /v1/files

beta 헤더는 files-api-2025-04-14입니다. 업로드할 때와, 그 파일을 참조하는 messages.create 양쪽에 모두 붙여야 합니다. 한쪽만 붙이면 실패합니다.

참조할 때는 content block 타입이 파일의 MIME 타입과 맞아야 합니다.

{
  "type": "document",
  "source": { "type": "file", "file_id": "file_01..." }
}

PDF와 텍스트는 document, 이미지는 image입니다.

정식 출시로 오면서 늘어난 것이 셋입니다. 파일 자동 만료가 들어왔고, rate limit이 5배로 올랐고, 조직당 저장 용량이 1TB가 됐습니다. 자동 만료는 편의 기능처럼 보이지만 실무에서는 정리 부담을 덜어 줍니다. 업로드해 둔 파일을 지우는 코드를 따로 관리하지 않아도 됩니다.

base64로 PDF를 매번 실어 보내는 방식과 비교하면 차이가 분명합니다. base64 경로는 요청 32MB, 600페이지 제한이 걸립니다. 같은 문서를 여러 번 물어볼 거라면 매 요청마다 그 크기를 다시 전송하는 셈입니다.

어디서 쓸 수 있나​

플랫폼마다 갈립니다. 세 기능 모두 Claude 플랫폼에서 쓸 수 있습니다. Skills API와 Files API는 Microsoft Foundry에서도 접근됩니다. computer tool과 browser tool은 Google Cloud Vertex AI에 들어올 예정입니다.

computer use는 플랫폼별로 버전이 다릅니다. computer_toolset_20260801 전체 지원은 Claude API고, Claude Platform on AWS와 Bedrock, Google Cloud, Foundry는 이전 버전이 beta로 올라가 있습니다. 특정 클라우드에 묶여 있다면 도구 식별자와 모델을 같이 확인해야 합니다.

무엇이 실제로 달라지나​

세 기능의 정식 출시를 하나로 묶으면, 에이전트가 API를 가진 시스템만 다루던 단계에서 벗어난다는 뜻입니다. 화면만 있는 소프트웨어, 예를 들어 사내 레거시 웹 콘솔이나 외부 기관 포털은 자동화 대상이 아니었습니다. 사람이 대신 클릭했습니다.

다만 ClaudeBleed 사례를 다루면서 봤듯이, 브라우저를 조작하는 권한은 그 자체로 공격 표면입니다. 화면을 보고 클릭하는 에이전트에게는 세션 쿠키가 붙은 브라우저가 그대로 열려 있습니다. 웹 포털에 자동 입력을 맡기기 전에, 그 에이전트가 어떤 페이지까지 갈 수 있는지 경계를 먼저 정해 두는 편이 좋습니다.

turn당 여러 동작이 묶이는 변화는 그래서 양면입니다. 비용과 지연이 줄지만, 잘못된 화면 판단 하나가 다섯 번의 클릭으로 번집니다. 되돌리기 어려운 작업에서는 disable_parallel_tool_use를 켜는 쪽이 낫다고 봅니다.

참고​

• computer use, Skills API, Files API 정식 출시 발표 (2026-08-20)
• computer use tool 공식 문서
• Skills API 레퍼런스

DB를 지키려고 붙인 모니터링 도구가 DB로 들어가는 문이 되면 곤란하겠죠. 2026년 8월 19일 Percona가 자사 모니터링 제품에서 그런 경로를 공개했습니다.

Percona 보안 공지의 대상은 Percona Monitoring and Management(PMM) 3.9.0 이하입니다. CVSS는 8.7, CVE 번호는 공지 시점에 아직 배정되지 않았고 배정되면 공지를 갱신한다고 적혀 있습니다.

문제의 모양​

PMM은 Grafana를 화면으로 쓰고, 쿼리 분석 데이터를 ClickHouse에 담습니다. 문제는 그 둘을 잇는 데이터소스 설정에 있었습니다.

두 가지가 겹칩니다. 첫째, Grafana는 로그인한 사용자가 raw data source API에 접근하는 것을 허용합니다. Viewer 역할도 포함입니다. 대시보드만 볼 수 있는 계정이 데이터소스에 직접 쿼리를 보낼 수 있다는 뜻입니다. 둘째, ClickHouse 데이터소스가 연결할 때 쓰는 기본 신원이 전역 DDL, DML, SOURCES 권한을 가지고 있었습니다.

Grafana에서 anonymous access를 켜 두면 로그인하지 않은 사용자까지 이 경로에 닿습니다. 기본값은 꺼져 있습니다. 이 조건은 명확히 해 두는 게 좋습니다. 뒤에 나오는 전체 공격 체인은 anonymous access가 켜져 있고 AWS EC2에 올라간 배포에서 성립합니다.

SOURCES 권한이 실제로 무엇을 여는가​

공지가 url() 함수를 언급하는데, ClickHouse를 자주 다루지 않으면 이게 왜 위험한지 감이 안 옵니다. 직접 확인해 봤습니다. 기본 설정으로 ClickHouse 컨테이너를 띄웠습니다.

$ docker run -d --name chtest -e CLICKHOUSE_PASSWORD=pw \
    clickhouse/clickhouse-server:latest
$ docker exec chtest clickhouse-client --password pw -q "select version()"
26.7.5.10

default 사용자가 가진 권한을 그대로 뽑아 봤습니다.

show grants for default;

GRANT SOURCES ON *.* TO default
GRANT TABLE ENGINE ON * TO default
GRANT CHECK, SHOW, SELECT, INSERT, ALTER, CREATE, DROP, UNDROP TABLE,
      TRUNCATE, OPTIMIZE, BACKUP, KILL QUERY, KILL TRANSACTION,
      MOVE PARTITION BETWEEN SHARDS, SYSTEM, dictGet,
      displaySecretsInShowAndSelect, INTROSPECTION, CLUSTER,
      FILE, URL, REMOTE, MONGO, REDIS, MYSQL, POSTGRES, SQLITE,
      ODBC, JDBC, HDFS, S3, HIVE, AZURE, KAFKA, NATS, RABBITMQ,
      YTSAURUS, ARROW FLIGHT, SOURCES ON *.* TO default

목록을 보면 성격이 드러납니다. FILE, URL, REMOTE, S3, MONGO, MYSQL, POSTGRES, HDFS가 전부 들어 있습니다. SOURCES는 이들을 묶은 상위 권한입니다.

이게 뜻하는 바는 ClickHouse의 쿼리가 데이터베이스 안에서 끝나지 않는다는 것입니다. url() 테이블 함수는 SELECT 문 안에서 HTTP 요청을 보냅니다. s3()는 S3 버킷을 읽습니다. file()은 서버 로컬 파일을 테이블처럼 읽습니다. SELECT 권한만 있는 계정이 아니라, HTTP 클라이언트를 겸하는 계정이 되는 셈입니다.

file()에는 별도 울타리가 하나 더 있습니다. 임의 경로는 막습니다.

$ clickhouse-client -q "select count() from file('/etc/hostname','LineAsString')"
Code: 291. DB::Exception: File `/etc/hostname` is not inside
`/var/lib/clickhouse/user_files`. (DATABASE_ACCESS_DENIED)

user_files 디렉터리 밖은 거부됩니다. 다만 그 안이라면 그대로 읽힙니다.

$ docker exec chtest sh -c 'echo secret-token-abc > /var/lib/clickhouse/user_files/t.txt'
$ clickhouse-client -q "select * from file('t.txt','LineAsString')"
secret-token-abc

네트워크 쪽은 울타리가 없습니다. 권한이 실제로 통과하는지 확인하려고 닫힌 포트를 겨냥해 봤습니다.

$ clickhouse-client -q "select * from url('http://127.0.0.1:1/x','LineAsString')"
Code: 1000. DB::Exception: Connection refused. (POCO_EXCEPTION)

돌아온 것이 권한 거부가 아니라 연결 거부입니다. 권한 검사를 통과해 실제로 소켓을 열려고 시도했다는 뜻입니다. 겨냥한 주소가 열려 있었다면 요청이 나갔을 것입니다. SELECT 문 하나가 DB 서버에서 출발하는 HTTP 요청이 되는 지점입니다.

공격 체인​

공지가 설명하는 흐름은 네 단계입니다.

url() 함수로 AWS IMDSv1에 요청을 보냅니다. 인스턴스 메타데이터 서비스의 v1은 토큰 없이 GET 하나로 응답합니다. 여기서 EC2 인스턴스에 붙은 role의 임시 자격증명을 얻습니다.

그 자격증명으로 S3에 접근해 Terraform state 파일을 읽습니다. state 파일에는 인프라 구성이 그대로 들어 있고, 관리자 비밀번호 같은 값이 평문으로 남아 있는 경우가 흔합니다.

마지막으로 그 값으로 PMM 관리자로 인증합니다. 모니터링 시스템의 관리자가 되면 감시 대상 DB의 접속 정보를 그 안에서 찾을 수 있습니다.

단계마다 그 자체로는 알려진 문제입니다. IMDSv1이 토큰 없이 응답하는 것도, Terraform state에 비밀이 남는 것도 오래된 이야기입니다. 이 공지가 보여 주는 건 그 알려진 약점들이 SELECT 권한 하나로 연결된다는 점입니다.

수정과 완화​

수정 버전은 PMM 3.9.1이고 2026년 8월 19일 나왔습니다. 근본 수정은 이쪽입니다.

바로 올릴 수 없는 환경을 위해 공지가 완화 스크립트를 함께 제공합니다. 방향은 단순합니다. 데이터소스가 쓰는 계정을 읽기 전용으로 새로 만들고, SOURCES 계열을 주지 않는 것입니다.

CREATE USER IF NOT EXISTS grafana_ro
  IDENTIFIED WITH plaintext_password BY '<password>'
  SETTINGS readonly = 1;
GRANT SELECT ON pmm.* TO grafana_ro;

readonly = 1을 걸고 pmm 데이터베이스에 SELECT만 줍니다. SOURCES를 주지 않으면 url(), s3(), mongodb(), remote(), file() 호출이 막힙니다. 대시보드가 필요한 것은 SELECT뿐이니 기능은 그대로 돕니다.

참고로 위 CREATE USER를 기본 default 계정으로 실행하면 거부될 수 있습니다. 제 컨테이너에서는 이렇게 나왔습니다.

Code: 497. DB::Exception: default: Not enough privileges.
To execute this query, it's necessary to have the grant
CREATE USER ON grafana_ro. (ACCESS_DENIED)

SOURCES는 넉넉히 주면서 사용자 관리 권한은 안 주는 기본 구성입니다. 이 스크립트를 돌리려면 ACCESS MANAGEMENT 권한이 있는 계정으로 접속해야 합니다.

관측 스택 계정 권한을 점검하는 자리​

공지가 다루지 않는 부분을 하나 짚고 싶습니다. 이번 문제의 뼈대는 PMM에 국한되지 않습니다. "대시보드가 DB에 붙을 때 어떤 권한으로 붙는가"라는 질문입니다. 이 질문은 어느 관측 스택에나 유효합니다.

점검할 지점을 정리하면 이렇습니다.

DB 계정 권한부터 보는 게 순서지만, 네트워크 쪽에서도 한 겹 막을 수 있습니다. DB 서버가 외부로 HTTP를 보낼 이유가 대개 없습니다. IMDSv2를 강제하는 것도 이 체인 두 번째 단계를 끊습니다.

남는 생각​

Copy Fail이나 NGINX Rift 같은 사례는 코드 한 줄의 결함이었습니다. 이번 건은 성격이 다릅니다. ClickHouse가 url()을 제공하는 것도, Grafana가 데이터소스 API를 여는 것도 각각은 의도된 기능입니다. 두 기능이 만나는 자리에서 권한 설정이 넉넉했던 것이 문제였습니다.

그래서 패치만으로 끝나지 않습니다. 3.9.1로 올린 뒤에도 데이터소스 계정에 무엇이 붙어 있는지 한 번 확인해 볼 만합니다. 저는 이 공지를 읽고 나서 ClickHouse의 SOURCES 권한이 그렇게 많은 것을 묶고 있는 줄 몰랐다는 걸 알았어요.

참고​

• Percona 보안 공지 (2026-08-19)
• ClickHouse 접근 권한 문서
• ClickHouse url 테이블 함수

Spectre는 2018년 이야기라고 생각하고 있었는데, 그게 아니었어요. 멀티테넌트 서버리스에서는 아직 진행 중인 문제입니다.

Cloudflare가 2026년 8월 19일 자사 Workers 환경에서 원격 Spectre 공격을 재현한 연구를 공개했습니다. 에든버러 대학교와 공동 연구입니다. 결과 문장이 짧고 셉니다. 프로덕션 환경에서 초당 최대 12비트, 정확도 99%로 안정적으로 유출했습니다.

무엇을 어떻게 빼냈나​

피해자 Worker 안에 JWT 토큰을 두고 비트 단위로 읽어 냈습니다. 첫 바이트가 문자 e, 이진값 0b01100101로 정확히 나왔습니다.

초당 12비트는 느리게 들립니다. JWT 하나가 수백 바이트라면 몇 시간이 걸립니다. 하지만 공격이 성립하는지 여부에서는 속도가 본질이 아닙니다. 정확도 99%로 안정적이라는 쪽이 문제입니다. 오류율이 높으면 재시도로 시간이 곱해지는데, 그게 아니라는 뜻입니다.

원격 타이머라는 전제가 무너졌다​

Spectre 계열 공격에는 정밀한 시간 측정이 필요합니다. 캐시에 있는 값을 읽는 시간과 없는 값을 읽는 시간의 차이가 신호이기 때문입니다. 그 차이가 나노초 단위입니다.

2018년 이후 브라우저와 런타임이 취한 대응 중 하나가 타이머를 무디게 만드는 것이었습니다. Cloudflare Workers도 타이머를 동결(frozen timer)했습니다. Worker 안에서 시간을 재도 값이 변하지 않게 만든 것입니다. 멀티스레딩과 공유 메모리도 껐습니다.

이 연구가 그 전제를 치웁니다. 외부 서버로 나가는 WebSocket 연결 하나로 충분했습니다. 그쪽에서 고해상도 타임스탬프를 받아 오면 됩니다. 몇 번의 표본만으로 중앙값 기준 밀리초 미만 해상도를 얻었습니다.

여기에 증폭 기법을 붙였습니다. L1 캐시의 tree-based PLRU 교체 정책을 이용해 단일 캐시 사건에서 나온 시간 차이를 임의로 키웠습니다. 나노초 차이를 밀리초 해상도로 읽을 수 있게 만드는 단계입니다.

isolate가 프로세스가 아니라서​

Cloudflare Workers는 수만 테넌트를 같은 OS 프로세스 안에서 돌립니다. 분리 단위가 프로세스가 아니라 V8 isolate입니다. 이 선택이 효율을 만듭니다. 프로세스를 띄우는 비용 없이 요청이 들어오면 즉시 실행되고, cold start가 사실상 사라집니다.

대가는 분리 강도입니다. 같은 프로세스 안이면 주소 공간이 이어져 있습니다. Worker 프로세스 안에서 임의 읽기가 한 번 성립하면 다른 테넌트의 데이터에 닿습니다.

공격자가 피해자와 같은 프로세스에 들어가는 방법도 단순했습니다.

fetch("https://victim.example")

피해자 스크립트를 호출하면 스케줄러가 바로 그 프로세스 안에 피해자 Worker 인스턴스를 띄웁니다. Durable Objects와 지속 WebSocket 연결로 isolate를 계속 살려 뒀습니다.

gadget은 두 개를 썼습니다. 첫 번째는 압축된 힙 포인터를 유출합니다. isolate의 힙 기준 주소를 얻는 단계입니다. 두 번째는 TypedArray의 backing store를 이용한 speculative type confusion으로, 공격자가 만든 임의의 64비트 포인터에서 값을 읽습니다. 기준 주소를 알아낸 뒤 임의 주소로 넘어가는 구성입니다.

2021년 방어는 왜 놓쳤나​

Cloudflare가 2021년에 내놓은 방어가 Dynamic Process Isolation(DyPrIs)입니다. 의심스러워 보이는 스크립트를 찾아 별도 프로세스로 격리합니다. 하드웨어 성능 카운터로 분기 예측 실패 같은 신호를 감시합니다.

이 방어가 통하지 않은 이유가 둘입니다.

첫째, 시점입니다. DyPrIs는 스크립트 실행이 끝난 뒤에 격리했습니다. 그런데 이 공격은 WebSocket keep-alive로 실행을 몇 시간에서 하루까지 이어 갑니다. 격리가 적용될 시점이 오지 않습니다.

둘째, 지표가 희석됐습니다. DyPrIs는 분기 예측 실패 횟수를 iTLB 접근 횟수로 정규화합니다. 그런데 WebSocket 트래픽 자체가 iTLB 활동을 늘립니다. 분모가 커지니 비율이 탐지 문턱 아래로 내려갑니다.

방어를 우회한 방식이 취약점을 새로 찾은 게 아니라, 정상 기능인 지속 연결을 쓴 것이라는 점이 인상적입니다. 탐지 지표를 정할 때 그 지표가 정상 트래픽으로 흔들릴 수 있는지가 중요하다는 사례입니다.

새로 붙인 방어​

이후 적용한 것이 셋입니다.

V8 샌드박스입니다. JavaScript 힙의 상당 부분에서 원시 64비트 포인터를 제거합니다. 이 연구가 쓴 speculative type confusion gadget은 임의의 64비트 포인터를 만들어 넣는 방식이었으니, 그 재료를 없애는 접근입니다. Cloudflare는 해당 gadget을 "재사용하기 더 어렵게" 만든다고 표현했습니다. 불가능하다고 하지 않았습니다.

Memory Protection Keys(MPK)입니다. 2025년 9월에 배포했습니다. isolate별 힙이 하드웨어로 강제되는 접근 경계 뒤에 놓입니다. 소프트웨어 검사가 아니라 CPU가 막습니다. 같은 프로세스 안이라는 구조를 유지하면서 분리를 강화하려면 이 방향이 남습니다.

DyPrIs 개선입니다. 장시간 실행과 I/O 위주 워크로드를 다루도록 바꿨고, 실행이 끝난 뒤가 아니라 실행 중에 탐지합니다. 위 두 회피 경로를 각각 겨냥한 수정입니다.

실제 악용 흔적은 지난 3년간 발견되지 않았다고 밝혔습니다.

남는 질문​

이 글에서 가장 오래 남는 대목은 결과 수치가 아니라 구조 쪽입니다. isolate 기반 멀티테넌시는 cold start를 없애려는 선택이었고, 그 선택이 만든 공격면을 하드웨어 기능(MPK)으로 메우는 단계에 와 있습니다. 소프트웨어 격리를 얇게 만든 대가를 CPU 기능으로 지불하는 구조입니다.

NGINX Rift처럼 코드 결함을 고치는 사례와 다른 종류의 문제입니다. 고쳐야 할 한 줄이 없습니다. 아키텍처 선택의 청구서라서, 방어도 계층을 더 쌓는 형태가 됩니다.

DB를 운영하는 쪽에서 읽으면 결론이 좀 밋밋합니다. 서버리스 런타임 위에 올려 둔 코드가 다루는 비밀은 언제든 같은 프로세스 이웃에게 노출될 수 있다고 가정하는 편이 낫습니다. DB 접속 자격증명을 Worker 환경 변수에 두고 오래 살려 두는 구성이라면, 자격증명 수명을 짧게 잡는 것이 이 종류의 공격에 대한 가장 현실적인 대응입니다.

참고​

• A revisit of remote Spectre attacks on Cloudflare Workers (2026-08-19)
• Cloudflare의 2021년 Dynamic Process Isolation 발표
• V8 Sandbox 설계 문서

primary key를 UUID로 쓰기로 하면 대개 v4를 씁니다. 그런데 그 선택이 index를 얼마나 부풀리는지 숫자로 본 적은 없었어요. pgEdge의 Shaun Thomas(숀 토머스)가 The Time Traveler's Primary Key에서 그 숫자를 냈고, PostgreSQL 18 컨테이너로 직접 재현해 봤습니다.

v4가 index를 흩어 놓는 방식​

B-tree는 정렬된 구조입니다. 새 키가 들어오면 그 값이 들어갈 자리를 찾아 해당 leaf page에 씁니다.

시퀀스로 만든 키는 항상 오른쪽 끝으로 갑니다. 마지막 page를 채우고, 차면 새 page를 붙입니다. page 하나가 거의 꽉 찬 상태로 남습니다.

UUID v4는 값이 완전히 무작위입니다. 원문 표현대로 "생성된 각 값이 맨 첫 행보다 앞에 정렬될 확률과 맨 마지막 행보다 뒤에 정렬될 확률이 같습니다". 그래서 삽입이 index 전체에 흩어집니다. 이미 꽉 찬 page 가운데에 값이 들어오면 page split이 일어나고, split된 두 page는 각각 절반씩만 채워집니다. 같은 개수의 키를 담는 데 page가 두 배로 필요해집니다.

UUID v7은 상위 48비트에 밀리초 단위 Unix 타임스탬프를 최상위 비트부터 담습니다. version 정보 뒤에 12비트를 더해 밀리초 이하 정밀도까지 표현합니다. 남는 약 62비트가 무작위입니다. 결과적으로 나중에 만든 값이 앞서 만든 값보다 크게 정렬됩니다. 시퀀스와 같은 삽입 패턴이 됩니다.

직접 재 봤다​

PostgreSQL 18에 uuidv7()과 uuidv4()가 내장되어 있습니다. 기본 설정 컨테이너로 세 가지 테이블에 100만 행씩 넣었습니다.

create table t_bigint (id bigserial primary key, payload text);
create table t_v4 (id uuid primary key, payload text);
create table t_v7 (id uuid primary key, payload text);

insert into t_bigint (payload) select 'x' from generate_series(1,1000000);
insert into t_v4 (id,payload) select uuidv4(),'x' from generate_series(1,1000000);
insert into t_v7 (id,payload) select uuidv7(),'x' from generate_series(1,1000000);

크기를 뽑았습니다.

 relname  | heap  |  idx
----------+-------+-------
 t_bigint | 42 MB | 21 MB
 t_v4     | 50 MB | 37 MB
 t_v7     | 50 MB | 30 MB

원문이 낸 수치가 v4 index 38MB, v7 30MB였는데 거의 그대로 나왔습니다. index만 놓고 보면 v7이 v4보다 19% 작습니다.

이유를 직접 확인하려면 pgstattuple의 pgstatindex()를 봅니다.

select 'v4' as k, avg_leaf_density, leaf_fragmentation from pgstatindex('t_v4_pkey')
union all
select 'v7', avg_leaf_density, leaf_fragmentation from pgstatindex('t_v7_pkey')
union all
select 'bigint', avg_leaf_density, leaf_fragmentation from pgstatindex('t_bigint_pkey');

   k    | avg_leaf_density | leaf_fragmentation
--------+------------------+--------------------
 v4     |            72.61 |              49.86
 v7     |            89.98 |                  0
 bigint |            90.01 |                  0

여기가 이 실험에서 가장 선명한 부분입니다. v4의 leaf 밀도가 72.61%이고 단편화가 49.86%입니다. v7은 밀도 89.98%에 단편화 0입니다. bigserial의 90.01%와 사실상 같습니다. v7의 삽입 패턴이 시퀀스와 구분되지 않는다는 뜻입니다.

원문 수치가 71.53%와 49.89%, 89.98%와 0.00%였으니 소수점 자리까지 맞았습니다.

heap은 줄지 않는다​

표에서 놓치기 쉬운 칸이 heap입니다. t_bigint가 42MB, UUID 두 개는 50MB로 같습니다. UUID는 128비트, bigint는 64비트니까 행마다 8바이트가 더 붙습니다. v7으로 바꿔도 이 차이는 그대로입니다.

정리하면 v7이 개선하는 것은 index의 공간 효율과 삽입 시 page split이고, 값 자체의 크기는 아닙니다. bigint와 UUID 사이의 선택은 여전히 별개 문제입니다. 원문도 이 부분을 분명히 합니다. 데이터가 단일 노드에 있고, 하나의 primary 인스턴스가 키를 발급하고, 키가 외부로 돌아다니지 않는다면 BIGINT GENERATED ALWAYS AS IDENTITY가 최선이라고 적었습니다. 위 실측에서도 bigint index가 21MB로 v7의 70% 수준입니다.

타임스탬프가 공개된다​

v7의 대가는 성능이 아니라 정보입니다. 상위 비트가 생성 시각이라서 값에서 그대로 읽힙니다. PostgreSQL 18은 그 추출 함수를 내장으로 제공합니다.

select id, uuid_extract_timestamp(id) from t_v7 limit 2;

01a03337-728f-7bf2-bdf8-69d062bfa627|2026-08-24 10:01:06.959+00
01a03337-7290-7767-bc60-69fb35dd6c00|2026-08-24 10:01:06.96+00

버전도 확인됩니다.

select uuid_extract_version(id) from t_v7 limit 1;   -- 7

이게 뜻하는 바가 셋입니다. 키를 받은 쪽이 그 레코드의 생성 시각을 밀리초 단위로 압니다. 키 두 개를 비교하면 그 사이 생성 간격을 알 수 있어서 생성 속도가 측정됩니다. 그리고 값이 시간순으로 인접하니 이웃 키를 추측해 보는 것이 무작위 값보다 훨씬 그럴듯해집니다.

주문 번호나 사용자 ID를 URL에 노출하는 구조라면 이 세 가지가 실제 문제가 됩니다. 가입 시각, 하루 주문 건수, 경쟁사 성장 속도가 키에서 읽힙니다. 원문도 생성 시각과 삽입 속도가 비공개여야 하는 경우에는 v4가 여전히 적합하다고 적었습니다.

오른쪽 끝이 경합 지점이 된다​

또 하나 짚어 둘 만한 대가가 있습니다. v7의 삽입이 index 오른쪽 끝으로 몰린다는 것은 곧 그 page가 모든 writer의 경합 지점이 된다는 뜻입니다.

샤딩된 환경이나 병렬 쓰기가 많은 구성에서는 이게 실제 병목이 될 수 있습니다. v4는 흩어져서 비효율적인 대신, 쓰기를 고르게 분산합니다. 단일 노드에서 순차 삽입이 주된 패턴이라면 v7이 유리하고, writer가 많고 오른쪽 끝 경합이 이미 보이는 환경이라면 계산이 달라집니다.

어떻게 고를까​

세 선택지의 성격을 정리하면 이렇습니다.

이미 UUID v4를 쓰고 있고 분산 생성이 필요해서 그렇게 한 것이라면, v7으로 옮기는 건 대체로 이득입니다. index가 작아지고 page split이 사라지는 대신 잃는 것은 생성 시각의 비공개성뿐입니다. 그 시각이 민감하지 않다면 바꿀 이유가 충분합니다.

반대로 UUID를 쓰는 이유가 "ID를 추측할 수 없게 하려고"였다면 v7은 그 목적과 충돌합니다. v7의 무작위 비트가 62비트라 값 자체를 맞히기는 여전히 어렵지만, 시간순 인접성 때문에 열거 시도의 탐색 공간이 좁아집니다.

새로 만드는 테이블이고 단일 노드라면 bigint가 답입니다. 위 실측에서 index가 v7의 70%, heap이 84%였고 그게 전부 실제 I/O입니다. UUID를 고르는 이유는 성능이 아니라 분산 생성이나 외부 노출이니까요.

참고​

• The Time Traveler's Primary Key (Shaun Thomas, pgEdge, 2026-08-21)
• PostgreSQL UUID 함수 문서
• RFC 9562 (UUID v7 규격)