임백준님이 번역 하였고, 개발자나 팀장 보다는 소프트웨어 개발 임원이나 CTO가 보면 도움이 많이 될 책입니다. 사실 개발 임원이 어떤 일을 하고 어떤 자세가 필요한지에 대해서는 읽을 거리가 부족한 것이 사실입니다. 이번에 이 책을 읽어 보니 제가 하고 있는 일 중에서 이미 책에 나와 있는 내용도 있었고, 새로 보거나 생각만 하고 있었는데 하고 있지 않았던 일도 나와 있어서 여러모로 반성할 기회도 되었습니다.

특히 M&A나 구직, 퇴사 등의 내용은 일반적으로 쉽게 찾을 수 있는 내용이 아니므로 개발자라고 해도 한번 읽어보면 자신의 회사 임원이 어떤 일을 하는지, 어떤 시각으로 바라보고 있는지 알 수 있는 좋은 기회가 되지 않을까 합니다.

번역서입니다만 책 말미에 부록으로 국내 다른 개발 임원들이 자신의 경험을 한 꼭지씩 쓰신 부분이 추가 되어 있는데, 저도 참여하게 되어서 영광이었습니다. 책 맨 마지막에 들어 있습니다.

아무래도 미국 책이라 미국식 엔지니어링 관리에 대한 책입니다. 실제 미국에서 일할 때 보고 듣던 일이 많이 써 있어서 해외진출하는 개발조직이나 해외 개발 조직을 직접 관리하는 입장이라면 읽어 보시면 좋겠습니다.

freebsd-rustdate라는 프로젝트를 최근에 보게 되었습니다. 기존의 freebsd-update(8)을 rust로 재구현한 프로젝트라고 하는데, 기존 도구와 호환성도 있고 기존의 FreeBSD 업데이트 서버를 이용하고 있다고 하여 큰 주의사항 없이 시도해 볼 수 있겠다는 생각이 들었습니다. 이번에는 개인 서버를 업그레이드하는데 사용해 보았습니다.

결론적으로는 문제없이 잘 동작하였습니다. 기존에 설치되어 있던 FreeBSD 14.1-RELEASE 은 소스에서 빌드한 것이라 업데이트가 가능할지 궁금하였는데 아마 업그레이드라서 그랬는지는 모르겠지만 기존 바이너리는 그대로 덮어 쓰는 것으로 보입니다.

이 도구는 pkg 에서 구할 수 있으므로, 홈페이지에 나와 있는 것 처럼 소스에서 설치해도 되지만 그대로 pkg 를 이용하면 됩니다.

# pkg install freebsd-rustdate

이 글을 쓰는 시점에서의 최신 버전은 1.0.1 이었습니다.

% pkg info freebsd-rustdate
freebsd-rustdate-1.0.1_2
Name           : freebsd-rustdate
Version        : 1.0.1_2
Installed on   : Sun Dec  8 13:41:49 2024 UTC
Origin         : sysutils/freebsd-rustdate
Architecture   : FreeBSD:14:amd64
Prefix         : /usr/local
Categories     : sysutils
Licenses       : BSD2CLAUSE
Maintainer     : fullermd@over-yonder.net
WWW            : https://rustdate.over-yonder.net/
Comment        : Faster freebsd-update replacement

FreeBSD 14.1-RELEASE 에서 14.2-RELEASE로 업그레이드

현재 버전을 확인해 봅니다.

% freebsd-version -ku
14.1-RELEASE
14.1-RELEASE

이제 FreeBSD 14.2 로 업그레이드를 시작해 봅니다.

# sudo freebsd-rustdate upgrade -r 14.2-RELEASE
Currently running 14.1-RELEASE.
Loading info for 14.1-RELEASE.
Trying server update2.freebsd.org....   OK.
Loading metadata index for 14.1-RELEASE...   OK.
Getting metadata files for 14.1-RELEASE...  2 missing.
...

기존 서버가 GENERIC커널을 그대로 쓰지 않고 다른 커널 설정을 사용하고 있었는데, 업그레이드하면서 덮어 쓰겠다는 의미입니다. 제 경우는 덮어 써도 문제가 없어서 그대로 두었는데 커널을 다시 빌드하지 않으면 부팅이 안되거나 하는 경우라면 주의해야 합니다.

    WARNING  --  WARNING  --  WARNING
This system is running a *** kernel, which is not
a distributed kernel config.  As part of upgrading, this
kernel will be replaced with a GENERIC kernel.
    WARNING  --  WARNING  --  WARNING

나머지 과정이 진행 됩니다.

...
Trying to merge 4 files.
4 files merged cleanly.
Run `freebsd-rustdate show-merges` to review.

Upgrade will remove 9 files, add 56 files, and update 6838 files.
Run `freebsd-rustdate show-merges` to review merge results.
Run `freebsd-rustdate show-install` to see details of what will be installed.

Run `freebsd-rustdate install` to upgrade from 14.1-RELEASE to 14.2-RELEASE.

업데이트할 파일을 받아서 설치하고, /etc 아래 설정 파일을 자동으로 병합해 줍니다. 이번 경우에는 자동으로 처리 되었는데 필요하면 수동으로 병합해 주어야 할 수 있습니다. 직접 보지는 못했는데 아마 기존 etcmerge 랑 비슷할 거라 봅니다.

show-merges 해도 잘 병합 된 것을 (다른 점이 없음) 알 수 있습니다.

# freebsd-rustdate show-merges
Pending upgrade from 14.1-RELEASE to 14.2-RELEASE.
4 merged files

diff /etc/group
--- /etc/group  (original)
+++ /etc/group  (modified)

diff /etc/master.passwd
--- /etc/master.passwd  (original)
+++ /etc/master.passwd  (modified)

diff /etc/shells
--- /etc/shells  (original)
+++ /etc/shells  (modified)

diff /etc/sysctl.conf
--- /etc/sysctl.conf  (original)
+++ /etc/sysctl.conf  (modified)

이제 freebsd-rustdate install을 실행해서 커널을 설치 합니다.

# freebsd-rustdate install
Installing pending upgrade from 14.1-RELEASE to 14.2-RELEASE
Checking required files are present...   10848 hashfiles...  Ok.

...

Kernel updates have been installed.  Please reboot and run
`freebsd-rustdate install` again to finish installing updates.
Note: you may need to update your UEFI bootblocks.

커널이 설치 되었으므로 리부팅합니다.

# reboot

재부팅이 안되면 콘솔로 접속해서 어떤 문제인지 살펴 보기 바랍니다. 필요하면 이전 버전 커널로 다시 부팅해야 합니다. 제 경우에는 문제없이 ssh 연결이 다시 가능 했습니다.

% freebsd-version -ku
14.2-RELEASE
14.1-RELEASE

커널만 14.2-RELEASE 인 것을 알 수 있습니다. 이제 나머지 부분을 계속해서 설치 합니다.

# freebsd-rustdate install
Installing pending upgrade from 14.2-RELEASE to 14.2-RELEASE
Checking required files are present...   10848 hashfiles...  Ok.
Creating snapshot of existing boot environment: (14.2-RELEASE_2024-12-08_132128)...  Done.
...
Installing world...
...
Rebuilding passwd db...  Done.
Rebuilding login.conf db...  Done.
Rebuilding manpage indices...  /usr/share/man /usr/share/openssl/man Done.

World update installed.
Deleting 9 paths...   Done.

Upgrade complete.

마지막 문장이 출력되면 잘 된 것입니다. 버전을 다시 확인해 봅니다.

% freebsd-version -ku
14.2-RELEASE
14.2-RELEASE

이걸로 업그레이드는 완료 하였습니다만, 한번 더 리부팅하는 편이 깔끔하게 시작할 수 있으니 리부팅을 한번 더 해 줍니다.

# reboot

다시 돌아 오면 다른 문제가 없는지 확인 합니다.

패키지 재설치

기존에 설치된 패키지를 업그레이드 합니다. 깔끔하게 하려면 업그레이드할 필요 없는 동일한 버전이라도 다시 덮어 쓰도록 -f 옵션을 주어서 업그레이드합니다.

# pkg-static upgrade -f
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking for upgrades (268 candidates): 100%
Processing candidates (268 candidates): 100%
The following 238 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
	brotli: 1.1.0,1
	p5-Class-Inspector: 1.36
	p5-File-ShareDir: 1.118

Installed packages to be UPGRADED:
	abseil: 20230125.3 -> 20240722.0
	apr: 1.7.3.1.6.3_1 -> 1.7.5.1.6.3_3
	bash: 5.2.26_1 -> 5.2.37
	boehm-gc: 8.2.6 -> 8.2.8
...

이제 완료입니다! pkg 로 설치한 것 중 부팅할 때 실행되는 것들이 있다면 (네트워크 서비스 등) 깔끔하게 다시한번 리부팅하는 것도 좋겠습니다.

끝으로

freebsd-rustdate 가 생각보다 깔끔하게 실행되어서 놀랐는데, 다음에는 일반 업데이트를 한번 시도해 볼 생각인데 기대가 크네요. 아직 rust 기반 시스템 유틸리티는 없는 것으로 아는데, FreeBSD 기반 시스템에 도입 논의가 있는 것으로 보이니 향후가 기대 됩니다.

Catenoid Techblog

1호 글 중 하나로 회사 리눅스 스트리밍 서버에 TCP BBR 혼잡 제어 알고리즘을 적용하는 기사를 작성 하였습니다.

• TCP BBR로 비디오 스트리밍 품질 개선

저에 대한 간단한 소개도 포함한 해당 기사의 배경에 대한 더 자세한 글은 회사 블로그에서 찾아보실 수 있습니다.

• 카테노이드의 ‘테크 블로그’에서 최적의 동영상 서비스를 위한 기술 노하우를 만나보세요!

제 글 이외에도 여러가지 회사에서 사용하는 기술에 대한 이야기가 있으니 관심 있는 분들은 주기적으로 많이 읽어 주시기 바랍니다!

기존에 공개된 것과 동일한 영상입니다만 rev.2 에서는 무음이나 불필요한 말 등이 수정이 되었고, 영상의 전체 길이가 39분에서 27분으로 줄었습니다.

일년이 조금 지난 자료라 지금은 약간 달라진 점은 있지만, 기본적인 사항은 변하지 않았으므로 QUIC과 HTTP/3의 기초에 대해 알고 싶은 사람을 위해 한국어로 된 좋은 자료가 될 거라 생각 합니다.

슬라이드도 같이 공개되어 있습니다.

그리고 내 (현재) 첫번째 유튜브 공개 영상입니다!

p.s. 2023년에 아슬아슬하게 시간을 맞추긴 했는데 새해에는 영상을 더 많이 올렸으면 좋겠네요.

클라우드플레어 회사와 개발 문화, QUIC, HTTP/3 관련된 프로토콜 개발 등 최근에 저에게 관련 있던 주제들에 대해서 이야기를 하니 관심 있는 분들은 들어 주셔도 좋겠습니다.

(업데이트 - 편집본이 올라와서 다시 올립니다)

p.s. 일년 넘게 포스팅이 없었네요. 올해에는 좀 더 노력하도록 하겠습니다.

그런데 시계를 돌려서 2020년대를 보면 이제 GPL은 더 이상 새로 나오는 오픈 소스 어플리케이션의 주류 라이센스로 보이지는 않는다. 최근에 유명한 오픈소스인 k8s도 Apache 2.0 라이센스이고, 안드로이드 운영체제에서 리눅스 커널 이외에는 Apache 2.0 라이센스가 사용되고 있다. 대부분의 자바스크립트 프론트엔드 소프트웨어도 마찬가지고, 대부분 데이터과학 및 머신러닝 소프트웨어도 GPL이 아니다 (tensorflow는 Apache 2.0 라이센스, pandas는 BSD).

또한 과거에는 GNU/Linux라 할 정도로 리눅스 배포본의 핵심 요소였던 GNU 소프트웨어군도 예전같지 않고, GNU은 원래 커널을 포함하여 완결된 운영체제를 갖출 예정이었지만 아직도 갈 갈이 멀다. 또한 널리 사용되는 python, node, rust, ruby, perl 등등의 언어는 본체 포함 관련 라이브러리도 절대 다수가 BSD/MIT/Apache 라이센스이다.

즉 최근에 새로 개발되는 유명한 소프트웨어에서 GPL이 사용되는 걸 별로 본 적이 없다 (있다면 git, systemd 정도). GPL v2의 단점을 보완해서 GPL v3 이 나온지 꽤 오래 되었지만 그리 많이 사용되지 않는다. GPL v3의 대표적인 소프트웨어가 gcc인데, 이제는 clang/llvm이 거의 대체 가능할 만큼 따라왔다. clang/llvm은 BSD라이센스이고. 프로젝트 초기부터 gcc로 빌드하던 FreeBSD은 이제 clang으로 빌드/배포된다.

이에 대해서는 여러가지 이유를 생각해 볼 수 있겠지만, 과거에는 소프트웨어가 주로 설치형이었고, GPL의 기본 사상은 설치형 소프트웨어가 닫힌 소스로 재배포되는 것을 막기 위해 수정된 소스도 동일 라이센스로 배포하도록 하자는 것이라 생각된다. 그런데 90년대가 되고 인터넷 사용이 늘어나면서 서버를 통해 제공되는 서비스 (WWW 등)의 사용이 늘어 났는데, 이 경우 GPL소프트웨어는 서버에 설치 해서 내부적으로 고쳐서 써도 소스 재배포에 해당되지 않으므로 인터넷의 발전과 GPL은 크게 충돌하지 않았다.

설치형 소프트웨어도 아직 많이 존재 하지만 약간 그 형태가 달라졌다. 안드로이드와 같이 일반 사용자 디바이스에 설치된 것은 어느정도 이전의 설치형 소프트웨어에 해당되지만 브라우저에서 동작하는 자바스크립트로 작성된 소프트웨어들은 소스가 자동적으로 공개 되므로 굳이 GPL로 할 이유가 없다.

여기에 추가하여 최근 10여년 간의 큰 중요한 변화는 클라우드/SaaS 서비스인데, 설치된 소프트웨어를 사용자에게 직접 배포하지 않지만 네트워크를 통해서 이용하는 (데이터베이스, 가상머신 등) 방식이 주류가 되어 가면서 GPL은 또한 선호되지 않는다. 최근의 아마존 vs 엘라스틱과 같은 경우를 보면 아예 클라우드/SaaS용 (직접 설치가 아니라 서비스 제공용) 소프트웨어 라이센스를 별도로 지정할 정도로 클라우드/SaaS는 새로운 소프트웨어의 용도로 정착하고 있다 할 것이다. 다만 엘라스틱과 같은 경우는 SaaS이용을 막으려다 보니 아예 오픈 소스가 아니게 되었다.

그리고 이제 오픈소스 개발은 대부분 대형 IT회사가 주도하고 있다. 이런 회사들은 소프트웨어 자체에서 이익을 얻지 않으므로 (구글, 아마존, 페이스북 등) 역설적으로 소프트웨어 공개에 특별한 제약을 두려 하지 않고 따라서 그런곳에서 공개하는 소스는 Apache/BSD/MIT 라이센스가 주류를 이루고 있다.

반대로 회사에서 외부 오픈 소스를 가져다 쓰는 것도 보편화됨에 따라 외부 소스를 가져다 쓸 경우 라이센스를 체크하는 일정 크기 이상의 조직인 경우 GPL 소스는 자사 소프트웨어 개발에 아예 사용 못하게 하거나 변경 및 재배포 여부를 엄격히 체크 한다.

따라서 신규 소프트웨어의 GPL도입율 저하 및 GPL이용율의 저하 경향이 지속될 경우 GPL은 점점 도태될 가능성이 높다 할 것이다.

4개의 RFC로 나누어져 있습니다. 각각은 다음과 같습니다.

• RFC 8999 Version-Independent Properties of QUIC - 통칭 Invariants. 버전에 관계 없이 공통적인 사항에 대한 것입니다.
• RFC 9000 QUIC: A UDP-Based Multiplexed and Secure Transport - 통칭 Transport. 제일 중심이 되는 내용으로 패킷 포맷, 상태 머신, 기본적인 동작에 대해 다루고 있습니다. QUIC에 대해 알고 싶다면 여기부터 읽어 보세요.
• RFC 9001 Using TLS to Secure QUIC - 통칭 QUIC-TLS. QUIC은 기본적으로 암호화를 해야 하는데 TLS 1.3 기반으로 약간의 확장을 더하고 있습니다. TLS 1.3에 대해서 기본적으로 이해가 있어야 합니다.
• RFC 9002 QUIC Loss Detection and Congestion Control - 통칭 Recovery. Transport에 추가하여 손실 복구 및 혼잡 제어 알고리즘에 대해서 다룹니다.

아마 출력하면 수백 페이지 분량일 것입니다. 8999는 짧은 편이지만 나머지 3개 RFC는 내용이 방대하고 전송 프로토콜에 대한 내용이라 TCP와 TLS에 대한 사전 지식이 있다면 보다 읽기 쉬울 것입니다. 지금부터 읽고자 한다면 사전 지식 없어도 먼저 한번 읽어 보고, 필요한 부분을 추가적으로 다른 RFC를 읽어 가면서 보충하는 방법을 권장합니다.

개인적으로는 UDP기반 전송 프로토콜을 작성하는 것을 이전 스타트업(Neumob)에서 시작했고 지금 회사(Cloudflare)에서 QUIC관련 업무를 (quiche 기반 HTTP/3 서비스) 하고 있어 2019년부터 관련 활동에 일부 참여하였습니다. RFC9002에 몇줄 공헌한 것도 있고 해서 정식으로 RFC가 되다니 감회가 새롭네요.

회사 블로그에 관련된 기사를 올린적이 있고요.

• quiche의 CUBIC와 HyStart++ 지원
• A cost-effective and extensible testbed for transport protocol development

이 블로그에서도 기본적인 소개 글을 쓴적이 있습니다.

• QUIC과 HTTP/3 - 1. UDP기반 전송 프로토콜의 대두
• QUIC과 HTTP/3 - 2. 기존의 성능 개선 기법 및 한계
• QUIC과 HTTP/3 - 3. curl + quiche 로 HTTP3 요청해 보기

이번 RFC는 QUIC관련이고, 상위 레이어인 HTTP/3 관련은 다른 워킹 그룹에서 별도로 리뷰하는 것으로 알고 있으니 관련 스펙 (HTTP/3, QPACK)은 추후 RFC가 될 것으로 알고 있습니다.

HTTP/2가 2015년에 발표된 이후 HTTP와 전송 프로토콜 관련해서 제일 큰 변화라고 생각 됩니다. 향후 많은 분야에서 활용되지 않을까 싶습니다.

• 한글: Firefox Nightly에서 HTTP/3 과 QUIC을 시험해 보기
• 영문: How to test HTTP/3 and QUIC with Firefox Nightly

저도 Firefox Nightly 쓰면서 기본으로 http3를 켜 두고 있습니다. 대부분 별 문제 없는데 버전에 따라서 일부 타임아웃 현상이 발생한 적이 있었습니다. 특히 구글 사이트 (gmail 이나 youtube 등) 이 안되는 경우라면 http3 를 사용중이면 한번 끄고 다시 해 보는 것도 도움이 됩니다.

p.s. Cloudflare 블로그에서 한글로 번역된 글은 다음 링크에서 모두 찾을 수 있습니다. 번역글은 원본 글과 같은 시간으로 포스팅 시간을 조정하기 때문에 블로그 홈페이지에서 바로 보이지 않을 수 있습니다.

• https://blog.cloudflare.com/tag/korean/

• RFC 8890 The Internet is for End Users

RFC8890이 나왔는데 인터넷은 엔드유저 (사용하는 사람)을 위한 것이라는 점을 강조하는 내용입니다. IETF는 RFC를 출간하는 조직인데 인터넷 프로토콜 표준을 만드는 것으로 알려져 있지만 사실 표준은 아니고 RFC를 작성할 뿐 실제 구현은 회사나 개발자에 의해 좌우됩니다. 가령 리눅스 커널의 TCP 코드를 보면 RFC에 없는 내용이 많이 포함되어 있지만 인터넷 대부분 트래픽을 차지하는 것이 현실이지요.

그리고 순수하게 기술적이지만도 않은게 은연중에 정치적 결정을 하는 경우도 존재하며 그리고 이는 국가간 또는 세력간에 손익을 발생시키기도 합니다. 한국의 예를 들자면 불법 사이트 차단을 위해 주요 ISP의 DNS에서 블랙리스트를 적용하는 것이나 SNI 정보를 이용하는 것을 들 수 있습니다. DNS over HTTP (DOH)/DNS over TLS (DOT)가 만들어졌을 때 이슈 중 하나는 DNS에 의존하는 사이트 차단 기능을 본질적으로 우회할 수 있다는 것인데, 대형 ISP DNS에서 차단하는 사이트라도 DOH를 쓰고 공개된 리졸버를 쓰게 되면 국가의 DNS 차단을 우회하게 됩니다. 가령 아동성범죄나 마약거래와 같은 불법 사이트 차단을 DNS/SNI 차단에 의존하고 있는 국가는 DOH 나 ECH (Encrypted Clieht Hello)와 같은 기법이 메이저 브라우저에서 기본 적용되는 것을 반기지 않을 것이고 따라서 실제로 파이어폭스 브라우저의 DoH설정이 국가별로 다른 경우가 일어나고 있습니다.

IETF는 검열에 관한 기술을 다루지 않으므로 DNS 관련 RFC에는 차단 방법에 대한 내용은 없지만 각 국가의 법령에 따라 실제 소프트웨어에는 구현되어 있는 경우가 다수 있습니다. 이러한 현실 위에서 검열을 피할 수 있는 DOH/DOT/ECS와 같은 새로운 기술은 기존 법령과 충돌을 일으킬 수 있지만, 또 그걸 뒷받침할 수 있도록 RFC를 작성하지도 않는다는 것입니다. 가령 한국이나 중국 정부에서 IETF에 인력을 파견해서 DOH/DOT나 ECH의 RFC작업을 하지 말라거나 검열이 가능하도록 백도어를 넣게 압력을 넣어 볼 수는 있겠지만 받아들여지지 않을 것이겠지요.

또 다른 예로 최근에 중국에서 TLS 1.3패킷을 검사하여 ESNI가 사용 중이면 연결을 끊는 사례가 보고되어 있는데, 그렇다고 IETF가 ECH개발을 중지하지도 않는다는 의미입니다. 이미 ESNI를 지나서 ECH라는 보다 발전된 기술이 논의되고 있습니다. ECH를 통해서 부가적인 프라이버시를 얻는 사람도 있지만, 이를 통해서 놓치는 범죄자들도 있을 것입니다.

이런 기준은 국가마다 다르고 동일한 잣대로 판단하는 것이 어려운 경우가 많습니다. 하지만 RFC의 내용은 최대한 일반 사용자의 이익이 되는 방향으로 가야 한다는 것입니다.

• 한글: HTTP/2 업로드 속도 향상기
• 영문: Delivering HTTP/2 upload speed improvements

의외로 반응이 좋네요. 처음에 글 올린 이후에 패치를 오픈소스하기로 해서 글 가장 끝을 보시면 패치 올린 링크가 있습니다.

그리고 어떤 유튜버가 리뷰를 하였더군요… 테크 블로그 글 리뷰하는 유튜버가 있는줄은 처음 알았습니다.

p.s. Cloudflare 블로그에서 한글로 번역된 글은 다음 링크에서 모두 찾을 수 있습니다. 번역글은 원본 글과 같은 시간으로 포스팅 시간을 조정하기 때문에 블로그 홈페이지에서 바로 보이지 않을 수 있습니다.

• https://blog.cloudflare.com/tag/korean/