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

• 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에서 종이책으로 구입 가능함
  • Amazon 링크
• 오타나 개선 사항을 발견하거나 내부 구조가 궁금한 경우, GitHub 리포의 star, fork, issue 등록 및 pull request 활용 가능
  • 기여자는 감사문에 실명 언급
  • GitHub: theBeamBook
• 실제 리뷰가 알고리듬에 더 크게 반영되므로 서평도 적극 요청함
• 실전 시스템 중심 BEAM internals 워크숍도 진행 가능하며, 문의는 happi@happihacking.com으로 이메일 요망