REA가 보여 준 것, 앱을 통째로 복제하는 시대에 기획자는 무엇을 지켜야 할까

 

이번 주에 REA라는 오픈소스를 둘러싼 이야기가 많이 보였습니다.

정식 이름은 Reverse Engineer Anything이고, 줄여서 REA라고 부릅니다.
이미 만들어진 소프트웨어를 AI 에이전트가 뜯어보고, 같은 기능을 다시 만들어 주는 도구라고 소개되고 있어요.
해외에서는 "소프트웨어는 끝났다"는 반응까지 나왔다고 합니다.

 

저는 개발자가 아니라 기획자라서, 이 소식이 신기하다는 마음과 걱정스럽다는 마음이 동시에 들었습니다.
그래서 오늘은 기획자의 관점에서 이 도구가 무엇인지, 무엇이 걱정되는지, 그리고 그렇다면 무엇을 지켜야 하는지를 길게 정리해 보려고 해요.
정리에는 REA의 GitHub README와 이 도구를 직접 써 보며 소개한 유튜브 영상(성공지식백과 채널)을 참고했습니다.
저는 이 글을 쓰는 시점에 직접 돌려 보기보다는 README와 영상을 보며 이해한 내용을 바탕으로 썼다는 점을 먼저 밝혀 둘게요.

 

REA는 무엇인가

README는 REA를 "바이너리, 애플리케이션, 런타임 동작을 아우르는 리버스 엔지니어링용 MCP 하나"라고 소개합니다.
리버스 엔지니어링은 소스 코드가 없는 소프트웨어를 거꾸로 분석해서 어떻게 동작하는지 알아내는 일이에요.
MCP는 AI 에이전트가 외부 도구를 호출할 수 있게 해 주는 연결 방식입니다.
그러니까 REA는 에이전트가 분석 도구를 대신 쓰게 해 주는 연결 장치라고 이해하면 됩니다.

README에 나온 분석 대상은 꽤 넓습니다.
네이티브 바이너리, 자바스크립트와 일렉트론 앱, 웹사이트, 네트워크 캡처, .NET 어셈블리, 안드로이드 앱, 펌웨어 같은 것들이 줄줄이 적혀 있어요.
사용하는 개발자라면 터미널에서도 쓸 수 있고, 클로드 코드나 코덱스, 커서, 제미나이 CLI 같은 에이전트에 설정을 붙여서 쓸 수도 있다고 합니다.

개발 쪽 내용을 조금만 옮겨 보면 설치와 사용은 이런 식입니다.

npx rea-agents setup
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json

 

첫 줄은 에이전트에 REA를 연결하는 설정이고, 둘째 줄은 자바스크립트 애플리케이션을 분석하는 명령입니다.
README에 따르면 분석은 로컬에서 실행되고, 결과에는 결론의 근거와 한계가 함께 담긴다고 해요.
REA가 직접 만든 코드는 MIT 라이선스이고, 안에서 쓰는 제3자 도구는 각자의 라이선스를 따른다고 합니다.

 

 

구조는 어떻게 되어 있나

영상에서는 구조를 개념도로 설명했습니다.
이 흐름을 제가 이해한 대로 글로 풀어 쓰면 이렇습니다.

사람이 에이전트에게 요청한다 ("이 앱의 이 기능을 똑같이 만들어 줘")
      ↓
에이전트가 REA(MCP)를 호출한다
      ↓
REA가 기존 분석 도구(Ghidra, Hopper, IDA, 크롬 브라우저 등)에 일을 시킨다
      ↓
의사 코드(pseudo code), 근거, "모르는 부분"을 정리해서 돌려준다
      ↓
에이전트가 코드를 짜고, 테스트하고, 다시 분석을 요청한다 (반복)

 

여기서 눈여겨볼 부분이 두 가지 있었습니다.

첫째는 결과에 근거와 모르는 부분이 함께 온다는 점입니다.
도구가 "이 부분은 확실하다, 이 부분은 모른다"를 구분해서 알려 준다는 것은 에이전트가 틀린 추측을 덜 하게 만드는 좋은 설계라고 느꼈어요. 

둘째는 사람이 원하는 기능을 하나하나 다 만들 때까지 이 반복이 돌아간다는 점입니다.
사람이 개입하는 횟수가 줄어든다는 뜻이기도 합니다.

 

 

영상에서 가장 흥미로웠던 지적이 이 부분이었습니다.
REA 안에서 쓰이는 분석 도구들은 전부 이미 있던 것들이라는 이야기예요.

영상에 따르면 Ghidra는 미국 국가안보국(NSA)이 오랫동안 내부에서 쓰던 도구인데, 2019년에 오픈소스로 공개되었습니다.
IDA는 1990년대부터 있었던 도구이고, Hopper도 10년이 넘은 도구라고 소개했어요.
그러니까 소프트웨어를 뜯어보는 기술 자체는 새로운 것이 아니었습니다.
새로 생긴 것은 이 도구들을 에이전트가 쓰기 쉽게 하나로 묶어 주었다는 점이에요.

 

저는 이 부분이 기획자에게 가장 중요한 힌트라고 생각했습니다.
기술이 새로워서 위험한 게 아니라, 쓰는 데 필요한 지식과 시간이 확 줄어서 위험해진 것이기 때문이에요.
예전에는 분석 도구 하나를 쓰려면 설치부터 사용법까지 따로 배워야 했습니다.
이제는 에이전트에게 "이 앱의 기능이 어떻게 돌아가는지 봐 줘"라고 한 줄만 쓰면 기본적인 분석이 시작된다고 영상은 설명합니다.
문턱이 낮아지면 쓰는 사람의 수가 달라지고, 쓰는 사람의 수가 달라지면 세상에 일어나는 일도 달라집니다.

 

영상 제작자는 윈도우 그림판을 대상으로 직접 실험했습니다.
그림판을 분석해서 새로 만들고, 원래 그림판에는 없는 기능을 하나 더 붙였어요.
붙여 넣은 그림들이 오른쪽 패널에 리스트로 쌓이는 기능입니다.
영상에서는 이 과정이 약 11분 걸렸다고 했습니다.
그림판이 비교적 단순한 앱이기 때문에 짧게 끝난 면도 있다고 스스로 말하긴 했지만, 그래도 기존 앱을 분석해서 새 기능까지 얹었다는 점이 의미 있다고 평가했습니다.

 

해외에서 나온 결과물도 소개되었습니다.
애플 1세대 리모컨을 45분 만에 분석해서 다른 환경에서 쓸 수 있게 만든 개발자가 있었다고 합니다.
어도비 프로그램 일곱 개를 대신하는 앱을 만들어 오픈소스로 공개한 개발자도 있다고 소개했어요.
에어컨 내부 소프트웨어를 분석해서 손동작으로 에어컨을 조종하는 앱을 만든 사례도 나왔습니다.
게임 여러 개를 섞어 놓은 결과물도 많았고, 투자 차트 웹사이트를 분석한 사례도 있었다고 해요.

이 사례들을 보면서 저는 두 가지를 느꼈습니다.
하나는 영역이 소프트웨어에 그치지 않는다는 점입니다.
기기의 펌웨어까지 분석하면 현실의 물건을 움직이는 일에도 영향을 줄 수 있다는 뜻이에요.
다른 하나는 데모의 상당수가 게임 섞기 같은 재미 위주였다는 점입니다.
영상에서도 실용적인 데모가 아직 많이 올라오지 않았는데, 상업 소프트웨어를 분석하는 일이 불법에 가깝기 때문일 수 있다고 짚었습니다.

 

기획자로서 걱정되는 점

하나, 복제 비용이 무너진다

제가 가장 먼저 든 걱정은 기능이라는 해자가 약해진다는 점이었습니다.
지금까지 많은 서비스가 "이 기능이 있어서 우리 서비스를 쓴다"는 말에 기대어 왔습니다.
그런데 기능을 보고 같은 기능을 다시 만드는 비용이 낮아지면, 기능만으로 차별화하기가 점점 어려워져요.

이 걱정은 새로운 것이 아닙니다.
AI가 코드를 써 주기 시작한 때부터 "만드는 비용이 줄어든다"는 이야기는 계속 있었어요.
다만 REA는 한 걸음 더 나아가서, 기획서나 설계 없이 완성된 앱만 있어도 그 안의 동작 방식을 꺼내 올 수 있다는 점이 다릅니다.
말하자면 경쟁사가 내 앱을 설치만 해도 내 설계서를 얻는 상황에 가까워지는 거예요.

영상에서는 이런 전망도 나왔습니다.
대부분의 소프트웨어가 사실상 오픈소스처럼 될 것이고, 이미 있는 아이디어를 섞는 문턱이 아주 낮아졌다는 이야기였어요.
아이디어만 있으면 오픈소스로 풀린 기능들을 합쳐 나만의 앱을 만들 수 있는 시대라고 표현했습니다.
개인에게는 좋은 소식이지만, 서비스를 운영하는 쪽에서는 긴장해야 하는 소식이기도 합니다.

 

둘, 법과 라이선스의 회색 지대

이 도구가 얼마나 합법적인지는 쓰는 방식에 달려 있습니다.
README는 REA가 합법적인 연구, 교육, 상호 운용성, 소프트웨어 보존을 위한 것이고, 본인이 소유했거나 분석할 권한이 있는 소프트웨어에 써야 한다고 밝혀 두었습니다.
도난당한 키나 크랙된 복제본을 쓰거나 라이선스 제한을 우회하는 것은 허용되지 않는다고도 적혀 있어요.
영상 제작자도 상업적으로 판매되는 앱을 분석해서 똑같이 만드는 것은 불법이라고 여러 번 강조했습니다.

애매한 부분도 분명히 있었습니다.
영상에서 소개된 어도비 대체 앱은 러스트로 새로 짜서 코드가 겹치지 않는다고 했는데, 이것을 합법으로 볼지 기존 소프트웨어의 아이디어를 빼 온 것으로 볼지는 판단하기 어렵다고 했어요.
저도 같은 생각입니다.
코드가 다르더라도 화면과 동작과 흐름이 비슷하면 어디까지가 영감이고 어디부터가 복제인지 선을 긋기가 어려워요.

제가 알기로 국내 저작권법에는 호환성 확보 같은 제한된 목적에서 프로그램 코드를 역분석하는 것을 허용하는 조항이 있습니다.
다만 범위가 좁고 조건이 붙기 때문에, "분석 도구가 있으니 괜찮다"는 식으로 받아들이면 안 됩니다.
이 글은 법률 자문이 아니고, 실제로 어떤 일을 하기 전에는 계약서의 이용 약관과 라이선스 조건을 꼭 확인하고 전문가의 의견을 들어야 해요.

기획자에게는 이 부분이 실무 문제로 돌아옵니다.
경쟁 서비스를 분석할 때 어디까지가 공개된 화면을 관찰하는 일이고, 어디부터가 앱 내부를 뜯어보는 일인지를 팀에서 먼저 정해 두어야 합니다.
이런 선을 정하지 않은 채 AI 에이전트에게 "이 앱처럼 만들어 줘"라고 시키면, 의도하지 않게 선을 넘을 수 있어요.

 

셋, 도구를 설치하는 일 자체의 보안

기획자가 놓치기 쉬운 걱정이 하나 더 있습니다.
이런 도구는 에이전트에게 새로운 능력을 붙이는 일이라서, 설치하는 순간 보안의 범위가 달라진다는 점이에요.

README에 따르면 설정 명령은 MCP 서버와 작업 안내를 에이전트에 추가하고, 기존 설정은 백업해 둔다고 합니다.
또 실제로 대상을 실행하거나 조작하는 런타임 분석은 "사용자 권한으로" 동작한다고 설명해 두었어요.
쉽게 말해 내 계정이 할 수 있는 일을 에이전트도 할 수 있다는 뜻입니다.
분석 자체는 로컬에서 하지만, 에이전트가 쓰는 모델 제공자는 자기만의 데이터 정책을 가진다고 FAQ에 적혀 있기도 했어요.

영상에서는 링크 하나만 에이전트에게 붙여 넣으면 설치까지 맡길 수 있다고 보여 주었습니다.
무척 편하지만, 편하다는 건 확인 없이 지나가기 쉽다는 말이기도 해요.
제가 정한 기준은 이렇습니다.

• 어떤 설정 파일이 바뀌는지 확인하고 백업이 있는지 본다.
• 분석할 대상이 내가 소유했거나 분석할 권한이 있는 것인지 먼저 확인한다.
• 업무 환경에서는 외부로 나가는 데이터가 있는지, 모델 제공자의 정책이 무엇인지 확인한다.
• 개인 PC에서 먼저 써 보고, 업무 환경에는 보안 담당자와 상의한 뒤에 도입한다.

넷, 핵심 로직이 서버로 이동할 수 있다

영상 제작자는 앞으로의 전망도 하나 이야기했습니다.
앱 안에 들어 있는 핵심 로직이 쉽게 뜯길 수 있으니, 회사들이 그런 기능을 앱에 넣지 않고 서버에서 처리하는 쪽으로 갈 수 있다는 이야기였어요.
그렇게 되면 클라우드나 메모리 쪽에는 좋은 소식일 수 있다는 말도 덧붙였습니다.

이 전망이 맞다면 기획자에게도 영향이 있습니다.
오프라인에서도 되던 기능이 줄어들 수 있고, 같은 화면이라도 서버 응답에 의존하는 구조가 늘어나요.
그러면 서버 비용과 응답 속도, 장애 때의 사용자 경험이 기획의 중요한 항목이 됩니다.
서버로 옮긴 로직도 API 호출을 관찰해서 추측당할 수 있기 때문에, 호출 횟수 제한이나 인증, 이상 징후 감지 같은 항목도 기획서에 들어가야 합니다.

저는 이 이야기가 마냥 맞는다고 확신하지는 못합니다.
다만 "클라이언트에 둘 것과 서버에 둘 것"을 나누는 기준이 이제는 성능과 편의뿐 아니라 "뜯겼을 때의 영향"까지 포함하게 될 것 같다는 점은 공감했어요.

 

 

그렇다면 앱을 뜯어서 얻을 수 없는 것은 무엇일까요?!
이 질문이 이 글에서 제가 가장 하고 싶었던 이야기입니다.

도구가 돌려주는 것은 "무엇이 어떻게 동작하는가"입니다.
의사 코드와 근거, 그리고 모르는 부분이었죠.
하지만 "왜 그렇게 만들었는가"는 코드에 남지 않습니다.
이 정책을 왜 이렇게 정했는지, 어떤 사고를 겪고 이 예외를 넣었는지, 어떤 사용자를 위해 이 선택을 했는지는 뜯어낸 코드에서 복원되지 않아요.

 

제가 요즘 만들고 있는 스팩브릿지는 바로 이 "왜"를 화면 위에 남기려는 시도입니다.
화면, 요구사항, 데이터, API를 연결해서 의도를 같이 보관하자는 생각이었어요.
REA 같은 도구가 나오면서 이 생각이 더 중요해졌다고 느낍니다.
동작은 복제할 수 있어도 의도와 맥락은 복제할 수 없으니, 그것을 조직 안에 잘 쌓아 두는 팀이 복제 이후에도 앞서갈 수 있기 때문이에요.

제가 맡고 있는 예약 시스템 기획에 대입해 보면 더 분명해집니다.
예약 화면과 달력과 알림 기능은 누구나 비슷하게 만들 수 있게 될 것입니다.
하지만 업장마다 다른 취소 규정을 어떻게 흡수할지, 노쇼가 반복될 때 운영자에게 어떤 선택지를 줄지, 동시에 들어온 예약을 어떻게 처리할지 같은 정책의 정교함은 쌓인 경험에서 나옵니다.
그리고 실제 운영에서 쌓인 데이터와 운영하시는 분들의 신뢰, 문제가 생겼을 때 빠르게 도와주는 지원 체계는 앱을 뜯는다고 가져올 수 없어요.

정리하면 복제하기 어려운 것은 이런 것들이라고 생각합니다.

• 정책과 예외 처리에 담긴 의도와 맥락
• 운영하며 쌓인 데이터와 거기서 얻은 학습
• 사용자와 사업자의 신뢰, 브랜드
• 문제가 생겼을 때의 대응 속도와 지원 체계
• 법과 규정을 지키며 쌓은 운영 노하우

기능은 복제될 수 있어도 이런 것들은 시간이 걸려야 쌓입니다.
그래서 기획자의 일도 "기능을 정의하는 일"에서 "이런 자산을 쌓는 구조를 설계하는 일"로 무게가 옮겨 가야 한다고 느꼈어요.

 

기획자가 지금 할 수 있는 체크리스트

마지막으로 지금 바로 해 볼 수 있는 일들을 세 가지 상황으로 나눠 정리해 봅니다.

내 서비스를 지키는 입장에서는 이렇습니다.

• 핵심 정책과 예외 처리의 의도를 문서로 남겨 둔다.
• 클라이언트에 노출되는 로직과 서버에 있어야 할 로직을 다시 나눠 본다.
• 이용 약관과 라이선스에 역분석과 복제에 대한 조항이 있는지 확인한다.
• 쌓이는 데이터와 운영 경험이 어디에 있는지 점검한다.

남의 서비스를 참고하는 입장에서는 이렇습니다.

• 공개된 화면을 관찰하는 일과 앱 내부를 분석하는 일을 구분한다.
• 참고한 것과 새로 만든 것의 경계를 기록으로 남긴다.
• 상업적으로 판매되는 앱을 분석해서 똑같이 만드는 일은 하지 않는다.
• 필요하면 법무나 전문가의 의견을 듣는다.

AI 에이전트를 팀에 도입하는 입장에서는 이렇습니다.

• 에이전트에게 맡길 수 있는 분석의 범위를 팀 규칙으로 정한다.
• 새 도구를 설치할 때는 설정 변경과 권한, 데이터 흐름을 확인한다.
• 에이전트가 만든 결과물의 출처와 근거를 남기도록 요청한다.

 

REA 때문에 소프트웨어가 끝났다고까지 말하기는 어렵다고 생각합니다.
영상 제작자도 아직은 끝났다고 단정하지 않았고, 이 도구가 한두 달 안에 에이전트의 기본 기능이 될 수도 있다는 의견을 덧붙였어요.

그래도 방향은 분명해 보입니다.
앱을 만드는 일과 앱을 따라 만드는 일의 비용이 함께 내려가고 있다는 점입니다.

이런 때일수록 기획자는 "무엇을 만들까"뿐 아니라 "만든 것이 복제되어도 남는 것이 무엇인가"를 같이 물어야 합니다.
저는 그 답이 의도와 정책, 데이터, 신뢰에 있다고 생각하고, 그것을 쌓는 일을 계속하려고 해요.
다음에는 이 도구를 개인 환경에서 직접 돌려 본 경험과, 팀에서 정할 분석 범위 규칙의 예시를 정리해 보겠습니다.