최신 글
EC2를 띄우기 전에 AWS CLI로 먼저 잰 것들 — 계획서가 틀려 있던 8가지
Coolify를 EC2에 올리기 전, 읽기 전용 describe만으로 계정을 먼저 쟀습니다. 계획서의 1순위 단계는 불필요했고, 정작 필수였던 것들은 계획서에 아예 없었습니다. 비용 0인 준비만 먼저 끝낸 과정을 정리했습니다.
배포가 겹치지 않게 락을 걸었더니 겹침은 정말 사라졌습니다. 다만 사라진 것은 겹침이지 낭비가 아니었습니다. 뒤에 온 세션은 앞 체인이 끝나기를 기다렸다가 같은 코드를 다시 빌드하고 있었습니다.
Node 20이 지원 종료를 맞아 24로 올리며 확인한 것들. V8의 JIT 계층 구조와 Maglev가 채우는 빈칸, 그리고 합성 벤치마크 35%가 실제 테스트 스위트에서 2%가 되는 이유. 메모리는 오히려 15% 늘고, N-API 덕에 네이티브 모듈 재빌드는 필요 없었습니다.
경로를 감싸는 함수가 콜론을 이스케이프하고 있었습니다. 그래서 윈도우 경로를 막아준다고 주석에 적혀 있었는데, 재보니 콜론만 여전히 실패했습니다. 이스케이프하는 것과 지켜주는 것은 다른 말이었습니다.
경로를 잘못 단정하던 테스트를 고쳤는데, 리뷰가 제 수정의 근거를 무너뜨렸습니다. 검색 결과의 첫 히트를 근거로 삼았고, 그것은 제가 찾던 것과 이름만 같은 다른 값이었습니다.
윈도우 러너에 무거운 작업을 맡길 수 없다고 믿었는데, 막고 있던 것은 성능이 아니라 코드베이스가 리눅스를 전제하고 쓴 문법이었습니다. 그리고 그날 내린 보류 결정은 지적 한 줄에 그날 무너졌습니다.
윈도우 러너가 느린 범인을 파일시스템으로 지목했는데, 그것도 절반만 맞았습니다. 파일 16만 개짜리 폴더를 93만 개 경로로 걷게 만든 것은 패키지 매니저의 링크 구조였고, 설정 한 줄로 260초가 14초가 됐습니다.
의존성 캐시를 끄자 작업당 4분이 사라졌습니다. 캐시는 매번 새로 만들어지는 기계를 전제로 설계된 장치인데, 제 러너는 사라지지 않는 기계였습니다. 전제가 다르면 최적화는 순손실이 됩니다.
전기세를 아끼려고 CI 러너 노트북을 재웠다가 깨우지 못했습니다. RTC 알람도 WoL 매직패킷도 무응답이었고, 설정은 전부 켜져 있었습니다. 결국 밤중에 전원 버튼을 누르러 간 이야기입니다.
사용량을 총량으로만 보면 원인이 안 보입니다. 저장소별 SKU로 분해하자 raw 99.4분짜리 macOS 작업이 994분으로 청구돼 쿼터의 절반을 태우고 있었습니다. 2주간 만든 러너 함대는 그래서 전부 껐습니다.