REA 이후의 질문: REA-Prompts와 ANTI-REA, 분석과 보호를 검증하는 법

AI가 기존 프로그램을 이해하도록 돕는 도구가 등장하면, 다음 질문은 두 갈래로 이어집니다. 분석을 어떻게 더 정확하게 요청할 것인가? 그리고 내가 만든 프로그램의 핵심 동작은 어떻게 보호할 것인가?

앞선 REA 소개 글에서는 에이전트와 분석 엔진을 연결하는 구조, 그리고 관찰과 추론을 구분해야 하는 이유를 살펴봤습니다. 이번에는 그 다음 단계에 있는 두 공개 저장소를 함께 읽습니다. REA-Prompts는 조사할 질문을 구체화하고, ANTI-REA는 보호 도구의 실행과 검증을 연결하려는 프로젝트입니다.

두 저장소를 단순한 ‘공격과 방어의 승부’로 읽으면 중요한 부분을 놓칩니다. 좋은 질문은 분석의 정확도를 보장하지 않고, 보호 파일이 만들어졌다고 역공학 저항성이 입증되는 것도 아닙니다. 두 프로젝트의 가치는 무엇을 했고 무엇을 아직 확인하지 못했는지 기록하는 방식에서 평가해야 합니다.

이 글은 2026년 10월 20일 공개 문서와 특정 커밋의 소스를 정적으로 검토한 분석입니다. MCP 서버 설치, 대상 바이너리 실행, 보호 엔진 적용이나 공격 재현은 수행하지 않았습니다. 아래의 실행 경로 관찰은 해당 코드에서 확인한 조건이며, 실제 제품 전체에 대한 성능 시험이나 보안 인증 결과가 아닙니다.

핵심 답변: REA-Prompts와 ANTI-REA는 무엇이 다른가요?

REA-Prompts는 분석 요청을 구체화하는 질문 모음이고, ANTI-REA는 보호 작업과 비교·검증을 연결하는 실험 프로젝트입니다. 질문 모음을 받는 것과 분석 엔진을 준비하는 것, 보호 파일을 만드는 것과 보호 효과를 입증하는 것은 각각 다른 단계입니다. REA-Prompts 검토 버전, ANTI-REA 보호 코드

공식 소스에서 작업 완료 상태를 읽을 때는 다음 세 질문으로 나누면 판단하기 쉽습니다.

1. 적용: 선택된 후보가 어떤 파일이며, 원본과 무엇이 달라졌는가?
2. 동작: 어떤 입력과 출력·종료 코드를 비교했고, 그 밖의 기능은 어떻게 확인할 것인가?
3. 비용과 효과: 실행 시간·크기 변화와 분석 저항성을 별도로 평가했는가?

이 글의 사례는 고정 커밋의 실행 분기를 읽은 정적 검토입니다. 보호 엔진을 실행한 성능 시험으로 바꾸어 해석하지 않습니다. 직접 실험을 준비할 때는 평가 기준표 작성법과 정상·경계·오류 사례를 나누는 회귀 검사를 함께 활용할 수 있습니다.

세 프로젝트의 역할부터 구분하기

역공학은 이미 만들어진 프로그램의 구조와 동작을 조사하는 일입니다. 소스를 잃어버린 자체 프로그램을 이해하거나 파일 형식의 호환성을 확인할 때도 사용합니다. 분석 도구와 질문 모음, 보호 도구를 분리하면 입문자가 무엇을 준비해야 하는지 알기 쉽습니다.

구분	REA	REA-Prompts	ANTI-REA
주된 역할	에이전트가 분석 엔진과 근거에 접근하는 도구 계층	분석 목적·범위·제출 결과를 정하는 질문 모음	보호 작업의 계획·실행·비교를 연결하는 도구와 실험 코드
독자가 만나는 형태	CLI·로컬 MCP 서버와 워크플로	README의 텍스트 템플릿	Python 패키지·MCP/CLI·보호 파이프라인
핵심 질문	이 프로그램은 어떻게 동작하는가?	어느 기능을 어떤 근거로 설명할 것인가?	무엇을 보호했고 기능·비용·저항성은 어떻게 달라졌는가?
별도 확인할 것	대상 형식에 맞는 분석 엔진·권한·실행 환경	REA 연결 상태·질문의 적합성·결과의 근거	보호 엔진·지원 대상·적용 증거·독립적인 평가

REA-Prompts는 REA를 활용하는 별도의 질문 모음이고, ANTI-REA는 REA를 분석 위협의 한 예로 제시합니다. 두 저장소가 같은 팀의 공식 제품군이거나, 서로를 대상으로 독립적인 비교 시험을 마쳤다는 근거는 이번 검토에서 확인하지 못했습니다. REA-Prompts README, ANTI-REA README

REA-Prompts: ‘전부 분석해 줘’를 조사 가능한 질문으로 바꾸기

확인한 REA-Prompts 커밋의 파일 트리는 README 한 개로 구성됩니다. 별도의 분석 엔진이나 MCP 서버를 제공하는 패키지가 아닙니다. REA와 에이전트가 준비된 환경에서 요청을 구체화하는 자료에 가깝습니다.

README는 설치 확인부터 기능 추적, 네이티브 바이너리, Android, Electron, 버전 비교와 장시간 조사까지 0번부터 16번까지 17개 주제 묶음을 제공합니다. 모든 주제에 대해 실제 분석 능력이 새로 생긴다는 뜻은 아닙니다. 결과는 연결된 도구, 대상 파일과 에이전트의 작업 품질에 달려 있습니다.

입문자가 먼저 볼 만한 부분은 CSV 내보내기 예제와 단일 기능 추적입니다. 버튼에서 파일 생성까지 흐름을 좁히고, 어느 파일과 함수가 각 설명의 근거인지 요청합니다. 또 확인된 사실·추론·모르는 점을 나누고, 정적 조사 단계에서는 프로그램을 실행하지 않도록 범위를 정합니다. 검토한 README

다음은 이 접근을 자체 프로젝트 조사에 맞게 새로 구성한 요청 예시입니다.

내가 개발한 메모 앱에서 ‘CSV 내보내기’ 기능 하나만 조사해 주세요.
이번 단계에서는 앱을 실행하지 말고 소스와 준비된 분석 결과만 읽어 주세요.
입력 → 변환 → 파일 저장의 흐름을 설명하고, 각 주장 옆에 파일과 함수를 적어 주세요.
확인된 사실 / 추론 / 추가 확인이 필요한 항목을 구분해 주세요.
마지막에 실제 실행으로 검증할 테스트 세 가지를 제안해 주세요.

이 형식의 장점은 답변을 읽고 반박하거나 확인할 수 있다는 점입니다. 다만 근거를 요구하는 문장만으로 환각이 사라지지는 않습니다. 인용한 함수가 존재하는지, 그 함수가 실제 실행 경로에 포함되는지, 출력이 예상과 맞는지는 별도로 대조해야 합니다.

저장소에는 취약점·보호 장치 연구를 다루는 주제도 있습니다. 교육용 소개에서는 이를 무단 우회 절차로 확장하기보다, 직접 소유하거나 명시적으로 분석을 허가받은 대상의 기능 이해·패치 비교·보호 점검으로 범위를 정하는 편이 목적과 결과를 명확하게 만듭니다.

ANTI-REA: 보호 엔진과 검증 작업을 연결하는 MCP

ANTI-REA의 목표는 에이전트가 핵심 함수와 주변 단서를 파악하고, 난독화나 VM 방식의 보호를 적용한 뒤 기능과 비용을 비교하도록 돕는 것입니다. MCP는 이 작업을 외부 에이전트에서 호출하는 통로입니다. 프로젝트 자체가 새로운 언어 모델인 것은 아닙니다.

난독화는 프로그램의 동작을 유지하면서 구조를 읽기 어렵게 만드는 방법입니다. 여기서 VM 보호는 선택한 로직을 별도의 명령 체계와 실행기로 처리하는 소프트웨어 보호 방식입니다. 가상 머신에 운영체제를 설치하는 작업과는 쓰임이 다릅니다.

기본 안내는 환경을 진단하는 protection_doctor, 입력과 명령을 기록하는 protection_plan, 계획을 실행하는 protection_protect 순서입니다. 소스에는 프로젝트 생성, 자동 보호, 벤치마크를 위한 별도 호출도 있습니다. 따라서 설명용 기본 흐름과 실제 호출 가능한 전체 기능을 구분해야 합니다.

단일 함수만 감추면 호출하는 함수나 상수에서 단서가 남을 수 있다는 문제의식도 담고 있습니다. 관련 문서의 LLVM IR은 컴파일러가 사용하는 중간 표현입니다. 이를 통해 호출 관계와 주변 함수를 살피는 경로를 설명하며, LLM의 추론 기록이나 ‘LLM IR’이라는 뜻이 아닙니다. 공식 개요, 범위 분석 코드

현재 지원과 최종 로드맵은 다릅니다

ANTI-REA 소개에서 가장 주의해서 읽을 부분입니다. README의 광범위한 언어·플랫폼 목록은 최종 목표에 포함돼 있습니다. 현재 검증 범위를 그 목록 전체로 확대해서 해석하면 안 됩니다. 상용 엔진 표는 Themida, VMProtect, Code Virtualizer를 가리킵니다. .NET, Java/Kotlin, JavaScript/Electron, Python, macOS는 최종 다중 대상 로드맵에 포함됩니다.

항목	공식 문서에서 확인되는 상태	도입할 때의 해석
내장 ANTI-REA Engine	Windows x86-64 C++ 중심의 자동 검증과 실험 파이프라인 설명	내 프로그램의 빌드 방식과 보호 대상에 적용되는지 별도 확인
상용 엔진 3종	Windows 네이티브 x86/x64 PE용 어댑터 구현 안내	해당 도구의 로컬 설치·에디션·라이선스·프로젝트 설정 필요
다중 언어·OS	최종 다중 대상 방어 로드맵에 포함	현재 모두 보호 가능하다는 지원 보증으로 읽지 않기
‘25%’ 진행 표시	자체 TestApp 실험을 바탕으로 저자가 정의한 방어 단계	보편적인 공격 차단율이나 독립 인증 점수로 해석하지 않기

첫 실험 안내에는 Python 3.11 이상 외에도 Windows C++ 개발 도구, Windows SDK, CMake/Ninja, JDK와 로그인된 에이전트 CLI 등이 등장합니다. Python 패키지의 의존성 목록이 짧다고 전체 보호·평가 환경도 가볍게 설치되는 것은 아닙니다. 상용 엔진을 연결하면 엔진 비용과 별도의 사용 조건도 남습니다. 실행 환경 안내

소스에서 확인한 네 가지 검토 지점

아래 내용은 검토 커밋의 antirea/protectors.py와 MCP 도구 정의를 읽은 결과입니다. 하나의 함수에서 관찰한 조건을 모든 경로의 공통 동작으로 일반화하지 않도록, 해당 경로를 함께 적었습니다.

1. 계획의 지문 확인과 사람의 승인은 구분해야 합니다

개별 protect() 경로는 계획 지문과 입력·프로젝트·도구의 해시를 확인합니다. 원본의 복사본으로 작업하고 실행 이후 무결성을 기록하는 장치도 있습니다. 계획 이후 파일이 바뀌었는지 확인하는 데 의미가 있습니다.

하지만 generate_project()는 설정된 공급자의 승인 목록에 생성 프로젝트의 해시를 추가할 수 있고, auto_protect()는 만들어진 계획의 지문을 직접 전달해 보호를 실행합니다. 이 자동 경로에 매번 별도의 사람이 확인하는 절차가 강제돼 있다고 설명할 수는 없습니다. 에이전트에게 승인 정책을 부여하고 호출 가능한 도구를 제한하는 운영 설계가 별도로 필요합니다. 해시는 계획의 동일성을 확인하는 값이며, 사람의 의도를 확인한 증명은 아닙니다.

2. 내장 엔진 자동 경로에서 원본이 비교 대상으로 돌아올 수 있습니다

검토한 auto_protect()의 내장 엔진 분기는 _locate_kagura_candidate()로 기존 후보 파일을 찾습니다. 이 함수는 정해진 후보 파일을 찾지 못하면 원본 경로를 반환합니다. 따라서 이 분기만으로 매번 새로운 보호 파일을 생성한다고 볼 수 없으며, 조건에 따라 원본과 원본이 비교될 수 있습니다.

출력 일치나 속도 숫자만 보고 보호가 적용됐다고 판단하면 잘못된 결론에 도달할 여지가 있습니다. 실제로 어떤 파일이 선택됐는지, 원본과 후보의 해시가 무엇인지, 의도한 함수가 변환됐다는 별도 증거가 있는지를 함께 봐야 합니다. 다른 빌드·방어 루프가 존재한다는 사실과, 이 자동 호출의 분기가 무엇을 하는지는 구분해야 합니다.

3. 기능 비교는 제공한 입력과 관찰 항목의 범위 안에서만 유효합니다

benchmark()는 테스트 입력별 표준 출력과 종료 코드를 비교합니다. 기본 입력도 제공하지만, 이것이 임의의 GUI 앱·네트워크 기능·파일 변경·전체 입력 공간을 검증해 주는 것은 아닙니다. 성능 반복 측정에는 입력 목록의 첫 번째 항목을 사용합니다.

따라서 보고서의 ‘100% 일치’는 제공한 사례와 비교 항목에서의 일치로 읽어야 합니다. 실사용에서는 오류 입력, 경계값, 큰 입력, 실제 작업 부하와 부작용까지 별도의 테스트로 확인하는 편이 타당합니다.

4. 완료 상태와 속도 목표 통과는 별도 항목입니다

개별 보호 작업의 산출물 상태는 artifact_created_unvalidated로 구분됩니다. 파일이 만들어졌지만 추가 검증이 필요하다는 뜻입니다. 자동 경로에서는 기능이 일치하면 completed가 반환될 수 있고, 속도 목표 달성 여부는 meets_speed_target에 따로 담깁니다.

이 구조에서는 ‘completed’를 그대로 ‘보호 효과·속도·배포 준비 모두 통과’로 번역하면 안 됩니다. 기능 일치, 속도 목표, 실제 보호 범위, 외부 분석에 대한 저항성을 각각 읽어야 합니다. 보호·자동화·벤치마크 코드, MCP 도구 정의

‘원래 속도의 80%’는 얼마나 느려진다는 뜻일까

README의 80%는 사용자가 지정하는 목표 예시입니다. 모든 프로그램에서 달성했다는 보장 수치가 아닙니다.

벤치마크 코드의 기본 계산은 같은 작업에 대한 원본 실행 시간 ÷ 보호 후보 실행 시간 × 100입니다. 예를 들어 원본이 100ms, 후보가 125ms라면 속도는 원본의 80%이며 걸리는 시간은 25% 늘어납니다. ‘속도 80% 유지’를 ‘실행 시간 20% 증가’라고 쓰면 계산이 맞지 않습니다.

또 해당 구현은 속도 표시를 최대 100%로 제한합니다. 숫자가 100%라고 해서 두 시간이 정확히 같다는 뜻은 아닙니다. 원본·후보의 중앙 실행 시간, 반복 횟수, 입력과 파일 크기도 함께 읽어야 합니다.

실제 도입 비교에서는 같은 기기·빌드 옵션·작업 부하를 고정하고, 준비 실행과 여러 번의 측정을 거쳐 지연 시간의 변동도 확인해야 합니다. 보호 강도를 낮춰 속도 목표를 맞췄다면, 그 설정에서도 필요한 로직이 보호되는지 다시 확인해야 합니다.

두 저장소를 함께 평가하는 현실적인 방법

두 프로젝트를 읽고 얻을 수 있는 실무적인 방향은 분석과 보호 양쪽에 확인 가능한 산출물을 요구하는 것입니다. 직접 만든 작은 프로그램의 규칙 하나를 대상으로 하면 비교의 범위를 통제하기 쉽습니다. 다음은 실행 결과가 아니라 도입을 검토할 때 사용할 평가 순서입니다.

순서	남길 기록	판단할 질문
1. 기준선 준비	원본 파일 해시·빌드 설정·정답 사례·성능 기준	무엇을 보존해야 하는가?
2. 무보호 분석	동일한 질문·분석 도구·시간 예산·근거 보고서	보호 전에는 어느 정도까지 설명 가능한가?
3. 보호 적용 확인	후보 해시·선택한 함수·엔진·적용 범위 증거	새 보호 산출물이 실제로 만들어졌는가?
4. 동작과 비용 비교	정상·경계·오류 사례, 출력과 부작용, 시간과 크기	기능이 유지됐고 비용을 감당할 수 있는가?
5. 보호 후 분석	원본 소스를 주지 않은 동일 조건의 조사 기록	단순히 설명이 길어졌는가, 검증 가능한 복원 능력이 줄었는가?

보호 평가자는 분석자에게 정답 소스나 비공개 테스트를 넘기지 않아야 비교 의미를 지키기 쉽습니다. 동시에 분석 실패를 보고할 때도 예산 소진, 도구 미지원, 실제 보호 효과를 나눠 기록해야 합니다. 제한 시간 안에 답을 못 얻었다는 사실만으로 영구적인 분석 불가능을 증명할 수는 없습니다.

ANTI-REA는 별도 REA 환경과 TestApp을 이용한 반복 평가를 설명합니다. 이는 프로젝트의 실험 방향을 보여주지만, 모든 형식과 모든 공격자를 상대로 한 독립 검증 결과로 확대할 수 없습니다. REA-Prompts 역시 질문 범위를 넓게 다룬다는 사실과 그 질문이 각 대상에서 성공한다는 사실은 다릅니다.

이 관점에서 REA-Prompts는 조사 요청의 품질을 점검할 자료, ANTI-REA는 보호 자동화의 설계와 검증 조건을 검토할 실험 프로젝트로 접근하는 것이 적절합니다. 바로 운영 프로그램에 적용하기보다, 복구 가능한 자체 샘플에서 평가 계약을 먼저 만드는 편이 결과를 해석하기 쉽습니다.

자주 묻는 질문

Q1. REA-Prompts만 내려받으면 분석을 시작할 수 있나요?

질문 텍스트만으로 분석 엔진이 설치되지는 않습니다. REA와 호환 에이전트, 대상에 맞는 도구가 필요합니다. 예제의 설치 요청을 붙여 넣으면 실제 설치 행동으로 이어질 수 있으므로, 조사할 때는 텍스트를 읽는 단계와 실행하는 단계를 구분하세요.

Q2. ANTI-REA를 쓰면 AI가 프로그램을 복제할 수 없나요?

그렇게 보장할 근거는 확인하지 못했습니다. 프로젝트도 단계별 목표를 제시합니다. 적용 범위·동작 보존·비용과 별도로, 제한된 조건에서 분석 난도가 얼마나 달라지는지 측정해야 합니다.

Q3. macOS나 Python 앱에도 지금 바로 같은 방식으로 쓸 수 있나요?

현재 README의 검증 중심은 Windows 네이티브 경로입니다. 최종 로드맵의 언어·플랫폼 목록을 현재 지원 범위로 해석하지 마세요. MCP 서버를 실행할 수 있는 환경과 실제 보호 대상의 호환성도 서로 다른 문제입니다.

Q4. 두 저장소는 무료로 사용할 수 있나요?

ANTI-REA는 MIT 라이선스 파일을 제공하고, REA-Prompts는 README에서 프롬프트를 MIT로 안내합니다. 다만 에이전트 모델 이용료, 분석 도구와 상용 보호 엔진 비용은 별도입니다. 대상 프로그램을 분석·수정할 권한도 이 저장소들의 라이선스가 부여해 주지 않습니다.

Q5. 이 사이트에서 두 도구의 성능을 직접 시험했나요?

아닙니다. 이 글은 고정 커밋의 문서·파일 구성·실행 분기를 읽은 정적 검토입니다. 수치 예시는 계산을 설명하기 위한 것이며, 자체 보호·공격 벤치마크 결과가 아닙니다.

공식 자료와 확인 기준일

확인 기준일: 2026-10-20

ANTI-REA는 커밋 84c4b87a4da583acd30d060bbf01f73ce1e30739, REA-Prompts는 커밋 bdc198d280bb89369c028088aa79a15274f22bda를 기준으로 검토했습니다. 이후 수정되면 자동 승인·후보 선택·상태 반환 등 구현 세부 사항은 달라질 수 있습니다.

• ANTI-REA 공식 저장소: 프로젝트 목표, 현재 방어 단계와 엔진 안내.
• ANTI-REA 보호 실행 코드: 계획 지문, 자동 프로젝트 등록, 후보 선택, 기능·속도 비교.
• ANTI-REA MCP 정의: 호출별 입력과 기능의 경계.
• ANTI-REA 실험 준비 문서: Windows C++ 보호·평가 환경과 준비 조건.
• ANTI-REA 라이선스: 저장소 코드의 이용 조건.
• REA-Prompts 검토 버전: 주제별 질문과 근거·범위 지침, README의 라이선스 안내.
• REA 공식 사이트: 분석 도구의 제품 안내. 두 후속 저장소의 독립적인 성능 보증을 뜻하지 않습니다.

관련 글: REA의 분석 구조와 근거를 읽는 법 · ARTEX 공개 저장소를 검토할 때 확인한 점