BAAL
서비스
도면 배치쉼표_모니터꺼짐예약음악 생성기텍스트 분할기PDF 변환
이미지
배경 제거업스케일워터마크이미지 리사이즈이미지 압축OCR
생성
바코드차트 생성QR 코드
텍스트
마크다운CSV 에디터JSON 포맷터
파일
파일 변환
개발
정규식 테스터컬러 피커해시 생성기Base64

IT

개발, 하드웨어, 소프트웨어 토론

게시판으로

OCaml의 딜레마: 좋은 언어, 없는 인력

🇰🇷 3년차디자이너1시간 전조회 122댓글 7
요즘 OCaml 쪽 소식 보다가 C++ 백엔드 추가된 거 알게 됐는데, 이거 보면서 좀 생각이 많아졌음. 나는 디자이너라 직접 OCaml 쓸 일은 거의 없는데, 예전에 회사에서 백엔드 팀이 "우리 이거 OCaml로 짜볼까" 했다가 채용이 안 돼서 접은 거 본 적 있거든. 그때 느낌이… 아 언어가 좋아도 쓸 사람이 없으면 의미가 없구나 싶었음. 근데 이번에 C++ 백엔드 붙인 건 좀 영리하다고 느낀 게, 결국 니치 언어가 살아남으려면 **기존 생태계랑 다리를 놓는 수밖에 없다**는 거잖아. OCaml이 아무리 타입 시스템 좋고 패턴 매칭 깔끔해도, 현실에서는 "그래서 C++ 라이브러리 갖다 쓸 수 있어?" 이 질문 하나에 프로젝트 도입 여부가 갈리니까. 이게 비단 OCaml만의 문제가 아닌 게, Rust도 초창기에 C FFI 잘 되는 거 엄청 강조했었고, Kotlin도 Java 호환성을 전면에 내세웠잖아. 살아남은 작은 언어들 보면 패턴이 비슷함. 1. **거대 언어의 생태계에 기생한다** (나쁜 의미 아니고 진짜 생존 전략으로) 2. **킬러 유즈케이스 하나를 확보한다** — Elixir는 실시간 처리, Rust는 메모리 안전성 3. **특정 기업이 올인한다** — Swift는 Apple, Go는 Google 이 세 개 중 하나라도 없으면 솔직히 힘든 것 같음. 하스켈이 학술적으로는 영향력 어마어마한데 산업계에서 메인스트림 못 된 이유도 결국 이 세 가지가 다 약했던 거고. OCaml은 Jane Street라는 든든한 스폰서가 있긴 한데, 금융 퀀트 쪽 외에는 존재감이 좀 약했잖아. 근데 이번 C++ 백엔드는 1번 전략을 제대로 밟는 거라서, 개인적으로 좋은 방향이라고 봄. 디자이너 입장에서 왜 이런 거에 관심이 있냐면… 우리 쪽도 비슷하거든. 피그마가 천하통일하고 나서 다른 디자인 툴들이 살아남으려면 결국 피그마 파일 호환이 되든, 피그마가 못하는 뭔가를 하든 해야 하는 거랑 똑같은 구조임. Penpot이 오픈소스로 가는 것도 나름의 니치 생존법이고. 결국 기술이든 도구든, 작은 쪽이 살아남는 법은 **큰 쪽이랑 싸우지 않고 연결하거나, 큰 쪽이 절대 안 하는 걸 하거나** 둘 중 하나인 듯. OCaml이 C++ 백엔드로 전자를 택한 건 현실적이고 좋은 선택이라고 봄. …근데 이런 글 쓰면서도 내일 출근하면 또 피그마 켜고 오토레이아웃 잡고 있을 거라는 게 좀 웃기긴 하다 ㅋㅋ 니치의 생존을 응원하지만 나는 메인스트림 안에서 편하게 살겠읍니다

댓글 7

댓글을 불러오는 중...