gleam creator - Louis Pilfold.mdx

https://www.youtube.com/watch?v=RntfkL8lUY4

Is Gleam your next programming language? (with Louis Pilfold)

크리스 젠킨스: 오늘 루이스 필폴드와 함께합니다. 루이스, 잘 지내시죠?

루이스 필폴드: 네, 덕분에 잘 지냅니다. 초대해 주셔서 감사합니다.

크리스 젠킨스: 만나서 반가워요. 팬데믹 이전, 그러니까 그 사건 이후로 직접 만난 적이 없네요.

루이스 필폴드: 맞아요, 그 사건 이후로요.

크리스 젠킨스: 이름조차 언급하기 싫은 그 사건 말이죠. 계속 마주칠 뻔했지만, 지금은 온라인으로만 만나게 되네요. 런던이 그렇게 큰 도시는 아닌데 말이죠.

루이스 필폴드: 온라인으로도 충분해요. 같은 도시에 살고 비슷한 관심사를 가지고 있다면, 기술 행사 같은 곳에서 마주쳤을 텐데 말이죠.

크리스 젠킨스: 언젠가 다시 만나게 되겠죠. 그동안 저는 비밀 추적 동굴에서 당신을 지켜보고 있었습니다.

루이스 필폴드: 으스스하네요.

크리스 젠킨스: 프로그래밍 언어를 만드느라 바쁘셨죠?

루이스 필폴드: 네, 취미 프로젝트로 시작했는데, 일처럼 커져버렸어요. 이제는 위험할 정도로 유용해졌죠. 꽤 멋지지 않나요?

크리스 젠킨스: 그 부분에 대해 자세히 알아보고 싶지만, 먼저 프레임을 설정해야 할 것 같아요. 당신의 언어는 Gleam이라고 불리죠?

루이스 필폴드: 네.

크리스 젠킨스: Gleam은 무엇이며, 왜 새로운 언어가 필요한가요?

루이스 필폴드: 저는 항상 언어에 대한 불만이 조금씩 있었어요. 언어를 좋아해서 매년 한두 개씩 새로운 언어를 배우려고 노력했죠. 그러다가 모든 언어에 짜증이 나는 지점에 도달했어요. Elm을 작성할 때는 Haskell을 작성하고 싶었고, Haskell을 작성할 때는 Erlang을 작성하고 싶었죠. Erlang을 작성할 때는 Rust를 작성하고 싶었어요. 마치 저기서 조금, 여기서 조금씩 가져와서 합치고 싶은 느낌이었죠. 그래서 "좋아하는 부분만 모아서 새로운 것을 만들면 어떨까?"라는 생각을 하게 되었어요. 과연 조화롭고 멋진 무언가를 만들 수 있을까요? 아니면 그냥 서로 어울리지 않는 종과 휘파람의 끔찍한 혼합물이 될까요?

크리스 젠킨스: 그 질문을 던지고 끔찍한 결과물을 내놓은 언어들을 몇 개 알고 있습니다. 당신의 답변은 어떤가요?

루이스 필폴드: 좋아요. 까다로운 문제죠. Lua와 Go에서 많은 영감을 얻었어요. 함수형 프로그래밍을 하는 사람으로서, 어떻게 설명해야 할지 모르겠지만, Lua처럼 매우 간단한 절차적 언어라는 의미는 아니에요. 언어의 표면적을 매우 작게 만들고, Go보다 훨씬 더 일관성 있게 만들려고 노력했어요. 그리고 이러한 다양한 유형의 언어에서 정말 가치 있는 것들이 무엇인지, 그리고 그것들을 최소한으로 가져와서 최대한 활용할 수 있는 방법은 무엇인지 고민했죠. 많은 사람들이 언어를 만들 때 선택하는 방식은 아니라고 생각해요. 더 많은 것을 추가하는 것처럼 보이지만, 저는 더 적게 가지려고 노력하고 있어요. 몇 년이 지난 지금, 많은 사람들에게 공감을 얻고 있는 것 같아요. 그래서 꽤 만족스럽습니다.

크리스 젠킨스: 멋지네요. 그럼 언어의 뷔페에서 어떤 것들을 골랐는지 말씀해 주시겠어요?

루이스 필폴드: Elm 스타일의 간단한 함수형 언어라고 할 수 있습니다. 당신도 과거에 Elm 팬이었죠?

크리스 젠킨스: 네, Elm 팬입니다.

루이스 필폴드: 그래서 언어의 기능이 꽤 적고, 일반적으로 함수는 값을 입력받아 값을 반환하며, 나머지는 무시한다고 말하죠. 그것이 필요한 전부입니다. 하지만 Elm과 같은 구문 대신, 처음에는 그런 구문을 사용했지만, JavaScript 프로그래머나 C 프로그래머에게 훨씬 더 친숙한 구문을 사용하게 되었어요. 중괄호 같은 것들 말이죠. 처음에는 "그게 무슨 의미가 있을까? 구문은 중요하지 않아."라고 생각했어요. 그런데 구문을 바꾸자 갑자기 모두가 "이 언어는 훌륭해!"라고 말하기 시작했죠. 아무것도 바뀐 게 없는데 말이에요. 그래서 제가 틀렸다는 걸 알았죠. 구문은 정말 중요합니다. 예전 구문이 그립지만, 사람들은 새 구문을 정말 좋아해요. 그래서 꽤 만족스럽습니다.

가장 큰 장점 중 하나는 Erlang 가상 머신인 Beam에서 실행된다는 것입니다. 처음부터 함수형 언어를 위해 설계된 가상 머신이라는 점이 특이하죠. 그리고 많은 함수형 언어들이 연구 프로젝트인 것과 달리, Beam은 산업을 위해 만들어졌어요. Ericsson의 전화 교환기를 위해 만들어졌죠. 그래서 매우 안정적인 시스템을 실행하고 유지 관리하고 디버깅하는 데 정말 유용합니다.

크리스 젠킨스: 흥미롭네요. 제가 Beam에 대해 아는 것은 Apache Beam이 아니라 Erlang Beam이라는 것과 안정성에 대한 새로운 접근 방식으로 유명하다는 것입니다.

루이스 필폴드: 네, 맞아요. Gleam은 타이핑을 선호하는 사람들과 Erlang을 선호하는 사람들 사이에서 오류 처리에 대한 논쟁을 해결하려고 노력하고 있습니다. Elm에서는 프로그램에서 유효하지 않은 상태를 표현할 수 없도록 만드는 것이죠. 정말 환상적인 방법이지만, Erlang을 선호하는 사람들은 "말도 안 돼! 애플리케이션에서 메모리 손상을 어떻게 막을 수 있지? 전화선 기둥에 설치된 컴퓨터 클러스터에 벼락이 떨어지면 어떻게 될까?"라고 말합니다. 타입으로는 그런 문제를 해결할 수 없죠.

크리스 젠킨스: 그렇죠. 타입으로는 해결할 수 없죠.

루이스 필폴드: 그래서 중요한 것은 오류가 발생할 것이라는 사실을 받아들이는 것입니다. 전체 시스템이 어떤 극적인 방식으로든 폭발할 수 있다는 것을 인정하고, 그 상황에서도 살아남을 수 있도록 해야 합니다. "껐다 켜봤어요?"라는 말처럼 시스템을 작은 격벽으로 나누어서, 한 서브시스템에서 모든 것이 잘못되면 해당 서브시스템만 다시 시작하는 방식입니다. 문제가 해결되었나요? 아니요. 그럼 한 단계 더 나아가서 해당 시스템의 손상된 상태를 버리고 천천히, 점진적으로 요소를 제거해 보는 건 어떨까요?

Beam과 Kubernetes 사이에 유사점이 있다고 생각할 수 있습니다. Go로 작성된 웹 서비스 배포가 있고, 해당 서비스에서 문제가 발생하면 VM, 아니, VM이 아니라 인스턴스가 다운되고 Kubernetes가 다시 시작합니다. 그러면 정상 상태가 되고 진행 중인 작업은 손실되지만, 시스템은 정상적으로 작동할 것입니다. 정말 멋진 방법이지만, Go 프로그램의 단일 인스턴스는 아마도 동시에 수백 또는 수천 개의 작업을 실행하고 있을 것이기 때문에 전체 인스턴스를 잃는 것은 좋지 않습니다. 그래서 전체 패턴을 유지하면서 데이터 센터 수준이 아니라 프로그램 수준에서 단일 VM 인스턴스가 실제로 수백, 수천, 수백만 개의 스레드를 실행하도록 한다면 어떨까요? 그리고 개별 스레드 수준에서 점진적인 상태 폐기를 수행할 수 있다면, 아마도 웹 요청 하나만 잃게 될 것입니다.

크리스 젠킨스: 다른 언어에서는 try-catch 같은 것을 사용해서 이런 종류의 작업을 할 수 있지만, Beam은 훨씬 더 세밀하고 정교한 방식으로 오류를 처리합니다.

루이스 필폴드: 네, 훨씬 더 세밀하고 정교한 방식으로 오류를 처리합니다. 그 결과 이 언어를 사용하는 회사들은 99.999%의 안정성을 주장할 정도로 매우 안정적인 서비스를 제공할 수 있습니다. 물론 그 주장을 입증하는 것을 본 적은 없지만, 그들이 그런 주장을 할 수 있고 사람들이 "어쩌면 그럴 수도 있겠다"라고 생각한다는 사실은 Beam이 얼마나 훌륭한지 보여주는 증거라고 생각합니다.

크리스 젠킨스: 맞아요. 그럴듯하다는 사실 자체가 Beam이 정말 훌륭하다는 것을 의미하죠. 그리고 공격적인 프로그래밍도 가능합니다. 오류를 전혀 확인하지 않고 모든 것이 성공할 것이라고 가정하는 것입니다. 오류가 발생하면 비즈니스 로직에 오류 처리 로직을 작성할 필요가 없죠. 비로컬 오류 처리라고 부르는 방식으로 처리할 수 있습니다.

루이스 필폴드: 네, 그런 방식이죠. 어떤 회사는 시스템이 100프레임마다 충돌하는 버그가 있었는데, 8개월 동안 눈치채지 못했다고 합니다. 시스템이 너무 잘 작동해서 아무런 문제도 느끼지 못했던 거죠. 100프레임마다 충돌하고 시스템이 다시 시작되면 작은 서브시스템만 다시 시작되고 나머지는 계속 작동했던 겁니다.

크리스 젠킨스: 그러니까 100프레임마다 다시 시작되고, 그 프레임만 다시 시도했던 거군요. 그들은 그 사실을 몰랐던 거고요. 모니터링을 개선해야 할 것 같네요. 하지만 프로덕션 환경에서 시스템을 실행할 때 사용자를 위해 계속 작동하도록 하고 싶지만, 문제가 발생했을 때 너무 스트레스를 받고 싶지는 않을 것입니다. 새벽 3시에 전화로 "당장 고쳐야 해!"라고 소리치는 사람들 때문에 깨고 싶지는 않을 테니까요. 최대한 스트레스를 덜 받는 방식으로 문제를 해결할 수 있어야 합니다.

루이스 필폴드: 맞아요. 처음부터 모니터링, 디버깅, 오류 처리 기능이 내장되어 있다는 점이 Beam의 매력입니다.

크리스 젠킨스: 네, 저도 Beam 플랫폼 때문에 Erlang을 살펴본 적이 있습니다. Erlang은 정말 이상해요. Lisp와 Haskell 프로그래머로서 하는 말입니다. Erlang은 정말 이상하죠. 그래서 매번 Erlang을 포기하게 됩니다.

루이스 필폴드: Erlang 런타임은 실제 요구 사항에서 비롯된 놀라운 속성을 가지고 있습니다. 예를 들어, 탐욕스러운 스레드, 탐욕스러운 그린 스레드가 스케줄러를 차단하고 문제를 일으키지 않도록 해야 합니다. 그래서 무한 루프가 있어도 모든 것이 계속 실행됩니다. 괜찮아요. 누군가 잘못된 정규식을 입력해도 스케줄러가 차단되지 않도록 해야 합니다. 무언가가 충돌해도 시스템에 영향을 미치지 않도록 해야 합니다. Erlang은 이러한 문제를 모두 해결했습니다. 놀랍죠. 하지만 언어 자체는, 저는 Erlang을 좋아하지만, 정말 끔찍해 보입니다. 보기도 안 좋고, 여러모로 불편하고, 도구도 이상해요.

크리스 젠킨스: 아까 복습하면서 살펴봤는데, 모듈에서 함수를 내보내려면 함수 이름 뒤에 인수 개수를 슬래시로 구분해서 써야 한다는 것을 잊고 있었어요.

루이스 필폴드: 네, my_start/1처럼 말이죠. 함수는 이름뿐만 아니라 인수 개수로도 고유하게 구분되기 때문입니다. 그래서 main/0, main/1, main/2, main/3은 모두 별개의 함수입니다.

크리스 젠킨스: 컴퓨터가 알아서 처리해 줄 수 있는 부분인 것 같아요.

루이스 필폴드: 맞아요. Gleam은 그렇게 처리하지만, 직접 제어할 수 있다면 실제로 더 많은 것을 할 수 있습니다. 실제로 더 강력하죠. 1개, 2개, 3개 중 어떤 것을 참조할지 결정할 수 있습니다.

크리스 젠킨스: 당신이 그런 건가요?

루이스 필폴드: 잘 모르겠어요. Erlang에서는 그 기능을 많이 사용합니다. 어떤 도구를 사용하든, 익숙해지면 용도를 찾게 되죠. 저는 Rust와 Elm 같은 언어를 좋아하지만, 다시 생각해 보니 그 기능이 그렇게 마음에 드는 것은 아닌 것 같아요. Erlang과 Elixir를 사용하는 사람들은 Gleam을 사용할 때 그 기능이 없다고 불평합니다. 어느 쪽이든 비판을 받게 되는 거죠. Gleam의 목표 중 하나는 Erlang에서 얻을 수 있는 멋진 것들을 우리에게 덜 낯설게 만드는 것입니다.

크리스 젠킨스: 그렇군요. 사람들이 견딜 수 있는 낯섦에는 한계가 있으니까요. 누군가 슈퍼 동시성, 내결함성 런타임에 대한 멋진 이야기를 듣고 Erlang에 관심을 가졌다가 갑자기 Erlang을 접하게 되면 "이건 너무 이상해. 낯섦이 호기심보다 크다. 다른 언어를 알아봐야겠다"라고 생각할 수도 있습니다.

루이스 필폴드: 네, 그래서 훨씬 더 평범해 보이는 언어를 원했어요. 어떤 면에서는 더 나쁠 수도 있지만, 더 많은 사람들이 사용할 수 있다면 그걸로 충분하다고 생각했습니다. 항상 장단점이 있죠.

크리스 젠킨스: 접근성이라는 단어를 사용합시다. 훨씬 더 좋아 보이니까요. 낯섦 대신 접근성.

루이스 필폴드: 낯섦 대신 접근성. 네, 맞아요.

크리스 젠킨스: 한번은 컨퍼런스가 끝나고 맥주를 몇 잔 마시고 용기가 생겨서 Erlang 개발자에게 "왜 이렇게 생겼어요?"라고 물어본 적이 있습니다. 그랬더니 "오픈소스하기 전에 봤어야 했는데. 훨씬 더 끔찍했어요."라고 대답하더군요.

루이스 필폴드: 상상도 안 가네요.

크리스 젠킨스: 조 암스트롱이었죠?

루이스 필폴드: 저는 베르딩에게 물어봤지만, 맞아요.

크리스 젠킨스: 좋아하는 언어의 기능을 모으고 있을 때, 처음부터 Erlang과 경쟁하거나 대체하거나 대안을 제시하고 싶었나요? Beam에서 말이죠.

루이스 필폴드: 저는 오랫동안 Beam 사용자였습니다. Elixir를 통해 Beam을 접했고, 얼마 지나지 않아 Erlang도 작성하게 되었죠. 두 언어 모두 꽤 좋아했습니다. Beam은 많이 사용되지 않는 런타임이었고, 저는 Beam을 정말 좋아했기 때문에 Gleam을 Beam에서 실행하는 것은 당연한 선택처럼 보였습니다. 사람들에게 유용할 수 있는 방법에 대해 생각하기도 전에, "이 런타임이 정말 마음에 들어. 아무도 사용하지 않을 내 이상적인 취미 프로그래밍 언어에 사용하고 싶어."라고 생각했죠.

처음부터 사람들을 위한 언어를 설계했다고 해도, 지금은 그렇게 생각하지만, 처음부터 그랬다고 해도 같은 결정을 내렸을 거라고 생각합니다. 하지만 Gleam이 Erlang과 경쟁한다고 생각하지는 않습니다. Erlang을 사용하는 사람들과 Gleam을 사용하는 사람들은 서로 다른 집단이라고 생각하기 때문입니다. 런타임에 관심은 있지만 "이상한 Prolog 혼합 구문에 동적 타이핑이고, Prolog도 아니고 이것도 아니고 저것도 아닌 이상한 패턴이 많아서 나랑은 안 맞아. Scala나 다른 언어를 써야겠다"라고 말하는 사람들이 많습니다. 그리고 "Elixir는 이상한 Ruby 구문을 사용해. 이상한 Lisp 매크로도 있고. 나랑은 안 맞아. 사용하지 않을 거야."라고 말하는 사람들도 많습니다. 이 두 가지를 좋아하지 않는 사람들은 C처럼 생긴 작은 함수형 언어, Elm 스타일의 타입 시스템을 가진 언어를 좋아할 수도 있습니다. 그래서 Erlang과 Elixir에서 많은 사람들을 끌어들이지는 못할 거라고 생각합니다. 오히려 Beam 커뮤니티 전체에 새로운 사람들을 데려올 수 있을 거라고 생각합니다.

크리스 젠킨스: 그러니까 Gleam과 Erlang, Elixir가 함께 성장하기를 바라는 거군요.

루이스 필폴드: 네, 그렇게 되기를 바랍니다. Gleam은 Gleam과 다른 언어 간의 상호 운용성을 중심으로 만들어졌습니다. 그래서 사람들이 Gleam으로 무언가를 작성하면 Erlang과 Elixir에서도 사용할 수 있기를 바랍니다. 반대로 Erlang과 Elixir로 작성된 것들을 Gleam에서도 사용할 수 있기를 바랍니다.

크리스 젠킨스: 양방향 상호 운용성은 종종 간과되는 부분이죠.

루이스 필폴드: 네, 맞아요. Gleam은 Erlang과 Elixir에서도 사용할 수 있고, Erlang과 Elixir에서도 Gleam 코드를 사용할 수 있습니다. 도구 지원은 아직 제가 원하는 만큼 좋지는 않습니다. Erlang과 Elixir 측에서 도구를 만들어야 하기 때문입니다. 하지만 방법은 있습니다.

크리스 젠킨스: Erlang과 경쟁하고 싶지 않다는 말씀이군요.

루이스 필폴드: 네, Erlang과 Elixir와 경쟁하고 싶지 않습니다. 왜 가장 가까운 이웃과 경쟁해야 하겠어요? 함께 일하고 싶습니다. 더 많은 언어들이 그렇게 생각했으면 좋겠어요. Erlang은 플랫폼의 보편적인 언어이기 때문에 양방향으로 작업하기가 꽤 쉽지만, Elixir는 Erlang 코드를 사용할 수 있도록 설계되었지만, Erlang에서 Elixir 코드를 사용하는 것은 훨씬 더 까다롭고, 사용할 수 없는 기능도 있습니다.

크리스 젠킨스: 그건 어쩔 수 없는 부분이죠.

루이스 필폴드: 네, 맞아요.

크리스 젠킨스: 언젠가는 상호 운용성이 가능한 유니버설 컴퓨팅 시대가 올 것입니다. 하지만 취미로 프로그래밍 언어를 만들어 본 프로그래머들을 몇 명 알고 있는데, 프로그래밍을 오래 하다 보면 한 번쯤은 겪는 통과 의례 같은 거죠. 그 과정에서 두 가지를 깨달았습니다. 첫째, 프로그래밍 언어는 마법이 아닙니다. 소스 코드를 평가하는 프로그램을 작성하는 것은 실제로 매우 흥미롭고 그렇게 어렵지 않습니다. 하지만 취미 프로젝트에서 실제로 프로덕션 환경에 적용할 수 있는 무언가를 만드는 과정은 엄청납니다. 그 과정에 대해 말씀해 주시겠어요?

루이스 필폴드: 제 생각에는 그냥 제 고집 때문인 것 같아요. 기술을 잘 모르는 사람들에게는 차고에 모형 철도를 만드는 사람처럼 보였을 겁니다. 여러 층으로 이루어진 매우 크고 화려한 모형 철도, 실제와 똑같은 모형 철도 말이죠. 보는 사람들은 "왜 이런 짓을 했지? 정말 대단하지만, 시간이 엄청나게 걸렸겠네."라고 생각할 겁니다.

크리스 젠킨스: 네, 그렇죠.

루이스 필폴드: 하지만 저는 그냥 호기심 때문에 시작했어요. 언어를 좋아하고, 파고들 수 있는 부분이 너무 많았거든요. 그래서 몇 년 동안 흥미를 잃지 않고 계속 작업할 수 있었어요. 처음 2년 정도는 그랬죠. 하지만 운 좋게도 저는 이미 Erlang과 Elixir 세계에서 꽤 유명했습니다. Elixir를 꽤 일찍 접했고, Ruby나 Elm에서 사용하던 기능이 없어서 "정말 아쉽다. 만들어 볼까?"라고 생각했죠. 그래서 linter를 만들었는데, 나중에 포크되어서 지금은 Elixir 시스템의 메인 linter가 되었습니다. 유지 관리할 필요가 없어서 정말 좋죠.

크리스 젠킨스: 오픈소스로 공개하고, 세상에 내놓으면 끝이죠.

루이스 필폴드: 네, 맞아요. 제가 만든 것보다 훨씬 더 좋지만, 원래는 제 것이었죠. 그리고 formatter도 만들었어요. Elm format이 너무 멋져서 Elixir에도 formatter를 만들고 싶었거든요. 그래서 공식 formatter가 만들어지는 데 영감을 주었습니다. 이런 일들을 통해서 저는 조금 알려지게 되었죠. 그리고 언어를 만들기 시작했을 때, 타입 시스템 같은 유행하는 단어들을 많이 사용했더니 사람들이 "오, 흥미롭네."라고 반응하기 시작했습니다. 그리고 사람들이 조금씩 이야기하기 시작했죠. 저는 항상 오픈소스 개발을 고집했기 때문에, 제가 홍보하지 않아도 사람들이 제 프로젝트를 보고 "이것 좀 봐."라고 말했죠.

크리스 젠킨스: 네.

루이스 필폴드: 그러면서 저는 더 많은 격려를 받았습니다. 사람들이 제 작업에 관심을 보이면 더 많은 격려를 받고, 계속 작업하고 싶은 마음이 생기죠. 그리고 천천히 "어쩌면 이게, 어쩌면 이게 몇 년 동안 작업한 결과물이 사람들에게 유용할 수도 있겠다"라고 생각하게 되었습니다. 그리고 지금은 사람들이 Gleam을 사용하고 있습니다. 정말 놀랍죠.

크리스 젠킨스: 네, 정말 놀랍네요. 그 과정에서 많은 것을 해냈을 텐데요. 타입 시스템을 추가하는 것만 해도 엄청난 작업이죠. Beam은 이전에 타입 언어를 지원한 적이 없었으니까요.

루이스 필폴드: 네, 맞아요. 정말 힘들었어요. 저는 항상 타입이 있는 언어를 좋아했지만, 타입 시스템이 어떻게 작동하는지 전혀 몰랐거든요. Gleam이 잘 되고 있는 이유 중 하나는 제가 타입 시스템 구현 이론에 대해 학문적인 지식이 없는 사람이기 때문이라고 생각합니다. 저는 언어 컴파일러 구현자나 런타임 구현자라기보다는 언어 설계자에 가깝습니다. 정말 흥미로운 분야라고 생각하지만, 저는 항상 특정 기능을 원할 때만 학습했습니다. 예를 들어, "언어에 이런 기능이 있으면 어떨까?"라고 생각하고, 그 기능이 있는 것처럼 코드를 많이 작성한 다음, 머릿속으로 컴파일해 보는 거죠. "이렇게 하면 어떻게 될까? 어떻게 작동할까? 이 프로그램을 어떻게 작성할 수 있을까?"라고 생각하면서요. 그리고 그 과정을 계속 반복했습니다.

크리스 젠킨스: 그러니까 "이 기능을 원해. 사람들은 이걸 할 수 있다는 걸 알아. 어떻게 해야 하지?"라고 생각하고, 적절한 수준의 이해하기 쉬운 논문을 찾아서 연구했군요.

루이스 필폴드: 네, 정말 힘들었지만, 이제는 타입 시스템에 대해 조금 알게 되었습니다.

크리스 젠킨스: 그럼 이제 시험에 합격할 수 있겠네요?

루이스 필폴드: 그럴 수 있을지는 모르겠네요. 단기 기억에 저장되어 있지 않아요. Gleam에 있는 기능은 잘 알지만, Gleam에 없는 기능은 전혀 모릅니다. 좀 답답하죠. 기능을 구현하고 나면 그 기능에 대해 충분히 이해하게 되지만, 언어를 위해서는 다른 관련 없는 작업을 해야 하기 때문에 더 이상 그 기능에 대해 배우지 못하게 되거든요. Gleam은 언어뿐만 아니라 빌드 도구, 패키지 관리자, 언어 서버, 패키지 인덱스 등 일반적으로 사용하는 모든 것을 핵심 프로젝트의 일부로 간주합니다. 그래서 언어와 컴파일러만 있는 것이 아니라, 빌드 도구, 패키지 관리자, 언어 서버, 패키지 인덱스 등도 있습니다. 이러한 것들을 커뮤니티에 맡기는 대신, Gleam에 내장되어 있습니다. 그 결과 정말 좋은 경험을 제공하지만, 저는 타입 시스템에 대해 흥미로운 것을 배우고 나면 의존성 해결 알고리즘을 작업해야 합니다. 결국 어느 것도 제대로 배우지 못하게 되는 거죠.

크리스 젠킨스: 그 모든 것을 어떻게 관리하시나요? 각각의 요소가 하나의 프로젝트가 될 수 있잖아요. 처음부터 패키지 관리자를 만들고 제대로 작동하게 하는 것은 쉬운 일이 아닙니다. 그런 일을 하는 팀도 있죠.

루이스 필폴드: 네, 맞아요. 패키지 관리는 다행히도 조금 속일 수 있습니다. Beam 언어의 나머지 부분과 잘 상호 작용하려면 Beam의 패키지 관리자를 사용해야 합니다. 그래서 서버 측 작업, 즉 업로드 및 배포는 이미 누군가가 만들어 놓았기 때문에 우리는 API만 사용하면 됩니다. 하지만 아무도 그 API를 제대로 통합한 적이 없어서 문서가 좋지 않습니다.

크리스 젠킨스: 그렇군요.

루이스 필폴드: 그래서 클라이언트 측만 구현하면 된다는 것을 알았지만, 그래도 여전히 매우 복잡합니다. 여러 제약 조건을 가진 버전을 찾는 알고리즘은 꽤 어렵습니다.

크리스 젠킨스: 하지만 많은 부분은 스타트업처럼 "각 요소의 MVP는 무엇일까? 가장 작고 유용한 접근 방식은 무엇일까?"라고 생각하면서 해결할 수 있습니다. 작은 언어를 만드는 것이 사용자 경험을 개선하는 데 도움이 되지만, 구현하기도 훨씬 쉽습니다. Rust나 Scala처럼 만들려고 했다면 절대 불가능했을 겁니다. 하지만 Lua나 Go처럼 만들려고 하기 때문에 가능한 거죠.

크리스 젠킨스: 네, 맞아요. 고양이 소리가 들리네요.

루이스 필폴드: 행복한 녀석이죠.

크리스 젠킨스: 당신의 설계 과정을 조금 살펴봤는데, 당신은 "판타지 프로그래밍 설계"를 하고 있다고 말했죠. 그리고 트위터에 가서 "이 동작에 어떤 구문을 사용할 것으로 예상하시나요?"라고 묻고, 디자인에 대한 정기적인 트위터 설문 조사를 실시하고, 언어를 작게 유지하고 있습니다. 그렇게 하면 특정 설계 선택을 할 수 있습니다. 조화로운 언어를 만드는 데 중요한 것은 무엇인가요? 어떤 언어는 잘하고, 어떤 언어는 못하는데, 당신은 어떻게 접근하시나요?

루이스 필폴드: 설문 조사는 정말 유용합니다. 저는 사람들이 놀라지 않도록, 즉 접근성을 높이려고 노력하고 있기 때문입니다. 하지만 저는 무엇이 정상이고 무엇이 정상이 아닌지에 대해 종종 틀린다는 것을 알게 되었습니다. 자신의 의견이 표준이라고 생각하기 쉽지만, 그렇지 않죠. 그래서 "이 두 가지 중 어느 것이 덜 이상해 보이나요?"라고 직접적으로 묻는 대신, 몇 가지 예제 코드에 대해 간단한 질문을 던져서 사람들이 어떤 부분에서 혼란스러워하는지 확인하는 것이 정말 유용합니다. 제가 더 나은 아이디어라고 생각하더라도, 제가 틀렸을 가능성이 높습니다.

크리스 젠킨스: 그렇군요.

루이스 필폴드: 하지만 꽤 까다로운 문제입니다. 천천히, 정말 천천히 작업하는 것이 도움이 된다고 생각합니다. Gleam은 작은 언어이고, 제가 대부분의 작업을 직접 하기 때문에 많은 시간을 할애할 수 있습니다. 패키지 관리자를 작업하고 있다면 6개월 전에 이미 아이디어를 떠올렸을 것입니다. 하지만 여전히 6개월 동안 패키지 관리자를 작업하고 있습니다. 그래서 1년 동안 "이렇게 하면 어떨까? 이렇게 하면 어떤 영향을 미칠까?"라고 생각하면서 아침 식사를 하면서 창밖을 바라보는 시간을 보내게 됩니다. 머릿속에서 아이디어를 천천히 끓이는 거죠. 12개월 동안 그렇게 생각하다 보면 "아, 이렇게 하면 이런 식으로 상호 작용하겠네. 흥미롭군. 저건 어떨까?"라는 생각이 떠오르는 순간이 생깁니다. 그리고 결국에는 오랜 시간 동안 집착적으로 생각하다 보면 모든 것을 우연히 다루게 됩니다. 느린 프로그래밍이죠.

크리스 젠킨스: 그게 당신의 방식이군요. 느리지만 집착적인 방식.

루이스 필폴드: 네, 생각을 멈추지 않고 오랜 시간을 투자하는 거죠.

크리스 젠킨스: 이름을 언급하지는 않겠지만, 개발자가 아침에 일어나서 새로운 기능 아이디어를 떠올리고 최대한 빨리 만들어서 세상에 내놓은 것처럼 보이는 언어들이 있습니다. 그리고 훨씬 더 조화로운 느낌을 주는 언어들이 있죠.

루이스 필폴드: 네, 맞아요. 저는 조화로운 언어를 만들고 싶습니다. 아이디어를 떠올리고, 만들어서, 세상에 내놓는 것은 정말 멋진 일이죠. 언젠가 Gleam을 완성하고, Gleam 재단에 넘겨서 관리하도록 하고, 저는 Gleam을 만들면서 포기했던 나쁜 아이디어들을 모아서 새로운 언어를 만들고 싶습니다.

크리스 젠킨스: 그렇군요.

루이스 필폴드: 항상 "이건 별로야. 하지 말자"라고 생각하는 아이디어들이 있지만, 정말 나쁜 아이디어들은 "오, 이거 정말 좋은데? 해보자"라고 생각하고 나서 "음, 잘 모르겠네. 확실하지 않아"라고 생각하게 되는 아이디어들입니다. 항상 멋져 보이는 아이디어들이죠.

대수적 효과가 위험하게 좋아 보이는 아이디어 중 하나입니다. 대수적 효과를 사용하면 async/await, 예외, try-catch 등을 사용자 영역에서 모델링할 수 있습니다. 정말 강력한 기능이죠. 앞으로 많은 언어들이 어느 정도 대수적 효과를 지원하게 될 것이고, 결국에는 일반적인 기능이 될 것입니다. 그래서 대수적 효과는 위험한 아이디어입니다. "멋진데?"라고 생각하기 쉽지만, 실제로 프로젝트의 목표와 일치하는지 생각해 봐야 합니다. 정말 간단하고 접근하기 쉬운 언어를 만들려고 하는데, 실험적이고 매우 복잡한 몇몇 언어에서만 사용되는 매우 강력한 도구를 추가하는 것은 좋은 생각이 아닐 수 있습니다.

크리스 젠킨스: 네, 맞아요.

루이스 필폴드: 그리고 Elixir와의 상호 운용성도 완전히 망가뜨릴 것입니다. 그래서 별로 좋은 생각이 아니라고 생각합니다.

크리스 젠킨스: 대수적 효과는 나중에 다시 살펴보고 싶지만, 지금은 크리스 젠킨스: 일단 보류하는 것이 현명한 선택인 것 같네요. 그럼 Gleam을 배우기 시작하려는 사람들에게 어떤 부분을 알려줘야 할까요? Gleam을 배우려면 어떤 부분을 알아야 할까요?

루이스 필폴드: 지금 그 부분을 고민하고 있어요. Gleam 학습 코스를 만들려고 하거든요.

크리스 젠킨스: 아, 그렇군요.

루이스 필폴드: Erlang 생태계 재단에서 자금을 지원받았습니다. 정말 멋진 단체인데, Gleam 커뮤니티를 성장시키기 위해 Exercism이라는 플랫폼에 강의 계획서를 만들려고 합니다. Exercism은 다양한 언어를 연습하고 배우는 플랫폼입니다.

크리스 젠킨스: 네, 알고 있어요.

루이스 필폴드: 2월에 Exercism에 정규 트랙을 런칭했습니다. Exercism에서 Gleam을 주요 언어로 선정해 주었는데, 정말 감사한 일이죠. 기본적으로 "여기 작은 프로그램과 과제가 있습니다. 해결해 보세요."라는 식으로 진행됩니다. 자동으로 테스트를 실행할 수 있고, 커뮤니티 회원의 멘토링도 받을 수 있습니다. 정말 멋진 사이트예요. 어떤 언어든 연습하고 싶다면 Exercism을 추천합니다. Exercism에는 강의 계획서라는 또 다른 레이어가 있습니다. 과제뿐만 아니라 언어의 개별 개념을 가르치는 특별 과제도 있습니다. 잘 만들어진 강의 계획서가 있다면 프로그래밍 경험이 없는 사람도, 물론 프로그래밍에 대한 기본 지식은 있어야 하지만, 코스를 통해 언어를 사용할 수 있는 수준까지 도달할 수 있습니다. 정말 멋진 일이죠.

Gleam을 배우려면 무엇을 알아야 할까요? 별로 많지 않습니다. Gleam은 작은 언어이기 때문에 쉬운 모드로 플레이하고 있다고 할 수 있습니다. 하지만 대부분 함수, 값, 패턴 매칭, 레코드 등 기본적인 것들입니다.

크리스 젠킨스: 알겠습니다. 하지만 Erlang은 액터 기반인데, Gleam도 액터 모델을 깊이 사용하나요?

루이스 필폴드: 아니요. Erlang의 액터 프레임워크인 OTP에 대해 이야기할 때는 항상 조심해야 합니다. Erlang도 꽤 작은 언어이기 때문입니다. 이상하지만 꽤 작은 언어예요.

크리스 젠킨스: 그렇군요.

루이스 필폴드: 그래서 Erlang을 배우면 Erlang을 배우는 데 이만큼 시간을 쓰고, 액터 프레임워크를 배우는 데 이만큼 시간을 씁니다. 액터 프레임워크는 다른 언어의 async/await이나 동시성 모듈보다 훨씬 더 크기 때문입니다. 여러모로 운영 체제에 가깝습니다. 독립적인 요소들이 서로 통신하는 방식, 서로를 돌보고 오류를 처리하는 패턴 등이 있습니다. 정말 복잡합니다. Erlang을 통해 Beam 프로그래밍을 접하면 액터 프레임워크를 보는 데 많은 시간을 할애하게 될 것입니다. Erlang 커뮤니티에서는 액터 프레임워크가 매우 중요하기 때문입니다.

하지만 Elixir를 통해 Beam 프로그래밍을 배우면 일반적인 비즈니스 프로그래밍에 훨씬 더 집중하게 됩니다. 웹 앱, 웹사이트, 데이터베이스 관리 등을 만드는 거죠. 코드가 모두 액터 프레임워크 내부에서 실행되지만, 실제로는 액터를 볼 일이 없을 수도 있습니다. 데이터가 있는 것은 아니지만, 대부분의 Elixir 프로그래머는 OTP 코드를 전혀 작성하지 않는다고 생각합니다. Elixir 프로그래머들은 인기 있는 웹 프레임워크에 포함된 웹 서버를 사용하고, 웹 서버에는 내부적으로 많은 액터가 있습니다. pub/sub 시스템도 액터이고, 다른 모든 것도 액터입니다. 하지만 Elixir 프로그래머들은 웹 핸들러, 데이터베이스 연결 등을 작성하기만 하면 됩니다. 모든 것이 액터이지만, 신경 쓸 필요가 없습니다. Ruby on Rails나 Python으로 애플리케이션을 작성하는 것과 매우 비슷합니다. 코드 내부에 async/await조차 없습니다. 모든 것이 핸들러 외부에서 처리되기 때문입니다.

크리스 젠킨스: 그렇군요. 저는 Erlang을 제대로 사용하려면 액터 모델을 이해해야 한다고 생각했는데, 나중에 Gleam에 익숙해지면 액터 모델을 선택적으로 사용할 수 있다는 말씀이군요.

루이스 필폴드: 네, 맞아요. 그리고 액터 모델을 사용하지 않을 수도 있습니다. 액터 모델이 async/await이나 콜백, future보다 좋은 점은 각 액터가 하나의 작업만 수행하기 때문에 완전히 단일 스레드라는 것입니다. 요청 객체에서 본문을 가져오는 코드를 작성할 때 async를 사용하지 않고 스레드를 차단합니다. 그리고 데이터베이스와 통신할 때도 async를 사용하지 않고 스레드를 차단합니다. 응답을 보낼 때도 async를 사용하지 않고 스레드를 차단합니다. 매우 비효율적으로 보이지만, 실제로는 그렇지 않습니다. 운영 체제 스레드 전체를 차단하는 것처럼 보이지만, 실제로는 하나의 액터만 차단하기 때문입니다. 수백, 수천 개의 액터를 동시에 실행할 수 있습니다. 그리고 사람들은 일상적으로 그렇게 합니다.

크리스 젠킨스: Beam 스케줄러에서는 매우 일반적인 일이죠?

루이스 필폴드: 네, 매우 일반적입니다. 당연히 그렇게 해야 합니다.

크리스 젠킨스: 그렇군요.

루이스 필폴드: 조 암스트롱은 동시에 백만 개의 요청을 처리할 수 있는 웹 서버를 만드는 것은 정말 어렵지만, 하나의 요청을 처리할 수 있는 웹 서버를 만드는 것은 정말 쉽고, 그런 웹 서버를 백만 개 실행하면 된다고 말했습니다. 이것이 Erlang OTP 액터의 핵심 아이디어입니다. 가장 작은 작업 단위에서 정말 간단한 작업을 수행하고, 완전히 다른 곳에서 멀티플렉싱하는 것입니다. 그리고 문제가 발생했을 때 "어떻게 하면 상태의 일부를 버리고 다른 부분에 영향을 미치지 않을 수 있을까?"라고 고민할 필요가 없습니다. 그냥 작은 상자 하나를 버리면 됩니다. 나머지는 괜찮습니다.

크리스 젠킨스: 프로그래밍에서 제가 좋아하는 부분 중 하나입니다. 같은 문제를 다른 방식으로 보면 정말 흥미로운 결과를 얻을 수 있습니다.

루이스 필폴드: 네, 맞아요.

크리스 젠킨스: 시간을 내서 Gleam을 써봐야겠네요.

루이스 필폴드: 네, 꼭 써보세요.

크리스 젠킨스: 두 가지 더 묻고 싶은 것이 있는데, 먼저 생계 유지에 대해 이야기해 볼까요? 당신은 Gleam을 개발하기 위해 여러 가지 일을 했는데, 그중에는 가난하게 사는 것도 포함되어 있죠?

루이스 필폴드: 네, 맞아요. 좋은 경험이었죠.

크리스 젠킨스: 독립적인 언어 설계자로 사는 것은 어떤가요?

루이스 필폴드: 힘들죠. 전통적으로는 직장에서 일하면서 점점 더 일에 짜증이 납니다. 직장이 나빠서가 아니라, 다른 일을 하고 싶어서 저녁과 주말에 다른 일을 하다 보면 어느 순간 "그만두고 Gleam에 전념해야겠다"라고 생각하게 됩니다. 그리고 은행 잔고가 줄어드는 것을 지켜보죠. 어느 순간 "월세가 이만큼이고, 은행 잔고가 이만큼이니까, 30일 안에 직장을 구해야겠다"라고 생각하게 됩니다.

크리스 젠킨스: 그렇군요.

루이스 필폴드: 그런 일을 두세 번 반복했습니다. 하지만 어느 순간 GitHub에서 GitHub Sponsors 프로그램을 출시했습니다. 프로그래머를 위한 Patreon 같은 거죠. 사람들이 "GitHub Sponsors에 가입해 보세요."라고 말했고, 저는 "이 프로젝트가 나를 부양할 수 있을 거라고는 생각도 못 했는데."라고 생각했습니다. 오픈소스로 돈을 버는 것은 불가능하다고 생각했거든요. 매우 복잡한 것을 판매하지 않는 한 말이죠.

그래서 GitHub Sponsors에 가입했는데, 놀랍게도 몇몇 사람들이 저를 후원하기 시작했습니다. "와, 정말 놀랍다. 이 정도로 지지해 주는 사람들이 있었구나."라고 생각했죠. 그리고 마케팅을 조금 더 하고, 좋은 글을 쓰는 데 집중하기 시작했습니다. Gleam이 어떻게 작동하는지, Gleam 세계에서 무슨 일이 일어나고 있는지에 대한 블로그 게시물을 더 많이 작성했습니다. 사람들이 Gleam의 소식을 계속 접할 수 있도록 말이죠. 그리고 후원자가 꾸준히 늘어나서, 이전에 했던 어떤 직업보다 수입은 훨씬 적지만, 생활비를 충당할 수 있을 정도가 되었습니다.

크리스 젠킨스: 그렇군요.

루이스 필폴드: Gleam을 성공시키고, Gleam을 존재하게 하고, 상사 없이 일하기 위해 얼마나 많은 돈을 희생할 의향이 있느냐는 질문에 대한 답이죠. 제가 좋아하는 일을 할 수 있다는 것은 좋은 거래입니다. 그래서 지금은 돈은 적지만, Gleam을 만들 수 있습니다. 정말 좋죠. 그리고 항상 부수입을 찾고 있습니다. Gleam과 관련된 일이면서 돈도 벌 수 있는 일이 있다면, Gleam을 더 지속 가능하게 만들 수 있기 때문에 할 만한 가치가 있습니다. 보조금 신청 같은 것도 좋은 예입니다. 아까 말씀드렸던 Erlang 생태계 재단의 Gleam 학습 코스 제작 보조금이 좋은 예입니다. 그런 일을 더 많이 하고 싶습니다.

크리스 젠킨스: 멋지네요. 돈에 대한 질문이라서 거절하셔도 되지만, GitHub Sponsors 후원자는 대부분 개인인가요, 아니면 기업인가요? 몇 명 정도 되나요?

루이스 필폴드: 거의 전부 개인입니다. 가장 큰 후원자는 배포 플랫폼인 Fly.io입니다.

크리스 젠킨스: 아, 그렇군요.

루이스 필폴드: 정말 좋은 제품입니다. 꼭 그렇게 말해야 하는 것은 아니지만, 정말 좋아요. 써보세요. 저도 쓰고 있습니다.

크리스 젠킨스: 네, 알겠습니다.

루이스 필폴드: 개발자 경험이 좋고, Firecracker VM을 사용하는데, 정말 똑똑한 방법이라고 생각합니다.

크리스 젠킨스: 그렇군요.

루이스 필폴드: 하지만 Fly.io에서 전체 후원금의 3분의 1 정도, 어쩌면 3분의 1보다 조금 더 많은 금액을 후원하고 있고, 나머지는 1달러, 5달러, 10달러 정도를 후원하는 사람들입니다. 그리고 100달러를 후원하는 사람들도 몇 명 있는데, 정말 놀랍습니다.

제 이상적인 상황은 Gleam을 사용하는 회사들이 모두 Gleam을 지원하기 위해 소액의 돈을 후원하는 것입니다. 기업 입장에서는 큰돈이 아니지만, Gleam을 유지하는 데 큰 도움이 될 것입니다. 기업들은 자신들이 사용하는 오픈소스 프로젝트를 지원하기 위해 소액의 돈을 기부해야 한다고 생각합니다. 그러면 저도 훨씬 덜 불안할 것입니다. 한 회사에 크게 의존하는 것보다 수십 개의 회사에서 소액의 돈을 후원받는 것이 훨씬 안정적이죠. Fly.io는 정말 훌륭하고, 앞으로도 계속 Gleam을 지원해 주기를 바랍니다. 정말 감사하지만, Fly.io가 Gleam을 지원할 의무는 없습니다. 언젠가 Fly.io가 다른 일을 하기로 결정할 수도 있고, 그러면 저는 곤란해질 것입니다.

크리스 젠킨스: Elm 개발자는 Elm을 많이 사용하는 회사에 취직해서 사내 언어 개발자로 일하고 있습니다. 당신도 그런 제안을 받은 적이 있나요?

루이스 필폴드: 몇몇 회사에서 제안을 했지만, 제가 별로 긍정적인 반응을 보이지 않아서 진행되지는 않았습니다. 하지만 몇몇 회사에서 조심스럽게 제안을 했습니다. 하지만 한 회사가 언어에 너무 많은 투자를 하거나 언어에 대한 통제권을 가지는 것은 언어의 발전 방향에 큰 영향을 미칠 수 있다고 생각합니다. 저는 그런 상황을 원하지 않습니다. 물론 후원자가 "우리에게는 이런 문제가 있으니 이런 기능을 추가해 주세요."라고 말하면, 저는 일반적으로 그 요구에 맞춰 백로그를 조정합니다. 하지만 고용주가 그렇게 말하면, 더 이상 제 결정이 아니고, 제가 무엇이 최선이라고 생각하는지 결정할 수 없습니다. 의무감을 느끼게 될 것입니다. 그리고 Gleam 커뮤니티와 미래의 Gleam 사용자에게 최선의 선택을 할 수 있을지 확신할 수 없습니다.

이론적으로는 Gleam 프로젝트가 앞으로 수십 년 동안 계속될 것입니다. 제가 Gleam을 그만두고 나서도 계속될 것입니다. 그래서 오늘날 어떤 회사가 필요로 하는 것은 그렇게 중요하지 않습니다. 저는 그런 것들을 최대한 분리하고 싶습니다.

크리스 젠킨스: 그러면 당신은 "자비로운 종신 독재자"를 목표로 하고 있다는 말씀인가요?

루이스 필폴드: 저는 항상 "악의적인 종신 독재자"라고 농담합니다.

크리스 젠킨스: 개발자에 따라 다르죠.

루이스 필폴드: Elm 개발자인 Evan은 이 주제에 대해 좋은 글을 썼습니다. 언어뿐만 아니라 기술 프로젝트 초기에 단일 리더십이 있는 것이 좋다는 내용입니다. 물론 좋은 리더를 만나야 한다는 전제가 있지만, 단일 리더가 있으면 의사 결정 과정이 훨씬 더 일관성 있게 진행될 수 있습니다. 논쟁이나 갈등 없이 말이죠. 그렇게 하면 프로젝트가 충분히 성숙해졌을 때 "이제는 개척보다는 관리가 더 중요하다"라고 생각할 수 있습니다. 그 시점에서는 리더십을 분산할 수 있습니다. 아직 Gleam은 그 단계에 이르지 못했습니다. 거의 다 왔지만요. Elm은 한 사람에게 너무 많은 부담을 주어서 그 단계에 이르기 전에 지쳐버린 것 같습니다.

크리스 젠킨스: 네, Elm에 대해서는 잘 모르지만, 어느 순간 업데이트가 멈춘 것 같습니다. Evan은 분명히 매우 똑똑한 사람이지만, 그가 말했듯이 지쳐버린 것 같습니다. 그는 자신이 만든 것에 대해 높은 수준의 통제권을 가지고 싶어하는 것 같습니다. 그런 상황에 있는 모든 사람들이 그렇겠지만요. 하지만 위임은 매우 중요합니다. 저는 오픈소스 덕후입니다. 제가 늙었다는 뜻은 아니지만, 오랫동안 오픈소스 덕후였습니다. 그래서 창작의 커뮤니티적 측면을 매우 중요하게 생각합니다. Gleam의 많은 부분이 커뮤니티와의 상호 작용 방식, 이슈 관리 방식, 사람들이 참여하고 무언가를 만들 수 있도록 돕는 방식에서 비롯되었습니다.

크리스 젠킨스: 그렇군요.

루이스 필폴드: 누군가가 저에게는 하기 힘든 멋진 작업을 해서 제 시간을 절약해 주는 경우도 있고, 누군가가 pull request를 보냈는데 별로 좋지 않아서 제가 도와서 완성하는 경우도 있습니다. 제가 직접 하는 것보다 시간이 훨씬 더 오래 걸리지만, 그 사람은 좋은 경험을 하고 커뮤니티의 일원이 됩니다. 둘 다 좋은 일입니다. 이 두 가지 모두를 성장시키고, 다른 모든 상호 작용을 통해 커뮤니티를 성장시키는 것이 매우 중요합니다. 그러면 내일 제가 사라지더라도, 물론 그럴 일은 없지만, Gleam은 계속될 것입니다.

크리스 젠킨스: 사람들이 도구를 기여하고, 언어 자체에 기여하고, 설계 결정에 참여하고 있나요? 당신에게서 얼마나 분산되어 있나요?

루이스 필폴드: 컴파일러 개발의 대부분은 제가 직접 하고 있습니다. 하지만 커뮤니티는 대부분 Discord에서 활동하고 있습니다. 정말 멋진 곳입니다. Discord 커뮤니티는 정말 친절하고 쾌활한 사람들로 가득합니다.

크리스 젠킨스: 그렇군요.

루이스 필폴드: 사람들은 그냥 Discord에서 어울리려고 합니다. 어떤 사람들은 언어 개발과 도구에 관심이 많아서 적극적으로 참여합니다. 멋진 라이브러리를 만들기도 하고, 학술적인 글을 쓰는 사람들도 있습니다. 언어 기능과 언어 기능 간의 상호 작용에 대한 긴 글을 쓰고, 논문을 참조하기도 합니다. 그리고 Gleam을 사용하는 사람들은 대부분 자신이 만든 라이브러리를 공유하거나 취미 프로젝트를 보여줍니다. 그리고 Gleam을 사용하지 않는 사람들도 있습니다. 그냥 커뮤니티가 좋아서 Discord에 있는 거죠. Gleam이 아니라 사람들이 좋아서 Discord에 있는 겁니다. "Gleam을 써본 적 있어요?"라고 물으면 "네, 한 번 설치해 봤어요. 실행해 본 적은 없지만요."라고 대답합니다. 하지만 그래도 괜찮습니다. 우리가 뭔가 제대로 하고 있다는 증거라고 생각합니다. 커뮤니티를 만들고 있다는 증거죠.

크리스 젠킨스: 네, 맞아요. 정말 좋은 신호입니다. 언젠가는 후원금으로 100에이커 규모의 목장을 사서 Gleam 커뮤니티 전체가 함께 살면서 목장 일을 할 수 있을 것 같네요.

루이스 필폴드: 네, 맞아요. 프로그래머들이 은퇴 후에 갈 수 있는 곳이죠.

크리스 젠킨스: 루이스 필폴드 은퇴자 마을이군요.

루이스 필폴드: 농장에서 사는 거죠. 좋네요.

크리스 젠킨스: Gleam의 미래는 어떻게 될까요? 2년 후에 Gleam을 보면 흥미로운 새 기능이 추가되어 있을까요? 루이스 필폴드가 GleamConf의 사회를 보고 있을까요?

루이스 필폴드: 최근에 컨퍼런스에서 발표를 줄이기로 했습니다. 발표하는 것을 좋아하지만, 발표 준비에 시간이 너무 많이 걸리기 때문입니다. 어떤 사람들은 기차에서 발표 자료를 만들기도 하지만, 저는 어렸을 때 연극을 많이 해서 그런지, 항상 대본을 쓰고 리허설을 하고 수정하는 과정을 거칩니다. 시간이 너무 많이 걸리죠. 블로그 게시물을 쓰는 것이 훨씬 빠르고, 더 많은 사람들이 읽습니다. 그리고 두 번째 블로그 게시물을 쓰거나, Gleam 기능을 개발할 수 있습니다. 지금은 Gleam이 많은 관심을 받고 있고, 좋은 모멘텀을 가지고 있습니다. GitHub에서 F#보다 별점이 더 많습니다. 정말 이상하죠.

크리스 젠킨스: 와, 정말 대단하네요. 어떻게 된 거죠?

루이스 필폴드: 지금이 Gleam을 밀어붙일 때입니다. 그래서 시간을 효율적으로 사용해야 하고, 지금은 컨퍼런스에 참석할 때가 아닙니다. 하지만 누군가 GleamConf를 개최한다면, 저는 꼭 참석할 것입니다.

2년 안에 Gleam은 완성된 언어처럼 보일 것입니다. 더 이상 기능이 추가되지 않는다는 뜻은 아니지만, Gleam 1.0 버전에 필요하다고 생각했던 모든 기능이 추가될 것입니다. 항상 저 멀리 수평선에 있는 산처럼 보였는데, 이제는 언덕처럼 보입니다. 여전히 크지만, 수평선에 있습니다. 정말 흥미롭죠. 그리고 "이제 1.0 버전을 출시할까? 컴파일러와 언어뿐만 아니라 빌드 도구, 언어 서버 등도 포함된 바이너리에서 1.0 버전은 무엇을 의미할까? 빌드 도구와 언어 서버는 0.x 버전으로 유지하고 언어 자체만 1.0 버전으로 출시할까?"라는 질문에 대한 답을 찾아야 합니다.

크리스 젠킨스: 그렇군요.

루이스 필폴드: 미묘한 부분이 많습니다. 사람들이 Gleam을 어떻게 사용하고 있는지, 프로덕션 환경에서 Gleam이 어떻게 작동하는지에 대한 데이터를 더 많이 수집하고 싶습니다. Gleam의 디자인이 좋다고 생각하지만, 2년 후에 사람들이 "이 부분이 정말 별로예요."라고 말할 수도 있습니다. 그러면 "알겠습니다. 고치겠습니다."라고 대답할 수 있죠. 1.0 버전을 출시한 후에 그런 문제가 발견되는 것보다 1.0 버전을 출시하기 전에 그런 문제를 해결하는 것이 좋습니다.

크리스 젠킨스: 그러니까 1.0 버전을 출시하기 전에 주요 기능들이 프로덕션 환경에서 충분히 검증되기를 바라는군요.

루이스 필폴드: 네, 그렇습니다. 데이터를 더 많이 수집하고 싶습니다. 데이터는 많을수록 좋습니다. 어떤 결정을 내릴 때 확신이 서지 않는다면, 조금 더 기다리세요. 더 많은 생각을 하고, 더 많은 사람들과 이야기하고, 더 많은 실험을 해보세요. Gleam 커뮤니티에 가입해서 액터를 여러 개 생성하고 어떤 액터가 깨지는지 확인해 보세요.

크리스 젠킨스: 네, 맞아요.

루이스 필폴드: 네, 그렇게 하세요.

크리스 젠킨스: 좋은 말씀입니다. 저도 Gleam을 꼭 써봐야겠네요. 오늘 오후는 시간이 있으니까요.

루이스 필폴드: 네, 좋습니다.

크리스 젠킨스: 루이스, 정말 멋진 언어를 만들었네요. Erlang만큼 이상하지 않으면서도 Erlang의 강력함을 가진 언어를 써볼 수 있게 되어 기쁩니다. 오늘 함께해 주셔서 감사합니다.

루이스 필폴드: 감사합니다. Gleam 커뮤니티에서 만나 뵙기를 바랍니다.

크리스 젠킨스: 네, 꼭 그러겠습니다.

루이스 필폴드: 감사합니다.

크리스 젠킨스: 루이스, 감사합니다. 그리고 루이스의 고양이 누비에게도 감사드립니다. 깜짝 출연해 주셔서 감사합니다.

이것으로 오늘 에피소드를 마치겠습니다. 저는 크리스 젠킨스였고, 루이스 필폴드와 함께 Developer Voices를 진행했습니다. 들어주셔서 감사합니다.

저도 Gleam을 써봐야겠네요. 시간이 좀 있으니까 프로그래밍을 좀 해봐야겠습니다. Gleam에 대해 더 자세히 알고 싶으시면 gleam.run을 방문하세요. Gleam에 대한 모든 정보가 있습니다. 저처럼 라이브러리 지원이 궁금하신 분들은 packages.gleam.run을 방문하세요.

gleam.run을 방문하기 전에, 팟캐스트의 이 부분에서는 스폰서를 소개하는데, 아직 스폰서가 없습니다. 그래서 이번 주 에피소드는 따뜻한 차 한 잔으로 후원되었습니다. 체육관에서, 부엌에서, 트럼펫 레슨을 가는 길에 이 팟캐스트를 듣고 계시다면, 따뜻한 차 한 잔과 함께 즐겨보세요. 그리고 비스킷도 함께 드시면 더 좋습니다. 비스킷을 던져주시고 Developer Voices의 다음 에피소드를 후원하고 싶으시다면 좋아요, 구독, 공유 버튼을 눌러주세요. 흥미로웠다면 친구들에게 공유해 주세요. 알고리즘은 사람들이 무엇에 관심이 있는지 파악하려고 노력합니다. 흥미로웠다면 클릭으로 알려주세요.

이것으로 오늘 에피소드를 마치겠습니다. 저는 크리스 젠킨스였고, 루이스 필폴드와 함께 Developer Voices를 진행했습니다. 들어주셔서 감사합니다.