끄적 끄적 로깅! 로깅!

Gmail을 웹에서 쓰다 보면 메일 하나를 열었을 때 주소창이 이렇게 바뀐다.https://mail.google.com/mail/u/0/#inbox/QgrcJHrhvXXVhMKdgvFSRvHcMBTKbNVfRtL맨 뒤의 QgrcJHrhvXXVhMKdgvFSRvHcMBTKbNVfRtL. 대소문자가 뒤섞인 길쭉한 문자열이라 그냥 랜덤 세션 토큰 같은 거려니 하고 넘겼다. 그런데 이게 랜덤이 아니었다. 서버에 물어볼 것도 없이, 순수 계산만으로 Gmail API가 쓰는 thread ID를 여기서 복원할 수 있다. 그걸 알게 된 삽질 과정을 짧게 남긴다.1. 발단: URL의 ID를 API에 그대로 넣었더니 터졌다메일 링크를 프로그램으로 다루고 싶었다. 링크에서 ID를 떼어내 Gmail API로 스레드를 조회하면..

들어가며: 한도는 소진되고 나서야 보인다Claude Code 구독 요금제에는 두 종류의 사용 한도가 있습니다. 하나는 5시간 롤링 윈도우, 다른 하나는 주간(7일) 한도입니다. 문제는 이 남은 양을 확인하는 내장 방법인 /usage 명령이 대화형 세션에서 내가 직접 쳐야만 보인다는 것입니다.작업에 몰입하다 보면 정작 한도가 얼마나 남았는지 신경 쓸 겨를이 없습니다. 그러다 갑자기 "한도에 도달했다"는 메시지를 만나면, 흐름이 뚝 끊깁니다. 그래서 매 순간 시야 안에 남은 한도가 들어와 있으면 좋겠다는 생각으로 statusline 스크립트를 만들었습니다.아이디어: 바 두 개를 나란히, 그리고 "과속 감지"statusline에 두 개의 막대를 나란히 그립니다.사용률 바 — 지금까지 몇 %를 썼는가. 색으로 ..

리눅스 서버에서 rsync 기반 백업이 도는 시간대에 메모리 사용률이 90%를 넘기며 알람이 뜨는 상황을 겪었다. 원인을 파고들어 보니 서로 다른 두 가지가 얽혀 있었다. 하나는 dirty page 적체, 다른 하나는 rsync가 만들어내는 page cache다. 둘 다 "메모리 사용률 증가"로 보이지만 성격과 대응법이 완전히 다르다. 나중에 또 만날 것 같아 정리해 둔다.1. dirty page 적체로 인한 메모리 스파이크증상대량 파일 쓰기(백업, 미러링 등)가 일어나는 동안 메모리 사용률이 출렁이며 치솟는다. 쓰기가 일정 구간 누적되었다가 한 번에 디스크로 flush될 때 스파이크가 발생한다.원인dirty page는 아직 디스크에 반영되지 않은, 메모리에만 존재하는 수정된 페이지다. 커널은 vm.di..