AI 역설계 방어 도구 BLA, 1인 앱 개발자가 막을 수 있는 것과 없는 것

요즘은 AI한테 앱 파일만 넘기면 소스 코드 없이 뜯어보고 비슷하게 만들어 주는 도구가 있다.

그 반대편에서 막는 도구도 나왔다. 이름은 BLA(Blind LLM Agents). 내가 배포하는 빌드에 미끼를 심어서 AI 분석기가 헛돌게 만든대.

나는 난독화 같은 거 없이 빌드 그대로 앱을 낸다. 그래서 이 도구가 뭘 하는지보다 먼저 궁금한 게 있었다.

이게 믿을 만한 도구인지.

AI가 앱을 뜯어보는 도구, REA

BLA가 겨냥하는 상대는 REA(Reverse Engineer Anything)라는 오픈소스다.

README에 따르면 AI 에이전트가 소스 없이 앱을 조사해서 기능이 어떻게 돌아가는지 설명하고, 내 프로젝트용으로 비슷하게 만들어 주는 도구래. 네이티브 프로그램, 자바스크립트·Electron 앱, .NET, 웹사이트까지 다룬다고 한다.

깃허브 스타는 407,423개다(2026년 10월 30일 기준). 생긴 지 반년 남짓인데 숫자가 이렇다.

어떻게 쓰는지는 여기 안 적는다. 이 글은 막는 쪽 얘기만 한다.

뜯기면 아까운 건 코드보다 아이디어

내 앱이 뜯기면 뭐가 제일 아까울까.

솔직히 아까운 거 별로 없다. 그냥 아이디어가 아깝다. 아, 핵심 로직이 그나마 제일 아깝지.

근데 그 코드도 다 AI가 짜준 거다. 내가 스스로 생각해서 한 줄씩 하드코딩한 거였으면 하나하나 다 아까웠을 것 같은데, AI가 짜준 코드라 감정이 좀 다르다.

그래도 안 털리는 게 좋긴 하지 ㅋㅋㅋ

누가 REA 같은 걸로 내 앱을 뜯어서 비슷한 걸 하루 만에 낸다고 치면, 좀 짜증 날 것 같긴 하다. 이 녀석이 하면서 욕도 나오고.
(실제로 나올 단어는 블로그에 못 씀)

반대로 남의 앱 보면서 이거 어떻게 만들었지 하고 파볼까 생각은 해봤다. 실제로 파본 적은 딱히 없다.

아까운 게 아이디어와 핵심 로직이라면, 방어 도구한테 기대할 것도 거기 맞춰 재보는 게 맞아 보인다.

BLA는 이렇게 일한대

BLA 저장소 README는 하는 일을 세 층으로 나눠 적어뒀다.

AI 역설계 방어 도구 BLA 작동 방식 3단계, 미끼 심기와 분석 한도 넘기기와 헛도는 결과, 사용자 실행 동작은 그대로라는 README 설명

미끼 심기(Poison): 형식에 맞는 가짜 자격증명, 꿀단지 메타데이터, 진짜처럼 보이는 미끼 흐름을 빌드 안에 넣는다.
한도 넘기기(Exhaust): REA 문서에 적힌 자원 한도를 일부러 넘긴다. 헤더 크기, 중첩 깊이, 인터페이스 목록 길이 같은 것들이래.
헛돌게 하기(Hallucinate): 분석기 손에는 잘린 목록과 애매한 막다른 길만 남긴다.

README 다른 섹션엔 하나가 더 있다. 실행 중 감시인데, Electron 앱 설정을 단단하게 잠그고 디버거가 붙으면 가짜 측정값을 돌려주는 부분이래.

1.5.0 변경 기록에는 AI 모델이 분석을 거부하게 만드는 경고성 미끼 문구를 모든 형식에 퍼뜨렸다고 적혀 있다.

비유하면 이렇다. 미로 입구마다 그럴듯한 가짜 보물지도를 깔아두고, 지도를 다 펼치기도 전에 가방이 꽉 차게 만드는 식.
(나라면 첫 번째 지도에서 바로 낚인다)

그럼 내 앱을 쓰는 사람은? README FAQ에 따르면 실제로 앱이 도는 경로에서는 출력이 바뀌지 않는다. 한도를 넘기는 장치는 평소엔 거치지 않는 조건 뒤에 숨겨뒀다는 설명이다.

만든 쪽이 잰 것, 추정한 것, 안 잰 것

이 도구 README에서 제일 눈에 띈 건 숫자를 세 종류로 나눠 적었다는 점이다.

실측: 만든 쪽이 진짜 REA를 돌려서 분석기가 실제로 한도 오류를 낸 것. 웹앱·데스크톱 앱에서 흔한 형식 셋만 뽑으면 이렇다.

형식	보호 전 → 후 크기	REA 결과
자바스크립트	761B → 116KiB	분석 예산 초과로 거부
Electron ASAR	607B → 16.9MiB	용량 오류(헤더 16MiB 한도)
WASM	54B → 6.56MiB	인터페이스 일부만 읽힘

README 「Empirical results vs real REA」 기준, Node v24.22.1에서 잰 값. 아주 작은 테스트 파일이라 “몇 배 커진다”로 일반화하면 안 된다.

실측 표에 올라간 건 Go, Erlang, SQLite, AI 모델 파일(Safetensors·GGUF)까지 합쳐 12가지다.

설계만: 실드는 들어 있는데 REA 경로로는 아직 안 잰 것. 파이썬, 안드로이드 DEX, Unity IL2CPP, .NET, JVM 등이 여기다.

BLA 형식별 검증 상태, 실제 REA로 잰 12가지와 설계만 된 안드로이드 DEX·Unity IL2CPP·파이썬, 건너뛴 펌웨어·GPU 형식, 토큰 612배는 내부 추정

추정: 14개 대상 벤치마크에서 나온 토큰 약 612.5배, 비용 약 292.2배. README가 이건 REA 한도 목록으로 계산한 내부 추정치고, 위의 실측과 같은 게 아니라고 스스로 적어뒀다.

같은 벤치마크에서 실측인 건 따로 있다. 14개 대상 모두 보호한 뒤에도 입력과 출력이 원본과 100% 같았다는 것(14/14). v1.4.0 기준이다.

그러니까 1인 개발자 입장에서 정리하면 이렇다.

웹앱·Electron 데스크톱 앱(JS): 만든 쪽이 실제 REA로 잰 영역
안드로이드 앱·Unity 게임: 실드는 있지만 실측은 아직인 영역
“AI 비용 600배”류의 말: 추정치

막을 수 없는 것

BLA의 면책 문서(DISCLAIMER)는 한계를 직접 적어뒀다.

no client-side protection scheme can guarantee absolute mathematical secrecy

시간과 디버거를 가진 사람 분석가 앞에서는 어떤 클라이언트 쪽 보호도 비밀을 끝까지 보장 못 한다는 얘기다. 바로 다음 문장이 API 키나 서명 키 같은 중요한 비밀은 믿을 수 있는 서버에 두라는 거다.

README도 안 해본 걸 따로 표로 빼뒀다.

네이티브 디컴파일 도구(Ghidra) 연동: 이 환경에서 안 돌림
실시간 디버거(Frida·LLDB 등): 안 돌림
안드로이드 APK 전체 과정: APK 재서명 미지원
펌웨어, GPU 객체: 건너뜀

공개 도전 과제 기록도 있다. BLA로 단단하게 만든 파일을 AI 역설계 에이전트로 풀어보라는 과제인데, 이전 버전(v4.1)은 레드팀이 CPU 15코어로 12분을 돌리고 사람이 직접 계산기를 짜서 뚫었다고 스스로 적어뒀다. 지금은 원인을 고친 v5.1이 올라가 있다.

비전공 바이브코더 눈높이로 옮기면, BLA는 AI 분석기가 내 빌드를 뜯는 값을 올리는 도구인 모양이다. 못 뜯게 하는 자물쇠라기보다는.
(틀린 데 있으면 살살 알려주길)

이건 나한테 하는 잔소리다. 혹시 앱 안에 API 키 같은 비밀값이 박혀 있다면, BLA를 붙이는 것보다 그걸 서버로 옮기는 게 먼저다.

믿을 만한 도구인가

여기가 내가 제일 궁금했던 부분이다. 2026년 10월 30일 기준으로 확인되는 걸 늘어놓으면 이렇다.

BLA 신뢰성 점검, 2026년 10월 30일 기준 만든 쪽이 밝힌 것과 아직 없는 것, 독립 검증 없음과 npm 1.1.0 버전 차이

숫자로 본 나이

저장소가 생긴 날은 2026년 10월 25일이다. 이 글 기준으로 5일째. 기여자는 2명, 스타는 약 670개, 라이선스는 MIT다.

만든 쪽 말고 다른 사람이 효과를 검증한 자료는 찾지 못했다. 위의 실측도 추정도 전부 만든 쪽이 잰 값이다.

하루가 멀다 하고 바뀌는 버전

10월 27일부터 30일 사이에 1.4.0에서 1.5.1까지 버전이 계속 올라갔다.

1.5.1 변경 기록을 보면 REA 쪽 새 분석기에 맞춘 대응이 들어갔고, 같이 Bun으로 만든 단일 실행 파일이 보호 과정에서 깨지던 문제를 고쳤다고 적혀 있다. 빨리 고친다는 뜻이기도 하고, 버전에 따라 내 빌드가 깨질 수 있다는 뜻이기도 하다.

npm 버전 함정

여기서 하나 걸린다. 🤔

npm에 올라간 최신판은 1.1.0(10월 25일 게시)이고, 저장소 릴리스는 1.5.1까지 나와 있다.

README 첫 화면만 보고 npx bla-agents harden .을 따라 치면 npm 쪽 1.1.0이 깔리고 거기엔 harden이 없어서 명령부터 안 먹을 수 있다. 1.1.0에서는 같은 일을 defend가 한다.

지금 npx로 받으면 README가 설명하는 것보다 옛날 버전이 깔린다. 위에서 말한 분석 거부 유도 문구도 1.1.0 빌드에는 없다.

내 빌드에 들어가는 것

반대로 저장소 최신판을 쓰면 그 분석 거부 유도 문구가 내 출시 빌드 안에 같이 들어간다.

이게 앱스토어 심사나 백신 프로그램 판정에 영향을 주는지는 확인된 자료가 없다. 알고 쓰자는 정도로만 적어둔다.

좋은 신호도 있다

실측과 추정을 스스로 나눠 적었다. verify:rea라는 점검 명령은 “보호 증거로 인용하면 안 된다”고까지 써뒀다.
소스가 MIT로 열려 있다. 뭐가 들어가는지 볼 수는 있다.
파괴적 명령, 셸 실행 코드, 외부로 연락하는 코드는 넣지 않는다고 면책 문서에 적었다.
뚫린 기록을 숨기지 않았다. 앞의 v4.1 얘기다.

하나 더. REA 저장소 README는 비슷한 이름의 저장소나 복사된 README가 공식 배포라는 증거가 아니라고 경고한다.

이 동네는 이름 비슷한 복제 저장소가 많은가 보다. 받을 땐 저장소 주소(qybaihe/bla)와 npm 이름(bla-agents)부터 맞춰보는 게 좋겠다.

그래서 지금 내 판단은 이렇다. 믿을 만하다, 아니, 믿을 만하다기보다 정직하게 적어둔 도구까지는 확인된다.

남이 검증해준 도구는 아직 아니다. 만든 지 5일 된 도구한테 그걸 바라는 것도 좀 이르구 허허.

그래도 써보려면

나는 아직 안 돌려봤다. 나중에 테스트 빌드로 한번 돌려볼 의향은 있다.

그때를 위해 공식 문서와 npm 1.1.0 도움말 기준으로 순서를 정리해뒀다.

준비물

Node.js: 22.13 이상 또는 24 이상(package.json 기준). 만든 쪽 레드팀 재현은 22.23.4 이상이나 24를 권한대.
테스트용 복사본: 출시 폴더 말고 복사본에서. 면책 문서도 출시 전에 스테이징에서 확인하라고 한다.
AI 코딩 도구(선택): Claude Code, Cursor, Codex 등에 연결하면 “내 소프트웨어 강화해줘” 식으로 시킬 수 있다고 한다. 명령줄만 써도 된다.

순서

버전부터 본다. npx bla-agents -v로 지금 깔리는 버전을 확인한다. 1.1.0이면 harden이 없다.
setup은 미리보기로. npx bla-agents setup은 내 AI 코딩 도구 설정 파일에 MCP 서버와 스킬을 등록하는 명령이다. 1.1.0 도움말에 --dry-run이 있어서 뭘 바꿀지 먼저 볼 수 있다.
보호를 건다. npm 1.1.0이면 defend <경로>, 저장소 최신판이면 harden .이 점검부터 검증까지 한 번에 돈대.
강도를 고른다. stealth, balanced, maximum, bankrupt 4단계다. protect의 기본은 balanced, defend·harden의 기본은 제일 센 bankrupt라서 같은 도구여도 명령마다 결과가 다를 수 있다.
검증한다. verify <보호본> <원본>으로 비교하고, 실제로 앱을 실행해서 기능이 다 도는지 본다.
용량을 비교한다. 위 실측 예처럼 파일이 커질 수 있다. 다운로드 크기에 민감한 앱이면 꼭 본다.
그만두려면 uninstall로 MCP 설정과 스킬 파일을 지운다.

빌드할 때마다 자동으로 붙이는 예(postbuild에 protect 걸기)도 설치 문서에 있다. 자동화는 손으로 몇 번 돌려서 앱이 정상인지 본 다음이다.

한국어 README도 있다(docs/readme/README_ko.md). 다만 영어판보다 옛날 내용이라 명령은 영어판 기준으로 맞춰보는 게 좋겠다.

뜯는 값을 올려주는 도구는 있어도, 그 도구를 믿을지는 내가 재봐야 하는 거로구나.

아이디어가 아까운 나한테 BLA는 “그래도 안 털리는 게 좋긴 하지” 정도의 마음에 맞는 크기의 도구인가 보다.

믿을 만한지라는 질문에는, 지금은 만든 쪽 기록까지만 답이 나와 있다.

혹시 나처럼 빌드 그대로 내고 있다면, BLA보다 먼저 앱 안에 박힌 키가 있는지부터, 그다음 깔리는 버전부터 확인해보길.
막는 장치는 나중에 붙여도 되지만, 앱에 박혀 나간 키는 이미 내 손을 떠난 거니까.