IPFS

1.개요

IPFS는 '행성 간 파일 시스템(InterPlanetary File System)'의 약자로, 파일을 여러 컴퓨터에 분산 저장하고 공유하기 위한 P2P 프로토콜이다. 2015년 프로토콜 랩스(Protocol Labs)의 후안 베넷(Juan Benet)이 개발했으며, 오픈 소스로 공개되어 있다. 이름의 '행성 간'은 통신 지연이 크고 연결이 불안정한 환경에서도 데이터를 주고받을 수 있는 시스템을 지향한다는 뜻을 담은 표현으로, 실제 대상이 지구 밖 통신망은 아니다.

기존 웹은 파일이 저장된 서버의 위치(URL, 주소)를 기준으로 데이터를 찾는 '위치 기반 주소 지정' 방식을 쓴다. 반면 IPFS는 파일의 내용 자체를 해싱하여 만든 고유한 식별자(CID, 콘텐츠 식별자)로 데이터를 찾는 '콘텐츠 기반 주소 지정' 방식을 사용한다. 즉 '어디에 있는가'가 아니라 '무엇인가'를 기준으로 파일을 요청하며, 동일한 내용의 파일은 항상 같은 주소를 갖는다. 파일 내용이 조금이라도 바뀌면 식별자도 달라지므로 데이터의 무결성을 검증할 수 있다.

IPFS는 특정 회사의 서버 군집이 아니라 프로토콜이며, 이 프로토콜을 따르는 노드들이 모여 하나의 탈중앙 네트워크를 이룬다. 누구나 노드를 실행해 네트워크에 참여할 수 있다.

2.콘텐츠 기반 주소 지정과 CID

IPFS의 핵심은 데이터를 '내용'으로 식별하는 콘텐츠 주소 지정이다. 파일을 올리면 그 내용에 해시 함수를 적용해 지문과 같은 고정 길이 값을 얻고, 이를 바탕으로 콘텐츠 식별자(CID, Content Identifier)를 만든다.

CID에는 단순한 해시값뿐 아니라 어떤 해시 알고리즘을 썼는지, 데이터를 어떤 형식으로 인코딩했는지를 나타내는 정보가 함께 담긴다. 덕분에 훗날 다른 해시 방식이 도입되어도 같은 체계 안에서 구분해 다룰 수 있도록 설계되어 있다.

콘텐츠 주소 지정에는 몇 가지 성질이 따라온다.

• 무결성 검증: 받은 데이터를 다시 해싱해 CID와 대조하면 내용이 변조되지 않았는지 스스로 확인할 수 있다.
• 자동 중복 제거: 같은 내용은 언제나 같은 CID를 가지므로, 동일한 파일이 여러 번 올라와도 네트워크에는 하나의 사본만 존재한다.
• 위치 독립성: 파일이 어느 노드에 있든 CID만 알면 요청할 수 있어, 특정 서버 주소에 얽매이지 않는다.

3.작동 방식과 기술 구조

IPFS에 파일을 올리면 파일은 작은 조각(블록)으로 나뉘고, 각 조각은 머클 트리 구조를 확장한 머클 DAG(방향성 비순환 그래프)로 연결되어 관리된다. 상위 노드가 하위 조각의 CID를 참조하는 구조여서, 큰 파일도 조각 단위로 나눠 여러 노드에서 병렬로 받아올 수 있고 공통 조각은 재사용된다.

이렇게 생성된 콘텐츠 식별자(CID)를 아는 사람은 네트워크에 참여한 노드 가운데 해당 조각을 보유한 노드로부터 파일을 내려받을 수 있다. 이 과정은 크게 두 단계로 나뉜다.

• 콘텐츠 라우팅: 특정 CID를 누가 갖고 있는지 찾는 단계다. IPFS는 분산 해시 테이블(DHT)을 이용해, 중앙 색인 서버 없이 네트워크에 흩어진 노드들이 협력해 보유자를 찾아낸다.
• 데이터 교환: 보유 노드를 찾으면 블록을 실제로 주고받는다. 이때 요청과 응답을 조율하는 프로토콜(비트스왑, Bitswap)이 사용되며, 이는 비트토렌트처럼 여러 상대에게서 조각을 동시에 받아오는 방식과 통한다.

노드 사이의 연결·전송 같은 저수준 통신은 별도의 네트워킹 계층이 담당하며, 이 계층은 이후 IPFS와 독립된 재사용 가능한 라이브러리로 분리되어 다른 P2P 프로젝트에서도 쓰인다.

4.데이터 지속성과 고정(pinning)

IPFS 자체는 데이터를 영구히 보관해 주지 않는다. 기본적으로 노드는 자신이 최근에 받아본 데이터를 임시로 캐시할 뿐이며, 이 캐시는 공간 확보를 위해 정리될 수 있다.

특정 파일을 계속 유지하려면 최소 한 곳 이상의 노드가 그 데이터를 '고정(pinning)'해 두어야 하며, 아무도 보유하지 않은 파일은 네트워크에서 사라질 수 있다. 즉 어떤 CID가 존재한다는 사실과, 그 CID의 실제 데이터를 누군가 계속 갖고 있다는 사실은 별개다.

이런 저장 지속성 문제를 완화하기 위한 방식은 대략 다음과 같다.

• 직접 고정: 이용자가 자신의 노드에 원하는 CID를 고정해 둔다.
• 고정 서비스: 대신 데이터를 안정적으로 보관·고정해 주는 외부 서비스를 이용한다. NFT 관련 데이터 보관에 특화된 서비스들이 대표적이다.
• 인센티브 계층: 저장 공간 제공에 경제적 보상을 부여하는 별도의 블록체인 프로젝트 파일코인(Filecoin)을 함께 두는 방식이다. 프로토콜 랩스는 IPFS의 저장 지속성 문제를 겨냥해 파일코인을 만들었으며, 파일코인은 저장 제공자가 실제로 데이터를 보관하고 있음을 주기적으로 증명하도록 한다.

5.가변 주소: IPNS와 게이트웨이

콘텐츠 주소는 내용이 바뀌면 CID도 바뀌므로, '항상 최신 버전을 가리키는 고정된 이름'을 만들기 어렵다는 한계가 있다. 이를 보완하기 위해 IPFS에는 IPNS(InterPlanetary Name System)가 있어, 변하지 않는 이름 하나가 그때그때 다른 CID를 가리키도록 갱신할 수 있다. 사람이 읽기 쉬운 이름과의 연결에는 도메인 시스템이나 이더리움 네임 서비스 같은 외부 명명 체계가 함께 쓰이기도 한다.

또한 일반 웹 브라우저는 기본적으로 IPFS 프로토콜을 직접 이해하지 못한다. 이를 잇기 위해 HTTP 게이트웨이가 존재하는데, 이는 일반 웹 요청을 받아 IPFS 네트워크에서 데이터를 가져다 되돌려 주는 중계 서버다. 게이트웨이 덕분에 IPFS 노드를 직접 실행하지 않는 이용자도 웹에서 CID로 데이터를 열람할 수 있다. 다만 특정 게이트웨이에 의존하면 그 지점이 다시 중앙 집중적 병목이 될 수 있다는 지적도 있다. 일부 브라우저는 IPFS 주소를 자체적으로 처리하는 기능을 도입하기도 했다.

6.구현체와 생태계

IPFS는 프로토콜이므로 이를 구현한 소프트웨어가 여럿 존재한다. 오랫동안 Go 언어로 작성된 구현체가 사실상의 표준 역할을 해 왔으며, 이 구현체는 이후 '쿠보(Kubo)'라는 이름으로 개편되었다. 자바스크립트 기반 구현 등 다른 언어·환경을 위한 구현체도 개발되어, 서버부터 브라우저까지 다양한 곳에서 동작한다. 관련 코드와 명세는 깃허브에서 공개적으로 개발된다.

프로토콜 랩스가 이끄는 이 생태계에서는 IPFS 외에도 저수준 네트워킹 라이브러리, 데이터를 서로 연결해 표현하는 데이터 모델, 인센티브 계층인 파일코인 등이 함께 자라났다. 데이터를 대신 고정·보관해 주는 상용 고정 서비스들도 생태계의 한 축을 이룬다. IPFS는 분산원장과 결합해, 또는 그 자체로 클라우드 컴퓨팅의 중앙 서버 모델에 대한 대안적 저장·배포 방식으로 자리 잡았다.

7.활용

IPFS는 블록체인에 직접 저장하기에는 용량이 큰 데이터를 오프체인에 보관하는 수단으로 널리 쓰인다. 대표적으로 NFT의 이미지나 속성 정보를 담은 메타데이터를 IPFS에 올리고, 블록체인에는 그 콘텐츠 식별자만 기록하는 방식이 있다. 이렇게 하면 온체인에는 짧은 CID만 남기고도, 그 CID가 가리키는 콘텐츠가 바뀌지 않았음을 누구나 검증할 수 있다.

주요 활용 분야는 다음과 같다.

• NFT·토큰 자산의 콘텐츠 저장: 이미지·메타데이터 등 대용량 부속 데이터를 오프체인에 두는 표준적 방식.
• 디앱 프런트엔드 배포: 디앱의 웹 화면을 IPFS에 올려, 특정 웹 서버에 의존하지 않고 배포·제공.
• 검열에 강한 데이터 공유: 특정 서버를 차단해도 데이터를 보유한 다른 노드가 있으면 접근이 유지되므로 검열 저항성이 높다.
• 웹 3.0 인프라: 웹 3.0 생태계 전반에서 이더리움 등 여러 네트워크의 응용과 결합해 저장·배포 계층으로 쓰인다. 저장·연산 자원을 분산 제공하는 디핀 성격의 프로젝트들과도 개념적으로 맞닿아 있다.

8.기존 웹(HTTP)과의 비교

IPFS는 기존 웹을 대체하기보다 그 한계를 보완하려는 성격이 강하다. 위치 기반의 HTTP와 대비하면 특징이 뚜렷하다.

• 주소의 기준: HTTP는 '서버 위치'를, IPFS는 '내용'을 기준으로 데이터를 지목한다.
• 단일 실패 지점: HTTP에서는 원본 서버가 내려가면 링크가 깨진다. IPFS에서는 데이터를 가진 노드가 하나라도 남아 있으면 같은 CID로 접근할 수 있다.
• 검증 가능성: HTTP로 받은 데이터가 원본과 같은지 스스로 확인하기 어렵지만, IPFS는 CID와 대조해 무결성을 검증한다.
• 데이터 지속성: HTTP 서버는 관리 주체가 데이터를 계속 올려 둔다. IPFS는 반대로, 아무도 고정하지 않은 데이터는 사라질 수 있다.

요컨대 IPFS는 분산 환경에서의 내용 검증과 중복 제거에 강점이 있는 반면, '누가 데이터를 계속 보관할 것인가'라는 책임을 이용자와 인센티브 계층에 넘긴다는 차이가 있다.

9.한계와 과제

IPFS는 여러 장점에도 불구하고 몇 가지 구조적 과제를 안고 있다.

• 저장 지속성: 앞서 보았듯 IPFS 자체는 영구 저장을 보장하지 않는다. NFT 등 장기 보존이 중요한 자산이 제대로 고정되지 않아 나중에 콘텐츠에 접근하지 못하게 되는 문제가 실제로 지적되어 왔다.
• 성능과 지연: 콘텐츠 보유자를 찾는 라우팅 과정 등으로 인해, 자주 조회되지 않는 데이터는 중앙화된 웹 서버보다 응답이 느릴 수 있다.
• 프라이버시: 기본적으로 네트워크에 올린 데이터는 CID를 아는 누구나 받아볼 수 있는 공개 데이터에 가깝다. 비공개가 필요하면 올리기 전에 별도로 암호화해야 한다.
• 게이트웨이 의존: 일반 이용자가 공개 HTTP 게이트웨이에 의존하면, 탈중앙 저장의 이점을 두고도 접근 경로가 다시 소수 지점에 집중될 수 있다.

이러한 과제들은 파일코인 같은 인센티브 계층, 고정 서비스, 브라우저·명명 체계와의 통합 등으로 조금씩 보완되고 있으나, 여전히 IPFS를 실제 서비스에 도입할 때 함께 설계해야 할 요소로 남아 있다.

10.연표7건

1. 2014이정표후안 베넷이 IPFS 백서를 공개하고 프로토콜 랩스를 설립
2. 2015설립IPFS 초기 구현체가 오픈 소스로 공개
3. 2017투자저장 인센티브 계층인 파일코인(Filecoin)의 토큰 판매(ICO) 진행
4. 2018출시클라우드플레어가 공개 IPFS 게이트웨이를 운영 개시
5. 2020이정표파일코인 메인넷 출시로 저장 보상 경제가 가동
6. 2021출시브레이브 브라우저가 IPFS 주소 기본 지원을 도입
7. 2022출시대표 구현체 go-ipfs가 '쿠보(Kubo)'로 개명