Claude Code로 앱을 리버스 엔지니어링하는 방법

리버스 엔지니어링이란 완성된 소프트웨어를 연구해 그것이 어떻게 작동하는지 이해하는 것을 말하며，보통 원본 소스 코드나 그것을 만드는 데 쓰인 설계 문서 없이 이루어진다. 그것이 무엇을 하는지，어떻게 구성되어 있는지，무엇과 통신하는지를 살펴보고，거기서부터 거꾸로 거슬러 올라가 그 동작의 모델을 만든다.

사람들이 이것을 하는 이유는 대부분 화려하지 않고，대부분 정당하다. 보안 연구자는 더 나쁜 의도를 가진 사람이 먼저 취약점을 찾기 전에 그것을 찾아내려고 프로그램을 리버스 엔지니어링한다. 개발자는 아무도 자신들을 위해 문서화해주지 않는 오래된 프로그램과 새 프로그램이 상호운용되게 하려고 파일 형식과 네트워크 프로토콜을 리버스 엔지니어링한다. 아카이브 작업자와 취미로 하는 사람들은 원본 하드웨어와 그 뒤의 회사가 둘 다 사라진 뒤에도 오래된 소프트웨어를 계속 돌리기 위해 리버스 엔지니어링한다. 그리고 때로는 그 이유가 단순히，의존하고 있는 프로그램이 문서화되지 않은 무언가를 하고 있어서，그것을 신뢰하거나 우회하기 전에 그게 무엇인지 알아야 하기 때문이다.

이 중 새로운 것은 없다. 보안 연구자와 소프트웨어 아카이브 작업자는 AI 에이전트가 존재하기 훨씬 전부터 디스어셈블러와 디버거를 가지고 수십 년간 이 일을 해왔다. 바뀐 것은 속도다：에이전트는 숙련된 사람이 몇 시간씩 걸리던 일을，디스어셈블리 목록이나 디컴파일된 메서드를 읽고 몇 초 안에 요약할 수 있다. 이것은 실제 역량의 향상이며，바로 그래서 이 가이드 뒤에 나오는 법적，윤리적 경계가 지금 더 덜 중요해지는 게 아니라 더 중요해진다，호기심과 복제 사이에서 사람들을 늦추던 그 걸림목이 거의 사라졌기 때문이다.

이 가이드의 나머지 부분은 구체적이다：Claude Code 같은 에이전트를 이런 종류의 분석에 연결해주는 REA라는 도구 하나를 다루고，그것을 무엇에든 쓰기 전에 갖춰둘 만한 습관들을 다룬다.

여기서 가장 중요한 구분은 무언가가 어떻게 작동하는지 연구하는 것과 그것의 보호되는 표현을 복제하는 것 사이의 구분이다. 인터페이스，파일 형식，또는 어떤 동작 하나를 알아내기 위한 리버스 엔지니어링은，법적으로，다른 사람의 코드나 자산을 자신의 제품에 가져오는 것과는 다른 행위다.

그 구분을 중심으로 만들어진 관행을 클린룸 설계라고 부른다. 한 사람 또는 한 세션이 원본을 연구해 그것이 무엇을 하는지에 대한 일반 명세서를 작성한다：인터페이스，데이터 형식，동작을，자신의 말로，원본 코드를 문서에 복제해 넣지 않고. 원본을 전혀 본 적이 없는 별도의 사람 또는 세션이 그 명세서만으로 새로운 구현을 만든다. 핵심은 최종 결과물이 원본 작업 자체가 아니라 기록된 설명에서 나왔다는 것을 보여줄 수 있다는 점이다.

이 점에서 오래된 미국 판결 두 건이 자주 인용되며，알아둘 가치가 있다，다만 둘 다 무엇이든 리버스 엔지니어링해도 된다는 일반적인 허가는 아니다. 1992년 제9순회항소법원이 판결한 Sega Enterprises Ltd. v. Accolade, Inc. 사건은，자사 게임이 어떤 게임 콘솔에서 돌아가게 하려고 그 콘솔의 잠금 시스템을 리버스 엔지니어링한 회사가 관련되어 있었다. 법원은，게임이 그 하드웨어에서 작동하는 데 필요한 보호받지 않는 기능적 요소에 도달하기 위해 이루어진 그 리버스 엔지니어링 과정의 중간 복제가，그 사건의 특정 사실관계 아래에서 공정 이용이라고 판단했다. 2000년 같은 법원이 판결한 Sony Computer Entertainment, Inc. v. Connectix Corp. 사건도，한 회사가 다른 종류의 컴퓨터용 에뮬레이터를 만들기 위해 콘솔의 부팅 소프트웨어를 리버스 엔지니어링했을 때 비슷한 결론에 도달했는데，이번에도 그 과정의 복제를，독립적으로 작성된 상호운용 가능한 제품을 위한 공정 이용으로 취급했다.

이 두 판결은 당신 상황에 대한 조언이 아니라 역사적 맥락으로 받아들여라. 이것들은 특정 사실관계에 대한 두 건의 구체적인 항소법원 판결이며，공정 이용은 사건마다 개별적으로 결정되고，다른 나라들은 이 경계를 다르게 긋고，복제 방지 우회를 겨냥한 이후의 법률들은 DRM이 걸린 소프트웨어에 대해 이를 상당히 좁혀놓았다. 이런 종류의 작업을 바탕으로 무언가를，특히 출시하거나 판매할 목적의 무언가를 만들려는 사람은 그중 어느 것에도 의존하기 전에 실제 변호사와 상담해야 한다.

REA는 어떤 특정 사건에 대해 법원이 결국 어떻게 판단할지와는 별개로 자체 기준을 세운다. 프로젝트의 DISCLAIMER.md에 따르면，REA는 DRM，라이선스 검사，안티치트 시스템，또는 그 밖의 기술적 보호 조치를 우회하거나，독점 소프트웨어 또는 그것의 보호되는 코드와 자산을 복제하는 일을 지원하지도，돕지도 않으며，프로젝트는 분석 결과물이 원본 프로그램에 대한 어떤 권리도 부여하지 않는다고 명확히 밝힌다. 거기서 따라 나오는 실용적인 규칙은：자신이 소유했거나，직접 작성했거나，그 외의 방식으로 조사 권한이 있는 소프트웨어만 분석하라는 것이다.

여기서는 Node.js 버전이 중요하다. REA 자체의 README는 요구 사항을 정확히 다음과 같이 명시한다：Node.js 22.x（>=22.23.4），24.x（>=24.22.1），또는 26.12.1 이상，그리고 npm. 이런 종류의 요구 사항은 릴리스마다 바뀌므로 설치하기 전에 실제 README와 대조해 확인하라.

설정 명령은 npx rea-agents setup이다. README에 따르면，이 명령은 REA를 어떤 에이전트에 등록할지 고르는 과정을 안내하고，승인하기 전에 적용하려는 변경 사항을 보여주며，기존 설정의 백업을 보관한다. 그 뒤에는 에이전트를 재시작해 새 MCP 서버를 인식하게 하라；REA 자체의 안내도 이를 명확히 말한다.

일회성 npx 실행이 아니라 지속적인 명령줄 설치를 원한다면，README는 npm install --global rea-agents를 설명하며，그 다음에 rea --help로 무엇을 쓸 수 있는지 확인한다. 전역 설치 상태에서는 rea update가 자동이 아니라 자신이 정한 일정에 따라 새 버전으로 옮겨주며，그 뒤 npx rea-agents@latest setup을 실행하면 에이전트 등록이 그에 맞게 새로 갱신된다.

완전히 소유하지 않은 것에 REA를 쓰기 전에，먼저 자신이 직접 작성한 작은 애플리케이션에서 시험해보라. REA를 설정한 상태에서 Claude Code에게 그 작은 앱을 열어서 보이는 것을 함수 단위로 설명하게 하고，그것을 자신이 이미 알고 있는 작성 내용과 비교하라. 이 한 가지 연습만으로 설정이 실제로 제대로 되었는지 확인할 수 있고，중요한 일에 의지하기 전에 REA의 증거，즉 파일，함수，호출이 실제로 어떻게 읽히는지 감을 잡을 수 있다.

앞서 나온 클린룸 아이디어를 두 개의 별도 Claude Code 세션을 이용해 구체적인 형태로 만들어보자. 첫 번째는 스펙 세션이다：조사 권한이 있는 소프트웨어에 REA를 겨누고，에이전트에게 그 인터페이스，데이터 형식，주요 함수의 동작에 대한 쉬운 말로 된 명세서를，원본 코드나 의사코드를 문서에 그대로 복제하지 않고 전부 자신의 말로 작성하게 한다.

두 번째는 빌드 세션으로，첫 세션에 대한 기억이 전혀 없이 새로 시작한다. 명세서 파일만 주고 다른 것은 아무것도 주지 마라：원본 바이너리도，첫 세션의 대화 기록도，REA의 원시 출력도 안 된다. 명세서를 만족하는 새롭고 독립적인 구현을 만들게 하고，명세서에서 모호한 부분이 있으면 원본 프로그램이 무엇을 했을지 조용히 추측하는 대신 알려달라고 하라.

이것들을 하나의 긴 대화의 두 단계가 아니라 진짜로 분리된 세션으로 유지하는 것이 중요한 부분이다. 원본을 연구한 뒤 대체물까지 작성한 단일 세션은，클린룸 설계가 선명하게 유지하려는 바로 그 경계를 흐려놓는데，나중에 뒷부분이 앞부분에 의존하지 않았다는 것을 보여줄 방법이 없기 때문이다.

이것이 실제로 가져다주는 것이 무엇인지 냉정하게 바라보라. 규율 있는 두 세션 워크플로우는 누군가 나중에 어떻게 만들었는지 물었을 때 클린룸 주장을 뒷받침하는 관행이다. 그 자체로 법적 보증은 아니며，출시하거나 판매하려는 것을 실제 변호사가 검토하게 하는 일을 대신하지도 않는다.