스팀잇 팀의 @roadscape가 어제 하이브마인드 (Hivemind) 프로젝트에 대한 업데이트(morning님의 번역)를 하였습니다. 이 프로젝트가 무엇을 의미하는지 저의 관점에서 해설을 해드리고자 글을 시작합니다.

본 글에서 언급하는 내용은 하이브마인드의 소스코드를 통해 파악한 내용이며, 스팀잇 개발 상황에 따라 언제든 변경될 수 있음을 미리 알려드립니다.

하이브마인드 소스코드:
https://github.com/steemit/hivemind

하이브마인드

하이브마인드 프로젝트는 스팀 풀노드가 가진 한계를 극복하기 위한 off-chain API layer 이며 이는 많은 변화를 가져올것으로 기대됩니다. 그리고 하이브마인드 내부 기능 중에서 가장 주목받고 있는 한가지가 “커뮤니티”입니다.

현재 스팀잇은 모든 글이 한곳에 쏟아져 들어오고 사용자들이 태그를 이용해서 알아서 걸러내야 하는 구조입니다. 또한 어떠한 추가적인 거버넌스 기능도 제공되지 않기 때문에 사실 사용자 입장에서는 너무나 불친절하고 불편합니다.

이를 극복하기 위한 방법은, 각 클라이언트 (예를들면 steemit.com, busy.org 등) 들이 각자의 off-chain 데이터베이스와 API를 구축하고 그위에 전용 UI를 입히는 것입니다. 이 방식이 어려운것은 아니지만, 가장 큰 장애물이 있습니다. 그것은 바로 클라이언트 간의 호환입니다.

만일 제가 끝내주는 스팀잇 클라이언트를 만들고, 동호회 기능을 추가했다고 가정합시다. 그리고 이모티콘 기능과 별도의 글 편집기를 장착했습니다. 그러면 제 클라이언트에서 사용하기위한 데이터들을 따로 저장하고, 블록체인에도 일부 저장하는 등의 방식을 택할 수 밖에 없습니다. 그런데 그런 일련의 비표준적인 방식으로 저장된 글과 데이터는 다른 클라이언트에서는 호환이 되지 않기때문에 결과적으로는 혼자 잘 살겠다고 나머지 클라이언트들에게 해를 가하는 결과를 초래합니다. 이것이 지금 스팀잇의 클라이언트들이 겉모습 말고는 딱히 대단한 변화를 주지 못하고 있는 가장 큰 이유입니다.

결국 이런 새로운 기능들이 스팀잇 “표준”으로 규격화 되고 제공되어야 다른 클라이언트들이 호환성을 유지할 수 있습니다. 그렇다고 이런 부분을 블록체인과 맞닿아 있는 steemd 풀노드에 추가하는것은 여러가지 문제로 불가능에 가깝습니다. 그래서 클라이언트와 steemd 사이에 추가적인 계층을 구성하여 표준화 된 방법으로 제공하려는 프로젝트가 하이브마인드 입니다.

아키텍쳐

하이브마인드는 이름은 거창하지만 사실 매우 단순한 컴포넌트 몇가지로 구성 되어 있습니다.

• 인덱서: 스팀 블록체인을 읽어서 데이터베이스에 차곡차곡 저장합니다.
• 서버: 가장 전면에서 클라이언트들의 API 요청을 라우팅합니다.
• 커뮤니티: 서버 뒷단에 붙어서 API 중 커뮤니티 관련 API 처리를 합니다.

SteemSQL 같은 서버에 여러 API 가 추가되어 데이터를 모듈 형태로 조회할 수 있도록 하고 일부 데이터들을 steemd를 통해 블록체인에 기록하기도 하는 형태의 백엔드 서비스라고 생각하시면 됩니다.

커뮤니티

하이브가 활성화 되면 클라이언트들이 표준화된 방법으로 커뮤니티 기반 UI를 구현 할 수 있습니다. 이는 완전히 off-chain은 아니고, 커뮤니티 설정 정보 자체는 on-chain 이고 글을 community 단위로 분류한다거나 권한을 적용한다거나 하는 부분은 off-chain 입니다.

커뮤니티는 누가 만들수 있나

누구나 만들 수 있습니다. 커뮤니티하나당 steem account 하나가 필요하며, 커뮤니티 설정정보들은 account의 json_metadata에 저장하는 듯 합니다. 따라서 커뮤니티 멤버들이나 권한설정 들은 블록체인에 바로 공개됩니다. 반드시 새로운 어카운트가 필요한것은 아니고 아무나 자신의 계정을 기반으로 하는 커뮤니티를 만들 수 있습니다.

커뮤니티를 생성할때 설정 가능한 값

커뮤니티 이름, 설명, 언어, 유해정보여부 (NSFW)

제공될 커뮤니티 관리 기능

• 멤버 추가: 멤버를 커뮤니티에 추가합니다.
• 멤버에게 권한 부여: 멤버에게 커뮤니티 운영 관련 권한을 줍니다.
• 멤버 제거: 멤버를 제외시킵니다.
• 멤버 뮤트/언뮤트: 특정 사용자의 글을 목록에서 보이지 않도록 합니다.
• 글 뮤트/언뮤트: 글을 목록에서 보이지 않도록 합니다.
• 글 고정/해제: 항상 위에 뜨게 하는 등 공지사항처럼 사용가능할 것으로 보입니다.
• 글 플래깅: 다운보팅 합니다.

멤버 종류와 그에 따른 권한 종류

소스코드상으로 본 멤버 종류와 권한입니다. 커뮤니티장은 모든 권한을 가지고 그 아래로 갈수록 권한이 사라지는 계층구조입니다.

• 커뮤니티장: 생성
• 관리자(admin): 관리자 추가/제거, 조정자 추가/제거
• 조정자 (moderator): 설정 변경, 회원 추가/제외, 사용자 뮤트/언뮤트, 글 뮤트/언뮤트, 글 고정/해제, 특정 사용자 이름이 어떻게 보일지 지정
• 회원(member): 다운보팅
• 손님(guest): 권한이 없음
• 차단됨(muted): 권한이 없음

성능

현재 스팀잇의 실 사용자 수가 얼마 되지 않기때문에 성능이 염려될 수준은 아닙니다. 메이져 SNS만큼의 트래픽을 감당하기에는 한계가 명백한 구조이므로 앞으로 개선할 점이 많아보입니다. 하지만 현재 생각할 수 있는 가장 경제적인 아키텍쳐이기도 하고, 확장성도 어느정도 까지는 보장되므로 큰 우려는 없습니다.

한계

하이브는 off-chain이므로, on-chain 데이터에 대한 access는 변동이 없습니다. 즉 커뮤니티 설정과 권한 설정과 전혀 관계없이 누구든 이전 클라이언트나 steemd API를 호출하여 액션을 취할 수 있기 때문에 on-chain에 행해지는 액션들은 여과 없이 그대로 반영 됩니다. 예를 들면 어떠한 방법으로도 커뮤니티 내의 글을 비밀로 할 수 없고, 커뮤니티 외부에서의 모니터링이나 다운보팅 같은 것을 막을 수는 없습니다.

데이터는 모두에게 노출되며 클라이언트에서 모든것을 설정에 따라 필터링해주는 방식이 됩니다. 하지만 이 방식만으로도 유저들의 만족도는 엄청나게 올라갈 것으로 판단됩니다.

마치며

지금 개발중인 하이브/커뮤니티는 백엔드쪽 구현이 전부입니다. 이부분이 완성되어도 클라이언트들이 커뮤니티 기능을 개발하지 않으면 아무것도 바뀌지 않습니다. 현재 대표적인 클라이언트인 steemit.com과 busy.org 가 하이브마인드의 개발 진행사항에 발맞춰서 신속하게 UI를 개발해 주기를 기대해 봅니다.