종단간 암호화 가계부 — 운영자도 못 보게 만드는 설계와 그 대가

가계부 데이터는 왜 특별히 민감한가요?

가계부에는 소득·대출·병원비·후원 이력처럼 신용과 사생활을 한꺼번에 드러내는 항목이 모입니다. 한 달 치만 봐도 직업·건강 상태·가족 관계·소비 성향이 대체로 재구성됩니다. 그래서 가계부는 유출 시 피해가 「불편」이 아니라 「협상력 상실」로 이어지는 종류의 데이터입니다.

일반적인 웹 서비스는 데이터를 서버에 평문으로 두거나, 서버가 가진 키로 암호화해 둡니다. 후자는 디스크를 훔쳐 가는 공격은 막지만 서버를 장악한 공격자·내부자·수사기관의 요구에는 열립니다. 키가 서버에 있으니까요. 이 구분이 「암호화했습니다」라는 문구를 무의미하게 만드는 지점입니다 — 중요한 건 키를 누가 쥐고 있는가입니다.

종단간 암호화는 일반 암호화와 어떻게 다른가요?

차이는 키의 위치 하나입니다. 종단간 암호화(End-to-End Encryption)는 키를 사용자 기기에서만 만들고 서버로 보내지 않습니다. 서버는 자기가 보관한 것이 무엇인지 알 수 없습니다.

키를 누가 쥐는가에 따른 차이

마지막 줄의 「복구 불가」가 종단간 암호화의 비용입니다. 이건 구현이 미숙해서 생긴 한계가 아니라 정의상 그래야 하는 성질입니다. 운영자가 되살려 줄 수 있다면 운영자가 열 수 있다는 뜻이고, 그럼 애초에 종단간이 아닙니다.

예산 플래너는 구체적으로 어떻게 암호화하나요?

비밀번호를 그대로 키로 쓰지 않습니다. 사람이 외우는 비밀번호는 짧고 편향돼 있어서 그대로 쓰면 대입 공격에 약합니다. 그래서 키 유도 함수(KDF)로 늘려 씁니다.

예산 플래너의 볼트 암호화 제원

팩트: AES-GCM은 인증 암호(AEAD)입니다. 복호화할 때 인증 태그를 함께 검사하므로 비밀번호가 틀리면 「이상한 값」이 나오는 게 아니라 복호화 자체가 실패합니다. 즉 틀린 비밀번호로 열어서 깨진 장부를 보게 되는 일이 구조적으로 없고, 누군가 저장된 암호문을 한 바이트라도 고쳐 두면 그 사실이 드러납니다. — AES-GCM(NIST SP 800-38D) 규격 · 예산 플래너 보안 설계

서버에는 정확히 무엇이 남나요?

서버(Supabase)에 올라가는 건 암호문 한 덩어리와 갱신 시각입니다. 항목명·금액·계좌·메모는 그 덩어리 안에 있어 서버 쪽에서는 구분되지 않습니다. 그래서 서버는 「이 사람의 식비가 얼마인지」는 물론 「항목이 몇 개인지」조차 알 수 없습니다.

다만 정직하게 덧붙이면, 종단간 암호화도 메타데이터는 가리지 못합니다. 계정 이메일, 가입 시각, 마지막 접속 시각, 암호문의 대략적인 크기와 갱신 빈도는 서버에 남습니다. 「아무것도 모른다」가 아니라 「내용은 모르고 흔적은 남는다」가 정확한 표현입니다.

비밀번호 재설정은 왜 없나요?

흔한 「비밀번호를 잊으셨나요? 메일로 재설정 링크를 보냅니다」 흐름은 종단간 암호화와 양립할 수 없습니다. 메일 링크로 새 비밀번호를 정하면 옛 비밀번호로 암호화된 데이터를 열 키가 사라집니다. 로그인은 되지만 장부는 안 열리는, 가장 나쁜 상태가 됩니다 — 사용자는 데이터가 남아 있다고 믿는데 영영 못 엽니다.

그래서 예산 플래너는 비밀번호 변경을 「로그인한 상태에서 전체를 다시 암호화하는 작업」으로만제공합니다. 지금 비밀번호로 볼트를 열 수 있는 사람만 새 비밀번호로 바꿀 수 있습니다. 이 작업은 인증 비밀번호와 데이터 암호문 두 시스템을 함께 바꾸는 일이라 중간에 실패하면 영구 잠금 위험이 있습니다. 그래서 바꾸는 동안에는 두 비밀번호의 암호문을 봉투에 함께 담아 두고, 다음 로그인에서 열리는 쪽을 정본으로 확정합니다.

원칙: 복구 백도어를 만들지 않는 대신 백업 파일을 스스로 내려받는 경로를 둡니다. 예산 플래너의 설정 탭에서 전체 데이터를 JSON으로 내보낼 수 있고, 이 파일은 평문입니다 — 열 수 있다는 게 장점이자 위험이라, 저장 위치를 사용자가 직접 골라야 합니다. 비밀번호 분실에 대한 유일한 현실적 대비책입니다. — 예산 플래너 보안 설계

인증 비밀번호와 암호화 키는 같은 건가요?

아닙니다. 이 둘을 섞으면 서버에 비밀번호를 넘기는 셈이 되므로 일부러 분리했습니다.

• 서버 로그인용 비밀 — 원문 비밀번호와 이메일에서 유도한 별개의 값을 보냅니다(PBKDF2 25만 회, 이메일에서 만든 소금). 서버는 이 값만 보고 원문은 모릅니다.
• 볼트 암호화 키 — 원문 비밀번호에서 따로 유도하며 기기 밖으로 나가지 않습니다.

중요한 함의가 있습니다. 서버 로그인용 비밀이 강해진다고 볼트가 더 안전해지는 건 아닙니다.볼트는 여전히 원문 비밀번호의 강도에 달려 있습니다. 그래서 긴 비밀번호가 이 구조에서 가장 효과가 큰 대비책입니다.

그래도 남는 위험은 무엇인가요?

종단간 암호화가 막아주지 않는 것들을 분명히 아는 게 안전에 더 도움이 됩니다.

• 약한 비밀번호 — 25만 회 반복은 추측 비용을 올릴 뿐 없애지 않습니다. 짧은 비밀번호는 여전히 뚫립니다.
• 내 기기가 이미 장악된 경우 — 잠금을 푼 동안 키는 메모리에 있습니다. 기기 감염은 별개 문제입니다.
• 내려받은 백업 파일 — 평문입니다. 클라우드 공유 폴더에 두면 암호화의 의미가 사라집니다.
• 어깨 너머·스크린샷 — 화면에 뜬 숫자는 어떤 암호도 가려주지 않습니다.

• Q. 운영자가 정말 내 가계부를 못 보나요?

  A. 볼 수 없습니다. 서버에는 기기에서 암호화된 암호문만 저장되고 복호화 키는 서버로 전송되지 않습니다. 다만 계정 이메일·가입 시각·마지막 접속 시각 같은 메타데이터는 남습니다.

• Q. 비밀번호를 잊으면 정말 방법이 없나요?

  A. 없습니다. 복구 수단을 만들면 그 수단으로 운영자도 열 수 있게 되어 종단간 암호화가 성립하지 않습니다. 대비책은 설정 탭에서 백업 JSON을 미리 내려받아 두는 것뿐입니다.

• Q. 비밀번호를 바꾸면 기존 데이터는 어떻게 되나요?

  A. 로그인한 상태에서 바꾸면 전체가 새 비밀번호로 다시 암호화되어 그대로 열립니다. 바꾸는 중 실패해도 두 비밀번호의 암호문을 함께 보관해 다음 로그인에서 열리는 쪽으로 마무리됩니다.

• Q. 여러 기기에서 쓸 수 있나요?

  A. 됩니다. 같은 계정과 같은 비밀번호로 로그인하면 각 기기가 스스로 키를 다시 만들어 암호문을 엽니다. 키가 기기 사이를 오가지 않습니다.

• Q. 백업 파일이 평문이면 위험하지 않나요?

  A. 위험합니다. 그래서 내보낼 때 경고를 띄웁니다. 공유 폴더·메신저 대화방에 두지 말고 본인만 접근하는 저장소에 보관하세요.

예산 플래너는 이 구조를 기본값으로 씁니다. 켜고 끄는 설정이 아니라, 계정을 만들면 처음부터 그렇게 동작합니다. 대신 백업을 내려받으라는 안내를 반복해 띄웁니다 — 복구해 줄 수 없는 대신 스스로 대비할 수 있게 하는 것이 이 설계에서 할 수 있는 최선의 정직함이라고 봤습니다.

이 글은 일반적인 가계 관리 정보를 제공할 뿐, 투자·세무·재무 자문이 아닙니다. 개인 상황에 따라 판단은 달라질 수 있습니다.