docs Unison | 💡 큰 생각 · Unison 프로그래밍 언어

여기 Unison의 큰 생각이 있습니다. 그리고 그것이 가져오는 여러 가지 이점을 함께 설명하겠습니다:

🧠

각 Unison 정의는 해당 구문 트리의 해시(hash) 로 식별됩니다.

다시 말해, Unison 코드는 콘텐츠 주소 방식(content-addressed)입니다.

예를 들어, Nat 타입에 대한 increment 함수가 있습니다:

unison
increment : Nat -> Nat
increment n = n + 1

이 함수에 사람이 읽을 수 있는 이름을 붙였고 (increment), 함수 Nat.+ 역시 사람이 읽을 수 있는 이름을 갖고 있지만, 이름은 단지 따로 저장되는 메타데이터일 뿐이며 함수의 해시에 아무런 영향을 주지 않습니다. Unison이 해시를 계산할 때 사용하는 increment의 구문 트리는 대략 다음과 같습니다:

text
increment = (#arg1 -> #a8s6df921a8 #arg1 1)

즉, 모든 이름 붙은 인자는 위치 기반으로 번호가 매겨진 변수 참조로 대체되고, 모든 의존성(이 예에서는 Nat.+ 함수)은 그 정의의 해시로 대체됩니다. 따라서 increment의 해시는 그 정확한 구현을 고유하게 식별하고, 그 모든 의존성까지 완전히 고정(pinned down)합니다.

비유를 들면: 각 Unison 정의는 거대한 불변 주소 공간 안에서 고유하고 결정적인 주소(그 해시)를 갖습니다. 이름은 이 공간 안의 주소를 가리키는 포인터와 같습니다. 우리는 어떤 이름이 어떤 주소를 가리키는지는 바꿀 수 있지만, 각 주소의 내용은 영원히 변하지 않습니다.

이점

이러한 출발점은 놀라운 이점을 제공합니다. 분산 프로그래밍을 단순하게 만들고, 빌드와 의존성 충돌을 없애며, 타입이 있는 내구성 있는 저장소를 지원하고, 구조적 리팩터링을 가능하게 하고, 코드를 다루는 더 나은 도구들을 가능하게 하는 등, 그 외에도 많은 장점이 있습니다.

🌟

이것은 단순한 이론이나 추측이 아닙니다. 우리는 누구나 Unison 코드를 작성하고 배포할 수 있도록 이러한 이점을 실제로 활용하는 Unison Cloud Platform을 만들었습니다.

이제 각 이점이 어떻게 나오는지 차례대로 살펴보겠습니다.

분산 프로그래밍 단순화

현재의 프로그래밍 언어들은 대체로 “프로그램은 단일 컴퓨터의 단일 OS 프로세스가 무엇을 하는지를 기술하는 것”이라는 개념을 기반으로 합니다. 프로그램 경계 밖의 것과 상호작용할 때는, 예를 들어 소켓을 통해 바이트를 전송하는 식으로 매우 간접적으로만 할 수 있습니다. 어떤 계산을 “그냥” 다른 곳에서 실행할 수는 없고, 네트워크를 통해 바이트를 보내야 하며, 그 반대편에서는 별도의 프로그램이 실행 중이어서 그 바이트를 수신하고 역직렬화한 후, 여러분이 원하는 계산을 실행해 주기를 (어떻게든) 보장해야 합니다.

이 기존 패러다임에서는 분산 계산이 하나의 프로그램이 아니라, 수많은 별도 프로그램들이 뒤엉킨 글루 코드, 덕트 테이프, YAML 파일, 그리고 네트워크를 오가는 JSON 덩어리들로 이어 붙여져서 표현됩니다.

또한, 여러분이 관심 있는 전체 계산을 수행하도록 모든 컴퓨팅 자원을 설정하는 것도 복잡한 일입니다. 전체적으로 그 자원들이 원하는 계산을 수행하도록 협력하게 만드는 것은 더더욱 어렵습니다. 이 과정에서 프로그래밍 언어가 제공하는 여러 가지 편의 기능도 전혀 누리지 못합니다. 단일 머신을 대상으로 프로그램을 작성할 때에는, 일반적으로 타입체커가 있어서 모든 조각이 서로 잘 맞는지 도와주고, 여러분은 원하는 방식으로 추상화를 하고, 재사용 가능한 컴포넌트를 도입하는 등 다양한 일을 할 수 있습니다. 그러나 여러 컴퓨터가 함께 유용한 일을 하도록 만드는 레이어를 구성할 때에는 이러한 지원이 눈에 띄게 부족합니다.

Unison에서는 정의가 콘텐츠 해시로 식별되기 때문에, 임의의 계산을 한 위치에서 다른 위치로 그냥 옮겨갈 수 있고, 필요한 의존성이 없다면 그때그때 배포할 수 있습니다. 기본 프로토콜은 대략 다음과 같습니다. 전송자는 바이트코드 트리를 수신자에게 보내고, 수신자는 그 바이트코드를 살펴보며 자신에게 없는 해시가 있는지 확인합니다. 필요한 모든 해시를 이미 갖고 있다면 계산을 곧바로 실행할 수 있고, 그렇지 않으면 부족한 것들을 요청하고, 전송자는 그것들을 즉석에서 동기화해 줍니다. 이렇게 받은 것들은 다음 번을 위해 캐시됩니다.

이렇게 임의의 계산을 옮길 수 있는 능력은, 기존의 더 제한적인 개념들인 코드 배포, 원격 프로시저 호출(RPC) 등을 포괄(subsume)하며, 강력한 분산 컴퓨팅 컴포넌트를 평범한 Unison 라이브러리로 구축할 수 있게 해 줍니다.

프로그램을 “그냥” 실행하기만 하면, 그 프로그램이 전체 분산 시스템을 기술할 수 있으면서도 사전에 아무런 설정을 하지 않아도 된다는 점은 굉장히 해방감을 줍니다. 코드가 실행되기 전에, 필요한 코드를 실행할 준비를 컴퓨팅 자원에게 시키기 위해(컨테이너를 빌드하고, 컨테이너 이미지나 jar 파일을 어딘가에 업로드하고, 기타 등등) 온갖 “바깥(band 밖)” 작업을 할 필요가 없습니다. Unison의 분산 컴퓨팅 모델에서는 그냥 코드를 실행하기만 하면 되고, 부족한 의존성은 그때그때 동기화하면 됩니다.

물론 분산 프로그래밍은 여전히 어려울 수 있으며, 분산 프로그램은 순차적인 단일 머신 프로그램과는 다릅니다. 하지만 분산 프로그래밍이 불필요하게 지루하고 고통스러울 필요는 없습니다. 분산 프로그램에서 정말 중요한 것들에 시간을 쓰고, 배포와 설정, 값을 옮기기 위한 지루한 인코딩/디코딩 작업에는 시간을 낭비하지 맙시다!

빌드 없음

Unison에서는 코드를 빌드하느라 기다리는 경우가 거의 없습니다. 왜 그럴까요?

Unison 정의는 해시로 식별되므로, 한 번 정의된 뒤에는 절대 변하지 않습니다. 어떤 이름이 어떤 해시와 연결되는지를 바꾸는 일(이것은 Unison의 리팩터링 및 코드 진화 방식에 사용됩니다)은 할 수 있지만, 특정 해시에 연결된 정의 자체는 바뀌지 않습니다.

따라서 정의들을 한 번 파싱하고 타입체킹한 뒤, 그 결과를 절대 무효화되지 않는 캐시에 저장할 수 있습니다. 게다가 이 캐시는 IDE나 빌드 도구 안에 존재하는 어떤 임시 상태(가끔 이상하게 일관성이 깨져 버리는 종류의 것)가 아니라, Unison 코드베이스 포맷의 일부입니다. 누군가가 한 번 정의를 파싱하고 타입체킹하여 코드베이스에 추가해 두었다면, 그 작업을 다른 누구도 다시 할 필요가 없습니다.

이 아이디어는 순수 계산(pure computation)에 대한 테스트 결과 캐시에도 그대로 적용할 수 있습니다. I/O를 사용하지 않는 결정론적인 테스트라면, 그 어떤 의존성도 바뀌지 않았다면 다시 실행할 이유가 없습니다!

이렇게 전반적으로 캐시를 활용함으로써, 여러분은 코드를 작성하는 데 시간을 쓰고, 컴파일러를 기다리는 데 시간을 낭비하지 않게 됩니다.

의존성 충돌 없음

의존성 충돌은 근본적으로 서로 다른 정의들이 동일한 이름을 “두고 경쟁”하기 때문에 발생합니다. 그런데 왜 우리가 두 다른 정의가 같은 이름을 사용하는 것에 신경을 써야 할까요? 실제로는 그럴 필요가 없습니다. 이런 제약은 정의를 이름으로 참조하기 때문일 뿐입니다. Unison에서는 정의를 해시로 참조하고(이름은 그저 따로 저장되는 메타데이터일 뿐입니다), 따라서 의존성 충돌과 다이아몬드 의존성 문제는 애초에 생기지 않습니다.

우리가 지금 “의존성 충돌”이라고 부르는 상황은, Unison에서는 그저 비슷한 목적을 가진 여러 개의 항(term)이나 타입이 존재하는 상황일 뿐입니다. 예를 들어 Email 타입이 있다고 해 봅시다. 하나는 Alice의 라이브러리 v1에서 온 것이고, 다른 하나는 (아마도 다른 라이브러리를 통해 전이적으로 포함된) Alice의 라이브러리 v2에서 온 것일 수 있습니다. 우리는 이런 의존성 “충돌” 때문에 빌드가 “망가졌기” 때문에 모든 일을 멈추고 이 문제를 해결해야 한다고 여겨 왔습니다. 그러나 Unison에서는 코드베이스 안에 서로 다른 두 개의 Email 타입이 떠다니고 있는 것은 전혀 문제가 되지 않습니다. 이 둘은 서로 다른 해시를 가진 서로 다른 타입으로 존재하며, 여러분은 이 둘을 동시에 다룰 수 있고, 심지어 평범한 함수들을 작성하여 한쪽에서 다른 쪽으로 변환하는 것도 가능합니다.

물론 시간이 지나면서 여러분은 코드베이스 안에 있는 두 Email 타입을 하나로 통합하고 싶을 수 있습니다. 하지만 이건 여러분이 원할 때 천천히 할 수 있는 일입니다. 그동안 코드베이스가 “망가진 상태”가 되지 않으며, 이 충돌이 해결될 때까지 코드를 실행하지도 못하고 아무 것도 못 하는 상황에 빠지지도 않습니다.

“같은” 함수나 타입의 여러 버전이 코드베이스 안에 떠다니는 것은, 사실 코드베이스 안에 생길 수 있는 다른 종류의 중복과 크게 다르지 않습니다. 예를 들어, 나중에 보니 어떤 공통 추상화로 정의할 수 있을 법한 비슷한 함수들이 여러 개 있는 상황과 비슷합니다. 적절한 시기가 되면 그런 중복을 정리해서 하나로 모으겠지만, 이런 자연스러운 과정이 늘 다른 모든 작업보다 최우선이 되어야 할 필요는 없습니다.

타입이 있는, 내구성 있는 저장소

값을 영구적으로 저장하는 데에는 두 가지 측면이 있습니다. 하나는 흥미로운 부분입니다. 즉, 대량의 데이터를 다루기 위해 어떤 스키마나 데이터 구조를 사용해야, 특정 질의나 계산이 효율적으로 동작할지를 고민하는 것입니다.

다른 하나는 흥미롭지 않은 부분입니다. 프로그램과 그 아래 저장소 계층(SQL, NoSQL 또는 그 외 어떤 것이든) 사이의 경계에서, 직렬화와 역직렬화를 처리하는 모든 지루한 작업들입니다.

Unison에서는 어떤 값이든(함수나, 함수를 포함하는 값까지도) 프로그래머가 직렬화 포맷을 직접 지정하거나 인코더/디코더를 작성하지 않고도 영속화(persist)하고 나중에 다시 복원(unpersist)할 수 있습니다.

사람들이 종종 수동으로 인코딩/디코딩 계층을 작성하는 이유 중 하나는, 시점 0에서 데이터를 직렬화하는 코드베이스와, 수개월 혹은 수년 후에 그 데이터를 역직렬화하는 코드베이스가 서로 다를 수 있다고 가정하기 때문입니다. 새로운 코드베이스가 다른 버전의 라이브러리를 사용하고 있다면 어떻게 될까요? 그러면 데이터를 다시 읽어 올 수 없게 될 것입니다! 따라서 저장 경계를 기준으로 SQL의 행, JSON 블롭 등과 같은 안정적인 포맷으로 변환하기 위한 지루한 코드를 양쪽에 작성해야 한다고 생각합니다.

콘텐츠 해시로 식별되는 정의를 직렬화하면 이러한 어려움을 피할 수 있습니다. 정의는 절대 변하지 않으며, 역직렬화를 하면 언제나 처음 직렬화했을 때와 동일한 의미를 가진 값을 얻게 됩니다.

더 나아가 이 아이디어를 통해 저장 계층 자체를 타입이 있도록 만들 수 있습니다. 이때의 타입 시스템은 여러분의 프로그램이 알지 못하는 별도의 타입 시스템(SQL에 있는 것처럼)이 아니라, 여러분의 Unison 프로그램의 일부입니다. 즉, 프로그램이 어떤 값을 영속화하면, 저장 계층에 대한 타입이 붙은 참조(typed reference)를 얻게 되고, Unison의 타입 시스템은 그 참조를 다시 로드할 때 기대한 타입의 값을 받게 될 것임을 보장해 줍니다.

Unison으로 분산 저장소 계층을 작성하는 방법에 대한 글도 곧 다룰 예정입니다.

더 풍부한 코드베이스 도구

Unison 코드베이스는 자신이 저장하는 모든 것의 타입을 알고 있고, 완벽한 컴파일 캐시를 가지고 있으며, 의존성에 대한 완전한 지식을 가지고 있고, 타입 기반 검색을 위한 인덱스 등을 갖춘, 제대로 된 데이터베이스입니다. 이 덕분에 코드를 둘러보고 상호작용하기 위한 훨씬 더 풍부한 도구를 손쉽게 만들 수 있습니다. 예를 들어, Unison Share는 생태계에 있는 라이브러리들을 완전히 하이퍼링크된 Unison 코드 형태로 둘러볼 수 있게 해주며, 하이퍼링크가 달린 내장 코드 샘플을 포함하는 풍부한 문서도 렌더링합니다.

코드베이스를 이렇게 더 구조화된 방식으로 저장하면, 이런 기능들을 지원하는 것이 훨씬 간단해집니다. Unison Share의 첫 버전은 Unison 코드베이스 API에 이미 존재하는 풍부한 정보를 활용하여, 한 사람이 몇 달 만에 작성했습니다.

코드는 근본적으로 구조화된 정보입니다. 우리는 편의상 코드를 텍스트로 편집하지만, 사실 코드를 가지고 하고 싶은 거의 모든 일은 이를 더 구조화된 형태로 변환한 뒤에 하는 편이 더 낫습니다.

간단한 예를 하나 살펴봅시다. 정의 이름 바꾸기(rename) 입니다. 코드가 가변 텍스트 파일들의 묶음으로 표현되어 있을 때, 정의를 정확하게 이름 바꾸기 위해서는 먼저 그 텍스트 파일들을, 언어의 스코프 규칙을 따르며 의존성이 명시적으로 드러나는 구문 트리로 변환해야 합니다. 이렇게 해야 구문 트리의 어떤 부분이 이름을 바꾸려는 대상을 참조하는지, 그리고 어떤 부분은 단지 같은 문자열을 포함하고 있지만 실제로는 다른 것(예를 들어 로컬 변수)에 바인딩되어 있거나, 문자열 리터럴이나 주석 안에 들어 있는 것인지를 구분할 수 있습니다.

이름 바꾸기가 끝난 뒤에는, 수정된 구문 트리를 다시 텍스트로 직렬화해야 하며, 이 과정에서 거대한 텍스트 diff가 생성되고, 다른 개발자들과 동시에 코드를 작업하고 있다면 수많은 충돌이 생길 수 있습니다. 더군다나, 이름 바꾸기가 공개된 라이브러리 안의 정의에 대해 이루어졌다면, 다운스트림 사용자들은 라이브러리를 업그레이드하는 순간 코드베이스가 망가진 상태가 되어 버릴 것입니다. 이거 좀 우스꽝스럽지 않나요?

또 다른 예를 들어 보겠습니다. 빌드 도구와 IDE의 일시적인 컴파일 캐시입니다. 이런 도구들은 텍스트 코드를 더 풍부한 형태로 처리하여 캐시하려고 하고, 코드를 불필요하게 재컴파일하지 않으려 매우 노력하지만, 기본 텍스트 파일이 도구의 눈앞에서 계속 바뀌어 버리기 때문에 이 작업은 매우 어렵습니다.

Unison은 코드베이스를 제대로 된 “코드 데이터베이스”로 표현함으로써 이러한 어려움의 상당 부분을 피해 갑니다. 여러분은 여전히 선호하는 텍스트 편집기로 코드를 작성하고 편집하지만, 코드가 코드베이스로 “흡수(slurp)”되는 순간, 잘 가공된 형태로 저장되며, 이 덕분에 깨지지 않는 즉각적인 이름 바꾸기, 타입 기반 검색, 하이퍼링크된 코드 등 다양한 이점을 얻게 됩니다. 그리고 어떤 정의든 한 명령만으로(예쁘게 pretty-print 되고, 정의에 대해 최신 이름을 사용한 채로) 다시 텍스트 버퍼에 가져와 쉽게 편집할 수 있습니다.

한편으로, 텍스트 파일과 텍스트 기반 도구들은 이미 거대한 생태계를 가지고 있고, 사람들도 익숙합니다. 하지만 코드를 저장하는 형식으로서 텍스트를 사용하는 것은, 코드베이스를 더 구조화된 방식으로 표현했을 때 Unison이 “공짜로” 얻는 엄청난 이점들을 놓치게 만듭니다. 그리고 우리는 아직 이 가능성의 표면만 긁어 본 상태입니다. Unison의 코드 작업 도구들은 앞으로도 계속 좋아질 것이고, 텍스트 기반 코드베이스로는 구현하기 어렵거나 불가능한 전혀 새로운 가능성들이 열릴 것입니다.

구조적 리팩터링

Unison의 근본 모델에서는 정의 자체는 절대 변하지 않지만, 사람이 읽을 수 있는 이름이 어떤 정의(어떤 해시)를 가리키는지는 때때로 바꾸고 싶을 수 있습니다. 버그를 고쳐야 하거나, 성능을 개선해야 하거나, 단순히 기존 이름을 새로운 정의에 재사용하고 싶을 수 있기 때문입니다.

Unison에서는 어떤 이름이 어떤 해시에 매핑되는지를 바꾸는 작업을, 일반적인 “텍스트 파일을 제자리에서 바꾸고, 산더미 같은 오해를 불러일으키는 컴파일 에러와 실패한 테스트를 나중에 고치는” 방식이 아니라, 구조적 리팩터링 세션을 통해 수행합니다. Unison 코드베이스는 리팩터링 도중에도 결코 망가진 상태가 되지 않습니다.

여러분의 코드베이스가 마치 초고층 빌딩 같다고 해 봅시다. 일반적인 리팩터링 방식은 기초가 되는 기둥 하나를 뽑아 내는 것과 비슷합니다. 그러면 빌딩은 무너져 폐허(긴 목록의 오해를 부르는 컴파일 에러)로 변하고, 여러분은 그 폐허 속에서 다시 제대로 서 있는 빌딩을 재건하려고 애써야 합니다.

Unison의 접근법은 기존 빌딩을 그대로 두고, 마법의 복제 도구를 사용해 그 일부를 새로운 빌딩으로 복사해 오는 것입니다. 코드베이스는 결코 망가진 상태가 되지 않습니다. 모든 코드는 언제나 실행 가능합니다. 다만 리팩터링 도중에는 아직 두 번째 빌딩을 완전히 다 지어 이름을 모두 옮겨 놓지는 않았을 수 있습니다. Unison은 이 진행 상황을 추적하며, 여러분이 처리해야 할 깔끔한 할 일 목록(todo list)을 제공합니다.

결론

콘텐츠 주소 방식 코드(content-addressed code)라는 아이디어와 함께 시간을 오래 보내다 보면, 이 개념이 점점 머릿속을 사로잡기 시작합니다. 이건 어떤 임의적이거나 이상한 것이 아니라, 엄청난 실용적 이점을 가진 논리적이고 합리적인 선택입니다. 이 아이디어의 단순함을 점점 더 높이 평가하게 되고, 어디에서나 이 개념이 필요해 보이기 시작합니다(“코드가 콘텐츠 주소 방식이었다면 이건 훨씬 쉬웠을 텐데…”). 그런데 이 아이디어를 중심으로 프로그래밍 언어를 실제로 만드는 것이 과연 현실적일까요? 네, 그렇습니다!

Unison을 만드는 즐거움의 일부는, 훌륭해 보이는 이 핵심 아이디어의 함의를 끝까지 따라가 보는 데 있었습니다. 그 과정에서 큰 질문이 하나 나왔습니다. 정의 자체는 변하지 않더라도, 우리는 때때로 관심 있는 정의를 바꾸고 그 정의에 보기 좋은 이름을 붙이고 싶어 합니다. 그렇다면 그건 어떻게 작동해야 할까요? 어떻게 리팩터링을 하거나 코드를 업그레이드할 수 있을까요? 코드베이스는 여전히 단지 가변 텍스트 파일들의 묶음일까요, 아니면 다른 무언가가 필요할까요?

콘텐츠 주소 방식 코드를 편하게 다루려면, 실제로 다른 무언가가 필요합니다. Unison에서는 이 무언가를 Unison 코드베이스 매니저(Unison Codebase Manager) 라고 부릅니다.

다음으로 어디로 갈까요?

🌟 코드베이스 매니저와 Unison 언어 둘러보기

🌟 Unison은 어떤 문제를 해결하나요?

📚 Unison 관련 발표 영상 보기