Unison 문서 | 💡 큰 아이디어 · Unison 프로그래밍 언어

URL: https://www.unison-lang.org/docs/the-big-idea/#simplifying-distributed-programming

Title: docs Unison | 💡 The big idea · Unison programming language

아래는 Unison의 큰 아이디어이며, 그에 따른 이점 일부를 함께 설명합니다:

🧠

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

다르게 말하면, Unison 코드는 콘텐츠 기반 주소 지정(content-addressed)입니다.

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

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

우리는 이 함수에 사람이 읽을 수 있는 이름을 붙였고(함수 Nat.+ 역시 사람이 읽을 수 있는 이름을 가집니다), 이름은 함수의 해시에 영향을 주지 않는 별도로 저장된 메타데이터일 뿐입니다. Unison이 해시하는 increment의 구문 트리는 대략 다음과 같이 생겼습니다:

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

즉, 모든 이름 있는 인자는 위치로 번호가 매겨진 변수 참조로 대체되고, 모든 의존성(이 경우 Nat.+ 함수)은 해시로 대체됩니다. 따라서 increment의 해시는 그 정확한 구현을 유일하게 식별하고, 모든 의존성까지 확정(pinning)합니다.

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

Benefits

이 출발점은 놀라운 이점들을 제공합니다. 분산 프로그래밍을 단순화하고, 빌드와 의존성 충돌을 제거하며, 타입이 있는 내구성 저장소를 지원하고, 구조화된 리팩터링을 가능하게 하며, 코드 작업을 위한 더 나은 도구를 제공하는 등 훨씬 더 많은 것들을 가능하게 합니다.

🌟

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

이제 각 이점이 어떻게 나타나는지 살펴봅시다.

분산 프로그래밍 단순화

오늘날의 프로그래밍 언어는 일반적으로 “프로그램은 단일 컴퓨터의 단일 OS 프로세스가 하는 일을 기술하는 것”이라는 생각을 중심으로 설계되어 있습니다. 프로그램 경계 밖의 것들과 상호작용하려면 예를 들어 소켓으로 바이트를 보내는 식으로 매우 간접적으로 해야 합니다. 어딘가 다른 곳에서 계산을 “그냥” 실행할 수 없고, 네트워크로 바이트를 보낸 다음, (어떻게든?) 반대편에서 그 바이트를 받아 역직렬화하고, 바라건대 원하는 계산을 실행해 줄 별도의 프로그램이 떠 있고 듣고(listening) 있어야 합니다.

이 기존 패러다임에서는 분산 계산이 하나의 프로그램으로 기술되지 않습니다. 대신 수많은 개별 프로그램을 온갖 글루(glue), 덕트 테이프(duct tape), YAML 파일, 그리고 네트워크로 전송되는 JSON 덩어리로 꿰맞춰야 합니다.

게다가, 전체적으로 당신이 원하는 전체 계산을 실행하도록 컴퓨팅 자원들을 설정하는 일은 복잡합니다. 그리고 그 과정에서 프로그래밍 언어가 제공하는 온갖 편의(도움)를 전혀 못 받습니다. 한 대의 머신을 대상으로 프로그래밍할 때는 보통 타입체커가 있어 모든 조각이 잘 맞는지 확인해 주고, 원하는 방식으로 추상화하거나 재사용 가능한 컴포넌트를 도입하는 등의 일을 할 수 있습니다. 하지만 여러 컴퓨터가 함께 유용한 일을 하도록 만들기 위해 필요한 올바른 레이어를 조립하는 데에는 이런 지원이 눈에 띄게 부족합니다.

Unison에서는 정의가 콘텐츠 해시로 식별되기 때문에, 임의의 계산을 한 위치에서 다른 위치로 그냥 옮길 수 있고, 누락된 의존성은 즉석에서 배포될 수 있습니다. 기본 프로토콜은 대략 이렇습니다: 송신자가 바이트코드 트리를 수신자에게 보내면, 수신자는 바이트코드를 검사하여 자신에게 없는 해시가 있는지 확인합니다. 필요한 모든 해시를 이미 갖고 있다면 계산을 실행할 수 있고, 아니라면 누락된 것들을 요청하고 송신자가 즉석에서 동기화(sync)해 줍니다. 이들은 다음을 위해 캐시됩니다.

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

전체 분산 시스템을 기술하는 프로그램을 “그냥” 실행하기 전에 사전 준비를 하지 않아도 된다는 건 해방감이 있습니다. 필요한 코드를 실행할 수 있도록 컴퓨팅 자원들이 준비되어 있게 만들기 위해(컨테이너를 빌드하거나, 컨테이너 이미지나 jar 파일을 어딘가에 업로드하거나 등등) “대역 외(out of band)”로 많은 일을 해야 하는 대신, Unison의 분산 컴퓨팅 모델에서는 그저 코드를 실행하면 되고, 빠진 의존성은 즉석에서 동기화될 수 있습니다.

물론 분산 프로그래밍은 여전히 어려울 수 있고, 분산 프로그램은 순차적(single-machine) 프로그램과는 다릅니다. 하지만 분산 프로그래밍이 불필요하게 지루하고 번거로워서는 안 됩니다. 배포, 설정, 값과 계산을 옮기기 위한 지루한 인코딩/디코딩에 시간을 쓰지 말고, 분산 프로그램에서 실제로 중요한 것들에 시간을 씁시다!

빌드 없음

Unison에서는 거의 코드 빌드를 기다릴 일이 없습니다. 왜 그럴까요?

Unison 정의는 해시로 식별되므로 결코 바뀌지 않기 때문입니다. 어떤 이름이 어떤 해시에 연결되는지는 바꿀 수 있고(이것이 Unison의 리팩터링 및 코드 진화 접근에 활용됩니다), 하지만 특정 해시에 연결된 정의 자체는 절대 바뀌지 않습니다.

따라서 우리는 정의를 한 번만 파싱하고 타입체크한 뒤, 그 결과를 절대 무효화되지 않는 캐시에 저장할 수 있습니다. 게다가 이 캐시는 IDE나 빌드 도구 안의 일시적인 상태(가끔 이유 없이 불일치해지는) 같은 것이 아니라, Unison 코드베이스 포맷의 일부입니다. 누군가 정의를 파싱하고 타입체크해서 코드베이스에 한 번 추가하면, 그 일을 다시 할 필요가 없습니다.

이 아이디어는 순수 계산에 대한 테스트 결과 캐싱에도 적용됩니다(I/O를 사용하지 않는 결정적 테스트). 의존성이 바뀌지 않았다면 결정적 테스트를 다시 실행할 필요가 없습니다!

이렇게 전방위로 적용되는 캐싱 덕분에, 컴파일러를 기다리기보다 코드를 작성하는 데 시간을 쓰게 됩니다.

의존성 충돌 없음

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

대신, 우리가 지금 “의존성 충돌”이라고 생각하는 것은 비슷한 목적을 수행하는 여러 용어(term)나 타입(type)이 존재하는 상황일 뿐입니다. 예를 들어 Email 타입을 생각해 봅시다. Alice 라이브러리 v1의 Email과 v2의 Email이 있을 수 있고(다른 라이브러리를 통해 전이적으로 포함될 수도 있음), 우리는 이런 의존성 “충돌” 때문에 “깨진” 빌드를 고치느라 모든 것을 멈춰야 하는 데 익숙합니다. 하지만 Unison에서는 코드베이스 안에 두 개의 서로 다른 Email 타입이 떠다니고 있어도 전혀 문제가 없습니다. 이들은 서로 다른 해시를 가진 서로 다른 타입으로 존재하며, 둘을 동시에 다룰 수 있습니다(그리고 한쪽에서 다른 쪽으로 변환하는 평범한 함수도 작성할 수 있습니다).

물론 시간이 지나면서 코드베이스 안의 두 Email 타입을 하나로 통합하고 싶어질 수는 있습니다. 하지만 Unison에서는 코드베이스가 깨진 상태가 되어 아무 코드도 실행하지 못하는 상황이 아니라, 당신이 원할 때 여유 있게 통합할 수 있습니다.

“같은” 함수나 타입의 여러 버전이 코드베이스에 존재하는 것은, 코드베이스에서 흔히 생기는 다른 종류의 중복과 크게 다르지 않습니다. 예를 들어 비슷해 보이는 함수 몇 개가 사실 공통 추상화로 정의될 수 있다는 걸 알아차리는 경우처럼요. 때가 되면 그 중복을 정리해 통합하면 됩니다. 이런 자연스러운 과정이 항상 다른 모든 작업보다 무조건 우선해야 할 이유는 없습니다.

타입이 있는 내구성 저장소(typed, durable storage)

값을 영속적으로 저장하는 데에는 두 가지 측면이 있습니다. 하나는 흥미로운 부분입니다: 방대한 데이터 컬렉션에 대해 어떤 종류의 스키마나 데이터 구조를 써야 특정 쿼리나 계산이 효율적인가?

흥미롭지 않은 부분은, SQL이든 NoSQL이든 다른 무엇이든 프로그램과 저장소 계층 사이 경계에서 늘 다뤄야 하는 직렬화/역직렬화입니다.

Unison에서는 어떤 값이든(함수 자체나 함수를 포함하는 값까지도) 프로그래머가 직렬화 포맷을 수동으로 지정하거나 인코더/디코더를 작성하지 않고도 저장(persist)했다가 나중에 다시 불러올 수(unpersist) 있습니다.

사람들이 수동 인코딩/디코딩 레이어를 작성하는 이유 중 하나는, 시간 0에 직렬화를 수행하는 코드베이스와 수개월 또는 수년 후 역직렬화를 수행하는 코드베이스가 다를 수 있다고 가정하기 때문입니다. 새 코드베이스가 라이브러리의 다른 버전을 가진다면 데이터를 다시 읽을 수 없게 될지도 모릅니다! 그래서 영속성 경계 양쪽에 SQL의 행, JSON 블롭 같은 안정적인 포맷으로 변환하는 지루한 코드를 써야 한다고 생각합니다.

콘텐츠 해시로 식별되는 정의를 직렬화하면 이런 어려움을 피할 수 있습니다. 정의는 결코 바뀌지 않으며, 역직렬화는 처음 직렬화했을 때와 같은 의미를 가진 값을 언제나 돌려줍니다.

더 나아가, 이 아이디어는 저장소 계층을 타입 있게 만들 수 있게 해줍니다. SQL처럼 프로그램이 알지 못하는 별도의 타입 시스템이 아니라, Unison 프로그램의 일부로 타입을 갖게 됩니다. 즉, 프로그램이 저장한 값들은 저장소 계층에 대한 타입이 붙은 참조를 돌려주고, 그 참조를 로드할 때 기대한 타입의 값을 돌려받는다는 것을 Unison 타입 시스템이 보장합니다.

Unison으로 분산 저장소 계층을 작성하는 글을 곧 공개할 예정이니 기대해 주세요.

더 풍부한 코드베이스 도구

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

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

코드는 본질적으로 구조화된 정보입니다. 우리는 편의를 위해 텍스트로 코드를 편집하지만, 코드로 하고 싶은 거의 모든 일은 먼저 더 구조화된 형태로 변환하면 더 잘할 수 있습니다.

간단한 예를 봅시다: 정의 이름 바꾸기. 코드가 변경 가능한 텍스트 파일 묶음으로 표현될 때, 정의의 이름을 정확히 바꾸려면 먼저 그 텍스트 파일들을 언어의 스코프 규칙을 존중하고 의존성이 명시적으로 드러나는 구문 트리로 변환해야 합니다. 그러면 구문 트리의 어떤 부분이 이름을 바꾸려는 대상을 참조하는지, 그리고 어떤 부분은 그 부분 문자열을 포함하지만 다른 것에 바인딩되어 있는지(예: 로컬 변수), 또는 문자열 리터럴/주석 안인지 등을 판단할 수 있습니다.

이름 바꾸기가 끝나면 수정된 구문 트리를 다시 텍스트로 직렬화해야 하며, 그 과정에서 거대한 텍스트 diff가 생성되고, 다른 개발자들과 동시에 작업 중이라면 충돌도 많이 생길 수 있습니다. 더 나쁜 것은, 공개된 라이브러리의 정의에 대해 이름 바꾸기를 하면, 다운스트림 사용자들은 업그레이드할 때 코드베이스가 깨진 상태가 된다는 점입니다. 정말 어리석지 않나요?

또 다른 예로, 빌드 도구와 IDE의 일시적인 컴파일 캐시를 생각해 봅시다. 이 도구들은 불필요한 재컴파일을 피하려고 텍스트 코드를 더 풍부한 형태로 처리해 캐시하려고 엄청나게 노력하지만, 특히 기반이 되는 텍스트 파일이 계속 변경되기 때문에 이를 제대로 하기는 꽤 어렵습니다.

Unison은 코드베이스를 제대로 된 “코드의 데이터베이스”로 표현함으로써 이런 어려움의 상당 부분을 우회합니다. 당신은 여전히 좋아하는 텍스트 편집기로 코드를 편집하고 작성하지만, 코드가 코드베이스로 흡수(slurp)되면 잘 처리된 형태로 저장되어 즉시(non-breaking) 이름 바꾸기, 타입 기반 검색, 하이퍼링크된 코드 같은 이점을 제공합니다. 또한 어떤 정의든 한 번의 명령으로 텍스트 버퍼로 다시 가져올 수 있으며(보기 좋게 pretty-print되고, 정의에 대해 최신 이름을 사용), 쉽게 편집할 수 있습니다.

한편으로는 텍스트 파일과 텍스트 기반 도구는 이미 거대한 생태계를 갖고 있고 사람들이 익숙합니다. 하지만 코드를 저장하는 방식으로서의 텍스트는, Unison이 코드베이스를 더 구조화해 표현함으로써 “공짜로” 얻는 막대한 이점들에 비해 손해가 큽니다. 그리고 우리는 이제 겨우 표면을 긁고 있을 뿐입니다. Unison의 코드 작업 도구는 계속 더 좋아질 것이고, 텍스트 기반 코드베이스로는 어렵거나 불가능한 완전히 새로운 가능성이 열릴 것입니다.

구조화된 리팩터링

Unison의 기본 모델은 정의는 결코 바뀌지 않는다는 것이지만, 사람이 읽을 수 있는 이름이 어떤 정의(해시)에 매핑되는지는 때때로 바꾸고 싶습니다. 버그를 고치거나, 성능을 개선하거나, 기존 이름을 새로운 정의로 재사용하고 싶을 수 있습니다.

Unison에서는 이름이 어떤 해시에 매핑되는지를 바꾸는 일을, 텍스트 파일을 제자리에서(mutating in place) 수정한 다음 오해를 부르는 컴파일 에러와 실패한 테스트의 긴 목록을 고치는 전형적인 방식이 아니라, 구조화된 리팩터링 세션으로 수행합니다. Unison 코드베이스는 리팩터링 도중에도 결코 깨진 상태가 되지 않습니다.

코드베이스가 마치 마천루(skyscraper)라고 하면, 일반적인 리팩터링 방식은 기초 기둥 중 하나를 뜯어내는 것과 같습니다. 마천루는 잔해 더미(오해를 부르는 컴파일 에러의 긴 목록)로 무너지고, 당신은 그 잔해로부터 다시 서 있는 마천루를 재건하려고 합니다.

Unison의 방식은 기존 마천루를 그대로 둔 채, 마법의 복제 도구로 그 일부를 새 마천루로 복사해 가는 것입니다. 코드베이스는 결코 깨지지 않습니다. 모든 코드는 실행 가능합니다. 다만 중간 단계에서는 두 번째 마천루를 아직 완전히 짓지 못했고 모든 이름을 전환(cut over)하지 못했을 수 있습니다. Unison은 이를 추적하고, 해결해야 할 일을 깔끔한 TODO 목록으로 제공해 줍니다.

Conclusions

콘텐츠 기반 주소 지정 코드라는 아이디어와 오래 함께할수록, 이 아이디어가 점점 당신을 사로잡기 시작합니다. 이는 임의적이거나 이상한 것이 아니라, 엄청난 실용적 이점을 가진 논리적이고 합리적인 선택입니다. 아이디어의 단순함을 이해하게 되고, 여기저기서 그 필요성을 보게 됩니다(“코드가 콘텐츠 기반 주소 지정이었다면 훨씬 쉬웠을 텐데…”). 하지만 정말 이 아이디어를 중심으로 프로그래밍 언어를 만드는 것이 가능할까요? 네, 가능합니다!

Unison을 만드는 재미 중 하나는 훌륭해 보이는 핵심 아이디어의 함의를 끝까지 밀어붙이며 확인하는 과정이었습니다. 그 과정에서 큰 질문이 하나 떠올랐습니다: 정의 자체는 변하지 않더라도, 우리가 관심 있는 정의가 무엇인지 바꾸고 보기 좋은 이름을 붙이고 싶을 때가 있습니다. 그럼 그건 어떻게 작동해야 할까요? 코드를 어떻게 리팩터링하거나 업그레이드할까요? 코드베이스는 여전히 변경 가능한 텍스트 파일 묶음이어도 될까요, 아니면 다른 무언가가 필요할까요?

콘텐츠 기반 주소 지정 코드를 다루기 좋게 만들려면 다른 무언가가 필요합니다. Unison에서는 그 무언가를 Unison Codebase Manager(유니슨 코드베이스 관리자)라고 부릅니다.

Where to next?

🌟코드베이스 관리자와 Unison 언어 둘러보기

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

📚Unison 관련 발표 보기