그냥 html 있는 디렉터리를 웹서버에 지정하면 바로 접속 가능한게 웹페이지죠. Caddy 같은 것 쓰면 설정 네댓줄로도 가능합니다. 외부 공개도 요즘은 cloudflared 같은 편한 것들 많고요.
모든 걸 직접 작성하지 않아도 Hugo 같은 정적 사이트 생성기도 있고요.
두 분이 논의하신 질문에 운영자로서 데이터를 하나 보태자면, 적어도 저희 리더보드 범위에서는 아직 어느 쪽으로도 결론이 안 납니다. 두 달을 결산해보니 AI 봇 10개 중 통계적으로 운과 구분되는 성적을 낸 봇은 하나도 없었고, 95% 신뢰구간이 0 위로 올라간 건 "무조건 상승"만 찍는 베이스라인 4개뿐이었습니다. 사람 참여자는 아직 표본이 적어 비교 단계도 못 갔고요.
마침 첫 댓글의 문제 제기를 인용하면서 시작하는 결산 글을 오늘 올렸습니다. 흥미로우실 것 같아 남깁니다: https://ldbd.app/ko/blog/prediction-log-03-two-month-review
봇이든 사람이든, 주장 대신 트랙레코드로 확인되는 걸 목표로 계속 쌓아보겠습니다.
저도 초기 제품 하나를 굴리면서 커뮤니티, 콜드 아웃리치, 런치까지 이것저것 해봤는데, 가장 크게 배운 건 피드백은 노출이 아니라 이해관계를 따라온다는 거였어요.
그냥 둘러보러 온 사람은 거의 피드백을 안 남깁니다. 실제로 쓸모 있는 피드백은 뭔가를 걸어본 사람, 예를 들어 가입까지 갔거나 쿠폰을 실제로 써봤거나 쓰다가 어딘가에서 막힌 사람한테서 나왔어요. 그래서 둘러본 사람의 댓글률을 올리자는 접근보다, 첫 실사용의 문턱을 낮추고 막히는 그 지점에서 말을 거는 쪽이 훨씬 나았습니다.
초기엔 공개 장치(업보트나 댓글)보다 1:1이 압도적이었어요. 실제로 써본 소수에게 직접 연락해서 이거 하나만 하는 식으로 답하기 쉬운 좁은 질문을 던지면, 공개 댓글을 기다리는 것보다 응답률이 훨씬 높더라구요. 두루뭉술한 피드백 남겨주세요는 거의 씹히더라구요.
큐레이션과 커뮤니티 중에서는, 제품과 사용자 수가 적을 때 커뮤니티 메커니즘(업보트 루프)은 임계질량이 없어서 오히려 텅 빈 느낌을 줍니다. 그 구간에선 운영자가 직접 써보고 쓰는 Dev Log 같은 큐레이션이 신뢰도 쌓이고 컨트롤도 되니 거기에 무게를 두는 게 맞다고 봤어요. 커뮤니티 층은 밀도가 어느 정도 쌓인 다음에 제값을 하더라구요.
그냥 html 있는 디렉터리를 웹서버에 지정하면 바로 접속 가능한게 웹페이지죠. Caddy 같은 것 쓰면 설정 네댓줄로도 가능합니다. 외부 공개도 요즘은 cloudflared 같은 편한 것들 많고요.
모든 걸 직접 작성하지 않아도 Hugo 같은 정적 사이트 생성기도 있고요.
사용해봐주셔서 감사합니다!
그리고 좋은 의견두요.
https://github.com/jadhvank/ko-llm-classifier/tree/main/extension
크롬 브라우저 확장 만들었습니다. 한번 이것도 써봐주세요.
헐 그런게 되는거였나요? 당장 셋업해봐야겠네요.
그러게요. 공감합니다. SDK 의존성이 생기긴 하겠지만, 런닝커브가 높아서 차라리 나을듯 합니다.
지금 확인해보니 서버가 터져서 공개서버 디렉토리에서 빠졌었네요. 서버 재실행했습니다.
앗 먼저 감사합니다. Public 서버라고 나오지않나요?
두 분이 논의하신 질문에 운영자로서 데이터를 하나 보태자면, 적어도 저희 리더보드 범위에서는 아직 어느 쪽으로도 결론이 안 납니다. 두 달을 결산해보니 AI 봇 10개 중 통계적으로 운과 구분되는 성적을 낸 봇은 하나도 없었고, 95% 신뢰구간이 0 위로 올라간 건 "무조건 상승"만 찍는 베이스라인 4개뿐이었습니다. 사람 참여자는 아직 표본이 적어 비교 단계도 못 갔고요.
마침 첫 댓글의 문제 제기를 인용하면서 시작하는 결산 글을 오늘 올렸습니다. 흥미로우실 것 같아 남깁니다: https://ldbd.app/ko/blog/prediction-log-03-two-month-review
봇이든 사람이든, 주장 대신 트랙레코드로 확인되는 걸 목표로 계속 쌓아보겠습니다.
langchain langgraph를 사용하는 모든 경우는 AI SDK로 대체 가능한 듯
현재 화면에는 로비 URL로 https://lobby.example.com 예시값만 표시되고, 기본 공개 서버 주소나 서버를 확인하는 방법은 별도로 찾지 못했습니다.
어떻게 사용 해야 하는지 확인가능할까요?
지구야미안해
오오 디테일한 의견 감사합니다!!!
어찌되었든 손품/발품 파는게 최고인거 같네요 ㅎㅎ
저도 초기 제품 하나를 굴리면서 커뮤니티, 콜드 아웃리치, 런치까지 이것저것 해봤는데, 가장 크게 배운 건 피드백은 노출이 아니라 이해관계를 따라온다는 거였어요.
그냥 둘러보러 온 사람은 거의 피드백을 안 남깁니다. 실제로 쓸모 있는 피드백은 뭔가를 걸어본 사람, 예를 들어 가입까지 갔거나 쿠폰을 실제로 써봤거나 쓰다가 어딘가에서 막힌 사람한테서 나왔어요. 그래서 둘러본 사람의 댓글률을 올리자는 접근보다, 첫 실사용의 문턱을 낮추고 막히는 그 지점에서 말을 거는 쪽이 훨씬 나았습니다.
초기엔 공개 장치(업보트나 댓글)보다 1:1이 압도적이었어요. 실제로 써본 소수에게 직접 연락해서 이거 하나만 하는 식으로 답하기 쉬운 좁은 질문을 던지면, 공개 댓글을 기다리는 것보다 응답률이 훨씬 높더라구요. 두루뭉술한 피드백 남겨주세요는 거의 씹히더라구요.
큐레이션과 커뮤니티 중에서는, 제품과 사용자 수가 적을 때 커뮤니티 메커니즘(업보트 루프)은 임계질량이 없어서 오히려 텅 빈 느낌을 줍니다. 그 구간에선 운영자가 직접 써보고 쓰는 Dev Log 같은 큐레이션이 신뢰도 쌓이고 컨트롤도 되니 거기에 무게를 두는 게 맞다고 봤어요. 커뮤니티 층은 밀도가 어느 정도 쌓인 다음에 제값을 하더라구요.
말씀해주신 내용 모두 적용 완료했습니다~~ 고맙습니다!
지금이라도 바꿀까 생각하다가 두 분처럼 생각하고 들어오시길 것 같아서 유지하겠습니다!! ㅎㅎ
안그래도 이 댓글 달려고 스크롤 내리고 있었습니다 ㅋㅋㅋ
하단에 '품절된 것 같아요' 버튼은 넣었는데, 할인이 종료 된 부분에 대해서는 생각하지 못했어요. 말씀해주신 것처럼 크롤링은 안 될 것 같아서, 선착순 상품에 대해서는 매일 직접 상품 페이지에 들어가서 확인할 수 있는 검수 페이지를 별도로 추가했어요!!
생각하지 못했던 좋은 의견 감사합니다!! 바로 적용할게요~
할인율, 인기순 등 필터도 마찬가지네요!
너무 좋아요! 감사합니다!
그런데, 하나 아쉬운 점이 있어요.
하단 네비게이션 바 위에 "전체", "뷰티", "식품" 등 카테고리 필터 UI가 있는데, 이게 클라이언트 상태로만 관리되어있는지 브라우저 새로고침을 하면 필터 상태가 초기화되네요.
URL을 이용해 새로고침 후에도 필터 상태가 유지되면 좋을 것 같아요!
개발적으로 가면 크롤링 해서 가격 바꼈나 보는건데 상품 크롤링은 네이버, 쿠팡 이런 곳 전부 까다롭게 막고 있어서 비 개발자면 힘드실 것 같고
간단하게는 그냥 제보 버튼 만들어서 만료 처리 3명 이상이면 삭제 시키던가 하는게 좋지 않을까요..