오늘은 새벽에 절전 설정을 손보는 것으로 시작해서, 자동 실행이 실패한 원인을 반나절 넘게 뜯어보고, 그 사이 블로그 화면 버그 3가지와 SEO 라벨 문제까지 한 번에 잡은 날이었다.
절전 설정부터 손봤다
매일 아침 7시에 자동으로 글을 발행하는 파이프라인이 있는데, 노트북이 잠들어 있어도 정시에 깨어나는지가 궁금했다. pmset 설정을 같이 들여다보면서 예약 웨이크(wakeorpoweron)를 06:55에 걸어두기로 했다. 명령어를 실행하고 pmset -g sched로 실제 등록됐는지 확인하는 것까지 마치고 잠들었다.
아침에 실행이 안 됐다
08시가 넘어서 확인해보니 어젯밤 설정한 예약 확인 작업은 정시(08:00:49)에 돌았는데, 정작 진짜 07시 파이프라인 로그는 어젯밤 이후로 갱신된 흔적이 전혀 없었다. launchd가 EX_CONFIG(78)라는 오류로 실행 자체를 거부하고 있었다.
절전/FileVault 문제인가 싶어 시스템을 완전히 깨운 상태에서 재시도했지만 또 실패했다. venv Python의 코드서명 문제인가 싶어 셸로 한 번 감싸는 방식으로 바꿔봤는데, 격리된 테스트에서는 성공했지만 실제 등록된 작업에 적용하니 다시 실패했다. Label 이름에 무언가 "낙인"이 남는 건가 싶어 완전히 새 이름으로 등록해봤더니 이번엔 성공 — 그런데 같은 방식으로 또 다른 새 이름을 만들어 재현해보니 다시 실패했다. 몇 시간을 이렇게 가설을 세우고 무너뜨리기를 반복하다가, 반복적인 재등록/재시도 자체가 오히려 문제를 더 꼬았을 가능성이 있다고 보고 일단 손을 뗐다.
블로그 화면 버그 3가지를 발견했다
그 사이 실제 블로그를 열어보니 완전히 다른 문제가 있었다. 게시글을 눌러도 홈 화면 요약이 그대로 나오고, 사이드바의 인기글 링크는 전부 홈으로 돌아가고, 사이드바의 시황판은 하드코딩된 가짜 숫자였다.
| 증상 | 원인 |
|---|---|
| 게시글 클릭 시 홈 요약만 나옴 | 테마 위젯이 "개별 글 보기"인지 구분하는 조건 분기가 아예 없었음 |
| 인기글 링크가 전부 홈으로 이동 | 테마에서 쓴 변수명이 실제로는 항상 빈 값이었음 |
| 표 안 글자가 갑자기 커짐 | 드롭캡 스타일이 "글 전체 첫 문단"이 아니라 표 안 문단까지 잡아버림 |
이 과정에서 예전에 붙여넣은 게시글 하나의 HTML 용량이 781KB나 되는 것도 발견했다. AI 리서치 도구 화면을 그대로 복사해서 붙여넣은 흔적이었는데, 정리 도구를 만들어 32KB로 줄였다. 확인해보니 같은 문제가 있는 글이 11개 더 있었는데, 오늘은 도구만 만들어두고 실제 정리는 다음으로 미뤘다.
실시간 시장 지수 위젯을 새로 만들었다
사이드바 시황판을 진짜 데이터로 바꾸는 작업도 했다. 코스피는 스크래핑 대신 공공데이터포털의 정식 오픈데이터를 쓰기로 했고, 나머지 지수는 기존에 쓰던 데이터 소스를 재사용했다. 그런데 Blogger는 테마를 API로 다시 배포할 방법이 없어서, 매일 계산한 값을 별도 저장소에 공개 파일로 올려두고 방문자 브라우저가 직접 그 파일을 읽어오는 구조로 설계했다.
SEO 라벨도 정리했다
게시글에 자동으로 붙던 라벨이 너무 기계적으로 보인다는 지적을 받고 다시 살펴봤다. 내부용 태그가 모든 글에 똑같이 붙다 보니 그 라벨 페이지가 사실상 블로그 전체 글 목록과 같아지는 문제가 있었다. 실제 독자가 검색할 만한 지표명과 지역 키워드로 바꿨다.
Trouble Shooting
| 증상 | 원인 | 해결 방법 |
|---|---|---|
| launchd 자동 실행이 EX_CONFIG(78)로 계속 실패 | 절전/서명/이름 낙인 등 여러 가설을 세웠으나 확정 못 함 | 이름을 바꾸고 방어적으로 코드를 감쌌지만 검증된 해결책은 아니라고 기록만 남기고 보류 |
| 사이드바 스크립트가 브라우저에서 조용히 안 먹힘 | 스크립트를 감싼 특수 구문을 Blogger가 벗겨내지 않고 글자 그대로 내보냄 | 그 구문 자체를 없애고, 필요 없는 문자를 안 쓰는 방식으로 스크립트를 다시 씀 |
| 표 안 글자가 58px로 부풀어 보임 | 스타일 규칙이 "첫 문단"을 너무 넓은 범위로 잡고 있었음 | 범위를 "바로 아래 자식"으로 좁혀서 표 안까지 안 번지게 수정 |
느낀 점 / 다음에 할 일
같은 방식으로 재현을 시도해도 결과가 오락가락하는 문제는 그 자리에서 끝까지 붙잡기보다 일단 기록해두고 다음 자연스러운 실행을 지켜보는 게 나을 때가 있다는 걸 다시 느꼈다. 반대로 사용자가 직접 화면을 보고 알려준 문제들은 원인이 훨씬 명확하게 잡혔다 — 결국 실제로 써보고 눈으로 확인하는 과정을 건너뛸 수 없다는 뜻이다. 다음에는 내일 아침 자동 실행이 실제로 성공하는지부터 확인하고, 남은 지수 데이터가 잘 반영되는지 마저 확인할 계획이다.
댓글
댓글 쓰기