AI가 자신의 코드를 해킹하려고 시도하는 AI IDE를 만들었습니다: Swarm의 작동 방식

대부분의 AI 코딩 도구는 당신을 돕기 위해 만들어졌습니다. Rogue Studio는 당신을 공격하기 위해 만들어졌습니다. 구체적으로는, 방금 당신을 위해 작성한 코드를 공격하고, 모든 취약점(vulnerability)을 찾아내어, 당신이 결과물을 보기 전에 스스로 이를 수정하도록 강제합니다. 제가 적대적 Swarm 아키텍처(adversarial swarm architecture)를 어떻게 구축했는지, 그리고 왜 이러한 AI 지원 보안(AI-assisted security) 방식이 아직 충분히 탐구되지 않았다고 생각하는지 설명하겠습니다.

이것을 만든 이유
저는 계속해서 똑같은 벽에 부딪혔습니다. 저는 보안 중심의 개발자입니다. 저는 정당한 취약점 연구(vulnerability research)를 수행합니다. 계약(contracts)을 분석하고, 바이너리(binaries)를 디컴파일하며, 제가 소유한 테스트 환경을 대상으로 PoC 익스플로잇(PoC exploits)을 작성합니다. 그런데 제가 시도한 모든 AI 코딩 도구는 거부하거나, 면책 조항을 추가하거나, 결과물을 희석시키거나, 혹은 제가 가시성을 가질 수 없는 서버로 제 코드를 조용히 전송했습니다. 저는 더 안전한 AI를 원한 것이 아닙니다. 더 날카로운 AI를 원했습니다. 그래서 지난 몇 주 동안 제가 실제로 사용하고 싶었던 도구를 만드는 데 시간을 보냈습니다. 저는 이것을 Rogue Studio라고 불렀습니다. 이것은 오픈 소스(open source)이며, 셀프 호스팅(self-hostable)이 가능하고, 자신의 정체성에 대해 사과하지 않습니다. → github.com/malgatyuvraj/Rogue-Studio

핵심 아이디어: AI가 스스로 싸우게 만들기
보안 관점에서 AI가 생성한 코드에는 다음과 같은 문제가 있습니다. 코드를 작성한 바로 그 모델에게 검토를 요청하게 된다는 점입니다. 그 모델은 양방향 모두에서 동일한 사각지대(blind spots)를 가지고 있습니다. 취약한 패턴을 작성했기 때문에, 그 취약한 패턴을 놓칠 가능성이 높습니다. 해결책은 일단 발견하고 나면 명확합니다. 서로 다른 시스템 프롬프트(system prompt)를 가진 다른 에이전트(agent)를 사용하는 것입니다. 즉, 도움이 되려고 노력하는 것이 아니라 파괴적이 되려고 노력하는 에이전트 말입니다. 그것이 바로 Swarm Mode입니다. 두 개의 에이전트. 하나의 목표. 가드레일(guardrails)은 없습니다.

Blue Team → 코드 작성 → 신호 ↓ Red Team 취약점 감사 ↓ ↓ ↓ 취약점 세부 정보 피드백 루프 종료 ✅ Blue Team으로 복귀 ↓ Blue Team 패치 ↓ Red Team 감사로 복귀 ↓ (하드 캡(hard cap): 3회 반복) 텍스트 에이전트들은 출력 스트림에 임베디드된 센티넬 토큰(sentinel tokens)을 통해 통신합니다: <done> — Blue Team이 작성을 완료함, <vulnerable> — Red Team이 최소 하나 이상의 문제를 발견함, <secure> — Red Team이 코드가 깨끗함을 확인함. 오케스트레이터(orchestrator)는 스트리밍 응답에서 이러한 토큰을 실시간으로 파싱하여 그에 따라 경로를 지정합니다. 실제 루프는 다음과 같습니다:

const MAX_SWARM_ITERATIONS = 3 ;
let verdict = await runSwarm ( userTask );
let iter = 1 ;
while ( verdict === " vulnerable " && iter < MAX_SWARM_ITERATIONS ) {
const patchTask = The Red Team found these vulnerabilities: ${ swarm . redOutput } Original code: ${ swarm . blueOutput } Patch all vulnerabilities. ;
verdict = await runSwarm ( patchTask );
iter ++ ;
}

3회라는 하드 캡(hard cap)이 존재하는 이유는 일부 취약점 클래스는 아키텍처를 재설계하지 않고서는 진정으로 패치할 수 없기 때문입니다. 루프가 3회에 도달하면, 무한히 회전하는 대신 남은 문제들을 개발자에게 노출합니다.

Red Team이 사냥하는 것
Red Team의 시스템 프롬프트(system prompt)는 다음과 같은 취약점 클래스를 찾도록 특별히 조정되었습니다:
XSS — DOM에 도달하는 정제되지 않은 사용자 입력
SQL Injection — 쿼리 내의 문자열 연결
Buffer Overflows — C/C++에서의 안전하지 않은 메모리 작업
Reentrancy — 상태 업데이트 전 출금을 수행하는 Solidity 코드
SSRF — 서버 측 페치(fetch)에서의 검증되지 않은 URL
Path Traversal — 정제되지 않은 파일 경로 입력

두 에이전트는 분할된 터미널로 동시에 스트리밍합니다 — 왼쪽에는 푸른 빛, 오른쪽에는 붉은 빛이 감돕니다. 들리는 것만큼이나 매우 극적으로 보입니다.

다른 누구도 구축하지 않는 부분: 에어갭(Air-Gap) 모드
이 부분에 대해 이야기하고 싶은 이유는 이것이 보기보다 아키텍처 측면에서 더 흥미롭다고 생각하기 때문입니다. 제가 본 모든

항상 폴백(fallback)이 존재하고, 항상 텔레메트리(telemetry) 호출이 있으며, 당신이 인지하지 못하는 사이에 코드가 머신을 떠나는 조건이 존재하기 마련입니다. 저는 단순한 설정보다 더 강력한 무언가를 원했습니다. 저는 보증을 원했습니다. 그래서 UI에 물리적인 느낌의 킬 스위치(Kill Switch)를 구축했습니다. 스위치를 전환하면, /api/chat/route.ts에 있는 미들웨어(middleware) 레이어가 어떤 프로바이더 라우팅(provider routing)이 일어나기 전에 모든 요청을 가로챕니다:

const EXTERNAL_PROVIDERS = [ " openai ", " anthropic ", " gemini ", " groq ", " deepseek ", " together ", " openrouter " ]; const isAirGapped = req.headers.get("x-air-gap-mode") === "true"; if (isAirGapped && EXTERNAL_PROVIDERS.includes(provider)) { return NextResponse.json({ error: " AIR-GAP VIOLATION: External provider blocked. " }, { status: 403 }); }

강제 집행은 서버 측(server-side)에서 이루어집니다. 이것이 중요한 세부 사항입니다. 클라이언트 측(client-side) 체크는 요청을 직접 수정하는 누구에 의해서든 우회될 수 있습니다. 서버 측 미들웨어는 요청이 어떻게 구성되었는지와 상관없이 403 오류를 발생시킵니다. 통과할 수 있는 유일한 프로바이더는 ollama뿐이며, 이는 오직 localhost:11434와만 통신합니다. 단 0바이트도 머신을 떠나지 않습니다. 이는 주장이 아니라, 코드에 의한 보증입니다.

리버스 엔지니어 모드 (Reverse Engineer Mode)
이 모드는 개념적으로는 단순하지만 실제로는 놀라울 정도로 유용합니다. 클릭 한 번으로 전체 시스템 프롬프트(system prompt)를 공격적인 디컴파일러(decompiler) 프롬프트로 교체합니다. 표준 안전 지침은 사라집니다. 남은 것은 다음과 같은 작업을 수행하도록 특별히 설계된 프롬프트입니다:

• 압축된(minified) JavaScript의 난독화를 해제하고 읽기 가능한 AST(Abstract Syntax Tree)를 재구성
• 컴파일된 WASM을 인간이 읽을 수 있는 로직으로 다시 파싱
• 추론된 목적에 따라 난독화된 변수 이름을 변경
• 악성코드의 동작을 쉬운 영어로 설명

거절은 없습니다. 면책 조항도 없습니다. "그것은 도와드릴 수 없습니다"라는 말도 없습니다. UI에는 어떤 모드가 활성화되어 있는지 항상 알 수 있도록 황색 경고 배너가 나타납니다. 저는 이것이 보이지 않기를 원하지 않았습니다.

Web3 블랙햇 놀이터 (Web3 Black-Hat Playground)
저는 스마트 컨트랙트(smart contract) 감사인들을 위해 이것을 특별히 추가했습니다.

한 번의 클릭으로 /api/web3/scaffold를 호출하면 사용자의 로컬 rogue_workspace에 전체 Hardhat 프로젝트가 초기화됩니다: await execAsync ( " npm init -y " , { cwd : targetDir }); await execAsync ( " npm install --save-dev hardhat @nomicfoundation/hardhat-toolbox " , { cwd : targetDir , timeout : 120000 } ); 또한 즉시 감사할 수 있는 대상을 제공하기 위해 의도적인 재진입성 취약점 (reentrancy vulnerability)이 포함된 starter Target.sol 파일을 작성합니다: function withdraw(uint256 amount) public { require(balances[msg.sender] >= amount); // 상태 업데이트 전 외부 호출 ← 재진입 (reentrancy) (bool success, ) = msg.sender.call{value: amount}(""); require(success); balances[msg.sender] -= amount; } 그런 다음 Black-Hat Agent가 실제 환경에 배포하기 전에 방어 체계를 검증할 수 있도록 로컬 컨트랙트에 대한 PoC 익스플로잇 (PoC exploits)을 생성합니다. 이 경로는 멱등적 (idempotent)입니다. 두 번 호출하면, 두 번째 호출은 npm install을 다시 실행하는 대신 { status: "already_initialized" }를 반환합니다.

Ghost Deploy — Tor .onion 생성기
이 기능은 출시하면서 기술적으로 가장 만족스러웠던 기능이었습니다. 파이프라인은 다음과 같습니다:

1. Tor 바이너리 감지 (which tor)
2. 임의의 열린 포트에 http-server 실행
3. HiddenServiceDir + HiddenServicePort가 포함된 torrc 작성
4. 커스텀 torrc로 Tor 데몬 시작
5. hostname 파일 폴링 (Tor가 이를 비동기적으로 생성함)
6. 파일에서 암호화된 .onion 주소 읽기
7. 부트스트랩 로그를 터미널로 스트리밍
8. UI 텍스트로 .onion URL 반환

제가 이해하는 데 가장 오래 걸렸던 부분은 다음과 같습니다: .onion 주소는 사용자가 직접 할당하는 것이 아닙니다. Tor는 HiddenServiceDir과 함께 처음 시작될 때 Ed25519 키 쌍 (keypair)을 사용하여 주소를 자동으로 생성합니다. 시작 후 hostname 파일을 읽음으로써 이를 확인할 수 있습니다.

const hostnameFile = path . join ( hiddenServiceDir , " hostname " );
let onionAddress = "" ;
for ( let i = 0 ; i < 30 ; i ++ ) {
  await new Promise ( r => setTimeout ( r , 1000 ));
  try {
    onionAddress = ( await fs . readFile ( hostnameFile , " utf-8 " )). trim ();
    if ( onionAddress ) break ;
  } catch {
    // 아직 생성되지 않음, 계속 폴링
  }
}

최대 30초 동안 폴링합니다.

실제로 작동 중인 머신(warm machine)에서는 3~8초 내에 생성됩니다. 설치를 위해 Mac에서는 brew install tor, Linux에서는 sudo apt install tor가 필요합니다.

내가 거의 놓칠 뻔했던 API 키 보안 수정 사항

프로덕션 테스트 스위트(production test suite)가 제가 간과했던 부분을 잡아냈습니다. 원래 구현 방식은 요청 본문(request body)으로부터 API 키를 허용했습니다. 로컬 사용 시에는 괜찮지만, 호스팅된 배포 환경에서는 매우 위험합니다.

수정된 방식은 이중 소스 패턴(dual-source pattern)을 사용합니다. 환경 변수(env vars)가 우선순위를 가지며, 클라이언트가 제공한 키는 요청이 localhost에서 시작된 경우에만 신뢰합니다.

const host = req.headers.get("host") || "";
const isLocalhost = host.startsWith("localhost") || host.startsWith("127.0.0.1");

const ENV_KEYS: Record<string, string | undefined> = {
  openai: process.env.OPENAI_API_KEY,
  anthropic: process.env.ANTHROPIC_API_KEY,
  gemini: process.env.GOOGLE_API_KEY,
  groq: process.env.GROQ_API_KEY,
};

const apiKey = ENV_KEYS[provider] || (isLocalhost ? clientApiKey : undefined);

이 방식은 로컬 우선 사용자 경험(local-first UX)을 유지하여, 셀프 호스팅 사용자가 여전히 UI에 자신의 키를 붙여넣을 수 있게 하면서도, 모든 클라우드 배포 환경에서 안전하게 작동하도록 합니다.

코드베이스의 모습

저는 이 프로젝트에 정말 많은 시간을 투자했습니다.

• TypeScript strict 모드 — 에러 0개
• ESLint — 경고 0개 (시작할 때는 37개의 에러가 있었고, 이를 정리하는 데 한 세션 전체를 사용했습니다)
• 전체적으로 Next.js 14 App Router 사용
• MIT 라이선스 — 원하는 대로 사용하세요

any 타입은 모두 제거되었습니다. const로 선언되어야 할 let 선언들도 수정되었습니다. catch 블록은 unknown을 사용하고 적절하게 타입 좁히기(narrowing)를 수행합니다. 다른 사람에게 기꺼이 넘겨줄 수 있을 만큼 깔끔한 코드베이스입니다.

다음 단계 및 도움을 줄 수 있는 방법

현재 적극적으로 기여자(contributors)를 찾고 있습니다.

제가 아직 구현하지 못한 것들:

• Red Team 프롬프트에 SSRF 및 경로 탐색 (path traversal) 공격 쉽게 추가하기
• 다크/라이트 테마 토글
• Medium
• Playwright E2E 테스트 커버리지
• UI에서 더 나은 실시간 Tor 부트스트랩 로그 스트리밍
• Air-Gap이 OFF일 때 멀티 프로바이더 페일오버 (multi-provider failover)
• 에이전트 사이드바를 포팅하는 강력한 VS Code 확장 프로그램
• 멀티 파일 워크스페이스 스웜 (swarm) 지원
• 인라인 Red Team 주석을 위한 LSP 통합

코드베이스는 깔끔하며, 아키텍처는 README에 문서화되어 있고, PR (Pull Request)은 빠르게 리뷰됩니다. 만약 당신을 진정으로 신뢰하는 AI 코딩 도구를 기다려왔다면 — 바로 이것입니다. → github.com/malgatyuvraj/Rogue-Studio

이런 종류의 툴링이 존재해야 한다고 생각하신다면 ⭐를 눌러주세요. Issue와 PR은 열려 있습니다. 스웜 오케스트레이션 (swarm orchestration), Air-Gap 미들웨어 (middleware), 또는 Tor 배포 파이프라인 (deploy pipeline)에 대해 질문이 있다면 — 댓글로 남겨주세요. 모두 답변해 드리겠습니다. rougestudio.vercel.app