프롤로그 — 2026년, '니치 언어'가 다시 흥미로워졌다

2010년대 후반의 언어 풍경은 단조로웠다. Python·JavaScript·Java·Go·Rust·C++·TypeScript — 사실상 이 일곱 언어가 산업의 90%를 차지했고, 나머지는 다 "취미"로 분류됐다.

2026년의 풍경은 더 두텁다.

- **Mojo 25.x** 가 부분 오픈소스화되며 ML 인프라의 '진지한 후보'로 들어왔다. Modular MAX 추론 엔진이 실전 워크로드에서 검증된다.

- **Carbon Language** 가 Google 내부에서 C++ migration 후보로 실험된다. Successor language 라는 명확한 좌표.

- **Roc 0.x** 가 Richard Feldman 주도로 함수형 + 빠른 컴파일 + Elm 스타일 에러 메시지를 가져왔다.

- **Crystal 1.14+** 가 Manas Tecnología와 일부 스타트업에서 실전 운영된다. Ruby 신택스에 정적 타입.

- **Pony 0.59+** 의 actor 모델과 capabilities 가 안전한 동시성의 살아있는 레퍼런스다.

- **Hare 0.25+** 는 Drew DeVault가 만든 미니멀 시스템 언어. C와 같은 영역, 다른 미감.

- **Vale·Hylo·Austral** 같은 메모리 모델 실험 언어들이 "Rust 너머"를 탐색한다.

- **Odin·Jai·Beef** 같은 게임 언어가 인디 씬에서 실제 게임을 출고시킨다.

- **Gleam 1.x** 가 BEAM(Erlang VM) 위에 타입 안전 함수형을 올려 production 사용자를 모은다.

"왜 굳이 니치 언어를 쓰는가" 는 더이상 멍청한 질문이 아니다. 도메인 적합성, 학습 가치, 성능 특성, 커뮤니티 — 합리적 이유가 늘었다. 이 글은 그 지형 전체를 한 번에 정리한다.

> 한 줄 요약: **"이 언어가 무엇을 더 잘하는가, 누가 이미 쓰고 있는가, 1년 뒤에도 살아있을까."** 이 세 질문이 니치 언어 선택의 90%를 결정한다.

1장 · 왜 니치 언어를 보는가 — 학습·도메인·호기심의 삼각형

니치 언어를 진지하게 보는 이유는 대체로 셋 중 하나다.

1. **학습** — 다른 패러다임에 노출되면 메인 언어 실력이 올라간다. Haskell을 한 학기 한 사람이 Python에서 더 좋은 코드를 짠다. Pony를 만져본 사람은 Go의 채널을 더 비판적으로 본다.

2. **도메인 적합성** — Mojo는 ML 인프라, Crystal은 빠른 웹 서비스, Carbon은 C++ migration, Odin은 게임. 도메인이 맞으면 니치 언어가 메인스트림보다 더 생산적이다.

3. **호기심·성능 특성** — GC 없음, 저지연, capabilities, value semantics 같은 특정 성질이 필요한 시스템.

반대로 피해야 할 이유도 분명히 있다.

- "쿨해 보여서" — 6개월 뒤 유지보수자를 못 찾는다.

- "성능이 더 빠를 것 같아서" — 같은 알고리즘이면 메인 언어와 차이가 크지 않은 경우가 대부분.

- "최신 트렌드라서" — 트렌드는 진행 중이지 도착이 아니다.

니치 언어의 진짜 가치는 "메인 언어로는 보이지 않던 시야"를 준다는 데 있다. 그 시야가 코드 한 줄 한 줄에 누적된다.

2장 · Crystal — Ruby의 미감에 정적 타입과 네이티브 컴파일

**Crystal 1.14+** (2014~, Manas Tecnología) 의 설계 명제는 단순하다. "Ruby처럼 보이고 C처럼 달린다." Ruby 신택스에 익숙하면 처음 보는 Crystal 코드도 즉시 읽힌다.

Crystal: 정적 타입 + 타입 추론

def fib(n : Int32) : Int64

return n.to_i64 if n < 2

fib(n - 1) + fib(n - 2)

end

puts fib(30)

핵심 특징:

- **정적 타입 + 강력한 타입 추론** — 명시 없이도 컴파일 타임에 결정.

- **LLVM 백엔드** — 네이티브 바이너리. Ruby 대비 흔히 10~100배 빠른 벤치마크.

- **Fiber 기반 동시성** — Go의 goroutine과 유사한 모델.

- **매크로 시스템** — 컴파일 타임 메타프로그래밍.

- **Shards** — gem 같은 패키지 매니저.

프로덕션 사용:

- **Manas Tecnología** — 창시자 회사. 자체 서비스 운영.

- **Heroku 기반 일부 스타트업** — Ruby에서 Crystal로 부분 이전.

- **Kemal**, **Lucky** 같은 웹 프레임워크가 실전 운영된다.

2026년의 Crystal은 "Ruby 대체" 가 아니라 "Ruby 시야를 지킨 채 성능을 얻고 싶을 때" 의 선택지다. Rails 전체를 Crystal로 옮기는 시나리오는 흔치 않고, 핫스팟 서비스만 잘라내 옮기는 패턴이 일반적이다.

3장 · Pony — Actor 모델과 capabilities 로 만든 안전한 동시성

**Pony 0.59+** 의 디자인은 다른 언어가 본격적으로 차용하지 못한 영역에 있다. **레퍼런스 capabilities** 라는 시스템으로 데이터 경쟁(data race)이 컴파일 타임에 불가능하게 만든다.

// Pony: actor 모델

actor Counter

var _count: U64 = 0

be increment() =>

_count = _count + 1

be report(env: Env) =>

env.out.print("count: " + _count.string())

핵심 특징:

- **Actor 모델** — Erlang/Elixir와 유사하지만 정적 타입.

- **Reference capabilities** — `iso`, `val`, `ref`, `box`, `tag`, `trn` 의 6가지 capability 가 객체 공유 가능성을 컴파일 타임에 보장.

- **No data races** — capability 시스템이 보장.

- **No deadlocks** — actor 끼리 락이 없음.

- **GC per-actor** — 액터 단위로 분리된 가비지 컬렉션.

프로덕션 사용:

- **Wallaroo Labs** — 스트리밍 데이터 처리. 인수 후 회사가 정리되며 Pony의 가장 큰 production user 가 사라짐.

- 현재는 학술·소규모 시스템 중심.

Pony는 "production 채택" 으로 보면 작지만, "동시성 안전성을 어떻게 타입 시스템으로 표현할 것인가" 의 살아있는 레퍼런스다. Rust의 `Send`/`Sync` 이전 세대 아이디어가 더 정교한 형태로 Pony에 있다.

4장 · Mojo — Python superset 로 SIMD·GPU 까지

**Mojo 25.x** (2023~, Modular, Chris Lattner) 는 가장 최근에 떠오른 시스템 언어다. 슬로건은 명확하다. "Python의 신택스에, C++ 의 성능과 SIMD/GPU 까지."

Mojo: Python superset

fn fib(n: Int) -> Int:

if n < 2:

return n

return fib(n - 1) + fib(n - 2)

fn main():

print(fib(30))

핵심 특징:

- **Python superset** — 기존 Python 코드가 거의 그대로 동작.

- **MLIR 기반** — 컴파일러 인프라가 Chris Lattner의 LLVM·Swift·MLIR 계보.

- **SIMD/GPU 일급 시민** — 벡터 연산이 언어 레벨에서.

- **Ownership** — Rust-스타일 메모리 안전성 + 값 시맨틱.

- **Modular MAX** — Mojo로 구현된 추론 엔진. PyTorch/TF 호환.

2025년 오픈소스화:

- **Modular 가 일부 컴포넌트를 MIT 라이선스로 공개**. 표준 라이브러리, 런타임 일부.

- 컴파일러 자체는 여전히 closed source 영역이 있음.

- 커뮤니티의 기대 vs 비판이 공존.

프로덕션 사용:

- **Modular MAX** — Modular의 추론 엔진. Mojo 자체로 구현.

- ML 인프라 스타트업 일부 채택.

2026년 Mojo는 "Python처럼 쓰는데 PyTorch보다 빠른 인프라가 필요할 때" 의 후보다. 일반 백엔드 언어로 Mojo를 쓰는 시나리오는 아직 흔치 않다.

5장 · Carbon — C++ 후계자 후보, Google 의 실험

**Carbon Language** (2022~, Google, experimental) 는 명확한 좌표를 가진다. **C++ successor language**. Rust나 Go가 아니라 "C++ 코드를 점진적으로 옮길 수 있는 언어" 가 목표다.

// Carbon: C++ 후계자 후보

package Sample api;

fn Fib(n: i32) -> i64 {

if (n < 2) { return n as i64; }

return Fib(n - 1) + Fib(n - 2);

}

fn Main() -> i32 {

Print("{0}", Fib(30));

return 0;

}

핵심 특징:

- **C++ interop** — C++ 코드와 양방향 상호운용. 한 프로젝트에서 두 언어가 공존.

- **Memory safety roadmap** — 메모리 안전성을 옵션으로 점진 도입.

- **Modern syntax** — C++ 의 역사적 짐을 제거.

- **No backwards compat guarantee** — C++ 처럼 35년 호환성 부담이 없음.

2026년 현황:

- 여전히 **experimental** 상태. 프로덕션 사용 권장 안 함.

- Google 내부에서 toolchain 실험.

- 표준이라기보다 "C++ 의 방향성에 대한 사고 실험" 에 가까움.

Rust가 "C++ 와 다른 언어로 처음부터 다시 쓰자" 라면, Carbon은 "C++ 코드베이스를 그대로 두고 점진적으로 후계자로 옮기자" 다. 같은 문제에 대한 다른 답이다.

6장 · Hare — Drew DeVault 의 미니멀 시스템 언어

**Hare 0.25+** (2022~, Drew DeVault 외) 는 명확하게 작은 언어다. **C 와 같은 영역, 다른 미감.**

// Hare: 미니멀 시스템 언어

use fmt;

export fn main() void = {

fmt::println("Hello, world!")!;

};

핵심 특징:

- **No GC** — 수동 메모리 관리.

- **No generics** — 의도적으로 빠진 기능. 단순성 우선.

- **Small standard library** — 명시적이고 작음.

- **QBE backend** — LLVM 대신 QBE 컴파일러 백엔드. 빌드가 빠르고 toolchain 이 작음.

- **AGPL/MPL 라이선스** — 자유 소프트웨어 윤리.

설계 철학:

- "C 가 50년 된 것은 좋다. 다만 그 50년 동안의 실수는 안 반복한다."

- Generics 가 없는 것은 버그가 아니라 기능. 단순성과 가독성 우선.

- 표준 라이브러리가 작은 것도 기능. 의존성 폭증을 막음.

2026년 Hare는 production 사용보다는 "C 의 정신을 다른 방식으로 잇는 언어" 의 살아있는 예시다. Drew DeVault 의 다른 프로젝트(sourcehut, wlroots) 와 결을 같이한다.

7장 · Roc — Elm 영감의 함수형, 빠른 컴파일

**Roc** (2020~, Richard Feldman) 은 명확하게 함수형 진영의 야심작이다. 슬로건은 "fast, friendly, functional."

Roc: Elm-inspired functional

app "fib"

packages { pf: "platform/main.roc" }

imports [pf.Stdout]

provides [main] to pf

fib = \n ->

if n < 2 then n

else (fib (n - 1)) + (fib (n - 2))

main = Stdout.line (Num.toStr (fib 30))

핵심 특징:

- **Purely functional** — Elm 처럼 순수 함수형.

- **Static types + 강력한 추론** — 명시 없이 거의 모든 타입 추론.

- **Friendly error messages** — Elm 스타일 컴파일러 에러.

- **Platforms** — 플랫폼(host)이 I/O 와 effects 를 담당, Roc 코드는 순수.

- **No null, no exceptions** — 명시적 Result 와 Task.

- **Fast compile** — 컴파일이 빠른 것이 디자인 목표.

프로덕션 사용:

- 소규모지만 성장 중.

- Web server, CLI 도구.

- platform 모델 덕에 다양한 host 에 임베드 가능.

Roc 는 "함수형이 진지한 옵션이 되는 한 방법" 의 사례다. Elm 의 미감을 Web 너머 시스템 영역으로 가져온 실험.

8장 · Vale — gen+region 메모리, no GC, no borrow checker

**Vale** 은 메모리 모델 실험의 최전선에 있는 언어다. **Generational references** 와 **region-based memory** 로 GC 없이도 borrow checker 의 학습 곡선을 피한다.

// Vale: generational references

exported func main() {

println("Hello, Vale!");

}

핵심 특징:

- **Generational references** — 포인터에 generation 번호를 붙여 use-after-free 를 런타임에 막음.

- **Regions** — 메모리 영역 단위로 GC/manual/arena 를 선택.

- **No borrow checker** — Rust 의 lifetimes 같은 컴파일 타임 제약 없음.

- **No GC** — 기본적으로 garbage collection 없음.

- **Linear types 옵션** — 자원 추적이 필요하면 명시적으로 선택.

설계 철학:

- "Rust 만큼 빠르면서, Java 만큼 쓰기 쉽게."

- Borrow checker 의 학습 비용을 generational references 로 우회.

- region 으로 메모리 전략을 코드 단위로 선택할 수 있음.

Vale 은 production 사용보다는 "메모리 안전성을 어떻게 다르게 풀까" 의 실험실이다. 아이디어 자체가 다른 언어로 전파될 가능성이 높다.

9장 · Virgil — Google Research 의 연구 언어

**Virgil** (Ben L. Titzer, Google) 은 연구 언어 진영의 베테랑이다. 임베디드와 시스템 사이에 좌표를 둔다.

// Virgil: research language

def main() {

System.puts("Hello, Virgil!\n");

}

핵심 특징:

- **AOT 컴파일** — Ahead-of-time 컴파일.

- **No GC** — 정적 메모리 모델.

- **Tiny runtime** — 임베디드 친화적.

- **Compile-time initialization** — 초기화를 컴파일 타임에 처리.

- **WebAssembly 백엔드** 도 지원.

Virgil 은 "임베디드와 WASM 사이에서 작은 런타임을 유지하면서도 모던 언어 기능을 가지는 길" 의 연구 사례다. 직접 production 에서 채택할 일은 드물지만, 아이디어가 다른 곳으로 흐른다.

10장 · Gleam — BEAM 위의 타입 안전 함수형

**Gleam 1.x** (Louis Pilfold) 는 명확한 가치 제안을 가진다. **Erlang VM(BEAM) 위에 타입 안전 함수형을 올린 언어.**

// Gleam: BEAM 위의 타입 안전 함수형

pub fn main() {

io.println("Hello, Gleam!")

}

핵심 특징:

- **Strong static typing** — 모든 타입이 컴파일 타임에 결정.

- **Erlang interop** — Erlang/Elixir 라이브러리를 그대로 호출.

- **JS target** — JavaScript 로도 컴파일.

- **Friendly syntax** — Rust 와 Elm 의 영향이 느껴짐.

- **Production users 증가 중**.

Gleam 은 "Erlang/Elixir 의 액터·OTP 의 견고함" 과 "정적 타입의 안전성" 을 모두 원하는 사람들의 답이다. 2026년 production 사용이 빠르게 늘고 있다.

11장 · Grain — 타입 함수형, WebAssembly 우선

**Grain** 은 처음부터 WebAssembly 타겟을 가정하고 설계된 함수형 언어다.

// Grain: WASM-first functional

print("Hello, Grain!")

핵심 특징:

- **WebAssembly 우선** — 1차 타겟이 WASM.

- **Strong static types** — 함수형 친화적 타입 시스템.

- **GC 있음** — WASM 환경의 GC.

- **No null** — Option·Result 명시적 처리.

Grain 은 "WebAssembly 가 모든 곳에서 돌아가는 시대" 에 적합한 함수형 옵션 중 하나다. 아직 작은 생태계지만 WASM 가 커지면 같이 커질 가능성이 있다.

12장 · Chapel — HPC 와 병렬 프로그래밍

**Chapel** (Cray/HPE) 은 HPC(High Performance Computing) 진영의 언어다. 명시적으로 병렬·분산 프로그래밍을 일급 시민으로 다룬다.

// Chapel: HPC parallel

forall i in 1..10 do

writeln("Hello from iteration ", i);

핵심 특징:

- **First-class parallelism** — 병렬 루프와 작업이 언어 레벨.

- **Locality awareness** — locale 개념으로 분산 노드에 분배.

- **Productivity + Performance** — 두 마리 토끼.

- **Supercomputer 환경 친화** — Cray 머신과 같은 대규모 분산.

Chapel 은 일반 웹 백엔드용 언어가 아니다. 그러나 numerical computing, scientific HPC 에서는 진지한 후보다. Mojo 와는 다른 결의 "performance" 를 노린다.

13장 · Inko — 동시성 OO, owned values

**Inko** (Yorick Peterse) 는 owned values 와 동시성을 결합한 OO 언어다.

// Inko: concurrent OO

class async Main {

fn async main {

Stdout.new.print('Hello, Inko!')

}

}

핵심 특징:

- **Async-first** — actor 와 lightweight process.

- **Owned values** — Rust 와 유사한 ownership.

- **No null** — Option 사용.

- **Pattern matching** — 강력한 패턴 매칭.

- **Erlang/Pony 의 영향**.

Inko 는 production 사용은 작지만, "OO 언어의 모던화" 라는 좌표에서 의미 있는 실험이다.

14장 · Hylo — mutable value semantics

**Hylo (formerly Val)** (Dave Abrahams 외) 는 명시적으로 **mutable value semantics** 를 핵심 철학으로 가져온 언어다.

// Hylo: mutable value semantics (signature 예시)

public fun main() {

print("Hello, Hylo!")

}

핵심 특징:

- **Value semantics** — 모든 것이 값. 참조 공유 없음.

- **Mutable values** — 값을 mutate 할 수 있지만 aliasing 은 없음.

- **No borrow checker** — value semantics 가 안전성을 자연스럽게.

- **Generic programming** — C++ template 의 후계자 격.

Hylo 는 Dave Abrahams 의 C++ generic 작업의 연장선이다. C++ committee 에서 못 한 것을 처음부터 다시 디자인한다.

15장 · Austral — linear types 의 실용화

**Austral** 은 **linear types** 를 핵심 기능으로 가진 시스템 언어다.

// Austral: linear types

module Main is

public function Main(): ExitCode is

return ExitSuccess();

end

end

핵심 특징:

- **Linear types** — 모든 자원이 정확히 한 번 소비.

- **No GC** — 수동 메모리.

- **Capability-based security** — 시스템 자원 접근에 capability 필요.

- **Small specification** — 언어 명세가 의도적으로 작음.

Austral 은 "linear types 를 진지하게 실용 언어로 가져오면 어떻게 보이는가" 의 답이다. Rust 의 affine types 와 비교하면 더 엄격하다.

16장 · Odin — Ginger Bill 의 게임 언어

**Odin** (Ginger Bill, 2016~) 은 게임 프로그래밍을 1차 타겟으로 한 시스템 언어다. Pascal 의 미감을 모던화한 인상.

// Odin: 게임 친화 시스템 언어

package main

main :: proc() {

fmt.println("Hello, Odin!")

}

핵심 특징:

- **No GC, manual memory** — 게임 친화.

- **Custom allocators** — 메모리 할당 전략을 코드에서 선택.

- **Struct-of-arrays 친화** — SoA 변환을 언어에서 지원.

- **Foreign function interface** — C 와 매끄러운 상호운용.

- **Vendor library** — 자주 쓰는 OpenGL·Vulkan·SDL2 바인딩 포함.

프로덕션 사용:

- **EmberGen** (JangaFX) — VFX 시뮬레이션 도구.

- 일부 인디 게임.

- **Bill 본인의 게임 개발**.

Odin 은 "C 의 정신을 게임에 맞게 모던화한" 언어의 한 답이다. Zig·Jai 와 영역이 겹치지만 미감이 다르다.

17장 · Jai — Jonathan Blow 의 closed-beta 게임 언어

**Jai** (Jonathan Blow, 비공개 베타) 는 The Witness 와 Braid 의 개발자가 만드는 게임 언어다. 2026년 시점에도 closed beta 단계.

핵심 특징:

- **No GC** — 게임 친화.

- **Compile-time execution** — 컴파일 타임에 임의 코드 실행. metaprogramming 의 다른 답.

- **Data-oriented design 친화**.

- **Fast iteration** — 컴파일 속도가 핵심.

2026년 현황:

- 여전히 비공개 베타.

- 영상으로만 공개되며 production 게임 출시는 제한적.

- 커뮤니티 일각에서 "언제 공개되나" 의 기대 vs 회의.

Jai 는 production 으로 평가하기 어렵지만, "compile-time execution 을 진지하게 끝까지 끌고 가면" 의 사고 실험으로 가치가 있다.

18장 · 그 외 시스템·게임·실험 언어 — V·Wuffs·Mun·Beef·Beef·Pinion·Helium

짧게 훑어볼 만한 언어들.

- **V (Volt)** — Go 와 Rust 의 영향. 다소 마케팅과 실제 진행도 사이의 격차로 논란. 그러나 작은 바이너리, 빠른 컴파일 등 명확한 매력 포인트가 있음.

- **Wuffs** — Google. "Safe-by-default subset of C." 이미지 디코더·압축 해제 같은 영역에 특화. Chrome 의 일부 코덱이 Wuffs 로 작성됨.

- **Mun** — 게임 hot-reload 친화 스크립팅. 작은 임베디드 언어.

- **Beef** — BeefLang. C# 의 영향. 게임 친화. IDE 와 컴파일러를 같이 개발.

- **Pinion**, **Helium** — 연구 단계의 실험 언어들.

이 그룹은 "production 추천" 보다는 "아이디어 시장" 이다. 한 둘이 메인스트림에 영향을 줄 수도 있고, 다 사라질 수도 있다.

19장 · 결정 매트릭스 — 어떤 도메인에 어떤 언어를 보는가

도메인별 결정 가이드.

| 도메인 | 진지한 후보 | 니치 후보 |

| --- | --- | --- |

| C/C++ replacement | Rust, Zig, Go | Carbon, Hare, Odin |

| Python 성능 | Cython, Numba, PyPy | Mojo |

| 함수형 | F#, OCaml, Haskell | Roc, Gleam, Grain |

| Erlang/BEAM | Elixir, Erlang | Gleam |

| 동시성·actor | Erlang/Elixir, Akka(JVM) | Pony, Inko |

| Ruby 대안 | Ruby + JIT, Crystal | Crystal |

| 게임 | C++, Rust+Bevy | Odin, Jai, Beef |

| HPC | C++, Fortran, Julia | Chapel, Mojo |

| WASM-first | Rust, AssemblyScript | Grain, Virgil |

| 메모리 실험 | Rust | Vale, Hylo, Austral |

| 임베디드 | C, Rust embedded | Hare, Virgil |

| 이미지/코덱 | C, Rust | Wuffs |

"진지한 후보" 는 production 채택 사례가 충분하고 채용 시장이 존재한다. "니치 후보" 는 도메인 맞으면 매우 강력하지만 채용·생태계 리스크가 있음.

20장 · 채용·커뮤니티·한국·일본 — 현실 점검

니치 언어를 진지하게 보려면 시장 현실도 봐야 한다.

- **채용 시장**:

- 대부분 0~극소수. Crystal·Gleam·Mojo 정도가 간헐적으로 채용 공고가 보임.

- Carbon·Jai·Vale·Hylo 는 직무 공고 거의 없음.

- 다만 "주력 언어로 채용은 안 하지만 사이드 프로젝트로 환영" 하는 회사는 늘었음.

- **커뮤니티 규모** (GitHub stars, Discord 멤버 기준 대략):

- Mojo: 가장 크고 빠르게 성장.

- Crystal, Gleam, Roc: 중간 규모이지만 활성화.

- Pony, Hare, Vale, Hylo: 작지만 응집력 있음.

- Jai, Carbon: 정보 제한적.

- **한국 커뮤니티**: 거의 모든 니치 언어가 매우 작음. Crystal·Mojo 가 일부 발표 자료가 있는 수준.

- **일본 커뮤니티**: Crystal Tokyo Meetup, Mojo 관련 일본 커뮤니티가 있음. 일본은 niche language 에 비교적 관용적.

- **학습 자료**:

- 공식 문서는 모든 언어가 평균 이상.

- 책은 Crystal·Mojo 정도가 있음.

- 한국어/일본어 자료는 극히 적음.

니치 언어를 회사 도입할 때 가장 큰 리스크는 "나 떠나면 유지보수 누가 하나" 다. 이 질문에 답이 안 서면 진지하게 재고할 것.

21장 · 학습 경로 — 한 번에 너무 많이 보지 말 것

니치 언어를 학습할 때 추천 경로.

1. **메인 언어 한 둘을 단단히 한다** — Python·Rust·Go·TypeScript 중 둘 정도는 진지하게.

2. **다른 패러다임 한 언어를 깊게 본다** — 함수형이면 OCaml 이나 Haskell 한 학기. 동시성이면 Erlang/Elixir 한 프로젝트.

3. **그 다음 니치를 본다** — 메인이 단단하면 니치 언어의 아이디어가 더 잘 보임.

4. **작은 프로젝트로 시작** — CLI 도구, 작은 웹 서비스. production 환경에 처음부터 도입은 위험.

5. **공식 문서 → 표준 라이브러리 → 작은 OSS 코드** — 책은 옵션. 문서가 가장 정확.

6. **커뮤니티 1년 관찰** — Discord, GitHub, 공식 블로그. 죽은 언어 vs 자라는 언어가 6개월이면 드러남.

기억할 것: 니치 언어를 본 시간이 메인 언어 실력으로 누적된다. 그 자체가 보상이다.

에필로그 — 결론과 권장 사항

니치 언어 풍경을 한 줄로 요약하면 이렇다.

> "메인스트림이 80% 의 일을 해결한다. 니치 언어는 나머지 20% 와 미래 100% 의 시야를 준다."

**2026년 권장 사항**:

1. **Crystal** — Ruby 신택스에 정적 타입과 네이티브 컴파일이 필요하면 안전한 후보.

2. **Gleam** — Erlang/Elixir 의 모델이 좋지만 타입이 필요하면 진지한 옵션.

3. **Mojo** — Python·ML 인프라에서 성능이 필요하면 살펴볼 가치.

4. **Roc** — Elm 미감을 서버·CLI 영역으로 가져오고 싶으면.

5. **Odin** — 게임·시스템 영역에서 C 보다 모던한 미감이 필요하면.

6. **나머지 (Carbon·Jai·Vale·Hylo·Austral)** — 학습·호기심 권장. production 도입은 신중.

니치 언어는 "도구" 보다 "시야" 다. 그 시야는 메인 언어로 돌아가도 사라지지 않는다.

— 니치 모던 언어 2026, 끝.

References

1. Manas Tecnología. "Crystal Programming Language." [https://crystal-lang.org/](https://crystal-lang.org/)

2. Pony Project. "Pony Programming Language." [https://www.ponylang.io/](https://www.ponylang.io/)

3. Modular. "Mojo Programming Language." [https://www.modular.com/mojo](https://www.modular.com/mojo)

4. Google. "Carbon Language GitHub." [https://github.com/carbon-language/carbon-lang](https://github.com/carbon-language/carbon-lang)

5. DeVault, D. "Hare Programming Language." [https://harelang.org/](https://harelang.org/)

6. Feldman, R. "Roc Programming Language." [https://www.roc-lang.org/](https://www.roc-lang.org/)

7. Vale Language. "Vale." [https://vale.dev/](https://vale.dev/)

8. Titzer, B. L. "Virgil Programming Language." [https://github.com/titzer/virgil](https://github.com/titzer/virgil)

9. Pilfold, L. "Gleam Programming Language." [https://gleam.run/](https://gleam.run/)

10. Grain Lang. "Grain Programming Language." [https://grain-lang.org/](https://grain-lang.org/)

11. Cray/HPE. "Chapel Parallel Programming Language." [https://chapel-lang.org/](https://chapel-lang.org/)

12. Peterse, Y. "Inko Programming Language." [https://inko-lang.org/](https://inko-lang.org/)

13. Abrahams, D. "Hylo Programming Language." [https://www.hylo-lang.org/](https://www.hylo-lang.org/)

14. Austral Lang. "Austral Programming Language." [https://austral-lang.org/](https://austral-lang.org/)

15. Bill, G. "Odin Programming Language." [https://odin-lang.org/](https://odin-lang.org/)

16. Blow, J. "Jai Programming Language Presentations." [https://www.youtube.com/@jblow888](https://www.youtube.com/@jblow888)

17. V Project. "V Programming Language." [https://vlang.io/](https://vlang.io/)

18. Google. "Wuffs Programming Language." [https://github.com/google/wuffs](https://github.com/google/wuffs)

19. Mun Lang. "Mun Programming Language." [https://mun-lang.org/](https://mun-lang.org/)

20. Beef Lang. "Beef Programming Language." [https://www.beeflang.org/](https://www.beeflang.org/)

21. Lattner, C. "Modular Blog." [https://www.modular.com/blog](https://www.modular.com/blog)

22. Feldman, R. "Roc Talks." [https://www.youtube.com/@rtfeldman](https://www.youtube.com/@rtfeldman)

23. Crystal Tokyo. "Crystal Tokyo Meetup." [https://crystal.tokyo/](https://crystal.tokyo/)

24. Carbon Working Group. "Carbon Language Design Documents." [https://github.com/carbon-language/carbon-lang/tree/trunk/docs](https://github.com/carbon-language/carbon-lang/tree/trunk/docs)

25. Roc Zulip. "Roc Community." [https://roc.zulipchat.com/](https://roc.zulipchat.com/)