"뭐든 역설계한다"는 화제의 GitHub 저장소, 직접 써 봤어요

한 줄 요약

요즘 화제인 깃허브 저장소 'Reverse engineer anything(REA)'을 Nick Saraev가 직접 써 보고, Mac 미리보기 앱을 REA를 쓴 쪽과 안 쓴 쪽으로 나눠 재현해 비교해요. Nick은 도구가 쓸 만하긴 해도 새롭지는 않고, 진짜 변화는 소프트웨어 자체가 상품이 되는 흐름이라고 봐요.

전체 내용 정리

REA는 오래된 역공학 도구를 AI 에이전트에 연결해 주는 MCP예요

REA는 MCP의 일종이에요. 실제 앱의 소스 코드를 디컴파일한 뒤 AI 에이전트에게 그 기능을 재현하거나 복제하는 방법을 알려 줘서, 사실상 원하는 소프트웨어를 다시 만들 수 있게 해 줘요. 애플 TV 리모컨을 약 45분 만에 리버스 엔지니어링한 데모가 돌았고, X에서는 포토샵 제품군 전체를 복제할 수 있겠다는 사람까지 나왔어요.

반응도 뜨거워요. Matthew Berman은 REA 때문에 기존 소프트웨어 방식은 끝났다고 했고, Replit CEO 암자드(Amjad)는 "이건 미친 짓"이라며 조만간 거의 모든 소프트웨어가 오픈소스가 될 거라고 했어요. Nick은 소프트웨어를 개발해 본 사람으로서 이런 우려에 깊이 공감한다면서도, 사실인지 판단하려면 먼저 알아야 할 게 있다고 말해요.

작동 방식은 단순해요 — 묻고, 도구에 보내고, 반복해요

흐름은 이래요. 사람이 에이전트에게 "이 기능은 어떻게 작동하지?", "이 앱을 리버스 엔지니어링해 줄 수 있어?"라고 물어요. 에이전트는 REA MCP에 요청을 보내고, REA는 그 요청을 Ghidra(2019년 출시), Hopper(2011년경), IDA(90년대 출시) 같은 도구 모음에 전달해요. REA 라이브러리는 에이전트가 이 도구들과 매끄럽게 통신하도록 이어 주는 역할이에요.

에이전트는 Chrome 개발자 도구 같은 서비스로 앱을 더 살펴본 뒤 결과를 내놔요. 결과에는 보통 의사 코드(pseudo code, 실제 코드가 아니라 작동 방식을 상위 수준에서 설명한 것), 근거, 그리고 아직 모르는 요소가 담겨요. 에이전트는 이걸 받아 앱 전체를 다시 만들 때까지 회전목마처럼 반복 작업을 해요.

시작도 쉬워요. 에이전트에게 "REA를 다운로드하고 끝나면 알려 줘"라고 말하면 끝이에요. Nick은 터미널을 여러 개로 빠르게 나눌 수 있는 Orca라는 터미널 관리자를 쓰는데, 한쪽에는 Claude를, 다른 쪽에는 Codex를 띄우는 식이에요. 물론 꼭 이렇게 할 필요는 없고 원하는 앱을 쓰면 된대요.

Mac 미리보기 앱을 두고 REA를 쓴 쪽과 안 쓴 쪽이 대결했어요

Nick은 설치가 끝난 뒤 새 Claude 세션에서 "REA를 써서 내 Mac의 미리보기 앱을 다시 만들어 줘"라고 시켜요. 미리보기는 사진을 띄우고 정보 버튼, 확대·축소 같은 기능이 있는 작은 앱이죠. 직접 다시 만들 수도 있지만 레이아웃이나 디자인이 마음에 들거나 박스 그리기, 손글씨 같은 기능을 그대로 쓰고 싶을 때 REA 같은 도구가 쓸모 있다는 설명이에요.

그리고 동시에 다른 Claude에게는 REA 없이 같은 앱을 만들게 했어요. REA 쪽은 Ghidra로 디컴파일을 마치고 절반쯤 진행한 상태였는데, 먼저 완성한 건 라이브러리 없이 작업한 Opus였어요. REA 버전은 3~4분 정도 더 기다려야 했고, 여러 탭을 열고 닫으며 테스트를 거친 뒤에야 나왔어요.

결과는 꽤 좋았어요. REA가 만든 앱은 Nick 컴퓨터의 미리보기 앱과 거의 똑같았어요. 한쪽이 훨씬 길게 보이는 게 가장 큰 차이 같다고 했고 정보 표시, 확대·축소, 공유, 그림 그리기, 회전, 주석을 멈추고 파일로 저장하는 기능까지 됐어요. 그림 그리는 속도는 오히려 다른 앱보다 훨씬 빨랐대요.

그런데 Nick은 "전혀 새로운 기술이 아니다"라고 봐요

Nick이 짚는 문제는 다들 이걸 엄청나게 새로운 기술처럼 대한다는 점이에요. Ghidra는 2019년부터 있었고 미국 국가안보국(NSA)이 공개한 도구예요. Hopper 디스어셈블러도 최근 것이 아니고, IDA는 좀 더 현대적이긴 해도 아주 오래전에 나왔어요. REA가 하는 일은 기본적으로 AI 에이전트가 이 도구들에 아주 간단한 인터페이스로 접근하게 해 주는 것뿐이라는 거예요.

Nick은 아직 제대로 된 데모를 보지 못했다고 해요. 그래서 이번 일을 인터넷 여론이 조금 앞서 나간 사례로 봐요. 물론 '토니 호크의 프로 스케이터', '헤일로 3', '모던 워페어', '룬스케이프'를 합친 게임 같은 멋진 결과물도 나왔고, Nick 자신도 며칠 전 '마인크래프트'와 '진격의 거인'을 섞은 게임을 만들어 봤대요. 그래도 진짜 돌파구라기보다는 유행에 가까운 현상이라는 판단이에요.

근거 중 하나가 깃허브 스타 그래프예요. REA를 다루는 거의 모든 영상이 최근 며칠 새 치솟은 스타 수 그래프로 시작하거든요. Nick은 스타 수 말고 할 말이 없다면 그냥 멋진 데모를 보여 주면 되지 않느냐고 되물어요. 그 자체의 가치보다 사람들의 인식만 이야기하고 있다는 거죠. 본인 표현으로는 "꼰대 같은 생각"이래요.

진짜 변화는 소프트웨어가 상품이 되는 흐름이에요

더 넓게 보면 Nick은 대부분의 소프트웨어가 오픈소스가 될 것이라고 봐요. 특정 앱과 그 구현 방식이라는 층에서, Claude나 Codex처럼 즉석에서 소프트웨어를 다시 만들 수 있는 범용 지능의 층으로 한 단계 올라섰기 때문이에요. 그래서 대부분의 프론트엔드와 백엔드도 이미 그렇지 않더라도 곧 고도로 상품화될 거라고 해요. Nick은 이걸 기회와 가용성의 '캄브리아기 대폭발'이라고 불러요.

다만 사업가 관점에선 닫히는 문도 많대요. 특정 앱을 리버스 엔지니어링하는 게 아니라 지난 몇 년간 이어진 기술 흐름 이야기예요. Claude나 Codex를 감싸 기능을 덧붙인 래퍼(wrapper) 앱들은 사실상 전부 디자인 업데이트나 대화형 설명 업데이트를 통해 모델 자체에 흡수됐어요. 가치 사다리가 이동한 거죠.

좋아하는 앱을 리버스 엔지니어링해서 '블랙햇 월드' 같은 곳에 팔아 단기 이득을 볼 수는 있겠지만, Nick은 분명히 심각한 지적재산권 제한에 부딪힐 거라고 봐요. 이걸로 대단한 사업을 하겠다는 것보다, 기존 아이디어를 조합해 멋진 결과물을 만드는 진입 장벽이 낮아졌다는 점이 더 중요하대요. 멋진 데모로 X(트위터) 트렌드에 오르는 문턱도 같이 낮아졌고요.

사실 REA 없이도 에이전트에게 말만 하면 돼요

Nick은 분명히 말해요. 앱을 따라 만들려고 꼭 역공학 도구를 쓸 필요는 없대요. 에이전트에게 "XYZ 앱의 XYZ 기능이 정말 마음에 들어. 어떻게 작동하는지 알아내서 리버스 엔지니어링해 줄래?"라고 하면, 에이전트가 자체 스크린샷 도구로 페이지를 가로지르는 애니메이션이든 복제하고 싶은 무엇이든 찍어서 알아서 해 줘요. 에이전트는 자기 추론만으로도 어떻게 해야 할지 이미 알고 있다는 거예요.

완벽하게 똑같이 복사할 수 있을까요? 아마 아닐 거래요. 그래도 복제하려는 기능 상당수는 사람이 직접 쓴 것보다 AI가 쓴 쪽이 더 효율적이어도 전혀 놀랍지 않다고 해요. 기본 Claude Code만으로도 꽤 근접하게 구현할 수 있고요. Nick은 한두 달 안에 Claude Code에 이런 리버스 엔지니어링 기능이 직접 들어가지 않더라도, 지속적인 사후 학습으로 대부분의 작업을 스스로 하게 될 거라고 봐요.

Ghidra나 IDA 같은 구성 요소 앱이 다 필요한지도 확실하지 않대요. 재현 속도에 도움이 됐으니 꽤 중요하긴 하다고 인정하면서요. REA로 어떤 앱이든 그럴듯한 시각 요소와 백엔드 유사물을 만들 수 있지만, 순수 에이전트만으로도 아마 3분의 2 정도의 시간 안에, 혹은 더 빨리 시각적으로 구현할 수 있다는 게 Nick의 판단이에요. 그래서 그의 마지막 말은 이거예요. "리버스 엔지니어링 시대를 준비하세요."

핵심 인사이트

• 화제성 지표와 실제 데모를 구분해서 보세요: Nick이 REA 열풍을 유행에 가깝다고 보는 근거 중 하나는 "다들 깃허브 스타 그래프부터 보여 준다"는 점이에요. 스타 수 말고 할 말이 없다면 그냥 멋진 데모를 보여 주면 된다는 거죠.
• 도구를 연결하는 층보다 모델 자체가 빠르게 일을 흡수해요: 미리보기 앱 대결에서 라이브러리 없는 Opus가 먼저 끝났어요. Nick은 Ghidra나 IDA 같은 구성 요소 앱이 다 필요한지도 확실하지 않고, Claude Code가 지속적인 사후 학습으로 대부분의 작업을 스스로 하게 될 거라고 봐요.
• "따라 만들기"가 쉬워질수록 가치는 조합과 맥락으로 옮겨가요: Nick은 앱을 복제해 팔면 지적재산권 제한에 부딪힐 거라고 봐요. 그보다 기존 아이디어를 조합해 멋진 결과물을 만드는 진입 장벽이 낮아졌다는 점이 더 중요하다는 게 Nick의 판단이에요.

오늘 당장 해볼 것

1. 평소 마음에 들었던 앱이나 웹사이트 기능 하나를 골라 Claude Code에 "이 기능이 어떻게 작동하는지 알아내서 비슷하게 만들어 줘"라고 시켜 보세요. 별도 도구 없이 어디까지 나오는지 보면 Nick이 말한 "에이전트만으로 충분하다"를 직접 확인할 수 있어요.
2. 같은 작업을 두 세션에 나눠, 하나는 특정 도구(MCP)를 쓰게 하고 하나는 쓰지 않게 해서 속도와 결과를 비교해 보세요. 새 도구를 들일지 판단하는 가장 확실한 기준이 돼요.
3. 지금 쓰고 있는 유료 SaaS 중 "Claude나 Codex 같은 모델 위에 기능 하나 덧붙인" 서비스가 있는지 목록을 만들어 보세요. 모델이 그 기능을 흡수하면 구독을 정리할 후보가 되고, 반대로 내가 그런 서비스를 판다면 대비가 필요하다는 신호예요.