클라이언트-서버 모델이란?
클라이언트-서버 모델의 제한 사항
오늘날, 웹의 대부분을 서비스하는 데 책임이 있는 회사는 극소수에 불과하다. 예를 들면 구글(Google), 아마존(Amazon), 페이스북(Facebook), 패스트리(Fastly)가 있다. 이 회사들이 결합하여 광고, 웹 페이지, 소셜 미디어, 비디오, 이미지를 제공하고 인프라에서 서버 및 서비스를 호스팅할 수 있다. 이러한 서비스와 상호 작용하려면 해당 API를 사용해야 하며 서버에 데이터를 보내고 응답을 기다려야 한다. 그런 다음 해당 응답을 처리하고 앱과 웹 사이트를 만들기 위해 필요한 모든 방법을 수행한다.
이 디자인에는 비용에서 개인 정보 보호에 이르기까지 몇 가지 문제가 있다. 예를 들어 무료 서비스는 대부분 광고로 자금을 조달한다. 광고는 모든 데이터가 몇 개의 중앙 지점을 통해 라우팅 되고 제3자에게 판매되기 때문에 개인 정보를 침해할 수 있다. 사실상, 무료 서비스는 개인의 관심과 개인 정보에 의해 지불된다.
단일 진실 공급원 (Single Source of Truth)
동영상을 보거나, 메시지를 보내거나, 원격으로 팀 동료와 협업하거나, 웹에서 무엇이든 하고 싶다면, 다른 사용자의 중앙 서버를 거쳐야 한다. 이 원칙은 클라이언트-서버 모델의 기본이다. 웹 브라우저나 채팅 앱과 같은 클라이언트를 사용하고 클라이언트-서버 모델의 서버인 단일 엔티티와 통신한다. 진실 공급원에만 의존하는 것 또한 신뢰와 같은 많은 문제를 열어준다. 오늘날, 엔티티가 누구인지 확인하기 위한 TLS 인증서를 가지고 있지만, 서비스가 손상된 경우에는 그다지 도움이 되지 않는다. 법인이 누구인지 확신하더라도 광고주 또는 다른 사람들이 우리 데이터를 어떻게 사용하고 있는지, 심지어 어떤 데이터가 수집되고 있는지 아는 데 여전히 도움이 되지 않는다.
애플리케이션을 구축하는 개발자는 종종 대규모 중앙 집중식 엔티티(예: Stripe, Google, Cloudinary, Auth0)에 의해 운영되는 API에 의존한다. 애플리케이션이 의존하는 API가 많을수록 더 취약해진다. 또한 사용할 수 없는 API가 있으면 앱이 작동을 중지한다. 오늘날, 인기 있는 빌드 방법은 다른 원격 서비스의 API에 의존하는 것이므로 이는 웹 전체를 매우 취약하게 만든다.
위치 기반 주소 지정
클라이언트-서버 모델에서 데이터를 원하는 경우 데이터가 어디에 있는지 알아야 한다. 이미지를 가져오고 공유하려면 일반적으로 해당 이미지의 전체 URL이 필요하다. 해당 이미지를 더 이상 사용할 수 없는 경우 해당 이미지를 검색하거나 다른 서버에 복사본을 업로드하여 다시 사용할 수 있도록 해야 한다(사용자가 복사본을 가지고 있다고 가정). 업로드 후에는 해당 이미지의 새 위치도 공유해야 한다. 이 원칙은 위치 기반 주소 지정이라고 불리며, 오늘날 대부분의 월드 와이드 웹(World Wide Web)이 어떻게 기능하는지 보여준다. URL이 있는 웹 사이트로 이동하면 해당 웹 사이트의 모든 데이터는 데이터 위치에 의해 주소 지정된다. 이미지 비유가 너무 어렵다면 좋아하는 비디오 플랫폼에서 비디오를 공유하는 방법을 사용할 수 있다. 이는 비디오의 위치라고도 하는 비디오의 URL을 공유하면 된다.
단일 장애 지점
AWS, Fastly, Facebook 또는 YouTube가 오프라인이 됐다고 가정했을 때 이러한 이벤트는 뉴스로 취급되며, 종종 생산성이 저하되거나 중단되기도 한다. 이러한 서비스 중 하나가 오프라인으로 전환되면 단일 이미지나 비디오가 손실되는 것보다 훨씬 더 큰 영향을 미친다. 이제 새로운 데이터를 사용할 수 있는 기능에 액세스할 수 없게 된다. 이러한 중앙 허브에 호스팅된 모든 데이터는 일시적으로 완전히 액세스할 수 없거나 더 나쁜 경우 영구적으로 액세스할 수 없다. 이는 오프라인 상태이기 때문에 데이터 위치에 액세스할 수 없다. 더 넓은 웹에서 데이터를 요청할 수 없으며, 다른 관련 엔티티가 원하는 데이터를 가지고 있더라도 데이터를 받을 것으로 기대할 수 없다.
물론 자체 서비스를 호스팅할 수도 있으며 단일 운영 중단으로 서비스가 중단되는 것을 방지하는 방식으로 서버의 위치를 분산시킬 수도 있다. 웹사이트나 플랫폼에 대한 다음 큰 아이디어를 생각해냈다고 가정해 보았을 때 여기에서 필요에 따라 다른 중앙 엔티티에 의존하지 않고 모든 인프라를 제어할 수 있다.
큰 확장 비용
이것은 다음 요점으로 이어진다. 확장은 매우 비쌀 수 있다. 이러한 비용이 항상 발생하는 것은 아니며, 일반적으로 발생하지 않는다. 즉, 트래픽의 폭발은 비용의 폭발로 이어질 수 있다. 자체 인프라를 호스팅하든, 다른 사용자에게 비용을 지불하든, 인프라를 효과적으로 확장하고 실행하려면 비용을 지불해야 한다. 자체 인프라를 호스팅하든 다른 사람에게 비용을 지불하든 관계없이 확장 및 실행을 효과적으로 원하면 비용을 지불하게 된다. 사용자가 많을수록 더 많은 트래픽이 발생하고 CPU, RAM 및 대역폭 비용이 증가한다. 또한 사용자가 서비스에 의존하게 되는 경우 사용자를 유지하고 만족스럽게 유지하려면 이 서비스를 계속 실행하고 사용할 수 있어야 한다. 모든 사람이 이러한 비용을 감당할 수 있는 것은 아니며, 특히 재미있는 프로젝트, 기술 또는 블로그를 만들고자 하는 경우에는 상당히 부담스러울 수 있다. 앞서 언급한 많은 기업이 이러한 비용을 보완하기 위해 광고에 의존하고 있다.
제한되고 검열된 콘텐츠
콘텐츠 제작자들은 종종 유튜브, 인스타그램 및 다른 플랫폼과 같은 몇 가지 플랫폼에 완전히 갇혀 있다. 여기에는 정부가 허용할 수 있는 것보다 훨씬 더 제한적이고, 그러한 규칙들이 언제 어떻게 바뀔지 말할 수 없다.
이러한 플랫폼 중 하나에서 콘텐츠를 호스팅하려는 경우 해당 플랫폼의 규칙과 규정을 준수하고 있는지 확인해야 한다. 이는 오늘날 비디오 및 그래픽 미디어에서 흔히 볼 수 있는 규칙 변경 또는 업데이트로 인해 인기 있는 콘텐츠가 손실될 경우 매우 안타까울 수 있다. 콘텐츠 제작자로서 때때로 이 문제를 해결하는 것이 불가능할 정도로 힘든 작업처럼 느껴질 수 있다. 앞서 언급한 대로 자체 서비스를 설정할 수 있지만 모든 사람이 이를 효과적으로 수행하는 방법을 알고 있는 것은 아니며 이와 관련된 시간과 비용에 대한 준비가 되어 있지 않다.
클라이언트-서버 모델에서 벗어나는 것은 오늘날 알고 있는 웹이 어떻게 작동하는지 다시 생각해보는 것을 의미한다. 클라이언트-서버 모델에서 벗어나는 것은 오늘날 알고 있는 웹의 작동 방식을 재고하는 것을 의미한다. 클라이언트-서버 모델은 web2를 나타낸다. 좋든 싫든 간에, 클라이언트-서버 모델을 참조하는 web2 모델이 개선될 방법에 대한 명확하고 강력한 주장이 있다. 이러한 새로운 모델은 분산 웹을 의미한다.
분산 웹
이 새로운 모델 분산 웹에 IPFS가 어떻게 적합한지 살펴보았다. 시작하기에 앞서, 먼저, 초보자들을 위해, 분산 웹이 무엇인지, 그리고 그것이 개인에게 무엇을 의미하는지 간략하게 설명하면 이는 사용자가 든 개발자가 든 개인이 생각하는 웹3의 분산형 웹의 혜택을 누릴 수 있다.
중앙 집중식 (Centralized) vs 분산형 (Decentralized) vs 분산 (Distributed)
위의 그림은 3가지 네트워킹 모델이다. 클라이언트-서버 모델은 중앙 집중식 모델이며 이것이 항상 중앙 서버와 단일 장애 지점에 관해 이야기하는 이유이다. 중앙에 주황색으로 표시된 부분이 서버이고 이를 감싸는 선들은 사용자인 클라이언트이다. 이 그래픽을 통해 해당 중심점이 제거되면 사용자가 더 이상 서로 통신할 수 없음을 쉽게 알 수 있다.
분산형 모델은 중앙 집중식 모델을 개선한 것이다. 이는 여전히 클라이언트-서버 방식으로 작동하며, 결국 허브가 사용자에게 서비스를 제공하는 허브가 되고, 허브가 나가면 네트워크의 일부만 손실된다. 이것은 좋은 개선이지만 여전히 클라이언트-서버 모델이 수반하는 모든 문제를 해결하지는 못한다. 오늘날 우리는 이 모델이 ActivityPub과 Matrix와 같은 많은 것들과 함께 사용되는 것을 볼 수 있다. 이러한 서비스가 중단되면 전체 소셜 네트워크나 채팅 서비스 대신 그들이 대표하는 커뮤니티의 일부에만 영향을 미친다.
분산 모델에서 각 사용자는 네트워크 자체의 일부를 제공합니다. 사용자가 오프라인으로 전환되면 네트워크는 정상적으로 작동합니다. 주요 노드가 작동 중단되더라도 로컬 피어를 활용하여 네트워크가 계속 작동할 수 있습니다. 그것은 회복력의 챔피언이며, 우리를 앞으로 나아가게 할 모델이다. 일부 노드는 다른 노드보다 클 수 있지만 단일 중단으로 전체 네트워크가 중단될 수는 없다. IPFS가 이 모든 것에 어떻게 적합한지 살펴보고, 분산 모델 자체에 대해서도 자세히 살펴보았다.
콘텐츠 주소 지정
위치 기반 주소 지정을 검토했다. 이제 콘텐츠 주소 지정이라는 대안의 기본 구성 요소 중 하나인 IPFS는 콘텐츠 식별자 또는 CID라고 하는 데이터에 대해 수학적으로 생성된 지문을 만든다. 이 단계는 IPFS가 어떻게 우리에게 콘텐츠 주소 지정을 제공하여 위치 기반 주소 지정에서 벗어나게 하는지에 대한 기본적인 IPLD 또는 행성간 연결 데이터라고 하는 것과 관련이 있다.
CID의 구성
위 사진은 바이너리로 표시된 v1 CID의 구조이다. 이미지의 맨 왼쪽에는 여기에 표시되지 않은 멀티베이스 프레픽스(multibase prefix)가 있다 바이너리로 작업할 때 실제로 멀티베이스 프레픽스가 없기 때문에 이 바이트를 저장할 수 있다. 멀티베이스 프레픽스가 하는 것은 IPLD가 많은 것을 지원하기 때문에 CID를 만들기 위해 어떤 기본 인코딩이 사용되었는지 알 수 있게 해준다.
다음으로는 작업 중인 버전 식별자이다. 이 경우 버전 1 CID로 작업하고 있다.
다음으로, 이 DAG(방향 비순환 그래프)가 프로토콜 버퍼로 인코딩되었음을 나타내는 dag-pb라는 멀티코덱이 있다. multicodec 필드 자체는 unsigned-varint입니다. 지원되는 코덱 목록은 github multiformats 저장소에서 확인할 수 있다.
다음은 멀티해시이며, 여기에는 3가지, 즉 멀티해시 알고리즘, 멀티해시 길이, 그리고 마지막으로 해시 다이제스트가 포함된다. 여기에서 길이가 32바이트인 sha2 해시로 작업하고 있는 것을 볼 수 있으며 해시 자체가 화면에서 사라진다. 이는 멀티해시 사양 multiformats github 저장소에서도 사용할 수 있다.
신뢰할 수 없는 검증과 지속성
앞서 살펴본 것처럼 CID의 해시 기능을 실행하고 직접 확인할 수 있으므로 데이터를 보내는 사람을 신뢰할 필요가 없다. IPFS는 분산 해시 테이블(DHT)에서 CID를 조회하거나 비트스왑을 사용하여 로컬 피어에게 "이 CID를 가지고 있습니까?"라고 묻는 방식으로 CID를 사용한다. 이것으로 원하는 것을 정확히 알고 있기 때문에 더 이상 데이터가 있는 위치가 중요하지 않다. 따라서 누가 그것을 가지고 있는지는 또한 중요하지 않다. IPFS는 이제 위치 기반 주소 지정에서 벗어났다.
웹 페이지, 이미지, 비디오 또는 기사를 공유하려는 경우 해당 CID를 친구에게 보내면 친구도 본인이 본 것과 똑같은 버전의 데이터를 다운로드할 수 있다. 적어도 본인의 노드 또는 다른 사람의 노드에 사본이 있는 한 공유할 수 있다. 본인 또는 다른 사람이 데이터 사본을 가지고 있다는 것이 중요하지 초기 호스팅 업체가 데이터를 제거했는지 여부는 중요하지 않다. 이를 통해 데이터는 원하는 사람이 있는 한 오래 저장될 수 있다. 파일코인으로 데이터가 얼마간, 어쩌면 영원히 지속될 것임을 암호화 방식으로 보장하기 위해 스토리지 제공자에게 비용을 지불할 수도 있지만 이는 다른 게시물을 위한 것이다.
그동안 데이터를 유지할 서비스를 찾고 있다면 web3.storage, nft.storage, lighthouse.storage를 확인해 보는 것을 추천한다. 이들 모두 IPFS를 통해 데이터를 제공하고 파일코인에 백업하기를 간절히 원하는 스토리지 핼퍼이다.
멈출 수 없는 데이터 및 서비스
이제 위치 기반 주소 지정에서 벗어나 컨텐츠 주소 지정으로 넘어갔다. 이는 이제 투명하게 네트워크가 문제를 둘러싼 새로운 경로를 찾을 수 있음을 의미다. 이 경우 문제는 중단이 될 수 있으며, 일정 기간 노드가 다운되면 데이터를 다른 노드로 가져갔는지 여부를 알 수 있다. 또는 IPFS 노드를 실행하는 사용자가 우연히 우리 데이터의 복사본을 가지고 있는 경우에도 마찬가지다.
IPFS를 사용하면 노드가 가비지 수집될 때까지 새 데이터를 캐시하므로 관련 CID의 가용성을 자동으로 강화할 수 있다. 로컬 네트워크의 일부 노드가 데이터의 복사본을 가지고 있는 한, 여전히 서비스를 제공할 수 있기 때문에 이는 지역 및 심지어 국가 전체의 인터넷 정지에 도움이 될 수 있다. 또한 피어 투 피어 네트워크에서 단일 노드 중단으로 인해 전체 서비스가 중단될 방법을 보여준다.
이 지식은 애플리케이션을 설계할 때 중요합니다. 게이트웨이를 활용할 수 있으며 시간이 촉박한 경우 해커톤에 참가할 수 있다. 원력이 있는 web3 P2P 애플리케이션을 실제로 만들고 싶다면 복원력을 달성하는 방법에 대해 생각하는 것이 중요하다. 그렇게 하려면 IPFS의 피어-투-피어 특성을 활용해야 한다. 게이트웨이, 특히 단일 게이트웨이에 의존하는 경우 해당 게이트웨이가 느려지거나 다운되면 전체 애플리케이션이 함께 작동한다. 대신 IPFS를 직접 사용하여 피어 투 피어 기능을 활용하면 사실상 멈출 수 없는 서비스를 만드는 궤도에 오르게 된다 .
확장 & 분산
해당 블로그는 IPFS 사용자가 관심 있는 데이터를 인근 피어에 예약하는 방법에 관해 설명했다. 이것은 사용자가 CID를 통해 네트워크에서 데이터를 요청하고, 노드가 데이터를 캐시한 다음 네트워크의 나머지 부분에 사용할 수 있도록 할 때 발생한다. 이는 복원력뿐만 아니라 효율적인 확장을 지원하는 네트워크 피칭으로 볼 수 있다. 인기 있는 앱을 만들고 트래픽이 폭발할 때의 클라이언트-서버 문제를 생각해보면 이러한 상황은 IPFS로 인해 효과적으로 뒤집혀 대역폭 확장 비용이 감소하게 된다.
여러 노드가 CID를 다운로드하려고 하면 데이터도 자동으로 다시 공유된다. CID를 요청하는 사람들로부터 트래픽이 폭발적으로 증가하는 동안 바로 그 사람들이 데이터 자체를 친구나 동료에게 자동으로 보내는 데 도움이 된다. CID의 인기가 높을수록 사람들이 자신에게 더 가까운 사람에게서 데이터를 검색하기가 더 쉽다.
이 특성은 IPFS의 분산형 측면에 매우 중요하다. 만약 화성에 있는 누군가가 원래 지구에서 검색한 데이터를 가지고 있다면, 다른 화성 사용자는 지구에서 같은 데이터를 검색하기 위해 기다릴 필요가 없다. 네트워크는 자동으로 그 데이터를 제공하고자 하는 다른 노드가 화성에 있다는 것을 알아내야 한다. 콘텐츠 주소 지정 및 분산 웹은 네트워크 수준에서 이러한 미래를 투명하게 여는 데 도움이 된다.
결론
IPFS와 같은 웹3 기술은 중앙 집중화의 세계에서 벗어나는 데 도움이 된다. 이는 소비자에게 더 많은 권한을 부여하고 개인 정보를 수집하려는 회사에 더 적은 권한을 제공한다. 또한 IPFS는 견고한 분산 설계를 통해 데이터에 대한 복원력과 상호 운용성을 향상하는 데 도움이 된다.
더 자세히 알고 싶다면, 아래 링크는 새로운 사용자와 기술에 대해 더 깊이 연구하고자 하는 개발자를 위해 IPFS를 사용하는 방법에 대한 몇 가지 링크이다.
링크
시작하기
학습 자료
- IPFS & Filecoin 시작하기
- IPFS 문서
- IPFS 커뮤니티 리소스(디스코드, 포럼 등)
비디오
사례 연구
기타 자료
더욱 다양한 정보 및 방송 관련 소식은
공식 SNS 채널을 통해 확인 가능합니다.
