Microsoft가 2007년에 종료한 FoxPro, 새 런타임으로 되살리다

AI 요약

FoxDev Studio와 FoxScript는 Visual FoxPro 9 프로젝트를 다시 작성하거나 파일을 변환하지 않고 실행하는 개발 환경입니다. 프로젝트, 폼, 클래스 라이브러리, 메뉴, 보고서를 기존 파일에서 열고 편집하며 테이블과 인덱스도 원래 형식으로 읽고 씁니다. 제작자는 Visual FoxPro의 실제 동작과 결과를 맞춰 호환성을 구현했다고 설명합니다. 폼과 테이블을 비롯한 샘플 프로젝트도 IDE에서 실행한 실제 화면으로 소개합니다.

기존 애플리케이션을 그대로 실행하는 새 런타임

Visual FoxPro는 32비트 프로그램이라 DBF 테이블과 메모 파일 크기가 각각 2GB로 제한됩니다. 큰 보고서를 처리할 때도 주소 공간 한계에 부딪힙니다. FoxDev Studio는 파일 오프셋을 64비트로 처리하고 테이블 전체를 메모리에 올리지 않아 수백 GB 규모 파일까지 다루는 것을 목표로 합니다. 다만 2GB를 넘긴 테이블은 Visual FoxPro에서 다시 열 수 없습니다. 기존 환경과 파일을 주고받아야 한다면 되돌릴 수 없는 변경이 될 수 있어 제작자도 별도 테스트를 권합니다.

실행 구조는 과거 FoxPro처럼 컴파일러와 바이트코드 인터프리터를 사용합니다. 새 컴파일러와 인터프리터는 Rust로 작성해 WebAssembly로 컴파일합니다. 편집기에서도 같은 컴파일러를 호출하므로 편집기 오류 표시와 실제 실행 오류가 달라지지 않도록 했다는 설명입니다. 프로그램은 파이버(fiber) 단위로 실행하며 메시지 상자, 모달 폼, 레코드 조회처럼 외부 작업이 필요한 순간 실행을 양보합니다. 이 방식으로 대화 상자를 띄워도 창이 멈추지 않고, READ EVENTS 대기와 폼 초기화 이벤트 순서도 기존 FoxPro 동작에 맞춥니다.

폼은 객체 트리로 표현하고 React가 화면을 그립니다. 객체마다 변경 사항을 살피므로 레이블 하나의 문구를 바꾸면 해당 레이블만 다시 그립니다. 폼 디자이너도 같은 객체 트리를 편집해 실행 화면과 설계 화면이 서로 다른 상태를 갖지 않도록 구성했습니다.

32비트 확장 라이브러리인 .fll은 64비트 프로세스에서 직접 불러올 수 없습니다. FoxScript는 SET LIBRARY TO 명령을 만나면 별도의 32비트 프로세스를 띄워 라이브러리를 보관하고, 런타임과 동기식으로 통신합니다. 암호화 라이브러리와 FoxTools, Microsoft API 예제 기반 라이브러리로 동작을 확인한다고 밝힙니다. 64비트 DLL은 DECLARE ... DLL로 현재 프로세스에서 호출하며 자동화 객체도 기존 방식대로 사용합니다.

HTTP 서버 기능과 적용 범위

FoxScript는 기존 문법 위에 람다 블록과 HTTP 서버 API를 추가합니다. 본문 예제에서는 FoxPro 코드로 고객 테이블을 조회하고, 결과에 따라 JSON 응답을 보내는 서버를 8080 포트에서 실행합니다. 폼에서 사용하는 런타임과 같은 환경에서 쿼리, 커서, 라이브러리 호출을 수행한다는 구상입니다. 제작자는 WebAssembly 모듈 하나를 Electron IDE, 배포 앱, jsdom 기반 테스트에서 함께 쓰며 플랫폼별 네이티브 빌드가 필요 없다고 설명합니다. WebAssembly 경계에서 호스트 호출이 실행 스택에 재진입하지 못하는 점도 외부 작업 때 실행을 양보하는 설계에 영향을 줬다고 덧붙입니다. 성능보다 파일 입출력과 UI가 주요 병목이며, 필요하면 Rust 코드의 네이티브 빌드도 가능하다고 답합니다.

데이터와 보안에 남는 과제

토론에서는 재구현과 기존 앱 재작성 가운데 어느 쪽이 더 안전한지도 쟁점이 됐습니다. FoxPro 애플리케이션은 DBF뿐 아니라 폼, 보고서, 디버거, 사용자 업무 절차가 한데 얽혀 있어 언어만 바꾸는 일이 간단하지 않다는 의견이 나왔습니다. 반면 네트워크 공유 폴더에서 파일 기반 데이터베이스를 여러 사용자가 다루면 잠금과 동시 수정 문제가 생기며, 클라이언트·서버 데이터베이스로 옮기는 편이 낫다는 경험담도 있었습니다.

한 전직 FoxPro 개발자는 DBC에 저장된 프로시저가 일반 텍스트이며, 파일에 쓰기 권한이 있는 사용자가 내용을 바꾸면 FoxPro 코드가 실행될 수 있다고 경고했습니다. 제작자는 FoxDev Studio도 현재 Visual FoxPro와 같은 방식으로 DBC를 읽으므로 이 위험을 그대로 물려받는다고 인정했습니다. 빌드 실행 파일에 프로시저 해시를 넣어 내용이 일치하지 않는 컨테이너의 실행을 거부하는 방안을 검토하겠다고 답했습니다. 다만 토론에서는 파일에 접근할 수 있는 권한 자체가 설계된 구조라면 이를 보안 취약점보다 아키텍처의 한계로 봐야 한다는 반론도 나왔습니다.

프로젝트는 GitHub에서 MIT 라이선스로 공개됐다고 제작자가 밝혔고, Windows에서 FLL 브리지를 빌드하려면 Visual Studio C++ 도구가 필요합니다. 그러나 초기 공개와 AI 보조 개발을 두고 코드의 실패 조건을 충분히 검증했는지 의심하는 댓글도 많았습니다. 특히 실제 업무 데이터에 적용하기 전 소스 감사와 테스트가 필요하다는 의견, 기존 FoxPro 시스템을 운영하는 기업이 여전히 많아 이런 도구를 환영한다는 의견이 함께 나왔습니다.

Hacker News 반응

• @ndiddy — 고객이 64비트 FoxPro를 필요로 한 이유는 무엇인가요? 런타임 전체를 다시 만드는 일을 앱 자체를 다시 쓰는 것보다 왜 더 신뢰하나요? 위험도 비슷해 보입니다.
  • @boredjohnny — 더 큰 테이블이 필요했습니다. 기존 코드 변경도 원하지 않았습니다.
• @Pannoniae — 데스크톱용이라면 WebAssembly를 쓴 이유가 무엇인가요? 성능 저하 말고 얻는 이점이 있나요?
  • @boredjohnny — 같은 모듈을 Electron IDE, 배포 앱, jsdom 테스트에서 실행하며 플랫폼별 네이티브 빌드가 필요 없습니다. WebAssembly에서는 내보낸 함수가 재진입할 수 없어서 부수 효과를 호스트에 양보하는 구조가 됐고, 대화 상자가 떠도 창을 멈추지 않게 합니다. 이런 앱의 병목은 성능보다 입출력과 UI입니다.
• @mikestew — DBC가 제대로 작동하려면 모든 사용자가 읽고 쓸 수 있어야 합니다. DBC에는 FoxPro 코드가 들어간 저장 프로시저가 있고, 파일 시스템에서 내용을 직접 바꿀 수 있습니다. SQL 데이터베이스로 옮기는 편을 권합니다.
  • @boredjohnny — 유용한 지적입니다. FoxDev도 현재 VFP와 같은 방식으로 DBC를 읽으므로 이 문제를 그대로 물려받습니다. 실행 파일에 저장 프로시저 해시를 넣고 내용이 맞지 않는 컨테이너를 거부하는 방안을 추가하겠습니다.
• @userbinator — 이미 설계상 전체 접근 권한이 있다면, 그 자체를 거대한 보안 구멍이라고 부를 수는 없습니다.
  • @EvanAnderson — 맞습니다. 프로그램의 아키텍처 문제입니다. 데이터베이스 엔진이 UI와 같은 보안 맥락에서 실행되는데 권한을 덧붙이려 하면 본질을 놓칩니다.
• @smackeyacky — 불완전하게 런타임을 재현하기보다 요즘은 업무 앱을 다시 만드는 편이 쉬워 보입니다. 고객에게 문제가 하나가 아니라 둘 생길 수 있습니다.
• @EvanAnderson — 이런 시스템은 개발 장벽이 낮고 생산성이 높아 업무 절차에 딱 맞는 앱을 만들기 좋습니다. 하지만 기반 플랫폼의 한계를 넘어가면 문제가 됩니다. 오늘날 흔한 여러 가상 네트워크 위에서 DBF 파일을 네트워크 드라이브로 공유하는 방식은 걱정스럽습니다.
• @rufugee — 우리 회사는 FoxPro 50만 줄을 매일 운영하며 5억 달러 규모 사업을 떠받칩니다. AI를 이용한 재작성 외에는 좋은 답이 없고 DBF 의존성도 있습니다. FoxScript 같은 시도를 환영합니다. 이 분야에서 고전하는 분이 있다면 댓글을 남겨 주세요.
• @whalesalad — 이런 바이브 코딩 프로젝트를 진지하게 받아들이기 어렵습니다. 코드가 나쁘거나 기능이 없다고 말하려는 건 아니지만, AI가 쓴 랜딩 페이지 문구가 너무 티 납니다.
  • @boredjohnny — 미안합니다. 이건 아버지 친구의 오래된 VFP 프로젝트를 옮기고 싶지 않아 하는 가게를 위한 해결책이었습니다. 사이트는 Claude로 빠르게 만들었습니다. 다음 주말에 사람이 손을 좀 보겠습니다.
• @meerita — 아버지가 FoxPro 프로젝트를 몇 개 만들었습니다. 90년대에는 제가 너무 어려서 잘 기억하지 못하지만, 이걸 보면 정말 좋아하실 것 같습니다. 오래된 상자를 찾으려면 플로피 디스크 드라이브를 사야 할지도 모르겠습니다.
  • @outworlder — 플로피가 아직 작동하지 않을 가능성이 큽니다. 작동한다면 바로 데이터를 복사하세요. 디스크가 부서지면서 드라이브 헤드에 잔해가 묻어 헤드까지 청소해야 할 수 있습니다.

원문: foxscript.org / 번역·요약: Trawling