PrivacyNotes는 제 노트에 대해 무엇을 볼 수 있나요?¶
읽을 수 있는 것은 아무것도 없어요. 노트, 제목, 태그, 첨부 파일은 동기화되기 전에 기기에서 암호화돼요. 서버는 해독할 수 없는 암호문만 저장하고, 저희 쪽에는 이를 바꿀 수 있는 키가 존재하지 않아요.
저희가 볼 수 있는 것은 서비스 운영에 필요한 최소한이에요. 암호화된 저장 공간을 얼마나 쓰는지, 기기를 몇 대 연결했는지, 그리고 동기화 타임스탬프요. Google이나 Apple 대신 시크릿 문구로 로그인하면 이메일 주소조차 알 수 없어요.
왜 사용자 이름과 비밀번호 대신 시크릿 문구를 쓰나요?¶
처음에는 거꾸로 가는 것처럼 느껴질 수 있지만, 시크릿 문구 하나가 더 강력한 구조예요. 사용자 이름과 비밀번호 방식에서 사용자 이름은 비밀이 아니라서(유출 데이터 덤프마다 등장하죠) 보안 전체가 비밀번호에 달려 있는데, 사람이 직접 고른 비밀번호의 엔트로피는 평균 대략 30~40비트 정도예요. 12단어 문구는 128비트가 보장되고, 기기가 생성하며, 사람이 고르지 않고, 다른 사이트에서 재사용된 적도 없어요.
저희가 잃어버릴 것도 없어요. 비밀번호 로그인은 서버가 최소한 비밀번호 해시를 저장한다는 뜻이고, 해시는 유출되거나 크랙되거나 피싱당할 수 있어요. 시크릿 문구는 기기를 떠나지 않아요. 암호화 키는 로컬에서 유도되고, 서버는 암호화된 데이터만 봐요. 훔칠 해시도 없고, 공격자가 악용할 비밀번호 재설정 절차도 없어요.
12단어 입력이 번거롭게 느껴진다면, 탭 한 번으로 문구를 비밀번호 관리자에 저장할 수 있어요(설정 > 보안 > 시크릿 문구). 그러면 로그인이 다른 서비스와 다를 게 없어요. 익숙한 방식을 선호하나요? Google이나 Apple 로그인도 지원하고, 그 경우에도 내부적으로는 여전히 시크릿 문구가 발급돼요.
편의와 프라이버시 사이의 균형을 직접 고를 수 있나요?¶
네, 의도적으로 그렇게 설계했어요. 모두가 같은 위협에 대비하는 것은 아니라서, 계정 모델은 하나의 원칙만 강요하는 대신 사다리처럼 단계로 이루어져 있어요. 어느 단계에서든 노트는 종단간 암호화돼요. 달라지는 것은 누가 키를 보관하는지, 그리고 저희가 여러분에 대해 무엇을 아는지예요.
가장 편한 단계: Google, Apple, GitHub로 로그인하고 선택 화면에서 "간단하게"를 고르는 거예요. 저희가 시크릿 문구를 대신 보관하고(서버에 저장될 때도 암호화된 상태로), 어떤 기기든 소셜 계정만으로 로그인되니 백업하거나 잃어버릴 것이 없어요. 정직한 트레이드오프: 소셜 계정 뒤의 이메일을 저희가 알게 되고, 서버가 완전히 침해당하면 이론상 보관된 키가 노출될 수 있어요. 현실적인 위협이 표적형 침해가 아니라 스스로 로그인 수단을 잃는 것이라면, 이건 합리적인 거래예요.
중간 단계: 소셜 로그인을 쓰되 "최대 프라이버시"를 고르는 거예요. 문구는 저희 서버에 절대 닿지 않고 암호화는 완전한 영지식이에요. 새 기기에는 문구를 입력하거나 이미 로그인된 기기에서 QR 코드를 스캔해야 해요. 소셜 계정의 이메일은 여전히 알 수밖에 없지만, 법적 강제가 있더라도 저희는 노트를 단 하나도 읽을 수 없어요.
가장 사적인 단계: 소셜 로그인을 아예 건너뛰고 12단어 문구만 쓰는 거예요. 이메일도, 이름도, 신원도 없고, 익명 Pro 구매와 조합하면 결제조차 어디에도 이름을 남기지 않아요. 그 대신 키 관리는 온전히 여러분의 몫이에요. 로그인된 기기가 하나도 없는 상태에서 문구를 잃으면, 아무도 도와줄 수 없어요.
이 래칫은 한 방향으로만 돌아가요. 위탁 보관에서 자가 보관으로는 언제든 올라갈 수 있지만(저희가 보관 중인 문구 사본을 삭제해요), 조용히 되돌아 내려가는 길은 없어요. 그리고 어느 단계에서든 로컬 보호 장치를 더할 수 있어요. PIN 앱 잠금, 생체 인식 잠금 해제, 노트별 보호까지요.
12단어 시크릿 문구로 충분히 안전한가요? Bitcoin 지갑처럼 24단어를 쓰지 않는 이유는요?¶
네, 12단어면 충분해요. 12단어 BIP-39 문구는 128비트의 엔트로피를 담아요. 128비트를 무차별 대입으로 뚫는 것은 "더 큰 컴퓨터가 필요한" 문제가 아니라 "인류가 생산하는 것보다 많은 에너지가 필요한" 문제예요. 128비트는 뚫는데 256비트에서는 실패하는 현실적인 공격은 존재하지 않아요.
Bitcoin과의 비교는 오히려 24단어가 대체로 마케팅에 가깝다는 것을 보여줘요. Bitcoin 키는 secp256k1 곡선 위에 있는데, 이 곡선 자체가 제공하는 보안이 약 128비트예요. 24단어 문구는 256비트의 엔트로피를, 뚫는 데 여전히 약 128비트의 작업량만 필요한 자물쇠에 넣는 셈이에요. 주요 지갑 다수가 지금도 12단어를 기본값으로 쓰는 이유이기도 해요.
PrivacyNotes는 처음부터 끝까지 동일한 128비트 보안 수준을 목표로 해요. 문구는 키 유도 함수를 거치고, 그 키가 보호하는 암호화(XChaCha20-Poly1305)도 같은 수준에 맞춰져 있어요. 24단어로 늘리면 적어 두고 입력할 양만 두 배가 될 뿐 실질적인 보안은 더해지지 않아서, 제공할 계획이 없어요.
어떤 시크릿 문구든 정직하게 말해 약점은 길이가 아니라 피싱, 그리고 적어 둔 종이를 보관하는 장소예요. 문구 자체만 잘 지키면 12단어는 우리 모두보다 오래 살아남을 거예요.
누군가 제 12단어를 맞히면 제 계정에 로그인할 수 있나요?¶
짧은 답: 네. 문구가 곧 열쇠라서, 문구를 가진 사람은 누구나 로그인할 수 있어요. 집 열쇠를 가진 사람이 누구든 문을 열 수 있는 것과 같아요. 이것은 의도된 설계예요. 문구는 노트를 여는 단 하나의 마스터 키이고, 그 앞에 더 약한 것이 놓여 있지 않아요. 그러니 진짜 질문은 문구를 가지면 접근할 수 있는지(맞아요, 할 수 있어요)가 아니라 누군가 그것을 맞힐 수 있는지인데, 그 답은 '아니요'예요. 현존하는, 그리고 예측 가능한 어떤 컴퓨터로도 불가능해요.
규모를 볼게요. 12단어 문구는 2^128가지 가능성 중 하나예요. 약 340간, 39자리 숫자죠(3.4 x 10^38). 첫 시도에 여러분의 문구를 맞힐 확률은 340간분의 1로, 3억분의 1짜리 복권 1등에 네 번 연속 당첨되는 것보다 희박해요. 요행이 아니라 전수 탐색으로 접근해도 소용없어요. 초당 100경 번(10^18, 국가 단위 공격자를 포함해 어떤 실제 하드웨어도 도달할 수 없는 속도)씩 시도해도 전부 훑는 데 약 10조 년, 현재 우주 나이의 800배 가까이 걸려요. 그리고 이것조차 환상 속 수치예요. 실제 시도는 매번 의도적으로 느리게 만든 키 유도 단계를 거쳐야 하고, 온라인 공격은 저희 서버를 통과해야 해서 실제 추측 속도는 여기서 다시 수십 자릿수 더 느려져요. 새로 고안한 방식도 아니에요. 같은 128비트 구조가 10년 넘게 Bitcoin 지갑을 지켜 왔고, 그동안 누구도 문구 하나를 맞힌 적이 없어요.
문구를 비밀번호처럼 생각해서 대문자, 숫자, 기호를 섞으면 더 강해진다고 상상하기 쉬워요. 시크릿 문구는 그런 식으로 동작하지 않고, 직접 만들거나 손으로 고치려 해서도 안 돼요. 기기가 암호학적으로 안전한 128비트의 무작위 값을 생성해 고정된 공개 목록의 2048개 단어 중 12개로 인코딩하는데, 그 무작위성이 강도의 전부예요. 마지막 단어에는 체크섬까지 내장되어 있어서 잘못 입력했거나 지어낸 문구는 그 자리에서 거부돼요. 단어 순서는 중요하지만 대소문자는 중요하지 않고(로그인할 때 정규화해요), 기호를 추가하면 문구가 무효가 될 뿐이에요. 발급된 그대로 정확히 입력하세요.
왜 2단계 인증(2FA)이 없나요?¶
빠뜨린 것이 아니라 의도적인 트레이드오프이기 때문이에요. 흔히 아는 2FA(문자로 받는 코드나 인증 앱)는 사람이 고른 약한 비밀번호를 보강하기 위해 존재하고, 서버에 보관되는 공유 비밀과 복구 경로에 기대요. 그것이 바로 시크릿 문구 모델이 제거하는 공격 표면이에요. 기기는 챌린지에 서명해서 키를 보유했음을 증명하고, 저희 서버는 공개 키와 서명만 받을 뿐 문구도 비밀번호 해시도 결코 받지 않아요. 그 위에 코드를 얹으면 이 설계가 피하려던 서버 측 장치를 다시 들여오게 되는데, 추측 공격을 막는 데는 아무것도 더해 주지 않아요. 128비트가 이미 그 문을 닫았거든요.
실제로 무언가를 더해 줄 수 있는 2차 인증은 하드웨어 보안 키나 패스키처럼 피싱에 강한 종류뿐이에요. 남아 있는 진짜 위험은 추측이 아니라 피싱, 멀웨어, 그리고 문구를 도난당하거나 어깨너머로 훔쳐보이는 상황이거든요. 잠그지 않고 둔 기기에서는 앱 잠금(PIN)과 생체 인식 잠금 해제가 로컬 방어선이 되어 줘요.
그 이상으로는, 문구가 곧 키이니 계정을 만든 그날 백업해 두세요. 신뢰할 수 있는 비밀번호 관리자에 보관하거나, 인쇄하거나 적어서 그 사본을 안전한 곳에 두세요. 앱 자체가 아닌 곳에는 절대 붙여 넣지 마세요.
Bitcoin 지갑과 같은 단어 목록(BIP-39)을 쓰나요?¶
네, 표준 BIP-39 영어 단어 목록이에요. 2048개 단어로, Bitcoin 지갑이 쓰는 것과 정확히 같은 목록이에요. 문구는 감사를 거친 오픈소스 라이브러리인 @scure/bip39로 생성해요. 자체 제작 단어 목록도, 직접 만든 암호화도 없어요.
이 목록은 손으로 적는 상황을 고려해 설계됐어요. 모든 단어는 앞 네 글자가 서로 달라서 번지거나 줄여 쓴 단어도 여전히 명확하고, 비슷해 보이는 단어는 의도적으로 제외됐어요.
표준 목록이기 때문에 어떤 공개 BIP-39 자료와도 문구를 대조해 볼 수 있고, 저희 암호화 계층은 오픈 코어로 공개되어 있어서 구현을 직접 확인할 수 있어요.
노트를 검색하면 서버로 무언가 전송되나요?¶
아니요. 검색은 기기에 만들어져 저장된 전문 색인을 대상으로 실행돼요. 검색어는 기기를 떠나지 않고, 인터넷 연결이 전혀 없어도 결과가 나오며, 무엇을 검색했는지에 대한 어떤 정보도 전송되지 않아요.
이것은 저희가 조용히 뒤집을 수 있는 정책상의 선택이 아니라 아키텍처가 강제하는 결과예요. 서버는 암호문만 보관하니, 저희 쪽에는 색인하거나 검색할 수 있는 읽기 가능한 데이터 자체가 없어요. 노트를 읽을 수 없는 서버는 노트를 검색할 수도 없어요.
PrivacyNotes는 제 노트에 AI를 사용하나요?¶
아니요. 앱에는 AI 기능이 없고, 백그라운드에서 도는 AI 처리도 없고, 여러분의 콘텐츠로 모델을 학습시키지도 않아요. 노트는 기기를 떠나기 전에 암호화되니, 저희 서버에는 무언가에 넣을 읽을 수 있는 데이터 자체가 없어요.
언젠가 이런 방향의 기능을 내놓는다면, 전적으로 기기에서만 실행되고 철저히 옵트인이어야 해요. 평문 노트를 클라우드 모델로 보내는 것은 영지식 약속을 깨는 일이라 고려 대상이 아니에요.
Burn note가 뭔가요?¶
Burn note는 PrivacyNotes를 쓰지 않는 사람에게 노트를 공유하는, 스스로 파기되는 방식이에요. 앱이 일회용 키로 내용을 암호화하고 링크를 만들어 줘요. 키는 링크의 프래그먼트에 담기는데, 브라우저는 프래그먼트를 서버로 절대 보내지 않아서 저희 서버는 읽을 수 없는 암호문만 저장해요.
링크가 처음 열리는 순간 서버는 암호문을 건네주면서 같은 단계에서 삭제해요. 한 번 읽히면 사라지는 거예요. 열리지 않은 링크는 24시간이 지나면 저절로 만료돼요. 어느 쪽이든 남는 것은 없어요.
PrivacyNotes는 오픈소스인가요?¶
여러분을 보호하는 부분은 이미 오픈소스예요. 암호화 코드, 데이터베이스 스키마, 위협 모델이 오픈 코어로 공개되어 있어서, 노트가 정확히 어떻게 보호되는지 저희 말만 믿는 대신 누구나 직접 감사할 수 있어요.
다음 차례는 앱이에요. 모든 플랫폼의 네이티브 앱이 출시되고 나면 클라이언트 코드(웹, 데스크톱, 모바일)를 오픈소스로 공개할 예정이에요. 비공개로 남는 유일한 부분은 동기화 백엔드인데, 백엔드에는 저희가 읽을 수 없는 암호화된 데이터 말고는 아무것도 없어요. 백엔드를 비공개로 두는 것은 프라이버시 측면에서 여러분에게 아무 비용도 지우지 않으면서, 누군가 서비스 전체를 복제해 저희 작업을 자기 것처럼 내놓는 일을 막아 줘요. 여러분을 보호하는 곳은 열고, 저희를 보호하는 곳은 닫았어요.