REA는 소프트웨어를 어떻게 분석할까

앱의 내보내기 버튼을 눌렀는데 파일이 보이지 않습니다. 저장 위치를 찾고 싶지만 설명서에는 없고, 내부 코드도 익숙하지 않습니다. AI에게 화면만 보여 주면 몇 가지 가능성을 말할 수는 있겠지만, 그 앱이 실제로 어느 코드를 거쳐 어디에 파일을 쓰는지까지 알아내려면 조사할 수단이 필요합니다.

REA(Reverse Engineer Anything)는 AI 에이전트에 그 수단을 연결하는 도구입니다. 기존 앱과 실행파일, 웹페이지를 조사해 관련 코드와 연결 관계, 관찰 결과를 제공합니다. AI는 이 근거를 따라 동작을 설명하거나 필요한 구현을 제안할 수 있습니다. REA 공식 프로젝트

흥미로운 점은 새로운 코드를 만드는 앞단에 기존 소프트웨어를 이해하는 조사 과정이 들어간다는 것입니다. 개발자에게는 익숙하지 않은 프로그램을 살펴볼 방법이 늘어나는 이야기이고, 동시에 자신이 하던 분석과 구현의 일부를 AI가 어디까지 수행할지 궁금해지는 변화이기도 합니다.

REA를 향한 관심은 자연스럽게 “내가 원하는 프로그램도 다시 만들 수 있을까”라는 질문으로 이어집니다. 계산기와 업무 앱의 작은 동작부터 GTA 같은 큰 게임까지, 공개된 근거가 뒷받침하는 범위는 제각각입니다. 무엇을 분석했고 무엇을 실제로 검증했는지 알아야 가능성과 과장을 가를 수 있습니다. 여기에 결과물을 공개할 권리가 있는지도 별도로 따져야 합니다.

REA가 AI에게 연결하는 것

완성된 프로그램을 조사해 구조와 규칙을 거꾸로 알아내는 일을 역공학, 영어로 리버스 엔지니어링이라고 합니다. 개발자가 쓴 소스코드가 그대로 있다면 읽어 볼 수 있지만, 배포된 실행파일에는 컴퓨터의 실행 명령만 남고 변수 이름과 주석, 설계 의도가 사라진 경우도 있습니다.

REA는 이런 대상을 분석하는 도구와 AI 에이전트를 연결합니다. 에이전트는 요청을 받아 여러 작업을 이어 가는 AI입니다. Claude Code나 Codex 같은 에이전트가 질문을 해석하고 REA를 호출하면, REA가 조사 결과를 돌려주고 에이전트가 후속 질문이나 구현을 진행합니다. 연결에는 MCP라는 규격을 사용하며 터미널에서 직접 분석할 수도 있습니다. REA의 구조와 사용 방식

대상에 따라 얻는 자료도 다릅니다. 실행파일에서는 기계 명령과 사람이 읽기 쉽게 풀어 쓴 의사코드, 특정 처리를 맡는 코드 묶음인 함수 사이의 연결 등을 조사합니다. JavaScript·Electron 앱에서는 코드 모듈과 메시지 전달 경로를, 웹페이지에서는 스크립트와 관찰한 요청 등을 살펴봅니다. 실행파일의 깊은 분석에는 Ghidra·Hopper·IDA 같은 별도 분석 도구가 필요할 수 있습니다. 분석 대상별 요구 조건

역할을 나누어 보면 REA를 어디에 쓰는지 명확해집니다. 에이전트는 조사할 질문과 다음 행동을 고릅니다. REA는 분석·관찰 도구를 통해 근거를 제공합니다. 대상에 맞는 분석 엔진은 실행 명령을 풀어 읽는 등의 작업을 담당합니다. 결과를 실제 개선에 쓸 때는 그 프로젝트의 실행 환경과 검사 방법도 필요합니다.

핵심 비교
구분	역할	설명	예시
AI 에이전트	질문을 해석하고 조사를 이어 갑니다	관련 처리를 더 찾거나 가설을 바꾸고, 모은 근거로 설명과 구현을 제안합니다.	이 코드가 저장 처리와 어떻게 연결되는지 후속 조사
REA	분석·관찰 근거를 전달합니다	대상 파일과 실행 상태에 맞는 도구를 연결하고 코드 위치·관계·관찰 결과를 제공합니다.	함수 호출 관계, 파일 위치, 관찰한 요청
분석 엔진	대상에 맞는 전문 분석을 수행합니다	깊은 실행파일 분석에는 별도로 준비한 도구를 사용할 수 있습니다. 모든 대상에 같은 엔진이 필요한 것은 아닙니다.	Ghidra·Hopper·IDA 등의 실행파일 분석

따라서 REA가 돌려준 의사코드를 원래 개발자가 작성한 소스코드 그대로라고 받아들이면 안 됩니다. 분석기가 풀어 쓴 결과가 불완전할 수도 있습니다. 관련 코드를 더 읽고 입력과 결과를 확인하면서 설명을 다듬어야 합니다.

버튼 하나를 코드와 연결하는 과정

공식 첫 조사 예제는 작은 Notes 앱의 내보내기 기능을 다룹니다. 질문은 간단합니다. “Export notes를 누르면 어떤 파일이 어디에 만들어질까요?”

답을 찾으려면 버튼이 부르는 처리에서 시작해 중간 메시지를 지나 실제 파일을 쓰는 코드까지 따라가야 합니다. 예제에서는 내보내기 요청이 notes:export라는 메시지로 전달되고, 처리 코드가 메모를 CSV로 바꿔 사용자의 다운로드 폴더에 notes.csv를 쓰는 경로로 이어집니다.

여기서 유용한 답은 저장 위치만 적은 한 문장이 아닙니다. 버튼의 요청, 요청을 받는 처리, 파일을 만드는 코드 위치가 서로 연결된 설명입니다. 그래야 저장 위치를 바꾸거나 오류를 조사할 때 다시 확인할 출발점이 생깁니다.

코드를 읽어 내린 예측과 실행 결과도 구분해야 합니다. 예를 들어 메모 제목에 쉼표가 들어가면 CSV에서 열이 나뉘지 않도록 처리하는지 궁금해집니다. 공식 예제는 이런 입력을 넣어 형식 변환 코드를 실행하고 예측과 결과를 비교하는 단계로 이어집니다.

이 예제에서 저장 위치는 관련 코드를 읽어 확인하고, CSV 형식 변환 규칙은 작은 입력을 넣어 실행해 검사합니다. 앱 전체의 내보내기 과정을 실행한 검사와는 범위가 다릅니다. 어떤 설명을 코드로 확인했고 어떤 예측을 실행으로 확인했는지 나누어 읽는 것이 중요합니다.

실제 앱에서 무엇을 확인했을까

계산기의 퍼센트 규칙

계산기에 200 + 10%와 200 × 10%를 넣으면 퍼센트를 다루는 규칙이 다릅니다. 앞에서는 200의 10%인 20을 더해 220이 되고, 뒤에서는 10%를 0.1로 바꿔 곱하므로 20이 됩니다.

REA 공식 설명은 설치된 Windows 계산기의 코드를 분석하고 Microsoft의 공개 소스와 대조해 이 두 규칙을 설명합니다. 분석할 함수 후보를 고르는 과정에는 사람의 도움도 들어갔습니다. 홈페이지의 작은 계산기는 찾아낸 규칙을 시연하는 별도 데모입니다. 분석 근거와 범위

REA 공식 사이트에서 퍼센트 계산 규칙을 설명하고 작은 계산기로 시연하는 화면 — REA의 공식 설명 데모입니다. Windows 계산기 자체의 화면은 아닙니다. 출처 · Copyright (c) 2026 morluto · MIT

이 사례에서 확인할 것은 버튼의 외형보다 연산자에 따라 달라지는 규칙입니다. 눈에 보이는 같은 % 버튼에도 서로 다른 조건이 들어 있고, 그 조건을 코드와 대조해 설명할 수 있습니다. 완전 자율로 계산기 전체를 만들었다는 성과로 확대할 필요는 없습니다.

Notion의 복사 경로

Notion 사례에서는 데스크톱 앱 패키지에서 복사 요청이 전달되는 경로를 추적했습니다. 화면 쪽 API에서 중간 연결 코드를 지나 운영체제의 클립보드에 글과 HTML을 쓰는 처리까지 이어집니다.

사용자에게는 한 번의 복사 동작이지만, 내부에서는 여러 코드가 메시지를 주고받습니다. REA의 분석 결과에서 시작 위치를 찾고 그 연결을 따라가면, 어느 처리에서 어떤 데이터를 전달하는지 설명할 수 있습니다.

확인한 범위는 이 클립보드 경로입니다. 이 결과만으로 클라우드 저장이나 공동 편집, 권한 관리까지 이해했다고 말할 수는 없습니다. 코드 위치를 찾았다는 성과와 서비스 전체를 파악했다는 주장을 구분해야 합니다.

DX-Ball의 소리 계산

고전게임 DX-Ball의 공식 사례에서는 벽돌이 깨진 가로 위치를 소리의 좌우 치우침으로 바꾸는 함수를 조사합니다. 처음 나온 의사코드에는 중요한 입력과 계산이 제대로 드러나지 않았습니다. 실제 기계 명령과 이 함수를 부르는 코드, 실행파일에 저장된 숫자를 더 조사해 규칙을 찾아냈습니다.

이어 재구현 프로젝트는 원래 함수와 3,205개 입력 경우의 결과를 비교했습니다. 정해진 주소 차이를 보정한 뒤 컴파일된 63바이트 분량의 실행 명령도 일치시켰습니다. 이는 특정 계산을 검증한 결과이며 게임 전체의 완성을 뜻하지 않습니다.

이 사례가 보여 주는 장점은 불완전한 첫 설명을 더 조사할 수 있다는 것입니다. 에이전트가 반환된 의사코드에서 멈추지 않고 다른 근거를 읽고, 찾아낸 규칙을 비교 가능한 코드로 구체화한 과정에 의미가 있습니다.

GTA 재구현은 어디까지 확인됐을까

GTA에 REA를 활용한다고 밝힌 프로젝트는 실제로 있습니다. 개발자 SebasKitten의 Grand-V 설명 문서는 REA를 기반으로 삼았다고 명시하며, GTA V의 브라우저 실행과 로컬 자체 호스팅을 소개합니다. 웹에서 프로그램을 실행하는 WebAssembly와 그래픽을 처리하는 WebGPU를 사용한다는 설명도 있습니다. Grand-V의 공개 설명

다만 이 주장을 읽을 때는 공개 범위를 함께 봐야 합니다. 위 링크로 고정한 버전의 저장소에는 설명 문서와 로고 파일만 있습니다. 이 저장소에는 구현 소스나 검사를 재현할 자료가 없어, REA가 어느 분석에 기여했는지와 원본의 동작을 얼마나 구현했는지까지 독립적으로 확인하기 어렵습니다. 문서에 적힌 Story 모드나 실험적 멀티플레이 설명을 GTA V 전체의 완성·호환성에 대한 검증으로 읽어서는 안 됩니다. 해당 버전의 공개 파일

여기서 ‘로컬’이라는 말도 범위를 좁혀 읽어야 합니다. 자기 컴퓨터에서 호스팅한다는 설명만으로 온라인 인증이나 외부 서버 의존성이 모두 사라졌다는 뜻이 되지는 않습니다. 실행 환경을 마련하는 일, 원본의 규칙을 새로 구현하는 일, 원본의 이미지·음악·맵 같은 게임 자산을 구하는 일은 서로 다른 작업입니다. Grand-V도 독점적인 게임 자산을 제공하지 않으며 사용자가 필요한 파일을 정당하게 확보해야 한다고 밝힙니다.

따라서 “REA를 활용해 GTA를 다루려는 사람이 있다”는 말에는 근거가 있습니다. “REA만 있으면 원하는 모든 게임을 완전한 오프라인 게임으로 만들 수 있다”는 결론까지 뒷받침하지는 않습니다. 이 차이는 규모만의 문제가 아니라, 분석할 수 있는 자료와 검증할 수 있는 동작의 차이이기도 합니다.

분석 결과에도 경계가 있습니다

REA로 무엇을 알아낼 수 있는지는 분석 대상과 제공한 자료에 달려 있습니다. 지원하는 대상이라는 사실만으로 모든 내부 동작이 자동으로 확정되지는 않습니다.

앱에서 보이는 정보와 서버의 내부 정보

내 컴퓨터에 있는 앱의 코드와 서비스 회사 서버에서 실행하는 코드는 위치가 다릅니다. REA의 브라우저 분석 안내가 다루는 자료는 페이지 구조와 스크립트, 관찰한 네트워크 요청과 실행 결과 등입니다.

따라서 앱이나 페이지에서 관찰한 응답만으로 서버의 전체 코드, 비공개 데이터, 모델 가중치까지 확보했다고 말할 수는 없습니다. 이 자료로 설명할 수 있는 부분과 별도의 접근·자료가 필요한 부분을 구분해야 합니다.

예를 들어 가상의 편집 앱에서 자르기와 붓칠은 로컬 코드가 처리하고, 별도 생성 기능은 서버에 요청한다고 해 보겠습니다. 두 기능이 같은 화면에 있어도 조사할 수 있는 내부 정보의 범위는 다릅니다. 서버에 어떤 요청을 보냈는지 안다는 것과 서버가 결과를 만드는 과정 전체를 안다는 것은 다릅니다.

가상 앱의 로컬 작업 화면과 별도 서버를 나누어 화면에 드러난 동작과 원격 내부 정보의 차이를 설명한 장면 — 같은 화면의 기능이라도 로컬 코드와 서버 내부를 조사할 수 있는 범위는 다릅니다. 실제 제품 화면이 아닌 개념 재구성입니다.

연결을 찾은 것과 실제로 실행된 것

코드를 읽어 가능한 처리 경로를 찾는 분석과 앱을 실행해 그 경로가 사용되는지 관찰하는 일도 구분해야 합니다. 특정 조건에서만 활성화되는 기능이라면 평소 화면만으로는 동작을 확인하기 어려울 수 있습니다.

REA의 JavaScript·패키지 분석 문서는 확정한 관계와 추론을 구별합니다. 실행 중에 정해지는 메시지 이름이나 모호한 연결, 누락된 구성 요소는 미확인 상태로 남을 수 있습니다.

좋은 분석 결과에는 이런 빈칸도 남아 있어야 합니다. “저장에 관련된 후보 코드가 있다”, “이 입력에서 그 처리가 실행됐다”, “다른 입력에서도 같은 규칙을 쓴다”는 각각 다른 근거를 요구합니다. 불분명한 부분을 숨긴 매끄러운 설명보다, 어디를 더 확인해야 하는지 알려 주는 답이 후속 작업에 유용합니다.

검증을 통과했는데 동작이 틀렸던 사례

공식 사이트에 소개된 동방영야초(TH08) 재구현 작업에서는 아이템 자동 수집 조건이 잘못된 문제가 보고됐습니다. 플레이어의 파워를 128.0과 비교해야 하는 조건 하나가 0.0으로 복원돼 있었습니다. 특정 높이 위에서 최대 파워가 아니어도 해당 조건을 통과할 수 있게 된 것입니다. 버그 보고

같은 가상 슈팅게임에서 아이템이 너무 일찍 기체로 모이는 왼쪽과 아직 남아 있는 오른쪽을 비교한 장면 — 수집 조건 하나가 어긋나면 아이템 이동도 달라집니다. 실제 게임 화면이 아닌 원리 재구성입니다.

문제의 함수는 이미 원본과의 비교를 통과했습니다. 당시 검사기가 메모리 주소의 차이는 보정했지만 그 주소에 저장된 고정 숫자, 즉 상수의 실제 값까지 확인하지 않았기 때문입니다. 수정 기록은 소스를 고치고 상수도 검사하도록 보완했으며, 일부러 틀린 값을 넣었을 때 거부하는 검사도 추가했습니다.

이 문제는 REA 본체의 결함으로 확인된 사건이 아니라, 분석을 바탕으로 만든 코드와 그것을 판정하는 검사기의 한계를 보여 줍니다. 분석 근거가 있다는 것, 그 근거를 올바르게 해석했다는 것, 새 구현이 실제로 같다는 것은 각각 확인할 일입니다.

DX-Ball에서 작은 계산을 비교한 결과도 같은 기준으로 읽을 수 있습니다. 비교한 입력에서는 어떤 값이 나왔는지, 실행 명령을 비교할 때 어떤 차이를 보정했는지까지 알아야 그 검증의 범위가 드러납니다. 통과 횟수만으로 검사하지 않은 조건까지 보장할 수는 없습니다.

로컬 실행이면 저작권 문제도 사라질까

REA로 동작을 알아낼 수 있다는 사실과 그 결과를 이용할 권리는 별개입니다. 프로그램의 원리를 조사하는 일, 그 원리를 참고해 새 코드를 쓰는 일, 원본의 코드·이미지·음악을 가져와 배포하는 일은 같은 판단을 받지 않습니다.

한국 저작권법에는 정당한 권한으로 이용 중인 프로그램의 아이디어와 원리를 조사하기 위한 복제 예외가 있습니다. 가정과 같은 한정된 장소에서 개인적인 비영리 목적으로 복제하는 예외도 있지만, 권리자의 이익을 부당하게 해치는 경우까지 허용하지는 않습니다. 개인이 자기 컴퓨터에서 하는 작업과 다른 사람에게 나누어 주는 작업을 같은 조건으로 볼 수 없는 이유입니다. 저작권법 제101조의3

프로그램 코드를 역분석하는 예외에는 더 구체적인 조건이 붙습니다. 정당한 이용 권한이 있고, 호환에 필요한 정보를 쉽게 얻을 수 없으며, 그 정보를 얻기 위해 역분석이 불가피한 경우 필요한 부분에 한정됩니다. 이렇게 얻은 정보를 호환 외의 목적으로 쓰거나 제3자에게 제공하는 일, 원본과 표현이 실질적으로 유사한 프로그램을 만드는 데 이용하는 일도 제한됩니다. 정품을 샀다는 사실이 모든 재구현을 허용하는 면허는 아닙니다. 제101조의4

게임은 코드 밖의 표현도 중요합니다. 대법원은 게임의 개별 요소뿐 아니라, 요소를 선택·배열하고 유기적으로 조합한 창작적 표현도 저작권 판단에 포함했습니다. AI가 코드를 새로 썼거나 그림 일부를 바꿨다는 이유만으로 원작과의 권리 문제가 사라진다고 단정하기 어렵습니다. 반대로 흔한 규칙이나 아이디어를 참고한 모든 게임이 곧 침해라는 뜻도 아닙니다. 무엇이 창작적 표현이고 무엇을 가져왔는지가 핵심입니다. 대법원 2017다212095 판결

인증이나 복제 방지 장치를 건드린다면 기술적 보호조치 규정도 별도로 봐야 합니다. 법은 무단 무력화를 금지하면서 호환을 위한 역분석 등 일정한 예외를 함께 둡니다. ‘로컬 실행’, ‘무료 배포’, ‘정품 보유’라는 조건 하나로 이 쟁점들이 한꺼번에 해결되지는 않습니다. 저작권법 제104조의2

기업은 무엇을 막고 무엇을 실험할까

역공학 도구의 발전에 기업이 대응하는 방식은 제품과 사업에 따라 달라집니다. 게임 데이터를 보호하기 위해 접근을 제한하는 사례와, 새로운 실행·창작 방식을 직접 탐색하는 사례가 함께 나타납니다.

Riot은 메모리 접근을 제한했습니다

Riot Games는 2026년 10월 6일부터 알 수 없는 서드파티 앱의 게임 메모리 접근을 기본 차단한다고 공지했습니다. 실행 중인 게임의 내부 데이터를 외부 도구가 읽거나 바꾸는 통로를 제한하는 조치입니다. 회사는 AI를 활용한 역공학의 발전으로 치트와 봇 등의 악용이 늘었다고 이유를 설명했습니다. Riot 공식 공지

Riot의 공식 주먹 마크와 게임 메모리 접근 제한 공지의 제목·게시자가 보이는 화면 — 외부 도구의 게임 메모리 접근을 제한하는 정책의 공식 공지입니다. Riot Support

기존 승인 도구에는 2027년 4월까지 유예를 두고 공식 API로 옮기도록 했습니다. API는 회사가 허용한 방식으로 데이터를 요청하는 통로입니다. 필요한 데이터를 대체할 수 없으면 일부 도구의 기능이 사라질 수 있다고도 안내했습니다. 악용을 줄이려는 제한이 정상적인 도구의 개발 방식에도 영향을 줄 수 있다는 사례입니다.

Riot은 경기 리플레이 파일의 공유 범위도 좁히려 했습니다. 리그 오브 레전드의 26.20 패치 노트는 자신이 참가하지 않은 경기의 리플레이와 외부 앱·사이트의 다운로드 접근을 제한한다고 예고했습니다. 본인이 참가한 경기의 클라이언트 내 다운로드·시청은 유지한다는 내용입니다. 이후 10월 7일 공식 계정은 코치와 크리에이터의 영향을 줄일 방안을 마련하기 위해 이 변경을 26.21 패치로 연기한다고 밝혔습니다. 최초 패치 안내, 후속 연기 공지

배포에 대한 이의 제기는 REA 이전에도 있었습니다

Take-Two가 GTA III·Vice City의 역공학 프로젝트인 re3·reVC 관련 저장소에 삭제를 요구한 일은 2021년에도 있었습니다. GitHub의 공개 기록에는 삭제 통지와 이의 통지, 이후 소송 통지가 남아 있습니다. 재구현 결과가 공개되는 단계에서 권리자가 대응한 선례입니다. GitHub에 공개된 Take-Two 통지와 처리 기록

저장소가 내려갔다는 사실 자체를 법원의 침해 확정 판단으로 읽어서도 안 됩니다. 권리자의 주장, 플랫폼의 삭제 절차, 법원의 판단은 구별해야 합니다. GitHub의 DMCA 처리 절차

Xbox는 활용 가능성을 탐색합니다

Xbox는 2026년 10월 13일 XBOX LABS를 발표하며, 최근 게임을 다른 하드웨어나 브라우저에서 실행하고 다른 게임과 섞는 실험을 직접 언급했습니다. 오래된 게임에 새 생명을 주고 이용자가 창작에 참여할 가능성을 탐색할 작은 조직을 만든다는 내용입니다. Xbox 공식 발표

XBOX Wire 마크와 Introducing XBOX LABS라는 발표 제목, Asha의 이름과 발표일이 보이는 공식 기사 화면 — XBOX LABS를 소개한 공식 발표 화면입니다. Asha · XBOX Wire

Xbox는 이런 실험을 추진하면서도 지식재산에 대한 책임을 유지하겠다고 명시했습니다. 기존 자산과 권리를 관리하면서 기술의 활용 가능성도 살펴보겠다는 선택입니다.

이 사례들을 바탕으로 보면 앞으로의 쟁점은 무엇을 막을지와 무엇을 허용된 통로로 제공할지에 놓일 가능성이 있습니다. 회사는 무단 접근과 침해 배포에 대응하면서, 공식 API·창작 도구·이용 허락의 범위를 정비하는 선택을 함께 검토할 수 있습니다.

한 동작을 조사하며 시작하는 방법

예를 들어 분석 권한이 있는 사내 판매관리 앱에서 CSV 내보내기 규칙을 문서화하는 상황을 가정해 보겠습니다. 화면의 버튼을 누르면 파일은 나오지만, 취소 거래가 들어가는지와 금액을 언제 반올림하는지가 불분명합니다. 다음은 실제 실행 결과가 아닌 요청 설계 예시입니다.

제가 분석 권한을 가진 판매관리 앱의 복사본을 지정하겠습니다.
REA로 '판매내역 CSV 내보내기'가 어떻게 작동하는지 조사해 주세요.

열과 순서, 취소 거래, 반올림, 한글 인코딩 규칙을 찾고
각 설명에 관련 코드 위치와 근거를 붙여 주세요.
코드에서 추론한 부분, 실행으로 확인한 부분,
아직 알 수 없는 부분을 구별해 주세요.

정상 거래 외에 취소 거래, 쉼표가 있는 상품명, 한글 이름으로
설명을 확인할 입력과 예상 결과를 먼저 제안해 주세요.
이번 조사에서는 운영 데이터를 변경하지 않겠습니다.

답이 “쉼표를 구분자로 씁니다”에서 끝났다면 더 물어볼 수 있습니다. 상품명 머그, 대형의 쉼표는 어떻게 처리하는지, 따옴표를 붙이는 코드가 어디인지 요청하는 것입니다. 이어 샘플 파일을 실제 사용할 스프레드시트에서 다시 열어 상품명이 한 셀에 남는지 확인할 수 있습니다.

취소 거래가 빠지는 규칙을 찾았다면 정상 판매만으로 검사해서는 부족합니다. 취소 전후의 같은 거래를 넣어 어느 단계에서 제외되는지 비교해야 합니다. 설명과 결과가 다르면 코드를 다시 조사하고 문서를 고칩니다. 기능을 개선할 때도 이 입력과 기대 결과를 따로 보존하면 기존 규칙을 실수로 바꾸는지 확인할 기준이 됩니다.

CSV 내보내기 동작을 조사하는 순서

질문과 범위분석 권한이 있는 앱의 복사본과 샘플 데이터, 확인할 내보내기 동작을 정합니다.
코드와 근거REA로 처리 경로를 조사하고 추론·관찰·미확인 조건을 구별합니다.
경계 입력취소 거래와 쉼표·한글이 든 이름으로 설명의 예측과 실제 결과를 비교합니다.
설명과 개선어긋난 규칙을 다시 조사하고 문서를 고칩니다. 후속 변경에는 비교 기준을 남깁니다.

처음 연결하는 독자는 공식 시작 안내와 작은 Notes 조사 예제를 함께 볼 수 있습니다. Windows·macOS·Linux와 분석 대상에 따라 준비할 도구가 다르므로 해당 환경의 절차를 따라야 합니다. 예제의 한 질문을 이해한 뒤 자기 앱의 한 동작으로 범위를 바꾸는 편이 접근하기 쉽습니다.

실제 자료를 분석할 때는 데이터와 권한의 경계도 함께 확인해야 합니다. REA는 로컬에서 대상을 분석하지만 결과는 에이전트로 전달되며 모델 공급자의 데이터 정책이 적용됩니다. 사내 자료를 다룬다면 분석 결과를 그 모델에 보내도 되는 범위를 정해야 합니다. REA 데이터 안내

또한 도구의 MIT 라이선스와 분석 대상의 이용 권리는 별개입니다. REA 사용 원칙은 권한 있는 분석 등을 목적으로 들며 보호된 코드·자산의 복제와 DRM·라이선스 검사 우회를 지원하지 않는다고 명시합니다. 파일을 갖고 있다는 사실만으로 분석과 재배포의 권한을 함께 판단해서는 안 됩니다.

소프트웨어를 이해하는 방식의 변화

화면이나 동작 설명을 주고 “이런 기능을 만들어 줘”라고 요청하면 AI는 주어진 정보를 바탕으로 구현을 제안할 수 있습니다. REA와 AI 에이전트를 함께 쓰면 여기서 한 걸음 더 들어갑니다. REA가 실제 프로그램의 코드와 연결 관계, 관찰 결과를 제공하고, 에이전트는 그 근거를 읽어 다음 조사를 이어 가거나 구현을 제안합니다. 겉으로 보이는 결과를 설명하는 데서 프로그램 내부의 근거를 함께 조사하는 데까지 요청의 범위가 넓어지는 것입니다. REA의 작동 방식

계산기의 퍼센트 규칙이나 Notion의 복사 경로는 이 조합이 무엇을 할 수 있는지 보여 줍니다. 동시에 TH08의 검사 오류와 Grand-V의 공개 범위는 분석 근거를 얻는 것과 완성된 소프트웨어를 검증하는 일 사이의 거리를 보여 줍니다. 무엇을 확인했고 무엇이 남았는지, 결과를 어떤 권한으로 이용할 수 있는지까지 함께 봐야 합니다.

개발자로서는 이런 도구가 반갑습니다. 사람이 단서를 찾아 읽고, 그 의미를 해석해 다음 조사로 연결하던 과정의 일부를 AI 에이전트와 함께할 수 있기 때문입니다. 문서가 부족하거나 동작을 이해하기 어려운 프로그램을 다룰 때, 추측을 확인할 구체적인 출발점이 생긴다는 것만으로도 도움이 될 것 같습니다.

그런데 소프트웨어를 만드는 입장에서는 조금 복잡한 마음도 듭니다. 제가 다른 프로그램을 더 쉽게 이해할 수 있다면, 누군가도 제가 만든 프로그램의 동작을 더 쉽게 분석하고 재현할 수 있겠다는 생각이 들기 때문입니다. 시간을 들여 쌓은 구현과 규칙이 어디까지 드러날 수 있을지, 제품을 만들고 지키는 방식은 어떻게 달라질지 궁금하면서도 걱정됩니다.

동작을 알아내는 것과 같은 품질의 제품을 만드는 일 사이에는 여전히 거리가 있습니다. 그 차이를 알면서도 REA와 AI의 조합을 마냥 가볍게 받아들이기는 어렵습니다. 개발을 돕는 좋은 도구가 나왔다는 반가움과, 그 기술이 제가 만드는 소프트웨어에도 똑같이 적용될 수 있다는 긴장감이 함께 남습니다.

VIEW—