숫자 하나로 시작하겠습니다 — 월 5달러 미만을 쓰던 AWS 계정에 추정 요금 17억 달러가 찍혔습니다. 실제 청구는 아니었지만, ‘기계가 읽는 숫자’의 신뢰 문제를 드러낸 사건이죠. 여기에 데이터베이스 코어를 공유 부품으로 만들겠다는 Turso의 선언, 27B 모델을 아이폰에 넣은 1비트 압축까지 — 각 항목은 사실을 짧게 밝히고, 한 줄 판단과 이번 주 확인할 일을 남깁니다.

오늘의 핵심

1. AWS 요금 콘솔, 추정치가 하루 동안 틀렸다

• 사실: AWS가 Billing and Cost Management 콘솔의 추정 요금(당월 사용량 기반 예상 청구액) 데이터가 부정확하게 표시되는 오류를 AWS Health Dashboard로 공식 확인했습니다.
  • 7월 16일 19:38(태평양 시간)부터 발생해, 월 5달러 미만 계정에 17억 달러, 일부 계정엔 수천억 달러대·음수 추정치까지 보고됐습니다(HN 스레드 906포인트).
  • AWS는 원인을 추정 요금 계산 서브시스템의 단위 요율 버그로 지목했고, 실제 청구에는 영향이 없다고 명시했습니다. 수정 후에도 전 계정 재계산에 수 시간이 걸린다고 안내했습니다.
  • ⚠️ Health Dashboard 공지는 상시 링크로 남지 않아, 세부 사실은 The Register 보도 등 복수 매체로 교차 확인했습니다.
• 한 줄 판단: “표시 전용 오류”라는 안심은 사람이 읽을 때만 성립합니다. 그 숫자를 읽는 자동화가 하나라도 물려 있다면 표시 오류는 그대로 운영 사고가 되죠. 돈이 오가는 시스템은 작은 실수도 불허한다는 그럼의 편집 기준에서, 교훈은 청구 원장이 무사했다는 다행이 아니라 이쪽입니다 — 예산 알람이나 자동 리소스 정지가 ‘추정치’를 트리거로 쓰고 있었다면, 이 하루 동안 잘못된 숫자로 실제 조치가 나갔을 겁니다. 잘못된 신호가 자동화를 타고 증폭되는 구조는 공개된 장애 사례가 반복해 보여준 패턴입니다.
• 이번 주 할 일: 비용 알람·예산 자동화가 어떤 신호(추정치인지 확정 청구인지)를 트리거로 쓰는지 점검해 보시길 권합니다. 자동 조치가 걸려 있다면 전월 대비 배수 상한 같은 이상치 가드(상식 범위 검사)를 한 줄 더하는 것도 좋고요. 단, 가드가 보수적일수록 진짜 비용 폭주 반응은 늦어지니 ‘알림은 민감하게, 자동 조치는 보수적으로’ 임계를 분리하는 편이 안전합니다. 가볍게는 이번 달 추정치와 지난달 확정 청구액을 오늘 날짜로 한 줄 기록해 두면 다음 이상치의 기준선이 생깁니다.

2. Turso — “데이터베이스의 LLVM”을 선언하다

• 사실: SQLite를 Rust로 재작성해 온 Turso가 같은 코어 위에 Postgres를 다시 구현하는 프로젝트를 공식 선언했습니다.
  • 핵심 설계는 SQL 방언별 프런트엔드를 공용 바이트코드 VM(SQL을 중간 명령으로 컴파일해 실행하는 가상 머신)으로 수렴시키는 것 — 스스로 “데이터베이스의 LLVM”(여러 언어 컴파일러가 공유하는 공용 기반처럼)이라 부릅니다.
  • 실험 구현 pgmicro가 메인 트리에 머지됐고, “쓸 만한 Postgres 서브셋까지 몇 달”이라는 전망을 냈습니다. 라이선스 MIT, 오픈소스 기여자 260명 이상.
  • 코어에는 MVCC(다중 버전 동시성 제어 — 읽기가 쓰기를 막지 않게) 동시 쓰기와 자동 갱신 머티리얼라이즈드 뷰(미리 계산해 두는 조회 결과)가 이미 들어가 있습니다.
• 한 줄 판단: Postgres 호환의 난이도는 문법이 아니라 의미론에 있습니다. 컴파일러가 LLVM으로 증명한 ‘프런트엔드는 여럿, 코어는 하나’ 구조를 데이터베이스에 이식하는 시도로, 방향은 설득력 있습니다. 다만 “Postgres 호환”을 내건 데이터베이스들이 공개 기술사에서 반복해 보여줬듯, 접속 프로토콜 호환까지는 빨라도 트랜잭션 격리·잠금·타입 경계 같은 동작 호환은 오래 걸립니다. 어제 정리한 Rust→Zig 재작성 회고와 같은 결로, 성패는 언어가 아니라 범위 고정에 달렸습니다 — ‘몇 달’은 서브셋 기준으로 읽는 게 정확합니다.
• 이번 주 할 일: 프로덕션 Postgres의 대체 후보로는 아직 신경 쓰지 않으셔도 됩니다. 다만 임베디드·엣지에서 SQLite의 동시 쓰기 한계에 막혀 본 적이 있다면 추적 목록에 올려 두시길 권합니다. 단, 신생 엔진을 이르게 들이면 마이그레이션 비용보다 미지의 버그 비용이 크게 돌아올 수 있습니다. 구조가 궁금하시다면 저장소를 클론해 pgmicro가 Postgres 방언을 바이트코드로 내리는 경로만 훑어봐도 ‘프런트/코어 분리’의 실물이 보입니다.

그림: Turso가 선언한 구조 — 프런트엔드는 여럿, 코어는 하나. 신뢰성 투자가 한 곳에 모이는 대신, 방언별 ‘동작 호환’은 프런트엔드가 짊어집니다.

3. Bonsai 27B — 27B 멀티모달이 아이폰 메모리에 들어갔다

• 사실: PrismML이 7월 14일, Qwen3.6-27B를 극저비트로 압축한 온디바이스 멀티모달 모델 Bonsai 27B를 공식 발표했습니다.
  • 1비트(3.9GB)·1.58비트 터너리(5.9GB) 두 변형을 양자화(가중치를 낮은 정밀도로 압축)해 Apache 2.0으로 Hugging Face에 공개했습니다(MLX·GGUF 배포).
  • 자체 벤치마크 기준 풀정밀 대비 1비트 90%+ · 터너리 95%+ 성능 유지를 주장합니다. ⚠️ 아직 제3자 검증 전 자체 집계입니다.
  • iPhone 17 Pro에서 11 tok/s, M5 Max에서 87 tok/s로 구동되며, 이미지 입력(스크린샷·문서·카메라)을 지원합니다.
• 한 줄 판단: 2024년 BitNet 논문의 1.58비트 극저비트 노선이 연구를 벗어나 제품 등급 27B로 내려온 장면입니다. 온디바이스 AI의 질문이 ‘단말에 올라가나’에서 ‘올려두고 계속 돌릴 수 있나’로 바뀝니다 — 다음 병목은 파일 크기가 아니라 배터리·발열·메모리 상주라는 게 태리의 판단입니다(2차 효과). 단말에서 이 정도가 돌면 클라우드 추론 API의 비용 구조에도 압력이 가고요. 90% 유지는 자체 집계인 만큼 벤치마크 표보다 각자 워크로드로 확인할 대상입니다.
• 이번 주 할 일: 모바일·데스크톱 앱에 AI 기능을 견적 중이라면, API 호출 전제로 잡아 둔 계산에 온디바이스 옵션을 다시 넣어 보시길 권합니다. 단, API 비용이 사라지는 대신 단말 편차 대응·모델 업데이트 배포·품질 검증이 앱 팀 몫으로 넘어오는 트레이드오프입니다. 가볍게는 GGUF 변형을 llama.cpp로 받아 노트북에서 tok/s를 실측해 두면 온디바이스 견적의 첫 데이터가 됩니다.

그래서, 무엇이 바뀌나

오늘의 공통분모는 운영 경계의 이동입니다. 비용 자동화에는 입력 검증이, 데이터베이스에는 호환성 경계가, AI 배치에는 클라우드와 단말을 오가는 재견적이 필요해졌습니다. 요금 콘솔의 숫자, 방언마다 통짜인 엔진, 서버에만 올리는 27B — 어제까지 당연하던 전제가 하루에 하나씩 흔들릴 때, 대응력은 낙관이 아니라 이렇게 명시적으로 그어 둔 경계에서 나온다는 게 그럼의 편집 기준입니다. 이번 주에는 각자 시스템에서 ‘검증 없이 믿고 있는 숫자’ 하나만 찾아보셔도 좋겠습니다.

참고 / 출처

• AWS Health Dashboard (공식 · ⚠️ 공지는 상시 링크로 남지 않음) · HN 스레드 · The Register 보도
• We’re building Postgres in Rust (Turso 공식 블로그)
• PrismML Announces 1-bit Bonsai 27B (PrismML 공식 발표) · Hugging Face 모델 컬렉션