# OCaml을 사랑하는 이유 (2023) > Clean Markdown view of GeekNews topic #24226. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24226](https://news.hada.io/topic?id=24226) - GeekNews Markdown: [https://news.hada.io/topic/24226.md](https://news.hada.io/topic/24226.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-11-08T17:33:27+09:00 - Updated: 2025-11-08T17:33:27+09:00 - Original source: [mccd.space](https://mccd.space/posts/ocaml-the-worlds-best/) - Points: 2 - Comments: 1 ## Topic Body - **함수형 프로그래밍과 정적 보장**을 중시하는 개발자가 여러 언어를 경험한 끝에 OCaml의 균형 잡힌 설계를 높이 평가 - Haskell의 **복잡한 타입 시스템과 느린 컴파일 속도**에 비해, OCaml은 단순성과 실용성을 함께 제공 - Go의 **빠른 컴파일과 간결한 런타임**을 닮았지만, 함수형 언어의 **패턴 매칭·합타입** 같은 강점을 유지 - **빠른 빌드, 정적 바이너리, 풍부한 문서화 도구(odig, utop)** 등으로 생산성과 접근성이 높음 - 단순성과 표현력의 **균형**, 그리고 세련된 언어 설계가 OCaml의 가장 큰 매력으로 제시됨 --- ### 프로그래밍 언어 경험과 비교 - 다양한 언어로 아마추어 및 전문 소프트웨어를 개발한 경험을 통해 **좋은 언어의 특징**을 정리 - 빠른 컴파일 속도, 단순한 런타임, 강한 정적 보장, 함수형 구성요소, 좋은 성능, 문서화 품질을 중요 요소로 제시 - **Haskell**은 함수형 프로그래밍의 사고방식을 익히게 했지만, **복잡한 문법과 느린 컴파일**이 문제로 지적됨 - 커뮤니티의 **복잡성 추구 경향**과 **space leak** 같은 런타임 문제로 인해 유지보수가 어려움 - **Go**는 단순성과 빠른 컴파일, 좋은 도구 체계, 간결한 코드 이해를 가능하게 함 - 그러나 **보수적인 설계**, **장황한 오류 처리**, **명시적 null 검사 부재**로 인해 버그 발생 가능성이 높고 불편함 - REPL 부재와 함수형 아이디어의 부정적 태도도 한계로 언급 ### OCaml의 주요 강점 - OCaml은 위의 기준을 대부분 충족하는 언어로 평가됨 - **강한 정적 보장**: 합타입, 다형 변이, 패턴 매칭 지원 - **단순한 런타임**: 가비지 컬렉션을 사용하면서도 시스템 수준 언어로 동작 - **빠른 컴파일 속도**: Dune 빌드 시스템을 통해 Haskell이나 Rust보다 빠름 - **정적 링크된 단일 바이너리 생성**으로 배포 용이 - **우수한 문서화 도구**: odig(오프라인 문서 탐색), utop(REPL), 인터페이스·구현 파일 분리 구조 - **자동 타입 추론** 기능으로 코드 작성 효율 향상 - 인터페이스 파일에 타입을 정의하는 구조가 명확한 코드 탐색에 도움 ### 언어 설계와 인상 - OCaml은 오래된 언어이지만 **세련된 설계 감각**을 유지 - 일부 **객체지향 기능**이나 복잡한 라이브러리는 불필요하다고 평가 - 전체적으로 **단순성과 표현력의 균형**, **좋은 문서화와 도구 생태계**가 OCaml의 핵심 매력 - 작성자는 “**단순하지만 표현력 있는 언어**”로서 OCaml을 높이 평가하며, 다른 언어에서 찾기 어려운 만족감을 언급 ## Comments ### Comment 46074 - Author: neo - Created: 2025-11-08T17:33:28+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45846517) - OCaml을 조금 써봤는데 여러 문제가 있었음 **Windows 지원이 형편없음**, OCaml 5로 와서야 “꽤 나빠진 정도”로 개선됨 문법은 사람이 읽기 어렵고, 구문 오류가 나면 한 글자만 잘못 넣어도 1000줄짜리 에러가 뜸 **Ocamlfmt**는 복잡한 `match`문도 한 줄로 만들어버려 가독성이 떨어짐 문서도 지나치게 간결하고 예제가 거의 없음 **OPAM**은 이론상 좋아 보이지만 실제로는 버그가 많고, 32개 이상의 Unix 그룹에 속하면 `curl`을 못 찾는 버그도 있었음 함수 시그니처의 타입 주석이 선택 사항이라 정적 타이핑의 장점이 줄어듦 생태계도 작고, 파일 복사조차 내장 함수가 없음 단일 연결 리스트에 집착하는 것도 비효율적임 그래도 C나 Python보다는 낫지만, **Rust**보다는 선택하지 않을 것 같음 - Windows에서 OCaml을 쓰려면 차라리 **F#** 을 추천함 CLR을 타깃으로 하기에 배포가 훨씬 쉽고, **.NET 생태계**를 그대로 활용할 수 있음 C#이나 VB.NET용 NuGet 라이브러리를 거의 그대로 쓸 수 있어 생태계가 방대함 F# 문서는 훨씬 풍부하고 예제도 많음 참고 링크: [F# 언어 레퍼런스](https://learn.microsoft.com/en-gb/dotnet/fsharp/language-reference/), [F# Core Docs](https://fsharp.github.io/fsharp-core-docs/), [F# Cheatsheet](https://fsprojects.github.io/fsharp-cheatsheet/fsharp-cheatsheet.pdf) - OPAM의 `curl` 버그가 실제로 있나 싶어 찾아봤는데, [이슈 #5373](https://github.com/ocaml/opam/issues/5373)에서 확인함 실제로는 **musl** 관련 문제이고, OPAM이 그 바이너리로 빌드되어 생긴 현상임 - 대부분은 학습 곡선 문제지만, 익숙해져도 **생태계 단절**은 여전함 `ocamlformat`은 **janestreet 프로필**로 설정하면 기본값이 훨씬 나음 함수 시그니처 타입 주석 문제는 `.mli` 파일을 제공하면 해결되지만, 대부분 그렇게 하지 않음 대신 **VS Code용 OCaml 플러그인**이 초보자에게는 최고의 경험을 줌 - 단일 연결 리스트 집착 얘기에 공감함 요즘 하드웨어에서는 기본 컬렉션이 **vector**여야 하지 않나 생각함 - Windows 지원이 나쁘다는 점에 전적으로 동의함 예전에는 ocaml.org에서 바로 설치조차 불가능했고, mingw나 wsl을 거쳐야 했음 그래서 사실상 Windows용 OCaml이 없었던 셈임 - Go 언어 설계자들이 함수형 프로그래밍의 아이디어를 거의 받아들이지 않은 이유는 명확함 **Rob Pike**의 말처럼, Google의 개발자들은 대부분 젊고 C 계열 언어에 익숙한 사람들이라 **쉽게 배울 수 있는 언어**가 필요했음 함수형 언어의 사고방식 전환에는 시간이 많이 들기 때문에 Go는 그 비용을 피하려 했음 - 실제로 **Go 팀의 결정**에 불만을 가진 Googler도 많음 - “ML”이라는 단어를 볼 때마다 아직도 가슴이 두근했다가, **Meta Language**가 아니라 **Machine Learning**임을 깨닫고 실망함 - ML은 Meta Language, LLM은 [Languages and Logic Montreal](https://llm.uqam.ca) 연구 그룹을 의미함 - 차라리 그런 혼동이 낫다고 생각함 요즘 “AI”라는 단어가 남용되는 게 더 싫음 진짜 **AGI**가 나오기 전까지는 AI라는 말을 쓰지 말았으면 함 - 1980년대 후반 80286 머신에서 ML을 처음 써봤을 때 정말 충격적이었음 - 예전에 비슷한 글을 올렸다가 **다운보트**를 잔뜩 받았는데, 이번엔 반응이 좋아서 반가움 - **Richard Feldman**의 [강연](https://www.youtube.com/watch?v=QyJZzq0v7Z4)을 보면 함수형 언어가 대중화되지 못한 이유가 잘 설명됨 플랫폼 독점 언어이거나, 킬러 앱이 있거나, 막대한 마케팅 자금이 있어야 함 Python이 급성장한 이유도 **AI 생태계의 중심 언어**가 되었기 때문임 나도 OCaml로 함수형을 배우고, Haskell과 Zig로 프로젝트를 해봤지만, 결국 “**쓸 수 있는 도구를 쓴다**”는 현실로 돌아오게 됨 OCaml, Rust, Haskell은 “배우고 싶어 하는 언어”로는 인기가 있지만, “실제로 널리 쓰이는 언어”는 아님 - Python의 인기가 AI 때문이라는 주장에는 동의하지 않음 **Torch는 원래 Lua 기반**이었고, 이미 인기가 높던 Python으로 옮겨간 것임 - 함수형 프로그래밍이 주류가 되지 못한 이유는 **엘리트주의적 태도** 때문이라고 생각함 FP 진영은 현실의 기술 변화에 무관심했고, 그 사이 **C, Pascal, Perl, Tcl** 같은 언어들이 시장을 차지했음 결국 FP는 “성당 안의 사제들”로 남았고, 명령형 언어가 대중을 얻었음 - F#을 써봤는데, **Actor 기반 동시성**이 이해하기 쉬웠음 다만 **mutable Array**가 등장하면 복잡해졌음 OCaml을 F#보다 실무에서 선호할 이유가 궁금함 - F#은 **CLR 변화**로 인해 호환성이 점점 떨어지고, 컴파일러도 느리고 툴링이 불안정함 반면 OCaml은 **글로벌 락 제거**, 빠른 컴파일, **모듈·GADT·이펙트** 같은 강력한 기능을 갖춤 F#은 여전히 Windows 지원과 SIMD, 언박싱 타입에서 우위지만, OCaml도 점점 따라잡는 중임 - F#의 .NET 통합은 양날의 검임 라이브러리는 많지만 대부분 **F#스럽지 않음** OCaml은 **네이티브 생태계**가 더 큼 - 회사에서 F#로 연산 집약적인 부분을 개발했는데, C#과의 상호 운용성은 좋지만, **C#에서 F# 라이브러리를 쓰는 건 악몽**이었음 결국 C# 셸을 유지하게 되고, 코드베이스가 혼종이 됨 .NET 생태계는 풍부하지만 **OOP 중심 사고**가 강해 FP 스타일과 충돌함 Visual Studio는 편하지만 CLI 기반 워크플로에는 불편함 컴파일 속도는 점점 느려지고, 테스트도 어색함 OCaml을 써보니 언어 **인체공학적 설계**가 훨씬 자연스러움 - OCaml은 **functor, 모듈 1급 값, GADT, 객체 시스템** 등 F#보다 훨씬 강력함 F#은 “OCaml for .NET”이라 불리지만, 실제로는 **ML 계열 언어일 뿐** 거의 다른 언어임 - OCaml이 오래된 언어라 OOP 기능은 빼도 될 것 같지만, **Standard ML**이 더 완벽하다고 생각함 - 나도 SML을 좋아하지만, OCaml의 **객체 시스템**은 과소평가받고 있음 **구조적 타입 레코드**나 **open recursion**, `Js_of_ocaml` 같은 JS 바인딩에 유용함 - SML로 컴파일러를 작성 중인데, **int/real 오버로딩**이나 **value restriction** 같은 이상한 제약이 있음 레코드 업데이트도 지원하지 않아 불편함 - 예전엔 SML을 더 좋아했지만, 당시엔 “O가 붙은 언어”가 유행이라 OCaml이 주목받았음 - OCaml은 2000년대 초부터 늘 “거의 완벽한 언어”였음 하지만 **마찰 요소**가 해결될 즈음엔 이미 다른 언어들이 그 아이디어를 흡수함 - OCaml은 **Velvet Underground** 같은 언어임 배우는 사람은 적지만, 배운 사람마다 새로운 언어를 만듦 [출처](https://quoteinvestigator.com/2016/03/01/velvet/) - 그럼에도 불구하고 OCaml은 **수십억 달러 규모의 거래 시스템**을 실제로 운영 중임 - “마찰”이 뭔지 모르겠음 이미 많은 프로젝트가 OCaml로 잘 돌아가고 있고, **이펙트 시스템**까지 추가되어 오히려 더 앞서가고 있음 - 인기와 실력은 다름 **인기 ≠ 우수함**, 음악에서도 마찬가지임 트렌드와 관성에 의해 결정될 뿐임 - 인기와 호감도는 오히려 **역상관** 관계임 많이 쓰이는 언어일수록 싫어하는 사람도 많고, 생소한 언어일수록 과대평가되기 쉬움 - 음악의 “좋음”은 주관적이지만, 언어의 “좋음”은 **문제 해결 효율성**으로 객관화 가능함 OCaml이 덜 인기인 이유는 그 효율을 체감하는 **사용자층이 작기 때문**임 그리고 FP 진영의 **교조적 태도**도 한몫함 - **Elixir**는 OCaml과 비슷하면서도 대중화 가능성이 있는 언어라고 생각함 **불변성, 패턴 매칭, Actor 모델** 등 FP의 장점을 갖추고, **BEAM 런타임** 위에서 안정적으로 동작함 정적 타이핑은 없지만 점진적 타입 검사를 도입 중임 - 사실 더 궁금한 건 왜 **F#이 더 인기가 없는가**임 .NET 생태계를 그대로 쓸 수 있는데도 OCaml보다 덜 알려져 있음 - Elixir는 **생태계와 툴링이 훌륭**하고, 문법도 Erlang보다 친숙함 실제로 SaaS 백엔드에 쓰는 회사도 많음 - 하지만 대부분의 조직은 **함수형 패러다임(재귀 중심)** 을 부담스러워함 그래서 FP 언어는 여전히 비주류임 - 개인적으로는 OCaml보다 Elixir가 **두뇌 부담이 적고 유연함** - **Gleam**도 흥미롭지만, **컴파일되지 않는 언어**는 내 작업에는 맞지 않음 - OCaml은 **GC 기반 시스템 언어**라는 점에서 Go와 비슷함 수동 메모리 관리나 **borrow checking**보다 GC를 선호함 D 언어의 GC도 훌륭했지만, “GC”라는 단어 자체가 사람들을 겁먹게 했던 게 문제였음