맞는 글이 없어요.
Deservewhatyouwant.
전체 글
위블로그 베타에서 실제 사용자의 질문과 행동은 처음 세운 고객 가설과 달랐습니다. 이 차이가 온보딩과 B2C/B2B 방향, 제공 가치의 재정의로 이어진 과정을 돌아봅니다.
위블로그에서 사용자가 원하는 글감을 바탕으로 자료와 출처를 확보하고 글을 생성·발행했습니다. 커스텀 도메인을 연결한 뒤 구글 검색 노출을 확인하기까지의 흐름과 한계를 소개합니다.
개발자 두 명과 디자이너, 마케터가 VPS 한 대를 함께 쓰면서 역할별로 계정과 홈, 포트를 나눴습니다. 각자의 작업공간은 분리하되, 운영 API 연결은 공용 터널 서비스가 담당하도록 구성했습니다.
16GB 맥북의 한계 때문에 코드 실행과 빌드를 96GB VPS로 옮기고, 맥북·개발 서버·운영 서버의 역할을 나눴습니다. 화면 개발에는 적합했지만 운영 API에 연결되는 구조여서, e2e 테스트는 별도 로컬 환경으로 분리해야 한다고 판단했습니다.
인앱 브라우저에서 간편로그인 버튼이 사라지는 문제를 확인했습니다. 에러 로그에 남지 않는 이탈에 대응하기 위해 브라우저를 감지하고, 외부 브라우저 전환과 폴백 경로를 마련했습니다.
LLM 주 계정의 사용량이 88%에 도달한 것을 확인하고 먼저 수동으로 계정을 전환했습니다. 이후에는 사용량 임계값과 계정 우선순위에 따라 보조 계정이 요청을 이어받도록 전환 절차를 자동화했습니다.
공유 서브도메인에서 검색 색인을 확인하기 어려웠던 경험을 바탕으로 커스텀 도메인을 권장하게 됐습니다. 도메인 이전 후 색인이 회복된 사례를 살펴보고, 관찰한 결과와 아직 일반화하기 어려운 조건을 구분합니다.
중복 검색과 실패할 재시도를 줄인 뒤, 글감 15건의 운영 로그로 검색·본문 파싱 비용을 계산했습니다. 실제 비용 약 150원과 생략한 호출을 포함한 비교값 약 309원이 어떻게 산정됐는지 설명합니다.
같은 글감으로 코덱스와 그록의 생성 결과를 비교하고, 품질과 호출 속도를 기준으로 선택을 검토했습니다. 긴 글을 나누어 생성하는 구조에서 그록을 선택한 이유와, 출처 보강과 숫자 검증으로 품질을 보완한 방법을 설명합니다.
LLM을 두 번 호출하던 키워드 발굴 경로를 구글·네이버 검색창 자동완성으로 바꾸었습니다. 응답 시간을 25.1초에서 0.2초로 줄인 구현과 함께, 비공식 엔드포인트를 서비스에 적용하며 검토한 제약을 다룹니다.
커스텀 도메인을 연결할 때 DNS 위임 전파를 기다리지 않아 인증서 발급과 검색엔진 등록이 실패했습니다. 위임 확인을 통과한 뒤 워커가 후속 작업을 수행하고 누락된 등록을 재처리하도록 연결 흐름을 자동화했습니다.
배포 대상 서비스를 지정하지 않아 DB와 리버스 프록시까지 재생성되면서 서비스 중단이 반복됐습니다. 어드민에는 블루그린 배포를 적용하고, Caddy는 배포 경로에서 분리해 각 구성 요소에 맞게 중단 원인을 제거했습니다.
Threads 여러 계정의 실행 환경을 격리하고, VPS의 작업 큐와 Mac mini의 브라우저 조작을 연결했습니다. 댓글 생성과 실행 간격 조정을 포함한 참여 자동화 구조를 설명하되, 동작 검증과 성과 검증은 구분합니다.
Threads 콘텐츠를 네 가지 축으로 구성하고, 큐 기반 발행과 봇 클릭을 구분하는 추적 체계를 설계했습니다. 생성부터 발행·측정까지의 동작을 검증한 과정과, 아직 마케팅 성과를 입증하지 못한 한계를 함께 다룹니다.
Threads 마케팅 에이전트의 병목은 콘텐츠 생성보다 사이트마다 다른 안티봇 차단을 넘어 자료를 수집하는 일이었습니다. TLS 지문과 브라우저 자동화 탐지에 맞춰 수집 계층을 나누고, 결과 형식과 품질 검증 기준을 통일했습니다.
서비스의 요청 처리량을 높이는 접근을 캐싱, 데이터베이스 최적화, 부수 작업 분리로 나누어 설명합니다. 각 전략이 줄일 수 있는 병목은 무엇이며, 적용 전에 어떤 조건을 확인해야 하는지 살펴봅니다.
메시지 전송 요청에 섞여 있던 FCM 푸시를 전용 워커 큐로 분리했습니다. 요청 처리와 외부 호출의 책임을 나누고, 빈 catch에서 사라지던 실패를 Sentry로 관측할 수 있게 바꾸었습니다.
메신저 부하 테스트에서 오류율이 42.8%까지 높아진 원인을 추적하니 읽지 않은 메시지 수를 갱신하는 쿼리에 교착 상태가 있었습니다. 반복 갱신이 필요했던 unreadCount 대신 마지막으로 읽은 시점인 lastReadAt을 사용하는 구조로 전환했습니다.
메신저 API의 처리 한계와 병목을 확인하기 위해 운영 구성을 복제한 7노드 부하 테스트 환경을 만들었습니다. 인프라 생성부터 관측 도구와 인증 데이터 준비까지 반복 실행할 수 있도록 구성했습니다.
Centrifugo의 Pub/Sub 브로커로 KeyDB를 검토했지만, 공개된 멈춤과 교착 상태 이슈에서 운영 위험을 확인했습니다. Valkey와 Sentinel로 전환하고, 10만 연결 부하와 페일오버 테스트로 동작을 검증했습니다.
긴 브라우저 녹음에서 메모리 증가와 크래시 손실, 음성 인식 품질과 수동 처리 흐름이 문제였습니다. 5분 단위 저장과 클라우드 직접 업로드를 도입하고, 전사·회의록 요약·실시간 전달까지 이어지는 파이프라인을 구축했습니다.
