일기
회고 / 메모
-
끝이 없을 것 같던 하루, 그래도 다 밀었다
오늘은 정말 많이 했다. 다 나열하면 일기가 아니라 커밋 로그가 되니까 느낀 것 위주로.
읽기 → -
새 사이트 파비콘이 안 바뀌던 문제 풀기
온보딩 가이드에 파비콘 고유화 관련 체크리스트를 추가했다. 사실 이건 간단해 보이지만, 매번 신입이나 새로운 팀원이 사이트를 구성할 때마다 같은 문제가 반복되던 지점이었다.
읽기 → -
접근성 검증을 프로세스 기본값으로 만들기
사실 이건 피할 수 있었던 사고였다. 한 서비스에서 검정색 배경 위에 검정색 텍스트가 놓이면서 아무것도 안 보이는 상황이 발생했다. 화면을 켜도 아무것도 읽을 수 없다. 시각장애인뿐 아니라 일반 사용자도 (밝기 문제, 화면 글레어 상황 등) 피해를 본다. 이렇게 되면 단순 디자인 리뷰나 QA 테스트 리스트로는 막을 수 없는 문제가 되어버린다.
읽기 → -
아이콘 라이브러리 통일, 문서에 명시하다
CLAUDE.md에 아이콘 정책을 명시하는 커밋을 했다. 팀이 쓸 프로젝트 지침서에 아이콘 라이브러리 룰을 추가한 것인데, 한두 줄 추가지만 팀 효율성과 일관성 측면에서 꽤 의미 있는 작업이었다.
읽기 → -
운영 가이드에 함정 3개를 추가하다
어느 정도 규모 있는 시스템을 운영하다 보면, 팀원들이 반복해서 같은 곳에서 헤매는 지점들이 생긴다. 사소해 보이지만 진단 과정을 몇 배로 길게 만드는 함정들 말이다. 이번엔 그런 함정 3개를 공식 운영 문서(hedvion-CLAUDE.md)에 정리했다. 각 항목이 왜 함정이 되는지, 어떻게 구분하고 진단하는지를 중심으로 남겼다.
읽기 → -
온보딩 문서의 법무 정책 갭, 실제로는 커뮤니케이션 부족이었다
처음엔 간단해 보였다. 새 사이트를 론칭할 때마다 온보딩 문서를 쓰고, 개발팀·운영팀·법무팀이 다 읽으면 끝. 그럼 다음 팀원이나 신입도 같은 순서로 따라가면 된다고 생각했다. 실제로는 그렇지 않았다.
읽기 → -
라이브 스트림 폴링 전략을 바꾸며 API 비용을 절감하다
vtuber 라이브 스트림 데이터를 추적하는 작업에서 매달 API 비용이 계속 증가하고 있었다. 150명의 vtuber 명단을 실시간으로 모니터링해야 했는데, 기존 폴링 방식을 재검토할 필요가 있었다. Holodex 라는 vtuber 정보 서비스의 API를 사용하고 있었는데, quota 사용량이 8,500에서 3,500으로 줄어들 수 있는 지점을 찾았고,
읽기 → -
무료 API로 VTuber 라이브 상태 자동화
라이브 스트리밍 콘텐츠 추적 시스템에서 **라이브 상태 정보**는 핵심이다. 누가 지금 방송 중인지, 언제 시작했는지를 정확히 알아야 사용자에게 적절한 타이밍에 콘텐츠를 전달할 수 있다. 이번 작업에서는 Holodex API를 통해 시간 단위로 라이브 상태를 갱신하는 방식을 문서화했다. 비용 0으로.
읽기 → -
아이콘 라이선스 기준 명확화
프로젝트 공식 지침에 아이콘 사용 정책을 추가했다. 상업용 무료 오픈소스 SVG만 사용하고, AI 생성 아이콘은 금지한다는 내용이다. 개발 가이드 문서 한 항목이 추가된 것이지만, 뒤에는 여러 고민과 판단이 들어가 있다.
읽기 → -
팀 전체 아이콘 라이선스 이슈 정책화
팀 규모가 커지면서 각 사이트나 서비스마다 디자인 요소를 선택하는 방식이 제각각이 되곤 한다. 그중 가장 간단해 보이지만 실제로는 복잡한 부분이 **아이콘 선택**이었다. 누군가는 유료 라이센스 아이콘을 썼고, 누군가는 AI로 생성한 아이콘을 사용했고, 누군가는 적절한 라이선스를 확인하지 않은 채 인터넷에서 무작정 가져다 썼다. 개별 팀원들이 "이 정도면
읽기 → -
문서 지침이 구식 배포법을 남기고 있었다
docs/hedvion-CLAUDE.md 에서 서버 배포 프로세스 관련 항목을 손봤다. 기존 기록에선 scp/no-git 이라고 명시되어 있었는데, 실제로는 이미 3단계 git 동기화 방식으로 운영되고 있었다. 문서가 현실을 따라가지 못한 전형적인 케이스다.
읽기 → -
검색 노출 0은 누락이 아닌 색인 진행 중
문서 한 줄이 팀의 불안감을 어떻게 없앨 수 있는지 배웠던 순간.
읽기 → -
신규 사이트 온보딩 복잡도를 문서로 풀다
신규 사이트 온보딩 문서를 보강했다. 포크 구조의 다국어 라우팅 설정([lang] 라우트)과 external apex CMS 수동등록 절차를 명시적으로 기록했다. 작은 변경이지만 팀 규모가 커질수록 이런 "프로세스 문서화"의 중요도는 급격히 올라간다.
읽기 → -
전사 반응형 웹 표준으로 팀의 흩어진 디자인 정책 모으기
예전엔 반응형 디자인의 기준이 팀 내에서 명확하지 않았다. 누구는 768px를 기준으로, 누구는 600px로, 누구는 자신의 노트북 해상도 기준으로 대충 맞춰놨다. UI 컴포넌트는 같은 패키지인데 화면 폭에 따라 다르게 동작하고, QA도 "모든 폭에서 테스트하는 게 맞나?"라고 물어봤다. 스타일시트와 미디어 쿼리는 조각난 상태였고, 신입이 들어올 때마다 "
읽기 → -
loose 사본으로 배포 실패하던 함정 문서화
ops 라이브러리를 서버에 배포할 때 자주 겪는 일이 있다. git pull 로 최신 코드를 받아도 실제 스크립트는 예전 버전이 그대로 남아있는 상황이다. 결국 "어? 방금 고친 스크립트가 왜 작동 안 하는데?" 하면서 한참 헤매다가 수동으로 파일을 복사해야 하는 경험 말이다. 이번에는 이 함정을 배포 자동화 계획에 명시해서, 팀원들이 같은 실수를 반복하지
읽기 → -
새로운 서비스 SEO 관리에 편입하고 기존 오류 정정
SEO 인프라 문서를 업데이트했다. blindboxdex라는 새로운 서비스를 SEO 관리 대상에 편입하면서, 동시에 vtuberprofile에서 siteFullUser 기능이 라이브되면서 생긴 정책 변경을 반영한 것이다.
읽기 → -
검증 중이었던 GSC 상태를 완료로 정정
며칠 전 CLAUDE.md를 훑다가 발견했다. Google Search Console 소유검증이 실제론 "완료"였는데도 문서엔 여전히 "검증 중"이라고 적혀 있었다. 사이트맵 제출도 마찬가지. 실제 상태와 문서 사이에 시간차가 생겼고, 이건 누군가를 혼동하게 할 수 있는 상황이었다.
읽기 → -
신규 사이트 온보딩 절차 한곳에서 관리하기
신규 사이트를 로칭할 때마다 여러 문서를 뒤적거려야 했다. 인증 정책은 어디? 콘텐츠 제약은? SEO 체크는? 배포 절차는? 담당자마다 다르게 이해하고, 누군가는 중요한 단계를 빼먹고, 나중에 "어라, 이걸 왜 안 했지?" 하는 일이 반복됐다. 이번에 신규 사이트 온보딩 체크리스트를 단일 문서(SSOT)로 정리해서 모든 관점을 한곳에서 관리하도록 만들었다.
읽기 → -
분산된 SEO 속성을 문서 하나로 통합 관리하다
여러 도메인을 운영하다 보니 각 도메인의 SEO 관리 정책과 현황을 한 문서에 정리할 필요가 있었다. 이번에 docs/seo-infra.md 를 최종 완성하면서 LEARN_SLUGS 정의를 확정하고, 별도 운영 중이던 4개 도메인을 편입하고, 현재 연결된 검색 콘솔 5개 속성까지 한데 정리했다.
읽기 → -
검색 인프라 권한 관리 혼선 제거와 문서 정정
인프라 문서를 정비하다가 발견한 흥미로운 케이스다. GSC 접근 권한이 여러 ADC로 산재되어 있었는데, 실제로는 단일 계정이 전 도메인을 관리할 수 있는 상황이었다. 개발 환경용 ADC가 불필요했다는 걸 깨닫고 문서를 정정했다.
읽기 →