개발
코드 / 아키텍처 / 디버깅
-
새 서비스 도메인의 트래픽 감시 선택적 추가
traffic-watcher 스크립트에 blindboxdex 도메인을 편입했다. 다만 "dex, 룰학습만"이라는 제약을 두어 전체 기능이 아닌 특정 모듈만 감시하도록 했고, 그 결과 SEO 추적 속성이 5개에서 6개로 늘었다.
읽기 → -
신규 사이트 온보딩 진행도 한눈에 확인
신규 사이트가 발견되면 그걸 시스템에 제대로 온보딩하는 건 단순한 기술 작업이 아니다. 운영팀과 개발팀 사이에 "지금 어디까지 했는데?"라는 질문이 자주 오가는데, 체크리스트 카드를 추가하면서 그 답변 주기를 좀 더 명확하게 만들 수 있게 됐다.
읽기 → -
Discord 채널 분리로 팀 소통 혼선 해결
요즘 사내 도구 설정 변경 중에 가장 간단해 보이는 작업들이 의외로 팀 전체에 영향을 크게 미친다는 걸 다시 한번 느낀다. 이번 작업도 그런 케이스였다. 회사 전체 공지사항이 섞여 있던 Discord에서 기획-seo학습 채널을 별도로 분리하고, 우리 시스템의 설정 파일(discord_channels.json)에 해당 채널 ID(1518466281718808
읽기 → -
다중 도메인 SEO 모니터링, 메타 분기로 깔끔하게
여러 이커머스/콘텐츠 플랫폼을 운영하면서 Google Search Console(이하 GSC) 통합 관리의 필요성이 계속 커지고 있었다. 기존에는 도메인마다 따로 모니터링하던 traffic-watcher를 확장해서, 한 대시보드에서 여러 도메인의 검색 트래픽을 관리할 수 있게 개선했다.
읽기 → -
SEO 포스트 Discord 채널 자동 라우팅
Discord 봇의 포스팅 시스템에 콘텐츠 종류별 채널 라우팅 로직을 추가했다. SEO 관련 포스트가 자동으로 올바른 채널로 전달되도록 정리한 작업인데, 이건 단순 피쳐 추가가 아니라 팀의 정보 흐름과 자동화 신뢰도를 한 단계 올린 사건이라고 봤다.
읽기 → -
리포트 채널 분리로 알림 노이즈 개선한 경험
traffic-watcher 스크립트가 뱉어내는 SEO 리포트를 종합 채널에서 전용 SEO 채널로 라우팅하는 작업을 했다. 한 줄 짜리 commit처럼 보이지만, 뒤에는 팀 커뮤니케이션 구조를 다시 생각하는 과정이 있었다.
읽기 → -
트래픽 학습 시스템의 전사 커버리지 확보
초기 설계가 일부 콘텐츠 사이트만 커버하도록 했던 traffic-watcher를 이제 전사의 모든 콘텐츠 사이트로 확장했고, 그 과정에서 빠진 서비스 하나를 발견해 추가했다.
읽기 → -
반복 생성 패턴을 구조적으로 분류하기
지난주 brainstorm 시스템에서 흥미로운 문제를 마주쳤다. 사용자들이 아이디어를 생성할 때 같은 패턴의 제안이 자꾸 반복되는데, 그걸 처리하는 방식이 아쉬웠다. 단순히 코드 로직으로 "이건 반복이다/다르다"를 판단하고 있었는데, 실제론 시스템이 **과거에 내린 의사결정의 맥락을 기억하지 못하고 있었던** 게 근본 문제였다.
읽기 → -
리뷰 조회 반환값 정규화로 금액 타입 버그 수정
learn-update 스크립트의 fetch_reviews 함수 반환값을 list로 정규화했다. 겉으로는 간단한 타입 통일처럼 보이지만, 실제론 파이프라인 전체의 데이터 안정성을 확보하는 중요한 작업이었다.
읽기 → -
폭주하는 피드백으로 마비된 학습 시스템 복구
작업: learn-update 스크립트의 세 가지 버그를 한 번에 수정했다. 피드백 제한(cap), 백로그 드레인, 실행 권한 복원.
읽기 → -
새로운 콜라보 시리즈 12종을 데이터베이스에 한 번에 추가
블라인드박스 플랫폼에서 새로운 콜라보레이션 시리즈(CRYBABY, Labubu 등)를 12개 아이템으로 확장하는 데이터를 SQL 시딩으로 배포했다. 꽤 간단한 작업으로 보이지만, 이 과정에서 데이터 확장 시의 의사결정과 팀 협업 관점에서 배운 게 많다.
읽기 → -
검증된 블라인드박스 시리즈 17개 추가
데이터베이스 시드 스크립트에 17개의 새로운 시리즈를 추가했다. 단순한 행(row) 추가처럼 보이지만, 이 작업이 보여주는 건 데이터 관리 패턴과 팀의 신뢰성 문제다.
읽기 → -
묶음 상품 시리즈 초기 데이터를 버전 관리하기 시작하다
요즘 들어 자주 마주치는 패턴이 있는데, 개발 초기 단계에서 **데이터베이스 seed 파일**이 git 추적 대상이 아니다가 나중에 "어? 이 데이터는 어디서 나온 거지?" 하는 상황이다. 이번 커밋은 묶음 상품 확장 기능(expansion)과 관련된 초기화 데이터를 드디어 버전 관리에 넣은 작업인데, 생각보다 이런 결정이 팀 전체에 미치는 영향이 꽤 크다
읽기 → -
팝마트 12개 시리즈 카탈로그 데이터 확정
블라인드박스 데이터베이스에 12개의 검증된 팝마트 시리즈를 추가했다. SKULLPANDA, MOLLY, DIMOO, HIRONO, HACIPUPU, Labubu 등 주요 콜렉션들을 db/seed-blindbox.sql에 확정 커밋한 일이다.
읽기 → -
사이트별 로그 추적 기능 추가
최근에 페이지뷰 로깅 시스템(site-pv)에 새로운 서비스를 등록하고, 등록된 서비스 목록을 한눈에 볼 수 있는 기능을 추가했다. 단순한 데이터 등록처럼 보이지만, 실제로는 멀티사이트 환경에서 로그 추적의 운영 방식을 크게 개선한 작업이다.
읽기 → -
도메인별 통계 격리로 대시보드 관리 자동화
새로운 도메인을 서비스에 추가할 때, 코드 변경은 한두 줄이지만 시스템 전체에 미치는 파급력은 생각보다 크다. blindboxdex.com을 대시보드에 등록하면서 단순히 데이터 소스를 추가하는 것에서 한 발 나아가, 로그 격리(DEDICATED_LOGS)와 표시 순서(DISPLAY_ORDER) 설정까지 함께 점검해야 한다는 점을 다시 한번 체감했다.
읽기 → -
프로젝트 맞춤 지침으로 상속 문서의 혼선 정리
이번엔 blindboxdex 프로젝트의 CLAUDE.md를 새로 작성했다. 그 전까지는 다른 프로젝트(vtuber 관련)의 지침 문서를 그대로 상속받고 있었는데, 프로젝트마다 도메인과 제약이 다르다 보니 팀원들이 "이 규칙이 우리 프로젝트에도 적용되는 거야?"라고 매번 판단해야 하는 불편함이 생겼다. 이번 작업으로 그 혼선을 명확하게 정리했다.
읽기 → -
여러 페이지에 새 테마 일괄 적용, 디자인 시스템 통합 완성
이번 작업은 CAPSULE과 VITRINE이라는 두 가지 디자인 테마를 전체 페이지에 일관성 있게 적용하고, 각 페이지의 레이아웃을 통일하는 "reskin" 프로젝트를 마무리한 것이다. FigureCard에서 시작한 디자인 변경이 BrandDetail, Drops, FigureDetail, Releases, SeriesDetail 등 6개 컴포넌트에 걸쳐
읽기 → -
블라인드박스 서비스 디자인 정체성을 한번에 잡다
몇 달 전부터 자꾸만 느껴진 게 있었다. 우리 블라인드박스 서비스가 화면마다 조금씩 다르다는 것. 상품 카드는 한 스타일, 카테고리 페이지는 다른 스타일, 드롭 페이지는 또 다른 톤... 사용자 입장에서는 같은 서비스를 쓰는 거지만, 우리 입장에선 매번 "이건 어떤 폰트지?", "이 카드는 왜 이렇게 생겼지?" 하면서 일관성 없이 개발하고 있었다.
읽기 → -
검색 엔진 페이지 등록 무한 대기 버그 수정
신규 프로필이나 콘텐츠가 생성될 때 외부 검색 엔진에 즉시 알려서 빠르게 인덱싱되도록 하는 bot/indexnow-ping.js 파일을 수정했다. 핵심은 외부 API 호출 시 응답이 없어서 무한 대기하던 문제를 12초 타임아웃으로 해결한 것.
읽기 →