AI 코딩 보안: Claude Code 베스트 프랙티스 (2026)

이 값들에 의존하기 전에, 명령어 이름과 권한 모드를 Claude Code 공식 문서에서 확인하세요.

왜 AI 코딩에는 다른 보안 사고방식이 필요할까요

예전의 자동완성은 텍스트를 제안하기만 했어요. Claude Code 같은 AI 코딩 에이전트는 근본적으로 다른 존재예요. 리포지토리 전체를 읽고, 실제 셸 명령을 실행하고, 파일을 편집하고, 외부 도구(MCP, web fetch, GitHub)를 호출해요. 이 세 가지 능력이 겹치면, 기존 lint나 코드 리뷰로는 결코 잡을 수 없던 공격 표면이 생겨요.

가장 이해하기 쉬운 비유는—Backslash Security 분석(2025년 9월 18일)에서 빌려온 것인데—에이전트를 「root 권한을 가진 아주 빠른 인턴」으로 보는 거예요. 이 인턴은 여러분보다 열 배 빠르게 코드를 치지만, 동시에 엉뚱한 디렉터리를 rm -rf 하거나, API 키를 커밋에 붙여 넣거나, 방금 읽은 GitHub issue에 숨겨진 「명령」을 충실히 따를 수도 있어요. 악의가 있는 게 아니라, 무엇이 위험한지에 대한 맥락이 없을 뿐이에요.

핵심 통찰은 이거예요. 위험은 "AI가 나쁜 코드를 쓴다"가 아니에요. 위험은 권한(에이전트가 여러분 머신에서 무엇을 할 수 있는지)과 입력에 대한 신뢰(에이전트가 누구를 믿는지)에 있어요. 그래서 올바른 보안 전략은 "제안되는 한 줄 한 줄을 주의 깊게 읽는 것"이 아니라, 체계적인 가드레일을 구축하는 거예요. 권한을 제한하고, 환경을 격리하고, 오가는 데이터를 통제하고, 최종 결정에는 늘 사람을 남겨 두는 것이죠. 이 글의 나머지 부분에서는 각 계층을 하나씩 어떻게 실천하는지 다뤄요.

AI 코딩의 6가지 주요 보안 위험

무언가를 손보기 전에, 무엇으로부터 방어하려는지 알아야 해요. 실무에서 가장 자주 마주치는 여섯 가지 위험 범주를, 각각 구체적인 시나리오와 함께 소개할게요.

이 여섯 가지 위험은 아래 여섯 가지 베스트 프랙티스와 거의 일대일로 대응해요. 전부 한 번에 할 필요는 없어요—다만 어떤 계층을 건너뛴다면, 자신이 어떤 위험을 받아들이는지 정확히 알고 있어야 해요.

베스트 프랙티스 1 - 시크릿과 민감 데이터 관리하기

근본 원칙: 시크릿은 에이전트가 평문으로 읽을 수 있는 어디에도 존재해서는 안 돼요. 저렴한 것부터 견고한 것까지 네 개의 방어 계층이 있어요.

1. 시크릿을 리포지토리 밖에 두기. .gitignore로 .env를 Git 밖에 두고, 플랫 파일보다 시크릿 매니저(Vault, Doppler, 1Password CLI, CI의 환경 변수)를 우선하세요. 이건 AI가 없어도 해야 할 일이에요—AI는 그 뒤처리를 더 심각하게 만들 뿐이죠.

2. 민감한 파일을 에이전트의 컨텍스트에서 빼기.Claude Code 보안 문서의 방법은 .claude/settings.json에서 permissions.deny에 Read() 규칙을 쓰는 거예요—패턴에 일치하는 파일을 에이전트가 읽을 수 없게 돼요.

{
 "permissions": {
 "deny": [
 "Read(./.env)",
 "Read(./.env.*)",
 "Read(./**/secrets/**)",
 "Read(./**/*.pem)",
 "Read(./**/*.key)"
 ]
 }
}

(일부 오래된 가이드는 .claudeignore 파일을 언급해요. 여러분의 CLI 버전이 아직 지원한다면 좋지만, 공식 문서가 권장하는 건 Read()를 쓰는 permissions.deny예요.)

3. 자동 시크릿 스캔.사람 눈을 믿지 마세요. gitleaks(또는 git-secrets, TruffleHog)를 pre-commit hook과 CI에 넣어, 키가 담긴 커밋이 머신을 떠나기 전에 차단하세요.

# pre-commit: block the commit if a secret is detected
gitleaks protect --staged --redact --verbose

4. 유출되면 로테이션하기.키가 컨텍스트나 커밋에 들어갔다면 영구적으로 침해된 것으로 취급하세요—커밋을 지우는 것만으로는 부족해요. 키가 이미 로그/모델/이력에 남아 있을 수 있으니까요. 올바른 절차는 이래요. 옛 키 폐기 -> 새 키 발급 -> 시크릿 매니저 갱신 -> 접근 로그에서 이상 징후 확인. 필요해지기 전에 로테이션 런북을 준비해 두세요.

베스트 프랙티스 2 - 권한을 통제하고 샌드박스에서 실행하기

이건 ROI가 가장 높은 계층이에요. Claude Code에는 에이전트가 스스로 무엇을 할 수 있는지 정하는 여러 권한 모드가 있어요.

직설적인 경고: bypassPermissions(그리고 --dangerously-skip-permissions 플래그)는 이름 그대로예요—위험해요. 이름에 "dangerously(위험하게)"라는 단어가 들어간 건 의도적이에요. 진짜 시크릿, 운영 접근, 고객 리포지토리가 있는 곳에서는 절대 켜지 마세요. 에이전트를 무인으로 돌려야 한다면(배치 작업, CI), 메인 머신이 아니라 샌드박스 안에서 하세요.

settings.json에서는 최소 권한을 적용하세요. 안전한 건 기본으로 허용하고, 위험한 건 확인(ask)하고, 스스로 절대 실행해서는 안 될 건 아예 거부(deny)해요. 복사해서 바로 쓰는 템플릿이에요.

{
 "permissions": {
 "allow": [
 "Read(./src/**)",
 "Bash(npm run test:*)",
 "Bash(git status)",
 "Bash(git diff:*)"
 ],
 "ask": [
 "Bash(git push:*)",
 "Bash(npm install:*)",
 "Write(./src/**)"
 ],
 "deny": [
 "Bash(rm -rf:*)",
 "Bash(curl:*)",
 "Bash(sudo:*)",
 "Read(./.env)",
 "Read(./.env.*)"
 ]
 }
}

컨테이너로 격리하기.피해 범위를 억제하는 가장 강력한 방법은 에이전트를 devcontainer/Docker 안에서 실행하는 거예요—필요한 디렉터리만 마운트하고, 불필요한 네트워크 접근을 끊고, 운영 자격 증명을 두지 마세요. 에이전트가 프롬프트 인젝션을 당해 나쁜 명령을 실행해도, 망가뜨릴 수 있는 건 그 박스뿐이고 여러분의 머신은 무사해요. 권한 설정을 더 깊이 알고 싶다면 Claude Code 권한을 안전하게 설정하는 가이드를 참고하세요.

아니면 네이티브 샌드박스를 쓰세요(Docker보다 가벼워요).Claude Code에는 /sandbox 명령이 있어요—빌드할 이미지도, 설정할 devcontainer도 없는 OS 수준의 격리예요. macOS에 내장된 Seatbelt, Linux/WSL2에서는 bubblewrap + socat. 컨테이너처럼 파일 시스템과 네트워크를 격리하지만, 더 빨리 시작하고 Docker 설치도 필요 없어요—전체 devcontainer를 세우지 않고 단일 작업(낯선 리포지토리 감사, 신뢰할 수 없는 코드 실행)을 빠르게 격리하고 싶을 때 딱 맞아요. 참고: 이건 권한 모드와는 다른 계층이에요—권한 모드는 에이전트가 행동하기 전에 무엇에 대해 묻는지를 통제하고, 샌드박스는 나쁜 명령을 실행하더라도 에이전트가 실제로 무엇을 할 수 있는지를 통제해요. 둘은 서로 보완하지 대체하지 않아요. 복잡한 설정을 가진 오래가는 개발 환경에는 여전히 컨테이너가 가장 강력한 선택이고, 네이티브 샌드박스는 빠르고 일시적인 격리에 맞아요. 전체 설정은 Claude Code 샌드박싱에서 보세요.

베스트 프랙티스 3 - 프롬프트 인젝션과 신뢰할 수 없는 콘텐츠 차단하기

프롬프트 인젝션은 가장 특징적이면서 가장 과소평가된 위험이에요. 메커니즘은 이래요. 에이전트는 여러분의 지시와 자신이 읽는 데이터를 깔끔하게 구분하지 못해요. 그 데이터에 명령문이 들어 있으면, 에이전트가 그걸 수행할 작업으로 취급할 수 있어요.

신뢰할 수 없는 콘텐츠의 흔한 출처:

• issue / PR / 댓글—GitHub에서 외부인이 작성한 것.
• 에이전트가 가져오는 웹 페이지—"이 URL의 문서를 읽어 줘"라고 요청할 때.
• MCP 서버의 출력 또는 서드파티 도구의 출력.
• 방금 클론했지만 아직 읽지 않은 리포지토리 안의 파일.

네 가지 완화 원칙, 거창한 이론은 필요 없어요.

1. 외부 입력을 다룰 때는 자동 승인 금지.에이전트가 issue/웹 페이지/MCP 출력을 읽기 시작하는 순간, 한 단계씩 확인하는 방식으로 돌아가세요—acceptEdits/bypass를 켜 둔 채로 두지 마세요.
2. 낯선 출처에는 plan 모드를 쓰세요.에이전트가 읽고 제안하게 하되, 여러분이 승인할 때까지 실행을 막으세요.
3. 격리하세요.베스트 프랙티스 2처럼, 신뢰할 수 없는 데이터는 시크릿이 없는 샌드박스에서 다루세요.
4. "정중한 명령"을 경계하세요.어떤 출력이 갑자기 명령 실행, 패키지 설치, 낯선 파일 읽기를 "제안"한다면—멈추고 자세히 읽으세요. 그건 전형적인 인젝션 신호예요.

Anthropic의 보안 문서에는 프롬프트 인젝션 방어를 다루는 전용 섹션이 있어요. 일반 원칙은 통제할 수 없는 데이터에 손댈 때는 에이전트를 가능한 한 가장 낮은 권한 모드로 유지하는 것이에요.

auto 모드에는 자체 인젝션 방어가 있어요.2026년 8월 기준으로, auto 모드는 Pro/Max/Team 플랜의 기본 시작 모드예요—덕분에 이제 이건 일부 예외적 상황이 아니라 대부분의 독자에게 직접 관련된 이야기가 됐어요. 메커니즘은 이래요. auto 모드에서 행동을 검토하는 분류기는 여러분의 메시지, 도구 호출, CLAUDE.md만 읽고—도구 결과는 절대 읽지 않아요. 별도의 서버 측 계층이 Claude가 읽기 전에 도구 결과에 적대적 콘텐츠가 있는지 스캔해요. 이건 부분적인 방어이지 절대적인 보장이 아니에요—auto 모드를 위의 네 가지 완화 원칙을 건너뛰어도 되는 이유로 여기지 마세요.

베스트 프랙티스 4 - AI가 생성한 코드는 항상 리뷰하기

타협 불가한 규칙: 사람의 개입 없이 AI 코드를 머지하지 마세요.코드 생성 속도가 빠르다 보니 "맹목적 머지"에 빠지기 쉬워요—그리고 가장 많은 취약점이 프로덕션에 도달하는 게 바로 거기예요.

미묘한 문제는 AI 슬롭(slop)이에요. 겉보기엔 매끈하고, 변수명도 좋고, 주석도 있고, 해피 패스에서는 잘 돌아가요—하지만 입력 검증을 빼먹거나, SQL 인젝션 구멍을 남기거나, 값을 하드코딩하거나, 보안 엣지 케이스를 잘못 처리하는 코드예요. "맞아 보여서" 급한 리뷰어의 눈을 스쳐 지나가요. 그걸 알아채고 피하는 방법은 코드 리뷰에서 AI 슬롭 피하기를 보세요.

security-guidance를 켜서 Claude가 코드를 쓰면서 스스로 자기 코드를 점검하게 하세요.이건 자동으로 돌아가는 네이티브 플러그인이라, 여러분이 호출을 기억할 필요가 없어요. 세 개의 계층이 스스로 발동해요—(1) Claude가 파일을 편집할 때마다 즉각적인 패턴 매칭(모델 호출 없음, 무료, eval(, os.system, dangerouslySetInnerHTML 같은 명확한 패턴을 잡아요). (2) 기본값으로 Opus 4.7에서 돌아가는 턴 종료 시점의 백그라운드 리뷰. (3) commit/push 시점의, 관련 호출자와 새니타이저까지 읽는 더 깊은 에이전트형 리뷰. /plugin install security-guidance@claude-plugins-official로 설치하고, .claude/claude-security-guidance.md와 .claude/security-patterns.yaml로 자신만의 규칙을 커스터마이즈하세요. 이건 쓰기나 커밋을 막지 않아요—찾아낸 지적을 Claude가 고치도록 드러낼 뿐이에요. 온디맨드 일회성 스캔인 /security-review(아래 2번)와 달리, security-guidance는 세션 내내 백그라운드에서 돌아가는 지속적인 계층이에요. 무료 멀티 에이전트 심층 스캔은 저희 보안 감사 글의 claude-security 플러그인을 보세요.

실전 리뷰 워크플로:

1. 설명이 아니라 diff를 읽으세요.에이전트가 "검증을 추가했다"고 말해도 제대로 했다는 뜻은 아니에요. diff에서 확인하세요.
2. /security-review 실행하기—Claude Code에 내장된 보안 리뷰 명령—손으로 리뷰하기 전에 흔한 취약점(인젝션, 하드코딩된 시크릿, 인증 누락)을 빠르게 스캔해요.
3. 민감한 영역을 우선하세요: 인증, 인가, 사용자 입력 처리, DB 쿼리, 셸 명령, 파일 작업.
4. 테스트와 linter/SAST를 실행하세요—다른 PR과 똑같이. AI라고 해서 CI가 면제되지 않아요.

더 엄격함이 필요한 프로젝트라면, 그때그때가 아니라 일정에 따라 돌아가는 완전한 Claude Code용 보안 감사 워크플로를 마련하세요.

베스트 프랙티스 5 - MCP 서버·플러그인을 검증하고 hook을 가드레일로 쓰기

활성화하는 모든 MCP 서버나 플러그인은 에이전트의 권한으로 실행되는 서드파티 코드예요. "편리하지만" 악의적인 서버는 여러분 모르게 파일을 읽고, 네트워크 통신을 하고, 데이터를 빼낼 수 있어요. 원칙은 이래요.

• 신뢰할 수 있는 서버만 활성화하기—읽을 수 있는 소스가 공개된 공식 출처를 우선하세요.
• 덜 알려진 서버는 설치 전에 소스를 읽기—특히 광범위한 네트워크나 파일 접근을 가진 것은요.
• MCP에도 최소 권한을Bash와 마찬가지로—실제로 필요한 범위만 부여하세요.

검증하기 전에 MCP가 어떻게 동작하는지 이해하려면 MCP가 무엇이고 어떻게 동작하는지를 읽으세요.

최후의 방어선으로서의 PreToolUse hook.이건 잘 활용되지 않지만 매우 강력한 계층이에요. 이 hook은 에이전트가 도구를 실행하기 전에 돌아가고, 아예 차단할 수 있어요. 예를 들어 위험한 명령 패턴을 차단하는 예시예요.

#!/usr/bin/env bash
# .claude/hooks/pre-tool-use-guard.sh
# Read the JSON payload from stdin, block dangerous commands
input=$(cat)
cmd=$(echo "$input" | jq -r '.tool_input.command // ""')

if echo "$cmd" | grep -Eq 'rm -rf|curl .*\| *(ba)?sh|:\(\)\{|dd if='; then
 echo "Blocked: dangerous command rejected by guardrail." >&2
 exit 2 # a non-zero exit code => Claude Code cancels the action
fi
exit 0

이 hook을 settings.json에서 PreToolUse 이벤트에 등록하세요. deny에만 의존하는 것에 비한 이점은, hook이 동적 로직(정규식, 변수 검사, 로깅)을 가능하게 하고, 실수로 느슨한 모드를 켜더라도 안전망이 된다는 거예요.

AI 코딩 보안 체크리스트 (지금 바로 복사해서 쓰기)

모든 베스트 프랙티스를 실행 가능한 목록으로 정리했어요. 출력하거나 프로젝트 README에 붙여 넣으세요.

1. [ ] 시크릿: .env를 .gitignore에 넣고, 시크릿 매니저를 쓰고, 리포지토리에 평문 키를 두지 않기.
2. [ ] 읽기 거부: permissions.deny가 .env, *.pem, *.key, 그리고 시크릿 디렉터리에 대한 Read()를 차단하기.
3. [ ] 스캔: gitleaks(또는 동등한 도구)가 pre-commit과 CI에서 돌기.
4. [ ] 로테이션: 키가 유출되면 폐기+재발급하는 런북이 존재하기.
5. [ ] 권한: settings.json이 최소 권한(allow/ask/deny)을 따르고, 샌드박스 밖에서는 bypassPermissions를 쓰지 않기.
6. [ ] 샌드박스: 위험한 작업은 운영 자격 증명이 없는 Docker/devcontainer에서 돌리기.
7. [ ] 프롬프트 인젝션: issue, 웹 페치, MCP 출력을 다룰 때는 plan/ask 모드로 전환하기.
8. [ ] 리뷰: 머지 전에 diff 읽기 + /security-review 실행 + CI/SAST, 절대 맹목적으로 머지하지 않기.
9. [ ] MCP/플러그인: 소스를 읽은 신뢰할 수 있는 서버만 활성화하고, 최소한의 범위를 부여하기.
10. [ ] hook: PreToolUse 가드레일이 파괴적인 명령을 차단하기.
11. [ ] 자동 리뷰: security-guidance 플러그인이 켜져 있어, Claude가 파일을 편집할 때마다 자동으로 리뷰하기.
12. [ ] 샌드박스: Docker보다 가벼운 격리가 필요한 작업에는 /sandbox를 켜기.

진짜 한계, 그리고 AI에게 맡기면 안 될 때

솔직히 말하면, 위의 모든 가드레일은 위험을 줄이는 것이지 없애는 게 아니에요. 분명히 짚어 둘 몇 가지 한계가 있어요.

AI는 사람의 위협 모델링을 대체하지 않아요.AI는 여러분의 비즈니스 맥락도, 데이터가 얼마나 민감한지도, 유출의 법적 파장도 이해하지 못해요. "이걸 자동화해도 안전한가"라는 판단은 여전히 여러분의 몫이에요.

에이전트가 운영 환경이나 진짜 시크릿을 건드리게 하지 마세요.에이전트를 프로덕션 데이터베이스에 연결하지 말고, 인프라 쓰기 권한이 있는 자격 증명을 주지 말고, 마음대로 배포하게 두지 마세요. 여기서의 실수는 되돌릴 수 없어요.

승인 피로는 실제 위험이에요.권한 확인이 너무 자주 뜨면, 사람들은 반사적으로 "허용"을 누르기 시작해요—애써 만든 방어 자체를 무력화하는 거죠. 해법은, 정말 안전한 작업에 대해 allow를 조정해서 확인이 정말 고민할 가치가 있는 것에만 뜨게 하는 거예요. 성가시다고 전부 꺼 버리는 게 아니라요.

요컨대, AI로 빠르게 움직이되 되돌릴 수 없는 결정은 사람의 손에 남겨 두세요. 가드레일은 여러분이 자신 있게 빠르게 움직일 수 있도록 존재하지, 생각을 멈추도록 있는 게 아니에요.

이미 만들어진 키트로 보안 표준화하기

프로젝트마다 PreToolUse hook, settings.json 템플릿, 리뷰 스킬을 전부 처음부터 짜는 건 번거로워요—특히 팀 전체를 같은 표준에 맞추고 싶을 때는요. 시간을 아껴 주는 하나는, Claude Code용 보안 리뷰 스킬과 가드레일 워크플로를 묶어 놓은 기성 키트예요. Claude Code용 AgentKit 키트는 일련의 리뷰/워크플로 스킬을 함께 담고 있어서, 처음부터 다시 만들 필요가 없어요. 자신에게 맞는지 확인하고 싶다면 AgentKit 가격 확인하기(링크로 20% 할인)를 볼 수 있어요(Engineer Kit는 $99, 사이트에는 반복 결제 안내가 없고, 평생 업데이트 포함). 그래도 자신의 프로젝트에 맞게 읽고 적용해야 해요—어떤 키트도 자신만의 위협 모델을 이해하는 걸 대신해 주지 않아요.

자주 묻는 질문 (FAQ)

AI 코딩을 실제 프로젝트에 써도 안전한가요?

네, 올바른 가드레일을 갖춘다면요. 시크릿을 손닿지 않는 곳에 두고, 최소 권한을 강제하고, 샌드박스에서 실행하고, 머지 전에 모든 코드를 리뷰하세요. 위험은 지나치게 넓은 권한과 신뢰할 수 없는 입력에서 오는 것이지, AI를 쓰는 것 자체에서 오지 않아요. 가드레일이 없으면 위험이 높지만, 있으면 통제 가능해요.

Claude Code는 제 코드를 어딘가로 보내나요?

Claude Code는 처리를 위해 필요한 컨텍스트를 Anthropic의 API로 보내요—그게 동작 방식이에요. 노출을 줄이려면, permissions.deny로 민감한 파일 읽기를 차단하고, Anthropic 문서에서 데이터 보존 정책을 확인하고, 극도로 민감한 코드는 전용 환경에 격리하세요.

에이전트를 통해 API 키가 새는 걸 어떻게 막나요?

세 개의 계층이에요. (1) 리포지토리에 평문 키를 두지 말고 시크릿 매니저를 쓰기. (2) permissions.deny로 .env와 키 파일에 대한 Read()를 차단하기. (3) gitleaks를 pre-commit과 CI에 넣어 시크릿이 담긴 커밋을 차단하기. 만약 새어 나갔다면 즉시 폐기하고 로테이션하세요—커밋을 지우는 것만으로는 부족해요.

bypassPermissions를 켜야 하나요?

진짜 작업용 머신에서는 거의 절대 안 돼요. bypassPermissions와 --dangerously-skip-permissions는 모든 승인 계층을 없애요—시크릿도 운영 접근도 없는 격리된 샌드박스에서만 쓰세요. 평소 작업에는 default를 유지하세요. 전부 꺼 버리는 대신 allow를 조정해 확인을 줄이세요.

AI 코드는 얼마나 리뷰해야 충분한가요?

에이전트의 설명을 믿는 대신 diff를 읽고, /security-review를 실행하고, 다른 PR처럼 CI/SAST와 테스트를 돌리고, 민감한 영역(인증, 입력, DB, 셸)을 꼼꼼히 살피세요. AI 슬롭을 조심하세요—맞아 보이지만 검증을 빼먹거나 보안 엣지 케이스를 잘못 처리하는 코드예요.

AI 코딩을 고객(NDA) 프로젝트에 써도 괜찮나요?

계약이 허용하고, 또한 엄격하게 격리하는 경우에만요. 고객마다 별도의 워크스페이스를 두고, 다른 고객의 코드가 있는 디렉터리 위에서 절대 에이전트를 열지 말고, 진짜 자격 증명을 범위에 두지 말고, 시작하기 전에 제3자 서비스로의 데이터 전송에 관한 NDA 조항을 확인하세요.

auto 모드는 혼자서 프롬프트 인젝션을 막아 주나요?

부분적으로요. auto 모드에서 행동을 검토하는 분류기는 여러분의 메시지, 도구 호출, CLAUDE.md만 읽고—도구 결과는 절대 읽지 않아요. 별도의 서버 측 계층이 Claude가 읽기 전에 도구 결과에 적대적 콘텐츠가 있는지 스캔해요. 이건 부분적인 방어이지 절대적인 보장이 아니에요—신뢰할 수 없는 콘텐츠를 다룰 때는 여전히 네 가지 완화 원칙(낯선 입력에 자동 승인 금지, plan 모드 사용, 격리, "정중한 명령" 경계)을 적용해야 해요.

결론과 다음 단계

AI 코딩 보안은 켜고 끄는 기능이 아니에요—그것은 여섯 개의 가드레일 계층이에요. 시크릿, 권한, 샌드박스, 프롬프트 인젝션 차단, 코드 리뷰, 그리고 MCP + hook 검증. ROI가 가장 높은 두 계층—시크릿용 permissions.deny와 최소 권한 settings.json—부터 시작하고, 나머지는 시간을 두고 더하세요. 위의 체크리스트를 프로젝트 README에 붙여 넣어 팀 전체가 하나의 표준을 따르게 하세요.

다음으로 읽어 보세요: 권한을 안전하게 설정하기와 완전한 보안 감사. 팀 전체를 위한 기성 보안 스킬 세트를 원한다면, AgentKit을 사용해 보기(링크로 20% 할인)도 할 수 있어요—단, 항상 자신만의 위협 모델에 맞게 읽고 적용하세요.