REA 안전하게 시작하기: 첫 연습, 팀 점검표, 30/60/90일 계획

시리즈의 앞선 세 편은 남들이 무엇을 시험했는지, 문서가 무엇을 가능하다고 하는지, 설계가 무엇을 내주는지를 살폈습니다. 마지막 편은 실용적인 질문을 다룹니다. 소중한 것을 위험에 빠뜨리지 않고 REA를 써 보려면 어떻게 해야 하고, 팀은 계속 쓸 가치가 있는지 어떻게 판단할까?

개요 글에 이미 일반적인 학습 순서와 ’직접 만든 프로그램으로 연습하기’가 있습니다. 이 글은 범위를 좁혀, 공식 픽스처를 쓰는 연습 하나와 시범 도입 계획을 다룹니다.

확인 날짜는 2026년 10월 14일입니다. 이 글에 나오는 명령과 옵션은 그날 확인한 6.4.0 공식 문서의 설명이지, 언제나 통하는 방법이 아닙니다. 설치하는 버전의 공식 시작 안내를 항상 따르세요. Motitory는 REA를 실행하지 않았으므로, 아래 단계는 우리가 직접 실행한 결과 보고가 아닙니다. 점검표, 성공 기준, 30/60/90일 계획은 Motitory의 제안이며, REA의 요구 사항이나 업계 표준이 아닙니다.

무엇보다 먼저: 허락과 데이터

아래 모든 단계에 두 가지 원칙이 적용됩니다.

직접 소유했거나 명시적으로 허락받은 것만 분석하세요. REA의 MIT 라이선스는 REA의 코드에 관한 것입니다. 분석 대상에 대한 권리는 주지 않고, Ghidra, JADX, Frida 같은 외부 도구에는 각자의 라이선스가 있습니다(외부 도구). 내려받을 수 있다는 것은 허락이 아닙니다. 이 글은 법률 조언이 아니며, 확실하지 않다면 분석하지 마세요.
’로컬’이어도 결과는 모델로 갑니다. REA는 여러분의 컴퓨터에서 도구를 돌리지만, 에이전트가 연결되어 있으면 도구 출력은 그 모델 제공자에게 갑니다. 그리고 브라우저, 프록시, 기기, Frida 같은 런타임 경로는 상태를 바꿀 수 있습니다(로컬 영향). 첫 연습이 런타임 경로와 민감한 대상을 모두 피하는 이유입니다.

먼저 알아 둘 것

전체 학습 순서는 개요 글에 있습니다. 이 연습과 시범 도입에 필요한 최소한은 이 정도입니다.

수준	알아 둘 것	여기서 중요한 이유
입문	무엇을 분석해도 되고 무엇이 범위 밖인지	나머지 모든 것이 여기에 달려 있음
입문	셸 사용: 절대 경로, JSON 출력 읽기	설정과 Evidence가 JSON
입문	기초 JavaScript: 모듈, import, 이벤트 핸들러	첫 대상이 Electron 앱
입문	관찰, 추론, 모름을 구분하기	Evidence를 읽는 핵심 기술
중급	C, 포인터와 메모리, 호출 규약, 실행 파일 형식	네이티브 대상을 다루기 전에
중급	디컴파일러가 틀리는 지점	의사 코드는 소스가 아님
중급	가상 머신, 별도 계정, 네트워크 규칙으로 격리하기	런타임 경로를 쓰기 전에
중급	CDP와 네트워크 캡처가 볼 수 있는 것	브라우저·프록시 경로는 민감한 데이터를 기록함
중급	로컬 MCP 서버의 위협 모델	REA는 샌드박스가 아님(보안 경계)
중급	공급망과 외부 도구 라이선스	provider는 직접 설치하고 라이선스를 갖춰야 함

생각할 수 있는 가장 위험이 낮은 첫 연습

대상은 프로젝트가 직접 제공하는 Notes 예제입니다. 첫 조사 안내와 notes-example.zip이 그것으로, 작고 공개되어 있으며 분석하라고 만든 것입니다. 원한다면 직접 만든 프로그램을 써도 됩니다. 이 연습에서는 그 밖의 것은 쓰지 마세요.

1. 버전을 골라 고정합니다. 검토한 릴리스 버전 하나를 고르고(이 글을 쓰는 시점이라면 6.4.0), 그 릴리스 노트를 읽습니다. main과 npm 릴리스는 다르다는 점을 기억하고(릴리스와 main), 한 연습 안에서 둘을 섞지 마세요.

2. 얼마나 보수적으로 갈지 정합니다.

가장 보수적인 방법: 에이전트를 연결하지 않고 CLI로 정적 분석만 합니다. 여러분이 직접 붙여 넣지 않는 한 모델 제공자에게 가는 것은 없습니다.
에이전트와 함께: 6.4.0 문서는 먼저 setup을 --client <클라이언트> --dry-run --json으로 실행하라고 설명합니다. 무엇이 바뀔지 읽고 직접 승인한 다음, 그 클라이언트 하나로 범위를 좁혀 실제 설정을 하고, doctor --client <클라이언트> --json으로 결과를 확인합니다. 정확한 명령은 여기가 아니라 시작 안내에서 가져오세요.

3. 원본은 건드리지 않습니다. 공식 사이트에서 ZIP을 받아 SHA-256 해시를 기록하고, 읽기 전용 사본을 보관합니다. 작업은 지워도 되는 폴더의 사본으로 합니다.

4. 좁은 질문 하나를 정적으로 던집니다. 예를 들면 “사용자가 Export notes를 고르면 데이터는 CSV가 되기까지 어떤 함수들을 거치고, 포매터는 메모 안의 쉼표, 큰따옴표, 줄바꿈을 어떻게 처리하나?” 같은 질문입니다. 정적 분석만 허용하고, REA로 앱을 실행하지는 마세요.

5. 답을 세 칸으로 나눕니다. Evidence가 보여 주는 것(파일과 위치 포함), 에이전트가 추론한 것, 모른다고 적힌 것입니다. 모르는 것이 하나도 없다면 다시 보세요. 같은 픽스처에 대한 독립 실행에서도 프로젝트 전체 그래프에는 44개가 남았습니다(1편).

6. 예측 하나를 독립적으로 시험합니다. 구체적인 예측 하나, 예를 들어 제목이 He said "hi", then left인 메모가 CSV에서 어떤 줄이 되어야 하는지를 골라, 에이전트 밖에서 직접 확인합니다. 픽스처 소스의 포매터를 직접 읽거나, 그것이 평범한 함수라면 지워도 되는 폴더에서 짧은 테스트로 불러 봅니다. 그리고 RFC 4180이 따옴표와 쉼표를 다루는 방식과 비교합니다. 예측이 맞으면 두 종류의 근거를 갖춘 주장이 하나 생기고, 틀리면 그만큼 더 배운 것입니다.

7. 기록합니다. 버전, ZIP 해시, 질문, 검토를 포함해 쓴 시간, 확인한 주장을 적습니다. 이 기록이 있어야 연습을 다시 하고 나중에 비교할 수 있습니다.

팀을 위한 점검표

팀이 더 나아가려 한다면, 첫 실제 대상 전에 답해 둘 질문들입니다. 묶음마다 내부 문서 한 쪽이면 충분합니다.

허락. 대상마다 소유자의 서면 승인, 그리고 허용하는 작업의 명확한 범위(정적 분석만인지, 특정 런타임 경로까지인지).
환경. 비밀, 쿠키, 고객 데이터가 없는, 버려도 되고 권한이 낮은 환경. 원본은 해시를 남기고 읽기 전용으로 보관.
공급망. 공식 출처에서만 설치. 버전, 다이제스트, 잠금 파일 고정. dry-run 출력 검토. 설정은 클라이언트 하나로 제한. 업데이트는 따로 계획한 시간에.
연결과 통제. stdio나 루프백만 사용. 호출마다 정확한 명령 표시. 파일 시스템과 외부 통신 제한, 에이전트에게 보이는 도구 걸러 내기, destructive나 기기 변경으로 표시된 것은 호출마다 승인. REA의 주석은 힌트일 뿐이고 승인을 강제하는 것은 클라이언트라는 점을 기억할 것.
데이터. 대상에 무엇이 담겼는지 분류. 모델 제공자의 데이터 정책 확인. 가능한 곳은 가리기. Evidence의 보관 기간, 접근 권한, 삭제 방법 정하기.
방법. 좁은 질문. 정적 분석부터, 가설을 세운 뒤, 필요할 때만 승인된 동적 단계. 사실, 추론, 모름을 분리. 중요한 결론에는 두 종류의 근거.
운영. 되돌리기 계획. provider 프로젝트와 캡처 정리. 매달 또는 릴리스마다 OS, provider, REA 버전의 호환성 점검. 사고 보고 경로.

효과가 있는지 판단하는 법: 제안하는 기준

시범 도입에 우리가 제안하는 기준이지, 보편적인 표준이 아닙니다. 숫자는 각자 정하되, 시작하기 전에 정하세요.

잴 것	제안 기준
직접 근거가 있는 중요한 주장	100%
주장 정밀도(확인했을 때 맞는 주장)	95% 이상
잘못된 확신(사실처럼 말했지만 실제로는 모르거나 틀린 것)	전체 2% 이하, 고위험 주장은 0
재현성(같은 버전과 입력에서 같은 중요 결론)	95% 이상
검토 시간을 포함한 시간 절약의 중앙값	30% 이상
허락 없는 접근, 의도하지 않은 외부 전송, 비밀 노출	0
제품·보안 결론에 대한 사람의 승인	100%

가장 중요하면서 가장 부풀리기 쉬운 것이 시간 절약입니다. 실행이 얼마나 빨리 끝났는지가 아니라, 누군가 Evidence를 읽는 데 쓴 시간까지 세세요.

30/60/90일 계획

1~30일: 픽스처, 정적 CLI. 공식 픽스처와 직접 만든 내부 픽스처처럼 답을 아는 대상. 목표는 감 잡기입니다. 에이전트는 얼마나 자주 맞고, 얼마나 자주 모른다고 인정하나?
31~60일: 승인된 테스트 앱, 제한된 관찰. 지워도 되는 환경에서 자체 테스트 빌드에 대해, 승인된 만큼만 브라우저나 프로세스를 관찰합니다. 목표는 런타임 근거가 무엇을 더해 주고, 설정과 검토에 무엇을 치르게 하는지 보는 것입니다.
61~90일: 별도 샌드박스의 네이티브 provider. 라이선스를 확인한 Ghidra나 다른 provider를 별도 샌드박스에 더합니다. 목표는 여러분의 대상에서 네이티브 경로가 그 부담만큼 값어치를 하는지 보는 것입니다.

어느 단계에서든 멈추세요. 작업이 승인된 범위를 벗어나거나, 비밀이 노출되거나, 중요한 결론이 재현되지 않거나, 라이선스가 불분명하거나, 검토 비용이 아낀 시간보다 크다면요. 멈추는 것도 시범 도입의 결과이지 실패가 아닙니다.

시리즈를 마치며

네 편에 걸친 그림은 한결같습니다. REA의 가장 강한 아이디어는 무엇을 보지 못했는지 말해 주는 결과입니다. 공개된 실적은 독립 실행 두 편이고 둘 다 JavaScript였습니다. 한계는 provider, 플랫폼, 권한, 그리고 정적으로 읽은 것과 실행했을 때의 진실 사이의 간격에서 옵니다. 가장 안전한 입구는 작고, 내 것이고, 정적이며, 기록으로 남는 연습입니다. 신중하게 무언가를 실행하고 Evidence를 공개한다면, 이 시리즈보다 REA에 관한 우리 모두의 이해에 더 많은 것을 보탤 것입니다.

참고 자료

공식 시작 자료: 시작 안내, 첫 조사, Notes 예제 ZIP
커밋 29d3dcb의 REA: 릴리스와 main, 로컬 영향, 신뢰할 수 없는 대상 콘텐츠, 보안 경계, 책임 있는 사용, 외부 도구
릴리스: rea-agents-6.4.0
생태계: MCP 보안 모범 사례, OpenAI Agents SDK: MCP 승인과 필터링
이 블로그: REA 개요, CSV와 RFC 4180

링크와 내용은 2026년 10월 14일에 확인했습니다.