읽는 방법. 이 문서는 설계 입력이지 시장 조사가 아니다.
- 아래 타사 제품에 대한 서술은 작성 시점(2026-08)의 우리 이해이며 출처를 검증하지 않았다. 제품은 바뀌고, 우리가 틀렸을 수 있다. 각 제품의 실제 능력은 그 제품의 문서를 봐야 한다.
- "Mathless가 이기려는 한 가지"는 의도다. 오늘 무엇이 실제로 되는지는
docs/STATUS.md와docs/LANGUAGE.md가 정본이며, 그쪽이 이 문서와 어긋나면 그쪽이 맞다.- 여기 있는 어떤 문장도 타사 제품을 깎아내리려는 것이 아니다. 우리가 무엇을 하지 않을지를 정하려고 적었다.
| 대상 | 배울 점 | 따라하지 않을 점 |
|---|---|---|
| RemObjects Pascal Script | 임베딩, Inno Setup 검증, 바이트코드 배포 | 기본이 인터프리터. 회사 주력은 미들웨어(Remoting SDK)와 별개 |
Inno Setup [Code] |
호스트 재빌드 없이 복잡한 설치 로직 | 설치 도구 특화, 웹/다중 호스트 아님 |
| DWScript / Lape | 현대 Object Pascal 스크립트 | 네이티브 배포·안티리버싱이 1목표가 아님 |
| AngelScript | C++-like 정적 타입 스크립트, 상용 게임 사용 | 대중 언어 아님. 웹은 실험적 |
| Lua | 임베딩의 왕, 작은 런타임 | 약한 타입, 보호 모델 다름 |
| Emscripten/Cheerp | 네이티브를 웹으로 | 스크립트 언어가 아니라 이식 툴체인 |
| AssemblyScript | 타입 + WASM | TS 계열, Delphi 탈출 서사와 다름 |
우리가 아는 범위에서, RemObjects의 주력 제품군은 Remoting SDK / Data Abstract 같은 미들웨어이고,
Pascal Script는 그와 별개인 오픈소스 스크립트 엔진이며 Inno Setup이 이를 사용한다.
이 둘을 같은 제품으로 묶어 보면 비교가 어긋난다 — 우리가 처음에 그렇게 착각했기 때문에 적어 둔다.
기존 Pascal Script 대비 노리는 것:
- 표면 문법이 더 보편적일 것 — 방향만 확정(D15), 세부 문법은 미정
- 산출물이 네이티브 모듈일 것 — 달성(
.dll산출·로드 실측) - 호스트가 Delphi만이 아닐 것 — 대체로 달성. CI가 매 푸시마다 강제하는 호스트 게이트는
둘이다: C(
MATHLESS_GATE_D)와 Object Pascal(MATHLESS_GATE_FPC_HOST— Free Pascal로 빌드한 호스트가 x64 모듈을 로드·호출한다). 플래그십인 Delphi 자신은 로컬 게이트까지다 (MATHLESS_GATE_DELPHI, 2026-09-09부터 반복 가능 — 에디션이 명령줄 컴파일러를 막아bds.exe -b로 IDE 빌드를 부른다). CI에서는 아직 아니다 — 러너에 Delphi도 대화형 세션도 없고,-Mdelphi는 방언 에뮬레이션이라 그것을 대신하지 못한다. 그 마지막 한 칸은 강점으로 쓰지 않는다 - 배포 보호가 설계 목표일 것 — 목표로 삼고 있고, 측정하는 것은 프록시뿐이다(export 개수·크기·소스 부재). "보호된다"는 결론으로 쓰지 않는다
Lua/AngelScript 대비 노리는 것:
- 더 강한 타입 — 정적 타입은 있다. 다만 표면은 아직 작다(
docs/LANGUAGE.md) - AI 친화 계약 파일 — ⏳ 존재하지 않는다. ROADMAP Phase 2의 계획이다
- Delphi 제품군과의 친연성 — 의미 모델 수준의 의도이고, 그것은 실측 대상이 아니다. C ABI 결합 쪽은 Delphi 호스트로 실측됐다(↑ 위 "호스트가 Delphi만이 아닐 것" 항목이 정본이다 — 로컬 게이트까지이고 CI에는 없다)
이 방향이 흔들리면 프로젝트 정체성이 흔들린다. 다만 방향과 현재 능력을 같은 문장에 섞지 않는다.