최근 프로그래밍 언어 트렌드, 그리고 이펙트 시스템의 미래

프로그래밍 언어의 설계와 구현은 지금 흥미로운 시기에 있다. 이 글에서는 최근 트렌드를 다섯 축으로 조망한 뒤, 이 분야에서 가장 뜨거운 주제인 이펙트 시스템(effect systems) 이 미래를 향해 정말 좋은 것이 될지를, 순풍과 역풍 양면에서 고찰한다.

Part 1: 최근 트렌드 조망

① GC 없는 메모리 안전 — 그리고 그 ’무거움’에 대한 반동

지난 10년의 최대 흐름은 Rust의 borrow checker가 메모리 안전의 방식을 주류로 만든 것이다. 하지만 지금은 “Rust의 안전성을, 더 가벼운 쓰기 감각으로” 를 노리는 움직임이 두드러진다.

• mutable value semantics(Hylo／구 Val) — 에일리어싱을 언어 수준에서 배제해, borrow checker 없이 안전하게 한다
• region 기반／generational references(Vale, Verona) — 리전으로 수명을 묶어 참조의 건전성을 가볍게 보장한다
• linear／affine types(Austral 등) — 값의 사용 횟수를 타입으로 묶는다

Rust 자신도 차세대 borrow checker(Polonius), gen 블록, async 개선으로 ’인간공학적 무거움’을 깎아내고 있다. 공통 주제는 “소유권은 필요하지만, Rust만큼 작성자에게 부담을 주고 싶지 않다”이다.

② 병행성 — ’함수 색칠’로부터의 되돌림

• structured concurrency(nursery／task group)가 정착 — Swift, Kotlin, Python, Trio
• virtual threads／colorless async — Java의 Project Loom(가상 스레드)이 크다. “async를 쓰지 않고 대량 병행” = Go식 동기 스타일로의 회귀
• data-race freedom을 타입으로 — Rust의 Send/Sync, Swift 6의 strict concurrency(Sendable)

async 여부로 함수가 두 색으로 갈리는 ‘함수 색칠(function coloring)’ 문제에 대한 반동이, 그린 스레드 회귀라는 형태로 나타나고 있다.

③ 타입 시스템의 고도화

• gradual typing의 성숙 — TypeScript의 지배, Python(pyright／typing 진화), Ruby(RBS／Sorbet)
• dependent／refinement types의 실용화 조짐 — Lean 4가 “정리 증명 지원이면서 평범하게 쓸 수 있는 언어”로 부상, Idris 2, F*, Liquid Haskell
• bidirectional type checking이 표준 기법으로 — 국소 추론＋주석으로 전역 추론의 취약함을 피한다

④ 구현·툴체인

여기가 구현자에게 가장 크게 작용하는 영역이다.

• LLVM 독주에서의 다양화 — Cranelift(빠르다, Wasmtime／rustc의 대체 backend), MLIR(Mojo나 AI 컴파일러의 기반), QBE(작은 backend), 자체 backend 회귀
• WebAssembly의 일급 타깃화 — Wasm GC, component model, WASI preview 2. “유니버설 컴파일 타깃”으로 처음부터 Wasm을 노리는 언어가 증가
• query-based／incremental compiler(rustc, Salsa)가 아키텍처의 정석으로
• LSP 퍼스트 — 언어를 만드는 시점에 language server 전제
• self-hosting／bootstrapping을 마일스톤으로 두는 문화
• 빠른 컴파일 그 자체를 기능으로 — Zig, Go, D

⑤ 횡단적 설계 철학

• capability 기반／no ambient authority — 글로벌 IO를 폐지하고 권한을 명시적 값으로 넘긴다. object-capability의 계보(Austral, Wasm component model). AI 생성 코드 시대의 샌드박스 적합성이라는 맥락에서도 가치가 오르고 있다
• comptime／staged metaprogramming — Zig의 comptime이 대표. 매크로보다 타입 안전한 메타프로그래밍
• error-as-values ＋ ? 전파 — 예외에서 ’값으로서의 에러’로. Rust／Swift／Zig가 ?로 전파
• pattern matching이 전 언어로 — Python의 match, Java, C#
• immutability by default／식 지향

Part 2: 이펙트 시스템은 미래를 향해 좋은 것이 될까

이 트렌드들 중에서도 타입 시스템 분야에서 가장 뜨거운 것이 이펙트 시스템이다. async/await·제너레이터·예외·상태·DI·병행을 하나의 기구(handler)로 통일하려는 발상이다. 그렇다면 이것은 미래를 향해 정말 좋은 것이 될까. 나의 견해는 “아이디어는 거의 확실히 미래의 일부가 된다. 다만 ‘타입 붙은 이펙트를 여기저기 쓰는’ 순수한 형태 그대로 주류화될지는 아직 도박” 이다.

순풍 — 왜 논리가 좋은가

• 통일력 — async·제너레이터·예외·상태·병행·이터레이터를 하나의 기구로 표현. 개념적 경제성이 높다
• 함수 색칠 문제를 원리적으로 푼다 — async의 두 색 문제를, 이펙트로 일반화해 흡수한다
• 이펙트가 타입에 실린다＝검사 가능 — “이 함수는 IO를 하는가／예외를 던지는가”가 시그니처에 드러난다. 테스트·샌드박스·AI 생성 코드의 안전성 맥락에서 가치가 오른다
• 재개 가능한 제어 — 백트래킹·협조 스케줄링·확률적 프로그래밍이 자연스럽게 써진다
• 합성된다 — 모나드 트랜스포머의 ’mtl 지옥’이 필요 없다

역풍 — 놓치기 쉬운, 구체적인 장애

솔직히 말하면 장애도 구체적이고 무겁다.

① 타입·추론·인간공학의 비용. 타입 붙은 이펙트는 타입 시스템에 통째로 새로운 차원(이펙트 다형·이펙트 행)을 더한다. 추론이 어려워지고, 에러 메시지가 무서워지며, 모든 함수의 시그니처에 이펙트 주석이 늘어난다. 중요한 전례가 있다 — Java의 검사 예외(checked exceptions)는 원시적인 이펙트 시스템 그 자체였다. 그리고 다들 싫어해 사실상 버렸다. 이펙트 시스템은 말하자면 “검사 예외를 제대로 다시 한 것”이지만, 그 검사 예외가 반면교사인 것이다.

② 성능·구현 비용. 일반(multi-shot) 핸들러는 연속(continuation) 캡처가 필요해, 빠르게 컴파일하기 어렵다. 빠르게 하려면 one-shot으로 제한하거나 무거운 CPS＋최적화가 필요하다. “우아한 의미론”과 “손으로 쓴 async만큼의 속도”의 격차는 아직 완전히 메워지지 않았다.

③ colorless async라는 강력한 경쟁자. 이펙트 시스템의 최대 셀링 포인트는 async의 통일인데, Java의 가상 스레드(Loom)나 Go는 타입 시스템에 아무것도 더하지 않고 실무의 고통을 해결해 버렸다. 즉 가장 큰 수요(async)를 지루한 그린 스레드가 빼앗고 있다. 이는 이펙트 시스템에 대한 수요 자체를 깎는다.

④ 전체를 끌어들이지 않으면 효과가 없다. 이펙트를 살리려면 언어와 표준 라이브러리 전체가 이펙트를 말해야 한다. OCaml 5가 굳이 ‘타입을 붙이지 않는’ 이펙트 핸들러를 넣은 것은, 타입 시스템을 통째로 다시 만드는 것을 피하기 위해서였다.

어디에 착지할 것인가

’표면의 패러다임’보다 ’구현의 기반’과 ’한정적 기능’으로 이긴다 — 이것이 현실적인 선이라고 본다.

1. 런타임(타입 없는) 핸들러를 부품으로(OCaml 5 형) — 언어는 한정 연속／핸들러를 프리미티브로 제공하고, async·제너레이터는 라이브러리가 위에 만든다. 이미 출하되어 유용하다. 이펙트를 ’엔진’으로 쓰고 문법 표면에는 두지 않는 지름길
2. 개별 이펙트가 일급 기능으로 들어온다 — 일반 시스템이 아니라 yield(제너레이터), async, ?(에러 전파), cancellation이 각각 독립 기능으로 흡수된다. 이펙트의 이익을 조각으로 파는 것
3. capability／effect-as-value 방식 — 행 다형의 완전한 타입 이펙트가 아니라, 능력(Console／Net／Clock)을 명시적 값으로 넘긴다. “이펙트가 명시·검사 가능·ambient authority 없음”이라는 80%의 가치를, 평범한 타입 시스템으로 얻는다. Roc의 platform, Unison의 abilities, object-capability 계열이 여기
4. 연구 선행 언어(Koka／Effekt／Flix／Unison／Eff)가 타입 이펙트를 계속 증명한다 — 누군가 “무섭지 않은 추론 × async급 속도 × 타입 이펙트”를 깨면 단숨에 판이 바뀐다. 그것이 미해결의 분기점

정리

최근 언어 트렌드를 관통하는 실은, “안전성·병행성·검사 가능성을, 작성자의 부담을 늘리지 않고 얻고 싶다”는 한 점에 있다. 메모리 안전은 borrow checker에서 가벼운 대안으로, 병행성은 함수 색칠에서 colorless로, 그리고 이펙트는 ’타입 붙은 패러다임’에서 ’구현 기반＋능력 기반 설계＋조각 기능’으로 — 모두 이상적 의미론과 실무의 인간공학 사이의 줄다리기다.

이펙트 시스템에 대한 한마디 결론은 이렇다. 그 사고방식은 미래에 남는다. 다만 대부분은 ‘구현의 기반’, ‘이펙트를 값으로 다루는 설계’, ’조각난 개별 기능’으로 흡수되고, 순수한 형태의 성패는 인간공학과 성능에 달려 있다. 그리고 최대의 경쟁자는, 역설적으로 지루한 그린 스레드다.