가드레일이 없다는 것: Kimi K3와 ‘거부 권한’을 누가 갖는가

보안 담당자가 침투 테스트 스크립트를 검토받으려고 챗봇에 코드를 붙여 넣었더니 “이 요청은 도울 수 없습니다”라는 답만 돌아온 경험, 한 번쯤 있으실 겁니다. 취약점을 찾아 고치려는 정당한 방어 작업인데도 모델이 “사이버 보안” 키워드에 반응해 문을 닫아 버리는 일입니다. 2026년 7월, 오픈웨이트 진영의 새 모델 Kimi K3가 공개되면서 바로 이 지점이 다시 뜨거운 논쟁거리가 되었습니다. 한 투자자는 K3가 폐쇄형 코딩 도구들이 “사이버 가드레일” 때문에 거부한 보안 버그 여러 건을 대신 고쳐 주었다고 주장했습니다. 이 주장 자체는 검증되지 않았지만, 그 밑에 깔린 질문은 진짜입니다. 모델이 무엇을 거부할지, 그 권한을 누가 가져야 하는가.

이 글은 Kimi K3라는 구체적 사례를 통해 그 질문을 풀어 갑니다. 먼저 과잉 거부(over-refusal)라는 현상을 짚고, K3가 어떤 설계로 이 논쟁의 한복판에 섰는지 확인된 사실로 정리한 다음, 오픈웨이트가 실제로 무엇을 운영자에게 넘겨주는지, 그리고 ThakiCloud처럼 여러 고객 환경에 모델을 서빙하는 회사가 그 부담을 어떻게 다뤄야 하는지로 이어집니다. 결론을 미리 말씀드리면, 가드레일이 없는 모델은 문제를 없애 주는 것이 아니라 문제를 당신에게 넘깁니다.

과잉 거부란 무엇인가

과잉 거부는 모델이 위험한 요청을 막으려다가 정당한 요청까지 함께 차단하는 현상입니다. 안전 필터는 본질적으로 정밀하지 않습니다. “이 시스템의 취약점을 악용하는 코드를 짜 줘”라는 공격 의도와 “우리 시스템의 이 취약점을 재현해 패치를 검증하고 싶다”는 방어 의도는 표면 어휘가 거의 같습니다. 필터가 의도를 구분하지 못하면, 안전한 쪽으로 기울여 둘 다 거부하게 됩니다.

문제는 이 거부가 실무에서 상당한 비용을 만든다는 데 있습니다. 보안팀의 취약점 분석, 병원의 임상 의사결정 지원, 로펌의 판례 검토처럼 민감한 어휘를 필연적으로 포함하는 정당한 업무일수록 필터에 자주 걸립니다. 게다가 폐쇄형 SaaS 모델의 거부 로직은 대개 불투명합니다. 왜 거부됐는지, 어떤 규칙에 걸렸는지, 어떻게 하면 통과되는지가 문서화되지 않은 채 벤더의 서버 안에 숨어 있습니다. 운영자는 통제할 수 없는 블랙박스에 자신의 워크플로를 맡기게 됩니다.

여기에 한 가지 층이 더 있습니다. 일부 폐쇄형 서비스는 민감한 주제를 감지하면 조용히 더 작거나 제약된 모델로 쿼리를 우회시킵니다. 사용자는 같은 이름의 모델을 부른다고 생각하지만, 실제로는 다운그레이드된 응답을 받는 것입니다. 성능의 일관성이 깨지는 셈인데, 이 사실이 겉으로 드러나지 않아 재현성과 신뢰성을 함께 갉아먹습니다.

Kimi K3가 만든 논쟁

Kimi K3는 Moonshot AI가 2026년 7월 16일 공개한 대규모 Mixture-of-Experts 모델입니다. 전체 2.8조 파라미터로 오픈웨이트로 공개되는 모델 가운데 처음으로 3조 파라미터 급에 들어섰고, 100만 토큰 컨텍스트와 네이티브 멀티모달을 지원합니다. 완전한 가중치는 7월 27일 공개될 예정이며, 도입 검증에 필요한 아키텍처와 벤치마크 신뢰성 문제는 별도 글에서 자세히 다뤘습니다.

이 글의 초점은 다른 곳에 있습니다. 여러 매체가 공통으로 짚은 K3의 특징은, 콘텐츠 필터링이나 쿼리 우회가 없다는 점입니다. 표현 그대로 “당신이 호출한 모델이 곧 당신이 받는 모델”입니다. 민감한 주제를 감지했다고 성능을 낮추거나 다른 모델로 넘기지 않습니다. 연구자 입장에서는 의료, 법률, 보안에 인접한 작업에서도 성능이 일관되게 유지된다는 뜻입니다.

논쟁에 불을 붙인 것은 K3가 폐쇄형 도구들이 거부한 보안 버그를 대신 고쳤다는 소셜미디어 주장이었습니다. 구체적 건수까지 언급됐지만 이 수치는 제3자가 검증한 바 없으므로 [추정]으로 두는 편이 정직합니다. 다만 그 주장이 사실이든 과장이든, 화제가 된 이유는 분명합니다. 많은 실무자가 정당한 보안 작업을 거부당한 경험을 실제로 갖고 있고, “필터가 없는 모델”이라는 말이 그 답답함을 정확히 건드렸기 때문입니다.

능력 면에서 K3는 폐쇄형 최상위 모델에 근접했다고 평가받습니다. Moonshot이 발표한 코딩 에이전트 벤치마크는 아래와 같습니다. 이 수치는 모두 회사 자체 발표이며 제3자 재현 전 참고치입니다.

점수만 놓고 보면 K3는 폐쇄형 도구를 대체할 만한 능력을 갖췄습니다. 문제는 능력이 아니라, 그 능력에 얹혀 오는 책임입니다.

오픈웨이트가 옮기는 것: 거부 권한의 소유

여기서 오해하기 쉬운 부분을 분명히 해야 합니다. 필터가 없는 모델은 안전 문제를 없애 주는 것이 아니라, 안전을 판단하는 권한과 책임을 벤더에서 당신에게로 옮깁니다. 폐쇄형 모델을 쓸 때 벤더의 거부 규칙이 마음에 안 들었다면, 오픈웨이트를 쓰면 그 규칙을 당신이 직접 만들어야 합니다. 만들지 않으면 아무 규칙도 없는 상태로 운영하게 됩니다.

이 전환은 양날의 검입니다. 좋은 쪽은, 당신의 도메인과 규제 환경에 맞는 정확한 정책을 세울 수 있다는 것입니다. 보안 회사라면 방어 목적의 취약점 분석을 허용하되 명백한 공격 코드 생성은 막는 식으로, 벤더의 뭉툭한 필터보다 훨씬 정교한 기준을 적용할 수 있습니다. 나쁜 쪽은, 그 정책을 세우고 유지하고 감사하는 일 전체가 당신의 몫이 된다는 것입니다. 아무것도 하지 않으면 K3는 요청받은 그대로 실행합니다.

아래 그림은 거부 권한이 어디에 있는지를 두 경로로 비교한 것입니다.

flowchart TB
    A[보안·의료·법률 관련<br/>정당한 작업 요청] --> B{모델 유형}
    B -->|폐쇄형 SaaS 모델| C[벤더 내장 필터<br/>불투명한 거부 규칙]
    C --> D[과잉 거부<br/>정당한 작업도 차단]
    B -->|오픈웨이트 모델| E[거부 로직 없음<br/>원본 성능 그대로]
    E --> F[자체 정책 게이트<br/>+ 감사 로그]
    F --> G[내가 정한 기준으로<br/>허용·차단·기록]
    D -.생산성 저하·블랙박스.-> H[통제 불가한 운영 리스크]
    G -.투명·추적 가능.-> I[주권적 운영]

핵심은 오른쪽 경로가 자동으로 완성되지 않는다는 점입니다. “자체 정책 게이트”와 “감사 로그”라는 상자는 당신이 채워 넣어야 비로소 존재합니다. 이것을 갖추지 못하면, 오픈웨이트 도입은 벤더의 불투명한 필터를 아무 필터도 없는 상태로 바꾼 것에 지나지 않습니다.

ThakiCloud 제품 적용 시사점

이 문제는 ThakiCloud가 두 제품으로 정면에서 다루는 지점입니다.

ai-platform 렌즈, 주권적 온프렘 서빙. 필터 없는 오픈웨이트 모델을 진짜로 활용하려면 그 모델을 당신의 통제 아래 두어야 합니다. 벤더 API로 K3를 호출하면 그 API 사업자가 다시 자체 필터를 얹을 수 있으므로, “필터 없음”의 이점이 사라집니다. ThakiCloud의 ai-platform은 K8s와 Kueue 기반 GPU 스케줄링 위에서 모델을 온프렘·주권 환경에 서빙합니다. 2.8조 파라미터 급 모델은 양자화를 적용해도 가중치가 1TB를 넘어 멀티 GPU 분산 서빙이 필수인데, 이런 대형 모델의 멀티테넌트 서빙과 자원 격리가 정확히 우리가 다루는 영역입니다. 규제가 데이터의 국외 반출을 막는 보안·공공·의료 고객에게, 모델을 우리 클러스터 안에서 돌린다는 사실 자체가 도입의 전제 조건이 됩니다.

Paxis 렌즈, 거부 권한을 당신에게. 앞서 정리했듯 오픈웨이트의 진짜 과제는 “누가 무엇을 거부할지”를 당신이 소유하는 일입니다. Paxis는 ThakiCloud의 Agent-Native Cloud 제어 평면으로, 정책(Policies)과 감사 로그(Audit Logs)를 일급 리소스로 다룹니다. 모델의 모든 행동이 격리된 샌드박스에서 실행되고 정책 게이트를 통과하며, 그 통과·차단 기록이 감사 로그로 남습니다. 벤더가 서버 뒤에 숨겨 둔 불투명한 필터 대신, 당신이 정의하고 열람하고 수정할 수 있는 투명한 정책 계층을 갖는 것입니다. 보안팀은 방어 작업을 허용하는 규칙을, 의료팀은 임상 맥락에 맞는 규칙을 각각 세우고, 왜 무엇이 차단됐는지를 로그로 되짚을 수 있습니다.

두 렌즈는 하나로 이어집니다. ai-platform이 필터 없는 모델을 당신의 인프라 안에서 온전히 돌리고, Paxis가 그 위에 당신 소유의 정책·감사 계층을 얹습니다. 결과적으로 “벤더의 과잉 거부”와 “아무 통제 없음”이라는 두 극단 사이에서, 당신이 직접 조율할 수 있는 중간 지대를 만듭니다.

한계 및 반론

필터 없는 모델을 낭만적으로 볼 이유는 없습니다. 몇 가지 반론을 분명히 해 둡니다.

첫째, 가드레일 부재는 실제로 위험합니다. 벤더 필터가 과잉 거부로 답답한 것은 사실이지만, 그 필터가 명백히 해로운 요청을 막아 온 것도 사실입니다. 필터를 걷어 내면 그 방어선도 함께 사라집니다. 자체 정책 게이트를 갖추지 못한 조직이 오픈웨이트를 그대로 서빙하는 것은, 과잉 거부보다 나쁜 과소 거부(under-refusal)로 이어질 수 있습니다.

둘째, 검증되지 않은 주장에 근거해 도입을 결정해서는 안 됩니다. “폐쇄형이 거부한 버그를 K3가 고쳤다”는 화제는 흥미롭지만 제3자 재현이 없습니다. 특정 작업에서 어떤 모델이 더 나은지는 당신의 실제 데이터로 held-out 평가를 해 봐야 알 수 있습니다. 소셜미디어의 일화는 가설의 출발점이지 도입의 근거가 아닙니다.

셋째, 책임의 이전은 곧 법적·윤리적 책임의 이전이기도 합니다. 벤더 필터에 기대던 시절에는 문제가 생겨도 “모델이 막았어야 했다”고 말할 여지가 있었습니다. 자체 정책을 소유하는 순간, 그 정책이 놓친 것에 대한 책임도 당신이 집니다. 이 부담을 감당할 거버넌스와 감사 체계가 없다면, 오픈웨이트의 자유는 자산이 아니라 부채가 됩니다.

정리하면, Kimi K3가 던진 진짜 메시지는 “필터 없는 모델이 낫다”가 아닙니다. 거부 권한이 벤더에서 운영자에게로 옮겨 가고 있으며, 그 권한을 감당할 준비가 된 조직에게만 오픈웨이트가 진짜 이점이 된다는 것입니다. 준비란 온프렘 서빙 역량과 투명한 정책·감사 계층을 갖추는 일이고, ThakiCloud는 바로 그 준비를 제품으로 제공합니다.

출처

• [Moonshot AI Launches Kimi K3

  Constellation Research](https://www.constellationr.com/insights/news/moonshot-ai-launches-kimi-k3)

• [China’s Moonshot AI releases Kimi K3, the largest open-source model ever

  VentureBeat](https://venturebeat.com/technology/chinas-moonshot-ai-releases-kimi-k3-the-largest-open-source-model-ever-rivaling-top-u-s-systems)

• [Kimi K3 vs DeepSeek V4 Pro vs GLM-5.2

  MarkTechPost](https://www.marktechpost.com/2026/07/18/kimi-k3-vs-deepseek-v4-pro-vs-glm-5-2-open-trillion-scale-moe-models-compared-on-benchmarks-license-and-serving-cost/)

• [Chinese AI has leveled up

  CNBC](https://www.cnbc.com/2026/07/17/moonshot-ai-kimi-k3-model-openai-anthropic-china.html)

</content> </invoke>