· 개발

REA의 장점과 그 대가, 그리고 앞으로 12~24개월의 다섯 가지 시나리오

REA의 장점은 대부분 같은 설계에서 나온 대가와 짝을 이룹니다. 여섯 쌍의 장단점, 누가 이득을 보는지, 반대 시나리오와 지켜볼 신호를 붙인 다섯 가지 조건부 시나리오. 예측이 아니라 분석입니다.

개발보안리버스 엔지니어링AI 에이전트

장단점 목록은 보통 출처가 다릅니다. 장점은 README에서, 단점은 누군가의 고생담에서 옵니다. REA는 거꾸로 보는 편이 낫습니다. 장점 거의 모두가 어떤 설계 결정에서 나오고, 그 결정이 대가도 함께 만들기 때문입니다. 이 글은 둘을 짝지어 본 다음, 같은 사실을 바탕으로 앞으로 일이 어디로 갈 수 있는지를 그려 봅니다.

개요 글에 이어지는 네 편 중 세 번째입니다.

  1. 최근 글들은 실제로 무엇을 시험했나
  2. 할 수 있는 것과 한계
  3. 장점과 대가, 그리고 앞으로의 시나리오 (이 글)
  4. 안전하게 시작하기

확인 날짜는 2026년 10월 14일입니다. REA에 관한 사실은 커밋 29d3dcb에 고정한 문서와 6.4.0 릴리스에서, 실제 실행에서 나온 수치는 1편에서 다룬 두 독립 실행 후기에서 가져왔습니다. Motitory는 REA를 실행하지 않았습니다. 장단점의 짝짓기, ‘누가 이득을 보나’ 절, 모든 시나리오는 Motitory 분석입니다. 위 자료로부터 추론한 것이지 잰 것이 아니고, 예측도 아닙니다.

여섯 가지 장점과 각각의 대가

장점 어디서 오나 같은 선택이 치르는 대가
CLI와 MCP, 여러 대상 유형에 걸친 하나의 Evidence 계약 모든 도구가 같은 결과 형태를 씀(도구 결과) 그 아래의 능력 표는 OS, provider, 버전에 따라 조각나 있어서, 같은 계약이 한 컴퓨터에서는 ’동작’을, 다른 컴퓨터에서는 ’사용 불가’를 뜻할 수 있음
결과에 식별 정보, 커버리지, 한계, 모르는 것이 담김 Evidence가 보지 못한 것을 말하도록 설계됨 출력이 매우 커짐. 한 실행에서는 1.6KB 픽스처에 약 907KB, 다른 실행에서는 요약 672KB와 도구 목록 1.95MB. 누군가는 그 컨텍스트를 읽고 비용을 내야 함
정적 경로는 대상을 실행하지 않음 JavaScript, .NET, APK, 네이티브 정적 분석은 바이트를 읽음 정적 결과로는 런타임 동작을 증명할 수 없음(2편)
provider 세션을 대신 관리해 줌 REA가 provider 세션을 시작하고 추적하고 닫음 OS 샌드박스가 아니고, 런타임 경로는 실제 권한으로 움직임(보안 경계)
큰 외부 도구를 몰래 설치하지 않음 provider는 운영자가 고름(외부 도구) Ghidra, JADX, Frida 등을 직접 설치하고 라이선스를 갖추고 관리해야 함
빠른 개선과 넓은 범위 잦은 릴리스 호환되지 않는 스키마 변경과 npm 릴리스·main 사이의 차이가 재현과 이전 비용을 키움(릴리스와 main)

몇 가지는 조금 더 설명할 만합니다.

진짜 제품은 Evidence 계약입니다. 디컴파일러를 돌려 주는 도구는 많습니다. REA가 더하는 것은 Electron 번들을 물었든 펌웨어 이미지를 물었든 같은 형태로, 어디까지 봤고 무엇을 확인하지 못했는지 말해 주는 결과입니다. HackerNoon 실행이 그 의미를 보여 줍니다. 자원 한도 때문에 365개 파일의 관계가 빠졌는데, 결과는 조용히 작아진 그래프를 돌려주는 대신 그렇다고 밝혔습니다. 이런 정직함은 누군가 읽을 때만 쓸모가 있고, 그게 대가입니다.

모든 것이 맞아도 크기는 비용입니다. 두 독립 실행 모두 출력이 컸다고 보고했습니다. HackerNoon 작성자는 MCP 도구 목록만 2MB에 가까웠고 간결 모드로도 9% 정도만 줄었다고 했습니다. 팀 입장에서는 첫 질문에 답하기도 전에 모델 컨텍스트, 돈, 검토 시간이 드는 셈입니다.

빠른 변화는 양날입니다. 6일 간격으로 게시된 두 독립 실행은 각각 6.0.0과 6.4.0을 썼습니다. 기능에는 좋은 일이지만, 앞선 결과를 다시 재현하려는 사람에게는 나쁜 일입니다.

누가 이득을 보고, 누구는 그렇지 않을까

위 사실에서 나온 우리의 해석입니다.

  • 이득을 볼 가능성이 큰 쪽: 이미 리버스 엔지니어링을 하고 있고 무엇을 확인했는지 일관된 기록을 원하는 사람, 기본 정적 경로만으로 충분한 자사 Electron이나 .NET 앱을 점검하는 팀, 자신 있는 추측보다 ’모름’을 더 귀하게 여기는 보안 검토자.
  • 이득이 적을 수 있는 쪽: 기초를 건너뛰고 싶은 입문자(Evidence를 판단하려면 도구 출력을 직접 읽을 때와 같은 지식이 필요합니다), 대상에 필요한 상용 provider가 없는 사람, 큰 결과를 검토할 시간이 없는 사람.
  • 도움이 되지 않는 쪽: 클라이언트에 없는 것을 되찾으려는 사람. 서버 로직, 데이터, 계정, 에셋은 바이너리에 없습니다. 1편에서 정리한 Hacker News 스레드가 이 점을 잘 짚었습니다.

앞으로 12~24개월의 다섯 가지 시나리오

어느 것도 예측이 아닙니다. 지금의 근거로 보아 그럴 법한 방향 하나와, 그만큼 그럴 법한 반대 시나리오, 그리고 어느 쪽으로 가는지 알려 줄 신호를 짝지었습니다. REA와 그 주변 생태계에 관한 이야기이지 프로젝트의 약속이 아닙니다.

1. MCP 서버가 클라이언트를 가리지 않게 되거나, 허용 목록 안에 갇히거나

만약: MCP가 여러 에이전트 클라이언트로 계속 퍼지고, REA 같은 서버가 어디서나 같은 방식으로 동작하게 된다면. 이미 그런 신호가 있습니다. Anthropic은 MCP를 새로 세운 Agentic AI Foundation에 기증했고, 공식 MCP Registry가 (미리 보기 단계로) 있으며, OpenAI Agents SDK 같은 다른 SDK도 MCP 서버를 지원합니다.

반대 시나리오: 공개 레지스트리에서 비슷한 이름의 가짜 서버, 약한 출처 확인, 느린 관리 같은 사고가 나면 조직들은 내부 허용 목록과 공급사가 승인한 커넥터로 돌아서고, 이식성보다 누가 서버를 검증했는지가 더 중요해집니다.

지켜볼 것: 레지스트리가 출처 확인이나 서명을 갖추고 미리 보기를 벗어나는지, 기업들이 내부 MCP 허용 목록을 공개하는지, REA의 설치 문서가 패키지를 검증하는 방법을 바꾸는지.

2. 계층을 잇는 근거 그래프가 중요해지거나, 전문가가 계속 중심에 남거나

만약: REA의 로드맵이 밝힌 우선순위, 곧 정적 분석 결과와 런타임 관찰을 여러 계층에 걸쳐 잇는 일이 실제로 들어오고, 그것이 REA를 쓰는 주된 이유가 된다면.

반대 시나리오: provider마다 다른 모델링 방식, 안티 디버깅, 난독화, 서버에 있는 로직 때문에 어려운 사례는 계속 사람이 직접 하고, REA는 쉬운 사례를 위한 편의 도구에 머뭅니다.

지켜볼 것: 계층 연결 항목이 실제로 릴리스 노트에 실리는지, 그리고 JavaScript가 아닌 대상에 대한 독립 실행이 나오는지. 우리가 찾은 범위에서는 아직 공개된 것이 없습니다.

3. 확인 가능한 근거가 매끄러운 답을 이기거나, 검토가 절약을 다 먹어 버리거나

만약: 팀들이 에이전트 도구를 ’주장마다 근거를 가리키는가’로 평가하기 시작하고, REA의 계약이 다른 도구들이 본뜨는 모델이 된다면.

반대 시나리오: 검토해야 할 근거의 양에, 틀리거나 지어낸 참조를 인용하는 모델 답변까지 더해져 아낀 시간이 상쇄됩니다. 맞긴 하지만 손으로 하는 것보다 확인하는 데 더 오래 걸리는 도구는 집니다.

지켜볼 것: 후기들이 실행 시간만이 아니라 검토 시간을 보고하기 시작하는지, REA의 출력 크기와 도구 목록 크기가 릴리스를 거듭하며 줄어드는지.

4. 로컬 격리와 승인이 병목이 되거나, 번거로움이 우회를 부르거나

만약: REA 도입에서 정말 어려운 부분이 안전하게 돌리는 일, 곧 로컬 MCP 서버를 격리하고, 도구를 걸러 내고, 위험한 호출마다 승인하는 일로 드러난다면. 공식 MCP 보안 모범 사례와, OpenAI Agents SDK의 승인·도구 필터링·가드레일·추적 같은 클라이언트 기능을 보면 생태계는 이를 실제 과제로 다루고 있습니다.

반대 시나리오: 호출마다 클릭이 필요하고 환경마다 검토가 필요하면, 사람들은 에이전트를 건너뛰고 같은 도구를 셸 스크립트로 직접 돌립니다. 그러면 통제도 Evidence도 함께 잃습니다.

지켜볼 것: 클라이언트가 호출별 승인과 필터링을 기본으로 갖추는지, REA의 주석(destructive, mutatesDevice 등)이 힌트에 머물지 않고 널리 쓰이는 호스트에서 강제되는지.

5. 에이전트가 더 많은 오픈 도구와 이어지되, 전문가와 상용 도구는 남거나

만약: 더 많은 에이전트 연결 도구가 Ghidra나 Frida 같은 오픈 도구와 이어지고, 일상적인 질문은 에이전트로 넘어간다면.

반대 시나리오: 라이선스 조건, 플랫폼 보안 정책의 변화, 계속 바뀌는 provider API 때문에 연동의 투자 대비 효과가 너무 낮아서, 중요한 작업에서는 비싼 전문가와 상용 도구가 계속 기본값으로 남습니다.

지켜볼 것: REA 릴리스 노트에 provider 연동이 깨져서 고친 항목이 얼마나 자주 나오는지, 상용 도구 회사들이 이용 약관에서 에이전트 사용을 다루거나 제한하는지.

이 그림을 바꿀 것

가장 큰 빈칸은 근거입니다. 공개된 독립 실행은 두 편이고 둘 다 JavaScript였습니다. .NET, Android, 네이티브 대상에 대해 Evidence를 남기고 검토 시간까지 보고한 신중한 실행 몇 편이, 이 글을 포함한 어떤 논평보다 다섯 시나리오 모두에 관해 더 많은 것을 말해 줄 것입니다.

4편에서는 이것을 실제 시작으로 옮깁니다. 알아 둘 것, 위험이 낮은 첫 연습, 팀이 시범 도입하는 방법입니다.

참고 자료

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

블로그로