프린세스 메이커 2를 아이패드로 옮긴 REA와 코덱스

REA는 완성된 프로그램을 개발의 자료로 만든다

REA는 Reverse Engineer Anything의 약자다. AI 에이전트가 실행 파일과 앱의 구조를 살펴볼 수 있도록 역분석 도구를 연결한다. 네이티브 프로그램에서는 Ghidra나 Hopper 같은 분석 도구로 함수와 호출 관계를 조사하고, JavaScript나 Electron 앱에서는 모듈과 데이터가 오가는 경로를 확인한다. 조사한 결과를 근거와 함께 남겨 후속 구현에 활용하는 것이 기본 흐름이다. REA 공식 저장소

역공학 자체는 오래전부터 존재했다. 달라진 것은 이를 활용하는 작업의 연결 방식이다. 사람이 분석 도구의 결과를 읽고 다른 개발 환경으로 옮겨 설명하던 과정에 AI 에이전트가 참여한다. 같은 작업 안에서 특정 기능을 추적하고, 설명을 만들고, 새 구현을 작성해 시험할 수 있게 된 것이다. 기존 도구와 공개 소스의 축적 위에 분석과 개발을 잇는 통로가 생겼다고 볼 수 있다.

프린세스 메이커 2 프로젝트에도 구체적인 조사 흔적이 남아 있다. 초기 기록에는 16비트 DOS 실행 파일을 Ghidra 기반으로 살펴본 결과와 함수 분석, 참조 관계 조사 등이 보관돼 있다. 이후에는 화면 리소스가 어떻게 선택되고 복사되는지 추적하는 자료가 더해졌다. 공개된 PC-98판 소스도 참고했지만, 이를 한국어 DOS판과 같은 프로그램으로 간주하지는 않았다. 실행 파일에서 확인한 동작과 참고 소스를 대조하는 과정이 필요했다.

이러한 분석은 변경 가능한 지점을 찾는 데 쓰였다. 게임의 어떤 상태에서 어떤 그림을 표시하는지 알아야 새 그림을 정확한 순간에 붙일 수 있기 때문이다. REA가 제공한 가치는 완성된 iOS 앱 자체가 아니라, 구현과 시험이 의지할 수 있는 원본 동작의 근거였다.

원본의 규칙을 유지하며 화면과 조작을 바꾸다

이번 앱은 원작의 모든 규칙을 새 코드로 다시 만든 방식은 아니다. DOSBox Pure가 원본 게임의 실행과 입력, 저장, 음성을 담당하고, C++와 SDL로 구성한 iOS 프런트엔드가 터치 조작과 새로운 화면을 연결했다. 원본 실행을 유지하면서 기기와 표현 방식을 바꾼 구조다.

이 선택은 개발의 목표를 분명하게 했다. 이미 작동하는 게임 규칙과 저장 구조를 활용하고, 사용자가 바꾸고 싶어 한 화면과 조작 경험에 작업을 집중했다. 오래된 프로그램을 새로운 기기에서 활용하는 길에는 완전한 재작성 외에도 이런 결합 방식이 있다. 분석 도구는 어느 부분을 보존하고 어느 부분을 바꿀지 판단하는 데 도움을 준다.

고화질 개선에는 이미지 생성 도구로 제작한 그림을 투명 PNG로 가공하고 원본 리소스와 대응시키는 방식이 쓰였다. 배경과 정보 패널은 일정하게 유지하면서 캐릭터는 나이와 교육, 일거리, 장소에 맞춰 바뀌어야 했다. 원본이 선택한 그림과 새 이미지의 대응이 어긋나면 한 화면은 좋아 보여도 다음 장면에서 분위기가 바뀌거나 움직임이 끊어진다. 사용자는 이 불일치를 지적했고, 작업은 장면별 연결을 다시 맞추는 방향으로 수정됐다.

변화는 이미지 파일의 수보다 같은 장면을 어떻게 보여 주는지에서 드러난다. 아래 비교에서는 원본 게임이 진행하는 집안일 장면을 그대로 두고 배경과 캐릭터, 정보 패널의 표현을 바꾼 모습을 볼 수 있다. 작은 장비·상태 아이콘 등에는 원본 표현이 남아 있으며, 모든 장면을 새 그림으로 교체했다는 뜻은 아니다.

코덱스의 작업은 설치 파일에서 끝나지 않았다

이 프로젝트에서 주목할 대목은 작업의 끝점이다. 코덱스는 분석 결과를 설명하는 데서 멈추지 않고 아트워크 제작과 가공, 장면 연결, 코드 수정, 테스트, iOS 빌드와 서명, 아이패드 설치까지 이어 갔다. 기존의 분석 도구와 이미지 생성 도구, 컴파일러와 기기 관리 도구를 한 작업 흐름에서 사용했다. 사용자에게 전달된 결과도 코드 조각이 아니라 실제 기기에서 다시 실행할 수 있는 앱이었다.

설치 과정에서는 이전 저장 데이터를 백업하고, 업데이트 전후에 게임·런타임 파일 67개의 해시가 같은지 비교했다. 최종 보고서는 데스크톱 실행 흐름 검사 54개와 iOS 시뮬레이터 검사 9개의 통과를 기록한다. 실제 아이패드에서는 앱의 실행과 저장 게임 재개, 새 홈 화면 표시를 확인했다. 이는 해당 버전과 시험 항목의 결과이며, 모든 분기와 모든 기기에서의 완전한 검증을 뜻하지는 않는다.

과정은 여러 차례의 수정과 검사를 거쳤다. 그림의 일관성 문제를 다시 다뤘고, 저장 공간 부족으로 중단된 검사도 재개했다. 사람은 목표와 원하는 미감을 제시하고 결과를 판단했다. 기기 연결과 접근 조건도 필요했다. 코덱스가 전 과정을 수행했다는 말은 이러한 조건 아래에서 분석부터 설치까지 기술적 실행을 이어 갔다는 뜻이다. 사람의 판단과 기존 소프트웨어의 기여까지 사라졌다는 의미로 넓힐 필요는 없다.

이 구분은 오히려 변화의 크기를 구체적으로 보여준다. 사용자는 모든 기술을 직접 익혀 각 단계의 작업자가 되는 대신, 원하는 결과와 받아들일 수 없는 오류를 설명하는 역할에 더 집중할 수 있었다. AI가 맡는 범위가 넓어질수록 사람의 요구를 시험 가능한 조건으로 바꾸는 능력이 중요해진다.

Adobe와 Office 유사 앱이 보여주는 변화

공개 개발 커뮤니티에서도 기존 제품의 기능을 새로운 프로그램으로 구현하는 시도가 이어지고 있다. 대표적인 사례가 Brandon Thomas의 ArtCraft 계열 프로젝트다. Thomas는 10월 2일 Hacker News에 올린 글에서 Claude Opus 5.5를 활용해 Adobe 유사 앱들을 Rust로 만들고 있다고 설명했다. PhotoCraft의 사진 편집, VectorCraft의 벡터 편집, FilmCraft의 영상 편집에 이어 WordCraft·GridCraft·DeckCraft에서는 문서와 표, 발표 자료로 범위를 넓혔다. 제작자의 Hacker News 글 · VectorCraft · FilmCraft

이 사례들을 REA가 Adobe와 Microsoft 제품을 직접 복제한 결과로 연결할 근거는 확인되지 않았다. ArtCraft의 공개 구현과 REA의 역분석 도구는 구분해서 보아야 한다. 그럼에도 두 흐름은 같은 질문을 제기한다. 사용자에게 익숙한 기능을 특정 기업의 제품에서만 이용해야 하는가, 아니면 필요한 작업을 다른 구현으로 다시 구성할 수 있는가 하는 질문이다.

비슷한 기능을 갖춘 앱이 생겼다는 사실과 기존 제품을 전문 업무에서 그대로 대체할 수 있다는 평가는 다른 시험을 요구한다. 10월 24일 ArtCraft 공식 앱 목록은 PhotoCraft를 초기 알파로, WordCraft·GridCraft·DeckCraft 등을 개발 중으로 표시한다. 사진 편집에서는 복잡한 파일을 다시 저장했을 때의 표현, 문서에서는 페이지 나눔, 스프레드시트에서는 계산과 서식의 보존이 실제 사용을 좌우한다. 메뉴의 개수만으로 이 문제들이 해결되지는 않는다.

그렇다고 이러한 시도의 의미가 사라지는 것은 아니다. 필요한 기능을 직접 구현하고 공개 저장소에서 고치고 확장할 수 있는 결과물이 등장했다. 완성도를 평가할 때는 냉정해야 하지만, 개발을 시작할 수 있는 주체와 범위가 넓어지고 있다는 변화 역시 함께 보아야 한다.

커뮤니티 사례가 제시하는 검증의 단위

REA의 공식 사례는 검증 대상을 더 작은 단위로 제시한다. DX-Ball 사례는 소리의 좌우 위치를 계산하는 함수를 복원해 원본 x86 실행 결과와 비교한다. 해당 함수에서는 3,205개 경우의 결과와 재컴파일한 63바이트의 일치를 보고했다. Notion 사례는 Electron 앱의 클립보드 처리가 화면 쪽 코드에서 프로세스 간 통신을 거쳐 어떻게 전달되는지 추적한다. TH04 사례는 DOS 게임의 탄환 각도 계산을 조사한다. 앱 전체를 재현했다는 선언보다 어떤 동작을 어디까지 설명하고 확인했는지가 앞선다. DX-Ball · Notion · TH04

개인 사용자의 경험에서도 비슷한 연결을 볼 수 있다. Kintu는 10월 9일 공개한 글에서 코덱스와 REA로 Sony의 Sound Connect 앱을 조사하고, XM4 헤드폰의 바람 소리 감소 기능을 조작하는 Android 앱을 만들어 설치했다고 보고했다. 분석이 막힌 부분은 기존 공개 프로토콜 자료로 보완했고 여러 차례 수정했다. 개발자의 자기 보고라는 한계는 있지만, 기존 앱에서 필요한 기능을 찾아 별도 도구로 옮겼다는 점에서 이번 아이패드 사례와 맞닿는다. Sony XM4 실험 기록

실패 범위가 드러나는 사례도 있다. Connor Turland는 10월 20일 Slack의 알림 처리를 조사해 macOS 방해금지 상태를 읽는 경로를 찾았지만, 서버에서 내려오는 클라이언트 쪽의 최종 표시 동작까지 설명하지는 못했다. 분석 대상에 들어 있지 않은 코드와 서비스의 동작은 추가 근거가 필요했다. 역분석의 결과가 풍부해져도 관찰 가능한 범위가 곧 제품 전체가 되는 것은 아니다. Slack 조사 기록

이런 검증 방식은 재구현의 신뢰를 쌓는 데 유용하다. 동작 하나를 설명하고 시험할 수 있으면 그 결과를 다음 기능의 기반으로 사용할 수 있다. 반대로 화면이 비슷하다는 이유만으로 내부 처리까지 같다고 가정하면, 실제 문서와 데이터가 들어왔을 때 문제가 드러날 수 있다.

프린세스 메이커 2의 장면 대응도 같은 문제를 보여준다. 새 캐릭터를 잘 그리는 일과 원본 게임이 선택한 동작을 정확히 표시하는 일은 함께 해결해야 했다. 앞으로 AI 개발의 성숙도를 가늠할 때는 생성한 코드의 양과 기능 목록뿐 아니라, 원본과 새 구현을 비교하는 시험이 얼마나 구체적인지 살필 필요가 있다.

개발사의 경쟁력은 구현 이후의 품질로 넓어진다

이러한 사례들에서 필자가 읽는 변화는 개발의 진입점이다. 요구사항을 듣고 빈 화면에서 프로그램을 만드는 방식에 더해, 이미 존재하는 프로그램을 관찰하고 필요한 부분을 다른 환경에 맞게 재구성하는 방식이 개인의 선택지에 들어왔다. REA는 분석을 연결하고, 코덱스 같은 에이전트는 그 결과를 구현과 실행으로 이어 간다.

개발사에는 익숙한 기능을 제공하는 것만으로 충분한지 묻는 압력이 생길 수 있다. 이용자가 자신의 작업에 맞는 대안을 만들기 쉬워진다면, 구매를 결정하는 이유는 파일 호환성, 협업, 접근성, 업데이트의 안정성, 장애 대응처럼 사용이 계속될수록 드러나는 품질로 넓어진다. 이는 대형 소프트웨어가 곧 사라진다는 예측이 아니라, 기능 목록의 독점만으로 설명하기 어려운 경쟁이 커질 수 있다는 판단이다.

동시에 기존 개발사는 유리한 자산을 갖고 있다. 다양한 파일과 예외 상황을 처리해 온 경험, 플러그인과 협업 체계, 장기간의 유지보수는 짧은 시연에서 대체하기 어렵다. AI를 활용한 새로운 앱도 사용자 파일을 안전하게 열고 저장하며, 수정 후에도 이전 기능이 유지되는지 증명해야 한다. 개발 속도가 빨라져도 이 책임은 남는다.

사용자에게는 더 작은 범위의 맞춤 개발이 현실적인 변화가 될 수 있다. 사진 편집기 전체를 새로 만들기보다 반복하는 편집 절차를 묶고, 거대한 업무 시스템을 교체하기보다 필요한 파일을 읽는 보조 도구를 만들며, 오래된 프로그램의 규칙을 유지한 채 새로운 화면과 입력 장치를 붙이는 방식이다. 프린세스 메이커 2의 아이패드 앱은 이 마지막 방향을 보여준다.

앞으로는 사람이 쓰기 쉽고 에이전트도 다루기 쉬운 앱이 필요하다

개발 방향의 변화는 새로 만드는 앱의 설계에서도 나타난다. WordCraft·GridCraft·DeckCraft는 명령줄 도구와 MCP 인터페이스를 공개한다. AI 에이전트가 화면의 버튼만 찾아 누르는 데 의존하지 않고 문서 구조, 셀과 수식, 슬라이드 작업을 명령으로 다루도록 구성한 것이다. 사람에게 편한 화면과 에이전트가 정확히 읽고 조작할 수 있는 구조가 함께 필요해지는 흐름이다. WordCraft · GridCraft · DeckCraft

여기에 검증 가능한 출력과 되돌릴 수 있는 변경이 더해져야 한다. 어떤 파일을 바꿨는지, 저장 전후에 무엇이 달라졌는지, 업데이트 뒤에도 이전 작업을 이어갈 수 있는지를 앱과 에이전트가 함께 설명할 수 있어야 한다. 이번 아이패드 업데이트에서 저장 데이터 보존을 검사한 이유도 같다. 사용자는 새 기능뿐 아니라 자신이 쌓아 온 결과의 연속성을 원한다.

분석에 사용할 수 있는 자료와 다른 사람에게 배포할 수 있는 자료도 따로 관리해야 한다. 이 개인 제작 사례가 원작 게임 파일이나 제3자의 이미지·코드를 자유롭게 배포할 수 있음을 뜻하지는 않는다. 공개 명세, 직접 만든 코드와 아트워크, 기존 프로그램에서 가져온 자산의 출처를 구분하는 일은 지속 가능한 개발의 일부다.

REA가 소프트웨어 개발의 역사에서 전환점이 될 가능성은 이러한 변화에 있다. 완성된 제품의 동작을 배울 수 있는 근거로 만들고, 그 근거를 개인의 구현으로 이어 주기 때문이다. 아이패드 미니에서 다시 실행된 프린세스 메이커 2는 그 가능성이 분석 화면 밖으로 나와 기기에 도착한 한 사례다. 앞으로 개발의 가치는 얼마나 빨리 만들었는지와 함께, 사용자가 원하는 환경에서 얼마나 정확하고 오래 작동하게 했는지로 평가될 것이다.