ipfs 호환을 끊고 QUIC 하나만 남겼다 — iroh 1.0까지의 설계 결정

iroh가 1.0을 냈고, 회고에서 가장 쓸모 있는 건 새 기능이 아니라 버린 것의 목록이다. ipfs 호환, noise 전환, 스트림마다 붙는 협상 핸드셰이크를 하나씩 내려놓은 기록이 곧 1.0까지 온 경로다.

"It is done. After four years of work and various pivots we have released iroh 1.0." — https://www.iroh.computer/blog/the-road-to-iroh-1-0

호환성을 버리고 QUIC 하나로 줄였다

iroh는 rust로 만든 ipfs 구현에서 시작했다. 방향이 바뀐 계기는 deltachat의 채팅 기록 이전이었다. 백업 blob 하나를 새 기기로 옮기는 일인데, 디스크와 네트워크 사용 제약이 엄격했고 중간에 끊겨도 이어받을 수 있어야 했다. ipfs 기반 구현으로는 이 좁은 요구조차 못 맞췄다. 의존성 트리가 너무 컸다.

그래서 호환을 끊었다.

원문도 기능이 "anemic"했다고 인정한다. 대신 deltachat이 자기 rust 코드베이스에 넣을 수 있을 만큼 가벼워졌다. 기능을 줄이고 첫 실사용자를 얻었다.

TLS는 지키고 인증서 우회는 걷어냈다

RFC 9000의 QUIC는 클라이언트와 서버 역할이 나뉘고, 서버는 인증서 체인으로 식별된다. P2P에 맞추려고 처음에는 자체 서명 인증서의 커스텀 X.509 확장에 실제 공개키를 넣었다. noise로 갈아타고 싶은 마음도 있었지만 TLS를 지켰다. TLS를 빼면 QUIC가 아니라 QUIC 부품을 가져다 쓰는 것에 불과하다는 판단이었다. rustls에 raw public key 지원이 머지되자 곧바로 그쪽으로 옮겼다.

프로토콜 협상은 ALPN 한 번으로 끝낸다

스트림마다 협상 핸드셰이크를 붙이면 그 비용이 스트림 수만큼 쌓인다. iroh는 ALPN TLS 확장을 쓴다. 연결하는 쪽이 후보 목록을 내밀고, 받는 쪽은 그중 하나를 고르거나 핸드셰이크를 거절한다. QUIC 핸드셰이크 안에서 끝나므로 추가 비용은 ALPN 문자열 바이트뿐이다.

다만 대가가 있다. ClientHello가 암호화되지 않아 경로 중간의 관찰자가 어떤 프로토콜을 쓰는지 볼 수 있다. 또 QUIC 연결 하나는 ALPN 하나에만 묶이므로, 프로토콜을 여러 개 쓰면 연결도 그만큼 열린다.

순수성보다 연결 성공을 골랐다

홀펀칭은 공개된 구현 가운데 tailscale 방식을 따랐다. 도와줄 작은 서버가 필요하면 그것도 받아들였다. 홀펀칭이 안 되는 기업 네트워크에서는 릴레이로 데이터를 보낸다. P2P 순수성은 목표가 아니라 포기할 수 있는 항목이었다.

내 기준은 이렇다

나는 P2P 계층을 고를 때 기능 목록보다 뺀 것의 목록을 먼저 본다. 이 회고에서 가져가는 기준은 세 가지다.

1. 호환성 레이어 때문에 성능 상한이 막히면 호환을 끊는다.
2. 협상은 별도 프로토콜로 만들지 않고 이미 있는 핸드셰이크에 태운다.
3. 직접 연결이 실패했을 때 릴레이로 내려가는 경로가 있어야 실제로 쓸 수 있다.

버전 협상을 정교하게 짜 두면 나중에 편하다는 생각은 버리기로 했다. 원문은 하위 호환을 지키며 프로토콜을 진화시키면 테스트할 변형이 조합 폭발한다고 적는다.

안 한 것

• 1.0 이후 벤치마크와 홀펀칭 성공률은 다루지 않았다. 출처에 수치가 없다.
• 직접 돌려 본 결과가 아니다. 출처 회고 글 하나만 읽고 정리했다.
• 언어 바인딩은 원문 기준으로 1.0까지 API가 자주 바뀌어 유지 부담이 컸다. rust가 아닌 언어로 쓸 생각이면 바인딩 상태를 따로 확인해야 한다.
• 경로 중간의 관찰자에게서 프로토콜 이름까지 숨겨야 하면 지금의 ALPN 방식은 맞지 않는다. encrypted client hello는 원문에서 향후 버전에 넣을 수도 있다는 언급뿐이다. h3 같은 흔한 ALPN으로 연결한 뒤 실제 프로토콜을 따로 협상하는 우회법은 있다.

iroh 1.0은 기능을 더해서가 아니라 호환성·협상·순수성을 덜어내서 도달한 버전이다.