브런치는 작가의 아카이브가 아니다

플랫폼에 올렸으니 내 글은 안전하겠지?

by 마봉

백업 - 아무리 강조해도 지나치지 않습니다

브런치 들어온 지 8개월 된 이 시점에서 바야흐로 백업에 대한 이야기를 할 때가 온 것 같다. 백업이란 무엇인가? 원본을 하나만 두지 않고 안전하게 한 벌 더 만들어 놓는 것이다.


나처럼 일단 브런치 글쓰기 눌러서 초고부터 쓰는 사람들이 생각보다 꽤 되는 것으로 안다. 메모장이나 MS 워드, 한글 등에 먼저 쓰고 브런치에 옮기는 것이 습관이 된 작가들은 이런 걱정 안 해도 될 것이다. 하지만 나의 경우 지속적으로 수정과 퇴고가 필수인 소설에 한해서만 MS 워드 원본을 따로 갖고 있고, 기타 여행기를 포함한 비소설류는 브런치에 바로 대고 쓴 글이다.


그래서 이제 문제가 눈에 보이기 시작한다. 브런치에 바로 쓴 글들은 브런치 자체가 원본이고 세상에 하나뿐이다. 내 글은 과연 브런치 안에서 안전한가? 영원히 보존되는가?


브런치가 곧 망할 테니 빨리빨리 백업하고 이삿짐 싸세요,라고 말하는 것이 아니다. 이 세상에 영원한 것은 없고('다이아몬드는 영원하다'라는 카피문구는 생각하지 말자. 왜냐면 설령 다이아몬드가 영원한 것이 맞다 해도 도둑놈이 집어가면 나에게는 더 이상 영원하지 않으니까) 이것은 디지털 세상에서도 예외는 아니다. 물론 물성을 지닌 것보다는 데이터가 도난과 파괴에 상대적으로 안전한 것은 사실이다.


그럼, 플랫폼을 원본으로 사용하는 것이 얼마나 위험한지 한번 확인해 보도록 하자. 물론 브런치는 카카오 계열사다. 설마 대기업 카카오가 내 글을 날려먹겠어? 특히 카카오는 2022년 판교 데이터센터 화재로 아주 호되게 당한 후, 뼈를 깎는 수준으로 시스템 다중화 작업을 거쳤다. 현재 브런치의 데이터는 내가 그 회사 사람이 아니라 모르지만 아마 대략 이렇게 안전하게 관리되고 있을 것이다.


1. 원고 및 텍스트 데이터(DB 이중화)

텍스트 형태로 된 글들은 영상이나 이미지에 비해 용량 자체가 아주 가벼운 편이다. 그래서 메인 데이터베이스(DB)에 글이 저장됨과 동시에, 물리적으로 멀리 떨어진 지역(판교나 안산 등) 데이터센터의 DB로 실시간 동기화가 이루어질 것이다. 한쪽 데이터센터가 통째로 셧다운 되어도 다른 쪽에 최신 글이 살아 있는 것이다.


2. 이미지 및 첨부 파일(분산 오브젝트 스토리지)

글에 들어간 이미지들은 DB가 아니라 '오브젝트 스토리지'라는 클라우드 창고 시스템에 들어갈 것이다. 이 클라우드는 데이터를 잘게 쪼개서 여러 대의 서버와 지역에 3-4중으로 복사본을 뿌려 저장하는 구조다. 그래서 특정 하드디스크 몇 개가 아작이 나도 파일이 깨지는 일은 거의 없다.


즉 카카오가 아예 문을 닫거나, 정으니가 쳐들어와 카카오 데이터센터만 쏙쏙 골라서 죄다 뿌셔버리거나, 소행성이 떨어져 지구 자체가 멸망하지 않는 한 브런치에서 원고가 통째로 증발할 확률은 거의 0에 가깝다.


그럼 안전하다는 거잖아요 왜 지랄이셈?

위에 열거한 것들은 모두 불가항적인 요소들이다. 정으니, 소행성, 천재지변. 그리고 여기에 추가로 대량 해킹 사태라던가 시스템 오류 문제가 추가된다. 전쟁 수준의 대재앙이 아니라도 '무조건 100% 안전한 시스템'은 세상에 존재하지 않는다. 브런치가 아무리 백업과 이중화 대비를 훌륭하게 해 뒀어도, 서비스 제공자의 잘못으로 데이터가 날라갈 확률은 0%이 아니다.


■ 확률 1. 소프트웨어 버그

물리적인 데이터센터 화재에는 대비되어 있어도 '잘못된 코드' 앞에서는 속수무책이다. 내부에서 치명적인 버그가 포함된 시스템 업데이트가 배포돼서 데이터가 꼬이거나 지워지는 명령이 실행된다면? '실시간 동기화' 시스템 덕분에 보조 서버 데이터까지 싹 다 날라갈 수 있다.


에이 그래도 네카라쿠배(네이버 카카오 라인 쿠팡 배민) 중 하나인 카카오에서 제일 잘 나가는 개발자들과 엔지니어들이 관리할 텐데 그런 일이 생기겠어요?


■ 확률 2. 서비스 종료

유저가 줄어들거나, 회사 정책이 바뀌면 어떤 서비스든 종료될 수 있다.


에이 그래도 부잣집 망해도 3년은 먹고산다고, 다른 데도 아니고 카카오인데, 서비스 종료될까? 그리고 서비스 종료되면 적어도 백업서비스까지 해주고 문 닫겠죠.


과연 그럴까? 그럼 얘기 나온 김에 플랫폼만 믿고 있던 유저들의 데이터가 허공으로 증발해 버린 대참사에 대해서 알아보도록 하자.


마이스페이스(Myspace) 데이터 증발 (2019년)

페이스북 이전에 전 세계를 휩쓸었던 이 플랫폼은 서버 이전 작업을 하다가 무려 12년 치(2003~2015년) 음악과 사진 5,000만 개를 싹 다 날려먹었다. 백업본조차 없어서 수많은 사람의 흑역사와 추억이 그대로 영구 삭제되었다.

프렌드스터(Friendster) 강제 폐기 (2011년)

한때 아시아권에서 국민 SNS로 불리던 이곳은, 게임 플랫폼으로 업종을 바꾸면서 유저들이 올렸던 사진과 글 데이터를 특정 날짜 이후 서버에서 몽땅 지워버렸다. 휴면 메일이라 공지를 못 본 수많은 사람의 청춘 기록이 강제 폐기되었다.

이글루스(Egloos) 서비스 종료 (2023년)

한국 1세대 블로그의 상징이었던 이글루스도 결국 문을 닫았다. 백업 유예 기간을 주긴 했지만, 뒤늦게 소식을 들었거나 휴면 메일 계정을 사용하는 바람에 타이밍을 놓친 사람들의 10년, 20년 치 방대한 글과 자료들이 인터넷 세상에서 흔적도 없이 소멸해 버렸다.


■ 확률 3. 내부자 소행, 혹은 외부 침입

최고 접근 권한을 가진 시스템 관리자가 고의로 메인 저장소와 오프라인 백업 스토리지까지 싹 다 포맷해 버리면 회사 차원에서도 복구 방법이 없다. 관리자 계정이 해킹당해 랜섬웨어로 전체 백업망이 접근 불가하도록 암호화되는 경우도 마찬가지다. YES24 사태를 기억하시는 분들 있으시겠지만 랜섬웨어라는 것은 한번 걸리면 자체 복구가 거의 어렵다. 결국 YES24 같은 큰 회사도 해커한테 돈 뜯기고 겨우 복구했다. 심지어 저 집 랜섬웨어 맛집이라고 소문나서 2차 공격까지 당했다.


사이버 세계는 총알과 미사일만 안 날라다니지 이미 치밀한 공격과 방어의 세계이다. 모든 회사들이 보안 솔루션을 억 단위 돈 주고 사다 쓰는 이유가 다 있다. 물론 우리 사용자 입장만 생각한다면 브런치가 랜섬웨어 공격을 당해도 카카오가 해커한테 돈만 주면 우리 데이터는 보존이 될 테니 걱정 없겠네? 뭐가 문제람?


놉놉 범죄자가 달리 범죄자가 아닙니다. 돈만 받고 먹튀 하는 해커들도 있고 해커가 암호 해독 키를 줬다 하더라도 그 키에 버그가 있어서 데이터 깨지는 경우도 있다. 보안 업계 통계에 따르면 돈을 주고 복구 키를 받아도 평균 60~80%의 데이터만 살릴 수 있고 나머지는 날아간다고 한다.


뿐만 아니라. 해커가 복구 키에 백도어를 심어 두고 감으로써 지들이 돈 필요하면 또 와서 털 수 있게 개구멍을 남겨놓기도 한다. YES24 2차 사태의 경우는 아마도 이렇게 발생했을 확률이 높다. 그래서 보안 전문가들은 '랜섬웨어 해커들에게는 절대 협상하지 말고 돈도 주지 마라'라고 경고한다.


설령 그런다 하더라도 브런치 측에서 책임지지 않겠음?

모든 회사는 이런 일에 대비해서 반드시 면피 조항을 만들어 둔다. 카카오 이용약관을 보도록 하자.

제16 조 (손해배상)

①회사는 법령상 허용되는 한도 내에서 서비스와 관련하여 본 약관에 명시되지 않은 어떠한 구체적인 사항에 대한 약정이나 보증을 하지 않습니다. 또한, 회사는 CP(Contents Provider)가 제공하거나 회원이 작성하는 등의 방법으로 서비스에 게재된 정보, 자료, 사실의 신뢰도, 정확성 등에 대해서는 보증을 하지 않으며, 회사의 과실 없이 발생된 여러분의 손해에 대하여는 책임을 부담하지 아니합니다.

②회사는 회사의 과실로 인하여 여러분이 손해를 입게 될 경우 본 약관 및 관련 법령에 따라 여러분의 손해를 배상하겠습니다. 다만 회사는 회사의 과실 없이 발생된 아래와 같은 손해에 대해서는 책임을 부담하지 않습니다. 또한 회사는 법률상 허용되는 한도 내에서 간접 손해, 특별 손해, 결과적 손해, 징계적 손해, 및 징벌적 손해에 대한 책임을 부담하지 않습니다.

1. 천재지변 또는 이에 준하는 불가항력의 상태에서 발생한 손해
2. 여러분의 귀책사유로 서비스 이용에 장애가 발생한 경우
3. 서비스에 접속 또는 이용과정에서 발생하는 개인적인 손해
4.제3자가 불법적으로 회사의 서버에 접속하거나 서버를 이용함으로써 발생하는 손해
5.제3자가 회사 서버에 대한 전송 또는 회사 서버로부터의 전송을 방해함으로써 발생하는 손해
6.제3자가 악성 프로그램을 전송 또는 유포함으로써 발생하는 손해
7.전송된 데이터의 생략, 누락, 파괴 등으로 발생한 손해, 명예훼손 등 제3자가 서비스를 이용하는 과정에서 발생된 손해
8. 기타 회사의 고의 또는 과실이 없는 사유로 인해 발생한 손해


즉 위와 같은 일로 인해서 브런치 글이 싹 날라간다 하더라도 카카오는 배상해 줄 의무는 없다. 물론 최선을 다해 데이터를 복구하고 정 복구 안되면 도의적인 책임을 지며 배상을 할 수는 있겠지. 하지만 날라간 글은 살릴 수 없을 수도 있다. 카카오 개발자가 아니라 개발자 할아버지라도 어쩔 수 없는 건 어쩔 수 없다.


아악, 무서워! 그럼 제 글은요?

자, 그러니까 백업합시다. 세상 어찌 될지 모르니까 여러분도 없는 살림에 약간이라도 저축하고 보험도 들고 그러는 거잖아요? 그럼 소중한 내 글 백업도 없이 브런치에 실어놨다가 브런치 접속 안되면 그땐 어쩌실 건데요? 머릿속에 다 있어서 괜찮아요? 와 부럽다. 일단 난 아님.


자자, 백업 방법 알아봅시다. 컴맹이세요? 괜찮아요 저도 컴맹임. 에브리데이 문송한 문과입니다. 따라오세요.


1. 누구나 아는 그 방법 - 드래그 & COPY & PASTE

글 하나씩 열어서 다 드래그 & 카피 앤 페이스트 해서 메모장이나 워드에 붙여 넣어 저장하는 방법이다. 아이고 손목이야. 나 죽네. 네, 언젠가 다른 플랫폼에도 올릴 생각 하면 이 방법이 제일 원초적입니다.


내 글은 260개나 되는데 어쩐담. 발행 취소한 글까지 더하면 300개쯤 되는데 아이고아이고 내 손목이야. 더 쉬운 방법 없나요?


2. html로 떠놓기(글 한 개씩 한 땀 한 땀)

html은 웹 페이지 모양 그대로 이미지까지 다 떠 놓는 방식이다. 일단 브런치의 내 글 아무 페이지나 가서 우클릭을 하면 이런 화면이 뜬다.

웹 페이지에서 우클릭하면 뜨는 팝업창

여기에서 '다른 이름으로 저장'을 선택하면 브런치의 내 글을 html 형식으로 이미지까지 레이아웃 그대로 유지한 채 저장해 준다. 이렇게 저장된 html 페이지는 내 PC 로컬에 저장되므로 오프라인 상태(인터넷 연결 안 된 상태)에서도 더블클릭하면 마치 브런치에 접속된 것처럼 내 글을 웹페이지 상태 그대로 보여준다.

다른 이름으로 저장하려고 하면 옵션 3개 나오는 파일 탐색기창

어! 웹 페이지 종류 3개 뜨는데 이중에 뭘로 해야 하죠?


□ 웹 페이지, HTML만 가능 (Webpage, HTML Only)

웹 페이지에서 글자(텍스트)만 쏙 뽑아다 저장한다. 삽화, 폰트, 배경색 같은 건 다 무시한다.


□ 웹 페이지, 단일 파일 (Webpage, Single File)

글, 이미지, 디자인 요소(CSS)를 .mhtml(또는 .mht)이라는 확장자를 가진 1개의 파일에 뭉쳐서 압축 저장해 준다. 파일이 글 하나당 하나만 생성돼서 관리하기 편하다.


□ 웹 페이지, 완료 (Webpage, Complete)

화면에 보이는 그대로를 아주 정직하게 저장하는 방식. 글이 담긴 html 파일 1개와 이미지, 디자인 소스가 같이 들어있는 폴더 1개가 세트로 저장된다.

html + 이미지와 디자인 소스 폴더 같이 저장된 모습

장점: 원본 이미지만 따로 빼서 쓰려면 이 방식이 좋다(글도 이미지도 따로 저장 안 해놓는 사람에게는 이 방법도 괜찮음)

단점은, 백업한 글을 다른 폴더로 옮길 때 꼭 html 파일과 폴더를 세트로 같이 옮겨야 한다는 점이다. html만 다른 데로 옮기거나 이미지 폴더만 다른 데로 옮기면 나중에 열어보면 이미지 안 보임.


3. 싱글파일(SingleFile) 확장 프로그램 사용하기

백업할 글이 많고, 지금 당장 텍스트로 긁어 붙여 넣기까지는 안 해도 되거나, 혹은 이미지 포함한 페이지 레이아웃 그대로 저장하고 싶은 사람에게는 이 방법이 최적이다. 광고 아니니까 걱정 말고 끝까지 읽자.


□ 싱글파일이란?

브라우저(엣지, 크롬 등)에서 설치하기만 하면 열어놓은 웹 페이지 그대로 저장해 주는 브라우저 확장 프로그램이다.


어어 이거 깔면 또 뭐 막 빼가고 그러는 거 아니에요? 백업하려고 했는데 이상한 악성코드 막 심고, 등등등. 무쪄웡!


크롬 웹스토어 같은 공식 스토어에서 정품만 설치하면 문제없다. 유명한 프로그램이다 보니 이름이나 아이콘을 교묘하게 따라한 가짜 악성 프로그램들이 올라올 때가 있으니 설치할 때 제공자(제작자) 이름이 'Gildas Lormeau'로 되어 있는지만 확인하면 된다. 링크는 아래와 같다.


크롬 웹스토어

https://chromewebstore.google.com/detail/singlefile/mpiodijhokgodhhofbcjdecpffjipkle

엣지 웹스토어

https://microsoftedge.microsoft.com/addons/detail/singlefile/efnbkdcfmcmnhlkaijjjmhjjgladedno

원작자 Gildas Lormeau의 깃허브(Github)

https://github.com/gildas-lormeau/SingleFile

파폭, 엣지, 사파리용 정식 링크도 다 여기 들어있음


□ 싱글파일 다운로드와 설치

링크를 누르면 저렇게 '다운로드' 버튼이 보인다.

싱글파일 공식 웹스토어(엣지)

걔를 누른다


그럼 "Microsoft Edge에 "SingleFile"을(를) 추가하시겠습니까?"하고 물어본다.

'확장 추가'를 누른다.

Microsft Edge에 SingleFile 을 추가하시겠습니까? 확장 추가 / 취소

브라우저 우측 상단에 무슨 깨진 팩맨같이 생긴 아이콘이 있는데(원래 있다) 걔를 눌러보면 방금 설치한 SingleFile 확장자가 설치되었음을 알 수 있다.

브라우저에 확장자 설치된 화면

□ 싱글파일로 브런치 글 떼로 백업하기

자, 설치 끝났다. 이제 백업을 시작하자. 브런치에서 글 하나씩 백업하는 방법은 위에 써놨는데, 이제 탭 여러 개를 사용해서 브런치 매거진 하나를 한방에 백업하려면 어떻게 해야 할까?


일단은 브런치 매거진이나 브런치북 하나를 각각의 탭으로 다 열어야겠지. 그런데 브런치 안에서 링크를 누르면 새로운 탭이 생성되는 게 아니라 이미 열려 있는 탭 안에서 새로운 글이 열린다. 우리 컴맹들 당황스럽다. 이럴 때는 어떻게 해야 할까? 결국 글 하나씩만 백업해야 하나?


노놉 우리 게으른 자들 그렇게 살지 않는다. 일단 매거진이나 브런치 북 메인 페이지를 연다. 링크들이 쭉~ 나열되어 있으면 아래 방법으로 새로운 탭에서 내 글들을 열 수 있다.


링크 위에 마우스를 올리고 마우스 휠(가운데 버튼)을 누른다.

혹은 Ctrl + 마우스 좌클릭해도 새로운 탭으로 뜬다.

혹은 링크 우클릭하고 '새 탭에서 링크 열기'를 선택한다.


이렇게 해서 내 매거진/브런치 북 글을 모두 개별 탭으로 열어놓고 이제 싱글파일을 돌린다.


아까는 없었는데, 이제 페이지 우클릭하면 파랑+노랑 아이콘으로 'SingleFile'이라는 애가 한 줄 더 생겨 있다. 그 아래 하위 메뉴로 'Save all tabs'라는 것이 보이면 얘를 누른다.

페이지에서 우클릭해서 SingleFile > Save All Tabs 선택하는 화면

탭을 여러 개 열어 놨다면 저장하는데 시간이 걸리니까 그동안 스쿼트라도 하면서 기다리도록 하자.

싱글파일이 열심히 저장 작업 진행중

잠시 후 '다운로드' 폴더를 열어보면 이렇게 html 파일로 브런치북 한 회차당 한 페이지로 저장이 되어 있다.

글 1개당 1개의 html 파일로 다운로드 폴더에 저장되어 있다

여기서 주의할 것은 그냥 저장만 하면 댓글/답글이 저장되지 않으니까 댓글/답글까지 저장하고 싶다면 반드시 스크롤 다운 끝까지 해서 댓글과 답글까지 다 페이지에 뜨는 것을 확인한 다음 Save all tabs를 하도록 하자. 댓글과 답글이 자동으로 저장되지 않는 이유는, 글은 고정된 데이터라 브라우저가 저장하기를 누르면 바로 잡히지만, 댓글은 스크롤을 다 내린 다음에(혹은 댓글보기를 눌렀을 때) 브라우저가 자바스크립트로 그제서야 댓글을 가져와 보여주기 때문이다.


백업 다 하면 이제 뭘 할까?

백업을 자기 PC에 저장하는 것으로 끝나면 그것은 백업이 아니다. 백업은 로컬(자기 PC)과 클라우드 양쪽에 해야 한다. 가장 좋은 것은 로컬, 클라우드, 외장하드 3개로 굴리는 것이다. 오바한다 염병한다 생각될 수도 있지만 세상에 완벽한 백업이란 없으며 그나마 완벽에 가까운 백업이란 이렇게 3개로 굴리는 방법이다.


클라우드가 영원한가? 아니지, 클라우드 서비스도 종료하면 땡이다. 로컬이나 외장하드도 마찬가지다. 외장하드는 오래되면 갑자기 데이터 못 읽고 버벅거리다가 못읽겠어욤~ 하고 뻗을 수도 있다. 내 PC는? 알면서 왜 이래. 이제까지 컴퓨터 안되면 다 사람 불렀지 니가 직접 했어? 닥치고 빨랑 삼중백업하자.

형제 여러분, 백업하십시오. 로컬에도 백업하고 클라우드에도 백업하고 외장하드에도 백업하십시오. 백업만이 너희를 구원하리라. 아멘.
형제님들, 백업하십시오! 백업교 수도사가 한 손에는 외장하드, 한 손에는 구글/아이클라우드 상징물을 들고 무릎꿇고 있다


매거진의 이전글브런치의 아키텍처