▲

내가 BEAM(Erlang VM) 책을 쓴 이유

 (happihacking.com)
1P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • Klarna의 핵심 시스템을 유지하며 겪은 실전 경험에서 15밀리초의 BEAM 중단이 대규모 결제 장애와 긴급 대응을 불러옴
  • BEAM에 대한 신뢰할 수 있는 레퍼런스를 만들고자 10년에 걸쳐 책을 집필함
  • 집필 과정에서 출판사 변경, 기술적 문제, 여러 번의 구조 변경 등 반복적인 좌절과 재도전을 경험함
  • 오픈소스화 후 커뮤니티의 피드백과 참여, 스타 증가, 격려가 지속적인 동기 부여 역할을 함
  • 핵심 내용은 BEAM VM의 구조와 운영에 집중되어 있으며, 실무 엔지니어에게 실질적인 도움이 되는 구성임

BEAM 책 집필 동기

Post-mortems, 커피, 그리고 10년의 집념

  • Klarna에서 핵심 결제 시스템을 운영하며 BEAM의 단 15밀리초 중단이 수백만 건의 결제 실패와 새벽 긴급 회의, CEO 호출까지 이어지는 상황을 반복적으로 경험함
  • 그런 위기를 신속히 해결할 수 있는 자료의 부재가 항상 아쉬웠으며, 다음 엔지니어가 더 빠르게 문제를 해결하길 바라는 마음으로 The BEAM Book을 집필함

초기 집필 과정

시작과 좌절

  • 2012년 10월, DocBook 파일 하나와 큰 포부로 프로젝트를 시작함
  • 2주간의 커밋은 대부분 구조 작업과 메타데이터 갱신에 집중, 실제 내용은 매우 적었음
  • 11월에는 AsciiDoc와 커스텀 빌드 스크립트로 전환하고 6개월 내 완성을 기대했으나, 계속된 재작성과 구조 변경으로 진전이 매우 느렸음

출판사와의 협업

  • 2013년 O’Reilly와 출판 계약 체결 후 Atlassian Atlas로 마이그레이션하였으나, 파일 분실 및 장 관리 문제 지속 발생
  • Git 히스토리는 불만과 구조 수정의 연속으로 점철되어 있음
  • 2015년 3월, 빌드 통과만을 목적으로 챕터 단위로 강제 분리하는 등의 궁여지책을 시도함
  • 2개월 후 계약 해지가 조용히 이루어지며 자괴감과 안도감이 동시에 찾아옴
  • Pragmatic Bookshelf와의 두 번째 시도 역시 느린 진척과 함께 중단됨

리셋과 커뮤니티 참여

  • 2017년 1월, 새 리포지토리로 massive commit으로 전체 이전(6622개 파일, 1백만 라인)이 이루어졌으나 재작성도 정체됨
  • 2017년 3월, Asciidoctor 기반 비공개 GitHub 리포지토리에서 다시 시작, 필요 부분만 복사
  • 2주 후 공개 전환과 동시에 외부 기여자들의 typo 수정, 다이어그램 추가, 라이선스 협력이 활발히 발생함

지속적인 동기 부여 요소

  • 본질적으로 BEAM의 진짜 동작 원리를 이해하고자 하는 개인적 호기심과 욕구가 가장 큰 원동력이었음
  • 커뮤니티의 피드백과 제안이 집필 의지를 높였으며, GitHub의 스타 수 증가가 지속적 동기 부여 효과를 가짐
  • “Please continue being awesome” 등에서 보듯 격려 이슈가 심리적 지지 역할도 크게 했음
  • Erlang, BEAM 관련 학회 및 컨퍼런스에서 자주 인용되는 일이 늘어나며 책의 필요성이 입증됨
  • Twitter 등에서도 지속적인 언급과 공유가 집필 지속을 자극함

책의 구조 및 주요 대상 독자

  • 직접 대규모 Erlang 시스템을 설계·운영하며 꼭 필요했던 부분 위주로 서술
    • 스케줄러 및 프로세스 관리: 실전 부하에서의 프로세스 스케줄링, 우선순위, 밸런싱 원리
    • 프로세스 메모리: 힙, 스택, 메시지, 바이너리 관리 방식과 운영에 미치는 영향
    • 가비지 컬렉션 및 메모리 모델: 프로세스별/글로벌 GC 작동 방식, 메모리 누수 및 참조 구조
    • 데이터 표현 체계: 정수, 실수, 튜플, 바이너리 등 데이터의 내부 태깅 구조
    • 컴파일러와 VM 내부 구조: 컴파일 이후 VM에서의 실제 명령 실행 흐름
    • 트레이싱과 디버깅: dbg, erlang:trace, 메시지 및 이벤트 추적 등
    • 성능 튜닝: 실코드 프로파일링, 지연 원인 분석, reduction 이해법
    • 시스템 아키텍처: ERTS, BEAM VM, 서브시스템의 통합 동작 원리
  • Erlang/Elixir 실무 운영자에게 매우 실질적 영향이 있으며, 흩어진 자료 대신 신뢰할 수 있는 종합 안내서 역할을 핵심 목표로 함

집필 과정에서의 교훈

  • 끈기가 완벽주의를 이김. 두 번의 출판 취소 경험도 “미완성”보다는 낫다는 결론임
  • 집중과 경계 설정이 중요함. 글쓰기 시간 확보와 알림 차단, 엄격한 시간 관리가 실제 진전의 원천임
  • 공개와 피드백은 질적 향상의 핵심임. 외부의 교정과 격려, 꾸준한 자극이 큰 도움을 줌
  • 스코프 관리가 필수적임. 범위 조정으로 어려운 주제(Dirty Scheduler, JIT 등)는 추후 부록에 넘김
  • 릴리즈 후 반복 개선 전략이 중요함. BEAM은 매년 변화하며, 살아있는 Git 리포로 지속 보완 가능함
  • 진짜 마감 설정이 실질적 동기임. Code Beam Stockholm 행사 전까지 인쇄라는 마감이 필수 내용을 선별하게 만듬

완성의 정의

  • 실제 인쇄본을 손에 쥐는 순간 마침내 ‘완성’이라는 느낌을 가질 수 있었음
  • 산발적 커밋들이 한 권의 실체로 묶여 있어 현재를 기준으로는 끝을 선언함

참여 방법

  • The BEAM Book 1.0은 현재 Amazon에서 종이책으로 구입 가능함
  • 오타나 개선 사항을 발견하거나 내부 구조가 궁금한 경우, GitHub 리포의 star, fork, issue 등록 및 pull request 활용 가능
  • 실제 리뷰가 알고리듬에 더 크게 반영되므로 서평도 적극 요청함
  • 실전 시스템 중심 BEAM internals 워크숍도 진행 가능하며, 문의는 happi@happihacking.com으로 이메일 요망
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • git 저장소는 여기에서 확인 가능함

  • BEAM을 제대로 이해하고 싶어서 계속 파헤치게 된다는 저자의 동기가 인상적임. 이런 열정이 멋진 결과물을 만들어낸다고 생각함. 그래서 바로 구매 결정. 내 경험을 말하자면 출판사로부터 여러 번 책 집필 제안을 받았지만, 서로 원하는 방향이 달라서 성사된 적이 없음. 예를 들면, 나는 14살 대상 Java 입문서는 쓰기 싫었고, 출판사는 내가 깊게 파는 주제(예: classloader)에는 관심이 없었음. 개인적 열정과 독자의 니즈가 만나는 교집합을 어떻게 찾는지 남들은 어떻게 하는지 궁금함

    • 책을 세 권 써본 경험으로 볼 때, 자가 출판하거나 출판사가 원하는 책을 쓰거나 둘 중 하나임. 출판사마다 추구하는 책의 색깔이 다르고, 초급자용 실용서에 집중하는 곳이 많아서 대중적이지 않은 주제를 쓰고 싶으면 자가 출판을 준비하는 것이 현실임. 다행히 요즘은 자가 출판이 쉬워져서 온라인으로 판매도 가능함. 즉, 아주 틈새 시장을 겨냥한 주제라면 출판사를 기대하지 말고 스스로 출판과 홍보를 맡아야 한다는 점이 현실임
    • 본인이 흥미로운 이야기를 한다면 결국 독자들은 그걸 이해하기 위한 방법을 찾게 됨. 경력 초기에 Don Box의 “Essential .Net”을 읽었는데, 그도 특정 독자층을 노린 느낌이 아니었음. 그냥 CLR 내부를 깊이 파헤친 책이었고, 처음에 완전히 이해하려면 여러 번 읽어야 했음
    • 출판사에 꼭 의존해야 하는지, 아니면 스스로 독립적으로 책을 써도 되는 건지에 대해 고민함. 출판사의 이름이나 부가적인 이득 때문인지 궁금함
    • 가르친다는 행위가 가장 좋은 학습법이라는 점에 동의함. 고등학교 때 수학 튜터하며 배웠고, 책을 쓰는 경험도 비슷함. 단순한 이해를 넘어서 근본적인 내용을 내 것으로 만드는 최고의 방법임
    • 약간 자랑 같지만, 나도 등반을 위한 근력 트레이닝 책을 이렇게 파고들다 쓰게 됨. 원래는 자가 출판하려 했지만, 결국 출판사를 찾아 약간 더 읽기 쉽게 수정했음. 출판사에 직접 접근해 보는 것도 방법임

  • BEAM과 Erlang/OTP를 다뤄 본 경험이 지난 1년 중 가장 좋았던 개발 경험 중 하나임. Joe Armstrong의 “Programming Erlang: Software for a Concurrent World” 책을 사용했고, 초보자에게 강력 추천하고 싶음. “Designing for Scalability with Erlang/OTP”도 평이 좋지만 아직 시작은 못했음. 하지만 깊이 면에서는 이번 책이 압도적임. BEAM은 정말 고대 문명이 남긴 외계 기술 같음. 좋은 타이밍에 저 책이 나와서 바로 구매. 두 번이나 출간이 취소된 뒤에도 책을 완성해 준 Erik Stenman 박사에게 감탄함

    • BEAM/Erlang/OTP로 어떤 소프트웨어를 개발했는지 궁금함

  • Elixir와 BEAM은 네트워크 기반이나 파이프라인이 많은 시스템 구축에 최애 선택임. 몇 년간 프로덕션에서 매일 사용했고, 최근 프로젝트에서는 선택이 쉽지 않지만 꾸준히 동향을 챙김. 이 책 출간이 고마움. 몇 년 전 프로덕션 Elixir에서 디버깅하면서 꼭 원했던 책임. 기존 자료는 너무 어렵거나 반대로 너무 단순해서 아쉬웠음

  • BEAM(Erlang virtual machine) 정보는 위키백과 링크에서 확인 가능함

    • 책 제목에 이미 잘 설명되어 있음

  • BEAM이 오픈소스 분야에서 가장 과소평가된 기술 중 하나라고 생각함. 예시로 whatsapp이 있음. Elixir와 Erlang이 높은 동시성 프로젝트에 더 인기가 없는 이유가 미스터리임

    • 내 직장은 Erlang 전문 회사임. Erlang의 진가는 수백만 DAU처럼 대규모 트래픽에 있음. Elixir로 수천 DAU 웹사이트를 돌릴 순 있지만, Erlang과 BEAM의 본질은 그 스케일에 있음. 이런 규모가 필요한 회사는 많지 않고, 더 큰 문제는 Erlang 생태계 자체가 마치 별도의 OS처럼 동작해서 환경 설정과 구성요소가 상당히 복잡함. 컨테이너나 k8s 같은 다른 인프라 기술도 필요 없고, 오히려 Erlang의 고유 방식 때문에 익숙하지 않게 느껴짐. 딱 들어맞는 상황에서 Erlang을 경험한다면, 일종의 마법 같다고 생각함. 내 커리어 하이라이트임
    • 결국 마케팅의 영향이라고 생각함. Java, C#, Go는 막강한 기업 후원이 뒷받침하지만 Erlang은 오히려 기업이 발목을 잡거나 기술 문서 외에는 별 신경을 안 씀. Elixir는 처음으로 다른 언어식 마케팅(루비 모델)을 따라갔으나, 진입 시점과 상황이 다름. 개발자들은 BEAM의 우수성을 납득하겠지만, 그 외의 의사결정권자들에게 어필이 잘 안 되는 것 같음
    • 투자 차이가 크다고 생각함. Rust, Go, Python 등은 기업 지원으로 정적 분석, 타입 체크, 개발자 경험 등에서 많은 투자가 이뤄졌지만, Erlang 쪽은 이러한 사랑을 충분히 받지 못했고, 대형 사용자들도 점차 BEAM 바깥에서 직접 솔루션을 만들거나 전향함
    • 우리는 최근 Squarespace 웹사이트를 Phoenix 애플리케이션으로 바꿨는데, 정말 즐거운 경험이었음
    • 동시에 가장 덜 비밀스러운 ‘비밀 소스’임. 최근 BBC도 Elixir로 전환했으니 점점 인기도 올라가는 중이라고 느낌

  • “Erlang Runtime System(ERS)”은 일반적인 Erlang 런타임을, “Erlang RunTime System(ERTS)”는 Ericsson 구현에 국한된 표현이라는 설명이 좋음

    • 저 정의가 바보 같지 않다고 생각함

  • 바로 책을 구매함. 온라인으로 무료로 볼 수 있지만 저자를 조금이나마 지원하고 싶어 구매함

  • Klarna 같은 대규모 시스템을 하지 않아서 체감이 어렵지만 15ms 딜레이가 포스트모템 이슈가 된다는 게 신기함

    • BEAM에서는 마이크로초(μs) 단위 응답이 일반적이어서, 밀리초(ms)로 튀면 바로 경보가 울릴 수 있음
    • BEAM 시스템에서는 이런 상황이 충분히 발생함. 공유 상태 보호를 위해 gen_server를 만들면, 이건 거대한 뮤텍스 같은 개념임. gen_server가 요청을 처리하는데 20us 걸린다고 하면, 15ms 딜레이면 메시지 큐에 750개의 메시지가 쌓임. 여기에 메시지 큐를 비효율적인 패턴으로 쓰면 성능이 급감함. BEAM은 특정 패턴만 메시지 큐 최적화를 해 주지만 나머지 패턴의 경우 큐 길이에 따라 처리 시간이 증가함. 라이브러리 내부에서 안전하지 않은 receive가 쓰이면 예상치 못한 성능 저하 발생. 최근에 BEAM이 메시지 큐 문제를 보완하는 'alias' 기능을 추가했지만 많은 라이브러리가 아직 사용하지 않음. alias는 메시지 손실 방지가 목적이고, 타임아웃 메시지로 큐가 오염되는 걸 막아줌. 보통 장수 프로세스는 큐를 루프로 돌면서 처리함
    • 언급된 사건의 포스트모템 링크 아시는 분 있으면 궁금함. 온라인에서 못 찾았음

  • BEAM과 유사한 VM이 있는지 궁금함. 혹시 BEAM이 워낙 뛰어나서 경쟁 제품이 없는 건지, 아니면 그만큼 만들기 어렵기 때문인지 알고 싶음

    • 현대 Kubernetes 인프라가 제공하는 기능이 BEAM과 비슷하다고 봄. 요즘은 이런 인프라로 대규모 셀프힐링 시스템을 구현하며, 언어 제약도 없음. Erlang/Elixir 말고도 다양한 생태계와 인력, 관심사가 존재함
    • AtomVM이라는 IoT 등 제약이 큰 장치용 별도 구현도 있음. BEAM이나 OTP를 다른 생태계에서 구현하려던 시도는 많았지만, 대부분 VM 레벨은 아님
    • BEAM이 90년대 후반, 2000년대 초에 나온 시기에는 꽤 독특했음. 지금은 구현 방식만 다를 뿐 같은 문제를 다양한 언어와 도구로 잘 풀 수 있음. Erlang 커뮤니티 특유의 “BEAM 방식 만이 정답”이라는 태도도 있지만, 2025년에는 정말 다양한 옵션이 존재함. BEAM 호환 구현도 있지만, 대부분 니치한 영역임. 기존 BEAM 인프라에 합류해야 하는 게 아니라면, 녹색필드 프로젝트에는 요즘 생태계의 현대적인 솔루션이 더 적합하다고 생각함. ergo 같은 소규모 프로젝트도 있음
    • Dis VM이 아마 가장 비슷하고, 그다음이 Smalltalk VM임. 사실 BEAM 자체보다 OTP가 얹혀 BEAM이 진가를 발휘함
    • 실사용에서 가장 비슷한 건 아마 Go일 것임. BEAM은 “Erlang류 언어”에 맞춘 생태계라 Elixir나 Gleam도 핵심 동작이 Erlang과 유사함. Go가 goroutine 등 병행성에서 Erlang식 primitive를 제공하지만, OTP처럼 애플리케이션 구조에 대한 뚜렷한 관점은 없음
답변달기