그건 그냥 사이트의 느낌에 대해 기대했던 것들의 목록일 뿐이에요. Reddit 스타일 테마/Discourse에는 그런 것들이 대부분 기본적으로 포함되어 있거든요.
Topic List Previews는 이 기능의 가장 첫 번째 구현이었습니다.
그건 아무에게도 도움이 안 되는데, 이 게시글은 다른 멤버들의 도움을 받아 제가 무엇을 해낼 수 있는지 시험해 보는 것이 목적입니다. 가능하다면 다른 분들에게도 도움이 되길 바랍니다 
2개의 좋아요
도와주려 노력했지만, 당신은 계속 거절했어요.
행운을 빕니다.
죄송합니다. 제가 반박하려는 것이 아닙니다. 질문하신 내용에 답을 드렸고, Starzen으로 링크를 보내셨는데, 그것은 제가 이루고자 하는 것이 아닙니다. 그러면 제가 보내신 링크의 게시물들을 봤고, 거기서는 무언가를 만드는 것에 대해 이야기하고 있었습니다. 저도 무언가를 만들려고 하고 있습니다. 제가 반박하는 것처럼 느끼셨다면 죄송합니다. 하지만 그런 의도는 아닙니다. 솔직히 말씀드리면, 이 대화의 방향이 어디로 향하는지 모르겠습니다.
3개의 좋아요
OP에게 영감을 준 것에 대해 감사의 말씀을 드리고 싶습니다. (몇 주 전 내비게이션 바에서 사용 중인 플러그인에 대해 제가 질문했을 때 친절하게 공유해 주셨거든요.)
제 의도는 소셜 미디어 인터페이스를 그대로 복제하는 것이 아니라, 우리 사용자에게 더 편리한 경험을 제공하는 것입니다. 현재 이 작업을 진행 중이며, 때가 되면 조사 결과, 최종 결과물, 그리고 리포지토리를 기꺼이 공유하겠습니다. 
참고로, 응답하거나 상호작용할 때 일부 사용자가 잊기 쉬운, 항상 기억해 두면 좋은 내용을 공유합니다: Core Rules of Netiquette
2개의 좋아요
맞습니다. 그래서 저도楼主(게시글 작성자)와 여러분들의 새로운 시도를 적극 지지합니다!
2개의 좋아요
이 문제에 대해 생각해 보니, 사실 그보다 좀 더 복잡한 문제입니다. 네, 모든 것이 토론을 중심으로 돌아가지만, 읽기는 매우 중요한 요소입니다. 독서/콘텐츠 소비자라는 거대한 독자층이 존재한다는 점을 인정하고 있으며, 그 경험을 마찰 없이 만드는 아이디어를 좋아합니다. 저는 오랫동안 쉽게 개인화할 수 있는 피드를 지지해 왔습니다.
5개의 좋아요
“피드 만들기”의 초기 설계가 완료되었습니다.
다음 단계로 DB에 새로운 테이블을 추가할 예정입니다. 다음과 같은 구조입니다.
| 필드 | 용도 |
|---|---|
user_id |
회원 |
category_id |
측정 대상 카테고리 |
impressions |
의미 있는 노출 횟수 |
opens |
열람한 토픽 수 |
likes |
좋아요를 누른 토픽 수 |
replies |
작성한 답변 수 |
dwell_seconds |
누적 읽기 시간 |
affinity_score |
계산된 선호도 점수 |
updated_at |
마지막 재계산 시각 |
첫 번째 버전에서는 관심사 테이블만 필요합니다. 행동 테이블은 어떤 경로를 취할지 결정된 후 나중에 추가할 예정입니다.
2개의 좋아요
오늘 Nodeloc 포럼에서 이와 관련된 것을 보았습니다: NodeLoc
이 접근 방식에 익숙하지는 않지만, 앞으로 어떻게 발전해 나갈지 기대됩니다!
1개의 좋아요
정말 인상적입니다. /r 라우트에 대해 많이 고민했지만, 카테고리 제한 때문에 사용하지 않기로 했었거든요. 어떻게 구현한 건지 궁금하네요.
1개의 좋아요
초기 피드 선택 기능이 추가되어 정상적으로 작동하고 있으며, 최종 단계까지 위에서 언급한 대로 스타일링은 아직 적용되지 않았습니다.
해당 선택 화면은 사용자가 피드에 처음 방문할 때 표시되며, 사용자가 관심 있는 3개의 카테고리를 선택하기 전까지 닫을 수 없습니다. 또한 ‘모두 선택’ 옵션도 추가되었습니다.
관심사 편집 탭도 추가되었습니다.
1개의 좋아요
초기 개인화 피드가 완성되어 정상적으로 작동하고 있으며, 아직 CPU 스파이크는 발생하지 않았고 빠르고 의도한 대로 동작합니다.
현재 피드는 다음과 같은 기능을 수행합니다:
- **관심사 55%, 신선도 25%, 인기 10%, 무작위성 10%**를 기준으로 주제를 점수화합니다.
- 가능한 경우 6번째 위치마다 발견(discovery) 주제를 우선 배치합니다.
- 대안이 있는 경우 한 카테고리에서 연속으로 3개의 주제가 나오지 않도록 방지합니다.
- 삭제되거나 소비된 항목과 독립적으로 페이지네이션을 유지합니다.
- 관심사가 변경되면 피드를 새로고침하고 순서를 다시 정렬합니다.
- 작동하는 팝업과 모두 선택 기능을 포함합니다.
그리고 피드를 변경하면
5개의 좋아요
계속하기 전에 스타일링을 마무리하고 싶었어.
3개의 좋아요
다음으로 할 일은
동작 추적 기능을 추가하기 전에, 이미 구축한 부분을 최적화하는 것입니다:
-
사용자의 캐시된 피드 세션을 제한하여 반복적인 새로고침으로 인해 6시간 분량의 캐시된 목록이 쌓이는 것을 방지합니다.
-
큰 큐에서 CPU 작업을 줄이기 위해 카테고리 혼합 방식을 개선합니다.
-
피드 로딩 시간과 캐시 사용량을 측정합니다.
그 다음에는 동작 추적이 도입됩니다: 실제 노출, 토픽 열람, 읽기 시간을 기록하는 것입니다. 미리 가져오기(Prefetching)는 읽기로 집계되지 않아야 합니다.
초기에는 순서를 변경하지 않고 이러한 신호만 수집할 계획입니다. 추적이 안정적으로 작동하면, 사용자가 30~50개의 게시물을 볼 때 15% 동작 가중치를 점진적으로 적용할 수 있습니다.
1개의 좋아요
좋은 취지네요!
"읽기는 근본적이다(reading is fundamental)"라고 말할 수도 있겠네요. 커뮤니티 매니저로 처음 시작했을 당시의 기반이 된 블로그 글이었습니다:
@Damian_Boon 주제에 이미지가 첨부되어 있지 않은 경우 이 시스템은 어떻게 작동하나요?
데모에서는 AI로 생성된 헤더 이미지를 사용하고 있는데, 이것이 기본 설정이 되지는 않기를 바랍니다. 가끔 한두 개 정도는 괜찮지만, 가짜 이미지가 계속 이어지면 꽤 빨리 눈살이 찌푸려지거든요
Safari 데스크톱에서 관련 주제 링크가 열리지 않는 버그도 조금 있습니다:
3개의 좋아요
완전히 동일하게 작동합니다. 단지 사용하는 것이 토픽 뷰포트일 뿐이거든요. 그래서 지금 보고 계신 것과 동일하게 보이지만, 이미지만 없는 상태가 됩니다.
이것은 테스트 케이스를 위해 모든 콘텐츠가 AI로 생성된 데모 사이트입니다.
알려주셔서 감사합니다. 홈페이지에서 캐시를 사용하고 있기 때문에 나중에 확인해 보겠습니다.
2개의 좋아요
지금까지 만든 것을 바탕으로 서버 부하를 테스트해야 합니다. Openrouter 계정이 있고, 10개의 봇이 동시에 게시물을 올리는 상황을 테스트하고 싶습니다. 예를 들어 다음과 같은 설정으로 테스트할 때, 어떤 경로로 진행하는 것이 가장 좋을까요?
봇 설정:
-
username: wtf_gaming
category: Gaming
personality: gaming-news
posts_per_hour: 30
replies_per_hour: 15 -
username: wtf_tech
category: Tech
personality: tech-news
posts_per_hour: 30
replies_per_hour: 15
그리고 10개의 로그인된 봇이 30초마다 /feed 페이지를 새로고침하도록 하는 방식입니다.
또는 Discourse Rails 프로세스 내부에 AI 요청을 직접 넣는 대신, Discourse와 OpenRouter와 통신하는 작은 독립형 Python 서비스를 만드는 방식입니다.
테스트를 위한 가장 좋은 방법은 무엇일까요?
1개의 좋아요
정말 멋져 보입니다. 최종적으로 새로운 주제로 구현할 수 있을까요?
2개의 좋아요
카테고리 선택기 피드가 포함된 테마 컴포넌트가 있으면 좋겠습니다!
1개의 좋아요