20장. 보안과 거버넌스

솔로 빌더에게 보안은 종종 "나중에 팀이 생기면 정리할 일"로 밀립니다. 하지만 에이전트 코딩 시대에는 이 생각이 가장 비싼 습관이 됩니다. 이제 한 사람의 실수는 한 사람의 실수로 끝나지 않습니다. AI 에이전트는 파일을 읽고, 명령을 실행하고, 외부 서비스와 연결됩니다. 생산성이 커진 만큼 사고 반경도 커집니다.

실제로 2026년에는 공격자가 Claude Code를 자신들의 개발·운영 워크플로우에 끼워 넣어 대규모 자격 증명 수집 작전을 굴린 사례까지 공개됐습니다. 핵심은 "AI가 나쁘다"가 아닙니다. 좋은 도구도 잘못된 파이프라인에 들어가면 공격 생산성을 키울 수 있다는 점입니다.¹ 반대로 말하면, 솔로 빌더도 보안을 체계로 만들어두기만 하면 작은 팀 규모로도 꽤 강한 운영 기준을 세울 수 있습니다.

이 장의 메시지는 단순합니다. 솔로라고 해서 보안을 대충 해도 되는 시대는 끝났습니다. 이제는 빠르게 만드는 사람보다, 빠르게 만들면서도 사고를 작게 만드는 사람이 오래 살아남습니다. Claude Code와 에이전트 워크플로우를 쓸수록 더 그렇습니다.

20.1 자격 증명 스크러빙

API 키, 데이터베이스 비밀번호, OAuth 토큰은 제품의 연료이면서 동시에 가장 위험한 인화물입니다. 솔로 빌더가 가장 자주 하는 실수는 두 가지입니다. 하나는 키를 코드에 박아 넣는 것이고, 다른 하나는 "어차피 내 로컬인데 괜찮겠지" 하며 세션 기록, 로그, 스크린샷, 파일 히스토리에 키를 흘리는 것입니다.

먼저 원칙부터 세웁시다. 자격 증명은 가능한 한 모델에게 보여주지 말고, 코드에도 남기지 말고, 디스크에도 오래 두지 않는다. 이 세 문장만 기억해도 절반은 막습니다.

Claude Code 생태계에서는 이 원칙을 구조로 만들 수 있습니다. 플러그인이 필요로 하는 자격 증명을 OS 키체인에 저장하고, 플러그인 코드가 키를 읽어 외부 API를 호출한 뒤 구조화된 결과만 모델에 넘기는 방식이 대표적입니다. 이때 중요한 건 "키를 안전하게 저장했다"가 끝이 아니라는 점입니다. 키체인은 저장 위치를 안전하게 만들 뿐이고, 진짜 경계는 모델이 키 그 자체를 컨텍스트로 보지 않게 설계하는 것입니다. 여기에 CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 같은 환경 스크러빙을 더하면 bash 도구, hooks, MCP stdio 서버 같은 하위 프로세스로 자격 증명이 새는 경로도 줄일 수 있습니다.²

반대로, 로컬 세션 데이터는 생각보다 쉽게 비밀을 축적합니다. Claude Code 관련 세션 파일, 붙여넣기 캐시, 파일 스냅샷, 명령 출력 기록에는 과거에 한 번 보여준 키가 평문으로 남을 수 있습니다. 그래서 "키를 지웠다"와 "유출이 없었다"는 전혀 다른 말입니다. 세션 데이터에서 키를 스크럽하는 도구들은 분명 유용하지만, 어디까지나 청소 도구이지 취소 버튼은 아닙니다. 이미 노출된 키는 반드시 폐기하고 새로 발급해야 합니다.³

여기서 실무적으로 기억할 포인트는 네 군데입니다.

• 코드 저장소: 하드코딩 금지, .env는 커밋 금지, 대신 .env.example만 남깁니다.

• 실행 환경: 가능하면 키체인, 시크릿 매니저, 프록시 주입 방식을 우선합니다.

• 대화와 로그: 디버깅한다고 키를 붙여 넣지 말고, 로그 공유 전에는 PII와 토큰을 먼저 마스킹합니다.

• 세션 흔적: Claude 관련 로컬 데이터도 정기적으로 스캔하고 필요하면 스크럽합니다.

보안 플러그인이나 스크럽 도구를 루틴에 넣으면 사고 확률이 크게 줄어듭니다. 예를 들어 민감한 파일 읽기를 막는 credential guard, 이미지 메타데이터 제거, 로그 PII 삭제, .gitignore 검증, 파일 권한 감사 같은 기능은 "실수했는지 나중에 알게 되는" 순간을 "실수하기 전에 막는" 순간으로 바꿔 줍니다.⁴ 이 차이는 큽니다. 커밋 후에 놀라는 것보다, 저장 직후 경고받는 쪽이 훨씬 싸니까요.

솔로 빌더에게 추천하는 최소 기준은 이렇습니다. 개발을 시작할 때는 .env와 키 파일이 .gitignore에 들어 있는지 확인합니다. 커밋 전에는 시크릿 스캔을 돌립니다. 로그를 외부에 공유하기 전에는 이메일, IP, 전화번호, 토큰 같은 값을 마스킹합니다. 그리고 한 번이라도 키가 세션, 로그, 커밋, 스크린샷에 노출됐다면 "나중에 치우자"가 아니라 즉시 회전합니다. 스크럽은 청소이고, 회전은 치료입니다.

보안을 더 쉽게 기억하는 방법도 있습니다. 키는 숨기는 게 아니라, 되도록 안 보여주는 것입니다. 숨겨 둔 키는 언젠가 새지만, 처음부터 모델과 세션이 보지 못한 키는 샐 일이 적습니다.

20.2 PID 네임스페이스 격리와 서브프로세스 샌드박스

AI 에이전트를 쓸 때 사람들이 가장 자주 착각하는 부분이 있습니다. "승인 팝업이 있으니 안전하겠지." 아닙니다. 승인 시스템은 브레이크입니다. 샌드박스는 가드레일입니다. 브레이크만 있고 가드레일이 없으면, 한 번 미끄러질 때 낭떠러지가 가까울 수 있습니다.

Claude Code 문서가 강조하듯이, 에이전트는 전통적인 소프트웨어처럼 고정된 코드 경로만 따라가지 않습니다. 읽은 파일, 웹 콘텐츠, README, 사용자 입력에 섞인 이상한 지시를 맥락으로 받아들여 예상 밖의 행동을 할 수 있습니다. 이것이 프롬프트 인젝션 위험입니다.⁵ 그래서 보안의 핵심은 "모델이 완벽하게 판단할 것"을 믿는 게 아니라, 잘못 판단해도 피해가 작도록 경계를 나누는 것입니다.

여기서 가장 중요한 개념이 최소 권한과 격리입니다. 쉽게 말해, 에이전트에게는 필요한 것만 주고, 그마저도 가능한 한 좁은 상자 안에서 하게 만드는 것입니다. 예를 들어 다음 같은 기준이 기본입니다.

• 민감한 호스트 디렉터리(~/.ssh, ~/.aws, ~/.config)는 마운트하지 않습니다.

• 코드베이스는 가능하면 읽기 전용으로 붙입니다.

• 네트워크는 전면 허용 대신 허용된 도메인만 통과시키는 프록시를 둡니다.

• 컨테이너 안에서는 루트가 아닌 사용자로 실행하고, capability를 떼고, 프로세스 수와 메모리를 제한합니다.

Claude Code의 권한 규칙은 명령을 실행하기 전에 AST 수준으로 파싱해 허용·차단·승인을 결정합니다. 이건 훌륭한 첫 번째 문입니다. 하지만 문서도 분명히 말하듯, 그것만으로는 샌드박스가 아닙니다.⁵ 즉, "sudo는 막았다"와 "이 프로세스가 밖으로 못 나간다"는 다른 이야기입니다.

솔로 빌더라면 격리 수준을 세 단계로 나눠 생각하면 편합니다.

첫째, 로컬 개발 단계입니다. 이 단계에서는 권한 규칙, 승인 프롬프트, 민감 명령 차단 hook, 환경 변수 스크러빙만으로도 큰 진전입니다. 혼자 개발하더라도 rm -rf, 강제 푸시, 운영 DB 쓰기 같은 명령은 기본 차단이 맞습니다.

둘째, 자동화와 CI 단계입니다. 여기서는 샌드박스 런타임이나 보안 강화 컨테이너를 쓰는 편이 낫습니다. 읽기 전용 루트 파일시스템, --cap-drop ALL, no-new-privileges, --network none, 제한된 tmpfs, 비루트 사용자 같은 옵션은 화려해 보이지만 사실상 "사고 범위를 줄이는 최소 예절"에 가깝습니다.⁵ 특히 네트워크를 끊고 외부 통신을 프록시 소켓 하나로만 내보내는 구조는, 에이전트가 엉뚱한 서버로 데이터를 내보내려 해도 길 자체를 봉쇄해 버립니다.

셋째, 고위험 작업 단계입니다. 고객 데이터가 많거나, 신뢰할 수 없는 저장소를 분석하거나, 원격 서버에서 헤드리스로 오래 돌린다면 gVisor나 별도 VM 같은 더 강한 격리를 고려해야 합니다.⁵ 여기까지 오면 혼자서도 "작은 엔터프라이즈"처럼 사고해야 합니다. 제품 규모가 아니라, 사고 비용이 기준입니다.

PID 네임스페이스 격리와 서브프로세스 샌드박스가 중요한 이유는 의외로 단순합니다. 에이전트가 잘못된 명령을 내렸을 때, 그 명령이 같은 프로세스 트리에서 무엇을 보고 무엇을 건드릴 수 있는지가 달라지기 때문입니다. 보안에서 좋은 구조는 똑똑한 구조가 아니라, 잘못해도 크게 못 망가뜨리는 구조입니다.

혼자 일할 때일수록 이런 생각이 더 중요합니다. 팀이 없으니 리뷰어도 없고, 보안팀도 없고, 새벽 3시에 복구해 줄 사람도 없습니다. 그래서 샌드박스는 불신의 표현이 아니라 자기 자신을 위한 보험입니다.

20.3 OpenTelemetry로 모든 결정을 감사 추적하기

거버넌스라는 말은 혼자 일하는 사람에게 너무 기업 냄새가 나 보일 수 있습니다. 하지만 뜻은 어렵지 않습니다. 무슨 일이 있었는지 나중에 설명할 수 있는 상태가 거버넌스입니다.

AI 에이전트가 코드와 인프라를 건드리기 시작하면, "왜 이렇게 바뀌었지?"라는 질문은 자주 생깁니다. 더 무서운 질문은 이겁니다. "이 삭제는 누가 승인했지?" "이 도구 호출은 어떤 인자로 실행됐지?" "어제 비용이 왜 갑자기 세 배가 됐지?" 여기에 답할 수 없으면 자동화는 편리한 대신 불안한 시스템이 됩니다.

Claude Code는 OpenTelemetry를 통해 메트릭, 로그/이벤트, 선택적으로 트레이스를 내보낼 수 있습니다. 즉, 사용량, 비용, 도구 활동을 표준 관측 체계로 수집할 수 있다는 뜻입니다.⁶ 솔로 빌더에게 이 기능이 특히 좋은 이유는, 별도 대규모 플랫폼 없이도 "내 에이전트가 실제로 뭘 했는지"를 흐름 단위로 볼 수 있기 때문입니다.

다만 여기에는 중요한 함정이 있습니다. 관측성은 보안을 돕지만, 잘못 켜면 보안을 해칠 수도 있습니다. Claude Code 문서에는 사용자 프롬프트, 도구 상세 정보, 도구 입출력 내용, 심지어 전체 Messages API 요청·응답 바디까지 로깅하는 옵션이 있습니다. 이런 옵션은 기본적으로 꺼져 있고, 켤 때는 그 자체가 민감 정보 수집이라는 사실을 이해해야 합니다.⁶ 즉, 감사 로그를 만든다고 해서 원본 비밀까지 한데 모아 버리면 CCTV를 달겠다고 집 열쇠를 현관에 걸어두는 셈입니다.

그래서 실무 기준은 "많이 남기는 것"이 아니라 "검증 가능한 최소 정보만 남기는 것"입니다. 추천하는 기본 필드는 다음과 같습니다.

• 세션 ID, 사용자 또는 실행 주체, Git 커밋 SHA

• 어떤 프롬프트/작업에서 나온 실행인지 연결해 주는 prompt ID

• 호출된 도구 이름, 시작/종료 시각, 실행 시간, 성공/실패 여부

• 인자와 결과의 원문이 아니라 해시 또는 요약

• 승인 여부, 승인 규칙의 출처, 비용과 토큰 사용량

특히 MCP 도구처럼 외부 세계를 건드리는 호출은 일반 로그보다 한 단계 더 강한 증빙이 필요할 수 있습니다. 이때 유용한 패턴이 인증 프록시 + 해시 체인 + 영수증(receipt) 방식입니다. 도구 호출 앞뒤에서 인자와 응답을 표준화해 해시를 만들고, 각 영수증을 이전 영수증 해시와 연결하면 중간 기록이 빠지거나 바뀌었는지 감지할 수 있습니다.⁷ 쉽게 말해, 일반 로그가 영수증 뭉치라면 해시 체인은 페이지마다 도장을 찍은 장부입니다. 누가 한 장을 몰래 찢어도 티가 납니다.

솔로 빌더가 여기까지 꼭 해야 하냐고 묻는다면, 답은 "모든 곳에 다는 아니지만, 돈·고객 데이터·삭제 작업에는 예"입니다. 예를 들어 환불 처리, 고객 계정 수정, 데이터 삭제, 운영 인프라 변경 같은 작업은 최소한 다음 두 가지가 필요합니다. 첫째, 실행 이력. 둘째, 승인 이력. 이 둘이 있어야 사고 후에 원인을 좁힐 수 있습니다.

감사 추적을 가볍게 시작하는 방법도 있습니다. 로컬에서는 OTel로 비용, 도구 호출 수, 실패율, 세션별 토큰 사용량을 수집합니다. 중요한 MCP 서버 앞에는 간단한 프록시를 두어 도구명·인자 해시·응답 해시를 저장합니다. 그리고 파괴적 작업은 "자동 실행"이 아니라 "항상 승인 필요"로 분리합니다. 이것만 해도 나중에 "AI가 알아서 했어요"라는 가장 위험한 문장을 피할 수 있습니다.

좋은 거버넌스는 자유를 줄이지 않습니다. 오히려 자동화를 더 멀리 밀어붙일 수 있게 만듭니다. 왜냐하면 기록이 있으면, 두려움 대신 수정 가능한 학습이 생기기 때문입니다.

20.4 솔로 빌더의 백업과 복구 전략

코드는 GitHub에 있으니 괜찮다고 생각하기 쉽습니다. 하지만 Claude Code 시대의 작업 환경은 코드만으로 복구되지 않습니다. 당신의 실전 생산성은 CLAUDE.md, 설정 파일, 권한 규칙, skills, commands, hooks, agents, MCP 구성, 프로젝트 메모리, 세션 기록 같은 "주변부"에 많이 숨어 있습니다. 노트북을 잃어버리거나 머신을 갈아엎는 순간, 코드는 살아 있어도 워크플로우는 죽을 수 있습니다.

실제로 Claude Code 백업 가이드들은 백업 대상을 코드가 아니라 작업 환경 전체로 봅니다. 전역 CLAUDE.md, 추가 컨텍스트 파일, settings.json, 로컬 권한 설정, keybindings, MCP 구성, skills, plugins, plans, custom commands, subagents, hooks, scheduled tasks, 프로젝트 메모리, 세션 transcript, subagent transcript, tool result payload까지 챙겨야 "같은 사람처럼 다시 일하는 환경"이 복구됩니다.⁸

그렇다고 무조건 다 백업하면 안 됩니다. 백업은 복구 가능성을 높이지만, 동시에 민감 정보 복제 수를 늘립니다. 그래서 제외 규칙이 중요합니다. 인증 토큰 파일, 거대한 전역 히스토리, 캐시, telemetry, debug 로그, 붙여넣기 캐시, 머신 종속 상태는 의도적으로 빼는 편이 낫습니다.⁸ 백업은 많을수록 좋은 게 아니라, 복구에 필요한 것만 남길수록 안전한 것입니다.

솔로 빌더에게 권하는 백업 전략은 네 겹입니다.

• 코드와 인프라 설정은 평소대로 Git 원격 저장소에 보냅니다.

• Claude Code 환경 파일은 비공개 저장소나 암호화된 아카이브로 주기 백업합니다.

• 월 단위 스냅샷은 외장 SSD나 클라우드 같은 오프사이트 위치에도 둡니다.

• 분기마다 한 번은 실제 복구 연습을 합니다.

여기서 핵심은 마지막 줄입니다. 복구 훈련 없는 백업은 희망사항입니다. 압축 파일이 있다고 끝이 아닙니다. 새 머신에서 실제로 CLAUDE.md, skills, hooks, MCP 설정, 프로젝트 메모리까지 되살아나는지 확인해야 합니다. 어떤 백업 시스템은 외장 SSD와 개인 클라우드 드라이브에 날짜 스탬프 아카이브를 남기고, 복원 스크립트까지 제공하는데, 이런 방식의 장점은 "머리를 쓰지 않아도 되는 복구 절차"를 만든다는 데 있습니다.⁹

특히 솔로 빌더에게는 백업 대상 우선순위를 이렇게 잡는 것이 현실적입니다.

첫째는 제품 복구입니다. 소스 코드, DB 스키마, 환경 설정, 배포 스크립트, 인프라 정의가 여기에 들어갑니다.

둘째는 에이전트 복구입니다. CLAUDE.md, slash commands, subagents, hooks, skills, MCP 설정이 여기에 들어갑니다. 이게 없으면 새 노트북에서 개발은 되지만, 이전만큼 빠르지 않습니다.

셋째는 맥락 복구입니다. 프로젝트 메모리, 중요한 세션 transcript, 의사결정 기록이 여기에 들어갑니다. 이게 없으면 왜 그렇게 설계했는지 다시 파헤쳐야 합니다.

복구 전략을 세울 때는 보안과도 연결해야 합니다. 백업 저장소 자체는 비공개여야 하고, 가능하면 암호화해야 하며, 접근 권한을 최소화해야 합니다. 그리고 백업 전에 민감한 로그와 세션을 먼저 스크럽할지, 아니면 원본은 로컬 안전 영역에만 두고 공유용 sanitized export를 따로 만들지 기준을 정해야 합니다.⁸ 백업은 안전망이지만, 잘못 다루면 또 하나의 유출 지점이 됩니다.

좋은 백업의 목표는 "모든 걸 저장한다"가 아닙니다. "최악의 날에도 내 작업체계를 한 번에 되살린다"입니다. 솔로 빌더에게 이것은 선택이 아니라 체력 관리에 가깝습니다. 혼자서는 복구 중에도 누가 대신 제품을 운영해 주지 않으니까요.

보안은 속도를 늦추지 않는다

여기까지 읽고 나면 보안과 거버넌스가 꽤 귀찮아 보일 수 있습니다. 맞습니다. 조금은 귀찮습니다. 하지만 이 귀찮음은 제품을 만드는 속도를 늦추는 종류의 귀찮음이 아닙니다. 오히려 속도를 오래 유지하게 해 주는 귀찮음입니다.

정리해 봅시다. 자격 증명은 가능한 한 모델과 세션에 보여주지 않습니다. 에이전트는 권한 규칙만 믿지 말고 샌드박스로 감쌉니다. 중요한 도구 호출은 OpenTelemetry와 영수증 체계로 추적합니다. 그리고 코드는 물론 Claude Code 작업 환경 전체를 복구 가능한 형태로 백업합니다.

솔로라고 보안팀이 없는 게 아닙니다. 당신이 보안팀입니다. 다만 다행인 건, 이제는 그 역할을 혼자서도 꽤 잘할 수 있는 도구와 패턴이 있다는 점입니다.

참고

¹Attacker embeds Claude Code in mass credential harvesting op

²Claude Code plugin credentials: what the new keychain storage does and doesn't do

³GitHub - penguinboi/claude-scrub: Find and remove secrets from Claude Code local session data

⁴GitHub - iamfiscus/claude-code-scrub: Claude Code plugin for scrubbing sensitive data

⁵Securely deploying AI agents - Claude Code Docs

⁶Monitoring - Claude Code Docs

⁷How to Build an Audit Trail for MCP Tool Calls — ArkForge Blog

⁸GitHub - jtklinger/claude-code-backup-guide: A comprehensive guide to backing up and restoring Claude Code settings across machines

⁹Claude Backup System