소스코드가 공개되지 않은 애플리케이션의 내부 동작을 인공지능(AI) 코딩 에이전트가 직접 조사하도록 돕는 오픈소스 프로젝트가 개발자 사회에서 큰 반향을 일으키고 있다. 깃허브에 공개된 'REA(Reverse Engineer Anything)'는 프로젝트 저장소에 "깃허브 스타 20만 개에 감사한다"는 문구를 내걸 만큼 빠르게 확산했다. 전문가 영역으로 여겨지던 리버스 엔지니어링(역공학)이 일반 개발자의 작업 흐름 안으로 들어왔다는 평가가 나온다.

소스코드가 화면에 채워진 모습컴파일되어 배포된 앱은 기계어 형태로 남지만, 분석 도구를 연결한 에이전트는 그 안의 규칙을 추적한다. 출처: NegativeSpace

에이전트와 분석 도구를 잇는 'MCP 가교'

REA는 앱을 직접 분해하는 프로그램이 아니다. 이미 존재하는 분석 도구들을 에이전트가 부릴 수 있도록 연결하는 중계 서버에 가깝다. 구현 방식은 MCP(Model Context Protocol)다. 에이전트가 로컬 서버를 통해 분석을 요청하면, REA가 대상 코드를 추적하고 그 근거와 함께 결과를 돌려주는 구조다.

공식 문서가 밝히는 지원 대상은 폭넓다. 네이티브 바이너리를 비롯해 자바스크립트·일렉트론 애플리케이션, .NET 어셈블리, 안드로이드 APK, 웹사이트, 펌웨어, SQLite 데이터베이스, WASM 아티팩트, EVM 바이트코드, 저장된 네트워크 패킷과 충돌 기록까지 포함된다.

대상별 요구 조건도 다르다. 네이티브 분석에는 Hopper, Ghidra, IDA 가운데 하나가 필요하고 웹사이트 분석에는 크롬 계열 브라우저를 쓴다. 반면 자바스크립트와 .NET 정적 분석은 별도 분석 엔진 없이 파일만 읽어 처리한다. 설치 후에는 Claude Code, Codex, Cursor, Gemini CLI 등 로컬 MCP 서버를 지원하는 에이전트에 등록해 사용한다.

REA는 대상 앱의 코드를 추적해 수도코드와 어셈블리, 호출 참조를 결과로 내놓는다. 출처: PickPik

결과에 '근거'와 '한계'를 함께 붙인다

REA가 다른 분석 흐름과 구별되는 지점은 결론의 형태다. 수도코드와 어셈블리 명령, 문자열과 심볼, 함수 호출과 참조를 제시하는 데 그치지 않고 아직 검증되지 않은 부분까지 함께 명시해 돌려준다. 에이전트는 이 결과를 받아 추가 질문을 던지거나 구현을 작성하고 시험하는 과정을 반복한다.

"앱에서 마음에 드는 기능이 있다면 에이전트에게 REA로 조사하게 하라. 소스코드 없이 그 기능이 어떻게 동작하는지 설명하고 근거를 보여준 뒤, 내 프로젝트용 구현을 만들어준다." (출처: REA 공식 저장소)

분석은 사용자 기기에서 이뤄진다. 다만 분석 결과는 다시 에이전트로 전달되므로, 그 이후의 처리 범위는 해당 AI 모델을 제공하는 사업자의 데이터 정책을 따른다는 점이 문서에 명시돼 있다. 로컬 실행이 곧 결과의 완전한 통제를 뜻하지는 않는다는 설명이다.

공개된 성과와 뚜렷한 한계

프로젝트가 공개한 대표 사례는 1996년에 나온 게임의 사운드 좌우 패닝 계산 함수를 되살린 작업이다. 원본 x86 코드에 대한 입력 3,205건을 통과했고, 재구성된 함수는 컴파일 결과 63바이트가 원본과 일치했다고 문서는 전한다. 노션의 복사·붙여넣기 처리 경로를 화면 계층에서 프리로드와 프로세스 간 통신(IPC)을 거쳐 시스템 클립보드까지 추적한 사례, 1990년대 PC-98 게임의 16비트 명령을 분석해 탄막 각도 계산을 복원한 사례도 함께 공개돼 있다.

이런 결과는 어디까지나 프로젝트가 보고한 사례라는 점을 감안해야 한다. 어떤 대상이든 완전히 재구성할 수 있다는 증명은 아니며, 대상 종류와 플랫폼, 의존 도구에 따라 제약이 뚜렷하다. 정적 분석과 실행 기반 분석의 위험도 다르다. 전자는 파일을 읽기만 하지만 후자는 사용자 권한으로 대상을 실행하거나 상호작용하므로, 출처가 불분명한 소프트웨어를 다룰 때는 두 방식을 구분해 접근해야 한다는 권고가 나온다.

책상에서 코드를 작성하는 화면분석 자동화가 진행될수록 결과를 읽고 검증하는 사람의 역할이 중요해진다는 지적이 나온다. 출처: Pixnio

'소프트웨어는 끝났다'는 말의 실체

확산 초기에는 위기감 섞인 반응이 앞섰다. 소프트웨어의 가치가 사라지는 것 아니냐는 우려다. 기술적 실체를 따져보면 REA가 동원하는 분석 엔진은 새로 발명된 것이 아니다.

Ghidra는 미국 국가안보국(NSA) 연구부서가 개발해 2019년 3월 공개한 소프트웨어 역공학 프레임워크다. 상용 도구인 IDA는 1990년대부터, Hopper는 2010년대 초부터 쓰여온 분석 도구다. REA는 이렇게 오래된 도구를 에이전트가 호출하기 쉬운 형태로 묶고, 조사 절차를 미리 정해 탐색 속도를 끌어올린 것에 가깝다는 분석이 나온다.

같은 맥락에서 '소프트웨어가 끝났다'는 표현은 과장이라는 시선도 적지 않다. 기능 구현의 진입 장벽이 낮아진 것과, 그 기능이 실제 서비스로 유지되는 것은 다른 문제라는 지적이다.

MIT 라이선스와 저작권법은 별개다

가장 혼동하기 쉬운 지점은 라이선스다. REA 자체는 MIT 라이선스로 공개돼 누구나 자유롭게 사용할 수 있다. 그러나 이 라이선스는 REA의 코드에만 적용된다. 분석 대상이 되는 상용 소프트웨어에 대한 권리까지 부여하는 것은 아니며, 별도로 사용허가를 받아야 하는 상용 분석 도구의 라이선스도 대신해 주지 않는다.

국내 저작권법은 프로그램 관련 권리를 따로 규정한다. 제101조의3은 시험·조사, 감정, 수업 목적 등 정해진 경우에 그 목적에 필요한 범위에서 프로그램을 복제하거나 배포할 수 있게 한다. 제101조의4는 호환에 필요한 정보를 쉽게 얻을 수 없고 그 획득이 불가피한 경우, 정당한 권한으로 프로그램을 이용하는 사람이 해당 부분에 한정해 프로그램코드역분석을 할 수 있도록 허용한다.

다만 같은 조 제2항은 이렇게 얻은 정보를 호환 목적 외의 다른 목적으로 이용하거나 제3자에게 제공하는 경우, 그리고 분석 대상 프로그램과 표현이 실질적으로 유사한 프로그램을 개발·제작·판매하는 데 이용하는 경우에는 그 정보를 쓸 수 없다고 못 박고 있다.

정리하면 개인적 조사나 호환 목적의 분석에는 허용 범위가 있지만, 상업적으로 판매되는 앱을 분석해 사실상 같은 프로그램을 만들어 유통하는 일은 법적 위험을 동반한다.

경쟁력은 어디로 이동하나

기능 복제 난이도가 낮아질수록 데이터와 운영 역량의 비중이 커진다는 전망이 나온다. 출처: PxHere

업계에서 나오는 전망은 일관된 방향을 가리킨다. 기능 자체를 복제하는 난이도가 낮아질수록, 독자적인 데이터와 도메인 지식, 사내 승인 절차와 연결된 업무 흐름, 결과의 품질과 고객 신뢰가 경쟁력의 중심으로 이동한다는 것이다. 화면과 개별 기능만으로는 제품의 우위를 지키기 어려워진다는 의미다.

기업이 핵심 로직을 클라이언트 앱에 담기보다 서버에서 처리하는 방식을 택할 수 있다는 관측도 제기된다. 동시에 AI가 만들어낸 결과를 읽고 이해하고 검증할 수 있는 기본 역량이 여전히 필요하다는 조언이 뒤따른다.

결론은 '아직 이르다'는 쪽에 가깝다. 화면을 따라 만드는 일은 이미 쉬워졌고 이제는 내부 동작까지 조사할 수 있게 됐지만, 원본 앱이 쌓아온 데이터와 신뢰까지 함께 복제되는 것은 아니기 때문이다.