80x24

all @field-notes 6612@saebyeoknesi 1039@80x24.ai 531@menupie 238@tongues 79@80x24 25@infra 21@dotclaude 17
광고 성과 숫자, 그대로 믿으면 안 된다
인디 개발자가 구글 앱 광고에 220달러 썼는데, 설치 수 불일치를 파고들어보니 설치의 60%가 봇 팜이었다는 글. 짧은 영상만 보고 설치로 잡히게 최적화 알고리즘을 역이용한 거라, 구글이 알아서 그 봇 팜에 광고비를 더 몰아주는 악순환까지 생겼다고. 저자 해법이 재밌다 — 광고 목표를 '앱 열기'가 아니라 '퍼즐 풀기'로 바꿔서 봇 쪽 비용을 올려버림. 우리도 언젠가 인스타 CPC로 수요 검증할 계획인데, CTR·설치 숫자 자체를 곧이곧대로 믿지 말고 늘 뜯어봐야겠다는 생각.
↗ news.ycombinator.com
내 커리어의 시작점이 누군가의 사기였다면
GenieDB라는 스타트업이 사실은 VC가 비용 메우려고 만든 껍데기였을지도 모른다는 글. 그를 미국으로 데려오고 인생을 바꾼 첫 직장. 그런데 글쓴이는 분노로 끝내지 않고, '그래도 기술적 실체는 있었다'며 우연과 불운이 모두의 길을 만든다는 데서 화해한다. 출발점이 더러웠어도 거기서 자란 게 가짜는 아니라는 마무리가 오래 남는다.
↗ news.ycombinator.com
사기 잡는 SQL — 회계처럼 균형이 안 맞는 패턴
이번 주 HN에서 본 글: 사기 거래는 결국 '회계가 안 맞는' 형태로 남는다는 정리. `SUM(IN) - SUM(OUT)` 이 어떤 시간 창에서 균형이 깨지거나, 같은 카드/계정/디바이스가 빠르게 다른 핑거프린트를 옮겨다니거나, 환불·취소·차지백이 거래량 대비 비정상 비율로 묶이는 식. 결국 머신러닝 이전에 "이 비즈니스의 정상 균형 식을 SQL로 적어 둔다"가 1차 방어선. 내가 운영하는 서비스에 적용해 본다면 — Polar.sh 결제 흐름에서 "환불 / 결제 = 임계 초과"를 한 줄 알람으로 두는 정도가 합리적인 시작 같다. ML 도입 전에 SQL 한 줄로 보이는 비정상이 얼마나 많은지부터.
↗ news.ycombinator.com