남의 CSS 코드를 복붙했는데 아무 일도 일어나지 않는 경험, 한 번쯤 해보셨을 것이다. 나는 #content에 width를 아무리 줘도 사이드바가 꿈쩍도 안 해서 한참을 헤맸다. 알고 보니 내 스킨은 #content라는 ID 자체가 없었다. 처음엔 내가 CSS를 잘못 쓴 줄 알았다. 그런데 원인은 코드가 아니라 전제가 틀린 것이었다. 존재하지 않는 대상에게 명령을 보낸 셈이었다.
이 경험이 내게 가르쳐준 건 의외로 단순했다. 내 블로그의 실제 구조를 먼저 봐야 한다는 것. 순서가 틀리면 아무리 좋은 코드도 소용없다.
편집창만 보면 절반밖에 못 본다
티스토리 스킨 편집창을 처음 열면 HTML과 CSS가 뒤섞인 코드가 나온다. 여기에는 치환자라는 것이 포함되어 있다. 치환자는 티스토리가 실제 렌더링 시점에 특정 데이터로 자동 대체해주는 플레이스홀더인데, 예를 들면 같은 형태다. 편집창에서는 이 치환자 그대로 보이지만, 실제 브라우저에서는 전혀 다른 HTML 구조로 바뀐다.
내가 한참 삽질한 이유가 여기에 있었다. 편집창만 들여다보며 구조를 파악하려 했는데, 치환자가 렌더링된 결과를 직접 보지 않으면 부모·자식 관계를 정확히 알 수가 없다. 사이드바를 감싸는 컨테이너 ID가 편집창에서는 보이지 않다가 렌더링 후에 생성되는 경우도 있다. 이때 CSS를 아무리 수정해봐야 타겟 자체가 틀렸으니 변화가 없는 것이다.
여기서 솔직히 말하면, 처음 이걸 깨달았을 때 허탈했다. 몇 시간 동안 고친 건 코드가 아니라 없는 ID를 향한 헛수고였으니까. 그런데 동시에 "그러면 내 블로그의 실제 구조를 보면 되잖아"라는 생각이 들면서 F12를 눌렀다. 그게 전환점이었다.
개발자 도구 Elements 탭이 실제 설계도다
Chrome DevTools의 Elements 탭은 브라우저가 실제로 렌더링한 DOM 트리를 실시간으로 보여주는 패널이다. 치환자가 어떻게 변환됐는지, 어떤 ID와 클래스가 실제로 존재하는지를 여기서 볼 수 있다. 나는 Ctrl+F 검색보다 트리를 눈으로 직접 따라가는 방식을 선호한다. 검색은 해당 요소 하나만 보여주는 반면, 트리를 따라가면 어떤 요소가 어떤 부모 아래에 있는지 한눈에 파악되기 때문이다.
스킨 구조를 파악할 때 확인해야 할 것들은 이렇다. 실제 렌더링된 컨테이너 ID와 클래스 이름, 사이드바와 본문 영역의 부모 요소 관계, 치환자가 렌더링된 후 생성되는 추가 태그 여부, float 또는 flex 기반 레이아웃 방식. 이 네 가지를 파악하고 나면 스킨의 뼈대가 보이기 시작한다.
HTML 구조를 파악했다면 다음은 CSS 탭이다. 이 방법을 알게 된 것이 스킨 편집에서 가장 큰 전환점이었다고 생각한다.
CSS 탭에서 레이아웃 설계도를 읽는 법
개발자 도구 CSS 탭에서 # 기호로 검색하면 ID 선택자에 적용된 스타일만 추려서 볼 수 있다. ID 선택자는 HTML 요소에 부여된 고유 식별자를 기반으로 스타일을 지정하는 방식인데, CSS 명시도 계층에서 클래스 선택자보다 우선순위가 높다. 명시도란 CSS 규칙이 충돌할 때 어떤 스타일이 최종적으로 적용될지 결정하는 우선순위 체계다. 이 개념을 모르면 아무리 CSS를 추가해도 기존 스타일에 덮어씌워지지 않는 상황이 반복된다.
직접 써봤을 때, CSS 탭에서 스킨의 주요 ID들에 걸린 float, width, margin 값을 확인하니 그게 사실상 그 스킨의 레이아웃 설계도였다. 예를 들어 #sidebar에 float: right와 width: 280px이 걸려 있고, #main-content에 margin-right: 300px이 걸려 있으면, 이 두 요소가 좌우로 나뉘는 구조라는 것을 즉시 알 수 있다. HTML만 보면서 추측하는 것과는 속도가 전혀 다르다.
렌더링 결과를 반복해서 보다 보면 치환자가 어떤 구조로 바뀌는지도 점차 예측할 수 있게 된다. 처음엔 가 렌더링 후 어떤 div를 감싸는지 알 수 없어서 매번 확인해야 했는데, 몇 번 반복하고 나니 치환자 종류에 따라 생성되는 구조가 어느 정도 패턴화됐다. 이 감각이 생기면 스킨 편집 속도가 확연히 달라진다.
스킨마다 ID가 다르다는 걸 받아들이기까지
스킨 커스터마이징 관련 글을 찾아보면 #container, #content, #sidebar 같은 ID가 보편적인 것처럼 소개된 경우가 많다. 나도 그렇게 믿었다. 그런데 블로그 글을 따라 했는데 결과가 나오지 않으면 처음엔 무조건 내 실수라고 생각하게 된다. 코드가 틀렸나, 위치가 잘못됐나, 한참을 뒤졌다. 실제로는 스킨마다 ID 이름이 제각각이라 남의 코드를 그대로 붙여 넣으면 처음부터 작동하지 않는 경우가 허다한데도.
이게 꽤 오래 걸렸다. "아, 내가 뭘 잘못한 게 아니라 전제 자체가 달랐구나"를 인정하는 데까지. 그 이후로 바뀐 것은 딱 하나다. 남의 코드를 보기 전에 내 블로그 개발자 도구를 먼저 연다. 순서를 바꾸는 것만으로 삽질하는 시간이 절반 이하로 줄었다.
명시도 충돌 문제, 마지막 함정
CSS 선택자 계층에서 또 하나 알아두면 좋은 것이 명시도 충돌 문제다. 스킨 기본 CSS에 !important가 붙어 있거나 인라인 스타일이 적용된 경우, 아무리 새로운 CSS를 추가해도 적용이 안 될 수 있다. 인라인 스타일은 HTML 태그 안에 직접 style 속성으로 작성된 스타일인데, 외부 CSS 파일보다 명시도가 높아서 쉽게 덮어쓰기가 어렵다.
이 역시 개발자 도구 Elements 탭에서 해당 요소를 선택해보면 어떤 스타일이 우선 적용되고 있는지 취소선 표시로 즉시 확인할 수 있다. 취소선이 그어진 스타일은 더 높은 명시도의 다른 스타일에 의해 무력화된 것이다. 이걸 모르면 CSS가 왜 안 먹히는지 영원히 알 수 없다.
처음엔 무서웠던 스킨 편집이 지금은 가장 먼저 손이 가는 메뉴가 됐다. 두려움의 정체가 "구조를 모른다"는 것이었는데, 개발자 도구로 구조를 눈으로 보기 시작하면서 그 막막함이 사라졌다. 티스토리 스킨 편집이 어렵다고 느껴진다면, CSS 코드를 찾기 전에 F12부터 눌러보길 권한다.
참고:
티스토리 공식 스킨 가이드: https://tistory.com
MDN Web Docs – CSS Specificity: https://developer.mozilla.org/ko/docs/Web/CSS/Specificity
Chrome DevTools 공식 문서: https://developer.chrome.com/docs/devtools
MDN Web Docs – CSS position: https://developer.mozilla.org/ko/docs/Web/CSS/position