# 언어 설계를 멈추고, 대신 라이브러리를 작성하라 > Clean Markdown view of GeekNews topic #25671. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25671](https://news.hada.io/topic?id=25671) - GeekNews Markdown: [https://news.hada.io/topic/25671.md](https://news.hada.io/topic/25671.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-09T07:33:16+09:00 - Updated: 2026-01-09T07:33:16+09:00 - Original source: [lbstanza.org](https://lbstanza.org/purpose_of_programming_languages.html) - Points: 1 - Comments: 1 ## Topic Body - 프로그래밍 생산성의 핵심은 **언어 자체보다 풍부한 라이브러리 생태계**에 있음 - Ruby on Rails처럼 **언어의 고급 기능을 활용한 프레임워크**가 비전문가에게도 높은 생산성을 제공 - 그러나 **언어의 구조적 한계** 때문에 Rails 수준의 프레임워크를 Java나 C로는 구현하기 어려움 - **언어 설계는 작성 가능한 라이브러리의 형태와 복잡도를 직접 결정**하며, 이는 언어 발전의 본질적 목적 - **Stanza 언어**는 이러한 관점에서, 강력하고 사용하기 쉬운 라이브러리 생성을 가능하게 하는 언어 설계의 중요성을 보여줌 --- ### 프로그래밍 언어와 라이브러리의 관계 - 대부분의 프로그래밍 언어는 변수, 배열, 반복문, 함수 등 유사한 기본 요소를 가짐 - 일부 언어는 **일급 함수**나 **코루틴** 같은 고급 기능을 제공하지만, 비전문가들은 이를 잘 사용하지 않음 - 많은 개발자에게 생산성을 높이는 요인은 **언어보다 라이브러리**임 - 예로, Ruby on Rails는 데이터베이스 기반 웹 애플리케이션을 손쉽게 구축할 수 있게 함 - Rails 덕분에 Ruby 언어 자체보다 **프레임워크에 대한 선호**가 높음 ### Ruby on Rails와 언어 기능의 상호작용 - Rails는 Ruby의 **메타프로그래밍**, **런타임 평가**, **일급 함수**, **가비지 컬렉션** 등 다양한 기능을 활용 - 예: ActiveRecords는 메타프로그래밍을, 템플릿 시스템은 런타임 평가를 사용 - 이벤트 처리는 일급 함수를 콜백으로 전달하는 방식으로 구현 - Java나 C에서는 이러한 기능이 부족해 **Rails 수준의 프레임워크 구현이 불가능** - Java의 메타프로그래밍은 ActiveRecords를 구현할 만큼 강력하지 않음 - 따라서 Rails는 Ruby 언어의 구조 덕분에 가능하며, **언어 설계가 라이브러리 가능성을 결정** ### 언어 설계가 라이브러리 형태를 결정 - C 언어는 함수 선언과 호출만으로 재사용을 지원하므로, 대부분의 C 라이브러리는 **함수 집합 형태** - Ruby는 일급 함수를 지원해 “버튼 클릭 시 실행할 동작”을 간결하게 표현 가능 - 반면 Java에서는 **핸들러 클래스**를 정의해야 하므로 코드가 복잡해짐 - 언어의 표현력은 **라이브러리의 구조와 사용성**을 직접적으로 규정 ### 상호작용형 소프트웨어와 확장 가능한 프레임워크의 등장 - 1970년대의 배치형 컴퓨팅에서는 함수 중심의 라이브러리로 충분했음 - 현대의 상호작용형 소프트웨어에서는 **확장 가능한 라이브러리**가 필요 - GUI나 이벤트 기반 시스템에서 “사용자 클릭 시 내 코드를 실행”하는 구조 요구 - Java와 C++은 **상속과 메서드 오버라이딩**으로 확장을 지원하며, 이러한 구조가 **프레임워크**로 발전 ### Stanza 설계의 배경과 언어 한계 - Stanza의 설계 동기는 Java에서 **사용하기 쉬운 게임 프로그래밍 라이브러리 작성의 어려움**에서 출발 - Java에서는 동시성을 상태 기계(state machine)로 표현해야 했음 - Scheme은 **continuation**을 지원해 더 직관적인 구현 가능 - 그러나 Scheme은 정적 타입 검사를 지원하지 않아 **디버깅 효율이 낮음** - 현재 대부분의 언어는 **타입 시스템을 라이브러리로 확장**할 수 없음 - Stanza는 **선택적 타입 시스템**, **가비지 컬렉션**, **멀티메서드 기반 객체 시스템**을 제공 - 하지만 사용자 정의 객체 시스템을 새로 작성할 수는 없음 ### 언어의 목적과 연구 방향 - 범용 프로그래밍 언어의 목적은 **강력하고 사용하기 쉬운 라이브러리 생성 지원** - 언어가 강력할수록 라이브러리 사용이 간결해짐 - 코드가 잘 설계된 라이브러리를 사용할 때는 **동료에게 지시하는 문장처럼 읽히는 자연스러움**을 가짐 - Racket, Shen, 메타 객체 프로토콜 연구 등은 **확장 가능한 타입·객체 시스템**을 탐구 중 - 궁극적으로 언어는 “**어떤 라이브러리를 쓸 수 있고, 쓸 수 없는가**”로 구분됨 - 우아한 라이브러리 뒤에는 **수십 년의 언어 연구와 설계 노력**이 존재함 ## Comments ### Comment 48918 - Author: neo - Created: 2026-01-09T07:33:16+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46525640) - 가장 좋은 예는 **Prolog**임. 흔히 논리 프로그래밍의 대표 언어로 불리지만, 사실상 여러 **알고리즘의 모음**에 불과하며, 각 언어의 라이브러리로 구현될 수 있음. Prolog의 문법적 표현만 각 언어의 문법에 맞게 제공하면 충분하다고 생각함 - Prolog의 핵심은 알고리즘이 아니라 **논리 규칙을 선언적으로 표현**하는 방식임. 예를 들어 “조부모는 부모의 부모”라는 규칙을 정의하면, 이를 통해 조부모를 찾거나 역으로 부모 관계를 추론할 수도 있음. 이런 **양방향 추론**이 Prolog의 매력임. 물론 일반 언어로 이런 기능을 흉내 내려면 부작용 없는 코드와 제한된 DSL이 필요함. CUDA를 Python에서 돌리는 PyTorch나 TensorFlow처럼 언어 간 호출도 가능하니, 언어에 종속되지 않는 구조도 충분히 가능하다고 봄 - Prolog의 문법은 **1차 논리(First Order Logic)** 의 부분집합으로, 변수는 값이 할당되지 않고 가능한 값의 집합 위에서 조건을 만족할 때까지 탐색함. Prolog 엔진은 단순한 라이브러리 호출 이상의 일을 함 — 예를 들어 **해 공간 압축 표현**, 병렬 실행, 자동 가지치기 등이 있음. 그래서 보통은 Prolog를 백엔드 서비스로 두거나 코드 생성 방식으로 통합함. Prolog는 **계획, 제약 해결, 정리 증명, 조합 테스트, 가격 모델링** 등에서 특히 강력함. 그래서 Prolog를 단순히 “라이브러리로 충분한 언어”라 보기엔 무리가 있다고 생각함 - 같은 논리로 보면, 객체지향 기능도 클로저로 흉내낼 수 있으니 언어에 굳이 필요 없다고 할 수도 있음. 하지만 **명확한 문법이 주는 표현력**이 주는 장점이 있음 - Prolog 같은 관계형 프로그래밍을 라이브러리로 구현하려면 언어가 **심볼과 변수 조작을 일급 객체로 지원**해야 함. Lisp류 언어가 그나마 가능하지만, 일반 언어에서는 사용성이 크게 떨어짐. Bob Harper와 얘기했을 때 그는 “그냥 새 언어를 만들어라”라고 했는데, 그 말이 꽤 설득력 있었음 - Prolog를 배우고 싶은데, 입문 튜토리얼과 고급 예제 사이의 **중간 수준 자료**를 찾기 어려움. Sudoku 변형 퍼즐을 Prolog로 풀어보려 하는데, 기존 예제는 너무 최적화되어 있어서 일반화된 관계 정의를 배우기 힘듦. 특히 일부 규칙이 틀릴 수도 있는 상황을 모델링하는 법이 궁금함. 참고로 [SWI-Prolog의 Sudoku 예제](https://www.swi-prolog.org/pldoc/man?section=clpfd-sudoku)를 보고 있음 - 10년 전엔 **Scala** 팬이었음. 타입 시스템 안에서 DSL을 만들 수 있다는 “Scalable Language” 개념이 매력적이었음. 하지만 커뮤니티가 JVM 위의 Haskell처럼 쓰기 시작하면서 흥미를 잃었음. 요즘은 **WASM**이나 **Graal** 같은 기술이 언어 선택의 유연성을 높여줄 것 같아 기대 중임. JS로 충분한 경우가 많지만, 필요할 때 **Rust** 같은 저수준 언어를 쓸 수 있는 선택지가 생긴 게 좋음 - 나도 Scala의 가장 큰 문제는 **DSL 남용**이라고 생각함. 언어 자체뿐 아니라 테스트 프레임워크 등에서 또 다른 언어를 배워야 하는 느낌임. 물론 Hadoop MapReduce를 한 줄로 표현할 수 있는 건 인상적이었지만, 대부분의 업무엔 과함. 게다가 Scala 개발자들은 “지루한 코드”를 쓰기 싫어함. 멋을 부리려다 유지보수 지옥을 남기고 떠나는 경우를 많이 봤음 - Scala 커뮤니티 전체가 Haskell 지향적인 건 아님. 일부 **타입 마법사들**이 그런 경향을 보일 뿐임. Scala는 단순히 “더 나은 Java”로 써도 충분히 훌륭함. 함수형의 장점을 부담 없이 누릴 수 있음 - Haskell은 원래 **DSL 제작용 언어**로 자주 쓰임. Meta의 Haxl이나 음악용 DSL인 TidalCycles가 좋은 예임. 다만 고차 타입 기반 라이브러리들은 성능 저하가 심하고, 불필요하게 복잡함 - 혹시 **Clojure(Script)** 를 써봤는지? Lisp 계열답게 문제에 맞춰 언어를 확장하는 **bottom-up 프로그래밍**이 가능함. Paul Graham의 [On Lisp](https://www.paulgraham.com/onlisptext.html)에서도 이런 접근을 강조함. 관련 강연 [Bottom Up vs Top Down Design in Clojure](https://www.contalks.com/talks/1692/bottom-up-vs-top-down-design-in-clojure-clojure-conj-2015)도 추천함 - 나는 최근 Scala를 배우기 시작했는데, **함수형 프로그래밍** 측면에서도 정말 마음에 듦. DSL 제작 외에도 다양한 방식으로 쓸 수 있을 만큼 범용적이라 생각함. 혹시 Scala에 부족한 점이 있다고 느끼는지 궁금함 - **타입이 있는 스크립트 언어**로 bash를 대체할 수 있으면 좋겠음. Elixir로 간단한 JSON 파서 스크립트를 만들어봤는데 꽤 괜찮았음 - **Nushell**을 써봤는지? 예전엔 “진짜 언어”를 써야 했던 작업을 한 줄로 처리할 수 있음. 예를 들어 파일 목록을 정렬하고 JSON으로 출력하는 파이프라인을 간단히 작성할 수 있음 - 사실 **shebang**을 이용하면 여러 언어로 스크립트를 작성할 수 있음. 예를 들어 [C#](https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/), [Java](https://dev.to/toliyansky/scripting-with-java-3i9k), [Go](https://golangcookbook.com/chapters/running/shebang/) 모두 가능함. [Scriptisto](https://github.com/igor-petruk/scriptisto)를 쓰면 거의 모든 언어로 shebang 스크립트를 만들 수 있음 - **OCaml**도 스크립트처럼 쓸 수 있음. `#!/usr/bin/env ocaml`로 바로 실행 가능함. 다만 단일 파일에서 외부 의존성을 자동 설치하는 기능은 없음 - Go에서도 shebang을 흉내내는 [트릭](https://lorentz.app/blog-item.html?id=go-shebang)이 있음. 관련 토론은 [여기](https://news.ycombinator.com/item?id=46431028) 참고 - 일상 스크립팅엔 **Python**이나 **PowerShell**도 좋은 선택임 - 언어와 라이브러리는 **서로 배타적이지 않음**. 어떤 라이브러리는 사실상 언어처럼 작동하고, 반대로 언어가 특정 라이브러리를 위해 설계되기도 함. 예를 들어 **Julia**는 성능과 사용성의 균형을 잘 잡은 사례임. 고성능 코드를 Julia로 직접 작성하고, **JIT 수준의 타입 특화 컴파일**로 최적화된 실행을 얻을 수 있음. 단순한 함수 호출 모델이지만, 내부적으로는 매우 정교하게 동작함 - 맞음, 결국 **언어와 라이브러리 둘 다 필요**하다는 게 핵심 요지였음 - **Raku**는 여러 하위 언어(slang)를 엮은 구조로 설계되어 있음. 예를 들어 정규식, PEG, quoting 등을 각각의 미니언어로 다루고, [Slangify](https://raku.land/zef:lizmat/Slangify)를 이용해 자신만의 DSL을 쉽게 추가할 수 있음 - 하지만 개인적으로는 **타입이 변수 이름 뒤에 오는 문법**이 마음에 들지 않아 Raku는 선호하지 않음 - 예전에 한 시니어 개발자가 “이력서에 Rails가 보이면 바로 버린다”고 말했음. 언어로 사람을 평가하는 건 **얼마나 어리석은 일인지** 새삼 느꼈음 - **Rails의 부상과 J2EE의 쇠퇴**가 동시에 일어난 건 우연이 아님. Rails는 단순하고 의견이 명확한 백엔드 코드를 보여줬고, 그 영향으로 DropWizard, Javalin, Spring Boot 같은 Java 프레임워크들이 등장했음 - 그 시니어의 기술 스택이 궁금함 - 그런 동료의 쓰레기통을 내가 수거하고 싶을 정도임. 좋은 Rails 개발자는 찾기 힘듦. 나도 **RoR 경험**이 있고 여전히 좋아함 - 물론 Java 개발자를 찾는 입장이라면 Rails 이력서를 거르는 게 효율적일 수도 있음 - 사람을 평가하는 기준은 결국 **조직의 문화적 적합성**과 **협업 스타일**에 따라 달라짐. 완벽한 필터링 방법은 없음 - 언어나 라이브러리는 결국 **기계와 사람 모두와의 소통 수단**임. 기계는 비트와 전압으로, 사람은 **의도와 개념**으로 소통함. 따라서 언어나 라이브러리가 사람에게 명확하고 빠른 표현 수단을 제공한다면, 그것이 언어인지 라이브러리인지는 중요하지 않음. **Rails든 Stanza든**, 목적에 맞고 팀이 이해하기 쉬우면 그게 정답임 - 나는 “라이브러리가 곧 최종 언어”라고 생각함. 예를 들어 **Ruby on Rails**는 Ruby를 기반으로 한 훌륭한 웹 서비스 언어임. Ruby와 Rails는 서로를 위해 진화했음. 결국 **프로그래밍은 언어의 연속적인 번역 과정**이라고 봄 - **C#과 ASP.NET Core**도 비슷하게 함께 발전했음. 사용자 친화적 문법과 시스템 수준의 최적화가 동시에 이루어졌음 - “언어가 강력할수록 라이브러리 사용이 쉬워진다”는 말이 맞음. 예전 Java로는 **Express** 같은 프레임워크를 만들기 어려웠음 - Express가 뭔지 모르겠지만, Java는 **라이브러리 활용성** 덕분에 기업용 언어로 자리 잡았다고 생각함 - C#의 **ASP.NET Core minimal API**는 Express를 거의 그대로 구현한 사례임. 언어와 프레임워크가 함께 발전해야 가능함 - Java에서도 [Javalin](https://javalin.io) 같은 Express 유사 프레임워크가 있음. 문제는 **커뮤니티가 단순함을 원하지 않는다**는 점임 - C 언어용 웹 프레임워크라면 **PHP**가 있지 않겠음? ;) - 그건 **라이브러리 개념을 너무 확장한 농담** 같음