참고: 이 문서는 Topaz v5.2 정식 문법을 기준으로 합니다 — 동결된 v5.1의 엄격 상위집합입니다. 모듈은 v5.2의 신규 기능입니다: 모듈과 가시성 참고.
한 문장 답: Rust를 쓰고 싶다면 Rust를 쓰면 됩니다. Topaz는 애플리케이션 의도를 작고 읽기 쉬운 단 하나의 정식 형태로 쓰고 싶은 사람 — 그리고 에이전트 — 를 위한 언어입니다.
질문은 보통 잘못된 층에 놓여 있다
"왜 Rust가 아니라 Topaz냐"는 질문은 두 언어가 같은 층에 있다고 가정합니다. 아닙니다.
- Rust의 층: 할당자, async 런타임, 네트워크 스택, unsafe 경계, 고성능 자료구조 — 기계와 협상하는 층.
- Topaz의 층: CLI 워크플로우, 데이터 변환, 백엔드 글루, 설정 기반 로직, SQL/셸/경로 오케스트레이션 — 의도를 서술하는 층.
이 층에서 Topaz의 실제 경쟁자는 Python과 TypeScript이고, 비교는 명확합니다: 그들처럼 읽히되, 정적 타입이고, 단일한 정식 형태가 있고, 런타임 설치물 없는 네이티브 배포를 지향합니다 (배포 도구는 로드맵 단계입니다 — 아래 정직한 경계 절 참고). 오늘 v0.3은 Topaz v5.2를 파싱·해석·실행까지 끝까지 수행합니다 — 정확한 경계는 툴체인 상태가 추적합니다.
성능은 영업 포인트가 아니라 방어선입니다: Topaz를 선택한 대가를 치르지 않게 한다는 것이 설계 목표이지, 벤치마크가 선택의 이유는 아닙니다.
네 개의 기둥
1. 작고 닫힌 표면
Rust가 전문가에게 모든 레버를 쥐여 준다면, Topaz는 정책을 언어
차원에서 결정합니다: 복구 가능한 실패는 Result, 부재는 Option,
프로그래머 오류는 fault(값이 아니며 잡히지 않음), 정리는 defer,
병렬 대기는 concurrent(timeout:) ... else. 파이프라인 관용구는 |>
하나, 암묵적 수치 변환 없음, exhaustive match. v5.1 설계
사이클의 절반은 두 번째 표현 방법을 제거하는 일이었습니다 — 남은
것은 의도당 하나의 정식 형태입니다.
2. Unicode 허용이 아니라 Unicode-first
대부분의 언어는 비영어 식별자를 허용합니다. Topaz는 1급 입력으로 삼습니다 — 공식 예제와 컴파일러 파스 코퍼스에 한국어·이모지 식별자가 들어 있고, 키워드는 영어로 고정하되 이름은 도메인을 따릅니다:
function 인사하기(이름: string) -> string {
return "안녕하세요, {이름}님!"
}감상적인 이유가 아닙니다. 업무 도메인의 개념을 영어로 번역하는 순간 정보가 손실되고, 코드 리뷰가 번역 검수가 됩니다.
3. 에이전트에게 맡길 수 있는 표면
Topaz는 생성 시대를 위해 설계되었고, 이 주장은 희망사항이 아니라 검증 가능합니다:
- 명세가 작고 닫혀 있습니다 — 모든 형태가
Program에서 도달 가능하고, 금지 형태가 열거되어 있습니다; - 정식 프로파일은 스타일 제안이 아니라 기계 검사 가능한 규범 문서입니다;
- 이 사이트의 모든 정식
topaz펜스는 툴체인으로 파스 검증되고, 실행 가능한 예제는 출력이 바이트 단위로 고정된 채 실행되며, 화면의 트랜스크립트는 캡처된 실행 결과와 일치해야 합니다 — 문법이나 런타임에서 어긋난 문서는 검증에 실패합니다 (이 사이트의 검증 방법); - 실패 모드가 좁습니다: 암묵 변환 없음, 명세가 요구하는 match
exhaustiveness(체커 출시 전까지는 런타임 가드), 고정된
fault/
Result경계.
에이전트 시대의 언어는 표현력이 아니라 생성 결과의 일관성과 검증 가능성으로 경쟁합니다.
4. 의도를 담는 템플릿
다른 곳에서 매크로와 라이브러리 규율이 필요한 것이 여기서는 문법입니다:
let report = sql"""
SELECT name, total
FROM orders
WHERE region = {region}
ORDER BY total DESC
"""문법 차원에서 sql 템플릿은 파트와 보간을 분리한 채 유지합니다 —
문자열로 붕괴하지 않으므로 이어붙이기형 인젝션이 일어날 자리가
없습니다. 도메인별 렌더링 정책(파라미터 바인딩, 셸 인용, 경로
정규화)은 미래 v5 결정으로 유예되어 있고, v0.3은 구조화된 값을
런타임까지 그대로 운반합니다. 태그 레지스트리는 닫혀 있어 생성
코드가 유사 DSL을 만들어낼 수 없습니다.
Topaz를 쓰면 안 되는 사람
이 절은 약점이 아니라 신뢰 자산입니다. 다음에 해당하면 Rust(또는 C, Zig)를 쓰는 것이 맞습니다:
- lifetime과 ownership을 직접 제어해야 하는 경우;
- unsafe 경계, FFI, 임베디드 타깃을 다루는 경우;
- 성능 병목을 손으로 최적화하는 경우;
- crate 생태계를 풀파워로 쓰려는 경우;
- 자유도 축소가 비용으로 느껴지는 경우 — Topaz의 좁은 길은 이런 분들에게는 실제 단점입니다.
Topaz의 타깃은 반대편입니다: 시스템 레벨 표면 없이 배포 가능한 결과를 원하는 사람, 도메인 언어를 코드에 남기려는 팀, 일관되게 생성되는 작은 표면이 필요한 에이전트 운영자.
탈출구 질문
다른 언어로 컴파일되는 언어는 결국 탈출구에서 평가받습니다. Topaz의 입장은 고정되어 있습니다:
- 인라인 탈출구는 없습니다. Topaz 소스에 외부 언어 코드를 섞는 문법은 만들지 않습니다. 섞는 순간 작은 표면과 생성 통제가 동시에 무너집니다.
- 경계는 모듈 단위입니다. 외부 코드와의 연결은 명시적으로 라벨링된 모듈 경계에서만 일어납니다 (모듈 시스템은 v5.2에 존재합니다; 인터롭 메커니즘은 이후 버전에서 도입됩니다 — 인라인은 영원히 없습니다).
- 생성된 산출물은 작성 포맷이 아닙니다 (비전 — 미래의 컴파일 파이프라인을 구속하는 약속이며, 현재 Topaz에는 코드 생성이 없습니다). 생성 코드를 읽어야 문제가 풀리는 상황은 컴파일러 버그로 분류합니다 — 외부 도구의 진단이 새어 나오는 것도 마찬가지입니다. Topaz의 진단은 Topaz 소스를 가리킵니다.
그러니 아닙니다 — Topaz 도입이 결국 Rust 학습을 요구하게 되는 일은 없도록 설계되어 있습니다. 이것은 출시된 도구가 아니라 기록된 설계 약속이며, 미래의 툴체인이 이를 깨면 설계 버그로 제보해 주세요.