이 영상은 하시코프(HashiCorp)의 공동 창립자이자 고스티(Ghostty)의 창시자인 미첼 하시모토와의 인터뷰를 담고 있습니다. 그는 소프트웨어 엔지니어링에 입문한 과정, 하시코프의 설립 역사, 그리고 널리 사용되는 오픈소스 도구를 성공적인 비즈니스로 전환하는 데 겪었던 어려움에 대해 이야기합니다. 또한, AWS, Azure, GCP와 같은 클라우드 서비스 제공업체들과 스타트업으로서 협업했던 솔직한 경험과 함께 AI 도구, 특히 AI 에이전트가 그의 일상 업무 방식에 어떤 혁명적인 변화를 가져왔는지 자세히 설명합니다. 그는 AI 시대에 소프트웨어 엔지니어와 창업자들에게 어떤 변화가 오고 있는지에 대한 깊이 있는 통찰을 제공합니다.
1. 소프트웨어 엔지니어링 입문과 오픈소스와의 첫 만남
미첼 하시모토는 12~13살 무렵, 비디오 게임에 대한 열정으로 코딩을 독학하기 시작했습니다. 하지만 곧 게임 프로그래밍보다는 웹 프로그래밍에 더 큰 흥미를 느꼈습니다. 당시 웹은 새로운 분야였고, 그는 PHP와 Perl을 사용하며 웹사이트를 만들었습니다. 어릴 적 돈이 없어 전문 서적을 살 수 없었던 그는 온라인에서 공개된 코드를 통해 프로그래밍을 배웠고, 이것이 그가 오픈소스(open source)를 접하게 된 계기가 되었습니다.
"저는 12, 13살, 어린 10대 때 비디오 게임에 대한 동기로 독학했어요. 많은 사람들과 마찬가지로요. 하지만 저는 웹을 좋아한다는 것을 정말 빨리 깨달았어요. 구글도 없던 시절이었죠."
그는 PHP 매뉴얼의 첫 두 챕터를 30~40페이지 분량으로 출력해 매일 학교에 걸어가면서 읽었습니다. 처음에는 너무 어려웠지만, 어느 순간 '달러 기호'가 변수(variables)라는 것을 깨닫게 되면서 코딩에 대한 이해가 폭발적으로 증가했다고 회상합니다. 그는 게이밍 웹사이트, 포럼 소프트웨어 등을 만들며 즐거움을 느꼈고, 심지어 온라인 송금이 어떻게 이루어지는지 궁금해 페이팔(PayPal) 클론을 만들기도 했습니다. 대학에서는 컴퓨터 과학을 전공하며 코딩에 대한 열정을 이어갔습니다. 고등학교 시절에는 프로그래밍을 친구들에게 숨겼지만, 대학에 진학하면서 비로소 자신의 열정을 드러낼 수 있게 되었습니다.
2. 하시코프 설립의 배경: 실패한 연구 프로젝트와 미해결 문제
대학 시절, 미첼은 루비 온 레일즈(Ruby on Rails) 컨설팅 회사에서 인프라스트럭처에 대한 흥미를 키웠습니다. 당시 그의 상사는 리눅스(Linux)를 사용하며 마우스를 전혀 쓰지 않았는데, 미첼은 이러한 모습에 매료되어 그에게 인프라 기술을 배웠습니다.
"그가 제 마우스를 뽑았어요. 그리고는 '이제 다시는 마우스로 작업하지 않을 거야. 알아서 해봐. 어떻게 해야 할지 말해주지 않을 거야.'라고 말했어요."
이후 그는 워싱턴 대학교의 '시애틀 프로젝트'라는 연구 프로젝트에 참여했습니다. 이 프로젝트는 다양한 컴퓨터(개인 PC, 서버 랙 등)를 활용하여 분산 컴퓨팅 환경을 구축하고, 학술 기관들이 워크로드를 실행할 수 있도록 하는 것이 목표였습니다. 미첼은 이 프로젝트에서 노드를 배포하는 역할을 맡았지만, 결국 실패로 끝났습니다.
하지만 이 실패는 오히려 그에게 영감을 주었습니다. 그는 실패의 원인을 분석하며 어떤 기술적 구성 요소들이 부족했는지 노트북에 꼼꼼히 기록했습니다. 이 노트에는 "선언적으로 리소스를 관리할 방법이 없다", "프라이빗 네트워크로 연결할 방법이 없다"와 같은 문제점들이 적혀 있었고, 이 내용들은 훗날 하시코프의 핵심 제품인 하시 스택(Hashi stack)을 구성하는 밑거름이 됩니다.
이 시기에 미첼은 컨설팅 경험을 바탕으로 개발 환경의 재현성 문제를 해결하기 위해 Vagrant라는 오픈소스 도구를 개발했습니다. Vagrant는 가상 머신을 쉽게 구축하고 관리할 수 있게 하여 개발자들이 빠르고 일관된 개발 환경을 구축할 수 있도록 도왔습니다.
"제 메타포는 항상 이랬어요. 윈도우를 사용하지는 않았지만, 어떻게 하면 더블 클릭으로 개발 환경을 열 수 있을까? 였어요."
그는 당시 클라우드 컴퓨팅, 특히 AWS가 막 태동하던 시대를 직접 경험하며, 클라우드가 미래의 더 나은 방식이라고 확신했습니다.
3. 하시코프의 초기 도전: 멀티클라우드 비전과 투자 유치
미첼은 학부 시절 보스였던 아르만 다다르(Armon Dadgar)와 함께 하시코프를 설립했습니다. 당시 두 창업자는 멀티클라우드(multicloud)에 대한 강력한 비전을 가지고 있었습니다. 2011~2012년 당시 AWS가 시장을 지배하고 있었고, Azure와 Google Cloud는 거의 존재하지 않던 시기였기에, 클라우드에 구애받지 않는 도구를 만들겠다는 그들의 생각은 회의적인 시선을 받았습니다. 하지만 그들은 "경제적으로 거대한 것이라면 다른 사람들도 파이의 조각을 원할 것"이라며 멀티클라우드의 등장을 확신했습니다.
하시코프는 초기 6개월 동안 미첼이 개인 저축 2만 달러로 자금을 조달하며 시작되었고, 미첼은 급여를 받지 않았습니다. 이후 아르만도 합류하면서 두 사람은 벤처캐피탈(VC) 투자를 유치하기로 결정했습니다. 그들은 회사를 부트스트랩(bootstrapping)하는 방식으로는 너무 많은 시간이 소요될 것이며, 클라우드 시장의 빠른 성장에 맞춰 빠르게 성장하기 위해서는 투자가 필수적이라고 판단했습니다.
"우리가 부트스트랩하면 아무리 성공해도 소프트웨어를 만드는 데 10년이 걸릴 거예요. 이건 너무 느릴 거예요. 느리면 문제가 뭐냐면, 세상에는 창문이 있고 클라우드는 너무 빠르게 성장하고 있었어요."
하시코프는 시드(Seed) 단계에서는 제품 개발에 집중하고, 시리즈 A에서는 제품 시장 적합성(Product-Market Fit)의 힌트를 보여주며, 시리즈 B부터는 반복 가능한 매출을 만드는 데 집중하는 방식으로 성장했습니다. 그들의 오픈소스 제품은 수백만 건의 다운로드와 수많은 GitHub 스타를 기록하며 강력한 제품 시장 적합성을 입증했지만, 초기 4년간은 실제 수익이 거의 없었습니다.
4. 하시 스택의 탄생과 사업화 실패
하시코프가 자체적으로 출시한 첫 번째 제품은 Packer였습니다. Packer는 VM 이미지 빌드 도구로, AWS, VMware 등의 이미지를 생성하여 클라우드 환경에서 빠른 오토스케일링(autoscaling)을 가능하게 하는 데 기여했습니다.
다음으로 출시된 Consul은 서비스 디스커버리(service discovery) 문제를 해결했습니다. 기존에는 고정된 IP를 가진 서버들을 관리했지만, 클라우드 환경에서는 서버들이 끊임없이 생성되고 파괴되므로, 빠르고 안정적인 서비스 디스커버리가 필수적이었습니다. Consul은 쿠버네티스(Kubernetes)의 헬스 체크와 유사한 기능을 제공하며 이러한 문제를 해결했습니다.
그리고 2014년에 출시된 Terraform은 하시코프를 대표하는 제품이 됩니다. Terraform은 인프라스트럭처를 코드로 관리(Infrastructure as Code)하는 도구로, 사용자가 텍스트 파일로 인프라를 정의하면 AWS와 같은 클라우드 환경에 수천 개의 리소스를 자동으로 배포하거나 파괴할 수 있도록 했습니다.
"아이디어는 AWS 계정이나 어떤 클라우드 계정이라도 비어 있는 상태에서 이 텍스트를 가지고 '이 텍스트를 현실로 만들어라'라고 말하는 것이었어요."
이어서 출시된 Vault는 비밀 관리(secrets management) 솔루션입니다. 비밀번호뿐만 아니라 개인 식별 정보(PII), 신용카드 번호 등 민감한 데이터를 안전하게 저장하고 관리하는 역할을 합니다. 미첼은 Vault 개발 당시 팀원들의 보안 경험이 부족해 많은 두려움을 느꼈고, 외부 보안 감사에 막대한 비용을 지불해야 했다고 고백합니다.
"팀원 중 어느 누구도 학부 보안 경험이 한 학기를 넘는 사람이 없었다는 사실을 숨겼어요."
이후 출시된 Nomad는 미첼이 학부 시절 실패했던 분산 컴퓨팅 스케줄링 문제를 해결하는 도구였습니다.
하시코프는 초기 4년간 이 비전을 구현하는 데 집중했지만, 비즈니스 모델을 구축하는 데는 어려움을 겪었습니다. 그들의 첫 상용화 시도였던 Atlas라는 통합 제품은 큰 실패로 돌아갔습니다. 이 제품은 하시코프의 모든 제품을 한 번에 도입해야 했고, 여러 부서의 예산을 아우르는 복잡성 때문에 고객들에게 외면받았습니다.
"회사에서 여러 구매 조직이 서로 싸우는 문제였어요. 그래서 모든 도구를 채택한 사람들조차도 '누가 이것을 지불해야 하는가?'라는 문제에 부딪혔어요."
5. 오픈 코어(Open-Core) 모델로의 전환과 상장
Atlas의 실패 이후, 미첼과 아르만은 이사회에서 질책을 받은 뒤 주말 내내 회사 방향성을 재고했습니다. 그들은 "만약 처음부터 시작한다면 무엇을 다르게 할까?"라는 질문을 던졌고, 그 결과 제품별 엔터프라이즈 솔루션과 오픈 코어 비즈니스 모델(Open-Core business model)을 채택하기로 결정했습니다. 이는 오픈소스 제품을 기반으로 하되, 기업 고객을 위한 추가 기능은 클로즈드 소스(closed source)로 제공하는 방식입니다.
월요일 전 직원 회의에서 이러한 급진적인 변화를 발표했을 때, 미첼과 아르만은 직원들이 대거 퇴사할 것이라고 예상했습니다. 하지만 놀랍게도 아무도 퇴사하지 않았고, 오히려 팀 분위기는 훨씬 긍정적으로 바뀌었습니다. 직원들은 불확실한 방향성 대신 명확한 목표가 생겼다는 사실에 만족했습니다.
"모두가 우리가 명확한 방향성과 확신을 갖게 된 것에 대해 흥분하고 있었어요."
이후 그들은 Vault Enterprise를 먼저 출시했고, 몇 달 만에 성공적인 전환의 조짐을 보였습니다. 보안 부서라는 명확한 구매자와 예산이 있었고, Secrets Replication과 같은 핵심 엔터프라이즈 기능은 고객들의 니즈에 정확히 부합했습니다. 기업 고객들은 오픈소스 여부보다는 상업적 계약, 지원, 개념 증명(POC) 등을 더 중요하게 여겼습니다.
Vault에 이어 Terraform과 Consul도 엔터프라이즈 버전을 출시하며 하시코프는 빠르게 성장했습니다. 특히 Terraform은 업계 전반에 걸쳐 엄청난 인기를 얻었습니다.
"테라폼이 업계 전반에 걸쳐 너무나 너무나 인기를 얻은 것을 기억해요."
미첼은 이 시기, 컨퍼런스 강연과 사람들과의 만남을 위해 엄청난 양의 출장을 다녔습니다. 2020년 코로나 봉쇄령이 시작되기 전까지 9년 동안 8일 이상 같은 장소에 머문 적이 없었다고 회상합니다. 그는 이동 중에도 코딩을 하기 위해 GitHub 이슈들을 10~15분 단위의 작은 작업으로 쪼개어 오프라인에서 작업한 후, 랜딩 후에 한 번에 푸시하는 시스템을 사용했습니다.
2021년, 하시코프는 성공적으로 상장(IPO)했습니다. 미첼은 상장 준비 과정이 1년 이상 소요되며, 상장 전부터 상장 기업처럼 운영되어야 하는 등 많은 준비가 필요했다고 설명합니다. 상장 전에는 규제 준수를 위해 모든 공개적인 발언을 극도로 자제해야 했습니다.
6. AWS, Azure, Google Cloud에 대한 솔직한 견해
하시코프를 떠난 후, 미첼은 AWS, Azure, Google Cloud와 같은 대형 클라우드 서비스 제공업체들과의 협력 경험에 대해 솔직한 견해를 밝혔습니다.
- AWS: 미첼은 AWS를 "거만하고 짜증 나는 존재"로 묘사합니다. 파트너십 논의나 미팅을 가질 때마다 AWS가 자신들에게 "호의를 베푸는 것" 같았다고 말합니다. 또한, AWS가 언제든 자신들의 제품을 만들어 스타트업을 고사시킬 수 있다는 미묘한 위협을 느꼈다고 덧붙였습니다. 실제로 AWS는 Elastic Search와 같은 오픈소스 프로젝트를 기반으로 서비스를 출시하며 논란을 일으킨 바 있습니다. Terraform AWS Provider 개발에 대한 AWS의 지원을 받기 위해 "AWS Provider를 더 이상 지원하지 않겠다"고 공개적으로 선언할 정도로 강경하게 나설 수밖에 없었다고 합니다.
"AWS는 정말 거만했어요. 짜증 날 정도로 거만했어요. 그들이 우리에게 호의를 베푸는 것 같았어요." "우리가 제품을 만들어서 당신의 회사를 죽일 거야 라는 미묘한 분위기가 항상 있었어요."
- Microsoft Azure: 미첼은 마이크로소프트에 대해 가장 긍정적인 평가를 내렸습니다. 기술적으로는 복잡했지만, 비즈니스 측면에서는 유능하고 협력적인 파트너였다고 말합니다. 그들은 모든 미팅에서 "어떻게 하면 양측 모두 이길 수 있을까?"라는 질문을 먼저 던졌다고 합니다. Azure는 Terraform 지원에도 가장 먼저 적극적으로 나섰습니다.
"마이크로소프트에 대해서는 가장 긍정적인 견해를 가지고 있어요. 그들은 정말 까다로운 기술 제품을 가지고 있었어요." "그들은 우리가 만난 모든 회의에서 첫 번째 질문이 '어떻게 하면 우리 둘 다 이길 수 있을까요?'였어요."
- Google Cloud (GCP): 구글 클라우드는 최고의 기술력과 아키텍처적 사고를 가졌지만, 비즈니스 측면에서는 전혀 신경 쓰지 않는다는 인상을 받았다고 합니다. 기술적인 논의는 활발했지만, 공동 판매(co-sell)나 영업 엔지니어의 할당량(quota) 조정 등 비즈니스 협력에 대한 논의는 거의 이루어지지 않았다고 회상합니다. 구글은 Terraform 프로바이더를 자동화된 방식으로 매우 훌륭하게 구축했지만, 그것을 어떻게 판매할지에 대한 논의는 어려웠다고 합니다.
"구글 클라우드는 항상 최고의 기술력, 가장 놀라운 기술력과 아키텍처적 사고를 가지고 있었어요." "그들 중 어느 누구도 비즈니스에 대해 전혀 신경 쓰거나 생각하지 않는 것 같았어요."
7. Ghostty 개발과 AI 시대의 오픈소스
하시코프를 떠난 후, 미첼은 3년 전부터 프로토타입으로 작업하던 Ghostty 개발에 본격적으로 뛰어들었습니다. Ghostty는 터미널 프로그램으로, 기존 터미널의 한계를 뛰어넘어 현대적인 기능을 제공하는 것이 목표입니다. 미첼은 15년간 인프라스트럭처와 클라우드 서비스에 집중하면서 데스크톱 소프트웨어 개발 능력이 녹슬었다고 느껴, 이를 다시 단련하기 위해 Ghostty 개발을 시작했습니다. 그는 Zig 프로그래밍 언어와 GPU, 데스크톱 소프트웨어 기술을 활용하여 터미널을 직접 구축해보기로 했습니다.
"저는 10년 넘게, 하시코프 법인에서 12년, 그 전 3년 동안 인프라 오픈소스를 했어요. 총 15년 동안 인프라와 클라우드 서비스에 대해서만 생각했어요." "제가 지그를 선택한 이유는 그냥 멋있어 보였기 때문이에요. 한번 시도해보고 싶었어요."
터미널은 텍스트 콘텐츠를 위한 브라우저와 유사하며, 텍스트, 색상, 이미지, 위젯, 마우스 이벤트 등 다양한 요소를 렌더링해야 하는 복잡한 시스템입니다. Ghostty는 UI, IO, 렌더러의 세 가지 스레드로 구성된 멀티스레드 아키텍처를 채택했습니다. 미첼은 Ghostty가 '터미널의 30%, 폰트 렌더러의 70%'라고 농담하며 폰트 렌더링의 복잡성을 강조합니다. Ghostty는 특히 성능 최적화에 집중하여 대용량 파일을 빠르게 덤프하는 데 강점을 보입니다.
"Ghostty의 복잡성에 대해 농담처럼 말하자면, 터미널의 30%, 폰트 렌더러의 70%예요."
AI는 터미널 사용량 증가라는 예상치 못한 부작용을 가져왔습니다. AI 기반의 CLI 도구들과 코드 생성 앱들이 많아지면서, 개발자들이 터미널을 사용하는 시간이 2023년 대비 훨씬 늘어났다는 것입니다. 미첼은 이 때문에 Ghostty의 핵심 기능을 libghosty라는 제로 종속성 라이브러리로 추출하여, 누구나 자신의 애플리케이션에 터미널 기능을 쉽게 임베드할 수 있도록 했습니다.
8. AI 에이전트를 활용한 작업 방식의 혁신
미첼은 AI 도구의 열렬한 팬이며, 매일 클라우드 코드(Cloud Code), AMP, 코드렉스(Codex)와 같은 도구와 챗 도구를 사용한다고 말합니다. AI는 그가 "무엇을 생각할지 선택할 수 있도록" 해 주었습니다. 과거에는 지루하고 반복적인 상용구(boilerplate) 작업에 시간을 많이 썼지만, 이제는 AI에 위임하고 그 시간에 더 중요한 일에 집중할 수 있게 되었습니다.
"저에게 가장 중요한 것은 무엇을 생각할지 선택할 수 있게 해 주었다는 점이에요."
그의 표준 워크플로우는 항상 AI 에이전트가 무언가를 하도록 만드는 것입니다. 그는 코딩을 할 때 에이전트가 계획을 세우게 하거나, 에이전트가 코드를 작성할 때 자신은 코드 리뷰를 하는 식입니다. 때로는 두 개의 에이전트를 동시에 돌려 어려운 작업을 경쟁시키거나, 하나는 코딩, 다른 하나는 리서치 작업을 시키기도 합니다. 그는 특히 리서치 작업에서 AI 에이전트의 효율성에 감탄합니다.
미첼은 AI가 생성한 코드에 대해 작업의 성격에 따라 다르게 접근합니다. 개인적인 웹사이트와 같이 중요도가 낮은 프로젝트의 경우 코드를 전혀 신경 쓰지 않고, 3개의 브라우저와 휴대폰에서 제대로 렌더링되면 바로 배포합니다. 하지만 Ghostty와 같이 핵심 프로젝트의 경우 모든 코드를 직접 리뷰합니다.
9. AI 시대의 오픈소스: 신뢰 시스템의 변화
Ghostty 프로젝트는 AI가 생성한 저품질 기여(low-quality AI contributions)로 인해 어려움을 겪고 있습니다. AI는 "그럴듯해 보이지만 부정확하고 저품질의 기여를 만드는 것을 사소하게 만든다"는 것이 미첼의 설명입니다. 그는 과거에는 저품질 코드라도 기여자가 진심으로 노력했기 때문에 교육적인 접근을 했지만, AI가 생성한 코드는 저노력으로 만들어진 것이므로 그럴 필요가 없다고 말합니다.
이러한 문제 때문에 Ghostty는 AI가 작성한 Pull Request(PR)에 대한 정책을 변경했습니다. 처음에는 AI 사용 여부 공개(disclosure)를 요구했지만, 저품질 AI PR의 양이 감당할 수 없을 정도로 늘어나자 정책을 더욱 강화했습니다. 현재는 승인된 기능 요청과 관련이 없는 AI 생성 PR은 허용되지 않으며, 내용 확인 없이 바로 닫아 버립니다.
"AI는 그럴듯해 보이지만 부정확하고 저품질의 기여를 만드는 것을 사소하게 만들어요."
나아가 Ghostty는 '보증(vouching) 시스템'으로의 전환을 준비하고 있습니다. 이는 커뮤니티 멤버의 보증 없이는 누구도 PR을 열 수 없게 하는 시스템입니다. 보증을 통해 신뢰를 얻은 사용자는 PR을 제출할 수 있지만, 만약 그들이 나쁜 행동을 하면 보증인과 그 보증인이 보증한 모든 사용자까지 레포지토리에서 영구적으로 차단됩니다. 이 시스템은 소셜 네트워크 'Lobsters'와 AI 툴킷 프로젝트 'PI'에서 영감을 받았습니다.
미첼은 AI로 인해 대부분의 오픈소스가 변해야 할 것이라고 전망합니다. 과거에는 PR을 제출하는 데 필요한 노력이 자연적인 진입 장벽 역할을 했지만, AI가 이를 제거하면서 신뢰 시스템이 재정립되어야 한다는 것입니다. 과거에는 기본적으로 '신뢰'를 기반으로 했지만, 이제는 '기본적으로 거부'하고 신뢰를 얻어야 하는 방향으로 바뀔 것이라고 예상합니다.
미첼은 또한 '포크(fork)'의 중요성을 강조합니다. 과거에는 포크가 많은 노력을 필요로 했지만, AI 시대에는 더 많은 포크가 활성화되어야 한다고 주장합니다. 이는 유지보수자들이 기여자의 요구에 반드시 응할 필요가 없으며, 기여자가 자신의 코드를 직접 유지보수할 수 있는 권리라는 점에서 중요합니다.
10. Git과 모노레포(Monorepos)의 미래, 그리고 소프트웨어 엔지니어링의 변화
AI 에이전트가 생성하는 코드의 양이 폭발적으로 증가하면서, Git과 모노레포(Monorepos)의 한계가 드러나고 있습니다. Git은 매우 큰 리포지토리(repository)에 상대적으로 취약하며, 전체 리포지토리를 복제해야 하는 문제 등이 있습니다. AI 에이전트가 엄청난 양의 코드를 생성하고 병합 대기열(merge queue)이 깊어지면서, 메인 브랜치(main branch)의 일관성을 유지하기가 극도로 어려워질 것이라는 전망입니다.
미첼은 Git에 많은 문제점이 있다고 지적하며, 특히 실패한 실험이나 채택되지 않은 코드 변경사항에 대한 정보가 사라지는 것을 아쉬워합니다. 그는 이를 Gmail이 이메일 저장 공간의 한계를 없애 '삭제하지 않고 아카이브하라'는 문화를 만든 것에 비유하며, 코드 역시 모든 정보를 버리지 않고 저장하는 방향으로 가야 한다고 주장합니다.
"흥미로운 점은 12년에서 15년 만에 처음으로 아무도 웃지 않고 그 질문을 한다는 점이에요."
그는 5년 전에는 누구도 Git의 미래에 대해 진지하게 묻지 않았지만, 이제는 Git이 5년 후에도 존재할지에 대해 진지하게 질문하는 사람들이 생겨났다는 점을 강조합니다. AI 시대의 에이전트 인프라스트럭처는 현재의 Git 및 GitHub 시스템과 호환되지 않으며, 근본적인 변화가 필요하다고 역설합니다.
미첼은 AI 시대에 CI/CD, 테스트, 코드 리뷰 등 전통적인 엔지니어링 관행들이 모두 변화할 것이라고 예상합니다. 특히 테스트는 AI 에이전트가 자신의 작업을 검증할 수 있도록 훨씬 더 광범위하게 확장되어야 한다고 말합니다. 그는 이를 '하네스 엔지니어링(harness engineering)'이라고 부르며, AI가 잘못된 일을 했을 때 이를 막거나 수정할 수 있는 도구를 구축하는 데 집중해야 한다고 강조합니다.
"모든 것이 변하고 있다는 점이에요. 그리고 제 짧지만 다른 사람들에게는 비교적 짧은 20년의 전문 경력에서 이렇게 많은 것이 동시에 변화의 대상이 되는 것은 처음이에요."
또한, AI 에이전트가 필요로 하는 샌드박스 환경(sandbox environments)으로 인해 최소 컴퓨트 유닛(minimal compute units)의 양이 폭발적으로 증가하고 있으며, 이는 Docker나 Kubernetes와 같은 기존 인프라 시스템에 큰 부하를 줄 것이라고 예측합니다.
11. 인재 채용과 미래 창업자를 위한 조언
미첼은 하시코프 시절 채용했던 최고의 엔지니어들은 의외로 "지루한 배경"을 가진 사람들이 많았다고 말합니다. 이들은 사생활을 중시하고, 9시부터 5시까지 근무하며, 퇴근 후에는 코딩을 하지 않는 경우가 많았습니다. 하지만 업무 시간에는 극도로 집중하며 뛰어난 역량을 보여주었다고 합니다. 그는 공개적인 GitHub 활동이 없더라도, 이름 없는 회사에서 깊이 있는 전문성을 쌓은 엔지니어들을 눈여겨보았다고 합니다.
"제가 하시코프에서 기억하는 가장 뛰어난 엔지니어들은 대부분 지루한 배경을 가지고 있었어요."
미첼은 자신이 사회관계망서비스(SNS)에 많은 시간을 할애하지만, 최고의 엔지니어들은 SNS에 시간을 낭비하지 않고 컨텍스트 스위칭(context switching)을 최소화한다고 지적합니다. 그 자신도 밤늦게까지 잠들기 전에 머릿속으로 코드를 작성하고 제품을 구상하는 등 끊임없이 생각한다고 합니다.
AI 시대의 채용에 대해 미첼은 AI 도구에 대한 역량이 필수적이라고 강조합니다. AI를 모든 것에 사용할 필요는 없지만, 필요할 때 적절히 활용할 줄 알아야 한다는 것입니다. 특히 개념 증명(Proof of Concept)과 같은 초기 단계에서는 AI를 활용해 빠르게 프로토타입을 만들어보는 능력이 중요하다고 말합니다. 그는 모든 엔지니어가 항상 AI 에이전트를 가동하여 느린 작업을 위임하도록 독려해야 한다고 주장합니다.
"AI 도구에 대한 능력이 필수적이라고 생각해요. 모든 것에 사용할 필요는 없어요. 하지만 적절하게 활용할 줄 알아야 해요."
미첼은 AI 에이전트의 방해를 피하기 위해 모든 알림을 끄고, 자신이 에이전트를 방해할 때만 결과를 확인한다고 말합니다. 또한, 그는 엔지니어링 작업 중 생각을 요구하지 않는 작업과 생각을 요구하는 작업을 명확히 구분하여 전자는 에이전트에게 위임한다고 합니다. 그는 AI 도구를 잘못 사용하면 생각을 덜 하게 되지만, '무엇을 생각할지 선택하는 방법'으로 활용하면 사고력을 희생할 필요가 없다고 조언합니다.
미첼이 미래의 창업자들에게 주는 가장 일반적인 조언은 "스타트업은 생각보다 훨씬 길다"는 것입니다. 그는 최소 10년 동안 이 일을 할 것인지 자문해야 한다고 말하며, 자신이 누구보다 이 일을 잘할 수 있다는 "어느 정도의 오만함(hubris)"이 필요하지만, 동시에 변화에 눈이 멀지 않을 정도의 균형감각도 중요하다고 강조합니다.
AI 스타트업의 경우, 전례 없이 빠르게 움직여야 하는 압박을 받고 있다고 지적합니다. AI는 미친 듯이 빠르게 움직일 수 있게 해주며, 동시에 많은 회사들이 실제로 그렇게 움직이고 있기 때문입니다. 그는 또한 시드(Seed) 투자 전에도 AI를 활용해 프로토타입을 빠르게 구축할 수 있게 되면서, 투자 유치 과정에도 변화가 생겼다고 덧붙였습니다.
12. 마무리
미첼 하시모토는 AI 시대에 소프트웨어 엔지니어의 역할이 더욱 '모호한 작업(vague tasks)'을 처리할 수 있는 역량을 요구할 것이라고 말합니다. 엔지니어들은 이제 팀 없이도 전체 데모를 만들고, 효과적으로 리서치하며, 더 많은 실험을 수행할 수 있게 될 것입니다. 하지만 생산화 단계에서는 기존과 유사한 방식이 유지될 것으로 보입니다.
코딩과 기술 외적으로 미첼에게 에너지를 채워주는 것은 바로 '조용하고 혼자만의 시간'입니다. 그는 내향적인 사람으로서 해변을 산책하거나, 밤에 소설책을 읽으며 에너지를 재충전한다고 합니다. 그의 가장 최근 추천 도서는 V. E. 슈와브의 『아디 라루의 아홉 번째 삶』(The Invisible Life of Addie LaRue)으로, 영원히 살지만 아무도 자신을 기억하지 못하는 여성의 이야기를 다룬 로맨스 소설입니다. 그는 소설을 읽는 것이 코딩과 완전히 다른 경험을 제공하며 생각을 전환하는 데 도움이 된다고 말합니다.
미첼 하시모토의 이야기는 AI가 소프트웨어 엔지니어링의 모든 측면을 어떻게 변화시키고 있는지, 그리고 이러한 변화 속에서 우리가 어떻게 적응하고 새로운 기회를 찾아야 하는지에 대한 중요한 통찰을 제공합니다. 특히 "항상 에이전트가 무언가를 하도록 하되, 알림은 끄고 에이전트에게 휘둘리지 말라"는 그의 조언은 AI 시대를 살아가는 모든 엔지니어에게 실용적인 지침이 될 것입니다.