최근 구글 디스커버 노출을 조금이라도 최적화해보고자 내 블로그의 스킨을 만지작거리고 있었다. 메타 태그 몇 개만 추가하면 끝나는 간단한 작업이라 가벼운 마음으로 시작했다. 그런데 로컬에서 코드를 수정하고 검증 도구를 돌리는 순간, 예상치 못한 블로거 테마 XML 파싱 에러 메시지가 화면 가득 나타났다.

방금 수정한 부분은 정말 단순한 메타 태그 한 줄뿐이었는데 어디서 스펠링이라도 틀린 건지 등 뒤로 식은땀이 흘렀다. 분명히 문법에 맞춰서 작성했는데 도대체 무엇이 문제였을까. 이번 포스팅에서는 나를 한참 동안 고민하게 만들었던 XML 파싱 에러의 황당한 원인과 해결 과정을 공유해보려 한다.

메타 태그 추가 후 마주한 뜬금없는 XML 에러

디스커버 최적화 작업을 위해 메타 태그를 조심스럽게 삽입하고 코드를 검증하는 과정이었다. 전체 XML 소스를 로컬 파이썬 스크립트의 XML strict parser로 파싱하여 구조적 문제가 없는지 먼저 확인하고 있었다. 그런데 테스트를 실행하자마자 이름도 생소한 구문 에러가 붉은 글씨로 출력되었다.

처음에는 내가 방금 추가한 메타 태그의 닫는 괄호나 큰따옴표가 빠졌나 싶어 소스코드를 몇 번이고 뚫어지게 쳐다봤다. 하지만 수정한 메타 태그 자체에는 문법적으로 아무런 결함이 없었다. 에러가 가리키는 라인도 내가 손대지 않은 완전히 엉뚱한 스타일 시트 영역이었다.

범인은 신규 태그가 아니었다? CDATA 파싱의 함정

원인을 찾기 위해 에러가 발생한 지점을 천천히 뜯어보기 시작했다. 문제가 된 곳은 다름 아닌 Blogger 테마 편집 화면에서 흔히 볼 수 있는 style 태그 내부였다. 블로거 테마에서는 스타일 시트나 자바스크립트를 보호하기 위해 흔히 CDATA로 시작해서 끝나는 주석 형태의 표기를 관행적으로 사용한다.

로컬 검증을 위해 사용한 파이썬의 XML strict parser는 이 변형된 CDATA 표기를 올바른 XML 문법으로 인식하지 못하고 에러를 뿜어냈던 것이다. 즉, 내가 방금 추가한 메타 태그 때문에 에러가 난 것이 아니라, 기존 테마에 이미 존재하던 블로거 특유의 코드 표기법이 엄격한 파서 기준에 걸린 것이었다.

실제 블로거 에디터와 검증 도구의 결정적 차이

여기서 한 가지 재미있는 점은 이 코드를 그대로 복사해서 실제 구글 블로거 테마 에디터에 붙여넣으면 아무런 에러 없이 정상적으로 저장되고 작동한다는 사실이다. 블로거 내부의 자체 런타임 파서는 이 관행적인 CDATA 표기를 아무런 문제 없이 정상적으로 처리하기 때문이다.

결국 내가 마주했던 블로거 테마 XML 파싱 에러는 실제 서비스 구동에는 아무런 영향을 주지 않는 검증 도구 자체의 오작동에서 비롯된 가짜 에러였다. 로컬 검증 도구의 엄격함이 오히려 불필요한 삽질을 유발한 셈이다. 이 사실을 깨닫고 나니 허탈하면서도 한편으로는 안도감이 밀려왔다.

엄격한 파서의 경고에 대처하는 개발자의 자세

웹 개발이나 스킨 커스텀 작업을 하다 보면 검증 도구의 에러 메시지에 지레 겁을 먹고 방금 바꾼 코드만 끊임없이 수정하는 실수를 범하기 쉽다. 이번 디버깅을 통해 깨달은 것은 에러가 발생했을 때 시야를 넓혀야 한다는 점이다. 내가 작성한 최신 코드뿐만 아니라 검증 환경과 실제 실행 환경의 미묘한 파싱 방식 차이도 반드시 염두에 두어야 한다.

앞으로는 로컬 XML strict parser가 뱉어내는 경고에 일희일비하지 않고, 실제 플랫폼이 코드를 어떻게 해석하는지 먼저 크로스 체크하는 습관을 들여야겠다. 나와 비슷한 상황에서 시간 낭비를 하고 있을 다른 블로거들에게 이 짤막한 디버깅 팁이 부디 도움이 되었으면 좋겠다.