Salt Code 공개, MCP로 AI 코드 정책을 주입하는 보안 경쟁

AI 요약

• 무슨 일: Salt Security가 Salt Code를 공개하며 AI 코딩 도구 안에서 보안 정책을 집행하는 MCP 기반 제품을 내놨습니다.
  • 공식 페이지는 Cursor, GitHub Copilot, Claude Code, Codex, Gemini CLI, Antigravity 등 MCP 지원 도구를 대상으로 나열합니다.
• 숫자: 초기 접근은 선착순 100개 조직, 네 가지 secure coding pack, 40개 이상 정책으로 시작합니다.
• 의미: AI 코드 보안의 집행 위치가 PR 리뷰와 SAST 뒤쪽에서 prompt, MCP server, code generation 시점으로 앞당겨집니다.
• 주의점: MCP로 정책을 넣는 방식은 assistant마다 같은 기준을 줄 수 있지만, 정책 서버 자체의 권한과 로그 검증도 새 운영 과제가 됩니다.

Salt Security가 2026년 6월 1일 Salt Code를 공개했습니다. 발표의 초점은 AI가 코드를 만든 뒤 PR 리뷰, SAST, DAST에서 취약점을 찾는 방식이 아닙니다. Salt는 Cursor, GitHub Copilot, Claude Code, Codex, Gemini CLI 같은 AI 코딩 도구가 코드를 생성하는 순간, 조직의 API 보안·MCP 보안·LLM 보안·OpenAPI 정책을 assistant workflow 안에 넣겠다고 설명합니다.

공식 Salt Code 페이지는 제품을 "AI coding assistant 안에서 보안 정책을 집행하는 솔루션"으로 소개합니다. 같은 페이지는 Salt Posture Governance Engine을 개발자가 이미 쓰는 도구에 연결하고, prompt부터 production까지 정책을 운반한다고 설명합니다. 제품 화면에는 Cursor가 agent registration API를 생성하는 예시와 함께 HTTPS 인증, UUID 사용자 ID, JWT bearer auth, PII 암호화, rate limiting, shadow API 금지 같은 항목이 Salt Compliance Verified로 표시됩니다.

무료 초기 접근 페이지의 숫자는 제품 포지셔닝을 더 선명하게 만듭니다. Salt는 선착순 100개 조직에 early access를 열고, 네 가지 secure coding pack과 40개 이상 정책을 제공한다고 밝혔습니다. 네 가지 팩은 OWASP API Top 10, Salt가 정의한 MCP Security Top 10, OWASP Top 10 for LLM Applications 기반 LLM Security Top 10, OpenAPI/Swagger compliance입니다. 페이지는 10개 이상 AI coding assistant 지원과 신용카드 없는 시작도 함께 적었습니다.

이 뉴스가 AI 개발팀에 걸리는 이유는 모델 성능보다 검토 위치가 바뀌기 때문입니다. 지금까지 많은 팀은 "AI가 만든 코드를 사람이 리뷰한다"는 문장으로 통제를 설명했습니다. Salt Code의 주장은 사람이 보는 diff가 나오기 전에 assistant가 참조하는 정책 context와 MCP tool call에 보안 기준을 넣겠다는 쪽입니다. PR 리뷰어가 취약한 API endpoint를 찾아 되돌리는 대신, assistant가 endpoint를 만들 때 인증 schema와 rate limit 조건을 같이 받는 구조입니다.

Salt가 공식 페이지에서 제시한 작동 단계는 세 구간으로 압축됩니다. 첫째, Salt Code를 MCP server로 Cursor, GitHub Copilot, Claude 같은 assistant에 연결합니다. 둘째, OWASP API, MCP Security, LLM Security, OpenAPI 같은 정책 팩을 켭니다. 셋째, 개발자는 같은 방식으로 prompt를 입력하고 assistant는 정책을 반영한 코드를 생성합니다. Salt는 별도 개발자 워크플로 변경 없이 "one configuration, every assistant"라고 설명하지만, 실제 운영에서는 조직별 MCP 설정 배포와 권한 관리가 핵심 변수가 됩니다.

AI 코딩 도구가 만든 코드의 양은 이미 보안팀이 무시하기 어려운 수준으로 커졌습니다. Sonar는 2026 State of Code Developer Survey에서 1,100명 이상 전문 개발자를 조사했고, 응답자 기준 AI 생성 또는 보조 코드가 현재 커밋 코드의 42%라고 발표했습니다. 같은 조사에서 개발자는 2027년 그 비율이 65%까지 늘 것으로 예상했습니다. 더 불편한 숫자는 신뢰와 검증의 간격입니다. 개발자의 96%는 AI 생성 코드의 기능적 정확성을 완전히 신뢰하지 않는다고 답했지만, 항상 확인한다고 답한 비율은 48%였습니다.

이 간격은 Salt가 팔려는 문제를 설명합니다. 리뷰어가 AI diff를 모두 꼼꼼히 보지 못하는 상황에서, assistant가 생성하는 API와 agent tool이 조직의 보안 정책을 모른다면 결함은 PR 대기열로 밀려납니다. Sonar 숫자를 그대로 받아들이면, 보안 리뷰는 사람이 작성한 코드만 상대하는 시대를 이미 지나고 있습니다. 정책이 prompt와 code generation 주변에 들어가야 한다는 Salt의 논리는 이 검증 간격에서 출발합니다.

Veracode의 2025 GenAI Code Security Report도 같은 방향의 압력을 만듭니다. Veracode는 100개 이상 대형 언어 모델과 80개 코딩 과제를 테스트했고, 생성 코드 샘플의 45%가 OWASP Top 10 취약점을 포함했다고 발표했습니다. 이 수치는 특정 모델 하나의 실패가 아니라, 더 크고 최신인 모델이 항상 안전한 코드를 만든다는 가정이 약하다는 근거로 쓰입니다. Salt Code가 OWASP API Top 10과 LLM Security Top 10 팩을 전면에 둔 이유도 여기에 있습니다.

Georgia Tech SSLab의 Vibe Security Radar는 synthetic benchmark가 아니라 공개 취약점 공지를 추적합니다. 이 프로젝트의 about 페이지는 2025년 5월 1일부터 2026년 3월 24일까지 46,831개 advisory를 분석해 AI-linked vulnerabilities 78건을 추적한다고 설명합니다. 방법론은 OSV, GitHub Advisory Database, Gemnasium, NVD에서 수정 commit을 찾고, SZZ식 blame으로 취약 코드를 도입한 commit을 추적한 뒤, 54개 이상 AI coding tool signature를 확인합니다.

Vibe Security Radar의 수치는 상대 위험률이 아닙니다. 연구팀도 공개 repository와 이미 공지·수정된 취약점만 범위에 넣고, false positive보다 누락을 감수하는 conservative pipeline이라고 설명합니다. 그래도 이 데이터는 AI 생성 코드 보안을 "느낌상 위험하다"는 말에서 "공개 advisory에 AI 도구 흔적이 남는 사건이 발생한다"는 후행 지표로 옮깁니다. Salt Code 같은 제품은 이 후행 지표를 앞단의 정책 집행 시장으로 바꾸려 합니다.

Salt가 선택한 연결 방식은 MCP입니다. 공식 페이지는 "MCP를 지원하면 Salt Code가 govern한다"고 씁니다. 지원 대상으로 Claude Code, Cursor, GitHub Copilot, Windsurf, Kiro, Codex, Gemini CLI, Antigravity, VS Code, OpenCode, JetBrains, Any MCP client를 나열합니다. MCP가 assistant와 외부 도구를 잇는 표준 접점으로 쓰이기 시작하자, 보안 도구도 그 접점으로 들어가고 있습니다.

MCP 기반 집행의 장점은 assistant마다 별도 플러그인을 다시 만들지 않아도 된다는 점입니다. 한 조직이 Cursor와 Claude Code, Codex를 동시에 쓰는 경우, 보안팀은 각 assistant의 prompt convention과 extension API를 따로 따라가야 합니다. Salt Code가 말하는 "one configuration, every assistant"가 실제로 작동한다면, 정책 팩은 assistant 교체와 무관하게 남습니다. 개발팀 입장에서는 IDE나 CLI 선택권을 유지하면서 공통 보안 기준을 붙일 수 있습니다.

반대로 MCP는 새 신뢰 경계도 만듭니다. 정책 server는 assistant가 어떤 context를 보고 어떤 tool call을 하는지 관찰하거나 영향을 줄 수 있습니다. 보안팀은 Salt Code 같은 MCP server에 어떤 repository metadata, prompt fragment, API schema, runtime finding이 전달되는지 확인해야 합니다. 정책 집행 도구가 또 하나의 민감한 개발 telemetry 수집 지점이 되기 때문입니다.

Salt Code의 정책 팩 구성을 보면 대상이 일반 코드 품질보다 agentic application에 맞춰져 있습니다. OWASP API Top 10 팩은 broken object level authorization, unrestricted resource consumption, server-side request forgery 같은 API 위험을 생성 시점에 잡겠다고 설명합니다. MCP Security 팩은 MCP server authentication, tool description validation against prompt injection, registered agent tool의 least privilege scope를 예시로 듭니다. LLM Security 팩은 prompt injection, sensitive information disclosure, excessive agency를 다룹니다.

OpenAPI/Swagger compliance 팩은 보안팀보다 platform team에 더 직접적인 이익을 줄 수 있습니다. AI assistant가 작은 endpoint를 빠르게 만들 때 문서화되지 않은 path, 빠진 response code, 애매한 auth scheme이 누적되면 API inventory가 깨집니다. Salt 페이지는 모든 AI-generated API가 documented authentication scheme, response code, schema definition을 갖도록 하겠다고 설명합니다. 이 부분은 "취약점 차단"보다 "AI가 만든 API sprawl을 inventory에 남기는 일"에 가깝습니다.

커뮤니티 반응은 아직 Salt Code 자체로 크게 모이지 않았습니다. Hacker News와 GeekNews에서 이번 제품명으로 큰 토론은 확인하지 못했습니다. 대신 2026년 4월 Hacker News에는 "The S in MCP Stands for Security" 토론이 있었습니다. Reddit의 r/mcp와 r/programming에는 AI coding assistant가 package install이나 code generation을 할 때 MCP server로 보안 검사와 malware check를 붙이려는 도구들이 공유됐습니다. 대화의 공통분모는 AI agent가 단순 text generator가 아니라 실제 파일과 shell, dependency, remote API에 닿는다는 점입니다.

Salt Code가 마주할 경쟁군은 세 갈래입니다. 첫째, SafeDep MCP Server처럼 AI agent가 패키지를 설치하기 전에 threat intelligence를 붙이는 작은 MCP 도구들입니다. 둘째, Sonar, Veracode, Snyk, Semgrep, GitHub Advanced Security처럼 사후 분석과 개발자 피드백 loop를 이미 가진 code security 도구입니다. 셋째, Noma, Zenity, Onyx, Traceable, Akto처럼 agentic security와 API posture를 전면에 내세우는 플랫폼입니다. Salt는 API 보안 출신이라는 점을 MCP와 agent integration inventory로 연결하려 합니다.

개발팀이 제품을 평가할 때 첫 질문은 "정책이 실제로 assistant 출력을 바꾸는가"입니다. 예시 화면의 compliance check는 이해하기 쉽지만, 실전 repository에는 legacy auth, 내부 gateway, 예외 path, 테스트용 mock endpoint가 섞입니다. 정책 server가 이런 context를 정확히 읽지 못하면 assistant는 과도하게 보수적인 코드를 만들거나, 반대로 compliance badge만 달고 중요한 예외를 놓칠 수 있습니다. evaluation은 demo prompt가 아니라 실제 사내 API 변경 PR로 해야 합니다.

두 번째 질문은 "정책 위반이 어디에서 차단되는가"입니다. Salt 페이지는 generation time enforcement, PR/CI validation, runtime validation을 모두 언급합니다. 세 지점은 실패 비용이 다릅니다. generation 단계에서 막으면 개발자 경험이 좋아질 수 있지만 false positive가 많으면 prompt loop가 길어집니다. PR 단계에서 막으면 reviewer와 CI가 이해하기 쉬우나 이미 생성된 코드를 되돌려야 합니다. runtime 단계에서 찾으면 실제 traffic 기반 근거가 생기지만 사고 비용은 커집니다.

세 번째 질문은 "MCP server 권한을 어떻게 제한하는가"입니다. 보안 정책을 주입하려면 repository 구조, API spec, assistant context, tool call, CI 결과 일부가 필요합니다. 그러나 모든 prompt와 source를 외부 SaaS로 보내는 설정은 규제 산업과 폐쇄망 개발팀에서 막힐 수 있습니다. 조직은 Salt Code가 self-hosted인지, data retention이 어떻게 되는지, custom policy가 어떤 언어로 표현되는지, audit log가 SIEM으로 나가는지 확인해야 합니다.

네 번째 질문은 "assistant가 정책을 우회할 수 있는가"입니다. MCP tool description 자체가 prompt injection 대상이 될 수 있고, repository 안의 README나 issue text가 assistant에게 보안 정책을 무시하라고 지시할 수 있습니다. Salt의 MCP Security 팩은 tool description validation against prompt injection을 예시로 들지만, 실제 방어는 assistant, MCP client, policy server, CI gate가 서로 다른 신뢰 수준을 가져야 가능합니다. prompt 안의 지시와 정책 server의 결정이 충돌할 때 어느 쪽이 우선인지도 문서화되어야 합니다.

다섯 번째 질문은 "보안팀의 정책 언어가 개발자에게 설명 가능한가"입니다. PR에서 JWT bearer auth required on external APIs 같은 위반이 나왔을 때, 개발자는 어느 endpoint, 어느 schema, 어느 commit에서 수정해야 하는지 알아야 합니다. AI assistant에게 정책만 넣고 사람이 읽을 수 있는 remediation을 주지 않으면, 개발자는 같은 prompt를 여러 번 바꾸며 시간을 씁니다. Salt 페이지가 runtime finding을 actionable fixes로 바꿔 developer workflow에 되돌린다고 설명한 부분은 이 병목을 겨냥합니다.

이 제품이 성공하려면 "보안팀이 만든 PDF를 AI가 읽는다"보다 더 엄격한 모델이 필요합니다. 정책은 versioned artifact가 되어야 하고, assistant별 호출 로그와 CI 결과에 같은 policy ID가 남아야 합니다. 어떤 정책이 어떤 코드 생성을 바꿨는지, false positive가 몇 건인지, 예외 승인이 누가 언제 했는지 확인되어야 합니다. 그렇지 않으면 Salt Code는 개발자에게 보이지 않는 prompt advice layer에 머물 수 있습니다.

Salt Code의 출시는 AI 코딩 보안 시장이 prompt 교육에서 운영 통제로 이동한다는 사건입니다. 개발자에게 "AI 코드를 잘 리뷰하라"고 말하는 방식만으로는 42% AI-assisted commit 시대를 감당하기 어렵습니다. 사후 리뷰는 계속 필요하지만, API auth, MCP scope, LLM input handling, OpenAPI schema 같은 반복 정책은 assistant가 코드를 쓰는 순간부터 적용되어야 합니다.

이 변화는 보안팀에도 부담을 줍니다. 정책이 앞단으로 이동하면, 보안팀은 더 이상 분기 말 audit 문서만 관리할 수 없습니다. Cursor, Codex, Claude Code, Copilot이 실제로 호출하는 MCP server 목록, 정책 팩 버전, assistant별 예외, CI gate 결과, runtime feedback loop를 운영해야 합니다. AI 코딩 도구의 생산성은 개발팀이 가져가지만, 그 생산성이 만든 코드 표면은 보안팀의 실시간 운영 영역으로 들어옵니다.

지금 Salt Code를 바로 도입하지 않더라도 개발팀이 확인할 항목은 분명합니다. AI assistant가 생성한 API endpoint에 auth scheme이 빠지는지, MCP server 등록에 least privilege scope가 있는지, prompt injection 방어가 user-facing input에 들어가는지 점검해야 합니다. OpenAPI 문서가 실제 route와 맞는지, PR과 runtime에서 같은 policy ID로 추적되는지도 확인 대상입니다. Salt Code는 그 점검을 제품화한 사례이고, MCP는 그 제품이 assistant 안으로 들어가는 통로입니다.

2026년 6월의 AI 코딩 보안 경쟁은 "어떤 모델이 코드를 더 잘 쓰는가"만 묻지 않습니다. 이제 질문은 "누가 assistant가 코드를 쓰는 순간 조직의 보안 기준을 강제하는가"로 바뀝니다. Salt Code의 early access는 작은 출시처럼 보이지만, Cursor와 Codex와 Claude Code를 동시에 쓰는 팀에게는 보안 정책의 배포 위치를 다시 정하게 만드는 사건입니다.