연매출  약 1조원 이상  GITHUB의 CEO가 말하는 당신이 모르는  GITHUB의  비밀 스토리

안녕하세요 mark입니다 :)

첫번째 글을 발행하고 두번째 글을 한달만에 발행하였습니다 

어떤주제의 글을 발행할까 고민했습니다만 AI에 관심있는 분들이 많은거 같습니다 

 “AI를 활용하지 않는 개발자는 업계를 떠날 준비를 해야 한다”고 발언하며  "코드 작성의 방식은 이미 AI 중심으로 바뀌고 있다"고 하여 파장을 일으키고 있는  

GitHub의 최고경영자(CEO) 토마스 돔케가 관한 팟캐스트 인터뷰를 갖고 왔습니다 

2025년 6월 19일자 팟캐스트에 진행된 인터뷰 입니다 

GitHub는 최근 창립 17주년을 맞았습니다. 하지만 시작은 어땠고, 플랫폼은 어떻게 진화했을까요? 저는 GitHub를 16년째 사용해 왔고, 7년간 재직, 2021년부터 4년째 CEO로 일하고 있는 토마스 돔케(Thomas Dohmke)와 마주 앉았습니다.

오늘 에피소드에서는 GitHub의 리모트 퍼스트·비동기 퍼스트 엔지니어링 문화, 그리고 회사가 이메일을 거의 쓰지 않는 이유를 이야기합니다. 또 2015~2020 사이 기능 출시가 거의 멈춘 듯 보였던 배경, 그리고 2021년 Copilot을 어떻게 만들었는지를 다룹니다. 초창기 내부 도구들(haste, github.tv, Halp 등)도 살펴보죠.

GitHub가 **하루 약 100억 건(초당 약 12만 건)**의 API 요청을 처리한다는 사실, 그리고 토마스가 ‘자율형 AI 도구’가 어려운 엔지니어링 과제를 해결해 주지는 않는다고 보는 이유 등 여러 주제를 이야기합니다. GitHub 같은 고성장 기업의 과거·현재·미래가 궁금하다면, 이번 에피소드는 꼭 들어보세요.

진행자: 토마스, 팟캐스트에 오신 걸 환영합니다

토마스(Thomas Dohmke): 초대해 주셔서 감사합니다. (이메일을 주고받다 이렇게 직접 만나니) 반갑네요. 뉴스레터도 매주 잘 읽고 있습니다.

진행자: 본격적으로 역사 이야기를 하기 전에, 사람들이 GitHub에 대해 잘 모를 수도 있는 흥미로운 사실 몇 가지부터 짚어보겠습니다. 첫 번째는 기술 스택입니다. GitHub는 흔히, 아니 정확히 말하면 과거에는 Ruby on Rails 모놀리식(monolith) 애플리케이션으로 알려져 있었습니다.

2)🛠️ GitHub의 기술 스택(모놀리식 Rails, 프런트엔드, Actions 등)

Q. 한때는 세계에서 가장 큰 Rails 애플리케이션이었고, 이후 Shopify가 더 커졌을 수도 있습니다. 그렇다면 지금도 여전히 Rails 모놀리식 구조일까요?

토마스(Thomas Dohmke):

네, 지금도 Rails 기반이고, 아마 여전히 가장 큰 Rails 애플리케이션 중 하나일 겁니다. (초기에 루비를 썼던 또 다른 사례로 트위터도 있었습니다.)

세 회사 모두 어느 정도는 Rails만으로는 한계가 있다는 점을 깨닫고 다른 아키텍처를 도입했습니다. GitHub 역시 지금도 큰 모놀리스를 유지하고 있고, 회사 내부의 약 700명 엔지니어가 시기에 따라 여기에 기여합니다. 물론 이들이 항상 전적으로 모놀리스만 다루는 것은 아닙니다. 최근 기준으로 이 모놀리스에는 200만 개 이상의 Git 커밋, 수만 개의 풀 리퀘스트가 기록되어 있습니다.

하지만 GitHub는 이제 단일 아키텍처에만 의존하지 않습니다. 예를 들어, 프런트엔드에서는 점점 더 React를 많이 사용합니다. 또 모놀리스 바깥에 별도의 서비스들도 늘어나고 있습니다

 예를 들어 Copilot API는 수많은 API 호출(추론 요청)을 처리해야 하므로 Go 언어로 작성되었습니다. GitHub Actions는 전혀 다른 기술 스택 위에 존재합니다. Rails는 무거운 워크플로우를 처리하기엔 적합하지 않다는 점을 감안했기 때문입니다.

사실 여기에는 흥미로운 역사가 있습니다. 액션스(Action) 스택의 상당 부분은 과거 Visual Studio Team Services → Azure DevOps → Azure Pipelines로 이어진 코드 기반에서 비롯된 것입니다. 그 코드에는 .NET이 많이 포함돼 있었고, 시간이 흐르면서 더 현대적인 아키텍처로 발전해 가고 있습니다. 목표는 ‘99.999% 이상의 가용성(5 Nines and beyond)’ 같은 안정성을 확보하는 것입니다.

즉 오늘날 GitHub의 기술 스택은 상당히 다양화되어 있습니다. 아이폰 앱을 위해 Swift를 쓰고, 안드로이드 앱에는 Kotlin을 씁니다. 여러 퍼블릭 클라우드를 동시에 사용하면서도, 자체 데이터센터의 ‘메탈 서버’도 함께 운영합니다. 요즘 다른 현대적 소프트웨어 회사들이 겪는 복잡성과 동일한 도전에 직면해 있는 셈이죠.

그리고 흔히 “Rails는 확장성이 없다”고 단정하는 시각도 있지만, 결국 중요한 건 기술 자체보다 무엇을 그 위에 쌓고 어떻게 운영하느냐입니다. GitHub의 역사가 그 증거입니다. 사실, 모놀리스와 모노레포(monorepo)를 유지하는 것의 장점과 단점만으로도 한 시간을 이야기할 수 있을 정도죠.”

📌 정리

3) ☁️🏢인프라 전략: 자체 데이터센터 + Azure 하이브리드로

Q. GitHub가 자체 데이터센터를 운영한다는 이야기를 들었는데, 실제로 지금도 일부는 그렇게 하고 있나요? 그리고 Microsoft의 일원이 된 지금, Azure를 포함한 클라우드 활용 전략은 어떻게 가져가고 있나요?”

토마스(Thomas Dohmke):

GitHub는 초창기부터 사실상 클라우드 기반으로 시작했습니다. 내부적으로는 AWS 위에서 플랫폼-서비스(PaaS) 형태로 설계됐죠. 그런데 중요한 사실이 있습니다. 창립 후 5년간 GitHub는 외부 투자 없이 부트스트랩으로만 운영되었습니다.

2008년 4월 정식 출시 후, 사용자 수와 공개/비공개 저장소 수가 폭발적으로 증가했습니다. 당시 사용자들은 심지어 “유료 플랜을 도입해 달라, 그래야 회사가 살아남을 거라는 확신이 생긴다”라고 요청할 정도였죠.

이런 상황에서 창업자들이 내린 자연스러운 결론은, “비용 최적화된 방식으로 서비스를 호스팅할 방법을 찾아야 한다”였습니다. 당시 클라우드 스토리지는 Git 저장소 운영에 적합하지 않았습니다. 특히 2008~2009년 당시에는 노드 간 네트워킹과 파일 스토리지에 대한 클라우드 접근성이 매우 제한적이었거든요.

그래서 결정은 상용 데이터센터의 물리 서버를 직접 운영하는 방식이었습니다. 즉 건물 자체를 소유하지는 않고, 상업적 데이터센터에 장비를 두고 GitHub가 서버·스토리지·랙을 직접 관리한 겁니다. ‘자체 운영’이라고 할 때는 바로 이런 의미였습니다.

오늘날도 GitHub의 코어 시스템은 여전히 이 상용 데이터센터 위에서 돌아갑니다. 하지만 GitHub Actions, Codespaces, Copilot 같은 서비스는 Azure 클라우드에서 구동됩니다. 특히 Copilot은 대규모 GPU 리소스가 필요하고, OpenAI·Anthropic·Google Vertex·AWS Bedrock 등 다양한 AI 모델 API를 활용하기 때문에 Azure 단독으로는 완전하지 않습니다. 그래서 여러 클라우드와 API를 함께 쓰는 구조죠.

또 GitHub는 이제 Azure 지역별 완전 호스팅 옵션을 제공합니다. 예를 들어 유럽 기업 고객은 모든 데이터가 유럽(네덜란드·스웨덴 등) 내에서만 저장되는 전용 GitHub 인스턴스를 사용할 수 있습니다. 호주, 미국 정부(FedRAMP)용도 같은 식으로 지역별 스탬프를 확장하고 있습니다.

이런 것들은 겉으로는 지루해 보일 수 있지만, 기업 고객 입장에서는 매우 중요한 요건이 됩니다. 단순히 ‘클라우드냐 온프레미스냐’가 아니라, 데이터 주권·규제 준수·엔지니어링 난이도까지 맞물려 있기 때문이죠.

📌 정리

4) 📶원격·비동기 문화

많은 사람들이 GitHub를 잘 모르면 “이제 마이크로소프트 산하니까 마이크로소프트처럼 운영되겠지?”라고 생각합니다. 그런데 사실 GitHub는 지금도 원격(리모트) 퍼스트 문화이고, 처음부터 그랬습니다. COVID 이전부터도 ‘진짜’ 원격 퍼스트였던 드문 회사 중 하나였죠.

물론 창업 초기에는 샌프란시스코에서 세 명이 모여 시작했습니다. 하지만 곧 GitHub 슈퍼팬들을 전 세계에서 채용하면서, 본사 중심 문화에서 빠르게 리모트 퍼스트로 전환했습니다.

이 덕분에 팬데믹이 닥쳤을 때도 GitHub는 이미 화상 회의, Slack, 비동기 협업에 익숙했습니다. 이는 Microsoft와 큰 차이를 만듭니다. 저는 아침에 일어나면, GitHub 측에서는 Slack DM과 채널 메시지가 수십 개 쌓여 있습니다. 이메일은 몇 통 안 되죠. 반면 Microsoft 쪽은 그 반대입니다. 이메일이 수십 통, Teams 메시지는 몇 개 정도입니다.

그리고 GitHub는 사내 모든 부서(엔지니어링·프로덕트뿐 아니라 HR, 커뮤니케이션, 재무까지)가 GitHub 자체를 업무 플랫폼으로 씁니다. 팀마다 저장소(repo)가 있고, 예를 들어 약관 개정 같은 문서도 **풀리퀘스트(PR)**로 제안해 수정합니다. 사내 공지 역시 “Hub”라는 저장소에 PR로 올리고, 이것이 내부 전용 GitHub Pages로 게시됩니다. 전체 메일 공지는 거의 하지 않습니다. Slack 채널에 링크만 공유하고, 대화는 그 저장소에서 이어갑니다.

즉 오늘날 GitHub는 전 세계에 분포한 직원들과 함께 리모트 퍼스트, 비동기 퍼스트 문화를 유지하고 있습니다. 대부분은 비동기로 협업하지만, 동기식 모임도 있습니다. 예를 들어 타운홀 미팅은 “GitTogether”라고 부르는데, 시차 문제 때문에 미국·유럽·APAC 지역을 번갈아 배려해 시간을 조정합니다. 서부 시간 아침에 열면 유럽인들에게는 아이들 하교 시간과 겹치고, 반대로 저녁 늦게 열면 오히려 유럽 직원들이 더 선호하기도 합니다. 이런 식으로 최대한 공정하게 운영합니다.

이 덕분에 GitHub는 인생 주기나 거주지에 상관없이 전 세계 인재를 채용할 수 있고, 이는 회사의 민첩성과 다양성에 큰 도움이 됩니다.

📌 정리

5) 👨‍💻흥미로운 초기 내부 도구들 (haste, github.tv, Halp 등)

재미있는 사실 하나. GitHub에는 아주 독특한 내부 도구들이 있었다고 합니다. 지금은 사라진 것도 있고, 여전히 쓰이는 것도 있습니다. 예컨대 **“Haste”**라는 내부 예외 추적 도구가 있었는데, 어떤 사람은 “본 것 중 최고의 소프트웨어였다”고 할 정도였다고 해요.

GitHub 초창기에는 매니저가 없었습니다. 직원들은 각자 자신의 열정 프로젝트를 마음껏 진행할 수 있었고, 그래서 전통적인 IT 인프라가 따로 없었죠. “우리가 직접 만들면 시중 도구보다 더 잘 만들 수 있다”는 믿음이 있었기 때문에, 거의 모든 것을 사내에서 자체 개발했습니다.

예를 들어, GitHub는 자체 동영상 스트리밍 플랫폼인 github.tv를 운영했습니다. 타운홀 미팅 같은 행사를 내부 플랫폼으로 생중계했죠. 지금은 사라지고, 대신 Loom을 씁니다.

또 **“Haste”**는 예외 추적 시스템이었는데, 15년 전 당시에는 지금처럼 시장에 확립된 도구(예: Sentry)가 없었고, 특히 루비 환경에 적합한 도구는 더더욱 없었습니다. 그래서 직접 만든 겁니다.

**“Halp”**은 사내 지원 티켓 시스템이었습니다. 직원들이 티켓을 열면 관련자가 배정되어 처리하는 방식이었죠. 지금은 Zendesk 같은 상용 솔루션으로 대체되었습니다.

이런 내부 도구 아이디어들은 훗날 GitHub 직원을 떠난 사람들이 스타트업을 창업하는 계기가 되기도 했습니다.

또 일부는 외부에도 공개되었습니다. 예를 들어 Atom 에디터에서 출발해 Electron 프레임워크가 나왔고, GitHub Desktop, CLI 같은 프로젝트도 오픈소스로 공개되었습니다. 지금도 개발자라면 누구나 그 코드를 보고 배울 수 있습니다.

6) 👥보안 문화 (“모두가 보안팀”), 탐지·연구조직, 규모

GitHub가 유명한 것 중 하나가 보안입니다. “모두가 보안팀”이라는 문화가 있다던데, 실제로는 어떤 의미인가요?

우리는 말 그대로 그걸 진지하게 받아들입니다. 모든 엔지니어가 일상적인 작업에서 보안을 고려해야 한다는 뜻입니다. 물론 전담 보안팀도 있지만, 보안은 모두의 책임이라는 문화가 핵심이에요. 예를 들어 누군가 풀리퀘스트(PR)를 올리면, 리뷰어들은 코드 품질이나 스타일만 보는 게 아니라 보안상 영향까지 반드시 검토합니다.

또 GitHub에는 아주 강력한 탐지 엔지니어링 팀이 있습니다. 이들은 플랫폼 전반에서 비정상적 패턴을 사전에 감지하려고 끊임없이 모니터링합니다. 그리고 세계적 수준의 리서치 팀도 있죠. GitHub는 원래부터 수많은 보안 연구자들이 활동하는 곳이었기 때문에, 그들에게 최고의 터전이 되고자 합니다.

규모 면에서도 보안은 필수입니다. GitHub는 하루에 약 **100억 건(초당 12만 건)**의 API 요청을 처리합니다. 이 정도 트래픽에서는 사람 손에만 의존할 수 없습니다. 시스템, 자동화, 이상 탐지, 지속적 모니터링 없이는 불가능하죠.

즉, GitHub의 보안은 문화적 시스템이자 기술적 시스템입니다. 모든 직원이 자신을 보안팀의 일원으로 여기며, 동시에 대규모 자동화·탐지·연구에 투자를 아끼지 않습니다.

📌 정리

7) 👩‍💼주니어/인턴 채용에 대한 관점

최근 트렌드를 보면, 많은 회사들이 주니어 엔지니어 채용을 줄이고 있습니다. 심지어 인턴 프로그램을 중단하는 곳도 있어요. “AI가 이제 초급 업무를 대체할 수 있다”는 이유에서죠. 그런데 GitHub는 여전히 인턴과 주니어 인재에 투자한다고 들었습니다. 왜 그렇습니까?

첫째, 우리는 인턴들이 우리에게서 배우는 것뿐 아니라, 우리도 인턴들에게서 배운다고 믿습니다. 세대마다 새로운 습관과 도구를 가지고 오기 때문이죠. 지금 세대는 LLM과 AI 어시스턴트와 함께 성장했습니다. 그래서 우리가 생각지 못했던 방식으로 AI를 활용하는 신선한 시각과 창의적인 방법을 제시해 줍니다.

둘째, 인턴십은 미래 인재를 평가하기에 가장 좋은 기회입니다. GitHub 최고의 엔지니어 중 다수는 인턴 출신이에요. 우리는 인턴십을 자선 사업으로 보는 게 아니라, 장기적인 투자로 봅니다.

셋째, 문화적 이유입니다. GitHub가 에너지와 호기심으로 살아 숨 쉬는 공간이 되길 원합니다. 인턴들은 분위기를 바꿉니다. 그들은 “왜?”라고 질문하고, 기존 방식을 의문시하며, 굉장히 열정적입니다. 덕분에 모두가 더 예리해지고 깨어 있게 됩니다.

📌 정리

8) 🧑‍💻 엔지니어링 리더십, 코딩 인터뷰, AI 도구 활용

놀라운 얘기를 들었습니다. GitHub에서는 심지어 시니어 엔지니어링 매니저나 디렉터급 지원자도 코딩 인터뷰를 본다고요? 왜 그렇습니까?

네, 사실입니다. 우리는 최고의 리더란 코딩에서 도망치는 사람이 아니라, 여전히 기술을 사랑하는 사람이라고 믿습니다. 그들이 매일 코드를 작성하지는 않더라도, 충분히 코드와 가깝게 지내며 이해하고, 토론하고, 함께 짝 프로그래밍(pairing)할 수 있어야 합니다. 그래서 GitHub의 채용 과정에서는 디렉터나 VP(부사장) 지원자도 코딩 세션을 치르며, 종종 저나 다른 시니어 엔지니어와 함께 짝을 이룹니다.

우리가 보는 것은 문법 암기 능력이 아닙니다. 어떻게 문제를 추론하는지, 어떤 도구를 사용하는지, 그리고 AI 도구가 코드를 생성했을 때 어떻게 반응하는지를 중점적으로 봅니다. 예컨대 Copilot이나 Cursor가 코드를 만들어 냈을 때, 후보자가 그것이 좋은 코드인지 나쁜 코드인지 평가할 수 있나요? 또 AI의 출력을 받아들여야 할 때와 직접 개입해 수정해야 할 때를 구분할 줄 아나요?

실제로 우리는 후보자들에게 인터뷰 중 AI 도구 사용을 권장합니다. 현실에서 GitHub 엔지니어들도 이 도구들을 쓰기 때문입니다. 때로는 AI가 엉터리 코드를 내놓습니다. 흥미로운 부분은, 지원자가 단지 프롬프트만 계속 바꾸며 시도하는지, 아니면 직접 책임을 지고 코드를 고치는지입니다. 그것이 바로 그들의 엔지니어링 본능을 잘 보여주거든요.

📌 정리

9) 🌍뛰어난 엔지니어의 특징과 AI 시대의 변화

지금 GitHub에서 뛰어난 시니어 혹은 스태프 엔지니어는 어떤 모습인가요? 3년 전, AI 도구가 없던 시절과 비교했을 때 달라진 점이 있습니까?

가장 큰 차이는 오늘날 최고의 엔지니어들은 AI 도구를 단순히 기능 개발 속도를 높이는 데만 쓰지 않는다는 점입니다. 오히려 그동안 늘 “언젠가 하고 싶다” 생각했지만 시간이 부족해 미뤄두었던 일들 — 예컨대 기술 부채(tech debt) 줄이기, 리팩토링, 코드 가독성 개선 같은 것들 — 을 실제로 시도합니다. 예전에는 먼 훗날의 과제로 치부됐던 일들이, AI 덕분에 이제는 에이전트를 활용해 실행할 수 있게 된 겁니다.

제가 본 뛰어난 엔지니어들은 AI 에이전트를 띄워 대규모 리팩토링을 시도하고, 그 결과 생성된 모든 PR을 하나하나 꼼꼼히 검토합니다. 때로는 결과물이 엉망이라 그냥 폐기하기도 합니다. 하지만 중요한 건 그들이 시도하기를 두려워하지 않는다는 것, 그리고 AI 덕분에 그런 도전적 과업을 훨씬 빠르게 탐색할 수 있다는 점입니다.

즉, 오늘날 GitHub에서 뛰어난 엔지니어란 호기심 많고, AI와 함께 실험하며, 자신의 영향력을 증폭시키는 사람입니다. 깊은 기술적 판단력과 동시에 새로운 워크플로를 과감히 시도하는 태도를 가진 이들이 두각을 드러냅니다.

📌 정리

10)💡 다른 회사가 AI-First 문화를 만들려면? (조언과 시작점)

많은 엔지니어링 리더들이 “우리도 GitHub이나 Shopify처럼 AI-First 문화를 만들고 싶다”고 말합니다. 그런데 어디서부터 시작해야 할지 모르겠다고도 합니다. 그들에게 어떤 조언을 해주나요?

가장 중요한 건 **롤 모델링(role modeling)**입니다. “AI를 써라”라고 말만 해서는 안 됩니다. 리더 본인이 직접 사용하고, 자신의 워크플로와 실험, 심지어 실패 사례까지 보여줘야 합니다. 그래야만 채택이 자연스럽게 퍼져 나갑니다.

GitHub에서는 내부적으로 프롬프트 라이브러리도 공유합니다. 누군가 좋은 프롬프트를 찾으면 내부 게시판에 올려서 다른 사람도 활용할 수 있게 합니다. 이렇게 하면 학습 속도가 훨씬 빨라집니다.

또 하나는 해커톤입니다. GitHub 전사 해커톤에서는 프로젝트에 반드시 AI를 포함하도록 했습니다. 단순히 주니어 엔지니어만 배우는 자리가 아니라, 시니어 스태프까지도 자신의 워크플로를 확장하고 실험하도록 만든 겁니다. 이 과정을 통해 AI 활용이 조직 문화 속에 자연스럽게 자리 잡게 됩니다.

마지막으로, 중요한 건 아직 아무도 정답을 갖고 있지 않다는 사실을 받아들이는 것입니다. 우리 모두가 실험 중입니다. 그렇기 때문에 “이건 잘 됐다, 이건 실패했다”를 투명하게 공유하는 게 필수입니다. 

📌 정리