Erlang/OTP 29.0 출시 및 Erlang 생태계에 대한 논의

SSH 데몬이 자동으로 활성화되거나 시작된 적은 없었던 것 같음. 두 항목의 표현은 다르지만, 의미는 SSH 데몬을 시작할 때 나열된 구성요소들이 기본으로 시작되지 않는다는 뜻으로 보임
SSH 데몬은 이제 셸(Shell)과 exec 서비스가 기본 비활성화되어 secure by default(기본 보안 설정) 원칙을 따름. 명시적으로 설정하지 않으면 인증된 사용자가 임의의 Erlang 코드를 실행하지 못하게 막음
SFTP 하위 시스템도 SSH 데몬 시작 시 더 이상 기본 활성화되지 않음

프로덕션 앱이 29 미만이면 이 버전이나 최신 패치 버전으로 최대한 빨리 업데이트하는 게 좋을 수 있음. 방금 프로덕션에 배포했는데 자동 보안 스캔에서 2026년 2~5월 날짜의 CRITICAL CVE 2개와 HIGH 위험 항목 여러 개가 잡힘

목록이 있음?

아직도 새 프로젝트에 Erlang을 쓰는 사람이 있는지 궁금함
여기 Elixir 좋아하는 사람이 많다는 건 아는데, 순수 Erlang을 말하는 것임
아직 Erlang을 쓴다면 Elixir보다 선호하는 이유가 뭔지 궁금함

올해만 해도 있음. AtomVM 기반 새 IoT 작업, Erlang으로 작성한 애플리케이션 서버, 아직 작업 중인 TUI 프레임워크가 있음
Elixir가 내게 Erlang 대비 실질적인 장점을 주지는 않음. 분명 장점이 있을 수는 있겠지만 Erlang이 내 사고방식에 더 잘 맞음. 배우거나 도움받는 걸 사회적 모임처럼 해보고 싶기도 한데, 나한테 맞는 자리를 잘 못 찾겠음

“레코드는 수십 년 전부터 있었는데?”라고 하려다가 변경 로그를 읽어봤음
흥미로움. Elixir가 언젠가 맵(Map)을 native records(네이티브 레코드)로 컴파일하는 세계가 있을지 궁금함

WhatsApp이 아직 Erlang 기반인지 아는 사람 있음?

맞음
2010년대 초부터 Erlang을 써왔는데, 그 무렵 기술 업계가 WhatsApp이 엔지니어 30명 정도로 활성 사용자 4억 명 이상을 지원한다는 걸 알게 됐음
당시 그쪽 엔지니어 한 명에게 연락했고, 미국에 살던 시절 이메일로 몇 가지 질문에 친절히 답을 받았음. 결국 커피도 마셨고 지금까지도 연락하고 지냄
Erlang은 지금도 WhatsApp의 중요한 일부라고 말할 수 있음

직접 아는 건 아니지만 2019년에 떠났고, WhatsApp의 공개 Erlang 관련 저장소들은 아직 활발함. 아는 한 Erlang이 Meta 전체로 퍼진 것도 아니라서, WhatsApp이 Erlang에서 벗어났다면 이후에 Erlang 작업을 계속할 이유가 별로 없음

맞음. 예전 내 직원이 지금 그쪽에서 일함

맞음. Erlang을 쓰고 있고 Rust도 점점 늘어나는 중임

-unsafe 속성 지원 추가라니, Rust로 다시 쓰기 딱 좋은 타이밍이네 /s

Erlang은 대체 누가 쓰는지 모르겠음. Rails를 쓰다가 Phoenix를 써봤는데, 뭔가 해내기가 훨씬 어려웠음
Phoenix에 대한 열광을 이해하지 못하겠음
1인 개발자에게는 Rails가 아마 가장 생산적인 웹앱 시스템임. LLM도 Ruby on Rails 코드를 아주 잘 작성함. Python 학습 말뭉치가 엄청 큰데도, 내 경험상 Django보다 훨씬 잘 씀
실험적인 앱은 Rails로 쓰고, 안정화되면 Go로 다시 작성함. 앱 범위가 불분명할 때 Go로 바로 쓰면 토큰을 훨씬 많이 쓰지만 Rails에는 매우 효율적임
요즘은 React나 Angular도 더 이상 필요 없고, Rails에서는 Hotwire를 쓰고 Go에서는 HTMX를 씀.
Erlang 포럼 자체도 Rails로 작성된 Discourse를 사용함

2016년부터 Elixir 앱을 풀타임으로 작성해왔음. 클라이언트들은 크래시(Crash)를 보지 않는 것에 매우 만족함. 실제로 지난 10년간 프로덕션에 배포한 모든 애플리케이션은 100% 가동 시간을 기록했음. 내가 통제할 수 없는 하드웨어, 운영체제, 네트워크 장애는 제외함
시야를 좀 넓혀보는 게 좋겠음

Rails가 Phoenix보다 빠른 것은 개발 속도 기준으로 대략 첫날 정도뿐이라고 봄. 그 이후에는 암묵적 로직 (implicit logic), method_missing 같은 것들에 부딪히게 되고, 동작 방식을 파악하느라 시간이 더 소요됨.

Elixir/Phoenix는 그 점에서 더 명시적 (explicit)이라 장기 유지보수, 즉 첫 주를 넘긴 시점부터는 훨씬 편함. 숨겨진 상태 (hidden state)가 없고, ModuleName.method(params)가 어디서 오는지 찾아 헤맬 필요도 없으며, 해당 메서드를 실행하기 위해 무언가를 설정할 필요 없이 올바른 인자 (argument)를 넘기기만 하면 됨. 단점은 즉시 사용할 수 있는 패키지 라이브러리 (package library)의 규모가 더 작다는 정도임.

Ruby Discord가 무엇을 사용하는지 맞춰볼래?

Phoenix가 주로 흥미로운 이유는 OTP와 채널 (channels), 그리고 LiveView 때문임. 다만 LiveView는 2026년에 내가 선택할 옵션은 아닐 것 같고, 그런 기능들이 필요 없다면 매력이 덜할 수 있음.
Ecto도 나쁘지 않음.
Claude Code는 Elixir 코드를 아주 잘 작성함.
놀랍게도 LLM이 있든 없든, 원래 알고 있는 기술을 쓸 때 더 생산적임.

“앱의 범위가 불분명할 때 Go로 바로 작성하면 토큰 (token)을 훨씬 많이 쓰지만, Rails에는 매우 효율적이다”라고 쓰는 절대적인 아이러니가 있음. 이렇게 길게 늘어놓고서 정작 코드는 본인이 쓰는 것이 아니라고 드러낸 셈임.