바쁘니

워드프레스 소스를 git으로 관리하기 - 코어까지 통째로

워드프레스를 Docker 공식 이미지로 쓰면 소스가 컨테이너 안에 숨어 있습니다. 파일을 직접 보거나 고칠 수 없고, 업데이트도 이미지가 알아서 합니다.편하지만 통제권이 없습니다. 그래서 공식 소스를 직접 받아 git으로 관리하기로 했습니다.결론부터github.com/WordPress/WordPress (공식 미러, upstream) │ git clone --branch ▼ 내 저장소 (origin) ──► 서버워드프레스는 GPL 오픈소스이고 공식 git 미러가 있습니다. 거기서 받아 쓰면업데이트도 git으로 할 수 있습니다.이미지에 맡기기git으로 관리코어 업데이트자동git 으로 직접파일 변조 탐지불가git status 로 즉시코어 수정불가가능관리 부담적음보안 패..

워드프레스를 플러그인 없이 쓰기 - SEO 플러그인이 정말 필요한가

워드프레스를 새로 세우면서 플러그인을 하나도 깔지 않기로 했습니다."그래도 SEO 플러그인은 있어야지" 싶었는데, 하나씩 따져보니 필요 없었습니다.결론부터보통 플러그인을 쓰는 기능실제로는사이트맵 생성워드프레스 기본 제공 (/wp-sitemap.xml)메타 description · OG 태그테마 코드 30줄정규 주소(canonical)워드프레스 기본. 직접 넣으면 중복캐시트래픽 적으면 불필요댓글 스팸 방지댓글을 끄면 불필요백업서버에서 스크립트로플러그인 0개로 돌아갑니다.왜 줄이려 했나플러그인은 남이 쓴 코드가 내 사이트에서 관리자 권한으로 도는 것입니다.취약점이 생기면 그대로 공격 경로가 됩니다개발자가 손을 놓으면 보안 패치가 멈춥니다사이트가 느려지는 흔한 원인이기도 합니다워드프레스 침해는 코어보다 플러그..

Docker Compose로 워드프레스 올리기 - 실제로 막혔던 지점들

워드프레스를 직접 호스팅하려고 Docker Compose로 올렸습니다. 공식 이미지가 있어서 금방 끝날 줄 알았는데, 막힌 곳이 네 군데였습니다.전부 "설치 가이드"에는 안 나오고 실제로 해봐야 만나는 것들이었습니다.결론부터 — 구성과 함정Caddy (리버스 프록시, 자동 HTTPS) └─ WordPress (php-apache) └─ MariaDB └─ Redis (선택)막힌 지점원인첫 기동에서 DB 연결 실패depends_on 이 컨테이너 시작만 보고 넘어감무한 리다이렉트프록시 뒤에서 HTTPS를 인식 못 함설정 바꿔도 반영 안 됨바인드 마운트는 compose up -d 가 변경을 감지 못함퍼머링크 전부 404.htaccess 가 없음1. depends_on 만으로는 부족합니다..

curl로 받은 HTML은 수만 글자입니다. 여기서 제목 하나, 개수 하나를 꺼내려면파이프로 몇 개를 엮으면 됩니다. 별도 도구를 설치할 필요가 없습니다.결론부터 — 이 네 개 조합이면 웬만한 건 됩니다grep -o '패턴' # 매치된 부분만 출력 (줄 전체가 아니라)grep -c '패턴' # 개수만 세기sed 's/]*>//g' # HTML 태그 제거tr -s ' \n' ' ' # 중복 공백·줄바꿈 압축grep -o — 이게 핵심입니다보통 grep은 매치된 줄 전체를 보여줍니다. HTML은 한 줄이 수천 글자라 쓸모가 없습니다.-o를 붙이면 매치된 부분만 나옵니다.# 제목 뽑기curl -s https://example.com/ | grep -o '[^'# 사이트..

상태 코드는 수십 개지만 실무에서 실제로 보는 건 열 개 남짓입니다.전체를 외우는 것보다 "이게 나오면 어디를 봐야 하는지" 를 아는 게 낫습니다.결론부터 — 첫 자리로 책임 소재가 갈립니다앞자리뜻누구 문제인가2xx성공—3xx다른 곳으로 이동설정 문제일 수 있음4xx요청이 잘못됨보내는 쪽 (주소·권한·인증)5xx서버가 처리 못 함서버 쪽4xx가 나오면 내 요청을, 5xx가 나오면 서버를 봅니다. 이 구분만 해도 절반은 잡힙니다.자주 보는 것들2xx — 성공코드의미비고200정상204성공했지만 줄 내용 없음API에서 삭제 처리 등206일부만 전송동영상 구간 재생, 이어받기3xx — 이동코드의미주의301영구 이동브라우저가 강하게 캐시한다302임시 이동검색엔진은 옛 주소를 유지한다304안 바뀜캐시 쓰라는 뜻. ..

티스토리에 개인 도메인을 붙이는 건 어렵지 않습니다. 문제는 그 구조가 나중에 무엇을 제약하는지입니다.저는 다 붙이고 나서야 알았습니다.결론부터 — 세 가지 제약제약내용블로그 1개 = 도메인 1개서브도메인을 쓰려면 블로그를 새로 만들어야 한다CNAME 방식루트 도메인에 걸면 MX·TXT를 함께 쓸 수 없다인증서 발급 주체가 티스토리내가 통제할 수 없다붙이기 전에 이것만 알고 시작하면 나중에 고생을 덜 합니다.1. 연결 방식은 CNAME입니다티스토리 개인 도메인은 이렇게 겁니다.CNAME blog host.tistory.ioA 레코드(IP 직접 지정)가 아니라 CNAME(별칭) 입니다. 서버 IP가 바뀌어도 티스토리 쪽에서 알아서 처리되므로 운영자 입장에선 편합니다.문제는 루트 도메인(example..

"주소를 바꿨으니 예전 주소로 들어오면 새 주소로 보내야지."방법이 여럿인데 겉으로는 다 똑같아 보입니다. 브라우저에서는 전부 새 페이지로 넘어가니까요.그런데 검색엔진이 받아들이는 방식은 전혀 다릅니다.결론부터방식응답검색엔진주소 표시줄쓸 곳301HTTP 301색인 이전새 주소영구 이전302HTTP 302기존 주소 유지새 주소임시 점검·A/B308 / 307HTTP 308/307301/302와 유사새 주소POST 유지해야 할 때meta refreshHTTP 200취급이 불확실새 주소권장하지 않음프레임(마스킹)HTTP 200이전 안 됨옛 주소 그대로피할 것주소를 영구히 옮겼다면 301입니다. 나머지는 목적이 다릅니다.301과 302의 차이301 Moved Permanently302 Found뜻"여기 영구히 ..

블로그에 글이 실제로 몇 개인지, 검색엔진이 뭘 보고 있는지 확인하려면 `sitemap.xml`을 보면 됩니다.**로그인하지 않고 밖에서** 알 수 있습니다.## 결론부터```bash# URL 개수 세기curl -s https://example.com/sitemap.xml| grep -c ''# 실제 주소 보기curl -s https://example.com/sitemap.xml | grep -o '[^' | sed 's/]*>//g'```사이트맵은 **"이 사이트에 이런 페이지들이 있다"고 검색엔진에 알려주는 목록**입니다.대부분의 블로그 서비스가 자동으로 만들어 줍니다.## 함정 — 숫자를 그대로 믿으면 안 됩니다### 1) 시스템 URL이 섞여 있습니다블로그 서비스는 글이 하나도 없어도 이런 주소들..

요즘 인증서는 대부분 자동 갱신됩니다. 그래서 실패해도 아무도 모릅니다.발급 당시엔 멀쩡하니, 만료일 당일에 사이트가 죽고 나서야 알게 됩니다.결론부터# 만료일 확인 — 이거 하나만 주기적으로 돌리면 됩니다echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \ | openssl x509 -noout -subject -datessubject=CN = example.comnotBefore=Sep 7 17:01:45 2026 GMTnotAfter=Dec 6 17:01:44 2026 GMTLet's Encrypt 인증서는 유효기간이 90일입니다. 자동 갱신을 전제로 한 설계입니다갱신은 만료 전에 미리 일어납..

"브라우저에서는 되는데 왜 안 된다고 하지?"사이트 문제를 브라우저로 확인하면 캐시, 자동 재시도, 인증서 예외 처리 때문에 실제와 다르게 보입니다. curl은 그런 보정 없이 서버가 실제로 뭘 주는지 그대로 보여줍니다.결론부터 — 이 다섯 개면 대부분 잡힙니다curl -s -o /dev/null -w '%{http_code}\n' https://example.com/ # ① 살아있나curl -sI https://example.com/ | grep -i location # ② 어디로 보내나curl -s ... vs curl -sk ... # ③ 인증서 문제인가curl --resolve example...