REA로 앱 역설계가 쉬워졌다: 회사 서비스와 납품받은 시스템을 지키려면 무엇을 정해야 하나

REA 같은 도구가 앱 역설계를 쉽게 만들었다고 해서 우리 서비스가 곧바로 복제당하는 것은 아닙니다. 다만 배포한 것은 읽힌다는 가정으로 설계를 다시 점검할 때가 됐습니다. 정할 것은 네 가지입니다. 클라이언트에 무엇을 둘지, 권한 검사를 어디서 할지, 이상 호출을 어떻게 알아챌지, 납품과 라이선스 계약에 무엇을 적을지입니다. 코드를 감추는 일은 시간을 벌 뿐이고 마지막까지 남는 방어선은 서버 쪽 통제와 계약, 그리고 코드 밖에 있는 해자입니다.

REA는 무엇이고 무엇이 달라졌나

REA(Reverse Engineer Anything)는 morluto가 MIT 라이선스로 공개한 오픈소스입니다. Claude Code, Codex, Cursor, Gemini CLI 같은 코딩 에이전트에 역설계 도구를 MCP로 연결해 줍니다. 저장소 설명에 따르면 분석 대상은 네이티브 바이너리, JavaScript·Electron 앱, .NET 어셈블리, Android APK, 웹사이트, 저장된 네트워크 캡처 등입니다. 분석은 사용자 컴퓨터에서 로컬로 돌고 결과에는 근거와 한계가 함께 나옵니다. README의 예시 요청은 Notes 앱의 검색이 어떻게 동작하는지 근거와 함께 보여 주고 내 프로젝트에 비슷한 기능을 만들어 달라는 것입니다. README는 스타 20만 개를 기록했다고 적고 있습니다.

이 접근 자체는 새롭지 않습니다. 개발자 Martin Alderson은 2월 13일 글에서 브라우저 개발자 도구로 Linear의 네트워크 요청을 HAR 파일로 저장한 뒤 Claude Code에 분석시켜 20번 남짓한 프롬프트와 저녁 이틀 정도, 수백만 토큰으로 Linear 핵심 기능 대부분을 따라 만들었다고 밝혔습니다. 소스 코드는 쓰지 않았습니다. 본인도 인증 시스템과 실시간 협업이 없고 일부 화면은 임시 데이터라고 적었고 공개하거나 상용화할 생각은 없다고 했습니다. REA는 같은 접근을 네이티브 바이너리, 데스크톱·모바일 앱까지 지원하는 도구입니다.

1. 클라이언트에 내려가는 것은 읽힌다고 가정한다

API 키, 내부 주소, 프롬프트 원문, 가격 계산 규칙처럼 경쟁사가 보면 곤란한 것은 앱이나 브라우저로 내려보내지 않습니다. 코드를 난독화하면 분석이 느려질 수는 있습니다. REA의 Go 바이너리 문서는 심볼 제거와 난독화가 빌드 정보 같은 메타데이터를 제한할 수 있다고 적습니다. 분석에 쓸 정보가 줄어든다는 설명이지, 분석이 불가능해진다는 설명은 아닙니다. AI가 풀지 못할 것이라는 기대는 설계 근거가 되지 못합니다.

2. 권한 검사와 핵심 로직은 서버에 둔다

서버 안에만 있는 데이터와 계정별 권한 판단은 네트워크 요청을 관찰해서는 알아낼 수 없습니다. 그래서 지켜야 할 것은 서버 쪽에 둡니다. 모든 요청을 서버에서 다시 인증하고 인가하며 화면에서 숨긴 기능도 서버가 막아야 합니다. 응답에는 화면에 필요한 값만 담고 공개 API 문서는 업무 로직이 드러나는 범위를 따져 공개합니다. Alderson은 공개된 API 문서만 붙여 넣어도 쓸 만한 복제본이 나올 수 있다고 봤습니다.

3. 이상 호출을 알아챌 수 있게 남긴다

Alderson은 앱을 직접 사용하며 요청을 모았고 REA도 웹사이트의 네트워크 관찰을 분석 대상으로 다룹니다. 같은 계정이나 IP에서 짧은 시간에 화면 전체를 훑는 호출, 평소 쓰지 않는 경로를 차례로 부르는 패턴이 남도록 요청 로그를 보관하고 호출 제한을 겁니다. 목적은 막는 것만이 아니라 누가 언제 얼마나 가져갔는지 알 수 있는 상태를 만드는 것입니다.

4. 법과 계약은 보조선이다

REA 저장소의 DISCLAIMER는 DRM과 라이선스 검사 우회, 독점 소프트웨어 복제, 허가받지 않은 시스템의 인증 우회를 돕지 않는다고 밝힙니다. 소프트웨어가 공개돼 있다는 사실만으로 모든 조작이 허락되는 것은 아니라고도 적었습니다. 반면 Alderson은 법률가가 아니라고 전제하면서 기능 자체는 저작권 대상이 아니라고 알고 있고 이런 역설계가 이용약관 위반일 수는 있어도 공개 배포된 파일을 두고 얼마나 집행할 수 있을지는 분명하지 않다고 썼습니다. 두 글 모두 법적 판단이 아니며 나라와 계약에 따라 달라집니다. 이용약관만 믿고 설계를 느슨하게 하지 말고 법률 자문은 따로 받으세요.

코드 밖의 해자

Alderson은 네트워크 효과, 독자 데이터, 특수한 인프라가 있는 소프트웨어가 복제에 더 강하다고 봤고 가장 오래 가는 해자로 책임을 꼽았습니다. 정식 업체는 데이터 유출에 대한 계약상 책임, 면책 조항, 사이버 보험, SOC2 같은 인증을 제공할 수 있지만 둘이서 만든 복제 업체는 그러기 어렵다는 논리입니다. 기능은 따라 만들 수 있어도 운영과 책임은 따라 만들기 어렵다는 점이 이 주제의 결론입니다.

구축 업체에 묻고 계약에 적을 것

• 소유권과 소스 인도: 납품 결과물의 소유권, 소스 코드 인도 여부와 시점, 재사용 범위를 계약서에 씁니다.
• 비밀값 위치: API 키와 프롬프트가 클라이언트가 아니라 서버나 비밀 관리 서비스에 있는지 확인하고 납품 후 키를 교체하는 절차를 받습니다.
• 서버 측 권한 검사: 화면에서 숨긴 기능도 서버에서 막히는지 확인한 테스트 결과를 요청합니다.
• 로그와 호출 제한: 이상 호출을 볼 수 있는 로그가 어디에 남고 누가 보는지 정합니다.
• 제3자·오픈소스 라이선스 목록: 납품물에 들어간 구성요소의 라이선스를 목록으로 받습니다.
• 납품 후 접근권 회수: 계약이 끝났을 때 계정, 키, 저장소 접근을 어떻게 회수할지 정합니다.

역설계 도구를 정당하게 쓰는 경우

반대로 소스 없이 넘겨받은 레거시 시스템을 이해하거나 자사 앱의 보안을 점검하는 데 이런 도구를 쓰는 것은 REA가 안내하는 정당한 용도, 곧 자기 소유이거나 분석 권한을 받은 소프트웨어의 점검에 해당합니다. 이때도 대상과 범위에 대한 권한을 문서로 확보해야 합니다.

노벤티스는 어떻게 다루나

노벤티스(noventis.io)는 AI 에이전트와 업무 자동화를 고객사 시스템에 맞춰 설계하고 구축하는 AX 엔지니어링 팀입니다. 위 점검 항목은 노벤티스의 특정 사례가 아니라 일반 설계 원칙입니다. 승인 없이 외부 발신·결제·삭제를 실행하는 자동화는 만들지 않으며, 납품 범위와 운영 조건은 진단 미팅 후 서면 견적과 계약으로 확정합니다.

이 글이 맞는 독자: 자사 앱이나 내부 도구를 운영하거나 외주로 시스템을 받는 중소·중견기업의 IT·운영 책임자입니다.