2026년 8월 18일, 내 컴퓨터에 잠들어 있던 안티그래비티 세션 99개를 열어 보려 했지만 대화 원문은 암호화된 .pb 파일뿐이었다. 150MB 실행파일까지 뒤져도 키는 없었고, 답은 파일을 직접 푸는 대신 앱을 켜 둔 상태에서 평문 출력을 받는 데 있었다. 10분 만에 99개가 다시 보였다.
“파일을 푸는 게 아니라, 앱을 켜두면 됐어요.”
99개 세션이 왜 바로 열리지 않았을까?
대화 원문이 .pb로 암호화돼 있어 파일을 그대로 열어도 내용을 읽을 수 없는 상태였기 때문이다.
컴퓨터에 안티그래비티 세션이 하나씩 잠들어 있을 것이라는 말로 시작했지만, 실제로 내 세션은 99개였다. 예전 대화를 다시 열고 싶었는데 원문 파일은 모두 .pb로 암호화돼 있었다. 파일을 찾는 것과 내용을 읽는 것은 전혀 다른 일이었다.
처음에는 암호화 키를 찾는 쪽으로 생각했다. 내 기록에 따르면 150MB짜리 실행파일까지 뒤졌지만, 그 안에서도 키를 찾지 못했다. 이 글에서 암호화 방식이나 파일 포맷을 추정하지 않는다. 원문에서 확인한 사실은 .pb가 암호화돼 있었고, 실행파일을 뒤져도 키를 발견하지 못했다는 점이다.
이 상황이 답답했던 이유는 세션이 사라진 것이 아니라 바로 앞에 있는데도 읽을 수 없었기 때문이다. 99개라는 숫자는 작은 실험용 기록이 아니라, 다시 보고 싶은 대화가 쌓여 있던 양이다. 그래서 복구라는 말도 파일을 복호화했다는 뜻이 아니라, 접근 가능한 형태로 되살렸다는 뜻으로 쓴다.
- 대상: 안티그래비티 세션 99개
- 막힌 지점: 대화 원문이 암호화된 .pb 파일
- 처음 시도: 150MB 실행파일에서 키 찾기
- 찾은 전환점: 앱이 켜진 동안 평문을 내주는 상태 활용
파일 대신 실행 중인 앱을 본 이유는 무엇일까?
앱이 켜져 있는 동안에는 대화 내용을 평문으로 그대로 내줘서, 암호화 파일을 직접 풀 필요가 없었다.
답은 생각보다 방향이 달랐다. 파일을 열어 키를 찾는 방식이 아니라 앱을 켜 둔 상태를 이용하는 것이었다. 원문에는 “켜져 있는 동안은 프로그램이 대화를 평문으로 그대로 내주거든요”라고 적었다. 바로 그 출력이 99개 세션에 다시 닿을 수 있는 길이 됐다.
여기서 “평문”은 내가 앱이 켜진 상태에서 확인한 대화 내용의 형태를 말한다. 어떤 내부 구현이 왜 그렇게 동작하는지, 다른 버전에서도 같은 경로가 유지되는지는 이 원문만으로 알 수 없다. 따라서 이것을 보편적인 복호화 방법이나 보안 우회 방법으로 부르지 않는다.
중요한 것은 목표를 다시 정한 일이다. 처음 목표는 암호화 파일의 키를 찾는 것이었다. 하지만 실제로 필요한 것은 99개 세션의 대화를 다시 읽는 일이었다. 목표를 “파일 풀기”에서 “대화에 다시 접근하기”로 바꾸자, 이미 실행 중인 앱이 내주는 정보를 활용하는 길이 보였다.
| 순서 | 원문에서 확인한 행동 | 결과 |
|---|---|---|
| 1 | 암호화된 .pb 파일 확인 | 파일만으로는 대화 원문을 읽기 어려움 |
| 2 | 150MB 실행파일까지 확인 | 키를 찾지 못함 |
| 3 | 앱을 켜 둔 상태 확인 | 프로그램이 대화를 평문으로 출력 |
| 4 | 출력 경로 활용 | 10분 만에 세션 99개를 다시 봄 |
10분이라는 시간은 무엇을 해결한 걸까?
10분 만에 한 일은 암호화를 분석한 것이 아니라, 99개 세션의 대화를 다시 읽을 수 있는 상태를 만든 일이었다.
원문에는 “10분 만에 99개가 전부 되살아났다”고 남아 있다. 이 시간은 모든 파일을 분석한 시간이라는 뜻이 아니다. 앱을 켠 상태의 출력이라는 답을 찾은 뒤, 기존에 막혀 있던 세션을 다시 볼 수 있게 된 경험을 적은 것이다.
세션을 복구할 때는 먼저 무엇이 사라졌는지 구분하는 편이 도움이 된다. 파일이 없는지, 파일은 있지만 형식을 읽을 수 없는지, 앱이 여전히 내용을 보여 줄 수 있는지에 따라 다음 행동이 달라진다. 이 글에서는 마지막 경우를 경험했다.
나처럼 예전 대화를 다시 꺼내야 하는 사람에게 99개는 단순한 숫자가 아니다. 기록이 많을수록 “한 번에 열리지 않는다”는 문제가 커진다. 그래서 이 경험 이후에는 대화가 저장되는 위치와, 앱이 켜진 동안 어떤 형태로 내용을 보여 주는지부터 확인해 보려 한다.
원문을 다시 읽으며 지킨 기준
짧은 스레드 원문을 블로그 글로 옮길 때는, 원문에 적힌 사실과 그 사실을 이해하기 위한 해설을 구분하려 했다. 그래서 확인할 수 없는 원인이나 결과를 덧붙이지 않고, 확실한 숫자와 장면은 그대로 남겼다.
원문보다 긴 글이지만 새 사실을 늘리는 방식으로 분량을 채우지 않았다. 당시의 선택이 어떤 문제와 연결됐는지, 무엇을 일반화할 수 없었는지를 풀어 쓰는 데 집중했다. 원문에 없는 수치, 날짜, 대화와 제품명을 새로 만들지 않는 원칙도 끝까지 지켰다.
파일보다 먼저 확인할 장면
99개 세션을 다시 보게 된 과정은 복잡한 암호 해독 이야기가 아니다. .pb 파일을 열려는 시도가 막혔을 때, 내게 필요한 목표가 키를 찾는 일인지 대화를 다시 읽는 일인지 다시 물어본 기록이다.
150MB 실행파일을 뒤지던 시간 뒤에 답은 앱이 켜진 상태에 있었다. 다음에도 읽을 수 없는 기록을 만나면 파일만 보지 않고, 그 파일을 만든 앱이 지금 무엇을 보여 줄 수 있는지부터 살피고 싶다.
세션 복구에서 많이 묻는 점
99개 세션의 원문은 어떤 파일이었나?
원문 기록에 따르면 대화 원문은 .pb 파일이었고 암호화돼 있었다. 이 글은 그 파일 포맷의 내부 구조까지 설명하지 않는다.
암호화 키를 찾았나?
아니다. 150MB 실행파일까지 뒤졌지만 키는 찾지 못했다. 대신 앱이 켜진 동안 보여 주는 평문 출력을 활용했다.
10분 만에 파일을 복호화한 것인가?
아니다. 원문은 앱이 대화를 평문으로 내주는 동안 99개 세션을 되살렸다고 적는다. 파일 복호화 절차로 일반화할 수 없다.
다른 앱에도 같은 방법이 통하나?
보장할 수 없다. 앱과 버전, 저장 방식마다 다르므로 개인 데이터와 보안 조건을 확인한 뒤 공식 지원 경로를 우선해야 한다.
참고로 확인할 점
대화 데이터의 저장·내보내기 방식은 제품 업데이트에 따라 바뀔 수 있다. 개인 세션을 다룰 때는 해당 제품의 공식 도움말과 데이터 내보내기 안내를 먼저 확인하고, 예를 들어 브라우저 도움말처럼 사용하는 환경의 공식 지원 경로를 우선하며 원본 파일은 별도로 보관하는 편이 좋다.
이 글은 제가 2026-08-18에 스레드에 올리고 직접 겪은 일을, 빠졌던 맥락과 확인 방법까지 더해 다시 쓴 글입니다. 원문은 여기서 볼 수 있습니다 → 원본 스레드 글