Skip to content
Published on

탈중앙 & P2P 콘텐츠 프로토콜 2026 — IPFS Helia / libp2p / BitTorrent v2 / WebTorrent / Hyperdrive / Iroh / Filecoin / Arweave / Storacha 심층 가이드

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

프롤로그 — "탈중앙"이라는 단어가 너무 많은 것을 가린다

2026년에 "탈중앙 콘텐츠"라고 말하면 사람마다 다른 것을 떠올린다. 어떤 사람은 IPFS의 CID(Content ID)를, 어떤 사람은 토렌트의 매그넷 링크를, 어떤 사람은 Arweave의 "영구 저장"을, 어떤 사람은 Filecoin의 스토리지 마켓을 떠올린다. 누군가는 Jack Dorsey의 Web5 슬라이드를 떠올리며 — 그런데 그건 2024~25년에 거의 멈춰버린 프로젝트다.

이 문서는 그 모든 단어를 하나의 지도 위에 올려놓는 작업이다. 어떤 프로토콜이 살아 있고, 어떤 게 죽었고(Beaker Browser, 2022 RIP), 어떤 게 이름을 바꿨고(web3.storage → Storacha, 2024), 어떤 게 조용히 빌드를 계속하고 있는지(Iroh, Helia, Boxo).

핵심 메시지부터 던지자.

  • IPFS는 "프로토콜"이고, Helia는 그 프로토콜의 모던 JS 구현체다. 둘을 헷갈리면 안 된다.
  • libp2p는 IPFS 안에서 떨어져 나와 자체적인 네트워킹 스택으로 자란 라이브러리다.
  • **BitTorrent v2(BEP 52)**는 2018년 스펙이지만 2026년에도 여전히 "느린 도입" 단계다.
  • WebTorrent는 브라우저에서 토렌트를 하는 거의 유일한 실용 옵션으로 살아남았다.
  • Hyperdrive / Hypercore는 Beaker 브라우저가 죽은 뒤에도 라이브러리로 살아 있다.
  • Iroh는 Rust로 다시 쓴 IPFS — "더 작고, 더 빠르고, 더 모바일 친화적"을 노린다.
  • Filecoin / Arweave / Storj / Sia / Akord는 각자 다른 경제 모델로 살아남았다.
  • Storacha(구 web3.storage), NFT.Storage는 Protocol Labs 계열 무료/저가 IPFS 게이트웨이의 후예다.
  • Web5는 거의 정체 상태다.

이제 하나씩 보자.

1장 · 2026년 P2P 콘텐츠 지도 — 네 가지 큰 분류

P2P 콘텐츠 세계를 머릿속에서 정리하는 가장 쉬운 방법은 네 가지 큰 분류다.

┌──────────────────────────────────────────────────────────┐
│             2026 P2P 콘텐츠 지도                          │
├──────────────────────────────────────────────────────────┤
│ 1. IPFS 계열 (content-addressed, CID)                    │
│    - IPFS Helia (JS)                                      │
│    - Kubo (Go)                                            │
│    - Boxo (모듈 라이브러리)                               │
│    - Iroh (Rust 재상상)                                   │
│    - libp2p (네트워킹 스택)                               │
│                                                           │
│ 2. Hyper 계열 (append-only logs)                          │
│    - Hypercore                                            │
│    - Hyperdrive                                           │
│    - Beaker Browser (RIP 2022)                            │
│    - Dat → Hyper 리브랜드                                 │
│                                                           │
│ 3. BitTorrent 계열                                        │
│    - BitTorrent v1 (1990s)                                │
│    - BitTorrent v2 / BEP 52 (2018, 느린 도입)             │
│    - WebTorrent (브라우저 JS)                             │
│                                                           │
│ 4. Crypto storage 계열 (경제 인센티브)                    │
│    - Filecoin (검증 가능한 스토리지 마켓)                 │
│    - Arweave (영구 저장)                                  │
│    - Storj DCS (S3 호환)                                  │
│    - Sia / Akord                                          │
│    - Banyan Storage (on Filecoin)                         │
└──────────────────────────────────────────────────────────┘

이 네 가지는 서로 보완 관계다. IPFS는 주소화·검색, BitTorrent는 대용량 배포, Hyper는 append-only 데이터 스트림, Crypto storage는 영속성·인센티브 — 각자 잘하는 일이 다르다.

그리고 옆에 살짝 비껴 있는 것들:

  • ActivityPub — Mastodon이 쓰는 페더레이션 SNS 프로토콜. P2P는 아니지만 "탈중앙"이라는 같은 우산 아래.
  • WebRTC 데이터 채널 — 브라우저 간 직접 통신. WebTorrent의 기반.
  • Tahoe-LAFS — 오래된(2008~) 분산 암호화 스토리지. 여전히 살아있다.

2장 · IPFS — Protocol Labs, 진화

**IPFS(InterPlanetary File System)**는 2014년 Juan Benet이 시작한, 콘텐츠 주소화(content-addressed) 분산 파일 시스템 프로토콜이다. 회사 이름은 Protocol Labs.

핵심 아이디어 한 줄: 파일을 위치(URL)로 식별하지 말고, 내용의 해시(CID)로 식별하자.

이게 왜 중요한가:

  • 같은 파일이면 같은 CID. 캐싱·중복제거가 자연스럽다.
  • CID가 같으면 누가 호스팅하든 같은 파일이다. 호스트가 사라져도 다른 노드에 같은 CID로 남아있으면 가져온다.
  • 위변조 불가능. CID는 그 자체로 해시이므로 데이터가 바뀌면 CID도 바뀐다.

IPFS 구현체들의 현재(2026)

오랫동안 IPFS의 두 메이저 구현체는 **Kubo(Go, 옛 go-ipfs)**와 js-ipfs였다. 그런데 2023년에 큰 변화가 있었다.

  • Kubo — 여전히 살아 있고, 활발히 개발되며, 서버·CLI용 표준이다.
  • js-ipfs는 사실상 EOL — 2023년 8월 Helia가 등장하면서 점진적으로 대체되었다.
  • Boxo — Kubo에서 떼어낸 모듈식 Go 라이브러리. IPFS의 "심장"을 그대로 가져다 쓸 수 있게.
  • Iroh — Rust로 다시 쓴 "lite IPFS". Number 0(이전 n0) 팀이 빌드.

이 변화의 핵심은 "단일 거대한 IPFS 데몬"에서 "필요한 부분만 가져다 쓰는 라이브러리"로의 전환이다.

IPFS는 블록체인이 아니다

자주 헷갈리는 부분이라 못 박아두자. IPFS는 블록체인이 아니다. 합의 알고리즘도, 토큰도 기본 IPFS 프로토콜엔 없다. IPFS는 그냥 분산 해시테이블(DHT) 기반 파일 검색이다.

Filecoin이 IPFS와 같은 회사(Protocol Labs)에서 나왔지만, Filecoin이 블록체인 부분이다. IPFS는 "주소 체계", Filecoin은 "그 주소가 누구 디스크에 있는지를 인센티브화하는 마켓".

3장 · Helia (2023.8) — js-ipfs 대체 모던 클라이언트

Helia는 2023년 8월에 Protocol Labs/IPFS 재단이 발표한 JavaScript용 새 IPFS 구현체다. js-ipfs를 거의 갈아엎고 다시 쓴 것에 가깝다.

왜 새로 썼나? js-ipfs가 만들어진 시점(2016~) 이후로 JS 생태계가 너무 많이 바뀌었다. ES 모듈, TypeScript 우선, Web Streams API, 그리고 무엇보다 번들 사이즈에 민감해진 프론트엔드 환경. js-ipfs의 코드는 너무 크고, 너무 무겁고, 너무 빡빡하게 통합되어 있었다.

Helia의 설계 원칙:

  • 모듈식 — 필요한 부분만 가져다 쓴다. 풀-노드를 통째로 임포트하지 않는다.
  • 현대적 JS — ESM, TypeScript 우선, async iterators.
  • 블록 단위 API — "파일"이 아니라 "블록"이 1차 시민. 파일 추상화(UnixFS)는 별도 패키지.
  • 트랜스포트 분리 — libp2p의 어떤 트랜스포트를 쓸지 선택 가능(WebRTC, WebTransport, WebSocket).

간단한 Helia 예시:

import { createHelia } from 'helia'
import { unixfs } from '@helia/unixfs'

const helia = await createHelia()
const fs = unixfs(helia)

// 파일 올리기
const encoder = new TextEncoder()
const cid = await fs.addBytes(encoder.encode('Hello Helia 2026'))
console.log('CID:', cid.toString())

// 파일 읽기
const decoder = new TextDecoder()
let content = ''
for await (const chunk of fs.cat(cid)) {
  content += decoder.decode(chunk)
}
console.log(content)

Helia를 쓰는 시나리오:

  • 브라우저에서 IPFS 노드를 직접 띄우고 싶을 때 — 게이트웨이(ipfs.io 같은) 없이.
  • Node.js 앱에서 가벼운 IPFS가 필요할 때 — Kubo 데몬 띄우기엔 과한.
  • 모바일 PWA / Electron 앱 — 번들 사이즈가 중요한 환경.

4장 · Boxo — 모듈식 IPFS 라이브러리(Go)

Boxo는 2023년에 Kubo에서 떼어낸 Go용 모듈 라이브러리 컬렉션이다. 이름은 "박스의 모음"이라는 뜻.

Helia가 JS 쪽의 "모듈식 IPFS"라면, Boxo는 Go 쪽의 그것이다. Kubo는 풀-노드 데몬, Boxo는 "Kubo가 내부적으로 쓰는 부품들을 외부에서도 쓸 수 있게 정리한 것".

Boxo가 포함하는 것 일부:

  • bitswap — 블록 교환 프로토콜.
  • gateway — HTTP 게이트웨이 구현(/ipfs/CID).
  • blockstore — 블록 저장 추상화.
  • routing — DHT, delegated routing.
  • path resolution — IPLD 경로 해석.

언제 Boxo를 쓰나? 자체 서비스에 IPFS 기능 일부만 가져다 박을 때. 예를 들어:

  • 사내 CDN에 콘텐츠 주소화 추가
  • HTTP 게이트웨이만 별도로 운영
  • 커스텀 IPFS 응용 노드(예: 데이터 마켓플레이스)

Boxo의 등장은 IPFS 생태계가 "풀-노드 IPFS"에서 "라이브러리화된 IPFS"로 이동하는 흐름을 잘 보여준다.

5장 · libp2p — IPFS에서 떨어져 나온 네트워킹 스택

libp2p는 원래 IPFS의 일부였다. P2P 네트워킹에 필요한 모든 것 — 피어 발견, 트랜스포트, 멀티플렉싱, 암호화 — 을 모아 IPFS 내부에서 쓰던 라이브러리. 그런데 이게 너무 좋아서 IPFS 밖에서도 쓰고 싶다는 수요가 생겼고, 결국 별도 프로젝트로 분리됐다.

2026년에 libp2p는 IPFS와 거의 독립된 P2P 네트워킹 표준이다. Ethereum 2.0(Lighthouse, Lodestar, Nimbus), Polkadot/Substrate, Filecoin, Eth2 P2P, Iroh 등이 libp2p를 쓴다.

libp2p의 모듈성

libp2p의 핵심은 "트랜스포트와 프로토콜을 갈아 끼울 수 있다"는 것:

  • Transports — TCP, QUIC, WebSocket, WebTransport, WebRTC, Bluetooth.
  • Security — Noise, TLS 1.3.
  • Muxers — yamux, mplex.
  • Discovery — mDNS, DHT, rendezvous, bootstrap.
  • Pubsub — gossipsub (Eth2가 쓰는 것), floodsub.

JS 예시 — Helia가 내부적으로 만드는 libp2p 노드의 단순화 버전:

import { createLibp2p } from 'libp2p'
import { webSockets } from '@libp2p/websockets'
import { webRTC } from '@libp2p/webrtc'
import { noise } from '@chainsafe/libp2p-noise'
import { yamux } from '@chainsafe/libp2p-yamux'

const node = await createLibp2p({
  transports: [webSockets(), webRTC()],
  connectionEncryption: [noise()],
  streamMuxers: [yamux()]
})

await node.start()
console.log('피어 ID:', node.peerId.toString())

libp2p를 알면 IPFS뿐 아니라 거의 모든 모던 P2P 시스템의 내부를 이해할 수 있다. 거의 표준이다.

6장 · BitTorrent v2 (BEP 52) — 2018 스펙, 2026에도 느린 도입

BitTorrent v2는 2018년에 BEP 52로 명세된 BitTorrent 프로토콜의 큰 업그레이드다. 핵심 변화:

  • SHA-256 해시 (v1은 SHA-1)
  • Merkle tree 기반 파일 검증 — 파일 하나하나가 개별 Merkle 루트를 가진다.
  • 중복 데이터 제거 — 같은 파일이 여러 토렌트에 들어 있으면 한 번만 다운로드.
  • 하이브리드 토렌트 — v1/v2 동시 지원.

기술적으로 v2는 명백한 개선이다. 그런데 2026년 현재까지도 도입은 매우 느리다. 왜?

  • 레거시 토렌트가 너무 많다 — 수십 년 치의 v1 토렌트가 트래커·인덱스 사이트에 쌓여 있다.
  • 클라이언트가 늦게 따라왔다 — qBittorrent, Transmission 등이 점진적으로 지원했지만 v1 폴백이 흔하다.
  • 사용자에게 "이득"이 잘 안 보인다 — v1도 어쨌든 작동한다.

2026년 시점의 v2 현실:

  • qBittorrent / Deluge / Transmission — v2와 하이브리드 지원.
  • uTorrent — 메인 라인은 늦었지만 지원함.
  • WebTorrent — v2 지원 부분적.
  • 트래커 사이드 — v2 인덱싱은 늘었지만 v1이 압도적.

배워야 할 사람:

  • 토렌트 클라이언트 개발자 — v2의 Merkle 검증 로직은 데이터 무결성 보장의 좋은 케이스 스터디.
  • 대용량 파일 배포 인프라(예: Linux ISO, 데이터셋) — 결국 v2로 가야 한다.

7장 · WebTorrent — 브라우저 JS로 토렌트

WebTorrent는 Feross Aboukhadijeh(feross)가 만든 순수 JS, 브라우저 친화적 토렌트 클라이언트다. 데스크톱 WebTorrent 앱도 있지만, 핵심 매력은 브라우저 안에서, 플러그인 없이, 토렌트를 받을 수 있다는 것.

어떻게 가능한가? WebRTC

전통 토렌트는 TCP/UDP를 쓴다. 브라우저는 그 둘 다 직접 쓸 수 없다. WebTorrent는 WebRTC 데이터 채널을 트랜스포트로 쓴다. 그래서 브라우저-브라우저 P2P가 가능하다.

물론 트레이드오프:

  • 전통 토렌트 피어와는 직접 못 만난다 — 별도의 WebRTC 지원 피어(Hybrid 클라이언트)가 있어야.
  • WebRTC 시그널링 서버가 필요 — 첫 연결을 맺으려면 누군가 중개해줘야 한다.

간단한 WebTorrent 브라우저 예시:

import WebTorrent from 'webtorrent'

const client = new WebTorrent()
const magnetURI = 'magnet:?xt=urn:btih:...'

client.add(magnetURI, function (torrent) {
  torrent.files.forEach(function (file) {
    // video 태그에 그대로 스트림
    file.appendTo('#player')
  })
})

WebTorrent가 살아남은 이유:

  • 브라우저 P2P 비디오 스트리밍의 거의 유일한 실용 옵션 — Twitter/X가 한때 검토했고, PeerTube 같은 ActivityPub 비디오 플랫폼이 적극 활용.
  • Feross가 maintain을 계속한다 — 개인 프로젝트 수준의 안정성.

2026년 시점에는 WebRTC P2P 비디오 / 라이브 스트리밍의 사실상 기본 라이브러리.

8장 · Hyperdrive + Hypercore — append-only 로그 기반 파일 시스템

Hypercore는 append-only 로그(추가만 가능한 로그)를 위한 P2P 프로토콜이다. Hyperdrive는 그 위에 올라가는 파일 시스템 추상화.

핵심 아이디어:

  • 모든 데이터는 로그로 저장된다. 변경하지 않고, 끝에 새 엔트리를 덧붙인다.
  • 각 로그는 공개 키로 식별된다. 키를 가진 사람이 "쓰기" 권한자.
  • 같은 키를 알면 누구든 읽고 복제할 수 있다.

이게 왜 IPFS와 다른가? IPFS는 "이미 만들어진 데이터의 콘텐츠 주소화", **Hypercore는 "시간에 따라 자라는 데이터의 P2P 복제"**다. 둘은 다른 문제를 푼다.

Hypercore가 잘 맞는 케이스:

  • 실시간 협업 도큐먼트 — 한쪽이 쓰고 다른 쪽이 따라온다.
  • append-only 데이터셋 — 로그, 감사 추적, 트레이딩 데이터.
  • 버전 관리 — 모든 변경이 로그에 남으므로 자연스럽다.

JS API 예시:

import Hypercore from 'hypercore'

const core = new Hypercore('./my-storage')
await core.ready()

await core.append('첫 번째 엔트리')
await core.append('두 번째 엔트리')

console.log('블록 수:', core.length)
const first = await core.get(0)
console.log(first.toString())

9장 · Beaker Browser (RIP 2022) → Dat → Hyper 리브랜드

Beaker Browser는 2016~2022년 동안 존재한 "P2P 웹 브라우저" 프로젝트였다. 일반 브라우저처럼 보이지만, dat:// 프로토콜로 P2P 사이트를 호스팅·방문할 수 있었다. 한 폴더를 만들고 "publish" 버튼을 누르면 그게 P2P 사이트가 됐다.

2022년에 Beaker는 공식적으로 개발을 중단했다. 그러나 그 기반 기술인 Dat 프로토콜은 죽지 않았다 — Hyper로 리브랜드되어 라이브러리 형태로 살아 있다.

  • Dat 프로토콜 → Hyper(Hypercore, Hyperdrive 등)
  • Beaker 브라우저는 RIP, 하지만 Hyper 생태계는 작은 커뮤니티로 유지
  • Holepunch(Pear Runtime의 모기업) — Hyper를 활용해 P2P 앱 런타임(Keet, Pear)을 만들고 있다.

Beaker가 죽고 Hyper만 남은 이 패턴은 "브라우저는 죽지만 라이브러리는 살아남는다"는 P2P 역사의 흔한 결말이다. 비슷한 사례:

  • ZeroNet — 거의 멈춤, 라이브러리만.
  • Maelstrom (BitTorrent 사의 브라우저) — 일찍 죽음.
  • Beaker — 2022 RIP.

브라우저 벤더 입장에선 P2P 통합은 너무 깊이 들어가서 보안·UX 면에서 부담이 크다. 그래서 라이브러리로 머무르는 게 현실적 균형점이다.

10장 · Iroh (Number 0) — Rust로 다시 쓴 IPFS

Iroh는 Number 0(이전 이름 n0) 팀이 만드는 Rust 기반 IPFS 재상상이다. 2022년경 시작, 2024~25년에 1.0을 향해 빠르게 진화 중.

핵심 메시지: "IPFS의 좋은 아이디어는 가져오되, 기존 구현의 짐(보들)은 버리자."

Iroh의 차별점:

  • Rust — 메모리 안전, 빠른 바이너리, 임베디드/모바일에 친화적.
  • 번들 사이즈가 작다 — 풀 Kubo는 수십 MB. Iroh는 훨씬 가볍다.
  • QUIC 퍼스트 — 트랜스포트 기본이 QUIC(libp2p의 옛 TCP-우선 가정과 다름).
  • 연결 자체에 초점 — "두 디바이스 간 직접 연결"을 가장 큰 목표로.
  • Holepunching 강조 — NAT 너머 P2P를 잘 뚫는 데 많은 엔지니어링.

Iroh는 자기 자신을 **"파일을 P2P로 빠르게 옮기는 라이브러리"**라고 묘사한다. IPFS의 사상은 따르지만, IPFS 메인 스택의 모든 기능을 다 구현하진 않는다.

Rust 예시:

use iroh::Iroh;

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let iroh = Iroh::memory().await?;
    let blob = iroh.blobs().add_bytes(b"Hello Iroh 2026".to_vec()).await?;
    println!("hash: {}", blob.hash);
    Ok(())
}

언제 Iroh를 선택하나?

  • 모바일/임베디드에서 P2P 파일 전송이 필요한 앱.
  • 번들 사이즈가 중요한 데스크톱 앱(Electron/Tauri).
  • Rust 백엔드와 함께 운영하고 싶을 때.

언제 IPFS Kubo를 선택하나?

  • 풀 기능 IPFS 노드가 필요할 때(public gateway, pinning, IPNS, MFS 등).
  • 기존 IPFS 도구·서비스와의 호환성이 중요.

11장 · Banyan Storage / Filecoin / Storj DCS / Arweave / Sia / Akord — 크립토 스토리지의 다섯 갈래

여기서부터는 "파일을 누가 어떻게 보관하느냐"의 경제 모델 이야기다. P2P 프로토콜은 데이터를 어디에 두느냐를 정의하지 않는다 — 그건 별도 시장의 문제다.

Filecoin

Filecoin(Protocol Labs)은 IPFS와 같은 회사가 만든 스토리지 마켓 블록체인이다. 핵심 메커니즘:

  • 스토리지 제공자(SP)가 디스크를 마켓에 올린다.
  • 클라이언트가 "이만큼 저장해줘" 거래를 한다.
  • SP는 PoSt(Proof-of-Spacetime), **PoRep(Proof-of-Replication)**으로 "정말 보관하고 있다"는 걸 주기적으로 증명.
  • 토큰(FIL)으로 지불.

2024~25년에 큰 변화는 FVM(Filecoin Virtual Machine) — EVM 호환 스마트 컨트랙트가 Filecoin 위에 올라가게 됐다.

Banyan Storage

Banyan Storage는 Filecoin 위에 올라가는 **"end-to-end 암호화된 클라우드 스토리지 UX"**다. 일반 사용자가 Filecoin을 직접 만지지 않아도 마치 Dropbox처럼 쓰게 해준다. 백엔드는 Filecoin·IPFS.

Storj DCS (Decentralized Cloud Storage)

Storj는 P2P 분산 스토리지이지만, S3 호환 API를 전면에 내세운다. 핵심 차이:

  • 파일을 80개 정도의 조각으로 erasure coding해서 전 세계 노드에 분산.
  • 그중 일부만 모아도 복원 가능.
  • 토큰(STORJ)으로 결제 가능하지만 신용카드도 OK.

Storj는 **"S3 대안"**에 가까운 포지셔닝. 개발자가 옮겨 오기 쉽게 만들었다.

Arweave

Arweave는 좀 다르다. 키워드는 "영구 저장(permanent storage)". 한 번 결제하면 "200년 보장"을 약속한다.

  • 데이터는 **블록위브(blockweave)**라는 변형 블록체인에 저장된다.
  • 마이너는 새 블록뿐 아니라 과거 블록 일부도 함께 증명해야 한다(Proof of Access).
  • 결제는 일시불 — "이만큼 토큰 내면 영구".

NFT 메타데이터, 학술 자료, 분실하면 안 되는 컨텐츠에 자주 쓰인다.

Sia / Akord

  • Sia — 오래된(2014~) 분산 스토리지. 자체 토큰(SC). 호스트와 렌터 간 직접 계약.
  • Akord — Arweave 위에 올라가는 사용자 친화 UI. 가족 사진 영구 보관 같은 시나리오.

Veera Network

비교적 신생. P2P 콘텐츠 배포·CDN을 노린다. 아직 메인스트림 도달 전.

한 줄 요약 매트릭스

솔루션한 줄
FilecoinIPFS와 짝지어진 스토리지 마켓 블록체인
BanyanFilecoin 위의 사용자 친화 클라우드 UX
StorjS3 호환 분산 스토리지
Arweave"영구 저장"이 핵심인 블록위브
Sia오래된 P2P 스토리지, 호스트-렌터 계약
AkordArweave 위 UI 레이어

12장 · Pintswap / Pollen — P2P 신예

Pintswap은 P2P 토큰 스왑 프로토콜이다. 중앙 매처 없이, libp2p 위에서 OTC(over-the-counter) 거래를 한다. "이 가격에 이거 살래?"를 P2P 메시지로 주고받고 서명만 온체인.

Pollen Network는 P2P CDN 비전. 사용자 디바이스의 유휴 대역폭을 모아 콘텐츠 배포 네트워크를 만든다.

둘 다 2026년 시점에 메인스트림은 아니지만, **"P2P 인프라가 dApp의 하위 레이어로 들어가는 패턴"**의 예시들이다.

13장 · web3.storage → Storacha 리브랜드 (2024)

2020~22년에 web3.storage와 NFT.Storage는 Protocol Labs가 운영하던 **"파일을 던지면 IPFS+Filecoin에 자동 저장해주는 무료/저가 서비스"**였다. NFT 메타데이터부터 학술 데이터셋까지 광범위하게 쓰였다.

2024년에 web3.storage는 Storacha로 리브랜드되며 운영 주체가 분리됐다. 핵심 변화:

  • 이름 변경 — web3.storage → Storacha.
  • UCAN(User Controlled Authorization Networks) 기반 권한 — 토큰 대신 분산형 권한 모델.
  • w3up CLI — 새 클라이언트.

CLI 예시:

# 설치
npm install -g @web3-storage/w3cli

# 로그인 (이메일)
w3 login your@email.com

# 스페이스 생성
w3 space create my-space

# 업로드
w3 up ./my-file.png

운영 안정성 면에서 여전히 IPFS 콘텐츠를 호스팅하기에 가장 접근하기 쉬운 옵션 중 하나.

14장 · NFT.Storage — Protocol Labs

NFT.Storage는 같은 흐름의 자매 프로젝트로, NFT 메타데이터 특화다. 토큰 ID·이미지·attributes JSON을 IPFS에 무료로 올려준다.

2024년에 NFT.Storage는 **NFT.Storage Classic(무료, 최소 지원)**과 **NFT.Storage v2(상업 서비스)**로 분기되었다. 무료 티어 정책이 변하면서 "공짜로 NFT 메타를 영구 저장"이라는 약속에 작은 균열이 갔고, 일부 컬렉션이 Arweave로 이주하기도 했다.

핵심 교훈: "무료 IPFS pin 서비스의 영속성은 항상 의심해야 한다." 누군가는 비용을 댄다.

15장 · Web5 (TBD55, Jack Dorsey) — 정체 상태

Web5는 Jack Dorsey의 Block(옛 Square) 산하 TBD(이후 TBD55로 일컬어진 그룹)가 2022년에 발표한 비전이다. 슬로건은 "Web2의 사용성 + Web3의 분산화, 토큰 없이".

핵심 요소(설계상):

  • DID(Decentralized Identifier) — 사용자가 자기 ID를 소유.
  • VC(Verifiable Credential) — W3C 표준.
  • DWN(Decentralized Web Node) — 사용자 데이터를 노드에 저장.

야망은 컸지만 2024~25년 동안 개발 속도가 크게 떨어졌다. 2026년 시점에서:

  • 메이저 dApp이 Web5를 채택한 사례가 거의 없다.
  • DWN 스펙은 살아있지만 상업적 모멘텀은 약하다.
  • "토큰 없는 Web3"라는 포지셔닝이 결국 Solid, IPFS 등 기존 비-토큰 분산화 흐름과 차별화에 실패했다.

이건 흥미로운 케이스 스터디 — **"슬로건이 강력해도 빌딩 모멘텀이 없으면 죽는다"**의 표본.

16장 · 한국 / 일본 IPFS 사용 사례

P2P 프로토콜은 글로벌이지만, 지역 사례를 보면 어디서 실제로 쓰이는지 감이 잡힌다.

한국

  • NFT 메타 / 디지털 자산 보관 — 클립, 다양한 한국 NFT 프로젝트가 IPFS·Arweave 조합을 채택.
  • 공공 데이터·디지털 아카이브 실험 — 일부 도서관·국가기록원에서 콘텐츠 무결성을 위한 IPFS 보조 활용 검토.
  • ICON / 카카오 클레이튼 계열 — 일부 페이스북 라이브러리 작업, 자체 분산 스토리지 솔루션 실험.
  • 국내 dApp 개발자 커뮤니티 — Helia/Storacha 기반 NFT 마켓플레이스 백엔드.

일본

  • Sony Music / 일본 음반사 NFT 프로젝트 — IPFS를 메타데이터 저장에 활용한 사례 다수.
  • 일본 web3 신청 / NFT 마켓 — 토큰 거래소·NFT 플랫폼에서 표준적으로 IPFS·Arweave 듀얼 호스팅.
  • 출판·아카이브 — 일부 만화·문학 아카이브 프로젝트가 IPFS 백업을 채택.
  • 분산 ID(DID) 실험 — 일본 디지털청 일부 PoC.

공통점: "NFT 메타 + 영구 저장" 시나리오에서 IPFS와 Arweave가 가장 자주 함께 쓰인다.

17장 · 누가 P2P 콘텐츠를 배워야 하나

역할무엇을 봐야 하나
dApp / NFT 개발자IPFS(Helia), Storacha, NFT.Storage 또는 Arweave
분산 시스템 엔지니어libp2p, IPFS Kubo, Iroh 내부
모바일/Tauri 개발자Iroh, WebRTC, WebTorrent
데이터 아키비스트Arweave, Filecoin, Banyan
학술/리서치IPFS, Arweave, Tahoe-LAFS
검열 회피 / 인권 도구IPFS, BitTorrent v2, WebTorrent, libp2p
미디어/CDNWebTorrent, Pollen, Filecoin

"왜 배워야 하나"의 4가지 동기

  1. 영구 저장 — 회사가 망해도 살아남는 콘텐츠. NFT, 학술, 저널리즘.
  2. 검열 회피 — 단일 호스트 의존성을 깨야 하는 시나리오. (그리고 책임도 함께 분산된다.)
  3. CDN 비용 절감 — 대용량 콘텐츠를 P2P로 옮기면 egress 비용이 크게 줄 수 있다.
  4. 연구·해킹의 재미 — libp2p, Iroh, Hypercore는 그 자체로 좋은 시스템 디자인 학습 자료.

"안 배워도 되는" 경우

  • 회사 내부용 일반 웹 앱 — 그냥 S3/Cloud Storage 써라.
  • 빠른 MVP 빌딩 중 — 표준 클라우드가 훨씬 빠르다.
  • 컴플라이언스가 엄격한 산업 — 데이터 위치 추적이 어려워질 수 있다.

P2P는 "기본값"이 아니라 "특정 문제를 풀기 위한 도구"다. 모든 곳에 넣으려 하지 마라.

18장 · 2026년 의사결정 가이드 — 5분 결정 트리

질문답
그냥 IPFS에 작은 파일 던지고 끝내고 싶다Storacha (구 web3.storage)
NFT 메타데이터 호스팅Storacha + Arweave 듀얼
진짜 영구 저장 (수십 년)Arweave
S3를 그대로 대체하고 싶다Storj DCS
브라우저에서 직접 IPFS 노드Helia
브라우저에서 토렌트 / P2P 비디오WebTorrent
모바일에서 P2P 파일 전송Iroh
append-only 협업 데이터Hypercore / Hyperdrive
Rust 백엔드에서 P2PIroh / libp2p (Rust)
검열 저항 비디오 플랫폼PeerTube (ActivityPub + WebTorrent)
토큰 시장 P2PPintswap

에필로그 — 살아남은 것과 그 이유

2014년 IPFS가 등장한 이후 P2P 콘텐츠 세계는 거의 12년의 사이클을 지났다. 그동안 살아남은 것과 사라진 것의 패턴은 분명하다.

살아남은 것의 공통점:

  • 명확한 단일 사명 — IPFS(주소화), Arweave(영구), WebTorrent(브라우저).
  • 라이브러리화 — 풀-앱이 아니라 다른 시스템에 박힐 수 있는 부품.
  • 꾸준한 메인테이너 — Feross, Protocol Labs, Number 0, Holepunch 등 핵심 인물·팀의 지속성.

사라진/정체된 것의 공통점:

  • 너무 큰 야망 — Web5, Beaker Browser.
  • 단일 회사 의존 — 회사가 식으면 같이 식는다.
  • 불분명한 가치 — "그래서 왜 일반 클라우드 대신 이걸 써야 해요?"에 답을 못 함.

2026년의 정답은 **"올인 탈중앙"이 아니라 "선택적 P2P 활용"**이다. NFT 메타엔 IPFS, 영구 저장엔 Arweave, 브라우저 비디오엔 WebTorrent, 그리고 나머지는 그냥 S3 — 이 조합이 실용적이다.

참고 / References

Discuss on Twitter • View on GitHub