Erlang/OTP 29 출시, 동시성의 원조가 또 한 걸음 나아갔어요

Erlang이 아직도 업데이트된다고요?

네, 그리고 아주 활발하게 되고 있어요. 1986년 스웨덴 통신회사 에릭슨에서 전화 교환기를 만들려고 탄생한 언어가 거의 40년이 지난 지금도 매년 메이저 버전을 내놓고 있다는 사실, 좀 놀랍지 않으세요? 이번에 발표된 Erlang/OTP 29.0은 그 긴 역사의 또 한 페이지를 더하는 릴리스예요.

Erlang을 처음 듣는 분들을 위해 잠깐 설명드리면, 이 언어는 "많은 연결을 동시에 안정적으로 처리하는 것"에 특화된 언어예요. WhatsApp이 단일 서버로 200만 동시 접속을 처리했다는 전설적인 이야기, 디스코드 백엔드 핵심에 Elixir(Erlang VM 위에서 돌아가는 언어)가 있다는 사실 모두 이 BEAM 가상머신의 힘에서 나와요. 가벼운 프로세스 수백만 개를 동시에 굴리고, 그 중 하나가 죽어도 시스템 전체는 멀쩡한 "let it crash" 철학으로 유명하죠.

29.0에서 뭐가 달라졌나

이번 릴리스의 핵심 키워드 몇 가지를 짚어볼게요.

첫째, comprehension에 zip 제너레이터가 추가됐어요. 이게 뭐냐면, 여러 리스트를 동시에 순회하면서 새 리스트를 만드는 문법인데요. 기존에는 lists:zip/2로 먼저 묶고 다시 풀어야 했어요. 이제는 [{X, Y} || X <- Xs && Y <- Ys]처럼 && 기호로 깔끔하게 표현할 수 있어요. 파이썬의 zip이나 하스켈의 zipWith 같은 걸 떠올리시면 비슷한 느낌이에요. 작은 문법 변화 같지만 실제로 데이터 처리 코드를 짜다 보면 정말 자주 쓰게 되는 패턴이거든요.

둘째, JSON이 표준 라이브러리로 들어왔어요. 그동안 Erlang은 JSON 처리를 jsx, jiffy 같은 외부 라이브러리에 의존해왔어요. 이제 OTP에 json 모듈이 내장돼서 별도 의존성 없이 인코딩/디코딩이 가능해요. 그것도 단순 구현이 아니라 NIF(Native Implemented Function, C로 작성된 고성능 모듈) 기반으로 빠르게 동작해요. 마이크로서비스를 짤 때 작은 변화처럼 보여도 의존성 트리를 줄여주는 효과가 커요.

셋째, 암호화 관련 모듈 정비예요. OpenSSL 3.x와의 호환성이 강화됐고, 오래된 알고리즘들이 정리됐어요. 보안 관점에서 더 깨끗한 기본값을 제공하는 방향이에요. 또 crypto 모듈에서 새로 추가된 알고리즘들이 있어서, 별도 의존성 없이 최신 암호화를 쓸 수 있게 됐어요.

넷째, JIT 컴파일러 개선이에요. OTP 24부터 도입된 BeamAsm JIT가 이번 릴리스에서 추가 최적화를 받았어요. 특히 ARM64 (Apple Silicon이나 AWS Graviton 같은) 환경에서의 성능이 더 좋아졌고, 코드 로딩 속도도 개선됐어요.

다른 언어와 비교해보면

요즘 동시성 얘기 하면 Go의 고루틴, Rust의 async, Java의 Virtual Thread(가상 스레드) 같은 게 많이 거론돼요. 이들 모두 "수많은 가벼운 실행 단위"라는 컨셉을 추구하는데, 사실 이 패턴의 원조가 Erlang이에요. Java가 2023년에 Loom 프로젝트로 겨우 도입한 걸 Erlang은 1980년대부터 했던 거죠.

다만 Erlang의 차별점은 단순한 동시성이 아니라 장애 격리와 자가 복구예요. supervisor 트리라는 구조로 "이 프로세스가 죽으면 누가 재시작할지"를 선언적으로 관리해요. 통신, 금융, 게임 백엔드처럼 "절대 멈추면 안 되는" 시스템에서 여전히 강력한 선택지인 이유예요.

Elixir와의 관계도 짚고 갈게요. Elixir는 BEAM 위에서 돌아가는 좀 더 현대적인 문법의 언어인데, OTP 29의 변경사항들은 Elixir 사용자에게도 그대로 혜택이에요. JSON 표준화나 JIT 개선은 Phoenix 같은 Elixir 웹 프레임워크의 성능에도 직접 영향을 주거든요.

한국 개발자에게 주는 시사점

솔직히 국내에서 Erlang을 메인 스택으로 쓰는 회사는 손에 꼽아요. 하지만 Elixir는 점점 채용 공고에서 보이기 시작했고, 카카오나 일부 게임 회사 백엔드 일부에서도 활용된 사례가 있어요. 실시간 채팅, 게임 서버, IoT 게이트웨이처럼 "동시 연결이 많고 죽으면 안 되는" 시스템을 설계할 때 BEAM 생태계는 진지하게 고려해볼 만한 옵션이에요.

그리고 굳이 실무에 안 써도, Erlang을 한 번 공부해보는 경험 자체가 멘탈 모델 확장에 좋아요. "공유 메모리 없이 메시지 패싱으로만 동시성을 풀어내면 어떻게 될까" 같은 사고방식은 다른 언어 짤 때도 두고두고 도움이 돼요. Rust의 채널, Go의 채널, Akka의 액터 모델이 다 이 영향을 받았거든요.

마무리

한 줄 정리하면, 40년 된 동시성의 원조가 JSON 내장, zip 제너레이터, JIT 최적화로 또 한 번 다듬어진 릴리스예요. 화려하진 않지만 단단해지는 업데이트죠.

여러분은 동시성 모델 중에 어떤 걸 가장 좋아하세요? 액터 모델? CSP? async/await? 댓글로 각자의 취향과 이유를 나눠보면 재밌을 것 같아요.