Simulation of Incentive Design:
어떤 보상 시스템이 가장 적합한가?
Part 1

Luke Park

Published in

DECON

14 min readFeb 2, 2019

Simulation of Incentive Design

Part 0: Why Simulation?
Part 1: 보상 시스템 설계 문제 및 시뮬레이션 환경 소개
Part 2: 히트맵을 통한 시뮬레이션 결과 오버뷰
Part 3: 시뮬레이션 결과 분석

디콘 시뮬레이션 시리즈의 두 번째 주제는 ‘보상 시스템 설계(Reward System Design)’ 문제입니다. 시뮬레이션 소개에 앞서, 보상 시스템 설계에서 어떠한 문제가 발생할 수 있는지 알아보겠습니다.

럭비공이 어디로 튈지 알 수 있을까?

행동의 다양성

전통적인 블록체인에서는 참여자들이 취할 수 있는 행동의 폭이 좁고 보상도 사람의 개입 없이 자동으로 주어집니다. 가령 비트코인에서는 블록을 채굴하는 과정을 통해서만 보상을 받을 수 있습니다. 이 보상은 문제를 푼 사람에게 코인베이스 트랜잭션(coinbase transaction)의 형태로 자동으로 주어집니다.

이러한 블록체인은 단순한 행동과 온전히 자동화된 보상 덕분에 참여자들의 행동을 예측하고 유도하기가 비교적 쉽습니다. 즉, 온전히 수학적으로 기술 가능하므로 보상 시스템을 설계하기가 용이합니다.

하지만 사용자가 채굴 이상의 다양한 행동으로 보상을 취득할 수 있는 블록체인에서는 보상 시스템을 설계하기가 쉽지 않습니다. 가령 게시글을 쓰던지(Steemit), 어떤 문제에 대한 새로운 알고리즘을 제시 하던지(Numerai), 좋은 데이터 셋을 게시해 두던지(Ocean) 등의 다양한 행동을 참여자들에게서 바란다면, 설계자는 어떻게 보상을 분배해야 할까요?

보상 시스템 설계 문제

참여자가 얼마나 유의미한 기여를 했는지 판단하는 과정을 완전히 자동화하는 것은 아직 불가능하므로, 사용자의 도움을 받아 보상을 분배해야 합니다. 많은 토큰 이코노미는 이러한 문제를 투표(voting)를 통해서 해결합니다. 사용자에게 게시글에 선호를 표시할 수 있도록 하여, 표를 많이 받을수록 더 많은 보상을 가져가게 하는 구조입니다.

가령 어느 시스템에서는 게시글을 작성하면 저자에게 적절한 보상을 주고자 합니다. 이 적절한 보상이란 게시글의 퀄리티, 독자의 호응 등으로부터 산정될 수 있습니다. 그러나 이러한 항목은 질적 평가를 요구하므로 자동화하기 매우 힘듭니다. 따라서 게시글이 받은 좋아요의 수를 기준으로 보상을 분배하고자 합니다. 이 경우 좋아요를 누르는 행위가 바로 투표에 해당하며, 게시글이 받은 좋아요의 수가 곧 득표수가 됩니다.

보상의 총량인 ‘보상 풀(Reward pool)’로 부터 내가 받은 좋아요 수와 전체 게시글의 좋아요 수의 비율만큼 보상을 분배받으면 합리적일 것으로 보입니다. 그러나 이러한 보상 시스템이 사용자의 지속적인, 퀄리티 높은 활동을 유도할 수 있을까요?

보상을 주는 방법들

언뜻 생각하기로는 자신이 작성한 글의 득표수와 전체 표의 비율(proportional)에 따라 보상을 분배하면 합리적일 것 같습니다.

그러나 어떤 사용자들은 노력 여하에 관계 없는 이유(인지도, 상위 노출도 등)들로 하여금 글 작성을 거부할 수 있습니다. 이런 사용자가 많은 환경에서는 득표수와 관계없이 일정량(uniform)의 보상을 주는 구조를 만들어야 할 것입니다.

또한, 너무 많은 사용자가 생태계에 참여하면 (보상의 총량이 제한된 상황에서) 상대적으로 득표수가 많더라도 보상이 작아질 수 있습니다. 이런 상황을 타개하고 사용자들의 퀄리티 높은 참여를 유도하기 위해서는 득표수에 따라 지수적으로(exponential) 보상이 증가하는 구조를 만들어야 할 것입니다.

가장 훌륭한 보상 시스템은 없다. 가장 적합한 시스템만 존재할 뿐.

그렇다면 Proportional, uniform, 그리고 exponential 중 가장 훌륭한 보상 시스템은 무엇일까요? 안타깝게도 이에 대한 대답은 “없다.”입니다. 모든 경우에 적용할 수 있는 만능 구조는 없습니다.

그러나 특정 생태계에 가장 적합한 시스템은 존재할 수 있습니다. 가령 사용자가 많은 환경에서는 exponential한 보상체계가, 반대로 사용자가 적은 환경에서는 uniform한 보상체계가 설계자의 목적달성에 적합할 수 있습니다.

아마 이것은 실제로 생태계가 형성되고 돌아가기 전까지는 답하기 어려운 문제일 것입니다. 하지만 서비스가 구동된 이후에 설계를 뒤엎기는 매우 힘든 일입니다. 그래서 디콘에서는 최적의 보상 분배 시스템은 무엇일지 탐구하는 시뮬레이션을 진행했습니다.

비록 럭비공이 어디로 튈지는 던져보기 전까지 알 수 없다지만, 현실을 시뮬레이션에 잘 반영하면 그 궤적을 대략적으로 알 수 있습니다. 마찬가지로 사용자 개개인의 행동이 아무리 다양 할지라도, 시뮬레이션을 통해 대략적인 양상은 모델링 할 수 있습니다. 그리고 이를 통해 더 나은 보상 시스템 도출을 목표로 하였습니다.

보상 시스템 설계

네트워크 설명

자료화면. [좌] ‘배달의 민족’ 리뷰 이벤트, [우] ‘여기어때’ 리뷰 이벤트

복잡한 보상 시스템의 한 예로써 리뷰 플랫폼을 가정해 보겠습니다. 본 네트워크에서는 사용자들이 어떤 활동을 한 뒤에 리뷰를 남길 수 있는데, 이 리뷰에 달린 좋아요(like)에 따라 보상을 분배받습니다.

이 보상은 보상 풀(reward pool, 보상의 총량)로부터 분배됩니다. 활동을 장려하고 싶은 주체들(리뷰가 필요한 레스토랑, 호텔 등)이 보상 풀의 크기를 결정할 수 있습니다.

주체들은 저마다 원하는 바가 각기 다릅니다. 가령 어떤 플랫폼에서는 리뷰 수가 많기를 바랄 수 있습니다. 반면 다른 플랫폼에서는 수는 중요하지 않고, 퀄리티 높은 리뷰를 원할 수 있습니다. 어쩌면 그 둘의 중간 정도를 원할 수도 있습니다.

시뮬레이션 환경 세팅

다음은 시뮬레이션을 위해 설정 및 가정한 환경입니다.

보상 풀: 사용자들의 리뷰를 유도하기 위해 주체(서비스 제공자)가 투자한 보상의 총량입니다. 기본값은 500입니다.
에이전트(agent) 수: 네트워크의 참여자 수입니다. 기본값은 100입니다.
에피소드: 에피소드 1회는 각 에이전트가 리뷰를 쓰는데 들이는 노력을 결정하고, 리뷰에 대한 보팅을 받고, 받은 보팅에 대한 보상을 받는 과정을 말합니다. 본 시뮬레이션에서 에피소드는 500번 반복됩니다.
노력 범위: 에이전트가 리뷰를 쓰는데 투자하는 시간과 비용의 수준입니다. 0이면 리뷰를 쓰지 않는 것이고, 9는 최대한의 노력으로 리뷰를 쓰는 것입니다. 정수로 표현됩니다.
에이전트들의 자산(asset) 분포: 불공평한 분포로 인해 대부분의 부가 소수에 의해 소유되는 파레토(Pareto) 법칙에 따라, 이를 효과적으로 나타내는 파레토 분포를 사용합니다. 분석의 편의를 위해 자산의 비율이 큰 순서대로 에이전트를 정렬합니다.

비용: 리뷰를 작성함에 소요되는 비용입니다. 에이전트의 노력 수준과 자산 수준에 의해 결정됩니다. 아래에서 보다 자세히 설명하겠습니다.
좋아요: 리뷰에 대한 다른 사용자들의 평가입니다. 득표수와 같습니다. 자신의 노력 수준과 리뷰 이력에 따라 평균적인 수준이 결정되며, 정규분포를 따라 무작위로 결정됩니다.

사용자들은 얻을 수 있는 이득(gain)과 자신이 리뷰를 작성하는데 소요될 비용(cost)을 비교해가며 리뷰 작성에 투자할 노력 정도를 결정합니다. 이득은 리뷰를 작성하여 받는 인센티브이며, 보상은 이득과 비용의 차입니다.

이득 분배 방법론

이득을 분배하기 위한 방법론으로 상기 언급했던 proportional, exponential, 그리고 uniform의 세 가지 경우를 시뮬레이션 해보았습니다. 각각의 상세는 다음과 같습니다.

Proportional

리뷰가 받는 좋아요에 비례하여 이득이 결정됩니다. 가령 10명의 에이전트가 [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]의 좋아요를 얻었으며, 보상 풀이 총 55라고 합시다. 각 에이전트는 순차적으로 [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]의 이득을 받습니다.

Exponential

좋아요 비율의 제곱에 따라 이득이 분배됩니다. 즉, 자신의 리뷰가 다른 에이전트의 리뷰에 비해 상대적으로 많은 좋아요를 받았다면, 더 많은 이득을 기대할 수 있습니다. 제곱 이후에 총합이 1이 되도록 하는 정규화 과정을 거칩니다.

가령 10명의 에이전트가 [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]의 좋아요를 얻었으며, 보상 풀이 총 55라고 합시다. 각 에이전트는 순차적으로 [0.143, 0.571, 1.286, 2.286, 3.571, 5.143, 7.000, 9.143, 11.571, 14.286]의 이득을 받습니다(소수점 넷째 자리에서 반올림). Proportional 대비, 여덟 번째 에이전트부터 보다 많은 보상을 받음에 주목하십시오.

Uniform

좋아요의 수에 관계없이 동일한 양의 이득을 받는 시스템입니다. 가령 10명의 사용자 중에서 5명이 리뷰를 썼으며, 보상 풀이 총 55라고 합시다. 이 경우 5명은 0의 이득을, 또 다른 5명은 11의 이득을 받습니다. 첫 번째부터 다섯 번째의 에이전트가 리뷰를 작성했다면 보상의 분배는 다음과 같습니다. [11, 11, 11, 11, 11, 0, 0, 0, 0, 0]

함수 소개

각 에이전트는 글을 작성함에 드는 비용을 산정하는 ‘cost 함수’, 그리고 작성한 글이 받을 좋아요를 산정하는 ‘like 함수’를 통해 행동을 결정합니다.

Cost 함수

리뷰 작성에 소요되는 비용은 다음과 같은 수식으로 산정됩니다.

에이전트가 사전 보유한 자산의 양(비율)과, 본 리뷰를 작성함에 투자한 노력(endeavor)에 영향을 받습니다. 가정은 다음과 같습니다.

노력을 들이지 않으면 소요되는 비용은 0입니다.
사전 자산이 많은 에이전트는 보상에 대한 한계효용(marginal utility)이 작기 때문에 (비교적 소량의) 인센티브를 받고자 굳이 리뷰를 작성할 요인이 없습니다. 따라서 자산이 많으면 cost도 크도록 설정하였습니다.
노력을 많이 들일 경우, 리뷰 작성에 소요되는 비용도 커집니다.
노력과는 상관없이, 리뷰를 작성함에 절대적으로 소요되는 비용은 상수항(b0)으로 부여합니다.
자산과 노력의 곱셈항으로부터 비용을 산정할 시 비선형적인 양상을 부여할 수 있습니다. 만일 계수 b3가 0이면 자산과 노력의 선형 결합으로 비용이 산정됩니다. 이 계수 b3의 값을 키우는/줄이는 것으로 비선형적 특성을 강화/축소할 수 있습니다.
노력은 0부터 9까지의 정수 값을 가지며 선형적으로 증감합니다. 이를 지수적으로 적용함으로써 비선형적 특성을 강화하였습니다. endeavor와 exp(endeavor)를 시각화하여 비교하면 다음과 같습니다.

비용 계산에 앞서, 사전 자산을 실제 수치가 아닌 파레토 분포에 따라 비율로 할당받는다는 점을 유의해야 합니다. 따라서 참여 에이전트의 수에 따라서 절대적인 수치가 차이 날 수밖에 없습니다.

안일하게(naive) 생각해보자면 10명의 에이전트가 참여하면 각 에이전트의 사전 자산의 기댓값은 0.1이지만, 100명의 에이전트가 참여하면 0.01이 됩니다. 따라서 이 자산의 비율을 바로 cost 산정에 사용하는 것이 아닌, 총 에이전트의 수를 곱하여 정규화하는 것이 바람직합니다. 본 시뮬레이션에서는 계수 b1과 b3에 이러한 고찰을 반영했습니다.

Like 함수

작성한 리뷰가 받을 좋아요는 해당 리뷰를 작성할 때 들인 노력의 정도(행동, action)와 해당 에이전트가 과거에 작성한 리뷰 내역(review history)에 영향을 받습니다. 노력을 많이 들인 리뷰는 퀄리티가 높으므로 독자들의 좋아요를 받을 가능성이 크기 때문입니다. 또한, 꾸준히 리뷰를 작성해온 사용자라면 보다 신뢰할 수 있기 때문입니다.

좋아요를 산정하기 위해서는 노력 여하가 아닌 실제 글을 작성하면서 들인 노력의 정도를 반영해야 하므로, exp(endeavor)가 아닌 action을 기준으로 합니다. like 함수의 수식은 다음과 같습니다.

좋아요는 평균(mu)과 표준편차(std)를 가지는 정규분포를 따르는 확률로써 구해집니다. 이 정규분포의 평균은 행동과 과거 리뷰 내역으로부터 결정되고, 표준편차는 기본값 1.0으로 주어집니다.

행동과 과거 리뷰 내역은 직접적인 상관관계가 없어 선형 결합으로 해석할 수 있습니다.

가정은 다음과 같습니다.

좋아요는 음수 값을 가질 수 없으므로 0 미만의 수치는 모두 0으로 반환합니다.
만일 행동이 0이면 리뷰를 작성하지 않은 것이므로 받는 좋아요 역시 0입니다.
그러나 실제로 받는 좋아요의 양을 정확히 추산할 수 없음을 반영하여, like는 정규분포를 따라 확률적으로 도출됩니다.
과거 리뷰 내역은 window로 주어지는 값 만큼의 과거 에피소드를 바라보는데, 리뷰를 작성했으면 1을, 아니면 0을 저장하고 있습니다. 가령 window가 5이며 현재 에피소드가 20번째라고 하면, 15, 16, 17, 18, 19번째 에피소드에서 에이전트가 리뷰를 작성했는지 여하를 파악하여 [0, 1, 1, 0, 0]과 같이 기록합니다.
과거에 리뷰를 작성했을 경우 더 많은 가점을 줍니다. 즉, 과거 리뷰 작성 횟수가 곧 반영 수치가 됩니다. 상기 예시에서는 0+1+1+0+0=2의 값이 평균을 구할 때 반영됩니다.
계수 c1과 c2를 적절히 조정하는 것으로 행동이 보다 중요한지, 과거 리뷰 내역이 보다 중요한지를 결정할 수 있습니다. 본 시뮬레이션에서는 c1 = 2.0, c2 = 1.0을 기본값으로 두었습니다. 과거 리뷰 내역보다 현재 행동이 보다 중요하다고 판단한 것입니다.

Score는 하이퍼파라미터(hyperparameter)인 window에 따라 가질 수 있는 값의 범위가 크게 차이나므로, window의 크기로 나눠주는 정규화 과정을 거칩니다. 본 시뮬레이션에서는 계수 c2에 이러한 고찰을 반영하였습니다.

Cost 함수와 Like 함수와는 달리 암시적으로 정의된 함수도 존재합니다. 이들 Gain 함수와 Reward 함수는 이득 분배 방법론을 따르거나 다른 함수의 반환값으로부터 도출됩니다.

Gain 함수

에이전트가 리뷰를 작성함으로써 받을 이득(gain)은 좋아요로부터 구해집니다. 상기한 proportional, exponential, 그리고 uniform 이득 분배 방법론에 따라 보상 풀로부터 내가 받을 이익이 결정됩니다.

cost나 like 함수와는 달리, 이득을 산정함에서는 내 리뷰가 받을 좋아요 만이 아니라 다른 모든 에이전트가 작성한 리뷰의 좋아요 값이 필요하므로, gain 함수는 환경(environment)에서 도출됩니다. 즉, 모든 에이전트의 행동이 수행되고 나서야 내가 받을 이득이 얼마일지를 알 수 있습니다.