AI로 남의 앱을 역공학해도 될까요? rea와 한국 저작권법 2026 기준 5가지 상황 정리

AI로 남의 앱을 역공학해도 될까요? rea와 한국 저작권법 2026 기준 5가지 상황 정리

다른 앱 기능을 내 제품에 만들어 넣어도 되나요?

rea는 AI 에이전트가 실행 중인 앱이나 컴파일된 실행 파일을 역공학(완성된 프로그램을 거꾸로 뜯어 동작 원리를 알아내는 일)하도록 돕는 오픈소스 도구예요. 설치법보다 쓸모 있는 건 용도별 경계입니다.

공식 README에 따르면 첫 문단이 내세우는 용례는 이렇습니다. 한국어로 옮기면 "다른 앱에서 본 기능을 내 제품에 원하는가? 에이전트에게 rea로 조사해 달라고 하라."이고, 이어서 "당신 프로젝트를 위한 버전을 만들 수 있다"고 적혀 있어요. 그런데 저작권법 제101조의4는 역분석을 허용하는 목적을 호환성 확보로 좁혀 뒀습니다. 제2항 제2호는 대상 프로그램과 표현이 실질적으로 유사한 프로그램을 개발·제작·판매하는 데 얻은 정보를 쓰지 못하게 하고요. README 첫 문단의 마지막 단계는 이 조항과 정면으로 충돌할 수 있어요.

"경쟁사 앱 기능을 분석해서 우리 서비스에 넣어도 되나요?" "내가 돈 주고 산 프로그램인데 뜯어보는 것도 안 되나요?" 이런 질문이 먼저 떠오르는 게 자연스러워요. 구매했다고 다 되는 것도 아니고 전부 막힌 것도 아니라서, 조문의 요건을 하나씩 대 봐야 답이 나옵니다.

이 글은 rea의 구조와 설치 전제, 운영 위험을 먼저 짚고 5가지 상황별 위험도를 가려 봅니다. 공개된 조문과 공식 문서를 정리한 글이고 법률 자문이 아니에요. 구체적인 사안은 변호사에게 확인하세요.

rea는 소스 코드를 되돌려 주는 디컴파일러인가요?

아니요, 중개자에 가까워요. 자체 디컴파일 엔진(실행 파일을 사람이 읽을 코드로 바꾸는 장치)을 새로 만든 게 아니라 Hopper, Ghidra, IDA, JADX, JEB 같은 기존 역공학 도구를 AI 에이전트가 MCP(AI 에이전트가 외부 도구를 부르는 공통 규격)로 호출하도록 이어 줍니다. 공식 소개 문구도 "바이너리, 애플리케이션, 런타임 동작을 리버스 엔지니어링하는 하나의 MCP"예요.

Illustrations of the DX-Ball sound-pan, Notion clipboard-bridge, and TH04 bullet-ring showcases

이미지 출처: github.com

rea란?: Hopper, Ghidra 같은 기존 역공학 도구를 AI 에이전트가 MCP로 호출하게 연결하는 오픈소스 중개 서버예요. 돌려주는 것은 의사코드, 어셈블리, 문자열, 심볼, 호출 관계이고 컴파일되는 소스는 에이전트가 그 근거를 읽고 다시 작성해요.

비유하면 통역사죠. 에이전트는 Ghidra 조작법을 몰라요. Ghidra는 자연어를 몰라요. rea가 그 사이에서 "이 함수를 디컴파일해라" 같은 요청을 옮겨 줍니다.

의사코드는 원본처럼 보이게 복원한 코드 초안이고 심볼은 함수와 변수의 이름표예요. 공식 README는 에이전트가 후속 질문을 하고 동작을 설명한 뒤 "구현을 작성하고 테스트한다"고 적었어요. FAQ도 "당신의 에이전트가 이 발견들을 이용해 구현을 작성하고 테스트한다"고 답합니다. 원본 소스가 복원되는 게 아니라는 뜻이에요.

결과에는 근거가 붙어요. README는 "결과에는 각 결론의 근거와 한계가 포함된다"고 설명합니다. AI가 그럴듯한 추측을 사실처럼 말할 위험을 어셈블리 원문으로 대조할 수 있다는 게 이 설계의 장점이에요.

분석은 로컬에서 돌아요. FAQ는 "rea는 대상을 로컬에서 분석한다"고 밝히면서 도구 결과를 받는 에이전트의 모델 제공자는 자체 데이터 정책을 따른다고 덧붙입니다. 바이너리는 내 컴퓨터에 머물지만 분석 결과는 모델 제공자로 간다는 뜻이라, 고객사 파일을 다룬다면 이 구분이 중요해요.

규모도 큽니다. GitHub API 기준 2026-10-12 18:42 KST에 스타 127,172개, 포크 28,482개였고 리포 생성일은 2026-04-14(2026-10-12 기준 181일 전)입니다. 같은 날 구간별로 잰 증가 속도가 시간당 약 2,470개에서 2,980개라서 이 숫자는 몇 시간 안에 낡아요. 라이선스는 MIT예요.

설치하고 붙이려면 무엇이 필요한가요?

공식 README의 분석 대상 표는 17종이고 지원 클라이언트(rea를 붙일 수 있는 AI 에이전트 앱)는 별도로 18개예요. 두 숫자는 가리키는 대상이 다르니 섞지 마세요. 아래는 17종 중 실무에서 자주 만날 6종만 발췌한 표입니다.

진입 장벽이 낮은 쪽은 네이티브 바이너리가 아니에요. JavaScript/Electron과 .NET은 추가 엔진 없이 돌아요. 네이티브 바이너리만 Hopper, Ghidra, IDA 중 하나가 반드시 필요합니다. 공통 요구사항은 Node.js와 npm이에요. npm 패키지 메타의 engines 필드 기준 버전 범위는 ^22.19.0 || ^24.11.0 || >=26.0.0이니, 22.19 이상의 22.x, 24.11 이상의 24.x, 또는 26 이상이라는 뜻입니다.

설치는 한 줄로 시작해요.

npx rea-agents setup

공식 문서에 따르면 이 명령은 세 가지 일을 합니다.

• 선택한 클라이언트에 rea의 로컬 MCP 서버를 등록
• 짝이 되는 워크플로 지시문(스킬)을 설치
• 기존 설정을 백업

실행 뒤에는 에이전트를 재시작해야 해요. 승인 프롬프트가 변경 계획을 먼저 보여 주고 어느 단계에서든 취소할 수 있습니다. Claude Code라면 ~/.claude.json의 mcpServers.rea 항목에 서버가 등록되고 스킬은 ~/.claude/skills에 깔려요.

MCP 도구 목록의 입력 스키마(도구마다 받는 인자를 적은 명세)가 커서 호스트가 매번 전체를 넘기면 컨텍스트(AI가 한 번에 읽는 분량)를 많이 먹어요. 공식 문서는 env에 REA_MCP_INPUT_SCHEMA_PROFILE을 compact로 넣으면 스키마 전체를 13,312바이트 예산 안으로 줄여 준다고 안내합니다. 기본값은 full이고 서버가 시작할 때 읽으니 바꾼 뒤에는 재시작이 필요해요.

상용 도구 라이선스는 사용자 몫입니다. README는 "IDA Pro / Hex-Rays 디컴파일러, Hopper, JEB를 포함한 상용 도구는 반드시 적법하게 취득하고 사용 권한이 있어야 한다"고 못 박았어요. 무료로 시작하려면 미국 NSA가 공개한 Ghidra가 있죠.

정적 분석과 런타임 캡처는 위험도도 달라요. README는 "정적 JavaScript와 .NET 검사는 애플리케이션을 실행하지 않고 제공된 파일을 읽는다"면서 "런타임 캡처는 선택한 대상을 당신의 사용자 권한으로 실행하거나 상호작용한다"고 구분합니다.

개발자 커뮤니티는 이 도구를 어떻게 보나요?

Hacker News 메인 스레드는 2026-10-10에 올라와 2026-10-12 확인 시점에 776포인트, 327댓글을 받았어요(2026-10-12 기준 2일 전). 같은 프로젝트의 최초 Show HN(2026-07-14)은 3포인트에 댓글 0건이었으니, 그 게시물과 견주면 90일 만에 776포인트까지 간 셈입니다. 반응은 비전문가에게는 진입로, 전문가에게는 기존 도구를 감싼 껍데기(래퍼), 법무팀에게는 지뢰밭이라는 쪽으로 갈렸어요.

반복된 질문은 "그래서 Ghidra를 직접 쓰는 것과 뭐가 다른가"였어요. 사용자 ethin은 "내 현재 RE 방법론이 못 하는 게 뭔가"라고 물었습니다. djmips는 "Claude Code에서 직접 하는 것보다 낫다고 생각하지 않는다. 사실 더 나쁘다"고 썼어요.

반대 보고도 있었어요. none_to_remain은 역공학 경험 없이 느린 로컬 모델에게 Ghidra CLI로 디컴파일을 시켰다가 "완전히 길을 잃었다"고 했고, rea로 다시 돌리자 "뭔가 진전을 내고 있다"고 썼어요. 공식 README 쇼케이스에 따르면 DX-Ball 사운드 패닝 복원은 원본 x86 케이스 3,205개를 통과하고 컴파일된 함수 바이트 63개를 전부 재현했습니다. 다만 이건 프로젝트가 직접 내놓은 사례예요.

인접 사례 하나는 따로 떼어 둘게요. ashdnazg가 HN에 올린 DOS 게임 디컴파일 보고는 원문에 rea 언급이 없고 사용한 디컴파일러 이름도 밝히지 않았습니다. Watcom 컴파일러로 빌드된 쪽은 약 2주에 141개 함수 중 139개가 일치했고 Microsoft C로 빌드된 쪽은 약 2일에 일치에 도달했다는 내용이라, rea의 효과를 재는 수치로는 쓸 수 없어요. Reddit r/artificial에는 PS2 시대 게임을 하룻밤에 디컴파일했다는 제목의 글이 있지만, 본문과 점수를 확인하지 못해서 rea 사용 여부와 소요 시간 모두 미검증 커뮤니티 주장으로 둡니다.

저작권 우려는 댓글 327건 중 32건에 나왔어요. lifeisloving은 LLM을 거친 역공학이 클린룸(원본 코드를 보지 않은 팀이 따로 구현해 침해를 피하는 방식)이 아니라 "그냥 IP 세탁이다"라고 썼고, 스스로 "내 생각에는"이라고 단서를 붙였어요. 반대편 user43928은 "그런 주장을 하려면 입증 책임은 Adobe에 있지 않나"라고 맞받았습니다. 이 쟁점은 법적으로 풀리지 않았고 이 글도 결론을 내리지 않아요. HN은 댓글 점수를 공개하지 않아서 어느 쪽이 더 호응받았는지는 알 수 없습니다.

업무에 넣으면 가장 먼저 부딪히는 위험은 무엇인가요?

버전 변동성이 1순위예요. 릴리스는 2026-10-08에 6.0.0, 2026-10-09에 6.1.0·6.2.0·6.3.0, 2026-10-11에 6.4.0으로 4일간 5개였습니다. npm에는 첫 공개일 2026-07-12 이후 31개 버전이 올라와 있어요(2026-10-12 기준 92일). 6.2.0 릴리스 노트는 "rea의 always-bump-minor 정책은 breaking change를 포함한다. 6.2는 하위호환 약속이 아니다"라고 직접 경고합니다. 마이너 버전에도 기존 사용법이 깨지는 변경이 들어간다는 뜻이에요.

실제로 6.0.0에서는 MCP 파일시스템 입력이 절대 경로를 요구하게 바뀌어, 상대 경로 호출은 실패하고 /home/analyst/app 같은 형태로 보내야 해요. 6.3.0은 과거 캡처 데이터를 거부하고 재캡처를 요구했습니다.

설치 방식도 비판받았어요. 공식 홈페이지는 "이것을 코딩 에이전트에 복사해 넣으세요"라며 npx rea-agents@latest setup 실행을 안내해요. HN 사용자 mb7733은 "우리는 curl | bash 설치의 다음 진화를 달성했다"고 꼬집었습니다. 바로 아래에 직접 실행할 명령이 있고 설치 계획을 승인받는 구조라는 반론도 나왔죠. 다만 @latest 태그를 쓰는 한 실행할 때마다 내용이 바뀔 수 있다는 지적은 남아서, 업무 환경이라면 버전을 고정하는 쪽이 안전해요.

샌드박스(외부와 격리된 실험 공간)가 아니라는 점도 알아야 합니다. SECURITY.md는 "이것은 샌드박스가 아니며 같은 OS 사용자로 이미 실행 중인 악성 프로세스를 막지 못한다"고 밝혀요. Ghidra 세션은 격리된 임시 프로젝트를 쓰고 세션이 끝나면 지우지만, 문서는 이 통제도 우발적 영속성과 자원 사용을 제한할 뿐이라고 선을 긋습니다. 악성코드 분석에는 별도 격리 VM이 필요해요.

전송 표면도 확인해야 해요. 바이너리는 로컬에 머물지만 의사코드·문자열·심볼은 모델 제공자로 갑니다. 고객사 바이너리나 내부 시스템을 분석한다면 그 의사코드가 외부 벤더 서버로 나가는 것을 계약이 허용하는지 먼저 봐야 해요.

한국 저작권법은 역분석을 어디까지 허용하나요?

여기서부터는 공개된 조문과 해설을 정리한 내용이고 법률 자문이 아니에요.

한국 저작권법은 역분석을 금지하지 않아요. 대신 목적을 좁게 제한합니다. 핵심은 제101조의4(프로그램코드역분석)로, 2009-04-22 신설되어 2023-08-08 개정·시행됐어요(법률 제19592호). 제1항은 이렇게 허용합니다.

"정당한 권한에 의하여 프로그램을 이용하는 자 또는 그의 허락을 받은 자는 호환에 필요한 정보를 쉽게 얻을 수 없고 그 획득이 불가피한 경우에는 해당 프로그램의 호환에 필요한 부분에 한정하여 프로그램의 저작재산권자의 허락을 받지 아니하고 프로그램코드역분석을 할 수 있다."

제2항은 역분석으로 얻은 정보를 다음 경우에 쓰지 못하게 해요.

"1. 호환 목적 외의 다른 목적을 위하여 이용하거나 제3자에게 제공하는 경우 2. 프로그램코드역분석의 대상이 되는 프로그램과 표현이 실질적으로 유사한 프로그램을 개발·제작·판매하거나 그 밖에 프로그램의 저작권을 침해하는 행위에 이용하는 경우"

요건은 네 가지이고 모두 충족해야 해요.

1. 주체: 정당한 권한으로 프로그램을 이용하는 자 또는 그의 허락을 받은 자. 한국저작권위원회 상담사례 정리에 따르면 라이선스를 받은 자나 구매한 자가 해당하고, 불법 복제물 소지자는 허용되지 않아요.
2. 입수 곤란: 호환에 필요한 정보를 쉽게 얻을 수 없어야 해요. 공개 API 문서가 있으면 이 요건이 깨집니다.
3. 불가피성: 그 정보를 얻는 것이 불가피해야 해요.
4. 범위: 호환에 필요한 부분에 한정해야 해요. 전체 디컴파일은 범위를 넘습니다.

"내가 산 소프트웨어니까 뜯어봐도 된다"는 오해예요. 구매는 1번 요건만 채워 줍니다. 나머지 세 요건과 호환 목적이 따로 필요해요. 제2항 제2호는 경쟁 제품의 기능을 역공학해 비슷한 제품을 만드는 행위 유형을 직접 겨냥하는 조항입니다. rea 홈페이지와 README가 내세우는 대표 용례가 바로 여기에 걸릴 수 있어요.

함께 봐야 할 조문이 둘 있어요.

• 제104조의2는 DRM이나 라이선스 확인 같은 기술적 보호조치를 정당한 권한 없이 무력화하는 것을 금지합니다(2011-06-30 신설, 2024-08-28 시행). 제1항에 예외가 8호 있고, 그중 제6호는 "다른 프로그램과의 호환을 위하여 필요한 범위에서 프로그램코드역분석을 하는 경우"를, 제7호는 "오로지 컴퓨터 또는 정보통신망의 보안성을 검사·조사 또는 보정하기 위하여 필요한 경우"를 허용해요. 제7호는 한국에도 보안 연구 예외가 있다는 뜻이지만 "정당한 권한을 가진 자"와 "오로지" 보안성 검사 목적이라는 두 제약이 붙어서, 허가 없는 제3자 시스템 분석에는 쓸 수 없어요.
• 제101조의5는 복제물의 멸실·훼손·변질에 대비한 복제를 필요한 범위에서 허용하므로 자사 레거시 보존의 근거가 될 수 있어요.

EULA(사용권 계약)에 디컴파일 금지 조항이 있으면 어떻게 되는지는 확인하지 못했어요. EU와 달리 한국법에서 이에 상응하는 명시적 조항을 찾지 못했고, 확정적 근거도 없어서 불확실한 영역으로 남깁니다. 금지 조항이 있다면 계약 위반 위험을 따로 계산하는 쪽이 안전해요.

미국과 EU는 어떻게 다른가요?

미국 DMCA 제1201조는 접근통제 우회를 금지하면서 역공학, 암호 연구, 보안 테스트 등을 영구 법정 예외로 둬요. 여기에 3년마다 임시 예외를 갱신하는 삼년주기 규칙제정이 더해집니다. 9차 절차의 최종규칙은 2024-10-25 발표되어 2024-10-28 발효됐고 선의의 보안 연구 예외가 갱신됐어요. 반면 생성형 AI 플랫폼의 접근통제를 우회해 편향을 연구하자는 "AI 신뢰성 연구" 예외 청원은 거부됐습니다. 저작권청 관계자는 정책 판단이 아니라 범위 문제라며 "그것은 단지 제1201조의 범위에 속하지 않는다"고 설명했어요.

EU 소프트웨어 지침(2009/24/EC) 제6조는 독립적으로 만든 프로그램과의 상호운용성에 필요한 정보를 얻는 디컴파일을 허용해요. 누적 요건 세 가지가 한국 제101조의4와 구조가 거의 같습니다. 다른 점은 제8조 제2항이에요. 제6조와 제5조 제2항·제3항에 어긋나는 계약 조항은 무효라서, EULA에 금지 조항이 있어도 제6조 권리는 남아요. 다만 이 보호는 그 세 조항에만 미칩니다. 오류 수정 목적 디컴파일을 인정한 Top System(C-13/20) 판결의 근거는 제5조 제1항인데, 이 조항은 무효 보호 목록에 없고 "특정 계약 조항이 없는 경우"를 전제로 해서 계약으로 제한될 수 있어요. 전문(recital)을 근거로 반대하는 학설이 있어 이 지점은 논쟁 중입니다.

자주 섞이는 두 판결은 따로 봐야 해요. Sony 대 Datel(C-159/23, 2024-10-17 판결)은 콘솔 RAM의 가변 데이터 내용이 프로그램을 복제하거나 이후에 창작할 수 있게 하지 않는 한 지침의 보호 범위 밖이라고 본 사건이에요. 기능이나 프로그래밍 언어, 데이터 파일 형식이 저작권 보호 대상이 아니라는 법리는 그보다 앞선 SAS Institute 대 World Programming(C-406/10)에서 나왔습니다. Datel 판결을 기능 모방과 표현 복제의 근거로 쓰면 부정확해요.

내 상황은 어느 쪽에 해당하나요?

같은 도구라도 목적에 따라 위험도가 크게 달라요. 아래는 위 조문과 규칙을 기준으로 5가지 상황을 정리한 표이고, 개별 사안의 결론이 아닙니다.

표에 없는 세 가지도 짚어 둘게요. 악성코드·침해사고 분석은 중간이에요. 분석 자체의 정당성은 넓게 인정되지만, 샌드박스가 아닌 환경에서 실행하면 보안 사고가 됩니다. 제3자 상용 소프트웨어를 통째로 디컴파일하는 건 높음이에요. "호환에 필요한 부분에 한정" 요건에 어긋나고 EULA 금지 조항이 있으면 계약 위반 위험이 더해지는데, 한국에서 그 효력 범위는 확정하지 못했습니다. DRM·라이선스 확인·안티치트 우회는 매우 높음이고 제104조의2 제1항 본문에 걸려요.

프로젝트 쪽 입장도 참고가 됩니다. DISCLAIMER.md는 지원하지 않는 용도 6종을 열거해요. 기술적 보호조치 우회, 게임 치트 개발과 온라인 서비스 조작, 권한 없는 시스템의 접근통제 우회, 독점 소프트웨어 복제나 보호되는 코드·에셋 재생산, AI 모델 제공자의 이용정책 회피, AI 계정·API 접근 재판매와 공유입니다. 문서는 "소프트웨어의 공개 입수 가능성, 파일의 소지, 디버깅 엔드포인트 접근 가능성만으로는 모든 작업에 대한 허가가 성립하지 않는다"고 못 박아요. 법적 방어선으로는 한계가 있어도, 분쟁이 나면 사용자 책임을 가리키는 근거로 인용될 수 있습니다.

공표 위험은 커뮤니티에서도 나왔어요. ArtCraft 앱을 만드는 echelon은 자기 팀이 클린룸으로만 작업하며 "Adobe 소스를 볼 수 없고 Ghidra 사용이 금지된다"고 썼습니다. rea는 개인 앱과 abandonware(방치된 구형 소프트웨어)에 맞겠지만 "결과를 공표하고 발견되면 문제가 될 것"이라고 내다봤어요.

쓰기 좋은 자리는 분명해요. 소스를 잃은 내부 도구, 퇴사자가 남긴 빌드 산출물, 벤더가 폐업한 업무 시스템은 수작업으로는 비용이 안 맞아 방치되던 영역이라 효용이 커요. 배포한 앱에 하드코딩된 키가 노출되는지, 난독화가 실제로 작동하는지 보는 점검은 JADX와 JDK만 있는 Android APK 경로라 상용 라이선스 부담도 없습니다. 교육과 CTF(보안 실력 겨루기 대회)는 DISCLAIMER도 적법 용도로 명시하는 영역이에요.

도입한다면 무엇부터 점검해야 하나요?

분석을 시작하기 전에 던질 질문 3개부터 보세요.

• 이 바이너리의 저작권이 우리에게 있나요? 외주 개발물이라면 계약서의 귀속 조항부터 확인해요.
• 목적이 호환성 확보나 보안성 검사에 해당하나요? 다른 제품의 기능을 가져오는 목적이라면 제101조의4 제2항 제2호와 부딪힐 수 있으니 변호사 확인이 먼저예요.
• 분석 결과나 파생 코드를 외부에 내보내나요? 공표와 배포 단계에서 위험이 커져요.

기술 체크리스트는 5개입니다.

1. 버전을 고정해요. @latest 대신 rea-agents@6.4.0처럼 명시 버전을 쓰세요. 4일에 5개가 나오는 속도에다 마이너에도 breaking change가 들어가기 때문이에요.
2. Node 버전을 먼저 맞춰요. 22.19 이상의 22.x, 24.11 이상의 24.x, 또는 26 이상이어야 합니다.
3. 엔진을 먼저 정해요. 네이티브 바이너리라면 Ghidra로 시작하고, Hopper와 IDA는 라이선스를 적법하게 확보한 뒤에 쓰세요.
4. 컨텍스트 예산을 관리해요. REA_MCP_INPUT_SCHEMA_PROFILE=compact로 13,312바이트 예산에 맞추고 재시작합니다.
5. 격리 환경을 나눠요. 신뢰할 수 없는 대상은 전용 VM에서 열고, 같은 OS 사용자로 돌리면 보호 장치가 없다고 생각하세요.

마무리

rea는 도구보다 용도가 문제예요. 자사 자산을 복원하고 점검하는 자리는 위험이 낮고, 다른 회사 제품의 기능을 가져오는 자리는 저작권법 제101조의4 제2항 제2호와 부딪힐 수 있습니다. 어디서부터 손대야 할지 막막하다면 분석하려는 대상 하나를 골라 "내 것인가, 목적이 호환이나 보안인가" 두 줄만 먼저 적어 보세요. 그 두 줄이 시작점입니다.

자주 묻는 질문

내가 구입한 소프트웨어는 rea로 분석해도 되나요?

구매만으로는 부족해요. 저작권법 제101조의4에서 구매는 주체 요건 하나만 채워 줍니다. 입수 곤란, 불가피성, 범위 한정 3개 요건과 호환 목적이 따로 필요하니, 구체적인 사안은 변호사에게 확인하세요.

rea가 Ghidra를 직접 쓰는 것보다 나은가요?

숙련도에 따라 갈려요. Hacker News 메인 스레드(2026-10-12 확인 기준 776포인트, 327댓글)에서 djmips는 직접 하는 쪽이 낫다고 봤고, none_to_remain은 경험 없이 로컬 모델에 Ghidra를 맡겼다가 길을 잃은 뒤 rea로 진전을 봤다고 썼어요. 전문가에게는 래퍼로, 입문자에게는 진입로로 보인다는 뜻입니다.

분석하는 파일이 외부로 업로드되나요?

바이너리는 올라가지 않지만 분석 결과는 나갑니다. 공식 FAQ는 "rea는 대상을 로컬에서 분석한다"고 답하고 모델 제공자는 자체 데이터 정책을 따른다고 덧붙여요. 의사코드와 문자열이 모델 제공자로 전송되니, 고객사 바이너리라면 계약이 허용하는지 먼저 확인하세요.

참고자료

• morluto/rea 리포 메타 (GitHub API, 2026-10-12)
• rea README.md
• rea README_ko.md
• Release rea-agents-6.4.0 (2026-10-11)
• Release rea-agents-6.2.0 (2026-10-09)
• Release rea-agents-6.0.0 (2026-10-08)
• npm rea-agents 패키지 메타
• docs/installation.md
• docs/mcp-contracts.md
• DISCLAIMER.md
• SECURITY.md
• rea.tools 공식 홈페이지
• Hacker News 메인 스레드 (2026-10-10)
• Hacker News 최초 Show HN (2026-07-14)
• 저작권법 제101조의4 (시행 2023-08-08)
• 저작권법 제104조의2 (시행 2024-08-28)
• 법제처 생활법령정보: 프로그램코드역분석 해설
• 미국 연방공보: DMCA 제1201조 9차 최종규칙 (2024-10-28)
• 미국 저작권청장 권고문 (2024-10-25)
• Cuatrecasas: Top System 판결 해설
• EU 지침 2009/24/EC 원문 (EUR-Lex)
• Jones Day: Sony v Datel 판결 해설