대용량 로그 검색 — 620MB 로그에서 원하는 줄만 빠르게 뽑아내기 (파이썬 실측)

대용량 로그 검색 — 620MB 로그에서 원하는 줄만 빠르게 뽑아내기 (파이썬 실측)

로그 파일이 수백 MB로 불어나면 에디터로 열어 Ctrl+F를 누르는 것부터 부담이 됩니다. 그래서 대용량 로그 검색을 파이썬 표준 라이브러리만으로 해결해 보려고, 이 노트북(윈도우 11, 파이썬 3.12)에서 620MB·900만 줄짜리 테스트 로그를 만들어 여섯 가지 방법을 비교했습니다. 흔히 쓰는 “한 줄씩 읽으며 in으로 찾기”는 평균 2.5~3.8초, 큰 덩어리로 읽고 bytes.find로 위치만 찾는 방법은 0.76초였습니다. 특정 시간대만 뽑을 … 더 읽기

폴더 용량 확인 스크립트 — 디스크를 잡아먹는 폴더 찾아내기 (파이썬 실측)

폴더 용량 확인 스크립트 — 디스크를 잡아먹는 폴더 찾아내기 (파이썬 실측)

C 드라이브가 빨간 막대로 바뀌면 탐색기에서 폴더를 하나씩 우클릭해 속성을 열어보게 됩니다. 폴더가 몇 개만 넘어가도 금방 지칩니다. 그래서 폴더 용량 확인 스크립트를 파이썬으로 만들어 이 노트북(윈도우 11, 파이썬 3.12)의 C:\Program Files에 돌려봤습니다. 흔히 보이는 os.walk 방식은 평균 6.09초, os.scandir로 바꾼 버전은 2.19초가 걸렸습니다. 더 중요한 건 속도가 아니었습니다. os.walk 버전은 50MB짜리 폴더를 100MB로 두 … 더 읽기

스크립트 중복 실행 방지 — 두 번 돌아 같은 일을 또 할 때 막는 법 (파이썬 실측)

스크립트 중복 실행 방지 — 두 번 돌아 같은 일을 또 할 때 막는 법 (파이썬 실측)

스케줄러가 한 번, 사람이 급해서 손으로 한 번. 같은 스크립트가 두 번 돌면 메일이 두 통 나가고, 글이 두 편 올라가고, 결제가 두 번 됩니다. 스크립트 중복 실행 방지는 보통 “잠금 파일 하나 만들면 되지” 하고 넘어가는데, 실제로 그 흔한 방식을 같은 순간에 5개씩 띄워 20번 돌려보니 20번 중 12번은 두 개 이상이 동시에 통과했습니다. … 더 읽기

자동화 헬스체크 스크립트 — 돌아가는 자동화들을 한 번에 점검하기

자동화 헬스체크 스크립트 — 돌아가는 자동화들을 한 번에 점검하기

자동화가 하나둘 늘어나면 “잘 돌고 있겠지”라는 믿음도 같이 늘어납니다. 이 블로그는 매일 정해진 시각에 발행 작업이 돌고, 실행할 때마다 logs/ 폴더에 날짜별 로그를 남깁니다. 이번에 이 로그들을 한 번에 훑는 자동화 헬스체크 스크립트를 만들어 직접 돌려보니, 로그 48개 중 9개가 정상 종료가 아니었습니다. 7개는 종료 코드 1로 끝났고, 2개는 종료 표시 자체가 없었습니다. 실패 알림이 … 더 읽기

RSS로 내 글이 실제로 올라갔는지 자동 확인하기 — 파이썬 표준 라이브러리만으로

RSS로 내 글이 실제로 올라갔는지 자동 확인하기 — 파이썬 표준 라이브러리만으로

예약 발행을 걸어두면 “내일 아침에 알아서 올라가겠지” 하고 잊게 됩니다. 이 블로그도 매일 오전 9시 예약 발행으로 운영하는데, 이번에 RSS 피드로 최근 7일치 발행을 자동 확인하는 스크립트를 만들어 직접 돌려보니 7일 중 이틀이 비어 있었습니다. 하루는 자동화를 데스크탑에서 노트북으로 옮기는 동안 예약 큐가 비어 생긴 공백이었습니다. 관리 화면을 매일 열어보지 않는 한 이런 공백은 잘 … 더 읽기

예약 발행이 엉뚱한 시각에 나갈 때 — 타임존 점검 순서 5단계

예약 발행이 엉뚱한 시각에 나갈 때 — 타임존 점검 순서 5단계

블로그 글을 “내일 오전 9시”로 예약했는데 실제로는 오후 6시에 올라가 있거나, 반대로 새벽에 먼저 공개돼 버리는 경우가 있습니다. 차이가 정확히 9시간이라면 거의 100% 시간대(타임존) 문제입니다. 한국 표준시는 UTC보다 9시간 빠르기 때문에, 어딘가 한 곳이 UTC로 계산하고 다른 곳이 한국 시각으로 계산하면 그 차이가 그대로 발행 시각에 찍힙니다. 이번 글에서는 예약 발행 시간이 안 맞을 때 … 더 읽기

문서 중복도 측정으로 AI가 쓴 글이 서로 얼마나 겹치는지 재보기 (n-gram 유사도)

AI에게 블로그 글을 맡기다 보면 어느 순간 이상한 기시감이 듭니다. 주제는 분명히 다른데 도입부 흐름이 똑같고, 예제 코드의 변수명까지 비슷합니다. 이 블로그도 글이 57편을 넘어가면서 같은 고민이 생겼습니다. 문제는 사람 눈으로는 이걸 확인할 수가 없다는 겁니다. 57편이면 서로 비교해야 할 조합이 1,596쌍입니다. 한 쌍을 1분씩만 봐도 26시간이 넘습니다. 그래서 이번 글에서는 문서 중복도 측정을 직접 … 더 읽기

스크립트 로그 관리 — 실행 로그를 날짜별로 남기고 오래된 건 자동 삭제하기

자동화 스크립트를 작업 스케줄러에 걸어두고 며칠이 지난 뒤, 결과물이 안 만들어져 있는 걸 발견합니다. 그런데 스케줄러 기록에는 “성공(0x0)”만 찍혀 있습니다. 스케줄러는 프로세스가 실행됐는지만 보고, 스크립트가 중간에 무엇 때문에 멈췄는지는 알지 못합니다. 남아 있는 단서가 없으면 결국 같은 상황을 손으로 재현해봐야 하는데, 그게 매번 30분씩 걸립니다. 반대로 로그 한 줄만 있으면 1분입니다. 이번 글에서는 스크립트 로그 … 더 읽기

PC를 정해진 시각에 깨우고 재우는 자동화

오전 9시에 돌도록 걸어둔 작업 스케줄러 작업이 며칠째 조용합니다. 로그 폴더는 비어 있고, 에러도 없고, 작업 이력에는 아무것도 남지 않았습니다. 원인은 허무할 만큼 단순합니다 — 그 시각에 PC가 켜져 있지 않았습니다. 이럴 때 필요한 게 컴퓨터 자동 켜기와 절전 예약입니다. 매일 아침 손으로 PC를 켜고 스크립트를 실행하는 데 2분씩 쓴다면 한 달이면 한 시간이고, 깜빡한 … 더 읽기

Node.js에서 .cmd 실행이 EINVAL로 죽을 때 (윈도우)

윈도우에서 Node.js 스크립트로 npm이나 npx를 호출하다가 node spawn EINVAL 에러를 만나면 대부분 당황합니다. 코드를 한 줄도 고치지 않았는데, Node 버전을 올린 다음부터 갑자기 죽기 때문입니다. 저도 자동 발행 스크립트에서 이걸 만나 30분 넘게 오타를 찾았습니다. 원인은 오타가 아니라 Node 자체의 보안 패치였습니다. 이 글에서는 왜 이런 일이 생기는지, 그리고 상황별로 어떤 해결책을 골라야 하는지 정리합니다. … 더 읽기