서버 측 vs. 클라이언트 측 암호화: 어떤 모델을 신뢰해야 할까?

서버 측 암호화는 평문을 수신한 후 서버에서 데이터를 암호화하므로 서비스 제공자를 신뢰해야 한다. 클라이언트 측 암호화는 데이터를 전송하기 전에 브라우저에서 암호화하므로 서버는 평문을 절대 볼 수 없다. 비밀 공유에서는 클라이언트 측 암호화가 더 안전한데, 서비스 자체를 신뢰 지점에서 제거하기 때문이다 — 서버가 침해되더라도 데이터를 읽을 수 없다.

이 글은 두 방식을 비교한다: 각각의 작동 방식, 신뢰를 요구하는 대상, 그리고 실제 트레이드오프가 어디에 있는지. 한쪽 편을 드는 주장이 아니라, 어떤 모델이 자신의 위협 모델에 맞는지 평가하는 프레임워크다.

클라이언트 측 암호화가 중요한 이유에 대한 빠른 개요는 이전 글을 참고하고, Vaulted의 구체적인 구현에 대한 자세한 내용은 zero-knowledge 심층 분석을 참고하자.

서버 측 암호화의 작동 방식

서버 측 모델에서는 서비스가 사용자를 대신해 암호화를 처리한다. 일반적인 흐름:

브라우저에서 비밀을 입력한다
브라우저가 평문을 TLS를 통해 서버로 전송한다
서버가 자체적으로 관리하는 키를 사용해 데이터를 암호화한다
암호문이 데이터베이스에 저장된다
수신자가 비밀을 요청하면 서버가 복호화하여 평문을 반환한다

암호화 키는 서버를 절대 떠나지 않는다. HSM(Hardware Security Module), 클라우드 KMS(Key Management Service), 또는 설정 파일에 있을 수 있지만 — 서버가 완전히 제어한다.

서버 측 신뢰 모델

서버 측 암호화에서는 다음을 신뢰해야 한다:

서비스 운영자가 데이터를 읽지 않는다는 것 (암호화/복호화 과정에서 키와 메모리 내 평문을 보유함)
인프라가 침해되지 않는다는 것 (서버가 침해되면 키와 데이터 모두 노출됨)
운영자의 직원들이 접근 권한을 남용하지 않는다는 것 (서버 접근 권한이 있는 누구나 비밀을 잠재적으로 읽을 수 있음)
법적 관할권이 공개를 강제하지 않는다는 것 (운영자는 키를 보유하므로 데이터 제출을 강제당할 수 있음)
서버 로그와 모니터링이 평문을 캡처하지 않는다는 것 (로깅 프레임워크가 민감한 데이터를 의도치 않게 기록할 수 있음)

이것이 반드시 나쁜 모델은 아니다. 많은 서비스가 성공적으로 사용하고 있다 — 클라우드 스토리지, 이메일 제공업체, 데이터베이스 서비스 모두 서버 측 암호화에 의존한다. 문제는 이 트레이드오프가 자신의 사용 사례에 맞는지 여부다.

클라이언트 측 암호화의 작동 방식

클라이언트 측 모델에서는 데이터가 서버에 도달하기 전에 브라우저에서 암호화가 이루어진다. 흐름이 다르다:

브라우저에서 비밀을 입력한다
브라우저가 암호화 키를 생성하고 데이터를 로컬에서 암호화한다
암호문만 서버로 전송된다
암호화 키는 별도 채널(보통 URL 프래그먼트)을 통해 수신자에게 전달된다
수신자의 브라우저가 암호문을 로컬에서 복호화한다

서버는 평문을 절대 보지 못하고 암호화 키를 보유하지 않는다. 암호화된 데이터 덩어리를 저장하고 검색할 뿐이다 — 그 이상은 없다.

Vaulted는 이 모델을 사용한다. 각 비밀에는 새로운 AES-256-GCM 키가 생성된다. 키는 URL 프래그먼트(#)에 배치되는데, RFC 3986에 따라 브라우저는 이를 HTTP 요청에 포함하지 않는다. 서버는 암호문과 저장을 위한 12바이트 랜덤 IV를 수신하지만, 키는 송신자와 수신자 간에 공유되는 링크 안에만 존재한다.

클라이언트 측 신뢰 모델

클라이언트 측 암호화에서는 다음을 신뢰해야 한다:

브라우저가 암호화를 올바르게 구현한다는 것 (Web Crypto API는 BoringSSL이나 NSS 같은 네이티브 암호화 엔진에 위임함)
애플리케이션 코드가 실제로 클라이언트 측에서 암호화를 수행한다는 것 (네트워크 요청을 검사하여 확인 가능)
링크 전달 채널이 안전하다는 것 (프래그먼트를 포함한 전체 URL을 가진 사람은 누구나 비밀을 복호화할 수 있음)
수신자의 기기가 침해되지 않았다는 것 (복호화 후 악성 소프트웨어나 화면 캡처가 평문에 접근할 수 있음)

서버, 서비스 운영자, 직원, 법적 관할권은 신뢰하지 않아도 된다. 서버는 읽을 수 없는 암호화된 데이터를 위한 저장 릴레이다.

트레이드오프 비교

어느 모델이 보편적으로 더 낫다고 할 수 없다. 각각은 보안, 사용성, 기능 풍부함 사이에서 서로 다른 트레이드오프를 한다.

보안 특성

특성	서버 측	클라이언트 측
서버 침해 시 노출	키 + 암호문 노출	암호문만 노출 (키 없이는 무용지물)
운영자의 데이터 열람	가능 (키를 보유함)	불가능 (키를 보유하지 않음)
법적 강제 공개 위험	운영자가 응할 수 있음 (접근 권한 있음)	운영자가 응할 수 없음 (접근 권한 없음)
링크 탈취 위험	해당 없음 (링크에 키 없음)	전체 URL = 완전한 접근 (패스프레이즈로 완화 가능)
중간자 공격	TLS가 전송 보호; 서버는 평문을 봄	TLS가 암호문 보호; 프래그먼트의 키는 전송되지 않음

사용성 특성

특성	서버 측	클라이언트 측
키 관리 부담	사용자에게 없음 (서버가 처리)	사용자가 링크를 안전하게 공유해야 함
비밀번호 복구	가능 (서버가 키 보유)	불가능 (키는 링크에만 존재)
검색 및 색인	서버에서 평문 검색 가능	복호화 없이는 불가능
공유 유연성	서버가 새 수신자를 위해 재암호화 가능	수신자마다 새 링크 필요
오프라인 접근	복호화를 위해 서버 연결 필요	암호문과 키가 로컬에 캐시된 경우 가능

기능 트레이드오프

기능	서버 측	클라이언트 측
콘텐츠 감사 로깅	가능	불가능 (서버가 콘텐츠를 읽을 수 없음)
콘텐츠 기반 정책	가능 (DLP, 컴플라이언스 스캔)	복호화 없이는 불가능
키 교체	서버가 새 키로 재암호화 가능	링크 재생성 및 재공유 필요
다자 접근 제어	서버가 사용자별 키 관리 가능	각 수신자가 키를 직접 받아야 함
Zero-knowledge 보장	없음	있음

서버 측 암호화가 적합한 경우

서버 측 암호화가 합리적인 선택인 경우:

서비스 운영자와 그 보안 관행을 신뢰할 때
서버 측 데이터 접근이 필요한 기능(검색, 공유, 컴플라이언스 스캔)이 필요할 때
데이터 민감도가 클라이언트 측 암호화의 사용성 비용을 정당화하지 않을 때
규제된 환경에서 운영자의 컴플라이언스 인증이 zero-knowledge 보장보다 중요할 때
키 관리의 복잡성을 사용자가 아닌 서비스가 처리해야 할 때

클라우드 스토리지 서비스, 기업 이메일, 관리형 데이터베이스 암호화 모두 이 모델을 효과적으로 활용한다.

클라이언트 측 암호화가 필요한 경우

클라이언트 측 암호화가 필요한 경우:

서비스 운영자에게 데이터를 맡길 수 없거나 맡겨서는 안 될 때
서버 침해 시 평문이 노출되어서는 안 될 만큼 데이터가 민감할 때
zero-knowledge 보장이 필요할 때 — 서버가 데이터를 읽을 수 없다는 수학적 증명
법적 또는 컴플라이언스 요건이 서비스 운영자의 콘텐츠 접근을 금지할 때
서비스 제공자 내부자 위협으로부터 보호가 필요할 때

비밀 공유는 클라이언트 측 암호화의 가장 강력한 사용 사례 중 하나다. 데이터는 본질적으로 민감하고(비밀번호, API 키, 자격증명), 공유는 일시적이며(조회 제한, 시간 제한), 신뢰 관계는 최소한이다(서비스 운영자를 모르거나 신뢰하지 않을 수 있음).

Vaulted의 접근 방식

Vaulted는 클라이언트 측 암호화만을 사용한다. 모든 비밀은 데이터가 서버에 도달하기 전에 브라우저에서 새로운 AES-GCM 키로 암호화된다. 키는 URL 프래그먼트에만 존재하며, 선택적 패스프레이즈 보호는 PBKDF2 키 파생과 AES-KW 키 래핑을 통해 두 번째 레이어를 추가한다.

서버는 만료 시간과 조회 카운터가 있는 암호화된 암호문을 저장한다. 콘텐츠를 복호화하거나, 검색하거나, 검사할 수 없다. 데이터베이스 전체가 침해되더라도 암호화된 데이터 덩어리만 나올 뿐이다 — 공유 링크에만 존재하는 키 없이는 계산적으로 무용지물이다.

키 생성, IV 처리, 패스프레이즈 래핑, 정확한 Web Crypto API 호출 등 전체 암호화 세부 사항은 zero-knowledge 암호화 심층 분석을 참고하자.

선택하기

올바른 암호화 모델은 무엇을 보호하고 누구를 신뢰할 의향이 있는지에 따라 다르다.

검색, 복구, 중앙화된 키 관리 같은 기능이 필요하다면 서버 측 암호화가 실용적인 선택이다. 아무도 — 서비스도, 그 직원도, 법원 명령도 — 데이터를 읽을 수 없다는 보장이 필요하다면 클라이언트 측 암호화만이 그것을 제공하는 유일한 모델이다.

비밀을 공유하는 경우 답은 명확하다: 데이터는 민감하고, 상호작용은 짧으며, 평문에 접근할 수 있는 당사자가 적을수록 좋다.

zero-knowledge 암호화로 비밀을 공유할 준비가 됐다면? Vaulted에서 비밀 만들기 — 데이터가 암호화되지 않은 채로는 브라우저를 절대 떠나지 않는다.

클라이언트 측 암호화가 중요한 이유 — 브라우저에서 암호화해야 하는 이유
Zero-Knowledge 암호화: Vaulted가 비밀을 비공개로 유지하는 방법 — 암호화 구현에 대한 심층 분석
Vaulted의 보안 — 보안 모델 요약