요즘 말하는 AI 리버스 엔지니어링 — SaaS·앱 ‘복제’ 이슈를 개념과 사례로

발행 읽는 시간 약 14 분

  • AI
  • 리버스엔지니어링
  • SaaS
  • AI코딩
  • 개발트렌드

글 소개

리버스 엔지니어링·HAR·MCP·클린룸·코딩 에이전트가 무엇인지부터, 2025~2026년 SaaS·앱 ‘복제’ 화제(Linear HAR, REA, Ralph, Artcraft)를 개념과 사례로 설명합니다.

AI 코딩 도구가 발전하면서 기존 소프트웨어의 기능을 분석하고, 비슷한 서비스를 새로 구현하려는 시도가 주목받고 있습니다. 예전에는 화면과 내부 동작을 확인하는 데 많은 시간이 필요했다면, 이제는 AI 에이전트가 코드 작성과 반복 테스트의 일부를 수행할 수 있습니다.

이런 흐름 속에서 Linear의 웹 동작을 분석한 실험, AI 기반 역분석 도구 REA, 반복 개발 방식인 Ralph, Adobe 제품군의 대안을 표방한 Artcraft 등의 사례가 논의됐습니다. 하지만 이들은 모두 같은 방식으로 소프트웨어를 ‘복제’한 것이 아닙니다.

원본 코드를 복사하는 것, 외부에서 관찰할 수 있는 기능을 재구현하는 것, 공개된 자료만으로 새로운 코드를 작성하는 것은 서로 다른 접근입니다. 기술적으로 가능한 범위와 법적·윤리적 쟁점도 달라집니다.

이 글에서는 리버스 엔지니어링의 개념과 관련 기술을 먼저 살펴보고, 대표 사례의 성과와 한계를 구분합니다. 마지막으로 개발자와 서비스 운영자가 무엇을 확인해야 하는지 정리합니다. 아래 타임라인은 2026년에 논의된 사건의 순서를 한눈에 보기 위한 것입니다.

2026년 복제 담론 타임라인


리버스 엔지니어링이란 — 세 가지 뜻#

리버스 엔지니어링(reverse engineering, 역공학)은 완성된 제품이나 시스템의 동작을 관찰하고 분석해 구조와 작동 원리를 이해하는 과정입니다. 소프트웨어에서는 실행 파일을 분석하기도 하고, 웹 서비스의 화면과 네트워크 통신을 조사하기도 합니다.

최근 AI 개발 사례를 이해하려면 분석 대상을 기준으로 세 가지 접근을 구분하는 것이 편리합니다.

HAR REA Ralph 세 갈래

구분분석 대상대표적인 방식
A. 웹 서비스 분석화면, 사용자 동작, 브라우저와 서버 간 통신개발자 도구, HAR 기록, AI 코딩 에이전트
B. 설치형 앱 분석실행 파일, 라이브러리, 실행 중 동작Ghidra, Hopper, 역분석 도구(REA 등)
C. 공개 자료 기반 재구현공개 문서, 기능 설명, 허용된 사양사양 정의, 새로운 코드 작성, 반복 테스트(Ralph 루프 등)

이 구분은 기술적인 이해를 돕기 위한 것으로, 각 방식의 적법성을 자동으로 판단해 주지는 않습니다. 특히 공개 자료를 활용하더라도 저작권, 계약 조건, 상표, 영업비밀 등은 별도로 검토해야 합니다.

또한 오픈소스 프로젝트를 라이선스에 따라 수정하는 ‘포크(fork)’와 원본 코드를 이용하지 않고 기능을 재현하는 ‘클린룸 재구현(clean-room reimplementation)’은 구분해야 합니다. 실제 논란에서는 무엇을 참고했고, 어떤 코드를 사용했으며, 결과물이 무엇과 얼마나 유사한지가 중요합니다.

닫힌 AI API(Jev 등)의 입출력 패턴으로 내부 구조를 추론하는 이야기도 리버스 엔지니어링이라고 불리지만, 제품 복제와는 검색어만 겹칩니다. → Jev / System One 입문


개념: HAR, 코딩 에이전트, MCP#

HAR(HTTP Archive) 은 브라우저와 서버 사이에서 발생한 네트워크 요청과 응답을 기록하는 형식입니다. 개발자는 Chrome 개발자 도구 등을 이용해 HAR 파일을 저장하고, 화면을 조작할 때 어떤 API가 호출되는지 살펴볼 수 있습니다. 다만 파일에 실제로 포함되는 데이터는 캡처 설정과 통신 방식에 따라 달라집니다. 세션 토큰이나 개인정보가 포함될 수 있으므로 공유 전에 반드시 민감정보를 제거해야 합니다.

AI 코딩 에이전트 는 파일 읽기, 코드 작성, 테스트 실행 등 개발 과정의 여러 단계를 지원하는 도구입니다. Claude Code나 Cursor Agent처럼 목표와 작업 범위를 입력받아 순차적으로 작업을 진행하는 형태가 대표적입니다.

MCP(Model Context Protocol) 는 AI 애플리케이션이 외부 도구 및 데이터와 연동할 수 있도록 하는 프로토콜입니다. REA와 같은 프로젝트는 이런 연동 방식을 활용해 AI 에이전트가 역분석 도구의 결과를 활용하도록 지원한다고 소개합니다. 지원 범위와 구현 방식은 해당 프로젝트의 공식 문서에서 확인해야 합니다.


사례 ① Linear: HAR로 웹 서비스 동작 분석#

HAR에서 클론 실험 흐름

배경. 2026년 2월 Martin Alderson은 프로젝트 관리 서비스 Linear의 동작을 브라우저에서 관찰한 자료로 일부 기능을 재현하는 실험을 소개했습니다. 목표는 내부 소스 코드를 확보하는 것이 아니라, 외부에서 확인할 수 있는 동작을 바탕으로 어느 수준까지 구현할 수 있는지 살펴보는 것이었습니다.

접근 방법. 그는 브라우저 개발자 도구에서 네트워크 요청을 수집하고, HAR 파일과 화면 관련 정보를 AI 코딩 도구(Claude Code)에 전달해 기능과 화면 구조를 분석하게 했습니다. 이후 단위·통합 테스트를 추가하고 여러 차례 수정하면서 결과물을 개선했다고 설명합니다.

결과와 한계. 이 실험은 화면과 일부 API 동작을 관찰한 자료만으로도 유사한 사용자 경험을 재현할 수 있음을 보여줍니다. 그러나 HAR 파일만으로 서버 내부의 비즈니스 규칙, 복잡한 권한 관리, 장기간 축적된 예외 처리까지 파악할 수는 없습니다. 일부 기능을 구현한 실험과 실제 서비스를 완전히 대체할 수 있다는 주장은 구분해야 합니다.

실험 조건은 작성자 본인의 설명에 따르면 약 20번의 프롬프트, 월 200달러 Claude Max 구독 범위 안의 토큰, 며칠 저녁에 걸친 작업이었습니다. 작성자는 연구 목적이며 결과물을 공개·상업화할 의도가 없고, 인증과 실시간 협업 등 중요한 기능이 빠진 불완전한 클론이라고 밝혔습니다.


사례 ② REA: AI 에이전트와 역분석 도구#

REA MCP 흐름

REA(Reverse Engineer Anything) 는 AI 에이전트와 역분석 도구를 연결해 소프트웨어의 작동 방식을 조사하도록 돕는 프로젝트입니다. 프로젝트 문서에서는 네이티브 바이너리, Electron 앱, .NET, 웹 등을 로컬에서 Ghidra·Hopper 등 기존 도구와 연결해 분석하고, 결과를 근거(evidence)와 한계와 함께 제시하는 기능을 소개합니다. README는 사용 범위를 합법적인 연구·교육·상호운용성·소프트웨어 보존과 본인이 소유하거나 분석 권한이 있는 소프트웨어로 한정합니다.

2026년 10월에는 REA의 GitHub 관심 지표와 실제 구현 능력을 둘러싸고 다양한 반응이 나왔습니다. 공개된 집계에 따르면 star 수는 10월 7일 약 1만에서 10월 16일 약 27만까지 열흘 만에 늘었고, 10월 18일 현재 저장소에는 약 31만으로 표시됩니다. 일부 Hacker News 이용자는 증가 곡선이 봇에 의한 것일 수 있다고 의심했고, 반대로 npm 설치 수와 포크 수가 함께 늘어 실제 관심이라고 보는 분석도 있었습니다. 어느 쪽도 star 목록을 직접 감사한 것은 아닙니다.

중요한 점은 분석 도구의 사용 가능성과 대규모 상용 소프트웨어의 완전한 재구현 능력은 서로 다른 문제라는 것입니다. quanglee 등은 공개된 시도 기준으로 작은 기능 단위 재현은 가능해도 규모 있는 앱 전체를 다시 만든 사례는 없다고 정리했습니다. 실제 성능은 재현 대상, 테스트 범위, 공개된 결과를 기준으로 판단해야 합니다.

REA 공식 설치처

설치가 필요한 경우에는 프로젝트가 현재 공식적으로 안내하는 저장소와 배포 경로를 직접 확인해야 합니다. README가 공식 출처로 안내하는 곳은 저장소 github.com/morluto/rea, 사이트 rea.tools(새 창), npm 패키지 rea-agents(npx rea-agents setup)입니다. README는 비슷한 저장소 이름이나 복사된 README가 공식 배포물임을 뜻하지 않는다고 명시하며, 실제로 README만 복사한 유사 저장소에서 Windows용 압축 파일을 내려받으라는 사례가 보고됐습니다. 원 프로젝트는 release 파일을 배포하지 않는다는 지적도 있었습니다. 유사 저장소에 악성 코드가 들어 있었는지는 보고가 엇갈리므로, 실행 파일을 다운로드하거나 설치 스크립트를 실행하기 전에 게시 주체와 변경 이력을 확인하세요.


사례 ③ Ralph 루프와 클린룸#

Ralph 는 Geoffrey Huntley가 이름 붙인 방식으로, AI 코딩 에이전트에 작업 계획을 반복해서 전달하며 개발을 진행합니다. 한 번의 실행으로 모든 작업을 끝내기보다, 남은 작업을 확인하고 다음 작업을 수행하는 과정을 반복하는 데 초점을 둡니다. Huntley는 가장 단순한 형태를 다음과 같은 셸 루프로 소개합니다.

Bash
while :; do cat PROMPT.md | claude-code ; done

위 명령은 원문을 그대로 인용한 개념 설명용 예시입니다. 종료 조건이 없는 무한 루프이고 에이전트가 자동으로 커밋까지 수행하도록 지시하는 구성이므로, 그대로 실행하지 마세요. 실제 설치된 CLI의 명령 이름도 다를 수 있습니다. 반복 실행에는 작업 횟수 제한, 테스트, 변경 사항 검토, 실행 권한 관리가 필요합니다.

PROMPT.md는 에이전트에게 계획 파일(원문 예시에서는 fix_plan.md)을 읽고 가장 중요한 한 가지만 수행한 뒤 커밋하라고 지시합니다. 매 반복마다 대화 컨텍스트는 초기화되지만, 디스크에 남는 계획 문서와 수정된 파일이 실행 사이의 진행 상황을 이어 주는 역할을 합니다.

Reverse Ralph 라는 표현은 기존 제품의 공개된 동작이나 문서를 분석해 요구사항을 정리하고, 그 정보를 바탕으로 새로운 구현을 만드는 접근을 설명할 때 사용됩니다. 이 방식을 정리한 글은 Huntley가 BSL 라이선스의 HashiCorp Nomad를 재구현한 사례를 예로 들며, The Register(2026년 1월)는 Huntley가 Ralph와 Claude Code로 상용 제품을 클론한 사례를 다뤘습니다. 이는 원본 코드를 직접 복사하지 않는다는 취지와 연결되지만, 그 사실만으로 저작권이나 계약 관련 위험이 사라지는 것은 아닙니다.


사례 ④ Artcraft: AI 기반 대체 제품의 가능성과 한계#

Artcraft 사례는 AI 코딩을 활용한 대체 소프트웨어 개발 가능성과 한계를 함께 보여줍니다. 개발자 Brandon Thomas는 2026년 10월 Adobe Creative Cloud 제품군을 대체한다는 Rust 기반 오픈소스 애플리케이션 7종(PhotoCraft, VectorCraft 등)을 공개했고, Claude로 클린룸 방식으로 구현했다고 주장했습니다. 다만 프로젝트의 발표 내용과 실제 제품이 제공하는 기능 수준은 구분해서 살펴봐야 합니다.

초기 단계의 시연이나 개발 속도가 빠르다는 사실만으로 오랜 기간 발전해 온 상용 제품과 동등한 품질이 검증됐다고 볼 수는 없습니다. 사용자 경험, 안정성, 파일 호환성, 성능, 유지보수까지 비교해야 하기 때문입니다. 보도에 따르면 Thomas는 처음에 한 달 안에 100% 기능 동등을 약속했다가 이후 목표를 완화했고, 초기 사용자들은 알파 버전의 기본 도구가 기대와 다르다고 지적했습니다. 클린룸 주장이 독립적으로 검증된 것은 아니라는 평가도 있습니다.

여기에 화면 구성이나 브랜드 표현이 기존 제품과 지나치게 유사할 경우, 코드가 다르더라도 별도의 법적 쟁점(trade dress 등)이 발생할 수 있습니다. 따라서 ‘AI로 소프트웨어를 빠르게 만들 수 있다’는 주장과 ‘기존 제품을 완전히 대체할 수 있다’는 평가는 구분해야 합니다. “Software is over”는 선언에 가깝고, 지금 당장 Adobe를 대체한다는 사실과는 거리가 있습니다.


돈과 시장이 말하는 것#

AI 코딩 도구가 발전하면 기존 소프트웨어의 일부 기능을 유사하게 구현하는 데 필요한 시간과 비용이 줄어들 수 있습니다. 하지만 기능을 만드는 비용이 낮아지는 것과 고객이 기존 서비스를 떠나는 것은 다른 문제입니다.

투자와 언론 보도는 이 두 측면을 동시에 보여 줍니다. Inevitable AI Group은 2026년 8월 Aleph가 주도한 600만 달러 pre-seed 투자를 발표하며, 소규모 팀이 AI로 기존 SaaS 범주를 더 싸고 빠르게 다시 만드는 스튜디오 모델을 내세웠습니다. Base44 창업자 Maor Shlomo는 2025년 인터뷰에서 바이브코딩 툴 자체가 복제하기 쉬워 방어선이 얇다고 말했습니다. 이런 이야기가 REA·에이전트가 남의 앱을 읽는 이야기와 겹치면, 앱뿐 아니라 앱을 만드는 툴도 방어가 얇아진다는 시장 심리가 커집니다.

반대로 KAD 등 분석은 구독 SaaS의 방어선을 적법하게 확보한 데이터, 유통, 컴플라이언스, 조직 업무에 깊이 들어간 워크플로에 둡니다. 기업 고객이 서비스를 선택할 때는 화면이나 기능뿐 아니라 데이터 이전, 다른 업무 시스템과의 연동, 보안, 규제 대응, 안정성, 기술 지원도 고려합니다. 따라서 유사한 데모를 만들었다는 사실만으로 기존 SaaS 시장의 경쟁력이 곧바로 사라진다고 단정하기는 어렵습니다.

개발자와 서비스 운영자에게 중요한 질문은 ‘이 기능을 복제할 수 있는가?’를 넘어, ‘실제 고객이 안심하고 운영할 수 있는 대체 서비스를 제공할 수 있는가?’입니다.


법·윤리 — 무엇을 했는가#

복붙 vs 클린룸

소프트웨어의 기능을 관찰하거나 비슷한 서비스를 새로 만드는 행위가 언제나 허용되거나 언제나 금지되는 것은 아닙니다. 실제 판단에는 사용한 코드와 자료, 라이선스 조건, 서비스 이용약관, 상표 및 저작권 등 여러 요소가 영향을 줍니다.

따라서 사례를 살펴볼 때는 단순히 ‘복제했다’는 표현보다 무엇을 참고했고, 실제로 어떤 코드를 사용했으며, 당사자들이 무엇을 주장했는지 구분하는 것이 중요합니다.

PearAI와 Continue 사례(2024) 에서는 오픈소스 코드를 활용한 제품 개발과 라이선스 고지 문제가 함께 논의됐습니다. Continue는 Apache 2.0 라이선스의 오픈소스이고, PearAI는 이를 포크해 AI 코드 편집기를 만들었습니다. 포크 자체는 라이선스 조건을 준수하는 범위에서는 허용될 수 있습니다. 논쟁은 PearAI가 처음에 자체 폐쇄 라이선스를 적용했다가 비판을 받고 원래의 Apache 라이선스로 되돌린 과정과 출처 표기 쪽에 몰렸습니다. 오픈소스 코드를 사용했다는 사실만으로 위법 여부를 단정할 수 없으며, 해당 라이선스의 고지·배포 조건을 충족했는지 살펴봐야 합니다.

Corgi와 Papermark 관련 논쟁(2026년 6월) 에서는 코드 사용 여부와 화면·문구의 유사성에 대한 서로 다른 주장이 제기됐습니다. Papermark 측은 Corgi의 신제품이 자사 기능 설명 문구를 그대로 썼다며 저작권·라이선스 침해를 주장했고, Corgi CEO는 Papermark의 코드를 쓰지 않았다고 반박하면서 일부 설정 화면의 시각 요소가 비슷했던 점은 인정하고 수정했다고 밝혔습니다. 공개적으로 확인된 사실과 각 당사자의 입장을 구분해야 하며, 분쟁의 법적 결론이 확인되지 않았다면 어느 한쪽의 주장을 사실로 단정해서는 안 됩니다. 클린룸 주장과 화면·카피 유사가 한 번에 문제가 되는 패턴은 Artcraft나 SaaS HAR 실험 같은 ‘기능 재현’ 담론과도 연결됩니다.


과장 vs 현실#

헤드라인 vs 현장

사례실무적으로 구분할 점
Linear 분석 실험관찰 가능한 화면·API를 재현한 것과 전체 서비스를 대체한 것은 다릅니다.
REA분석 기능과 프로젝트 관심 지표는 제품 완성도에 대한 직접적인 증거가 아닙니다.
Artcraft개발 시연과 상용 제품 수준의 호환성·안정성은 구분해야 합니다.
Ralph개발 자동화 방식이며, 적법성과 품질을 자동으로 보장하지 않습니다.

새로운 도구나 시연 사례를 검토할 때는 네 가지를 확인하세요. 실제로 동작하는 범위는 어디까지인가? 공개된 테스트나 재현 가능한 자료가 있는가? 코드·데이터의 이용 권한은 확인했는가? 설치 파일과 배포처는 공식적으로 검증됐는가?


정리#

AI와 리버스 엔지니어링을 결합하면 기존 소프트웨어의 화면과 동작을 분석하고, 일부 기능을 재현하는 작업을 더 빠르게 진행할 수 있습니다. 그러나 브라우저에서 관찰한 기능을 구현하는 일과 복잡한 상용 제품을 안정적으로 대체하는 일은 구분해야 합니다.

또한 원본 코드를 직접 사용하지 않았다는 이유만으로 모든 법적 문제가 해결되지는 않습니다. 라이선스와 이용약관, 지식재산권, 데이터 취급 및 배포 방식까지 함께 확인해야 합니다.

실무에서는 구현 속도보다 검증 범위가 중요합니다. 개발자라면 재현 가능한 테스트와 출처를 확인하고, 서비스 운영자라면 보안·연동·유지보수·고객 전환 비용을 함께 평가해야 합니다. AI가 개발 비용을 낮출 수는 있지만, 신뢰할 수 있는 제품을 운영하는 책임까지 대신해 주지는 않습니다.


출처 (더 읽기)#

FAQ

자주 묻는 질문

AI 리버스 엔지니어링이 불법인가요?
항상 그렇지는 않습니다. 공개 문서 기반 클린룸 재구현, 이용약관 위반, 코드 무단 복사, UI·브랜드 모방 등 무엇을 어떻게 했는지에 따라 판단이 달라지며, 한국을 포함해 적용되는 관할에 따라 결과가 다를 수 있습니다. 이 글은 법률 조언이 아닙니다.
REA GitHub star가 많으면 믿어도 되나요?
GitHub 스타 수는 관심 지표이지 기술적 검증이 아닙니다. 설치는 프로젝트가 공식으로 안내하는 경로(github.com/morluto/rea 저장소, rea.tools, npm 패키지 rea-agents)에서만 진행하고, 비슷한 이름의 저장소나 실행 파일은 공식 배포물로 가정하지 마세요.
Jev 역분석 글과 같은 이슈인가요?
검색어가 비슷할 뿐 다른 주제입니다. Jev 역분석은 공개 API의 입출력 패턴으로 내부 구조를 추론하는 이야기이고, 이 글은 SaaS·앱·클린룸 제품 복제 담론을 다룹니다.

Follow · Ask · Work

이 글이 도움이 됐다면

짧은 작업 기록과 데모는 인스타그램에 올립니다. 만들고 싶은 것이 있다면 프로젝트 의뢰나 협업 제안도 편하게 보내 주세요.

글쓴이

파란여우

직접 만든 AI 앱·제품의 개발·배포를 공개하는 실전형 테크 크리에이터

파란여우 소개 Instagram @bluefox._.hi

시리즈 · AI 실험실

시리즈 전체 보기

AI 글 더 보기