솔직히 말해 보겠습니다. 매주 쏟아지는 새로운 프로그래밍 언어들에 지치셨나요? 저도 그렇습니다. “더 빠르다”, “더 안전하다”는 마케팅 문구는 이제 식상하죠. 그런데 오늘 Hacker News를 보다가 제 눈길을 사로잡은 녀석이 하나 있습니다. 이름은 Loon 입니다.

브라우저에서 돌아가는 함수형 언어인데, Rust의 Ownership(소유권) 모델과 Koka의 Algebraic Effects(대수적 효과) 를 가져왔습니다. 게다가 문법은 Lisp을 닮았죠. 이 기묘한 혼종이 과연 우리에게 어떤 통찰을 줄 수 있을지, 시니어 엔지니어의 관점에서 뜯어보았습니다.

1. 보이지 않는 타입 (Invisible Types)

Loon의 가장 논쟁적인 특징은 바로 “타입을 작성하지 않는다”는 철학입니다. 동적 타이핑이냐고요? 아닙니다. 강력한 정적 타이핑 언어지만, Hindley-Milner 타입 추론을 극한으로 밀어붙였습니다.

보통 TypeScript나 Rust를 쓸 때도 우리는 타입 추론의 혜택을 봅니다. 하지만 함수 시그니처에는 명시적으로 타입을 적는 것이 관례이자 예의죠. Loon은 여기서 한 발 더 나갑니다.

“타입은 컴파일러가 실수를 잡아내기 위해 존재하는 것이지, 당신의 의도를 표현하기 위해 존재하는 것이 아니다.”

이 문구는 꽤 도발적입니다. HN의 한 유저는 이에 대해 “타입은 컴파일러뿐만 아니라 인간이 코드를 추론하는 데도 도움을 준다”며 강하게 반박했습니다. 저 역시 이 의견에 동의합니다. 코드는 작성하는 시간보다 읽히는 시간이 훨씬 기니까요. 하지만 Loon의 접근 방식은 에디터가 타입을 보여주는 방식(Inlay Hints)으로 이 문제를 해결하려 합니다. 코드는 깔끔하게 유지하고, 정보는 IDE가 제공한다는 것이죠.

2. Algebraic Effects: 예외 처리와 비동기의 통합

제가 Loon에서 가장 흥미롭게 본 부분은 Algebraic Effects 입니다. React를 쓰시는 분들은 Hooks를 떠올리시면 이해가 빠를 겁니다. 하지만 언어 레벨에서 훨씬 더 강력하게 작동합니다.

Loon은 handle이라는 키워드를 통해 부작용(Side-effect)을 제어합니다. 예외 처리, 비동기(Async/Await), 의존성 주입(DI), Mocking을 이 하나의 메커니즘으로 해결합니다.

[handle [load-config "app.toml"]
    [IO.read-file path] [resume "mock contents"]
    [Fail.fail msg]     "default"]

이 코드를 보면 load-config 함수 내부에서 파일 읽기(IO.read-file)가 발생하면, 핸들러가 이를 가로채서 “mock contents”를 반환하며 실행을 재개(resume)합니다. 실패(Fail.fail)하면 기본값을 반환하고요.

이게 왜 중요할까요? 함수의 색깔 문제(Function Coloring Problem) 를 해결하기 때문입니다. 비동기 함수를 호출하기 위해 온갖 곳에 await를 도배할 필요가 없어집니다. 테스트할 때 복잡한 Mocking 라이브러리 없이 핸들러만 갈아 끼우면 됩니다. 아키텍처 관점에서 보면 제어의 역전(IoC)이 언어 문법 자체에 녹아있는 셈입니다.

3. Rust의 소유권 모델 차용

함수형 언어들은 보통 GC(가비지 컬렉터)에 의존합니다. 하지만 Loon은 Rust의 소유권 모델을 가져와서 메모리 안전성을 보장하려 합니다. 흥미로운 점은 이를 명시적으로 선언하는 것이 아니라, 컴파일러가 흐름을 분석해 소유권을 추적한다는 점입니다.

이는 순수 함수형 언어의 불변성(Immutability) 제약을 실용적으로 풀어내려는 시도입니다. 성능 최적화와 리소스 관리를 개발자가 더 세밀하게 할 수 있게 해주니까요.

4. 문법 논란: () vs []

HN에서 가장 뜨거운 감자는 의외로 문법이었습니다. Lisp 계열 언어들은 보통 소괄호 ()를 쓰는데, Loon은 대괄호 []를 사용합니다.

• 찬성: Shift 키를 안 눌러도 돼서 입력이 편하다.
• 반대: 비영어권 키보드 레이아웃에서는 입력이 고역이다 (예: 독일어 키보드).

개인적으로는 [* x x] 같은 문법이 낯설긴 하지만, Clojure 개발자라면 금방 적응할 것 같습니다. 다만, 다중 인자(Multi-arity) 정의를 허용하는 부분은 가독성을 해칠 수 있다는 우려가 듭니다. 함수 오버로딩은 읽는 사람에게 항상 인지 부하를 주니까요.

5. 현실적인 한계와 Verdict

Loon의 공식 사이트 자체도 Loon으로 작성되어 브라우저에서 컴파일되는데, 로딩이 상당히 느립니다. 아직 초기 단계(v0.4)이고 최적화가 덜 되었다는 증거죠. HN 댓글을 보면 “일주일 된 프로젝트”라거나 “Claude가 커밋을 다 짰다”는 의혹도 있었지만, 메인테이너가 빠르게 피드백을 수용하고 버그를 고치는 모습은 긍정적입니다.

제 결론은 이렇습니다:

아직 프로덕션에 도입할 단계는 전혀 아닙니다. 하지만 “타입 추론 + 소유권 + 대수적 효과” 라는 조합은 모던 프로그래밍 언어가 나아가야 할 하나의 방향성을 제시하고 있습니다. 특히 복잡한 비동기 로직과 에러 처리에 지친 백엔드 엔지니어라면, Loon이 제시하는 handle 패턴에서 큰 영감을 받을 수 있을 겁니다.

주말에 가볍게 머리를 식히며 “함수형 언어의 미래”를 맛보고 싶다면, Loon의 플레이그라운드를 한 번 건드려보시길 추천합니다.