노트북을 잃어버리면 무엇이 사라지는가 (1) — 값은 살아있는데 못 들어가는 역설

어느 날 문득, 지금 이 노트북을 잃어버리면 나는 무엇을 잃는가를 계산해 보고 싶어졌습니다. 도난이든 분실이든 물에 빠뜨리든, 원인은 중요하지 않았습니다. 정작 중요한 것은 그 다음 날 아침에 제가 어떤 상태에 놓이는가였습니다.

디스크는 전체 암호화가 켜져 있습니다. 그래서 누군가 제 노트북을 주워도 안의 데이터를 읽지는 못합니다. 다만 그건 "남이 못 읽는다"의 문제였고, 제가 던지고 싶었던 질문은 "내가 다시 못 쓰는가"였습니다. 돌이켜 보면 저는 그동안 앞의 질문에만 답을 해두고, 뒤의 질문은 미뤄두고 있었습니다.

백업 태세를 솔직히 들여다보니 부끄러웠습니다. 시스템 전체 백업은 설정해 두지 않았고, 클라우드 동기화는 문서 폴더 일부에만 걸려 있었습니다. 정작 여러 프로젝트에 흩어진 수십 개의 개발 자격증명—SSH 개인키, 각종 토큰, 접속 정보—은 백업이라 부를 만한 것이 거의 없었습니다. 이 글은 그 자산을 처음으로 전수 조사하면서 알게 된 것들에 대한 기록입니다.

값이 사는 것과, 값에 닿을 수단이 사는 것은 다릅니다

처음에는 이렇게 안심했습니다. "시크릿 값 자체는 어차피 서버에 살아 있잖아." 결제 연동에 쓰는 시크릿은 그 서비스 대시보드에 있고, DB 접속 문자열이 가리키는 데이터는 클라우드 DB에 있고, 코드는 private git에 push돼 있으니까요. 값은 노트북이 아니라 저 바깥에 산다는 생각이었습니다.

그런데 곰곰이 생각해보니 그 안심에는 큰 구멍이 있었습니다. 값이 저 서버에 살아 있다는 것과, 제가 그 서버에 들어갈 수 있다는 것은 전혀 다른 문제였습니다. 클라우드 DB는 멀쩡히 돌고 있어도, 거기에 접속할 SSH 개인키가 이 노트북 한 대에만 있으면 저는 그 서버를 눈앞에 두고도 못 들어갑니다.

서버는 멀쩡히 살아 있는데, 그 서버로 들어갈 문 열쇠만 사라진 상태. 제가 마주할 뻔한 것은 바로 그런 역설이었습니다.

이것을 흔히 단일 실패점(SPOF, Single Point of Failure)이라고 부릅니다. 다만 여기서의 단일 실패점은 조금 특이한 결을 가지고 있었습니다. 무너지는 것은 시크릿 값이 아니라 그 값에 닿는 능력이었으니까요. 값은 다 살아 있는데 접근 수단만 한곳에 몰려 있어서, 노트북 한 대가 사라지는 순간 연쇄적으로 문이 잠기는 구조였습니다.

초록과 빨강으로 자산을 가르다

그래서 자산을 두 가지 색으로 나눠보기로 했습니다. 기준은 단순합니다. 계정만 있으면 어디서든 되살아나는 것은 초록, 이 노트북과 함께 사라지는 것은 빨강. 색을 칠하고 나니 무엇을 백업해야 하는지가 선명해졌습니다. 초록은 이미 안전하니 손댈 필요가 없고, 백업이 필요한 것은 오직 빨강이었습니다.

자산	색	이유
클라우드에 사는 데이터·문서	초록	계정 로그인으로 어디서든 접근
원격에 push된 코드	초록	git 호스팅 계정으로 다시 clone
외부 서비스 대시보드의 시크릿 값	초록	계정으로 로그인해 재발급·조회 가능
로컬에만 있는 SSH 개인키	빨강	노트북에만 존재하는 서버 접근 수단
노트북에 로그인된 VPN 세션	빨강	메시 VPN 로그인 상태가 기기에 묶임
로컬 설정 파일에만 있는 배포 플랫폼 토큰	빨강	파일이 사라지면 운영 접근 수단 소멸
CLI로 넣은 OS 키체인 항목	빨강	동기화 대상이 아닐 수 있음 (다음 편에서 자세히)

빨강을 모아 놓고 보니 공통점이 보였습니다. 하나같이 "값에 닿기 위한 수단"이라는 것. 시크릿 값 자체가 아니라, 그 값이 사는 서버·플랫폼·네트워크로 들어가는 열쇠들이었습니다. 애초에 제 불안의 정체는 값의 소실이 아니라 접근 능력의 소실이었던 셈입니다.

값을 한 번도 출력하지 않고 조사하는 법

빨강을 백업하려면 먼저 빨강이 정확히 무엇인지 목록을 만들어야 했습니다. 그런데 여기서 원칙을 하나 세웠습니다. 조사하는 동안 시크릿 값을 화면에도, 로그에도 단 한 번도 출력하지 않는다. 이유는 단순합니다. 백업하려다 값을 흘리면 본말전도이기 때문입니다.

시크릿을 cat으로 한 번 열어보는 사소한 행동조차 그 값을 새로 복제합니다. 터미널 스크롤백에 남고, 셸 히스토리 파일에 적히고, 화면 캡처에 찍히고, 원격 세션이라면 로그에까지 남습니다. 안전하게 만들려던 작업이 오히려 노출 지점을 늘리는 것입니다. 그래서 조사 보고서에 담을 수 있는 것은 값이 아니라 메타데이터뿐이어야 했습니다. 경로, 키 이름, 백업 상태(원격에 사본이 있는가 아니면 로컬 유일본인가), 파일 권한, 그리고 값 자체가 아니라 해시의 앞 16자 정도.

예를 들어 SSH 개인키에 패스프레이즈가 걸려 있는지는 꽤 중요한 정보입니다. 패스프레이즈가 없는 키는 파일 하나만 새어도 그대로 뚫리니까요. 그런데 이걸 확인하겠다고 키를 열어볼 수는 없습니다. 대신 ssh-keygen의 종료 코드로 판정하면 값을 보지 않고도 알 수 있습니다.

# 값을 출력하지 않고 SSH 개인키의 패스프레이즈 유무만 판정합니다.
# 패스프레이즈가 없으면 exit 0, 있으면 non-zero. 개인키 내용은 화면에 나오지 않습니다.
for key in ~/.ssh/id_*; do
  case "$key" in *.pub) continue ;; esac
  if ssh-keygen -y -P '' -f "$key" >/dev/null 2>&1; then
    echo "$key : 패스프레이즈 없음 (분실 시 그대로 노출)"
  else
    echo "$key : 패스프레이즈 있음"
  fi
done

ssh-keygen -y는 개인키를 읽어 공개키를 출력하는 명령입니다. 공개키는 비밀이 아니므로 /dev/null로 버리고, 우리가 보는 것은 오직 성공/실패 여부입니다. 빈 패스프레이즈(-P '')로 읽기가 성공하면 그 키는 패스프레이즈가 없는 것이고, 실패하면 걸려 있는 것입니다. 값은 끝내 화면에 나오지 않습니다.

같은 정신으로, 파일 자체를 열지 않고도 "이게 그 파일이 맞는지"는 지문으로 확인할 수 있습니다. 값 대신 해시 앞자리와 권한, 경로만 남기는 것입니다.

# 값 대신 '지문'만 남깁니다: 해시 앞 16자 + 권한 + 경로
for f in ~/.ssh/id_* ~/.config/*/secrets.env; do
  [ -f "$f" ] || continue
  printf '%s  %s  %s\n' \
    "$(shasum -a 256 "$f" | cut -c1-16)" \
    "$(stat -f '%Sp' "$f")" \
    "$f"
done

이렇게 만든 목록에는 시크릿이 한 줄도 들어 있지 않습니다. 그럼에도 "무엇이 어디에 있고, 원격에 사본이 있는지, 권한이 느슨하지는 않은지"를 전부 판단할 수 있었습니다. 조사가 끝났을 때 제 손에는 값이 아니라 지도가 남았습니다. 백업해야 할 빨강 자산들이 어디에 흩어져 있는지 그린 지도 말입니다.

다음 편으로

자산을 초록과 빨강으로 가르고 나니, 진짜 문제는 백업 그 자체가 아니라 "복구의 열쇠를 어디에 둘 것인가"라는 생각이 들었습니다. 열쇠를 잘못된 곳에 두면 정작 필요한 순간 그 열쇠에도 닿지 못하니까요. 다음 편에서는 이 빨강 자산들을, 계층마다 단일 실패점이 다른 곳에 있도록 설계한 3계층 백업으로 어떻게 풀었는지—그것도 전부 무료 티어로—이어서 적어보겠습니다.