🤗 이 글은 누구나 읽을 수 있는 안전한 글입니다.

🙃 무슨 이야기 할거냐?

디시를 스크래핑 하다가 알게 된 사실과 문제점들을 써 보려고한다. 이 글은 디시인사이드에서 게시글을 삭제해도 사실 이미지 URL은 여전히 public하게 접근가능하다는 문제 등과 함께 디시 이미지 서버가 느린 이유에 대해 설명 한다.

몇몇 인터넷 커뮤니티는 유저들의 기호에 따라 디시인사이드의 컨텐츠를 극도로 싫어하지만 좋든 싫든 디시인사이드의 컨텐츠는 명실상부한 대한민국 유행어의 발산지이다. 지역, 정치, 출신 학교 상관 없이 디시가 만든 유행어는 누구나 한 번 쯤 사용했을 거고 알던 모르던 보고 웃고 즐긴다. 꼭 사람이 아니더라도 대기업의 마케팅 문구나 TV 프로그램의 자막 등에 쓰이는 등 디시인사이드의 영향력은 대단하다. 이런 디시인사이드의 컨텐츠는 어떻게 관리 되고 있을까?

🖼 이미지 서버 문제

가장 먼저 눈에 띄는 문제는 디시의 이미지 서버다. 극도로 비효율적으로 운영되고 있을것 같다는 짐작을 뿌리칠 수 없기 때문에 이 부분을 먼저 다뤄보려고 한다.

🤭 실제로는 서버에서 삭제 되지 않는 이미지

디시에 소위 말하는 '야짤'을 올리게 된다면 어떻게 될까? 거의 확실하게 삭제를 당하고야 만다. 그렇다면 야짤은 정말로 디시의 이미지 서버에서 삭제 된 것인가? 그렇지 않다.

아래 링크는 수개월전 디시에서 삭제된 게시물에 첨부되었던 한 이미지의 URL이다. 노출된 사진이므로 주변에 누가 있는지 잘 확인 한 뒤 클릭하길 바란다.

https://images.dcinside.com/viewimage.php?id=??????????&no=??????????

⚠️ 진짜 야짤 링크를 올린건 좀 그래서 삭제 하였음. 아직까지 수백개의 야짤이 접근 가능한 상태임.

비록 게시글이 삭제가 되어서 확인이 불가하더라도 게시글에 남아 있던 디시 이미지 서버의 URL은 여전히 다운로드가 가능한 상태다. 즉 여전히 디시인사이드의 내부 서버에 야짤은 남아 있다는 것이고 public으로 공개 된 상태이다.

이 글을 쓰는 시점에서 8개월 전 삭제 된 야짤의 URL도 여전히 살아 있는걸 확인 할 수 있었다. 만약 이 글을 보고 있는 여러분이 디시에서 삭제한 다른 야짤/혐짤의 URL만 알고 있으면 누구나 볼 수 있다는 이야기다.

아래는 수 개월간 디시인사이드에서 야짤만 스크래핑하며 URL을 수집한 결과이다. 이 글을 쓰는 현 시점까지도 500장이 넘는 야짤들이 여전히 조회되는 상태다. 디시 운영진들에 의해 게시글이 삭제 당하든, 본인이 쓴 게시글을 직접 삭제하던 결과는 마찬가지였다.

⚠️ 이미지에 blur를 걸긴 했지만 blur가 충분히 되지 않아 거의 다 드러나는 형태여서 불쾌하다는 사용자들이 있었습니다. 때문에 자연 풍경 사진으로 대체 합니다.

따라서 게시글이 삭제 되기전에 URL을 기록 해 둔다면 모든 삭제 게시글에 대해 접근 할 수 있다. 다만 누가 이렇게 비정상적인 접근 방식을 사용하겠는가? 하는 의문이 들지만 여러가지 시나리오에 의해 일반적인 사용자들도 삭제 된 이미지의 URL에 쉽게 접근할 수 있고 재배포 될 수 있다.

• 디시인사이드에서 게시글을 삭제하기 전에 web cach server에서 이미지 URL 캐싱해 버린 경우 검색 결과에서 나타 날 수 있음.
• 게시글이 삭제 되기 전에 누군가 다운로드 버튼을 눌렀고 브라우저의 다운로드 히스토리에 저장돼 시간이 지난 뒤에도 공유 할 수 있음.
• 드문 경우지만 게시글 공유를 위해 디시의 게시글을 타 사이트에 재게시 했을 경우 원본이 삭제 되어도 이미지는 계속 보일 수 있음.

🤔 세번째의 경우 디시가 URL을 마구 꼬아놔서 벌어지기 힘들다. 디시에서 이미지 주소를 복사해 보아도 브라우저에서는 빈 화면만 뜨게 될텐데 외부에서 디시의 이미지를 보지 못하도록 viewimage.php에 장난을 쳐 두었다. 그러나 복사한 디시의 URL 중 'image'를 'images'로, 'co.kr'을 'com'으로 고치면 접근이 가능하다.

과거 수많은 '디시 클리너'들이 흑역사(?)를 지우는데 큰 도움을 줘 왔지만 아마 클리너로 지운 게시글 역시 아직 이미지 URL은 Accessible 할 것이다. 물론 그 URL들이 외부에 드러나지는 않으므로 심각한 문제가 될 가능성은 낮아보인다.

게시글의 텍스트는 URL을 알고 있다 할 지언정 "삭제 된 게시글"이라는 경고와 함께 접근이 되지 않지만 어딘가에 유령처럼 둥둥 떠다닐 첨부 파일 이미지들은 여전히 찜찜함을 남긴다.

👎🏻 캐싱이 되지 않는 이미지

디시인사드는 '짤방'이라는 용어를 탄생시켰다. 요즘 10/20대들 대부분은 '짤방'이 정확히 무슨 의미인지 잘 모르고 그냥 '재미있는 이미지'정도로의 의미로 굳어졌지만 '짤방'이란 원래 디시인사이드에서 쓰던 용어이자 개념이었다. 짤방의 어원에 관해서 설명을 하자면 글의 주제와 벗어나기에 더 이상의 자세한 설명은 생략한다.

아무튼 디시인사이드에서는 글을 쓸 때 자동으로 짤방을 첨부 할 수 있도록 하는 기능을 제공 중이다. 한 디시인사드 유저가 작성한 게시글에 첨부된 이미지의 URL을 보면 다음과 같다.

https://images.dcinside.com/viewimage.php?id=2fbcc323e7d334aa51b1d3a24e&no=24b0d769e1d32ca73fed81fa11d0283146878605f8ff89cb706fda048768f60daa764f9a552cb5a643364dfec271c1cc50d0e28da187fbc324560f01ee350c90f6460d14a3ec2b2298ffb5f62ccfb36e8e58b27c3ebd616d082a340f106034187819aeddbb34ae43f7

URL 쿼리 스트링을 보자. 너무 기니까 마지막 5개 정도의 문자열만 보도록 한다. 이 이미지의 no는 e43f7로 끝난다. 해시 값으로 추정되는 문자열이다. 문자열이 애매한 240자인걸로 봐서는 평범한 SHA1이나 SHA256이 아닌 것을 짐작 할 수 있다. 기회가 있으면 이 부분에 대해서도 글을 쓰겠지만 지금은 넘어가자.

쿼리 스트링 중 id의 값인 2fbcc323e7d334aa51b1d3a24e는 갤러리의 해시ID로 추정된다. 만화 갤러리의 경우 2eb2dd2fe6ed36a379ed를 사용하고 있다.

문제는 여기서 시작 된다. 만약 위와 '같은 유저'가 똑같은 짤방을 써서 게시글을 쓴다면 어떻게 될까? 자동짤방 기능으로 인해 같은 이미지가 사용 됐다면? 아래는 실제로 위와 같은 유저가 같은 짤방을 써서 게시글을 썼을 때 해당 글에 포함된 이미지의 URL이다.

https://images.dcinside.com/viewimage.php?id=2fbcc323e7d334aa51b1d3a24e&no=24b0d769e1d32ca73fed81fa11d0283146878605f8ff89cb706fda048768f60daa764f9a552cb5a643364dfec271c1cc50d0e28da187fbc3780d0957ec660997062de7c86994bacdaf4e11f1132c084c57834a5b4269d0a70011b667239a06707b806ae2c099663f8b

링크를 눌러보면 알겠지만 당연히 똑같은 위 연예인의 사진이다. 따라서 같은 이미지니까 당연히 같은 URL이 나와야 하겠지만 이 URL의 경우 no 값은 63f8b로 끝나는 문자열이다. 위의 값과 다른 것이다.

결국 Caching하지 못하고 매번 새롭게 이미지를 로딩하게 된다. 모바일 유저들은 데이터와 배터리를 더 소모하는 상황이 되는 것이다. URL 값이 다르므로 public CDN에서도 각각 캐싱 될 것이다.

![https://velog.velcdn.com/images%2Fmowinckel%2Fpost%2Fab8e0671-6350-4988-ae60-f62a0b29a7b1%2Fcollage.png%5D(https%3A%2F%2Fimages.velog.io%2Fimages%2Fmowinckel%2Fpost%2Fab8e0671-6350-4988-ae60-f62a0b29a7b1%2Fcollage.png)

위 스크린샷은 같은 사진이 첨부된, 같은 유저의 게시글을 각각 조회한 결과다. 다른 이미지들은 모두 캐싱되고 있지만 자동 짤방으로 추가된 이미지는 매번 디시에 request를 보내고 있다.

스크린샷이 잘려 미처 보이지 않았지만 두 request 모두 200 OK 응답을 보내 왔다. 한 번 더 요청을 보내면 놀랍게도 304 Not Modified를 보내준다. 이미지 서버 response header에는 Cache-Control이 없고 ETag만 있다.

최악의 경우가 하나 남았다. 바로 URL이 다른 점을 미루어 짐작컨데 디시인사이드가 같은 이미지라도 중복으로 디스크에 저장하고 있을 수도 있다는 것이다. 하루에도 수천개의 게시물이 올라오는 갤러리의 똑같은 첨부 이미지를 중복 저장한다면? 어쩌면 이것이 디시가 지불하는 서버비용이 기하급수적으로 늘어나는 원인일 수도 있겠다. 만약 그렇다면 브라우저 Local Storage에 Caching도 하지 않을 데이터를 계속해서 생산 해 나가고 있다는 뜻이다.

✂️ 썸네일을 사용하지 않음

위 두 가지 문제와는 달리 비교적 작은 문제다. 디시인사이드는 썸네일을 적극적으로 활용하고 있는 편은 아니다. 디시는 페이지에 접근하면 무조건 '원본' 이미지를 우선 로딩한다. Lazy Loading 따위 역시 하지 않는다. 그렇다면 썸네일은 과연 어디에 있는걸까? 디시에서 썸네일을 찾으려면 바로 metadata를 보아야 한다. 페이지 소스를 열고 meta 태그들을 보면 아래와 같다. 필요한 부분만 볼 수 있도록 좀 편집했다.

    <meta property="og:type" content="website">
    <meta property="og:title" content="집에서 저렴하게 록맨 코스프래 한거 올려봄. - HIT 갤러리">
    <meta property="og:description" content="바야흐로 서기 20XX년 세계는 인간과 로봇이 서로 행복하게 공존을 하고 있었다.하지만 세계 정복을 꿈꾸던 닥터 ">
    <meta property="og:image" content="<https://write.dcinside.com/viewimage.php?id=hit&no=24b0d769e1d32ca73ced80fa11d02831208acfae4be8406aea1df201c6adc8aedde864b3f6d74a409644c6bb9e2d6d3de6447e0185deb7ecfc5999699b6582c643ea6dda92e32a>">
    <meta property="og:url" content="<https://gall.dcinside.com/board/view/?id=hit&no=15777>">
    <title>집에서 저렴하게 록맨 코스프래 한거 올려봄. - HIT 갤러리</title>

바로 여기서 오픈 그래프 태그에 해당하는 og:image가 디시인사이드 컨텐츠의 유일한 썸네일이다! 해당 URL을 다운로드 해 보면 저 게시글의 첫번째 이미지의 썸네일을 볼 수 있다. 하지만 이 metadata는 웹 페이지를 로드 할 때 쓰이지 않는다. 사용자가 볼 일도 없다. 그렇다면 과연 이 URL은 어디에 쓰이는 걸까?

![https://velog.velcdn.com/images%2Fmowinckel%2Fpost%2F48af7d53-872a-40b3-a890-7dd49c55b60d%2F%EC%8A%A4%ED%81%AC%EB%A6%B0%EC%83%B7%202020-04-30%20%EC%98%A4%ED%9B%84%206.49.41.png%5D(https%3A%2F%2Fimages.velog.io%2Fimages%2Fmowinckel%2Fpost%2F48af7d53-872a-40b3-a890-7dd49c55b60d%2F%EC%8A%A4%ED%81%AC%EB%A6%B0%EC%83%B7%202020-04-30%20%EC%98%A4%ED%9B%84%206.49.41.png)

그것은 바로 카카오톡과 같은 메신저에서 디시인사이드의 URL을 붙여 넣기 했을 때 뜨는 미리보기 이미지에 사용된다. 더 자세한 내용은 페이스북이 만든 📎 Open Graph Markup을 보자.

위 처럼 디시인사이드는 썸네일을 보유하고 있음에도 불구하고 적극적으로 쓰는 편은 아니다. 더 재미있는 것은 썸네일이 가장 필요한 모바일 페이지에는 해당 meta 태그를 찾아 볼 수 없다는 점이다. 오히려 Lazy Loading이 가장 절실한 모바일 페이지의 img 태그는 아래와 같이 구성 되어 있었다.

<img src="<https://dcimg7.dcinside.co.kr/9f3c5ba3bf>"  
data-original="<https://dcimg7.dcinside.co.kr/9f3c5ba3bf>" 
alt="9f3c5ba3bf"
class="lazy">

URL의 길이가 너무 길어 보기 불편할까봐 앞부분은 임의로 잘라 냈다. img 태그의 class는 나름 lazy로 되어 있어 lazy loading을 구현 해 놨으나 src, data-original, alt까지 모두 같은 URL이다. 단지 늦게만 로딩할 뿐 어차피 다 똑같은 원본을 로딩 할 수 밖에 없는 운명인 것이다.

디시는 나름대로 오픈 그래프 프로토콜에 metadata를 잘 기술 해 두었다. 따라서 썸네일을 만들 능력이 없는 것이 아니다. 디시인사이드 이미지의 원본과 썸네일의 크기를 비교 해 본 결과 디시인사이드가 사용중인 썸네일의 크기는 원본의 15%에 불과 했다. (원본 93KB, 썸네일 14KB) 대략 85%의 이미지 트래픽을 줄일 수 있다는 이야기다. 보다 적극적으로 썸네일을 도입하고 Cache Control까지 한다면 디시가 크게 빨라질 수 있지 않을까?

🤔 디시는 STON Edge라는 Content Caching Server를 사용중인데 이 서버는 image crop, resize등을 지원하며 on-fly로 썸네일을 제공 할 수 있다. 왜 이 기능을 사용하지 않는건지 잘 모르겠다.

디시에서는 오래전 부터 '이미지 미리보기' 기능이 추가 됐으면 한다는 유저들의 요구가 끊임 없이 있어왔다. 이름이 '갤러리'인데도 불구 디시는 아직도 게시판을 텍스트 리스트 형식으로만 볼 수 있다. 개인적인 추측인데 디시는 아마 썸네일을 도입하기 어려운 상황이고, 캐싱도 하지 못하고 있는 상황이라 수십장의 이미지를 로드 시키는 '이미지 미리보기'를 서비스 하기엔 아직 자신이 없는 상황이 아닐까 생각 해 본다. 이 상황에서 이미지 수십장을 미리보기로 띄운다면 이미지 서버가 죽는 것은 시간 문제이긴 하다.

여전한 Gif 포멧

또 다른 문제는 디시인사이드는 여전히 Gif 포멧을 사용중이라는 것이다. 사실 Gif를 쓴다는것 자체를 문제 삼기에는 지나친것 같아서 쓰지 않으려 했으나 짧게만 메모해 두려고 한다.

Gif 포멧은 그다지 효율적이진 않다. Gif는 여러장의 이미지를 저장 해 두었다가 차례대로 보여주는 방식인데 이 때 GPU 가속을 사용하지 않고 오직 CPU만을 사용해서 여러 장의 Gif를 반복 재생하면 CPU 점유율이 매우 높아지는 문제가 있다. 때문에 요즘은 사용자가 gif를 업로드 하더라도 mp4로 인코딩하여 HTML5 video 태그로 재생하는 것이 추세이다. 대표적으로 트위터가 그렇다. Gif와 mp4의 오버헤드 비교는 좋은 글들이 많아 두 가지를 남겨둔다.

📎 GIF 사용을 멈춰주세요!
📎 Replace Animated GIFs with Video

내용은 gif는 mp4에 비해 용량도 크고 배터리 소모만을 늘리는 아주 몹쓸 포멧이라는 것이다.

As you can see in the above figure, image decodes occurs on the rasterizer threads as each new frame of the GIF is decoded.

Gif의 매 프레임마다 image decode가 Rasterizer thread에서 발생하고 있다.

디시는 오직 움짤만을 올리는 '싱글벙글 지구촌'이라는 곳이 있을 정도로 많은 유저들이 움짤을 좋아하는 곳이다. 앞서 살펴본 것과 같이 디시가 게시글을 삭제해도 실상 이미지는 삭제하지 않는다는 점을 생각 해 보자. 적게는 수 MB에서 많게는 수십 MB에 달하는 고용량의 gif도 삭제하지 않는다는 것은 스토리지 부담이 누적 될 수 있음을 시사한다.

그렇지만 커뮤니티를 운영하는데 있어 gif를 mp4로 인코딩하거나 web에 embed 시키는건 매우 귀찮은 일이다. 인코딩 역시 비용이 드는 일이고 video 태그를 써야 하는 등 아무튼 귀찮다 이거다. 요즘 추세가 mp4라는 말을 했지만 Giphy나 Imgur는 여전히 gif 포멧을 사용하고 있다. 거기엔 비밀이 있는데 이 서비스들의 gif는 진짜 gif가 아니다. imgur는 아예 gif 포멧을 새로 정의 해서 Gifv라는 것을 만들었다.

📎 introducing gifv

이렇게 내가 생각하는 디시인사이드의 크고작은 문제 네가지 정도를 살펴 보았다.

🤔 결론

그냥 디시인사이드 이미지 서버는 비효율적이라는 것뿐이다. 악용의 소지도 크다. 불법 이미지를 어딘가 저장 해 두고 싶을 때 디시는 감추기 딱 좋은 장소가 될 수 있다. 디시인사이드는 사실상 무한 용량의 무료 클라우드를 운영하고 있는 셈이다.

이미지를 캐싱하지 않는데다가 가능성은 낮지만 중복으로 저장하는 건 아닐까 하는 의심이 남아 있다. 정리하자면 아래와 같다.

• 게시글은 삭제되더라도 이미지 URL은 살아 있다. 즉 디시 내부 이미지 서버에서는 여전히 저장중이고 삭제하지 않는다. 누구나 접근이 가능하다.
• 똑같은 이미지라도 URL이 다르고 response 헤더에 Cache-Control 없어 브라우저가 로컬 스토리지에 캐싱하지 못하고 있다. 데이터 사용량이 증가하고 배터리 역시 영향 받는다.
• 똑같은 이미지가 매번 중복으로 디시 이미지 서버에 저장 되어 있을 가능성이 있다.
• 썸네일 없이 항상 원본 이미지 데이터를 로딩 중임.

글에서는 디시인사이드만을 언급했지만 실상은 디시인사이드 뿐만이 아니라 수 많은 국내 커뮤니티들이 이와 같은 문제를 품고 있다. 원래 만들어진 사이트의 단점을 두들겨 패고 비판하는 것은 쉽다. 그러나 그 사이트를 제대로 만들고 운영하는 것은 아주 어려운 일이다. 이미지 캐싱은 정말 어려운 문제고 특히 http 헤더의 캐싱 관련한 필드 개수를 보면 아마 깜짝 놀랄 것이다. 누군가에겐 도움이 됐을 글이길 희망하며 끝낸다.

📘 더 읽어 볼 거리

• 📎 Prevent unnecessary network requests with the HTTP Cache