Mitchell Hashimoto - Founder of HashiCorp, Terraform, and Thoughts of Open Source Monetization - https://www.youtube.com/watch?v=vw61iI08iro

Hashicorp가 존재하기 전에 시작한 모든 프로젝트들은, 사업이 될 거라고 전혀 의도하지 않았습니다. 사업이 될 거라고  생각하지 않았죠. 누군가가 사용할 거라고도 생각하지 않았습니다. 많은 프로젝트가 그렇게 시작됩니다. 상업적인  생각이나 계획이 전혀 없죠. 상업적인 측면은 커뮤니티의 성공에 따른 부작용일 뿐입니다. 안녕하세요, DevTools FM 팟캐스트에 오신 것을 환영합니다. 이 팟캐스트는 개발자 도구와 그것을 만드는 사람들에 관한 것입니다. 저는 Andrew이고 이쪽은 공동 진행자 Justin입니다. 여러분 안녕하세요. 오늘 Mitchell Hashimoto님을 모셨습니다. Mitchell님, 함께 해주셔서 감사합니다. Mitchell님은 유명하게도 Hashicorp를 시작하셨는데 2010년, 2012년 즈음이었죠. 꽤 이른 시기였습니다. 회사가 법적으로 설립된 건 2012년이었죠. 2012년이었던 것 같아요. 네, 2012년이죠. 정말 놀랍습니다. 저는 여러분이 그렇게 많은 일을 하셨다는 걸 몰랐어요. 많은 사람들이 Hashicorp에 대해 들으면 아마도 Terraform을 들어봤을 겁니다.  Terraform은 여러분이 만든 큰 영향력 있는 프로젝트죠. 하지만 저는 Vagrant를 사용했던 걸 기억합니다. 대학 졸업 후에요. 그때는 Mitchell님이 그것도 만드셨다는 걸 몰랐어요. 정말 흥미로운 연관성이네요. 그래서 우리는 이런 얘기를 나누게 되어 정말 기대됩니다.당신의 초기 작업과 Hashicorp, 그리고 이 모든 여정에 대해 얘기해보겠습니다. 하지만 본격적으로 시작하기 전에, 청취자들에게 자신에 대해 좀 더 소개해주시겠습니까? 네, 대략적인 내용은 말씀해주셨지만, 저는 배경과 열정이 엔지니어입니다. 저는 항상 오픈 소스 소프트웨어 개발에 깊이 관여해 왔습니다. 지난 10년 정도 동안 인프라 소프트웨어에 주력했지만, 다양한 분야에서 일해왔습니다. 현재는 터미널 에뮬레이터 작업을 하고 있는데, 아마 이에 대해 얘기하게 될 것 같습니다. 네, 그게 제 개인적인 소개입니다. 그렇습니다. 그게 저예요. 멋집니다. Hashicorp 얘기를 하기 전에, 당신은 부업으로 조종사이기도 하죠. 저는 이게 정말 좋습니다. 제 어머니와 의붓아버지도 둘 다 조종사거든요. 개인적으로 취미 삼아 하시는 정도지만요. 그래서 어떻게 조종사가 되셨는지 궁금합니다. 간단히 말하자면, 저는 항상 비행에 관심이 있었습니다. 하지만 깊이 알아보지 않아서 현실적으로 불가능하다고 생각했죠. 아니면 도달하기 힘들다고요. 그러다 친구의 여자친구 아버지가 조종사인 분을 알게 됐는데, 그게 제가 조종사와 가장 가까이 접한 경험이었습니다. 사교 모임에서 그분을 만나 대화를 나누면서 조종사가 되는 게 얼마나 접근 가능하고 가능한 일인지 설명해주셨어요. 이건 Hashicorp 이전의 일이었습니다.어떤 재정적 성공을 거둔 것 같았어요. 저 개인적으로는 그 전이었죠. 그래서 깨달았죠, 아, 이제 이걸 시작할 수 있겠구나, 가능하다는 걸요. 그래서 비행을 시작했어요. 그리고 정말 흥미로운 점은 비행이 재미있고 멋지다는 거예요.  사실 과정으로 봤을 때 그리 어렵지 않다고 생각해요. 하지만 제가 정말 빠져든 것, 그리고 많은 엔지니어들을  비행에 끌리게 하는 것은 비행기 시스템과 규정,  그리고 그런 것들에 대한 지식이 필요하다는 점이에요. 특히 엔지니어들에게는 비행에 관한 규칙들이 어떤 면에서 매우 안정감을 줍니다. 매우 엄격한 시스템이죠. 거기 들어갔을 때 정확히 무엇을 예상해야 할지 알 수 있어요. 그리고 그게 정말 좋아요. 일반적으로 비행은  어렵고 위험해 보이지만, 당신은 한 단계 더 나아가 자신만의 항공 소프트웨어를 만들었어요. 그게 대체 무슨 의미인가요? 그리고 네, 네, 음, 저는 절대로 제 소프트웨어를  실제 비행 중인 조종석에 넣지 않을 거예요. 제가 항공과 관련해 만든 모든 소프트웨어는 비행 전 계획을 돕기 위한 것이었어요. 날씨  분석, 보고서 작성 등이죠. 기본적으로, 제가 비행 학교를 다니고 면허를 따고  연습을 하면서 깨달은 건, 제가 같은 일을  반복해서 하고 있다는 거였어요. 그래서정확히 동일한 경로 작업으로 여기서 날씨 정보를 가져옵니다. 비행 경로의 여러 지점에서 특정 보고서를 가져오는데, 이는 다양한 웹사이트에서 얻습니다. 그래서 자동으로 가져오는 데 도움이 되는 도구를 만들었습니다. 하지만 여전히 소스에서 가져오며, 데이터를 생성하거나 비행기에 직접 입력하지는 않습니다. 미리 읽어보는 정도입니다. 네, 개인 비행이나 사설 항공이 얼마나 많이 변했는지 흥미롭습니다. 제 어머니가 2007년경에 비행을 배우기 시작했을 때를 생각해보면... 2007년, 2008년쯤이었죠. 아직 꽤 최근이네요. 네, 하지만 그때부터 많이 수동적이었고 종이를 많이 사용했는데, 지금은 어머니와 계부께서 아이패드를 사용해 모든 비행 전 체크리스트와 경로 계획 등을 하십니다. 그 짧은 기간 동안 얼마나 많이 바뀌었는지 흥미롭습니다. 네, 저는 이제 파일럿 경력이 5년밖에 되지 않았지만, 그때도 아이패드는 이미 널리 사용되고 있었죠. 사실 아이패드가 거의 필수품이에요. 물론 아이패드 없이 비행하는 방법도 많고, 예전에는 다들 그렇게 했죠. 사람들은 오랫동안 아이패드 없이 비행해왔습니다. 개인 조종사 과정을 밟을 때, 적어도 제 교관은 아이패드를 절대 사용하지 않게 했어요. 모든 것을 펜과 종이, 구식 차트로 해야 했죠. 그게 정말 중요하다고 생각해요. 하지만지난 5년간 비행하면서 이제는 선택 장비로 여기지 않습니다 iPad를 기내에 가져가지만, 같은 소프트웨어를  휴대폰에도 설치해 두었죠. 그게 제 백업입니다. 그리고 FAA와 후속 시험을 할 때, 시험관은 매우 수용적이었습니다. 감정적인 의미가 아니라 그는 답변을 정확하다고 여겼습니다 백업이 무엇이냐고 물었을 때 전화기라고 대답했더니요. 전화기가 안 되면 계기판을 사용한다고 했습니다. 제게는 iPad가 1순위, 전화기가 2순위입니다. 비행기의 차트 데이터는 실제로 가장 후순위입니다 FAA 시험관들도 계획만 있다면 괜찮다고 했습니다. 주제를 조금 바꿔보겠습니다. 당신은 개인 블로그에 Zig에 대해 많이 쓰셨는데요, 훌륭합니다. 아직 보지 않은 분들은 꼭 확인해보세요. 우리는 BUN의 Jared와 Zig를 사용하는  몇몇 사람들과 이야기를 나눴지만 깊게 다루지는 않았습니다. Zig의 매력이 무엇인지, 어떤 프로젝트에 사용했는지  말씀해 주시겠습니까? 네, Hashicorp와도 연관 지어 말씀드릴 수 있겠네요. Zig에 끌린 이유는 생산성이 높으면서도 표현력 있는 시스템 프로그래밍 언어를 찾고 있었기 때문입니다. 충분히 표현력이 있으면서도 생산적이고일종의 악몽 같은 빌드 시스템과 빌드 환경이 있습니다. 그래서 사실 Hashicorp로 잠깐 돌아가보면, 우리가 Hashicorp를 시작했을 때, 결국엔 모든 것을 Go로 작성했지만 처음 시작할 때, 우리가 작성하려는 소프트웨어에 대해 어떤 기술을 선택할지 좁혀나갈 때, 결국 그 과정의 끝에서 GO 또는 C로 좁혀졌습니다. 저와 공동 창업자는 C에 매우 익숙했습니다. 우리는 수년간 프로덕션 품질의 서버 사이드 C를 작성했고 이는 꽤 큰 규모로 사용되었기에 우리는 그 어떤 것도 두렵지 않았지만 결국 우리는 명백히 Go를 선택했습니다. 나중에 원하시면 그 이유를 설명할 수 있습니다. 하지만 Zig는 제게 비슷한 느낌입니다. Zig가 그 당시에 존재했다면, 아마도 지금보다 더 안정적이어야 했겠지만, Zig가 2012년경에 1.0 형태나 거의 1.0에 가까운 형태로 존재했다면 상황이 달랐을 수도 있습니다. 저는 그것을 C의 정말 훌륭한 후계자로 보며, 이미 그런 상황에 익숙한 상태에서 저는 Zig를 사용하는 것을 정말 좋아하고, 그게 제게 Zig의 진정한 틈새 시장이라고 봅니다. 당신의 의견으로는, Rust와 비교해 어떤 이점이 있나요? 제게는 표면적인 이점이 있다고 봅니다. 저는 Ruby로 시작했고 Ruby는 항상 프로그래밍이 재미있어야 한다는 사고방식을 가지고 있었습니다. 그리고 저는 그것이 개인적인 것이라고 생각합니다. 즉, 그것이 객관적인러스트가 재미없다는 건 아니지만 저에게는 절대 재미있지 않습니다. 러스트로 코딩할 때마다, 작은 프로젝트를 해봤지만 큰 건 안 해봤어요. 러스트를 쓰거나 읽을 때마다 많은 러스트 코드를 읽어봤지만 아직도 그냥, 행복하지 않아요. 재미가 없고 Zig는 개인적으로 정말 재미있고 즐겁습니다. 개인적인 의견이에요. 비개인적인 측면에서는 메모리 안전성이 매우 중요하다고 생각합니다. 하지만 저는 매우 선형적이고 정확하진 않지만 기계 코드로 어떻게 변환될지 잘 알 수 있는 언어를 좋아합니다. 그리고 그것들이 기계 코드로 어떻게 변환될지 잘 알 수 있어요. 러스트는 항상 대여 검사기를 위해 프로그래밍하는 느낌이었고 항상 명확하지 않았어요. 경험이 쌓이면 나아질 수도 있지만 적어도 초보자로서는 정확히 어떻게 기계 코드로 변환될지 명확하지 않았어요. Zig는 전혀 그렇지 않아요. 모든 줄마다 어떤 기계 코드가 생성될지 직관적으로 이해할 수 있어요. 단점은 러스트처럼 메모리 안전 언어가 아니라는 거예요. C만큼 나쁘진 않지만 러스트만큼 확실한 보장은 없어요. 일부 사람들은 이를 철학적인 경계선으로 봅니다. 하지만 저에게는 그렇지 않아요. 일부 사람들은 이를 철학적 한계선으로 보지만 저는 그렇지 않습니다.좋다고 생각해요. 최근에 Zig로 사이드 프로젝트들을 만들고 계신 것 같은데 터미널 에뮬레이터를 작업하고 계신 걸 봤어요. 어떻게 진행되고 있나요? 그리고 터미널 에뮬레이터를 만들 때 어떤 어려움이 있나요? 네, 재미있었어요. 정말 재미있는 프로젝트예요. 사실 처음에는 이런 걸 할 거라고 전혀 예상하지 못했어요. 시작할 때도 여러 가지를 배우기 위한 프로젝트였어요. Zig도 그렇고 GPU 프로그래밍도 그렇고, 터미널 에뮬레이션 레이어도 마찬가지고요. 그냥 배우고 싶었어요. 다른 사람들이 사용하는 기능이 풍부한 프로젝트가 될 줄은 몰랐어요. 시간이 지나면서 더 나은 터미널 에뮬레이터를 만들 기회가 많다는 걸 깨달았고, 터미널 에뮬레이션 자체를 개선할 기회도 많다는 걸 알게 됐어요. 앱 측면이 아니라 CLI에서 실행되는 프로그램이 실제로 할 수 있는 일들 말이에요. 그래서 정말 재미있었어요. 지금 베타 테스터가 800명 정도 있어요. 올해 공개 출시할 계획이에요. 완전히 열정의 산물이에요. 사람들이 자주 물어보는데, Hodge Script를 그만두고 이걸 하는 거냐, 새 회사를 차리는 거냐 등등. 전혀 아니에요. 그냥 순수한 열정 프로젝트예요. 하지만 정말 재미있었어요.  열정 프로젝트를 갖는 게 좋다고 강하게 믿어요. 이번 주 스폰서에게 감사드립니다.CodeCrafters. CodeCrafters는 경험 있는 소프트웨어 엔지니어를 위한 프로그래밍 과제를 만듭니다. 주말에 리트코드 문제를 풀거나 기여할 사이드 프로젝트를 찾는 대신, 우리가 사용하고 사랑하는 멋진 오픈 소스 기술을 재구축하는 데 주말을 보낼 수 있습니다. 그들은 많은 멋진 과제들을 가지고 있습니다. 자신만의 BitTorrent 만들기, 자신만의  git 만들기, 자신만의 Docker 만들기 등 많은 과제가 있습니다. 이 과제들에 대해 모든 인기 있는 프로그래밍 언어를 지원합니다. 이러한 개발 도구들의 깊은 내부 작동 방식을  살펴보고, 그들이 사용하는 바이너리 프로토콜을 풀어보며 실제로 어떻게 작동하는지 보는 것은 정말 멋집니다. 저는 몇 가지 과제를 해봤는데, 바이너리 프로토콜이 얼마나 간단한지 항상 놀랍습니다. 더 낮은 수준의 세부 사항을 풀어보는 것은 정말 재미있습니다. 또 다른 멋진 점은 이것이 정말 커뮤니티 경험처럼 느껴진다는 것입니다. 다른 사람들의 해결책을 볼 수 있고, 댓글도 있어서 진공 상태에서 배우는 것 같지 않습니다. 다른 사람들이 함께 있는 것처럼 느껴집니다. 내용 외에도 사용자 경험 자체가 경험 있는 소프트웨어 개발자를 대상으로 합니다. 예를 들어, 사용자를 맞춤형 브라우저 경험에 묶어두는 대신, CodeCrafters는  여러분이 모든 자신의 도구를 사용할 수 있게 해줍니다. IDE나 텍스트 에디터를 사용할 수 있습니다. 여러분이 해야 할 일은 codecrafters에 푸시하는 것뿐입니다. 그들이 테스트를 실행하고 결과를 보여줍니다. 원하지 않으면 웹사이트에 갈 필요도 스폰서를 모집하고 있습니다. 이제 본 에피소드로 돌아가겠습니다. 우리가 HashiCorp에 대해 이야기하는 것으로 전환할 수 있을 것 같습니다. 패션 프로젝트 얘기가 나왔으니 말이죠. 당신은 2012년에 HashiCorp를 설립했다고 말씀하셨습니다.  초기에는 어떤 일을 하셨나요? HashiCorp를 설립해서 어떤 문제를 해결하고자 하셨나요? 네, 우리가 처음 회사를 설립했을 때는 Vagrant라는 소프트웨어만 출시한 상태였습니다. 하지만 저와 공동 창업자는  추구하고 싶은 다른 아이디어들도 적어 놓았었죠. 정확한 목록을 기억하기는 어렵습니다. 결국 만들지 않은 것들도 많았거든요. 하지만 우리가 만든 것들 중에서는  지금까지 제가 알기로는 거의 모든 것이 그 목록에 있었습니다.  Vault만 좀 달랐죠. Vault는 목록에 없었습니다. 우리는 보안이 모든 프로젝트에 걸쳐 분산될 거라고 생각했습니다. 비밀을 하나로 중앙화하는 것이 더 나은 해결책이라는 걸  실제 상황에 부딪혀서야 깨달았죠. 하지만 초기 계획에서는 그렇게 생각했습니다. 실제 계기는 제가 대학을 졸업하고 샌프란시스코 베이 에어리아로 이사가서 스타트업 환경에서 일하면서 파이썬 기반의 수제 자동화 및 인프라 자동화 도구들을 만들고 있었는데, 사교 모임에 가보니 다들 저와 같은 문제를 겪고 있다는 걸 알게 된 거죠. 그래서 그게 제가 이렇게 생각하게 된 계기 중 하나였습니다. "이런 문제들을 해결할 수 있는 도이런 문제들에 집중하는 조직을 만들어볼까 하는 생각이 들었어요. 그리고 Vagrant가 이미 존재했고 당시 꽤 인기가 있었는데, 완전히 사이드 프로젝트였죠. 저는 Vagrant와 전혀 관련 없는 일을 주 40시간 하면서 정상적인 직장 생활을 하고 있었어요. 그리고 집에 돌아와서는 Vagrant 작업을 하루에 4-8시간 정도 할 때도 있었죠. 그러고 나서 잠자고, 일어나서 출근하고, 이 사이클을 반복했어요. 그때도 이게 지속 가능하지 않다는 걸 알았죠. 그래서 이 두 가지 요인이 저를 Hashicorp를 시작하게 만들었어요. 그게 Hashicorp를 시작하게 된 이유였습니다. 멋집니다. 2014년에 Tao of Hashicorp를 발표하셨는데, 당시 생각이 어떻게 영향을 미쳤나요? 생각은 간단했어요. 2014년쯤에는 우리가 정말로 사람들을 고용하기 시작했고, 회사가 상당히 크게 성장하고 있었죠. 그 무렵에 우리는, 정확히 2014년인지는 모르겠지만, Tao를 작성하기 시작했을 때 회사가 10명 정도의 전환점에 있었어요. 우리는 문화에 대한 설명과 채용 시 원하는 것을 문서화해야 한다는 것을 깨달았죠. 그래야 회사의 모든 사람들이 단순한 분위기 이상으로 같은 방향을 향하게 될 거라고 생각했어요. 그래서 우리는, 그리고 인간적인 측면뿐만 아니라, 그리고 단순히 인간적인 면만이 아니었어요.원래 TAO의 초점은 제품 디자인이었습니다. 우리가 더 많은 사람들에게 프로젝트 작업을 위임하고 제 또는 아몬드의 관여 없이 커밋하고 릴리스를 하게 되면서, 그들이 우리의 소프트웨어처럼 느껴지는 소프트웨어를  제공하도록 어떻게 보장할 수 있을까 고민했죠. 그래서 TAO가 나왔습니다. 이는 기술에 관한 우리의 디자인 원칙을 성문화한 것이었습니다. 이게 흥미롭다고 생각합니다. 특히 그 시기에, 그리고 일반적으로, 위대한 회사들에 대해 생각해보면, HashiCorp도 그 중 하나고, Heroku의 초기 활동이나 오늘날의 Linear를 생각해봅니다. 항상 그들의 정체성과 운영 방식, 그들이 하는 일이나 이론에 대한 초기 글쓰기가 있었죠. 그래서 HashiCorp의 TAO가 있었고, Heroku는 유명한 12 Factor 앱이나  그와 관련된 것이 있었습니다. Linear는 Linear 방법론이 있는데, 이것도 중요한 글이라고 생각합니다. 정확히 어디로 가려는 건지 모르겠지만, 흥미로운 점은 이런 중요한 초기 작업들, 회사들이 자신들의 정체성과 하는 일에 대해  쓰고 이야기하는 초기 포스트들이 있다는 거예요. 어떻게 그런 글을 쓰게 되는지, 그 과정이 궁금합니다.어떤 모습인지, 어떤 건지 말이에요. 네, 잘 모르겠어요. 이건 2014년이었고, 1년 정도 지나서야 첫 직원을 고용했죠. 맞아요, 약 1년 후에요. 그리고 나서 더 많이 고용하기 시작했죠. 대략적으로요. 네, 맞아요. 많이 생각해보지 않아서 잘 모르겠어요. 하지만 한 가지 확실한 건, 제가 당시 인프라 소프트웨어에 대해 다른 접근법을 가졌다고 느꼈다는 거예요. 적어도 제게는 그렇게 느껴졌어요. 지금은 돌이켜보기 어렵지만, 제가 공로를 주장하려는 게 아니라 그 당시 제 감정과 지금의 감정을 비교하면, 오늘날 인프라 소프트웨어가 훨씬 나아진 것 같아요. 복잡하긴 하지만요. 쿠버네티스도 복잡하고, Hashicorp가 한 일들도 복잡하죠. 하지만 돌이켜보면, 제가 전에 말했듯이 한 회사에서 2년 동안 인프라 관리를 했을 때, 모든 인프라 소프트웨어가 기계를 먼저 생각하고  사람을 나중에 생각하는 것 같았어요. 아마도 제 Ruby 앱 개발자 배경 때문일 수도 있고, 또 하나는 Apple Store에서 짧게 소매 직원으로 일한 경험 때문일 수도 있어요. Apple의 소매점에서조차 있던 그런 문화 말이에요. 이 두 가지가 합쳐져서 제가 전환했을 때, 그 두 가지를 합쳐서 제가 인프라로 전환했을 때,인프라 세계로 직업적으로 진출했을 때, 저는 생각했습니다 소프트웨어가 뒤집혀야 한다고, 기계보다 인간 측면에 먼저 초점을 맞춰야 한다고. 그래서 그것이 우리가 타오에 적은 내용의 일부입니다. 타오의 한 요소가 있는데, 그것이 결국 제가 있을 당시 회사 전체의 지침 원칙이 되었습니다. 바로 '기술이 아닌 워크플로우'였죠. 이는 우리가 설계한 아이디어였습니다. 제가 처음으로 한 일 중 하나는 당시와 지금까지도 설계하는 모든 소프트웨어에 대해, 일부 사람들이 'readme 주도 개발'이라고 부르는 것을 하는 것이었습니다. 그 용어는 당시에 존재하지 않았지만, 저는 실제로  bash 스크립트나 makefile 같은 것을 만들어 소프트웨어가 이미 존재한다고 가정했습니다. 아무것도 하지 않고 터미널에 출력만 에코했죠, 실제처럼 보이게 하기 위해 sleep도 넣었고요. Terraform에서도 그렇게 했습니다.  Terraform plan, Terraform apply 같은 것을 실행할 수 있었죠. 당시 제 삶에서 인터넷이 좋지 않을 때 주로 비행기에서 이런 작업을 했습니다. 그냥 앉아서 그 환경을 상상하며 이 명령어들을 실행하고 제 느낌을 평가했습니다. 소프트웨어를 사용하는 게 재미있나? 직관적인가? 다음 단계는 뭘까? 어떤 플래그가 필요할까? 어떤 기능이 있어야 할까? 이런 식으로 생각했죠. 이를 통해 많은 아이디어가 탄생했습니다우리가 그 다음에 기술로 돌아갈 내용의 그리고 그 당시에는 다른 사람들과는 다른 사고방식이었다고 생각합니다. 적어도 다른 사람들과는 다르게 느껴졌죠. 오늘날에는 모든 것이 훨씬 더 인간 중심적으로 느껴집니다. 네, 소프트웨어를 그렇게 정의하는 방식이 좋습니다. 저는 몇 개의 NPM 패키지를 가지고 있는데 항상 readme부터 시작해요. API부터 시작하고, 좋은 느낌이 들도록 가지고 놀다가 그 다음에 실제로 구체화하려고 노력합니다. 네. 한 가지 Armand에게 공을 돌려야 할 것은 제가 회사를 시작했을 때 이 과정에서 극단주의자였다는 점입니다. readme부터 시작해서 뒤로 갔죠. Armand는 훨씬 더 강한 학문적인 컴퓨터 과학 기초를 가지고 있었고 이런 아이디어를 제시했습니다. 그렇게 하되 그냥 뒤로 작업하는 대신,  우리가 도달하고자 하는 최종 상태를 고려해서  핵심적인 추상화나 소프트웨어 모델링에 대해 이야기를 나누자고 했습니다. 그리고 나서 중간에서 만나자고 했죠. 좋은 예로 Terraform을 계속 들자면 제가 설계한 CLI가 있었지만 그 다음에는 이런 아이디어가 있었습니다. 우리가 가진 이것들이 작은 상태 기계인가, 그래프의 노드인가? 어떤 종류의 알고리즘인가? 상태 기계와 그래프는 잘 알려진 것들이고 잘 정립된알려진 연산들이 Terraform 환경에서 유용한가요? 그래프를 순회해야 하는지, 그리고 그 순회가 정확히 apply를 수행하는 방법이라는 것을 빠르게 깨달았습니다. 그게 작동하는 방식입니다. 상태 기계에 대해, 예를 들어 하나의 상태 기계가 한 번에 움직이나요? 병렬로 움직일 수 있나요? 서로를 인식해야 하나요? 상태 기계가 다른 상태 기계를 트리거하는 것과 같은 연구 분야가 있기 때문입니다. 그것이 거의 당시 우리가 읽은 모든 연구였는데, 온라인 게임 시스템이  거대한 분산 상태 기계처럼 작동한다는 것이었습니다. 그래서  Arman이 전체 프로세스에 가져온 일종의 엄격함이 있었고, 저는 그것을 지금까지 유지하고 있습니다. 기본적으로 이 프로젝트들을 작업할 때, 우리는 양쪽에서 시작했지만 코어부터 시작했고, CLI도 시작했습니다, 그리고 우리는 동시에 중간을 향해 나아갔습니다. 그리고 제 기억에 가장 두드러지는 것은 Vault입니다. Vault를 만들 때, 우리는 6주 만에 Vault 0.1을 완성했습니다. 그리고 공개 릴리스 약 이틀 전까지 작동하는 바이너리가 없었습니다. 우리는 단위 테스트와 우리가 가지고 있던 설계 문서를 사용하여 개발했습니다. 릴리스하기 약 일주일 전에, 왜냐하면 우리는 많은 초기 보안 테스터들이 있었기 때문에, 우리는 바이너리를 만들었고 그것이 작동했습니다. 그리고 우리는 "오케이, 흥미롭네"라고 생각했습니다. 이런 강력한 설계를 할 수 있다는 것이양쪽 모두 테스트로 뒷받침되고, 중간으로 이동하여 실제로 소프트웨어를 만들어냅니다 그 소프트웨어는 버그도 많지만 작동도 합니다. 네, 당신은 Hashicorp에서 많은 도구를 만들었습니다. 몇 가지에 대해 이야기했죠. Vagrant, Terraform. 하지만 초기에 가장 좋아했던 작업은 무엇이었나요? 그리고 어떤 것이 인프라 생태계에 가장 큰 영향을 미쳤다고 생각하나요? 아마도 둘 다 같을 겁니다. 쉬운 답을 고르려는 게 아닙니다. 저는 항상 제가 작업한 프로젝트 중 가장 좋아하는 것이 Terraform이라고 일관되게 말해왔습니다. 또한 그것이 결국 우리가 만든 모든 프로젝트 중에서 인프라 분야의 가장 많은 사람들에게 정말 큰 영향을 미쳤다고 생각합니다. 실제로 보면 그렇게 느껴집니다. 음 아니요, Vault도 비슷한 수준의 영향력이 있다고 생각합니다 실제 사용 측면에서요. 덜 흥미롭고 덜 알려져 있지만, 매우 널리 사용되고 있으며 매우 중요한 정보를 보호하는 데 사용됩니다. 그래서 Vault의 영향력은 엄청납니다. 하지만 Terraform은 제가 항상 가장 흥분했던 프로젝트였습니다. 또한 Hashicorp를 시작했을 때 제가 가장 명확하게 이해하고 있던 프로젝트였죠. 무엇을 하고 싶은지에 대해서요. 몇 년 전에 트윗한 적이 있는데 예전에 텀블러 블로그를 운영했었습니다. 그 블로그에 2010년경에 글을 올렸는데블로그 글에서 Terraform에 대한 제 욕구와 정확히 어떻게 작동하길 원하는지 설명하고 누군가에게 만들어달라고  부탁했습니다. 아무도 만들지 않았고, 결국 제가 필요한 시점이 와서 '그럼 내가 만들어야겠다'고 생각했죠. 저는 항상 명확한 비전이 있었습니다. AWS가 Cloudformation을 출시한 날  그 블로그 글을 게시했는데, Cloudformation을 보고  멋지다고 생각했지만 제가 하고 싶었던 방식은 아니었거든요. 그래서 '좋은 아이디어지만 이렇게 하는 게 어떨까'라고 썼고, 그게 결국 Terraform이 되었습니다. 좋습니다. 당신은 Hashicorp에서 오랜 시간을 보냈죠. 몇 년간 CEO를 지냈고, 그 후 몇 년간 CTO를 했으며, 마지막 2-3년은 개인 기여자로 전환했습니다. 그 경험은  어땠나요? CEO를 그만둔 후 보고 체계에  어색한 점은 없었나요? 네, 그게... 제가 22살 때 Hashicorp를 시작했어요. 제 첫 벤처 지원 스타트업이었죠. 지금까지도 유일한 벤처 지원 스타트업이에요. Hashicorp 창업 전에 제가 일했던 가장 큰 회사는  직원 45명 정도였습니다. 그래서 사업을 시작하는 데 무엇이 필요한지, CEO가 실제로 무엇을 하는지, 아무 것도 모르고 시작했어요. 사업 시작에 무엇이 필요한지, CEO가 실제로 무엇을 하는지,기업 회사에서 어떤 책임을 맡게 될지에 대해 우리는 처음에 기업 회사라는 걸 몰랐어요. 시작했다가 나중에  그렇게 되었죠. 그래서 저는 CEO로 4-5년 정도 일했어요. 그 기간 동안 몇 번의 펀딩 라운드를 거쳤고 직원 수는 20명에서 40명 사이였어요. 정확한 숫자는 기억나지 않지만 20명에서 40명 사이가 맞을 거예요. 그리고 회사가 커지고 우리의 미션이 확장되면서 깨달은 점이 있었어요. CEO 직책이 얼마나 실제적인 일인지 알게 되었죠. 그 전에는 CEO가 그저 형식적인 직함이라고  생각했는데, 그건 제 무지였어요. 실제로 CEO가 하는 일과 책임이 무엇인지 알게 되었죠. 물론 우리는 아주 작은 회사였지만, 그 순간에도 제가 그 일에 편하지 않다는 걸 깨달았어요. 그리고 그 일에서 큰 즐거움을 느끼지 못했죠.  구체적으로 말하면, 임원진 구성, 재무 계획, 3-5년 사업 전망 같은 일들이에요. 당시에는 10년 기술 전망은 그릴 수 있었지만, 3-5년 사업 전망을 세우는 건 정말 어려웠어요. 고객과 대화하고 어떻게비기술적인 사람들에게 회사에 대해 이해하기 쉽게 설명하는 것이 그런 것들이 정말 어려웠어요. 그래서 저는 아르만과 이야기를 나누기로 했고, 긴 이야기를 짧게 하자면 더 많은 일이 있었지만, 간단히 요약하자면  외부에서 CEO를 영입하고 제가 CTO로 내려가는 것이 최선이라고 판단했습니다. 그래서 저는 몇 년 동안 CTO를 맡았고, 진심으로 즐겼습니다. 분명히 제가 훨씬 더 오랫동안 CTO로 남아있었을 평행 우주가 있을 거예요. 그리고 완전히 행복했을 겁니다. 하지만 제가 깨달은 점은 CTO 역할에 대해 좋아하는 부분도 있었지만, 순수하게 100% 사랑하는 것은 엔지니어링과 소프트웨어 개발이었다는 거예요. 그래서 어느 시점에 CTO 역할을 하면서 회사가 훨씬 더 잘 되기 시작하고 회사가 더 건강하고 성숙한 위치에 있다고 생각했을 때, 아르만과 우리가 고용한 CEO인 데이브와 이야기를 나눴고 제가 좀 더 이기적인 단계를 밟기 시작하고 싶다고 말했어요. 개인적으로 제 진정한 열정인 것으로 돌아가고 싶었죠. 그건 바로 엔지니어링이었습니다. 그래서 저는 IC가 되었고, 보고 체계는... 네, 많은 사람들에게 이상했을 거예요. 아무도 제 얼굴을 보고 그렇게 말하지 않았지만 어려웠을 거예요. 하지만 저는 최선을 다했고 문화가 정말 좋은 상태에 있다고 생각했습니다.제가 최선을 다해 같은 위치에 있으려고 노력했고 창업자로서의 위치를 절대 이용하지 않으려 했습니다 이전에 말했듯이, 그 상황에 대해 사람들이 어떻게 느꼈는지 제가 모르는 점이 있을 수 있지만 그렇게 나쁘지는 않았다고 생각합니다. 네, 저는 그것이 정말 존경스러운 전환이었다고 생각합니다. 우리가 실제로 좋아하는 것과 즐기는 것을 인정하지 않고 많은 고통을 겪게 된다는 인식이 있죠. 우리는 그저 '이게 내가 해야 할 일이야' 또는 '이 자리에 있어야 해'라고 생각합니다. 하지만 '사실 나는 이것을 정말 좋아해. 그냥 할 거야'라고 말하는 자유로움이 있습니다. 사람들에게 말했던 한 가지는 '어떻게 알았나요? 어떻게 정의했나요?'라고 물을 때 저는 항상 이렇게 대답했습니다. 그것은 엔지니어링이든 아니든 코딩으로 좁혀 말하자면, 코딩은 제가 항상 시간을 내는 것이었습니다. 시간이 없을 때조차 시간을 만들어냈죠. 저는 희생을 감수하고 잠을 줄이면서까지 했습니다. 일하기에 적합하지 않은 상황에서도 일했고 일, 즉 코딩을 했습니다. 휴일에도 코딩했죠. 기억나는 게 한 번은 전 여자친구와 헤어졌을 때 힘든 시기를 겪고 있었는데 제가 가장 먼저 한 일은집에 가서 8시간 동안 쉬지 않고 코딩하고 여러 가지를 출시했어요 그게 제가 즐거워하는 방식이고, 슬픔을 달래는 방식이에요 그 주변의 모든 것이 그랬어요. 그게 공허함을 채우는 방법이었죠 지금도 여전히 그걸 좋아해요. 그래서 알게 됐어요 CTO 관리 업무나 영업 업무 같은 것들에  추가 시간을 내지 않았다는 걸요. 그 순간에는  그런 일들을 하는 게 나쁘지 않았지만, 그것들을 위해 추가적인 시간을 내지는 않았어요. 그게 제 신호였죠. 네, 이해가 됩니다. 저는 그 전환에 대해 권력 역학 측면에서 생각하고 있었어요 특히 창업자로서, 첫 회사라면 쉽게 내면화하지 못할 수 있죠 아, 내가 보고 구조의 다른 부분에 있다는 걸요 보고 체계 어딘가에 관리자가 있고 이제 그들이 저를 관리해야 하는데 어떻게 해야 할지 모르겠다는 거죠. 흥미로운 전환이에요 조직 내 권력 구조를 어떻게 탐색하는지에 대해 더 많이 이야기하는 게 좋을 것 같아요. 현실이니까요 당신은 직장과 개인 시간에 많은 대규모  오픈 소스 프로젝트를 이끌어 왔어요 이러한 오픈 소스 프로젝트를 만들고 커뮤니티를 육성할 때 어떤 점들을 고려하시나요? 시간이 지나면서 변화가 있었어요 오픈 소스 프로젝트를 만들고 커뮤니티를 육성할 때 고려하는 점들이 달라졌어요. 제가 처음 시작했을 때는오픈 소스 프로젝트에 대해, 초기에 20대 초반에는 깊게 생각하지 않았어요. 처음에는 그저 GitHub에 올리고 관대한 라이선스를 붙이고 'IRC 채널 열고 즐겁게 하자' 정도였죠. 하지만 지금은, 특히 이 터미널 에뮬레이터를 시작하면서 경험상 많이 달라졌어요. 이제는 처음부터 지속가능성에 대해 훨씬 더 신중하게  고민하고, 커뮤니티 문화에 대해서도  초기부터 생각하게 됐어요. 예를 들어, 커뮤니티 문화를 위해 매우 긴 비공개 베타 기간을 갖고 있어요. 이는 부분적으로 제 개인적 안녕을 위한 것이기도 해요. 너무 많은 압박을 받고 싶지 않거든요. 하지만 또 다른 이유는 이런 느린, 통제된 성장을 통해 원하는 모습의 커뮤니티를 더 신중하게 만들 수 있다고 생각하기 때문이에요. 첫날부터 백만 명이 몰려오면, 올바른 행동이 무엇인지, 무엇이 용인될지에 대해 통제하기 어려워져요. 하지만 천천히 성장하면 그런 것들이 자연스럽게 이해돼요. 지금은 제 Discord 커뮤니티에 관리자들을 임명했고, 어떻게 운영되는지 꽤 명확하게 이해하고 있죠. 지속가능성 측면에서는, 저에게는 이 프로젝트로 생계를 유지하는 것에 대해 크게 걱정하지 않는 특권적 위치에 있어요. 그건 전혀 의도하지 않았죠. 하지만 저는 제가 지속할 수 있는 프로젝트를 만들고 싶어요. 그건 중요해요. 하지만 저는 제가 계속 할 수 있는 프로젝트를 만들고 싶어요.어떤 식으로든 기여자들을 돕거나 상위 프로젝트를 돕는 것입니다. 그래서 저는 적극적으로 논의하고 있습니다. 사람들이 이미 물어봤어요. 공개되지 않았는데도 사람들이 이미 물었죠. "프로젝트에 기부할 수 있나요?" 같은 것들이요. 아직 받고 있지는 않습니다. 하지만 제 생각은 이렇습니다. 제가 도움이 필요하지 않더라도, 제가 의존하는 많은 프로젝트들이 도움이 필요하니까 누군가 제 프로젝트를 돕고 싶다면, 그 도움을 그 프로젝트들에게 전달할 수 있을까요? 이를 통해 일종의 선행을 이어가는 메커니즘으로 사용할 수 있을까요? 마찬가지로, 기여하는 사람이 있다면, 아마 그들의 여가 시간에 하고 있을 텐데 그런 시간이 많지 않죠. 그래서 이런 생각을 합니다. 어떻게든 그들을 도울 수 있을까요? 같은 맥락에서요. 저는 매일 밤 몇 시간 일하는 것이 부담되지 않습니다. 비용이 들지 않으니까요. 하지만 누군가가 계약직으로 일할 수 있고 그것이 그들의 삶에 도움이 된다면, 제가 그 정도를 도울 수 있을까요? 전체 급여를 지급하려는 게 아니라, 정말로 좋아하는 것은 Zig 프로젝트가 재단 관점에서 하는 일입니다. 그들은 한 두 명만 고용하지만, 많은 기여자들에게 시간당 약 55달러를 지급합니다. 더 많은 금액으로 계약할 수 있지만, 이 아이디어는 프로젝트에 무료로 중요한 기여를 할 필요가 없다는 것입니다. 승인된 작업이라면, 시간당 55달러로 계약할 수 있고 그것도 의그래서 저는 제 프로젝트와 관련해서도 그것에 대해 많이 생각해 왔습니다. 알다시피, 마차를 말 앞에 두는 것처럼 느껴질 수 있죠.  때로는 저도 그렇게 느낍니다. 하지만  이제는 전에는 걱정하지 않았을 것들에 대해 걱정하게 되었습니다. 네, 그건 멋진 접근 방식이에요. 특히 JS 커뮤니티에서는  기반 프로젝트들보다 화려한 대형 프로젝트가  모든 자금을 흡수해버리는 문제가 있죠. 그래서 JS 코어 담당자 같은 사람들은 사람들이 자신의 프로젝트를 사용하는지도 모르기 때문에 기부를 받기 힘들어요. 네, 맞아요. 이것에 대해 많은 생각을 하고 있습니다. 제 프로젝트를 통해 행동으로 옮기려고 노력 중이에요. 다른 사람들과도 이야기하면서 이를 바꾸려고 노력하고 있습니다. 네. 오픈소스를 중심으로 사업을 구축하는 것은  쉽지 않을 수 있습니다. 결국 무료이고 개방된  소프트웨어를 기반으로 사업을 만드는 것이니까요. 하지만 결국 사업은 돈을 벌어야 합니다. 그래서 프로젝트를 시작할 때 적절한 라이선스를 선택하는 것이 중요하면서도 어려운 결정이 될 수 있습니다. 오픈소스 프로젝트를 시작할 때는 그냥 모든 사람이 사용할 수 있게 하고 싶어 하죠. 하지만 자연스럽게 사업으로 발전하다 보면 우리가 올바른 선택을 했는지 의문이 들 수 있습니다. 그때 가서 올바른 선택을 했는지 깨닫게 되는 거죠.우리가 올바른 선택을 하지 않았나요? 지금 어떻게 생각하세요? 네, 지금은 많이 다르게 생각합니다. 특히 상업적 오픈소스를 경험한 기업가로서 말이죠. 저와 많은 다른 오픈소스 창작자들을 대변해 말할 수 있을 것 같습니다. 정직하게 말씀드리면, Hashicorp 이전에 시작한 모든 프로젝트에서 비즈니스가 될 거라고 전혀 생각하지 않았습니다. 누군가 사용할 거라고도 생각 못했죠. 예를 들어 Hashicorp가 있기 전에 말이에요. 비즈니스가 될 거라 전혀 예상하지 못했고, 누군가 사용할 거라고도 생각하지 않았습니다. 많은 프로젝트가 그렇게 시작된다고 봅니다. 상업적인 생각이나 계획이 전혀 없이 시작되죠. 왜냐하면 상업적인 측면은 커뮤니티의 성공에 따른 부수적인 결과이기 때문입니다. 그것은 부수적인 효과이고, 일부 경우에는 탐욕에서 비롯될 수도 있겠지만, 제 경우는 정말 다른 이유였습니다. 최근에 이야기했듯이, 결국은 선택의 문제였습니다. 월세를 내기 위해 풀타임으로 일할지, 아니면 오픈소스를 상용화하는 걸 추구할지 선택해야 했죠. 그래야 그 일로 월세를 낼 수 있었으니까요. 둘 다는 할 수 없었습니다. 하루에 시간이 부족했기 때문에 일상생활을 영위할 방법이 필요했습니다. 그래서 그게 제 동기부여 요인이었죠. 매일매일 살아갈 방법이 필요했던 거예요. 그게 제 동기부여 요인이었습니다. 그래서 저는프로젝트 아이디어가 있고 오픈소스가 최선의 해결책이라고 판단했지만 상용화도 원한다면, 어떤 라이선스를 선택할지 더 잘 결정할 수 있는 위치에 있다고 봅니다. 라이선스 외에도 수익화 전략을 생각해볼 수 있죠. SaaS, 오픈코어, 듀얼 라이선싱, 지원 및 서비스 등 미리 결정할 수 있습니다.  문제는 제가 겪었고 많은 사람들이 겪는 것처럼 처음에는 상용화 계획이 전혀 없다가 나중에 특정 경로에 갇히게 되는 것입니다. 상용화하고 싶다는 걸 깨달았을 때는 이미 너무 많은 것을 공개해버려서 스스로가 가장 큰 경쟁자가 되어버리는 거죠. 오픈소스를 지지하는 사람으로서 오픈소스 자체를 탓하는 건 아닙니다.  오픈소스가 좋다 나쁘다 할 게 아니라 미리 계획하지 않은 것이 문제라고 봅니다. 초기 결정의 결과를 나중에 감당해야 하는 거죠. 네, HashiCorp 작별 편지에서 그런 점이 잘 드러납니다. 처음에는 '큰 기업들이 우리 소프트웨어를 쓴다면 어떨까?'라는 십대의 생각으로 시작했다고 하셨죠. '그냥 그들의 손에 넣기만 하면 어떨까?' 하는 생각에서 시작해서손에 들고 있지만 "만약 그런 일이 일어나면 어떡하지?"라는  미래에 대해 생각하지 않죠. 그걸로 생계를 꾸려야 할 수도 있는데 말이에요. 그리고 이건 자신만의 문제가 아닙니다. 상업화 경로를 선택하고 회사를 설립하면 많은 압박감이 생기게 됩니다. 그 압박감의 상당 부분은 이런 사실을 깨닫는 데서 옵니다. 알다시피, 제가 Armon과 Hashicorp를 시작했을 때, 우리는 실패를 두려워하지 않았어요. 실패해도 괜찮다고 생각했죠.  대담한 시도를 해보자고 했어요. 실패하더라도  그냥 다른 직장을 찾으면 된다고 생각했으니까요. 물론 요즘은 취업이 훨씬 더  어려워졌죠. 당시엔 경제 상황이 달랐습니다. 하지만 그때 우리는 22살의 젊은이였고 그렇게 생각했어요. 조금 무신경했을 수도 있지만, 그때는 그렇게 생각했고 신경 쓰지 않았죠. 하지만 직원들을 고용하기 시작하면서 상황이 달라졌어요. 어느 순간부터 저는 잠을 자는 데 어려움을 겪기 시작했습니다.  짧은 기간 동안 매일 불안감을 느꼈어요. 회사가 잘 되지 않던 시기에 특히 심했죠. 갑자기 많은 불안감이 밀려왔는데, 그 이유는 우리 회사의 급여에 의존해 생활하는 사람들이 있다는 걸 깨달았기 때문이에요. 그들은 그 돈으로 주택담보대출금을 갚고 아이들을 키우고 있었죠. 저는 아이가 없어서 실패해도 상관없었지만, 다른 사람들에게는 실패가 그들의 인생에 큰 영향을 미칠 수 있다는 그래서 어느 순간 그것이 나에게 와 닿았고 회사 자체도 어려움을 겪고 있었습니다. 그리고 저는 시작했습니다, 잠시 동안 정말 무거워지고 있었습니다. 저는 매우 특정한 줌 미팅이 있었다고 말씀드리겠습니다. 우리는 무언가의 상업적 적합성을 찾으려 하고 있었죠. 그리고 제가 얘기하고 있던 사람은 아주 평범한 근무 시간대에 원룸 아파트에서 세 아이와 함께 있었습니다. 두 아이가 뒤에서 소리를 지르고 있었고 그 사람은 노이즈 캔슬링 헤드폰을 착용하고 저와 얘기하고 있었습니다. 그 미팅을 마치고 저는 생각했습니다, 나는 그 사람에게 내가 목격한 것 이상의 스트레스를 주고 싶지 않다고. 그래서 그런 순간들이, 오픈소스이든 아니든, 상업적 기업의 창업자로서 결정을 내리는 데 있어 정말 큰 촉매제가 되기 시작했습니다. 저는 그렇게 생각합니다, 네, 오픈소스는 어렵습니다. 왜냐하면 근본적으로 인간적이기 때문이죠. 인간성과 많이 연관되어 있습니다. 우리는 이런 창의적인 것들을 만들어 세상에 내놓아 사람들이 즐기고 사용할 수 있게 하고 싶어 하죠. 그리고 우리는 그로부터 인정을 받습니다. 하지만 우리 자신의 필요와 특히 회사를 세우면서 다른 사람들의 필요를 떠안게 되는 현실이 있습니다. 저는 그저, 그것이 어려운 결정이라고 생각합니다. 처음에는 어려워 보이지 않을 수 있지만, 회사를 만들면서 다른 사람들의 필요를 책임지게 되면, 정말 어려운 결중요해집니다. 그리고 제 생각에는, 아시다시피, 많은 경우 큰 논란의 원인이 될 수 있지만, 사람들은 이것이 매우 인간적인 일이라는 점을  명심해야 합니다. 그리고 알다시피, 이것은, 심지어 사람들이, 기업들이  라이선스 결정을 재고하거나 할 때도, 종종 필요에 의해  지속 가능한 비즈니스를 구축하고 경쟁 시장에서  지속 가능한 비즈니스를 만들려는 생각에서 비롯됩니다. 그리고 문제는, 모든 가치를 무료로 제공하는 것은, 오픈소스에서 그렇게 하는 것이  칭찬할 만하지만, 실제로 결과가 따릅니다. 그래요, 아마도 원룸 아파트에 사는 세 아이의 부모가 회사가 예산을 긴축하려고 해서 일자리를 잃을 수도 있습니다.  그리고 그것은 실제적인 영향입니다. 그래서, 라이선스 변경이 그만한 가치가 있을까요? 절대적으로 그렇습니다. 만약 그 조직의 사람들이 일자리를 유지할 수 있다면 말이죠. 네, 물론입니다. 저는, 이런 일들의 인간적 비용이 때때로 간과된다고 생각합니다. 네, 제 생각에는, 아주 일반적인 말일 수 있지만, 해커 뉴스나 트위터 같은 곳에서, 제 영역에서는, 이것이 기술 분야에만 국한된 것은 아니라고 봅니다. 물론 다른 분야에서도 그렇겠지만, 특히 기술 분야에서는 사람들이 결정을 지나치게 단순화하는 경향이 있습니다.매우 환원주의적인 사고방식으로 모든 것을 생각하게 되죠. 세상이 단순하고 쉬운 결정만 있다고 생각하고 싶지만 제 경험상 그렇지 않습니다.  오픈소스와 관련 없이 사업을 운영하는 것만 봐도 거의 모든 결정이 어렵고 복잡한 측면이 있었습니다. 그게 그 위치에 있는 사람으로서 정말 스트레스 받는 부분이죠. 제가 공개적으로 이야기했고 자주 언급되던 주제 중 하나는 지금은 좀 오래된 이야기지만 Hashgraph가 원격 우선 회사라는 점이었습니다. 그런데 사람들이 "특정 국가에서 채용을 안 하니 진정한 원격 회사가 아니다"라고  자주 비난했죠. 어느 시점에 저는 정말 지쳤습니다. 그 글은 여전히 남아있고  당시에는 정확했습니다. 하지만 다른 사람의 원격 관련 글에 똑같은 말이 나오는 걸 보고 이제 바로잡아야겠다고 생각했습니다. 그래서 전 세계 어디서나 사람을 고용하는 것의 법적 복잡성에 대해  설명하는 댓글을 올렸습니다. 실제로는 그렇게 쉽지 않다는 점을 말이죠. IT 업계에서는 인터넷 때문에 우리나라에서 전 세계에 접근할 수 있다고 생각하는 경향이 있습니다. 뭔가를 입력하면 바로 연결되는 것처럼 느껴지죠. 하지만 실제로는 그렇게 단순하지 않습니다.어디든 갈 수 있을 것 같았죠. 하지만 제가 말씀드리고 싶은 점은 세상은 인재 채용 관점에서 매우 불평등하고, 우리는 법률에 묶여 있어서 제약을 받습니다. 그래서 저는 HR 외의 모든 결정에서도  마찬가지로 기술적 결정이나 그런 것들에서도 결정을 내리는 게 결코 쉽지 않았다고 봅니다. 쉽지 않은 결정 얘기가 나왔으니 말인데, 라이선스 선택도 꽤 어려울 수 있죠. 앞서 말씀하신 것처럼 새로운 흥미로운 라이선스들이 나왔고 그 당시 있었다면 선택했을 수도 있다고 하셨는데, 그 새로운 라이선스들은 무엇인가요? 제가 선택했을지는 모르겠지만, 중요한 건 제가 오픈소스 프로젝트를 시작했을 때 실제로 고려할 만한 선택지는 매우 관대한 라이선스들뿐이었다는 거예요. GPL, MIT, Apache, BSD 같은 오래된 오픈소스 라이선스들이 있었죠. 하지만 그게 전부였어요. 당시에는 수익화 수단으로서의 라이선스에 대한 논의가 없었습니다. 분명히 말씀드리면, 이중 라이선스는 하나만 존재했는데 GPL 프로젝트에서 돈을 내면 GPL이 아닌 다른 라이선스를 쓸 수 있었죠. 하지만 당시에는 아무도 그렇게 생각하지 않았어요. 지금은 모르겠지만 그때는 그게 사업 성장의 viable한 방법으로  여겨지지 않았죠.  벤처 성장의 실행 가능한 방법으로 보지 않았어요.사업이었죠. 작은 회사나 개인이 선택할 만한 viable한 옵션으로 여겨졌지만 벤처 성장 사업으로는 보지 않았어요. 그래서 실제로 논의 대상이 되지 않았죠. 요즘에는 추가 라이선스를 개발하려는 진지한 노력이 보이고 있어요. 이는 지속 가능성을 염두에 두면서도 소스를 공유하고 커뮤니티를 구축할 수 있게 하려는 의도입니다. 하지만 이 분야에는 아직 많은 불확실성이 있다고 봅니다. 모두가 동의하는 하나의 최선의 접근법은 명확히 없어요. 하지만 여전히 살펴볼 만한 흥미로운 주제라고 생각합니다. 아직 하나를 골라 추천하긴 어렵지만, 전체 커뮤니티가 이런 대안들을 탐구하기 시작했다는 점이 좋습니다. 사실 시작한 지 몇 년 됐지만, 지속 가능성을 염두에 두고 이런 대안들을 탐구하고 있다는 게 기쁩니다. 네, 정말 필요한 일이죠. 우리가 겪은 고통과 논쟁을 보면 이 분야에 더 많은 관심과 시도가 필요하다는 게 분명해요. 좋은 해결책을 찾을 수 있길 바랍니다. 비즈니스를 구축하면서 오픈소스 제품을 가지고 있다면, 양쪽의 장점을 모두 취할 수 있는 좋은 라이선스가 있으면 좋겠어요. 네, 두 가지 극단이 있죠. 하나는 GPL 수준의 완전히 자유롭고 오픈된 소스이고, 다른 하나는 완전히 폐쇄적이고 독점적인 소스입니다. GPL 수준의 완전히 자유롭고 오픈된 소스가 한쪽 극단이고, 다른 한쪽 극단은 완전히 폐그리고 오픈 소스를 절대적으로 지지하는 사람들조차도 모두가 동의할 것이라고 생각합니다 우리는 비즈니스를 위해 모든 것을 완전히 클로즈드 소스로 만드는 것이 더 쉬운 현실을 절대 원하지 않습니다. 알다시피, 저는 Mac OS와 같은 클로즈드 플랫폼에서 정기적으로 개발하는 개발자로서 그들은 오픈 소스 부분이 있지만 대부분은 클로즈드입니다 제가 아주 적은 권한만 가지고 있더라도 예를 들어 SwiftUI의 소스 코드를 갖는 것이 그렇지 않은 것보다 훨씬 낫습니다. 하지만 저는 그것을 가지고 있지 않죠. 그래서 어떻게 작동하는지 전혀 모릅니다 문서가 부족하면 완전히 곤란해집니다. 그래서 비즈니스가 성공할 수 있는 어떤 지점을 찾을 수 있기를 바랍니다 최소한 소스를 공유할 수 있는 능력을 유지하고, 가능하다면 커뮤니티를 구축하고 그 성공을 어느 정도 공유할 수 있기를 바랍니다. 하지만 이것은 정말 열린 활발한 질문이라고 생각합니다 네, 맞습니다. 자, 마지막 몇 가지 질문을 하겠습니다 우리는 항상 미래에 대해 이야기하며 세그먼트를 마무리합니다 앞으로의 전망이나 다음 계획에 대해서요. 그래서 아마도 당신에게는 터미널 인터뷰, 터미널 에뮬레이터를 작업하고 계시죠 거기에 많은 시간을 투자하고 계신데, 오랫동안 작업할 수 있는 그런 프로젝트일 수 있겠네요. 하지만 혹시 현재 프로젝트 이외에 다음으로 하고 싶은 비즈니스 아이디어나 전문적으로네, 현재로서는 아닙니다. 구체적인 아이디어는 없어요. 다음으로, 저는 이 터미널 에뮬레이터를 오랫동안 작업하길 바랍니다. 제 생각에는 터미널 에뮬레이션에는 많은 기술적 기회가 있습니다. 해결된 문제처럼 보이고, 오래되고 지루해 보일 수 있지만 말이죠. 실제로 많은 것들이 있다고 생각합니다. 제가 설명했듯이 이것은 웹 브라우저의 텍스트 플랫폼 버전입니다. 웹 브라우저가 사라지지 않을 것처럼요. 웹 브라우저를 없애려는 게 아닙니다, 그렇게 미친 건 아니에요. 하지만 견고한 텍스트 UI 플랫폼을 위한 공간이 있다고 생각하고 그게 바로 터미널이 하는 일이죠. 동시에 제가 말했듯이, 터미널은 거의 혁신하지 않습니다. 브라우저의 혁신 속도의 0.1% 정도에 불과해요. 그래서 만약 그걸 5%로만 올린다면, 조금이라도 시작해서 뭔가를 도입한다면 어떨까요. 그게 제가 하려는 거예요. 저는 이것을 제 기술적 자선 활동이라고 부릅니다. 우리는 삶에서 사회적 선을 추구하려 하고, 우리 공동체를 돕는 등의 방식으로 그렇게 하려고 하죠. 터미널 에뮬레이터는 제게 있어서 기술적 버블 버전의 그런 것입니다. 과거의 성공 덕분에 이제 시간이 더 많아져서, 제 열정과 에너지를 개발자들의 삶을 이런 식으로 더 나아지게 만드는 데 쏟을 수 있을까 하는 거죠. 그래서 터미널에 대해 그렇게 생각합니다. 하지만 그 외에는, 제가48:58.960 --> 49:02누군가 할 수 없는 일을. 나는 하지 않을 거예요. 바쁘게 지내는 걸 좋아하고 일하는 걸 좋아해요. 지금 당장 사업 아이디어는 없지만 계속 바쁘게 일할 거예요. 그래요. 심지어 터미널 에뮬레이터의  이름조차 그 느림을 말해주는 게 재미있어요. 왜냐하면 우리가 60년대의 것을 에뮬레이션하고 있잖아요?  왜 아직도 에뮬레이션이란 말이 들어가 있을까요? 네, 실제로 커뮤니티의 일부 사람들과 이에 대해 얘기해봤어요. 기본적으로는 옛날 터미널을 에뮬레이션하지만, 혁신을 시작하면 그게 공정하고 정확할까요? 터미널 에뮬레이션이라고 부르면 사람들이 화낼까요? Kitty, Alacrity 같은 다른 터미널 에뮬레이터들도 있잖아요. 그들을 대변하는 건 아니지만, 내가 새로운 걸 시도하면 그들이 당연히 할 수 있는 반응은 "그만해"일 거예요. 더 이상 에뮬레이션이 아니라 혁신이고, 그들에게 더 많은 일을 만들어내고 화나게 할 테니까요. 그래서 다른 표현을 써야 할지, 특정 기능에 대해 다른 터미널과 호환되려고 하지 않는다고 말해야 할지 고민했어요. 그들에게 강요하려는 게 아니라 대체 텍스트 인터페이스 플랫폼 같은 걸 만들려고 한다고요. 아직 모르겠어요. 여전히 고민 중이에요. 네, 이 분야에서 일하는 몇 사람과 얘기해봤어요. 초기 에피소드 중 하나는 Fig 창업자들이었는데, 결국 아마존에 회사를 팔았죠. 그들은 정말 흥미로운 일을 하고 있그들은 장기적으로 터미널을 재구축할 계획을 가지고 있었습니다 Warp 창립자들을 초대했는데, 그들은 그 분야에서 정말 흥미로운 작업을 하고 있습니다. 좋은 분야라고 생각하고 사람들이 그 일을 하는 것을 보니 기쁩니다. 개발자들은 특히 터미널에서 많은 시간을 보내기 때문에 그 경험을 개선하는 것이 중요합니다. 팟캐스트에서는 그 사람이 관여한 분야에 대해 미래 지향적인 질문을 하고 싶습니다. 당신은 클라우드와 인프라 분야에 10년 이상 관여해 왔습니다. 네, 거의 평생 동안 말이죠. 클라우드와 인프라의 미래가 어떻게 될 것 같나요? 더 복잡해질까요, 아니면 덜 복잡해질까요? 네, 제 생각에는 먼저 제가 더 이상 이 분야에서 일하지 않는다는 점을 밝힙니다 Hashicorp를 떠날 때의 제 생각은 지금도 같은데, 덜 복잡해져야 한다고 봅니다 제가 Hashicorp를 시작했을 때는 매우 제한된 도구들이 있었고 사용하기 어려웠습니다 지금은 개별적으로는 사용하기 쉬운 많은 도구들이 있지만 원하는 작업을 수행하려면 더 많은 도구들을 연결해야 합니다 그리고 그것이 좋지 않게 느껴집니다. 그래서 저는 미래가 더 단순해지기를 희망합니다 그리고사용 면에서 더 간단하고 복잡성 측면에서도 더 단순해집니다. 쿠버네티스를 예로 들면, 쿠버네티스는 좋지만 제가 쿠버네티스를 사용할 때마다 쿠버네티스만 있는 게 아니라 쿠버네티스와 10개 정도의 다른 벤더 프로젝트가 통합되어 있습니다. 그래서 매우 복잡해집니다. HashiCorp도 어느 정도 그 문제의 일부입니다. Vault만 해도 사용하려면 많은 다른 도구가 필요합니다. 그래서 단순화할 기회가 있다고 봅니다. 그게 미래라고 생각합니다. 일부는 제가 과거의 PaaS로 돌아가자는 뜻으로 이해하는데, Heroku 같은 것을 다시 쓰자는 게 아닙니다. Heroku를 좋아했고 새로운 Heroku 스타일 서비스도 좋아하지만, 모든 사람에게 완벽히 맞는 박스를 만들기는 너무 어렵습니다. 그래서 그런 서비스가 다시 성장해 시장의 일부를 차지하더라도, 더 복잡하고 특별한 요구사항이 있는 쪽에서는 더 단순하고 나은 도구가 필요할 것입니다. 복잡하고 특별한 요구사항이 있는 쪽에서는 더 단순하고 나은 도구가 필요할 것입니다. 좋습니다. 이번 주 질문은 여기까지입니다. 팟캐스트에 와주셔서 감사합니다. 지난 10년간의 일에 대한  당신의 견해를 들을 수 있어 즐거웠고, Zig와 터미널 에뮬레이터에 대해  이야기 나눌 수 있어 좋았습니다. 정말 감사합니다. 대화 나누기 좋았습니다. 네, Mitchell, 출연해 주셔서 감사합니다. 당신의 작업은이 분야에 있는 모든 사람들에게 확실히 영향을 미쳤죠 그리고 제 경력 초기에 당신의 오픈소스 프로젝트를 사용한 후에 이렇게 당신과 대화를 나누는 것이 참 흥미롭네요 정말 재미있는 경험이에요. 저를 초대해 주셔서 정말 감사합니다 좋은 시간이었어요. 정말 고마워요