컴퓨터컴퓨터
컴퓨터/
프로그래밍 언어프로그래밍 언어
프로그래밍 언어/
XZ Utils 백도어 사건으로 돌아보는 오픈소스 생태계 :: Outsider's Dev Story

XZ Utils 백도어 사건으로 돌아보는 오픈소스 생태계 :: Outsider's Dev Story

생성일
Apr 7, 2024 08:50 AM
언어
분야
URL
https://blog.outsider.ne.kr/1714
XZ Utils는 오픈소스 무손실 압축 라이브러리로 압축과 해제에 Lempel–Ziv–Markov chain 알고리즘(LZMA)을 사용하고 있다. 지난 3월 29일 XZ Utils에서 메인테이너가 백도어를 심는 충격적인 사건이 발생했다. 그래서 사건도 사건이지만 이 사건을 통해서 오픈 소스 생태계에 대해서 평소 생각하던 걸 좀 더 정리해 보게 되었다.

XZ Utils

일단 XZ Utils가 뭔지 찾아봤다. 의외로 Chromium 프로젝트에서 가장 자세한 히스토리 파일을 찾을 수 있었다.
2005년 Slackware라는 리눅스 배포판의 포크인 Tukaani 리눅스의 배포를 위한 그룹이라고 생각되는데 정작 Tukaani 리눅스는 나온 적은 없는 것 같다. 이 소규모 그룹의 목표는 리눅스 배포를 700MiB로 압축하는 것이었고 gzip 대신 LZMA가 압축률이 높아서 LZMA로 700MiB로 압축할 수 있게 된다. Slackware는 .tar.gz의 약어인 .tgz 파일로 배포하고 있었는데 LZMA를 쓴 경우에는 .tar.lzma의 약자로 .tlz를 사용하게 되었다.
Tukaani 프로젝트는 멈췄지만, LZMA Utils 개발은 계속 진행되었고 Slackware 기반 일부 배포판에서는 여전히 LZMA를 사용하고 있었다. 이 LZMA Utils에는 lzmash라는 쉘 스크립트와 lzmadec라는 디코더 CLI가 포함되어 있었는데 이는 Lasse Collin이라는 개발자가 작성했다. 개발이 진행되면서 새 포맷을 만들게 되었지만 만드는 데 시간이 꽤 걸리게 되어 기존 .lzma 파일 확장자를 쓸수 없게 되자 .xz 파일 확장자를 쓰기로 하고 2008년 12월에 드디어 릴리스 하게 된다.
새로운 LZMA Utils의 핵심은 liblzma 라이브러리였지만 프로젝트 이름을 LZMA Utuils에서 XZ Utils로 바꾸게 된다. XZ Utils는 압축률이 높았기 때문에 다양한 리눅스 배포판에 포함되기 시작하고 Fedora, Ubuntu, Debian, Red Hat, Kali Linux, OpenSUSE 등 우리가 볼 수 있는 대부분의 배포판에 포함되어 기본 유틸리티로 사용되게 된다.
이렇게 수많은 배포판에 기본 유틸리티로 쓰이는 압축 라이브러리가 되었지만, XZ Utils를 만든 Lasse Collin가 2007년부터 2022년까지 거의 혼자서만 이 프로젝트를 유지보수하는 상황이었다.
notion imagenotion image
XZ Utils의 컨트리뷰션 그래프
이번 백도어 문제로 GitHub에서는 GitHub의 xz 저장소를 비활성화시켰고 지금은 아예 사라진 상태이다. xz의 원본 저장소는 GitHub이라기보다는 git.tukaani.org라고 할 수 있어서 여기서 커밋을 볼 수 있다. git.tukaani.org를 메인으로 쓰다가 몇 년 전부터 GitHub을 같이 이용한 것으로 보이는데 양방향 싱크를 한 것인지 GitHub으로 이사 갔다가 돌아온 것인지는 정확히 알 수가 없다.
GitHub에서 xz 저장소를 비활성화해서 지금은 GitHub에서 저장소를 직접 볼 수가 없어서 인터넷 아카이브에서 찾아볼 수밖에 없었다.
notion imagenotion image
차단된 GitHub의 XZ 저장소
XZ Utils는 24년 1월 26일 기준으로 xz의 안정 버전은 5.4.6이었고 불안정 버전은 5.5.1이었다.

XZ Utils 백도어 취약점

이번 사건은 Andres Freund라는 개발자가 서버의 SSH 접속이 뭔가 느림을 발견하고 이를 추적하면서 XZ 최신 버전에 백도어가 숨겨져 있는 것을 발견하고 이를 openwall의 OSS-Security 메일링 리스트에 리포팅하면서 알려지게 된다. 이 Andres Freund가 올린 리포팅이 그냥 이상하다고만 올린 게 아니라 이상 현상부터 XZ가 원인이었고 여기에 백도어가 심겨 있었으며 XZ에 해당 백도어가 어떻게 들어왔는지까지 다 분석해서 올려서 이후에도 상황 업데이트가계속되지만, 첫 리포팅에서 대부분의 상황이 알려지게 된다.
이번 사건을 처음 알린 Andres Freund는 Microsoft의 Principle software engineer이면서 오랫동안 PostgreSQL에 기여한 커미터이기도 하다. 아래에서 anarazel가 Andres Freund다.
notion imagenotion image
PostgreSQL의 Andres Freund 커밋 그래프
이번 공격은 간단히 정리하면 백도어를 여는 악성 코드를 테스트 쪽 코드인 척하고 넣어두고 빌드가 될 때 악성 코드가 tarball에 추가되는 구조로 되어 있고 glibc를 사용하는 amd64 리눅스에만 포함되도록 만들어졌다. Andres Freund의 말에 의하면 glibc와 amd64만 타게팅한 것은 백도어가 들키지 않게 하기 위함으로 추측하고 있다. 모든 시스템에 다 들어가면 들킬 확률도 높아지고 시스템마다 다르면 찾아내기도 더 어려워지니 가장 많은 glibc에 amd64만 목표로 한 것으로 보인다.이번 백도어는 sshd를 이용한 것으로 인증을 우회해서 서버에 접속할 수 있거나 원격 코드를 실행할 수 있을 것으로 보고 있다.
Evan Boehs라는 개발자가 정리한 Everything I Know About the XZ Backdoor에 이번 사건이 잘 정리되어 있다. 물론 수사가 이뤄진 것은 아니라 어느 정도 정황과 추측이 섞여 있지만 이 글에서 거의 대부분의 상황을 알 수 있다고 생각한다. 또한 FAQ on the xz-utils backdoor (CVE-2024-3094)도 참고하면 좋다.
이번 백도어 사건을 정리해 보면 다음과 같다.
  • 2021년 Jia Tan이라는 사람이 JiaT75라는 GtiHub 계정을 만들고 libarchive라는 저장소에 PR을 올린다.(여기도 의심할 필요 있음)
  • xz-utils의 메일링 리스트에 Jia Tan이 패치를 제출한다.(이때는 git.tukaani.org에서 메일로 패치를 받은듯하다..)
  • Jigar Kumar라는 사람이 나타나서 이 패치를 병합해야 한다고 압력을 가한다. 이 Jigar Kumar라는 사람은 누군지 모른다.
  • 이 Jigar Kumar는 Lasse Collin에게 혼자만 작업하니 다른 메인테이터가 필요하다고 압박을 가한다.
  • Dennis Ens라는 사람도 등장해서 같이 압박한다.(이 사람도 누군지 모른다.)
  • Jia Tan(JiaT75)은 xz에 커밋을 또 올리게 되고 이후 메인테이너가 된다.
    • 위의 컨트리뷰터 목록을 보아도 2022년부터 활발하게 기여한 걸 볼 수 있다.
    • 이시점 어느 정도부터 git.tukaani.org와 GitHub의 xz 저장소가 같이 올리게 된다.
  • 2023년이 되면서 Jia Tan(JiaT75)은 완전한 신뢰를 얻게 되고 3월에는 기본 연락처가 Lasse Collin에서 Jia Tan(JiaT75)으로 바뀐다.
  • Jia Tan(JiaT75)이 기존 tukaani.org/xz/로 되어있던 프로젝트 주소를 xz.tukaani.org/xz-utils로 바꾸고 이 주소는 핀란드의 어떤 서버에서 호스팅이 된다.
  • 프로젝트에 백도어를 심는 커밋을 추가하고 5.6.0을 릴리스한다. 의도적으로 모든 tarball에 백도어가 심은 것이 아니라 타게팅한 시스템의 tarball에만 심어졌다.
  • 이 백도어로 인해서 valgrind 에러가 발생하자 백도어는 남겨둔 채 이 에러를 우회한 5.6.1을 릴리스한다.
5.6.0은 2월 24일에 릴리스되고 5.6.1은 3월 9일에 릴리스된다. 5.6.0이 나온 지 한 달이 약간 넘은 상황이기 때문에 이 시점 이후에 xz를 설치하거나 최신 버전으로 업데이트한 경우에만 백도어가 포함된 버전이 설치되었을 것이고 그 이전 시스템은 괜찮은 상황이다. Ubuntu를 기준으로 하더라도 이번 4월에 나올 24.04에 xz 5.6.0이 포함되었다.
그러므로 이번 사건은 Andres Freund가 아주 빨리 발견했기 때문에 수많은 시스템이 취약점에 노출되기 전에 잡아낸 것이고 아마 조용히 많은 Linux 시스템이 이 버전으로 업데이트되기를 기다렸다가 뭔가 하려고 하지 않았을까 생각할 수 있다.
이 취약점은 CVE-2024-3094 할당받았고 가장 높은 심각도를 판정받았다. 처음 취약점이 공개되었을 때 상황 파악이 완전히 되지 않아서 Jia Tan 뿐 아니라 Lasse Collin의 깃헙 계정도 정지되었지만 지금은 다 풀린 상태이다.
Lasse Collin은 Tukanni 프로젝트에 이번 백도어 사건에 대한 공식 페이지를 만들고 홈페이지도 xz.tukaani.org를 차단하고 tukaani.org/xz/로 되돌리는 작업을 하고 있다. 아직도 이번 경위에 대해서 조사하고 있는 것으로 보고 이후 정리해서 깨끗한 XZ Utils 5.8.0을 릴리스 하겠다고 발표했다.

오픈소스 생태계의 상황

기존에도 공급망 공격(Supply Chain Attack)은 종종 있었다. 공급망 공격은 사람들이 신뢰하는 레지스트리를 다른 곳으로 속이거나 공급망을 해킹하는 등 다양한 방법을 통해서 할 수 있지만 이번 공격은 사회공학을 통했다는 점에서 다른 부분이 있고 많은 사람이 충격을 받았다.
그도 그럴 것이 앞의 커밋 그래프를 보면 Jia Tan이라는 사람 혹은 그룹은 이 백도어를 위해서 2년 가까이 XZ Utils에 커밋을 하면서 신뢰를 쌓았고 이 사건이 벌어지기 전까지 XZ Utils를 유지보수하면서 지탱한 것도 사실이다. 이번 사건이 발생했을 때 많은 사람이 "어떻게 리뷰를 통과하고 악성코드가 코드에 들어왔지?"라는 의문을 가졌지만, 메인테이너가 직접 넣은 코드였고 메인테이너가 단둘뿐이었기 때문이다.
이번 공격 자체도 충격적이지만 비슷한 일이 반복적으로 발생하는데 상황이 나아지진 않는다고 느끼고 있다. 이전에도 비슷한 사건이 있었다.
  • 2018년에는 Node.js의 event-stream를 이용한 공급망 공격이 있었다. 2011년에 event-stream을 만든 Dominic Tarr는 당시 npm에만 400여 개의 모듈을 가지고 있었고 더 이상 관리되지 않던 event-stream에 자신이 기여하겠다고 접근해서 저장소 권한과 모듈 배포 권한을 획득한 뒤 이 안에 악성코드를 심어서 배포했다.
  • 2024년에는 브라우저 간 동작 차이를 메꿔주는 polyfill.js를 편하게 사용하도록 polyfill.io라는 서비스가 Funnull이라는 회사에 넘어가게 되면서 최초에 polyfill.io를 만들었던 사람이 공급망 공격이 우려되니 즉시 사용을 중단하라고 경고했다.
polyfill.io는 약간 다른 부분이 있긴 하지만 event-stream을 포함해서 이번 사건도 오픈소스 메인테이너 부족이 근본적인 원인이 아닌가 하는 생각이 든다. 메인테이너가 10명, 20명이었다면 Jia Tan이 저렇게 메인테이너로 쉽게 들어오지도 못했을 것이고 들어왔어도 악성코드를 맘대로 커밋하지 못했을 것이다. 그렇게 보면 이런 문제 혹은 품질의 문제도 포함해서 근본적인 원인은 오픈소스 생태계의 메인테이너들이 처한 환경이 그리 좋지 않다는 데 있다고 생각한다.
xkcd에 Dependency라는 다음과 같은 만화가 있다.
notion imagenotion image
xkcd의 Dependency
수많은 의존성을 가진 오픈소스를 사용하고 있지만 일반적으로 개발자가 직접 사용하는 유명한 프로젝트나 모던한 프로젝트에만 관심을 두지, 그 뒤에 있는 많은 프로젝트에는 관심을 가지지 않는다. 이번 XZ Utils와 마찬가지로 xkcd에서는 그중 어떤 의존성은 한 명의 메인테이너에게 완전히 의존하고 있어서 그 사람이 지치거나 더는 작업을 할 수 없게 되었을 때 전체 의존성이 깨질 수 있음을 지적한 것이다.
공급망 공격은 아니었지만 2014년 4월 OpenSSL에서 메모리에 저장된 정보를 빼갈 수 있는 Heartbleed라는 취약점이 발견되었다. 이때 취약점과 별개로 오픈소스 생태계는 이래서 믿을 수 없다거나 어떻게 이런 버그를 모를 수 있냐 하는 얘기도 있었지만, 전 세계에서 OpenSSL에 의존하지 않는 곳이 없다시피 하지만 실패로 펀딩을 제대로 받지 못하고 풀타임 직원이 1명뿐임이 밝혀졌다. 그리고 OpenSSL에 십여 년 동안 기여하던 사람들이 이때 펀딩이 들어오면서 처음 뒤셀도르프에서 오프라인으로 만날 수 있게 되었다는 얘기에 놀라기도 했다.(이때 이분들은 온라인으로만 서로 작업하다가 15년 만에 처음 만나게 되었다.)
이런 사건들을 보면 우리 생태계가 소수의 선의에 얼마나 기대어 있는가를 다시한번 생각하게 했다. 여기서 우리 생태계라고 한 것은 오픈소스 생태계뿐만 아니라 그 위에 쌓아 올린 수많은 IT 시스템도 마찬가지이기 때문이다. 비슷한 일로 수많은 웹사이트에서 polyfill 라이브러리를 사용하는 core-js의 메인테이너가 생활비조차 마련하지 못한 상황이 알려져서 아주 안타깝기도 했다. 이 글을 보고 이후에는 core-js에 소액을 기부하고 있다.
최근 Redis의 라이센스 변경 이슈를 포함해서 몇 년 전에 Elastic의 라이센스 변경에 관한 글도 썼고 비슷한 상황에서 다른 선택을 한 Grafana Labs에 대한 생각도 적었었다. 물론 큰 이슈이지만 기본적으로 회사이기도 하고 거대기업과의 이권이 달린 일이기에 주목을 훨씬 많이 받는다는 면에서 앞에서 얘기한 모던하거나 직접 사용하는 프로젝트에만 관심을 가지는 것과 크게 다르진 않다고 생각한다. 물론 이 부분도 클라우드의 발전과 이어지기 때문에 중요한 부분이고 관심을 가지고 고민해야 할 부분이라고 생각한다.
그럼에도 잊지 않아야 할 것은 기업이 운영하는 오픈소스 외에도 개인 메인테이너나 소수가 운영하는 수많은 오픈소스 프로젝트라는 큰 축이 오픈소스 생태계를 지지하고 있다는 점이다. 의존성까지 고려한다면 이러한 소수의 오픈소스 프로젝트들이 생태계를 지지하는 중심이라고 생각한다. 그런데도 수년이 지나도록 이러한 환경을 개선되지 않고 있다.
이번 XZ Utils 백도어 사건을 운 좋게 막은 것은 다행이지만 이번 일을 통해 오픈소스 생태계가 계속 유지될 수 있게 하는 방법을 고민하는 계기가 되었으면 하고 바라고 있다. 지금 상태로는 지속 가능하지 않아 보여서 걱정이 많다.
꽤 오랫동안 생각해 봤지만, 명확한 해결책은 잘 떠오르지 않는다.(그럴 일이라면 이미 해결되었겠지...) 사람마다 생각이 다르겠지만 나는 지금보다 오픈소스 생태계에 기부금의 규모가 훨씬 커져야 한다고 생각한다. 개인이나 회사나 결국 오픈소스 생태계에 기여하는 메인테이너들의 헌신과 선의에 기대서 많은 이득을 취하고 있는데(꼭 돈을 번다기보다 개발 속도나 안정성 등에서...) 그에 비해 다시 생태계에 내놓는 것은 너무 부족하다고 생각한다(물론 나도 포함이다). 어떻게 개인 메인테이너들에게 분배하고 어떻게 해야 공평하냐 같은 많은 문제가 있긴 하지만 지금의 펀딩 혹은 기부금의 액수가 10배, 100배 커진다면 어느 정도의 문제는 해소되지 않을까 생각한다. 물론 돈이 몰리면 그로 인한 문제도 발생하겠지만 그건 또 그때 해결하면 되고 첫 발걸음으로는 오픈소스 생태계의 들어가는 돈의 규모가 더 커져야 한다는 것이 요즘 내 생각이다.
Response : No Trackback , No Comment

웹개발 관련

  • [번역] 리액트가 컴파일될 예정입니다 : React Will Be Compiled의 번역 글로 React Compiler가 나올 것이라는 건 알려진 사실인데 이게 무엇을 의미하는지 설명하는 글이다. React를 클래스 컴포넌트, 훅, 컴파일 이렇게 세 가지 시대로 나눌 수 있었는데 클래스 컴포넌트에서는 추상화를 위한 원시성이 없었기 때문에 이를 해결하기 위해 Hooks가 등장하게 된다. 하지만 Hooks에서는 메모이제이션이 필요해졌는데 왜 메모이제이션이 필요한지를 보여주고 컴파일을 통해서 자동 메모이제이션이 가능하게 만들 예정이다.(한국어)
  • 토스가 꿈꾸는 React Native 기술의 미래 : Toss에서 실험을 통해서 제품을 개선하는 곳에서는 React Native와 WebView를 사용하고 있는데 WebView에 기술적 한계에 비해서 React Native는 로딩속도가 빠르고 배포도 빠르기 때문에 이점이 많아서 점점 많이 사용하고 있다고 한다. 마이크로 프론트엔드 아키텍처로 서비스마다 뷰를 나누었고 ESBuild를 통해 빠른 배포와 로딩을 사용하고 있다.(한국어)

그 밖의 개발 관련

  • Stacked Diffs(Stacked PR) : Pull Request로 협업할 때 협업을 잘 하기 위해 여러 방법이 있는데 그중에서 Stacked PR을 설명하는 방법이다. 코드 리뷰를 하는 동안 다음 작업을 하기 위해서 PR이 서로 이어지기 때문에 Stacked라는 표현을 쓰는 것인데 Stacked PR이 필요한 이유와 함께 GitHub에서 실제로 Stacked PR을 만들려면 어떻게 하는지까지 보여주어서 이해하기가 좋다. 이러한 과정을 쉽게 도와주는 도구와 문제점도 같이 설명해 주고 있다.(한국어)
  • Enhancing Node.js Core: Introducing Support for Synchronous ESM Graphs : ESModules가 표준이 되었지만, CommonJS 기반이었던 Node.js에서는 여전히 ESM을 적용하는 데 어려움이 있었기 때문에 -experimental-require-module 플래그를 적용하면 ESM 모듈을 require()로 동기식으로 불러올 수 있는 기능이 추가되었다.(영어)
  • On Tech Debt: My Rust Library is now a CDO : 글을 쓴 Armin Ronacher의 의도를 다 알 수는 없지만 오픈소스 생태계의 문제를 지적한 글로 읽었다. Rust 생태계에서 어떤 의존성 라이브러리를 사용하고 있을 때 해당 라이브러리가 더 이상 관리되지 않아서 RUSTSEC 데이터베이스에서 해당 라이브러리가 문제 있다고 알리는 경우 이 기술 부채를 해결해야 하지만 현실에서는 해당 라이브러리 코드를 자신의 프로젝트에 합치면 기술 부채가 사라진다고 얘기하고 있다.(영어)

인프라 관련

  • Everything I Know About the Xz Backdoor : 무손실 압축 라이브러리인 xz-utils에 메인테이너에 의해 의도적으로 백도어가 포함된 것이 발견되었다. 서버의 SSH 접속이 느린 것을 추적하다가 백도어를 발견하고 리포팅한 Andres Freund가 추적한 내용을 보면 정황상 추측이 포함되어 있지만 2021년부터 Jia Tan이라는 계정이 xz 저장소에 Pull Request를 올리면서 등장해서 다른 가짜 계정을 통해서 메인테이터로 추가할 것을 압박하며 결국 메인테이너가 되어 라이브러리 호스팅하는 곳을 변경하는 등의 작업을 하면서 테스트 파일처럼 추가해 놓은 파일을 빌드 시에 마지막에 살짝 넣어서 배포된 라이브러리에 백도어가 포함되도록 했다. 발견되기 어렵게 하기 위한 많은 시도가 눈에 보이고 백도어로 인해 생긴 버그를 해결하는 과정에서도 이를 숨기려고 했던 노력이 눈에 보인다. 이 문제는 기존의 공급자 공격과는 다른 형태로 이뤄졌다는 면에서 오픈소스 생태계에 큰 충격을 주고 있다. 이번엔 운좋게 많은 시스템에 심어지기 전에 발견되어 영향은 크지 않은 것으로 보이지만 서버가 해당 백도어가 실행될 조건에 있지 않은지 확인해 볼 필요는 있다. GitHub은 이 저장소와 사용자를 정지시켰다.(영어)
  • Actions Usage Metrics public beta : GitHub Actions는 비용 리포트 외에는 별도의 통계 데이터를 제공하지 않아서 개인은 몰라도 회사에서는 어려움이 있었는데 이번에 Beta로 어떤 워크플로우가 얼마나 실행되고 어디서 실행되는지 파악할 수 있는 통계 페이지가 추가되었다. 이는 GitHub Enterprise Cloud 플랜에서만 현재 사용할 수 있고 Org에 어드민 권한이 있어야 볼 수 있다.(영어)
  • Linux Foundation Launches Open Source Valkey Community : Redis의 라이센스 변경으로 오픈소스가 아니게 되자 오픈소스 커뮤니티가 이에 대응하기 위해 빠르게 움직이고 있다. Linux 재단은 기존 Redis 기여자를 중심으로 Redis 7.2.4를 포크해서 Valkey로 이름 짓고 BSD 라이센스로 배포할 예정이라고 발표했다.(영어)

볼만한 링크

  • 네이버 Yorkie TF 인턴 생존기 : Yorkie는 CRDT 기반으로 실시간 동시 편집을 지원하는 오픈소스 데이터스토어인데 인턴으로 Yorkie 팀에 가서 2달 동안 일한 과정입니다. 제목은 인턴기이지만 Yorkie의 데이터 구조와 동작 방식에 대해 알 수 있는 글이다.(한국어)
  • The Curse of the Senior Software Engineer : 시니어 개발자로서 오래 일하면서 승진에 전혀 관심 없었지만, 시간이 지나 창업하려다가 다시 취업을 시도하다 보니 시니어로 채용하기엔 너무 높은 직급이거나 리더쉽으로 채용하기에는 경험이 부족한 상황에 빠졌다고 설명하는 글이다. 본인의 가설이긴 하지만 맞다면 다른 사람들은 조심했으면 좋겠다고 얘기하며 승진 주기에 맞춰서 커리어를 관리하거나 빅테크식의 관리 방법을 쓰지 않는 회사를 찾는 해결책이 있다고 얘기한다.(영어)
  • 20 years of Gmail : 20년 전 당시 이메일 서비스가 15메가바이트일 때 1기가 바이트의 용량을 약속하며 등장한 Gmail을 큰 인기를 끌면서 필수 서비스가 되었다. 이 글은 지난 20년을 돌아보며 Gmail의 대용량과 검색으로 수많은 메시지가 휘발성으로 사라졌지만, 여전히 Gmail의 메시지는 검색이 가능하다고 얘기하고 있다.(영어)

IT 업계 뉴스

  • Redis Adopts Dual Source-Available Licensing : Redis가 7.4 버전부터는 RSALv2(Redis Source Available License)와 SSPLv1(Server Side Public License) 듀얼 라이센스로만 배포하고 BSD 라이센스로는 배포하지 않는다고 공지했다. 이는 소스코드는 여전히 공개될 것이지만 Redis를 호스팅하는 클라우드 서비스는 무료로 Redis를 사용할 수 없게 되었다는 의미이고 Redis가 더 이상 오픈소스 소프트웨어가 아니라는 의미이다.(영어)

프로젝트

  • Rerun : 멀티모달 데이터의 시각화를 위한 SDK
  • jnv : jq를 사용한 인터랙티브 JSON 필터
  • monolith : 웹페이지를 하나의 HTML 파일로 만들어주는 CLI 도구

버전 업데이트

1열
2열
3열
두려움 없는 조직 - 심리적 안정감은 어떻게 조직의 학습, 혁신, 성장을 일으키는가 - ⭐⭐ 에이미 에드먼슨 지음최윤영 옮김다산북스원제: The Fearless Organization
https://blog.outsider.ne.kr/attach/1/4380922434.jpg
하버드 경영대학원의 종신 교수이면서 25년간 '심리적 안정감'을 연구한 에이미 에드먼슨이 조직 내 심리적 안정감에 관해서 설명하는 책이고 회사의 동료들과 독서 모임으로 같이 읽었다. 항상 느끼던 거지만 이런 류의 책은 나하고는 잘 맞지 않는다는 생각이 든다. 딱히 정의하기가 쉽지는 않은데 똑같이 조직이나 문화에 대한 얘기라고 하더라고 개발자에게 물어보세요처럼 더 실무와 경험을 담은 책이 많이 와 닿고 이 책이나 이전의 다른 리더십 책처럼 컨설팅 느낌의 조언이 모인 책은 좋은 말 모음집처럼 느껴져서 좋은 말이긴 하지만 또 크게 와닿지는 않는다.(성격이 그래서일지도...)
다른 전통적 조직에 비해서 IT 조직은 꽤 오랫동안 이런 심리적 안정감이 중요하다는 것을 인지하고 있었고 개선하기 위해 노력했다고 생각한다. 완전하다고는 할 수 없지만 타 분야보다는 꽤 높은 수준이라고 생각하고 있고 한국이 전반적으로 다른 나라에 비해 이런 부분이 뒤처지는 걸 생각한다면 좀 더 낫다고 생각한다. 대표적으로는 장애가 발생했을 때 이 문제를 개인의 문제로 만들지 않고 시스템의 문제로 만들려는 부분 등이 여기에 포함된다고 생각한다. 물론 IT라고 다 같은 건 아니니까 개인의 문제로 만드는 조직이 여전히 많다고 생각하고 상황에 따라서 그렇게 되는 경우도 있다고 생각한다.
그럼에도 조직에서 심리적 안정감을 확보하려고 노력하지만, 여전히 어렵긴 하다. 심리적 안정감이라는 건 모인 사람 수에 따라 차이가 나기도 하는데 5명이 모인 회의에서는 자유롭게 얘기할 수 있지만 200명이 모인 회의에서는 자가 검열이 더 강하게 동작하는 것이 사실이다. 당연히 똑같지 않은 게 당연한 거 같으면서도 왜 달라지는 걸까 하는 궁금증도 생기게 된다. '해도 되는 말인까?'같은 생각을 하게 되고 '나만 이렇게 생각하는 걸 아닐까?', '날 불편한 사람으로 보면 어쩌지?'같은 생각이 들게 마련이다. 개개인의 성격적인 차이도 당연히 있지만 조직에서 이런 부분을 얼마나 해소해 줄 수 있을까 하는 생각도 들면서 자가 검열이 아예 없어서는 안 되기도 해서(특히 부적절한 말) 적절한 선이 무엇인가? 하는 고민은 있다.
나도 지금은 연차가 많이 올라가서 회사에서 말을 많이 하는 편이지만 예전에는 전혀 그렇지 않았고 하루에 한마디도 안 하고 퇴근하는 경우도 많았다. 그렇다고 그때 불만이나 답답함이 없었냐 하면 또 그렇진 않았다. 물론 예전 조직이 심리적 안정감이 있는 조직이었냐 하면 그렇진 않았지만, 지금은 조직의 심리적 안정감이 객관적으로 전보다 나은지는 난 알 수 없을 거로 생각하긴 하다. 회사도 다른 회사이지만 내 연차나 위치도 다르긴 하니까 절대 비교할 수는 없다.
이건 꽤 중요한 부분이라고 생각하고 리더들이 고민에 빠지는 부분이라고 생각한다. 머릿속에 정답이라고 생각하는 건 당연히 있을 텐데 그게 진짜 정답일지 아무도 알 수 없으니까 결국 정답을 함께 찾을 수 있게 해야 한다고 생각한다. 물론 또 함께 정답을 찾도록 하면서 리더가 자신이 생각하는 정답으로 오도록 유도하면서 생기는 답답한 경우도 겪어봤고 너무 의사결정을 안 해주어서 논의만 하다가 일이 진행되지 않는 경우도 보았기 때문에 팀의 상황에 맞춰서 적절함(?)을 가지는 게 중요하다고 생각한다.
동의하는 편이다. 심리적 안정감이 중요하다. 물론 모두가 말을 다 하면 너무 피곤하다거나 일이 진행이 안 된다거나 하는 걱정을 할 수도 있지만 거기까지 가지 않아봐서 잘 모르겠다. 그래도 다 같이 본인이 느끼는 것을 얘기할 수 있다면 거기서 효율적인 부분을 풀어나가는 것이 훨씬 좋겠다고 생각한다. 나도 회사에서 "의견을 말하라"는 말을 많이 하긴 하는데 성격의 영향도 있는 거라 참 어렵긴 하다. 기분 안 좋은 사람한테 옆 사람이 기분 풀라고 말하는 답답한 상황처럼 느껴진다.(그런말 듣는다고 기분이 풀어질 리도 없으니까...)
실무자의 의견은 아주 중요하다고 생각한다. 이런 건 리더나 관리자가 알아내기가 쉽지 않고 꽤 많은 문제는 직원 혹은 실무자는 이미 문제라고 생각하고 있던 경우가 상당수라고 생각한다. 그래서 그때그때 바로 의견을 얘기하고 문제 해결이 진행될 수 있게 설득할 수 있는 과정이 필요하다고 보는 편이다.
책에서 얘기하는 대로 심리적 안정감을 확보하는 것은 회사에서 아주 중요한 일이라는 것에 동의한다. 문제는 어떻게 심리적 안정감을 확보하냐에 있을 것 같다. 책에서 어느 정도 나와 있기는 하지만 좀 추상화된 얘기들이라 실제 조직에서 적용하기에는 얕게 느껴졌다. 아무래도 난 현실에 복잡한 상황에서 이를 어떻게 적용할 것인가에 더 관심이 있는 것 같다. 책에 대해 좀 안 좋게 얘기한 느낌이 있지만 당연한 얘기라 와닿지 않았다는 의미이지 책에서 얘기하는 내용이 안 중요하다는 얘기는 당연히 아니다.
Response : No Trackback , No Comment
Trackback URL : 이 글에는 트랙백을 보낼 수 없습니다

Leave a Reply

Name *
Password *
Website Address
secret
Your comment

웹개발 관련

  • CrUX 202402 : Google Chrome에서 실제 사용자가 경험하는 웹사이트 성능을 측정한 데이터 세트인 CrUX의 2024년 2월 데이터가 BigQuery에 등록되었습니다. 직접 조회해 볼 수 있습니다.(영어)
    • LCP가 good을 경험한 사용자는 61.3%
    • FID가 good을 경험한 사용자는 96.2%
    • CLS가 good을 경험한 사용자는 76.6%
    • LCP, CLS, FID 모두 good을 경험한 사용자는 48.8%
    • INP가 good을 경험한 사용자는 80.6%
    • LCP, CLS, INP가 모두 good을 경험한 사용자는 45.6%
  • The End Of My Gatsby Journey : 독특한 데이터 계층과 SSG(Static Site Generator) 덕분에 인기를 끌은 Gatsby가 점점 인기를 잃고 Netlify에 인수된 후 개발까지 멈추게 되었다. 오랫동안 Gatsby를 좋아하고 사용하던 개발자가 더 이상 Gatsby를 안 쓰기로 하면서 Gastby에 무슨 문제가 있었는지를 정리한 글이다.(영어)
    • 수익을 내기 위해서 Gastby Cloud를 도입하면서 증분 빌드 등의 추가 기능을 Gastby Cloud에서만 사용할 수 있고 다른 클라우드에서는 쓰기 어렵게 만들면서 Vercel과의 경쟁에서 이기지 못했고 Netlify에 인수된 이후에도 Gastby Cloud의 기능이 Netlify로 이전될 것이라고 했지만 이는 현실이 되지 않았고 Netlify는 직원을 대부분 해고하게 된다.
    • Netlify의 CEO인 Matt Biilmann은 Gasby가 Next.js와의 혁신 경쟁을 포기하고 깨끗하고 안정적인 프레임워크로 유지하는데 집중한다고 발표했다.
    • Gastby가 사용자에게 외면받은 이유는 의존성이 너무 많아서 다루기 어려웠고 개발 속도와 빌드 속도가 너무 느렸기 때문이다.
    • 그럼에도 Gastby가 잘한 부분은 GraphQL 데이터 레이어, 클라이언트 성능, 플러그인 생태계를 꼽았다.
  • Speedometer 3.0: The Best Way Yet to Measure Browser Performance : Apple WebKit 팀이 Blink, Gecko 등의 주요 브라우저 엔진 개발자들과 협업해서 브라우저 성능을 측정하는 Speedometer 3.0을 공개했다. Speedometer는 다른 벤치마크 도구와는 달리 TodoMVC 앱을 구동해서 실제 웹 앱이 동작하는 것을 테스트할 수 있게 했으며 더 복잡한 앱과 다양한 콘텐츠, 차트, 코드 에디터, WYSIWIG 에디터를 테스트에 추가해서 브라우저 성능을 제대로 측정할 수 있게 되었다.(영어)
  • Interesting ideas in Observable Framework : Observable에서 최근 공개한 Observable Framework의 장점을 소개한 글이다. Observable Framework는 기본적으로 정적 사이트 생성기인데 마크다운 내에서 자바스크립트를 사용할 수 있으면서도 의존하는 셀의 데이터를 변경하면 다른 곳도 즉각적으로 변경되며 데이터로 빌드 시에 로딩되기 때문에 아주 빠릅니다. 마크다운만 관리하면 되기 때문에 관리하기가 쉬워서 빠르게 대시보드를 만들 수 있다.(영어)

그 밖의 개발 관련

  • 테스트가 관리하는 트랜잭션 - 향로 님의 @Transactional 글을 읽고 : 스프링에서 @Transactional을 이용한 롤백 테스트에 대한 향로님의 글에 대해 토비님이 의견을 남긴 글이다. 기술에서 안티패턴은 많은 경우 동작 방식을 제대로 이해 못 한 경우에 발생하는데 토비님은 이 글에서 테스트에서 @Transactional이 어떻게 동작하는지를 설명하고 이 문제가 @Transactional의 문제인지 트랜잭션 테스트 자체의 문제인지 짚고 팀의 상황에 따라 여러 가지 테스트 스타일을 사용할 수 있지만 기본적으로 스프링의 @Transactional을 기본으로 쓰고 트랜잭션 상황을 잘 이해하고 있어야 한다고 얘기하고 있다.(한국어)
  • Keeping secrets out of public repositories : GitHub 저장소에 실수로 API 키나, 비밀번호 등 민감한 정보를 같이 커밋하는 경우가 있는데 그동안은 GitHub이 탐지해서 메일로 알려주었지만 이제 모든 공개저장소에서 커밋에 이러한 시크릿이 포함된 경우 푸시가 차단되도록 변경되어서 푸시 후 제거가 아니라 푸시 자체를 막을 수 있게 되었다.(영어)

인프라 관련

  • Grafana Labs Observability Survey 2024 : Grafana Labs에서 300명 이상의 실무자에게 설문 조사를 한 결과를 공유했다.
    • 중앙 집중화된 옵저버빌리티를 가진 조직의 79%가 시간과 비용을 아꼈다.
    • 70%의 팀은 4가이 이상의 옵저버빌리티 기술을 사용한다.
    • 사용중이라고 답한 옵저버빌리티의 도구는 62가지다.
    • 응답자 중 61%는 옵저버빌리티의 가장 큰 우려 사항으로 비용이나 예상치 못한 청구서를 꼽았다.
    • 응답자의 98%가 오픈소스 옵저버빌리티 도구를 쓴다고 대답했다.
    • 가장 많이 쓰이는 기술은 Grafana, Prometheus, Grafana Loki, OpenTelemetry, ELK다.
  • 서버리스 ML 훈련 인프라 구축하기: Vertex AI Pipelines & TFX : 당근마켓에서 GKE에서 Kubeflow 파이프라인으로 관리하다가 작년부터 Vertex AI Pipelines로 갈아탔다. Vertex AI Pipelines는 매니지드 서비스라 운영의 부담을 덜 수 있었고 편리한 시각화와 주기적 재실행 등 편리한 기능을 설명하고 모니터링하는 방법도 소개하고 있다.(한국어)
  • Introducing the Daggerverse : 몇 주 전 Dagger에서 Dagger Functions라는 기능을 출시하면서 언어가 달라서 서로 호출할 수 있게 되었기 때문에 Dagger Functions를 모듈화해서 공유할 수 있도록 레지스트리인 Daggerverse를 공개했다.(영어)

볼만한 링크

  • Headcount benchmarks for DevProd teams : 개발자 생산성 관련 플랫폼인 DX에서 고객사의 데이터를 분석해서 여러 회사의 총 엔지니어 인력과 중앙 집중식 생산성 팀의 입력 비율에 대해 정리한 보고서다. 개발자가 1,000명 미만인 회사는 평균 19%의 인력이 개발자 생산성 팀에 있었고 조직이 커질수록 비율은 줄어드는 경향이 있었으며 시리즈 C-E의 회사들은 21.7%, 시리즈 F 이상은 평균 15.8%의 인력이 배치되어 있었다. 각 회사가 중앙집중식 개발자 생산성 팀을 어떻게 구성하고 있는지에 대한 예시도 볼 수 있다.(영어)
  • 사내 해커톤에 진심인 IT서비스 회사, 퍼플아이오 : 글로벌 SaaS 플랫폼으로 도약할 비전을 가지고 있는 퍼플아이오의 인터뷰 기사이다. 사무실 좌석 예약제를 하기 위해 사내 해커톤을 하는데 그 퀄리티가 아주 높다. 코오롱몰과 서비스 개선 업무도 하지만 자체 서비스도 성공하게 하기 위해 해커톤으로 아이디어를 얻어서 코드앤버터라는 팝업/배너 관리 서비스도 출시해서 개선하고 있다. 개발자를 귀하게 여긴다는 슬로건이 좋다.(한국어)
  • Marking the Web’s 35th Birthday: An Open Letter : 월드와이드웹을 만든 Tim Berners-Lee가 5년 전에도 웹이 몇몇 기업에 지배된 문제를 지적한 적이 있는데 이제 AI의 발전으로 이러한 문제가 더 심각해졌다며 웹의 35주년을 맞이하여 공개서한을 작성했다. 해결해야 할 두 가지 문제는 원래 구상했던 웹의 탈중앙화 정신과 위배되는 권력 집중 정도이고 또 하나는 사람들의 정보를 통제할 수 있는 개인 데이터 시장이다. 이러한 문제를 방지하기 위해 개혁하려는 사람에 대한 지지가 필요하다고 호소하고 있다.(영어)
  • 서비스에서 넛지를 추구하면 안 되는 걸까 : 넛지와 다크패턴을 설명하는 글이다. 나도 넛지라는 말을 종종 사용해서 넛지를 넣는 거에 곤란해하는 상황이 좀 의아하긴 했는데 넛지는 사용자가 더 나은 결정을 할 수 있도록 유도하는 방식이고 다크 패턴은 사용자를 속여서 의도하지 않는 선택을 하도록 유도하는 전략이라 둘을 구분해서 사용해야 한다는 부분에 동의한다.(한국어)
  • Vision Pro is an over-engineered "devkit" : Meta의 전 Oculus 헤드인 Hugo Barra가 Apple Vision Pro에 관해 쓴 글이다. Vision Pro 덕에 VR에 관심이 늘어난 건 Meta에게도 좋은 일이지만 Oculus가 그랬듯이 현실에 비해 과한 하드웨어가 들어가서 이건 개발키트의 성격이 강하다고 하고 있다. Vision Pro는 지금까지 장비 중 가장 강력한 디스플레이를 선보였으며 고의로 약간 흐릿하게 해서 픽셀 문제를 해결했지만, 패스스루 모드의 모션 블러 문제는 피하지 못했다. 생산성 면에서 아이패드나 맥북과 비교해서 현재 어떤 위치에 있는지와 초기의 신기함과 실제 사용까지 가기까지의 문제와 가능성을 경험자로서 잘 짚어내고 있다.(영어)

IT 업계 뉴스

  • 대체 앱스토어 설치 앱, EU서 30일 이상 떠나면… : EU의 디지털 시장법 DMA를 준수하기 위해 Apple이 iOS 17.4부터 앱 스토어외에 대체 앱스토어를 지원하기 시작했다. 하지만 대체 앱스토어를 사용하려면 기기 위치가 EU 회원국이어야 하고 다른 국가에 가서 30일 이상 지나면 더 이상 업데이트할 수 없고 새 앱을 설치할 때도 EU 회원국에 있어야 한다고 밝혔다.(한국어)
  • OpenAI denies Elon Musk lawsuit claim that there ever was founding agreement : Elon Musk가 3월 초 OpenAI의 Sam Altman과 Greg Brockman이 초기 창업할 때 OpenAI가 인류를 위한 비영리 단체가 될 것이고 상업적 이익을 위해 정보를 비공개로 하지 않는다는 2015년 창립 계약을 위반했다며 소송을 걸었다. OpenAI는 이러한 합의를 한 적이 없다고 반박했다.(영어)
  • OpenAI and Elon Musk : OpenAI가 위 고소 이후 OpenAI와 Elon Musk와의 관계에 관해 설명했다. 처음 창업할 때 Elon Musk가 참여하고 자본을 댔지만 이후 영리 법인으로 전환하기로 하면서 자신이 CEO가 되길 원했고 Tesla와의 합병도 제안했다가 Tesla 내에서 AGI를 만들겠다며 퇴사했다고 하며 증거 이메일을 공개했다.(영어)
  • Fig is sunsetting, migrate to Amazon CodeWhisperer : 확장된 CLI를 제공하는 Fig가 작년 9월에 AWS에 인수되었는데 올해 9월 1일부로 Fig 접근이 종료되고 앞으로는 Amazon CodeWhisperer에 통합되었으니, CodeWhisperer를 사용하라고 한다.(영어)
  • Introducing the next generation of Claude : Anthropic에서 새로운 LLM인 Claude 3을 출시했다. Claude 3에는 Haiku, Sonnet, Opus 세 가지 모델이 포함되어 있고 Opus가 가장 강력한 모델이다.(영어)

프로젝트

  • PromptHero : AI로 생성한 수백만 개의 이미지의 프롬프트를 검색할 수 있는 사이트.

버전 업데이트

웹개발 관련

  • React Labs: What We've Been Working On – February 2024 : React에서 연구 개발 중인 프로젝트의 진행상황을 정리한 글이다.(영어)
    • 상태 변경으로 종종 너무 많은 렌더링이 일어나는 문제를 그동안 useMemo, useCallback, memo 등 수동 메모이제이션을 사용해서 해결해 왔다. 합리적인 타협점이지만 이 문제를 해결하기 위해 React를 위한 최적화 컴파일러를 구축하는 것이 React Compiler다. 그동안 리서치 프로젝트였지만 이미 instagram.com에서 사용 중이고 Meta에 더 적용한 후 첫 릴리스를 오픈소스로 공개하기 위해 준비 중이다.
    • Server Actions는 클라이언트에서 서버로 데이터를 보내는 방법으로 개발 중 이 API를 클라이언트에서만도 사용할 수 있도록 API를 확장해서 이러한 기능을 Actions라고 부르게 되었다.
    • 이전에는 Meta 내부에서 개발하고 안정 버전만 공개되었는데 React Canary의 도입으로 개발 중인 새로운 기능도 커뮤니티에서 미리 확인할 수 있게 되었다. Directives, Document Metadata, Asset Loading, Actions 같은 기능도 모두 react.dev 문서에 추가되었다.
    • 오랜 작업으로 릴리스할 준비가 되었고 Document Metadata, Asset Loading은 일부 앱에는 큰 변화가 되므로 다음 버전은 React 19가 될 예정이다.
    • 화면에서 보이지 않는 부분에 적용되기 때문에 Offscreen라는 이름으로 개발 중이던 기능을 개발하면서 화면에 보이면서도 비활성 상태일 수 있다는 것을 알게 되어 이름을 Activity로 변경했다.
  • 인프런 콘텐츠에 동적으로 생성되는 Open Graph(OG) 이미지 적용하기 : 인프런에서 콘텐츠를 외부에 공유할 때 OG 이미지를 콘텐츠에 맞게 동적으로 생성해 주기 위해 작업한 결과를 정리한 글이다. Vercel이 만든 og를 사용하고 CDN을 연결해서 기능을 구현했지만, 서버 쪽 성능은 좋지 않았기에 og 라이브러리 대신 그 내부에서 사용하는 satori를 직접 사용하면서 병목이 되는 부분을 개선하고 satori에 성능 개선 제안도 하면서 최초 이미지 생성 성능을 35배나 개선했다.(한국어)
  • Introducing SafeTest: A Novel Approach to Front End Testing : Netflix에서 내부에 적용해서 사용하는 프론트엔드 테스트 프레임워크 SafeTest를 공개했다. 기존의 UI 테스트 프레임워크 중 react-testing 라이브러리 같은 단위테스트 도구는 렌더링 대상이나 임포트 등을 제어할 수 있지만 실제 페이지와 상호작용할 수 없게 되고 Cypress나 Playwright같은 통합테스트 도구는 페이지는 제어할 수 있지만 내부를 제어할 수가 없게 된다. 이러한 문제를 해결하기 위해 SafeTest를 만들게 되었고 지연 로딩을 활용해서 페이지에 테스트를 실행하는 코드를 동적으로 로딩하는 것이 주용 아이디어다. 이렇게 설정한 뒤에 Playwright를 사용해서 실행하므로 페이지를 테스트할 수 있으면서도 특정 함수나 컴포넌트를 오버라이딩해서 더 쉽게 테스트할 수 있다.(영어)
  • JSR: What We Know So Far About Deno’s New JavaScript Package Registry : JSR은 Deno 팀에서 만든 패키지 레지스트리로 Deno 팀에서는 npm을 고려했지만 Deno 환경과는 맞지 않는 부분이 있어서 ESModules가 도입된 상황에서 npm 레지스트리말고 새로운 개발자 경험을 줄 새로운 중앙 패키지 레지스트리를 구축할 필요가 있었다고 한다. 개발자들은 TypeScript를 제대로 지원을 하는 점에서 매력적이라는 의견도 있지만 반드시 모듈을 발행하려면 Deno를 써야하는 문제도 있고 생태계가 분열되는 것에 대한 걱정도 있다.(영어)

그 밖의 개발 관련

  • React Native 앱 접근성 지원 시작하기 : 뉴스레터 서비스인 뉴닉의 React Native 앱에서 접근성을 개선한 내용을 정리한 글이다. 다크모드를 지원하고 기능을 말로 설명해 주는 보이스오버나 톡백 기능을 구현하고 가로 모드 지원과 폰트 크기를 다양하게 지원할 수 있도록 개선했다. 스타트업에서 제품의 성장과 접근성 지원 간의 우선순위에 대해 고민이 많았지만, 접근성이 중요하다고 공감하는 사람이 많아서 할 수 있었다고 한다. 이렇게 접근성 개선을 노력하는 서비스를 응원한다.(한국어)
  • Popular git config options : Git에서 설정하면 좋을 설정을 정리한 글이다. pull 할 때 어떻게 동작할지나 컨플릭트시 보여주는 방식, autosquash 설정이나 push할 브랜치 설정등 많은 사람들이 기본적으로 설정해서 사용하는 옵션들이 어떤 기능을 제공하는지를 정리해 두었다.(영어)
  • Better Git Conflicts with zdiff3 : Git에서 컨플릭트가 발생했을 때 두 브랜치의 차이점이 파일에 표시되는데 설정에서 diff3를 사용하면 원래 어떻게 되었는지 3개의 차이를 모두 보여주어서 수정하기가 훨씬 쉬워진다. Git 2.35에서 추가된 zdiff3를 사용하면 공통 조상에서 충돌된 부분을 더 정확하게 잡아준다.(영어)

인프라 관련

  • 세계 최초로 cert-manager 버그를 발견하고 해결하기 : Let's Encrypt 인증서를 사용하던 중 연결에 문제가 생긴걸 발견하고 원인을 추적해서 해결한 과정이다. Let's Encrypt에는 지금은 만료된 DST Root CA X3 루트 인증서와 새로운 ISRG Root X1 루트 인증서가 있는데 설정에서 ISRG Root X1를 사용하게 했음에도 DST Root CA X3가 내려오는 상황이었다. Let's Encrypt가 Trust CA가 되기 전에 DST Root CA X3를 사용한 과거가 있고 이를 deprecte 한 뒤 cert-manager에서 버그가 발생하는 조건이 충족되어 문제가 발생했다.(한국어)
  • 개발-운영 생산성 모니터링하기 (with Devlake, Grafana) : 인프런에서 DORA의 생산성 매트릭인 배포 빈도, 변경 사항이 적용되는 시간, 변경 실패율, 서비스 복원 시간을 측정해서 가시화하기 위해 작업한 내용이다. 여러 도구를 검토 후 오픈소스인 Devlake를 이용해서 GitHub, Jenkins, Jira를 연동해서 데이터를 수집한 뒤에 MySQL에 저장하고 이 데이터를 Grafana에 데이터소스로 연결해서 대시보드를 통해서 빌드, PR, 커밋, 이슈 등의 통계를 한 번에 볼 수 있게 했다. 한눈에 현황을 파악할 수 있어서 상당히 좋아 보인다.(한국어)
  • Product-Focused Reliability for SRE : 사이트 안정성 엔지니어(SRE)는 보통 서비스의 안정성을 책임지지만 이는 제품의 최종 사용자 경험에는 어느 정도 한계가 있다. 이를 개선하기 위해 Google의 SRE가 인프라와 서비스에 집중하는 대신 제품과 최종 사용자의 요구사항 지원에 집중해서 어떻게 해결했는지를 설명한 글이다. 이를 위해 엔지니어뿐 아니라 관리자와 디자이너 등 이해관계자의 참여를 유도하고 제품의 목적을 정의해서 우선순위를 정하고, 제품의 SLO를 측정하기 위해 클라이언트 SLO나 e2e SLO를 도입해서 제품의 SLO를 만들어서 이 신뢰성을 관리한다. 이 접근 방법은 SRE팀이 사용자와 비즈니스에서 가장 중요한 곳에 자원을 집중하게 만들어준다.(영어)
  • 스타트업 엔지니어의 AWS 비용 최적화 경험기 : 인프런이 AWS 비용을 최적화 하기 위해서 해온 활동을 정리한 글이다. 각 팀이 비용에 관심을 가지도록 분위기를 만들고 높은 비용부터 분석해서 개선해 나갔는데 스팟 인스턴스, CDN 등을 활용하고 같은 AZ내의 통신을 하도록 개선하고 일부 SaaS는 내부 설치형 도구로 바꾸면서 월간 3천만원 이상을 아낄 수 있었다고 한다.(한국어)
  • Freenginx: A Fork of Nginx : 웹서버인 Nginx의 핵심 개발자 중 한 명인 Maxim Dounin이 Nginx를 포크해서 freenginx를 만든다고 발표했다. Maxim Dounin는 원래 Nginx를 소유한 F5에서 일하다가 2022년 F5가 모스크바 사무실을 없앤 뒤로는 F5에서 일하진 않지만, 자원봉사자로 계속 일하기로 합의했다. 하지만 F5의 nginx에 너무 많이 관여하고 있고 F5내에서 이뤄지는 작업도 알 수 없기 때문에 nginx 개발에 더 이상 참여하지 않고 포크해서 freenginx에서 작업한다고 한다.(영어)
  • Announcing bpftop: Streamlining eBPF performance optimization : Netflix가 eBPF 프로그램의 성능 최적화와 모니터링을 쉽게 할 수 있게 하는 bpftop CLI를 오픈소스로 공개했다. bpftop으로 실행중인 eBPF 프로그램의 성능 통계를 실시간으로 볼 수 있고 bpftop을 사용 중일 때만 활성화되므로 오버헤드도 최소화하고 있다.(영어)
  • Introducing Dagger Functions : Dagger Functions 기능이 도입되어 원하는 언어로 기능을 구현하고 이를 다른 언어에서도 불러와서 사용할 수 있는 기능이 추가되었다. Dagger는 CI/CD를 위한 블록을 만들 수 있는 프로젝트라고 할 수 있는데 CUE에서 프로그래밍 언어로 바뀌면서 재사용면에서는 프로그래밍 언어의 제약이 생겼다고 생각했는데 Dagger Function을 이용해서 언어가 달라도 사용할 수 있게 되었다. 현재는 Go, Python, TypeScript의 가이드를 제공하는데 다른 언어의 가이드도 추가될 예정이다.(영어)

볼만한 링크

  • We Have to Start Over: From Atom to Zed : Zed 에디터는 GitHub에서 Atom을 만들던 Nathan Sobo, Antonio Scandurra, Max Brunsfeld이 나와서 창업한 회사인데 이 세 명의 창업자와 인터뷰한 내용이 정리된 글이다. Zed의 비전은 Atom에서 가졌던 비전과 거의 비슷한데 Atom때는 당시 기술적 성숙도가 미치지 못했고 IDE처럼 강력하면서 확장성 있으면서도 가벼운 에디터를 만드는 것이 목표라고 한다. Atom을 만들기 위해 Electron을 만들고 VS Code가 훌륭하게 해냈지만, 이들은 더 많은 것을 원했고 Rust와 GUI 가속을 선택했고 UI 프레임워크인 GPUI 2를 만들어서 Zed를 만들기 위한 기술 스택을 모두 소유할 수 있게 되었다.(영어)

IT 업계 뉴스

  • Google pauses Gemini’s ability to generate AI images of people after diversity errors : Google이 Gemini의 이미지 생성 기능을 공개했는데 여기서 인물 이미지가 제대로 생성되지 않아서 해당 기능을 일시 중지했다. 구글의 공지에 따르면 이미지 생성 시 특정 인종에만 한정되지 않도록 하고 싶었지만 반대로 문화적, 역사적 배경이나 특정 인종을 요청하는 경우는 정확하게 생성되어야 하지만 제대로 동작하지 않았다고 한다. 그래서 1800년대 미국 상원의원 등의 이미지 요청에서 흑인과 원주민 여성의 이미지가 생성되어 실제 역사적 사실과 성차별의 역사를 오히려 지우는 문제가 발생했다.(영어)
  • Gemma: Introducing new state-of-the-art open models : Google이 Gemini 모델을 만든 것과 같은 기술과 연구로 만든 경량 오픈형 모델인 Gemma를 공개했다. Gemma는 2B, 7B 2가지 크기를 제공하고 개발자 노트북 등에서 직접 실행할 수 있다.(영어)
  • Stable Diffusion 3 : 텍스트-이미지 변환 모델인 Stable Diffusion 3의 프리뷰 버전이 발표되었다. 8억 ~ 80억개의 파라미터를 지원하고 대기자로 등록해야 사용해 볼 수 있다.(영어)

프로젝트

  • Cursor : 코드 자동완성이나 채팅 등 AI 기능에 초점을 맞춘 코드 에디터.
  • Tempo : JavaScript 날짜/시간 라이브러리
  • DevPod : devcontainer.json를 이용해서 개발자 환경을 만들 수 있는 클라이언트 도구로 Codespaces의 오픈소스 버전이라고 생각할 수 있다.
  • Borp : Node.js 테스트 라이브러리인 node:test릐 위한 TypeScript 러너
  • readyset : Postgres와 MySQL을 위한 데이터베이스 캐시.
  • Testcontainers : 테스트 목적으로 데이터베이스, 레디스 등을 컨테이너로 환경을 구성해 주는 프레임워크

버전 업데이트

  • Grafana Tempo v2.4.0 : 분산 트레이싱 백엔드, 릴리스 공지
    • TraceQL에 실험적인 metrics 기능 추가로 trace 쿼리 결과에 함수를 적용해서 trace 쿼리를 확장할 수 있게 됨.
    • vParquet3이 기본이 됨.
44BITS 팟캐스트(홈페이지)는 첫 화부터 모든 에피소드를 들었을 정도로 나에게 꽤 애착이 있는 팟캐스트임에도 사이트가 따로 있고 거기서 에피소드가 발행되다 보니 문득 회고 등에서나 언급할 뿐 블로그에서 제대로 얘기한 적이 없다는 생각이 들었다.
지난주 방송으로 어느새 200회를 녹음했다. 200회면 매주 녹음한다고 해도 거의 4년이 걸리는 시간이라 새삼 '44BITS가 참 오래되었구나!' 하는 생각이 들었다.

stdout.fm 팟캐스트

200회 방송에서도 얘기 나왔지만 44BITS 팟캐스트는 2018년에 10월에 stdout.fm 팟캐스트라는 이름으로 1화를 시작했다. 이 팟캐스트는 seapy님 주도로 nacyot님, 너굴님 세 분이 시작했다.
notion imagenotion image
사용자 삽입 이미지
Twitter나 커뮤니티 활동을 오래 하다 보니 꽤 친해진 사람도 언제 어디서 친해지게 되었는지 잊어먹은 경우가 꽤 많다. nacyot님과 너굴님은 stdout.fm이 시작되기 전에 같은 회사에 다니긴 했지만, 같이 일하기 전에도 이미 알고 있는 사이였다. 회사 같이 다니기 전에는 아마 오프라인에서는 한두 번 인사한 정도면서 트위터에서 많이 떠들던 사이지 않았나 싶다.(정확히 기억이 나지 않는다) Seapy님도 그전에 트위터에서 얘기 나눈 기록은 많이 있는데 어디서 알게 되었는지는 잘 기억나지 않는다. 창업한다고 퇴사하는 글을 본 기억이 있어서 친분은 꽤 있었던 거 같다.
그래서 자연스레 stdout.fm 팟캐스트가 시작할 때부터 알고 있었고 1화부터 듣기 시작했다. 당시에도 다들 YouTube를 사용하고 있었는데 Seapy님이 팟캐스트의 유행이 다시 올 거라고 했던 기억이 난다. 물론 실제로 팟캐스트 유행은 돌아왔다. 전 세계에서는 유행이 되었지만, 한국에서는 그렇지 않았을 뿐이다.
국내에서는 2011년 "나는 꼼수다"가 등장하면서 팟캐스트가 인기를 끌었지만 나는 2009년 정도부터 팟캐스트를 들었는데 그때부터 지금까지 팟캐스트란 매체를 좋아하는 편이다. 그래서 stdout.fm이라는 한국어로 하는 기술 팟캐스트가 생겼다는 게 꽤 반가웠고 그래서 1화부터 열심히 들었다. 팟캐스트 앱은 내 아이폰에서 중요한 앱 중 하나였기에 구독만 하나 추가하면 쉽게 들을 수 있었다.
시작하는 사람들이 다 알고 있던 사람이었다 보니 아주 초반인 3화부터 게스트로 출연해서 해외 콘퍼런스에 갔다 왔던 경험을 얘기하기도 했다. 큰 준비 없이 수다 떨듯이 나와서 꽤 재미있었던 걸로 기억한다. 진행자들하고 친분이 있고 나도 뉴스레터를 계속 발행하고 있다 보니 이슈가 있을 때마다 게스트로 참석해서 같이 떠들었다. 시간이 지나면서 subicura님과 ecleya님도 멤버로 참여했는데 다 아는 사람들이었기 때문에 지인들과 그냥 수다 떠는 기분으로 참여했다.
SDuck님이 만들어주신 2020년 100회 기념 페이지를 보면 100회 중에 총 8번 참여했다. 엄청 많은 건 아니지만 게스트 중에는 가장 많이 참여했다.

44BITS 팟캐스트

팟캐스트는 stdout.fm이고 블로그는 44BITS로 운영하다가 101회부터 팟캐스트도 44BITS로 이름을 변경해서 운영하기 시작했다.
notion imagenotion image
사용자 삽입 이미지
그리고 난 2020년 12월에 당근마켓으로 이직했다. 이직 글에도 썼지만, 당시 난 꽤 소진된 상태로 번아웃이 왔다 갔다 하는 상태였고 당시 이직을 생각하고 있진 않았지만, 소고기를 구워주면서 당근마켓에 와서 같이 일하면서 팟캐스트 하자고 했을 때 재밌겠다는 생각에 맘이 꽤 동한 게 사실이다. 하지만 막상 이직했을 때는 코로나가 한창이었기 때문에 모이기가 어려워서 녹음은 별로 못하고 한참 동안은 그냥 일만 했다. 뭐 원래도 난 주기적으로 녹음하던 사람은 아니라서 크게 영향은 없었고 당연히 업무에 적응하느라 정신없기도 했다.
재택을 주로 하다 보니 가끔 모이거나 Zoom으로 녹음했지만 쉽지 않았고 녹음 간격도 꽤 띄엄띄엄하기 시작했다. 그러다 작년 초였나 오랜만에 번개로 다 같이 모여서 다시 팟캐스트를 잘하기 위해 2주마다 날짜를 정해서 하기로 했다. 전에는 지속해서 할 수 있도록 점심시간에 녹음했는데 요즘은 다들 바빠져서 점심시간에도 시간을 내기 어려워서 저녁으로 녹음 시간을 옮겼다. 다행히도 이게 효과가 꽤 있어서 이후로는 거의 2주마다 계속 녹음을 할 수 있게 되었다.
notion imagenotion image
사용자 삽입 이미지
게스트로 나올 때보다 자주 나오니까 더 재밌게 녹음을 한 거 같다. 초기에 Seapy님 얘기대로 녹음하는 데 너무 큰 노력이 필요하면 오래 할 수 없기 때문에 보통 주제 정도만 모아놓고 대본도 없이 그냥 생각나는 대로 하는 편이다. 나는 한 달에 2번씩 뉴스레터를 발행하기 때문에 그중에서 팟캐스트에서 얘기해 볼 만한 이슈나 트위터에서 본 주제를 가져와서 같이 얘기한다. 물론 우리는 앞뒤 정도만 자르고 편집도 따로 하지 않는다. 그래서 200회까지 올 수 있었다는 생각도 들고 그냥 잡담을 하다 보니까 어느새 200회네? 하는 기분도 든다.
200회 방송하면서도 느꼈지만 잡담하듯이 하다 보니까 설명도 좀 부족하고 기술 이름이나 옛날얘기를 그냥 꺼내면서 얘기해서 듣는 사람에게 친절한 편은 아닌 거 같다. 그래서 그런지 듣는 사람도 항상 비슷비슷한 느낌인데 그 대단하지 않은 잡담이 꽤 즐겁긴 하다. 여기서 잡담을 많이 하다 보니 대본까지 힘들게 준비한 RetroTech 팟캐스트를 기획하게 된 것이기도 하다.
멤버들이 다양한 관심과 재능이 있어서 시간만 많으면 재밌는 일을 더 많이 할 수 있을 것 같은데 다들 바빠서 좀처럼 쉽지 않다. 이번 200회때도 공개방송 얘기가 나왔지만 공개 방송이란게 장소 구하는거부터 녹음까지 할일이 한두개가 아니다 보니까 실제로 진행할 엄두가 나지 않았다.(물론 사람들이 오기는 할까? 하는 걱정도 있었다) 그래도 올해부터는 스튜디오가 생겨서 아지트처럼 쓸 수 있고 더 세팅되면 모이기만 하면 바로 방송도 할 수 있게 되어서 전보다 더 다양한 일을 할 수 있지 않을까 생각한다. 물론 스튜디오가 아주 가깝진 않아서(아주 멀지도 않지만) 자주 가진 못하지만 그래도 올해는 뭔가 또 재미난 일이 있지 않을까 기대한다. 지금처럼 계속 잡담하는 것도 좋고 ㅎㅎ

웹개발 관련

  • The web just gets better with Interop 2024 : 브라우저 간 호환성을 유지하기 위해 여러 브라우저가 벤더와 회사들이 공동으로 테스트를 만들어서 상호 운용성을 개선하기 위한 Interop 2024가 발표되었다. Interop 2023 컨테이너 쿼리, :has(), Flexbox, Grid 등의 영역의 상호 운용성을 크게 개선했다. 올해는 Microsoft Edge를 크롬과 별도로 구분해서 보여주기 시작했으며 접근성, 웹소켓용 HTTPS URL, CSS Nesting, CSS 커스텀 프로퍼티(@property), 선언적 쉐도우 DOM, 레이아웃, 스크롤바 스타일 등이다.(영어)
  • How To Center a Div : DIV를 부모 요소의 중앙에 배치하는 것은 의외로 까다로운 작업인데 중앙에 배치한 다양한 방법을 설명하는 글이다. 마진을 auto로 설정해서 가운데 배치하거나 flexbox를 이용하는 방법 그리고 position: fixed를 이용해서 뷰포트의 중앙에 배치하거나 CSS Grid로 중앙에 배치하는 방법을 설명한다. 실행해 볼 수 있는 예제를 같이 보여주면서 특징을 설명하고 있어서 이해하기 좋다.(영어)
  • Observable 2.0 : d3.js를 만든 Mike Bostock이 만든 Observable에서 2.0을 출기하면서 Observable 프레임워크를 오픈소스로 공개했다. 그동안 데이터를 효과적으로 보여주기 위한 노트북을 제공했는데 이는 임시적인 데이터 탐색에는 적합하지만 세련된 대시보드와 앱에는 적합하지 않았기 때문에 프레임워크를 만들게 되었고 이를 이용해서 데이터앱을 구축할 수 있다. 모든 백엔드 언어와 연결이 가능하고 빌드시에 데이터로더가 실행되기 때문에 페이즈 로딩이 아주 빠르다.(영어)

그 밖의 개발 관련

  • The Plan for Rails 8 : Rails 8 웹프레임워크에 대한 계획이 공개었다. 최신 웹 앱의 복잡성을 압축해서 웹 앱을 더 쉽게 구축한다는 Rails의 모토를 여전히 유지하고 있다. NVMe SSD로 데이터베이스가 훨씬 빨라짐에 따라 Solid Cache와 Solid Queue를 통해 기존 Redis에 의존하던 캐싱이나 백그라운드 작업을 대체하고 데이터베이스를 사용하게 되었다. Postgres와 MySQL이 지원하는 WebSocket을 통해 브라우저에 메시지를 브로드캐스트할 수 있도록 지원하고 오랫동안 Rails의 에셋 파이프라인이었던 Sprockets을 propshaft이 대체할 예정이다. 그외에도 Kamal 배포도구, HTTP 기본 인증 생성기, 벤치마크 도구, Rails 8의 Language Server 등의 도구가 포함될 예정이다.(영어)
  • Opening Up GitButler : 전에 GitHub에서도 일하고 Pro Git을 쓴 Scott Chacon이 창업한 Git 브랜치 관리 시스템인 GitButler가 정식 오픈했다. GitButler는 Virtual Branch라는 개념을 도입해서 워킹 디렉토리에서 작업을 하던 중 버그 수정을 위해 새로운 브랜치로 전환하지 않고 UI에서 필요한 수정사항만 끌어다가 새로운 브랜치를 만들어서 커밋하고 푸시할 수 있게 제공한다. 곧 클라이언트도 제공할 예정인데 GitButler는 기존 Git 워크플로우는 그대로 유지하면서 브랜치를 사용하는 완전히 새로운 방법이라고 소개하고 있다.(영어)
  • Rye: A Vision Continued : Python 프로젝트와 패키지를 관리하는 도구인 Rye를 만든 Python의 유명 개발자 Armin Ronacher가 Rye의 중요성을 설명하는 글이다. Rye가 있으면 Python이 설치도 안 되어 있는 환경에서도 1분 이내에 모든 환경이 갖춰진 파이썬 프로젝트를 시작할 수 있는데 이는 Rust에서 Cargo의 원활한 통합을 보면서 이를 Python 커뮤니티에서도 비슷한 경험을 하고 싶어서 만들었다고 한다. Cargo가 그렇듯이 모든 도구를 다 만드는 것이 아니라 생태계의 다른 도구를 연결해 주는 역할을 하]고 이는 Rye도 비슷하게 하고 있지만 아직 1인 프로젝트이며 이러한 표준화 아이디어가 Python 생태계에 더 필요하다고 얘기한다.(영어)
  • uv: Python packaging in Rust : pip와 pip-tools를 대체하려고 Rust로 작성된 uv는 엄청나게 빠른 Python 패키지 인스톨러이면서 리졸버이다. Python을 위한 Cargo를 지향하고 있으며 이번 릴리스와 함께 Rye의 관리도 같이 맡아서 공동의 비전을 실현하기 위해 노력할 것이라고 한다.(영어)

인프라 관련

  • Enabling a Cloud Operating Model : HashiCorp에서 클라우드 인프라를 운영하는 모델을 정리한 백서를 공개했다. 물론 회사에서 공개한 내용이니 상당 부분은 이러한 운영 모델을 HashiCorp의 제품으로 어떻게 구축하는지에 대한 내용이지만 운영 모델에 대한 내용과 HashiCrop의 접근도 참고할 만하다. 클라우드에서는 정적 인프라가 아니라 동적 인프라이고 IP 대신 ID 기반으로 보안과 네트워킹 정책을 세워야 하고 수동 티켓 시스템으로 운영하는 대신 자동화된 셀프서비스 플랫폼이 필요하다. 조직 내에 클라우드를 도입하고 이 운영 모델이 점점 성숙해질 수 있도록 플랫폼 엔지니어링 관행을 도입해서 운영을 소프트웨어 문제로 취급하도록 하고 베스트 프렉티스를 모아서 셀프서비스 기능으로 제공하고 동적 환경을 지원하는 워크플로우를 만들 수 있도록 변화가 필요하다고 얘기하고 있다. 23페이지로 된 PDF로 된 백서라서 개인 정보를 입력해야 다운로드 받을 수 있다.(영어)
  • Unlocking Kubernetes Performance with no CPU Resource Limits : Kubernetes에서 리소스를 설정할 때 CPU의 requests와 limits가 어떻게 동작하는지 설명하고 왜 limits를 설정하지 않는 것이 좋은지를 설명한 글이다. requests가 있으면 사용할 CPU를 보장받을 수 있으면서 필요할 때는 그 이상의 CPU를 사용할 수 있지만 limits이 있으면 스로틀링 때문에 보장받은 CPU도 제대로 사용할 수 없기 때문인데 그림과 함께 이해하기 좋게 설명하고 있다. Kubernetes에서 나도 CPU limits를 해제하는 게 맞다고 생각하기에 동의하는 글이다.(영어)
  • AWS: EKS Pod Identities – a replacement for IRSA? Simplifying IAM access management : AWS EKS에서는 Pod에 AWS 권한을 부여하기 위해 IRSA(IAM Roles for Service Accounts)를 사용하는데 새로 나온 EKS Pod Identities로 IRSA를 대체하는 방법을 사용한다. EKS Pod Identities는 OIDC를 사용하지 않기 때문에 IAM 역할을 만들고 클러스터 수준에서 서비스 어카운트를 연결해서 관리할 수 있다.(영어)

볼만한 링크

  • How Quora Died : 전문가에게 답변을 받을 수 있는 커뮤니티인 Quora가 쇠퇴해 가는 과정을 설명한 글이다. Quora는 좋은 질문과 좋은 답변을 얻을 수 있는 커뮤니티를 잘 구축했지만 트래픽을 모으려고 노력하면서 SEO를 위해 질문 길이를 제한하고 피드 최적화로 피드에 콘텐츠 기사를 넣기 시작했가 이어서 수익 공유 프로그램을 만들었는데 이는 기존 커뮤니티보다 봇을 만드는 게 더 돈이 된다는 것을 보여주었고 이후 답변에 AI를 도입하면서 답변은 전문가의 답변보다는 평이한 답변이 차지하게 되고 AI 학습을 위해 모든 질문 답변이 AI 학습에 사용된다는 이용약관의 변경으로 인해 사용자는 계속 이용할지 갈등하게 만들었다는 내용이다.(영어)
  • How SSH port became 22 : 1995년 SSH를 만든 Tatu Ylonen이 SSH의 포트 번호인 22번을 어떻게 할당받았는지를 적은 글이다. 당시 23번 포트의 Telnet과 21번 포트의 FTP를 대체할 수 있도록 SSH를 설계 후 무료인 22번 포트를 사용하면 좋겠다고 생각했습니다. 당시에는 인터넷의 규모가 작고 초기 단계였기에 IANA에서 포트 번호를 관리했기에 IANA에 SSH의 RFC를 첨부하면서 포트 번호를 받고 싶다고, 특히 22번을 받고 싶다고 이메일 보냈고 IANA에서 22번을 할당해 주고 Tatu Ylonen을 담당자로 지정해 주어 바로 SSH의 베타테스터들에게 공개했다.(영어)

IT 업계 뉴스

  • Weaveworks will be closing its doors and shutting down commercial operations : GitOps 솔루션을 만들던 Weaveworks가 문을 닫기로 했다고 2014년에 Weavework를 창업한 Alexis Richardson이 글을 올렸다. 2023년에도 1,000만 달러 이상의 매출을 기록했고 도입되는 회사도 늘어났지만, 매출 성장이 고르지 못했고 현금 사정이 불안했기 때문에 파트너와 투자자가 필요한 상황이었다. 대기업과 합병을 논의하고 있었지만 11시간 만에 결렬되고 결국 문을 닫기로 했고 weave.works 홈페이지도 이미 닫혔다. Weaveworks는 Cortex, eksctl, Flagger, Flux CD등 다양한 오픈소스를 만들었고 이 오픈소스는 CNCF에 기부되거나 eksctl은 Amazon의 공식 CLI가 될 정도로 생태계에는 큰 영향을 주었다. 이런 회사가 문을 닫는다는 것은 안타까운 일이다.(영어)
  • Apple is finally allowing full versions of Chrome and Firefox to run on the iPhone : Apple이 EU의 새 규정을 준수하기 위해 iOS 17.4부터 유럽 사용자는 Webkit 외 다른 브라우저 엔진을 선택할 수 있게 된다. EU에 거주하는 사람들만을 대상으로 하며 처음 Safari을 열때 브라우저 엔진을 선택할 화면을 볼 수 있게 되어 WebKit 외에 Blink나 Gecko를 선택할 수 있게 된다.(영어)
  • The Epic-Apple antitrust saga isn’t over yet : Epic 게임즈와 Apple의 반독점 소성의 결과로 애플 인앱결제 외에 다른 결제 방법도 안내할 수 있다고 판결이 나왔지만 여기서도 27%의 수수료를 받겠다고 해서 Epic 게임즈가 비난하며 다시 제소할 계획이라고 밝혔다. Apple의 안내에 따르면 앱에 포함할 링크를 포함할 수 있는 권한을 신청하고 월말 기준으로 거래 보고서를 통해 매출을 입증해야 하며 사용자가 링크를 탭하고 발생한 거래에 대해 27%의 수수료를 받겠다고 한다.(영어)
  • The next chapter of our Gemini era : Google이 자사의 생성형 AI인 Bard를 Gemini로 리브랜딩하고 Gemini Ultra를 출시했다. Gemini Android 앱을 출시하고 iOS 용도 곧 출시할 예정이라고 한다.(영어)
  • 구글의 차세대 모델: 제미나이 1.5 : Google에서 최근 Gemini 1.0 Ultra에 이어 Gemini 1.5를 발표했다. 1.5는 Mixture-of-Experts(MoE) 아키텍처를 사용해서 효율적으로 훈련해서 Gemini 1.0 Ultra와 비슷한 수준의 중형 멀티모달 모델로 기존 3만 2천 토큰을 넘어 최대 100만 토큰까지 처리할 수 있게 되었다.(한국어)
  • Creating video from text : OpenAI에서 텍스트를 입력하면 비디오를 만들어주는 AI 모델 Sora를 공개했다.(영어)

프로젝트

  • jsr : Deno에서 npm을 대체할 새로운 자바스크립트 레지스트리를 만들고 있다. 아직 자세한 내용은 공개되지 않았지만, Deno의 denoland를 대체할 것으로 예상된다.
  • LLRT(Low Latency Runtime) : AWS에서 실험적으로 QuickJS 엔진을 사용하고 Rust로 만든 JavaScript 런타임을 공개했다. 이는 서버리스 애플리케이션의 빠르고 효율적인 요구사항을 해결하기 위한 런타임으로 AWS Lambda에서 10배 빠른 시작 시간과 2배 저렴한 비용을 보여주었다.
  • Pkl : Apple이 프로그래밍할 수 있고 확장성 있으면서 안전한 구성 언어(Configuration Language)를 공개했다. Pickle로 발음한다.
  • Keep : 오픈소스 얼럿 관리 및 자동화 플랫폼
  • HyperDX : Datadog이나 New Relic의 오픈소스 대체제로 로그, 메트릭, 트레이스, 예외, RUM 등을 한곳에 모아서 서비스 문제를 쉽게 찾을 수 있게 해준다.

버전 업데이트

  • Turbo v8.0.0 : 싱글 페이지 애플리페이지의 변경을 관리하는 라이브러리, 릴리스 공지
  • Argo CD v2.10.0 : Kubernetes 배포 도구, 릴리스 공지
    • ApplicationSet 템플릿 지원
    • 관리자 권한 없이도 앱 사용자가 알림 설정 가능
Response : No Trackback , No Comment
현재 Git이 Merge 할 때 사용하는 전략이 ort로 바뀌었다. Git에 ort 머지 전략이 들어온 것은 Git 2.33부터였고 Git 2.34에서 별도의 설정 없이도 Merge할 때 사용되는 기본 전략으로 바뀌었다.
이 Merge 전략은 git merge와 git pull을 할 때 주로 사용되지만 rebase, cherry-pick, revert, stash, checkout에서도 사용된다. 2.34가 2021년 11월에 나왔으니 바뀐 지는 꽤 되었지만 뭐가 바뀌는지는 정확히 모르고 있어서 정리를 해봤다. 이 글 쓰는 시점의 Git 최신 버전은 2.43.0

resolve 전략

Git이 2개의 브랜치를 머지할 때 변경 사항을 합치기 위해 여러 가지 전략 중 하나를 선택한다. 원래의 전략은 3-way merge 알고리즘을 사용하는 resolve 전략을 사용했다.
3-way merge는 A 파일과 B 파일의 차이점을 분석한 후 두 파일의 공통 조상인 C 까지 고려해서 합칠 변경 사항을 구성하고 A, B, C 셋 다 다른 경우는 충돌(Conflict)로 표시해서 사용자가 해결하도록 한다.

recursive 전략

Git이 만들어진 초기인 2005년에 resolve 전략은 recursive라는 전략으로 교체된다. 이렇게 recursive로 바꾼 주요 이유는 머지할 두 브랜치가 공통된 조상이 없는 경우에도 각 브랜치에서 그 이름대로 재귀적으로 머지할 수 있어서 resolve 전략에서 충돌하는 경우에도 머지할 수 있고 한 브랜치에서는 파일이 수정되고 다른 브랜치에서는 파일명이 변경된 경우에도 이를 감지할 수 있기 때문이다.
이렇게 적용된 recursive는 오랫동안 Git의 기존 전략으로 사용되었다. 2005년에 적용되고 2021년에 나온 Git 2.33에서 바뀌었으니 16년 동안 사용된 셈이다.

ort 전략

ort는 재귀(recursion)와 파일이름 변경 탐지를 하는 recursive와 같은 컨셉을 가지고 처음부터 새로 작성된 전략이다. 그래서 ort라는 이름도 Ostensibly Recursive’s Twin의 약자로 표면적으로는 Recursive의 쌍둥이라는 의미이고 이전에 비해 훨씬 빨라졌다.
Git 공식 문서를 보면 ort 전략을 다음과 같이 설명하고 있다.
그러면 오랫동안 사용하던 recursive 전략을 왜 바꿀 필요가 있는지를 알아야 하는데 새로운 전략이긴 하지만 방법 자체를 바꾸었다기보다는 많은 최적화 작업을 합쳐서 ort라는 새로운 전략이 탄생했다고 볼 수 있고 그렇기에 이름도 recursive의 쌍둥이라는 이름을 가지게 된 것이다.
Git에서 recursive 머지의 코드 베이스는 문제를 해결하기 위해 조금만 고치다 보니 결국 고칠 수 없는 상황까지 왔습니다. 그래서 버그도 많이 발생하고 해결하기 어려운 엣지 케이스도 발생하고 있었고 개발자들도 이 부분의 코드 수정은 피하고 있었다. Git의 핵심 개발자 중 한 명인 Elijah Newren가 큰 변경을 하려고 하자 초기부터 Git을 리드하고 있는 Junio Hamano 그냥 다시 작성하자는 제안하고 이에 따라 아주 대규모의 최적화 작업이 시작된다.
이 최적화 과정을 이해하려면 Git의 3-way 머지를 좀 이해해야 한다.
     A---B---C topic
    /
D---E---F---G main
Bash
즉, 위처럼 2개의 브랜치를 머지한다고 했을 때 각 브랜치의 최신 커밋인 C와 G, 두 브랜치의 공통 조상이 되는 커밋인 E까지 고려해서 머지하는 것이다. 특정 라인이 C 커밋에는 없고 G 커밋에는 있다고 했을 때 이 둘만 가지고는 이 라인이 추가된것인지 제거된 것인지 알 수 없다. 공통 조상이 E 커밋을 봤을 때 해당 라인이 있다면 C 커밋에서 제거한 것이고 E 커밋에 해당 라인이 없다면 G 커밋에서 추가된 것이다.(참고로 git에서 diff3 설정을 하면 충돌이 발생했을 때 공통 조상의 내용도 같이 보여서 수정할 때 편하다.)
여기서 파일 이름 변경까지 되면 훨씬 복잡해진다. 각 브랜치에서 파일 내용을 수정할 수 있지만 파일명을 바꾸거나 파일명은 그대로이지만 디렉터리 위치가 바뀔 수 있다. Git은 파일명을 따로 추적하고 있지 않기 때문에 머지할 때 이 이름 변경을 감지해서 이름이 변경된 파일을 찾아내야 하는 것이다. 위에서 말한 대로 머지를 할 때 3개의 커밋이 필요한데 각 커밋에서 고유의 파일명 목록을 만들고 서로 일일이 비교하면서 내용의 유사성을 비교해서 파일 변경인지를 표시하게 되므로 상당히 느린 부분이다.
코딩에서 추상화는 중요한 개념이지만 때로는 경계를 만들어서 경계에 걸쳐서 어떤 작업을 하려고 할 때 어렵게 만들기도 한다. Git도 이러한 추상화로 인해서 최적화가 어려웠던 경우인데 Git에도 파일 이름 변경을 탐지하는 컴포넌트가 분리되어 있었다. 이 컴포넌트는 3개의 커밋에 대한 정보가 아니라 2개 커밋에 대한 정보만 받고 있었는데 파일 이름 변경을 추적하려면 3개 커밋의 정보가 모두 필요했기 때문에 이 추상화 경계를 넘어서 추가 정보를 제공해야 했다.
또한, rebase나 cherry-pick을 할 때도 각 커밋 단계마다 이름 변경 탐지를 하게 되는데 이게 반복적으로 진행되므로 인메모리에 캐싱해서 개선하게 된다. 당연히 왜 이전에는 안 했는지 궁금할 수 있지만 캐싱해도 동작의 차이가 없는지를 확인하는 것이 아주 복잡했기 때문에 못 했던 것인데 이번에는 몇 가지 제약사항을 가진 채 이 캐싱 최적화를 추가했다.
Git에서 Index라는 것은 보통 우리가 Stage 영역이라고 부르는 것으로 다음 커밋에 포함될 파일에 대한 정보를 가지고 있는 데이터 구조인데 recursive 전략에서는 이 Index 데이터 구조가 핵심이었다(working tree 포함). ort 전략에서는 이 Index를 사용하지 않고 recursive에서 성능에 영향을 많이 주던 unpack_trees()라는 저수준 함수의 사용을 안 하도록 바뀌었다. 그래서 이 두 가지에 의존함으로써 생긴 제약을 대부분 해결할 수 있게 되었다.
다시 정리하면 ort는 index와 working tree를 건드리지 않고 머지 결과를 트리로 만들어서 이 머지 결과가 나왔을 때만 ort가 체크아웃 로직을 이용해서 머지 결과로 이동하게 된다. index에 항목을 추가 제거하는 동작과 머지하면서 수행되는 값비싼 트리 탐색을 피할 수 있게 되어 속도가 훨씬 빨라지게 된다.
최대한 간단히 정리했지만, 이 내용은 이 수많은 최적화 작업을 주도한 Elijah Newren이 작성한 6편의 글 Optimizing Git’s Merge Machinery, #1, #2, #3, #4, #5, #6에 잘 나와 있다. 아주 긴 글이지만 한번 읽어볼 만한 좋은 글이다.
Git 2.33 공지에 따르면 ort가 이전보다 훨씬 빨라져서 파일명 변경이 많고 복잡한 머지의 경우 500배가 빨라졌고 rebase 과정에서 비슷한 머지를 반복해서 하게 되면 ort가 일부 계산을 캐싱하기 때문에 9,000배 이상 빨라진다고 한다. 이건 특수한 경우고 일반적으로도 ort가 recursive보다 약간 빠른 것으로 나타났지만 recursive는 상황에 따라 속도 편차가 크지만 ort는 일관된 속도를 보여주었다.
일반적인 상황에서 보통 머지 속도가 문제 되진 않지만 아마 머지와 리베이스를 가장 많이 실행하는 GitHub이 ort를 적용한 결과를 보면 머지 속도가 p50에서는 10배 p99에서는 5배 빨라졌고 리베이스에서도 이전에 512시간 걸리던 리베이스가 ort에서는 33시간으로 줄어들었다는 것을 보면 속도가 얼마나 개선되었는지 알 수 있다.
추가로 Git으로 머지할 때 다음과 같이 어떤 전략이 사용되었는지 나온다.
Auto-merging a.txt
Merge made by the 'ort' strategy.
Bash
git merge --strategy recursive BRANCH-NAME처럼 머지할 때 -s나 --strategy 옵션으로 머지 전략을 지정하면 다른 머지 전략을 사용할 수 있다. 여기서처럼 ort 대신 recursive를 지정하면 메시지에서도 Merge made by the 'recursive' strategy.라고 나와서 머지 전략이 바뀌었음을 확인할 수 있다.

웹개발 관련

  • How Core Web Vitals affect SEO : Google은 Core Web Vitals로 사이트의 성능을 평가해서 SEO에 반영하는데 이 데이터를 실제 사용자에게 수집하므로 필드 데이터라고 부른다. Google은 크롬 브라우저의 실제 사용자의 75 퍼센타일로 전 세계에서 필드 데이터를 수집하기 때문에 사용자는 데스크톱이나 Android에서 Chrome을 사용해야 한다.(다른 말로 하면 iPhone 사용자는 집계되지 않는다) 지역별로 다르게 다루지 않고 전 세계에서 수집하므로 전 세계 모든 사용자에게 뛰어난 성능을 제공할 수 있어야 하고 점수는 지난 28일간의 평균 점수이므로 성능을 개선한 후 영향을 파악하려면 한 달 정도가 걸린다. Lighthouse 등으로 Core Web Vitals를 측정한 것은 실험실 데이터라고 부르는데 이러한 결과는 검색 결과에는 반영되지 않고 실제 사용자와는 다르기 때문에 성능 문제를 찾는 참고용으로 사용해야 한다.(영어)
  • QUIC 프로토콜 | 구글 또 너야? : QUIC 논문을 보고 내용을 정리한 글이다. 불필요한 RTT(Round Trip Time)을 줄이면 페이지 로드 시간에 큰 영향을 주기 때문에 QUIC은 TCP가 아니라 UDP 위에 구현되었는데 QUIC을 설계한 이유는 프로토콜을 변경하기 어렵고 핸드 쉐이크를 줄일 필요가 있었고 HOL 블러킹 문제를 해결하기 위해서였다. 이를 구현한 과정과 적용한 과정까지 정리되어 있다.(한국어)
  • Celebrate a more interoperable web with Interop 2023 : 브라우저간 호환성을 유지하기 위해 여러 브라우저가 벤더가 공동으로 테스트를 만들어서 상호 운용성을 개선하기 위한 Interop 2023이 마무리 되었다. 작년 초와 비교했는때 대부분 90점대 후반으로 큰 개선이 이루어 졌고 :has(), 컨테이너 쿼리, 서비그리드, 색공간 등 주요한 기능이 추가되었다. 곧 Interop 2024가 발표될 예정이다.(영어)
  • NEXT.JS APP ROUTER MIGRATION: THE GOOD, BAD, AND UGLY : Flightcontrol이라는 서비스가 Next.js의 페이지 라우터로 구축되어 있던 대시보드를 앱 라우터로 다시 구축하면서 경험한 내용을 정리했다. 중첩된 레이아웃을 구축할 수 있게 되었고 로딩 상태를 유연하게 표시할 수 있지만 실시간 업데이트를 위해 클라이언트에서 데이터 불러오는 코드를 중복으로 작성해야 했고 서버 측 오류가 쉽게 삼켜져서 추적하기에 어려웠다고 한다. 지금은 해결되었지만 개발하면서 버그가 너무 많아서 고생했고 개발 서버의 성능이 너무 안 좋아서 성숙도에 비해 너무 빨리 마케팅이 되었다고 한다.(영어)

그 밖의 개발 관련

  • Jira의 이슈 정렬 방식이 Integer 방식이 아니라고?! : 드래그 앤 드롭으로 리스트의 정렬을 조정하는 구현을 할 때 각 아이템의 정렬을 관리하는 방식에는 Integer, GreenHopper, Linked List 방식이 있습니다. Integer 방식은 위치를 변경하면 다른 모든 아이템의 값도 변경해야 하고 GreenHopper은 각 아이템 사이에 충분한 간격을 두어 쉽게 업데이트할 수 있지만 공간이 고갈되면 문제가 생긴다. Linked List는 앞뒤 아이템만 업데이트해 주면 되지만 조회할 때 풀 스캔을 해야 한다. Atlassian이 이러한 문제를 해결하기 위해 LexoRank를 만들었고 사전적 정렬을 위해 Bucket|FixedKey:VariableKey를 사용해서 정렬해서 O(1)로 정렬할 수 있으며 공간 고갈 시에는 무중단으로 재조정 할 수 있다.(한국어)
  • 기술 문서 사이트로 Docusaurus 활용하기 : Line내에서고 기술 문서의 규모가 커지면서 그때그때 다른 SSG(Static Site Generator)를 쓰게 되면서 공용 SSG를 선정하게 되었다. SSG를 선정하면서 웹 문서에 필요한 기본 기능이 충실하고 새로운 기능을 자유롭게 추가할 수 있어야 한다는 기준을 정하고 2세대 SSG 도구 중에 React 기반이면서 MDX도 지원하는 Docusaurus를 선정했다. 기술 문서에 필요한 기능을 추가하기 위해 줄 바꿈 테이블, 용어집, API 레퍼런스 기능을 만든 과정을 설명한다.(한국어)
  • Jetpack Compose로 LINE 앱 Yahoo!검색 모듈 개발하기 : Line에서 선언적 UI 툴킷인 Jetpack Compose를 도입한 과정을 설명한 글이다. 기존 앱을 운영하면서 도입해야 했기에 새로운 뷰에 도입하기로 하고 Composable에 도입하기로 조건을 걸고 선언적 UI를 위해 상태관리를 일원화하고 Composable을 stateless로 만들고 만든 Composable은 미리보기로 만들고 미리보기는 Pull Request에 포함하기로 하면서 Jatpack Compose 도입을 했다고 한다.(한국어)
  • Zed is now open source : GitHub의 Atom을 만들던 개발자가 나와서 만든 Zed 에디터가 오픈소스가 되었다. 오픈소스로 해야 최고의 제품이 될 수 있고 훨씬 더 재밌을 거로 생각해서 오픈소스로 공개했다고 한다.(영어)

인프라 관련

  • Maturing Istio Ambient: Compatibility Across Various Kubernetes Providers and CNIs : Istio의 사이드카 없는 버전인 Ambient Mesh를 구현하고 작년 알파를 출시해서 Ambient 모드의 가치를 입증하는 데 중점 했으나 초기 메커니즘이 다른 CNI와 충돌하는 것을 알게 되었고 사용자들은 어디서나 모든 CNI 구현에서 Ambient 모드를 원한다는 것을 알게 되고 베타버전으로 가기 전에 가장 중요한 요구사항이 되었다. istio-cni는 기본 CNI 구현이 아니고 클러스터의 기본 CNI를 확장하는 노드 에이전트인데 이 초기 구현이 기본 CNI 구현의 네트워킹 구성과 충돌이 발생하고 적용한 네트워크 정책도 상황에 따라 Istio CNI 확장에서 적용되지 않을 수 있어서 이 요구사항을 충족할 수 없다는 게 확실해졌다. 새로운 솔루션을 찾기 시작했고 사이드카를 모방하여 파드의 네트워크 네임스페이스에서 리다이렉션을 구성하는 아이디어가 나왔고 Linux 소켓의 기본 기능을 이용해서 다른 네임스페이스 내의 수신 소켓을 생성하고 소유할 수 있다는 걸 알게 되고 이를 구현하기로 했고 그 결과 모든 트래픽 캡처와 리다이렉션이 파트의 네임스페이스 내부에서 발생하고 마치 사이드카 프록시가 있는 것처럼 보이게 되었다.(영어)
  • GitHub-hosted runners: Double the power for open source : GitHub이 공개 저장소에서 사용하는 GitHub Actions은 무료로 제공하고 있었고 기존에는 2 vCPU 머신을 사용하고 있었는데 2023년 1월부터 Linux와 Windows의 러너를 새로운 4 vCPU, 16 GiB 메모리, 150 Gib 스토리지로 2배 업그레이드를 진행했다. 그 결과 기존보다 25% 속도가 빨라졌다고 한다.(영어)
  • Slashing Data Transfer Costs in AWS by 99% : AWS에서 가용영역(AZ)간에 데이터를 전송하면 비용이 발생한다. S3는 1a, 1b 같은 AZ 단위가 아니라 리전 단위로 버킷을 저장하므로 같은 리전에 모든 AZ에서 똑같이 사용할 수 있으며 (공용 인터넷이 아니라면) 다운로드와 업로드가 무료이며 스토리지 비용은 시간단위로 부과된다. 이 두가지 특징을 이용해서 1a에 있는 인스턴스에서 1b에 있는 인스턴스로 데이터를 보낼 때 직접 보내는 대신 S3를 거쳐서 보내도록 해서 비용을 절감하겠다는 아이디어이다.(전송후에는 S3에서 지워서 스토리지 비용을 아낀다) 직접 테스트로 1TB를 전송했을 때 직접 보내면 20.48달러가 청구되었지만, S3를 통해서 보낼 때는 8센트만 청구되었다.(영어)
  • 2023년 4분기 DDoS 위협 보고서 : Cloudflare에서 2023년 4분기 DDoS 위협 보고서를 공개했다. 여기서 나오는 DDoS 공격은 처리량보다 더 많은 요청을 보내는 HTTP 요청 집중형 DDoS, 라우터/방화벽/서버에서 처리할 수 있는 패킷보다 더 많은 패킷을 보내는 IP 패킷 집중형 DDoS, 인터넷을 포화 상태로 만드는 비트 집중형 DDoS 세가지 유형이 있다. 이전에 비해 HTTP DDoS 공격을 줄어들고 Network 계층의 DDoS 공격 증가하고 있다. 분야별 지역별 DDoS 위협을 살펴볼 수 있다.(한국어)

볼만한 링크

  • [리뷰] Q60MAX – 현존 최고의 HHKB 배열 기계식 키보드 : 키크론 Q60 MAX에 대한 리뷰입니다. HHKB 키보드 배열의 장점과 정적 용량 무접점의 특징까지 설명한 뒤 키크론 Q60 MAX가 기계식임에도 좋은 키감을 커스텀 키보드이면서 완성품으로 제공하기 때문에 편의성을 주면서 커스텀도 가능해진다. 글을 읽고 나서 사고 싶어졌다.(한국어)
  • 3일 후 운명이 결정되는 팔월드라는 우연한 이야기 : 요즘 스팀에서 인기라는 팔월드라는 게임이 만들어진 과정에 대한 이야기이다. 작은 게임 회사 입장에서 퍼블리싱이 어렵다는걸 깨닫고 스팀으로 발향을 돌리면서 여러 게임을 만들다가 팔월드라는 인기 게임이 나오기까지 편의점 알바생을 고용하고 게임엔진을 교체하고 모션 디자이너를 고용하고 탈락 시켰던 사람을 채용했는데 그 사람이 너무 잘하는 등 수많은 기적 속에 팔월드라는 인기게임을 만들게 되었다는게 그걸 기적으로 설명하는 부분이 현실감있고 재미있다. 일본어인데 번역해서 보면 읽을만 하다.(일본어)
  • Yes, good DevEx increases productivity. Here is the data. : 개발자 경험(DevEx)을 개선하는 것은 중요한 일이지만 그에 대한 데이터는 많지 않았는데 GitHub이 DX와 협업해서 생산성에 어떤 영향을 미치는지 연구했다. Slack 메시지 등 모든 방해 요소를 최소화해서 심층 작업(Deep Work)에 충분한 시간을 사용하는 개발자는 생산성이 50% 향상되고 코드에 대한 이해도가 높은 개발자가 아닌 개발자보다 생산성이 42% 높았고 피드백 루프가 중요하기 때문에 코드 리뷰가 빠른 등 처리시간이 빠르면 20% 더 혁신적이라고 느꼈다.(영어)

IT 업계 뉴스

  • Dave Mills has passed away : NTP(Network Time Protocol)을 발명하고 인터넷 아키텍처 테스크 포스의 초대 의장을 하는 등 인터넷 개발에 여러 가지 기여를 했던 Dave Mills가 지난 17일 85세의 나이로 세상을 떠났다고 인터넷의 아버지로 알려진 Vinton Cerf가 메일링 리스트의 부고를 전했다. 삼가 고인의 명복을 빕니다.(영어)
  • Supreme Court rejects Epic v. Apple antitrust case : Epic Games가 2020년 포트나이트에서 자체 결제시스템을 도입하자 Apple이 포트나이트를 앱 스토어에서 차단하면서 시작된 소송인데 대법원에서 두회사가 각기 제기한 청원을 기각함으로써 재판이 끝났다. 이 기각으로 애플은 앱 스토어에서 다른 결제 수단을 금지하는 것이 반경쟁적 행위라고 판단했으므로 애플은 다른 결제시스템을 허용해야 하게 되었고 Epic Games가 주장했던 다른 스토어를 통해서 iOS에 앱을 배포하도록 허용하도록 하는데까지는 실패했다.(영어)
  • Adobe Gives Up on Web-Design Product to Rival Figma After Deal Collapse : Figma 인수를 포기한 Aodbe가 Figma의 경쟁 제품인 Adobe XD를 유지 보수 모드로 전환하고 새 기능 추가도 안 하고 따로 판매도 안 할 생각이라고 발표했다. 2022년 XD의 연간 매출은 1,700만 달러였고 개발자는 19명뿐이었다고 한다.(영어)
  • Blue Oak Model License : Open Source initiative가 권한을 최대한 부여하고 기여자를 보호하는 Blue Oak Model 라이센스를 오픈소스 라이센스로 승인했다.(영어)

프로젝트

버전 업데이트

  • Terraform v1.7 : Infrastructure as Code 도구, 릴리스 공지
    • 1.6에서 추가된 테스트 프레임워크에 mock_provider가 추가되었다.

웹개발 관련

  • OROR Forge: Figma to Code 도구 제작기 (1) 디자인을 코드로 만들어보자!, (2) 실전용으로 만들기 : Figma로 된 디자인을 코드로 만드는 시간을 줄이기 위해 자동화 도구를 만드는 과정이다. 상용 Figma to Code 솔루션 중 Amplify Sudio와 Locofy를 살펴보면서 인상적인 기능이 있었지만, 각 한계점이 있었고 직접 만들기로 한다. 이 OROR Forge에서 Figma의 디자인을 픽셀 퍼팩트한 코드를 생성하기 위해 Figma의 Property, Auto Layout, Constraints, Text를 CSS의 Property, Flexbox, Postions, Text로 변환한 과정을 설명한다. 이를 실제 현업에서 활용하기 위해 인라인 스타일 대신 TailwindCSS를 사용하기로 하고 인라인 스타일을 TailwindCSS로 매핑하는 빌더 함수를 구현하고 HTML 코드고 React 컴포넌트로 변환해서 코드 생성을 자동화한 과정을 설명한다.(한국어)
  • How I'm Writing CSS in 2024 : Vercel의 Lee Robinson이 nesting, :has(), 컨테이너 쿼리 등의 크로스 브라우저 지원과 CSS 도구 등에 관한 생각을 정리한 글이다. 이제 최신 CSS 기능이 대부분의 브라우저에서 지원되면서 Sass나 Less 없이도 최신 CSS를 작성할 수 있지만 컴파일러를 사용해서 사용하지 않는 스타일을 줄이고 고유한 파일명을 생성해서 캐싱할 수 있다. 동적인 화면을 위해서는 CSS를 스트리밍해야 하는데 이를 위해서 CSS 모듈, Tailwind CSS, StyleX를 사용할 수 있다.(영어)

그 밖의 개발 관련

  • Rebuilding Netflix Video Processing Pipeline with Microservices : Netflix에서 2007년 스트리밍 서비스 출시 이후 동영상 처리 파이프라인을 개선해 왔다. 2014년부터 3세대 플랫폼인 Reloaded로 운영해 왔는데 모든 미디어 자산을 처리하는 모노리식 시스템으로 만들어졌기에 수년 동안 확장되면서 복잡도가 증가하고 한계가 드러나기 시작했다. 기능이 결합하여 있어서 기능 추가가 어려웠고 모노리식 구조로 재사용되지 않아야 하는 코드도 재사용되며 개발 속도를 늦추고 배포 규모가 커져서 프로덕션에 나가기까지 2주에서 4주나 걸리게 되었다. 그래서 2018년부터 차세대 플랫폼인 Cosmos를 개발하면서 Reloaded의 확장성과 안정성은 유지하면서 유연성과 개발 속도를 목표로 하면서 마이크로 서비스로 만들게 되었고 2023년 9월에 전환을 완료했다.(영어)
  • Python 3.13 gets a JIT : CPython 핵심 개발자인 Brandt Bucher가 Python 3.13에 copy-and-patch JIT을 추가하는 Pull Request를 올렸다.(현재 Draft 상태) 인터프리터는 실행할 때마다 opcode라 부르는 바이트 코드 이름을 if 문과 비교하는데 실행할 때마다 발생하는 오버헤드를 없애기 위해 시퀀스로 코드를 생성하는 것이 JIT이 하는 일이고 이번에 제안된 것은 copy-and-patch JIT이다. 인터프리터 루프는 해석한 뒤 실행하는 두 가지 과정을 거치는데 copy-and-patch JIT은 각 명령의 인스트럭션을 복사한 뒤에 바이트 코드 인수를 채우는(patch) 방식으로 진행된다. copy-and-patch JIT을 선택한 이유는 일반 Python 사용자가 이를 실행할 일은 없고 CPython을 빌드하고 패키징하는 CI 머신에서 LLVM JIT 도구만 설치하면 되기 때문이다. 초기 벤치마크에서는 2~9%의 성능 향상이 있는데 이 결과가 작아 보일 수 있으나 최적화 작업의 첫 단계로 생각하면 된다.(영어)

인프라 관련

  • Prometheus Vs Victoria Metrics Load Testing : Prometheus와 Vitoria Metrics의 성능 비교를 한 글이다. Prometheus는 압축할 때 active time series를 메모리에 저장하지만, Vitoria Metrics는 VM insert 스토리지에 저장하므로 이는 성계의 차이는 성능에도 영향을 준다. active time series, 수집률, 수집 대상의 수를 부하 테스트를 하면서 프로덕션에 운영하는 정도의 매트릭으로 둘을 비교하고 있다. 부하가 커지면 Prometheus는 메모리가 Vitoria Metrics는 CPU가 커지는 특징이 있지만 Vitoria Metrics에 최적화한 뒤에는 전체적으로 Vitoria Metrics 리소스 사용이 훨씬 적은 것으로 나타났다.(영어)
  • Announcing Builds View in Docker Desktop GA : Docker Desktop 4.26부터 빌드 뷰를 제공하기 시작했다. 빌드뷰를 통해서 실패한 빌드의 로그를 볼 수 있고 캐싱 여부도 확인할 수 있다.(영어)
  • Target CLI: The context switcher for HashiCorp tools : HashiCorp의 Senior Developer Advocate가 만든 Target CLI의 소개 글이다. HashiCorp에는 Terraform, Vault, Boundary, Consul, Nomad 등의 도구가 있지만 각 클러스터 간의 전환을 위해서는 환경변수를 세팅해야 한다. Target CLI는 이러한 컨텍스트 프로필의 전환을 쉽게 해주는 역할을 한다.(영어)
  • Deprecation Warnings in containerd - Getting Ready for 2.0! : containerd가 2017년 1.0 릴리스 이후 6년간의 개발을 통해 2.0가 나올 예정이므로 이를 준비하라고 알리는 글이다. ctr deprecations list 명령어로 사용량 기반으로 중단되는 기능을 확인할 수 있다.(영어)

볼만한 링크

  • The More Features You Add... : 여러 연구 결과에 따르면 사람들은 제품 사용 전에는 기능 수에 따라 품질을 판단하고 제품을 사용한 후에는 너무 많은 기능으로 사용성에 문제가 있다는 걸 깨닫게 된다고 한다. 제품의 시기에 따라 영업의 결과도 달라지는데 기업은 초기 매출을 극대화하기 위해 기능이 많은 제품을 개발하지만, 이후에는 고객 유지를 극대화하기 위해서 기능보다는 사용 편의성을 우선시해야 한다. 또한 기능이 많아지면 유지보수도 많아져서 속도도 느려지게 되므로 조심해야 한다.(영어)
  • Cloudflare Radar Year in Review 2023 : Cloudflare에서 자신들의 트래픽을 기준으로 리포트를 공개했다. 가장 많이 사용되는 인터넷 서비스와 iOS/Android 비중, API 클라이언트, 국가별 인터넷 품질, 모바일/데스크톱 비중 등을 확인할 수 있다.(영어)

IT 업계 뉴스

  • Introducing the GPT Store : 사람들이 많은 GPT를 확인할 수 있는 OpenAI GPT 스토어가 나왔다. 인기 많은 GPT를 확인할 수 있고 1분기 이내에 수익 프로그램을 출시해서 GTP 사용량에 따라 만든 사람한테 수익이 분배되도록 할 예정이라고 한다.(영어)

프로젝트

  • Tart : Apple Silicon 기반 macOS/Linux 가상화를 제공하는 서비스로 GitHub Actions, GitLab Runner, Buildkite 등의 러너로 사용할 수 있다.
  • OpenPubKey : OpenID 프로바이더에서 식별자를 공개키에 바인딩하는 프로토콜의 구현체
  • Minimalist CV : 간단한 정적 파일을 통해 이력서 페이지를 만들어주는 프로젝트.

버전 업데이트

HashiCorp의 공동창업자인 Mitchell Hashimoto가 얼마 전 Merge vs. Rebase vs. Squash라는 글을 작성했다.
Git에서 Merge, Rebase, Squash에 관한 질문을 자주 받아서 정리했다고 하는데 요약하면 다음의 내용이다.
  • 셋 중 특정 전략이 100% 정답이라고 말하는 사람은 틀렸고 각 전략은 상황에 따라 다르다.
  • Merge 커밋을 만드는 Merge가 히스토리를 가장 잘 표현한다고 생각해서 Merge를 선호한다.
  • Merge 커밋이 있으면 쉽게 되돌릴 수 있다.
  • 모든 커밋이 빌드된다면 커밋이 많을수록 git bisect가 좋아진다.
  • 이상적으로 커밋은 +50/-50 정도로 유지하는 것이 좋다.
  • PR에 많은 WIP 커밋이 있지만 하나의 목표라면 Squash를 한다.
  • Squash할 때 Git과 GitHub이 제공하는 기본 메시지는 좋지 않아서 Squash를 할 때 커밋 메시지를 새로 작성한다.
  • PR에 WIP가 많은데 각 커밋의 차이가 크다면 인터랙티브 Rebase로 커밋을 합치고 순서를 변경한다.
  • 개발자들이 커밋 관리에 신경 쓰기를 기대하지만, 많은 개발자가 Git에 익숙하지 않다.
  • 대규모로 인터랙티브 Rebase를 할 때는 Git GUI를 사용한다. macOS에서는 Tower를 쓰고 있다.
대부분의 내용을 공감해서 공유하면서 나는 어떻게 생각하고 있지를 고민하다 보니 그동안 개발을 하면서 내가 선호하는 방법도 다양하게 바뀌었다는 것을 깨달았다. 개발하면서 Git에 어울리게 쓰고 싶어서 한 것들도 있고 협업하다 보니내 취향과는 다르게 절충하게 된 것들도 있어서 트위터에서 글을 쓰다가 블로그에 정리하게 되었다.

Merge

Git을 배우면 처음에 Merge에 관해 배우기 마련이다. Git에서는 브랜치를 만들어서 작업하는 게 일반적이기 때문에 작업 후에 이 브랜치를 기본 브랜치에 합치는 Merge는 아주 중요하다.
notion imagenotion image
사용자 삽입 이미지
Merge하면 그래프가 위처럼 만들어지고 Merge branch '브랜치 이른'의 메시지를 가진 Merge 커밋이란 게 만들어진다. 이 그래프처럼 Merge 커밋이 있으면 작업할 때 브랜치가 분리되었다가 합쳐졌다는 게 시각적으로나 구조적으로 구분되고 히스토리에도 남게 된다.
물론 더 정확히 얘기하면 머지할 때 fast-forward 머지가 아닐 때만 이 머지 커밋이 생긴다. fast-forward 머지가 가능할 때는 머지커밋 없이 바로 생기고 fast-forward와 상관없이 머지 커밋을 만들려면 git merge --no-ff 옵션을 사용해야 한다.
초기에 Git을 배우고 익숙해지면서 주변 사람들도 Merge 커밋 선호자와 비선호자로 나뉘게 되었는데 나는 Merge 커밋이 좋은가? 안 좋은가를 많이 고민했다. 그래도 시간이 지나면서 머지 커밋을 안 남기는 것을 더 좋아하게 되었다.
notion imagenotion image
사용자 삽입 이미지
당시 내가 가장 좋아하던 Node.js 프로젝트는 Git 히스토리를 일직선으로만 만들었다. 당시 GitHub의 Pull Request는 무조건 --no-ff로 머지했기 때문에 항상 머지 커밋이 남게 된다. 그래서 머지커밋을 안 남기려면 Pull Request 브랜치를 로컬에 가져와서 fast-forward로 머지한 뒤에 이를 푸시하는 방식으로 머지해야만 가능했기에 메인테이너들이 아주 바빠지게 되지만 Node.js는 항상 이렇게 했다. 그래서인지 일직선으로 유지되는 히스토리가 더 멋지다고 생각했고 머지 커밋은 나한테는 불필요한 정보가 남는 걸로 보여서 장황하게 느껴졌다.
물론 브랜치를 나누어서 작업한다는 것이 보통 하나의 작업 단위가 되기 때문에 머지 커밋을 남기면 이 작업 단위에 커밋이 여러 개 있다고 하더라도 이를 분리해서 볼 수 있고 분리되어 있으므로 필요하다면 한꺼번에 revert 할 수도 있다. 머지 커밋이 없는데 revert 한다면 커밋을 일일이 찾아야 한다. 하지만 현실에서는 머지를 통째로 revert 하는 일이 많지 않기도 하고 머지를 통째로 revert 하기보다는 수정 커밋이 새로 올라가는 게 더 자주 있는 일이라고 생각했다.
혼자 할 때는 얼마든지 내가 원하는 대로 히스토리를 관리할 수 있지만 협업하면 얘기가 달라진다. 얘기했듯이 GitHub의 Pull Request를 사용하면 항상 머지 커밋을 남길 수밖에 없었다. Squash로 머지할 수 있는 기능은 2016년에 와서야 추가되었다.
그렇다 보니 머지 커밋을 싫어하는 내 취향과 관계없이 GitHub에서 협업할 때는 머지 커밋을 남기게 되었다. GitHub 사이트에서 머지 버튼 누르는 게 훨씬 편하고 모두가 Git을 잘 다루는 것도 아니니까 "머지는 버튼으로 안 하고 로컬에 받아서 fast-forward로 머지합니다"라고 할 수도 없어서 어쩔 수 없이 그냥 머지 커밋을 쓰게 되었다.

Rebase

Rebase는 Git의 아주 훌륭한 기능이지만 Git을 배울 때 가장 어려워하는 기능이기도 하다. 예전에 Git 강의를 할 때도 Rebase를 알려주는 게 나을지 고민을 정말 많이 하곤 했다. 처음부터 Rebase 익히지 않는 게 나을 수도 있지만 Git을 제대로 쓰려면 Rebase를 필수라고 생각하고 있긴 하다.
Git을 쓰면서 히스토리 관리를 중요하게 생각하는 편이라 코드 리뷰할 때 커밋 메시지도 리뷰하고는 했다. 영어를 잘하는 건 아니니까 커밋 메시지의 문법을 보는 건 아니지만 WIP 라던가 아무 의미 없는 커밋 메시지를 가진 커밋이 쌓이는 건 싫어했다.
내가 커밋할 때도 Pull Request를 올리면서 모든 커밋은 인터랙티브 Rebase로(git rebase -i)로 히스토리를 다시 정리했다. 작업을 하면서 A-B-C 순으로 작업을 하는데 놓친 부분이나 수정할 게 생기면 A-B-C-A'-B'-A''-C' 형태로 커밋 히스토리가 복잡해 지는 게 인터랙티브 Rebase를 써서 순서를 바꾸고 커밋을 합쳐주면 다시 A-B-C 처럼 만들 수 있다.(--fixup 와 --autosquash를 쓰면 편하다.) 그래서 결과적으로 보면 처음부터 모든 경우를 고려해서 순서대로 작업한 것 같은 히스토리가 만들어지게 되는데 커밋 메시지는 모든 작업 과정을 다 담는 것이 아니라 나중에 이해할 수 있게 정리된 히스토리여야 한다고 생각하기 때문이다.
notion imagenotion image
사용자 삽입 이미지
머지에서 피곤하게 느낀 건 위와 같은 상황이었다. Pull Request를 올리려고 작업을 하다 보면 작업 시간이 몇 시간에서 며칠이 걸리기도 하니까 다른 사람들의 작업도 기본 브랜치에 머지되면서 브랜치의 각 커밋이 흩어지게 된다. Git 도구를 쓰면 못할건 아니지만 머지 커밋은 상단에 바로 보이지만 그 브랜치에서 진행된 커밋을 보려고 하면 저 아래에 있어서 보기 쉽지 않은 게 싫었다. 당연히 협업자가 많으면 머지 커밋은 더 많이 생기고 히스토리는 복잡해진다.
notion imagenotion image
사용자 삽입 이미지
이 문제를 해결하려면 Rebase를 하면 된다. 머지 하기 전에 Rebase를 하면 기본 브랜치를 대상으로 커밋을 다시 하게 되므로 자연히 커밋이 모이게 되고 이후에 머지를 하면 머지 커밋과 해당 브랜치의 커밋이 한 곳에 모이게 된다.
하지만 이것도 위에 Rebase로 커밋 히스토리를 정리하자는 것과 같은 상황이기 때문에 나 혼자서는 지킬 수 있는 규칙이지만 협업할 때 모두가 이렇게 하라고 하는 건 어려운 문제가 된다. 그래서 처음에는 Rebase 요청이나 커밋 히스토리에 대한 정리에 대한 요청도 많이 하곤 했지만, 시간이 지나면서 점점 커밋 히스토리를 너무 신경 쓰지 않으려고 노력하게 되었다.
Pull Request에서 Rebase를 적극적으로 사용하지 않게 된 이유가 또 하나 있는데 코드 리뷰 때문이었다. 예를 들어 변수명에 오타가 있다가 있다고 코드 리뷰를 받았을 때 이를 수정해서 올리면 새로 올라온 커밋만 보고 리뷰대로 오타가 수정되었구나!' 할 수 있다. 하지만 내가 이걸 수정한 다음 인터랙티브 Rebase로 커밋을 원래 커밋에 다시 합친 뒤에 force push를 하면 리뷰한 사람 입장에서는 전체 diff를 다시 보면서 제대로 수정되었는지 확인하기가 쉽지 않아진다. 내가 가진 Rebase 습관이 Git 관점에서는 맞는다고 생각하지만, 협업 관점에서는 오히려 문제가 되기 때문에 Rebase를 너무 적극적으로 안 하기 시작했다.

Squash

GitHub Pull Request가 Merge 커밋을 남기게만 동작하다가 2016년 4월에 Squash and merge 기능이 나오고 2016년 9월에는 Rebase and merge가 나왔다.
Squash는 Pull Request의 모든 커밋을 합쳐서 하나의 커밋으로 만드는 기능이고 Rebase는 타겟 브랜치를 기준으로 모든 커밋을 다시 커밋(rebase)해서 fast-forward 머지가 가능한 상태로 만든 뒤에 머지하는 기능이다. Rebase and merge는 앞에서 말한 대로 내가 기다리던 기능이었기 때문에 나는 이쪽을 더 선호했고 그 덕에 커밋 히스토리를 한 줄로 만들 수 있게 되었다. 하지만 여전히 Pull Request에서 코드 리뷰와 관련해서 불필요한 커밋을 남길 수밖에 없는 문제는 해결되지 않았다.
notion imagenotion image
사용자 삽입 이미지
그런 고민을 하던 중 지인이 자기 팀에서는 Squash를 기본으로 사용한다는 것을 알고 Squash에 관심을 가지게 되었다. Squash를 사용해 보면서 팀 단위로 협업할 때는 Squash를 선호하게 되었다.(여전히 개인 프로젝트에서는 Rebase and merge를 선호한다.) 아까 말한 대로 머지 커밋을 사용하지 않을 수 있으면서 코드 리뷰를 위해 Pull Request 브랜치에서는 히스토리 조정을 하지 않고 머지할 때는 하나의 커밋으로 합쳐서 최종 히스토리는 깔끔하게 유지할 수 있다. 협업 때 규칙을 합의 보고 지키기 위해서는 규칙이 너무 복잡하지 않아야 하는데 그런 부분에서도 Squash는 장점이 많다. 가끔 까먹을 때도 있지만 Squash로 합칠 때 커밋 메시지는 다시 조정하는 편이다. 안 그러면 커밋 메시지에 Pull Request에 포함된 모든 커밋 메시지가 다 포함된다.
더군다나 Pull Request의 변경 사항을 너무 크게 만들지 않게 하는 데도 유용하다. 기본적으로 코드 리뷰를 원활하게 하기 위해서는 Pull Request의 변경 사항은 너무 크지 않아야 한다. 그동안 Rebase로 히스토리 조정을 많이 해오면서 두 가지 목적의 작업은 거의 한 커밋에 안 섞는 편이다. 코드 수정을 하다가 리팩토링 할게 보인다거나 컨벤션 일부를 수정해야 해서 스타일 설정 파일을 수정해야 한다고 했을 때 이 부분만 따로 작업해서 Pull Request를 올리고 기능 추가나 버그 수정은 해당 변경 사항만 담기도록 노력하고 있다.
그렇기에 Squash를 기본 규칙으로 가게 하면서 하나의 커밋(Pull Request 내에서는 여러 커밋이 있지만 결국은 하나로 합쳐지므로)에는 너무 많은 변경 사항이 담기지 않도록 서로 노력하는 게 더 쉬웠고 문제가 생겼을 때 Revert 할 단위도 커밋 단위로 만들 수 있게 되었다. 결국 Pull Request 하나가 하나의 원자적 단위가 되는데 Mitchell Hashimoto 말대로 모든 커밋이 빌드할 수 있어야 하는 건 중요하고 그래야 어느 커밋으로도 되돌아갈 수 있는데 Pull Request에서 모든 커밋에서 CI를 다 돌리진 않지만, Squash로 한다면 모든 커밋에서 CI가 통과했다는 보장을 할 수 있게 된다.
Pull Request를 잘게 쪼개는 건 아주 중요하고 이건 연습이 좀 필요하다고 생각한다. 코드 리뷰를 한다는 것은 언제 머지될지 모른다는 얘기가 되므로 Pull Request를 쪼개기 시작하면 Pull Request를 올려두고 이어진 작업을 하기 위해 이전 Pull Request가 필요하게 된다. 이를 Stacked Changes 혹은 Stacked Pull Request라고 부른다. 나는 손이 느려서 그런지 예전부터 쪼개는 것에 익숙해져서인지 Stacked Pull Request는 잘 사용하지 않지만, Stacked Pull Request가 필요하다면 Graphite같은 서비스도 도움이 된다. 관련한 도구에서는 제일 잘 만들지 않았나 싶다.
Response : No Trackback , No Comment
Trackback URL : 이 글에는 트랙백을 보낼 수 없습니다

Leave a Reply

Name *
Password *
Website Address
secret
Your comment
AWSKRUG 플랫폼엔지니어링 모임에서 "당근 개발자 플랫폼은 어떤 문제를 해결하고 있는가?"라는 제목으로 발표했다. 현재 당근마켓 SRE팀의 딜리버리 파트에서 배포 시스템을 시작으로 해서 사내 개발자 플랫폼(IDP, Internal Developer Platform)을 만들고 있다.
플랫폼 엔지니어링을 목표로 했다기 보다는 배포 시스템을 만들고 이를 플랫폼으로 발전시키면서 고민하다 보니 어느 순간 플랫폼 엔지니어링이라는 개념을 만나게 되었다. 사실 플랫폼 엔지니어링은 지난 십여 년간 IT를 이끈 빅테크 기업인 Google이나 Netflix 등에서 적용했던 방법이 이제 업계로 나오고 있는 거라고 생각하고 있다.
플랫폼 엔지니어링이란 개념을 너무 팔면 약 파는 기분도 들고 해서 조심하긴 했지만 그래도 관련한 일을 계속하면서 고민하고 있다 보니 하는 일에 관해서 지난 3년간 여러 번의 발표를 했다.
플랫폼 엔지니어링 관련 글은 웬만한 건 다 찾아봤다고 생각하고 있지만 또 혼자 공부하면서 이해하고 해석했기에 지난 11월 AWSKURG에서 플랫폼엔지니어링모임이 생겼길래 참석했다. 팀 내에서는 여러 번 얘기하고 했지만, 내가 해석하고 이해한 거였기 때문에 다른 회사, 다른 사람들은 플랫폼 엔지니어링을 어떻게 보고 있는지 궁금해서 참석했다. 그렇게 참석했다가 그 자리에서 다음 밋업의 발표를 제안받고 발표를 하게 되었다.
다른 콘퍼런스나 세미나보다는 점 격식 없으면서 시간 여유도 있는 편이라 이전에 못 했던 얘기를 할 수 있을 거로 생각했다. 그동안의 발표는 제한된 시간에 주제에 맞게 전달하려다 보니 개념적으로 정리해서 얘기한 게 많았다. 결국 같은 얘기이긴 하지만 저번 밋업에서 끝나고 질문을 받으면서 지난 3년간 사내 개발자 플랫폼을 만들면서 어떤 상황에서 어떤 고민을 하면서 만들었는지는 좀 더 그대로 이야기하는 것도 도움이 될 것 같다고 생각했다.
결국 발표이긴 하니까 어느 정도 정리가 필요하기는 하지만 넉넉한 시간을 이용해서 그때의 상황과 어떤 고민을 하고 어떻게 플랫폼을 만들면서 발전해 왔는지를 공유하고 싶었다. 그렇게 발표 자료를 만들다 보니 장표가 113 페이지나 나왔다. 그래도 실제로 했던 얘기를 풀어나가는 거라서 이전에 했던 다른 발표보다 크게 힘들거나 하진 않았고 오히려 다시 정리하다 보니 "그때 그런 생각을 했었지", "맞다. 그때 그랬었지"하는 생각도 나서 재밌었다.
장표가 113페이지가 되니 분량이 잘 가늠이 안 되어서 평소와 달리 발표 연습은 하지 않았다. 발표 시간이 명확하게 정해져 있진 않았고.. 그래도 평소의 발표 경험이 있다 보니 90분이 넘진 않겠느냐고 했는데 실제로 하니까 쉬는 시간 포함해서 딱 90분에 발표가 끝났다.(화면 연결을 제대로 준비하지 못해서 발표자 노트가 내 맥북에 나오지 않아서 열심히 적어놓은 내용을 기억으로만 발표해야 해서 좀 아쉬웠다. ㅠ) 끝나고 질문도 많이 나와서 질문/답변만 30분을 했다. ㅎㅎ
이전에도 발표하면서 참석자들이 꽤 있었지만 그래도 아직 플랫폼 엔지니어링은 아직 마이너한 주제라고 생각하고 있었다.(물론 난 인프라팀의 방향에서 이 방향이 맞는다고 생각하고 있다.) AWSKRUG에서 발표하는 건 처음인데 아무래도 인프라에 관심 있는 분들이 많아서 그런지 밋업치고는 상당히 많은 210명 정도가 참석해 주셔서 "어라? 플랫폼 엔지니어링에 관심이 언제 이렇게 커졌지?"하는 생각마저 들었다.
90분 발표란 게 듣는 입장에서 쉽지 않은데 많은 분이 그래도 재밌게 들어주신 거 같아서 준비하는 과정이나 발표나 꽤 즐거운 시간이었다.

웹개발 관련

  • Renovate Web E2E tests with Playwright Runner : Mercari에서 기존 E2E 테스트에 Jest-Playwright를 사용하고 있었다. 실행은 CircleCI에서 했기 때문에 CircleCI에서는 코드 실행만 하고 Moon이라는 프로젝트를 이용해서 내부 네트워크의 브라우저와 연결해서 테스트를 실행했다. 하지만 Jest-Playwright가 이제 지원 속도가 느려지기 시작했고 Moon을 통해 브라우저를 원격으로 연결하면서 재시도도 어렵고 최종 보고서에도 누락되는 문제가 있었다. Jest-Playwright 대신 Playwright를 사용하기로 하고 내부에 CI를 위한 러너를 제공해서 원격 브라우저 연결을 없앤 형태로 개선했다. 마이그레이션을 끝내기까지 6개월 정도 걸렸고 기존 E2E 테스트는 그대로 두고 새 저장소를 만들어서 테스트 케이스를 업데이트하면서 마이그레이션 했다.(영어)
  • 크롬에서 서드 파티 쿠키를 폐기하기 위한 다음 단계 : 웹사이트에서 서드파티 쿠키에 접근하는 것을 차단해서 사이트 간 추적을 제한하는 추적 보호 기능을 Chrome이 1월 4일부터 테스트한다. 전체 사용자 중 임의의 1%에만 먼저 적용되며 테스트 대상이 되는 사용자는 알림을 받게 될 예정이다.(한국어)

그 밖의 개발 관련

  • How to Git Stash a Specific File: A Step-by-Step Guide : 임시로 변경 사항을 저장할 수 있는 git stash에서 특정 파일만 stash하고 싶을 때가 있는데 git stash push로 특정 파일이나 디렉터리를 stash하는 방법을 설명한다.(영어)

인프라 관련

  • Platform Engineering at Mercari : Mercari에서 플랫폼 엔지니어링을 하면서 배운 내용을 정리한 발표 자료다. 내부 플랫폼 만들면서도 비즈니스가 최우선 가치이고 플랫폼을 지속해서 개선해야 하는 제품처럼 다뤄야 하며 개발팀과 협업해서 효과적으로 우선순위와 기능을 고를 수 있게 하면서도 적당한 거리를 두어 X-as-a-Service가 되도록 해야 한다. 그리고 플랫폼 엔지니어링은 마이그레이션을 항상 동반해야 제대로 효과를 볼 수 있다.(영어)
  • Open source log monitoring: The concise guide to Grafana Loki Part 1, Part 2, Part 3 : Grafana의 로그 수집 도구인 Loki 5주년을 맞이하여 Loki의 개념과 함께 그동안 어떻게 발전해 왔는지 설명하는 3편의 글이다.(영어)
    • Loki는 "로그 스트림을 정의하는 Prometheus 스타일의 레이블"을 작은 인덱스로 구축하도록 설계되어 이를 LogQL로 질의한다.
    • Loki는 높은 카디널리티 레이블값을 지원하도록 설계되지 않았고 오히려 그 반대로 수명이 아주 길고 매우 낮은 카디널리티의 레이블을 위해 구축되었으므로 레이블 수가 적을수록 좋다.
    • 레이블의 키-값 쌍을 통해 Ingester에 샤딩되는데 특정 Ingester에 몰리지 않도록 자동 스트림 샤딩을 도입했다.
    • Pod 이름 등 카디널리티가 높은 값을 조회하는 문제를 해결하기 위해 그동안 카디널리티가 1시간의 10만 개 미만의 스트림이라면 색인화하고 이 이상이라면 Promtail의 pack 단계에서 로그 라인에 카디널리티를 포함했다. 3.0에 정식으로 포함될 structured metadata를 사용하면 키-값 쌍을 인덱스가 아닌 로그와 함께 저장할 수 있게 되었다.
    • 고유 ID를 검색하는 일이 일반적인 사례라는 것을 깨닫고 Bloom filter를 도입했다.
    • 쿼리를 실행할 때 먼저 쿼리를 더 작은 시간 세그먼트로 분할하고 이를 처리할 양에 따라 샤드로 분리해서 작업 큐에 배치한다.
    • 성능 문제를 해결하기 위해 max_concurrent를 보통 8 정도를 권장하고 문제가 된다면 더 줄이길 권한다. 보통 수직 스케일링보다는 수평 스케일링을 더 권장한다.
    • tsdb_max_query_parallelism와 split_queries_by_interval로 병렬 처리를 조정할 수 있다. 테넌트가 수집하는 데이터가 많으면 더 많은 병렬처리를 할 수 있다.
    • 모든 쿼리에 metrics.go라는 로그 행을 생성하고 여기에는 실행된 쿼리의 다양한 통계가 있으므로 metrics.go를 조회해서 슬로우 쿼리 등을 찾을 수 있다.
  • How Meta built the infrastructure for Threads : 23년 7월에 런칭한 Threads가 5일 만에 1억 명의 사용자가 가입했는데 이때 이 인프라를 책임진 두 가지 요소를 설명한다. 기존에 앱 출시를 고려했지만, 실제 출시는 결정 후 2일 만에 출시해야 했고 기존에 인프라 성숙도에 대한 믿음이 있었기에 할 수 있었다.(영어)
    • ZippyDB는 분산형 키-밸류 디비로 Meta에서 완전 관리형으로 운영되며 Meta의 인프라를 활용하도록 구축되었다. ZippyDB의 리샤딩 프로토콜을 사용하면 일관성/정확성을 보장하면서 다운타운 없이 수평적 샤딩를 늘릴 수 있고 기존 사용에서 100배가 증가하더라도 문제없도록 리샤딩을 계속 개선해 왔다.
    • XFaaS라고도 부르는 Async는 서버리스 함수 플랫폼으로 엔지니어가 프로덕션 배포까지 걸리는 시간을 줄일 수 있도록 지원하며 HackLang, Python, Haskell, Erlang 등의 언어를 지원한다. Async는 Instagram에서 이미 팔로우 중인 사람을 Threads에서도 팔로우하도록 하는 기능에 중요한 역할을 했고 5일 만에 1억 명의 사용자에게 이 기능을 제공하려면 상당한 처리량이 필요했지만, Async가 이를 잘 처리했다.
  • Ending Support for the Dagger CUE SDK : CI/CD 파이프라인인 Dagger의 초기 버전은 구성 언어인 CUE를 사용했지만 이후 GraphQL API를 도입하면서 다양한 프로그래밍 언어로 Dagger를 사용할 수 있도록 추가되었다. 이후 CUE용 SDK의 사용이 크게 줄어들었고 23년 12월 14일부터 CUE SDK 지원을 중단하기로 했다.(영어)

볼만한 링크

  • End of Year Pay Report 2023 : 테크 기업의 연봉을 비교해 주는 levels.fyi에서 2023년 통계 보고서를 공개했다. 2023년에 비해서 연봉 인상률의 추세를 비교해서 보여주고 레벨별 높은 연봉을 주는 회사와 각 중위 연봉을 확인할 수 있다. 참고로 미국에서의 연봉 공개는 연봉에 주식 등도 포함되어 있을 수 있어서 참고해서 봐야 한다.(영어)
  • Run a Node project with Deno and win prizes in the #NodeToDenoChallenge : Deno에서 Node.js 프로젝트를 Deno로 실행해 보는 #NodeToDenoChallenge 를 시작한다. 1월 4일까지 Node.js 프로젝트를 Deno로 실행하고 결과를 스크린샷으로 올려서 참가할 수 있다. 이는 그동안 Node.js 호환성을 높이는 작업에 대한 자신감을 보여주면서 Node.js 사용자가 Deno를 사용해 보도록 하는 의미로 보인다.(영어)

IT 업계 뉴스

프로젝트

  • SSH3 : QUIC과 TLS 1.3을 이용해서 더 안정적으로 통신하도록 만든 SSH 프로토콜
  • Suno.ai : 프롬프트를 입력하면 AI가 음악을 생성해 주는 서비스
  • Stirling-PDF : PDF를 합치거나 나누는 등 PDF를 조작하는 다양한 기능을 할 수 있는 웹 애플리케이션으로 로컬에 직접 띄울 수 있다.

버전 업데이트

  • Vue.js v3.4 Slam Dunk : 자바스크립트 UI 라이브러리, 릴리스 공지
    • 2배 빨라진 새로운 템플릿 파서
  • Nuxt.js v3.9.0 : 서버렌더링 Vue.js 애플리케이션 프레임워크, 릴리스 공지
    • Vite 5와 Rollup 4 지원

회사

당근마켓에 다닌 지 3년이 넘었고 어느새 내가 다닌 회사 중에 두 번째로 오래된 회사가 되었다. 사실 2년 이상 다닌 회사는 당근마켓 포함해서 딱 2개밖에 없긴 하다. 가장 오래 다닌 회사가 3년 5개월을 다녔으니 큰일이 없으면 내년 중에 가장 오래된 회사가 될 것 같다.
SRE팀에서 딜리버리 파트로 일하면서 3년 내내 내가 하는 일은 영역만 넓어졌지 계속 똑같다. 어느새 파트는 2명에서 6명이 되었고 SRE팀도 16명으로 아주 큰 팀이 되었다.
3년째 배포 시스템을 만들고 있는데 여전히 도전적이고 재미있는 도메인이라는 생각이 든다. 배포 시스템이 사내 플랫폼 역할을 하면서 고민할 건 더 많아졌지만, Kubernetes도 점점 이해하고 플랫폼 엔지니어링도 공부하면서 차근차근 나아가고 있다. 사내에서도 어느 정도 사내 플랫폼이 자리 잡고 인정받는 부분도 있어서 동기 부여도 많이 되고 지금까지는 꽤 잘 해내고 있다고 생각한다. 물론 초기에는 기능 구현 등에서 명확하다고 생각하는 게 많이 있었는데 기능이 많아지고 고도화되면서 점점 어느 쪽 방향으로 가야 하는지 고민되는 일이 많아지고 있지만 국내에서 어디 가도 부럽지 않을 만큼 좋은 SRE팀이라고 생각하고 협업하는 것도 즐겁고 업무 몰입도도 높은 편이라 만족스럽다.
작년 회고에서도 얘기했듯이 리드이긴 하지만 매니징을 많이 하고 있다고 생각하진 않는다. 동료들이 적극적으로 고민하면서 일해주기 때문에 점점 내가 관여하는 부분도 줄어들고 있다. 올해는 인프라실 내 지원 업무도 늘어나서 미팅이나 딜리버리 파트 외의 업무가 많아지긴 했다. 우리 파트 업무는 잘 돌아가고 있긴 하지만 가장 밀접한 우리 파트와 보내는 시간이 줄어들어서 좀 걱정된다.
notion imagenotion image
사용자 삽입 이미지
이제 파트도 총 6명이 되었고 직접 작업하는 시간은 많이 줄어들었다.
notion imagenotion image
사용자 삽입 이미지
큰 기능은 대부분 나눠주고 지원 업무나 내가 좀 전체적으로 파악해야 할 일 위주로 내가 하고 있다. 큰 방향성과 각 기능에서 전체적인 방향에 대한 논의에 주로 참여하고 세세한 부분은 개별 작업자가 알아서 하고 있어서 나는 주로 팀이 잘 돌아가게 지원해 주는 역할을 하고 있다. 하루에 Pull Request 리뷰를 한 번도 못 하는 날도 늘어갔는데 그래도 시간이 날 때 최대한 리뷰에 참여해서 릴리스 속도가 느려지지 않도록 지원하고 있다. 그래도 아직은 내가 전혀 모르는 작업 내용이 배포되거나 하진 않는다.(설사 늦게 볼지라도...) 아직까진 리드와 현업의 간격이 괜찮다고 느끼는 편인데 여기서 협업과 더 멀어지면 내 역량으로 할 수 있을지 자신이 없어서 이 간격을 최대한 유지하는 중이다.
올해는 어쩌다 보니 Kubernetes CPU의 사용량 추적 및 최적화가 내 업무에 큰 부분을 차지하게 되었는데 2023년에 CPU 스케줄링을 고민하고 있을 줄은 몰랐지만, 연초보다는 훨씬 이해도가 올랐지만, 여전히 이해 못 하는 부분이 많다. 너무 궁금한데 원래 잘 아는 영역도 아니고 CPU 스케줄링 커널 소스를 까본다고 알 수 있을 것 같지도 않아서 증상과 가설을 통해서 지식을 넓혀가고 있다. 어디 잘 정리된 글이 없나 싶은데 가벼운 내용의 글은 많지만, 자세히 설명된 글은 많지 않다. 이해 안 될 때는 너무 답답하지만, 개발이 다 그렇듯이 그러다가 이해하기 시작하면 또 재밌고 그렇다.

코딩/블로그

올해는 글을 많이 쓰는 대신 코딩을 거의 못 했다. 올해는 뭔가 집에 오면 좀 늘어져 있고 싶었던 적이 많아서 집에 오면 OTT를 보면서 쉬는 경우가 많다 보니 절대시간이 부족해서 글을 많이 쓰니까 대신 코딩을 별로 못했다. 이것저것 하고 싶은 건 많았지만, 절대시간이 줄어드니 어쩔 수 없긴 하다. 한해 쉬었으니, 내년에는 사이드 프로젝트나 오픈소스 기여를 할 수 있기를 기대하고 있다.
notion imagenotion image
사용자 삽입 이미지
올해는 이 회고 글까지 포함하면 57개의 글을 썼는데 작년 68개 보다는 적지만 나름 만족할 정도로 글을 썼다. 그리고 RetroTech 팟캐스트를 개인적으로 시작했다. 이 팟캐스트는 작년부터 생각한 것이고 팟캐스트이긴 하지만 대본 작성하느라고 나한테는 글을 쓰는 작업이나 다름없고, 올 2월부터 준비해서 총 8개의 에피소드를 올렸는데 아무리 작게 잡아서 글의 분량이나 들인 시간을 생각하면 한 에피소드에 블로그 글 3~4개 정도의 시간을 들었기 때문에 이 팟캐스트까지 포함하면 글 쓰는데 시간을 많이 쓰긴 했다.
물론 첫 주제로 골랐던 JavaScript 프레임워크를 8 에피소드나 녹음하면서 올해 내에 끝내지 못할 줄은 생각하지 못했다. 올해 내에 끝내고 다음 주제로 넘어가고 싶었는데 아쉽지만 어쩔 수 없다. 미리 준비해 둔 대본도 있어서 5편 정도는 2주마다 정기적으로 올리면서 목표로 잡았지만 2주마다 올리는 게 너무 힘들어서 조금씩 길어지면서 지금은 비정기적으로 끊기지 않고 올리는 게 목표로 바뀌었다. 약간 힘들긴 하지만 예전에 몰랐던 상황도 알게 되면서 꽤 재미있긴 하다.
처음에 시작할 때도 많은 사람이 들을 팟캐스트라고 생각하진 않았지만 또 막상 힘들게 준비했는데 구독자가 많지 않으니 아쉽긴 하다. 한편 올리면 한 50명 정도 듣는 거 같다. 구독자 수 신경을 안 쓰고 해야지 생각하고 있지만 그래도 노력이 많이 들어가니까 많이 들어줬으면 하는 바램도 있긴 하다.(재밌게 말해야 하는데 내가 말하는 거니 감이 없어서 모르겠다. ㅠ)
그리고 작년에는 열심히 못했는데 올해는 44BITS 팟캐스트도 열심히 했다. 우리가 올해 24편을 녹음했는데 그중에 23편에는 참석했으니 나름 열심히 했다고 할 수 있다. 그리고 이전에는 녹음 날짜와 업로드 날짜의 차이가 너무 나서 듣는 분들이 힘들었을 텐데 (길 때는 6개월까지...) (내가 하는 건 아니지만) 이제는 녹음하면 며칠 내에 업로드가 되고 있어서 녹음하는 재미도 더 커졌다.
notion imagenotion image
사용자 삽입 이미지
RescueTime에서는 어차피 사용한 시간 대비니까 여전히 72% 정도는 생산성인 시간에 쓴 거로 나온다.(OTT를 맥북으로 보진 않으니까...) 그래도 작년대비 1,500시간 정도의 컴퓨터 사용량이 줄어든 걸 보면 확실히 컴퓨터 앞에 훨씬 덜 앉아있긴 했다. RescueTime이 유료라 회사 맥북도 같이 물려뒀더니만 얼마나 수집되었는지 헷갈리지만, 데이터가 섞여서 오히려 통계 보기가 안 좋은 거 같다. 회사는 따로 추적해 보고 싶긴 한데 또 결제하긴 그렇고(통계 때 분리해서 보고 싶은데 ㅠ) 내년엔 회사 장비는 빼야겠다.
notion imagenotion image
사용자 삽입 이미지
wakatime도 올 초부터 결제해서 쓰고 있다.(이런 기록에 집착하는 편이다.) 이건 개인 장비에만 연결된 데이터이다.
notion imagenotion image
사용자 삽입 이미지
아까 말한 대로 코딩은 거의 안 하고 글을 썼기 때문에 Sublime Text만 잡혔다. 나는 Sublime Text에서 보통 글을 작성하고 여기서는 코드 작성은 전혀 하지 않는다.
올해부터는 Google Analytics 4로 바뀌면서 통계 수치도 달라지고 뭔가 사용하기 어려워졌지만, 페이지뷰 기준으로 올해 많이 조회된 글이다.
아래는 올해 쓴 글 중에서만 페이지뷰가 높은 10개를 뽑아봤다.
발표는 회사 밋업까지 포함해서 3번 했다. 1월 초에도 발표가 하나 있어서 준비해야 하긴 하는데 내년 일을 내년에 해야지 하고 일단 머릿속으로만 정리 중이다.

공부

올해는 총 12권의 책을 읽었다. 더 많이 읽고 싶었지만, 책을 느리게 읽는 편이라 많이 읽지는 못했다.
내가 좋아하는 인프라 스터디에서는 Observability Engineering를 같이 읽었는데 이 스터디는 멤버도 좋고 오래 지낸 사람들이기도 해서 스터디를 하면서 배우는 게 많다. 그래서 더 어려운 주제로 선택하게 되는 거 같기도 하다. 평소에 리더십 책을 많이 읽는 편은 아닌데 동료들과 리더십 책 모임을 하면서 올해는 리더십 관련 책을 몇 권 읽게 되었다. 지나서 보면 개발자에게 물어보세요 - 디지털 공급망으로 조직의 핵심 역량 구축하기가 제일 재밌었다.
난 비소설만 읽는 편이고 그중에서 대부분이 개발 관련 책만 보기는 하는데 올해는 소설도 좀 읽고 싶어졌다. 이 블로그가 개발 블로그라서 후기를 올리진 않았지만, 동료에게 추천받은 프로젝트 헤일메리를 읽었는데 너무 재밌고 감동적이었다.(눈물 나올 뻔) 그리고 워낙 유명한 소설인 눈물을 마시는 새 1권을 봤다. 문득 어렸을 때 재밌게 본 영웅문을 다시 읽어보고 싶다는 생각이 들었는데 다시 읽기엔 시간이 오래 걸릴 테니 고민하다가 이영도 작가의 드래곤 라자를 재밌게 본 기억이 나서 그 유명한 눈물을 마시는 새를 봤다. 아직 1권만 봤는데 오랜만에 보는 소설들이 꽤 재미있다. 내년에도 많이는 아니어도 소설은 약간씩은 읽어 보려고 한다.
내 삶은 엄청 루틴한 편이라 올해도 무난하게 만족하면서 보낸 한해인 것 같다. 출근을 일주일에 3일만 하고 있고 다른 회사도 재택하는 회사들도 있다 보니 확실히 예전보다는 사람들을 많이 만나진 않는 것 같다. 작년에도 건강관리에 관해 썼지만 이제 수영도 시작했으니, 건강관리도 하면서 한 해를 보내야겠다.

새해 복 많이 받으세요.

비밀번호 관리 서비스인 1Password는 2022년에 1Password Developer Tools를 런칭하고 SSH와 Git의 비밀키 관리 기능도 추가하면서 사용자의 비밀번호 관리뿐만 아니라 시스템이나 개발자의 보안을 유지할 수 있는 기능도 추가하고 있다.
작년인가 1Password의 Connect Server를 보고 이를 이용해서 서비스에서 시크릿 보관소로 쓸 수 있을지 궁금했던 기억이 있다. 테스트해 봐야지 하고는 아직 못하고 있었다.
최근 GitHub Universe에서 1Password 부스를 구경하다가 1Password Developer Tools에 Service Accounts라는 기능이 나왔다는 것을 알게 되었고 내가 올해 고민하던 문제의 해결책이 될 수 있겠다는 생각에 살펴봤다.
내가 생각하는 문제는 보통 로컬에서 개발 환경을 구성하기 위해서 다양한 시크릿 정보를 환경 변수에 저장해 놓고 사용하게 되고 direnv나 그 외 환경변수 관리 도구를 쓴다고 하더라도 일반적으로 이 정보는 로컬에 보통 평문으로 저장되어 있다. 개발 환경이긴 하지만 상황에 따라선 프로덕션용 시크릿이 보관되어 있을 수 있다. 물론 컴퓨터의 자체 보안이 있고 노트북을 잃어버려도 보통 암호가 걸려있어서 암호가 풀린 상태로 다른 사람에게 노트북을 주거나 공격자에게 침투당하는 상황까지 고려하는 것은 아니지만 파일을 복사하거나 백업하면서 실수로라도 이러한 시크릿이 유출될 가능성이 높다는 것이었다.

1Password Service Accounts

1Password Service Accounts는 올 6월에 퍼블릭 베타로 공개된 기능이고 지금은 베타가 끝나서 공개된 상태이다.
notion imagenotion image
사용자 삽입 이미지
1Password의 Developer Tools에 들어가면 CI, Kubernetes, CLI, SSH/Git, IDE와 통합할 수 있는 메뉴가 나온다. 참고로 IDE는 현재는 VS Code만 통합할 수 있다.
notion imagenotion image
사용자 삽입 이미지
GitHub Actions를 클릭해서 Service Accounts와 Connect Server 중에서 선택할 수 있게 나온다. 둘 다 시크릿은 자동화해서 연동할 수 있게 하는 기능인데 Service Accounts는 CLI를 사용해서 연동할 수 있고 Connect Server는 별도의 서버를 실행해서 연동할 수 있다. Connect Server는 나중에 또 공부해 보려고 하는 데둘의 기능 차이를 살펴보면 다음과 같다.
notion imagenotion image
사용자 삽입 이미지
CI나 로컬에서 연동하려면 별도의 서버 관리가 필요 없는 Service Accounts가 더 적합해 보였다.
Service Accounts 생성을 클릭하면 이름을 입력할 수 있다.
notion imagenotion image
사용자 삽입 이미지
생성할 서비스 어카운트가 접근할 금고(Vault)를 선택할 수 있다. 권한은 읽기만 허용하거나 읽기/쓰기까지 가능하거나 할 수 있다. 서비스 어카운트에서는 주로 읽기를 할거라고 생각했기에 읽기 권한만 부여했다.
notion imagenotion image
사용자 삽입 이미지
생성이 완료되면 해당 서비스 어카운트의 인증 토큰이 나오고 이 토큰은 1Password CLI에서 사용할 수 있다.
notion imagenotion image
사용자 삽입 이미지
이 토큰을 나중에 사용해야 하므로 1Password에 저장해 둘 수 있다.
notion imagenotion image
사용자 삽입 이미지

1Password CLI

macOS 기준으로 Homebrew를 이용해서 설치하거나 직접 다운로드 받아서 사용할 수 있다.
CLI는 op 라는 명령어로 사용할 수 있고 현재 최신 버전은 2.24.0이다.
$ op -v
2.24.0
Bash
인증을 하기 위해 OP_SERVICE_ACCOUNT_TOKEN 환경변수에 아까 발급받은 인증 토큰을 지정한다.
$ export OP_SERVICE_ACCOUNT_TOKEN=ops_eyJ...
Bash
그리고 1Password 앱의 설정의 개발자 섹션에서 "1Password CLI와 통합"을 활성화해야 한다.
notion imagenotion image
사용자 삽입 이미지
이를 활성화하면 1Password의 각 시크릿에서 "보기"와 "크게 보기" 외에도 "비밀 참조 복사"라는 항목이 생기게 된다.
notion imagenotion image
사용자 삽입 이미지
위는 예시로 API 키를 저장한 시크릿인데 이 "비밀 참조 복사"를 하면 op://Dev/demo/api_key와 같은 주소가 생긴다. 여기서 op://[금고 이름]/[시크릿 이름]/[필드 이름] 형태가 된다. 여기서 각 항목에 지원하지 않는 문자가 있는 경우에는 op://Dev/iunplqsduyobjbri45irjajgcu/password처럼 이름 대신 UID가 생성된다.
앞에서 서비스 어카운트를 만들고 발급받은 인증 토큰을 OP_SERVICE_ACCOUNT_TOKEN 환경변수에 저장하면 바로 CLI를 사용할 수 있다.
op vault list 명령어로 금고 목록을 볼 수 있는데 해당 금고는 Dev 금고에만 접근 권한을 주었기 때문에 한 개만 나온다.
$ op vault list
ID                            NAME
u7mujejocgwhnu3sxbxjehtdpm    Dev
Bash
CLI에서 각 아이템의 목록을 볼 수 있다.
$ op item list
ID                            TITLE                                             VAULT            EDITED
4phd2vr5vnqt3ssrjpupdfbkfy    demo                                              Dev              10 minutes ago
bkgfwcb25abmp4wwslo4ss2qwy    Service Account Auth Token: GitHub Actions        Dev              2 weeks ago
Bash
1Password 앱을 켜지 않고도 특정 아이템의 자세한 내용을 확인해 볼 수 있다.(여기서 보이는 api_key는 임의로 만든 문자열이다.)
$ op item get demo --vault Dev
ID:          4phd2vr5vnqt3ssrjpupdfbkfy
Title:       demo
Vault:       Dev (u7mujejocgwhnu3sxbxjehtdpm)
Created:     1 day ago
Updated:     10 minutes ago by Outsider
Favorite:    false
Version:     3
Category:    SERVER
Fields:
  api_key:    RvN4HNRk2oE.iL*42veP.UE.eDre6rPf_K*@m8!j
  관리자 콘솔:

  호스팅 제공업체:
Bash
CLI에서 비밀 참조를 알고 싶다면 JSON 형식으로 출력해 보면 확인할 수 있다.
$ op item get demo --vault Dev --format json
{
  "id": "4phd2vr5vnqt3ssrjpupdfbkfy",
  "title": "demo",
  "version": 3,
  "vault": {
    "id": "u7mujejocgwhnu3sxbxjehtdpm",
    "name": "Dev"
  },
  "category": "SERVER",
  "last_edited_by": "K2ACBLCXENBKJLN2V6Y3HPRSBY",
  "created_at": "2023-12-19T08:10:17Z",
  "updated_at": "2023-12-21T01:48:25Z",
  "sections": [
    {
      "id": "hosting_provider_details",
      "label": "호스팅 제공업체"
    }
  ],
  "fields": [
    {
      "id": "password",
      "type": "CONCEALED",
      "label": "api_key",
      "value": "RvN4HNRk2oE.iL*42veP.UE.eDre6rPf_K*@m8!j",
      "reference": "op://Dev/demo/api_key"
    },
    {
      "id": "name",
      "section": {
        "id": "hosting_provider_details",
        "label": "호스팅 제공업체"
      },
      "type": "STRING",
      "label": "이름",
      "reference": "op://Dev/demo/hosting_provider_details/name"
    }
  ]
}
Bash

op read

op read는 비밀 참조의 값을 읽어오는 명령어로 다음과 같이 비밀번호를 조회해 볼 수 있다.
$ op read op://Dev/demo/api_key
RvN4HNRk2oE.iL*42veP.UE.eDre6rPf_K*@m8!j
Bash
이를 이용해서 특정 시크릿 값을 파일에 저장할 수도 있다.
$ op read op://Dev/demo/api_key --out-file key.txt
/Users/outsider/temp/op-test/key.txt

$ cat key.txt
RvN4HNRk2oE.iL*42veP.UE.eDre6rPf_K*@m8!j
Bash
값을 확인하고자 할 때는 op read를 이용할 수 있지만 서비스 어카운트를 쓴다는 것 자체가 비밀번호를 직접 다루지 않기 위함이라고 생각하기 때문에 이 명령어는 CLI에 약간 익숙해 지면 쓸 일은 없어질거로 생각한다.

op run

아마 서비스 어카운트에서 가장 많이 사용할 명령어라고 생각한다. 1Password 금고에 시크릿을 저장했다면 개발할 때 이를 가져다 써야 하는데 op run이 이 문제를 해결하는 명령어다.
$ export API_KEY=op://Dev/demo/api_key
Bash
위와 같이 내가 원하는 환경변수(API_KEY)를 앞의 비밀 참조 값으로 설정한다.
애플리케이션에서 이 환경변수를 사용하는 상황을 테스트하기 위해 아래와같이 간단한 Node.js 코드를 작성했다. 3000 포트에 떠 있는 다른 서버에 API_KEY 환경 변수를 쿼리스트링으로 전달하고 API_KEY을 로그로 출력하고 응답받은 결과를 출력하도록 했다.
// app.js
fetch(`http://localhost:3000?secret=${process.env.API_KEY}`)
  .then(async (res) => {
    console.log(`API_KEY: ${process.env.API_KEY}`);
    const result = await res.text();
    console.log(result);
  })
JavaScript
당연하게도 API_KEY의 값으로 op://Dev/demo/api_key가 출력되고 다른 서버의 로그에도 op://Dev/demo/api_key가 출력된다.
$ node app.js
API_KEY: op://Dev/demo/api_key
Response from another server
Bash
이를 op run -- 명령어와 연결해서 서버를 실행하면 환경변수 중에 존재하는 비밀 참조를 모두 찾아서 1Password 값으로 치환해서 처리해 준다.(참고로 --인 더블 대시는 셸에서 옵션과 인자를 구분하는 문법이다.)
$ op run -- node app.js
API_KEY: <concealed by 1Password>
Response from another server
````

위에서 보듯이 해당 환경변수를 로그에 출력했을 때도 값이 출력되는 게 아니라 `<concealed by 1Password>`로 가려진다. 당연히 다른 서버에 전달된 쿼리스트링에는 실제 시크릿 값이 제대로 전달된다.

이렇게 하면 **로컬에서 환경변수를 관리하면서도 실제 시크릿 값을 가지고 있지 않을 수 있다. 실행명령어에 `op run`이 붙어야 하는 불편함이 있지만 보안상으로도 좋고 환경변수 파일을 그대로 GitHub에 공유한다고 하더라도 실제 시크릿 값은 포함되어 있지 않기 때문에 `.env.example` 같은 걸 만들 필요 없이 그냥 환경 파일을 공유해서 사용하는 것도 가능하고 다 참조 값이기 때문에 해당 값을 바꿀 때도 1Password에서 바꾸면 바로 로테이션시킬 수 있다.**

하지만 1Password API에 찔러서 가져오는 것이기 때문에 항상 인터넷에 연결되어 있어야 하고 당연히 API 값을 가져오느라 약간의 시간이 더 걸린다.

```bash
$ op run -- printenv API_KEY
<concealed by 1Password>

$ op run --no-masking -- printenv API_KEY
RvN4HNRk2oE.iL*42veP.UE.eDre6rPf_K*@m8!j
Bash
환경변수 값을 확인하고 싶을 때는 위와 같이 확인해 볼 수 있고 --env-file 옵션을 사용하면 사용하고자 하는 환경파일도 지정할 수 있다.

op inject

셸 스크립트 등에서 비밀 참조를 변환해서 실행하고 싶다면 다음과 같이 op inject를 파이프로 연결하면 전달받은 문자열의 비밀 참조를 실제 값으로 치환한다.
$ echo "API key is op://Dev/demo/api_key" | op inject
API key is RvN4HNRk2oE.iL*42veP.UE.eDre6rPf_K*@m8!j
Bash
여기서 비밀 참조인 op://Dev/demo/api_key를 처리할 때 환경변수도 섞어서 사용할 수 있다. 예를 들어 다음과 같이 같은 API 키가 DEV, Alpha, Prod 3개가 있을 때 같은 패턴으로 만들면 op://$ENV/demo/api_key로 환경변수에 지정하고 ENV 환경변수로 참조할 시크릿을 바꿔가면서 쓸 수 있다.
  • op://Dev/demo/api_key
  • op://Alpha/demo/api_key
  • op://Prod/demo/api_key

GitHub Actions에서 1Password Service Accounts

로컬에서 사용하는 방법을 알아봤으니 당연히 CI에서도 사용할 수 있다. CI에서는 GitHub 기준으로 저장소에 액션 시크릿을 설정할 수 있고 공통으로 사용하는 시크릿은 Org에 시크릿을 설정해서 공통으로 사용할 수 있다. 기본적으로 GitHub에서는 시크릿을 설정한 뒤에는 내용을 확인하기 어렵기 때문에 개인이라면 좀 낫지만, 회사 차원에서는 예전에 어떤 값을 설정했는지 확인하기 어려워서 로테이션시키기가 어려운데 이때도 1Password Service Accounts를 쓸 수 있다.
1Password에 접근하기 위해 저장소에 OP_SERVICE_ACCOUNT_TOKEN을 저장한다. 여기서는 데모라서 저장소에 Actions 시크릿으로 저장했지만, 회사라면 Org 시크릿으로 저장하거나 관리 정책에 따라 팀별로 따로 지정하는 등의 방법이 가능하다.
notion imagenotion image
사용자 삽입 이미지
GitHub Actions에 다음과 같은 액션을 만들어 보자. 여기서는 1password/load-secrets-action 액션을 사용해서 시크릿을 불러와서 원하는 환경변수에 저장할 수 있다. export-env를 true로 설정해야 다음 스텝에서도 해당 환경변수를 사용할 수 있다. 참고로 on에 workflow_dispatch로 지정한 것은 GitHub UI에서 수동으로 실행해서 테스트하기 위함이고 Print unmasked secret 스텝은 보통은 하면 안 되는 트릭이지만 GitHub Actions에서 시크릿 로깅을 허용하지 않기 때문에 이를 회피해서 값을 확인하기 위한 우회법이다.
name: 1Password test

on: workflow_dispatch

jobs:
  1pw-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Load secret
        uses: 1password/load-secrets-action@v1
        with:
          # Export loaded secrets as environment variables
          export-env: true
        env:
          OP_SERVICE_ACCOUNT_TOKEN: ${{ secrets.OP_SERVICE_ACCOUNT_TOKEN }}
          API_KEY: "op://Dev/mysql/password"

      - name: Print masked secret
        run: echo "Secret is $API_KEY"

      - name: Print unmasked secret
        run: echo "$API_KEY" | sed 's/./& /g'
YAML
이 액션을 실행해 보면 다음과 같이 1Password에서 시크릿 값을 가져와서 사용할 수 있는 것을 볼 수 있다.
notion imagenotion image
사용자 삽입 이미지
이렇게 사용하면 로컬이나 CI에서 1Password의 서비스 어카운트 토큰만 저장하고 다른 시크릿은 모두 1Password에서 관리할 수 있는 구조로 만들 수 있다. 보는 관점에 따라서 1Password에 다 담아 놓는 게 좋은가 아닌가는 의견이 갈릴 수 있지만 나는 유출된 지점을 줄이면서 로테이션시킬 수 있다는 점에서 긍정적으로 보고 있다.
물론 1Password의 보안은 상당히 신뢰하는 편이지만 1Password API서버에게 장애가 생기면서 로컬이나 CI에도 영향을 받기 때문에 이 부분은 같이 고려해야 할 것으로 생각한다.
월터 아이작슨이 쓴 일론 머스크의 전기이다. 일론 머스크(Elon Musk)는 요즘이야 따로 설명할 필요도 PayPal Mafia 중의 한 사람으로 SpaceX, The Boring Company, Nurallink, Tesla 등을 창업, 운영하고 최근에 Twitter도 인수한 사람이다.
내가 일론 머스크를 언제부터 알았는지 정확하지는 않지만, PayPal 마피아가 되었을 때는 잘 몰랐던 것 같고(아마 다른 사람들에게 관심이 더 갔던 듯) 아마 Tesla에 관해 알게 되면서 일론 머스크에 대해서도 알게 되기 시작했다. 그때 인상은 참 대단한 사람이라는 생각이었고 대단한 창업가가 많이 있지만 일론 머스크는 뭔가 인류를 걱정하는 듯 SpaceX의 화성 이주 목표나 Starlink, Tesla 전기 자동차, The Boring Company의 Hyperloop를 보면서 그 스케일과 실천력에 감동하였다.
그렇게 좋은 인상이었다가 인상이 나빠지기 시작한 것은 Twitter를 인수한 뒤였다. 그 전에는 그냥 트위터에서 가끔 이상한 얘기하면서 어그로 끌면서 관심 모으는 인상은 있었지만 창업가는 좀 독특한 면모가 있으니 그냥 그런가보다 했고 처음 트위터 인수 얘기가 나왔을 때도 그래도 그 수많은 회사를 운영하던 사람인데 Twitter에서도 뭔가 보여줄지도 하는 기대도 있었다. 그 뒤로는 사실 실망의 연속이었고 Twitter를 X로 바꾸면서 너무 이상하게 만들어버렸다. 내가 Twitter를 워낙 좋아하기 때문에 많은 사람들이 Twitter를 떠나려고 하는 것도 마음이 불편하고 회사를 이렇게 운영한다는 것 자체도 이해하기가 어려웠다.
이 정도가 책을 읽기 전에 내 막연한 생각이었고 일론 머스크의 전기를 읽어보면서 일론 머스크에 대해서 제대로 알지 못했다는 생각이 많이 들었다.
집투를 동생과 창업하고 페이팔과 합쳐졌다가 이후에 SpaceX를 창업하면서 연쇄적으로 회사를 차리기까지의 과정을 볼 때까지 아주 흥미롭다. 여기선 내가 전혀 모르던 얘기도 많았다.
SpaceX가 발사에 실패하고 돈이 없어서 힘들 때 Nasa의 사업을 따오는 부분이나 기존에 로켓 발사의 발주 구조를 혁신적으로 바꿔내는 부분, 치열하게 싸우면서 테슬라를 창업하는 과정 등이 꽤 재미있었다.
다른 회사들도 많이 있지만 아무래도 SpaceX와 Tesla가 그 중심에 있고 가장 큰 사업과 혁신들이었기에 이부분에 대해서도 많이 다루고 있다. 단편적으로는 알고 있는 뉴스들도 있지만 처음부터 찾아보진 않았기 때문에 이 책에서 두 회사가 어떻게 시작되고 어떤 어려움이 있었고, 심지어 회사가 망할 수도 있는 상황에서 어려움을 극복하고 성공에 이르렀는지 보는게 꽤 흥미로웠다.
당연하게도 이러한 혁신을 이루기 위해서는 치열하게 일하는 머스크가 있었다. 이전에 일론 머스크는 어떻게 저 많은 회사를 운영하는 거지? 시간이 되나? 하는 생각을 한 적이 있지만 전기를 보면서는 더 현실감 없을 정도로 치열하게 일하고 있었다. 이젠 꽤 큰 회사의 CEO이기 때문에 회사 운영에 집중할 거로 생각했는데 실제로는 각 제품의 재질이나 디자인, 기술에 다 관여하고 의논할 정도로 거의 모든 일이 일론 머스크를 중심으로 이루어지고 있었다. 이는 일론 머스크가 엔지니어들과 그런 논의를 할 수 있을 정도로 상당한 지식을 가지고 있는 거라고 할 수 있어서 그런 장면들을 보면서 감동스럽기도 했다.
본인이 그렇게 일하면서 그로 인해서 상상도 못할 성공까지 했기 때문인지 당연히 직원들도 그렇게 일하기를 기대한다. 대부분의 채용에도 관여한 것으로 나오는데 대부분 그냥 미친듯이 일만하는 사람을 뽑겠다는 걸로 나오고 주말이든 개인 사정이든 일론 머스크가 지금 해야겠다고 생각하면 하나도 용납하지 않는 모습, 수년동안 열심히 일해서 기여했지만 조금만 나태한 모습을 보이면 바로 해고하는 걸 보면서 엔지니어로써 공감이 되면서도 직장인으로써 묘한 감정이 들기도 했다. 책에는 안나오는데 치열하게 요구할 수는 있는데 일론 머스크가 세계 최고의 부자가 되기까지 회사의 수익이 직원들에게 월급이나 스톡옵션으로 얼마나 보상이 돌아갔는지 궁금해지긴 했다.
요즘은 생각이 좀 달라졌지만 나도 이런 생각을 예전에는 많이 했기에 공감도 많이 되었다.
Twitter를 인수했을 때 직원들 해고하고 엔지니어들 모아놓고 아키텍처 리뷰하고 그럴 때 Twitter 정도 규모의 아키텍처를 새로운 CEO에게 리뷰한다는 게 말도 안 된다고 생각했는데 책을 보면서는 일론 머스크라면 말이 될 수도 있겠다는 생각으로 바뀌었다. 그 이전에 SpaceX의 로켓 설계나 발사체에 대한 논의나, Tesla의 전기차에 대한 부분도 다 관여하고 심지어 엔지니어들의 접근 방법도 바꿔놓은 경우가 많기 때문이다. 내가 보거나 들은 수많은 CEO와는 (당연히도) 완전히 다른 사람이구나 싶었다.
어쨌든 일론 머스크가 오랫동안 회사를 운영하면서 기준으로 세우고 하는 것들은 엔지니어로서 공감되는 부분이 꽤 있다.
SpaceX나 Tesla나 하드웨어 제조가 상당한 부분을 차지하지만 요즘 스타트업이 목적 조직을 구성하는 것도 비슷한 이유라고 생각하고 근복적으로 애자일도 비슷한 접근 방식이라고 생각한다.
보통 일을 하면서 정부의 프로세스나 대기업의 프로세스의 답답함에 불만을 갖지만 일론 머스크는 그 수준이 아니라 계속해서 혁신을 하려고 하는 것이 대단하다고 생각한다. 전문가들조차도 이건 안되지 하는 부분을 바꾸라고 해서 성공하는 부분들을 보면 또 다양한 분야에서 "이건 당연한 거지"라고 하는 비효율이 있을 수 있겠다는 생각이 들었다.
물론 항상 바른 판단을 할 수는 없기에 나중에 후회하는 결정들도 나오고 나도 읽으면서 이것도 없애라고 하는 건 말도 안 되지 같은 생각이 들었다.
트위터를 인수한 과정도 책을 보고 어떤 상황이었는지 알게 되었다. 저자인 월터 아이작슨도 얘기하지만, 충동적이 결정인 느낌이 있다.
다양한 일이 있었지만, Twitter를 엑스라는 이상한 이름으로 바꾼 것이 개인적으로 열받는 부분인데 PayPal을 엑스로 바꾸려고 시도했던 얘기가 나와서 웃음이 나기도 했다.
트위터 인수 후의 일은 최근 일이라서 대부분 알고 있기는 하지만 내부 사람들과 인터뷰하면서 정리해 놓은 내용이라 더 자세한 상황을 알 수 있기도 했다. SpaceX나 Tesla에서도 초기에는 꽤 많은 문제가 있었겠지만, Twitter는 최근에 더 자세히 봐서 그런지 실제로도 많은 문제를 일으키고 있긴 하다.
일론 머스크는 인류를 걱정하는 태도를 자주 보이는데 언론의 자유에 관심이 있지만 방향성에 대해서 좀 고민이 든다. 그래서 꽤 좋은 능력을 갖춘 콘텐츠 검열을 하고 균형을 맞추는 사람들도 나가곤 했다. 일론 머스크가 극우적 성향을 보이고 있진 않지만, 책에서도 뒤로 갈수록 우클릭하고 있다. 물론 언론의 자유라는 것은 한쪽만 열기는 어렵다. 좋은 말(?)을 많이 하게 하면 자연히 나쁜 말도 늘어나기 마련이고 좋은 말(?)만 올리게 한다는 건 반대로 나쁜 말만 올리게 한다는 것과 또 크게 다르지 않기도 하다.
책을 읽으면서 내내 불편했던 것은 일론 머스크가 각성 바이러스 부르는 Woke이다.(원문을 찾아보지 않았지만, 정황상 Woke를 의미한다고 생각했다) Woke는 인종차별, 성차별 등의 사회적 불평등에 대한 인식을 개선하기 위한 용어이고 움직임인데 우리나라로 말하면 깨인 유리창이나 남녀 차별에 대한 부분이라고 할 수 있고(참고로 말하자면 나는 Woke를 지지한다) 어떤 이유에서인지 일론 머스크는 이런 부분이 문제가 오히려 많다고 생각하고 트위터에서도 기존에 너무 심한 차별 글을 올려서 퇴출당한 사람을 복구하는 등의 행동을 했다.(대표적으로 ye) 이런 부분은 동의할 수 없기에 마음이 불편했고 책에도 나오지만 언론의 자유가 중요하다고 하면서 정작 자신을 비판한 기자들은 차단한다거나 스페이스를 닫아버리는 건 이중적이라고 느낄 수밖에 없다.(책에도 나온다.)
Tesla의 임시 CEO로 잠시 영입되었던 마크스의 말에 동의한다.
Response : No Trackback , No Comment

웹개발 관련

  • Maglev - V8’s Fastest Optimizing JIT : 2021년까지 V8의 실행 계층은 인터프리터인 Ignition과 최적화 컴파일러인 TurboFan이 있어서 모든 JavaScript 코드를 Ignition 바이트 코드로 먼저 컴파일한 후 실행한다. 실행하면서 동작 방식을 추적해서 메타데이터와 바이트 코드를 최적화 컴파일러에 제공해서 인터프리터보다 훨씬 빠르게 실행되는 고성능 머신 코드를 생성한다. Ignition과 TurboFan 간의 속도 차이가 크기 때문에 2021년 Sparkplug라는 JIT를 도입해서 성능을 개선했지만, 한계가 있었기에 훨씬 빠른 코드를 생성할 수 있도록 최적화 JIT Maglev를 도입했다. Maglev는 Sparkplug와 TurboFan 사이의 간극을 메우기 위해 도입되었다.(영어)
  • Introducing StyleX : Meta에서 표현력, 결정성, 안정성, 확장성을 갖춘 스타일링 시스템인 StyleX를 오픈소스로 공개했다. StyleX는 CSS-in-JS의 개발자 경험을 컴파일 도구를 사용해서 CSS 성능과 확장성을 지원할 수 있도록 설계되었다. 그래서 표현형 CSS 하위집합을 지원하며 유틸리티 클래스나 라이브러리를 학습할 필요 없이 스타일을 원자적 CSS 클래스 명으로 변환해서 최적화하며 파일/컴포넌트를 넘어서 스타일을 합칠 수 있고 타입을 지원해서 프로퍼티와 값을 세밀하게 제어할 수 있다. StyleX는 컴파일 타임과 런타임 모두에서 빠르게 설계되었다. 이 StyleX는 Facebook.com을 React로 다시 구축할 때 스타일에 더 나은 무언가가 필요하다는 것을 깨닫고 만들기 시작했고 Meta에서 Facebook, WatsApp, Instagram, Threads 등에서 수년간 사용하면서 발전시켜 오다가 이제 오픈소스로 공개한 것이다.(영어)
  • PandaCSS와 함께 CSS-in-JS의 미래로 : 기존에 styled component를 사용하고 있었지만, PandaCSS로 바꾸게 된 배경을 설명한다. styled component를 잘 사용하고 있었지만 사용하지 않는 스타일이 번들에 포함되고 동적 기능으로 인한 성능 저하 문제가 있었고 디자인 시스템을 직접 만들기는 어려웠다고 한다. PandaCSS는 디자이너와 공유하는 토큰을 쉽게 정의할 수 있고 컴포넌트 레시피로 재사용이 쉽고 정적인 CSS를 지원해서 프레임워크를 타지 않는 장점이 있다. 한편 빌드타임에 코드를 생성하므로 토큰/레시피를 수정하면 다시 생성해 주어야 하고 다양한 방법을 지원하므로 팀에서 사용하려면 표준을 정하는 것이 좋다고 한다.(한국어)
  • v0 is now open for everyone. : Vercel이 만든 프롬프트를 입력해서 UI 컴포넌트를 생성해 주는 서비스인 v0이 이제 모두가 사용할 수 있도록 열렸다.(영어)
  • Introducing Learn Performance : web.dev에서 웹 성능에 관심이 있는 사용자를 대상으로 따른 웹페이지를 만든다는 것의 기술적 세부 사항을 설명하는 학습 코스인 Learn Performance의 초기 버전을 공개했다.(영어)

그 밖의 개발 관련

  • Merge vs. Rebase vs. Squash : HashiCorp의 Mitchell Hashimoto가 Git에서 Merge, Rebase, Squash에 관한 질문을 많이 받아서 자기 생각을 정리한 글이다. 셋 중의 하나가 정답이라고 말하는 건 틀렸다고 생각하고 각 전략이 필요한 상황이 있다고 생각한다. Merge와 Merge 커밋이 히스토리를 가장 잘 표현한다고 생각하기에 Merge를 선호하며 모든 커밋이 빌드할 수 있으면서 커밋이 많을수록 bisect가 좋아지기에 하나의 커밋에 변경이 많은 것은 싫어하고 한 커밋은 +50/-50 정도가 가장 좋다고 생각한다. 하지만 이렇게 하려면 모두가 이 규칙을 잘 따라야 하는데 보통 쉽지 않기에 OSS에서 PR에 WIP 커밋이 많지만 대부분 작은 차이이고 PR이 하나의 목표만 있다면 Squash를 사용하는데 이때도 Git/GitHub의 기본 스쿼시 메시지가 아니라 다시 작성하는 편이다. 변경 사항이 많은 WIP가 많은 경우 rebase를 통해 적당히 스쿼시하고 순서도 조정해서 관리한다. 그리고 50개 이상의 커밋을 대규모로 인터랙티브 리베이스를 할 때 GUI가 편하다는 걸 깨달아서 Tower를 사용하고 있다.(영어)
  • Java의 미래, Virtual Thread : 우아한형제들에서 Virtual Thread(Project Loom)이 JDK 19부터 얼리 엑세스로 포함되고 JDK21에서 정식 기능이 되면서 스터디한 결과를 공유했다. 스레드를 사용할 때 더 많은 요청을 처리하면서 컨텍스트 스위칭 비용을 줄이기 위해 훨씬 가벼운 Virtual Thread의 구조와 동작 원리를 보여주고 다른 델인 Thread, Kotlin Coroutine, Reative와 비교해서 성능이 얼마나 차이 나는지도 보여준다.(한국어)

인프라 관련

  • Upgrading GitHub.com to MySQL 8.0 : GitHub.com이 성장하면서 단일 MySQL에서 아키텍처를 발전해 오고 있었는데 1,200개 이상의 MySQL 호스트를 8.0으로 업그레이드한 과정이다.(영어)
    • SLO에 영향을 주지 않으면서 업그레이드하기 위해 계획, 테스트, 업그레이드에 1년이 넘게 걸렸다.
    • MySQL 5.7의 수명이 거의 종료됨에 따라 8.0 으로 업그레이드 해야 했다.
    • GitHub의 MySQL 인프라 구성
      • 1,200개 이상의 호스트로 구성되어 있고 Azure와 베어 메탈 호스트의 조합
      • 300TB 이상의 데이터를 저장하고 50개 이상의 데이터베이스 클러스터에서 초당 5,500만 건의 쿼리를 처리
      • 각 클러스터는 primary와 replicas를 이용한 고가용성 구성
      • 수평/수직 샤딩을 모두 활용하여 데이터가 파티셔닝 되어 있음
      • 대규모 도메인 영역을 위해 수평 샤딩 된 Vitess 클러스터도 있음
    • SLO/SLA를 준수하면서 업그레이드해야 하지만 모든 장애를 미리 고려할 수는 없으므로 중단없이 MySQL 5.7로 롤백할 수 있어야 한다. 다양한 워크로드가 있으므로 클러스터를 원자단위로 업그레이드하고 해야하고 혼합 버전을 오랫동안 운영해야 했다.
    • 2022년 7월부터 업그레이드 준비를 시작했다.
    • MySQL 8.0의 설정값을 결정하기 위해 벤치마크했고 두 버전을 운영해야 했기에 도구와 자동화가 두 버전을 모두 처리할 수 있어야 했다.
    • 모든 애플리케이션의 CI에 MySQL 8.0을 추가해서 CI에서 5.7과 8.0을 같이 실행했다.
    • 업그레이드 전략
      • replicas를 먼저 업그레이드하고 트래픽을 받도록 한 뒤 모니터링하면서 교체해 나가고 5.7은 롤백을 위해 띄워두었지만, 트래픽은 안 가게 함
      • Replica 토폴로지를 조정해서 8.0 primary가 5.7 primary를 복제하도록 구성하고 8.0 replicas 아래에는 5.7 세트와 8.0 세트로 구성해서 8.0만 트래픽을 처리하도록 함
      • Primary를 직접 업그레이드하지 않고 페일오버를 통해 MySQL 8.0 Replica가 Primary로 승격되도록 함
      • 백업이나 비 프로덕션을 위한 MySQL로 모두 업그레이드.
      • 롤백할 필요가 없다는 걸 확인 후 5.7 서버를 모두 제거
  • Why We Created the Argo Project : Argo 프로젝트를 Jesse Suen, Alexander Matyushentsev와 시작했던 Hong Wang이 처음에 왜 Argo 프로젝트를 시작했는지를 정리했다.(영어)
    • 셋은 Applatix라는 스타트업에서 만났는데 2016년 Applatix에서 DevOps 솔루션을 구축해서 컨테이너와 퍼블릭 클라우드를 통해 Jenkins보다 나음 경험을 제공하고자 했다.
    • Kubernetes를 알게 되고 Kuberntes 네이티브로 만들어야 한다는 것을 깨닫고는 Argo Workflows를 시작하게 되었다.
    • 2017년에는 Kubernetes에 CRD가 나오면서 이 CRD를 사용하기로 결정하고 Argo Workflows 2.0을 재작성하게 된다.
    • Intuit가 Kubernetes로 이전하는 작업을 원활하게 수행할 팀을 찾다가 Applatix를 인수하기로 결정했고 Argo Workflows 팀은 하루 빨리 대규모로 테스트하고 싶어졌다.
    • 하지만 바로 Intuit에 Kubernetes 클러스터와 네임스페이스가 너무 많았지만 이를 관리할 도구는 없다는 걸 깨달았다.
    • 처음부터 멀티 클러스터 지원이 필요했고 더 쉽게 오케스트레이션 하려면 단일 컨트롤 플레인이 필요했기에 Argo CD를 만들게 되었고 플랫폼 팀과 애플리케이션 팀이 협업해서 역량을 강화하기 위해 GUI 중심으로 만들기로 결정하게 된다.
    • Intuit에서 점점 Kubernetes로 운영하면서 장애의 50%정도가 배포때 발생하고 복구하는게 걸리는 시간(MTTR)을 단축하는데 실패했다는 걸 깨닫게 된다.
    • 이 문제 해결을 위해 블루/그린과 카나리 배포 전략을 소개하게 하고 Argo Rollouts를 만들게 되었다.
  • A deep dive into CPU requests and limits in Kubernetes : Kubernetes에서 CPU 스케쥴링은 기본적으로 CFS(Completely Fair Scheduler)에 의해서 이루어지고 1.10에서 Beta로 도입되고 1.26에서 Stable이 된 CPU Manager에서 기본 정책인 none을 사용하면 CFS가 CPU를 스케쥴링한다. CPU Manager의 정책을 static으로 설정하면 Linux CPUSets를 사용하게 된다. 이때 Guaranteed QoS 클래스에 할당된 Pod은 요청한 CPU 코어에 독점적인 엑세스를 얻게 되고 해당 코어는 공유 풀에서 제거된다. 이 독점적 코어 사용은 다른 Pod에만 적용되고 시스템 데몬에는 적용되지 않으므로 시스템 데몬에도 따로 CPU를 할당해야 한다. 그래서 static 정책은 컨텍스트 전환에 민감한 워크로드에 유용하지만 다른 컨테이너에 영향을 줄 수 있다.(영어)
  • Atlantis Hardening and Review Fatigue : DoorDash에서 Terraform 코드를 관리하기 위해서 Atlantis를 사용해서 자동화한 과정이다. Atlantis에서 Pull Request 승인을 받지 않으면 terraform apply를 할 수 없는데 실제로는 악의적 코드를 가져올 수도 있고 승인 요건을 우회할 수도 있고 Atlantis 설정으로 허용한 프로바이더를 지정해서 관리할 수 있다. 그리고 리뷰 피로감을 줄이기 위해 Conftest와 OPA를 사용해서 일부 변경 사항은 승인 없이 할 수 있도록 하고 사람이 봐야 하는 변경만 승인이 필요하게 할 수 있다.(영어)
  • Kubernetes V1.27 : Safeguarding Pod with MemoryThrottlingFactor : Kubernetes 1.27에 도입된 메모리 스로틀링 기능을 설명한다. 메모리 request와 limit으로 메모리를 제한하고 관리할 수 있지만 1.27은 request와 limit 간의 차이를 기본 스로틀링 계수(기본값은 0.9)로 계산해서 memory.high를 설정한다. memory.high에 가까워지면 메모리 스로틀링이 동작해서 메모리를 관리한다. 정확히 스로틀링이 동작하는 방식도 궁금한데 그 부분까지는 이글에는 나와 있지 않다.(영어)
  • Open source forkers stick an OpenBao in the oven : OpenTofu 운영자 중 한 명이면서 DevOps 관련 스타트업인 Scalr의 공동창업자이자 CEO인 Sebastian Stadil가 HashiCorp Vault의 포크인 OpenBao 프로젝트를 공개했다. Terraform의 라이센스 변경으로 OpenTofu가 생겼듯이 Vault도 같은 이유로 포크해서 OpenBao를 만든 것이다. OpenBao는 Linux 재단의 인큐베이팅을 받고 있고 IBM 개발자들이 엣지 컴퓨팅 이니셔티브인 LF Edge를 통해 프로젝트를 주도하고 있으면 아직 IBM에 공식 승인이 있었던 것은 아니다.(영어)

볼만한 링크

  • Why We’re Dropping Basecamp : Duke 대학이 10년 동안 프로젝트 관리 플랫폼인 Basecamp를 사용해 왔지만, 현재 사용 수준과 Basecamp의 모회사인 37signals 경영진의 폐해로 인해 올해 12월 종료 후 구독을 갱신하지 않을 거라고 밝혔다. Basecamp는 2여 년 전 고객의 이름으로 인종차별 했던 게 알려지면서 쟁점이 되었지만 37signals는 내부 토론을 차단했는데 Duke 대학에서도 당시에 논의했지만 계속 Basecamp를 사용하기로 했다. 올여름 내부에서 37signals의 CTO인 DHH가 대학 입학 시 인종에 대해 고려하지 않는 대법원판결을 축하는 글과 Meta에선 정치를 하지 않는다는 글을 통해 다시 Basecamp 사용에 대한 검토를 다시 하게 되었다고 한다. DHH는 다양성, 형평성, 포용성(Diversity, Equity, and Inclusion, DEI)를 확고히 자리 잡은 운동이라고 하며 이후 시위를 폭동이라고 하며 사실을 왜곡하고 있고 그가 원하는 글을 쓸 수 있지만 Duke 대학도 Duke 대학의 의견이 있고 선택할 수 있다고 얘기한다. Duke 대학은 도서관이기 때문에 인류가 만들 수 있는 최악이 무엇인지 알고 있고 직장 관행이나 문화가 초래한 해약도 알고 있으며 이는 본받아야 할 모델이 아니라고 얘기한다.(영어)
  • Introducing Gemini: our largest and most capable AI model : Google DeepMind에서 새 대규모 언어 모델인 Gemini를 발표했다. 이 모델은 가장 성능이 뛰어난 Gemini Ultra, 다양한 업무에서 확장할 수 있는 Gemini Pro, 온디바이스 작업에 효율적인 Gemini Nano로 나뉘어져 있다.(영어)
  • 신입 프론트엔드 개발자가 공유하는 소소한 취준팁 : 비전공자로 2년 정도 교육과 프로젝트, 해커톤, 인턴쉽 등의 경험을 쌓은 뒤에 본격적인 취업 준비를 하면서 300회가 넘게 지원하면서 취업까지 성공한 뒤 그동안 경험을 정리한 글이다. 이력서는 주변 사람들에게 피드백 받고 읽는 사람 입장에서 고민해서 작성하고 과제 할 때는 해당 부분을 질문했을 때 어떻게 대답할지를 고민하면서 작성했다고 한다. 면접은 많이 볼수록 경험이 쌓이니까 가능한 한 많이 지원해 보라고 하고 있고 면접 장소에 좀 일찍 가서 컨디션이랑 복장 관리를 한 뒤에 면접하라는 팁도 제공하고 있다. 오랫동안 맘고생도 심했겠지만, 고민을 많이 하면서 준비했다는 게 느껴지는 글이다.(한국어)
  • CIA가 CTO를 신설한 이유는 : 미국 바이든 정부의 CIA 국장인 윌리엄 번스는 사상 처음으로 CTO 직책을 신설하고 낸드 물찬다니(Nand Mulchandani)를 CTO로 임명했다. 낸드 물찬다니는 실리콘 밸리에서 네 개의 기업을 창업하고 매각한 연쇄 창업가로 국방부의 인공지능센터에 부임한 뒤 CIA의 CTO까지 오르게 되었다. 백악관의 CTO는 오바마 정부에서 처음 신설하고 트럼프 정부에서 꽃을 피웠는데 이번에 CTO를 뽑은 CIA 국장은 이제 기술 자체가 경쟁과 분쟁의 영역이 되고 있어서 국가 안보에 영향을 미치게 되었다고 얘기했다.(한국어)

IT 업계 뉴스

  • Mitchell reflects as he departs HashiCorp : HahiCorp의 공동창업자인 Mitchell Hashimoto가 11년 동안 일한 HashiCorp를 떠나기로 했다. 그동안 CEO에서 물러나고 리더십 팀과 이사회에서도 물러나는 등 준비를 해오다가 최근 아이도 생겼고 새로운 도전을 하기에 적절한 시기라고 판단해서 떠나기로 했다고 한다. 아직 어떤 도전을 할지는 정확히 밝히지 않았다.(영어)
  • 트위치, 6년만에 국내 철수... 내년 2월27일 서비스 접는다 : 게임에서 많이 사용하는 스트리밍 플랫폼 Twitch가 공식적으로 내년 2월 27일까지만 운영하고 국내 서비스를 종료하기로 했다. Twitch에서 밝힌 이유로는 망 사용료가 너무 비싸서 운영비용이 많이 들기 때문이라고 했다.(한국어)

프로젝트

  • Ghostty : Mitchell Hashimotor가 만드는 터미널 에뮬레이터.
  • MRR Counter with linear() : CSS linear() easing 함수로 숫자가 돌아가면서 표시되는 애니메이션을 보여주는 예제 코드
  • markdown-it-github-alerts : GitHubdl 마크다운 blockquote에서 Note, Tip, Caution 등을 표시해 주는 기능을 구현한 markdown-it 플러그인
  • System Design 101 : "가상 면접 사례로 배우는 대규모 시스템 설계 기초" 1, 2권의 저자인 Alex Xu가 복잡한 시스템을 시작 자료를 이용해서 쉽게 설명하는 저장소를 공개했다.
  • Vault Benchmark : Vault가 어느 정도의 트래픽을 안정적으로 받아주는지 테스트할 수 있는 벤치마크 도구로 HashiCorp가 만들었다.

버전 업데이트

  • SvelteKit v2.0 : Svelte의 앱 개발 프레임워크, 릴리스 공지
    • Vite 5 지원
    • 24년에 출시될 Svelte 5를 도입하려면 SvelteKit 2로 업그레이드 권장
  • astro v4.0 : JavaScript 웹 프레임워크, 릴리스 공지
    • Dev Toolbar 도입
    • 국제화(i18n) 라우팅
    • 실험적 증분 콘텐츠 캐시
    • View Transition API 지원
  • Kubernetes v1.29 Mandala : 컨테이너 오케스트레이션 도구, 릴리스 공지
    • PV와 PVC에 ReadWriteOncePod 모드가 추가되어 하나의 파드만 PVC를 사용할 수 있도록 할 수 있다.
    • CSI 드라이버에서 스토리지에 접근할 때 자격증명을 할 수 있는 Node volume expansion Secret 기능이 GA가 되었다.
    • KMS v2가 GA가 되었다.
  • Deno v1.39.0 : TypeScript 런타임, 릴리스 공지
    • 성능 문제로 제거했던 WebGPU API 재 도입
    • deno coverage 명령어에 summary와 html 리포터 추가
  • Turborepo v1.11.0 : JavaScript/TypeScript 빌드 시스템, 릴리스 공지
    • Go 대신 Rust로 작성한 새로운 기반 도입
  • Safari 17.2 : 웹브라우저, 릴리스 공지
    • 루트 <html> 요소의 CSS cap, ex, ic, ch와 같은 rcap, rex, ric, rch 단위 추가
    • CSS linear() 함수 지원
    • CSS Math 함수인 rem(), mod(), round() 지원
    • 반응형 이미지의 프리로딩 지원
  • Open Policy Agent v0.59.0 : 클라우드 네이티브 환경의 정책 엔진, 릴리스 공지
    • OPA 1.0 릴리스를 대비하기 위해 기존 정책을 준비하기 위한 릴리스
    • OPA 1.0에서는 Rego 언어에 호환 안되는 변경사항이 있으므로 -rego-v1 플래그를 통해 문법을 확인할 수 있다.
Response : No Trackback , No Comment
지난 12월 1일 공개SW 페스티벌 2023에서 "오픈소스에 기여할 때 알면 좋을 개발 프로세스"라는 제목으로 발표했다. 공개SW 페스티벌은 3년전인 2020년에도 "오픈소스 뒤에 메인테이너 있어요"라는 제목으로 발표했었다.
이번에 발표 요청을 받고 고민을 많이 했다. 올해는 회사 일도 바빴고(핑계지만...) 집에 와서는 좀 쉬기 바빴던 한해라서 오픈소스 활동도, 사이드 프로젝트도 거의 못 했기 때문에 발표할 주제가 마땅치 않았고 이전에 발표한 주제를 또 하고 싶지는 않았다. 이런저런 고민을 하면서 김태곤 님한테도 연락받고 오랜만에 보는 분들도 꽤 오시는 것 같아서 사람들도 볼 겸 발표를 먼저 수락했다.(이후 이날 팀 회의가 있는 날일걸 깨달았지만 어쩔 수 없었다)
발표 수락을 하고 난 바로 미국으로 날아갔다. 시차 적응도 하고 이것저것 하느라고 정신없이 보내다가 발표 제목을 내야 하는 날이 임박해서야 고민을 시작했다.
정확히는 몰랐지만, 참석자는 오픈소스를 잘 모르는 초심자들이 많을 것 같았기에 쉬운 주제로 해야 할 것 같았고 뭘 하면 좋을까 고민하다가 프로세스 생각이 났다. CI나 CLA처럼 사소하고 별거 아닌 내용이긴 하지만 또 전혀 모르면 처음에는 이해하기 어려운 프로세스를 정리해서 한번 설명하면 가볍게 들으면서 한번 듣고 나면 좀 도움이 되지 않을까 싶어서 말할 내용을 몇 가지 정리해 보니 발표할 수 있을 것 같아서 주제를 요약해서 보냈다.
발표 자료를 만들면서는 역시 어려웠다. 항상 그렇듯이 발표 스토리가 꽤 잡혀있지 않으면 만들면서 스토리 라인 잡느라고 고생하는 편인데 이번에도 역시 그랬다. 그리고 사실 내용이 너무 쉬운 내용이라 이걸 발표하는 게 맞나 하는 생각을 장표 한 장 만들 때마다 생각했다. 그래도 정리하다 보니 발표 분량은 나왔고 현장에서 발표했는데 이번엔 연습을 많이는 못 해서 말을 좀 절었던 것 같다.
전체 사람들의 느낌은 모르지만, 발표 끝나고 발표 잘 들었다고 질문하시는 분들이 있어서 그래도 몇몇 분에게는 도움이 되었구나 하고 안심했다.
이번에 특히 흥미로웠던 것은 마지막 세션이라 다른 발표자분들처럼 끝나고 질문 시간이 따로 없어서 질문이 없을 거로 생각했는데 다 끝나고 가려고 하는데 두 분이 와서 질문을 했다. 처음에는 회사에 대한 간단한 질문부터 시작해서 나도 편하게 얘기하고 있었는데 이번에 정부에서 한 행사에서 수상한(공개 SW 페스티벌은 한 해 동안 정부에서 시행한 오픈소스 사업의 시상식도 포함하고 있는데 어디서 수상했는지는 정확히 찾기가 어려웠다..) Haetae - Your Smart Incremental Tasks라는 프로젝트였는데 의존성을 추적해서 영향받는 파일의 테스트만 돌리는 등의 작업을 해주는 증분 태스크 러너였다.
코엑스에 서서 1시간 정도 얘기를 나누었는데 설명을 듣다 보니 결국 노트북도 꺼내서 설명을 듣게 되었고 가볍게 만들기 시작한 게 아니라 Bazel부터 빌드도구나 태스크 도구에 대해서 오랫동안 고민하고 어떻게 만들어야 하는지 긴 준비 끝에 만들었음을 느낄 수 있었고 써보진 않았지만, 퀄리티도 꽤 좋아 보여서 정식 릴리스가 기대되는 프로젝트였다.
이 글은 GitHub Universe 2023 참석기 #1에서 이어진 글이다.

Open Source Community Day

notion imagenotion image
사용자 삽입 이미지
화요일은 오픈소스 커뮤니티 데이가 진행되어 GitHub Stars 뿐만 아니라 오픈소스 메인테이너들과 Microsoft MVP 들이 GitHub 본사에 초대받았다.
notion imagenotion image
사용자 삽입 이미지
오전에는 GitHub HQ 오피스 투어가 있었다. GitHub 오피스 투어는 사실 여러번 해봤긴 하지만 그래도 볼때마다 좋다.
notion imagenotion image
사용자 삽입 이미지
투어가 끝나고는 컨퍼런스 행사장 중 하나인 Hyatt Regency에 가니 GitHub Universe가 곧 시작됨을 느낄 수 있었다.
notion imagenotion image
사용자 삽입 이미지
notion imagenotion image
사용자 삽입 이미지
등록대에 가서 등록을 하니 네임택를 받을 수 있었다. 모든 세션에 다 들어갈 수 있는 All Access이고 프라이빗 행사에도 참여할 수 있는 Dark Mode라 목걸이도 보라색으로 받았다. eink로 된 네임택은 작년부터 나누어 주었던거 같은데 작년에 트위터에서 보고 부러웠는데 올해도 나누어 주어서 받을 수 있었다.
notion imagenotion image
사용자 삽입 이미지
notion imagenotion image
사용자 삽입 이미지
등록하면 바로 USB-C를 연결해서 현장에서 바로 내 이릅이 표시된 eink 네임택을 받을 수 있고 뒷면도 이쁘게 디자인 되어 있다. 행사 중에 이를 연결할 수 있는 키트를 주기도 하고 가이드를 주어서 직접 컴퓨터에 연결해서 모드를 바꿀수도 있는데 아직 안해봤다. 다른 사람들은 반전을 주어 다크모드로 바꾼다거나 다른 글자나 이미지를 넣는 등의 튜닝도 했다.
notion imagenotion image
사용자 삽입 이미지
등록은 미리 했지만 사전 이벤트인 오픈소스 커뮤니티 데이였기 때문에 한 곳에서 오픈소스 관련 소규모 세션이 진행되었다.
notion imagenotion image
사용자 삽입 이미지
GitHub 리더십 팀과의 질문답변시간도 있었고 오픈소스 관련 그룹 토론이나 GitHub 스폰서 기능에 대한 의견 교환 시간도 있었다. 리더십 팀의 규모는 모르지만 GitHub의 VP나 디렉터 직급들한테 질문을 하는 시간이었는데 여성이 3명이나 되었고 다른 곳에서도 리더들에 여성 비율이 꽤 많게 느껴졌다. 여긴 또 이렇게 우리나라 보다 앞서가는 구나 하는 생각이 들었다.
notion imagenotion image
사용자 삽입 이미지
Node.js TSC 디렉터이기도 하고 OpenJS 재단이나 TC39에서도 활동하고 현재는 GitHub에서 npm과 Codespaces를 이끌고 있는 Myles Borins가 있어서 같이 사진도 찍었다. 아침부터 얼굴을 알아보고 기회를 노리고 있었고 첨에는 Myles Borins만 알아봤는데 오전부터 같이 얘기하던 사람들이 Node.js 커미터인 Tierney Cyren, Shelley Vohr이고 Electron 메인테이너인 Samuel Attard라는 것을 금새 눈치챘다. Node.js와 JavaScript를 좋아하는 터라 너무 반가웠지만 내 짧은 영어로는 대화에 끼기는 어려웠다.
notion imagenotion image
사용자 삽입 이미지
저녁에는 Minna Gallery라는 곳에서 오픈소스 메인테이너 소셜 행사가 있었다. 저녁 이벤트라 그냥 갔는데 술은 계속 주는데 핑거푸드 조차 주지 않았다. 오픈소스 메인테이너 들은 신청후 참석할 수 있었는데 2015년에 Airbnb 오피스에 방문할 때 우리를 초대해줬던 Jordan Harband도 만날 수 있었다. 8년전 한번 만났지만 그 뒤에서 Popular Convention땜에 몇번 얘기했던터라 다행히고 내 닉네임을 보고 바로 알아봐주었다.
낮부터 GitHub Campus Expert 사람들이 있어서 아시아 사람들도 있길래 혹시 한국분인가 명찰을 지나가면서 유심히 봤는데 나의 동체시력으로는 알아볼 수가 없었다. GitHub Stars 중 약간 친해진 Huan Li가 한국 사람 있다고 알려줘서 한국 Campus Expert 중 한분인 김서현님과도 인사를 나눌 수 있었다. 이번에는 유독 한국분이 적어보여서 더욱 반가웠다.
notion imagenotion image
사용자 삽입 이미지
notion imagenotion image
사용자 삽입 이미지
이전 같으면 공짜술이라서 신나게 마셨을테지만 미국 가기전에 몸이 꽤 아파서(아마도 술병?) 좀 정신차리고 술을 안먹고 있던터라 맥주만 약간 마셨다. 오픈소스 메인테이너 행사라 밖에 나와서 쉬는 중에 warp 터미널 개발자도 만날 수 있었다. 오픈소스 회사라 일하다가 잠깐 놀러왔다면서 다시 들어가서 일해야 된다고 했다. 난 솔직히 아직 warp 안쓰고 iTerm 쓴다고 얘기하길 했는데 티셔츠 보내주겠다고 이메일도 적어갔다.

GitHub Universe Day 1

notion imagenotion image
사용자 삽입 이미지
GitHub Universe는 YBCA(Yerba Buena Center for the Arts)에서 진행되었다. YBCA에 도착하자 커다란 옥토캣이 사람들을 반겨주고 있었다.
샌프란시스코 바로 옆에 있는 Moscone 센터 바로 옆에 있는 문화센터인데 장소가 아주 크진 않아서 인지 바로 옆에 Hyatt Regency 2층과 길건너의 SF MOMA도 홀도 같이 사용했다. 그래서 몇개의 세션은 해당 장소로 이동해야 했는데 길을 건너야 하는게 좀 귀찮았다.
notion imagenotion image
사용자 삽입 이미지
키노트는 메인 스테이지에서 진행되었는데 9시까지 가야하는데 첫날 좀 늦게 일어다서 딱 9시에 도착했더니 2층에만 자리가 있었다. CEO인 Thomas Dohmke가 키노트를 진행했는데 GitHub은 Git 기반으로 만들어졌지만 이제는 Copilot 기반으로 다시 만들어 진다면서 AI 플랫폼이 될 것임을 얘기한 것이 가장 인상적이었다.
이 키노트에서 많은 것을 발표했다.

GitHub Copilot Chat

GitHub Copilot Chat이 12월 정식 출시될 예정이고 Copilot 사용자는 바로 사용할 수 있다. 실제로 써보면 에디터에 바로 붙어있다는 것이 편의성도 있지만 코드 블럭을 지정해서 바로 질문할 수도 있고 /fix, /test 같은 명령어도 내릴 수 있다. Copilot Chat은 GPT-4 기반이고 JetBrains IDE도 지원하기 때문에 따로 GPT-4를 쓸 일이 더 줄어들 것 같다.
그리고 Copilot Chat은 github.com에도 통합될 예정이다. 이건 아직 사용해보지 못했는데 데모 화면에서는 볼 수 있었는데 내 기억에는 사이드바와 코드뷰 등에서 Copilot 아이콘으로 바로 접근할 수 있고 GitHub Mobile 앱에서도 사용할 수 있어서 ChatGPT 대용으로 쓰기도 좋을 것 같다. 어차피 내가 물어볼 것의 대부분은 코드 관련이긴 하다.

GitHub Copilot Enterprise

Copilot Individual($10)과 Copilot Business($10)에 이어서 Copilot Enterprise가 내년 2월에 출시될 예정이다. 가격은 $39로 꽤 비싼 편이다.
발표에서는 Pull Reqeust를 올리고 버튼을 누르면 자동으로 요약을 보여주며 GitHub에 올라오는 Pull Request의 상당수에 설명이 비어있다고 설명했다. 코드 리뷰 어느정도는 자동으로 제안해주기도 하는데 이런 기능에 기대 후에 이러한 기능은 엔터프라이즈에서만 동작한다고 해서 아쉬웠다. AI의 비용을 생각하면 꼭 싸다고 할 수 없지만 GitHub Enterprise도 $21인데 Copilot Enterprise까지 쓴다면 직원당 상당한 비용이 되긴 한다.
엔터프라이즈의 가장 큰 부분은 조직내의 코드페이스로 파인 튜닝할 수 있다는 점이다. 이걸 듣고 생각이 들었던건 어디까지 튜닝이 가능하냐는 점인데 사내에 HTTP 클라이언트 같은게 있다면 코드 완성할 때 범용적인 HTTP 클라이언트가 아니라 사내에 맞춰서 해준다면 꽤 좋겠다는 생각이 들었다. 그리고 A 메서드가 deprecated되고 B 메서드를 추가한 경우 IDE에서 자동으로 B 메서드를 추천하는 식으로 한다면 사내에 커뮤니케이션을 상당히 줄여주어서 $39가 아깝지는 않겠다는 생각이 들었다.
notion imagenotion image
사용자 삽입 이미지
Copilot Enterprise를 발표하고 갑자기 Microsoft의 CEO인 Satya Nadella가 무대에 등장했다. 길게 있진 않았는데 GitHub이 하는 AI 행보에 힘을 실어주기 위해 나타난 것으로 보인다.

GitHub Advanced Security

그 외에 GHAS(GitHub Advanced Security)에도 AI 기능이 많이 추가되어 IDE에서 취약점 수정 제안이 가능하고 현재는 JavaScript/TypeScript만 지원하지만 Pull Request에서도 취약점을 수정하는 제안을 자동으로 올릴 수 있게 된다. 개인적으로 GHAS는 가격($49)에 비해서 아직은 기능이 좀 부족하지 않나 싶긴 한데 AI 기능이 많이 추가되면 IDE에서도 많은 지원을 할 수 있는 Shift Left가 가능하기 때문에 꽤 쓸만해 질 수 있겠단 생각이 들었다.

GitHub Copilot Workspace

notion imagenotion image
사용자 삽입 이미지
키노트가 거의 끝난무렵 갑자기 스티브 잡스 얘기를 하면서 One more thing...이 등장했다. GitHub에서 One more thing을 보게 될 줄은 몰랐다.
notion imagenotion image
사용자 삽입 이미지
그러고 발표한 것은 GitHub Copilot Workspace이다. 내년에 출시 예정이라고 하는데 아직은 실험 상태로 대부분의 작업이 이슈에서 시작하는데 데모 영상을 보면 GitHub 이슈에서 워크스페이스를 열면 어떤 변경을 하면 될지 AI가 제안해 주는데 이에 대한 내용을 사람이 일부 수정하고 구현하기를 누르면 코드 수정을 보여주고 바로 Pull Request까지 올릴 수 있게 된다.

GitHub Stars Walk of Fame

notion imagenotion image
사용자 삽입 이미지
notion imagenotion image
사용자 삽입 이미지
작년부터 시작된건데 행사장 일부 공간에 GitHub Stars Walk of Fame로 꾸며주고 있다. 헐리우드에 있는 Walk of Fame을 따라 한 것인데 바닥에 각 Stars의 이름이 있어서 내 이름도 발견할 수 있었다. 작년에는 다른 분께 사진만 전달받았는데 올해는 직접 볼 수 있어서 좋았다. 저 스티커는 따로 한장을 집에 가져가라고 줬는데 너무 커서 캐리어에 구겨지지 않게 넣어서 가져오기 쉽지 않았다.

GitHub Shop

notion imagenotion image
사용자 삽입 이미지
notion imagenotion image
사용자 삽입 이미지
notion imagenotion image
사용자 삽입 이미지
GitHub Universe에는 항상 GitHub Shop이 운영된다. 컨퍼런스 때 새로나온 제품도 있지만 기존 GitHub Shop에서 파는 제품도 좀 싸게 팔아서 이전에도 이것저것 사오긴 했었는데 이번에는 신상품 말고는 제품이 없었다.
깃헙 스웨터는 내 취향이 아니라 안샀고 후디는 집업 후디만 입는 편이라서 딱 맘에 드는 제품이 없었다. 그래서 우산이랑 키캡이랑 티셔츠만 구매했다. 원래 알고 지내던 GitHub 총판인 단군소프트의 담당자분을 오랜만에 만났더니 키캡을 사서 선물해 주셨다.(감사합니다.)
처음엔 안샀는데 스케이드보드 덱을 살지 말지 너무 고민됐다. 디자인이 딱 내취향이면 샀을텐데 이번엔 뭔가 맘에 드는듯 아닌듯 애매했는데 가격도 비쌌기 때문에 고민하다가 선뜻 하지 못했다. 다음날 세션을 듣다가 세션이 좀 재미없기도 하다가 언제 또 기회가 오겠나 하고는 세션을 나와서 사러 갔더니 마지막 남은 1개의 보드가 있었다. 마지막 남은걸 구매했더니 세션 중간에 나와서 사길 잘했다는 생각이 들었다. 당연히 스케이드 보드로 타려는건 아니고 인테리어 용도이다. 종종 GitHub 사무실이나 GitHub 직원들과 화상 미팅을 할 때 벽에 있던 스케이트 보드가 부러웠기 때문이다. 그리고 어제는 없었던 옥토캣 LED도 있어서 같이 사왔다.

행사장

notion imagenotion image
사용자 삽입 이미지
입구에는 당연히 라운지와 등록대가 있고 가운데에는 GitHub의 부스가 있고 옆에도 다른 부스들이 있었다.
notion imagenotion image
사용자 삽입 이미지
notion imagenotion image
사용자 삽입 이미지
Copilot 등 새로운 기능을 살펴보고 질문할 수 있는 GitHub 부스뿐 아니라 네임텍을 찍으면 화면에 내 이름으로 랜덤 커밋 메시지가 나오거나 퀴즈를 주고 자물쇠를 풀면 열쇠고리와 키캡을 주는 이벤트도 있었다. 443 포트를 묻는 문제였는데 긴가민가 하다가 자물쇠에 0443을 입력하니까 자물쇠가 열려서 상품을 받아올 수 있었다.
GitHub 부스에서 커스텀 프로퍼티 기능도 알게 되었다. 나중에 보니 이건 지난 달에 공개된 것이었는데 저장소에 부서나 중요도 등 프로퍼티를 지정할 수 있는 기능이다. 부스에서 좀 이해하고 테스트를 해보니 어딘가에 표시되는건 아니고 Org 차원에서 프로퍼티의 종류를 생성할 수 있고 이 키를 각 저장소에서 원하는 값으로 설정하는 거라 첨에는 어디 쓰는건지 잘 몰랐는데 다음날 세션을 보면서 더 이해할 수 있었다.
notion imagenotion image
사용자 삽입 이미지
notion imagenotion image
사용자 삽입 이미지
메인스테이지가 있는 옆건물로 가기 위한 야외에도 행사장으로 꾸며져 있어서 식사를 하거나 과자, 음료 등을 마시며 쉴 수 있는 공간이 있다. 사람들과 편하게 교류할 수 있는 공간이 넓다 보니 사람들이 많이 얘기도 하고 책상도 많아서 업무를 하는 사람도 꽤 보였다. 메인 스테이지의 발표는 야외에서도 볼 수 있게 제공하고 있었는데 자세히 보진 않았지만 밖이 밝아서 보기가 쉽진 않아서 많은 사람들이 여기서 발표를 보고 있진 않았다.

Platform engineering: a new idea or just a new name?

notion imagenotion image
사용자 삽입 이미지
notion imagenotion image
사용자 삽입 이미지
Platform engineering: a new idea or just a new name?은 Octopus Deploy에서 진행한 세션이었다. 키노트를 듣고 행사장 구경도 하고 부스도 보고 분위기 파악을 하고 최근 플랫폼 엔지니어링에 관해서 관심도 많고 해서 여기선 어떤 얘기를 하는지 궁금해서 들으러 갔다.
아직 컨퍼런스 장소에 익숙치 않아서 몰랐는데 이 발표의 장소가 Discussion Lounge였다는 것이다. 들어가면서 그냥 자유롭게 의자가 배치되어 있다고 생각했는데 알고 보니 이게 그룹별로 나뉘어져 있는 것이었다. 그래서 Octopus Deploy에서 주제를 던지면 각 그룹별로 토론하는 형태였다.
물론 장표를 보여주면서 설명하는 발표의 영어도 다 알아듣지 못하는 나에게 이러한 토론은 너무 알아듣기가 어려웠다. 다 알아들었다면 꽤 재미있는 자리였겠지만 못알아들어서 아쉬웠다. 중간에 나갈까도 생각했지만 너무 맨앞에 앉았기도 하고 던져주는 키워드로도 어떻게 생각하고 있는지 어느정도는 이해할 수 있어서 그냥 기다렸다. 이상하게 내가 제목만 보고 고른 세션은 몇개가 Discussion Lounge였었고 장소보고 이후에는 들어가지 않았다.

Dark Mode

notion imagenotion image
사용자 삽입 이미지
notion imagenotion image
사용자 삽입 이미지
저녁에는 다크 모드 행사가 있었다. 다크 모드는 GitHub Universe의 전체 엑세스가 가능한 사람들만을 대상으로한 파티로 SF MOMA 2층에서 열렸다. 해외 컨퍼런스는 저녁에 항상 이런 네트워크 파티가 있는데 국내에는 이런 문화가 없어서 항상 아쉬운 부분이다.
notion imagenotion image
사용자 삽입 이미지
notion imagenotion image
사용자 삽입 이미지
notion imagenotion image
사용자 삽입 이미지
여기선 다양한 음식도 나오고 술도 계속 주었는데 꽤 맛있었다. 3층으로 가면 에그노그? 라고 하는건지 핫초코 비슷한데 꽤 독한 술을 만들어 주었다. 영어도 잘 못하지만 처음엔 뭘 준다는건지 몰랐는데 따뜩한 차에 찐한 알콜이 특이한 느낌이었다. 저녁 파티를 즐기고 싶었는데 이 시각에 한국에서 빠지기 힘든 미팅이 있어서 Zoom으로 참여하느라고 파티를 잘 즐기지 못했다.

GitHub Universe Day 2

notion imagenotion image
사용자 삽입 이미지
컨퍼런스 둘째날은 좀 일찍 나가서 1층에 앉았다. 어제 AI 중심으로 바뀌는 방향성에 대해서 강조하고 GitHub Actions의 Apple Silicon 지원과 GitHub Enterprise 기능 소개, GitHub의 멀티 어카운트 지원(너무나 기다렸던 기능)을 발표했다.

GitHub: The best developer experience built by developers, for developers

notion imagenotion image
사용자 삽입 이미지
notion imagenotion image
사용자 삽입 이미지
이 세션에서는 GitHub이 오픈소스 중심의 플랫폼에서 이제는 AI 기반으로 나아가는 과정을 설명하면서 새로운 기능 등을 설명했다. GitHub은 꽤 자세히 보고 있어서 기능 자체가 나에겐 새롭지 않았지만 개인적으로 AI를 AI를 썼다는 것 자체를 마케팅 수단으로 쓰는 정도를 넘어서서 실제로 효용 가치를 가장 잘 주는 서비스 중 하나라고 생각해서 인상적이었다.

1 Password Rule GitHub with just a touch of your finger

notion imagenotion image
사용자 삽입 이미지
스폰서 부스에서 1Password를 구경하다가 서비스 어카운트를 알게되고 테스트해봐야지 하고는 1년 가까이 미루고 있는 사이에 1Password의 Developer Tools 기능이 꽤 많이 좋아졌다는 것을 알게 되어서 세션을 참가했다. 여기서 SSH 키 관리와 서비스 어카운트를 어떻게 쓸 수 있는지 데모를 보면서 이해할 수 있었고 올해 고민하던 문제의 해결책이 될것 같아서 관심이 많이 간 세션이었다. 이 세션은 컨퍼런스장 중간에 데모 스테이지에서 소규모로 열린 세션이었는데 내가 제목을 보고 관심 가진 세션의 많은 세션이 여기서 진행된 세션이었다.

How GitHub Securely uses GitHub

notion imagenotion image
사용자 삽입 이미지
GitHub이 GitHub에서 보안관리를 어떻게 하고 있는지 설명하는 발표였고 GitHub 사람들 3명이 돌아가면서 발표를 했다.
notion imagenotion image
사용자 삽입 이미지
notion imagenotion image
사용자 삽입 이미지
몇가지 기억나는 것은 워크플로우에서 GitHub 외부에서 작성된 워크플로우를 직접 호출해서 사용하는 것은 거의 없고 각 단계에 다야한 검사 과정이 있지만 올해 추가된 Repository Rulesets이 현재 GitHub이 밀고 있는 보안 관리의 핵심 기능이라는 생각이 들었다.
RuleSets를 통해 중요 프로젝트는 필요한 건증단계가 모두 진행되었는지 확인하고 이를 통해서 파이프라인에서 다음 단계를 진행할지를 판단한다. 이는 GitHub이 GitHub을 개밥먹이기를 하면서 더 잘할 수 있는 방법을 고민하면서 이를 기능으로 구현한 것이 Rulesets라는 생각이 들어서 더욱 관심이 갔다.
이 세션을 꽤 괌심이 갔는데 영어를 다 알아듣지 못해서 특히나 아쉬운 세션 중 하나였다.

그 외...

데모 스테이지에서 Datadog의 CI Visibility에 대한 세션도 들었다. CI의 실행 상황을 추적해 주기도 하고 특히 해결하기 꽤 피곤한 freaky 테스트에 대한 모니터링을 통해서 얼마나 랜덤으로 자주 실패하는지 언제부터 실패하는지 보여주는 부분은 꽤 관심이 갔다. 컨퍼런스 가기전에 좀 살펴보기도 했는데 커미터달 한달에 $8 라서 가격대비 효용을 얻을지 좀 고민이 되었던 터라 더 아쉽다는 생각이 들었다.(좀 비싼 느낌)
데모 스테이지에서 기다리던 중 GitHub Next의 리서치 시니어 디렉터인 Idan Gazit을 찾으면 GitHub Next 스티커를 준다는 트윗을 보았다. GitHub Next는 GitHub의 R&D 조직으로 다양한 실험을 하면서 미래 사업을 많이 연구하고 있어서 좋아하는 터라 라운지를 돌아다니니 운좋게도 금방 Idan Gazit를 찾을 수 있었다. 그래서 GitHub Next 스티커를 몇장 받았다.

에필로그

오랜만에 샌프란시스코에 컨퍼런스 참석차 갔다온 경험은 역시 좋았다. 이 도시는 여전히 날 다양하게 설레이게 한다는 생각이 들었고 올해 바쁜 업무 가운데도 리프레시가 되는 기분이었다. 컨퍼런스 참석 후기는 44bits 팟캐스트에서도 얘기했다.
혼자 돌아다녀도 좋긴 하지면 여전히 영어는 너무 아쉬웠다. 이 후기 자체도 갔다온지 한달 가까이 된 시점에야 작성하고 있지만 여전히 영어 공부를 따로 하고 있지는 못하고 그래서 여전히 영어를 잘 못하는 이유이기도 하다. 이전에 그냥 참석했을 때와 달리 이번에는 GitHub Stars로 참석했기에 다른 Stars는 어느정도 유대가 있기에 쉽게 어울리고 대화할 수도 있음에도 영어가 너무 안되니 잘 끼지 못한게 아쉬웠다. 그래도 약간은 대화 나누고 링크드인을 연결한 사람들도 있다.
올해도 재밌었다.
Response : No Trackback , No Comment
지난 10월 30일부터 11월 11일까지 GitHub Universe 콘퍼런스에 참석하려고 미국 샌프란시스코에 갔다 왔다.

샌프란시스코

나는 샌프란시스코를 좋아한다. 더 정확히는 결국 소프트웨어를 가장 선도하는 회사들이 이 실리콘밸리에 모여있다 보니 이 동네에 오기만 해도 좀 설레고 지나가면서 내가 아는 회사들 간판을 볼 때마다도 설레는데, 오랜만에 가서 그런지 별고 안 해도 꽤 좋았다.
1~2년에 한 번 정도는 콘퍼런스 참석 목적으로 샌프란시스코에 가는 편이었는데 팬데믹으로 인해서 2019년 GitHub Universe를 참석하고는 4년 만에 방문하는 샌프란시스코였다. 팬데믹 후에는 샌프란시스코가 많이 위험해졌다는 소식이 많이 들려서 큰 차이 없을 거라고 하면서도 약간 걱정되었다.
막상 갔을 때는 잠시 머무는 여행자 입장에서는 큰 차이가 없게 느껴졌다. 텐더로인이나 시빅센터 부근은 예전부터 좀 위험하다고 생각해서 자주 가진 않는 편이기도 하고 이쪽은 이전보다 약하는 사람도 늘어나고 좀 더 위험해졌는지 몰라도 나는 유니언 스퀘어 부근에서 샌프란시스코 역 사이만 왔다 갔다 하는 편이라 이전과 차이가 없게 느껴졌다. 원래도 좀 길에서 냄새도 나고 노숙자도 꽤 있고 가끔 노숙자가 말도 걸고 그래서 불편하고 그랬기에 이전과 비슷하게 느껴졌다.
아무래도 한번 가기가 쉽지 않다 보니 콘퍼런스보다 일주일 먼저 가서 샌프란시스코에서 머물렀다. 샌프란시스코를 좋아하는 이유 중 하나는 매일 저녁 다양한 밋업이 있다는 것이었고 그 덕에 밋업에 참여하면서 여러 회사 오피스도 방문하고 티셔츠도 생기고 저녁까지 얻어먹고 오면서 저녁까지 심심하지 않기 때문이었다. 하지만 팬데믹 이후 커뮤니티가 회복이 안 되었는지 여기도 5일 다 출근하는 회사가 아직 적기 때문인지 meetup 사이트를 아무리 찾아봐도 갈만한 밋업이 보이지 않았고 오프라인 밋업 자체가 상당히 줄어들어 보였다. 보통 와서 요즘 실리콘밸리는 이런 기술에 관심이 많다는 것을 오프라인에서 느낄 방법의 하나였는데업을 하나도 참가하지 못한 게 가장 아쉬웠다.

코워킹 스페이스

notion imagenotion image
사용자 삽입 이미지
업무를 해야 했기에 코워킹 스페이스를 찾았다. 카페에 가면 노숙자나 이상한 사람들이 들어오기도 하고 화장실 갈 때 짐을 다 싸서 갔다가 와야 해서 불편하기 때문에 코워킹 스페이스를 보통 이용하는 편이다. 예전에 사무실이 WeWork를 이용할 때는 샌프란시스코의 WeWork를 그대로 이용할 수 있었기에 가장 편하긴 했는데 이젠 WeWork도 파산해서 어떻게 되는지는 잘 모르겠다.
이번에 간 곳은 Trellis라는 곳이었는데 가보니 예전에도 가본 곳인데 이름만 바뀐 곳이었다. 하루 이용에 $29인데 사이트에서 예약도 가능하지만, 그냥 입구에서 결제하고 들어갈 수 있다.
notion imagenotion image
사용자 삽입 이미지
여긴 인터넷과 전기는 무료이지만 커피는 바로 옆에 커피숍이 있어서 따로 사 먹어야 한다. 싼지 비싼지 좀 모호하긴 하지만 그래도 책상도 편하고 인터넷도 빠르고 입구에서 등록자만 들어오도록 관리하기 때문에 노트북 놔두고 왔다 갔다 할 수 있어서 좋다. 아쉬운 건 아침 9시부터 저녁 5시까지만 운영한다는 것이다. 그래서 5시에 나와야 했는데 저녁 9시까지 정도만 해도 좋을 텐데 아쉬웠다. 당연히 주말에도 하지 않는다. 어떤 면에서 보면 워라밸이 좋다고 할 수도 있고...
notion imagenotion image
사용자 삽입 이미지
중간에 이동해야 해서 하루 종일 코워킹 스페이스를 이용하기 어려운 날은 그냥 카페를 이용했다. 스타벅스보다는 그래도 Philz Coffee가 쾌적해서 필즈 커피를 이용했다. 당근마켓에 입사한 뒤로는 Wayland라는 영어 이름을 쓰고 있기에 커피숍에 갈 때마다 Wayland라는 영어 이름을 시도했지만, 한번도 성공하지 못했다. 내 발음도 문제지만 일반적으로 사용하는 이름이 아니라서 더 그런 것 같다. 물론 한국 이름으로 불러줄 때도 제대로 된 적이 이전에도 한 번도 없긴 했다.

Google Office

notion imagenotion image
사용자 삽입 이미지
트위터에서 알게 된 Daniel Lee님의 초대로 샌프란시스코에 있는 구글 오피스에도 갔다 왔다. 보통 구글 방문할 때는 마운틴뷰에 있는 오피스만 가봤는데 샌프란시스코 시내에도 구글 오피스가 있는 건 올해 처음 알았다. 시내라 훨씬 가까워서 다녀오기 편했고 내부는 구글 오피스 어디나 비슷한 느낌으로 깔끔하게 인테리어가 되어 있었다.
notion imagenotion image
사용자 삽입 이미지
발코니에 나가서 점심을 먹었는데 베이브리지 뷰가 아주 좋았다. 점심 먹고 오피스에서 몇 시간 일하다가 간식까지 얻어먹고 나왔는데 사진을 찍지 못했다. 이 건물은 Mozilla가 있는 건물이기도 해서 몇 년 전에 방문한 적이 있긴 한데, 오랜만에 다시 오니 역시 경치가 좋았다. 건물 반대쪽으로 가면 Firefox와 Mozilla 로고가 있는 데 간 김에 사진도 한번 찍고 올 걸 그냥 온 게 아쉬웠다.

Meta HQ

notion imagenotion image
사용자 삽입 이미지
기환 님의 초대를 받아서 Meta의 오피스인 MPK 22에 방문했다. 전에도 있었나 기억이 안 나는데 오피스가 꽤 크기 때문에 오피스를 오갈 수 있도록 자전거가 많이 있었고 주차장에 전기차 충전소가 많이 있는 게 부러웠다. 시스템이 있어서 충전 순서가 되면 알림이 와서 내려가서 충전할 수 있다고 한다.
notion imagenotion image
사용자 삽입 이미지
Meta의 오피스는 MPK 20, 21, 22 이렇게 나뉘어져 있지만 건물은 하나라서 이동할 수 있다. MPK 20번 대를 쓰는 곳은 새로 만들어진 오피스이고 구 오피스는 1번 대를 쓰는데, 과거에 해커웨이라고 길의 이름을 짓고 Sun Micro Systems의 간판을 뒤집어서 페이스북의 간판으로 쓴 곳이 구 오피스이다. 몇 년 전에 방문했을 때는 MPK 22까지는 있지 않았던 거 같은데 사무실이 더 커져 있었다.
점심도 맛있었는데 얘기하면서 먹다가 사진 찍는 걸 잊었다. 오피스가 크다 보니 일식, 양식 등 다양한 종류의 구내식당이 있어서 취향에 따라 먹을 수 있었다.
notion imagenotion image
사용자 삽입 이미지
구역마다 분위기가 약간씩 다른데 MPK 22는 신기한 형태로 되어 있었다. 곳곳에 커피도 주고 요거트도 주어서 밖에 나가서도 마시면서 얘기를 나누었는데 캘리포니아는 역시 날씨가 참 좋다. MPK라는 약자가 궁금했는데 Meta가 있는 지역인 Melon Park의 약자라고 한다. Google 오피스로 가는 버스는 Mountain View를 뜻하는 MTV라고 되어 있어서 버스 탈 때 이 약자로 구분해야 한다고 한다. 지역 이름을 쓰는 게 신기했는데 이 지역도 젠트리피케이션이 심하기 때문에 과거 시위 등도 있었고 해서 버스 등에 크게 Facebook이나 Google이라고 쓰는 대신 지역 이름의 약자를 쓴다고 한다.
notion imagenotion image
사용자 삽입 이미지
notion imagenotion image
사용자 삽입 이미지
얘기하면서 고민하다가 구 오피스에 있는 샵에 가고 싶다고 했다. 몇 년 전에 왔을 때도 티셔츠 등을 사 갔었는데 이 Meta의 SWAG을 파는 샵이 구 오피스에만 있었기에 이렇게 초대받아 왔을 때만 살 수 있다. 좀 걸어가야 해서 고민했는데 미리 말할 걸 그랬다. 다행히 시간 여유가 좀 있어서 구 오피스까지 방문했는데 새 오피스와 달리 캠퍼스 분위기가 나서 좋아하는 곳이다. 이날은 무슨 행사가 있는지 사람도 많고 외부 사람으로 보이는 사람들도 많이 있었다.
notion imagenotion image
사용자 삽입 이미지
Meta 로고가 붙은 파타고니아 자켓이 있었는데 가격이 비싸서 고민하다가 파나고니아이기도 하고 또 언제든 살 수 있는 것도 아니라서 티셔츠 몇 개와 함께 구매했다. 팬데믹으로 오랫동안 새로운 티셔츠가 많지 않았는데 오랜만에 새 SWAG이 많이 생겼다.

Meta Office

한 10년 전에 같이 프로젝트를 했던 디자이너가 얼마 전에 유럽에서 샌프란시스코 Meta로 이동했다는 것을 알게 되었다. 몇 년 전에 한국에 오셨을 때 보고 오랜만이라 연락했더니 마침 사무실이 샌프란시스코 시내에 있었다.
notion imagenotion image
사용자 삽입 이미지
시내에도 Meta 오피스가 있는지는 몰랐는데 Park Tower라는 꽤 높은 건물에 있어서 사무실에서 보이는 베이브리지 뷰가 구글 오피스와는 또 다른 느낌으로 좋았다. 샌프란시스코에서 높은 건물에 올라와 볼 일이 없어서 이렇게 높은 곳에서 샌프란시스코를 보기는 처음인 것 같다.
notion imagenotion image
사용자 삽입 이미지
여기는 인스타그램 팀이 있어서 인스타그램으로 인테리어가 되어 있었다. 지금은 광고도 많아지고 예전 느낌이 덜 나지만 그래도 인스타그램은 처음 스타트업으로 나왔을 때부터 여전히 좋아하는 서비스 중 하나이다.

Google Visitor Experience

최근에 마운틴뷰에 Google Visitor Experience가 생겼다는 걸 알고 있어서 딱히 할 일이 없는 주말에는 칼트레인을 타고 내려갔다 왔다.
notion imagenotion image
사용자 삽입 이미지
이 Visitor Experience는 Google의 새로운 오피스인 Gradient Canopy에 위치하고 있었다. 가기 전에는 이 Gradient Canopy 전체가 비지터 센터인 줄 알았는데, 가보니 Gradient Canopy는 구글의 새로운 오피스 건물 이름이었고 비지터 센터는 옆에 작게 있었다. 옆에 언덕에 올라가 보면 이 Gradient Canopy가 여러 개 있는걸 볼 수 있다. 약간 한국의 기와집 느낌도 나면서 건물이 아주 이뻐서 안에도 너무 들어가 보고 싶었다.
notion imagenotion image
사용자 삽입 이미지
구글의 픽셀폰이나 Nest 등 구글의 전자 제품과 SWAG을 살 수 있는 스토어가 있고 옆에는 식당과 카페가 있었다. 설명을 보면 커뮤니티 모임 공간으로 빌려주는 공간도 있는 걸로 보였다.

Apple Visitor Center

notion imagenotion image
사용자 삽입 이미지
Google Visitor Experience 간 김에 지도 보니 Apple 비지터 센터가 멀지 않아서 우버를 타고 들렸다. Apple 비지터 센터는 가본 적이 있긴 하고 혼자 돌아다니다 보니 우버 비용이 싸진 않지만, 마운틴뷰 쪽까지 내려오긴 쉽지 않았고 주말이라 1시간에 1대 있는 기차도 시간이 남아서 어정쩡했다.
notion imagenotion image
사용자 삽입 이미지
Google 스토어와 Apple 비지터 센터에서 티셔츠를 몇 장 샀다. 구글에 오프라인 공룡은 피규어도 있어서 고민했는데 생각보다 너무 크고 어디 놔둘 데가 없어서 그냥 왔다.
notion imagenotion image
사용자 삽입 이미지
일요일은 별다른 일정이 없어서 RetroTech 팟캐스트 대본도 쓸 겸 Sight Glass에서 놀았다. 여긴 샌프란시스코에서 내가 제일 좋아하는 장소인데 유일한 단점으로는 전원있는 자리가 거의 없다는 것이었다. 하지만 이제는 맥북이 M2 맥북이라서 하루 종일 놀아도 배터리 걱정이 크게 없어서 여기서 하루 종일 있을 수 있었다.
하루 종일 이라고 해도 5시까지 밖에 하지 않는다. 스타벅스는 좀 늦게까지도 하는데 스타벅스는 가기 싫었고 내가 가는 필즈커피나 사이트글라스나 다 5시까지만 해서 저녁 먹고 6시면 숙소에 와있었다. 이제는 밋업도 없어서 저녁때 달리 할것도 없었다. 숙소가 최대한 싼 숙소를 잡았기에(SWAG은 100달러 주고 구매하면서도 숙소에 100달러 쓰는 건 너무 아까워서 못 쓰겠다..) 책상이 없어서 침대에 누워서 늦게까지 앉았다 엎드렸다 하면서 컴퓨터를 했다. 또 샌프란시스코에서 7시 정도가 되면 한국이 출근 시간이 되기 때문에 슬랙을 계속 보다 보면 잠잘 시간이 되었다.

Nova 2023

notion imagenotion image
사용자 삽입 이미지
이번에 GitHub Universe에 참석하게 된 것은 내가 GitHub Stars인 것이 크다. 티켓도 지원해 주었고 약간의 여행비도 지원해 준 데다가 Nova 콘퍼런스라는 GitHub Stars를 대상으로 한 프라이빗 콘퍼런스가 있었기 때문이다. GitHub Universe는 수, 목 2일간 진행되는데 Nova 콘퍼런스는 월요일에 진행이 되었다. GitHub Stars는 현재 총 93명이 있는데 처음 생겼을 때가 팬데믹 기간이었기 때문에 그동안 온라인으로만 진행되었고 혹시나 기대했던 작년에도 국가별로 코로나 상황이 달랐기에 온라인으로 진행되었다. 다행히 올해는 오프라인/온라인으로 진행되어서 30여 명의 GitHub Stars가 모일 수 있었다.
notion imagenotion image
사용자 삽입 이미지
행사는 GitHub HQ에서 진행되었는데 사실 그동안 다양한 시도로 GitHub 오피스는 많이 오긴 했다. 그래도 이번엔 정식 초대를 받은 거라 입구에서 등록하니까 왔다 갔다 할 수 있게 스티커를 주었다.
notion imagenotion image
사용자 삽입 이미지
notion imagenotion image
사용자 삽입 이미지
GitHub의 CEO인 Thomas Dohmke의 일정에 맞추기 위해서 인지 행사가 아침 7시부터 시작했다. 너무 일찍 일어나서 와야 했기에 너무 힘들었고 이후에도 여러 GitHub의 발표 세션이 있었지만, Nova의 각 세션은 모두 비밀이다. 대부분은 2일 뒤에 GitHub Universe에서 공개되긴 하지만 Nova는 보통 내부 제품이나 계획을 공개하고 Stars와 의견을 주고받는 형식으로 진행되기 때문에 NDA 하에 진행되므로 공개할 수는 없다.
이 글은 GitHub Universe 2023 참석기 #2로 이어진다.
Response : No Trackback , No Comment