Rust를 고수준 언어처럼 사용하는 접근으로, 고통은 줄이고 타입 안정성과 성능의 장점 대부분을 얻는 방법을 살펴봅니다.
에세이 - 게시일: 2026.02.11 | 5분 읽기 (1,413단어)
고지: 제휴 링크를 통해 구매하시면 제가 소액의 수수료를 받을 수 있습니다. (disclosures)
저는 수년간 완벽한 프로그래밍 언어를 찾아 왔고, 지금까지 내린 결론은 그런 언어가 없다는 것입니다.
모든 것을 갖춘 프로그래밍 언어는 없습니다:
여러 언어가 근접하긴 하지만, 모두 뭔가 하나씩은 빠져 있습니다.
지난 몇 년 동안 제가 주로 선택한 언어는 F#, TypeScript, C#이었습니다. 모두 탄탄한 언어이지만, 저는 늘 어떤 차원에서는 타협하고 있다는 느낌을 받았습니다.
F# - 훌륭한 타입과 좋은 기반을 갖췄지만, 문법이 너무 미니멀해서 가독성이 떨어진다고 생각합니다. 생태계는 매우 작고, 버려진 패키지가 많거나 C#과 상호 운용하기 위해 래퍼를 직접 만들어야 합니다. 또 학습 데이터가 너무 적고 OO C#에 가려져 있어서, AI도 관용적인 F#을 잘 다루지 못합니다.
TypeScript - 어디에나 있고 세계 최대의 생태계를 갖고 있지만, 타입은 거짓말이고 생태계는 끊임없이 대규모 혼란을 겪고 있습니다.
C# - 탄탄한 OO 언어이지만 보일러플레이트가 많고, 아직도 네이티브 유니온과 완전한 패턴 매칭을 갖추지 못했습니다 (올해는 가능할까요?).
관련 글: F#가 형편없는 7가지 이유
그래서 저는 해마다 이 언어들 사이를 왔다 갔다 하며, 각 언어를 제가 원하는 방향으로 더 밀어붙이고 있었습니다:
모두 조금씩 가까워졌지만, 여전히 딱 맞지는 않았습니다.
저는 Rust를 오래전부터 알고 있었지만, 진지하게 고려해본 것은 몇 번 되지 않았고 실제로 뭔가를 만들어본 적도 거의 없었습니다. 주된 이유는 학습 곡선에 비해 얻는 이득이 크지 않다고 생각했기 때문입니다. 결국 저는 시스템 수준 프로그래머가 아닌데, 왜 시스템 수준 언어를 써야 할까요?
하지만 최근 몇 주 동안 여러 가지를 만들며 시간을 보낸 Recurse Center에서는 Rust가 인기가 있고, 누군가가 타입만 보고 선택하더라도 Rust는 좋은 언어라고 말했습니다. 그 점이 제게는 흥미로웠습니다. 저는 실제로 언어를 타입 때문에 고르는 경우가 많기 때문입니다 (가장 큰 차별점 중 하나이니까요). 그리고 나서는 그걸 뒷받침할 생태계가 있기를 기대합니다.
그래서 저는 사라진 언어에 대해 조사하고 정리해보았고, 예상대로 Rust는 매우 강력한 후보였습니다. 단, devx만 제외하면요.
그런데 이런 생각이 들었습니다. AI가 표준적인 코드를 아주 잘 작성하는 지금, 이 학습 곡선은 이제 훨씬 낮아진 것 아닐까요? Rust로도 다른 언어만큼 빠르게 움직일 수 있을까요? 그리고 그렇게 할 수 있다면, 우리는 무엇을 얻게 될까요?
Rust의 장단점을 정리하면 대체로 다음과 같습니다:
장점:
단점:
장점은 정말, 정말 좋습니다. 사실 단점만 제거할 수 있다면 Rust는 제가 찾아 헤매던 종류의 언어와 상당히 비슷해 보입니다.
그래서 이런 생각을 하게 됐습니다. Rust를 그냥 고수준 언어처럼 작성할 수 있다면 어떨까요? devx를 C#, F#, TS에 가까운 수준으로만 끌어올릴 수 있다면, 사실상 장점만 남게 됩니다.
그래서 저는 조사하기 시작했고 Rust 책을 읽고 작은 프로토타입도 만들어봤습니다.
그 결과, Rust의 장점은 약 80% 얻으면서도 고통은 약 20%만 감수하면 되는 접근법을 떠올리게 되었습니다. 그리고 대부분의 경우 단점이라고 해봐야 성능이 10-20% 정도 떨어지는 것뿐인데, Rust가 기본적으로 얼마나 빠른지, 또 같은 방식으로 만들 다른 언어들과 비교했을 때 어떤지 생각해보면 나쁘지 않은 수준입니다.
그 접근은 다음과 같습니다:
Arc를 사용하고 불변 컬렉션 crate를 써야 할 가능성이 큽니다.Arc<dyn TRAIT>를 사용합니다.이 접근법으로 성능은 다소 잃게 되지만, clone을 얼마나 자주 하느냐에 따라 대략 10-30% 수준입니다. 만약 hot path나 성능이 중요한 영역이 있다면, 보통 그 부분만 mutation으로 바꿔서 최적화할 수 있습니다.
덧붙이자면, 이 접근법은 어디에서나 불변 구조 / primitive / Arc를 사용해 clone 비용을 줄여야 한다는 점에서 추가적인 정신적 부담을 더합니다. 이는 GC 언어에서는 보통 지불하지 않는 실제 비용입니다 (데이터 양이나 clone의 빈도 / 크기를 제한하는 정도는 제외하고요). 그리고 현재 Rust의 타입 시스템도 이 부분을 도와주지 않습니다 (비싼 clone과 싼 clone이 모두 그냥 .clone()이기 때문입니다). Rust에서 비싼 clone은 정말로 치명적입니다. 모두 깊은 복사이기 때문에, hot path에 비효율적인 clone 몇 개만 있어도 F# / C# 같은 다른 컴파일 언어보다 성능이 더 떨어질 수 있습니다. (이 문제를 돕기 위한 alias 제안들이 있는 것으로 보이고, 저도 이런 실수를 반복하지 않도록 타입 시스템이 이를 지적할 수 있게 해주는 패키지를 만들고 있습니다.)
그래서 이 접근법은 대부분의 일반적인 고수준 컴퓨팅 작업에는 잘 맞지만, 어디에나 통하는 만능 해법은 아닙니다.
제 생각에 이건 성능보다 로직이 더 중요한 경우에 잘 맞습니다. 하지만 성능이 중요한 문제이거나 hot path에 로직이 있다면, mutation이 훨씬 더 빠르기 때문에 아마 그쪽이 더 합리적일 것입니다.
잘 맞는 경우:
맞지 않는 경우:
Rust는 문서상으로는 정말 훌륭한 언어처럼 느껴지지만, 온보딩을 어렵게 만드는 무서운 경계 사례들이 있습니다. 제 생각에는 이 접근법이 그런 날카로운 부분을 조금 무디게 만들어서, 필요할 때는 금속에 가까운 성능도 낼 수 있는 훌륭한 고수준 언어로 Rust를 바꿔줄 수 있습니다.
하지만 두고 봐야겠죠. 저는 이 여정을 몇 주 전에야 막 시작했고, 데모 웹 서비스, 게임, CLI를 통해 이 접근법을 적극적으로 탐구하고 있기 때문에 제 관점이 바뀔 수도 있습니다.
저는 현재 LightClone — 저렴한 clone을 강제하는 패키지 — 를 활발히 만들고 있습니다. 이 아이디어에 관심이 있거나 실제로 보고 싶다면 GitHub에서 star를 눌러주시고 피드백도 보내주세요. 그러면 사람들이 이걸 원한다는 것, 투자할 가치가 있다는 것, 그리고 더 범용적으로 유용하게 만드는 데 도움이 된다는 것을 제가 알 수 있습니다!
이 글이 마음에 들었다면 다음 글들도 좋아하실 수 있습니다:
제 작업을 지원하는 가장 좋은 방법은 즐겨 쓰는 소셜에서 이 글에 좋아요 / 댓글 / 공유를 해주시는 것입니다.
Twitter (@sirhamy)YouTube (HAMY LABS)Instagram (@hamy.labs)LinkedIn (Hamilton Greene)Blue Sky (sirhamy.bsky.social)
HAMINIONs 멤버 되기HAMY 굿즈 쇼핑하기HAMY LABS 후원하기
CloudSeed Rust로 제작됨