MS가 2007년에 죽인 FoxPro, 64비트 런타임 'FoxDev Studio'로 부활
- FoxDev Studio가 Visual FoxPro 9 프로젝트, 폼, 클래스 라이브러리, .dbf 테이블을 변환·마이그레이션 없이 그대로 열어 실행함
- 런타임을 처음부터 다시 작성해 VFP 9 언어 레퍼런스 요소 1,722개 중 1,534개를 실제 VFP와 산출물을 대조하는 테스트로 검증, 미구현은 3개뿐임
- 코드를 바이트코드로 컴파일해 WebAssembly 가상머신에서 돌리고 파일·테이블·COM·64비트 라이브러리는 호스트가 맡으며, 32비트 .fll은 fllhost.exe 별도 프로세스에서 호출함
- 전체 64비트로 재구축해 테이블 상한 2,147,483,647 바이트(2GB)를 넘어 수백 GB까지 확장했으나 2GB를 넘긴 테이블은 다시 VFP에서 열 수 없음
- 폼은 객체 트리에서 직접 그리는 React로 렌더링하고, 에디터 린터는 런타임 자체 컴파일러로 동작해 밑줄 친 곳이 실제 컴파일 오류와 일치함
Hacker News opinions
아버지가 FoxPro로 프로젝트 여러 개 만드셨는데 이번에 아주 기뻐하실 듯. 근데 플로피 디스크 드라이브를 새로 사서 옛날 박스를 뒤져야 할 거임.
플로피는 이미 데이터가 날아갔을 가능성이 큼. 살아있으면 바로 복사하고, 디스크가 부서지면서 드라이브 헤드도 오염시키니까 청소까지 해야 함.
어릴 때(~10살) Visual FoxPro 좋아해서 즐겨찾는 사이트와 파일 여는 작은 UI들을 만들어봤었음.
FoxPro랑 Erlang, F#, ColdFusion으로 다 돈 받은 사람 나뿐일 듯. DOS판 FoxPro로 태권도장 청구 시스템 만졌는데 손댈 때마다 짜증났음. VFP가 좀 덜 구리면 좋겠음.
나도 태권도장에서 비슷한 일 했는데, 네가 맞는 이유는 내가 Erlang은 안 만져봤기 때문임.
80년대 말 대학 도서관에서 dBase III, Foxbase, DOS FoxPro 순으로 DB랑 인터페이스 다뤘는데 꽤 좋았음. 근데 내 상사가 도서관 IT인 동시에 태권도 사범이었음. FoxPro와 태권도는 무슨 인연이길래?
진입 장벽 낮고 생산성 좋은 건 좋은데, DBF 파일을 각종 overlay VPN으로 엮은 네트워크 드라이브에서 열면 반드시 무너짐. 원격 접속이 VFP 앱이 제일 못 버티는 상황이고, 클라이언트/서버 DB를 투명하게 끼워 넣을 수 있으면 좋겠음.
그렇게 플랫폼 한계에 걸린 건 맞는데, 지금은 AI 도구가 있으니 90년대만큼 끔찍하진 않을 거라고 봄. 그때는 진짜 고통스러웠지.
지금도 이런 식으로 도는 회사가 수두룩함. VFP랑 Citrix 조합으로 뭘 하는지 보면 놀라든지 혐오하게 될 걸.
요즘엔 런타임을 어정쩡하게 재현하는 것보다 비즈니스 앱을 다시 쓰는 게 더 빠를 듯. 이러면 고객 문제가 하나에서 둘로 늘어남.
그래서 청구를 두 번 할 수 있는 거임. 고객이 원하는 대로 한 번, 실수한 걸 깨닫고 제대로 다시 한 번.
바이브코딩 프로젝트는 진지하게 못 받아들이겠음. 랜딩 페이지 카피에서 LLM이 팔고 있는 느낌이 남. 코드가 나쁘다는 게 아니라 AI가 만든 랜딩 자체가 냄새가 남.
바이브코딩 사이트는 항상 실제보다 훨씬 오래되고 규모 있는 프로젝트인 척함. 지금은 투박한 사이트나 손으로 쓴 README.md가 오히려 신뢰할 수 있는 신호임.
AI 생성 문장 리듬이 확 띄어서 매끈한 디자인과 글이 따로 노는 느낌이었음. 나이틀리가 main 커밋마다 다시 비드해 GitHub 프리릴리스로 올린다고 하는데 커밋이 한 시간에 두 개뿐이라 릴리스 자동화라기보단 계획서처럼 읽혔음. 실패 모드를 알려면 알파·베타 이력이 신호인데.
미안함. 아는 분 가게가 아주 오래된 VFP 프로젝트를 마이그레이션하기 싫다고 해서 만든 거라 사이트는 Claude로 급하게 뽑았음. 주말에 사람 손 좀 태울 예정.
오래된 파일 포맷 상대해 본 입장에서 레거시 OS에 묶이지 않은 새 도구가 나온 건 반가움. 근데 애플이 죽인 FileMaker는 누가 오픈소스로 살려쥼?
애플이 아직 FileMaker 팔고 있음. Claris에서 나옴.
전 회사가 최근까지 VFP로 ETL 돌렸는데, 데이터 옮기는 속도는 진짜 기가 막혔음.
64비트 런타임이 왜 필요한 거고, 런타임 통째로 다시 쓰는 게 앱 자체를 다시 쓰는 것보다 위험하지 않나? 그건 똑같이 위험해 보이는데.
테이블 2GB 상한 때문이고, 소스 코드를 한 줄도 안 고치고 가려고 그렇게 한 거임.
Access는 아직도 멀쩡히 살아 있고, 32비트판이 3년 전에 Large Address Aware가 됨. 내 첫 직장이 Access VBA 몇 주짜리였는데 아마 아직도 그 코드가 돌아가는 중일 듯. Access에서 갈아탈 만한 싼 대안이 없으니까.
Access 진짜 좋지. 리눅스와 맥에 이에 상응하는 범용 도구가 없다는 게 의외임. 스프레드시트로 때운 적이 한두 번이 아님.
FoxPro가 뭔데? 어린 세대를 위해 설명 좀.
IDE, 폼 디자이너, 언어, 런타임, 데이터베이스 엔진이 한 묶음인 비즈니스 앱 개발 도구임. Access나 비주얼 베이직 같은 포지션이고, dBase II/III 경쟁작인 FoxBase로 시작해 마이크로소프트가 인수함.