최신 글
워드프레스 숏코드와 자산 로딩 — 조건부 로딩은 성능이 아니라 범위였습니다
숏코드는 어느 페이지에 붙일지를 개발자가 아니라 운영자가 정하게 만듭니다. 자산은 wp_enqueue_scripts 훅에서 등록만 하고 렌더 시점에 적재했는데, 성능 최적화인 줄 알았던 분리가 테마 전역 뷰포트 설정을 이 페이지에서만 다시 쓰는 열쇠였습니다. 시리즈 마지막 편입니다.
부품 카탈로그가 커스텀 포스트 타입으로 감당되지 않아 커스텀 테이블을 직접 만들었습니다. 그러자 스키마 마이그레이션과 상태 검증까지 제 몫이 되었고, 재실행을 막으려 걸어둔 버전 옵션 가드가 구 스키마를 영구 고착시켰습니다. 쿼리는 성공했고 로그는 깨끗했지만 컬럼은 없었습니다.
훅 이름이 admin_init 이니 관리자만 도달한다고 믿었습니다. 그런데 워드프레스 코어는 인증을 확인하기 전에 그 훅을 발화하고 있었고, 그 안에는 제가 방금 넣은 DROP TABLE 이 있었습니다. 권한 검사를 경로가 아니라 호출 지점으로 옮긴 이야기입니다.
워드프레스 훅은 add_action 으로 걸어두면 알아서 불린다고 생각했습니다. 그런데 표준 훅 네 개가 하나도 발화하지 않았습니다. 훅 기반 통합의 전제는 상대도 워드프레스를 통과한다는 것이고, 그 전제가 깨지면 오류가 아니라 무음 실패로 나타났습니다.
워드프레스에 기능을 넣을 자리는 네 군데였고, 선택 기준은 기술 취향이 아니라 남의 코드가 업데이트될 때 내 코드가 살아남는가였습니다. 플러그인으로 PHP 는 분리했지만 CSS 는 격리되지 않았고, 경계는 제가 그은 곳이 아니라 언어마다 다르게 그어져 있었습니다.
테넌트마다 주소를 준다는 요구는 세 가지 서로 다른 목적을 감추고 있었습니다. 목적을 확정하기 전에 인프라를 지으면 그중 하나는 버려집니다. 그리고 커스텀 도메인의 진짜 비용은 TLS가 아니라 세션이었습니다.
와일드카드 인증서를 손에 넣고 나서야 그것이 한 단계밖에 못 덮는다는 사실이 문제가 됐습니다. 고객사 소유 도메인을 받으려면 애초에 다른 메커니즘이 필요했고, 그 판단이 프록시 선택 자체를 다시 보게 만들었습니다.
멀티테넌트 서브도메인을 위해 와일드카드 인증서를 발급하려다 알게 된 것은, 문제가 TLS가 아니라 DNS 쓰기 권한이라는 점이었습니다. 프록시에 Route53 권한을 주는 순간 생기는 폭발 반경과 그것을 좁히는 방법을 정리했습니다.
어떤 캡챠는 체크박스를 누르는 대신 터미널을 열어 명령어를 붙여넣으라고 시킵니다. 실제 macOS 침해사고의 화면을 무해화해 교보재로 재구성하면서, 어디까지 보여주고 어디부터 지워야 하는지 정한 기준을 적었습니다.
메이저 업그레이드에서 무서운 건 깨지는 API라고 생각했습니다. 실제로 위험했던 건 안 깨지는 쪽이었습니다. 타입도 통과하고 파싱도 정상 동작하는데 커스텀 메시지만 조용히 사라지고 있었습니다.