소스코드를 주지 않았는데 AI가 비슷한 앱을 만들어냈다면, 원본을 이해했다고 말할 수 있을까. 화면이 닮았다는 것과 데이터 구조·예외 처리까지 파악했다는 것은 다른 문제다.
Dante’s Datalab의 REA 실험은 이 차이를 보여준다. 제작자는 자신이 소스를 가진 자료 관리 앱을 분석하게 한 뒤, 별도 평가 에이전트로 원본과 결과물을 대조했다. 약 23분 만에 주요 기능을 재구현했지만, 결과는 완전 복제가 아닌 100점 만점의 74점이었다. 특히 잘못 해석한 근거 하나가 내부 설계를 다른 방향으로 이끌었다.
REA는 새로운 디컴파일러보다 ‘분석 도구를 연결하는 층’에 가깝다
REA는 Reverse Engineer Anything의 약자다. 공식 문서는 네이티브 바이너리, JavaScript·Electron 앱, 웹사이트 등을 조사하는 도구를 에이전트에 연결한다고 설명한다. 에이전트는 분석 결과를 읽고 다음 조사 대상을 정하며, 판단의 근거와 한계를 함께 남긴다.
따라서 REA가 Ghidra·Hopper·IDA를 모두 대체하는 새로운 분석 엔진이라는 이해는 정확하지 않다. 기존 분석 도구와 실행 관찰을 코딩 에이전트의 작업 흐름으로 묶는 쪽에 가깝다. Electron 앱의 정적 JavaScript 분석에는 네이티브 분석 엔진이 필요하지 않다는 점도 공식 문서에서 구분한다.
영상에서 중요한 용어는 Evidence다. 단순히 “이렇게 동작할 것 같다”고 답하는 대신, 어떤 파일·분석 결과·실행 관찰에서 판단했는지 기록한다. 다만 기록을 남겼다는 사실이 그 해석의 정확성까지 보장하지는 않는다.
원본 소스 접근을 막았지만, 배포된 앱 내부는 분석했다
실험 대상은 제작자가 수정 중인 Serpent 기반 자료 관리 앱이었다. 제작자는 원본 프로젝트 소스를 보유하고 있어, 분석 결과가 실제 구현과 맞는지 대조할 수 있었다. 상용 앱을 무단으로 복제하는 실험과는 출발 조건이 다르다.
실험은 세 역할로 나뉘었다.
- 준비 에이전트: 앱을 패키징하고 테스트 자료와 안내 문서를 준비했다.
- 분석 에이전트: 설치된 앱을 조사하고, 같은 사용자 기능을 하는 앱을 새로 구현했다.
- 평가 에이전트: 원본 소스와 재구현 코드를 모두 보고 동작과 근거를 비교했다.
분석 에이전트에는 원본 프로젝트 폴더, 외부 검색, GitHub 조회가 금지됐다. 반면 설치된 앱에 포함된 번들 코드와 디스크에 남는 파일은 조사할 수 있었다. ‘원본 소스를 주지 않았다’는 말은 ‘코드를 전혀 볼 수 없었다’는 뜻이 아니다.
엄격한 의미의 클린룸 개발과도 구분해야 한다. 이 실험에서는 분석 에이전트가 구현까지 맡았다. 영상 역시 분석자와 구현자를 분리한 방식이 아니라는 점을 밝힌다. 또 앱이 남긴 파일에서 원래 이름을 보게 됐으므로, 앱의 정체가 끝까지 완벽하게 가려졌다고 보기도 어렵다.
23분 만에 만든 것은 완성품이 아니라 주요 사용자 흐름이다
제작자의 공개 기록에 따르면 재구현에는 약 23분이 걸렸다. REA 호출은 9회였고, 결과물은 외부 패키지 없이 949줄의 코드로 구성됐다. 이 수치는 제작자의 해당 실행 기록이며, 여기서 별도로 재현한 벤치마크는 아니다.
원본은 Electron 데스크톱 앱이었지만, 재구현 앱은 Node.js 기반 서버와 브라우저 화면을 사용했다. 같은 기능을 반드시 같은 기술로 만들 필요는 없다는 접근이다.
라이브러리 열기, 자료 가져오기, 격자 표시, 태그, 검색, 상세 정보, 휴지통, 재시작 후 상태 유지 등은 동작했다. 반면 폴더·컬렉션·되돌리기 같은 기능과 일부 보기·필터는 빠졌다.
공개 채점표의 결과는 다음과 같다.
- 화면 구조: 16/20점
- 데이터 모델: 16/20점
- 주요 동작: 25/30점
- 예외 상황: 8/15점
- 코드 구조 유사도: 9/15점
- 합계: 74/100점
여기서 74점을 ‘완성도 74%’나 ‘어떤 앱이든 복제할 확률’로 읽으면 안 된다. 제작자가 정한 다섯 평가 항목에 따라, 평가 에이전트가 이 결과물에 부여한 점수다. 원본과 같은 내부 구조를 택했는지도 포함한 기준이므로, 일반적인 제품 품질 점수와도 다르다.
근거 24건 중 22건이 맞아도 설계는 틀릴 수 있다
이 실험에서 가장 눈여겨볼 대목은 속도보다 오류다. 원본 소스와 대조한 Evidence 24건 중 22건이 맞았고, 1건은 확인할 수 없었으며, 1건은 틀렸다.
문제가 된 항목은 Electron의 IPC 통신 해석이었다. 분석 에이전트는 채널 이름을 찾지 못한 상황을 실행 중 문자열 조합으로 해석했다. 이를 바탕으로 기능별 API를 새로 설계했지만, 원본에서는 컴파일 시점에 정해진 상수를 사용하는 구조였다.
중복 파일 처리에서도 차이가 드러났다. 재구현 앱은 파일 지문 정보를 저장했지만, 이를 중복 검사에 제대로 활용하지 못했다. 원본이 거르는 지원하지 않는 형식도 받아들였다. 정보를 발견하는 것과 그 정보가 필요한 이유를 구현하는 것은 별개였던 셈이다.
이 사례는 근거의 개수만 세는 검증이 충분하지 않음을 보여준다. 많은 항목이 맞아도, 설계의 핵심 가정 하나가 틀리면 결과물 전체의 방향이 바뀔 수 있다. 중요한 추론일수록 원자료와 실제 동작을 함께 대조해야 한다.
더 유용한 방향은 ‘복제’보다 이해와 기능 확장이다
제작자는 재구현 뒤 대본 문단을 넣으면 관련 자료를 찾아주는 패널을 추가했다. 태그·파일명·메모를 비교해 자료를 순위로 보여주는 기능이다. 기존에 만든 데이터 접근과 화면 동작을 재사용하면서 확장했다는 점이 핵심이다.
다만 시험 과정에서 붙인 태그가 검색 점수에 영향을 준 대목도 있었다. 새 기능이 돌아간다는 것만으로 추천 품질까지 검증된 것은 아니다. 실제 업무 데이터를 분리해 다시 시험해야 하는 이유다.
이 관점에서 REA를 검토할 만한 대상은 남의 상용 앱만이 아니다. 오히려 분석 권한이 분명한 다음 대상이 먼저다.
- 개발자가 떠나 내부 문서가 부족해진 자사 업무 프로그램
- 문서와 실제 응답이 달라진 내부 API
- 오래된 자체 파일 형식과 데이터 이전 작업
- 동작은 하지만 회귀 테스트가 부족한 기존 프로그램
목적을 “같은 앱 만들기”로 넓게 잡기보다, “검색은 어떻게 동작하는가”, “저장과 복원은 어떤 규칙을 따르는가”처럼 좁히면 검증 기준도 선명해진다.
그림판 11분 데모: ‘같은 앱’보다 ‘내가 원하는 기능’
성공지식백과의 추가 영상은 REA의 활용을 다른 방향에서 보여준다. 발표자는 윈도우 그림판을 바탕으로 간단한 그림판 형태의 앱을 재구현하고, 붙여넣은 이미지가 오른쪽 에셋 목록에 쌓이는 기능을 추가했다. 영상에서는 기본 그리기와 색상 변경·채우기, 이미지 붙여넣기를 직접 확인한다. 에셋 이름 변경, 재사용, 다운로드와 목록 삭제도 시연한다.
여기서 구분할 점은 기존 윈도우 그림판 제품 자체를 수정한 것이 아니라, 새로 만든 앱에 맞춤 기능을 붙였다는 것이다. 핵심은 원본과 완전히 같아지는 데 있지 않다. 익숙한 작업 흐름에 자신이 필요했던 기능을 결합하는 데 있다.
발표자는 약 11분 만에 결과물이 나왔다고 설명한다. 다만 이 영상에는 앞선 Serpent 실험처럼 원본 소스와 결과물을 대조한 채점표가 없다. 커서 표시 등 미완성 부분도 남아 있다. 짧은 시연에서 동작한 기능을 장기간 사용 가능한 제품 품질로 확대 해석하면 안 된다.
11분과 23분은 성능 순위를 뜻하지 않는다
두 영상은 같은 도구를 다루지만 서로 다른 것을 보여준다.
- 단테랩스의 약 23분 실험: 자료 관리 앱을 대상으로 원본 소스 접근을 제한했다. 별도 평가 에이전트가 원본과 결과물을 대조해 74점을 부여하고, 근거의 오류와 누락 기능을 공개했다.
- 성공지식백과의 약 11분 데모: 그림판 형태의 앱과 에셋 패널을 만들고 화면에서 주요 동작을 시험했다. 같은 평가 기준의 점수나 원본 소스 대조 결과는 제시하지 않았다.
대상 앱의 복잡도, 구현 범위, 실행 환경과 평가 방식이 다르다. 따라서 두 시간을 비교해 어느 에이전트가 더 빠른지, REA의 성능이 얼마나 향상됐는지 판단할 수는 없다. 전자는 이해의 정확성 검증, 후자는 개인 맞춤 기능을 만드는 활용 사례로 읽는 편이 적절하다.
일반인에게 낮아진 것은 분석의 진입장벽이다
추가 영상은 REA의 가치를 새로운 역공학 기술의 발명보다, 기존 도구를 접근하기 쉽게 연결한 데서 찾는다. 예전에는 분석 도구의 설치와 사용법을 따로 익혀야 했다면, 이제는 에이전트에 작업을 요청하는 흐름으로 시작할 수 있다는 관점이다.
그러나 ‘시작하기 쉬워졌다’와 ‘검토할 지식이 필요 없다’는 같은 말이 아니다. 발표자 역시 결과물을 읽고 이해하고 분석·검토할 정도의 학습이 필요하다고 강조한다. 앞선 IPC 해석 오류와 중복 파일 처리 실패가 그 이유를 보여준다.
실무에서는 처음부터 앱 전체를 맡기기보다 범위를 좁히는 편이 좋다. 분석 권한이 있는 프로그램에서 기능 하나의 입력·출력·저장 규칙을 확인하고, 그 설명과 근거가 맞는지 시험한 다음 확장한다. REA를 쓰지 않은 일반 코딩 에이전트와도 같은 과제를 비교해 보면, 추가 도구가 실제로 필요한지 판단하는 데 도움이 된다.
핵심 로직이 서버로 이동할 수 있다는 전망은 어떻게 읽을까
성공지식백과는 분석이 쉬워질수록 소프트웨어 회사가 핵심 로직을 앱 내부보다 서버 쪽에 두려 할 수 있다고 전망한다. 이용자 기기에 배포된 구현은 조사 대상이 될 수 있으므로, 제공 방식을 바꾸려는 유인이 생긴다는 해석이다.
이는 영상 발표자의 전망이지, 모든 앱이 서버 중심으로 바뀐다는 확정된 사실은 아니다. 설계 관점에서도 서버화는 운영비, 네트워크 지연, 오프라인 사용성, 개인정보와 접근 통제 등의 조건을 함께 따져야 한다. 서버에 있다는 이유만으로 모든 보안 문제가 해결되는 것도 아니다.
마찬가지로 ‘소프트웨어가 끝났다’거나 ‘대부분의 앱이 오픈소스가 된다’는 표현은 변화의 크기를 강조한 전망으로 읽어야 한다. 기능 구현이 쉬워지는 것과 유지보수·보안·지원까지 갖춘 제품을 지속 운영하는 것은 별개의 일이다. 분석할 수 있다는 사실이 해당 제품의 코드나 자산을 사용할 라이선스를 부여하지도 않는다.
개인 학습용이라면 언제나 괜찮다는 결론도 피해야 한다. 추가 영상의 활용 예시는 참고하되, 분석 목적과 권한·약관·라이선스는 기존 체크리스트에 따라 별도로 확인하는 것이 맞다.
웹앱 사례가 더해지면 보이는 차이: MathSheets는 무엇을 재현했나
AI with Hassan의 추가 영상은 Google Sheets의 화면과 기본 동작을 참고해 MathSheets라는 간단한 스프레드시트를 만드는 과정을 보여준다. 발표자는 웹앱 분석에 필요한 도구만 설치하고, 네이티브 바이너리 분석용 Ghidra·Hopper 같은 도구는 설치하지 않도록 요청한다.
이는 모든 대상에 같은 역공학 도구를 쓰는 것이 아니라, 웹에서 관찰할 수 있는 기능과 설치형 프로그램 내부 분석을 구분하는 접근이다. 브라우저 화면과 상호작용을 조사하는 것만으로 서버 내부의 구현이나 운영 구조까지 알아냈다고 볼 수는 없다.
영상에서는 셀 편집과 선택, 간단한 덧셈 결과를 시연한다. 발표자는 작업에 약 20~30분이 걸렸다고 설명하지만, 정확한 측정 기록이나 동일 과제의 반복 실험은 제시하지 않는다. 앞선 11분 그림판 데모나 23분 자료 관리 앱 실험과 시간을 직접 비교할 근거도 없다.
화면의 공유 버튼과 실제 공동작업 기능은 다르다
영상만 보면 Google Sheets와 매우 비슷한 화면이 완성된 것처럼 보인다. 그러나 제작자가 공개한 MathSheets 저장소의 README는 구현 범위를 더 구체적으로 설명한다.
- HTML·CSS·JavaScript로 만든 가벼운 스프레드시트이며, 앱 자체에는 서버가 필요하지 않다고 안내한다.
- 셀 참조와 범위, SUM·AVERAGE 등 일부 수식, CSV 내보내기를 지원한다고 설명한다.
- 데이터는 브라우저의 localStorage에 저장한다. 사이트 데이터를 지우면 사라지므로 보관할 자료는 CSV로 내보내라고 명시한다.
- Share와 Email은 ‘soon’으로 표시된 미구현 메뉴라고 안내한다.
따라서 이 사례를 Google Sheets의 공동 편집, 계정·접근 권한, 클라우드 저장과 운영 체계까지 복원한 결과로 읽어서는 안 된다. 공유 버튼이 보이는 것과 여러 사용자가 안전하게 같은 문서를 편집할 수 있는 것은 다르다. 위 기능 목록은 공개 문서에 따른 것이며, 여기서 해당 앱을 별도로 실행해 검증한 결과는 아니다.
REA 공식 저장소와 영상의 예제 저장소도 구분해야 한다. 전자는 역공학 도구이고 후자는 이를 활용한 학습용 결과물이다. 예제 README의 License 항목에는 아직 라이선스를 지정하지 않았다고 적혀 있다. GitHub에서 코드를 볼 수 있다는 사실만으로 자유로운 재사용·배포 조건이 확정되는 것은 아니다. 사용 시에는 해당 저장소의 최신 라이선스와 이용 권한을 따로 확인해야 한다.
멀티에이전트의 분업보다 먼저 정할 것은 검증 경계다
Hassan은 그리드와 수식 등 작업을 하위 에이전트로 나누는 흐름을 보여준다. 입력·선택 같은 화면 작업과 수식 해석을 분리하면 각 역할을 명확히 할 수 있다는 사례다. 다만 에이전트를 여러 개 썼다는 사실 자체가 더 빠르거나 정확하다는 검증은 아니다. 단일 에이전트로 같은 과제를 수행한 비교 결과는 제시되지 않는다.
스프레드시트를 업무에 쓰려면 화면 유사성 외에 다음과 같은 시험이 필요하다. 이는 영상이 모두 검증했다는 뜻이 아니라, 실제 사용 전 확인할 항목이다.
- 셀을 수정하면 이를 참조하는 다른 셀도 올바르게 다시 계산되는가?
- 빈 셀, 잘못된 수식, 순환 참조와 오류 값은 어떻게 처리하는가?
- 새로고침·브라우저 종료 뒤 데이터가 유지되고, CSV 내보내기와 다시 가져오기는 의도대로 동작하는가?
- 공동작업을 요구한다면 사용자별 권한, 동시 수정 충돌, 변경 기록과 복구를 별도로 구현·시험했는가?
REA가 돌려주는 근거와 아직 모르는 부분(unknowns)은 이 검증 계획의 출발점으로 볼 수 있다. 모르는 항목을 구현 완료로 취급하지 않고, 확인한 동작·추론한 구조·미구현 기능을 나눠 관리하는 것이다. 코드 생성을 여러 역할에 나누더라도, 최종 통합과 검증의 기준은 하나로 맞춰야 한다.
세 영상을 함께 보면 결론은 ‘어떤 앱이든 무료로 완벽 복제한다’가 아니다. 자료 관리 앱 실험은 분석 근거의 정확성, 그림판 데모는 개인 맞춤 기능 확장, MathSheets 사례는 화면·기본 동작과 서비스 전체의 차이를 각각 살펴보게 한다. 개발의 문턱이 낮아져도 어떤 문제를 해결하고 어디까지 신뢰할 수 있는지 판단하는 일은 남는다.
REA의 효과를 판단하기 전에 남는 세 가지 한계
첫째, 한 번 실행한 사례다. 대상 앱, 모델, 프롬프트, 테스트 데이터가 바뀌면 시간과 결과도 달라질 수 있다.
둘째, REA를 쓰지 않은 비교 조건이 없다. 이번 결과만으로 일반 코딩 에이전트보다 얼마나 나았는지, 어떤 성과가 REA 덕분인지 분리할 수 없다.
셋째, 평가에도 AI 에이전트를 사용했다. 원본 코드와의 대조는 유용하지만, 그 채점 자체를 독립적인 전문가 감사나 보안 검증과 같게 볼 수는 없다.
따라서 영상의 제목보다 실험 조건과 실패 장면을 함께 읽는 편이 도구의 쓸모를 판단하는 데 도움이 된다.
분석 권한과 라이선스는 도구 성능보다 먼저 확인한다
REA가 오픈소스라는 사실은 분석 대상 앱의 권리까지 열어주지 않는다. 분석할 권한, 대상 프로그램의 라이선스·약관, 코드와 이미지·아이콘 등 자산의 이용 범위는 각각 확인해야 한다.
영상은 국내 저작권법의 프로그램 관련 규정도 소개한다. 다만 기능 관찰, 코드 역분석, 호환성 확보, 결과물 배포는 목적과 범위가 서로 다르다. 이를 “역공학은 언제나 합법” 또는 “화면만 비슷하면 문제없다”로 단순화해서는 안 된다. 상용 앱 분석이나 결과물 배포를 계획한다면 구체적인 조건을 전문가에게 확인하는 편이 안전하다.
실험 전에는 다음 다섯 항목을 점검할 수 있다.
- 직접 만든 프로그램이거나 분석·활용 권한을 확인한 대상인가?
- 대상 프로그램과 분석 도구의 라이선스 조건을 각각 확인했는가?
- 원본 코드·디자인 자산을 무단으로 재사용하지 않는가?
- 분석 로그와 공개 화면에서 개인정보·비밀정보를 제거했는가?
- 관찰된 사실과 추론을 구분하고, 정상 동작뿐 아니라 예외 상황도 시험하는가?
REA 실험의 가치는 ‘앱 복사’라는 한 문장보다 크고, 동시에 그보다 제한적이다. 기존 프로그램을 이해하는 시간을 줄일 가능성을 보여주지만, 해석과 검증의 책임까지 없애주지는 않는다. 시작점은 권한이 분명한 프로그램의 작은 기능 하나를 이해하고, 근거와 테스트로 확인하는 일이다.
함께 읽으면 좋은 글
- Grokbot·Buzz·Hermes 비교: 에이전트 작업 환경의 선택 기준
- Buzz 오픈소스 AI 협업 툴: 역할을 나눠 에이전트와 일하는 법
- Grok Bot과 Herdr로 만드는 AI 에이전트 작업환경
FAQ
REA는 소스코드 없이 어떤 앱이든 완벽하게 복제하나요?
그렇게 확인된 것은 아니다. 영상은 원본 프로젝트 소스 접근을 막은 조건에서 주요 기능을 재구현한 단일 사례다. 설치된 앱의 번들 코드는 분석할 수 있었으며, 누락된 기능과 잘못된 내부 설계 해석도 있었다.
REA는 Ghidra나 IDA를 대체하나요?
공식 문서상 REA는 기존 분석 엔진과 여러 관찰 도구를 에이전트에 연결하는 층에 가깝다. 분석 대상과 환경에 따라 사용하는 도구가 달라진다.
23분과 74점은 REA의 일반적인 성능인가요?
아니다. 제작자가 정한 환경과 평가 기준에서 한 번 나온 결과다. 반복 실험이나 REA 미사용 조건과의 비교가 없어 보편적인 성능으로 일반화할 수 없다.
유료 앱을 구매했으면 역공학과 재배포도 자유로운가요?
구매만으로 모든 분석·재사용·배포 권한이 생긴다고 볼 수 없다. 관련 법과 이용 약관, 라이선스, 분석 목적과 범위를 따로 검토해야 한다.
그림판 11분 데모가 기존 23분 실험보다 뛰어난 결과인가요?
대상 앱과 구현 범위, 평가 기준이 달라 직접 비교할 수 없다. 그림판 데모는 맞춤 기능 확장의 예시이고, 기존 실험은 원본 소스와의 대조 및 누락 기능 검증에 초점이 있다. 두 영상 모두 단일 실행 사례다.
참고자료
본문 이미지는 원본 영상의 관련 장면을 설명·비평하기 위해 인용한 캡처다. 실험 수치와 평가 결과는 영상 제작자의 공개 기록에 따른 것이며, 별도의 재현 실험 결과가 아니다.