워드프레스 내에 포함된 이 블로그의 다른 퍼머링크로 가는 URL이, 블로거닷컴으로 옮겨오면서 모두 깨지는 참사가 일어났다. 서비스마다 퍼머링크 구조와 정책이 다르니 당연한 일이고 감수하려고 했다. 다행이 예전 링크를 새 링크로 수정하는 방법을 AI를 통해 찾을 수 있었고, 방금 400여개 글에 포함된 링크를 모두 수정하였다. 서버에 API로 연결을 해서 내용을 가져오고 변경해서 업데이트 하다보니 자동으로 처리를 했음에도 15분 정도 걸렸다. 주로 2005년부터 2007년 사이의 글에 집중되었고 2008년 이후로는 발생빈도가 뚝 떨어졌다. 블로그의 부흥기라고나 할까, 그 즈음에 유행했던 글쓰기 패턴이었나보다. 아무래도 글도 지금보다 더 자주 썼을 것이고.
검수(?)하면서 살펴보니 다른 사이트로 연결한 링크들은 99%이상 다 깨진 상태이다. 어쩔 수 없는 일이다. 내가 사용한 내 퍼머링크에 대해서는 게시물 단위로는 거의 다 살려놓았으니 링크에 대한 책임은 이 정도면 됐지 싶다.
워드프레스가 설치되어 있던 AWS 라이트세일 인스턴스를 완전히 삭제했다. 아침에 인스턴스를 중지 상태로 바꿔놓고 '블로거닷컴에서 적응이든 셋팅이든 실패하면 다시 워드프레스로 돌아갈거야?' 를 생각해보니 차마 다시 돌아가진 못하겠다. 인스턴스를 재부팅하거나 새로 생성하는 순간부터 따라오는 수많은 셋팅과 모니터링, 유지보수에 대한 책임과 스트레스를 또 감당할 생각을 하니 속이 메슥거릴 정도다. 말하자면 배수의 진이다. 워드프레스를 즉시 되살릴 수 있는 여지를 없애버렸다.
24년차에 접어든 블로그 생활 중 가장 큰 변화가 아닐까 싶다. b2로부터 시작해서 워드프레스로 운영하다가 오늘 블로거닷컴으로 이사를 했다. 아직 도메인을 옮긴것은 아니라 지금은 블로거닷컴에서 받은 주소만 갖고 있는 상태이다. 안정화가 되면 도메인도 이쪽을 향하도록 수정할 것이다. 일단은, 그간의 글과 이미지를 마이그레이션 해 왔다. 변경하면서 달라진 점들은 이러하다.
6월에 aws 라이트세일 블루프린트가 기존 비트나미 패키지에서 라이트세일 패키지로 변경되면서 새 인스턴스를 만들어서 이 블로그를 옮겼다. 이후로 업타임로봇의 5분주기 핑 테스트에서 잦은 서버 접속불가 현상이 생기기 시작했다. 할 수 있는 원인파악 방법과 대응을 해 보았으나 전혀 효과가 없었다. 인스턴스간 편차가 있나 싶어 새 인스턴스를 서너개 교체해 보았다. 오랜 세월 운영하며 워드프레스 DB가 꼬였나 싶어 새로 설치하고 순수한 게시물 데이타XML과 첨부 이미지만 옮겨와 보았다. 모든 플러그인을 다 사용중지도 해 보았다. 그래도 하루, 길어도 이틀에 한번은 접속 불가 리포트가 날아왔다. 외부의 공격이 원인이라면 클라우드플래어가 막아줄테니 최후(?)의 수단으로 클라우드플래어의 방화벽 뒤로 숨어보았다. 어제 오후에 네임서버를 옮기고 프록시 서비스를 작동시켰다. 아침에 일어나보니 밤에 서버 순단현상이 생겼다는 업타임로봇의 알림메일이 도착해 있었다. 밤10시 반에 한번 왔었고, 두번째는 아침 6시에 또 한번 타임아웃 알림 메일이 도착했는데 다행이 그 순간에 컴 앞에 있던 중이라 즉각 이 블로그에 접속해보니, 어? 접속이 잘 됐다. 4분뒤에 접속이 복구됐다는 메일이 도착했다. 5분 주기 체크이긴 한데 체크한 순간에 접속이 안되고 즉각 메일이 왔고 내가 바로 블로그 접속을 했으니 1. 접속이 안되고 있는 중 2. 체크 3. 알림 4. 확인의 상황이 이루어지기까지는 수초 정도만 걸렸을 것이다. 접속이 안된다며? 그런데 나는 접속이 되네?
됐고, 일단 클라우드플래어의 프록시가 해결해 줄 수 있는 문제가 아님은 명확해졌다. 네트워크 타임아웃 "문제"를 해결하기 위해 클라우드플래어로 들어가는 것은 해결책이 아닌게다. 아울러 이 조치에 따른 부작용이라 해야할지, 문제가 생겼다. 블로그 접속에 종종 지연이 발생했다. 이게 0.5초 걸리던게 1초가 걸리는게 아니고 10초 지연도 걸리고 50초 지연도 걸리곤 한다. 당연히 용납할 수 있는 수준이 아니다. 특히 wp-admin 하위 메뉴로 들어가면 지연이 더 심해지는데 2분 가까이 걸린 적도 있었다. 페이지 열리는데 2분 걸리는 것이면 인터넷에 블로그를 쓸게 아니고 타자기로 쳐서 펀치 뚫어 보관하는 걸 고려해야하지 않겠는가.
일단 클라우드플래어로 옮긴 네임서버는 그대로 두고 프록시 기능을 다 껐다. 즉각 페이지 (메인 및 개별게시물) 로딩 속도가 0.3~0.4초대로 회복되었다.
두번째 조치는, 이건 마치 원효대사 해골물 같은 관점인데. 업타임로봇의 모니터링을 껐다. 뭔가 천만뷰 블로그를 운영하는 것도 아니고 매출이 나오는 쇼핑몰도 아니고, 하루에 한번 5분 이내 순단 현상이 일어난다고 보면 이것 때문에 스트레스받지 말고 그냥 모니터링을 중단하는게 낫겠다 싶었다. 여태까지 해본 조치들의 면면을 보면 해볼만큼 한계까지 해본 것이고 더 이상의 노력과 시간을 들이는 것은 흔한 말로 인건비도 안나오는 작업이다. 심지어 접속이 안된다는 알림이 오자마자 접속해보니 접속이 잘 되는 상황을 겪어보니, 어쩌면 허깨비를 앞에 두고 쉐도우복싱을 하는건 아닌가 하는 의심도 하게 됐다.
[업데이트]@2026.8.29
잘못된 접속 중단 알림은 아니었다. 며칠전 또 한번 접속 타임아웃 알림이 왔고 곧바로 접속 테스트 해보니 연결이 안됐다. 메모리는 다 사용했고 추가로 스왑이 엄청 잡혀 있었는데 에러 로그를 못 남길 정도로 지연이 있었다는 AI님의 진단이 있었다. 서버 사양을 한단계 올리라는 조언이 있었는데 그 사양이 충분한지, 앞으로도 영원히(?) 충분한지는 아무도 모르는 것.
6월에 AWS Lightsail에서 이 블로그가 돌아가는 인스턴스를 비트나미 인스턴스에서 라이트세일 인스턴스로 변경하였다.CPU니 램이니 서버 스펙은 완전 동일했고 블로그도 잡데이터들 삭제하고 깨끗하게 정리해서 옮겼다. 문제는 그때부터 며칠에 한번씩 몇분씩 접속 불가 현상이 생겼다.
uptimerobot.com 에서 5분 간격으로 서버가 살았는지 죽었는지 찔러보고 접속이 안되면 메일을 보내준다. 그간 받은 로그를 차트로 그려보니 이러했다. 예전에는 일년에 한번 접속 끊기는 정도였는데 6월에 인스턴스를 바꾸면서부터는 일주일에 한번 이상 접속이 끊겼다가 복구되곤 하였다. 두달간 아파치의 error.log를 제미나이를 이용해 분석시켰고 두가지 대응방안을 받았다. 첫번째는 .htaccess를 이용하여 워드프레스 내부 파일에 직접 접속할 경우 403 에러를 내는 것. (기존에는 500 에러)
두번째는 비트나미 인스턴스 때는 있다가 라이트세일 인스턴스에서 사라졌다고 하는 fail2ban 을 다시 설치하여 비정상적인 접근을 하는 아이피들을 자동으로 ban시키는 것이다.
처음에는 .htaccess 을 이용하는 방법만 적용했는데 error.log를 보니 하루 2~3천회씩 접속하는 ip들이 보여서 fail2ban까지 함께 적용시켰다. 이상한 짓 하는 ip들이 잘 차단되는지, 무엇보다 네트워크 타임아웃 오류가 사라지는지 지켜봐야겠다.
[업데이트]@2026.8.17
하루만에 서버 접속불가 현상이 또 생겼다. 접속 불가가 생기기 직전 access.log와 error.log는 깨끗했다. fail2ban이 블록한 ip도 하나도 없이 0을 유지하고 있었다. 서버 cpu도 꾸준히(...) 1%~2% 부하를 벗어나지 않았다. 외부로부터 들어오는 악성 트래픽이 원인이 아닌가보다.
서버 사양이 동일하다 하더라도 비트나미에서 라이트세일로 블루프린트가 바뀌었고 어쩌면 환경 편차가 있을 수도 있으니 새 인스턴스를 만들었다. 저번에 고생한 것과 다르게 이번에는 다행이 구글드라이브에 자동 백업된 DB와 첨부파일이 문제없이 한방에 복원이 됐다. SSL 인증서도 라이트세일 웹 ui에서 쉽게 발급할 수 있었다. 처음 생성한 서버에서 생긴 오류가 두달 뒤에 생성한 서버에서는 괜찮을까, '그래 저번 서버는 뭔가 잔잔한 오류나 편차가 있던 서버였을수도 있잖아?' 하는 불안 반, 기대 반인 심정이다. 이래도 또 순단현상이 생기면 진짜 20년간의 워드프레스를 다 고정페이지로 발행해버리고 새 블로그를 하던지 해야하지 않겠나 싶기도 하다.
간만에 지인들과 완주 봉동시장 우리국수를 찾았다. 몇달만의 방문인데, 가게는 출입문부터 내부,주방까지 다 깨끗하게 바뀌었다. 할머니는 안계셨고 다른 분 두분이 조리와 서빙을 담당하고 계셨다. 벽에 걸려있던 할머니의 오래전 기사 액자도 없어졌다. 새 주인장의 멸치 육수는 괜찮은 편이었다. 다만 앞으로도 두시간 넘게들 달려와 먹을 것이냐는 물음에는 아무도 대답하지 않았다. 그럴 만도 하다. 국수뿐만이 아니라 할머니가 계신 오래된 가게, 부글부글 끓어넘치는 면 삶는 솥, 겨울이면 물방울이 잔뜩 들러붙어 있는 낡은 출입문까지 한꺼번에 애정해던 것이니까.
건강이 허락할때까지 문 열겠다고 하셨는데 무슨 일인가 하는 걱정과 함께 그동안 삶아주신 국수 맛있게 잘 먹었다는 감사 인사를 이렇게 남긴다.
작년부터 아내가 온라인 수업을 듣고 있다. 인강 사이트가 윈도우만 지원하는지라 윈도우가 돌아가는 노트북이 필요했다. 인텔 CPU가 달려있는 2017 맥북프로가 개점휴업 상태로 있는 중이라 일단 이 녀석을 이용하기로 했다. 부트캠프로 맥 파티션을 최소한으로만 잡고 윈도우가 기본값으로 부팅되도록 했다. 그럭저럭 온라인 학습을 하기에 성능상 부족함은 없을 것이었다. 다만 문제는 6년쯤 사용한 배터리가 말썽이었다. 완충을 시켜놔도 며칠만에 자연 방전되고 만다. 이러다보니 공부할려고 노트북을 사용하기 위해서는 전원 어댑터를 같이 끌고 다니면서 상시 연결을 시켜두어야했다.
회사 다니며 시간을 쪼개 하는 공부인데 노트북 전원까지 신경쓰면서 공부하게 하고 싶지는 않았다.
쓰던 맥북보다 화면은 더 큰데 30%쯤 가벼운 윈도우 노트북을 하나 구입했다. 해상도도 레티나 디스플레이에 근접해서 만족스러웠다. 이제 생각날 때 아무 때나 전원에 꽂아놨다가 대충 전원선 분리해 두고, 시간날 때 아무데서나 편한데 앉아서 공부하면 되겠다.
200여회 충전에 대해 테슬라메이트가 기록한 충전손실율 기록이다. 보통 10% 정도 손실이 있다. 20%이상의 손실이 있던 완속 충전은 대개 추울 때 5~10kWh 정도 조금 충전했던 경우다. 충전을 위해 배터리를 뎁히거나 차량 시스템을 가동시키기 위한 기본 전력 대비 충전량이 적어서 생긴 까닭으로 보인다. 주황색 막대는 급속(DC)충전이고 보통 9%정도 손실이 있으니 대충 비슷하다 치고. 단, 완속(AC) 충전기는 충전기가 보낸 전력량 대비 차량에서 받아들인 전력량 사이 손실분을 사용자가 부담하고 급속(DC)은 업체가 부담한다. 그러니까 완속의 손실분 10%는 내가 내고, 급속의 손실분 9%는 업체가 부담한다. 따라서 1kWh당 완속이 290원이고 급속이 350원이라 치면 급속이 60원 비싼 요금이지만 손실율에 대한 금액 부담을 고려하면 실제로는 30원 비싼 셈이다.
대체 뭐가 문제인지 모르겠는데, 회사 와이파이에서만 아이폰과 맥에서의 메시지 동기화 지연이 심하다. 아이폰으로만 주고받으면 맥에 메시지가 늦게 뜬다. 반대로 맥에서 계속 메시지를 주고받으면 아이폰에서 그 메시지들이 늦게 뜬다. 회사 와이파이가 아닌 다른 모든 와이파이에서는 일어나지 않는 문제이다. 이제는 그러려니, 하고 반쯤 (아니면 거의) 포기하고 있는 중이다. 몇년은 된 문제이고 이통사를 KT향을 쓸 때, SKT향을 쓸 때를 가리지 않는 문제다.
그러다 문득 발견한 현상. 아이패드미니 와이파이 모델로 이북리더 겸 해서 사용중이라 안볼때는 맥 옆에 눕혀 놓고 있다. 맥에서 메시지를 주고받고 하다보니 아이폰은 늘 그렇듯이 새 메시지 알림이 뜨지 않는데 아이패드에서는 계속 동시에 메시지 도착 알림이 뜬다. ????? 맥과 아이폰, 아이패드가 모두 같은 와이파이에 연결되어 있는데 말이다. 그렇다면 문제는 여태까지 계속 문제로 의심해왔던 와이파이가 아니라 아이폰의 셀룰러 네트워크도 관련이 있다는 얘기인가?
아이패드와 같은 조건을 만들기 위해 아이폰의 셀룰러 데이터를 끄고 와이파이만 켠 채 맥의 메시지로 아내에게 테스트 메시지를 요청했다. 아내의 메시지가 맥과 아이패드, 아이폰(!)까지 동시에 뜬다. 이거 그러면 아이폰의 셀룰러 데이터와 와이파이 상에서 뭔가 알수는 없지만 충돌이라도 있는 것인가? 셀룰러데이터와 와이파이 설정을 찾아보니 일단 설정 → 셀룰러 → 셀룰러 데이터 옵션 → 음성 및 데이터가 "5G 우선"으로 되어 있었다. LTE를 사용중이기 때문에 그 아래에 있는 "LTE"항목으로 바꾸었다. 셀룰러 데이터를 다시 켠 후 아내에게 테스트 메시지를 요청하니 이번에는 셀룰러 데이터를 켰음에도 아이폰에도 즉시 메시지가 도착했다.
일단 이렇게 해두고 더 테스트를 해 봐야겠다. 와이파이 연결이 불안정하면 셀룰러가 지원한다는 Wi-Fi지원이 켜 있는 상태이니, 이번 테스트가 실패(...)하면 이 옵션도 꺼봐야겠다. 참 오래된 문제인데, 인터넷에서는 관련한 정보나 같은 문제를 겪고 있는 사람의 경우를 찾을 수 없으니 답답한지고...
[업데이트]@7.1 12:50
이 방법도 소용없다. 맥에서 아내에게 메시지 전송. 아내의 답장은 아이폰으로 도착. 2~3분 대기. 맥의 메시지에서 (아직 아이폰으로 온 메시지가 동기화 되진 않았지만) 답장부터 먼저 작성해서 전송하니, 그제서야 맥에도 아내가 보냈던 메시지가 뜬다. 결국 실패로 결론. 이제 아이폰의 설정→셀룰러 → Wi-Fi 지원 기능을 끄고 한번 더 살펴보자.
[업데이트]@7.1 15:15
아이폰으로 메세지 알림이 온 후, 맥의 메시지창을 열어 메시지를 확인하고 답장하려고 기다려도 묵묵부답. 이번 테스트도 이렇게 망한 것으로 종료한다. 그렇다면 역시 희한한 이 와이파이가 유일한 문제로 확정되는 것인가. 그렇다면 왜 아이패드에서는 전혀 지연이 발생하지 않는 이유는 뭘까, 싶다. 심지어 잠금 상태로 파우치 속에서도 문자(아이메시지 포함) 도착할때마다 알림음이 나고 있다.
[업데이트]@7.2 13:30
어제 밤에 아이폰에서 네트워크 설정값을 초기화 하였다. 지금 테스트 해보니 아이폰으로 도착한 문자가 맥의 메시지 앱으로는 30초 정도 후에 도착한다. 30초면... 동시라고 볼 수 있을지, 지연이라고 해야할지 조금 애매하다. 다시 한번 테스트 문자를 보냈다. 이번에는 거의 동시에 맥,아이폰,아이패드 순서로 도착했다.
[업데이트]@7.2 20:15
아이폰와 아이패드 모두 화면 잠금 상태, 맥에서 작업중. 아이폰으로 imessage 도착과 동시에 아이패드에서도 도착음 났다. 그러나 맥에서 메시지 창을 활성화시키고 대화 입력창 클릭까지 한번 해 두었는데 약 1분30초 뒤 메시지 표시되었다. 크. 나도 모르겠다 이제.
인스턴스를 옮기면서 favicon 파일을 빼먹었다보다. 북마크해둔 이 블로그 이름 앞에 뜨던 아이콘이 보이질 않는다. 예전에 백업해둔게 있어서 블로그 루트디렉토리에 올릴려고 하다보니 html에서 파비콘 파일 위치 지정해야하는게 생각났다. 어떻게 했더라, 검색해보니까 어라? 요새는 워드프레스 설정 화면에서 파비콘으로 쓸 이미지를 업로드하면 된단다. 예전에는 헤더파일 수정해서 수동으로 등록했던거 같은데 아무튼 편해졌다. 다만 전에는 가로세로 48x48픽셀이었는데 이제는 최소 크기가 가로세로 512px로 올리란다.
그러니까 브라우저의 탭에 표시되는 파비콘으로만 쓰는 이미지가 아니고 여러 디바이스에서 홈화면에 바로가기로 꺼내놓거나 엣지 브라우저 등에서 시작 페이지에 깔아둘 이미지로도 사용할 수 있으니 아예 넉넉한 크기로 올리라는 것이다. 업로드한 이미지를 워드프레스가 미리 적당한 크기로 변환해두고 필요에 따라 큰 이미지가 필요한데는 큰 이미지로, 파비콘 같은 용도로는 제일 작은 이미지로 알아서 보내주겠다는 것.
여태 파비콘은, 지금은 이런 저런 시끄러운 사정으로 주인도 바뀐 것 같은데 양수리에 있던 어느 식당 겸 카페 마당에서 모닥불 앞에 앉아 찍은 사진으로 만든 아이콘이었다. 픽셀 에디터로 한땀 한땀 찍어서 만든 아이콘이라 큰 이미지로 바꾸기에는 한계가 있었다. 이번 기회에 바꾸기로 했고, @hof 에서 골뱅이는 약간 평평하게 다듬은 원으로, hof에서는 h만 가져와서 만들었다. 한변의 길이가 48에서 512로 바뀌었으니 면적은 100배 이상이 되었다. 무슨 항공사와 물류를 주로 하는 회사 로고와 0.1초 비슷한 느낌이 나긴 하는데, 기분 탓이겠지. 나중에 바꾸던지 해야겠다.
