REA도 역공학도 안 쓰고 노션을 복제했더니?

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

REA도 역공학도 안 쓰고 노션을 복제했더니를 중심으로, 클로드 코드가 어사이드 브라우저를 제어해 노션의 메뉴와 블록을 직접 조작했다. 역공학 도구와 DOM 구조 분석을 배제하고, 화면에를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. 클로드 코드가 어사이드 브라우저를 제어해 노션의 메뉴와 블록을 직접 조작했다. 역공학 도구와 DOM 구조 분석을 배제하고, 화면에서 확인한 동작을 구현의 출발점으로 삼았다.
2. 기본 블록, 페이지 계층, 인라인 서식, 데이터베이스와 설정 등을 조사해 12개 카테고리의 명세를 작성했다. 모듈별로 수십 장의 스크린샷을 확보했지만, 실제 관찰과 AI의 추정이 섞였는지 확인할 필요가 있었다.
3. 분석 도중 구현을 먼저 시작하는 문제가 발생해 작업 순서를 바로잡았다. 이모지 같은 세부 기능에 시간이 쏠린 사례도 있어, 분석 범위와 우선순위를 관리하는 사람의 개입이 필요했다.
4. 구현과 브라우저 비교를 반복하며 제목 선택, 사이드바 상태, 마우스 이벤트 등의 문제를 수정했다. 그러나 AI가 통과했다고 평가한 뒤에도 직접 테스트에서 행 선택과 팝업 메뉴의 오작동이 발견됐다.
5. 최종 검수는 검증표 289개 행의 기록 대조, 원본과 복제본의 좌우 비교, 별도 에이전트의 독립 테스트로 구성했다. 기능 90% 이상 일치를 완료 조건으로 정했으나, 제공된 구간에는 이를 달성했다는 최종 결과가 없다.

🧩 배경과 문제 정의

• REA와 역공학을 활용한 서비스 복제에 관심이 집중된 상황에서, 화면에 드러나는 기능만 관찰해도 AI가 기존 서비스를 얼마나 비슷하게 구현할 수 있는지 실험한다.
• 복제 대상은 노션이다. 사람이 기능을 분석해 전달하는 대신, 클로드 코드가 어사이드 브라우저를 제어해 메뉴와 블록을 직접 조작하고 구현에 필요한 정보를 수집한다.
• 역공학 도구와 DOM 구조 분석을 배제하고 화면 관찰에 의존한다. 구현 결과도 브라우저로 비교하며, 검증표에서 90% 이상을 달성할 때까지 수정하는 것을 목표로 한다.
• 실제 관찰과 AI의 추정이 섞일 가능성이 있으므로 명세의 근거를 확인해야 한다. 제공된 구간 끝에서도 전체 구현은 완료되지 않은 상태다.

🕒 시간순 섹션별 상세정리

1. REA 없이 화면 조작만으로 노션 복제를 시도한다

• 특정 서비스를 복제할 때 REA가 반드시 필요한지 의문을 제기한다. 이미 알려진 기능을 AI 에이전트에 구현하도록 요청하는 방식의 가능성을 시험한다 [00:36]
• 사람이 노션을 분석해 요구사항을 전달하는 대신, 클로드 코드가 어사이드 브라우저로 메뉴를 클릭하고 페이지 구조와 블록 생성 방식을 직접 관찰하도록 한다 [01:31]

2. 화면 분석·구현·비교 검증을 하나의 작업으로 연결한다

• 오르카에 노션 클론 프로젝트를 만들고, 클로드 코드를 오토 모드로 실행한다. 모델은 오퍼스 5.5, 에퍼트는 미디엄으로 설정한다 [04:00]
• 초기 지시에는 역공학 도구뿐 아니라 DOM 구조 분석도 금지한다. 어사이드가 메뉴 클릭과 화면 캡처로 분석하고, 클로드 코드가 그 결과에 따라 최대한 노션과 비슷하게 구현하도록 한다 [04:42]

3. 작업 권한과 구현 범위를 넓게 설정한다

• 분석 과정에서 실제 노션 워크스페이스에 최상위 페이지 등을 만들 수 있도록 폭넓은 조작을 허용한다 [06:28]
• 기술 구성은 서버 없이 브라우저에서 기능을 구현하는 간단한 방향으로 정하고, 데이터베이스도 가능한 기능을 모두 다루도록 범위를 잡는다 [06:54]

4. 테스트 페이지에서 기본 블록과 서식을 관찰한다

• 어사이드가 화면을 캡처하며 작동하고, 클로드 코드가 보낸 지시가 브라우저 에이전트 탭에 나타난다. 알려진 서비스라도 세부 기능을 직접 눌러 확인해야 구현 계획을 구체화할 수 있다는 전제다 [09:04]
• 개인 페이지에 클론 실험용 페이지와 하위 샘플 페이지를 생성해 페이지가 만들어지는 방식과 구조를 확인한다 [10:43]

5. 페이지 중첩과 이동까지 조사하지만 세부 기능에 시간이 쏠린다

• 페이지 안에 다시 페이지를 만들고, 드래그로 위치를 바꾸거나 다른 페이지 내부로 이동시키며 계층 구조와 이동 동작을 시험한다 [12:16]
• 라이트 모드와 다크 모드를 전환하고 차트 관련 기능도 살펴본다. 차트는 이 시점에 생성하지 않고 기능을 훑어보는 수준이다 [12:53]

6. 분석 도중 구현을 시작한 작업 순서를 바로잡는다

• 화면 분석이 진행되는 동안 코드 작성과 첫 빌드도 함께 진행되는 정황이 나타난다. 이는 분석을 마치고 계획서를 작성한 뒤 구현하려던 의도와 다르다 [14:30]
• 분석이 끝나기 전에 구현하지 말라는 지시를 추가한다. 이후 작업 순서를 다시 정리하고, 분석을 완전히 마친 뒤 코드를 작성하는 방향으로 수정한다 [15:15]

7. 분석 범위를 점검하고 실제 UI의 세부 차이를 발견한다

• 중간 점검에서 쉘, 디자인 토큰, 사이드바, 블록·슬래시 메뉴 분석은 완료된 상태다. 페이지 구조, 인라인 서식, 블록 조작, 고급 블록은 진행 중이며 데이터베이스·뷰·검색·설정 등은 추가 분석이 필요하다 [16:12]
• 관찰 중인 노션의 텍스트 선택 메뉴가 상단 가로 툴바가 아니라, 선택 끝의 파란 손잡이 옆에 붙는 세로 카드 형태라는 차이를 발견한다 [17:08]

8. 모듈마다 수십 장의 스크린샷을 근거로 명세를 만든다

• 데이터베이스를 생성해 여러 뷰로 바꾸고, 이미지와 수학식 같은 고급 블록도 시험한다 [18:21]
• 중간 집계에서 A1은 35장, A2는 거의 90장, 페이지 구조는 61장, 블록·슬래시 메뉴는 32장, 인라인 서식은 41장, 블록 조작은 30장의 스크린샷을 확보한다 [18:51]

9. 분석을 마치고 기획 문서와 기본 구현으로 넘어간다

• 남은 분석 결과를 반영한 뒤 기획서를 확정하고 구현을 시작하는 순서로 진행한다 [20:13]
• 전체 분석이 끝나 기획 문서를 작성하며, 분석 중 만들었던 테스트 페이지는 휴지통으로 정리한다 [20:33]

10. 원본과 구현 결과를 비교하며 즉시 수정한다

• 분석 결과를 정리한 계획서에 따라 구현하고, 프런트엔드를 로컬호스트 5173 포트에서 실행한다. 이 시점의 화면에서는 대부분의 기능이 의도대로 작동한다는 중간 평가가 나온다 [21:18]
• 클로드 코드와 어사이드가 차이를 발견하면 수정하고 다시 테스트하는 과정을 반복한다 [21:46]

11. 기능 명세에 화면 구조와 편집 동작을 구체적으로 기록한다

• 기능 명세에는 최상위 빈 페이지, 사이드바 구조와 페이지 행, 하단 메뉴, 휴지통 패널의 동작을 상세히 정의한다 [23:01]
• 페이지 제목 정렬과 하단 정보, 아이콘, 상단바·공유·댓글뿐 아니라 슬래시 메뉴의 출현 조건과 크기도 기록한다. 슬래시 메뉴 폭은 약 325로 명시되어 있다 [23:43]

12. 데이터베이스 명세를 확장하고 관찰과 추정을 구분한다

• 데이터베이스 명세에는 생성 메뉴, 상단 구조와 표 모양, 속성 추가, 필터·정렬 옵션을 정의한다. 약 여섯 가지 보기를 분석하며 보드·리스트·갤러리·캘린더·타임라인 등을 포함한다 [25:03]
• 검색·단축키·휴지통과 설정·홈까지 포함해 총 12개 카테고리의 명세를 작성한다 [25:42]

13. 개발 순서와 단계별 검증 기준을 문서로 관리한다

• 개발 순서표는 D1부터 D15까지 총 15단계로 구성한다. 디자인 토큰, PRD, 노션 클론 기획서도 함께 작성한다 [26:26]
• 검증 절차와 통과 기준은 QC 관련 세 문서에 정리한다. D1·D2, D3·D4, D5 등 단계별 검증 기록도 관리한다 [26:47]

14. 블록 편집과 인라인 기능을 보완한다

• 블록 메뉴와 2단 열이 작동하는 상태에서 미구현 항목을 확인한다. 마우스 이벤트가 연결되지 않은 문제도 발견해 수정한다 [27:55]
• 링크 팝오버, 링크 호버 막대, 인라인 수식 렌더링을 구현한다. 수식 표시는 KaTeX 문법을 사용하는 방향이다 [28:11]

15. 고급 블록 작업을 마쳤지만 전체 15단계 중 9단계까지 진행됐다

• 고급 블록 작업 완료 내역에는 코드, 표, 이미지, 북마크, 임베드, 동영상, 파일, 수식 블록과 콜아웃 관련 변경이 포함된다 [29:11]
• 검수 과정에서 발견한 버그 세 개도 수정했으며, 변경 결과는 로컬호스트 5173 포트에서 확인할 수 있는 상태다 [29:30]

16. 데이터베이스 기능 구현과 실제 사용 검증의 차이

• 데이터베이스 블록 관련 검증 항목이 남아 있으며, 속성 칸 표시와 필터·정렬 카드, 오른쪽 보기 설정 패널을 구현한다 [30:36]
• 브라우저 검증에서는 필터·정렬·검색·그룹 설정 패널 등이 통과했다는 결과가 나왔지만, 사이드바에서 버그가 발견돼 수정이 계속된다 [31:04]

17. 반복 비교와 독립 검수로 완료 조건 구체화

• 화면을 촬영해 노션과 비교하고 차이점을 보완하는 작업을 반복한다. 최종 검수에서는 검증표의 289개 행이 단계별 기록에 모두 포함됐는지 대조한다 [32:31]
• 실제 노션과 복제본을 좌우에 띄워 기능을 비교하고 미비점을 보완하는 최종 테스트를 계획한다. 완료 조건은 두 프로그램의 기능이 90% 이상 일치하는 것이다 [33:12]

18. 동작 관찰을 통한 재구성과 검증 판단의 중요성

• 실험의 핵심은 노션을 얼마나 똑같이 복제했는지보다, 소스 코드 없이 동작을 충분히 관찰해도 AI가 소프트웨어를 재구성할 수 있는지에 있다. 이번 실험에서는 그 가능성을 확인했다는 결론을 내린다 [35:15]
• 이후 실제 결과를 바탕으로 성공한 기능, 구현하지 못한 기능, 사람이 개입한 순간을 평가하고 다시 피드백하는 과정이 후속 과제로 드러난다 [35:45]

🧾 결론

• 화면 조작과 동작 관찰을 명세로 바꾸고 구현에 연결하는 방식으로, 소스 코드 없이도 노션의 여러 기능을 재구성할 가능성을 보여줬다.
• 복제 품질은 코드 생성뿐 아니라 관찰의 정확성, 명세의 근거, 실제 사용 동작을 포함한 검증 기준에 좌우됐다.
• 실험의 성과를 평가하려면 최종 구현 결과와 함께 성공한 기능, 미구현 기능, 사람이 개입한 지점을 확인해야 한다.

📈 투자·시사 포인트

• 소프트웨어 개발에서 AI 활용 범위가 코드 작성뿐 아니라 기능 조사, 명세 작성, 브라우저 테스트까지 이어질 수 있음을 보여주는 사례다.
• AI 개발 도구를 평가할 때 생성된 화면이나 자체 통과 보고와 함께, 원본과의 동작 비교 및 독립 검수 결과를 살펴볼 필요가 있다.
• 무엇을 먼저 관찰하고 어떤 조건에서 완료로 판단할지 정하는 역량이 중요해진다. 이번 실험에서는 우선순위 조정과 검증 기준 보완에 사람이 개입했다.
• 개발 비용, 소요 시간, 유지보수 성과에 관한 비교 수치는 제시되지 않았다. 이 사례만으로 특정 기업의 수익성이나 투자 매력도를 판단할 근거는 부족하다.

⚠️ 불확실하거나 확인이 필요한 부분

• 기능 90% 일치는 목표이자 완료 조건이다. 최종 통과율과 미통과 항목이 공개된 결과처럼 해석해서는 안 된다.
• 명세에 실제 관찰한 내용과 AI가 추정한 내용이 섞일 수 있다. 상세한 명세나 많은 스크린샷만으로 모든 기능의 근거가 확인됐다고 볼 수 없다.
• AI의 브라우저 검증과 사람의 직접 테스트에서 판단 차이가 나타났다. 검증표 289개 행이 기록에 포함됐는지 확인하는 것과 각 기능이 올바르게 작동하는지는 별도로 점검해야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 명세 항목마다 실제 관찰, 스크린샷 근거, AI 추정을 구분하고 추정 항목은 원본에서 다시 확인한다.
• 분석 완료와 기획서 확정을 구현 시작 조건으로 명시하고, 핵심 기능부터 조사하도록 우선순위를 정한다.
• 검증표 289개 행과 단계별 기록을 대조한 뒤, 원본과 복제본을 나란히 놓고 동일한 조작을 수행한다.
• 행 선택, 드래그, 중첩, 마우스 이동 팝업 등 직접 테스트에서 차이가 드러난 동작을 재검증한다.

❓ 열린 질문

• 기능 90% 일치율은 어떤 항목과 가중치로 계산하며, 핵심 편집 동작의 실패는 어떻게 반영하는가?
• 실제 관찰로 확인된 명세와 AI가 추정한 명세는 각각 얼마나 되며, 추정 항목의 재확인은 끝났는가?
• 최종 구현에서 남은 기능과 버그는 무엇이고, 분석·구현·검수 과정에 사람이 얼마나 개입했는가?