사진: Олег Мороз / Unsplash

서론

마이클 할리(Michael Harley)가 며칠 전 How I make my blog posts more resilient이라는 글을 썼다. 블로그는 물론 거의 모든 웹사이트를 운영하는 데 도움이 되는 좋은 아이디어와 원칙을 많이 다룬다. 그의 글을 읽다 보니 거의 10년 전 내 사이트 중 하나에서 겪었던 꽤 큰 사건이 떠올랐다.

당시에는 문제를 전반적으로 기록하긴 했지만, 내가 겪어야 했던 문제 중 하나인 망가진 서드파티 임베드에 대해서는 일부만 언급했다. 내가 겪은 문제와 그 대처 방식을 이야기하는 것이 마이클의 글에 어울리는 짝을 이루는 글이 될 것 같았다.

사건의 발단

2018년에 나는 The CerebralRift에 여러 가지 변화를 줘야 했다. (이 변화들에 대한 자세한 내용은 2018년에 올린 글들에서 확인할 수 있다: CerebralRift Goes KABOOM!, Extreme Website Cleaning, The Long Grind Aftermath 그리고 A Pair Of Post Cleanup Rants. 하지만 읽어보길 권하지는 않는다. 길고 투덜대는 투에, 그럭저럭 지루하기까지 하다.) 여기서는 그중 한 부분을 원래 글에서보다 더 자세히 다뤄보려 한다.

변경을 진행하면서 사이트에 여러 문제가 있다는 걸 알게 됐다. 변경을 하면 할수록 문제는 오히려 악화됐다. (변경의 상당수는 콘텐츠를 옮기거나 삭제하는 것이었기 때문에 상황이 악화된다는 건 직관에 어긋나 보였다.) 곧 문제를 해결하려면 더 깊이 파고들어야 한다는 걸 깨달았다.

발견한 내용

내가 발견한 문제 중 하나는 사이트에서 임베드를 사용한 방식과 관련이 있었다. 내가 썼던 대부분의 리뷰(약 350개)에서 리뷰의 일부로 해당 음반을 임베드하곤 했다. 대부분 독자를 위한 배려였다. 리뷰 대상을 직접 듣거나 볼 수 있게 하고 싶었다.

하지만 원본 음원이 이동하거나 인터넷에서 사라졌을 때, 이 임베드 중 상당수가 우아하게(gracefully) 실패하지 않는다는 걸 알게 됐다. 우아하게 실패한다는 건 무슨 뜻일까?

호출될 때 임베드는 전달받은 URL이나 URI가 유효한지 확인할 수 있어야 한다. 유효하지 않다면 임베드는 실패해야 한다. 하지만 이 임베드들 중 상당수는 그렇게 동작하지 않았다. 대신 두 가지 중 하나가 일어났다.

1. 임베드가 계속 로딩을 시도하면서 웹페이지가 끝내 완전히 로드되지 못했다.
2. 임베드는 로드됐지만, 잘못된 형식의 URI를 12~16개나 만들어냈다.

이는 내 사이트의 성능과 많은 검색 엔진이 사이트를 평가할 때 매기는 점수에 영향을 미쳤다(그렇다, 당시 나는 SEO 원칙을 다루고 있었다 — 하지만 지금은 좀 나아졌다). 멈춘 임베드는 극도로 긴 로드 시간으로 집계됐다. 그리고 잘못된 형식의 URI들은 끊어진 링크처럼 보였다. 기본적으로 이런 끊어진 링크들은 SEO 점수뿐만 아니라 사이트를 운영할 때 반드시 지켜봐야 할 순수한 기술적 지표까지 엉망으로 만들고 있었다.

하지만 나는 또 다른 걱정이 있었다. 제대로 동작하지 않는 이 임베드들이 공격 표면으로 악용될 수 있지 않을까 하는 점이었다. 직감으로는 서버 자체에는 문제가 되지 않을 것 같았지만, 내 사이트 이용자들에게는 취약점이 될 수 있었다. 그래서 워낙 의심이 많은 나는 이 망가진 임베드들을 보안 문제로 간주했다. (솔직히 이 문제로 꽤 오래 고민했고, 망가진 임베드를 이용해 내 서버까지 침투할 방법이 있지 않을까 생각하기도 했다. 그냥 내 편집증 증상일 뿐이다.)

대응 방법

무엇을 했는지는 꽤 분명하다고 생각한다(특히 위에 언급한 글들을 읽어봤다면). 나는 사이트에 게시된 400개가 넘는 글을 하나씩 체계적으로 점검해 나갔다. (리뷰 외에도 더 많은 글이 영향을 받았다.) 그 과정에서 필요한 글은 모두 업데이트하고 새로 고쳤다.

긴 과정이었다. 모든 것을 정리하는 데 문자 그대로 며칠이 걸렸다. 그 과정에서 앞으로 어떻게 운영할지 많은 고민을 했다.

새로운 원칙

정말 특수한 이유로 반드시 사용해야 하는 경우가 아니라면, 서드파티 임베드는 더 이상 내 사이트에서 환영받지 못한다. 거의 10년이 지난 지금까지 그런 이유를 찾은 기억이 없다.

당시에는 고려하지 못했지만 지금 보면 관련 있어 보이는 것이 또 하나 있다. 우리는 예전부터 이 임베드 중 상당수가 우리 시스템에서 상태를 추적하기 위해 쿠키를 사용해야 한다는 것을 알고 있었다. 하지만 우리 중 누구라도 이 임베드들이 실제로 무엇을 하고 있는지 정말로 알까? 이들이 우리 시스템에 비콘 쿠키나 다른 교차 사이트에서 접근 가능한 데이터를 심고 있을 가능성은 충분히 있다.

그리고 내가 아는 한(틀렸다면 바로잡아 달라), 임베드가 할 수 있는 일을 규제하는 GDPR에 준하는 규정은 없다. 그 생각을 하면 조금 불안해진다.

그렇다고 내 사이트에서 미디어를 찾을 수 없다는 뜻은 아니다. CerebralMix Archive가 좋은 예다. 대부분의 페이지에 미디어 플레이어가 있다. 하지만 그 미디어 플레이어는 순수 HTML5 코드로 만들어졌다. 어떤 이유로든 실패하면 오류 메시지를 표시하도록 구성되어 있다. 그리고 미디어를 직접 다운로드할 수 있는 독립적인 링크도 여전히 제공되므로, 플레이어가 실패하더라도 사용자가 미디어에 접근할 수 있다.

웹사이트에 리치 미디어를 넣는 것이 오히려 당연한 시대에 이런 원칙은 뒤처져 보일 수도 있다. 하지만 솔직히 말하면, 덕분에 사이트 유지 관리가 훨씬 쉬워졌다. 그리고 웹사이트에 시한폭탄을 안고 있지 않다는 것을 아니 조금 더 마음 편히 잠들 수 있게 됐다.