REA가 바꾸는 소프트웨어 개발의 출발점

사용자의 질문이 구현의 단위가 된다

REA는 바이너리·JavaScript·Electron 등의 분석 도구를 MCP와 명령줄로 연결한다. 에이전트는 함수, 참조, 코드 위치 같은 결과를 읽고 다음 조사나 구현으로 이어 간다. 공식 저장소가 설명하는 역할은 이 분석 연결에 있다. 프로그램 전체를 한 번에 원래 소스로 되돌리는 능력을 약속하는 것은 아니다.

이 구조에서 질문의 크기가 중요해진다. “이 앱을 똑같이 만들어 달라”보다 “이 파일을 저장할 때 어떤 값이 남고, 다시 열면 어떻게 복원되는가”가 확인할 대상을 만든다. 입력과 결과가 분명하면 사용자가 기대한 동작과 새 구현을 나란히 비교할 수 있다. 기능 요구가 추상적인 취향에서 시험할 수 있는 조건으로 바뀌는 것이다.

그동안 새 코드를 쓰는 능력과 낯선 프로그램을 읽는 능력은 별도로 요구됐다. 에이전트가 두 작업을 오갈 수 있다면, 작은 호환 기능이나 개인용 작업 도구를 시도하는 문턱은 낮아질 수 있다. 다만 이는 공개된 도구 구조에서 도출한 전망이며, 모든 프로젝트의 비용이 이미 줄었다는 측정 결과는 아니다.

작은 성공을 어떻게 증명했는가

REA의 DX-Ball 사례는 소리의 좌우 위치를 계산하는 한 함수를 C로 복원해 원본과 대조했다. 공식 기록에는 3,205개 입력 조건의 결과 비교와 재컴파일한 63바이트의 일치가 제시된다. 이 수치는 해당 함수의 근거이며 게임 전체의 완성도를 뜻하지 않는다.

Notion Desktop 7.6.1 사례는 복사 요청이 preload와 프로세스 간 통신을 거쳐 시스템 클립보드에 도달하는 경로를 연결한다. 근거는 배포 패키지의 코드와 추출 모듈 시험이다. 실제 데스크톱 세션 전체를 관찰한 결과나 Notion 서비스 전체를 복제한 사례로 소개되지 않는다.

Touhou 4 사례에서도 기여의 경계가 드러난다. REA는 DOS 실행 파일의 탄환 방향 계산을 조사했다. 유지되는 C++ 코드와 2,139바이트의 컴파일 일치 기록은 기존 복원 프로젝트가 제공했다. 이미 축적된 복원 작업에 새로운 분석 경로가 더해진 사례다.

세 사례의 공통점은 무엇을 알아냈는지뿐 아니라 무엇과 비교했는지를 공개한다는 데 있다. 필자는 이 점이 시연 화면의 화려함보다 오래 남을 성과라고 본다. 다른 사람이 같은 범위를 다시 시험할 수 있을 때, 한 번의 성공은 다음 작업이 의지할 수 있는 지식이 된다.

작은 기능을 되찾는 사람들

10월 9일 Kintu gk는 Sony 헤드폰의 바람 소음 감소 기능을 바로 켜는 Android 앱을 Codex와 REA로 만들었다고 기록했다. 분석이 막힌 부분에는 기존 공개 프로토콜 자료를 활용했고, 기기에서 설정을 읽어 되확인했다. 당사자의 사용 기록이며 이 글에서 별도로 재현한 시험은 아니다.

UPMI Lab의 프린세스 메이커 2 작업도 사용 목적에서 출발했다. 원본 게임 실행을 유지하면서 화면과 조작을 바꾸고 iPad mini에 설치한 과정은 별도 기고에 담았다. REA 분석 이후의 그림 제작·통합, 앱 수정, 빌드·서명·설치는 코덱스 워크 작업 공간에서 이어졌다. 이 자체 사례의 운영 주체는 UPMI Lab이다.

두 경험에서 사용자가 원한 것은 대기업 제품 전체의 대체가 아니었다. 자주 쓰는 동작을 쉽게 실행하거나 오래된 경험을 지금의 기기로 옮기는 일이었다. 이런 요구는 시장 규모가 작아 공식 제품의 우선순위에 오르지 못할 수 있다. 개인이 구현에 참여할 수 있다는 변화는 바로 이 작은 필요를 다룰 수 있는 주체가 늘어난다는 뜻이다.

개발이 빨라질수록 확인의 책임은 선명해진다

동작을 읽는 일과 제품을 책임지는 일 사이에는 여전히 거리가 있다. 저장 파일 하나가 열려도 다른 버전의 파일은 실패할 수 있고, 화면 한 장이 맞아도 입력 시점과 오류 복구는 어긋날 수 있다. 새 구현의 범위가 커질수록 성공 사례뿐 아니라 실패 조건을 남기는 작업이 필요하다.

필자는 검증 기록에 세 가지를 남기는 방식을 제안한다. 어떤 버전의 원본을 살폈는지, 어떤 입력과 결과를 비교했는지, 아직 시험하지 않은 영역이 무엇인지다. 서버에서 처리되는 동작을 로컬 패키지만으로 설명할 수 없다면 그 경계도 구현 계획에 포함해야 한다. 모르는 부분을 지운 설계는 다음 변경 때 비용으로 돌아온다.

분석이 로컬에서 이뤄진다는 말도 데이터의 이동을 모두 설명하지는 않는다. REA의 FAQ는 분석 결과를 받는 에이전트와 모델 제공자의 데이터 정책이 적용된다고 밝힌다. 조직에서 활용하려면 분석 대상과 결과에 어떤 정보가 담기는지 정해야 한다. 기능을 이해한 것과 원본 코드·그림을 배포할 근거를 확보한 것도 별개의 작업이다.

개발사가 팔아야 할 가치는 더 구체적이 된다

이 흐름을 소프트웨어 회사의 소멸로 곧장 연결하는 것은 성급하다. 사용자는 기능 목록과 함께 과거 파일의 호환성, 장애 대응, 협업 상대와의 연결을 산다. 비슷한 기능을 만드는 속도가 빨라져도 축적된 작업을 손상 없이 이어 주는 책임은 남는다.

반대로 특정 기능을 재현하기 어렵다는 사실만으로 오래 경쟁하기는 점차 힘들어질 수 있다. 필자가 예상하는 대응은 공개된 연결 규격, 안정적인 내보내기, 자동화 인터페이스와 검증 자료에 대한 투자다. 고객이 자신의 작업 흐름을 확장할 수 있을수록 제품을 계속 선택할 이유도 더 구체적으로 설명할 수 있다.

개발팀의 평가지표도 함께 바뀔 필요가 있다. 생성한 코드의 양보다 실제 파일과 기기에서 확인된 동작, 수정 후에도 유지된 호환성, 문제가 생겼을 때 복구하는 시간을 보는 편이 낫다. 이는 자동화가 커질수록 사람의 판단을 어디에 배치할지에 관한 제안이다.

다음 개발의 시작은 더 정확한 요구다

REA를 처음 적용한다면 자신이 사용할 수 있는 대상 하나와 불편한 동작 하나를 정하는 편이 현실적이다. 원본을 보존하고 작은 구현을 만든 뒤 같은 입력으로 비교한다. 결과가 맞지 않을 때 분석으로 돌아갈 수 있도록 근거와 시험 자료를 함께 남긴다. 이 순환은 도구가 바뀌어도 다음 개발자가 이어받을 수 있다.

필자는 REA의 영향력을 “얼마나 큰 프로그램을 복제했는가”만으로 평가하고 싶지 않다. 사용자가 발견한 문제를 조사 가능한 질문으로 바꾸고, 그 답을 실행 가능한 결과로 잇는 사람이 늘어나는 것이 더 큰 변화다. 소프트웨어 개발 역사의 다음 장은 코드를 더 빨리 쓰는 기술과, 그 코드가 원하는 일을 계속 한다고 설명할 수 있는 능력이 함께 만들 것이다.