블록체인으로 콘텐츠 저장도 탈중앙화로, IPFS
이근해 아르고 개발자는 IPFS 기술의 장점을 강조하며 이같이 말했다. 기존 웹에서는 파일서버, 웹서버가 다운되거나 콘텐츠에 이르는 라우트가 먹통이 되면 사용자는 콘텐츠에 액세스할 수 없게 된다. IPFS는 바로 이 문제를 해결하고자 등장한 파일 시스템이다. IPFS는 동등 계층 간 통신망(P2P) 형태로 구성돼 있다. IPFS에 파일이 업로드 되면 네트워크 상에서 잘게 쪼개져 분산 저장된다. IPFS 네트워크의 참여자들은 파일이 쪼개진 청크 데이터를 분산 소유하고 관리하게 된다. 사용자로부터 파일의 다운로드 요청이 들어오면 분산된 청크 데이터를 토대로 다운로드가 진행된다. IPFS의 이같은 방식을 사용하면 웹에서 중앙 서버의 통제를 받지 않는 영구적인 파일 시스템을 만들 수 있다.
분산화 대용량 스토리지 서비스 IPFS
기존의 중앙화된 파일시스템은 파일을 관리하는 데는 효율적이지만 지속적인 서비스를 항상 보장하기는 어렵다. 먼저 콘텐츠를 관리하는 중앙 기관에 사고가 발생하면 동영상에 접근할 수 없게 된다. 또 서버에서 정책상 콘텐츠를 통제하는 경우도 있다. 실제로 유튜브에 게시된 동영상은 게시자가 사라지거나 콘텐츠 정책이 변동되면 삭제되거나 재생될 수 없다.
뿐만 아니라 웹에서 받은 데이터가 실제로 사용자가 요청한 데이터와 일치하는지 알 수 있는 방법이 아직 없다는 점도 기존 웹의 문제점으로 꼽힌다. 네트워크 상에 존재하는 데이터가 사용자가 요청한 내용과 일치한다 해도 이를 보장할 방법이 아직까지 없다. 때문에 사용자의 요청은 오로지 접수된 서버에서만 처리된다. 동일한 데이터를 갖고 있는 근처 노드에서 데이터를 가져오는 등 유연한 분산 처리 기능 등은 현실적으로 어려운 셈이다. 정해진 경로에 요청이 쏠릴 수밖에 없어 규모가 커질수록 데이터를 처리하는 비효율성은 더욱 커지게 된다.
반면 IPFS에서는 노드(피어)로 참여한 참여자 각자의 하드 디스크에 청크 단위로 저장하고 파일을 찾아가는 인덱스를 해시로 기록한다. 하지만 청크 데이터를 어떤 노드가 지니고 있는지는 알 수 없다. 콘텐츠 파일의 위치를 탈중앙화하는 셈이다.
IPFS에서는 해시함수를 토대로 파일 데이터의 해시를 생성하고 파일의 진위 여부 검증에 사용한다. 해시란 파일마다 고유한 값을 지니는 디지털 지문과도 같다. 사용자는 이같은 해시값을 입력해 원하는 파일을 요청하면 IPFS는 해당 해시값을 토대로 데이터를 파일시스템에서 끌어 모아 사용자를 위한 파일 다운로드를 준비한다. 실질적인 다운로드는 사용자로부터 가까운 노드에서 우선 찾아가 이뤄지고 필요시 웹서버를 경유하기도 한다. 다운로드가 완료되면 사용자는 해시값을 파일의 정보가 담긴 머클트리와 비교해 봄으로써 파일의 진위 여부를 쉽게 가려낼 수 있다.
IPFS 내부 동작 방식
IPFS에서 파일을 추가하면 파일의 해시가 생성된다. IPFS에서 파일은 실제로 매우 작은 청크 단위로 쪼개지며 하나하나 마다 해시값이 부여된다. 매우 작은 이 단위를 블록이라고 한다. 블록체인에서 말하는 블록과는 다른 개념이다. 블록이란 IPFS 내부에서 쓰는 데이터 교환의 단위며 모든 블럭은 해시값을 가진다.
네트워크에는 노드가 천만개 이상 존재하기 때문에 자료를 얻기 위해 매번 모든 노드에게 질의를 할 수는 없다. 특정 파일인 A라는 파일을 얻기 위해 천만 노드에게 데이터를 모두 물어보기란 현실적으로는 어렵다. 예를 들어 P2P 파일환경에서는 참여자인 피어의 수가 늘수록 메시지 교환에 필요한 부담이 기하급수적으로 증가한다.
IPFS에서는 파일을 찾는데 루트 해시값을 매개로 사용한다. 해시를 통해 파일을 검색하기 때문에 사용자도 다운로드 하기 원하는 파일의 해시를 미리 알고 있어야 한다. 원하는 파일의 해시값은 별도의 서비스를 통해서 알 수 있다. 이는 토렌트에서 토렌트 시드를 검색하는 방식과 유사하다.
IPFS에서는 P2P 시스템의 비효율성 문제를 극복하기 위해 분산해시테이블(DHT)를 도입했다. DHT란 IPFS에서 파일 해시값과 파일을 연결한 해시테이블을 말한다. IPFS 내부에서 파일 데이터 검색과 노드 간 연결의 효율성을 높이기 위한 일종의 매핑 테이블인 셈이다. 때문에 P2P 노드가 매우 많아져도 해시값을 토대로 콘텐츠를 찾는데 걸리는 시간은 그리 오래 걸리지 않게 된다. 실제로 IPFS는 네트워크 부담을 이같은 DHT와 라우팅 기술로 해결했다고 주장한다.
IPFS로 간단한 텍스트파일 업로드∙다운로드 해보기
IPFS는 고(GO), 자바스크립트(javascript) 등 여러 버전의 클라이언트 프로그램이 현재 존재한다. IPFS 깃허브에서 소스파일을 깃클론으로 받아온 후 각자 컴퓨팅 환경에 맞춰 컴파일해서 사용해야 한다. 자바스크립트 버전 클라이언트의 경우 노드패키지매니저(npm)에도 등록돼 있어 간편하게 받아올 수 있다. 프로그램 빌드와 각종 환경 변수 등 셋업이 번거로운 경우 IPFS 홈페이지에서 프리빌드 패키지를 받아서 직접 사용해 볼 수도 있으며 그래픽유저인터페이스(GUI) 버전의 IPFS 클라이언트도 현재 개발됐다. 이번 사용기는 macOS 하이시에라를 기준으로 GO언어 프리빌드 구현체를 기준으로 작성됐다.
파일을 누가 올렸는지도 알 수 없다. 또 파일에 다른 사람의 접근을 제한시킬 방법도 없다. 콘텐츠에 기반한 파일 시스템이지만 콘텐츠에 권한을 부여하는 방법도 없다. 해시값에는 콘텐츠를 업로드한 사용자나 시간값이 반영되지 않기 때문이다. 보통의 파일시스템에서는 정책상 사용자, 그룹 간 읽기, 쓰기 권한을 부여하지만 IPFS에서는 이같은 절차 모두에서 익명으로 별도의 권한 설정 없이 운영한다.
IPFS 기반하면 끊김없는 '심리스한 웹 서비스' 가능
유튜브와 여러 웹서비스가 아마존웹서비스(AWS) 등 서버 오류로 인해 중단된 적이 최근 있었다. 일반적으로 IP는 도메인 링크로 바뀌고 라우터를 통해 엔트리 서버의 로드밸런싱 하는 곳으로 들어가 콘텐츠 어드레스를 토대로 조회된다. 여기까지 이르는 길목이 끊기거나 중간 객체가 불능이 되면 콘텐츠를 읽을 수 없게 된다. 유튜브가 먹통이 된 사례도 이같은 길목, 라우팅 문제로 추정되고 있다. 반면 IPFS의 경우 사용자가 어떤 콘텐츠에 접근할 수 없게 되더라도 지속적으로 콘텐츠를 받아올 수 있다. 사용자가 IPFS 망에 리퀘스트를 보내면 해시값이 동일한 파일을 가지고 있는 노드에 접근해서 받아올 수 있다. IPFS에 콘텐츠를 업로드하고 파일이 충분히 확산된 경우 이같은 에러의 위험은 크게 줄어든다.
IPFS에서 콘텐츠를 주고받기 위해 전송하는 데이터 전송량은 기존의 웹서버-클라이언트 모델과 거의 비슷하지만 콘텐츠를 받아오는 경로에 커다란 차이점이 있다. 동영상 등 콘텐츠를 재생하는 경우 일반적으로 데이터는 컴퓨터의 공유기, 중계기, 중간 라우팅, 서버 등을 여럿 거치게 되는데 이같은 과정에서 불필요한 경로가 여럿 발생할 수 있다. 즉 최단 거리가 아닌 루트를 거치기 때문에 불필요한 전송량이 발생하고 데이터 부담도 늘어난다고 볼 수 있는 셈이다. 이근해 개발자는 “IPFS처럼 P2P 네트워크를 통해 구축한 웹은 회선 낭비를 막고 빠른 곳에서 데이터를 찾아 전송해 전반적인 데이터 부담을 줄여 끊김없는 영상 서비스 등 사용자경험(UX)를 증진시킬 것”이라고 전망했다. 그뿐만 아니라 IPFS는 콘텐츠 검열, 차단 등의 정책에도 저항성을 지니고 있다. 국가, 기관에서 어떤 콘텐츠를 막더라도 IPFS 네트워크를 사용하면 차단 루트를 우회해 콘텐츠 서비스를 막힘없이 할 수 있게 된다. 이는 서비스 접속을 위한 버츄얼프라이빗네트워크(VPN) 플러그인을 사용한 효과와도 유사하다.
퍼블릭 블록체인 + IPFS, 프라이빗 블록체인 + IPFS
블록체인이 신뢰의 아이콘이듯 블록체인이 제공하는 데이터 스토리지는 데이터 관리가 투명하다는 점이 강점이지만 비싸고 느린 편이다. 그렇다고 용량이 큰 데이터 부분만 떼어내 오프체인 스토리지에 저장하기로 한다면 신뢰의 문제가 발생할 수 있다. IPFS는 탈중앙화를 유지하며 블록체인 외부에 데이터를 저장하는 효과적인 솔루션으로 떠오르고 있다. 퍼블릭 망에서 파일 위치를 탈중앙화하고 블록체인의 느린 속도와 비싼 수수료를 모두 해결하기 때문이다.
IPFS에서 사용자는 파일에 기록된 메타데이터를 토대로 파일의 링크를 따라가 하나의 파일을 완성해 다운로드 하는 식으로 콘텐츠를 받는다. 하지만 IPFS에 참여한 노드들은 완성된 파일의 형태 보다는 중간 덩어리 형태로 유지하는 경우가 많다. 참여자의 스토리지 용량에는 한계가 있어 애초에 파일이 적절히 분산되기 때문이다. 이같은 상황에서 참여자 역시 파일을 끝까지 유지할 의무도 없다. 반면 피닝을 통해 데이터를 사용자의 스토리지에 영구적으로 오래 유지하는 경우 파일코인이라는 인센티브를 받을 수 있다. IPFS에 참여하는 노드는 이같은 IPFS 데이터가 제대로 존재하는지 조사하고 운영에 따른 인센티브를 얻는다. 토렌트에 연결된 컴퓨터가 없으면 파일 서비스가 작동하지 않듯 IPFS에도 사용자의 참여가 무엇보다 중요하기 때문이다.
다만 파일을 업로드하면 누구나 볼 수 있는 상태가 돼 프라이버시는 사실상 지켜지지 않는다. 때문에 프라이버시 보호를 위해 데이터 자체를 암호화해서 올리거나 프라이빗 IPFS망을 생성해 사용하는 등의 방법이 대안으로 떠오르고 있다. 하지만 이는 사이드체인을 쓰는것과 크게 다르지 않다는 분석이 나온다. 아르고는 IPFS 기술을 오프체인 데이터를 저장하는 용도로 사용하되 권한을 부여해 프라이빗 블록체인에서도 쓸 수 있도록 개량하는 방안을 검토하고 있다. 콘텐츠를 지정된 사람만 읽을수 있도록 설정하거나 멀티시그를 콘텐츠에 적용하는 등의 기법을 고려하고 있다. 한편 기존 웹 개발자도 익숙하게 사용할 수 있도록 IPFS 인터페이스를 개선하는 방향도 고려중이다.
“분산 파일 시스템, 최적화는 아직 지켜봐야”
IPFS 기술은 5년이 채 안됐을 정도로 역사는 깊지 않다. 하지만 기술적인 스택은 기본적으로 모두 구현돼 있다. 특히 이더리움에서 데이터를 저장하는 높은 수수료 문제, 스토리지 문제를 해결할 수 있을 것으로 전망받고 있다. 그는 “디스크 등 파일 스토리지는 점점 저렴해지고 있고 콘텐츠 용량은 커지고 있는 게 현재 추세다. 때문에 파일을 공유하는 시스템에서도 네트워크 대역폭을 덜 쓰고 전체 트래픽을 감소시키는 기술이 중요할 것”이라고 말했다. 여기서 IPFS와 같은 분산형 파일 시스템을 사용하면 네트워크의 부하를 줄이고 파일 공유의 효율성을 크게 끌어올릴 수 있다고 설명했다.
이 개발자는 “IPFS를 알고 있는 사람은 현재 적은 편이다. 지금은 개발자들만 알고 있는 정도다. 기초적인 외양은 완성이 됐지만 편의성을 증진시킬 방안과 기존 데이터를 어떻게 호환하도록 할 건지 또 사용자의 매시브한 확대에 따른 확장성을 어떻게 확보할 것인지가 중요할 것”이라고 내다봤다. IPFS는 사용자가 많지 않기 때문에 실질적인 문제점이 아직 드러나지 않았고 최적화도 덜 됐다고 그는 진단했다. 이 개발자는 IPFS가 모든 사람이 자발적으로 노드를 운영해준다는 가정에서 동작하기에 사용자가 실제로 늘어났을 때 효과적으로 기능할지는 더 지켜봐야 한다고 덧붙였다.
기사 작성에 참여하고 검수를 진행한 이근해 개발자는 카이스트 전산학 석사를 마치고 티맥스OS에서 선임, 책임연구원으로 근무한 바 있다. 티맥스OS 재직 당시 운영체제와 플랫폼 개발에 참여했으며 슈프리마에서는 생체인증기기의 백엔드 시스템을 개발하기도 했다. 현재는 블로코에 합류해 아르고 체인 모듈을 개발하고 있다.
[강민승 D.STREET(디스트리트) 기자]
[ⓒ 매일경제 & mk.co.kr, 무단전재 및 재배포 금지]
Copyright © 매일경제 & mk.co.kr. 무단 전재, 재배포 및 AI학습 이용 금지