분산 시스템을 하나의 프로그램으로: 코레오그래피 언어 'Choral'

분산 시스템을 만들어 본 개발자라면 익숙한 통증이 있다. 클라이언트와 서비스, 로그인 제공자처럼 여러 프로그램이 채널을 통해 메시지를 주고받으며 협력해야 하는데, 그 조율 로직이 각 프로그램에 흩어져 있다는 점이다. 누가 언제 무엇을 보내고 받아야 하는지는 개발자가 send/receive 호출을 손으로 배치하며 맞춰야 하고, 한쪽이 데이터를 기대하는데 다른 쪽이 보내는 것을 잊으면 그 불일치는 실행 시점에야 드러난다. 게다가 동시성 때문에 가능한 통신 순서가 여러 갈래로 갈라지므로, 무엇이 어디서 어긋났는지 추적하기가 특히 어렵다. Choral은 이 문제를 언어 차원에서 다루려는 자바 계열 연구 프로젝트다.

Choral은 '코레오그래피(choreography)'를 프로그래밍하는 언어다. 코레오그래피란 앨리스, 밥 같은 여러 역할(role)이 어떻게 서로 조율해 하나의 일을 해내는지를 정의하는 다자간 프로토콜을 말한다. 핵심 아이디어는 분산된 여러 참여자의 상호작용 전체를 흩뿌리지 않고 하나의 프로그램으로 기술하는 것이다. 그렇게 작성한 코레오그래피를 컴파일하면, Choral 컴파일러가 각 역할별로 별도의 자바 라이브러리를 생성한다. 개발자는 자신이 담당하는 역할의 라이브러리를 자기 프로젝트에 가져다 쓰면 되고, 그 라이브러리는 원래 정의한 프로토콜을 반드시 준수하는 구현이 된다.

타입에 드러나는 분산

Choral은 객체지향 언어이지만 한 가지 비틀림이 있다. 객체의 타입이 T@(R1, ..., Rn) 형태를 띤다는 점이다. 여기서 T는 익숙한 인터페이스이고, R1부터 Rn까지는 그 객체를 함께 구현하는 역할들이다. 즉 데이터 타입 자체에 어떤 역할들이 관여하는지가 명시되어, 분산이라는 성질이 타입 수준에서 겉으로 드러난다. 기술적으로는 역할을 매개변수로 받는 고차 종류(higher-kinded) 타입으로, 코레오그래피와 멀티티어 프로그래밍에서 발전해 온 개념을 일반화한 것이다.

역할 간 실제 상호작용은 데이터를 한 역할에서 다른 역할로 '옮기는' 메서드 호출로 표현된다. 예를 들어 SymChannel 인터페이스의 com 메서드가 그 역할을 한다. 중요한 점은 Choral이 특정 미들웨어를 강제하지 않는다는 것이다. 코레오그래피가 요구하는 타입만 만족시킬 수 있다면 자신만의 통신 구현이나 기존 자바 코드를 그대로 쓸 수 있다. 대신 Choral의 타입 시스템은 채널 토폴로지, 전송 가능한 데이터의 타입 같은 통신 요구사항을 개발자가 명시적으로 적도록 강제한다. 문서에 소개된 예시는 앨리스가 밥에게 카롤과의 회의를 제안하고, 밥이 먼저 카롤에게 가능 여부를 물은 뒤 자신도 판단해, 최종 결과를 앨리스가 밥으로부터 돌려받는 프로토콜이다. 이런 흐름이 하나의 클래스 안에 순차 코드처럼 담긴다. 참고로 Choral은 F#의 전방 연쇄 연산자 >>를 빌려와, expression >> object::method를 object.method(expression)의 의미로 쓴다.

컴파일이 만들어 주는 것

Choral의 개발 방법론에서 컴파일러의 역할은 코레오그래피로부터 역할별 자바 라이브러리를 뽑아내는 것이다. 앨리스, 밥, 카롤 세 역할짜리 프로토콜을 컴파일하면 각 역할에 맞는 라이브러리가 생성되는데, 예컨대 앨리스용 라이브러리에는 앨리스와 무관한 코드가 전부 사라지고 앨리스가 해야 할 일만 남는다. 자바 개발자는 생성된 MeetingVote_Alice 같은 클래스를 임포트해 run 메서드를 호출하면, 제3자가 구현한 밥·카롤과도 올바르게 협력할 수 있다. 코레오그래피 기술과 실제 구현 사이에 불일치가 생기면 컴파일러가 그 오류를 지적하고 해결을 돕는다. 여기에 더해 ChoralUnit이라는 테스트 도구가 있어, 통합 테스트를 단위 테스트만큼 간단하게 작성하고 분산 시스템에 대한 런타임 통합 테스트를 대신 수행해 준다.

실무적으로 이 접근이 겨냥하는 영역은 뚜렷하다. Choral 측은 비즈니스 프로세스, 마이크로서비스, 보안 프로토콜, 그리고 넓게는 분산 서비스 일반에서 특히 유용할 수 있다고 본다. 분산 인증 프로토콜, 암호 프로토콜, 병렬 알고리즘처럼 참여자 간 조율이 정확성의 핵심인 영역이 대표적이다. 여러 Choral 컴파일 프로그램을 신뢰성 있게 조합해 필요한 토폴로지를 구성하고 서로 다른 프로토콜을 섞을 수 있다는 점도 강조된다. 순차 프로그램의 단순함으로 짜되, 강한 정확성 보장을 갖춘 탈중앙 제어의 분산 시스템을 얻는다는 것이 지향점이다.

다만 현재 Choral은 명확히 프로토타입이다. 진행 중인 연구 프로젝트의 일부이며, 향후 릴리스가 하위 호환성을 깨뜨릴 수 있다고 명시되어 있다. 자바와의 상호운용을 내세우고 C++, C#, 코틀린, 스위프트 사용자에게도 문법이 낯설지 않다고 하지만, 아직은 조기 도입과 교육용 수준으로 자리매김한다. 확장 라이브러리 쪽 움직임도 있다. Ozone은 Choral 코드에서 퓨처를 안전하게 쓰게 해 주는 실험적 라이브러리로, CompletableFuture를 통한 비동기 반환이나 병렬 요청 처리를 지원한다. 또한 인터넷 릴레이 챗(IRC)을 Choral로 구현해 전이중 비동기와 상호운용성 문제를 다룬 연구도 발표되어, 실제 널리 쓰이는 프로토콜에 이 방식을 적용한 첫 사례로 소개된다.

한국의 IT 실무자 입장에서 Choral을 당장 프로덕션에 투입하기는 이르지만, 던지는 질문 자체는 검토할 가치가 있다. 우리는 여전히 분산 시스템의 조율 로직을 여러 서비스에 흩어 놓고, 그 계약이 어긋났는지는 스테이징에서의 통합 테스트나 운영 장애로 확인한다. '통신 프로토콜을 타입으로 못 박고 컴파일러가 준수를 강제한다'는 발상은 그런 검증을 왼쪽으로 당기려는 시도다. 마이크로서비스 간 계약, 인증·결제 흐름처럼 순서와 데이터 전달이 어긋나면 곧바로 사고로 이어지는 지점에서, 이런 코레오그래피 기반 접근이 어떤 형태로 성숙해 가는지 지켜볼 만하다.