필자가 약 6개월 동안 Gleam으로 개인 사이트와 사이드 프로젝트를 운영하며 확인한 안정성, 성능, 유지보수와 개발 경험을 바탕으로, Gleam이 프로덕션에서 충분히 실용적인지 평가한 1부 글.
URL: https://lindbakk.com/blog/is-gleam-production-ready-part-1
제목: John M. Lindbakk
참고
이 글은 2부작 시리즈의 첫 글입니다. 이번 글은 제 경험에 초점을 맞추고, 다음 글에서는 기업 관점에서 Gleam의 도입 준비성을 평가합니다.
약 반년 동안 제 웹사이트를 Gleam으로 운영해 왔고, 최근 사이드 프로젝트로 surtoget.no도 Gleam으로 출시했습니다. 또한 Gleam의 창시자인 Louis Pilfold와 짧게 이야기했는데, Gleam을 프로덕션에서 어떻게 운영하는지에 대한 콘텐츠가 부족하다고 하더군요. 그래서 제 생각을 공유하고, Gleam 코드 사용 및 유지보수 경험을 이야기하려 합니다.
제가 만든 사이트들이 세상에서 가장 복잡한 소프트웨어는 아닐지라도, 실제로 존재하며 실제 목적을 수행하고 대중에 공개되어 있습니다. 한편으로 저는 업무에서 엔터프라이즈 시스템을 다루고 있으며, 10년간 전문 소프트웨어를 개발해 왔습니다. 그래서 Gleam을 프로덕션에서 다뤄본 소감을 이야기할 자격은 충분하다고 생각합니다.
처음 접하시는 분들을 위해: Gleam은 비교적 젊은 프로그래밍 언어로 BEAM 엔진(Erlang의 VM)에서 동작합니다. JavaScript 타깃도 지원하지만, 저는 주로 BEAM용으로 Gleam을 사용하므로 본 글의 범위에서는 다루지 않습니다.
Gleam의 흥미로운 점은 바로 그 "새로움"입니다. 우리는 어떻게 어떤 언어가 "프로덕션 레디"인지 알 수 있을까요? 프로덕션 레디란 무엇을 의미할까요? (버전이 V1.0.0에 도달하면 충분한가요?) 새로운 언어를 프로덕션에 써도 안전한 시점은 언제일까요? 이 질문들에 답해보겠습니다.
언어는 "그 자체만"으로 존재하지 않습니다. 언어를 둘러싼 모든 것—예컨대 의존성 관리나 LSP 같은 툴링—이 있습니다. 또한 파이프라인을 구축하고, 프로덕션에서 시스템 상태를 모니터링할 수 있어야 합니다.
이 2부작 시리즈의 첫 글에서는, 언어 자체와, 언제나 접근 가능해야 하는 시스템(우연히도 Gleam으로 작성된)을 어떻게 유지할 수 있는지에 집중합니다.
저는 한 사람의 머릿속에 전부 담을 수 없을 만큼 거대한 시스템을 다루는 엔터프라이즈 배경을 갖고 있습니다. 수천 개의 서비스가 있고, 여러 나라에 흩어진 팀들이 이를 유지보수하며, 이 모든 것이 하나의 응집력 있는 전체(이론적으로)는 솔루션을 이루기 위해 함께 동작해야 합니다.
엔터프라이즈 세계에서는 언어나 프레임워크를 마음대로 고를 사치가 거의 없습니다. 흔히 "아키텍트 보드"가 정해 놓은 몇 가지 옵션(대개 Java나 C#)에 묶이거나, 기존 팀의 기술 역량에 제한을 받습니다. 제 사이트를 만들기로 했을 때는 익숙한 것에서 벗어나 새롭고 다른 무언가를 택하고 싶었고, Gleam이 딱 들어맞았습니다.
또 하나 마음에 들었던 점은, 당시 LLM들이 아직 따라잡지 못했다는 것입니다. LLM들은 Gleam이 어떻게 동작하는지 전혀 모르거나 여전히 어려워합니다. 저는 제 학습 능력을 날카롭게 유지하고, 문서나 심지어 언어의 소스 코드까지 읽어가며 이해하길 원했기에 그런 점을 원했습니다.
마지막 이유는 Erlang VM을 본격적으로 파고들고 싶었기 때문입니다. 그 VM은 놀라운 특성들을 갖고 있거든요.
이 사이트는 6개월 넘게 Gleam으로 구동되고 있으며 단 한 번의 중단도 없었습니다. 이상한 HTTP 응답 지연이나 hiccup도 없었습니다. 문제가 생긴 적이 있다면 전부 제 미숙함 때문에 생긴 것뿐이었고(이 경우엔 오히려 좋은 일이죠), 언어 탓은 아니었습니다.
제 개입이나 감독 없이도 몇 달씩 안정적으로 돌아갔고, CPU 사용량에 놀랄 일도, 메모리 사용량의 요동도, 그 밖의 다른 문제도 없었습니다. 시스템 전체는 메모리 상한을 512MB로 제한하고 있지만, 실제 사용량은 그에 근접한 적이 없습니다(약 210MB 수준으로 머뭅니다).
이 글을 쓰면서 제 웹사이트의 성능 이슈를 몇 가지 발견했습니다. 이는 Gleam 때문이 아니라, 제가 사이트를 구성한 방식에 기인한 문제였습니다.
현재 성능은 훌륭합니다! 단일 CPU 코어에서 초당 2000건 이상의 요청을 처리할 수 있습니다.
다시 말해 Gleam의 근본적인 성능에 대해선 걱정이 없습니다. 대부분의 일을 하기엔 충분히 빠릅니다. 병목의 상당수는 프로그래밍 언어에서 비롯되지 않으며, 대체로 설계나 코드가 충분히 숙고되지 않아 생기는 자기 유발적 문제입니다.
전반적으로 제 Gleam 프로젝트 유지보수는 아주 수월했습니다. Gleam에는 꽤 탄탄한 패키지 관리자와 빌드 시스템이 있어, 의존성 업데이트는 gleam update 한 줄이면 됩니다. 저는 Renovate를 사용해 의존성 업데이트를 자동화합니다.
굳이 아쉬움을 꼽자면, 생태계의 속도와 미성숙도에 관한 부분입니다. 많은 패키지가 아직 V1에 이르지 않았고 활발한 개발이 진행 중입니다. 어떤 것은 V1에 도달하지 못하고, 어떤 것은 브레이킹 체인지를 도입하기도 합니다. Lustre와 Wisp처럼 핵심 의존성은 매우 견고하지만, 부수적인 의존성은 버전 전환 시 안정성의 확실성이 상대적으로 떨어집니다. 물론 이게 큰 문제를 일으키거나 많은 시간을 잡아먹은 적은 없었지만, 언급할 가치는 있습니다. 이에 대해서는 다음 글에서 더 이야기하겠습니다.
Gleam을 작성하는 경험은 많은 다른 언어들과 유사합니다. 릴리스마다 유용한 기능이 추가되는 잘 다듬어진 LSP가 있고, 탄탄한 패키지·빌드 시스템이 있습니다. 특별히 빠져 있는 구석이 없습니다.
BEAM과 Erlang에 대해 조금이라도 아신다면, 그 VM이 클러스터로 실행되거나, 클러스터 내 내부 프로세스를 자동 스케일링하는 등 놀라운 일들을 해낸다는 걸 아실 겁니다. 저는 처음 웹사이트를 만들 때, 초기 구동이 마치 쿠버네티스를 세팅하는 것만큼 복잡하지는 않을까 걱정했습니다. 다행히 그렇지 않았습니다. Java, Node 등과 마찬가지로 아주 간단히 애플리케이션을 컨테이너로 묶어 실행하면 됩니다. BEAM의 인프라 관련 기능은 일종의 선택사항이어서, Gleam은 다른 어떤 언어만큼이나 쉽게 실행하고 호스팅할 수 있습니다. 심지어 Gleam은 애플리케이션을 바로 구동하는 데 쓸 수 있는 공식 컨테이너 이미지까지 제공합니다.
이는 또한 CI/CD 파이프라인을 손쉽게 구성하고, 선택한 어떤 클라우드 제공업체에서도(해당 업체가 VM이나 컨테이너를 지원한다면) Gleam 웹 애플리케이션을 호스팅할 수 있음을 의미합니다.
Gleam은 프로덕션 사용에 충분히 준비되어 있습니다. Gleam을 작성하는 일은 대부분의 다른 프로그래밍 언어보다 결코 더 복잡하지 않으며, 프로덕션 배포와 운영 또한 마찬가지입니다. 다소 평범해 보일 수 있지만, 이 경우엔 그게 장점입니다. 프로덕션에서 저는 놀랄 일을 원치 않습니다. 그냥 쉽고 매끄럽기를 바랍니다.
결론적으로, Gleam은 잘 작동하고, 성능도 좋으며, 지난 6개월 동안 언어 자체는 안정적이었고, 이상하거나 불쾌한 의외의 일도 없었습니다. 저는 Gleam을 업무에도 기꺼이 사용할 수 있습니다(기회가 주어진다면 실제로 그렇게 할지도 모릅니다).
다음 글에서는 Gleam 생태계를 더 깊이 파보겠습니다. 언어가 프로덕션 레디라고 해도, 생태계(혹은 그 부재) 때문에 매번 바퀴를 재발명해야 한다면 큰 도움이 되지 않으니까요.
