많은 불평을 듣고 있는 사항 중 하나는 일일 좋아요의 “리필” 주기입니다. 이는 일일 수가 아닙니다. 좋아요를 사용하는 시점에 따라 하나씩 리필되는 것으로 보입니다.
“일일” 한도라는 말은 다음 날 한도가 초기화되어 다시 그 수량을 사용할 수 있음을 의미합니다. 리필이 한꺼번에 이루어진다면 훨씬 더 합리적일 것입니다. 신뢰 등급(Trust Level) 접근 권한은 고유한 상호작용에 기반하므로, 일일 한도는 이에 영향을 미치지 않습니다.
이 문제는 가장 활발하게 상호작용하는 회원들에게 문제가 됩니다. 대부분 이미 TL2 또는 TL3 등급을 달성한 상태입니다. 이들은 사이트에 매우 많이 상호작용하며, 대부분의 경우 하루에 수천 개의 게시글을 작성합니다. 이러한 리셋의 기이한 점진적 리필을 기다려야 한다는 것은 이러한 상호작용에 장벽이 됩니다.
저는 사용자들이 실제로 사이트를 사용하는 방식을 고려하여 좋아요 한도를 확실히 상향 조정할 계획이지만, 대신 디스코르스(Discourse) 팀에 이 요청을 전달하고 싶었습니다. 이 요청을 계속적으로 받고 있습니다. 심지어 "좋옥 감옥(like jail)"에 대해 논의하는 스레드가 10,000회 조회 한도에 거의 도달할 정도입니다.
음, 또 그랬네요. 하하! 솔직히 합리적인 기본 한도란 게 뭔지 나도 잘 모르겠어요. 우리 커뮤니티는 분명히 많이 사용하니까요. 넘겨서는 안 되는 기본 좋아요 상한선이 있나요? 사실 저희는 얼마나 쓰는지 별로 신경 안 쓰거든요. 많을수록 좋으니까요. 이건 신뢰 시스템의 작은 부분일 뿐이라, 기본 좋아요 수를 늘렸다고 해서 신뢰 등급 접근 권한 부분에 아무런 영향이 없었습니다.
기본적으로 이 중 많은 분들이 24시간 내내 활동하고 있어요. 언젠가 롤오버(누적 리셋)가 일어나길 기대하지만, 실제로는 그런 동작을 경험하지 못하죠. “일일” 한도라는 표현은 매일 한도가 리셋된다는 걸 의미하는데, 실제로는 그렇지 않거든요.
이것은 NaNoWriMo 포럼이겠죠. 솔직히 말해서 항상 좀 엉성할 수밖에 없어요 (참가자로서 말하는 겁니다).
아마 직접 테스트해 봐야 할 것 같습니다. "좋아요"는 몇 가지 항목에 대해 계산되므로 /admin/site_settings/category/all_results?filter=like를 확인해 보세요. 만약 10,000명이 50개 항목에 좋아요를 누른다면, 그 50개 항목은 **인기(hot)**가 될 것입니다. 현재 이것이 문제가 되지 않는다면, 무한 좋아요도 괜찮을 수 있습니다.
또한, 사람들이 TL3에 머물러 있는 방식에 영향을 줄 수 있지만, 그 정도 규모의 그룹에 대해서는 아마도 별개의 관심사일 것입니다.
동의하되 의견은 다릅니다 (여러 가지 함축적 의미에 포괄적인 것 같습니다). 하지만 아마도 그 점을 설명하고 텍스트를 변경하는 것이 필요할 것입니다. 아마 사람들은 작동 방식(10,000명의 비"좋아요" 수감자를 제외하고)보다는 그것이 어떻게 설명되는지에 대해 더 문제를 제기하는 것일 수 있습니다.
제가 볼 때, 이건 정말 큰 문제가 아닙니다. 좋아요에 대한 우리의 일일 보고서는 다음과 같습니다:
2020년 4월 1일
15079
2020년 4월 2일
14059
2020년 4월 3일
11591
2020년 4월 4일
10774
2020년 4월 5일
10388
2020년 4월 6일
10101
2020년 4월 7일
12637
2020년 4월 8일
11253
2020년 4월 9일
12596
2020년 4월 10일
9991
2020년 4월 11일
9515
2020년 4월 12일
8996
2020년 4월 13일
12427
2020년 4월 14일
11605
2020년 4월 15일
13795
2020년 4월 16일
16213
2020년 4월 17일
12662
2020년 4월 18일
12566
2020년 4월 19일
11272
2020년 4월 20일
13804
2020년 4월 21일
15423
2020년 4월 22일
13840
2020년 4월 23일
14696
2020년 4월 24일
12972
2020년 4월 25일
12834
2020년 4월 26일
11395
2020년 4월 27일
11871
샘플 합계
—
334k
우리는 TL3 권한을 약간 낮추어 설정해 두었습니다. 게시물 수정 같은 일부 기능은 이미 TL2(트러스트 레벨 2)로 넘어간 상태입니다. TL3의 수정 권한을 켜는 옵션은 꺼져 있습니다. 왜냐하면 TL4(트러스트 레벨 4)와 구별할 수 없기 때문입니다 (우리의 설정 방식으로는 TL4는 수정을 허용하고 TL3는 허용하지 않는 것을 원하지만, 현재로서는 불가능합니다.) 우리는 심지어 модератор(모더레이터)들에게도 콘텐츠 수정을 권장하지 않습니다. 대신 수정이나 삭제를 요청하는 방식을 선호합니다.
모더레이션 관점에서는, 누군가가 얼마나 많은 좋아요를 받았는지는 전혀 신경 쓰이지 않으므로, 기본 설정이 우리에게 적합합니다.
제가 볼 때, 문제는 설명보다는 기능적인 측면에 더 가깝습니다. 그들은 더 많은 항목에 좋아요를 누르길 원하지만 그럴 수 없으므로, 화가 나고 더 많은 항목에 좋아요를 누를 수 있기를 기대합니다. 제한에 대한 근거가 그들의 관점에서는 말이 안 되기 때문에, 불필요한 규제처럼 느껴집니다. 심지어 좋아요 한도를 초과했다는 것에 일종의 자부심 같은 것도 있습니다. (자동화하고 싶지만, 그것은 완전히 별개의 주제입니다) 그걸 위한 배지가 있거든요.
저희 ‘수감자’(좋아요 한도 초과자)들은 무제한 좋아요를 갖게 된다면 행복할 것 같습니다. 그 한도를 빈칸으로 설정하면 무제한 한도가 설정되나요? 실험해 보고 결과를 확인해 볼 수 있을 것 같습니다. 만약 시스템이 어긋나면, 한도를 다시 복구하면 됩니다.
또 다른 방법은 신뢰 수준 2 이상인 모든 사용자의 일일 ‘좋아요’ 배율(likes/day multiplier)을 8배 수준으로 올리는 것입니다. 이렇게 하면 사용자가 처음 가입했을 때 기본 수량만큼의 일일 좋아요 한도를 가지게 되며, 2주간 꾸준히 접속하면 한도가 크게 상향 조정됩니다.
과거 다른 포럼에서는 ‘절벽형’ 좋아요 리셋 방식에 대해 불만을 제기한 적이 있습니다. 이는 리셋이 사용자의 시간대가 아닌 서버의 시간대에 따라 이루어져야 하기 때문에, 하루가 언제 시작되고 끝나는지에 대한 논쟁을 더욱 악화시키기 때문입니다.
정확한 개념을 이해하려면 모바일 클릭어 게임을 떠올려 보세요. 게시글에 좋아요를 누를 때마다 도트(dot) 하나를 소모하며, 각 도트는 다시 충전되기까지 자체의 24시간 타이머가 작동합니다.
네. 우리는 계약직인 지역 자원봉사자들에게 TL4 지위를 부여하고 있습니다. 커뮤니티의 대부분은 다른 사람들이 자신의 게시물을 재분류하는 것을 허용하는 데 대해 매우 불편해했습니다. 우리 커뮤니티는 그런 방식으로 작동하지 않습니다. TL4에게만 별도로 허용할 수 있다면 지역 카테고리를 더 효과적으로 관리할 수 있을 텐데, 아쉽네요. 하지만 이미 적절한 워크플로우를 구축해 두었기 때문에 부담은 크지 않습니다.
네, 그건 그들이 그리워할 기능일 겁니다. 저도 비슷한 기능이 있으면 좋겠습니다. 다만, 게시물을 '좋아요’할 수 있게 하는 것보다는 덜 중요하긴 합니다.
사실 어느 정도 자동화되어 있어요 (아니, 과거형이 맞긴 하네요). 스크립트에서 해당 스레드에 스크립트가 마지막으로 실행된 이후로 게시글을 남긴 사용자 중 ‘Out of Love’ 배지를 가진 사람을 확인하고, 해당 조건이 충족되면 API를 통해 자동으로 배지를 부여하도록 작성해 두었거든요.
사실 이 주제에 대해 글을 쓰고 싶었던 이유가 바로 이거예요. ‘좋아요’ 한도 초과 문제와 관련하여 자주 언급되는 부분이거든요. NaNo 사용자 중에는 한도를 모두 사용했다는 메시지를 받았는데, 관련 배지는 전혀 받지 못한 경우가 많아요.
제 판단으로는 배지 관련 날짜가 서버 시간 기준 자정에 리셋되는 것 같지만, 일일 한도는 기본적으로 24시간 롤링 윈도우 방식인 것 같습니다.
여러 사용자가 좋아요를 사용했는데, x시간 동안 기다려야 한다는 메시지를 받은 적이 있습니다. 그렇게 할 때, 한 게시물에 좋아요를 누른 뒤 두 번째 게시물에 좋아요를 누르려 하면 다시 대기 메시지가 뜨는 경우가 있었습니다. 보통 대기 메시지가 다시 뜨기 전에 몇 개의 좋아요를 사용할 수 있었습니다. 좋아요를 모두 사용할 수 있는 유일한 방법은 24시간 이상 기다리는 것이었습니다.
저는 개발용 설치 환경에서 이 현상을 직접 목격한 적이 있지만, 처음에는 개발용 설치 환경에 콘텐츠를 채우기 위해 API를 사용하는 방식이 어떤 속도 제한(rate limit)에 걸렸기 때문이라고 생각했습니다.
죄송합니다. 더 잘 설명했어야 했는데. 제 개발용 설치 환경에 데이터를 채우는 데 사용하던 스크립트는 제가 속도 제한에 걸린 줄 알고 나서 재작성되었습니다.
이 스크립트는 특정적으로 최대한 빨리 좋아요를 누르지 않도록 재작성되었습니다. 처음에는 2시간 동안 5개의 게시물에만 좋아요를 누릅니다(테스트를 쉽게 하기 위해 설정한 일일 제한입니다). 나머지 테스트는 전부 제 브라우저를 통한 사람의 직접적인 상호작용이었습니다.
추가로, 저는 Digital Ocean 호스트 여러 대에서 스크립트의 여러 복사본을 실행하고 있으며, 각 호스트는 계정마다 관리자 생성된 고유한 API 키를 사용합니다. 목적은 실제 트래픽을 최대한 모방하는 것입니다. 따라서 이론적으로 제가 스팸 제한에 걸린다면, 그것은 IP나 사용자 계정 기반이 아닌 다른 요인에 기반해야 합니다.
NaNo 사용자가 스팸 제한에 걸리는 경우가 일부 있다는 가능성을 배제하지는 않겠습니다. 그중 일부는 확실히 좋아요를 누르는 것을 좋아합니다.
