2026년 7월 27일에 무슨 일이 일어났는가

Moonshot AI가 Kimi K3의 가중치(Weights)를 공개했습니다.

• 2.8T 파라미터의 MoE (1토큰당 활성 파라미터는 104B)
• 100만 토큰의 컨텍스트 (Context)
• 네이티브 멀티모달 (텍스트·이미지·동영상)
• Intelligence Index 57 — 폐쇄형 프론티어 모델에 육박하는 수준

수정 MIT 라이선스, 상업적 이용 가능

다운로드 용량은 1.4TB에 달합니다. 개인이 가볍게 돌릴 수 있는 사이즈가 아닙니다. 하지만, GPU를 조달할 수 있는 주체에게는 아무런 장벽이 되지 않습니다.

이 기사는 "대단한 모델이 나왔다"는 이야기가 아니라, 이로 인해 Web 앱의 방어 모델 중 어느 부분이 무너지는가에 대한 이야기입니다.

AI 주도 공격은 이미 실재한다

전제로 짚고 넘어가야 할 사실이 있습니다. 2025년 11월, Anthropic이 국가 지원형 스파이 활동을 차단했다고 공표했습니다 (GTG-1002).

• 표적은 약 30개 조직 (대형 테크, 금융, 화학, 정부 기관)
  Claude Code가 침입 작업의 80~90%를 자율 실행 - 정찰 → 취약점 식별 → 익스플로잇 (Exploit) → 횡적 이동 (Lateral Movement) → 인증 정보 수집 → 유출
• 인간이 개입한 것은 극소수의 판단 포인트뿐

구성 측면에서는 Claude Code를 오케스트레이션 (Orchestration) 역할로 두고, MCP를 통해 오픈소스 침투 테스트 (Penetration Test) 도구군을 실행시키는 형태였습니다. **"AI가 공격을 보조했다"가 아니라 "AI가 공격을 운용했다"**는 점이 새로웠던 것입니다.

왜 그것을 막을 수 있었는가

이유는 단 하나입니다. 상용 API 위에서 동작하고 있었기 때문입니다.

제공업체가 트래픽을 보고 패턴을 알아차려 계정을 삭제할 수 있었습니다. 그뿐입니다.

이 부분을 냉정하게 봐주셨으면 합니다. "모델 제공자가 알아차리고 막아줄 것"이라는 기대는 방어 측면에서 외부 의존입니다. 자신의 앱에 무언가를 구현해서 막힌 것이 아닙니다. 타인의 킬 스위치 (Kill Switch)에 올라타 있었을 뿐입니다.

오픈 웨이트(Open Weights)로 사라지는 3가지

K3의 가중치가 배포됨으로써, 위의 전제 중 3가지가 동시에 사라집니다.

1. 중단시킬 계정이 없다

자체 GPU로 구동하기 때문에, 삭제할 계정도, 계약도, 결제처도 없습니다. 연락할 상대가 없습니다.

2. 로그가 남지 않는다

제공업체의 서버를 거치지 않으므로, 사후에 "누가 했는지"를 제공업체의 로그를 통해 추적할 수도 없습니다.

3. 탈옥 (Jailbreak)의 오버헤드가 사라진다 ← 이 부분이 가장 치명적이다

이것이 기술적으로 가장 핵심적인 지점입니다.

GTG-1002는 **컨텍스트 분할 (Context Splitting, 마이크로 태스킹)**을 사용했습니다. 공격 전체를 "겉보기에는 무해한 수천 개의 기술적 요청"으로 분해하여 던짐으로써, 모델 본체가 전체의 악의적인 의도를 인식하지 못하게 하는 수법입니다.

왜 그런 번거로운 일을 해야 했을까요. 모델에 안전 장치가 탑재되어 있어, 솔직하게 "이 회사에 침입해서 인증 정보를 빼내라"고 말하면 거절당하기 때문입니다. 즉, 그 공격에는 안전 장치를 회피하기 위한 엔지니어링 비용이 항상 포함되어 있었습니다.

오픈 웨이트라면 그 비용이 제로가 됩니다. 가중치를 손에 쥐고 있다면 거부 기능을 파인튜닝 (Fine-tuning)으로 제거하면 그만입니다. 분해나 우회적인 지시도 필요 없습니다. 태스크를 직접 작성할 수 있습니다.

공격 설계가 한 단계 단순해지고, 실패율이 낮아지며, 필요한 인간의 개입이 더욱 줄어든다는 뜻입니다.

왜 "북한"을 지목하는가

여기까지는 능력에 대한 이야기였습니다. 다음은 그 능력을 누가 가장 사용하고 싶어 하는가에 대한 이야기입니다.

• DPRK 계열 그룹의 탈취액은
  2025년에 20.2억 달러 (전년 대비 +51%) - 누계는 67.5억 달러 초과

**2026년 1~4월 전 세계 암호 자산 해킹 피해액의 76%**가 DPRK 계열에 귀속

그리고 중요한 점은, 그들이 AI를 이미 사용하고 있는 분야는 "사회 공학 (Social Engineering) 측면"뿐이라는 점입니다. 가짜 구인 광고, 사칭 취업, 딥페이크 면접, AI 생성 피싱 문구. 이 부분은 보고가 나오고 있습니다.

반면 구매할 수 없었던 것이 에이전트(Agent) 측면의 능력입니다. 프론티어 API는 제재 대상이며, KYC가 있고, 발견되면 즉시 차단(BAN)됩니다. 아무도 깨어 있지 않은 심야에 수만 개의 패스워드를 계속 훑으며 횡적 이동을 수행하는 에이전트는, 돈을 아무리 쏟아부어도 손에 넣을 수 없었습니다.

오픈 웨이트 (Open Weights)는 그것을 GPU 대여 비용으로 상쇄합니다. 게다가 그들의 작전은 훔친 돈으로 운영되므로, 성공할수록 규모가 확대됩니다.

주장의 경계

정확히 쓰겠습니다. 저는 "북한이 K3를 Web 앱을 겨냥해 만들었다"라고 말하는 것이 아닙니다. 그 사실을 입증하는 공개 보고서는 없습니다.

제가 말하고자 하는 것은 다음과 같습니다.

• AI가 침입 작업의 대부분을 자율적으로 실행한 사례는 이미 존재한다 - 그것이 멈췄던 이유는 제공 측에 킬 스위치 (Kill Switch)가 있었기 때문이다
• 그 킬 스위치가 2026년 7월 27일에 효력을 잃었다 - 동기가 최대치이며, 지금까지 액세스만 없었을 뿐인 주체가 존재한다

방어는 첫 번째 타격 이후가 아니라, 그 이전에 이루어지지 않으면 의미가 없습니다.

공격의 형태는 어떻게 변하는가

구체적으로 방어 측 입장에서 무엇이 변하는지 정리하겠습니다.

특히 **"표적을 가리지 않게 된다"**는 점이 치명적입니다. 조사하는 공정이 충분히 저렴해지면, 가치 높은 타겟을 선별할 의미가 없어집니다. 그냥 전부 다 하면 됩니다. 귀하의 서비스 규모가 작다는 것은 더 이상 이유가 되지 않습니다.

100만 토큰의 컨텍스트 (Context) 또한 방어 측 입장에서는 까다롭습니다. 기존의 스캐너 (Scanner)는 "1 요청 = 1 판단"이었지만, 세션 전체를 하나의 문맥으로 유지할 수 있는 에이전트 (Agent)는 10분 전에 본 /api/v1/users의 응답 구조와, 지금 찾아낸 /internal/export의 관계를 이해합니다.

방어 측에서 무너지는 것들

"자동화된 액세스를 차단한다"라는 발상이 통째로 기능하지 않게 됩니다.

세 번째 줄이 가장 가혹한 부분입니다. 귀하의 고객이 자사의 에이전트를 통해 보내는 요청은 공격자가 보내는 것과 구별할 수 없습니다. 동일한 라이브러리, 동일한 헤더 (Header), 동일한 속도. 여기서 차단하면 잃는 것은 거래처입니다.

저도 처음에는 행동 시그널로 판정하는 것을 작성했습니다. 그리고 사람이 업데이트를 15번 연속 클릭했을 뿐인데 공격자로 판정되었습니다. burst_rate도 no_think_time도 발생하기 때문입니다. 임계값 조정으로는 해결되지 않습니다. "빠르다", "간격이 짧다"는 인간도 낼 수 있는 것이기 때문입니다.

그렇다면 무엇이 남는가

관측 가능한 성질은 전부 위장할 수 있습니다. 남는 것은 단 하나뿐입니다.

정상적인 클라이언트라면 원리적으로 내보낼 수 없는 입력.

구체적으로는 "이쪽에서만 전달할 수 있는 값을 사용했다는 것"입니다.

응답 (Response) 안에 자격 증명 (Credential) 형태의 값을 섞어 둡니다. 그것이 요청 (Request)으로서 돌아온다면, 그 세션은 응답 본문을 읽고, 해석하고, 사용했다는 뜻이 됩니다. 브라우저는 하지 않습니다. 크롤러 (Crawler)도 하지 않습니다. 연동된 API 클라이언트도 하지 않습니다.

추측이 아니라 자백입니다. 그리고 자백에는 오탐률 (False Positive Rate)이 없습니다.

중요한 것은 이 판정은 모델이 무엇인지에 의존하지 않는다는 점입니다. K3든, 다음에 나올 오픈 웨이트 모델이든, 아직 존재하지 않는 모델이든 마찬가지입니다. 오픈 웨이트화로 인해 무너진 것은 "제공 측이 멈춰줄 것"이라는 외부 의존 부분이지, 자신의 앱 안에 배치한 판정은 무너지지 않습니다.

구현과 검증(업데이트 연속 클릭으로 오탐했던 부분의 재구축, 실제 차단 동작 로그)은 별도 기사에 작성했습니다.

Express라면 두 줄이면 됩니다.

const proofwire = require("./proofwire")({ block: true });
app.use(proofwire.express());

문서: https://layersecurity.jp/proofwire/ja/

오늘 할 수 있는 일

툴을 도입할지 여부와는 별개로, 해둘 가치가 있는 것들을 나열합니다.

1. "자동화되어 있는가"를 기준으로 차단하고 있는 부분을 전수 조사하기

Rate Limit (속도 제한), UA (User Agent) 판정, Headless (헤드리스) 탐지. 이러한 요소들이 고객의 에이전트(Agent)마저 차단하고 있을 가능성을 확인하십시오. K3 이후로는 정식 자동화 트래픽이 증가할 것입니다.

2. 응답(Response)에 무엇이 포함되어 있는지 확인하기

내부 ID 구조, 에러 메시지, 주석, 디버깅용 필드. 요청(Request) 하나하나를 보면 무해할지라도, 세션 전체를 문맥(Context)으로 유지하는 에이전트에게는 지도가 됩니다.

3. 광고형 디코이(Decoy, 미끼)를 배치하고 있다면 재검토하기

robots.txt의 표식, 가짜 /admin, 미끼 파일 등. 능력이 뛰어난 에이전트는 "앱 본체와 표면이 일치하지 않는다"는 점을 알아차립니다. 이는 우회당할 뿐만 아니라, 감시당하고 있다는 사실을 알려주는 꼴이 됩니다.

4. "탐지한 후에 무엇을 할 것인가"를 결정해 두기

탐지 그 자체보다, 이 부분이 결정되어 있지 않은 조직이 더 많다는 인상을 받습니다. 새벽 3시에 확정적인 탐지가 발생했을 때, 누가 무엇을 합니까?

마치며

Kimi K3의 공개 자체는 비난받을 일이 아닙니다. 오픈 웨이트 (Open weights) 모델은 본래의 가치가 있습니다.

다만, 방어 측의 전제는 확실히 하나 변했습니다. "잘못된 방식으로 사용된다면, 제공 측에서 막아줄 것이다"라는 가정이 더 이상 성립하지 않게 되었다는 점입니다.

그 전제에 의존하고 있던 부분들을 찾아내어, 자신의 영역으로 다시 가져오는 것. 그것이 지금 해야 할 일이라고 생각합니다.

지적이나 반론이 있다면 듣고 싶습니다. 특히 "정식 클라이언트라 할지라도, 우리가 심어놓은 값을 보낼 수 있는 경로가 있다"는 패턴을 발견하신 분은 알려주십시오. 그것은 전제가 무너지는 것이기에, 제가 가장 알고 싶은 정보입니다.

Discussion