빅테크 클라우드 없이 기기끼리 직접 연결, Iroh 1.0이 다시 꺼낸 P2P의 꿈

우리가 주고받는 거의 모든 데이터는 누군가의 서버를 한 번 거칩니다. 메신저 한 줄, 사진 한 장도 결국 빅테크의 클라우드를 경유하는데요. 그런데 두 기기를 중간 서버 없이 직접 잇겠다는 프로젝트가 최근 1.0 정식 버전을 냈습니다. Rust로 만든 P2P 네트워킹 스택 Iroh입니다.

오늘은 솔직하게 짚고 시작하겠습니다. 이번 주제는 커뮤니티 화제성 데이터가 거의 잡히지 않았습니다. 신제품 출시 직후의 떠들썩한 반응을 기대하기는 어려웠는데요. 그래서 오늘 글은 커뮤니티 여론 정리보다는, 이 기술이 무엇을 풀려고 하는지와 그 한계를 차분히 뜯어보는 쪽으로 가겠습니다.

P2P가 왜 이렇게 어려운 문제였나

P2P, 즉 기기끼리 직접 연결한다는 아이디어 자체는 새롭지 않습니다. 토렌트가 그랬고, 옛날 메신저들도 그랬죠. 문제는 현실의 인터넷이 그렇게 친절하지 않다는 데 있습니다.

대부분의 기기는 공유기 뒤에, 통신사 NAT 뒤에 숨어 있습니다. 외부에서 곧장 찾아갈 수 있는 고정 주소가 없는 셈인데요. 그래서 두 기기가 서로를 발견하고, 방화벽을 뚫고, 직접 통로를 여는 일은 생각보다 까다롭습니다. 이 홀펀칭(hole punching)이라 불리는 과정이 P2P의 진짜 난관입니다.

결국 많은 서비스가 포기하고 중앙 서버로 돌아갔습니다. 모든 트래픽을 클라우드가 중계하면 연결은 확실하지만, 비용과 종속성이 따라옵니다. Iroh는 바로 이 지점을 다시 공략합니다.

Iroh가 내세우는 핵심: “어떤 기기로든 다이얼”

Iroh의 슬로건을 한 문장으로 줄이면 dial any device입니다. 상대 기기의 공개키만 알면, 그 기기가 와이파이 뒤에 있든 LTE 위에 있든 직접 연결을 시도하겠다는 겁니다.

작동 방식은 이렇습니다. 먼저 가능한 모든 경로로 직접 연결을 노립니다. 홀펀칭이 성공하면 두 기기는 진짜로 직접 통신합니다. 만약 직접 연결이 끝내 안 되면, 그때만 중계(relay) 서버를 통해 우회합니다. 핵심은 직접 연결을 기본값으로 두고, 중계는 최후의 수단으로 둔다는 점인데요. 게다가 연결 도중에 네트워크가 바뀌어도 경로를 알아서 다시 잡습니다. 와이파이에서 셀룰러로 넘어가도 연결이 끊기지 않는다는 뜻입니다.

전송 계층으로는 QUIC을 씁니다. 구글이 만들고 이제 HTTP/3의 기반이 된 그 프로토콜입니다. TCP보다 연결 수립이 빠르고, 암호화가 기본이며, 한 연결 안에서 여러 스트림을 독립적으로 굴릴 수 있습니다. P2P처럼 불안정한 환경에서 특히 강점을 보이는 설계죠.

1.0이라는 숫자의 무게

오픈소스에서 1.0은 단순한 버전 표기가 아닙니다. “이제 API를 함부로 바꾸지 않겠다"는 약속에 가깝습니다.

그동안 Iroh를 실험적으로 써보고 싶어도 망설였던 개발자들이 있었을 겁니다. 0.x 버전은 다음 업데이트에서 인터페이스가 통째로 바뀔 수 있으니까요. 1.0은 그 불확실성을 걷어내는 신호입니다. 실제 서비스에 넣어도 되겠다는 안정성의 선언인 셈인데요.

다만 여기서 냉정해질 필요가 있습니다. 1.0이 “완성"을 뜻하지는 않습니다. P2P의 근본 난제인 NAT 환경의 다양성, 모바일 네트워크의 변덕, 그리고 직접 연결이 실패할 때의 중계 비용 문제는 버전 숫자가 올라간다고 사라지지 않습니다.

중계 서버라는 불편한 진실

Iroh를 이야기할 때 가장 정직하게 짚어야 할 부분이 바로 이 중계 서버입니다.

“완전한 P2P, 탈중앙"이라는 표현은 멋지지만, 현실에서 직접 연결이 100% 성공하지는 않습니다. 통신사 환경에 따라 홀펀칭이 막히는 경우가 분명히 있고, 그때는 중계 서버가 트래픽을 받아줘야 합니다. 이 서버를 누가 운영하고, 누가 비용을 대느냐가 남습니다.

물론 이 중계 서버는 직접 운영할 수 있습니다. 특정 회사의 클라우드에 묶이지 않는다는 점에서 기존 중앙집중 모델과는 분명히 다른데요. 그래도 “서버가 아예 없다"가 아니라 “서버 의존을 최대한 줄이고, 그 서버마저 내가 통제할 수 있다"가 더 정확한 표현입니다. 이 차이를 흐리면 기대가 어긋나기 쉽습니다.

그래서 어디에 쓰나

추상적으로만 들리지 않게 그림을 그려보겠습니다. 기기 간 파일 동기화, 로컬 우선(local-first) 앱, 협업 편집 도구, 분산형 메시징 같은 영역이 후보입니다. 중앙 서버에 모든 데이터를 쌓아두지 않고도 기기끼리 상태를 맞추고 싶은 모든 경우인데요.

Rust로 작성됐다는 점도 무시할 수 없습니다. 메모리 안전성과 성능을 동시에 챙기려는 시스템 소프트웨어에서 Rust는 사실상 기본 선택지가 됐습니다. 네트워킹 스택처럼 오래 켜두고 안정적으로 돌려야 하는 코드에는 특히 어울리는 선택입니다.

마무리

Iroh 1.0은 “클라우드 없이도 기기끼리 직접 연결할 수 있다"는 오래된 꿈을, 이번에는 꽤 현실적인 엔지니어링으로 풀어낸 시도입니다. 직접 연결을 기본으로, 중계를 보조로 두는 실용적 절충이 핵심인데요. 환상 대신 “줄일 수 있는 만큼 의존을 줄인다"는 태도가 오히려 신뢰를 줍니다.

당신이 만드는 서비스의 데이터는 꼭 누군가의 서버를 거쳐야만 할까요. 아니면 기기끼리 직접 이야기하게 두는 편이 더 나을까요. 이 질문이 다시 진지하게 던져지는 시대가 온 것 같습니다.