Salt Code 40개 정책 공개, MCP로 코딩 어시스턴트를 통제

AI 요약

• 무슨 일: Salt Security가 Salt Code를 공개하며 AI 코딩 어시스턴트 안에서 보안 정책을 적용하겠다고 발표했습니다.
  • 공식 페이지 기준 4개 보안 코딩 팩, 40개 이상 정책, 10개 이상 어시스턴트, 첫 100개 조직 무료 EAP가 제시됐습니다.
• 방식: Salt Code는 MCP 서버로 Cursor, Copilot, Claude, Codex, Gemini CLI 같은 도구에 연결됩니다.
• 의미: AI 코드 보안 검사가 PR 뒤쪽에만 있던 구조에서 프롬프트, MCP 설정, 런타임 검증까지 앞당겨집니다.
  • 검증할 지점은 벤더가 말한 policy-compliant code by default가 실제 팀의 예외 처리, 리뷰, CI 실패율을 얼마나 줄이는지입니다.

Salt Security가 2026년 6월 1일 Salt Code를 공개했습니다. 발표 문구만 보면 또 하나의 AI 보안 제품처럼 보이지만, 위치가 다릅니다. Salt Code는 AI 코딩 어시스턴트가 코드를 만든 뒤 PR에서 검사하는 도구가 아니라, Cursor, GitHub Copilot, Claude, Codex, Gemini CLI 같은 개발자 도구에 MCP 서버로 연결돼 코드 생성 순간부터 정책을 적용한다고 설명합니다.

Salt의 보도자료는 Salt Code를 Agentic Security Platform의 새 컴포넌트로 소개합니다. 적용 범위는 세 가지입니다. 첫째, 생성되는 코드입니다. 둘째, MCP 서버와 에이전트 도구 등록 같은 control plane configuration입니다. 셋째, API, MCP integration, agent가 실제 production에서 보이는 runtime behavior입니다. 이 세 축을 같은 정책 모델로 묶겠다는 것이 이번 발표의 제품상 차별점입니다.

제품 페이지의 숫자는 명확합니다. 무료 시작 계정은 네 개의 ready-to-use secure coding pack을 포함합니다. 팩 이름은 OWASP API Top 10, MCP Security Top 10, LLM Security Top 10, OpenAPI/Swagger Compliance입니다. Salt는 이 네 팩에 40개 이상 정책이 들어 있으며, Cursor, Copilot, Claude와 모든 MCP 지원 어시스턴트에서 쓸 수 있다고 말합니다. 비고객도 첫 100개 조직까지 Early Access Program으로 신청할 수 있습니다.

Salt가 선택한 연결 방식은 MCP입니다. 공식 설명에 따르면 개발자는 Salt Code를 Cursor, GitHub Copilot, Claude 또는 다른 AI coding assistant에 MCP server로 추가합니다. 그다음 네 개 팩 중 필요한 팩을 켜고, 기존처럼 프롬프트를 작성합니다. Salt가 약속하는 결과는 "output arrives policy-compliant"입니다. 이 문장은 벤더 주장으로 읽어야 하지만, 보안 통제의 삽입 위치는 분명합니다. 정책이 PR 리뷰 코멘트나 CI 실패 메시지로 뒤늦게 등장하는 대신, 모델이 코드를 내놓는 순간의 context로 들어갑니다.

이 위치 이동은 AI 코딩 도구가 단순 autocomplete에서 agentic workflow로 바뀐 뒤 더 중요해졌습니다. Copilot, Claude Code, Codex, Cursor, Windsurf, Gemini CLI는 파일을 읽고, 테스트를 실행하고, 명령을 제안하고, 때로는 PR까지 만듭니다. 사람 리뷰가 늦어질수록 보안팀은 "누가 어떤 어시스턴트로 어떤 코드를 만들었는가"보다 "그 어시스턴트가 어떤 권한과 정책을 보고 있었는가"를 먼저 물어야 합니다. Salt Code는 이 질문에 MCP 설정과 정책 팩으로 답하려 합니다.

Salt가 보도자료에서 인용한 보안 배경도 이 지점을 받칩니다. 보도자료는 Georgia Tech의 Vibe Security Radar를 언급하며 2026년 3월에 AI coding tool에서 비롯된 CVE가 35개 공개됐다고 설명합니다. Infosecurity Magazine도 2026년 3월 26일 같은 추적 프로젝트를 보도했습니다. 기사에 따르면 월별 수치는 1월 6개, 2월 15개, 3월 35개였습니다. Vibe Security Radar 공개 페이지는 2026년 6월 1일 확인 기준 78개 AI-linked CVE, 8개 AI tools, 43개 critical/high, 46,831개 advisory scan을 표시합니다.

이 숫자를 Salt Code의 영업 주장과 분리해 읽을 필요가 있습니다. Vibe Security Radar는 "AI가 만든 코드가 모두 위험하다"는 결론을 내리기보다, AI 생성 코드가 남기는 metadata, commit signature, issue thread, tool trace를 통해 취약점 원인을 추적하려는 프로젝트입니다. 추적 가능한 사례가 늘어난다는 것은 실제 결함이 늘어난 결과일 수도 있고, AI 도구 사용량이 커지면서 흔적이 더 잘 발견되는 결과일 수도 있습니다. 그러나 보안팀 입장에서는 두 경우 모두 같은 실무 문제로 이어집니다. 생성 속도가 올라갈수록 정책 확인 지점은 사람 리뷰 하나로 버티기 어렵습니다.

Salt Code가 제시한 네 개 팩은 그래서 도구별 기능보다 정책 범주를 보여줍니다. OWASP API Top 10 팩은 broken authorization, unrestricted resource consumption, SSRF 같은 API 보안 위험을 생성 코드에 적용합니다. MCP Security Top 10 팩은 MCP server authentication, tool description validation, least-privilege scope 같은 에이전트 연결 지점을 다룹니다. LLM Security Top 10 팩은 prompt injection, sensitive information disclosure, excessive agency를 겨냥합니다. OpenAPI/Swagger Compliance 팩은 인증 스키마, response code, schema 문서화를 생성 단계에서 요구합니다.

제품 아키텍처에서 MCP는 단순한 플러그인 규격이 아닙니다. Salt 보도자료는 MCP를 "AI assistants connect to external context and tools"하는 open protocol로 설명합니다. 이 정의는 개발자가 매일 보는 문제와 맞닿아 있습니다. 에이전트가 repository, ticket, database schema, internal API, secret scanner, CI log를 읽을수록 보안 검토 대상은 생성된 .ts 파일 하나가 아니라 연결 목록 전체가 됩니다. Salt Code가 MCP Security Top 10을 별도 팩으로 둔 이유도 여기에 있습니다.

기존 보안 도구와의 관계는 보완에 가깝습니다. GitHub Advanced Security의 secret scanning, Snyk나 Semgrep의 SAST, Checkmarx의 code scanning, CI policy gate는 여전히 필요합니다. Salt Code가 바꾸려는 부분은 "어디에서 처음 실패하게 할 것인가"입니다. 개발자가 AI에게 API endpoint를 만들라고 지시했을 때 인증 스키마 누락, response code 누락, overly broad tool scope가 그 자리에서 수정된다면 PR 리뷰의 부담은 줄어듭니다. 반대로 Salt Code가 같은 문제를 나중에 ticket으로만 보내면 기존 보안 backlog와 다르지 않습니다.

Salt는 runtime까지 같은 정책을 가져간다고 말합니다. 보도자료에는 GitHub, GitLab, Bitbucket, VS Code, MCP 설정을 지원하는 IDE, 주요 CI/CD 플랫폼, Jira, ServiceNow 통합이 언급됩니다. 제품이 실제로 강해지는 구간은 이 통합들이 서로 다른 alert를 한 화면에 모으는 데서 끝나지 않을 때입니다. 예를 들어 runtime에서 특정 API가 policy violation을 보였고, 같은 정책이 다음 코드 생성 프롬프트에 반영돼 수정 후보를 제한한다면 "runtime-to-code remediation"이라는 표현에 실질이 생깁니다.

개발자 팀이 먼저 확인할 질문은 세 가지입니다. 첫째, Salt Code가 MCP server로 연결될 때 어떤 repository, branch, prompt, tool call metadata를 읽는가입니다. 둘째, 정책 위반을 blocking으로 처리하는지, warning으로 처리하는지, 또는 모델에게 재생성을 요청하는지입니다. 셋째, 한 팀 안에서 Cursor, Codex, Claude Code, Copilot을 섞어 쓸 때 같은 정책 결과가 나오는지입니다. AI 코딩 어시스턴트 보안은 모델 품질보다 권한, 로그, 예외 승인, 감사 trail에서 차이가 크게 납니다.

커뮤니티 반응은 아직 Salt Code 직접 사용 후기로 축적되지 않았습니다. 2026년 6월 1일 확인한 Hacker News front page에는 Salt Code 자체 토론은 보이지 않았습니다. 다만 PromptArmor의 "ChatGPT for Google Sheets exfiltrates workbooks" 항목이 252 points와 97 comments로 올라와 있었고, AI 도구가 업무 데이터와 연결될 때 생기는 유출 경로가 개발자 커뮤니티의 관심을 받고 있었습니다. GeekNews 최신 목록에서는 2026년 5월 31일 "Claw Patrol - 에이전트를 위한 보안 방화벽"이 올라와 에이전트 자격 증명과 traffic parsing을 다뤘습니다.

이 두 반응은 Salt Code를 해석하는 데 쓸 만한 기준을 줍니다. PromptArmor 사례는 프롬프트 인젝션이 UI와 데이터 접근을 함께 건드릴 수 있음을 보여줬고, Claw Patrol류 제품은 agent credential과 wire-level traffic을 runtime에서 통제하려 합니다. Salt Code는 그보다 앞선 코드 생성 단계와 MCP 설정 단계에 자리를 잡습니다. 같은 "agent security"라도 통제 위치가 다르면 구매자와 운영 책임자가 달라집니다. 개발 플랫폼 팀은 MCP 설정과 IDE 배포를 보고, AppSec 팀은 정책 팩과 CI 결과를 보고, SRE나 보안 운영팀은 runtime alert를 봅니다.

Salt Code가 실무에서 통과해야 할 검증 기준은 명확합니다. 첫째, false positive가 낮아야 합니다. AI coding assistant 안에서 정책이 지나치게 자주 막히면 개발자는 MCP server를 끄거나 더 느슨한 도구로 이동합니다. 둘째, custom policy 작성 비용이 낮아야 합니다. Salt가 기본 제공하는 40개 이상 정책은 시작점일 뿐이고, 실제 기업은 내부 auth middleware, company-specific logging rule, API versioning convention, PII masking rule을 넣어야 합니다. 셋째, policy result가 PR, ticket, runtime log에서 같은 ID와 설명으로 추적돼야 합니다.

제목에 넣은 "40개 정책"은 제품의 전체 가치를 보장하는 숫자가 아닙니다. 이 숫자의 의미는 보안팀이 AI 코딩 도구를 막는 대신 policy pack이라는 배포 단위로 다루기 시작했다는 데 있습니다. 지금까지 AI 코딩 가이드라인은 "민감정보를 넣지 말라", "출력을 검토하라", "프로덕션 반영 전 테스트하라" 같은 문서 문장에 머무는 경우가 많았습니다. Salt Code는 그 문장을 MCP server와 policy engine으로 바꾸겠다고 말합니다.

구매자에게 남는 질문은 가격보다 운영 경계입니다. Salt는 비고객에게 무료 Early Access를 제공하고, 기존 Salt 고객에게는 라이선스에 포함된다고 설명합니다. 그러나 보안팀이 실제로 봐야 할 비용은 라이선스보다 예외 승인, 정책 작성, 어시스턴트별 설정 배포, 개발자 교육, 로그 보관입니다. AI 코딩 어시스턴트가 여러 개일수록 중앙 정책의 이점은 커지지만, 그만큼 각 도구의 MCP 구현 차이와 권한 모델 차이도 드러납니다.

Salt Code 출시는 AI 코딩 보안 시장이 "AI가 만든 코드도 검사한다"에서 "AI가 코드를 만들 때 어떤 정책을 보게 할 것인가"로 이동하고 있음을 보여주는 사례입니다. Vibe Security Radar의 CVE 추적, PromptArmor의 데이터 유출 사례, GeekNews의 에이전트 방화벽 관심은 모두 같은 압력을 가리킵니다. 개발팀은 더 빠른 생성 속도를 이미 받아들였고, 보안팀은 그 속도에 맞는 통제 지점을 다시 배치해야 합니다. Salt Code의 첫 번째 검증대는 데모가 아니라, 실제 repository에서 PR 수정 횟수와 runtime 위반을 얼마나 줄이는지입니다.