주소모음 백업과 복구, 이렇게 하면 끝

웹을 오래 쓰다 보면 북마크, 즐겨찾기, 링크 스크랩이 일종의 두뇌 보조장치처럼 변한다. 다음 프로젝트의 참고 문헌, 고객이 보내온 로그인 포털, 자주 쓰는 API 문서, 주말에 볼 레시피까지, 클릭 하나의 차이에 시간과 스트레스가 갈린다. 그래서 주소모음이 날아가는 날은 일의 박자가 완전히 무너지는 날이다. 2019년에 한 팀이 크롬 프로필 동기화 충돌로 800개 북마크가 뒤섞였을 때, 정리 복구에 꼬박 이틀이 들었다. 폴더 구조가 무너지면 링크 자체보다 기억의 실마리가 사라진다. 백업과 복구는 기술이라기보다 습관에 가깝다. 좋은 습관 하나로 난리통을 예방할 수 있다.

주소모음이 담기는 그릇부터 이해하기

주소모음은 크게 세 가지 그릇에 담긴다. 첫째, 브라우저 북마크. 크롬, 엣지, 파이어폭스, 사파리는 모두 자체 북마크를 가진다. 보통 로그인 동기화 기능을 제공하지만, 이것만 믿으면 안 된다. 네트워크 불안정, 프로필 충돌, 실수로 한 기기에서 대규모 삭제가 일어났을 때, 그 상태가 그대로 다른 기기로 전파되는 일이 종종 있었다.

둘째, 전용 링크모음 서비스. 예를 들면 주소아지트처럼 폴더형 큐레이션을 강조하는 서비스, 다양한 브라우저에서 쓸 수 있는 링크모음 북마클릿이나 확장 프로그램을 제공하는 서비스, 태그 기반 정리에 강한 툴이 있다. 이런 서비스는 협업이나 공유, 썸네일, 검색 품질이 강점이다. 다만 서비스 중단이나 요금제 변경, 잠깐의 API 장애가 문서 접근성을 가로막을 수 있다. 자체 내보내기 기능 유무와 데이터 포맷을 반드시 확인해야 한다.

셋째, 파일과 노트 시스템. Notion, Obsidian, 에버노트처럼 문서 안에 링크를 모으는 방식, 또는 단순히 스프레드시트로 정리하는 방식이다. 가볍고 이식성이 좋은 대신, 브라우저 즐겨찾기처럼 한 번에 열거나 드래그 앤 드롭으로 폴더 간 이동하는 편의성은 떨어진다. 대신 CSV나 Markdown처럼 표준 포맷으로 뽑아내기 쉬워 장기 보관에는 유리하다.

결론적으로, 주소모음의 80%는 브라우저 북마크와 링크모음 서비스에 쌓인다. 두 환경에서 확실히 백업 루틴을 만들면 웬만한 사고는 막는다.

포맷을 아는 사람이 복구를 지배한다

북마크의 표준 포맷은 사실상 Netscape Bookmark HTML이다. 이름만 보면 고풍스럽지만, 오늘도 대부분의 브라우저에서 이 HTML로 내보내고 가져온다. 장점은 단순함이다. 폴더, 제목, URL, 메모가 모두 HTML 태그로 들어간다. 단점은 태그, 즐겨찾기 아이콘, 하이라이트 같은 서비스 고유 메타데이터가 빠지기 쉽다는 점이다.

최근 브라우저는 JSON 포맷도 쓴다. 크롬과 엣지는 프로필 폴더 안에 Bookmarks라는 JSON을 저장한다. 폴더 구조, 북마크바, 순서가 고스란히 남는다. 이 파일을 그대로 다른 프로필에 덮어써 복구하는 요령을 알아두면 속전속결로 되살릴 수 있다. 다만 사용자 프로필 경로가 OS마다 다르고, 실수하면 현재 상태를 망가뜨릴 수 있으니 사본을 만드는 습관이 중요하다.

CSV는 서비스형 링크모음에서 자주 본다. 제목, URL, 태그, 생성일 같은 열을 가지며, 스프레드시트로 정리하기 좋다. 다만 브라우저로 다시 가져오려면 중간 변환이 필요하다. 변환은 크게 어렵지 않다. CSV를 Markdown이나 HTML로 바꾸는 스크립트를 쓰거나, Raindrop 같은 서비스에 임포트하고 브라우저로 다시 내보내는 우회로가 있다.

인코딩은 늘 UTF-8로 통일하는 편이 낫다. 한글 깨짐은 백업 파일을 열어봐야 알 수 있다. 10개 정도 샘플을 점검하는 습관만으로 큰 낭패를 절반은 줄인다.

백업 전략은 3 - 2 - 1, 그리고 버저닝

주소모음은 용량이 작다. 2천 개 북마크라 해도 HTML 내보내기가 수 메가바이트를 넘지 않는다. 그렇다고 대충 다뤄도 된다는 뜻은 아니다. 기본은 3 - 2 - 1 원칙이다. 사본 3개, 매체 2종, 외부 보관 1개. 실제로는 로컬 디스크 사본, 클라우드 동기화 폴더 사본, 외장 드라이브나 다른 클라우드의 암호화된 사본 정도가 현실적이다.

주기 설정이 핵심이다. 하루에도 수십 번 링크를 추가한다면 주간 백업이 낫고, 업무 북마크가 고정되어 있다면 월간으로 충분하다. 프로젝트 시즌에는 과감히 일일 백업으로 올렸다가 끝나면 주기를 내리면 된다. 버저닝을 켜두는 게 두 번째 핵심이다. 드롭박스, 구글 드라이브, 원드라이브는 기본적으로 파일 버전을 보존한다. HTML 파일 하나를 덮어쓰는 방식으로 백업해도, 복원 시점 선택이 가능하니 실수를 만회할 수 있다.

마지막으로 암호화. 링크 자체는 민감 정보가 아니라고 방심하기 쉽다. 그러나 내부 대시보드, 개발용 엔드포인트, 프로젝트 관리 툴 링크는 주소만으로도 조직 구조와 권한 체계를 노출한다. 외부 보관본에는 암호화를 적용하는 편이 안전하다. 7z AES-256 압축이나 VeraCrypt 컨테이너면 충분하다.

브라우저별 백업, 경험에서 나온 디테일

크롬과 엣지는 인터페이스가 거의 같다. 설정에서 북마크 관리자에 들어가 내보내기, 가져오기를 차례로 누르면 HTML 파일로 손쉽게 백업된다. 여기서 한 가지, 프로필을 여러 개 쓰는 경우가 문제다. 실수로 다른 프로필에서 내보내면 폴더 구조가 달라진다. 내보내기 전에 주소창 오른쪽 프로필 아이콘을 확인하는 습관을 들인다. 또 한 가지, 북마크바만 따로 쓰는 사람은 내보낸 뒤 파일을 열어 북마크바 섹션에 실제 항목이 다 들어있는지 확인해야 한다. 때로는 모바일 북마크가 북마크바에 합쳐지는 버그가 있었다.

파이어폭스는 라이브러리 창에서 백업과 복원을 모두 제공한다. 여기서 JSON으로 백업하면 파이어폭스끼리의 완전 복원이 가능하다. HTML은 범용 호환을 위해 쓰되, 파이어폭스 전용 보관용으로 JSON을 하나 더 둔다. 파이어폭스의 북마크는 태그 지원이 좋다. HTML로는 이 태그가 일부 손실된다. 태그를 적극 쓰는 사람이라면 JSON 백업이 필수다.

사파리는 맥에서만 제대로 다룰 수 있다. 파일 메뉴에서 내보내기를 선택하면 HTML로 나온다. 아이클라우드 동기화를 켰다면, 복구 시 대량 삭제가 동기화되기 전에 네트워크를 끊고 사파리를 종료한 뒤 다시 가져오는 요령이 필요하다. 시스템 환경설정에서 사파리 동기화를 잠시 꺼두고 복구한 다음, 구조가 안정되면 다시 켠다.

회사 환경에서 흔한 시나리오는 브라우저 정책으로 동기화가 제한되고, 프로필 폴더도 정기적으로 초기화되는 경우다. 이럴 때는 사용자 디렉토리의 프로필 폴더에 접근할 수 있는지 IT팀에 문의하고, 접근 가능할 때 Bookmarks JSON을 주기적으로 복사하는 배치 스크립트를 써두면 복구가 매우 빠르다.

모바일에서 놓치기 쉬운 포인트

안드로이드와 iOS의 크롬, 사파리, 파이어폭스는 동기화 중심이다. 별도의 내보내기 기능이 약하다. 이럴 때는 데스크톱과의 동기화를 전제로 백업 루틴을 가져간다. 즉, 모바일에서 추가한 북마크를 매일 데스크톱에 열어보고, 주기적으로 데스크톱에서 내보낸다. 아이폰 사파리의 경우 읽기 목록과 즐겨찾기가 섞여 보일 수 있으니, 복구 전에 각각의 성격을 구분해두어야 한다. 읽기 목록은 임시 보관함에 가깝고, 내보내기 호환성이 떨어진다.

안드로이드에서 시스템 초기화가 잦은 사람은 파이어폭스 계정을 써서 태그 기반 북마크를 관리하면 생각보다 수월하다. 파이어폭스는 모바일과 데스크톱의 동기화가 견고하고, JSON 복구가 탄탄하다. 크롬은 프로필이 회사 계정과 연동되어 정책이 걸리는 경우가 많아 개인과 업무용을 분리해두면 사고를 줄일 수 있다.

주소아지트와 같은 링크모음 서비스, 내보내기 습관이 살린다

링크모음 서비스는 편리하지만, 업체마다 내보내기 포맷과 호환성이 다르다. 주소아지트를 비롯한 서비스 다수가 HTML 또는 CSV 내보내기를 지원한다. 실제로 써보면 이미지 썸네일, 컬렉션 순서, 사용자별 권한 같은 요소는 빠질 때가 많다. 본질은 URL과 제목, 폴더 구조다. 내보낸 직후 바로 다른 서비스나 브라우저로 임포트해 시범 복구를 해보면, 빠지는 메타데이터가 무엇인지 리스트업할 수 있다. 그 결과에 맞춰 태그나 설명 필드를 적극 활용해, 이식성을 높인다.

협업 보드에서 공유 링크를 쓰는 조직은 더 조심해야 한다. 특정 팀원이 탈퇴하거나 라이선스 수가 줄면서 보드 자체가 잠기는 사례가 있다. 이럴 때 관리 권한이 있는 계정으로 분기 말마다 내보내고, 개인 보관용 HTML과 조직 보관용 CSV를 나눠 저장하면 일이 매끈해진다. CSV는 BI툴이나 데이터 카탈로그와도 연계가 쉬워, 검색 체계 재구성에 도움이 된다.

자동화는 가볍게, 검증은 확실하게

자동화의 목적은 잊어도 돌아가게 만드는 것이다. 윈도우에서는 작업 스케줄러로 크롬 북마크 HTML 내보내기를 직접 호출하기 어렵다. 대신 북마크를 JSON 파일 단위로 복사하는 스크립트를 쓰고, 주 1회 HTML로 수동 내보내기를 병행한다. 맥에서는 Automator와 단축어를 조합해 사파리 내보내기를 반자동화할 수 있다. 파일이 생성되면 클라우드 동기화 폴더로 이동하고, 7z로 암호화 압축하는 과정까지 묶는다. 리눅스는 크로미움 계열 브라우저의 프로필 경로가 일정해 쉘 스크립트로 날짜 스탬프가 붙은 사본을 남기기 좋다.

중요한 건 검증이다. 자동화가 돌아간 흔적만 믿지 말고, 월 1회는 백업 파일을 열어 폴더의 수, 대표 링크 20개, 태그 샘플 10개를 점검한다. 이 검증이 자동화의 진짜 안전벨트다. 숫자를 잡아두면 비교가 쉽다. 예컨대 지난달 HTML에 폴더가 42개였는데 이번 달에는 31개라면, 대량 삭제가 있었을 수 있다는 뜻이다.

복구, 짧고 정확하게 끝내는 절차

아무리 잘 준비해도 사람은 실수한다. 북마크를 몽땅 지우거나, 같은 링크가 수백 개 중복되거나, 폴더 트리가 엉킬 수 있다. 복구는 간결해야 한다. 지연되면 동기화가 망가뜨리는 범위만 커진다.

네트워크 동기화를 잠시 끊는다. 노트북은 와이파이를 끄고, 브라우저의 동기화를 일시 중지한다. 가장 최근의 검증된 백업 파일을 선택한다. HTML과 JSON이 모두 있다면, 동일 브라우저 복구는 JSON을 우선한다. 현재 상태를 덮어쓰기 전에, 현 상태도 별도 사본으로 저장한다. 혹시 일부 최신 링크가 필요할 수 있다. 가져오기 또는 파일 교체로 복구한다. 복구 후 브라우저를 재시작하고 폴더 수와 대표 링크를 샘플 점검한다. 동기화를 다시 켜기 전에, 모바일과 다른 기기에서 브라우저를 닫아두었는지 확인한다. 그 다음 동기화를 켜고, 다른 기기에서 구조가 동일한지 확인한다.

이 순서를 따르면 동기화로 망가진 상태가 다시 덮어쓰는 일을 줄일 수 있다. 특히 두 번째와 세 번째 단계, 즉 검증된 백업 선택과 현 상태 사본 저장은 자주 생략된다. 그러나 두 단계를 지키면 미세 조정이 가능해, 잃어버린 일주일치 북마크만 골라 합치는 식의 회복이 가능하다.

중복 제거와 구조 다듬기, 복구의 절반

복구 이후 주소모음은 보통 무겁다. 비슷한 링크가 폴더마다 들어가 있고, 과거 프로젝트의 레거시가 남아 있다. 중복 제거는 기계적 알고리즘에만 맡기지 않는다. 주소가 다르고 리다이렉트가 걸린 링크가 같은 문서를 가리키는 경우가 흔하다. 중복 판단 기준을 몇 가지로 정해 사람 눈으로 샘플링한다. 첫째, 도메인이 같은가. 둘째, 제목 유사도가 높은가. 셋째, 최근 방문 기록이 없는가. 이 기준으로 후보군을 추려 50개 정도를 직접 확인하면, 도메인별 패턴을 애써 가르치지 않아도 감이 생긴다.

폴더 구조는 프로젝트형과 주제형 중 하나로 통일하는 편이 유지보수가 쉽다. 업무에서는 보통 연도 - 분기 - 프로젝트로 나누는 프로젝트형이 깔끔하다. 개인 연구는 주제형, 예를 들어 Algorithm, Infra, Writing 같이 개념으로 묶는 편이 검색에 유리하다. 혼합형을 쓰면 중복이 폭증한다. 복구를 계기로 한 가지 방식으로 정리하면 검색 속도가 체감적으로 빨라진다.

태그는 작게 시작해 합치기 쉬운 단어로. 두 단어 조합을 최소한으로 줄이고, 동의어를 합친다. 예를 들어 ai, artificial-intelligence, ml, machine-learning 같은 태그가 뒤섞여 있다면, ml 하나로 합치고, 필요하면 설명에 세부를 적는다. 태그 수가 50개를 넘으면 사실상 아무도 기억하지 못한다. 20개 내외가 유지 가능한 상한선이다.

링크 부패와 장기 보존, 두 가지 레이어

세월이 지나면 링크는 부패한다. 도메인이 사라지거나, 문서가 이동하고, 로그인 벽이 생긴다. 중요한 자료는 두 레이어로 보존한다. 첫 번째 레이어는 주소 자체의 백업. 이것이 오늘 다루는 백업과 복구다. 두 번째 레이어는 콘텐츠의 스냅샷이다. 텍스트가 주소아지트 핵심인 문서는 PDF로 저장하고, 원문 URL을 파일 속성이나 파일명에 함께 남겨둔다. 기술 문서는 버전이 바뀌면 의미가 달라지므로, 저장 시점도 기록한다.

아카이브 툴을 가볍게 도입하면 체계가 생긴다. 브라우저 확장 프로그램 SingleFile은 페이지를 하나의 HTML 파일로 통째로 저장한다. 코드 블록, 이미지, 스타일이 의외로 잘 보존된다. 중요한 가이드나 블로그 글, 계약 안내 페이지는 이 방식으로 남겨두면 나중에 로그인 변경이나 삭제에도 안전하다. 퍼블릭 페이지는 Wayback Machine에 수동 제출을 해두면 링크 자체로 과거 스냅샷을 열람할 수 있다. 연구나 레퍼런스 수집이 많다면 ArchiveBox처럼 로컬 아카이브 서버를 두는 것도 방법이다. 저장 공간이 조금 들지만, 장기적으로 링크 부패 스트레스를 크게 줄인다.

한글 깨짐, 파비콘 손실, 권한 오류, 자주 겪는 문제들

한글 깨짐은 보통 CSV에서 발생한다. 내보낼 때 UTF-8 with BOM 옵션이 있으면 켠다. 엑셀로 열 때는 데이터 가져오기 기능을 통해 인코딩을 지정한다. 이미 깨진 파일은 전용 변환툴로 회복을 시도할 수 있지만, 100% 복구는 기대하지 않는 편이 낫다.

파비콘 손실은 본질적으로 문제가 아니다. 북마크 복구 후 처음 해당 사이트를 열면 새로 받아온다. 다만 수백 개 링크에 대해 파비콘이 모두 사라져 있으면 시각적 인지가 떨어진다. 복구 직후 상위 폴더의 대표 링크를 한 번씩 열어두면, 자주 쓰는 아이콘은 빠르게 복구된다.

권한 오류는 링크모음 서비스에서 잦다. 팀원이 떠나고, 링크 소유자가 바뀌면 일부 컬렉션이 열리지 않는다. 관리자 권한으로 내보내기를 했는지, 개인 폴더와 팀 폴더의 구분이 정확한지 확인한다. 가능하면 링크 공유 권한을 문서화해두고, 분기별로 리뷰한다. 주소아지트처럼 협업을 지원하는 서비스에서는 특히 폴더 소유권 이전 기능을 익혀두면, 계정 변경 시 파급을 줄일 수 있다.

보안, 링크에도 예의가 필요하다

링크 자체에 비밀번호가 달린 경우가 있다. 게스트 접속 토큰이 URL 파라미터로 붙어 있는 식이다. 이런 링크는 외부 유출 시 바로 권한 탈취로 이어질 수 있다. 외부 보관본에는 이런 민감 링크를 별도 목록으로 분리해 두고, 팀 내부에만 접근 가능한 저장소에 둔다. 가능하면 토큰 기반 링크 대신, 로그인 뒤 접근하는 일반 링크로 대체한다.

개인 계정과 업무 계정을 섞지 않는다. 브라우저 프로필도 분리하고, 링크모음 서비스 계정도 분리한다. 나중에 권한을 정리할 때, 계정 분리가 돼 있지 않으면 공유 해제에 큰 시간과 혼선이 생긴다. 2단계 인증은 기본이고, 내보내기 파일 역시 암호화한다. 암호는 비밀번호 관리자에 보관한다.

조직에서의 운영, 단일 진실의 원천 만들기

팀이 커질수록 링크가 문서보다 먼저 흩어진다. 슬랙, 문서, 위키, 메신저, 이메일 어디에나 반복 공유가 나온다. 주소모음은 단일 진실의 원천이 될 수 있다. 팀 표준 링크 컬렉션을 하나 정하고, 거기에만 추가한다. 프로젝트 킥오프 때 이 컬렉션을 복제해 프로젝트 전용 폴더를 만들고, 종료 시 공용 컬렉션으로 합친다. 이 흐름을 의식적으로 운영하면, 분기 회고에서 잃어버린 링크를 찾느라 시간을 쓰지 않는다.

백업은 담당자를 정하되, 누구나 복구할 수 있게 문서화한다. 담당자가 휴가를 가거나 퇴사할 수 있다. 업무 연속성은 문서가 지킨다. 백업 위치, 포맷, 암호화 방식, 복구 순서를 스크린샷과 함께 한 페이지로 정리해 두면, 신입도 30분 안에 복구를 끝낼 수 있다.

사례로 보는 실전 복구

중견 스타트업 A사는 크롬 프로필 세 개로 업무를 나누었다. 마케팅, 운영, 개발. 어느 날 운영 프로필에서 북마크바 정리를 하다 대량 삭제를 했다. 15분 뒤 개발자 노트북에도 빈 북마크바가 동기화됐다. 팀은 와이파이를 끊고, 지난주 금요일에 저장된 HTML을 꺼냈다. 개발 프로필은 JSON 보관본이 있었지만 운영은 HTML만 있었다. 운영 프로필은 HTML로 가져오고, 개발 프로필은 JSON 파일 교체 후 재시작했다. 검증 과정에서 주말 동안 추가된 세 개의 긴급 링크가 사라진 것을 발견했다. 다행히 현 상태 사본을 남겨두었기에, 그 사본에서 세 링크만 추출해 합쳤다. 전 과정에 40분이 들었다. 만약 사본 없이 HTML만 믿고 진행했다면, 긴급 링크를 기억으로 되살리느라 반나절이 갔을 것이다.

개인 사용자 B는 주소아지트에 연구 링크를 모았다. 내보내기가 CSV였다. 브라우저로 옮기려다 태그 손실이 걱정되어, 먼저 Raindrop으로 CSV를 임포트하고, 태그를 정규화한 뒤 브라우저용 HTML로 다시 내보냈다. 이 과정을 통해 duplicate라는 태그로 중복 후보를 자동 분류했고, 최종 임포트 전 120개의 중복을 정리했다. 백업 파일은 CSV 원본과 HTML 변환본 두 가지를 모두 보관했다. 6개월 뒤 주소 체계가 바뀐 대학 라이브러리 링크에서 문제가 생겼지만, 태그 기반 검색으로 대체 링크를 금방 찾아 교체할 수 있었다.

월간 유지보수 체크리스트

브라우저와 링크모음 서비스에서 각각 내보내기를 실행하고, 파일을 열어 샘플 20개를 점검한다. 백업 파일을 날짜로 명명해 클라우드와 외장 보관소에 저장하고, 이전 버전과 폴더 수를 비교한다. 중복 후보 태그나 폴더를 점검해 30개 이내의 중복을 정리한다. 중요 문서 5개를 선택해 PDF 또는 SingleFile 스냅샷을 갱신한다. 권한이 필요한 링크의 접근 권한을 검토하고, 떠난 팀원의 소유권을 이전한다.

작은 습관이 큰 복구를 만든다

주소모음은 업무와 취미의 관문이다. 그래서 백업은 거대한 시스템이 아니라, 일상에 녹아든 작은 습관이면 충분하다. 내보내기 파일을 열어보는 2분, 폴더 수를 비교하는 30초, 최근 추가분을 한 번 스캔하는 1분. 이 세 가지면 돌이킬 수 없는 사고의 대부분을 피한다. 링크모음 서비스를 쓸 때는 주소아지트처럼 내보내기가 쉬운지, 태그와 폴더가 어떻게 담기는지 먼저 확인해두면 나중의 선택지가 넓어진다. 브라우저 동기화에만 기대지 말고, 파일 사본을 남기는 루틴을 가져가자. 복구는 그러면 간단해진다. 네트워크를 끊고, 검증된 백업을 고르고, 현 상태 사본을 확보하고, 임포트하고, 동기화를 다시 켜는 절차. 이렇게 하면 끝이다.

Edit

Pub: 18 May 2026 13:22 UTC

Views: 0