“이 서비스의 예약 과정은 왜 편할까?” “AI로 만든 우리 서비스는 어디부터 고쳐야 할까?” 좋은 화면을 발견해도 이를 개발 요청으로 옮기기는 쉽지 않습니다. 버튼의 색보다 중요한 것은 사용자가 어떤 정보를 보고, 무엇을 입력하며, 실패했을 때 어떻게 다시 진행하는지입니다.
REA는 이런 질문을 근거 있는 분석으로 이어가는 데 활용할 수 있는 도구입니다. 이 글에서는 비개발자와 서비스 운영자가 REA를 이해하고, 관찰 결과를 자신의 서비스 개선에 활용하는 방법을 소개합니다.
1. REA는 어떤 도구인가요?
여기서 말하는 REA는 Reverse Engineer Anything으로, 공식 저장소는 morluto/rea입니다. AI 에이전트가 분석 도구를 사용할 수 있도록 연결하는 MCP 서버와 명령줄 도구(CLI)를 제공합니다. MCP는 AI와 외부 도구를 연결하는 공통 연결 방식이라고 이해하면 됩니다.
공식 문서에는 웹사이트, JavaScript·Electron 앱, 네이티브 실행 파일 등 여러 분석 대상이 소개되어 있습니다. 다만 대상마다 필요한 환경과 도구가 다릅니다. 서비스 운영자가 처음 살펴볼 부분은 웹 화면과 사용자 행동을 관찰하는 기능입니다.
리버스 엔지니어링은 이미 만들어진 결과에서 구조와 동작을 거슬러 이해하는 접근입니다. 이 글의 활용 방향은 허가된 범위에서 서비스의 흐름을 이해하고, 우리 고객에게 필요한 요구사항을 새롭게 설계하는 것입니다.
2. 웹 서비스에서 무엇을 확인할 수 있나요?
공식 브라우저 관찰 문서에 따르면 REA는 Chrome 계열 브라우저에 연결해 페이지 구조와 스크립트, 관찰 구간의 네트워크 정보 등을 수집하고, 요청한 화면을 캡처할 수 있습니다. 페이지 이동이나 오류 등 사용자의 행동에 따른 변화를 관찰하는 기능도 있습니다.
여기서 관찰 기능과 자동 조작은 구분해야 합니다. 문서에서 설명하는 CDP 관찰은 기존 페이지를 살펴보는 기능이며, 스스로 모든 버튼을 눌러 업무를 끝내는 범용 자동화 기능과 같지 않습니다. 작업 시나리오를 실행하는 별도 기능은 다른 전제와 권한을 가집니다.
- 확인할 수 있는 것: 허가된 화면의 구성, 관찰된 이동 순서, 실제로 포착된 요청·오류, 선택한 화면의 모습.
- 추가 검증이 필요한 것: 특정 버튼이 보이지 않는 이유, 사용자 역할별 차이, 예외 상황에서의 동작.
- 화면만으로 확정할 수 없는 것: 서버 내부 코드, 전체 데이터베이스 구조, 모든 권한 규칙과 결제·정산 로직.
REA 연결 이전에 발생한 네트워크 활동은 관찰 결과에 없을 수 있습니다. 기록이 없다는 이유로 “그 기능은 없다”고 결론 내리면 안 됩니다. 결과에 표시된 관찰 범위와 누락도 함께 읽어야 합니다.
3. 운영자를 위한 활용 순서: 한 가지 흐름부터
① 개선할 질문을 하나 정합니다
“서비스 전체를 분석해 주세요”보다 “예약 날짜를 고른 뒤 완료하기까지 사용자가 헷갈리는 지점을 찾고 싶습니다”가 유용합니다. 가입, 검색, 예약, 문의 중 가장 중요한 흐름 하나를 선택하세요.
② 접근 범위와 테스트 조건을 정합니다
자사 서비스나 분석 허가를 받은 환경을 대상으로, 확인할 페이지·계정 역할·테스트 데이터를 정합니다. 실제 고객 정보 대신 테스트 데이터를 사용하고, 결제나 알림 발송처럼 외부에 영향을 주는 동작은 사전에 범위를 정해야 합니다.
③ 관찰한 사실과 해석을 따로 적습니다
각 단계마다 시작 화면, 사용자 행동, 결과 화면, 오류 문구를 기록합니다. “뒤로 가기를 누르니 날짜 선택이 사라졌다”는 관찰입니다. “그래서 고객이 이탈할 것이다”는 가설이므로 고객 피드백이나 운영 데이터로 확인해야 합니다.
④ 우리 서비스의 요구사항으로 바꿉니다
분석 결과는 “비슷하게 만들어 주세요” 대신 누가, 어떤 상황에서, 무엇을 할 수 있어야 하는지로 작성하세요. 기능마다 완료 기준을 붙이면 개발자나 AI가 구현 결과를 확인하기 쉬워집니다.
⑤ 작은 변경을 적용하고 다시 확인합니다
핵심 흐름 하나를 먼저 개선한 뒤 데스크톱과 모바일에서 정상 진행, 잘못된 입력, 되돌아가기, 중복 클릭을 확인합니다. 문의 완료율이나 반복 문의 건수 등 서비스에 맞는 지표를 정하되, 개선 효과를 미리 보장하지는 않습니다.
4. 가상 예시: 예약 화면을 요구사항으로 정리하기
아래는 방법을 설명하기 위한 가상 예시이며, 코드픽이 실제 수행한 프로젝트나 REA 실행 결과가 아닙니다.
- 관찰: 시간 선택 후 연락처 입력 단계에서 뒤로 가면 선택한 시간이 초기화됩니다.
- 확인할 질문: 의도한 정책인가요? 모바일에서도 같은가요? 시간이 만료된 경우와 일반 이동을 구분하나요?
- 개선 요구사항: 일반적인 단계 이동에서는 선택값을 유지하고, 예약이 불가능해졌다면 이유를 안내하고 다시 선택할 수 있게 합니다.
- 완료 기준: 유효한 선택값은 뒤로 이동해도 유지됩니다. 만료된 시간으로는 예약되지 않으며, 재선택 안내가 표시됩니다.
- 운영 검증: 실제 예약 완료와 관리자 기록이 일치하는지, 중복 예약을 막는지는 서버와 데이터 처리를 별도로 점검합니다.
이렇게 정리하면 화면을 따라 그리는 작업에서 벗어나 우리 서비스가 지켜야 할 동작을 논의할 수 있습니다. 분석 문서에는 화면 근거, 확인되지 않은 항목, 우선순위, 검증 방법을 함께 남겨두세요.
5. 시작 전에 알아둘 한계와 준비 사항
공식 설치 안내는 Node.js와 npm 환경에서 npx rea-agents setup을 실행하고 연결할 에이전트와 설정 변경을 검토하도록 설명합니다. Codex 등 지원 에이전트가 있지만, 설치됐다는 사실만으로 브라우저 연결이나 분석 성공을 의미하지는 않습니다. 분석 대상과 실행 환경에 맞는 준비가 필요합니다.
2026년 10월 16일 확인한 공식 릴리스 목록에는 v6.5.0이 최신으로 표시되어 있습니다. 기능과 요구사항은 바뀔 수 있으므로 도입 시 공식 릴리스와 설치 문서를 다시 확인하세요. 이 글은 공개 자료를 바탕으로 작성한 소개이며 특정 Mac 환경의 실행 성공을 보증하는 사용 후기가 아닙니다.
또한 AI가 작성한 설명은 검토가 필요합니다. 실제로 본 내용과 추론을 구분하고, 운영 정책은 담당자가 확정해야 합니다. 로컬 분석 도구를 사용하더라도 연결한 AI 서비스로 전달되는 내용과 보관 설정은 별도로 확인하세요.
자신이 소유하거나 분석을 허가받은 대상과 접근 범위를 지키세요. 타사 코드·브랜드·이미지를 그대로 복제하거나, 인증을 우회하거나, 비공개 정보를 추출하는 방식은 이 글에서 권하는 활용이 아닙니다. 수집된 화면과 로그에 개인정보가 포함되지 않았는지 확인하고 필요한 자료만 공유하는 것이 좋습니다.
6. 분석 다음에는 실제로 운영할 수 있는 구조가 필요합니다
화면과 흐름을 이해했다면 다음 단계는 기능의 우선순위, 데이터 구조, 권한, 서버, 배포와 운영을 연결하는 일입니다. AI로 화면을 만들었더라도 이 부분에서 프로젝트가 멈추는 경우에는 현재 상태와 남은 요구사항부터 정리해야 합니다.
코드픽은 초기 기획·아키텍처·서버 구축부터, AI로 직접 만들다가 막힌 프로젝트의 완성·배포·운영을 지원합니다. 고객이 이후 AI와 함께 직접 수정하기 쉬운 구조와 인수인계도 함께 다룹니다. 분석 자료와 현재 서비스, 가장 먼저 해결하고 싶은 흐름을 준비하면 상담에서 작업 범위를 구체화하는 데 도움이 됩니다.
확인한 출처와 더 읽을 자료
확인일: 2026년 10월 16일. 기능 설명은 공식 저장소와 문서를 기준으로 작성했습니다. 공개 소개 글과 사례는 활용 방향을 비교하는 데 참고했으며, 문구와 이미지를 재사용하지 않았습니다.
- REA 공식 저장소 — 개요와 설치 안내
- REA 공식 문서 — 브라우저 관찰과 범위·한계
- REA 공식 릴리스 — 버전별 변경 사항
- REA 공식 이용 범위 안내
- REA 공식 공개 사례 — 분석과 검증의 예시
- Eigent의 REA 소개 글 — 외부 활용 관점 참고
대표 이미지: 코드픽 글을 위해 AI로 새로 제작한 개념 일러스트. 보라색 경로로 연결된 서비스 화면을 확대경으로 살펴보고 요구사항 체크리스트와 개선 화면으로 연결하는 모습입니다.