본문으로 건너뛰기

REA가 뭔가요? 공식 사례부터 설치·팩맨 실습까지

· 약 13분
AI builder
이 글과 연결된 글 보기
12편 · 39개 연결
100%
문자로 온 네이버페이 포인트 기프티콘, AI 브라우저 에이전트에게 등록시켜 봤습니다해외 출장 가이드북, 메일·캘린더·지도에 흩어진 정보로 15쪽 PDF 만들기 (프롬프트 포함)이제 직원 급여도 AI가 보냅니다: 은행 앱 급여 이체부터 급여명세서 발송까지 AI 에이전트에 맡긴 8단계 (ADB)AI가 내 책을 학습하는 대가, 내 몫은 16만 원이었다터미널에서 AI 브라우저에게 일 시키기, Aside CLI 사용법Daytona란 무엇인가? AI가 만든 코드를 안전하게 실행하는 샌드박스문자로 쓰는 AI 비서 instinct, 처음엔 무슨 일을 시켜볼까요?Muse 가입부터 첫 작업까지: 처음 쓰는 사람을 위한 8단계 가이드AI에게 일을 맡기고 팀이 함께 검토한다: OpenAI DevDay 2026 발표 요약OpenAI Dots는 Muse 대항마가 아니라 '클라우드 PC 비서'입니다REA가 뭔가요? 공식 사례부터 설치·팩맨 실습까지Codex에 영상 넣고 "자막 따줘" 한마디|AI로 영상 자막 자동 생성하는 방법

드래그로 이동 · 휠/두 손가락으로 확대 · 방향키로 글 선택 · 0으로 맞춤. 실선: 본문 링크, 점선: 시리즈·주제의 대표 연결.

표시된 글 12편 목록
전체 글 연결 탐색

REA(Reverse Engineer Anything)는 코딩 AI가 기존 프로그램의 작동 방식을 조사하도록 돕는 도구입니다. 무엇을 해주는지부터 공식 사례, 설치와 연결 확인, 직접 유령이 되어 팩맨을 잡는 실습까지 순서대로 정리했습니다.

바이브코딩은 해봤지만 개발 용어는 낯선 분을 위한 안내입니다. REA가 맡는 일 → 공식 사례 → 설치와 연결 → 팩맨 실습 → 결과 확인이 궁금하다면 필요한 절부터 읽어도 됩니다. 공식 사례는 8절에 모았습니다.

확인 범위를 구분했습니다. 팩맨 역할 변경은 직접 실행한 실습이고, 설치 안내는 공식 문서 조사이며, 다른 제작자의 앱 변경 사례는 공개 자료에 근거합니다. 모든 운영체제·AI 조합에서 새로 설치해 본 것은 아닙니다. 문서 확인일: 2026년 10월 15일.

1. REA는 무엇을 해주나요?​

이 절의 이름·역할·설치 요건은 공식 README와 설치 문서를 확인해 정리했습니다.

REA는 Reverse Engineer Anything의 약자입니다. 완성된 프로그램을 살펴보고 “이 기능이 어떻게 움직이는지” 거꾸로 알아내는 일을 역공학이라고 합니다. 요리책 대신 완성된 요리를 보고 재료와 조리 과정을 추측하고, 실제 맛과 비교하며 확인하는 것에 가깝습니다.

내 질문 → 코딩 AI → REA → 분석 도구 → 근거 → AI의 설명·구현·검사

내가 “이 버튼을 누르면 어떻게 저장돼?”라고 물으면 코딩 AI가 REA를 통해 조사합니다. REA는 코드를 읽거나 다른 분석 도구를 연결해서 함수, 호출 관계, 관련 파일 등의 근거를 돌려줍니다. AI는 이 결과를 읽고 설명하거나 내 프로젝트의 새 기능을 작성합니다. REA 자체가 게임을 한 번에 바꾸는 버튼은 아닙니다.

낯선 말이 가이드에서의 뜻
코딩 AI내 작업 폴더를 읽고 코드를 고치는 도구. Claude Code, Codex, Cursor 등이 해당합니다.
MCPAI와 외부 도구가 질문과 결과를 주고받는 연결 방식입니다.
원본 코드 / 배포 파일개발자가 작성한 자료 / 사용자에게 전달된 실행용 자료입니다. 둘은 형태가 다를 수 있습니다.
정적 분석 / 실행 확인코드를 읽어 동작을 추론하는 일 / 실제로 켜서 맞는지 보는 일입니다. 둘 다 필요합니다.

웹사이트의 화면 쪽 코드는 브라우저가 받아 실행하므로 직접 읽을 수 있는 경우가 있습니다. 이것이 모든 서버 내부 코드까지 공개됐다는 뜻은 아닙니다. 원본 코드가 공개된 대상은 REA 없이 분석할 수도 있습니다. REA를 썼다는 사실과, 꼭 필요했다는 주장은 구분해야 합니다.

2. 설치 전에 준비할 것​

처음에는 내 컴퓨터와 이미 사용하는 코딩 AI 하나, 별도 실습 폴더를 준비하세요. 휴대폰의 일반 채팅창만으로 따라 하는 과정은 아닙니다. AI가 폴더와 분석 도구에 접근할 수 있는 환경이 필요합니다.

  1. Node.js와 npm: REA 실행에 사용하는 프로그램입니다. 공식 README 기준 지원 범위는 Node.js 22.19 이상(22계열), 24.11 이상(24계열), 또는 26 이상입니다. 막 설치한다면 Node.js 공식 사이트에서 현재 지원 버전을 확인하세요.
  2. 코딩 AI: Claude Code, Codex, Cursor 중 이미 쓰는 것을 선택합니다. REA가 오픈소스라는 것과 AI 모델 사용료는 별개입니다. 분석량에 따라 AI 사용량이 늘 수 있습니다.
  3. 실습 대상: 본인이 만든 프로그램이나 공개된 게임으로 시작합니다. 회사 내부 앱이나 타인의 비공개 자료 대신, 공개 팩맨 리메이크를 사용합니다.

가장 쉬운 설치 요청​

코딩 AI에서 실습 폴더를 열고 아래 내용을 붙여 넣으세요. 변경할 설정을 먼저 읽고 승인할 수 있게 요청한 문장입니다.

REA 공식 프로젝트 https://github.com/morluto/rea 를 확인하고,
지금 사용하는 코딩 AI에 REA를 연결해줘.
내 OS, Node.js와 npm 버전부터 확인해줘.
공식 명령 npx rea-agents@latest setup 을 기준으로 진행하고,
변경할 설정 파일과 추가 설치가 필요한 프로그램을 먼저 설명해줘.
원래 설정은 백업하고, 완료 후 재시작 방법과 연결 확인 결과를 알려줘.
이번 첫 실습은 공개 JavaScript 게임 분석이야.

직접 터미널에서 한다면 node --version, npm --version으로 준비 상태를 확인하고 아래 설치 명령을 실행합니다. 설치 안내에서 실제 사용할 AI만 선택하고, 변경 경로를 확인한 다음 승인하세요. 완료 메시지에 나온 AI를 완전히 종료했다가 다시 열어야 연결이 반영될 수 있습니다.

npx rea-agents@latest setup

명령은 이 가이드 확인 시점의 공식 문서 기준입니다. 이미 다른 버전이 설치돼 있다면 오류 메시지와 공식 설치 문서를 먼저 확인하세요.

Ghidra나 Hopper도 꼭 설치해야 하나요?​

대상에 따라 다릅니다. 공개 JavaScript 분석은 별도의 네이티브 분석 엔진 없이 시작할 수 있습니다. 설치된 앱의 실행 파일을 분석하는 작업은 Ghidra·Hopper·IDA 같은 도구와 운영체제별 준비가 필요할 수 있습니다. 첫 실습 전에 모든 도구를 무조건 설치할 필요는 없습니다. 설치 프로그램이 제안하는 비용·라이선스·변경 범위를 읽고 결정하세요.

3. “설치했어” 다음에 실제 연결 확인​

AI가 설치가 끝났다고 말하는 것만으로 끝내지 않습니다. 다시 연 AI에게 실제 REA 도구를 확인하고 호출 결과를 보여달라고 요청하세요.

REA가 지금 이 세션에서 연결됐는지 확인해줘.
사용 가능한 실제 REA 도구 이름과 버전을 보여줘.
공식 doctor 또는 이에 해당하는 준비 상태 검사를 실행하고,
이번 JavaScript 분석에 필요한 항목과 불필요한 항목을 구분해줘.
성공했다고만 하지 말고 실제 호출 결과와 남은 문제를 적어줘.
아직 분석 대상을 수정하지 마.

확인할 결과: 사용 중인 버전, 도구 연결 상태, 필요한 분석 도구의 준비 상태, 실패했다면 구체적인 오류입니다. 명령줄로 준비 상태를 확인할 때는 공식 문서의 npx rea-agents@latest doctor --json을 참고할 수 있습니다. 전체 준비 상태 중 특정 엔진의 경고가 있어도, 현재 하려는 JavaScript 분석에 필요한지부터 확인하세요.

4. 팩맨을 “유령이 팩맨을 잡는 게임”으로 바꾸기​

유튜브에서 영상 보기

직접 실행해 확인한 실습입니다.

원래 팩맨에서는 내가 노란 팩맨을 움직여 유령에게서 도망칩니다. 이번 목표는 내가 분홍 유령을 움직이고, 노란 팩맨은 자동으로 도망가게 만드는 것입니다. 원작 아케이드 실행 파일 대신 masonicGIT의 공개 JavaScript 리메이크를 대상으로 했습니다.

저희 실습에서는 REA 6.5.0으로 공개 배포 파일을 분석했습니다. 팩맨의 목표를 정하는 pacman.setTarget, 방향을 정하는 Player.steer, 통로에서 움직이는 Player.step 관계를 추적했습니다. 그 리메이크에는 이미 팩맨이 분홍 유령에게서 멀어지는 방향을 목표로 삼는 코드가 있었습니다. 이 부분을 재사용하고, 입력 대상을 유령으로 바꾸는 코드는 별도로 작성했습니다.

중요한 구분

REA가 발견한 것: 기존 이동·타깃 규칙과 관련 코드.
새로 만든 것: 유령 조종, 다른 유령 대기, 시작 위치, 자동 이동이 멈추는 상태 보정, 포획 안내.
실행으로 확인한 것: 방향키에 따른 분홍 유령 이동, 입력 없이 움직이는 팩맨, 실제 충돌·포획.
증명하지 않은 것: REA가 없으면 이 게임을 못 만든다는 주장이나 원작 아케이드 코드 복구.

1단계 · 원본을 먼저 실행​

새 실습 폴더에서 https://github.com/masonicGIT/pacman 를 준비해줘.
이 프로젝트의 실행 방법과 GPL-3.0 라이선스 조건을 확인해줘.
원본 파일은 보존하고 수정용 사본을 별도로 만들어줘.
먼저 로컬 브라우저에서 원래 팩맨이 실행되는지 확인해줘.
아직 역할을 바꾸지 말고 조종 방법과 실행 주소를 알려줘.

2단계 · REA로 조사​

이 게임에서 조종 대상을 팩맨에서 분홍 유령으로 바꾸고 싶어.
수정 전에 실제 REA 도구로 배포된 JavaScript를 분석해줘.
1. 키보드 입력이 어느 캐릭터로 전달되는지
2. 팩맨과 유령의 방향·이동을 결정하는 함수
3. 이미 있는 팩맨 자동 이동이나 도망 규칙
4. 캐릭터 충돌과 라운드 종료 판정
각 항목의 파일·함수·근거 위치를 적어줘.
실제로 확인한 내용, 코드만 보고 추론한 내용, 모르는 내용을 구분해줘.
아직 구현하지 말고 최소 변경 계획부터 설명해줘.

3단계 · 역할 바꾸기​

확인한 근거를 바탕으로 유령 조종 모드를 만들어줘.
방향키는 분홍 유령에만 전달하고, 노란 팩맨은 기존 자동 이동을 활용해줘.
다른 유령은 대기하는 1대1 모드로 시작해줘.
원래 팩맨 모드로 되돌리는 버튼도 유지해줘.
플레이 중 내가 조종하는 유령을 명확하게 표시하고,
진짜 충돌 판정이 발생했을 때만 성공 안내를 보여줘.
새로 만든 규칙과 원본에서 재사용한 규칙을 구분해서 기록해줘.
기존 이동 규칙을 켰는데 멈추면 이유를 조사하고 수정 근거를 남겨줘.

복사한 요청은 저희 실습 흐름을 따라가기 위한 출발점입니다. AI가 고른 구현과 현재 저장소 버전에 따라 결과는 달라집니다. 완성 화면을 보자마자 성공으로 처리하지 말고 아래 검사를 진행하세요.

5. 진짜로 바뀌었는지 확인하는 법​

  1. 방향키 검사: 오른쪽을 누를 때 분홍 유령의 위치가 바뀌는지 봅니다. 화면에만 “유령 모드”라고 써 있는 것은 증거가 아닙니다.
  2. 팩맨 자동 이동: 내가 키를 누르지 않아도 팩맨이 움직이는지 확인합니다. 키보드 입력이 두 캐릭터를 동시에 움직이면 다시 고칩니다.
  3. 벽과 모서리: 벽을 뚫지 않고 통로에서 방향을 바꾸는지 확인합니다.
  4. 포획: 실제로 만나서 종료 판정이 일어나는지 확인합니다. 시간만 지나면 성공 표시가 뜨는 구현은 제외합니다.
  5. 원래 모드: 되돌리면 다시 노란 팩맨이 조종되는지 확인합니다.
  6. 실제 기록: 자동 시연인지 직접 입력인지 적고, 입력·캐릭터 위치·게임 상태를 함께 남깁니다.

저희 촬영에서는 자동 추격을 끈 상태로 브라우저 방향키를 입력했습니다. 기록상 첫 포획은 녹화 시작 약 5.92초에 발생했고 유령과 팩맨이 같은 통로에서 만났습니다. 릴스는 이 연속 플레이를 1.5배속으로 편집했습니다.

원래 모드와 유령 모드를 각각 실행해서 확인해줘.
입력 방향, 움직인 캐릭터 위치, 팩맨 자동 이동, 실제 충돌 상태를 기록해줘.
분석만 했는데 실행 검증했다고 쓰지 마.
자동 시연 영상과 실제 방향키 조종을 구분해줘.
실패하면 가장 작은 재현 상황부터 찾아 수정하고 다시 확인해줘.

6. 막혔을 때 확인할 것​

증상다음 요청
npx 또는 node를 못 찾음Node.js/npm 설치와 PATH부터 확인. 명령을 다시 붙여넣기 전에 실제 버전을 출력하도록 요청.
REA 도구가 안 보임설치 때 현재 AI를 선택했는지, 설정 저장에 성공했는지, AI를 완전히 재시작했는지 확인.
분석 엔진 경고지금 대상이 JavaScript인지 실행 파일인지 먼저 구분. 이 작업에 필요한 엔진만 준비.
게임은 보이는데 유령 조종이 안 됨키 입력 전달, 선택한 조종 캐릭터, 재시작 때 모드가 초기화되는지 확인. 실제 좌표 변화로 검증.
팩맨이 벽 앞에서 멈춤타깃·다음 방향·정지 상태·통로 판정을 확인. 임의 속도 증가로 덮지 않고 원인을 좁힘.
어느 파일을 고쳐야 할지 모름“게임 전체 분석” 대신 입력 또는 충돌 한 가지 기능과 근거 위치부터 조사.

재설치를 반복하기 전에 OS, REA 버전, 사용한 AI, 대상 종류, 실행 명령, 첫 오류 메시지를 모아 전달하세요. API 키나 개인 자료가 들어 있다면 오류 공유 전에 지웁니다. 업데이트가 필요한 경우 공식 설치·문제 해결 문서를 기준으로 현재 연결 설정을 확인한 뒤 진행하세요.

7. 영상에 나온 사례: 제작자의 공개 자료​

  • ReaCut: 캡컷 계열 중국판 젠잉을 조사해 만든 별도 영상 편집기입니다. 프로젝트와 분석 기록을 확인했습니다. 상용 앱 전체와 기능이 같다는 뜻은 아닙니다.
  • ChatGPT 배경 변경: 제작자의 REA 사용 설명과 결과 이미지를 확인해 소개했습니다. 저희가 같은 변경을 재현한 것은 아닙니다.
  • QuickTime → Tempo: 제작자 시연에서 속도 메뉴와 배속 조절 결과를 확인했습니다. REA 사용과 구현 과정은 제작자의 설명에 근거합니다.

다음 실습은 “앱 전체를 복제해줘”보다 “이 버튼의 저장 방식을 조사해줘”처럼 작게 시작해보세요. 질문 하나, 근거 하나, 작동 검사 하나를 끝내면 다음 기능으로 넓히기 쉽습니다.

8. REA 공식 사례에서는 무엇을 분석했나요?​

아래는 REA 공식 쇼케이스에 실린 조사입니다. 공식 문서에 공개된 분석 과정과 검증 설명을 확인했으며, 저희가 이 다섯 프로그램을 직접 재현한 것은 아닙니다. 앱 전체를 똑같이 만들었다는 사례와, 특정 기능 하나를 분석한 사례도 구분해야 합니다.

노션: 복사한 글의 서식은 어떻게 따라올까?​

노션의 화면에서 앱 내부를 거쳐 시스템 클립보드로 이어지는 복사 경로

REA 공식 노션 분석 페이지의 도표를 캡처했습니다. 실제 앱의 복사 동작을 설명하는 도표이며, 노션 앱 화면은 아닙니다. 공식 출처 보기 ↗

노션에서 문장을 복사하면 글자뿐 아니라 서식과 블록 정보도 함께 움직입니다. 공식 사례는 노션 데스크톱 앱에 들어 있는 JavaScript에서 복사 요청을 추적합니다. 화면 쪽 요청이 앱 내부 연결을 거쳐 시스템 클립보드에 글자와 HTML을 쓰는 경로, 그리고 블록 정보를 연결하는 표식을 설명합니다.

REA가 한 일: 읽기 어려운 코드에서 조사할 위치를 찾아주는 것. 이후 에이전트가 그 위치의 코드를 읽고 연결 관계를 설명했습니다. 노션 전체를 복제하거나 새 노션을 만든 사례는 아닙니다. 공식 분석: Notion

인증 앱 Aegis: 로그인 숫자는 왜 30초마다 바뀔까?​

공식 데모에서 시계를 60초로 옮기자 구간은 2, 인증 숫자는 359152로 표시되는 화면

REA 공식 웹 데모 캡처. 59초의 287082와 60초의 359152를 비교할 수 있습니다. 공개 테스트 키를 쓰는 데모이며 개인 계정의 인증 번호가 아닙니다. 공식 출처 보기 ↗

인증 앱에 뜨는 여섯 자리 숫자를 떠올리면 됩니다. 공식 사례는 안드로이드 설치 파일에서 숫자를 만드는 메서드를 찾고, 시간을 바꾸며 계산을 확인할 수 있는 데모로 원리를 설명합니다. 현재 시간이 어느 30초 구간에 속하는지가 계산에 들어갑니다.

공식 문서가 보고한 검증: 추출한 Java 메서드와 독립적으로 재구성한 계산을 133개 조건에서 비교했다고 설명합니다. 실제 안드로이드 앱은 코드를 읽는 방식으로 조사했다고 구분합니다. 공식 분석: Aegis

벽돌깨기 DX-Ball: 왼쪽 벽돌을 깨면 소리도 왼쪽에서 날까?​

DX-Ball 실행 파일에서 소리의 좌우 값을 계산하는 함수를 찾아 C 코드로 복원하고 검증하는 공식 도표

REA 공식 도표. 실행 파일 조사 → 계산 복원 → 원본과 비교 검증의 과정입니다. 게임 전체가 완성됐다는 의미는 아닙니다. 공식 출처 보기 ↗

공식 사례는 1996년 윈도 게임의 실행 파일에서, 벽돌의 가로 위치를 소리의 좌우 값으로 바꾸는 계산을 조사합니다. REA로 명령어와 호출 관계, 저장된 숫자를 읽고 작은 C 함수로 다시 작성한 과정입니다.

공식 문서가 보고한 검증: 원래 함수와 3,205개 조건에서 결과를 비교하고, 다시 컴파일한 함수의 63바이트도 맞췄다고 설명합니다. 플레이 가능한 게임 전체 복원은 계속 진행 중이라고 명시합니다. 공식 분석: DX-Ball

동방 TH04: 탄환은 어떻게 플레이어 쪽을 향할까?​

16발의 탄환 고리가 플레이어 방향에 따라 회전하는 모습을 비교한 공식 도표

REA 공식 도표. 기본 탄환 고리에 플레이어 방향을 더하면 어느 쪽을 향하는지 보여줍니다. 실제 게임 플레이 캡처가 아닌 설명 그림입니다. 공식 출처 보기 ↗

탄막 게임에서 총알 여러 개가 원을 그리며 플레이어를 향하는 장면입니다. 공식 사례는 옛 PC-98용 DOS 게임의 각도 계산 보조 함수를 조사해, 좌표와 곱셈·나눗셈이 읽을 수 있는 C++ 계산으로 이어지는 과정을 보여줍니다.

분석 범위: 탄환 방향을 정하는 함수입니다. 게임 전체를 새 플랫폼으로 옮긴 사례로 소개하면 범위를 과장하게 됩니다. 공식 페이지에서 단계별 계산과 탄환 고리 시각화를 볼 수 있습니다. 공식 분석: TH04

보너스: 정답 확인 프로그램의 규칙 거꾸로 풀기​

정답 검사 프로그램이 특정 칸을 골라 합을 확인하는 규칙을 보여주는 공식 도표

REA 공식 도표. 선택한 칸의 값이 정답 판정 계산에 어떻게 들어가는지 시각화한 그림입니다. 공식 출처 보기 ↗

보안 문제 풀이 대회인 DownUnderCTF의 예제에서는 프로그램이 정답을 판별하는 코드를 찾아 계산식으로 바꾸고, 구한 답을 원래 프로그램에 넣어 확인합니다. 게임을 바꾸는 일과는 다르지만, “규칙 찾기 → 설명하기 → 원본으로 검사하기”가 어떤 과정인지 보여줍니다. 공식 사례 목록에서 CTF 보기

처음 따라 한다면 노션처럼 익숙한 앱의 기능 하나를 질문으로 정해보세요. “앱 전체를 복제해줘”보다 “복사 버튼을 눌렀을 때 어떤 자료가 어디로 가는지 찾아줘”가 조사 범위와 성공 기준을 정하기 쉽습니다.

9. 공식 문서와 원본​

직접 확인한 범위: 공개 리메이크 분석, 역할 변경, 방향키 입력과 자동 이동, 실제 포획. 설치 안내는 공식 문서를 조사해 작성했으며, 모든 OS·AI 조합에서 새로 설치해 본 것은 아닙니다. REA 자체의 로컬 분석과 사용 중인 AI 서비스의 데이터 처리 정책도 구분해 확인하세요.