업로드를 위한 클라이언트 측 암호화 vs 서버 측 암호화

업로드된 문서에 대한 암호화 선택이 중요한 이유

앱에서 파일 업로드를 허용하면 단순한 “문서”를 저장하는 것이 아닙니다. 서명된 계약서, 여권 또는 운전면허 사진, 의료 양식과 검사 결과처럼 사용자의 또 다른 신원 정보가 저장됩니다. 파일은 작지만, 그에 따른 위험은 큽니다.

계약서가 유출되면 법적·재정적 문제가 발생할 수 있습니다: 가격이 공개되거나 서명이 복제되고 분쟁이 빠르게 악화될 수 있습니다. 신분증 스캔이 도난당하면 신원 도용과 계정 탈취로 이어질 수 있습니다. 의료 문서는 사적인 건강 정보가 소수의 사람들 외에 노출될 수 있어 피해가 큽니다. 한 번의 실수로 수년간 신뢰가 흔들릴 수 있습니다.

팀들은 종종 “암호화된 저장소”라고 말하면서 서로 다른 의미로 사용합니다. 때로는 업로드 연결이 암호화되어 있다는 의미(HTTPS)일 수 있고, 때로는 디스크에 저장될 때 암호화된다는 의미(저장 시 암호화)일 수 있으며, 사용자의 기기에서 파일을 암호화해 서버가 평문을 전혀 보지 못하게 한다는 의미(클라이언트 측 암호화)일 수도 있습니다. 이들은 서로 교환 가능한 개념이 아니며, 서로 다른 실패 상황을 방지합니다.

보안 선택은 일상적인 사용성과 지원에도 영향을 줍니다. 더 많은 프라이버시는 더 많은 마찰을 의미할 수 있습니다: 파일을 보려면 추가 단계가 필요하고, 공유가 어렵고, 검색과 미리보기가 제한되며, 기기나 키를 잃었을 때 복구가 고통스러워질 수 있습니다. 더 쉬운 접근은 인덱싱, 악성코드 검사, 미리보기, 비밀번호 재설정 같은 기능을 가능하게 하지만, 서버(및 이를 침해한 사람)가 볼 수 있는 범위를 넓힙니다.

작은 클리닉이 보험증 및 의료 PDF를 업로드한다고 상상해 보세요. 직원은 빠르게 파일을 찾아야 하지만, 관리 계정이 해킹됐을 때 피해를 줄이고 싶어 합니다. “올바른” 모델은 어떤 실패가 가장 큰 손해를 가져오는지와 사용자가 감내할 불편함에 따라 달라집니다.

빠른 정의: 클라이언트 측 암호화 vs 서버 측 암호화

실무적인 질문은 간단합니다: 파일이 언제 암호화되고 누가 나중에 복호화할 수 있는가?

서버 측 암호화는 파일이 백엔드에 읽을 수 있는 형태로 도착하고, 서버가 저장하기 전에 암호화한다는 뜻입니다. 이는 저장 시 암호화입니다: 누군가 드라이브를 훔치거나 스토리지 버킷에 원시 접근을 얻어도 데이터는 뒤섞여 있습니다. 서버는 필요할 때 파일을 복호화할 수 있습니다.

클라이언트 측 암호화는 파일이 업로드 전에 사용자의 기기(브라우저나 모바일)에서 암호화된다는 뜻입니다. 서버는 오직 암호문만 저장합니다. 정상적인 운영에서는 서버가 복호화 키에 접근하지 않으면 문서를 읽을 수 없습니다.

실제 구분선은 키 소유권입니다:

• 서버 측 암호화에서는 키를 백엔드가 관리합니다(종종 키 관리 서비스 사용). 백엔드는 권한 있는 사용자에게 파일을 복호화해 제공합니다.
• 클라이언트 측 암호화에서는 키가 사용자, 그들의 기기 또는 클라이언트에 보관된 비밀에 의해 통제되며, 백엔드는 주로 저장과 접근 규칙을 시행합니다.

두 모델 모두 인증과 권한 관리가 필요합니다. 암호화가 접근 제어를 대체하지는 않습니다.

사람들은 또한 “종단 간 암호화(end-to-end encryption)”를 다음처럼 사용합니다: 파일은 발신자의 기기에서 암호화되고 서버에 저장되는 동안 암호화된 상태를 유지하며, 승인된 수신자의 기기에서만 복호화됩니다. 이는 기밀성을 향상시킬 수 있지만, 서버 측 미리보기, 전체 텍스트 검색, 바이러스 검사, 쉬운 복구 등을 훨씬 어렵게 만듭니다. 위협 모델을 바꾸지 않는 한 말입니다.

위협 모델: 실제로 무엇을 막으려 하는가

암호화는 당신이 줄이려는 위험을 명확히 했을 때에만 도움이 됩니다. “의도한 사용자만 파일을 읽을 수 있게” 하려는 목표는 “스토리지가 유출될 때 피해를 줄이기”와는 다른 선택을 요구합니다.

계약서, 신분증, 의료 문서를 저장하는 앱에서 흔한 위협들은 다음과 같습니다:

• 도난당하거나 재사용된 비밀번호(계정 탈취)
• 과도한 내부자 접근(지원팀, 관리자, 계약직 직원)
• 클라우드 계정 침해나 잘못 구성된 스토리지 버킷
• 데이터베이스나 백업의 버그 또는 유출
• 사용자 기기의 악성코드

노출이 발생할 수 있는 지점을 구분하는 것도 도움이 됩니다:

• 전송 중: 기기에서 서버로 파일이 이동할 때
• 저장 중: 객체 스토리지, 데이터베이스 행, 백업, 로그
• 보기/처리 중: 미리보기, OCR, 검색, 변환 과정

핵심 차이는 다음과 같습니다. 서버 측 암호화에서는 시스템이 복호화할 수 있으므로 미리보기, 검사, 인덱싱이 가능합니다. 클라이언트 측 암호화는 서버가 암호문만 저장하므로 서버 침해나 내부자 접근의 영향 범위를 줄이는 경향이 있습니다.

암호화가 모든 것을 막지는 못합니다. 기기가 감염되면 악성코드가 암호화 전이나 복호화 후의 파일을 훔칠 수 있습니다. 문서를 볼 수 있는 사람은 스크린샷을 찍거나 재공유하거나 인쇄할 수도 있습니다.

각 모델이 무엇을 막아주고 무엇을 막아주지 못하는지

비교할 때 유용한 질문은: 어느 시점에서 누가 평문을 볼 수 있는가? 그 대답이 침해 영향, 내부자 위험, 백업 안전성 등을 결정합니다.

서버 측 암호화에서는 서버 침해가 많은 것을 드러낼 수 있습니다. 백엔드는 미리보기 생성, 바이러스 검사, 검색 지원, 공유 처리 등을 위해 복호화 키에 접근하거나 요청할 수 있기 때문입니다. 최악의 경우 공격자가 저장된 데이터와 키 접근을 모두 얻으면 모든 것을 복호화할 수 있습니다.

클라이언트 측 암호화에서는 인프라가 침해되더라도 공격자는 암호화된 블롭만 훔치는 경우가 많고, 사용자 키가 없다면 해당 블롭은 쓸모가 크게 떨어집니다.

내부자 접근에서 차이가 가장 분명해집니다. 서버 측 암호화에서는 권한 있는 직원, 클라우드 관리자, 또는 침해된 지원 계정이 애플리케이션을 가장하거나 스토리지에서 문서를 조회해 접근할 수 있습니다. 클라이언트 측 암호화에서는 인프라는 파일을 저장하고 이동할 수는 있지만 키가 제공되지 않는 한 내용을 읽을 수 없습니다.

클라이언트 측 암호화가 해킹된 기기를 해결해주지는 않습니다. ID나 의료 PDF처럼 높은 위험의 업로드에는 기기 보안과 계정 보호가 저장 암호화만큼 중요합니다.

또한 "파일 저장소 밖"에서 발생하는 유출을 주의하세요. 많은 사고는 다음을 통해 발생합니다:

• 복호화된 파일이나 키를 캡처하는 백업과 스냅샷
• 파일 이름, 메타데이터, 추출 텍스트를 기록한 로그
• 썸네일, 미리보기, 검색 인덱스
• 이메일, 채팅, 티케팅 도구로의 내보내기
• 업로드나 변환 중 생성된 임시 파일

사용자가 즉시 느끼는 UX 트레이드오프

가장 큰 차이는 수학적 문제가 아닙니다. 사용자가 쉽게 할 수 있는 것과 어려워지는 것입니다.

서버 측 암호화는 보통 보이지 않게 작동합니다. 사용자는 로그인하고 업로드하면 즉시 미리보기를 볼 수 있습니다. 지원팀은 접근을 재설정할 수 있습니다. 관리자는 누군가 결근했을 때 보통 권한을 재할당할 수 있습니다.

클라이언트 측 암호화는 온보딩과 일상 업무를 바꿉니다. 사용자는 더 강한 암호문구, 기기에 저장된 로컬 키, 혹은 추가 잠금 단계를 필요로 할 수 있습니다. 기기를 교체하거나 브라우저를 초기화하거나 앱을 재설치하면 접근이 끊길 수 있으므로 키 백업과 복구를 계획해야 합니다.

계정 복구는 팀들이 자주 놀라는 지점입니다. 만약 오직 사용자가 복호화 키를 보유하고 있다면 "비밀번호 잊음"은 "접근 영구 손실"로 이어질 수 있습니다. 복구 키나 에스크로 플로우를 추가할 수 있지만, 그것이 의미하는 바를 정직하게 설명해야 합니다.

공유도 더 복잡해집니다. 서버 측 암호화에서는 공유가 주로 권한 문제입니다. 클라이언트 측 암호화에서는 대개 키 공유가 수반되며, 철회와 기존 복사본의 처리 같은 문제를 다뤄야 합니다.

검색과 편의 기능은 어딘가에서 복호화를 강요할 수 있습니다. 전체 텍스트 검색, 미리보기, OCR은 서버가 파일을 읽을 때 가장 쉽습니다. 엔드투엔드 스타일의 프라이버시를 원한다면 클라이언트 측 OCR, 로컬 인덱싱 또는 파일 이름과 태그 같은 제한된 검색을 도입해야 합니다.

예: 클리닉이 검사 PDF를 업로드하고 스캔 내부의 환자 이름을 찾기 위해 OCR이 필요하다고 합시다. 서버 측 암호화는 빠른 OCR과 검색을 지원합니다. 클라이언트 측 암호화는 기기 쪽으로 이 작업을 옮기게 되어 웹과 모바일 전반에 걸쳐 지원하기 더 어렵고 느려질 수 있습니다.

문서 유형별 필요 사항: 계약서, 신분증, 의료 기록

최선의 선택은 파일 유형보다는 워크플로우에 더 많이 달려 있습니다: 누가 읽어야 하는지, 얼마나 빨리, 얼마나 자주, 얼마나 오래 인가요?

계약서

계약서는 보통 검토, 수정, 승인, 감사 추적을 포함합니다. 팀은 신뢰할 수 있는 검색, 공유, 보존 규칙을 원합니다.

제품 내에서 협업 검토를 지원한다면 서버 측 암호화가 실용적인 기본 선택인 경우가 많습니다. 시스템이 미리보기 렌더링, 검색 실행, 역할 기반 접근을 사용자에게 키 관리를 요구하지 않고도 수행할 수 있기 때문입니다.

클라이언트 측 암호화는 최종 서명된 PDF를 소수의 임원 그룹처럼 단순 보관하는 금고(vault) 용도에서는 맞을 수 있습니다. 다만 클라이언트 측 도구를 추가하지 않으면 편의성이 약해집니다.

신분증(여권, 운전면허)

신분증은 위험이 크지만 보관 기간이 짧은 경우가 많습니다. 많은 팀은 확인이 끝나면 즉시 삭제합니다. 워크플로우는 빠른 조회와 엄격한 처리 규칙을 요구하지, 협업을 요구하지는 않습니다.

일반적인 접근은 엄격한 접근 통제, 강한 감사 로그, 짧은 보존 기간을 결합한 서버 측 암호화입니다. 지원 직원이 절대 ID를 볼 수 없어야 한다면 클라이언트 측 암호화를 고려할 수 있지만, 그 경우 확인을 완료할 다른 방법이 필요합니다.

의료 문서

의료 기록은 더 강한 프라이버시 기대가 있습니다. 사용자들은 보통 최소한의 사람만 볼 수 있을 것이라고 기대합니다.

클라이언트 측 암호화는 서버가 침해되거나 관리자가 오용될 경우 노출을 줄일 수 있습니다. 하지만 비밀번호 재설정, 기기 변경, 긴급 접근 같은 실무적 문제를 실제로 복잡하게 만듭니다.

선택하기 전에 각 문서 유형을 워크플로우에 매핑하세요:

• 누가 읽어야 하는가(어디에서)?
• 얼마나 빨리 로드되어야 하는가?
• 얼마나 오래 보관하는가?
• 어떤 제품 기능이 중요한가(미리보기, 검색, 자동 삭제 등)?

선택 방법: 단계별 의사결정 프로세스

먼저 당신이 저장하는 것과 누가 만지는지를 적어보세요. 단순히 "uploads" 폴더가 있는 것만으로는 정책이 아닙니다.

1단계: 단순히 '사용자'가 아니라 접근을 매핑하세요

역할을 나열하고 두 가지 질문에 답하세요: 누가 파일을 열어야 하는가, 그리고 누가 절대 열어선 안 되는가(관리자 포함)? 보존 기간도 이때 포함시키세요.

2단계: 위협 가정 선택

당신이 방어하려는 바를 솔직히 적으세요.

• 내부자 위험이 가장 큰 걱정이라면 클라이언트 측 암호화가 매력적입니다.
• 기기 분실과 비밀번호 재설정이 흔하다면 복구 복잡성에 비용을 치르게 됩니다.

그다음 경험을 압박 테스트하세요:

1. 복구 및 지원: 누군가 비밀번호를 잊거나 휴대폰을 잃으면 어떻게 되는가? 복구가 필요하면 순수한 클라이언트 측 암호화는 적합하지 않을 수 있습니다.

2. 필수 기능: 미리보기, 검색, OCR, 전자 서명, API 기반 처리 같은 기능이 필요한가? 이러한 기능은 흐름 어딘가에서 서버 측 복호화를 요구하는 경우가 많습니다.

3. 감사 및 규정 준수: 누가 언제 무엇을 봤는지 분명한 로그가 필요한가? 두 모델 모두 로그는 가능하지만, 클라이언트 측 디자인은 "우리는 도와줄 수 없다"는 결과를 피하려면 추가 고려가 필요합니다.

대부분의 팀은 하이브리드 방식을 선택합니다: 대부분 문서는 서버 측 암호화로 처리하고, 직원이 절대 볼 수 없어야 하는 소수의 문서만 클라이언트 측 암호화를 적용합니다.

흔한 실수와 함정

가장 큰 함정은 암호화를 전부인 것처럼 다루는 것입니다. 프라이버시와 규정 준수는 누가 데이터에 접근할 수 있는지, 접근 승인 방식, 기록되는 로그, 보관 기간, 삭제 요청 처리 방식에도 달려 있습니다.

두 번째로 큰 실수는 복구 계획 없는 클라이언트 측 암호화를 구축하는 것입니다. 사용자가 기기를 잃거나 암호문구를 잊거나 회사를 떠나면 복구할 수 있는가? 개인 금고라면 "우리는 도와줄 수 없다"가 허용될지 모르지만, 비즈니스 앱에서는 보통 실패합니다.

이러한 실수는 실제 유출과 회피를 초래합니다:

• 관리자에게 모든 것을 보는 숨겨진 경로를 주거나 지원팀이 사용자를 가장해 접근하게 하되 엄격한 로그와 2인 승인 절차가 없는 경우
• 브라우저나 앱에서 복호화한 뒤 복사본을 남기는 경우(캐시된 미리보기, 임시 다운로드, 동기화 폴더)
• "보안" 문서를 나중에 안전하지 않은 채널로 보내는 경우(이메일로 PDF 전송, 채팅에 스크린샷 붙여넣기, 티켓에 파일 첨부)
• 보안 절차가 너무 불편해서 사용자가 개인 드라이브로 이동하거나 화면을 사진 찍어 저장하게 되는 경우
• "저장 시 암호화"만으로 동의, 접근 이력, 보존 및 침해 보고 요구사항을 자동으로 충족한다고 가정하는 경우

예: 클리닉이 intake 양식을 암호화했지만 직원이 청구 리포트를 내보내 로컬의 암호화되지 않은 폴더를 만들면, 그 폴더가 공유 드라이브로 백업됩니다. 유출은 암호화가 아니라 워크플로우에서 발생합니다.

결정하기 전에 확인할 체크리스트

한 문장으로 적어보세요: 누가 이 파일을 읽어야 하고, 누가 절대 읽어선 안 되는가(서버에 접근권을 가진 사람이더라도).

그다음 확인하세요:

• 누가 언제 복호화할 수 있는가? 정확한 역할과 조건을 나열하세요. 정책이 "업로더만"이라면, 공유 키 같은 백도어를 조용히 추가하지 마세요.
• 빠르게 접근을 취소할 수 있는가? 오프보딩(퇴사)은 진짜 시험입니다. 접근이 계정에 묶여 있는가, 기기에 묶여 있는가, 그룹에 묶여 있는가를 결정하세요.
• 기기 분실 또는 비밀번호 재설정 후 어떻게 되는가? 복구가 필요하면 강력한 승인으로 보호하세요.
• 미리보기, 바이러스 검사, OCR이 필요한가? 그렇다면 복호화가 어디에서 일어나는지, 누가 트리거할 수 있는지 계획하세요.
• 감사 로그가 충분히 구체적인가? "조회"와 "다운로드"는 무엇인지 정의하고 사용자, 시간, 기기, 이유를 캡처하세요.

예시 시나리오: 신분증과 의료 PDF를 저장하는 소규모 팀

작은 클리닉이 직원이 환자 소개서(PDF)와 보험증 사진을 업로드하는 앱을 운영합니다. 목표는 문서를 적절한 사람에게 빠르게 전달하면서, 기기 분실, 계정 침해, 또는 클라우드 실수로 인한 피해를 줄이는 것입니다.

실행 가능한 한 가지 접근은 엄격한 역할 분리를 적용한 서버 측 암호화입니다. 파일은 저장 시 암호화되고 권한으로 접근을 통제합니다: 프런트 데스크는 업로드, 청구 부서는 신분증 열람, 임상 담당자는 소개서 열람 등입니다. 이는 직원이 데스크탑이나 모바일에서 추가 단계 없이 문서를 열 수 있고, 감독자가 부재 시 권한을 재할당하기 쉬워 일상 운영에 편리합니다.

다른 접근은 가장 민감한 항목에 대해 클라이언트 측 암호화를 사용하는 것입니다. 파일이 업로드 전에 기기에서 암호화되면 서버는 암호문만 저장합니다. 이는 서버 침해와 내부자 접근의 영향을 줄일 수 있지만 운영을 다음과 같이 바꿉니다:

• 비밀번호 재설정은 서버 측 암호화에서 정상적으로 접근 복구를 허용하지만, 클라이언트 측 암호화에서는 키가 안전하게 백업되지 않으면 사용자가 접근을 잃을 수 있습니다.
• 직원 이직 관리는 서버 측 암호화가 더 간단합니다. 클라이언트 측 암호화에서는 문서 접근을 계속 가능하게 하려면 키 전송이나 에스크로 계획이 필요합니다.

사용자들은 공유, 모바일 접근, 분실폰 후 복구에서 마찰을 느낍니다. 이런 세부가 암호화 모델만큼 중요합니다.

다음 단계: 결정하고, 정책을 문서화하고, 구현하세요

먼저 위협 가정을 평범한 언어로 적으세요. 위험을 충족하는 가장 단순한 접근을 선택하고, 문서가 진짜로 필요하다고 판단되는 곳에서만 강화하세요.

결정을 짧은 내부 규칙집으로 정리하세요:

• 허용되는 파일 유형과 저장 위치
• 누가 어떻게 접근하고 공유를 승인하는지
• 보존 및 삭제 규칙
• 비밀번호 재설정 및 기기 분실 후 복구 절차
• 내보내기(다운로드, 이메일, 메시징) 처리 및 차단 시점

그다음 역할 검사, 감사된 액션(조회, 다운로드, 공유), 안전한 미리보기, 신중한 키 관리를 중심으로 구현을 설계하세요.

AppMaster (appmaster.io) 같은 노코드 플랫폼에서 구축 중이라면 역할과 승인 흐름을 조기에 모델링해 놓고 요구사항이 바뀔 때 전체 앱을 다시 작성하지 않고 조정할 수 있도록 하면 도움이 됩니다. 중요한 점은 실제 사용자에게 안전한 경로를 쉬운 경로로 만드는 것입니다.