▲

Unison 1.0 릴리즈

 (unison-lang.org)
5P by GN⁺ 14시간전 | ★ favorite | 댓글 1개
  • Unison은 코드 정의를 이름이 아니라 내용(Hash) 으로 식별하는 구조를 기반으로, 코드 저장·버전 관리·배포 방식 전체를 새롭게 구성한 함수형 프로그래밍 언어
  • 모든 코드는 텍스트 파일이 아닌 코드베이스(DB) 에 저장되며, 이름은 단순한 라벨로 취급되어 동일 이름/파일 충돌·리팩터링 충돌 같은 문제가 구조적으로 사라지는 형태
  • UCM(Unison Codebase Manager)을 통해 정의 추가·삭제·이동·이름 변경·테스트·실행이 이뤄지며, LSP·UCM Desktop·Unison Share와 연결된 협업 도구 생태계가 제공됨
  • Abilities 기반의 효과 시스템, 지연 계산, 구조적 패턴 매칭 등 언어 기능과 더불어, 동일 프로그램 안에서 애플리케이션 로직과 클라우드 배포(Cloud/BYOC) 를 함께 정의하는 통합 모델로 확장됨
  • 해시 기반 구조 덕분에 중복 컴파일 제거·버전 충돌 감소·정적 참조 탐색 등이 기본 특성이 되며, Share·Cloud·Projects·Branch 시스템을 포함한 일관된 분산 개발 경험을 제공함

Unison 언어 개요

  • 내용 기반 식별(content-addressable code) 구조로 정의를 관리해, 동일한 이름이라도 내용이 다르면 완전히 별개의 정의로 취급됨
    • 재컴파일 불필요, API 진화 충돌 최소화, 완전한 참조 안정성
  • 코드베이스는 SQLite 기반 DB 로 유지되며 코드·이름·문서가 모두 데이터로 저장됨
    • ls, view 같은 UCM 명령으로 구조 탐색
  • 텍스트 파일은 편집을 위한 인터페이스일 뿐, 실제 소스의 단일 진실은 DB
    • 이름 충돌·파일 병합 충돌·리포 구조 관리는 전부 구식 개념으로 축소됨

언어 기능

  • Abilities: IO, Exception 등의 효과를 타입 시스템으로 제어하는 기능
  • 구조적 패턴 매칭: 타입을 구조적으로 분해해 제어 흐름 구성
  • 지연 계산(Delayed computations): 비엄격 평가를 명시적으로 표현
  • 강한 정적 타입 + 풍부한 타입 유추 + Kind-checking 제공

개발 환경 및 툴체인

  • UCM (Unison Codebase Manager)
    • 정의 생성·삭제·이름 변경·테스트·실행
    • 프로젝트·브랜치·클론·머지 등 Git 유사 버전 관리를 언어에 내장
  • UCM Desktop
    • 코드베이스 구조 탐색, 클릭 기반 정의 이동, 문서 렌더링
  • LSP 지원
    • 인기 있는 에디터 대부분에서 IDE 기능 사용 가능
  • Unison Share
    • 중앙 코드 허브: 프로젝트 호스팅, 검색, 리뷰, 기여(=Pull Request), 타입 기반 검색
    • 모든 정의가 hash 기반이기 때문에 참조는 항상 하이퍼링크처럼 이동 가능

배포 모델: Unison Cloud & BYOC

  • 같은 언어로 애플리케이션 로직 + 인프라 정의까지 작성하고, 이를 곧바로 배포
  • YAML, Helm, 복잡한 RPC 규약 없이 “코드”만으로 분산 시스템 구성
  • BYOC(Bring Your Own Cloud)로 자체 컨테이너 인프라 위에서도 Cloud 스택 실행 가능
  • OrderedTable 등 타입 안전 저장소, Daemon 지원, 자동 오케스트레이션 포함

예시: Guessing Game

  • Abilities(IO, Exception)를 활용한 단순한 CLI 예제
  • Random, console IO, 패턴 매칭, 지연 계산 등 언어 요소가 자연스럽게 결합된 형태

생태계 및 커뮤니티

  • Share를 통한 기여·리뷰·조직 계정 지원
  • 타입 기반 전체 에코시스템 검색, AI 에이전트를 위한 MCP 서버 제공
  • 점진적으로 C FFI 작업 진행 중
  • Git-style diff 뷰어, 브랜치 주석 등 협업 생산성 기능 확장

주요 역사(요약)

  • 2018: Unison Computing 설립
  • 2019: 첫 알파 릴리즈
  • 2021: 코드베이스를 SQLite로 전환 (100x 축소)
  • 2021: Unison Share 공개
  • 2022~2024: LSP, Projects, Kind-checking, Pull Request, Cloud GA
  • 2025: Desktop App, 대규모 런타임 최적화, MCP 서버, BYOC 지원
  • 2025 Nov: Unison 1.0 정식 릴리즈

FAQ

  • 왜 새로운 언어인가?
    • 해시 기반 코드 모델은 기존 언어에 애드온 형태로 이식하기 불가능에 가까움
    • 코드 저장·버전 관리·배포·협업 방식이 모두 이 아이디어에서 자연스럽게 파생되기 때문에, 처음부터 새 언어로 설계할 필요가 있었음
  • 실제 사용 사례?
    • Unison Cloud 전체가 Unison 자체로 작성되어 운영 중
    • 조직·팀 단위 협업과 분산 애플리케이션 개발을 위한 상용 수준 워크플로 구성
  • 벤더 종속성 우려: 오픈소스 언어로, Docker 등으로 자유롭게 배포 가능하며 BYOC 지원
  • 협업 방식: 조직, 티켓, 코드 리뷰, PR 등 지원하며, 정의 단위 충돌만 발생
  • 버전 관리: Git 없이 자체 프로젝트·브랜치·푸시·풀·머지 기능 제공
  • IDE 제약 없음: LSP 서버 제공으로 다양한 에디터 사용 가능
  • 타 언어 연동: C FFI 개발 중
  • 파일 없는 코드베이스 접근: CLI(UCM) 명령 또는 Desktop 앱으로 구조 탐색 가능
▲
GN⁺ 14시간전  [-]
Hacker News 의견

  • 나는 Unison을 아주 오래전부터 지켜봐 왔음. Paul의 개인 블로그 시절부터니까 벌써 10년이 넘었음. 이번 1.0 릴리스는 정말 큰 이정표지만, 솔직히 약간 실망스러움
    프로그래밍 언어를 정말 좋아해서 Rust, Go, Zig 같은 언어들의 성장도 다 봐왔는데, Unison은 이 정도의 완성도에 비해 생태계 확산력이 부족하다고 느낌
    그 이유는 대부분의 기능이 클라우드 종속적으로 설계된 비즈니스 모델 때문이라고 생각함. BYOC 옵션이 있긴 하지만 충분하지 않음. 뭔가 분위기가 맞지 않음

    • Zig, Rust, Go와 비교하는 건 동의하지 않음. Unison은 Abilities나 데이터베이스 기반 코드 구조 같은 “새롭고 이상한” 개념을 너무 빨리 소진함
      Share 프로젝트는 오픈소스이고, GitHub도 실질적 종속성이 있음에도 여전히 인기 있음.
      이런 점을 부정하려는 건 아니고, 사람들이 직접 써보고 다른 언어 설계에도 도움이 될 부분을 느껴봤으면 함
    • Unison의 문제는 FFI 부재라고 생각함. 오히려 비즈니스에 집중하는 건 좋은 전략임. 돈을 벌어야 사용자에게 중요한 기능에 집중할 수 있고, 사소한 논쟁에 빠지지 않게 됨
    • 나도 동의함. 인터넷이 끊겨도 로컬 협업이 가능한 시스템을 만들고 싶은데, 해시 기반 함수 구조가 그에 딱 맞음.
      하지만 학습 자료 대부분이 클라우드 인프라 사용을 전제로 하고 있어서, 오프라인 환경에서는 길이 막혀 있음.
      아마 Unison식 접근이 있을지도 모르지만, 마케팅 레이어가 그 길을 가리고 있음
    • 상업적 방향이 있는 게 오히려 반가움. 잘만 하면 더 많은 시간을 투입해 지속 가능한 발전이 가능해짐.
      유료 사용자가 생기면 기술이 현실적이고 실용적으로 유지될 동기가 생김.
      상업적 요소가 없었다면 그냥 또 하나의 esolang으로 느껴졌을 것임. 이제 사이드 프로젝트에서 써볼 생각임
    • 핵심 아이디어는 멋지지만, 코드 배포나 가져오기가 클라우드 플랫폼을 통해서만 가능하다면 사용하지 않을 것 같음.
      문서에 Unison Share가 언급되어 있는데, 이것도 unison-lang.org에서 호스팅됨.
      BYOC 옵션이 있긴 하지만 여전히 unison.cloud 계정과 구독이 필요함. 이런 부분은 마케팅과 문서에서 명확히 밝혀줬으면 함

  • 안녕하세요, 저는 Unison 언어의 공동 제작자 중 한 명임. 궁금한 점이 있으면 무엇이든 물어봐도 됨

    • 오랫동안 Unison을 지켜봤는데, 릴리스 축하함!
      Unison은 algebraic effects (Abilities) 를 주요 기능으로 내세운 최초의 언어 중 하나임.
      초기에 이 기능이 잘 받아들여질지 확신이 없었던 걸로 기억하는데, 지금은 만족스러운지 궁금함.
      효과 시스템이 언어의 다른 부분과 잘 어우러지는지, 문법은 마음에 드는지, 내부 구현에 대한 흥미로운 이야기도 듣고 싶음
      관련 문서: Unison Abilities
    • 테스트 실행 결과를 캐싱할 때 실제로 어떤 데이터를 저장하는지 궁금함.
      표현식의 해시와 “passed” 값만 저장하는지, 아니면 모든 값의 해시를 계산할 수 있는지도 알고 싶음.
      만약 후자라면 Nix나 Trustix처럼 재현 가능한 빌드를 확장할 수 있을 것 같음.
      아마 현재 캐싱은 바인딩된 표현식만 다루겠지만, 런타임에서 외부 세계와 연결하는 다리 역할을 할 수도 있을 것 같음
    • 릴리스 축하함! Unison의 해시 기반 정의 개념은 정말 혁신적임.
      다만 지금은 문제를 찾는 솔루션처럼 느껴짐.
      이 언어는 누구를 대상으로 하고, Unison Cloud 외에 실제 프로덕션에서 사용하는 곳이 있는지도 궁금함
    • 정말 멋진 프로젝트임. 하지만 content-addressed language 개념이 아직 완전히 이해되진 않음.
      처음엔 BEAM 기반 언어인 줄 알았는데, 자체 VM 위에서 동작함.
      BEAM 언어와 비교했을 때 fault tolerance 측면에서 어떤 차이가 있는지, 그리고 Unison이 더 잘 맞는 사용 사례가 무엇인지 궁금함
    • OrderedTable, Table 같은 지속성 프리미티브가 내부적으로 어떻게 구현되어 있는지 궁금함.
      외부 데이터베이스를 호출하는지, 아니면 Unison 자체로 구현된 건지 알고 싶음.
      Database 추상화와 함께 보면 정말 흥미로운 조합인데, 개념을 완전히 이해하기가 쉽지 않음

  • 나는 Unison을 가장 흥미로운 언어 중 하나로 생각함.
    algebraic effects는 다음 세대의 핵심 개념이 될 거라고 믿음.
    Unison은 이 외에도 멋진 아이디어가 많음.
    개인적으로는 게임 모드 개발에도 적합할 것 같음.
    신뢰할 수 없는 코드를 클라이언트에서 실행해야 하는데, Unison의 ability 시스템 덕분에 샌드박스 환경을 쉽게 만들 수 있을 것 같음.
    또한 ECS(Entity Component System) 구현에도 유용할 수 있음.
    함수가 필요로 하는 능력을 추론할 수 있다면, 병렬 실행 안전성을 자동으로 확보할 수 있을 것임

    • 실제로 Unison Cloud에서 이런 샌드박스 검증을 하고 있음.
      Cloud에서는 IO ability를 직접 사용할 수 없고, 대신 안전하게 제어된 Http ability 같은 것만 허용함.
      이렇게 하면 사용자가 파일 시스템에 접근할 수 없게 됨.
      나도 게임 개발에 이 기능을 활용하는 걸 구상 중임.
      다른 사용자가 native service로 ability를 구현해 게임에 기여할 수도 있음.
      참고 링크: Unison Cloud, validateSandboxed 코드, ECS 예제

  • 이 프로젝트를 처음 봤을 때 “5년 뒤에 어떻게 될까”라고 생각했는데, 진짜로 그만큼 시간이 흘렀음.
    이제 1.0 릴리스를 보게 되어 정말 기쁨

  • 이런 급진적인 언어를 실제 산업 환경에서도 쓸 수 있게 만든 건 대단한 성취임. 축하함

  • 나는 Unison 같은 시스템이 컴퓨팅의 미래라고 생각함.
    하지만 그 미래가 언제 올지는 모르겠음.
    이런 시스템의 아름다움은 인프라, 데이터, 서비스 계층이 하나의 통합된 시스템 안에 있다는 점임.
    어쩌면 AI 코딩 에이전트에게 더 좋은 기반이 될 수도 있음.
    다만 VC 모델보다는 지속 가능한 독립적 개발이 더 어울린다고 생각함.
    이런 장기적인 프로젝트를 계속 이어가는 팀이 정말 멋짐

  • Rúnar가 Unison을 시작한다고 했던 날이 기억남.
    완전히 새로운 패러다임을 여는 프로젝트라고 생각했고, 지금 1.0 릴리스를 보니 정말 자랑스러움.
    언젠가 Unison이 내 주력 언어가 되길 바람

  • Unison 웹사이트에 벤치마크가 있었으면 좋겠음.
    성능 특성을 알아야 어떤 용도에 적합한지 감이 옴.
    Django, Express.js, ASP.NET과의 요청 처리 속도 비교 같은 간단한 수치라도 있으면 좋겠음.
    아이디어는 흥미롭지만, 웹 외의 런타임 타깃도 생기길 바람.
    개인적으로는 대형 웹 프로젝트보다 CLI 도구 같은 곳에서 새로운 언어를 시도하기 쉬움

  • 2023년에 올라온 Unison 리뷰 글을 참고했는데, 꽤 도움이 됐음

  • 아이디어는 흥미롭지만, Unison은 언어 + 소스 관리 + 호스팅을 한꺼번에 도입해야 하는 올인원 구조임.
    스택 중 하나라도 마음에 안 들면 전체를 쓰기 어려움.
    그래서 이런 아이디어들이 직접적으로는 널리 퍼지기 힘들 것 같음

    • Unison은 점진적으로 도입할 수 있음.
      언어 자체의 툴링 품질이 매우 높고, 기존 시스템과의 통합도 가능함.
      예를 들어 Unison Cloud는 대부분 Unison으로 작성되었지만 일부는 Haskell을 사용함.
      관련 논의: HN 스레드1, HN 스레드2
      여러 기술을 유기적으로 설계해 함께 잘 작동하게 만드는 데 큰 가치가 있다고 생각함
    • 상업적 성공 여부보다는, 이 프로젝트가 보여주는 컴퓨터 과학적 연구 가치 자체가 더 흥미로운 평가 기준이라고 생각함
답변달기