리버스 엔지니어링 오픈소스 REA가 노션/캔바를 클론했다
Quick Summary
오픈소스 REA로 노션·캔바의 화면과 일부 기능을 재구현한 실험은 AI 역공학의 가능성을 보여주지만, 제품의 완성도와 운영·법적 책임은 별도로 검증해야 한다.
영상 보기
클릭 전까지는 가벼운 미리보기만 먼저 불러옵니다.
🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론
오픈소스 REA로 노션·캔바의 화면과 일부 기능을 재구현한 실험은 AI 역공학의 가능성을 보여주지만, 제품의 완성도와 운영·법적 책임은 별도로 검증해야 한다.
📌 핵심 요점
- 발표자는 REA와 AI를 활용해 노션·캔바를 재구현했다. 노션 클론의 녹음·AI 채팅·데이터베이스 생성과 캔바 클론의 요소 편집·PDF 및 PNG 내보내기 등을 시연하거나 작동했다고 설명한다.
- 개발 방식은 역공학 목표와 테스트 환경을 AI에 제공하는 것이었다. 발표자에 따르면 AI는 11시간 넘게 분석·개발·테스트를 수행했다.
- REA는 기존 프로그램을 조사한 근거를 AI 에이전트에 제공한다. 원본 소스 코드를 그대로 복구하기보다 작동 원리를 분석해 새로운 구현을 돕는 도구다.
- 분석 대상은 웹사이트, 일렉트론 기반 데스크톱 프로그램, 컴파일된 바이너리까지 포함한다. 다만 보호된 코드와 복잡한 내부 동작에는 한계가 있으며, 소개된 외부 재구현 사례의 완성도도 검증이 필요하다.
- 영상의 핵심 전망은 SaaS의 소멸보다 경쟁 기준의 변화다. 기능 구현 비용이 낮아질수록 데이터·업무 이해, 안정적인 운영, 서비스 신뢰성, 무엇을 만들지 판단하는 능력이 중요해진다는 주장이다.
🧩 배경과 문제 정의
AI에게 프로그램 개발을 맡기려 해도 필요한 기능, 화면 구성, 데이터 처리 방식을 먼저 정하기는 쉽지 않다. 영상은 기존 소프트웨어를 벤치마크로 삼고, REA가 그 작동 원리를 조사해 AI의 구현을 돕는 접근을 소개한다.
발표자는 노션·캔바 클론을 통해 화면뿐 아니라 일부 기능도 재구현할 수 있다고 설명한다. 이를 출발점으로 역공학의 기술적 범위와 한계, SaaS의 경쟁 변화, 저작권과 사용자 책임을 살펴본다. 중심 문제는 복제 가능성 자체를 넘어 무엇을 만들고 어떻게 검증·운영할지에 있다.
🕒 시간순 섹션별 상세정리
1. 노션·캔바 클론과 11시간 자율 개발 실험
- 노션 원본과 클론을 비교하고, 클론의 AI 노트 녹음이 정상 작동했으며 AI 채팅으로 데이터베이스도 생성했다고 보여준다. [01:12]
- 캔바 클론에서는 요소 추가·위치 및 길이 조정·텍스트 수정과 PDF·PNG 내보내기를 소개하며 실제 기능도 상당 부분 작동한다고 드러낸다. [01:49]
- 발표자는 코드를 직접 작성하거나 기능을 하나씩 설명하는 대신 역공학 목표와 테스트 환경을 제공했고, AI가 11시간 넘게 분석·개발·테스트했다고 보여준다. [02:20]
2. REA의 원리와 분석 대상
- REA는 Reverse Engineer Anything의 약자다. 기존 프로그램의 구조와 동작을 조사한 근거를 클로드 코드·코덱스 같은 AI 에이전트가 해석해 새로운 코드를 작성하도록 돕는다. [03:25]
- 웹사이트의 화면 구조·자바스크립트·네트워크 통신·사용자 상호작용과 일렉트론 기반 데스크톱 프로그램을 분석 대상으로 보여준다. [03:46]
- 컴파일된 바이너리도 역공학 도구와 연결해 함수 관계와 의사 코드 등을 분석할 수 있다고 보여준다. 다만 보호된 코드와 복잡한 내부 동작까지 완벽히 복원할 수는 없다고 선을 긋는다. [04:45]
3. 외부 재구현 사례와 완성도의 한계
- GitHub 스타가 24만 개를 넘었다고 소개하고, 한 사용자가 약 한 시간 만에 HWP·HWPX 읽기·쓰기 프로그램을 만들었다는 사례를 전해진다. 실제 호환성과 완성도는 검증되지 않았다고 덧붙인다. [05:18]
- 소프트웨어 수익화의 위기라는 반응과 화면 모방은 제대로 작동하는 제품과 다르다는 지적을 함께 보여준다. 이어 AI와 러스트로 어도비 제품의 기능을 재구현하려는 별도 프로젝트를 보여준다. [06:05]
- 해당 프로젝트의 REA 사용 근거는 확인되지 않았고, 초기 단계의 편집·영상 처리 기능에도 부족함이 있다고 드러낸다. 그럼에도 개인이 AI와 함께 대형 소프트웨어를 재구현하는 흐름에 의미를 둔다. [06:39]
4. 요구사항 추론과 SaaS 경쟁 기준의 변화
- 무엇을 만들지 정하기 어려울 때 기존 제품은 기능·화면·데이터 처리의 벤치마크가 된다. REA는 기존 소프트웨어를 분석해 요구사항을 역으로 추론하도록 돕지만, 결과의 적절성은 사람이 판단해야 한다. [07:38]
- 발표자는 REA의 의미를 기존 소프트웨어를 이해하고 새 제품을 만드는 진입 장벽을 낮추는 데 둔다. 기능이 명확한 고객 관리·일정 관리 프로그램에서는 직접 개발하는 선택지가 늘어날 것으로 본다. [08:21]
- SaaS가 사라지기보다 경쟁 기준이 달라질 수 있다고 전망한다. 다중 사용자 작업·데이터 보관·운영·보안·유지보수는 여전히 어렵고, 데이터·업무 이해와 서비스 신뢰성이 중요해진다는 주장이다. [08:52]
5. 저작권과 공개·상용화의 책임
- 역공학이 무조건 불법은 아니며 국내 저작권법에 일정 조건의 호환성 확보를 위한 코드 역분석 규정이 있다고 보여준다. 이를 다른 회사 프로그램의 자유로운 복제·판매 허용으로 해석해서는 안 된다고 덧붙인다. [09:18]
- 작동 원리를 참고하는 것과 보호되는 코드·화면 표현을 복제하는 것은 구분해야 한다. 유사한 프로그램의 배포·판매에는 저작권·상표권·계약 관련 문제를 살펴봐야 하며, AI가 작성했어도 사용자 책임이 사라지지 않는다고 강조한다. [09:50]
- 학습·기능 검증 실험과 결과물의 공개·상용화를 구분하자고 제안하며, 자신의 클론도 REA의 가능성을 살펴보기 위한 실험 결과물로 보여준다. [10:07]
6. 추가 시연과 사람에게 남는 판단
- 노션 클론에서 새 에이전트 추가, 가져오기·연동, 계정 설정과 AI·회의 노트·개발자 관련 메뉴 등을 보여주며 폭넓은 기능이 적용됐다고 보여준다. [10:57]
- 실험의 결론은 AI가 발전할수록 코드 작성 속도보다 무엇을 왜 만들어야 하는지 판단하는 능력이 더 중요해진다는 것이다. REA가 그 변화를 얼마나 앞당길지는 예측할 수 없다고 드러낸다. [11:16]
- 끝으로 이런 기술이 소프트웨어 산업에 위협이 될지, 개인 개발자의 기회와 소프트웨어의 민주화를 넓힐지 질문하며 시청자의 의견을 요청한다. [11:31]
🧾 결론
- 노션·캔바 클론은 REA의 가능성을 보여주는 실험 결과물이다. 일부 기능의 작동과 원본 제품 전체의 동등성은 구분해서 봐야 한다.
- 기존 소프트웨어는 기능·화면·데이터 처리 방식을 이해하는 벤치마크가 될 수 있다. REA는 이를 분석해 요구사항을 역으로 추론하는 과정을 지원한다.
- AI가 분석과 구현을 맡더라도 결과가 적절한지 판단하고 운영과 법적 책임을 감당하는 역할은 사람에게 남는다.
- 발표자는 코드 작성 속도보다 무엇을 왜 만들어야 하는지 판단하는 능력이 더 중요해진다고 결론짓는다.
📈 투자·시사 포인트
- 기능이 명확한 고객 관리·일정 관리 프로그램에서는 직접 개발하는 선택지가 늘어날 수 있다. 단순 기능 제공에 의존하는 SaaS의 경쟁 환경이 달라질 가능성을 살펴볼 필요가 있다.
- 다중 사용자 협업, 데이터의 안전한 보관, 지속적인 서비스 운영은 여전히 어렵다는 것이 영상의 관점이다. 제품 경쟁력을 평가할 때 기능 목록과 함께 운영 역량과 신뢰성을 봐야 한다.
- 개인 개발자가 AI와 함께 기존 소프트웨어를 재구현하는 사례는 제품 개발의 진입 장벽이 낮아질 가능성을 보여준다. 다만 시연만으로 상용 제품의 완성도나 사업성을 판단하기는 어렵다.
- 영상에는 특정 기업의 실적·가치평가나 투자수익을 판단할 자료가 없다. SaaS 경쟁 변화에 관한 논의를 특정 종목의 투자 결론으로 곧바로 연결할 근거는 부족하다.
⚠️ 불확실하거나 확인이 필요한 부분
- 노션·캔바 클론의 전체 기능 범위와 원본 대비 완성도는 확인되지 않았다. 발표자의 작동 설명과 시연만으로 모든 연동·설정·편집 기능이 검증됐다고 보기는 어렵다.
- 11시간 이상의 자율 개발과 GitHub 스타 24만 개 초과는 영상에서 제시한 수치다. 개발 환경·비용·재현 조건과 스타 집계 시점은 제공된 자막만으로 확인할 수 없다.
- 약 한 시간 만에 HWP·HWPX 읽기·쓰기 프로그램을 만들었다는 사례는 외부 작성자의 실험 보고다. 영상도 실제 파일 호환성과 완성도는 검증되지 않았다고 명시한다.
- 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
- 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
- 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.
✅ 액션 아이템
- REA 실험 전에 참고할 프로그램과 재구현하려는 기능을 정하고, 학습·기능 검증·공개·상용화 중 목적을 명확히 한다.
- 노션형 실험에서는 녹음·AI 채팅·데이터베이스 생성, 캔바형 실험에서는 요소 편집·텍스트 수정·파일 내보내기를 직접 확인한다.
- AI가 추론한 요구사항과 구현 결과가 실제로 원하는 업무에 맞는지 사람이 검토한다.
- 직접 개발과 SaaS 이용을 비교할 때 구현뿐 아니라 운영·보안·유지보수와 데이터 보관 책임을 함께 검토한다.
❓ 열린 질문
- REA로 재구현한 프로그램은 실제 업무에서 원본의 기능과 안정성을 어느 수준까지 충족할 수 있을까?
- 기능 구현 비용이 낮아질 때 SaaS의 데이터·업무 이해와 서비스 신뢰성은 얼마나 강한 경쟁력이 될까?
- AI가 기존 제품에서 추론한 요구사항의 누락과 오류를 사람은 어떻게 판단할 것인가?