Jieun
deserve what you want
글 11개
-
버튼 하나로 커스텀 도메인 붙이기 — 'DNS 전파는 못 줄인다'를 전제로 설계한 3단계 자동화
도메인을 사서 블로그에 붙이는 기능을 만들었는데, 같은 코드로 네 번 사는 동안 네 번 다 다르게 실패했습니다. 원인은 하나였습니다. 우리가 못 줄이는 대기 구간(DNS 전파)을 무시하고 즉시 처리하려 한 것. 이걸 전제로 받아들이자 파이프라인이 '동기 1단계 + 워커 2단계'로 정리됐습니다.
-
Caddy를 배포 경로에서 떼어낸 이야기 — SPOF를 자동으로 건드리는 게 구조적으로 문제였다
배포 한 번에 전 서비스가 60~100초씩 끊겼습니다. blue-green으로 대부분을 없앴는데 리버스 프록시에서 5초가 남았고, 그 5초의 진짜 비용은 5초가 아니라 "5초 아니면 무기한"이라는 분산이었습니다. 그래서 배포 경로에서 아예 떼어냈습니다.
-
[Threads 마케팅 에이전트 3편] 안티디텍트 브라우저로 만든 멀티계정 참여 자동화 — 두뇌·손 분리, CDP 조종, 탐지를 의식한 페이싱
Threads 마케팅 에이전트 엔지니어링 로그 3편: 참여(좋아요·댓글) 자동화. 서브계정을 AdsPower 안티디텍트 브라우저로 격리하고, VPS(두뇌)와 Mac mini(손)를 큐로 잇고, CDP로 브라우저를 조종하며, 탐지를 의식한 랜덤 스케줄로 페이싱한 이야기.
-
[Threads 마케팅 에이전트 2편] 생성 파이프라인 설계 — 4축 콘텐츠 모델, 큐 기반 스케줄링, 3계층 어트리뷰션
Threads 마케팅 에이전트 엔지니어링 로그 2편: 생성 파이프라인. 네 개의 축으로 분해한 콘텐츠 모델, SQLite 큐와 멱등 워커로 만든 예약 발행, 그리고 클릭의 90%가 봇이었던 3계층 어트리뷰션.
-
[Threads 마케팅 에이전트 1편] 3단계 anti-bot을 뚫는 크롤러 설계 — TLS fingerprint부터 CDP 탐지까지
Threads 마케팅 에이전트 엔지니어링 로그 1편: 진짜 병목은 LLM 생성이 아니라 크롤링이었습니다. 안티봇이 무엇을 들여다보는지를 기준으로 수집 전략을 3계층으로 나눈 이야기.
-
프로덕션에서 QPS를 10배로: 실제로 효과가 있는 3가지 전략
"더 빠르게 만들어라"는 막연해 보이지만 아닙니다. 결국 같은 세 가지 수로 수렴합니다 — 캐싱, 데이터베이스 최적화, 그리고 요청에서 부수적인 일을 들어내기.
-
[메신저 부하 테스트 3편] 요청 경로의 FCM은 큐로, 삼키던 실패는 Sentry로 — 메시지 전송 핸들러 정리기
메신저 부하 테스트 실전기 3편: 메시지 전송 핸들러에 섞여 있던 FCM 푸시를 전용 워커 큐로 분리하고, 빈 catch에 삼켜지던 실패를 Sentry로 관측 가능하게 만든 이야기. 외부 I/O 격리와 에러 로그 처리, 두 축을 함께 다룹니다.
-
[메신저 부하 테스트 2편] AI가 생성한 코드에 deadlock이 숨어 있었다 — `unreadCount`를 `lastReadAt`으로 교체한 이야기
부하 테스트 시작 9분 만에 HTTP 오류율 42.8%, 목표 TPS의 12%. 범인은 AI 보조 코딩 중 무심코 작성한 단 한 줄의 updateMany였습니다.
-
[메신저 부하 테스트 1편] 재사용 가능한 부하 테스트 환경 구축 — Make 기반 IaC, Observability, Auth Seeding
메신저의 send API는 몇 TPS까지 버티고, 정확히 어디서 무너지는가. 프로덕션을 복제한 7-노드 환경을 Makefile 한 줄로 언제든 다시 세울 수 있게 만들었습니다.
-
Centrifugo의 Pub/Sub 브로커로 KeyDB를 절대 쓰면 안 되는 이유
KeyDB의 active-replica 모드는 10만 동시 WebSocket 대칭형 듀얼 스택에 완벽해 보였습니다. 그리고 5년치 hang·deadlock 이슈가, 대부분 열린 채로 쌓여 있는 걸 발견했습니다.
-
브라우저에서 크래시에 강한 엔드투엔드 회의 녹음 파이프라인 구축하기
한 시간짜리 브라우저 녹음이 JS 힙을 300MB까지 밀어올렸고, 탭이 죽으면 전부 날아갔습니다. 5분 세이브포인트를 둔 6단계 파이프라인으로 다시 만든 기록.
