REA 활용법 5가지, 기능 분석부터 버그⁠·보안 점검까지

REA는 Claude Code 같은 AI 에이전트가 앱과 웹사이트를 거꾸로 뜯어보게 해 주는 오픈소스 역분석 도구입니다. 이 글은 REA 활용법 다섯 가지(다른 앱의 기능 동작 알아내기, 경쟁 서비스 조사, 내 앱 버그 찾기, 성능 점검, 공개 전 보안 점검)를 설치부터 25단계로 따라 하게 정리했습니다. 단계마다 그대로 붙여 넣을 수 있는 요청 문장도 함께 적었습니다.

REA 활용법을 보기 전에 알아 둘 것

REA 한 줄 정의

REA(Reverse Engineer Anything)는 AI 에이전트가 완성된 앱을 거꾸로 분석해 기능의 원리를 찾도록 도구를 이어 주는 오픈소스입니다. 형태는 MCP 서버(AI가 바깥 프로그램을 자기 도구처럼 쓰게 이어 주는 표준 연결 방식)이고, Claude Code나 Codex 같은 에이전트에 연결해서 씁니다.

저장소는 github.com/morluto/rea, 라이선스는 MIT입니다. 깃허브 별(관심 표시)은 2026년 10월 17일 기준 약 29만 개입니다. "깃허브 트렌딩 1위"라는 소개는 특정 날짜의 순위라, 순위보다 별 수와 최근 업데이트 날짜를 보는 편이 정확합니다. 최신판은 10월 14일에 나온 6.5.0입니다. 별 수와 버전은 빠르게 바뀌니 저장소에서 다시 확인합니다.

스크린샷 도구와 다른 점

보통은 Claude가 설명과 브라우저 스크린샷을 보고 기능을 짐작합니다. 겉모습은 비슷하게 만들어도, 클릭⁠·드래그⁠·삭제했을 때 어떻게 동작하는지는 자주 틀립니다.

버튼을 누르면 페이지는 서버에 데이터를 보내고, 서버는 보여 줄 내용을 돌려줍니다. 스크린샷만 보는 도구는 이 주고받는 과정을 놓칩니다.

REA는 그 클릭을 따라가 요청을 보내는 바로 그 코드를 찾습니다. 웹사이트라면 크롬 계열 브라우저로 페이지 구조, 스크립트, 네트워크 요청을 관찰합니다. 단계마다 보낸 것과 받은 것을 기록하고, 기능이 어떻게 돌아가는지 글로 정리해 줍니다.

확인⁠·추정⁠·모름을 나눠 적는다

REA가 잡아낸 요청과 실행된 코드는 각각 증거 ID가 붙어 저장됩니다. REA와 함께 설치되는 작업 안내 스킬은 에이전트에게 모든 결론을 관찰한 것(확인), 다른 단서로 짐작한 것(추정), 뒷받침할 것이 없는 것(모름)으로 나눠 적게 합니다. 리포트에서는 seen / guessed / unknown 같은 표시로 보이기도 합니다.

이 구분 덕분에 추측이 사실처럼 넘어가지 못합니다. 리포트를 읽을 때 가장 먼저 볼 곳도 이 표시입니다.

볼 수 없는 것

증거는 브라우저에 도착한 것만 다룹니다. 회사 서버 안에서 일어나는 일은 REA가 볼 수 없습니다.

데스크톱 앱은 만든 방식에 따라 다릅니다.

• 웹사이트처럼 만든 앱(일렉트론 앱): 웹사이트와 같은 방식으로 분석합니다.
• 프로그램 파일을 내 컴퓨터에 두는 앱: 그 파일을 직접 읽어 분석합니다. 맥⁠·윈도 설치형 프로그램은 Hopper, Ghidra, IDA 같은 분석기가 필요합니다.
• 모든 것을 인터넷에서 불러오는 앱: 컴퓨터에 읽을 것이 없어 분석하지 못합니다.

분석해도 되는 대상

REA는 내가 만들었거나 분석 허락을 받은 소프트웨어, 호환성 확보나 연구⁠·교육 목적에 쓰라는 원칙을 밝혀 둡니다. 남의 앱과 사이트를 볼 때는 이용약관에서 역분석⁠·자동 수집 금지 조항을 먼저 찾아보고, 찾아낸 원리를 바탕으로 내 코드를 새로 짭니다. 원본 코드나 그림⁠·문구를 그대로 가져오지 않습니다. 버그⁠·성능⁠·보안 점검(용도 3~5)은 내 앱에만 씁니다.

REA 활용 준비물

• 코딩 에이전트: Claude Code 또는 Codex. 그 밖에 Cursor, Gemini CLI 등도 지원합니다.
• 터미널
• Node.js와 npm. Node.js는 22.x라면 22.19 이상, 24.x라면 24.11 이상, 또는 26 이상이 필요합니다. 버전은 터미널에서 node -v로 확인합니다.
• 크롬 계열 브라우저(웹사이트 분석용)
• 분석할 앱⁠·사이트. 용도 3~5는 내 사이트 주소나 내 컴퓨터에서 실행할 수 있는 내 앱이 있어야 합니다.
• 비용: REA는 무료입니다. Claude Code나 Codex는 유료 요금제나 API 사용료가 듭니다.

REA 설치와 활용 25단계

REA 설치하기

1~11단계는 순서대로 진행합니다.

1단계. 웹 브라우저로 REA GitHub 저장소를 연다

• 위치: github.com/…
• 확인: 저장소 페이지가 열립니다. 공식 배포처는 이 저장소와 rea.tools, npm의 rea-agents 패키지뿐입니다. 비슷한 이름의 다른 저장소는 쓰지 않습니다.

2단계. 저장소 페이지에서 설치 명령어를 찾는다

• 위치: README 첫 부분의 설치 안내
• 확인: 아래 명령어가 보입니다.

npx rea-agents setup

3단계. 설치 명령어를 복사한다

• 확인: 명령어가 클립보드에 들어 있습니다.

4단계. 터미널을 연다

• 맥: Cmd+Space를 누르고 terminal을 입력한 뒤 엔터를 누릅니다.
• 윈도: 시작 메뉴에서 PowerShell이나 터미널을 엽니다.
• 확인: 명령을 입력할 수 있는 창이 뜹니다.

5단계. 복사한 명령어를 터미널에 붙여 넣는다

• 확인: 명령어가 터미널 입력줄에 보입니다.

6단계. 엔터를 누른다

• 확인: 명령이 실행되고, 내 컴퓨터의 코딩 도구를 찾아 어디에 설치할지 묻는 목록이 뜹니다.

7단계. 화살표 키로 설치할 코딩 도구를 고른다

• 위치: 터미널에 뜬 도구 목록. 위아래 화살표로 움직입니다.
• 확인: 원하는 도구(Claude Code 또는 Codex)가 선택된 상태입니다.

8단계. 엔터를 누른다

• 확인: REA가 바꾸려는 설정 내용을 보여 주고 승인을 받은 뒤 설치를 진행합니다.

9단계. Hopper 설치 질문에 답한다

• 위치: 설치 중에 바이너리 분석용 Hopper를 설치할지 묻습니다.
• 확인: 질문이 넘어가고 설치가 끝납니다.
• 판단 기준: Hopper는 웹 방식이 아닌 설치형 프로그램을 깊이 볼 때 씁니다. 웹사이트나 웹사이트처럼 만든 데스크톱 앱만 다룬다면 필요 없습니다. Hopper는 유료 라이선스가 있는 상용 도구라, 처음 실행할 때 데모 모드와 라이선스 등록 중 하나를 고릅니다.

10단계. Claude Code를 다시 연다

• 확인: Claude Code 입력창이 뜹니다. 켜져 있던 Claude Code는 /exit로 닫고 claude로 다시 켜야 REA가 연결됩니다.
• 참고: 역분석 스킬은 프로젝트 폴더가 아니라 메인 Claude 폴더(~/.claude/skills)에 설치됩니다. 그래서 아무 폴더에서 열어도 쓸 수 있습니다. 앱 종류별 참고 자료(references)도 같이 들어 있습니다.

11단계. Claude Code에서 MCP 연결을 확인한다

• 위치: Claude Code 입력창에 /mcp를 입력합니다.
• 확인: 연결된 MCP 서버 목록에 REA가 연결됨(connected)으로 보입니다.

용도 1. 다른 앱의 기능 동작을 알아내 내 앱에 만들기

가장 많이 쓰는 용도입니다. 노션처럼 동작하고 옵시디언(Obsidian)처럼 페이지를 서로 연결하는 메모 앱을 만들고 있는데, 그래프 보기 기능이 아직 없다고 해 보겠습니다.

12단계. Claude Code에 기능 분석을 요청한다

아래처럼 보냅니다. 앱 이름과 기능만 내 것으로 바꿉니다.

REA로 Obsidian 데스크톱 앱을 살펴서 그래프 보기를 어떻게 만드는지 알아내 줘.
노션은 보드 보기가 어떻게 동작하는지 봐 줘.
아직 구현하지 말고, 두 기능이 어떻게 동작하는지 behavior list 파일로 먼저 적어 줘.
결론마다 확인·추정·모름을 구분해 줘.

• 확인: 에이전트가 역분석 스킬을 먼저 불러오고, 대상 종류에 맞는 참고 자료를 불러온 다음 옵시디언부터 분석합니다.
• 참고: 노션 MCP를 미리 연결해 뒀다면 노션은 그쪽으로 볼 수 있습니다. 옵시디언처럼 연결된 MCP가 없는 앱은 REA가 앱 파일을 직접 읽습니다.

13단계. 만들어진 behavior list 파일을 연다

• 확인: 노드 배치, 선 그리기, 강하게 연결된 페이지끼리 서로 끌어당기는 정도, 노드를 끌 때 일어나는 일 등이 적혀 있습니다. REA가 코드에서 실제로 본 것과 확정하지 못한 것이 나뉘어 있습니다.

14단계. 목록 중 필요한 동작을 구현해 달라고 요청한다

behavior list에서 우리 앱에 필요한 동작을 골라 구현해 줘.
원본 코드를 복사하지 말고, 찾은 원리를 바탕으로 우리 코드로 새로 짜 줘.

• 확인: 내 앱에 그 동작이 들어갑니다.
• 사례: 옵시디언은 지운 노드로 가는 링크를 깨진 링크로 남깁니다. 이 동작을 알고 나면 "페이지를 지우면 그 링크는 일반 글자로 바꾼다"처럼 내 앱의 규칙을 따로 정할 수 있습니다. 이런 동작은 스크린샷에는 나오지 않습니다.

용도 2. 경쟁 서비스 조사

15단계. 내가 만드는 것을 설명하고 경쟁사를 모두 찾아 달라고 요청한다

나는 AI 회의록 앱을 만들고 있어. 같은 일을 하는 경쟁 서비스를 모두 찾아서 목록으로 정리해 줘.

• 확인: 같은 일을 하는 사이트 목록이 나옵니다. 첫 줄의 설명은 내 서비스로 바꿉니다.

16단계. 상위 5개를 골라 REA로 깊이 조사해 달라고 요청한다

이 중 상위 5개를 골라 REA로 하나씩 깊이 조사해 줘.
로그인 없이 볼 수 있는 공개 페이지만 보고, 각 서비스가 어떻게 동작하는지와 서로 무엇이 다른지 표로 정리해 줘.

• 확인: 경쟁사별 동작 방식과 차이가 정리돼 나옵니다.
• 사례: 회의록 앱으로 시험한 사례에서는 REA 없이 같은 5곳을 조사하면 가격, 회의 녹음 방식 같은 기본 정보만 나왔습니다. REA는 각 서비스의 로그인 전 페이지가 불러오는 코드를 살폈고, 거기서 홈페이지에 적히지 않은 기능이 보였습니다.
• 주의: 남의 서비스 약관이 자동 수집이나 역분석을 금지하는지 먼저 확인합니다. 결과는 기획 참고용으로만 씁니다.

용도 3. 내 앱 버그 찾기

코드만 읽어서는 놓치기 쉬운, 고객을 잃을 만큼 심각한 문제를 찾는 용도입니다.

17단계. REA로 내 사이트 기능을 점검해 달라고 요청한다

REA를 써서 https://내사이트주소 의 결제 기능이 원래 의도대로 정확히 동작하는지 확인해 줘.
아무것도 바꾸지 말고, 소스 코드도 읽지 말고, 사이트만 보고 판단해 줘.
이상한 점이 있으면 무엇이 잘못됐는지 전체 리포트로 알려 줘.

• 확인: 에이전트가 테스트 시나리오를 폴더에 적은 뒤 MCP로 하나씩 실행합니다.
• 팁: 코드를 읽지 말라는 조건이 중요합니다. 사이트만 보고 알아내게 해야 코드에서는 멀쩡해 보이는 더 깊은 문제를 찾습니다.
• 팁: 기본은 headless 모드(브라우저 화면이 안 보이는 상태)입니다. 브라우저를 직접 보면서 지켜보고 싶으면 "headless를 쓰지 말고 브라우저를 띄워서 진행해 줘"라고 덧붙입니다.

18단계. 테스트가 끝난 뒤 리포트를 읽는다

• 확인: 찾은 문제가 모두 적혀 있고, 증명하지 못한 것은 추정으로 표시돼 있습니다.

데모 결제 앱으로 시험한 사례에서는 이런 결과가 나왔습니다.

• 화면에 보이는 가격과 실제 청구 가격이 달랐습니다. 가격 코드 자체는 멀쩡해 보여서 코드만 읽어서는 찾기 어려운 문제였습니다.
• 대부분 계정은 맞았지만 두 계정이 달랐습니다. 하나는 실제 금액의 절반, 하나는 0이 보였습니다.
• 원인을 단계별로 추적했습니다. 가격은 브라우저 안에서 계산되고 항목⁠·할인⁠·세금은 맞았는데, 마지막에 합계를 더하는 단계에서만 틀렸습니다.
• 작은 문제로는 서버가 음수 좌석 수를 받아들이고 요금제 한도보다 많은 좌석을 파는 것, 한 계정이 모든 청구서가 남겨야 하는 결제 기록을 남기지 않은 것이 나왔습니다.
• 페이지에 들어 있는 설정 목록이 두 가격 오류의 원인이라는 결론은 추정으로 표시됐습니다.

용도 4. 성능 점검

느린 페이지나 깨진 레이아웃은 사용자가 앱을 떠나는 흔한 이유라 자주 점검하는 편이 좋습니다.

19단계. 앱을 실행하고 REA로 전체 점검을 해 달라고 요청한다

내 앱을 로컬에서 실행한 뒤 REA로 전체 점검을 해 줘.
속도, 사이트를 느리게 하는 원인, 깨진 링크, 휴대폰 화면을 포함한 전반적 동작을 확인하고 리포트로 정리해 줘.
고치기 전에 먼저 리포트만 보여 줘.

• 확인: 사이트 전체에 브라우저 테스트가 돌아갑니다.

20단계. 마지막에 나온 리포트를 읽고 고칠 것을 고른다

• 확인: 문제 목록이 나옵니다. 한 사례에서는 휴대폰에서 대시보드 상단(헤더)이 화면 밖으로 넘친 것이 잡혔습니다.
• 다음: 고칠 항목을 골라 "헤더 넘침부터 고쳐 줘"처럼 따로 요청하면 에이전트가 수정합니다.

용도 5. 공개 전 보안 점검

앱을 공개하기 전에 가장 중요한 용도입니다. AI로 만든 앱은 공개되면 안 되는 값이 새는 경우가 많은데, 화면에는 아무 표시가 없습니다.

21단계. 앱을 실행하고 REA로 보안 문제를 점검해 달라고 요청한다

내 앱을 로컬에서 실행하고 REA로 보안 문제를 점검해 줘.
브라우저에 노출된 API 키·비밀번호, 로그인 없이 다른 사람 데이터에 접근되는 경로를 중심으로 보고,
찾은 것을 위험도 순으로 전부 보고해 줘. 항목마다 고치는 방법도 적어 줘.

• 확인: 점검이 돌아갑니다.

22단계. 보안 리포트를 읽는다

• 확인: 위험도 순으로 정렬돼 있고 항목마다 고치는 법이 적혀 있습니다.
• 사례: 문제를 일부러 심어 둔 테스트 앱에서는 쉽게 접근 가능한 OpenAI·Stripe API 키를 찾았고, 백엔드 접근 권한 없이 고객 데이터에 접근하게 하는 논리 문제도 잡았습니다. 쉬운 문제도, 코드 속에 숨긴 문제도 있던 앱이라 내 앱에서도 같은 개수가 나온다는 뜻은 아닙니다.

23단계. 리포트의 문제를 고친다

• 방법: 위험도가 높은 것부터 하나씩 고칩니다. 에이전트에게 맡길 때는 "1번 항목부터 고치고, 고친 뒤 같은 점검을 다시 돌려 줘"라고 요청합니다.
• 확인: 다시 점검했을 때 그 항목이 사라졌습니다. 노출됐던 API 키는 코드에서 지우는 것만으로 끝나지 않으니 발급처에서 새 키로 바꿉니다.

공통. 결과 판정

24단계. 리포트의 각 발견에 붙은 표시를 확인한다

• 확인: 확인(REA가 잡은 증거 있음), 추정(다른 단서로 짐작), 모름(근거 없음) 중 하나입니다. 중요한 결론은 근거가 된 증거 위치를 직접 열어 봅니다.

25단계. 서버 안쪽 동작이 필요한 결론인지 따져 본다

• 확인: REA는 브라우저에 도착한 것만 보므로, 회사 서버 안에서 일어나는 일에 대한 결론은 추정일 수밖에 없습니다. 서버 쪽 확인이 필요하면 내 서버 로그와 코드로 따로 확인합니다.

REA 활용 중 자주 막히는 곳

• 테스트 중 브라우저가 안 보일 때: 기본이 headless 모드라서입니다. 에이전트에게 headless를 끄라고 요청합니다.
• 웹 방식이 아닌 앱을 깊이 못 볼 때: 설치 때 Hopper를 건너뛰었을 수 있습니다. Hopper를 설치하거나, 무료인 Ghidra를 미리 깔아 둡니다.
• 서버 쪽 로직이 리포트에 안 나올 때: REA는 브라우저에 도착한 것만 봅니다. 도구 자체의 한계입니다.
• 데스크톱 앱 분석이 안 될 때: 모든 것을 인터넷에서 불러오는 앱은 컴퓨터에 읽을 파일이 없습니다.
• 리포트 내용이 사실인지 헷갈릴 때: 발견마다 근거 수준이 다릅니다. 확인⁠·추정⁠·모름 표시를 봅니다.
• 설치했는데 에이전트에서 안 보일 때: 에이전트를 다시 시작했는지 보고, 그래도 안 되면 npx rea-agents@latest setup으로 최신 설정을 다시 적용합니다.

REA 활용 점검표

• Claude Code(또는 Codex)에서 REA MCP가 연결됨으로 보인다
• 용도 1: behavior list 파일이 생겼다
• 용도 2: 경쟁사 상위 5곳 조사 결과가 나왔다
• 용도 3: 버그 리포트가 나왔다
• 용도 4: 성능 점검 리포트가 나왔다
• 용도 5: 위험도 순 보안 리포트가 나왔다
• 각 발견이 확인⁠·추정⁠·모름 중 무엇인지 확인했다

REA의 쓸모는 "겉모습이 아니라 동작"에 있습니다. 스크린샷이 아니라 브라우저가 실제로 주고받은 요청과 코드를 증거로 남기고, 발견마다 근거 수준을 붙입니다. 내 앱에 쓸 때는 리포트의 확인⁠·추정 표시를 먼저 보고, 확인된 항목부터 고칩니다.