sbjang
← 목록으로

REA

REA: 코딩 에이전트가 프로그램을 들여다보고 동작을 설명하게 한다

원문 보기

REA(Reverse Engineer Anything)는 코딩 에이전트에게 프로그램 분석 도구를 붙여 주는 오픈소스 프로젝트다. 소개 페이지는 REA가 하는 일을 “에이전트가 프로그램을 검사하고 그 동작을 설명할 수 있게 도구를 준다”라는 한 문장으로 요약한다. 사용자가 일상적인 말로 질문하면 REA가 명령어와 디컴파일 코드, 호출 관계를 찾아 넘기고, 에이전트가 그 결과를 읽어 동작을 설명하거나 같은 동작을 다시 구현한다. GeekNews에 GN⁺ 글로 올라온 것을 보고 원문인 rea.tools를 읽었다. GeekNews 글은 원문 요약과 함께 Hacker News 토론에서 나온 주요 의견을 정리해 두었다. 저장소는 GitHub의 morluto/rea이고 MIT 라이선스로 공개되어 있다. 소개 페이지에는 발행일이 없어서, 이 글의 날짜를 정한 근거는 글 끝에 따로 적었다.

REA가 에이전트에게 주는 것

설치 명령 npx rea-agents@latest setup은 두 가지를 함께 등록한다. 하나는 에이전트가 분석 도구를 호출하는 MCP 연결이고, 다른 하나는 그 도구로 조사를 진행하는 절차를 담은 조사 스킬이다. FAQ는 skills.sh에서 스킬만 설치해서는 부족하다고 따로 적어 둔다. 스킬은 조사 지침만 줄 뿐이고, 에이전트가 도구를 실제로 호출하려면 setup으로 MCP 서버까지 연결해야 한다는 설명이다.

REA는 자체 디컴파일러가 아니다. 네이티브 바이너리를 깊이 분석할 때는 사용자 컴퓨터에 설치된 분석 엔진 하나를 백엔드로 쓴다.

  • Ghidra: 12.1.x 설치본과 64비트 JDK 21 이상이 필요하다. Linux와 macOS(x64, arm64)에서 쓰고, Windows x64 지원은 고정 NTFS 드라이브에 있는 x86·x64 PE 파일을 읽기 전용으로 다루는 실험 단계다
  • Hopper: macOS와 Linux에서 쓴다. setup이 기존 설치를 찾거나 설치 계획을 제안한다. macOS에서는 데모 모드나 라이선스 활성화를 먼저 마쳐 두어야 사람이 지켜보지 않는 분석이 돌아간다
  • IDA: 검증된 구성은 Windows뿐이다. 이미 등록해 둔 IDA MCP 서버(실행 중인 GUI에 붙는 방식이나 헤드리스 데이터베이스 방식)를 REA에 알려 주는 식으로 연결하고, Linux와 macOS의 헤드리스 분석은 아직 검증되지 않았다

반면 JavaScript·Electron과 .NET 정적 분석은 주어진 파일만으로 동작하므로 이런 엔진이 필요 없다. 분석 대상은 크게 세 갈래로 나뉜다.

대상 REA가 돌려주는 것 필요한 것
네이티브 실행 파일·라이브러리 함수, 어셈블리, 의사 코드, 문자열, 참조, 호출 관계, 관련 상수 Ghidra, Hopper, IDA 중 하나
JavaScript·Electron 앱 앱 폴더나 ASAR 아카이브에서 찾은 모듈, 임포트, 라우트, IPC, 네이티브 의존성, 소스 위치 별도 엔진 없음
브라우저·런타임 활동 선택한 브라우저 페이지나 프로세스의 스크립트, 요청, 런타임 관찰 결과와 실행 사이의 비교 로컬 디버깅 연결

이 밖에 관리형 어셈블리, Android APK, 펌웨어, 패키지 리소스를 다루는 워크플로도 있다고 FAQ에 적혀 있다.

계산기 질문 하나로 보는 차이

소개 페이지는 리버스 엔지니어링을 “프로그램 자체를 살펴서 소프트웨어가 어떻게 동작하는지 알아내는 일”로 정의하고, 기능을 설명하거나 바꾸거나 다시 만들 수 있을 만큼 이해하는 것을 목표로 둔다. 그리고 질문을 하나 던진다. Windows 계산기에서 200 + 10%를 누르면 왜 220이 나올까?

사람이 직접 풀면 세 단계를 거친다. 페이지는 계산기 DLL에서 고른 x64 명령어를 보여 주고, 전문가가 할 법한 추론을 예시로 붙여 둔다.

  • 분기 해독: CMP EAX, 0x5c와 CMP EAX, 0x5b 뒤에 같은 주소로 뛰는 JZ가 하나씩 붙어 있다. 명령 ID를 찾아보면 0x5b는 나누기, 0x5c는 곱하기다
  • 호출 추적: MOV EDX, 0x64의 0x64가 100이라는 것은 바로 보이지만, CALL 뒤에는 주소만 있어서 어느 함수가 나누는지, 어떤 값이 들어가는지 알 수 없다. 보조 함수를 하나씩 열어 보고 저장된 값을 따라가야 한다
  • 규칙 복원: 덧셈 쪽 경로가 다른 입력을 곱한다는 것을 확인하면, + 뒤의 10%는 200의 10%(200 × 10 / 100 = 20)라는 결론에 이른다. 피연산자에 이름을 붙이고 두 연산자 경로를 모두 확인해야 작업이 끝난다

REA를 쓰면 이 과정이 프롬프트 하나로 줄어든다.

Use REA to inspect Windows Calculator. Why does 200 + 10% give 220?

REA는 % 버튼 핸들러의 명령어, 디컴파일 코드, 호출 관계를 넘기고, 에이전트는 어느 분기가 적용되는지, 무엇을 계산하는지, 어떻게 다시 만들지를 설명한다. 페이지에 실린 예시 답변은 “+ 뒤에서 % 버튼은 첫 번째 숫자의 백분율을 취한다. 200의 10%는 20이고 200 + 20 = 220이다”라는 내용이다. 다만 페이지는 에이전트의 생각과 답변이 분석 결과를 설명하려고 만든 예시라고 밝힌다. REA는 증거를 모으고 해석은 에이전트가 맡는 이 역할 분담이 뒤의 모든 예제에 그대로 이어진다.

예제 1: 크롬 공룡 게임은 왜 점점 빨라지나

첫 예제는 크롬 공룡 게임이 점점 빨라지는 이유를 찾고, 속도를 조절할 수 있는 미니게임으로 다시 만드는 것이다. 검사 대상은 wayou가 Chromium 코드에서 떼어 낸 브라우저판(BSD 라이선스)이다. REA는 로컬 디버깅 연결로 HTTP로 띄운 이 페이지에 붙어서, 실제로 로드된 index.js를 소스와 다이제스트까지 포함해 돌려준다. 에이전트가 그 안에서 찾은 갱신 함수의 핵심은 다음 세 줄이다.

if (this.currentSpeed < this.config.MAX_SPEED) {
  this.currentSpeed += this.config.ACCELERATION;
}

설정값은 SPEED: 6, ACCELERATION: 0.001, MAX_SPEED: 13이다. 속도 6에서 시작해 충돌 없이 갱신될 때마다 0.001씩 더하다가 13에 닿으면 더 오르지 않는다. 페이지는 이 규칙을 확인한 방법도 적어 두었다. 장애물과 자동 스케줄링을 끈 통제된 브라우저 검사에서 원본 게임의 갱신 함수를 직접 호출해 보니, 4,000회 뒤 속도는 10.0이었고 10,000회 뒤에는 13.0이었다(소수 첫째 자리 반올림).

새로 만든 미니게임은 이 속도 규칙만 원본에서 가져왔고, 그리기와 점프, 충돌 처리는 교육용으로 작게 새로 짠 코드다. 페이지 안에서 바로 플레이할 수 있고, 슬라이더로 속도를 바꿔 볼 수 있다.

예제 2: Windows 계산기의 % 버튼을 다시 만든다

두 번째 예제는 앞의 계산기 질문으로 돌아간다. 이번 목표는 + 뒤와 × 뒤에서 다르게 동작하는 % 버튼의 규칙을 모두 찾아, 두 경우를 올바르게 처리하는 작은 계산기를 만드는 것이다. 과정은 세 단계로 나뉜다.

  • calc.exe 읽기: calc.exe의 코드는 ms-calculator:를 열어 계산기 앱을 실행한다. 그래서 에이전트는 설치된 앱의 라이브러리로 대상을 옮긴다
  • 라이브러리 읽기: REA가 % 핸들러의 코드를 돌려준다. 이 함수는 연산자를 확인하고 상수 100을 쓴다
  • 해석과 재현: 에이전트가 분기를 Microsoft의 공개 소스와 대조한 뒤 두 규칙을 설명하고 구현한다

REA가 돌려준 원래 명령어 가운데 분기 부분은 다음과 같다.

0x180124945: MOV EAX, dword ptr [R13 + 0x18]
0x180124949: CMP EAX, 0x5c
0x18012494c: JZ 0x180124aba
0x180124952: CMP EAX, 0x5b
0x180124955: JZ 0x180124aba
0x18012495b: MOV EDX, 0x64

Microsoft 공개 소스의 정의를 보면 IDC_MUL이 92(0x5c), IDC_DIV가 91(0x5b)이고, 0x64는 100이다. 곱하기나 나누기 뒤라면 같은 주소로 뛰고, 그 밖의 연산자는 그대로 내려간다. 페이지의 설명대로라면 한쪽 분기는 100으로 나누기만 하고, 다른 쪽 분기는 첫 번째 숫자를 곱한 뒤 100으로 나눈다. 페이지가 정리한 읽기 쉬운 요약은 이렇다.

if (operation == multiply || operation == divide) {
  percent = current / 100;
} else {
  percent = current * previous / 100;
}

previous = 200, current = 10으로 두면, 덧셈 뒤에는 10 * 200 / 100 = 20이 되어 200 + 20 = 220이 나온다. 곱셈 뒤에는 10%가 0.1로 바뀌어 200 × 0.1 = 20이 나온다. 검사에는 REA 4.1.0과 Windows Calculator 11.2508.4.0 x64를 썼다. 요약 코드에 쓴 이름은 복원한 분기를 설명하려고 Microsoft 공개 소스에서 빌려 왔고, 페이지는 백분율 구현 코드와 Microsoft의 테스트 케이스 링크를 함께 걸어 두었다.

설치와 전제 조건

설치는 명령 하나로 끝난다. 터미널에서 직접 실행해도 되고, 코딩 에이전트에게 다음 프롬프트로 맡겨도 된다.

Install REA and connect it to this coding agent using
npx rea-agents@latest setup. Show me the setup plan for approval,
then verify the installation.
npx rea-agents@latest setup

setup은 클라이언트를 고르게 한 뒤, MCP 연결과 조사 스킬을 더하는 변경 계획을 보여 주고 적용하기 전에 승인을 받는다. 기존 설정은 백업해 둔다. 설치가 끝나면 에이전트를 다시 시작해야 도구가 보인다. 데스크톱 앱은 창만 닫아서는 안 되고 완전히 종료했다가 다시 열어야 한다.

  • Node.js: 22.19 이상, 24.11 이상, 26 이상 가운데 하나가 필요하다. 없으면 Node.js 24 LTS를 설치하라고 안내한다
  • 지원 클라이언트: 로컬 MCP 서버를 지원하는 에이전트면 된다. setup이 직접 다루는 목록에는 Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, Windsurf, Devin, OpenCode, Antigravity, GitHub Copilot CLI, Command Code, Grok Build, OMP, VS Code가 있다
  • 에이전트 없이 쓰기: CLI도 같은 분석 워크플로를 쓴다. Electron 앱 폴더나 .asar 파일은 analyze-javascript-application 명령으로 앱을 실행하지 않고 분석할 수 있다
  • 업데이트: 릴리스가 잦다. npm으로 CLI를 설치했다면 rea update를 실행하고, npx로 설정했다면 setup을 다시 실행한다. 에이전트에 등록된 REA 연결은 패키지 버전을 고정하므로, setup을 다시 해야 새 릴리스를 쓴다
  • 도구가 보이지 않을 때: doctor 명령으로 클라이언트별 등록 상태를 점검하고, 등록이 빠졌거나 낡았으면 그 클라이언트만 골라 setup을 다시 실행한다
  • 데이터: 분석은 사용자 컴퓨터에서 이루어진다. 다만 결과는 에이전트에게 넘어가므로 그 에이전트가 쓰는 모델 제공자의 데이터 정책을 따른다

릴리스가 잦다는 말은 실제 기록에서도 확인된다. 소개 페이지의 계산기 예제와 DX-Ball 사례는 REA 4.1.0(2026-10-06 릴리스)으로 기록했는데, 이 글을 쓰는 시점의 최신 릴리스는 닷새 뒤에 나온 6.4.0(2026-10-11)이다. 그 사이에 메이저 버전이 두 번 올랐으므로, 페이지에 실린 명령이나 출력은 지금 버전과 조금 다를 수 있다.

사례 연구: DX-Ball의 사운드 팬 계산

소개 페이지의 두 예제가 맛보기라면, 사례 연구 페이지에는 더 큰 작업이 실려 있다. 가장 자세한 사례는 1996년에 나온 Windows 게임 DX-Ball 1.07을 실행 파일에서 출발해 유지보수할 수 있는 C 코드로 다시 짓는 프로젝트다. 2026년 10월 7일 체크포인트 기준으로 관리하는 C 함수가 55개이고, 원본 코드와 45,380회 비교했으며, 그중 33개 함수는 컴파일된 바이트까지 원본과 같다.

사례 연구는 그 가운데 사운드 팬 계산 하나를 따라간다. 벽돌이 맞으면 그 가로 위치가 사운드 코드로 넘어가는데, 그 화면 좌표가 어떻게 좌우 패닝 값으로 바뀌는지 알아내는 것이 목표다. 처음 받은 0x406400 함수의 의사 코드는 인자 없이 __ftol()만 부르는 모양이었는데, 명령어 보기에는 스택 입력과 부동소수점 연산이 있었다. 이 불일치 때문에 에이전트는 조사를 이어 갔고, 질문 세 개를 REA로 풀었다.

  • 빠진 입력 찾기: analyze_function에 0x406400을 넘기자, 돌아온 명령어에서 디컴파일 결과에 없던 정수 입력 [EBP+8]이 드러났다
  • 호출한 쪽 따라가기: 첫 결과에 나온 호출자 0x411f40을 다시 analyze_function으로 열었다. 타일 좌표에 30을 곱하고 20을 더해 벽돌의 화면 좌표(20 + 30 × tile_x)를 넘긴다는 것이 보였다
  • 주소 뒤의 값 읽기: read_bytes를 두 번 호출해 0x420068, 0x420070, 0x4210a0에 든 바이트를 double로 해독했더니 1.5625, 500.0, 1.0이 나왔다

이 결과로 에이전트가 쓴 C 함수는 다음과 같다.

DxBallInt dxball_screen_pan(DxBallInt x)
{
  double pan;
  pan = (double)x;
  pan = pan * 1.5625;
  pan = pan - 500.0;
  pan = pan * dxball_pan_scale;
  return (DxBallInt)pan;
}

화면 좌표에 1.5625를 곱하고 500을 빼므로 화면 중앙인 320이 0이 되고, 배율이 1이면 왼쪽 끝은 -500, 오른쪽 끝은 500이 된다. 검증은 두 가지로 했다. 첫째는 원본 x86 함수를 실제로 실행해 반환값을 비교하는 동작 검사로, 0부터 640까지의 모든 정수 위치를 배율 0, 0.5, 1, 20, -1 다섯 가지로 돌린 3,205개 사례다. 둘째는 고정해 둔 VC4.0 툴체인으로 C 함수를 컴파일하고, 검토를 거친 재배치를 반영하고 참조 상수까지 확인한 뒤, 함수 전체 63바이트가 원본과 일치하는지 본 검사다.

나머지 사례도 같은 형식으로 정리되어 있다.

  • Aegis(Android APK): 배포된 APK에서 6자리 로그인 코드를 만드는 계산을 찾고, 데모 시계를 움직여 코드가 30초마다 바뀌는 이유를 보여 준다
  • DownUnderCTF(네이티브): 쉬운 CTF 문제의 검사 함수를 찾아 마스크와 합을 방정식으로 바꾸고, 풀어 낸 플래그를 원래 프로그램으로 확인한다
  • Notion(Electron): 패키징된 JavaScript에서 페이지에 노출된 API를 IPC 래퍼를 거쳐 시스템 클립보드까지 따라가고, 작은 HTML 표식이 리치 블록 데이터를 복사본에 이어 붙이는 방식을 설명한다
  • TH04(PC-98 DOS): 동방 프로젝트 4편의 16비트 각도 계산 보조 함수를 읽기 쉬운 C++로 옮기고, 플레이어를 겨냥한 탄환 고리가 만들어지는 과정을 보여 준다

블로그 에세이: 오라클도 검증해야 한다

REA 블로그에는 저장소의 주요 기여자인 N0zoM1z0이 2026년 10월 10일에 쓴 에세이 “The industrial revolution in reverse engineering”이 실려 있다. 글쓴이는 2026년 8월부터 에이전트가 이끄는 리버스 엔지니어링을 본격적으로 시도하며 동방 프로젝트 게임 세 편을 재구성했다. TH08은 GensokyoClub의 공개 재구성을 이어받아 8월 13일에 시작했고, 8월 19일에 식별된 게임 함수 1,107개 모두에 소스가 생겼다. TH095는 8월 29일에 확인된 함수 0개로 출발해 9월 10일에 플레이할 수 있는 Windows i386 재구성으로 표시되었다. TH04는 DOS 재구성이 동작하고, 지금은 64비트 네이티브 포트를 개발하고 있다.

에세이가 정리한 요점은 다음과 같다.

  • 조사는 에이전트에게 맡긴다: 사람은 목표와 합격 기준을 정하고, 다음에 무엇을 시도할지는 에이전트가 고른다
  • 저장소를 작업 기억으로 쓴다: 추론 근거와 검사를 코드와 함께 두고, 대화가 끝나도 다음 세션이 Git 체크포인트에서 이어 가게 한다
  • 증거가 주장을 정한다: 확신에 찬 설명도 검사를 거쳐야 하고, 근거가 모자라면 “모른다”도 유효한 답이다
  • 오라클도 검사한다: 통과하면 안 되는 사례를 일부러 넣어 보고, 오라클이 놓친 버그가 나오면 그 오라클에 기댄 이전 결과도 다시 확인한다

마지막 항목에는 구체적인 사례가 붙어 있다. 9월에 TH08 재구성을 가져다 쓴 Switch 포트에서 버그가 보고되었는데, 따라가 보니 아이템 자동 수집 조건이 플레이어 파워를 원본의 128.0(최대 파워 기준) 대신 0.0과 비교하고 있었다. 이 함수는 이미 완전 일치 비교를 통과한 상태였다. 비교 도구가 재빌드로 바뀐 상수 주소를 보정해 명령어 바이트를 맞추면서도, 그 주소에 실제로 든 부동소수점 값은 확인하지 않았기 때문이다. 9월 2일에 소스를 고치면서 비교 도구도 참조 상수의 실제 바이트를 보도록 바꿨고, 이어진 감사에서 부동소수점 리터럴 참조 1,548개를 다시 검사해 이미 승인된 함수 다섯 개에서 잘못된 참조 12개를 더 찾았다. 글쓴이는 에이전트가 쓴 코드를 한 줄씩 다 읽을 수 없으니, 검사가 실제로 무엇을 확인하는지 이해하는 일이 사람의 몫이라고 정리한다.

토론에서 나온 이야기

GeekNews 글은 원문 요약 뒤에 HN 토론(2026-10-13 확인 기준 783점, 댓글 329개)에서 나온 주요 의견을 정리해 두었다. 아래는 그 정리를 다시 의역한 것이다.

  • 디컴파일 품질: Touhou 4 디컴파일 결과가 원본과 일치하고 변수 이름과 주석도 명확해서, 지금까지 본 AI 디컴파일 결과보다 훨씬 낫다는 평가가 있었다. 다만 파일 구성이 원작 개발자의 설계보다 AI가 작업하기 편한 쪽에 맞춰져 있다는 아쉬움도 함께 나왔다
  • 취미와 공동체: 레트로 게임 이식과 디컴파일이 쉬워지면 이 분야의 취미가 줄어든다는 걱정과, 과정 자체를 즐기는 사람에게 AI는 그 즐거움을 대신하지 못한다는 반론이 맞섰다. AI가 협업할 동기를 줄여 공동체를 고립시킨다는 우려에는, 공동체가 사라지는 것이 아니라 재편되는 중이라는 의견이 붙었다
  • 진입 장벽: 저수준 프로그래밍이나 리버스 엔지니어링에 익숙하지 않던 사람도 게임 수정과 확장에 도전할 수 있게 되었다는 긍정적인 평가가 있었다
  • 모델별 거부 반응과 안전장치: 같은 리버스 엔지니어링 요청에도 모델마다 반응이 달라서, DRM이나 라이선스 검사와 관련된 작업은 거부당하거나 하위 모델로 내려야 했다는 경험담이 나왔다. 사이버 보안용 안전장치가 보안과 무관한 정당한 리버스 엔지니어링까지 막는다는 비판도 있었다
  • 기존 방식과의 비교: 최상위 모델이 바이너리에서 버그 위치를 찾아 패치한 사례가 여럿 소개되었고, Ghidra 헤드리스 모드와 Frida를 활용한 경험도 나왔다. 그래서 Claude에게 Ghidra 환경을 직접 맡기는 방식보다 REA가 얼마나 나은지는 의견이 갈렸다. 이미 작업 흐름이 있는 사람에게는 큰 차이가 없다는 의견과, 초보자에게는 진입 장벽을 낮춰 준다는 의견이 함께 나왔다
  • 상용 소프트웨어 복제: Photoshop이나 Office 같은 상용 앱을 바이브 코딩으로 복제하는 영상이 늘면서, 법적 위험과 클린룸 방식의 중요성이 언급되었다. Adobe의 경쟁력은 기능만이 아니라 신뢰성과 지원에 있다는 지적도 있었다

공동체를 둘러싼 갈등은 앞의 에세이에도 직접 나온다. TH08의 토대가 된 GensokyoClub은 README 공지에서 AI 디컴파일과 포트가 자신들의 작업을 가져다 쓰는 상황을 강하게 비판하고, 완성할 때까지 개발을 비공개로 진행하며 주로 AI로 만든 풀 리퀘스트는 받지 않는다고 밝혔다. N0zoM1z0은 그들의 노력을 존중하며 이어받은 작업의 기록과 공로를 그대로 보존했다고 적는다. 그리고 의견이 갈리는 지점은 재구성을 어떻게 진행하고 기여를 무엇으로 판단하느냐에 있다고 정리한다.

읽고 남는 것

REA는 새로운 분석 엔진이 아니다. 디컴파일은 Ghidra, Hopper, IDA가 하고, REA는 그 결과를 MCP 도구로 감싸서 에이전트가 함수 하나, 호출자 하나, 바이트 몇 개 단위로 물어볼 수 있게 만든다. 어떤 순서로 조사할지는 스킬에 담았다. HN에서 Ghidra를 직접 맡겨도 되지 않느냐는 반응이 나온 것도 이 구조 때문일 것이다. 대신 REA가 공을 들인 곳은 검증으로 보인다. 계산기 예제는 Microsoft 공개 소스와 테스트 케이스로, 공룡 게임은 원본 갱신 함수를 통제된 환경에서 돌린 수치로, DX-Ball은 3,205개 동작 사례와 63바이트 일치로 결과를 확인한다. 여기에 에세이의 “오라클도 검증하라”까지 겹쳐 보면, 에이전트가 그럴듯한 설명을 내놓게 하는 것보다 그 설명을 원본과 대조하는 절차를 갖추는 쪽이 이 도구의 핵심이라고 읽힌다. 다만 무엇을 분석해도 되는지는 여전히 도구가 아니라 사용자가 판단해야 한다. 공개 소스가 있는 계산기나 BSD 라이선스로 풀린 공룡 게임과 달리, 상용 앱을 들여다보고 복제하는 일은 라이선스와 클린룸 문제를 피해 갈 수 없다.

원문: REA · Reverse Engineer Anything (REA. 페이지에 발행일이 없어, Hacker News 게시글이 올라온 2026-10-10 00:37 UTC와 같은 날 등록된 GeekNews 글, 같은 날짜가 적힌 블로그 에세이를 근거로 글의 날짜를 정했다. 이 날짜는 REA가 HN과 GeekNews에 소개된 날이고 사이트가 처음 열린 날은 아니다. 저장소는 2026-04-14에 만들어졌고, 페이지의 예제는 2026-10-06에 나온 4.1.0으로 기록되어 있다. 한국어 페이지는 기계 번역이 어긋나 있어서(예: + 뒤와 × 뒤를 비교하는 문장에서 ×가 “2018 년 11 월 13 일” 같은 날짜로 바뀌어 있다) 이 글은 영문판을 기준으로 적었다. 설치와 분석 조건은 FAQ와 설치 가이드, 사례 수치는 DX-Ball 사례 연구에서 가져왔다. HN 점수와 댓글 수, 릴리스 정보는 2026-10-13에 확인한 값이다)