저는 제가 출시한 몇 가지 오픈 소스 (OSS) 프로젝트의 첫 실제 사용자들을 확보하려는 1인 개발자입니다. 모두가 똑같은 말을 합니다. 사용자들이 이미 있는 곳으로 가고, 유용해지며, 스팸을 하지 말라고 말이죠. 개발자에게 그것은 주로 Reddit을 의미합니다. 그래서 저는 당연한 엔지니어식 접근법으로 자동화를 시작했습니다.

제가 무엇을 만들었는지, 무엇을 측정했는지, 그리고 의도적으로 제거한 기능 하나가 무엇인지 소개합니다.

빌드 (The build)

의존성이 전혀 없는 작은 Node 스크립트입니다. 약 14개의 서브레딧 (subreddits)에서 공개된 /new.rss 피드를 가져와, 제가 실제로 알고 있는 분야(AI agents, Claude Code, OSS, i18n/일본 시장 관련 사항)와 얼마나 관련이 있는지 각 게시물의 점수를 매깁니다. 그다음 이미 확인한 게시물은 중복을 제거하고, 답변을 위한 제안된 관점과 함께 상위 게시물들의 순위를 매깁니다. API 키도, 로그인도 필요 없습니다. 오직 RSS와 점수 산정 함수 (scoring function)만 사용합니다.

첫 번째 실제 실행 결과, 솔직한 수치는 다음과 같습니다: Reddit은 브라우저가 아닌 RSS에 대해 매우 엄격하게 속도 제한 (rate-limits)을 겁니다. 저의 단순한 방식으로는 모든 것이 429 에러를 반환하기 전에 14개 서브레딧 중 2개만 가져올 수 있었습니다. Retry-After를 준수하는 백오프 (backoff)를 추가한 후, 재시도를 통해 14개 중 7개를 복구했습니다. 그중에서 175개의 게시물을 가져왔고 49개를 "관련 있음"으로 점수를 매겼습니다.

처음부터 잘못되었던 점

49개가 관련이 있었지만, 높은 점수를 받은 대부분은 "X를 만들었습니다"와 같은 출시 (launch) 게시물이었습니다. 이 게시물들은 제가 관심을 갖는 것과 동일한 키워드로 가득 차 있기 때문에 높은 점수를 받습니다. 하지만 이들은 답글을 달기에 최악의 대상입니다. 누군가의 출시 게시물 아래에 동료 개발자로 나타나는 것은 경쟁자의 소음으로 읽히며, 게시자는 당신의 날카로운 의견이 아니라 인정을 원하기 때문입니다.

실제로 답변할 가치가 있는 게시물은 질문 형태의 것들이었습니다. "왜 Claude Code는 긴 세션 동안 점점 멍청해지는 것 같나요?" "제가 뭘 잘못하고 있나요, 프롬프트당 제한량을 전부 다 쓰고 있어요?" 같은 것들 말이죠. 저는 매일 똑같은 벽에 부딪히기 때문에, 그런 질문에는 실제 경험을 바탕으로 답변할 수 있습니다. 그래서 저는 출시 관련 언어("I built", "introducing", "check out my")에는 음수 가중치 (negative weights)를 추가하고, 질문 신호 (question signals)를 강화했습니다. 49개 중 약 3개만이 진정으로 적합했습니다. 단 3개였습니다. 그 비율은 저를 놀라게 했고, 이것이 실제 교훈입니다. 병목 현상은 게시물을 찾는 것이 아니라, 제 시간을 들일 가치가 있는 소수의 게시물을 찾는 것이었습니다.

삭제한 부분

물론 계획은 루프를 완성하는 것이었습니다. 답글을 생성하고, 게시하고, 다음으로 넘어가는 것이죠. 어쩌면 그 과정에서 자동으로 추천(upvote)까지 해줄 수도 있었을 겁니다.

하지만 실행에 옮기기도 전에 그 모든 기능을 삭제했습니다.

두 가지 이유가 있는데, 둘 다 도덕적인 이유는 아닙니다. 첫째, Reddit은 자동화된 댓글 작성, 특히 자동화된 추천(voting)을 조작(manipulation)으로 간주하며, 얼굴 없는 저카르마(low-karma) 계정이 이를 수행하면 즉시 섀도우밴(shadowban)을 당합니다. 계정 자체가 제가 구축하려는 자산입니다. 이를 자동화하는 것은 추위를 피하기 위해 자산을 불태우는 것과 같습니다. 둘째, 인간처럼 보이도록 최적화된 AI 작성 답글은 결국 AI가 작성한 답글일 뿐이며, 특정 서브레딧(subreddit)에서 하루 종일 시간을 보내는 사람들은 이를 귀신같이 알아챕니다. 답글이 실제로 먹히는 핵심은 영리한 문구(phrasing)가 아니라, 오직 당신만이 가진 실제적인 직접 경험(first-hand detail)입니다. 봇에게는 그런 것이 없습니다. 저에게는 있습니다.

그래서 도구는 한 단계 일찍 멈춥니다. 게시물을 3개 찾아내고, 각각에 대한 답글 초안을 작성한 뒤, 저에게 전달합니다. 저는 스레드(thread)를 읽고, 그 순간의 제 말투에 맞게 한 줄을 수정하여 직접 게시합니다. 90초면 충분합니다. 기계는 지루한 작업의 90%(모니터링, 필터링, 초안 작성)를 수행하고, 저는 핵심인 나머지 10%를 수행합니다.

"실제적인 디테일"은 어디에서 오는가

이 방식은 실제로 투입할 수 있는 생생한 경험(lived details)이 있을 때만 작동합니다. 저의 경험은 지루한 것들에서 나옵니다. 저는 Medusa, Jan, Memos에 풀 리퀘스트(pull request)가 병합된 경험이 있으므로, 누군가 기여(contributing)나 특정 버그 유형에 대해 물을 때 추측하지 않습니다. 누군가 왜 자신의 긴 Claude Code 세션 성능이 저하되는지 물으면, 블로그에 나온 내용이 아니라 제가 직접 세션에서 측정한 값을 말해줄 수 있습니다. 그것이 자동화할 수 없고 속일 수도 없는 부분이며, 낯선 사람을 당신의 이름을 기억하는 사람으로 바꾸어 놓는 부분이기도 합니다.

만약 당신도 똑같은 것을 만들고 싶다면

찾기 도구(finder)를 만드세요. 그것은 진정으로 유용하며 만드는 데 오후 시간 정도면 충분합니다. 게시 도구(poster)는 건너뛰세요. 당신이 원하는 레버리지(leverage)는 "모든 것에 답장하기"가 아니라 "좋은 질문을 절대 놓치지 않기"여야 합니다. 자동화의 목표를 제출 버튼이 아니라, 당신의 주의력(attention)에 맞추세요.

점수 산정 방식이 덜 민망해지면 아마도 이 레이더(radar)를 오픈 소스(open-source)로 공개할 것입니다. 핵심 요약을 원하신다면 다음과 같습니다: RSS 입력, 관련성(relevance) + 의도(intent) 점수 산정, 출시 홍보 문구(launch-speak)에 대한 음수 가중치(negative weights) 적용, 그리고 마지막 단계에서의 인간 참여(human in the loop). 이것이 전부입니다.