이 글은 GitHub Universe 2024 참석기 #1: Day 0, 1에서 이어진 글이다.

Day 2

둘째 날도 main stage에서 키노트가 진행되었다. GitHub에 11년 전 개발자로 입사해서 지금은 COO가 된 Kyle Daigle이 무대에 나와서 지난 10년간 GitHub이 해온 일들을 돌아오며 앞으로의 목표는 전 세계에서 10억 명의 사람들이 개발자가 되는 비전을 얘기하면 AI가 발전하는 시대에 개발자가 되는 길은 다양하며 AI가 결코 개발자의 의미를 희석하지 않고 오히려 새로운 창의성을 발휘하게 할 것이라고 얘기한다.

그러면서 GitHub은 개발자들의 집이었으며 앞으로도 그럴 것이라고 얘기했다. 그리고 이번 Octoverse 2024에서 가장 많은 컨트리뷰션을 받은 Home Assistant를 소개하며 Home Assistant를 만든 Paulus Schoutsen와 엔지니어링 리드인 Franck Nijhof가 무대 위로 나왔다.

Home Assistant의 동작을 보여주었는데 프로젝트는 알고 있었지만, Home Assistant가 이렇게 인기 있고 발전했는지 모르고 있어서 Google Home이나 Apple Home을 쓰고 있지만 Home Assistant도 써봐야겠다는 생각이 들었다. 그리고 Home Assistant가 만들어진 것처럼 GitHub에서 새로운 프로젝트를 만들어 보라면서 자연스럽게 오픈소스 얘기로 넘어가면서 내년부터는 공개 저장소의 GitHub Actions에서 Arm 기반 러너도 무료로 사용할 수 있게 된다고 발표했다.

GitHub Issues와 Projects로 협업하는 시연과 함께 전날 세션도 있었지만 Copilot Autofix를 모든 공개 저장소에서 무료로 사용할 수 있다고 발표했다.

Secure OSS Fund를 발표했다. 최근 오픈소스 메인테이너가 보안 관리를 하는데 가장 시간을 많이 쓰고 어려워한다는 리포트를 본 적이 있는데 이 부분을 지원하기 위해 Copilot Autofix를 무료로 제공하고 펀드도 마련하는 건 좋아 보였다.

이어서 소프트웨어의 미래를 얘기하면서 GitHub Next의 Principal Research Engineer인 Amelia Wattenberger가 등장해서 원하는 자신만의 학습 코스를 만들어주는 Learning Sandbox를 소개한다. AI를 이용해서 프로젝트를 진행하는 것이 아니라 어떤 기술을 배우기 위한 튜토리얼을 만들어준다는 점이 꽤 흥미로웠다. 이는 처음에 얘기했던 10억 명의 개발자를 만들기 위한 일환이다.

다시 Kyle Daigle이 등장해서 GitHub Education을 소개하고 10대들이 코딩하는 커뮤니티인 Hack Club을 소개하며 Hack Club의 학생인 Acon Lin이 나와서 high seas 사이트를 공개해서 보여주었다.

How the New York Times engineered a user-friendly developer platform

회사에서 플랫폼 엔지니어링 관련 업무를 하고 있다 보니 이쪽에 관심이 많은데 둘째 날은 플랫폼 엔지니어링과 관련한 발표가 많아서 그런 발표를 위주로 듣게 되었다.

이 발표는 The New York Times의 Principal Engineer인 David Grizzanti가 나와서 뉴욕타임스에서 IDP(Internal Developer Platform)으로 어떻게 만들었는지를 설명했는데 Drone CI와 Argo CD, HashiCorp의 Vault를 이용해서 Kubernetes에 쉽게 배포할 수 있게 적용하면서 플랫폼을 구성한 것을 설명해 주었는데 플랫폼 엔지니어링의 개념 설명 세션 정도로 느껴졌다.

첫날 10분 이내에 프로덕션 배포까지 할 수 있어야 한다는 목표는 배포 플랫폼이나 개발자 플랫폼에 괜찮은 목표라는 생각이 들었다.

Improve your developer experience with Compass, Atlassian's internal developer platform

이 발표는 Atlassian에서 시니어 엔지니어 매니저인 Raghu Venkatesh가 Atlassian에서 구축한 Compass를 설명하는 발표였다.

아틀라시안은 2012년 경에 모노리스에서 마이크로서비스로 넘어가게 된다. 뒤에서도 또 얘기하겠지만 결국 많은 회사에서 마이크로서비스로 넘어가면서 관리의 어려움이 생기게 되고 이를 해결하기 위해서 IDP를 구축하게 되는 거로 보인다. 2018년에 Microscope라는 IDP를 만들어서 사용하다가 2022년부터는 Compass로 통합해서 사용하고 있다고 한다.

위에 보듯이 누가 봐도 아틀라시안 제품처럼 생겼다. Compass에서는 GitHub 저장소와 연결해서 각 마이크로서비스의 단위라고 할 수 있는 컴포넌트라는 것을 등록하게 되고 여기서 배포 등의 활동, 스코어카드, API 명세, 문서 등을 관리할 수 있고 DORA 메트릭을 보여주고 컴포넌트 간 의존성 관리 및 팀 설정을 할 수 있다. 그리고 각 팀에서 스코어카드에 대한 기능을 관리해서 문서 관리 정도 같은 것을 쉽게 평가해서 보여줄 수 있고 GraphQL을 통해 확장성도 제공하고 있었다.

큰 회사답게 꽤 잘 만들었고 각 기능에 관해 공감이 가는 부분도 많고 참고할 부분도 많아서 재밌게 들은 발표였다. 발표를 들을 때는 몰랐는데 내부에서 만들고 잘 되어서 그런지 Compass는 아틀라시안에서 파는 제품 중 하나라서 다른 회사도 Compass를 결제해서 IDP를 사용할 수 있다.

Thriving through change: A decade of engineering evolution at Spotify

이 발표는 Spotify의 시니어 프로덕트 매니저인 Sanjana Seetharam과 VCS 영역의 엔지니어링 매니저인 David Rubin가 나와서 Spotify에서 플랫폼 엔지니어링을 통해서 엔지니어링 혁신을 어떻게 이뤘는지에 대한 발표였다. 사실 발표를 들으러 갈 때는 까먹고 있었는데 Spotify는 Backstage를 만들어서 적용하고 이를 오픈소스로 풀어서 IDP로 가장 유명한 오픈소스 프로젝트로 만들었기 때문에 발표를 듣던 중에 "아! Spotify가 Backstage 만든 곳이지!!!"하면서 어떤지 내용이 너무 좋더라고 생각하면 들었다. 콘퍼런스에서 가장 재밌게 듣고 많은 생각을 하게 한 발표였다.

Spotify는 6억여 명의 사용자가 있고 2,800여 명의 엔지니어가 500개 팀에서 하루에 2,900번 이상 프로덕션 배포를 한다고 한다. 엔지니어 수도 많지만, 배포 수를 봤을 때 Continuous Delivery가 아주 잘 되어 있다는 생각이 들었다.

GitHub에 저장소가 19만 개이고 org가 2,800개이며 자동화된 코드 변경이 880만 라인이라고 하는데 조직이 어떻게 구성되어 있는지는 모르겠지만 GitHub org가 너무 많은 게 아닌가 싶다.(엔지니어마다 org 하나씩 만들어주나...) 음악 서비스인 Spotify 답게 자신들의 컬쳐를 밴드와 비유한 것도 재밌었다.

2013년 2,400만 사용자가 있을 때 SRE가 23명 있었는데 이때는 스프레드시트를 사용해서 하드웨어 프로비저닝을 관리하고 있었고 CLI로만 관리하고 있었다.

또한 이때는 코드 리뷰 시스템인 Gerrit을 사용하고 있었고 당시 업계에서는 GitHub이 표준처럼 사용되고 있었기에 사내 개발자들에게 설문했을 때 대부분 GitHub을 원해서 2015년 5월 Gerrit에서 GitHub Enterprise Server로 넘어가게 된다.

서비스와 회사가 성장하면서 마이크로서비스가 커지게 되고 하드웨어 서버에서 클라우드로 전환되면서 각 서비스를 띄우는 속도는 더욱 빨라지게 된다.

그래서 위 그래프를 보면 녹색이 엔지니어의 수이고 파란색은 컴포넌트인데 엔지니어의 증가에 비해서 컴포넌트가 훨씬 빠르게 증가하는 것을 볼 수 있고, 이는 인프라나 운영팀에서 추적해야 할 팀이 엄청나게 많다는 것을 의미하고 새로운 문제가 생기게 된다. 그래서 Spotify도 이러한 문제를 해결할 방법을 새로 고민해야 한다.

Single pane of glass여러 시스템이나 데이터 소스를 하나의 통합된 인터페이스에서 볼 수 있게 하는 대시보드나 플랫폼을 의미하는 용어다. Spotify도 통일된 경험을 제공하기 위해 팀을 만들어서 여러 시도를 하게 되었고 모든 서비스의 정보를 가지고 있는 카탈로그를 시작으로 해서 Backstage를 만들게 된다. 이 카탈로그의 모든 정보는 Git을 기반으로 하고 각 팀이 이 정보를 관리하도록 해서 오너쉽을 관리하게 했다. 그 뒤에 여러 기술 문서가 흩어져 있고 최신 상태가 아니었기에 기술 문서를 Git위에 Markdown으로 구성하게 하고 이를 Backstage에 연결해서 문제가 생겼을 때 누구를 찾아야 하고 문서는 어디 있는지 알 수 있도록 했다.

GitHub를 기반으로 모든 것을 구축해서 Backstage에서 모든 것을 볼 수 있고 용량을 늘리거나 장애시 트래픽을 전환하는 작업도 할 수 있게 되었다.

서비스와 조직이 너무 빠르게 성장하면서 새로운 엔지니어를 온보딩하기 어려워졌고 복잡도와 파편화가 커지면서 개발자 생산성에 영향이 미치는 문제를 조사하기 시작했다. DevEx Ingredients는 개발자 경험의 재료(?)이런 의미인데 제대로 된 방법으로 빠르게 하기 어려워한다는 것을 알게 되어 "올바른 방법으로 빠르게 하기(Doing things the right way, fast)"와 개발하면서 청구서 처리, 배포, 보안, Audit, 업스트림 의존성 관리 등에 너무 많은 시간을 쓰고 있었기 때문에 운영하면서 발생하는 반복적 수동 작업을 없애줘야 한다는 것을 알게 되었다.

각 서비스가 팀마다 다르게 구성되어 있어서 파편화가 심했기 때문에 중앙 집중화하고 엔지니어들은 순수하게 비즈니스에만 집중하게 하고 인프라와 관련한 어려움은 없애고 싶었습니다. 그래서 Tech Halth 전략을 만들게 되었다.

• Golden Path는 소프트웨어를 개발하는 표준 방법으로 모범사례를 문서화하고 신규 입사자가 튜토리얼을 항상 따라 하게 해서 이 문서가 outdated되지 않도록 했다. 시간이 지나면서 이 Golden path도 계속 압축하고 불필요한 과정을 없애서 더 쉽게 만들었다.
• Golden Technologies는 표준 인프라 세트로 모든 프로덕션 구성요소에서 사용해야 할 필수 기술을 선택했고 이 Golden Technologies를 사용하면 유지보수 작업이 플랫폼의 일부가 되기 때문에 개발자가 최종사용자에게만 집중할 수 있다..
• Golden State는 모든 요소의 원하는 목표 상태이다. 전체 소프트웨어를 쉽게 관리하고 최신 상태로 유지할 수 있도록 하고 새로운 기술로 넘어갈 때도 모든 사람이 같이 넘어갈 수 있게 되었다.

이 3가지 축은 너무 중요하게 느껴졌고 많이 공감되었다. Spotify에서는 Golden Technologies를 사용해서 Golden State에 도달하도록 Golden Path를 따르도록 하고 있다. 이렇게 만들어진 모범 사례를 통해 기존 저장소에서 클릭 한 번으로 새로운 서비스를 만들 수 있는 소프트웨어 템플릿까지 만들어서 효과를 많이 받았다고 한다.

위 그래프는 Spotify의 서비스 간 의존성 그래프인데 꽤 복잡했기에 개발자들이 겪는 인프라 문제를 자동화로 해결하기 위해 Fleet Management라는 프로그램을 도입했다. 찾아보니 Fleet Management는 원래 있는 용어로 차량, 선박 항공기 등의 다양한 운송 수단을 효율적이고 경제적으로 운영/관리하는 프로세스를 의미한다고 한다. 그래서 Fleet Management로 모든 것이 버전화되고 코드화되어 있는지 확인하고 변경을 쉽게 만들고 대규모로 수십만 개에 실행할 수 있도록 했다.

몇 년 전 Log4 취약점을 예시로 들었는데 9시간 만에 80%에 적용했고 나머지 20%도 모두 처리되기까지 8일이 걸렸다고 한다.

이 덕분에 새로 입사한 사람이 기존에는 기여하는 데 2달이 걸렸으나 이제 20일밖에 안 걸리게 되었고(67% 감소) 긴급한 장애도 25% 줄고 빌드시간도 56% 줄었다고 한다.

이에 따라서 새로운 기능이 프로덕션에 나가는 시간이 엄청나게 빨라졌고 자동화된 bot이 제출한 코드가 사람보다 많아졌다고 한다. 소프트웨어 생명 주기가 표준화되어 개발자에게 주는 영향을 측정하기가 훨씬 쉬워졌다.

Backstage를 사용하는 개발자가 GitHub에서 2.3배 더 활동하고 코드 변경도 2배 많았으면 배포도 2배 더 많이 했다. 개인적으로 이런 발표를 볼 때 측정을 어떻게 했을까 하는 고민을 하게 된다. 자동화 되지 않고 관리가 잘 안되던 영역이 측정이라고 잘 될 가능성이 별로 없기 때문에 어떤 걸 개선하려고 할 때 실제 결과도 알고 싶기에 측정을 먼저 할 수 있게 하고 개선해야 하나? 혹은 측정하려는 게 개인 욕심이고 불필요한 과정일까? 하는 생각을 하게 된다. 개선하고 나면 효과는 있는 거 같은데 수치나 그래프로 비교해 보고 싶은데 예전 데이터가 없어서 아쉽기도 하고...

이어서 AI 도구 도입에 대한 얘기도 했는데 이건 GitHub에서 하는 발표라 Copilot 얘기를 좀 한 거 같고 이 발표에서 얘기한 Spotify의 경험을 모아서 최근 Spotify Portal for Backstage을 베타로 공개했다. 이는 노코드 IDP로 Backstage를 설치, 관리하기 쉽게 제공한다.

아무래도 최근 IDP나 플랫폼 엔지니어링의 관심을 가지는 조직이 가장 많이 선택하는 Backsage를 만들 곳이었기에 발표도 재밌고 생각 정리도 많이 되었다 내가 회사에서 플랫폼을 만들 때의 Backstage는 꽤 초기 상태였기에 제대로 고려하지 않았지만, 지금의 Backstage를 좀 테스트해 봐야겠다는 생각이 들었다.

GitHub Stars Lounge

메인 건물인 Festival Pavilion 한가운데 GitHub 부스들 사이에 GitHub Stars를 위한 라운지가 준비되어 있었다. Stars 프로그램도 알리고 사람들이 Stars와 얘기도 할 수 있게 준비한 공간이라서 나도 2일 중 한 시간 정도가 할당되어서 라운지를 지키고 있어야 했는데 누가 찾아와서 말을 걸거나 하진 않았다.(사실 영어에 대한 부담이 있으니, 누가 와서 물어보면 어쩌지 하는 걱정도 있었다. ㅎㅎ)

실제로는 GitHub Star들이 오가며 짐 놔두고 쉬는 공간으로 사용되었다. 성격상 많이 어울리진 못했지만 그래도 이런 공간이 있으니, 얘기도 좀 나누고 좋았다. GitHub Stars를 모두 다 모으지 못해서 3일 동안 단체 사진을 몇 번이나 찍는지 모르겠지만 그래도 재밌었다. 올해부터 새로 GitHub의 DevRel로 와서 GitHub Stars 프로그램을 관리해 주는 Howard Lio도 만나서 반가웠다.

에필로그

콘퍼런스를 돌아다니다 보면 한국분인 거 같은데? 하는 사람들이 있는데 확신도 없고 해서 그냥 지나가곤 했다. 우연히 지나가다가 류대열님이 인사를 해주셔서 얘기를 좀 나누었었는데 마지막 날에 Bryant Son님이 한국분들이 모여있다고 오라고 해서 갔더니 새로 오신 한국 담당 GitHub 직원분과 여러 회사에서 오신 분들을 만나서 한참 얘기를 나누고 저녁도 같이 먹었다.

끝나고 나가는 길에는 이렇게 2일 연속으로 배지 등의 선물을 주었는데 이것도 꽤 괜찮게 느껴졌고 m&m 초콜릿에 옥토캣이 찍힌 건 너무 귀여웠다. 스폰서 부스나 콘퍼런스 분위기가 궁금하다면 2일 차로 찍은 vlog에서 볼 수 있다.

이 글은 3편으로 이어질 예정이다.