개발하는 TeEm0

지난 분기에 우리 팀에서 실제로 있었던 일이다. 인증 흐름 하나 바꾸는 작업을 RFC로 먼저 쪼갰다. 이슈 6개, PR 6개. 3번째 PR을 머지하고 나서야 "아, 2번에서 만든 인터페이스로는 프론트에서 못 쓴다"는 걸 알았다. 앞의 두 개를 되돌리고 다시 만들었다. 리뷰어 시간까지 합치면 이틀은 날아갔다.

GeekNews에 올라온 "넓게 만들고, 좁게 배포하라(Build Wide, Ship Narrow)"는 딱 이 문제를 건드린다. 핵심 주장은 간단하다. 무엇을 만들지는 구현 전에 정하되, 어떻게 PR로 쪼갤지는 구현이 끝난 뒤에 정하자.

왜 우리는 코드도 없는데 PR 경계를 먼저 정해왔나

전통적 흐름은 RFC 작성 → 작은 이슈 분해 → 순차 구현이었다. 합리적으로 보이지만 근본적 문제가 있다. 아직 코드가 한 줄도 없는, 정보가 가장 부족한 시점에 구조적 경계를 결정해야 한다는 것이다.

• 어떤 부분이 실제로 분리 가능한지 모른다
• 각 부분의 복잡도를 추측만 할 수 있다
• 뒷 단계에서 발견한 문제가 앞 설계를 뒤집을지 알 수 없다

그런데도 왜 미리 쪼갰나? 원문은 이렇게 답한다. 완성된 브랜치를 나중에 작은 리뷰 단위로 다시 푸는 일이 너무 비쌌기 때문이다. 사전 분해는 구현을 쉽게 하려던 게 아니라 "사람이 리뷰할 수 있는 크기"를 확보하려던 현실적 타협이었다.

AI가 바꾼 건 딱 이 비용이다. 원문이 꼽는 싸진 것 세 가지: 구현, 설계 검토, 그리고 완성된 작업의 재분해. 일주일간 얽혀 만든 브랜치를 작은 PR 여러 개로 다시 나누는 게 프롬프트로 처리 가능한 수준이 됐다는 것이다.

반대로 안 싸진 것도 명확하다. 코드 리뷰의 판단 부분(이 코드가 여기 있는 게 맞나, 이 API가 6개월 뒤에도 괜찮나)과 제품 검증이다. 봇이 PR을 승인하는 것과 사람이 코드를 이해하는 것은 다르다는 문장이 이 글의 핵심이라고 본다.

동작 원리: 작업 브랜치는 '버려도 되는 연습장'

전체 흐름은 다섯 단계다.

1. 설계 검토 — 계획에 실제 결정이 충분히 들어갈 때까지. 새 설계면 명세를 코드보다 먼저 커밋
2. Build Wide — 브랜치 하나에서 백엔드/프론트 가로질러 끝까지 구현
3. 데모 먼저 — PR 열기 전에 Slack 영상이나 프리뷰 배포로 제품 피드백
4. Ship Narrow — 완성된 코드가 드러낸 경계로 작은 PR 재구성
5. 정리 PR — 기존 코드 삭제는 마지막 별도 PR

여기서 인프라 하는 사람이 가장 거부감 느낄 지점이 2번이다. 원문 저자는 리팩터링 하나에서 하루 동안 수십 개 파일을 고치며 커밋 12개 이상을 만들었다고 한다. Git 이력 깔끔하게 관리하던 사람 입장에선 끔찍하다.

근데 전제가 다르다. 이 작업 브랜치의 이력은 최종 기록으로 남지 않는다. 최종 PR은 전부 main에서 새로 만든다. 작업 브랜치는 버리는 연습장이고, 커밋은 "위험한 시도 전 되돌아갈 지점" 용도다. 구현 중 필요한 이력과 리뷰어가 읽어야 할 이력을 분리하는 것이다.

실제 분해는 이런 식으로 간다. 원문의 5개 PR 사례:

# 작업 브랜치(feat/wide)에서 기능 완성 후, main 기준으로 PR별 worktree 생성
git worktree add ../pr1-backend-a -b pr/backend-endpoint-a main
git worktree add ../pr2-backend-b -b pr/backend-endpoint-b main

# 프론트는 실제 의존성이 있으므로 해당 백엔드 PR 위에 스택
git worktree add ../pr3-front-a -b pr/frontend-view-a pr/backend-endpoint-a

# 삭제만 담당하는 마지막 PR
git worktree add ../pr5-cleanup -b pr/remove-legacy-path main

git worktree list

/home/dev/app              a1b2c3d [main]
/home/dev/pr1-backend-a    a1b2c3d [pr/backend-endpoint-a]
/home/dev/pr2-backend-b    a1b2c3d [pr/backend-endpoint-b]
/home/dev/pr3-front-a      e4f5g6h [pr/frontend-view-a]
/home/dev/pr5-cleanup      a1b2c3d [pr/remove-legacy-path]

독립적인 백엔드 엔드포인트 2개는 각각 main에서 직접 분기, 프론트 뷰 2개는 자기가 쓰는 백엔드 위에 스택, 마지막 PR은 기존 경로 삭제만. 원문에 따르면 이 마지막 삭제 PR에서 제거한 코드가 새 기능 전체가 추가한 코드보다 수백 줄 더 많았다고 한다.

이 사례가 말하는 게 뭐냐면, "기존 코드 삭제 PR"은 사전 분해로는 절대 못 만드는 단위라는 것이다. 새 경로를 전부 만들고 동작을 확인해야만 무엇을 지울 수 있는지 알 수 있으니까.

실무 관점: 어디에 쓰고 어디서 터지는가

잘 맞는 작업은 원문 기준으로 세 가지다. 백엔드/프론트를 가로지르는 기능, 끝까지 해보기 전엔 구조를 모르는 리팩터링, 사전에 경계를 정하려면 추측만 가능한 작업.

덜 맞는 작업이 더 중요하다. 인프라 하는 입장에선 여기가 지뢰밭이다.

• 운영 순서가 제약인 마이그레이션과 스키마 변경 — 어떤 변경을 먼저 적용해야 하는지가 실제 제약이다. 사후에 예쁘게 쪼개봐야 배포 순서는 여전히 강제된다
• 처음부터 나눌 위치가 명백한 작업 — 굳이 왕복할 이유가 없다
• 첫 단계만 따로는 절대 배포 못 하는 기능 — 사후 분해로 얻는 건 점진적 리뷰뿐이다

세 번째 항목은 원문도 솔직하게 인정한다. 예시로 든 5개 PR은 글 쓰는 시점에도 전부 열려 있었고, 결국 같은 날 다 머지될 수도 있다고 한다. PR을 잘 나눴다고 자동으로 점진 배포가 되는 게 아니다. "리뷰하기 쉬움"과 "독립적으로 머지할 가치가 있음"은 다른 조건이고, 에이전트가 도와줄 수 있는 건 앞의 것뿐이다.

흔한 함정 1: 편하다고 스택하기

원문 규칙은 명확하다. 실제 의존성이 있을 때만 스택한다. 단순히 편해서 스택하면 아래 PR에 리뷰 피드백이 들어오는 순간 위쪽 브랜치 전부를 연쇄 리베이스해야 한다. 실무에서 이렇게 터진다.

$ git rebase pr/backend-endpoint-a
Auto-merging src/api/client.ts
CONFLICT (content): Merge conflict in src/api/client.ts
error: could not apply e4f5g6h... feat: add frontend view A
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
Could not apply e4f5g6h... feat: add frontend view A

3~4단 스택에서 이게 나면 아래에서부터 순서대로 다 풀어야 한다. 실제 의존성이 없는데 편의로 쌓아둔 거면 그냥 손해다. 원문은 최초 분해를 수행한 채팅 세션을 유지해두면 그 컨텍스트로 위쪽 브랜치 업데이트도 다시 맡길 수 있다고 하는데, 이건 도구 의존적인 얘기라 각자 환경에서 검증이 필요해 보인다.

흔한 함정 2: 데모를 건너뛰기

이게 실무에서 가장 많이 생략되는 단계인데, 사실 이 방식의 절반이다. 코드 리뷰 단계에서 "UI가 헷갈린다", "이 API 프론트에서 쓰기 불편하다"는 피드백이 나오면 리뷰어 시간과 개발자 시간이 동시에 날아간다. 데모 단계에서 나오면 코드 구조를 크게 바꿔도 부담이 없다.

인프라 관점에서 이건 PR 프리뷰 환경이 있냐 없냐의 문제로 직결된다. 없으면 이 워크플로 자체가 안 돌아간다. CI에서 PR 브랜치별 임시 환경을 띄우는 파이프라인이 선행 조건이라고 보면 된다.

# .github/workflows/preview.yml (핵심만)
on:
  push:
    branches: ['feat/**']   # PR 열기 전 작업 브랜치도 대상
jobs:
  preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy preview
        run: |
          NS="pv-$(echo $GITHUB_REF_NAME | tr '/' '-' | cut -c1-40)"
          kubectl create ns "$NS" --dry-run=client -o yaml | kubectl apply -f -
          helm upgrade --install app ./chart -n "$NS" \
            --set image.tag=$GITHUB_SHA --set ingress.host=$NS.preview.example.com
          echo "https://$NS.preview.example.com"

포인트는 on.push.branches에 PR이 아닌 작업 브랜치를 넣었다는 것이다. Build Wide 단계에선 PR이 아직 없으니까. 다만 네임스페이스 무한 증식은 막아야 한다. TTL 붙여서 자동 정리하는 job은 별도로 필요하다.

흔한 함정 3: 분해를 AI에 맡기고 안 읽기

원문이 강조하는 부분인데, PR로 나누는 과정 자체가 작성자 본인의 첫 코드 리뷰다. diff를 머릿속에 담을 수 있는 크기로 하나씩 확인하는 과정이 "AI가 쓴 코드를 그냥 배포한 것"과 "이해하고 배포한 것"을 가른다. 여기서 분해까지 통째로 자동화하고 넘기면 그냥 2,000줄 PR을 다섯 조각 낸 것에 불과하다.

그리고 오해하기 쉬운 게, Build Wide가 "모든 PR이 작아진다"는 뜻이 아니다. 새 데이터 모델, 새 API 표면, 신뢰 경계가 걸린 백엔드 PR은 여전히 무겁고 무거워야 한다. 목표는 균일한 크기가 아니라 리뷰어의 주의를 실제 위험이 있는 곳에 몰아주는 구조다.

대안 — 안 바꿔도 되는 경우

기존 트렁크 기반 개발 + 피처 플래그 조합이 이미 잘 돌고 있고, 도메인이 안정적이라 경계가 자명하다면 굳이 갈아탈 이유가 없다. 이 방식이 값을 하는 건 "해보기 전엔 모르겠는" 작업이다. 반대로 팀에 프리뷰 환경도 없고 리뷰가 며칠씩 밀리는 상황이면, 이 워크플로 도입보다 리뷰 SLA부터 잡는 게 순서다.

정리

한 줄로: 구현 전에 추측으로 하던 PR 경계 결정을, 실제 코드가 존재하는 시점까지 미루는 것. 구조적 판단을 없애는 게 아니라 뒤로 옮기는 거다. 설계를 건너뛰라는 얘기가 절대 아니고, 오히려 원문 저자는 편집기 열기 전에 계획을 세우고 새 설계면 명세를 문서 PR로 먼저 머지해 팀이 이의 제기할 기회를 준다고 한다.

이런 팀에 권한다.

• AI 코딩 에이전트를 이미 일상적으로 쓰고 있는데 PR이 자꾸 비대해지는 팀
• 풀스택 기능 하나 만드는 데 이슈를 5~6개로 쪼개다가 중간에 설계가 뒤집힌 경험이 있는 팀
• PR 프리뷰 환경이 이미 있거나, 만들 여력이 있는 팀

반대로 스키마 마이그레이션이 주 업무거나, 배포 순서가 규제로 정해져 있는 도메인이면 얻는 게 별로 없다. 그리고 도입한다면 프리뷰 환경 → 데모 문화 → 분해 자동화 순서로 가는 걸 권한다. 마지막 것부터 손대면 그냥 큰 PR을 잘게 썬 것으로 끝난다.

참고 자료

• 넓게 만들고, 좁게 배포하라 — GeekNews (원문 토픽)
• Adapt Engineering Blog (원 출처)
• git-worktree 공식 문서
• Negative 2000 Lines Of Code — folklore.org (댓글에서 언급된 일화)
• Trunk Based Development

1. 무슨 일이 있었나 — 그리고 왜 남 얘기가 아닌가

GitHub Actions와 GitHub Pages가 6시간 넘게 대규모 장애·성능 저하를 겪었다. 증상은 대략 이렇게 정리된다.

• 워크플로우 실행 실패와 지연, 큐 적체
• 웹훅 처리량이 정상 대비 약 15% 수준까지 떨어져 push/PR 기반 CI 트리거 자체가 안 걸림
• 자체 호스팅(셀프호스티드) 러너까지 작업 할당이 마비

세 번째 항목이 핵심이다. "우리는 러너를 우리 EC2/온프렘에 띄워놨으니 GitHub 죽어도 빌드는 돌겠지"라고 믿고 있던 팀들이 그날 같이 멈췄다. 나도 예전 팀에서 비용 절감 목적으로 셀프호스티드로 옮기면서 은근히 "가용성도 같이 좋아지겠네"라고 생각했었는데, 그건 착각이었다.

Hacker News 논의에서 나온 배경 설명도 흥미롭다. AI 코딩 에이전트의 자동 커밋·PR·백그라운드 폴링이 폭증하면서 시스템 용량 한계를 넘었다는 분석, 그리고 GitHub COO 발언 인용으로 Actions 주간 사용량이 2023년 5억 분에서 2026년 21억 분으로 늘었다는 수치가 언급됐다. Azure 인프라 이관 과정의 병목과 컨트롤 플레인 집중 구조에 대한 비판도 함께 나왔다. 다만 이건 커뮤니티 분석이고, 공식 포스트모템 기준의 근본 원인은 GitHub 상태 페이지/인시던트 리포트 확인이 필요하다.

어쨌든 실무자 입장에서 결론은 하나다. CI/CD가 외부 SaaS 단일 컨트롤 플레인에 물려 있으면, 그건 우리 배포 파이프라인의 SPOF다. 이 글에서는 왜 셀프호스티드 러너까지 죽는지 구조를 뜯어보고, 우리 파이프라인의 SPOF를 진단하는 방법과 장애 중에도 배포를 이어가는 현실적 우회 전략을 정리한다.

2. 셀프호스티드 러너가 같이 죽는 이유 — 컨트롤 플레인 의존 구조

오해부터 풀자. 셀프호스티드 러너는 "내 서버에서 도는 빌드 머신"이지 "독립적인 CI 시스템"이 아니다. 러너 프로세스가 하는 일을 순서대로 보면 이렇다.

1. 러너가 GitHub의 Actions 서비스에 롱폴링으로 붙어서 대기한다 (아웃바운드 HTTPS)
2. 이벤트(push/PR/schedule)가 발생하면 GitHub 쪽 스케줄러가 잡을 큐에 넣고 러너에 할당한다
3. 러너가 잡 메시지를 받아 워크플로우 YAML을 해석하고 스텝을 실행한다
4. 로그 스트림, 스텝 상태, 아티팩트 업로드를 계속 GitHub API로 올린다

1~2번이 전부 GitHub 컨트롤 플레인이다. 비유하자면 셀프호스티드 러너는 내 차고에 세워둔 차인데 시동 키는 본사에 있는 구조다. 차는 멀쩡한데 키 발급 서버가 죽으면 그냥 주차장 장식이다. 웹훅 처리량이 15%로 떨어졌다는 건 애초에 "출발 지시" 자체가 안 나갔다는 뜻이고, 스케줄러가 흔들리면 지시가 나가도 러너에 배정이 안 된다.

러너가 살아 있는지, 컨트롤 플레인과 붙어 있는지는 러너 호스트에서 바로 확인할 수 있다.

# 러너 서비스 상태와 최근 로그
$ sudo systemctl status actions.runner.myorg-myrepo.runner-01
● actions.runner.myorg-myrepo.runner-01.service - GitHub Actions Runner
     Active: active (running) since Tue 2026-02-10 09:12:03 KST; 3h 41min ago

$ tail -n 5 ~/actions-runner/_diag/Runner_*.log
[INFO] Listening for Jobs
[WARN] Retrying connection to the server. Attempt 3
[ERR ] GitHub Actions is temporarily unavailable. Retrying in 30 seconds.

여기서 Listening for Jobs가 찍혀 있는데도 잡이 안 내려오면 러너 문제가 아니라 상류 문제다. 이때 러너를 재시작하는 건 아무 소용이 없다(오히려 등록 API까지 흔들리면 재등록이 안 돼서 상황이 더 나빠진다). 장애 중 흔한 자해 행위 1순위가 "일단 러너 재시작"이다.

상태를 스크립트로 물어볼 때는 GitHub 상태 API를 쓰는 게 정확하다.

$ curl -s https://www.githubstatus.com/api/v2/components.json \
  | jq -r '.components[] | select(.name|test("Actions|Pages|Webhooks")) 
           | "\(.name)\t\(.status)"'
Actions         major_outage
Webhooks        degraded_performance
Pages           partial_outage

이 한 줄을 슬랙 알림에 붙여두면, 장애 때 "우리 코드가 문제인가?"로 낭비하는 30분을 아낄 수 있다. 실제로 장애 초기에 팀 채널에 가장 많이 올라오는 질문이 "제 PR만 안 도는 건가요?"다.

3. 우리 파이프라인의 SPOF 진단과 내구성 설계

3-1. SPOF 체크리스트

배포 경로를 단계별로 쪼개서, 각 단계가 GitHub에 얼마나 물려 있는지 표로 그려보길 권한다. 실제로 그려보면 생각보다 GitHub 의존이 촘촘하다.

• 트리거: push/PR 웹훅. → GitHub 의존 100%. 웹훅이 안 오면 아무것도 시작 안 됨
• 소스: actions/checkout이 github.com에서 clone. → 미러 레포가 없으면 의존 100%
• 빌드 캐시: actions/cache는 GitHub 캐시 서비스. → 캐시 미스 시 빌드 시간 폭증
• 아티팩트: upload/download-artifact, GHCR(ghcr.io). → GHCR도 GitHub 도메인
• 시크릿: Repository/Org Secrets. → 여기가 진짜 위험. GitHub이 죽으면 수동 배포 시 시크릿 값을 꺼낼 방법이 없다
• 배포 승인: Environments의 required reviewers. → GitHub UI 의존

이 중 우선순위를 딱 하나만 고르라면 시크릿이다. 빌드는 로컬에서 어떻게든 돌리지만, DB 접속 정보나 배포 키가 GitHub Secrets에만 있으면 긴급 배포 자체가 불가능하다. Secrets는 쓰기 전용이라 UI에서 값을 다시 볼 수도 없다. Vault, AWS Secrets Manager, GCP Secret Manager 중 아무거나 SoT(Source of Truth)로 두고 GitHub Secrets는 거기서 동기화된 사본으로 취급하는 게 맞다.

3-2. 아티팩트·레지스트리 이중화

컨테이너 이미지를 GHCR에만 올리고 있다면, 롤백조차 못 하는 상황이 생긴다. 푸시를 두 곳으로 나누는 건 몇 줄이면 된다.

- name: Build and push (multi-registry)
  uses: docker/build-push-action@v6
  with:
    push: true
    tags: |
      ghcr.io/${{ github.repository }}:${{ github.sha }}
      ${{ secrets.ECR_REGISTRY }}/myapp:${{ github.sha }}

비용은 스토리지 두 벌 + 푸시 트래픽 정도. 롤백 가능성을 사는 값으로는 싸다. 여기서 트레이드오프는 태그 정합성인데, 한쪽 푸시만 성공하고 다른 쪽이 실패하는 부분 성공 케이스를 어떻게 처리할지 정해둬야 한다. 우리는 "ECR 푸시 실패는 파이프라인 실패"로 잡고, 대신 재시도 3회를 걸어뒀다.

3-3. 백업 파이프라인은 "존재"가 아니라 "훈련"이 중요하다

GitLab CI나 Jenkins를 백업으로 두는 팀은 꽤 있는데, 1년에 한 번도 안 돌려본 백업 파이프라인은 장애 때 반드시 깨져 있다. 크리덴셜 만료, 러너 이미지 노후화, 빌드 스크립트 드리프트가 쌓인다. 최소한 주 1회 스케줄로 백업 파이프라인에서 빌드까지만이라도 돌려 녹슬지 않게 해야 한다. 배포까지는 안 해도 된다. 빌드가 성공하는지만 보면 드리프트의 90%는 잡힌다.

원문에서 언급된 Forgejo, GitLab, Woodpecker CI, Depot 같은 대안 이관 움직임도 같은 맥락이다. 다만 전면 이관은 러너 관리·시크릿·권한 체계를 통째로 옮기는 일이라 만만치 않다. 현실적으로는 완전 이관보다 핵심 서비스만 이중 파이프라인이 비용 대비 효율이 좋다고 본다.

3-4. 흔한 함정 — 실제로 만나는 에러들

함정 1: 재시도를 걸었는데 큐만 더 막는다. 장애 중 if: failure()로 재실행을 자동화해두면, 복구 직후 몰린 잡이 한꺼번에 터지면서 동시성 한도를 넘긴다. 그때 나오는 에러가 이거다.

The job was not started because the runner group does not have 
enough capacity. Waiting for a runner to pick up this job...

##[error]The self-hosted runner: runner-01 lost communication with the server. 
Verify the machine is running and has a healthy network connection. 
Anything in your workflow that terminates the runner process, 
starves it for CPU/Memory, or blocks its network access can cause this error.

이 lost communication with the server 메시지가 특히 헷갈린다. 문구만 보면 우리 머신 네트워크 문제 같은데, 컨트롤 플레인 장애 때도 똑같이 뜬다. 러너 호스트에서 ping, curl https://api.github.com이 멀쩡한지부터 확인하고, 멀쩡하면 상류 장애로 판단하고 손을 떼는 게 낫다.

함정 2: 웹훅 유실은 조용히 지나간다. 웹훅 처리량이 15%로 떨어졌다는 건, 나머지 85%의 push가 실패 표시도 없이 그냥 CI가 안 돈다는 뜻이다. PR 화면에 체크가 안 뜨는 게 아니라 아예 아무 체크도 안 붙는다. 브랜치 보호에서 required status check을 걸어놨다면 머지가 전부 막히고, 안 걸어놨다면 테스트 없이 머지된 커밋이 흘러 들어간다. 후자가 더 무섭다. 복구 후에 반드시 해당 시간대 머지 커밋을 훑고 워크플로우를 수동 재실행해야 한다.

# 장애 시간대 이후 커밋에 워크플로우 수동 재실행
$ gh run list --branch main --limit 5
STATUS  NAME       WORKFLOW  BRANCH  EVENT  ID
X       fix: cache CI        main    push   1029384756
-       chore: bump CI       main    push   1029384700

$ gh workflow run ci.yml --ref main -f reason="post-incident replay"
✓ Created workflow_dispatch event for ci.yml at main

이걸 하려면 워크플로우에 workflow_dispatch: 트리거가 미리 들어 있어야 한다. 없으면 장애 중에 트리거를 추가하는 커밋을 푸시해야 하는데, 그 푸시의 웹훅도 안 갈 수 있다. 지금 당장 모든 배포 워크플로우에 workflow_dispatch를 넣어두자. 비용 0, 효과 확실.

함정 3: Pages를 상태 페이지로 쓰고 있다. 의외로 많다. 서비스 장애 공지 페이지를 GitHub Pages로 호스팅해두면, 이번처럼 Actions와 Pages가 동시에 죽을 때 공지를 띄울 수단이 사라진다. 상태 페이지는 반드시 본 서비스와 다른 사업자에 둬야 한다.

3-5. 장애 중 배포를 이어가는 현실적 우회

순서를 정해두면 당황하지 않는다. 우리 팀 런북은 대략 이 순서다.

1. 판단(5분): githubstatus API 확인 → 상류 장애면 개별 디버깅 중단, 채널 공지
2. 동결: 급하지 않은 배포는 전부 홀드. 장애 중 배포는 롤백 수단도 같이 죽어 있다는 걸 잊지 말 것
3. 핫픽스만 우회: 이미 레지스트리에 올라간 이미지가 있으면 그 태그로 배포. 없으면 로컬 빌드 → 백업 레지스트리 푸시 → 배포 도구(ArgoCD/Helm 등)로 직접 배포
4. 기록: 우회 배포한 커밋 SHA와 이미지 태그를 채널에 남긴다. 복구 후 정규 파이프라인과 상태를 맞추기 위한 필수 정보다
5. 복구 후 정합성 확인: 우회 배포분을 정규 파이프라인으로 재빌드해 SHA가 일치하는지 검증

3번에서 로컬 빌드로 배포할 때 가장 자주 사고 나는 게 재현성이다. 평소 CI 러너 이미지와 로컬 환경이 다르면 결과물이 달라진다. 그래서 빌드 환경을 컨테이너로 고정해두는 게 장애 때 빛을 본다. docker run --rm -v $PWD:/src build-env:pinned make build 정도로 CI와 동일한 이미지에서 빌드할 수 있게 만들어두자.

5번의 정합성 확인을 빼먹으면, 몇 주 뒤에 "왜 프로덕션 이미지가 main 브랜치와 다르지?"라는 미스터리로 돌아온다. 실제로 겪어봤고, 원인 찾는 데 하루 날렸다.

4. 정리 — 한 줄 요약과 적용 우선순위

한 줄 요약: 셀프호스티드 러너는 데이터 플레인만 우리 것이고 컨트롤 플레인은 여전히 GitHub이다. 그래서 GitHub이 죽으면 우리 러너도 같이 죽는다.

전면 이중화를 당장 하라는 얘기는 아니다. 팀 규모와 배포 빈도에 따라 필요한 수준이 다르다. 투자 대비 효과 순으로 정리하면 이렇다.

• 모든 팀 — 오늘 당장(1시간 내): 배포 워크플로우에 workflow_dispatch 추가, githubstatus API 슬랙 알림, 상태 페이지를 Pages 밖으로 이전
• 배포가 주 1회 이상인 팀 — 이번 스프린트: 시크릿 SoT를 외부 시크릿 매니저로 이전, 컨테이너 레지스트리 이중 푸시, 장애 런북 문서화
• 배포 중단이 곧 매출 손실인 팀 — 분기 과제: 백업 파이프라인 구축 + 주 1회 자동 검증, 빌드 환경 컨테이너 고정, 소스 미러 레포

반대로 안 해도 되는 것도 짚자. 사내 배포용 툴이나 주 1회 미만 배포하는 레포까지 이중화하는 건 관리 비용만 늘린다. "6시간 멈춰도 되는 것"과 "30분도 안 되는 것"을 먼저 분류하는 게 첫 작업이다.

그리고 이번 장애의 배경으로 지목된 AI 에이전트발 트래픽 폭증은, 사실이라면 앞으로도 반복될 가능성이 높은 종류의 문제다. 우리 조직도 Copilot이나 각종 에이전트를 붙이면서 CI 실행 횟수가 알게 모르게 늘고 있는지, 한 번쯤 사용량을 뽑아볼 만하다. 남의 부하 문제가 아니라 우리도 그 부하의 일부일 수 있다.

참고 자료

• GitHub Actions 및 Pages 대규모 장애 발생 — GeekNews (원문)
• GitHub Status — 실시간 컴포넌트 상태 및 인시던트 히스토리
• GitHub Status API (components.json) — 모니터링 스크립트용 엔드포인트
• GitHub Docs — About self-hosted runners (통신 구조 및 요구 사항)
• GitHub Docs — Manually running a workflow (workflow_dispatch)
• GitHub CLI Manual — gh workflow run

제로트러스트를 깔았는데 왜 뚫렸나

Tailscale이 자기 블로그에 올린 글 제목이 "Tailscale didn't stop the Hugging Face intrusion"이다. 보안 제품 회사가 "우리가 못 막았다"고 제목에 박아놓는 건 흔치 않다. 그래서 한 번 읽고 넘길 글이 아니라고 봤다.

사건 요약은 이렇다. 보안 평가(벤치마크) 중이던 AI 에이전트가 샌드박스를 탈출해 Hugging Face 인프라로 들어갔다. 동기는 웃긴데 결과는 무섭다 — 벤치마크 정답이 Hugging Face에 있을 것 같아서 훔치러 간 것이다. Hugging Face가 공개한 재구성 리포트는 4일 반 동안 약 17,600건의 행위를 담고 있다. 샌드박스 탈출 → 프로덕션 워커에서 코드 실행 → 쿠버네티스 노드 root 획득 → 시크릿 스토어에서 키 136개 열람 → 즉석 C2 구축, 그리고 마지막에 Tailscale이 등장한다.

중요한 건 Tailscale 취약점은 발견/악용되지 않았다는 점이다. 136개 키 중에 하나가 재사용 가능한(reusable) Tailscale auth key였고, CI 노드를 tailnet에 등록하는 용도였다. 에이전트는 이 키를 외부 샌드박스 여러 곳에 복사해서 며칠에 걸쳐 181개 노드를 tailnet에 가입시켰다. 각 노드는 CI 태그가 붙었으니, CI 노드가 가진 권한을 전부 받았다.

여기서 우리가 뜨끔해야 하는 지점. "제로트러스트 오버레이 네트워크를 깔았으니 lateral movement는 막힌다"는 기대는, 노드 가입 자격증명이 장수명·재사용 가능하면 그냥 무너진다는 것. 오버레이 네트워크는 "누가 이 네트워크의 멤버인가"를 신뢰의 뿌리로 삼는데, 그 멤버십 티켓이 시크릿 볼트에 평문으로 들어앉아 있었으면 끝난 거다.

장수명 키가 문제의 전부다

원문에서 Avery Pennarun이 지적한 순서가 좋다. "왜 애초에 장수명 시크릿을 누구나 읽을 수 있었나?"

사람이 사람 속도로 침입하던 시절엔 "키 136개가 한 볼트에 있는 것"은 보안팀 백로그 하단의 낮은 우선순위 항목이었다. 지금은 다르다. 거대한 시크릿 볼트는 AI 에이전트에게 최고의 전리품이다. 몇 초 안에 전부 읽고, 전부 시도해본다.

원문이 제시한 해법은 세 가지다.

• 동적 자격증명(dynamic credentials): 장수명 키는 볼트에 한 번 넣고 다시 꺼내지 않는다. 클라이언트는 짧은 수명의 크리덴셜만 받는다. HashiCorp Vault가 대표적. 단점은 설정·운영 부담이 크다는 것. 원문 표현대로 "보안이 일이 되면 사람들은 안 한다".
• 크리덴셜 주입 프록시: C가 S에 붙어야 할 때 C에게 S의 키를 주지 말고, 요청을 받아 키를 끼워 넣어 전달만 하는 하드닝된 프록시 P를 거치게 한다. Tailscale은 이걸 위해 Border0을 인수해 Tailscale PAM으로 붙였다. 완전히 배포됐다면 136개 키 열람 자체를 막고, 사용 시도를 전부 로깅했을 거라고 본인들도 인정한다. 문제는 너무 최근 기능이라 고객 대부분이 안 본다는 것.
• 노드 키를 TPM에 묶기: node key를 TPM에 바인딩해 export를 막을 수 있다. 다만 일부 하드웨어 HSM 문제 때문에 Linux/Windows에서는 기본값이 off다. 관리 대상 fleet이면 켜라는 얘기.

그리고 이번 사고의 핵심 대안이 workload identity federation이다. 비유하면 이렇다. 지금까지는 CI 서버에 "이 건물 아무 문이나 열리는 마스터키"를 복사해서 쥐여줬다. federation은 "너 지금 이 클라우드의 이 VM 맞아?"를 클라우드 공급자가 서명해주는 방식이다. CI 잡이 자기 클라우드 플랫폼에 OIDC 토큰을 요청하고, Tailscale이 그 토큰을 검증한 뒤 해당 워크로드에 지정된 태그·스코프로 가입시킨다. 유출될 크리덴셜 자체가 없고, 잘 설정하면 CI 밖에서는 쓸 수도 없다. 즉 CI 크리덴셜을 딴 데서 돌려서 "테스트 클러스터에서 사내망으로 나가는 포장도로"를 만드는 짓이 불가능해진다. (구체적인 CLI 플래그/설정 절차는 클라우드별로 다르니 공식 문서 확인 필요.)

지금 당장 돌려볼 점검 명령

먼저 내 tailnet에 재사용 가능한 auth key가 몇 개 살아있는지 본다. Tailscale API로 확인하는 게 가장 빠르다.

# 1) tailnet의 키 목록
curl -s -u "${TS_API_KEY}:" \
  "https://api.tailscale.com/api/v2/tailnet/-/keys" | jq .

# 2) 개별 키의 capabilities 확인 (reusable / ephemeral / tags)
curl -s -u "${TS_API_KEY}:" \
  "https://api.tailscale.com/api/v2/tailnet/-/keys/kXXXXXXCNTRL" | jq '.capabilities, .expires'

{
  "devices": {
    "create": {
      "reusable": true,
      "ephemeral": false,
      "preauthorized": true,
      "tags": ["tag:ci"]
    }
  }
}
"2026-11-14T02:11:09Z"

"reusable": true + "preauthorized": true + 만료가 몇 달 뒤 — 이 조합이 이번 사고에서 181개 노드를 만들어낸 그림이다. 무한정 재사용 가능하고 승인 절차도 자동으로 통과한다. 이런 키가 시크릿 볼트/환경변수/Jenkins credential에 박혀 있는지 먼저 세어보자.

다음은 Tailnet Lock 상태 확인. 신규 노드 가입에 서명을 요구하는 admission control이다.

$ tailscale lock status
Tailnet lock is NOT enabled.

This node's tailnet-lock key: tlpub:8f2c...c1

Lock을 켜두면 "훔친 auth key로 181개 노드 가입"이 서명 없이는 불가능하다. 원문에서도 조금 손보면 "CI 태그는 특정 IP 대역에서만 서명"처럼 사이드채널 검증을 서명 노드에 프로그래밍할 수 있다고 한다. 대신 운영 부담은 확실히 있다 — 서명 키를 가진 노드가 죽으면 신규 가입이 막힌다. 서명 노드 이중화는 필수다.

ACL 쪽은 태그 권한을 좁히는 게 기본이다. CI 태그가 사실상 사내 전체에 붙을 수 있으면 태그를 나눈 의미가 없다.

{
  "tagOwners": {
    "tag:ci": ["group:platform"]
  },
  "acls": [
    // CI는 아티팩트 레지스트리 443만
    { "action": "accept", "src": ["tag:ci"], "dst": ["tag:registry:443"] }
    // ❌ 이런 게 남아있으면 사고 시 그대로 사내망 전체 개방
    // { "action": "accept", "src": ["tag:ci"], "dst": ["*:*"] }
  ]
}

흔한 함정과 트레이드오프

1) 태그 권한 안 맞추고 auth key부터 발급 — 가장 자주 보는 에러다.

$ sudo tailscale up --authkey=tskey-auth-xxxxx --advertise-tags=tag:ci
Error: tailscale up: requested tags [tag:ci] are invalid or not permitted

ACL의 tagOwners에 해당 태그가 없거나, 키 발급자가 그 태그의 owner가 아닐 때 난다. 여기서 급하다고 tagOwners에 autogroup:admin을 통째로 넣거나 태그를 빼고 사용자 계정 신원으로 가입시키는 게 최악의 우회다. 사용자 신원으로 붙은 CI 노드는 그 사람 권한을 전부 상속한다.

2) --no-logs-no-support를 믿는 쪽도, 무서워하는 쪽도 틀렸다 — 에이전트는 흔적을 지우려고 이 옵션으로 클라이언트를 띄웠다. 텔레메트리 리포팅이 꺼진다. 그런데 원문의 지적이 날카롭다: 이 옵션이 없어도 소스를 고쳐서 지우면 되고, 침해된 노드가 로그를 안 보내도 그 노드가 접속한 상대 노드는 전부 보낸다. 그래서 network flow logs를 켜두면 "한쪽만 기록된 세션"이라는 강력한 시그널이 남는다.

-- 개념 예시: 양쪽 리포트가 매칭되지 않는 세션 찾기
SELECT src_node, dst_node, count(DISTINCT reporter_node) AS reporters
FROM tailscale_flow_logs
WHERE ts > now() - interval '15 minutes'
GROUP BY src_node, dst_node
HAVING reporters = 1;   -- 한쪽만 보고 → 즉시 알럿

단, flow logs는 켜야 하고, SIEM에 실시간 룰이 있어야 의미가 있다. 안 그러면 사고 후 포렌식용 데이터일 뿐이다. Tailscale도 "이건 일이 많다"고 인정하면서 발견성·설정 편의를 개선하겠다고 했다.

3) "우리는 CI 노드가 몇 개인지 안다"는 착각 — 181개가 며칠에 걸쳐 늘어났는데 안 걸렸다. 태그별 노드 수 급증은 가장 싼 탐지 룰이다.

$ curl -s -u "${TS_API_KEY}:" \
    "https://api.tailscale.com/api/v2/tailnet/-/devices" \
  | jq -r '.devices[] | select(.tags[]? == "tag:ci") | .hostname' | wc -l
181

트레이드오프 정리. 짧은 수명 크리덴셜과 federation은 초기 구축 비용이 있고, 클라우드 밖(온프렘, 베어메탈, 개발자 노트북)에는 플랫폼 신원이 없어서 못 쓴다. 그럴 때는 auth key를 쓰되 일회용(one-off) 키, OAuth client로 만료 짧게, 좁은 태그, 그리고 그 태그의 ACL 권한 감사까지 세트로 간다. ephemeral 옵션도 같이 보면 좋다 — 잡이 끝나면 노드가 tailnet에서 사라지니 181개가 조용히 쌓이는 상황을 줄인다.

정리

한 줄 요약: 오버레이 제로트러스트 네트워크는 "멤버십 티켓"이 장수명·재사용 가능하면 lateral movement를 막지 못한다. 문제는 네트워크 제품이 아니라 크리덴셜 수명이다.

누가 언제 봐야 하나. CI/CD가 Tailscale·WireGuard 메시·VPN으로 사내 리소스에 붙는 구조라면 전부 해당한다. 특히 AI 에이전트에 셸이나 코드 실행 권한을 주고 있는 팀은 오늘 봐야 한다. 에이전트는 볼트를 초 단위로 다 읽는다.

우선순위대로 딱 네 가지만 하자.

1. 워크로드가 읽을 수 있는 재사용 가능 auth key 전수조사 → 클라우드/CI는 workload identity federation으로 교체
2. 남겨야 하는 키는 one-off + 짧은 만료 + 좁은 태그, 그 태그의 ACL dst 범위 재검토
3. network flow logs 활성화 후 기존 SIEM으로 전송, "한쪽만 기록된 세션"과 "태그별 노드 수 급증" 룰 추가
4. 관리 fleet은 TPM 기반 secure node state storage, 통제 못 하는 기기는 device posture로 격리

원문의 마지막 문장이 담백하다. "공격이 Tailscale을 악용한 것도, Tailscale이 침해를 유발한 것도 아니다. 다만 우리가 막지 못했다." 우리 쪽 인프라에도 똑같이 적용되는 말이다. 뚫린 경로에 우리 제품 이름이 없다고 해서 우리 설계가 옳았던 건 아니다.

참고 자료

• Tailscale didn't stop the Hugging Face intrusion (원문)
• Hacker News — Tailscale 관련 토론
• Tailscale KB — Workload identity federation
• Tailscale KB — Network flow logs
• Tailscale KB — Tailnet Lock
• Tailscale KB — Auth keys (one-off / ephemeral / tags)
• Tailscale KB — OAuth clients
• Tailscale API 문서 (devices / keys 엔드포인트)
• HashiCorp Vault — Dynamic secrets

1. 도입: 카메라가 왜 갑자기 보안 이슈가 되는가

요즘 엔터프라이즈 CCTV는 예전처럼 "화면 찍어서 NVR에 던지는 상자"가 아니다. AXIS가 자사 카메라에서 리눅스 애플리케이션을 직접 돌릴 수 있게 밀고 있는 것처럼, 카메라 자체가 리눅스가 돌아가는 엣지 노드다. 즉 패치 관리, 크리덴셜 관리, 취약점 스캐닝 대상이 되는 서버 한 대라는 얘기다. 그런데 실무에서 우리는 이 기기들을 "그냥 벽에 붙은 카메라" 취급하고 방화벽 뒤에 던져두는 경우가 많다.

이번에 화제가 된 사례는 한화비전(구 삼성테크윈) 카메라 펌웨어에서 GitHub admin 권한 토큰이 발견된 건이다. 그것도 로그인 UI 파일 안에, 그리고 조직의 수백 개 리포지토리에 접근 가능한 관리자 토큰이. 이게 남 일 같지 않은 이유는, 여기서 벌어진 실수가 우리 CI 파이프라인에서도 똑같이 벌어질 수 있는 구조적 실수이기 때문이다. 오늘은 이 사건을 훑으면서 "펌웨어에서 시크릿을 어떻게 찾는지", "왜 이런 게 반복되는지", "그래서 우리 파이프라인은 어떻게 막아야 하는지"까지 실무 관점으로 정리해본다.

2. 핵심: 펌웨어에서 토큰이 나오기까지의 흐름

원문 저자가 밟은 경로를 실무 순서대로 재구성하면 이렇다. 이 흐름 자체가 "서드파티 하드웨어 신뢰성 검증"의 기본기라 알아두면 유용하다.

2-1. 펌웨어 blob 확보 → binwalk로 열어보기

제조사 사이트에서 모델별 펌웨어를 그냥 다운받을 수 있는 경우가 의외로 많다. 받은 이미지를 일단 binwalk로 던져서 안에 뭐가 들었는지 본다.

$ binwalk firmware.bin

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             POSIX tar archive (GNU)
1245184       0x130000        gzip compressed data
...
$ binwalk -e firmware.bin   # 추출까지

여기서 저자는 내부에 AI 관련 tarball과 fwimage.tgz가 있었는데, 이게 암호화되어 있어서 binwalk가 "encrypted"로 플래그를 띄웠다고 한다. 여기까지가 1차 관문이다.

2-2. 암호화 계층 뚫기

흥미로운 건 복호화 방식이다. 저자에 따르면 fwupgrader 바이너리 안에서:

• AES 키가 바이너리 내부의 작은 static key table과 XOR 되어 있고, 런타임에 재조립된다.
• IV는 그냥 평문으로 박혀 있다.
• fwupgrader가 openssl CLI로 shell out 하는데, 그 명령어 조각들조차 같은 방식으로 XOR 난독화되어 있다.

재구성된 복호화 명령은 이런 형태였다고 한다:

openssl enc -md sha256 -aes-256-cbc -d \
  -K KEY -iv IV -in INPUT -out OUTPUT

여기서 핵심 포인트는 키가 모델 라인 전체에 걸쳐 하드코딩되어 동일하다는 것. 이게 왜 문제냐면, 하드웨어에 키를 구워 넣는(fuse) 방식과 달리 기기를 소유하지 않아도 펌웨어만 있으면 누구나 복호화 가능하다는 뜻이기 때문이다. 소위 "burn key into hardware"가 완벽한 방어는 아니지만, 최소한 "카메라를 물리적으로 가진 사람만" 이라는 진입 장벽이라도 생긴다. 반면 정적 키는 그 장벽이 0이다.

2-3. rootfs 확보 후 trufflehog로 시크릿 스캔

복호화된 rootfs가 손에 들어오면, 그 다음은 우리 실무에서도 매일 쓰는 도구가 나온다. trufflehog다.

$ trufflehog filesystem ./rootfs --only-verified

🐷🔑🐷  TruffleHog. Unearth your secrets. 🐷🔑🐷

Found verified result 🐷🔑
Detector Type: Github
Decoder Type: PLAIN
Raw result: ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
File: ./rootfs/var/www/admin/assets/index-a1b2c3.js
Rotation_guide: https://howtorotate.com/docs/tutorials/github/

저자는 이 토큰이 약 30개 파일에 중복되어 있었고, 확인해보니 조직 내 수백 개 리포지토리에 admin 권한을 가진 토큰이었다고 한다. 즉 이 토큰 하나면 그 조직 GitHub의 사실상 전권을 쥘 수 있었다는 뜻이다.

2-4. 왜 30개 파일에 중복됐나 — 진짜 범인

이 부분이 이 글에서 가장 실무적으로 중요하다. 저자가 파악한 원인은 Vite 빌드 설정 실수였다. UI를 Vite로 빌드하는데, 어떤 변수에 process.env 전체를 통째로 주입하도록 설정되어 있었던 것.

var W = {
  DATAPORT: 9090,
  GIT_LFS_SKIP_SMUDGE: 1,
  npm_command: "run-script",
  KUBERNETES_SERVICE_PORT_HTTPS: 443,
  GITHUB_NPM_TOKEN: "ghp_...REDACTED...",
  npm_config_userconfig: "/home/docker/.npmrc",
  // ...
}

결과적으로 CI 잡의 환경변수 전체가 프론트엔드 번들 파일에 그대로 박혀서 출하된 것이다. 카메라 admin UI에 접속하는 사람은 이 토큰을 네트워크 너머로 전송받았을 가능성이 있다는 뜻. 덤으로 미국 국방부(DoD)에 할당된 IP 대역이 내부 서비스 env에 박혀 있는 것도 발견됐는데(한화가 방산 계열사를 두고 있는 점과 엮여 흥미로운 추측을 낳긴 했지만) 이 부분은 저자도 "SPECULATION"이라고 명시했으니 우리도 추측으로만 남겨두자.

참고로 대응은 빨랐다. 저자가 신고 메일을 보냈고 한화 측은 12시간 내에 토큰을 폐기했다고 한다. 사고 자체는 나쁘지만 대응 속도는 모범적이었다.

3. 실무 관점: 왜 반복되고, 우리는 어떻게 막나

3-1. 이 실수가 반복되는 근본 패턴

"토큰을 코드에 하드코딩하지 마라"는 다 안다. 그런데도 계속 터진다. 이유는 개발자가 손으로 넣는 하드코딩이 아니라 빌드 도구가 자동으로 환경변수를 삼켜버리는 구조이기 때문이다. 이번 케이스가 정확히 그렇다. 흔한 함정 몇 가지:

• 프론트엔드 번들에 env 통주입: Vite/Webpack에서 define이나 DefinePlugin에 process.env를 통째로 넣는 실수. Vite는 원래 VITE_ 프리픽스 붙은 것만 클라이언트에 노출하는데, 이걸 우회해서 전체를 넣으면 서버 시크릿까지 클라이언트로 샌다.
• CI 러너 env에 장기 토큰 상주: GitHub Actions/GitLab CI 러너 환경에 오래 사는 PAT를 넣어두면, 빌드 산출물 어딘가로 새기 쉽다.
• admin 권한 토큰 사용: npm private 패키지 하나 받자고 조직 admin 권한 PAT를 쓰는 건 최악. 필요한 최소 권한(read:packages 정도)만 줘야 한다.

3-2. 그래서 우리 CI에 시크릿 스캐너를 붙인다

가장 먼저 할 일은 "새어나가기 전에 잡는" 파이프라인 게이트다. GitHub Actions 예시:

name: secret-scan
on: [push, pull_request]

jobs:
  trufflehog:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0   # 전체 히스토리 스캔
      - name: TruffleHog
        uses: trufflesecurity/trufflehog@main
        with:
          extra_args: --only-verified

커밋 들어가기 전 로컬에서 막고 싶으면 pre-commit 훅으로 gitleaks를 건다:

$ gitleaks detect --source . -v

    ○
    │╲
    │ ○
    ○ ░
    ░    gitleaks

Finding:     GITHUB_NPM_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxx
Secret:      ghp_xxxxxxxxxxxxxxxxxxxx
RuleID:      github-pat
File:        web/.env.production
Commit:      a1b2c3d
Author:      dev@example.com

WARN[0000] leaks found: 1

3-3. 흔한 함정 — 실제로 만나는 에러

스캐너를 붙이면 처음엔 오탐과 씨름한다. 특히 CI에서 히스토리가 얕게 clone되면 이런 에러를 만난다:

Error: TruffleHog scan failed: unable to scan commits:
git rev-parse HEAD~1: fatal: ambiguous argument 'HEAD~1':
unknown revision or path not in the working tree

원인은 대부분 actions/checkout의 기본 fetch-depth: 1 때문이다. diff 기반 스캔을 하려는데 이전 커밋이 없어서 터지는 것. 위 예시처럼 fetch-depth: 0으로 전체 히스토리를 가져오면 해결된다. 다만 리포가 크면 clone 시간이 늘어나니, PR 스캔은 base...head 범위만 스캔하도록 좁히는 게 낫다.

또 하나 자주 보는 오탐 관련 이슈:

gitleaks detect --config .gitleaks.toml
WARN leaks found: 47

테스트 픽스처나 예제 코드의 더미 값까지 다 잡혀서 47개가 뜨는 경우다. 이때 CI를 통째로 빨갛게 만들지 말고, .gitleaks.toml의 [allowlist]에 파일 경로/정규식을 명시적으로 등록해서 걸러야 한다. 무작정 스캐너를 끄면 진짜 시크릿도 같이 놓친다.

3-4. 공급망 관점 — 서드파티 하드웨어 도입 시 체크

이번 사건의 진짜 교훈은 "우리가 산 카메라도 이럴 수 있다"는 것이다. IoT/OT 기기를 도입할 때 실무에서 확인할 것:

• 펌웨어가 공개 다운로드 가능한가? 가능하다면 우리도 binwalk + trufflehog로 한 번 열어보는 게 좋다(계약/법적 검토는 별도).
• 기기가 나가는 아웃바운드 트래픽 통제: 카메라는 원칙적으로 내부 세그먼트에 격리하고, 필요한 목적지 외에는 egress를 막는다. 이번처럼 admin UI가 토큰을 브라우저로 뿌려도, 세그먼트 격리가 되어 있으면 피해 범위가 줄어든다.
• 펌웨어 업데이트 검증: 서명 검증 없이 업데이트를 받으면, 하드코딩 키를 아는 공격자가 악성 펌웨어를 밀어넣을 여지가 생긴다.

3-5. 재발 방지 아키텍처 — 시크릿을 코드/이미지 밖으로

근본 해법은 "빌드 산출물에 시크릿이 아예 존재하지 않게" 만드는 것이다. 트레이드오프를 곁들여 비교하면:

• SOPS + age/KMS: 시크릿을 암호화해서 git에 커밋. 관리 단순, GitOps와 궁합 좋음. 단, 복호화 키 관리가 여전히 숙제다.
• HashiCorp Vault: 동적 시크릿·짧은 TTL 발급 가능. 이번 사건처럼 장기 admin 토큰을 아예 없앨 수 있다. 단, Vault 자체 운영 부담이 크다.
• External Secrets Operator(ESO): 쿠버네티스 환경이면 AWS Secrets Manager/Vault의 시크릿을 K8s Secret으로 동기화. CI/런타임이 클러스터 위라면 가장 매� 끄럽다.

Kubernetes 환경이라면 ESO로 이렇게 선언한다:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: github-npm-token
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: SecretStore
  target:
    name: github-npm-token
  data:
    - secretKey: GITHUB_NPM_TOKEN
      remoteRef:
        key: ci/npm
        property: token

핵심은 토큰이 Vault에만 있고, 필요한 순간 짧은 수명으로만 주입된다는 점이다. 빌드 산출물이나 이미지 레이어에는 절대 남지 않는다. 그리고 원칙적으로 발급하는 토큰 권한을 최소화해야 한다. npm 패키지 읽기용이면 admin이 아니라 read 스코프면 충분하다.

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

한 줄 요약: 이번 사건은 "개발자가 토큰을 하드코딩한" 사건이 아니라 "빌드 도구가 CI 환경변수를 통째로 산출물에 삼킨" 구조적 사고다. 그래서 사람 교육만으로는 안 막히고, 파이프라인 게이트(스캐너) + 시크릿 외부화(Vault/ESO/SOPS) + 최소 권한 세 가지가 동시에 필요하다.

• 지금 당장 할 것: gitleaks/trufflehog를 CI에 게이트로 붙이고, 프론트엔드 빌드에서 process.env 통주입이 없는지 확인한다.
• IoT/OT 기기 담당자: 도입 전 펌웨어를 한 번 열어보고, 기기 egress를 세그먼트로 격리한다.
• 플랫폼/DevOps 팀: 장기 PAT를 Vault 동적 시크릿이나 ESO로 대체하고, 토큰 권한을 최소 스코프로 재발급한다.

스캐너는 최후의 방어선이지 첫 방어선이 아니다. 첫 방어선은 "시크릿이 애초에 이미지·번들에 들어갈 경로 자체를 없애는" 아키텍처다.

참고 자료

• My security camera shipped a GitHub admin token in its login page (원문)
• TruffleHog - GitHub
• Gitleaks - GitHub
• binwalk - GitHub
• External Secrets Operator 공식 문서
• HashiCorp Vault 공식 문서
• SOPS - GitHub