-
신규 서비스의 디스코드 채널 연동을 표준 패턴으로 추가
vtuber 프로필 서비스를 위한 디스코드 채널 연동 설정을 추가했다. 핵심은 기존에 kpopdex에서 정립된 설정 패턴을 그대로 따라가기로 결정한 것. 단순히 JSON 한 줄 추가가 아니라, 이미 검증된 구조를 신규 서비스에 적용함으로써 설정 일관성을 유지하고 향후 확장성을 확보하는 작업이었다.
읽기 → -
신규 도메인 모니터링 대시보드 추가로 운영 시야 확보
한 이커머스 및 크리에이터 서비스 플랫폼으로 확장하면서, 각 서비스별 통계 대시보드를 개별 관리해야 하는 상황이 생겼다. 이번 작업은 기존 stats-dashboard 스크립트에 신규 서비스를 추가하는 작업인데, 단순 도메인 등록을 넘어 모니터링 시스템의 확장성을 어떻게 설계할지에 대한 고민이 담겨 있다.
읽기 → -
새 도메인 등록, 정책 문서도 함께 갱신
vtuberprofile.com 을 hedvion 인벤토리에 등록하는 작업을 했다. 단순히 도메인 이름을 어딘가에 적어둔 게 아니라, hedvion-CLAUDE.md 와 sites-detail.md 를 함께 갱신했는데, 이게 생각보다 중요한 부분이라 정리해 본다.
읽기 → -
금액 표시 규칙을 파이프라인으로 자동화
생성 단계부터 발행 직전까지 금액 데이터를 정제하는 두 단계 파이프라인을 연결했다. 예전엔 생성 후 발행 직전에 데이터를 일일이 정제해야 했는데, 이제 규칙을 파이프라인에 넣어두니 수동 작업이 줄어들었다.
읽기 → -
합쇼체만 반복되던 한국어 톤 다양화 개선
한국어 자연어 처리에서 텍스트를 생성할 때 한 가지 단조로운 문체만 계속 나오는 문제가 있었다. 특히 humanizer 모듈의 기본 한국어 톤 처리 레벨에서 모든 문장이 존경스러운 합쇼체로만 일관되게 생성되곤 했다. 이번 작업은 그 지점을 개선해서 상황에 맞는 다양한 톤이 섞여 나올 수 있도록 보강한 것이다.
읽기 → -
가짜 데이터 걷어내고 프로덕션 준비 완료
프로젝트 전체를 VTuber Profile로 리브랜딩하고 가짜 데이터를 정제하는 작업을 마쳤다. 단순히 서비스명을 바꾸고 테스트 데이터를 제거한 것처럼 보일 수 있지만, 실제로는 프로젝트를 개발 단계에서 프로덕션 레벨로 격상시키는 중요한 리팩토링이었다.
읽기 → -
데이터 검증 게이트와 출처 명시로 신뢰도 높이기
데이터 품질 문제가 계속 튀어나오던 상황이 있었다. 어떤 정보는 자동 크롤링으로 수집했고, 어떤 건 수동 입력이었고, 일부는 머신러닝 생성 결과였는데—시간이 지나면서 신뢰도가 뒤섞여 버렸다. 사용자 입장에서도 "이 데이터가 정확한가"를 판단할 근거가 없었고, 우리 팀도 어느 항목이 검증된 상태인지 추적하기 어려워졌다. 이번엔 그 문제를 체계적으로 정리하는
읽기 → -
다언어 라우팅으로 SEO와 광고 수익 동시 최적화
8개 언어 지원, [lang] 라우트, hreflang, AdSense 연동까지 한 번에 처리한 i18n 대작업을 마무리했다. 단순히 번역 텍스트 몇 개 추가하는 수준이 아니라, 검색 엔진 최적화부터 광고 수익까지 고려한 풀스택 국제화 구현이었다.
읽기 → -
상 목록 조회가 화면에 안 띄우던 alias 예약어 버그
지난주에 상 조회 기능 데이터가 DB에서는 정상 반환되는데 화면에 나타나지 않는 버그를 잡았다. 원인은 SQL 쿼리의 alias가 DB의 예약어였기 때문. 백틱으로 처리해서 해결했는데, 이런 류 버그가 왜 자꾸 튀어나오는지, 어떻게 더 일찍 catch할 수 있을지 생각해보게 됐다.
읽기 → -
정산 최종 보고서를 저장소에 기록한 이유
결제 플랫폼과의 정산 완료 보고서를 깃 저장소에 PDF로 보관하기 시작했다. 한 줄 커밋이지만, 이 뒤에는 우리 팀이 결제 도메인에서 배운 작은 실수들이 담겨 있다.
읽기 → -
그룹 페이지에 수상 내역 추가로 프로필 완성도 올려
kpop 그룹의 프로필 페이지에 수상 정보를 추가했다. 적재 봇, UI 컴포넌트, 다국어 번역까지 한 번에 정리한 작업이었는데, 각 레이어에서 뭘 챙겨야 하는지 좋은 학습이 됐다.
읽기 → -
정산 도메인 규칙 분산을 단일진실로 통합 관리
도메인별 지침이 여러 곳에 흩어져 있는 문제를 정리했다. 특히 결제·정산(payment/settlement) 같은 금융 도메인은 변경이 잦고 실수 여지가 크기 때문에, 진실의 출처(single source of truth)를 명확히 하는 게 핵심이다.
읽기 → -
fork 엔진으로 신규 사이트 기동 가속화
새로운 장르 플랫폼을 기존 kpopdex 엔진에서 fork해서 구축하기로 결정했다. 비슷한 구조의 사이트를 빠르게 만들어야 하는 상황에서 fork는 꽤 합리적인 선택이었다.
읽기 → -
기사 데이터 생성 시 날짜 임의 단정 제거
우리 팀에서 관리하는 기사 시드 데이터 생성 스크립트(bot/seed_articles.py)에 날짜 관련 fix를 적용했다. 그간 테스트·개발 편의상 과거나 미래 연도를 구체적으로 박아놓던 관행을 버리고, 연도 기준 중립표현으로 통일하기로 한 것이다. 겉보기엔 사소한 수정이지만, 이걸 통해 팀의 데이터 정책을 어떻게 강제할지, 그리고 왜 시드 스크립트 같은
읽기 → -
플레이스홀더 날짜로 인한 오류 방지
seed_articles.py 에서 아티클 샘플 데이터를 생성할 때 플레이스홀더 날짜 처리 방식을 개선했다. 지금까지는 게시 날짜를 알 수 없을 때 1월 1일(01-01)로 고정하고 있었는데, 이렇게 하면 나중에 그 데이터가 실제로 1월 1일 게시된 건지, 아니면 단순 플레이스홀더인지 구분이 안 되는 문제가 생긴다. 커밋 메시지에서 "정확일자 단정 방지"라
읽기 → -
데이터 소유권 모델 정의로 팀 간 혼선 해결
동료 팀과 공유하는 데이터에 대해 명확한 소유 모델을 정의하고, 이를 문서에 기록했다. .md=진실 / DB=단방향미러 라는 단순하지만 명시적인 규칙을 세우면서, 동시에 특정 마이그레이션(/p/{id})을 하지 않기로 결정한 그 배경도 함께 남겼다.
읽기 → -
자체 칼럼 시스템으로 콘텐츠 운영 자동화
자체 칼럼(articles) 플랫폼을 구축하고, 디스코그래피 콘텐츠를 자동으로 생성하는 봇을 만들었다. 기존에는 콘텐츠 업데이트가 주로 수동 작업이거나 외부 소스에 의존했는데, 팀 규모가 커지면서 이런 반복적인 운영 비용이 계속 늘어나고 있었다.
읽기 → -
글 저장소 이중 기록 방식 기록 완성
동료가 작성한 데이터 레이어 설명 문서를 검토하다가 놓친 부분을 발견했다. 글이 단순히 하나의 데이터 저장소에만 쌓이는 줄 알았던 기록이 있었는데, 실제로는 두 곳에 중복으로 기록되는 하이브리드 방식이었다. cms_post DB에 별도로 id를 부여하고 적재되는 구조였는데, 그 부분의 설명이 누락되어 있었다. 91건 규모의 데이터가 이 방식으로 처리되고 있
읽기 → -
사이트맵 통합으로 검색 엔진 크롤링 효율 높이기
검색 엔진 최적화(SEO) 관점에서 크롤러가 우리 사이트를 얼마나 효율적으로 발견하는지는 매우 중요하다. 최근에 sitemap.xml을 중앙집중식 인덱스로 통합하고, robots.txt에 명시적으로 선언하는 작업을 했다. 단순해 보이지만 이 변경이 왜 필요했고, 어떤 영향을 미치는지 풀어본다.
읽기 → -
인프라 설정 문서를 동료와 정합했다
개인 저장소에서 팀 저장소로 전환하면서 마주하는 문제 중 하나가 **문서와 현실의 괴리**다. 특히 여러 사이트가 각기 다른 설정을 갖고 있을 때, 누가 언제 어떤 설정을 적용했는지, 그 설정이 왜 필요한지가 명확하지 않으면 나중에 유지보수하는 사람은 그야말로 지뢰밭을 걷게 된다. 이번엔 한 사이트의 인프라 설정 정보를 동료와 맞추고, 그 과정을 사이트 상
읽기 →