ㅁ 근황

• 연구팀에서 노션 페이지 유지 —> 정보의 공유 받는 느낌 있어서 좋았음. 다른 팀도 고려해보면 어떨까?
• 항심님 A-Lab : 자율성 연구 모임, 7명 구성원으로 온라인 모임을 먼저 진행 중이며 자율적인 운영을 위해서 각자에 대하여 알아보는 시간을 가지고 있음. 그러한 차원에서 강점 검사를 진행하고 내용 공유 예정. 구성원들의 자율성뿐 아니라 DAO LAB의 자율성에 대하여서도 연구할 예정
• 제이슨 :
  • 다음 주 오프라인 모임 —> 30분 정도 catch-up 할 시간 드릴 예정
  • 서브랩 활동 공유
  • 모두연 DAO 킥오프 관련하여 진행사항 및 결과 등 공유할 예정
  • 프레임워크 + 툴 만들기에 대한 구상과 설계 등에 대하여 가능한 범위 내에서 공유
  • 전체 대상으로 공유할 내용 있는 분 발표 세션 혹은 외부에서 초청하여 발표 세션 진행 예정
  • 5월 중에는 외부 분들 2분 정도 모셔서 진행하려고 계획중 (폴님 등)

ㅁ 발표자료

03-daolab2-service_dao_tools.pdf

ㅁ 발제 (맑/한/고/양) 서비스 다오 사례 연구와

• 서비스 DAO 종류와 소개

  • 서비스 DAO : 금전적인 보상에 기반하여 특정 프로젝트를 수행
  • 예시

  

Q1. 다른 DAO와의 차이점은

• 맑 : 실제로 참여자들과 삶과 일이 연결되어 있다는 점에서 가장 큰 차별점이 있음
• 광현 : 웹2 에이전시 (외주회사)와 유사, 다만 DAO 시스템이므로 기여도에 따라 보상을 받아감. 인간 한 사람의 신뢰도가 더 중요해질 것이라고 생각함. 웹2 같은 경우에는 개인정보가 제공되나 웹3 같은 경우에는 닉네임 하나만을 가지고 신뢰도를 구축해서 서비스 제공이 되어야 하므로 오히려 신뢰도가 중요해졌다고 생각됨
• 제이슨 : 서비스 DAO가 다른 DAO와 매우 다름. 주식회사는 소유와 경영이 분리되는 것이 특성, 다른 DAO 토큰 홀더들이 거버넌스 참여하는 정도 선에서 소유와 경영이 분리되는 것으로 보임. 그러나 서비스 DAO는 토큰 홀더가 일하는 사람으로서, 거버넌스까지 하여 소유와 경영이 합쳐져 있는 구조이라는 점에서 차이가 있다. 투자DAO나 Collector DAO는 feasible 하게 만들어 내기가 더 용이하나, 서비스 DAO는 여러 시행착오를 통해서 구조가 도출되어야 할 것이라고 생각된다.
• 맑 : 짜기 나름이긴 하지만 설계하기가 미묘한 점들이 있어서 해당 사항은 한번
• 제이슨 : 전문적인 서비스를 제공하는 전문가들이 모여서 만들 DAO가 이것이고, 전문가들이 모여서 만드는 DAO라고 한다면 서비스 DAO의 카테고리에 들어가지 않을까?
• 광현 : 맑의 경우 회사 시소가 서비스 DAO와 비슷하다고 느꼈다고 하였는데 어떤 점에서 그러 하였는지?
• 맑 : 구성원이 정규직이나 프리랜서냐 등에 대하여 구분/가치를 크게 두지 않음. 그런 면에서 비슷하다고 생각하고, 사람들이 일하는 방식과 조직에 대한 변화에 대한 호기심. 한국인들이 일을 새로운 것을 더 할 필요는 없다고 생각. 일을 어떤 가치를 가지고 하는 지에 대하여 의문이 있음. 그런 면에서 DAO라는 구성과 맥락적으로 닿은 부분이 있다고 생각함

Q2. 웹2 에이전시에 비한 장점은?

• 맑 : 웹2 에이전시의 경우에도 포트폴리오만 보고 담당자는 사실 잘 모르는 경우가 많음. 실제 에이전시도 해당 개발자가 아직 있는지도 모름. 오히려 웹3에서 익명이기에 그런 개인/실력 검증을 하려는 경향이 있는 것이 아닌가고 생각.
  • DAO라는 커뮤니티 속성으로 더 좋은 인재풀인 것이 아닐가 생각. 그것으로 인해서 경쟁력이 생기는 것이 아닌가?
  • 협업관리 시스템/페널티 제도가 있는가? 실제로 DAO에서 별도로 협업관리 시스템이 있어 보이지는 않았고, 페널티에 대하여 잘 구성된 시스템이 있지는 않아 보였음.
• 제이슨 : 웹2에서는 어떻게 분쟁관리 등을 하는지?
  • 맑: 선수금 /중도금 / 후수금 포인트를 잡아서 명기하고, 갈등이 제일 많이 나온 것들이 해결하는 방식으로 활용하는 것으로 경험상 클라이언트와 팀의 매칭이 잘 안되었거나, 책임감 없는 사람인 경우등이 잇어서 기존에는 “외주성”(납품심) 계약기반으로 중간 과정 공유 없이 결과물만 보여주는데, 실제 과정을 보면 일정 조율, 결과물 범위 등에 있어서 맥락이 전달되지 않아서 상호 조율이 어려움. 특히 디자인의 경우에는 그런 경우가 많음. 이것을 어떻게 바꿀까 하다가 회사 안에서처럼 구조를 변경하여 2주 단위로 스프린트하고 2주 단위로 정산하고, 단계별로 진행하는 방향으로 전환함. 회사가 좋은지 안좋은지 간보기 보다는 2주 단위로 서로 실험해보고 안 맞으면 빨리 정리하는게 더 효율적이라고 생각하였음. 어차피 정말 잘 맞는 팀/사람일지는 사전에 제공되는 정보로 판단하기는 어려움.
  • 제이슨 : 고객 입장에서 외주를 많이 주어보았는데, 유명 플랫폼도 엄청 많이 외주를 주는 경우가 많음, 거의 외주 팀이 본사라고 할 수 있을 정도로, 한국 개발사는 외주를 싫어하는데 어거지로 외주를 시키면 중간 결과를 이야기해주지 않고 2달씩 지나고 나서 방향이 다르다고 해서 뒤집히고 문제가 많이 됨. 결국 실제로 만족스럽게 끝난 경우가 거의 없는데 실제로는 텀이 너무 길어서 그렇지 않은가 생각이 됨.
  • 맑 : 아웃소싱과 n잡에 대해서는 한번 사례 등 경험 공유할 수 있음
• 서비스 다오 찾는 플랫폼이 있는지?
  • 맑 : 잘 없는 것 같다.
• 고광현 : 블록체인 서비스 개발을 하려면은 생태계에 대한 이해가 있어야 하는데 웹2에 맡기기 보다는 서비스 DAO가 장점이 있지 않을가?
  • 맑 : 블록체인 인프라 쪽은 기존 개발사/개발자/개발조직이 보통 헤비하게 들어가지 않는지
  • 광현 : 블록체인 서비스 개발 경험이 많은 사람이 아니라, 새롭게 서비스 시작하는 분들의 경우에는 크몽 등에서 블록체인 관련 개발을 해줄 분들을 찾는 경우가 많은데, 이럴 때에는 서비스 DAO를 가는 것이 더 좋지 않은가 생각
  • 맑 : 초창기에는 블록체인 프로젝트 받지 않음. 나중에는 조금 받음. 클레이트트 API가 생각보다 쉬워서 잘 적응할 수 있어서 받기 시작함. 지금의 AI와 비슷하다고 봄. 블록체인도 가다보면 도메인 이해도가 더 올라가고 보다 많은 사람들이 이 업무를 할 수 있을 것이라고 생각함.
  • 제이슨 : 애플리케이션 개발과 인프라 개발은 천지차이 : 백엔드 / 분산시스템 /크립토를 알아야 인프라 개발이 가능. 그래서 동유럽에 많이 줌. 애플리케이션은 블록체인 몰라도 개발할 수 있음. 대부분 소스코드가 다 공개되어 있음. 플랫폼들을 직접 액세스하지 않고 외부 API로 접속이 가능함. 컨트랙트를 직접 개발해야 하면 이야기가 다르지만, 그렇지 않은 경우에는 웹2에서 역량 있는 사람들 충분히 찾을 수 있음. 웹3 서비스들의 경우에는 실제로 fiat로 지급하지 않고 토큰으로 줄려고 함. 그런데 웹2 에이전시는 fiat 화폐 지급 받기 어려움. 그래서 크립토로 결제 할 수 있는 서비스DAO를 쓰려고 함. 에스크로 서비스 같은 경우에도 대금을 락을 걸고 키를 멀티시그로 의뢰인과 서비스 제공자가 둘이 같이 있으면서 양쪽이 다 만족해야 지급되도록 설계가 가능함. 이런 식으로 QC를 할 수 있음. 제품은 좋은데 의뢰인이 돈은 주고 싶지 않을 때, 제3자를 끼워서 해결함. 양쪽과 이해관계 없는 제3자를 옵저버로서 판단하고 손들어줄 수 있게 함. 3개 키 중에서 2개 키만 오케이면 리턴되게 하는 등 구조 설계. 웹2에서 결과에 대한 QC가 잘 안됨. 마이크로 단위로 잘라서 하는 것이 아니면 사실 결과물에 대한 통제가 어려운데 블록체인으로 하면 풀 수 있는 방법이 있다고 생각됨. 이해당사자 아닌 외부의 참여자들이 판결을 내리게 하는 것. 외부의 참여자들이 여러사람이 묶여서 분산해서 처리되고 보상이 이루어지게 하는 것. 에스크로도 분산된 방식으로 여러 재판관을 둘 수 있음.
  • 제이슨 : 레이드길드 관련 : 리더 없고, 거버넌스 같이하는 구조에서 팀빌딩이 어려울 것이란 점에서 레이드길드 운영이 어렵지 않을까 생각. 보상 큰 프로젝트 참여 원하는 팀들 중 어덯게 지정하지, 룰세팅은 리더 없이 어떻게 하지? 이런 점에서 의문이 있음. 전문성 (expertise) 문제도 있음. 최적의 팀을 구성할 수 있는 것이 있는데, 리더가 알아서 이것을 조율할 수 있는데, 여기는 거버넌스가 모두가 개입하므로 더 어려움. 분쟁이 발생하기 시작하면 내부가 깨짐. 중앙화된 거버넌스가 아닐 때 어떻게?
  • 맑 : 전체 DB에 등록된 인재 200명 중인데, 그 정도 규모에서는 라이프사이클/ 비용/ 프로젝트 핏이 맞아야 지원하므로 생각보다 겹치는 것이 문제가 크게 되지는 않았음. 프로젝트의 유명도나 레퍼런스를 더 중요하게 보았음. 시소의 경우에는 제안 자체를 프라이빗하게 관리함. (중앙화된 거버넌스)