최신 글
WoL은 켜져 있었는데 노트북은 깨어나지 않았습니다 — 원격 전원의 시행착오
전기세를 아끼려고 CI 러너 노트북을 재웠다가 깨우지 못했습니다. RTC 알람도 WoL 매직패킷도 무응답이었고, 설정은 전부 켜져 있었습니다. 결국 밤중에 전원 버튼을 누르러 간 이야기입니다.
사용량을 총량으로만 보면 원인이 안 보입니다. 저장소별 SKU로 분해하자 raw 99.4분짜리 macOS 작업이 994분으로 청구돼 쿼터의 절반을 태우고 있었습니다. 2주간 만든 러너 함대는 그래서 전부 껐습니다.
윈도우 러너가 hosted보다 15배 느렸습니다. 공유기가 100Mbps라는 증거까지 찾아내 네트워크를 범인으로 지목했는데, 캐시가 채워진 상태의 재측정이 콜드보다 느리면서 진단이 통째로 뒤집혔습니다.
맥북 한 대로는 CI 큐가 밀렸습니다. 방치돼 있던 Proxmox 홈랩 서버와 윈도우 노트북을 러너로 붙이면서, 네이티브 폴백이 없는 GitHub Actions에서 라벨만으로 폴백을 만든 과정을 정리합니다.
GitHub Actions hosted 러너가 새벽에 전면 차단됐습니다. 변수 한 줄과 self-hosted 러너로 30분 만에 우회했지만, 에러 메시지를 원인으로 착각한 탓에 진짜 이유는 2주 뒤에야 알게 됐습니다.
1인 개발자에게 CI는 사치일까요. 어느 날 CI가 통째로 멈추고 나서야, 그것이 테스트를 대신 돌려주는 편의 기능이 아니라 머지 자체를 막는 임계 경로였다는 것을 알게 됐습니다.
글을 통째로 벡터 하나에 담던 설계를 조각내 다시 세웠습니다. 헤딩 경계 청킹과 taskType 비대칭으로 잘림을 풀었고, 그 재임베딩 배치가 정확히 50번째 글마다 죽던 MongoDB 커서 타임아웃까지 잡은 기록입니다.
코드는 1만 자에서 잘랐지만, gemini-embedding-001은 그보다 앞선 2,048 토큰에서 조용히 나머지를 버리고 있었습니다. 같은 글의 prefix를 길이별로 임베딩해 비교하니 6,000자부터 벡터가 비트 단위로 동일했고, 글 셋 중 하나가 뒷부분을 검색에서 잃고 있었습니다.
반년 전 붙여둔 하이브리드 검색이 정말 정확한지 추측 대신 검색어 16개로 직접 측정했습니다. Precision@1은 88%로 나쁘지 않았지만, 재는 과정에서 정작 고쳐야 할 것은 정확도가 아니라 파이프라인의 숨은 결함 네 개라는 걸 알게 됐습니다.
Search Console에 sitemap을 API로 재제출하려다 403을 만났습니다. 서비스 계정을 소유자로 올려도 여전히 403이었습니다. 인가가 두 겹—리소스 권한과 OAuth 스코프—이었기 때문입니다. 스코프는 발급 시점에 굳으며, 서비스 계정 키로 직접 뚫는 법을 정리했습니다.