Jieun
deserve what you want
글 16개
-
인앱 브라우저에서 간편로그인 버튼이 사라진다 — 로그인이 어려우면 사용자는 그냥 나갑니다
스레드 인앱 브라우저로 들어오면 '카카오톡으로 로그인' 버튼이 사라지고 아이디·비밀번호 폼만 남습니다. 에러 로그에도 안 잡히는 이탈이라, 감지·탈출·폴백 세 단으로 사용자를 진짜 브라우저로 빼냈습니다.
-
88%에서 LLM 계정을 갈아탄 기록 — 수동으로 먼저, 그다음 임계값 80% 자동 전환
그라파나에서 주 계정이 88%에 닿은 걸 보고, 언제 마르는지 계산해 사용자가 없는 새벽에 손으로 갈아탔습니다. 그다음 계정에 순서를 줘서 메인이 비거나 한도를 넘겼을 때만 서브가 받도록 자동화했습니다.
-
코덱스 말고 그록 다회 호출을 택한 실험 기록
같은 글감으로 두 엔진을 나란히 돌렸습니다. 정독 평가에서 이긴 쪽은 코덱스였지만, 결국 코드에서 지웠습니다. 일정 분량 이상은 아무리 지시해도 안 나오는 문제를 해소하기 위해 모델 교체는 하지 않고, 여러번 호출하는 쪽으로 방향을 잡았습니다. 짧게 여러 번 부르는 구조로 가자, 호출 속도가 판단을 결정했습니다. 모자랐던 그록의 답변 품질은 출처를 4,000자까지 넣고 숫자를 코드로 대조해 메웠습니다.
-
키워드 발굴 25초를 0.2초로 — 검색창 자동완성을 프로덕션에 넣기까지
지식iN 질문에서 키워드 조각을 캐내 LLM 두 번으로 정제하던 경로를 구글·네이버 자동완성 호출로 바꿨습니다. 버튼을 누르고 목록이 뜨기까지 25.1초 걸리던 게 0.2초가 됐고 LLM 호출은 사라졌습니다. 구글이 2015년에 쓰지 말라고 공지한 엔드포인트라, 성능보다 먼저 확인할 게 있었습니다.
-
외부 협업자에게 무엇까지 열어줄 것인가 — BFF 구조에서 격리된 개발 환경 설계하기
외부에 문을 하나만 두고 데이터에 닿는 자격증명은 전부 안쪽에 가둬둔 구조였습니다. 디자이너가 로컬에서 화면을 보며 작업하겠다고 했을 때 그 설계와 정면으로 부딪혔습니다. 무엇을 열고 무엇을 잠글지 기준을 먼저 세우고, 셸은 막고 터널만 남기는 키를 발급한 기록입니다.
-
버튼 하나로 커스텀 도메인 붙이기 — '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단계 파이프라인으로 다시 만든 기록.
