[1권 - 15장] 구글 드라이브 설계

[KimH4nKyul]

1부에서 그룹별로 생성된 질문을 2부 아고라 세션에서 논의해 볼 수 있도록 질문을 남겨주세요!
드디어 마지막 세션 "구글 드라이브 설계" 입니다.

[Cheondongmin]

동기화 충돌이 발생하는 대표적인 시나리오는 무엇이며,
실제 서비스에서는 어떻게 감지하고 처리할 수 있을까...

&&

사용자 경험(UX) 측면에서는 동기화 충돌을 어떻게 다루어야 할까

[Cheondongmin]

동기화 충돌

여러 곳(서버, 클라이언트 등)에서 동일한 데이터에 동시에 업데이트를 시도할 때 발생하는 문제임. 예를 들어, 두 명 사용자가 같은 문서를 동시에 수정하면 어느 한 쪽만 반영되거나 둘 다 반영될 수 없어 데이터가 엉망이 됨.

주요 포인트

동시 업데이트

여러 사용자가, 혹은 여러 노드가 동시에 같은 데이터를 수정하려고 할 때 발생함.
네트워크 지연, 분산 환경 특성 때문에 각 노드가 다른 업데이트를 동시에 처리함.

충돌 발생

서로 다른 업데이트 결과가 동시에 반영되면 어떤 변경 사항을 최종으로 적용할지 결정해야 함.
충돌 해결 없으면 데이터 불일치, 일관성 깨짐.

해결 전략

버전 관리

데이터마다 버전을 부여해 최신 상태 판단함.
예: 벡터 시계(vector clock) 사용, 각 노드의 업데이트 내역 기록하여 선후 관계 비교.

최종 일관성(Eventual Consistency)

충돌 발생 시 즉시 일관성을 보장하지 않더라도, 일정 시간이 지나면 모든 노드가 동일한 상태에 도달하도록 함.

병합 전략

자동 병합: 시스템이 충돌된 업데이트를 자동으로 병합함.
수동 병합: 사용자가 충돌을 인지하고 직접 수정함.

결론

동기화 충돌은 분산 시스템이나 협업 환경에서 불가피하게 발생하는 문제임. 이를 해결하기 위해 버전 관리, 충돌 감지 및 해결 알고리즘, 최종 일관성 모델 등을 사용하여 데이터 일관성을 유지해야 함.

[hyojin202406]

https://neil.fraser.name/writing/sync/

[renechoi]

위의 링크 요약이요 ㅋ

Neil Fraser의 “Differential Synchronization” (2009) 논문은 여러 사용자가 동시에 하나의 문서를 편집할 때, 실시간 동기화를 효율적이고 견고하게 수행하기 위한 알고리즘(“차등 동기화”)을 제안합니다. 기존의 잠금(Locking), 이벤트 전달(Event Passing), 3-웨이 머지(Three-way Merge)
방식이 가지고 있는 문제점을 지적하고, ‘끊임없이 diff(차이)’를 추출하고 이를 기반으로 양방향 patch(반영) 하는 접근을 통해 충돌과 네트워크 불안정 상황에서도 문서를 최대한 즉각적이고 일관성 있게 공유·동기화할 수 있도록 설계되었습니다. 주요 내용을 간략히 정리하면 다음과 같습니다.

---

1. 기존 기법의 문제점

1. 잠금(Locking)

   • 한 사람이 문서를 수정할 때 다른 사람의 편집을 막는 방식.
   • 세밀하게 섹션별 Lock을 해도 동시 협업이 제한되며, 네트워크가 불안정하면 잠금 해제 신호가 누락되어 영구 락이 발생할 수 있음.

2. 이벤트 전달(Event Passing)

   • 사용자의 모든 편집 이벤트(입력, 삭제, 붙여넣기 등)를 실시간으로 다른 쪽에 전달.
   • 한 번 이벤트 전달이 실패하거나 순서가 꼬이면 이후 편집 내용 전체가 연쇄적으로 틀어질 위험이 큼.
   • 근래에는 OT(Operational Transformation)나 CRDT 등을 활용하긴 하지만, 브라우저 환경 등에서는 풍부한 UI 이벤트를 전부 포착·동기화하기가 어려움.

3. 3-웨이 머지(Three-way Merge)

   • Subversion 등에서 사용하는 방식으로, 일정 시점에 문서 전체를 서버로 보내고, 서버가 병합 후 다시 클라이언트에게 결과를 전송.
   • 사용자가 타이핑 중에는 다른 사람의 수정이 즉각 반영되지 않고, 머지 완료 후에야 적용되어 실시간성이 떨어짐.
   • 충돌이 잦은 환경에서는 “수정하다가 전송 → 새 버전 수신 → 재수정”의 반복 충돌이 발생해 비효율적.

---

2. 차등 동기화(Differential Synchronization)란?

1. 끊임없는 ‘diff → patch’ 사이클

   • 문서(클라이언트 측)와 그림자(Shadow), 그리고 서버 측 문서를 두고,
   • “클라이언트 문서 - 그림자” 차이를 추출(diff)한 뒤 이를 서버 문서에 반영(patch)하는 과정을 지속 반복.
   • 서버에서도 동일한 과정을 반대로 수행하여, 결국 양측 문서를 끊임없이 서로 비슷하게 맞춰가는(수렴) 방식.

2. fuzzy patch(퍼지 패치)

   • 문서가 이미 다른 변경사항을 포함해 부분적으로 달라져 있어도, 맥락(Context)을 기준으로 수정사항을 적용할 수 있도록 고안.
   • 일부 패치가 실패해도, 다음 diff/patch 단계에서 실패분이 다시 인식되어, “실패한 패치 되돌리기” 또는 “충돌 부분 다시 반영”이 자동으로 이루어짐.
   • 즉, 어느 한 번의 동기화에서 100% 정확히 맞출 필요 없이, 지속적으로 교정하며 최종적으로 동기화 상태를 유지.

3. 듀얼 섀도(Dual Shadow) 구조

   • 실제 네트워크/클라이언트-서버 구조에서는, 서버와 클라이언트 각각이 자기 ‘Shadow’를 유지해, 상대방과의 동기화에서 서로 독립적인 버전을 보관.
   • 만약 네트워크 패킷 누락 등 문제가 생겨도, 섀도 간 버전/체크섬이 어긋나면 문서 전체를 재전송해 자체 복구(Self-Healing) 가능.

---

3. 네트워크 장애 대응 & 확장성

1. 보장 전달(Guaranteed Delivery) 메커니즘

   • 패킷이 유실되거나 응답이 지연될 때, 서버/클라이언트가 서로 **백업 섀도(Backup Shadow)**를 두어,
   • 중간에 누락된 패치가 재전송되거나, 충돌 발생 시 백업 상태로 되돌아가 다시 동기화.

2. 동기화 토폴로지(Topology)

   • 1:1이 아니라 서버 중심으로 여러 클라이언트를 붙일 수 있고, 서버 간 동기화(서버-서버) 네트워크도 구성 가능.
   • 부하분산(Load Balancing): diff/patch 계산 비용이 커지면 여러 서버로 나누거나, 서버 간에 트리 구조로 연결하여 확장성을 높임.
   • 주기적 동기화 주기를 **적응형(Adaptive)**으로 조정해, 편집이 활발할 때는 자주 동기화하고, 조용할 때는 간격을 늘려 성능과 네트워크 부하를 최적화.

---

4. 핵심 특징 및 장점

1. 항상 실시간에 가깝게 수렴

   • “편집을 멈추고 대기해야 하는” 순간 없이, 동시에 여러 사용자가 문서에 변경을 가해도, 지속적으로 diff/patch를 교환하며 점진적으로 일치 상태에 가까워짐.

2. 오류·충돌에 강함 (Self-Healing)

   • 일부 패치가 실패하거나, 패킷이 누락되어도, 이후 반복 diff/patch 과정에서 자동으로 발견 및 수정.
   • “동시에 다른 부분을 수정했다면 모두 반영하고, 같은 부분을 다르게 수정했다면 충돌이 발생하지만, 계속된 반복 패치로 ‘어느 한쪽 수정’을 선택하거나 사용자가 수동으로 해결”이 가능.

3. 간단한 구현 & 범용성

   • 문서 형식(Plain text, HTML, 바이너리 등)에 맞는 diff/patch 알고리즘만 제공하면 적용 가능.
   • 편집 이벤트 추적 없이도 “현재 버전 vs. 그림자” 차이를 비교해내므로, 브라우저/네트워크 환경에서 구현이 용이.

---

5. 요약

Neil Fraser가 제안한 차등 동기화(Differential Synchronization) 알고리즘은,

• 문서를 상시 diff하고,
• 이를 fuzzy patch로 상대방에게 적용한 뒤,
• 실패나 충돌이 생기면 다음 사이클에서 재차 보정하도록 만들어,
  동시에 여러 사용자가 편집해도 문서가 거의 실시간으로 일관성을 유지하게 돕는 방법입니다.

기존 잠금, 이벤트 기반, 3-way 머지 방식이 지니는 단점(실시간성 부족, 충돌 시 복잡한 재처리, 네트워크 장애 대응의 어려움)을 해결하고,

• 안정적인 네트워크/서버 확장
• 부분 실패나 패킷 유실에도 자가 치유(Self-Healing)
• 실시간 협업에 적합
  하도록 설계된 점이 핵심입니다.

실제 예시는 Google Wave, MobWrite, Google Docs 등 다양한 협업 편집 시스템(OT, CRDT 혼합 사례)에도 적용되어 왔으며,
이 논문에서 제안한 알고리즘 자체는 텍스트뿐 아니라 다양한 형식(이미지, 벡터 그래픽 등)에도 diff/patch만 마련되면 확장 가능하다는 장점을 지닙니다.

[renechoi]

diff 를 판단하는 것도 비용 아닐까? 그 비용의 복잡도는?

[renechoi]

네, diff 연산을 수행하는 것 자체도 비용이 듭니다.
파일(또는 문서)의 크기에 비례해서 diff 계산에 O(n) 이상의 시간 복잡도가 걸리는 것은 당연합니다. 특히 텍스트의 경우, 전통적인 diff 알고리즘(예: Myers algorithm)은 최악의 경우 O(n×m) (두 텍스트 길이가 n, m일 때)으로 동작합니다. 이 비용은 실시간 협업 시스템에서는 무시하기 어려운 부담이 될 수 있습니다.

---

1. Differential Synchronization에서의 diff 비용 문제

Neil Fraser의 논문 “Differential Synchronization”에서 제안된 방식은 끊임없이 diff를 수행하여 변경사항을 추출하고 이를 상대편에 patch로 전달하므로,

• 변경이 아주 빈번하면 매번 diff를 계산해야 해서 연산 비용이 커질 수 있습니다.
• 이 때문에, diff를 얼마나 자주 계산할지(동기화 주기) 혹은 diff를 효율화하는 알고리즘을 어떻게 적용할지가 매우 중요해집니다.

(1) 변경이 적을 때의 이점

• 변경이 실시간으로 작은 단위로 축적될 때, diff해야 할 텍스트 구간 자체가 짧아질 수 있으므로, 실제 연산 부담이 줄어듭니다.
• 예컨대, “이전 sync 이후로 10자 정도만 달라진 상태”라면, 그 차이를 찾는 데 드는 비용이 n×m 전체 문서 크기에 비해 훨씬 작아질 수 있음.

(2) 변경 사항이 누적되는 경우

• 동기화 주기가 길어지거나, 사용자 활동이 활발하여 변경이 크게 누적되면, 단일 diff 연산 비용이 커질 수 있습니다.
• 논문에서는 “적응형(Adaptive) 동기화” 전략으로, 변경이 활발할수록 diff 주기를 자주 하고, 조용하면 주기를 길게 가져가서 전체 부담을 조절하자고 제안합니다.

---

2. 성능 최적화 방안

1. 적응형(Adaptive) 동기화 간격

   • 사용자의 편집이 활발할 때는 짧은 간격으로 동기화 → 각 diff에서 변경 범위가 작아 연산 부담 감소.
   • 편집이 거의 없으면 동기화 간격을 늘려서 불필요한 diff 연산을 줄임.

2. 부분 diff 및 캐싱

   • 텍스트가 매우 큰 경우, 마지막 diff 당시의 해시나 체크섬을 저장해두고,
   • 변경 여부가 의심되는 특정 범위만 부분적으로 diff하는 기법 활용.
   • 예: 파일을 블록 단위로 나누어, 변경된 블록만 diff를 계산.

3. 빠른/근사 diff (Heuristic)

   • Myers 알고리즘처럼 정교하지만 비용이 큰 알고리즘 대신,
   • 휴리스틱(Heuristic) 기반의 대략적인 diff로 빠르게 “어느 지점이 크게 달라졌는지”를 찾아내고, 세밀한 부분에만 정교한 알고리즘을 적용.

4. 실시간 편집 이벤트를 약간 활용

   • 완전히 이벤트 기반(OT)으로 가면 복잡도가 커지지만,
   • 텍스트 필드에서 타이핑이나 마우스 커서 이동 같은 가벼운 단서를 일부 추적해, “어느 부분이 수정 중인지”를 파악할 수 있음.
   • 이렇게 특정 구간만 diff를 먼저 시도해보도록 최적화.

5. 서버 측 부하 분산

   • 다수 사용자가 동시에 편집하면 서버(또는 협업 시스템)가 diff/patch를 처리해야 하는 횟수가 많아짐.
   • 여러 서버를 두고 부하를 분산하거나, 서버-서버 간 동기화도 Differential Sync 방식으로 구성해 큰 부하를 분산함.

---

3. 결론

• Differential Synchronization의 핵심은, 비록 diff 연산이 부담이 될 수 있지만, 이를 자주 작게 수행함으로써(혹은 똑똑하게 휴리스틱을 써서) 큰 폭의 변경 누적을 방지하고, 결과적으로 전체 협업 시스템에서 충돌도 줄이고 실시간성을 높이는 이점을 얻는다는 데 있습니다.
• 결국 실무에서는 diff 연산의 비용과 실시간 동기화가 가져다주는 사용자 경험(UX) 장점을 균형 있게 맞추는 설계를 하게 되며, 필요에 따라 적응형 주기나 부분 diff 최적화 등 다양한 방식으로 부담을 낮추게 됩니다.

[Cheondongmin]

파일을 여러 청크로 분할해 업로드할 때, 중간에 끊기면 끊어진 청크부터 재전송해야 하니까 청크 크기가 중요한데,
어떤 기준으로 청크 크기를 정해야 할지 궁금함.

예를 들어, 너무 작은 청크면 네트워크 요청 오버헤드가 커지고, 너무 크면 실패 시 재전송 부담이 큼. 일반적으로 S3 multipart upload 같은 경우
최소 5MB 정도를 권장하는데, 실제 시스템에서는 파일 크기, 네트워크 품질, 서버 처리 능력 등을 고려해서 동적으로 조정할 수도 있음...

(서버환경에 따라 진짜 동적으로 결정되는거라 갑론을박 할만한 질문거리는 아님. 그냥 읽어보고 PASS 해도 무관)

[Cheondongmin]

전회사 사례)

업로드를 열심히 하던 컴퓨터가 갑자기 절전모드로 들어가면서 업로드가 끊겨버림
중간에 업로드가 끊기는걸 브라우저 레벨에서 막을 수 없을까?

[Cheondongmin]

컴퓨터 켜놓으세요 ^^

[KimH4nKyul]

동기화 전략에서 델타 전략과 버전 벡터의 차이점은?

[KimH4nKyul]

네, 델타 동기화와 버전 벡터는 서로 다른 개념이며, 구글 드라이브에서 각각 다른 목적으로 사용됩니다. 두 기술의 주요 차이점을 설명해 드리겠습니다.

델타 동기화와 버전 벡터의 차이점

1. 기본 개념과 목적

델타 동기화(Delta Synchronization)

• 정의: 파일의 전체가 아닌 변경된 부분(델타)만 전송하는 기술
• 목적: 네트워크 대역폭과 데이터 전송량 최소화
• 사례: 대용량 문서에서 몇 문단만 수정했을 때, 변경된 부분만 서버로 전송

버전 벡터(Version Vector)

• 정의: 분산 시스템에서 각 노드(기기, 사용자)별 변경 이력을 추적하는 메타데이터 구조
• 목적: 동시 수정 시 충돌 감지 및 인과 관계(causality) 추적
• 사례: 오프라인 상태에서 여러 기기가 동일 파일을 수정했을 때 충돌 감지

2. 작동 방식

델타 동기화

파일 → 청크 분할 → 변경된 청크 식별 → 델타만 전송

• 파일을 작은 청크(chunk)로 분할
• 체크섬을 통해 변경된 청크만 식별
• 변경된 부분만 전송하여 효율성 증대

버전 벡터

[클라이언트A: 3, 클라이언트B: 2, 클라이언트C: 1]

• 각 클라이언트/노드의 수정 횟수를 벡터로 표현
• 벡터 비교를 통해 버전 간 관계 파악:
  • 앞선 버전(선행)
  • 뒤선 버전(후행)
  • 충돌 버전(병렬 변경)

3. 데이터 처리 수준

델타 동기화

• 내용 수준(Content level): 파일 내용 자체의 변경 사항 추적
• 바이너리/텍스트 수준: 실제 데이터의 변화를 바이트 또는 텍스트 단위로 처리

버전 벡터

• 메타데이터 수준(Metadata level): 변경 사항 자체가 아닌 변경 이력 추적
• 시스템 수준: 여러 시스템 간의 동기화 상태를 관리

4. 구글 드라이브에서의 활용

델타 동기화

• 파일 업로드/다운로드 시 대역폭 절약
• 구글 문서 등에서 실시간 편집 내용의 효율적 전송
• 리비전 간 차이점 저장 시 스토리지 효율화

버전 벡터 (또는 유사 메커니즘)

• 여러 기기 간 동기화 상태 추적
• 오프라인 편집 후 충돌 감지
• 동시 편집 상황에서 일관성 유지

5. 구체적 사례

델타 동기화 예시:

원본 문서: "구글 드라이브는 클라우드 스토리지 서비스입니다."
수정 문서: "구글 드라이브는 안전한 클라우드 스토리지 서비스입니다."
델타 정보: ["안전한 "을 "클라우드" 앞에 삽입]

• 전체 문장이 아닌 추가된 "안전한 " 부분만 전송

버전 벡터 예시:

초기 상태: [A:1, B:0, C:0] - A가 파일 생성
A 수정 후: [A:2, B:0, C:0] - A가 추가 수정
B 오프라인 수정: [A:1, B:1, C:0] - B가 초기 버전에서 수정
충돌 감지: [A:2, B:0, C:0]와 [A:1, B:1, C:0] 비교 시 충돌 감지

구글 드라이브의 실제 구현

실제로 구글 드라이브는 이 두 기술을 모두 사용하지만, 실시간 협업 문서(구글 문서, 스프레드시트 등)에서는 Operational Transformation(OT) 이라는 또 다른 알고리즘을 주로 사용합니다. OT는 버전 벡터의 개념을 확장하여 실시간 협업 편집에 최적화되어 있습니다.

델타 동기화는 효율적인 데이터 전송에 중점을 두는 반면, 버전 벡터는 동시 편집 환경에서의 충돌 감지와 해결에 중점을 둔다고 볼 수 있습니다. 구글 드라이브는 이러한 기술들을 조합하여 효율적이고 일관된 파일 동기화 시스템을 구현하고 있습니다.

[renechoi]

롱폴링 ?

롱 폴링(Long Polling)은 서버와 클라이언트 간의 통신을 효율적으로 유지하기 위한 웹 통신 기법 중 하나입니다. 일반적인 폴링(polling)은 클라이언트가 일정 간격으로 서버에게 “새로운 정보가 있는지”를 확인(요청)하는 방식입니다. 하지만 이렇게 짧은 간격으로 폴링을 하면 불필요한 요청/응답이 많이 발생해 서버나 네트워크 리소스를 낭비하게 되고, 긴 간격으로 폴링하면 실시간성이 떨어집니다.

롱 폴링은 이러한 문제를 개선하기 위해 다음과 같은 방식으로 작동합니다.

1. 클라이언트가 서버에 요청을 보냄

   • “새로운 알림이나 이벤트가 있는지 알려주세요”와 같은 요청을 보냅니다.

2. 서버가 즉시 응답하지 않고 대기(Hold)

   • 서버는 새로운 이벤트(알림, 데이터 변경 등)가 발생할 때까지 이 연결을 유지한 상태로 기다립니다.
   • 만약 서버에 ‘새로운 이벤트’가 발생하면 즉시 클라이언트에게 해당 정보를 응답으로 보냅니다.

3. 응답 수신 후, 클라이언트는 다시 연결

   • 클라이언트가 응답을 받으면, 이벤트 처리 후 다시 새로운 요청(Long Polling 요청)을 보내어 다음 이벤트를 기다립니다.
   • 이런 식으로 연속적으로 요청을 보내고 서버가 대기/응답하는 구조가 반복됩니다.

롱 폴링을 사용하면 클라이언트가 원하는 정보를 거의 실시간에 가깝게 전달받을 수 있으면서, 이벤트가 발생하지 않는 시간에는 빈번한 요청/응답이 이루어지지 않아 리소스 낭비가 줄어드는 장점이 있습니다.

이러한 이유로, 문서 협업 서비스(구글 드라이브 등)나 채팅 서비스에서는 클라이언트에게 변경 사항(알림)을 빠르게 전송해야 할 때 롱 폴링 기법을 많이 활용했습니다. 근래에는 WebSocket이나 Server-Sent Events(SSE) 등 더 효율적인 양방향(or 단방향 스트림) 통신 프로토콜이 존재하지만, 롱 폴링은 여전히 기존 인프라/브라우저 호환성, 혹은 간단한 구현 등을 이유로 많이 사용되는 기법입니다.

구글 드라이브를 설계할 때 블록 저장소가 있고 클라우드 저장소가 있는데, 각각의 역할 ? 나누는 이유는 ?

시스템 디자인 관점에서 구글 드라이브(또는 유사한 대용량 파일 저장/공유 서비스)를 설계할 때, 파일 데이터를 **‘블록(Chunk/Block) 단위로 저장하는 저장소(Block Storage)’**와 그 위에 구축된 ‘클라우드 저장소(Cloud/Object Storage)’ 계층을 나누는 이유와 각각의 역할은 다음과 같습니다.

---

1. 블록(Chunk/Block) 저장소의 역할

1. 파일을 작은 블록(Chunk)으로 쪼개어 저장

   • 대형 파일(수백 MB ~ 수 GB 이상)을 한 덩어리로 저장하면 전송·수정 시 비효율적입니다.
   • 이를 크기가 일정한 블록(예: 4MB, 8MB 등)으로 나누어 저장하면, 변경이 발생한 블록만 업데이트하거나 전송할 수 있습니다.

2. 중복 제거(Deduplication) 가능

   • 여러 사용자가 같은 파일(또는 동일한 일부 블록)을 업로드하는 경우가 많습니다.
   • 블록 단위로 해시를 계산하여 중복된 블록은 한 번만 저장하고, 다른 파일에서 해당 블록을 재사용하게 함으로써 저장 용량을 절약할 수 있습니다.

3. 버전 관리(Versioning) 및 부분 업데이트 용이

   • 문서 협업(예: 구글 Docs, Sheets 등)에서는 문서가 자주 업데이트됩니다.
   • 블록 단위로 버전을 관리하면, 수정된 블록만 기록해두면 되므로, 전체 파일을 매번 모두 새로 저장할 필요가 없습니다.
   • 충돌(Conflict) 제어나 협업 시의 동시 편집(Concurrency) 관리를 좀 더 유연하게 처리할 수 있습니다.

4. 전송 최적화

   • 클라이언트(웹, 모바일, 데스크톱 등)와 동기화할 때도, 변경된 블록만 받아오면 되므로 대역폭 낭비가 줄어듭니다.

---

2. 클라우드(또는 객체) 저장소의 역할

1. 전 세계적인 확장성 및 고가용성

   • 구글 드라이브처럼 전 세계적으로 수십억 건의 파일을 저장·접근해야 하는 시스템은 데이터센터 여러 곳에 파일을 분산 저장해야 합니다.
   • 클라우드 스토리지는 내부적으로 여러 노드/서버에 객체(Object)를 복제·분산해두어, 지리적·물리적 장애에도 안전하게 데이터를 보관합니다.

2. 추상화된 ‘객체’ 단위의 관리

   • S3(GCS), GCS(Google Cloud Storage) 같은 객체 스토어(Cloud Storage)는 파일(혹은 블록)을 객체로 다룹니다.
   • 애플리케이션(구글 드라이브)은 객체가 어느 노드에 있는지 직접 알 필요 없이, "객체 식별자(Object ID)"로 접근합니다. 내부 분산/복제/백업 전략은 클라우드 스토리지가 알아서 처리합니다.

3. 자동 확장(Elasticity)

   • 사용자가 급격히 늘어나거나 파일 저장량이 폭증해도, 클라우드 제공자가 알아서 스토리지 노드를 확장(추가)해주므로, 시스템이 탄력적으로 대응할 수 있습니다.

4. 비용 및 운영 효율성

   • 직접 물리적인 SAN/NAS 등을 운영하려면 상당한 비용과 관리 노력이 들어갑니다.
   • 클라우드 스토리지를 이용하면 운영 부하를 줄이고, 필요할 때만 스토리지를 늘리는 ‘종량제’ 모델을 사용하기도 용이합니다.

---

3. 구분하는 이유 요약

1. 성능 및 효율성

   • 블록 단위 처리를 통해 중복 제거, 부분 업데이트, 협업 충돌 최소화 등을 처리할 수 있습니다.
   • 이러한 블록 단위 관리 레이어를 별도로 두면, 실제 물리적 저장 리소스를 추상화하고 최적화 로직을 유연하게 구성할 수 있습니다.

2. 확장성(Scalability)

   • 구글 드라이브 같은 서비스는 전 세계 수많은 사용자, PB(페타바이트) 단위 데이터를 다룹니다.
   • 객체 스토리지(Cloud Storage) 계층은 내부적으로 자동 복제·분산·확장을 지원하기 때문에, 대규모 트래픽 및 저장 요구량을 안정적으로 처리할 수 있습니다.

3. 분리된 책임(Separation of Concerns)

   • “파일(블록) 관리 로직”과 “물리적(또는 가상) 인프라”를 분리하여 각각 전문화된 계층에서 최적화합니다.
   • 블록 레벨 로직은 “파일의 버전 관리, 중복 제거, 사용자 권한, 빠른 업데이트” 등에 집중하고,
   • 클라우드 스토리지는 “데이터 보존, 안정성, 용량 확장”에 집중하게 됩니다.

---

결론

• 블록 저장소: 파일을 작은 블록 단위로 나눠서 중복 제거, 버전 관리, 부분 업데이트 등의 기능을 담당하는 추상화 계층.
• 클라우드 저장소: 대규모 분산 환경에서 영구적으로 데이터를 저장하고 관리하며, 확장성과 고가용성을 제공하는 ‘객체(오브젝트) 스토어’ 형태의 인프라.

이 둘을 분리함으로써, 구글 드라이브와 같은 대규모 파일 협업/공유 서비스는 데이터 전송 최적화, 저장 공간 효율화, 무중단 확장성을 모두 달성할 수 있게 됩니다.

메모리 캐시가 일반적으로 최종 일관성을 지원한다? 이게 무슨 말일까? 장단점은?

• 캐시가 보관하는 데이터가 항상 최신 상태를 보장하지는 않지만, 시스템 내에서 변경 사항이 더 이상 없을 경우 **결국(Eventually)**에는 원본 데이터(데이터베이스 등)와 일치하게 된다는 의미
• 즉, 캐시에서 잠시 동안은 오래된(stale) 데이터가 반환될 수 있지만, 시간이 지나면(갱신/동기화 절차를 통해) 결국 최신 상태로 합쳐지는(Converge) 동작 방식

-> 읽기 성능 극대화

읽기에서: 요청 - 캐시 먼저 봄 - 없으면 DB
업데이트: 요청 - 캐시에 먼저 씀 - 나중에 DB 반영

=> DB를 먼저 보는 다른 노드와 일관성이 차이 날 수 있음

블록이라는 게 cs 관점에서 어떤 개념인지?

1. 블록의 기본 개념

1. 일정 크기를 갖는 데이터 단위

   • 예: 디스크/파일시스템에서 일반적으로 4KB, 8KB 등 한 덩어리를 블록이라고 부릅니다.
   • 클라우드 스토리지나 대용량 분산 파일 시스템(HDFS 등)에서는 64MB, 128MB 등 더 큰 단위를 ‘블록(Chunk)’으로 사용할 수도 있습니다.

2. 시스템에 따라 이름이 달라질 수 있음

   • 운영체제(메모리 관리): ‘페이지(Page)’라는 용어를 사용 (예: 4KB 페이지).
   • DBMS: 내부 저장 구조를 ‘페이지(Page)’ 또는 ‘블록(Block)’라고 부름 (예: 오라클 8KB 블록).
   • 분산 파일 시스템: 대용량 파일을 나누는 단위를 ‘청크(Chunk)’라고 부르기도 함.

3. 주요 특징

   • 작은 업데이트를 할 때, 블록이 변경되면 해당 블록 전체를 다시 쓰거나(Write) 전송하는 식으로 동작.
   • 블록 단위로 인덱싱, 캐싱, 복제(Replication)를 처리하기 쉬움.
   • 중복 제거(Deduplication) 시에도 블록 단위 해시를 통해 중복 판단이 가능.

---

2. 블록을 사용하는 이유

1. 관리 및 추상화 용이

   • 파일이나 메모리를 균일한 크기로 나누면, 각 부분에 대한 **인덱스(위치 정보)**를 동일한 규칙으로 관리할 수 있습니다.
   • 예: 디스크에서 논리 블록 번호(LBN)와 물리 블록 번호(PBN)를 매핑하면, “몇 번째 블록”이 “디스크 어느 위치”에 있는지 쉽게 계산 가능.

2. 성능 최적화

   • 데이터를 작게 쪼개서 I/O나 전송할 때, 블록 단위로 읽고 쓰면 디스크/네트워크 접근에 유리한 측면이 있습니다(연속 읽기/쓰기 최적화).
   • 캐시 메커니즘도 동일 크기의 블록(페이지)을 다룸으로써 구현 간소화 및 효율 향상.

3. 오류 격리 & 복구

   • 특정 블록에만 오류(Corruption)가 나도 전체 파일이 망가지지 않고, 해당 블록만 복구하면 됨.
   • 대규모 분산 시스템에서는 블록 단위로 복제(Replication)하여, 장애가 나면 해당 블록만 다른 노드에서 재다운로드/복원할 수 있음.

4. 중복 제거 및 버전 관리

   • 문서 협업 서비스(구글 드라이브 등)나 분산 파일 시스템에서 블록 해시를 이용해 “이미 저장되어 있는 블록”과 “새로 올린 블록”이 동일한지 비교해 중복 스토리지 사용을 줄임.
   • 문서가 수정될 때, 변경된 블록만 새 버전으로 저장하여 스토리지 비용 절감.

---

3. 다양한 맥락에서의 블록 예시

3.1 파일 시스템(FAT, NTFS, ext4 등)

• 보통 4KB 또는 8KB 같은 “파일시스템 블록 크기”를 갖습니다.
• 큰 파일을 저장할 때, 여러 개의 블록에 걸쳐 저장됩니다.
• 파일 열 때는 필요한 블록들을 순서대로 읽어 메모리에 올립니다.

3.2 데이터베이스(DBMS)

• 오라클: 8KB(기본) 블록
• MySQL(InnoDB): 16KB 페이지(블록과 같은 개념으로 봐도 무방)
• DB 엔진은 이 블록 단위로 테이블/인덱스를 관리, 버퍼 풀에 적재, 디스크 I/O 수행.

3.3 분산 파일 시스템(HDFS, GFS 등)

• 64MB, 128MB 등 비교적 큰 단위를 “청크(Chunk)/블록”으로 사용합니다.
• 대용량 파일을 쪼개 여러 데이터 노드에 분산 저장하고, 각 블록마다 복제본(Replica)을 둘 수 있습니다.
• 노드 장애 시 해당 블록 복제본을 사용해 전체 파일을 재구성합니다.

3.4 클라우드 스토리지(예: AWS S3, GCP GCS)

• 내부적으로는 대형 객체(Object)를 4MB, 8MB 등으로 쪼개 병렬로 업로드/다운로드하거나, 변경된 부분만 재전송합니다(멀티파트 업로드/리스타트 가능).
• 사용자는 객체(Object) 단위로 접근하지만, 내부에서는 블록 단위 최적화를 진행합니다.

---

4. 블록 개념 시각화

아래는 “파일을 블록 단위로 나눈다”는 것을 간단히 도식화한 예시입니다. 파일 크기가 20MB이고, 블록 크기가 4MB라고 가정해 봅시다.

┌─────────────────────┬─────────────────────┬─────────────────────┬─────────────────────┬──────┐
│       Block 0       │       Block 1       │       Block 2       │       Block 3       │ ...  │
├─────────────────────┴─────────────────────┴─────────────────────┴─────────────────────┴──────┤
│<----------  4MB  ---------->                                           <----  File  ---->    │
│<----------------------------------  20MB total ---------------------------------------------->│
└────────────────────────────────────────────────────────────────────────────────────────────────┘

1. Block 0: 파일의 첫 번째 4MB 구간
2. Block 1: 그 다음 4MB
3. …
4. 마지막 Block(N): 파일이 4MB 단위로 나뉘어 떨어지지 않으면, 마지막 블록은 4MB보다 작을 수 있음.

• 각 블록은 별도의 식별자(Block ID, 해시 등)를 가질 수 있습니다.
• 데이터를 읽고 쓸 때, “Block 2만 다시 받아온다”처럼 부분 전송이 가능합니다.
• 중복 제거 시 Block 0~N 해시를 계산하여 기존에 동일 해시 블록이 있다면 재사용할 수 있습니다.

---

5. 블록 크기의 트레이드오프

1. 작은 블록(예: 4KB)

   • 장점: 세밀한 업데이트/캐싱/중복 제거가 가능 → 변경된 부분만 정확히 다룸
   • 단점: 블록 관리(메타데이터)가 매우 많아짐, I/O 요청 횟수 증가 가능

2. 큰 블록(예: 64MB)

   • 장점: 대규모 순차적 읽기/쓰기 성능이 좋아짐, 메타데이터 관리가 단순화
   • 단점: 작은 변경에도 큰 블록 전체를 다시 로드/저장해야 할 수 있음

→ 시스템 특성(파일 크기 분포, 업데이트 패턴, 네트워크 대역폭, 메모리 상황 등)에 따라 블록 크기를 적절히 결정합니다.

---

6. 결론

• **블록(Block)은 “일정 크기의 데이터 단위”**로, 저장·전송·캐싱·복제·중복 제거 등 다양한 관점에서 활용되는 CS의 핵심 개념입니다.
• 작은 파일이든 큰 파일이든, 또는 메모리든 디스크든 네트워크든, 블록 단위로 나누어 관리하면 추상화와 최적화가 수월해집니다.
• “블록”을 시각화할 때는, 큰 데이터를 ‘퍼즐 조각’처럼 일정 크기로 잘라서 각 조각에 대해 식별(해시), 복제, 캐싱 등을 수행한다고 생각하면 이해가 쉽습니다.

“알림이 오면 클라이언트가 최신 변경 사항을 가져온다" 는 시나리오의 정상 케이스는 OK 문제가 발생할 수 있는 상황은 어떤 게 있을까 ?

알림 타이밍과 실제 데이터 적용 타이밍이 어긋나는 경우

• A사용자가 파일을 수정 → 서버에 변경 내용이 기록되고, 알림 서비스는 ‘파일 변경됨’ 이벤트를 트리거.
• 알림 서비스가 클라이언트들에게 변경 알림을 보냄.
• 클라이언트는 그 알림을 기반으로 최신 파일 버전을 요청함.
• 하지만 실제로는 서버(또는 백엔드)의 내부 처리(저장, 인덱스 업데이트, 분산 저장소 동기화 등)가 아직 완료되지 않았을 수 있음.
• 분산 시스템일 경우, 변경된 버전이 특정 노드에는 아직 반영 중 (Eventual Consistency 환경)

알림 순서가 뒤바뀌거나, 알림이 중복/누락되는 경우

• A 사용자가 파일을 수정(버전 2로 업데이트),
• 이어서 B 사용자도 거의 동시에 수정(버전 3으로 업데이트).
• 알림 시스템에서 “버전2 수정” 알림과 “버전3 수정” 알림을 클라이언트들에게 보내는데,
• 네트워크 지연, 큐(Queue) 처리 지연 등으로 인해 일부 클라이언트는 버전3 알림이 먼저 오거나,
• 버전2 알림이 늦게 도착할 수 있음.
• 클라이언트가 버전3 알림을 받고 최신 버전을 받아놓고 있었는데, 뒤늦게 버전2 알림이 도착 → 혼동 발생

동시에 여러 클라이언트가 수정 요청을 하는 경우의 충돌(Conflict)

• 클라이언트1이 알림을 받고 파일을 열어놓고 편집을 시작함. (버전 2 → 편집 중)
• 클라이언트2도 알림을 받고 편집을 시작함. (동일 버전 2 → 편집 중)
• 클라이언트1이 먼저 편집을 완료(버전 3 업로드).
• 곧이어 클라이언트2도 편집을 완료(근데 이건 여전히 버전 2 기반 수정) → 업로드 시 (버전 4?)
• 클라이언트2가 업로드를 시도했을 때, 이미 서버에는 새 버전(버전 3)이 존재.
• 만약 병합 로직(merge)이 제대로 처리되지 않으면, 클라이언트2의 업데이트가 클라이언트1의 수정을 덮어써버리거나 충돌이 난다.

해결법 ?

1. 알림에는 버전, 타임스탬프, 혹은 변경 토큰(Change Token) 등을 포함해서,
   • 클라이언트가 알림 순서를 스스로 판단하고, 필요하면 서버에게 “현재 최종 버전이 무엇인지” 재확인할 수 있도록 합니다.
2. 서버 측에서 최종 일관성 제어
   • 알림을 보내기 전(또는 직후)에 변경 사항이 확실히 반영되도록 해두거나,
   • 클라이언트가 요청할 때 최종 버전으로 리다이렉트/병합 처리하도록 “조정”하는 매커니즘이 필요합니다.
3. 충돌 감지 및 해결
   • 동시에 편집이 일어날 가능성이 있다면, 버전 충돌 시 “수정 거부(에러)”를 내거나, 변경 사항을 병합(merge) 하는 로직이 필수.
   • 구글 Docs/Sheets처럼 실시간 협업이 중요한 서비스는 보통 운영 변환(OT), CRDT, Locking 등 보다 정교한 기법을 사용합니다.

[hyojin202406]

3. SynchronousQueue 또는 BlockingQueue 사용

멀티스레딩 환경에서 데이터를 동기화하여 전달하고자 할 때, SynchronousQueue 또는 BlockingQueue를 사용할 수 있습니다. 이 방식은 스레드 간에 데이터를 교환하는 데 유용합니다.

예시: SynchronousQueue 사용
java
@service
public class ThreadService {

private final SynchronousQueue<String> queue = new SynchronousQueue<>();

public void sendDataFromAtoB(String data) throws InterruptedException {
    new Thread(() -> {
        try {
            queue.put(data); // A 스레드에서 데이터를 B 스레드로 전송
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }).start();

    new Thread(() -> {
        try {
            String receivedData = queue.take(); // B 스레드에서 데이터를 받음
            System.out.println("B thread received: " + receivedData);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }).start();
}

}
SynchronousQueue는 데이터를 교환하기 위해 두 스레드가 동기화되어야 하는 큐입니다.
한 스레드가 데이터를 put하면 다른 스레드가 take할 때까지 대기합니다. 이를 통해 두 스레드 간의 데이터 전달을 쉽게 구현할 수 있습니다.

[yonghanyoon]

이어올리기 방법 중 해당 방법들이 있다. (java + spring boot 기준)

• aws s3 multipart upload api
• tus 프로토콜 구현

aws s3 multipart upload api 활용 방법은 s3 사용이 필수라고 한다.
tus 프로토콜은 s3외에 다른 저장소도 사용 가능. (s3 직접 저장은 불가능)

aws s3 multipart upload api 활용 방법과 tus 프로토콜 방법 중 뭐가 더 나은가?
시장에선 대부분 s3를 사용한다고 하니 multipart upload api 활용이 나아보이긴 하지만 s3를 사용하지 않는 경우도 있으니 상황에 따라 달라지는건가?
s3를 사용하지 않고 tus 프로토콜 방식을 채택 했을 때 s3를 사용하여 multipart upload api를 활용한 것보다 이점이 무엇이 있을까?

[yonghanyoon]

회사가 돈을 많이 벌어서 S3를 쓰자.

[yw7148]

추돌 감지를 어떻게 해야할까?
예를 들면 사용자가 google docs처럼 ver1, ver2, ver3 업데이트 요청이 지속적으로 올 수도 있는데,

1. 지속적으로 업데이트하는 파일의 업데이트 요청인가?
2. 아니면 같은 파일을 업데이트하려는 충돌인가?

[yw7148]

버전 관리를 client가 하면서 어떤 버전에서 어떤 버전으로 업데이트하는 지 서버에 알려준다?

[yw7148]

지속적으로 업데이트하는 경우에는 순차 업데이트를 하는 것이 안전함.

• 순차 업데이트: 내 버전이 최신인 지 확인하고, 새로운 업데이트를 요청
• 동시 업데이트: ver1 -> ver2 요청이 완료되지 않은 시점에, ver1 -> ver3를 요청함
  • 충돌할 가능성이 높고, 충돌해소 전략이 필요함
  • Google docs같은 경우는 자동 병합 기능이 일부 있음 (그럼에도 수동 병합이 필요한 경우도 많음)

[Cheondongmin]

청크와 블록은 비슷하게 사용되기도 하지만, 기본 개념이 다름.

청크(Chunk)

파일이나 데이터를 전송하기 위해 논리적으로 나눈 단위임.
업로드 중 중단 시, 마지막 청크 이후 부분만 다시 전송할 수 있도록 함.
크기를 애플리케이션에서 조절할 수 있음.

블록(Block)

파일 시스템이나 스토리지에서 데이터를 저장하는 물리적 단위임.
보통 고정 크기로 관리되며, 디스크 I/O나 내부 저장 방식에 영향을 줌.
문맥에 따라 두 용어가 혼용되는 경우도 있으나, 업로드 및 네트워크 전송 관점에서는 청크가, 저장 및 파일 시스템 관점에서는 블록이란 의미로 주로 사용됨.

[KimH4nKyul]

클라우드에 직접 저장하는 방식과 블록 저장소를 사용하는 방식의 차이점

[KimH4nKyul]

구글 드라이브 블록 저장소 vs 직접 저장 방식 비교

1. 기본 개념

블록 저장소 방식 (Block Storage)

• 정의: 파일을 고정 또는 가변 크기의 작은 블록(청크)으로 분할하여 저장하는 방식
• 저장 단위: 4KB~16MB 크기의 블록
• 식별 방식: 각 블록은 해시 기반 고유 ID로 관리
• 구글 드라이브 적용: 드라이브의 기본 파일 시스템 구조로 사용됨

직접 저장 방식 (Object Storage)

• 정의: 파일을 단일 객체(object)로 취급하여 저장하는 방식
• 저장 단위: 파일 전체
• 식별 방식: 전체 파일에 대한 단일 식별자
• 구글 드라이브 적용: 초기 버전이나 단순 백업 시스템에서 사용

2. 핵심 차이점

특성	블록 저장소 방식	직접 저장 방식
데이터 관리 단위	작은 블록	전체 파일
업데이트 효율성	변경된 블록만 업데이트	전체 파일 재업로드 필요
대역폭 사용량	낮음 (변경 블록만 전송)	높음 (전체 파일 전송)
메타데이터 복잡성	높음 (블록 매핑 필요)	낮음 (단순 메타데이터)
저장 효율성	높음 (중복 블록 제거)	낮음 (파일 중복 가능)
파일 접근 방식	블록 재조합 필요	직접 접근 가능
시스템 복잡성	높음	낮음
버전 관리 효율성	높음 (변경 블록만 저장)	낮음 (전체 버전 저장)

3. 블록 저장소 방식의 문제점과 해결 전략

3.1 메타데이터 관리 복잡성

문제점

• 수백만 개의 블록을 파일 구조로 매핑해야 함
• 메타데이터 서버 병목 현상 발생 가능
• 메타데이터 손상 시 전체 파일 접근 불가

해결 전략

• 분산 메타데이터 관리:

  파일 → 샤딩 키 → 메타데이터 샤드 1~N → 블록 매핑 정보
  

• 계층적 메타데이터 구조:
  • 최상위: 파일 기본 정보
  • 중간: 블록 그룹 정보
  • 하위: 세부 블록 매핑
• 메타데이터 캐싱: 자주 접근하는 파일의 메타데이터 메모리 캐싱
• 체크포인트 생성: 주기적 메타데이터 스냅샷으로 복구 지점 확보

3.2 시스템 복잡성 증가

문제점

• 블록 할당, 해제, 관리 로직 복잡
• 가비지 컬렉션 필요성
• 블록 저장소와 파일 시스템 계층 간 일관성 유지 어려움

해결 전략

• 마이크로서비스 아키텍처:
  • 블록 스토리지 서비스
  • 메타데이터 관리 서비스
  • 파일 시스템 서비스
  • 동기화 서비스
• 비동기 처리 파이프라인:

  블록 생성 → 블록 저장 → 메타데이터 업데이트 → 인덱싱
  

• 자동화된 모니터링 및 복구:
  • 블록 무결성 검사
  • 고립된 블록(orphaned blocks) 자동 제거
  • 참조 정합성 검사기

3.3 블록 단편화 및 스토리지 효율성

문제점

• 시간이 지남에 따라 블록 단편화 발생
• 작은 파일도 최소 블록 크기 차지 (공간 낭비)
• 불완전한 중복 제거로 인한 효율성 저하

해결 전략

• 가변 크기 블록:
  • 파일 크기 및 특성에 따라 블록 크기 조정
  • 작은 파일은 작은 블록, 큰 파일은 큰 블록 사용
• 콘텐츠 기반 중복 제거:

  블록 내용 → 해시 함수 → 블록 ID동일 해시 → 기존 블록 재사용
  

• 압축 알고리즘:
  • 텍스트 파일: gzip, bzip2
  • 이미지/미디어: 파일 타입별 최적화 압축
• 정기적인 압축 및 최적화: 백그라운드 작업으로 스토리지 재구성

3.4 분산 시스템 일관성 문제

문제점

• 여러 서버에 분산된 블록 간 일관성 유지 어려움
• 부분 업데이트 실패 시 파일 손상 위험
• 동시 접근 시 경쟁 조건(race condition) 발생

해결 전략

• 버전 기반 동시성 제어:

  읽기: (파일ID, 버전) → 블록 세트쓰기: (파일ID, 버전) → 새 버전 → 블록 업데이트
  

• 트랜잭션 로그:
  • 변경 사항을 먼저 로그에 기록
  • 변경 완료 후 커밋
  • 실패 시 롤백 가능
• 쿼럼 기반 복제:
  • N개 서버 중 W개 쓰기 성공, R개 읽기 성공 필요 (W+R>N)
  • 일관성과 가용성 간 균형

3.5 복구 복잡성

문제점

• 일부 블록 손실 시 전체 파일 접근 불가
• 복구 과정 복잡
• 블록 간 의존성으로 인한 도미노 효과

해결 전략

• 리드 솔로몬 코드 등 오류 정정 기법:

  n개 데이터 블록 + k개 패리티 블록 = 최대 k개 블록 손실 복구 가능
  

• 다중 복제: 중요 블록 여러 위치에 복제
• 정기적인 무결성 검사: 백그라운드 스캔으로 손상 블록 조기 발견
• 계층적 복구 전략:
  1. 로컬 캐시에서 복구 시도
  2. 다른 복제본에서 복구 시도
  3. 오류 정정 코드로 복구 시도
  4. 사용자에게 부분 손상 알림

4. 직접 저장 방식의 문제점과 해결 전략

4.1 대역폭 비효율성

문제점

• 작은 변경에도 전체 파일 재전송 필요
• 모바일 환경 등 제한된 네트워크에서 성능 저하
• 대용량 파일 처리 시 병목 현상

해결 전략

• 델타 인코딩:

  변경사항만 인코딩하여 전송 → 서버에서 재구성
  

• 클라이언트 측 차분(diff) 계산:
  • 로컬에서 변경 부분 계산
  • 변경된 섹션만 전송
• 적응형 전송 프로토콜:
  • 네트워크 상태에 따라 전송 속도 조절
  • 낮은 대역폭에서 필수 부분 우선 전송
• CDN 활용: 자주 접근하는 파일 엣지 서버에 캐싱

4.2 버전 관리 비효율성

문제점

• 각 버전마다 전체 파일 복사본 필요
• 버전 증가에 따른 스토리지 사용량 급증
• 버전 간 차이 비교 어려움

해결 전략

• 스냅샷 기반 버전 관리:

  기본 버전 + 증분 변경사항 = 전체 버전 기록
  

• 타임스탬프 기반 버전 간소화:
  • 시간 경과에 따라 버전 통합
  • 최근 24시간: 모든 버전 유지
  • 최근 30일: 일단위 버전 유지
  • 그 이상: 주/월 단위 버전 유지
• 선택적 버전 관리: 중요 파일만 상세 버전 기록

4.3 대용량 파일 처리 어려움

문제점

• 업로드/다운로드 시간 과다
• 네트워크 중단 시 처음부터 재시작 필요
• 메모리 제약으로 인한 처리 한계

해결 전략

• 멀티파트 업로드/다운로드:

  파일 → 청크 분할 → 병렬 전송 → 서버에서 재조합
  

• 중단 지점부터 재개:
  • 전송 상태 추적
  • 실패 시 완료된 부분은 유지
• 스트리밍 접근: 전체 다운로드 없이 필요 부분만 스트리밍
• 백그라운드 동기화: 사용자 작업과 병렬로 동기화 진행

4.4 동시 접근 및 편집 제한

문제점

• 동시 편집 시 충돌 발생
• "Last writer wins" 정책의 데이터 손실 위험
• 실시간 협업 지원 어려움

해결 전략

• 락 메커니즘:

  편집 시작 → 락 획득 → 편집 → 저장 → 락 해제
  

• 충돌 감지 및 해결 UI:
  • 충돌 발생 시 사용자에게 알림
  • 병합 도구 제공
• Operational Transformation(OT):
  • 실시간 편집 작업을 교환 가능한 연산으로 변환
  • 모든 클라이언트와 서버에서 동일한 결과로 수렴
• 차이점 기반 병합: 공통 조상을 기준으로 자동 병합

4.5 스토리지 효율성 저하

문제점

• 유사 파일도 중복 저장
• 빠른 스토리지 소진
• 백업 및 마이그레이션 비용 증가

해결 전략

• 서버 측 중복 제거:

  새 파일 업로드 → 기존 파일과 비교 → 중복 시 참조만 생성
  

• 파일 유사성 인식:
  • 파일 시그니처 생성
  • 유사한 파일 그룹화하여 효율적 저장
• 선택적 압축: 압축 가능한 파일 형식 자동 감지 및 처리
• 계층형 스토리지: 접근 빈도에 따라 다른 스토리지 계층 활용

5. 구글 드라이브의 하이브리드 접근법

구글 드라이브는 두 방식의 장점을 결합한 하이브리드 시스템을 채택하고 있습니다:

5.1 핵심 아키텍처

• 기본 구조: 블록 저장소 기반
• 최적화된 동기화: 델타 동기화 알고리즘 결합
• 파일 유형별 처리:
  • 구글 문서/시트: 구조화된 델타 저장 (OT 기반)
  • 미디어 파일: 청크 기반 블록 저장
  • 작은 정적 파일: 직접 저장 방식에 가까운 단순화된 처리

5.2 통합 전략

• 적응형 블록 크기: 파일 특성에 따라 블록 크기 조정
• 스마트 캐싱: 사용 패턴 분석으로 자주 사용하는 블록 우선 캐싱
• 선택적 동기화: 사용자가 필요한 파일/폴더만 로컬 동기화
• 온디맨드 액세스: 블록 수준의 스트리밍 액세스 지원

6. 미래 방향성

6.1 기계 학습 기반 최적화

• 사용자 패턴 학습으로 자동 블록 크기 조정
• 예측적 프리페칭으로 블록 미리 로드
• 지능형 캐싱으로 효율성 향상

6.2 향상된 분산 시스템

• 에지 컴퓨팅 활용한 지역적 최적화
• 글로벌 일관성과 로컬 성능 간의 더 나은 균형
• 블록체인 영감 기술로 분산 무결성 확보

6.3 암호화 및 보안 강화

• 종단간 암호화된 블록
• 제로 지식 증명으로 프라이버시 보장
• 사용자별 키 관리로 안전성 향상

[KimH4nKyul]

이 문서는 Dropbox의 보안에 대한 종합적인 개요를 제공합니다. Dropbox는 사용자 신뢰를 최우선으로 생각하며, 이를 위해 다계층 보안 접근 방식을 채택하고 있습니다. 여기에는 기업, 인프라, 애플리케이션, 제품 전반에 걸친 보안 정책, 정기적인 보안 훈련, 침투 테스트, 그리고 내부 및 외부 위험 평가가 포함됩니다. Dropbox는 또한 데이터 보호 및 암호화, 침해 사고 대응, 네트워크 보안, 물리적 보안 등 다양한 측면에서 강력한 보안 조치를 구현하고 있습니다. Dropbox의 보안 프로그램은 위험을 평가하고 보안 문화를 구축하는 데 중점을 두고 있으며, 모든 직원이 고객 데이터 보호에 헌신하고 있습니다. 이 문서는 Dropbox가 어떻게 사용자 데이터를 안전하게 보호하고 있는지에 대한 자세한 정보를 제공합니다.

1. 🛡️ Dropbox 신뢰 프로그램 및 보안 관리
   Dropbox는 사용자의 정보를 보호하는 책임을 다하기 위해 보안, 개인 정보 보호, 투명성 및 준수를 강조하여 신뢰를 쌓고 있으며, 이를 위한 다양한 정책과 절차를 마련하고 있다.

보안 정책은 기밀성, 무결성, 가용성 및 개인 정보 보호와 같은 요소에 대한 위험 평가 프로세스를 포함하며, 정기적인 교육 및 보안 점검이 이루어진다.

Dropbox는 물리적 보안, 데이터 보안, 인증 및 장치 보안을 포함한 다층적 접근 방식을 통해 시스템과 제품의 보안을 강화하고 있다.

애플리케이션 보안 및 맬웨어 탐지를 위한 시스템을 구축해 사용자가 안전하게 서비스를 이용할 수 있도록 하며, 지속적으로 제3자 전문가의 침투 테스트를 통해 보안을 점검하고 개선하고 있다.

1.1. ️ Dropbox 신뢰 프로그램의 기초
신뢰는 Dropbox와 전 세계 수백만 사람 및 기업 간의 관계의 기초이다.

Dropbox는 사용자가 믿어준 것에 대한 책임을 진지하게 여기고 있으며 정보를 보호하는 것을 중요시한다.

신뢰를 받기 위해 Dropbox는 안전성, 프라이버시, 투명성, 그리고 준수에 중점을 두어 계속 성장할 것이다.

Dropbox 신뢰 프로그램 정책은 위험 평가 프로세스를 수립하여 모든 의사결정 과정에 반영된다.

1.2. 시스템 보안 및 신뢰성 프로그램
시스템 보안은 환경적, 물리적, 사용자, 제3자, 법률 및 규제, 계약 요구사항 등 다양한 위험 요소를 고려하여 관리된다.

성과 리뷰는 최소 연 1회 실시되어 보안 체계를 점검한다.

Dropbox는 보안, 개인 정보 보호, 준수 및 제품 신뢰성에 관한 정보를 제공하기 위해 Trust Center를 운영하고 있다.

Trust Center에 대한 추가 정보는 trust.dropbox.com에서 확인할 수 있다.

1.3. Dropbox의 다층적 보안 접근 방식
다층적 접근 방식을 통해 조직에 영향을 미치는 기업, 인프라, 애플리케이션 및 제품의 보안을 확보한다.

Dropbox는 정보 보안 관리 프레임워크를 수립하여 신뢰 유지를 위한 목적, 방향, 원칙 및 기본 규칙을 기술한다.

보안을 위해 위험 평가를 실시하고, 보안, 기밀성, 무결성, 가용성 및 개인 정보를 지속적으로 개선한다.

정기적으로 보안 정책을 검토 및 업데이트하고, 보안 교육을 제공하며, 응용 프로그램 및 네트워크 보안 테스트를 수행한다.

내부 및 외부 위험 평가를 통해 보안 정책 준수 여부를 모니터링한다.

1.4. 서비스 보안을 위한 정책
드롭박스 보안팀에 의해 시행되는 철저한 보안 정책이 수립되어 있다. 이 정책들은 매년 최소한 한 번 검토 및 승인된다.

모든 직원, 인턴, 계약자는 회사에 합류할 때 의무적인 보안 교육을 받으며, 지속적인 보안 인식 교육에도 참여한다.

정보 보호를 위해 사용자 및 드롭박스 정보의 보안 유지가 중요하다.

드롭박스 직원들은 정보 시스템 및 데이터에 접근하기 위해 자신을 인증하는 방법을 설명한다.

회사 정보를 접근하기 위한 모바일 장치의 최소 보안 요구사항이 규정되어 있다.

1.5. Dropbox 보안 시스템 개요
Dropbox 시스템 접근 및 사용자 정보의 보안을 유지하기 위한 정책을 설명한다.

데이터 보안에 대해 Dropbox가 데이터 보호를 위해 채택한 특정 스토리지, 접근, 사용 요구 사항을 기술한다.

여행 보안에서는 Dropbox 직원이 해외 여행 전에 취해야 할 조치들을 설명한다.

판매 및 고객 경험(CX) 보안 가이드라인은 사용자 정보를 안전하게 보호하고, 직원들을 지키며, 사용자에게 지원을 제공하는 내용을 포함한다.

물리적 보안의 중요성 역시 언급되어 있다.

1.6. Dropbox의 보안 환경 유지
Dropbox는 사람과 재산을 안전하게 보호하기 위한 환경을 유지하고 있다.

생산 물리적 보안 가이드라인은 생산 시설에 대한 물리적 접근 관리를 포함하고 있다.

사건 대응 계획은 보안, 개인 정보 보호 및 사이트 사건 보고 처리를 규명하고 있다.

직원들이 무단 저작물을 저장하거나 공유하는 것을 금지하고 있다.

사용자 데이터 개인정보 보호는 Dropbox의 개인정보 보호 정책에 따라 사용자 정보를 보호하고 처리하는 것을 목표로 한다.

1.7. Dropbox의 보안 프로그램 개요
Dropbox Trust Program은 Dropbox가 어떻게 운영되고 신뢰할 수 있는지를 설명한다.

모든 Dropbox 직원들은 고객 데이터를 보호하기 위해 보안 문화를 구축하고 이에 헌신하고 있다.

보안 프로그램은 정보 보안 프로그램과 일치하여 모든 제품과 서비스에 적용된다.

보안 위험은 주기적으로 검토되어 제품, 인프라 및 회사 차원에서 보안 관련 이니셔티브를 발생시킨다.

Dropbox의 보안 팀은 전문적이고 경험이 풍부하여, 신용 카드 결제를 수용하기 위한 전용 결제 환경을 안전하게 유지하고 관리한다.

1.8. 프라이버시 프로그램 운영과 직원 보안 관리
프라이버시 팀은 Dropbox의 프라이버시 프로그램 운영을 담당하며, 프라이버시 설계를 데이터 라이프사이클에 통합하는 주요 이니셔티브를 실행한다.

직원들은 배경 검토를 거치고, 행동 강령 및 허용 사용 정책에 서명하며, 연간 보안 및 프라이버시 교육을 받는다.

직원의 접근 권한은 중앙 디렉토리를 통해 관리되며, 강력한 비밀번호와 이중 인증으로 인증된다.

모든 직원은 SSH 키 기반의 생산 네트워크 접근 권한이 제한되며, 방화벽 구성은 소수의 관리자에게만 제한적으로 통제된다.

Dropbox는 기술적 접근 통제를 통해 직원들이 사용자 파일에 임의로 접근하지 못하도록 하며, 사용자 파일이 저장된 환경에 접근할 수 있는 엔지니어는 소수에 불과하다.

1.9. 드롭박스의 물리적 보안과 취약점 관리
드롭박스의 물리적 보안팀은 사무실의 물리적 보안 정책을 집행하고 보안을 감독하는 역할을 담당한다.

기업 시설의 물리적 접근은 승인된 드롭박스 직원과 동반된 등록 방문객에게 제한되며, 배지 접근 시스템을 통해 인가된 개인만이 제한 구역에 들어갈 수 있다.

서버 및 네트워크 장비가 있는 구역의 접근은 배지 접근 시스템을 통해 허용된 승진 직원에게만 제한되며, 정기적으로 승인된 개인 목록이 검토된다.

보안팀은 정기적으로 자동화된 및 수동 보안 테스트와 패치 관리를 수행하며, 잠재적 보안 취약점과 오류를 식별하고 수정하기 위해 제3자 전문가와 협력한다.

이러한 평가에서 나온 결과와 권고 사항은 드롭박스 경영진에게 전달되어 필요에 따라 적절한 조치가 취해진다.

1.10. 드롭박스 보안 관리 및 대응 프로세스
고위험 문제는 지정된 보안 엔지니어에 의해 문서화되고 추적되며 해결된다. 이때 물리적 접근은 드롭박스 직원으로 제한된다.

모든 접근 요청은 경영진의 명시적 승인과 기록이 필요하며, 필요한 경우에는 물리적 보안 조치가 강화된다.

드롭박스는 사고 대응 정책을 마련하여 서비스 가용성, 보안, 프라이버시 문제를 효과적으로 대응하고 있으며, 전담 팀이 경고를 신속히 처리한다.

인프라 보안은 AWS 및 드롭박스 담당 팀이 공유 책임 모델에 따라 운영되며, 네트워크 보안 및 암호화는 여러 단계로 보장된다.

데이터 전송 및 저장 시 256비트 AES 암호화를 통해 사용자 데이터를 보호하고, 키 관리 시스템은 탈중앙화되어 안전하게 운영된다.

2. 🔒 드롭박스 팀 보안 및 데이터 보호 개요
   드롭박스를 사용한 57만 개 이상의 기업이 원격 및 분산 팀의 안전한 협업을 위해 드롭박스의 클라우드 솔루션을 활용하고 있다.

드롭박스의 보안 프로그램인 드롭박스 신뢰 프로그램은 원격 근무에 대한 글로벌 접근 방식이 발전하면서 필수적인 다층적 보안 접근 방식을 채택하고 있다.

파일 인프라는 드롭박스의 사용자들이 안전한 서버에 접속하여 파일에 액세스하고 공유할 수 있도록 구성되어 있으며, 메타데이터 및 파일 블록을 포함해 여러 구성 요소로 이루어져 있다.

드롭박스는 파일을 블록으로 나누어 강력한 암호화 기법으로 보호하며, 변경된 블록만 동기화하여 전송하는 독창적인 보안 메커니즘을 제공한다.

드롭박스의 신뢰성은 데이터 손실 방지 및 접근 가능성을 보장하는 여러 레이어의 중복성을 갖추고 있으며, 연간 데이터 내구성은 99.999999999% 수준으로 디자인되어 있다.

2.1. ️ Dropbox for Teams의 데이터 보호 및 보안
디지털 전환이 여러 산업에서 진행되고 있으며, 데이터, 팀, 장치의 보호가 필수적이다.

클라우드 솔루션을 사용하는 조직은 원격 및 분산 워크플로를 지원하기 위해 협업을 간소화하고 클라우드 위험을 사전에 관리해야 한다.

575,000개 이상의 기업과 조직이 Dropbox for Teams를 사용하여 안전하게 협업하고 있으며, 이는 파일 동기화 및 공유 기능을 포함한다.

Dropbox for Teams는 산업 최우수 인프라와 고급 기업 보안 기능, 팀 및 콘텐츠 보안, 전자 서명 등을 제공하여 보안을 강화한다.

이 백서에 포함된 정보는 모든 Dropbox for Teams 제품에 적용되며, Paper는 Dropbox for Teams의 기능 중 하나로 포함된다.

2.2. Dropbox의 보안 접근 방식
Dropbox는 다층적인 보안 접근 방식을 채택하며, 이는 원격 근무의 글로벌 변화에 필수적이다.

이 백서에서는 Dropbox for Teams 제품의 보안 기능과 운영 보안 조치, 개인정보 보호 및 투명성 약속, 그리고 독립 인증 및 규제 준수 조치를 설명한다.

Dropbox for Teams에 관한 정보는 특별한 언급이 없는 한 일반적으로 적용되며, 이는 기본적으로 Dropbox의 기능이다.

데이터 전송, 저장 및 처리 과정은 안전하게 이루어지며, 우리는 제품 및 아키텍처의 지속적인 개선을 통해 신속한 데이터 전송과 신뢰성을 보장한다.

2.3. Dropbox의 파일 인프라 구조
Dropbox 사용자는 데스크탑, 웹, 모바일 클라이언트 및 제3의 애플리케이션을 통해 언제든지 파일과 폴더에 접근할 수 있다.

Dropbox의 파일 인프라는 미리보기 저장 서버, 블록 저장 서버, 메타데이터 데이터베이스로 구성되어 있다.

메타데이터는 사용자의 계정 및 파일에 대한 기본 정보를 포함하고 있으며, 이를 통해 버전 역사, 복구 및 동기화 기능을 지원한다.

SSL/TLS를 통해 보안 서버와 연결되어 파일 공유 및 업데이트를 안전하게 수행할 수 있도록 지원한다.

파일 관련 기본 정보는 메타데이터 저장 서비스에서 인덱스로 관리되어 사용자 계정 데이터를 효율적으로 조회할 수 있도록 도와준다.

2.4. 드롭박스의 데이터 보안 메커니즘
파일 메타데이터는 트랜잭션 키-값 저장소에 저장되며, 다중 버전 동시성 제어를 통해 샤딩되고 복제되어 성능 및 고가용성 요구를 충족한다.

드롭박스는 전통적인 암호화를 넘어서는 독특한 보안 메커니즘을 제공하여 사용자 데이터를 보호한다.

블록 서버는 파일을 블록으로 나누어 강력한 암호화 기법을 사용하여 각 파일 블록을 암호화하고, 수정된 블록만 동기화한다.

드롭박스 애플리케이션이 새 파일이나 기존 파일의 변경을 감지하면, 블록 서버에 변화를 통지하고 이를 처리하여 블록 저장 서버로 전송한다.

블록 서버는 사용자에게 파일과 미리보기를 전달하는 역할도 한다.

2.5. 블록 스토리지 서버와 미리보기 서비스
사용자 파일의 실제 내용은 암호화된 블록 형식으로 블록 스토리지 서버에 저장된다.

블록 스토리지 서버는 콘텐츠 주소 가능 스토리지(CAS) 시스템으로 작동하며, 각 개별 파일 블록은 해시 값에 따라 검색된다.

미리보기 서버는 파일의 미리보기를 생성하며, 이는 사용자의 파일을 보다 빠르게 표시할 수 있는 형식으로 변환된다.

미리보기 서버는 블록 스토리지 서버에서 파일 블록을 가져와 캐시된 미리보기를 생성하고 전달한다.

알림 서비스는 Dropbox 계정의 변경 사항을 모니터링하며, 파일이나 메타데이터를 저장하지 않거나 전송하지 않는다.

2.6. ️ Dropbox 데이터 저장 방식
Dropbox는 두 가지 종류의 파일 데이터를 저장하는데, 하나는 파일에 대한 메타데이터(마지막 변경 일시 등)이며, 다른 하나는 실제 파일 내용(파일 블록)이다.

파일 메타데이터는 Dropbox 서버에 저장되며, 파일 블록은 Amazon Web Services(AWS) 또는 Magic Pocket이라는 Dropbox의 전용 저장 시스템에 저장된다.

Magic Pocket은 신뢰성과 보안을 위해 고안된 독자적인 소프트웨어와 하드웨어로 구성되어 있다.

Magic Pocket과 AWS 모두 파일 블록을 암호화하여 저장하며, 두 시스템 모두 높은 신뢰성 기준을 충족한다.

사용자들은 웹 및 모바일 클라이언트를 통해 언제든지 Dropbox Paper 문서에 접근할 수 있으며, 이러한 클라이언트는 안전한 서버와 연결되어 문서 공유 및 업데이트를 지원한다.

2.7. ️ Dropbox Paper의 인프라 구조
Dropbox Paper의 인프라는 이미지 저장소, 미리보기 저장소, 메타데이터 데이터베이스 등 여러 구성 요소로 이루어져 있다.

Paper Doc의 콘텐츠 정보는 암호화된 청크 형태로 저장되며, 이에 관련된 메타데이터도 포함된다.

미리보기 서버는 Paper Doc 파일 데이터를 암호화된 블록으로 처리하고, 이를 사용자에게 제공한다.

Paper Doc의 리비전 역사와 같은 미리보기 데이터는 SSL/TLS를 통해 여러 장치에 전달된다.

2.8. Paper Application Servers 및 데이터 관리
Paper Application Servers는 사용자 요청을 처리하고, 편집된 문서의 결과를 사용자에게 다시 제공하며, 알림 서비스를 수행한다.

사용자 편집 내용은 Paper Databases에 기록되며, 이는 지속적인 저장소에 배치된다.

HTTPS를 통해 Paper Application Servers와 Paper Databases 간의 통신 세션이 안전하게 유지된다.

사용자 문서의 실제 내용 및 관련 메타데이터는 암호화되어 Paper Databases에 저장된다.

Paper Databases는 성능 향상 및 고가용성 요구를 충족하기 위해 샤딩 및 복제된다.

2.9. 이미지 및 문서 보안 관리
이미지는 Paper docs에 업로드되면 Paper Image Storage Servers에 안전하게 저장되고 암호화된다. 또한, Paper Application과 Paper Image Storage Servers 간의 데이터 전송도 암호화된 세션을 통해 이루어진다.

Previews Servers는 Paper docs에 업로드된 이미지와 하이퍼링크에 대한 미리보기를 생성하며, 이미지 데이터는 Paper Image Storage Servers에서 암호화된 채널을 통해 가져온다.

하이퍼링크에 대한 미리보기는 소스 링크에 명시된 암호화 기준에 따라 암호화하여 렌더링된다. 사용자에게는 Block Servers가 최종적으로 미리보기를 제공한다.

Paper docs에서 저장되는 데이터는 주로 메타데이터와 사용자에 의해 업로드된 실제 내용으로 구성되며, 이들은 Paper doc data로 명칭된다.

모든 Paper doc 데이터는 Amazon Web Services (AWS)에 저장되며, AWS는 높은 신뢰성 기준을 충족하는 환경에서 Paper docs를 암호화하여 저장한다.

2.10. 다층 보안 접근 방식
조직의 엔터프라이즈, 인프라, 응용 프로그램, 제품을 보호하기 위해 다층적인 접근 방식이 필요하다.

신원 및 접근 관리, 데이터 관리, 네트워크 보안이 중요한 요소로 포함되어 있다.

신뢰성을 확보하기 위해 Dropbox는 중복 저장 시스템을 통해 데이터 손실을 방지하고, 가용성을 보장하는 여러 계층의 중복성을 개발하였다.

파일 메타데이터는 최소 N+2 가용성 모델에 따라 독립된 장치에 분산 저장되고, 시간당 최소 한 번의 증분 백업과 36시간마다의 전체 백업이 수행된다.

파일 차원에서도 최소 두 개의 지리적 지역에 중복된 파일 블록을 저장하며, 연간 데이터 내구성을 99.999999999% 이상 제공하는 구조를 가지고 있다.

3. 🔒 Dropbox 보안 기능 개요
   강력한 경고 및 모니터링 기능이 있어 팀 관리자는 민감한 파일이 외부에 공유될 때 알림을 받을 수 있고, 경고를 처리할 수 있는 옵션이 있다.

데이터 분류 기능을 통해 개인 및 민감한 데이터가 자동으로 라벨링되어 외부 노출 위험을 줄이며, 민감한 정보가 공유될 때 관리자에게 DLP 알림이 전송된다.

데이터 거버넌스 추가 기능을 통해 팀 관리자는 법적 보류, 데이터 보존, 데이터 처분 기능을 사용하여 규정 준수와 리스크 관리에 도움을 받을 수 있다.

팀 관리자 역할을 통해 다양한 보안 및 공유 권한을 설정할 수 있으며, 회원 관리와 보고서 작성 기능을 활용해 사용자의 활동과 팀의 데이터를 효과적으로 관리할 수 있다.

이중 인증은 보안 코드를 통해 계정에 대한 추가 보호 계층을 제공하며, 관리자는 모든 팀 구성원 또는 특정 구성원에 대해 이를 강제할 수 있다.

3.1. Dropbox 보안 기능 및 데이터 보호
대량 데이터 이동, 외부로 공유된 민감한 내용, 팀 내부 및 외부에서의 맬웨어 공유와 같은 여러 보안 위협 요소가 존재한다. 이러한 위협들은 계정 해킹이나 랜섬웨어 감지와 같은 이슈로 이어질 수 있다.

Dropbox는 외부로 민감한 파일이 공유될 때 알림 임계값을 구성하고 알림 수신자를 조정할 수 있는 기능을 제공한다. 관리자는 알림을 검토, 해결 또는 기각으로 표시할 수 있다.

관리자는 외부 공유 보고서를 통해 팀의 파일과 폴더가 외부로 공유된 내용을 확인할 수 있으며, 이를 통해 파일 유형, 공유한 사용자, 링크 설정 등을 필터링할 수 있다.

팀 관리자는 공유 설정을 통해 팀 수준의 기본 만료일, 비밀번호 제한 등을 설정할 수 있으며, 이는 데이터 손실의 위험을 줄이는 데 도움을 준다.

Dropbox Enterprise는 민감한 데이터를 자동으로 분류하여 노출 위험을 줄일 수 있는 기능을 제공하며, 관리자는 팀 폴더에서 민감한 정보가 외부로 공유될 때 DLP 알림을 받을 수 있다.

3.2. 데이터 거버넌스 애드온 개요
데이터 거버넌스는 조직의 데이터 자산을 관리하고 보호하기 위한 전반적인 프로세스, 기술, 팀의 집합이다. 이러한 과정은 기업 데이터를 필요에 따라 저장, 식별, 검색하고 발견하는 능력을 포함한다.

Dropbox 데이터 거버넌스 애드온은 조직이 데이터에 대한 통제 및 보안을 강화하고, 규제 및 준수 요구를 충족하는 데 드는 위험과 비용을 줄이는 기능 세트를 제공한다.

애드온의 주요 기능으로는 확장된 버전 기록, 법적 구속, 데이터 보존, 데이터 처분 등이 있다.

확장된 버전 기록(EVH)을 통해 팀의 관리자는 지난 10년 동안 삭제되거나 변경된 파일을 복구할 수 있다.

법적 구속 기능을 통해 팀 및 준수 관리자는 해당 팀원이 생성하거나 수정한 콘텐츠를 조회 및 내보낼 수 있으나, 해당 멤버에게는 알림이 전해지지 않으며 권한은 유지된다.

데이터 보존 기능은 규정에 따라 일정 기간 보유해야 하는 콘텐츠의 우발적 삭제를 방지하는 데 도움을 준다. 이를 통해 고객은 가장 최근 "수정" 날짜에서 10년 이상 데이터를 보존할 수 있다.

데이터 처분 기능은 관리자가 특정 날짜에 데이터를 영구 삭제하여 보존 및 처분 요건을 준수할 수 있게 하며, 예정된 파일 삭제에 대한 보고서를 통해 활동을 모니터링할 수 있다.

3.3. 드롭박스 팀의 데이터 복구 및 보안 기능
드롭박스 팀 사용자들은 삭제된 파일과 Paper 문서를 복원할 수 있으며, 이전 버전도 복구 가능하여 중요한 데이터의 변경사항을 추적할 수 있다.

추가 보안을 위해, 사용자는 10회 실패한 비밀번호 입력 후 드롭박스의 모든 데이터를 기기에서 삭제하는 옵션을 활성화할 수 있다.

기본적으로 드롭박스 모바일 클라이언트는 파일이 기기의 내부 저장소에 저장되지 않으며, 사용자가 기기를 드롭박스 계정과 연결 해제하면 저장된 파일은 자동으로 삭제된다.

사용자가 드롭박스 계정 보안 페이지에서 Paper와 연결을 끊으면 오프라인 Paper 문서가 자동으로 기기의 내부 저장소에서 삭제되며 로그아웃된다.

드롭박스 팀을 위한 다양한 도구들이 관리자들이 팀의 특정 요구에 맞게 드롭박스를 사용자화할 수 있도록 지원한다.

3.4. 드롭박스의 팀 관리 기능과 권한 구조
드롭박스는 티어드 관리자 역할을 제공하여 효과적인 팀 관리를 지원한다. 팀 관리자는 세 가지 접근 수준 중 하나를 부여받으며, 팀의 관리자는 제한 없이 배정될 수 있다.

팀 관리자는 팀 전체의 보안 및 공유 권한을 설정하고, 관리자를 생성하며, 팀원을 관리할 수 있다. 팀 관리자는 모든 관리자 권한을 가진다.

사용자 관리 관리자는 팀 관리 작업의 대부분을 처리할 수 있으며, 팀원 추가 및 제거, 그룹 관리, 팀 활동 피드 조회가 가능하다.

지원 관리자는 팀원의 서비스 요청을 처리하며, 삭제된 파일 복원이나 이단계 인증 관련 문제를 도와줄 수 있다.

기업 관리 그룹은 관리자만 생성, 삭제 및 관리할 수 있으며, 사용자들은 직접 가입하거나 탈퇴 요청을 할 수 없다.

3.5. 사용자 관리 및 공유 권한
사용자 관리 그룹을 통해 관리자는 사용자가 직접 그룹을 생성하고 관리할 수 있는 권한을 부여할 수 있으며, 필요 시 사용자 관리 그룹을 회사 관리 그룹으로 전환할 수 있다.

관리자는 팀원이 자신의 업무 Dropbox 계정이 연결된 컴퓨터에 두 번째 Dropbox 계정을 연결하는 것을 차단할 수 있다.

관리자는 사용자의 계정을 비활성화하여 데이터와 공유 관계를 유지하면서 회사 정보를 안전하게 보호할 수 있으며, 이후에 계정을 다시 활성화하거나 삭제할 수 있다.

관리자들은 팀원의 팀 계정으로 로그인할 수 있어, 팀원의 파일, 폴더 및 Paper 문서에 직접 접근하여 변경하거나 감사 작업을 수행할 수 있으며, 이러한 작업은 팀의 활동 로그에 기록된다.

팀 관리자는 Dropbox를 통한 팀의 공유 권한을 종합적으로 제어할 수 있으며, 팀원이 외부인과 파일 및 폴더를 공유할 수 있는 여부를 설정할 수 있다.

3.6. ️ Dropbox for Teams의 사용자 관리 및 인증 방법
Dropbox for Teams의 팀 관리자는 파일 및 Paper 문서를 영구 삭제할 수 있는 권한을 팀 관리자에게만 제한할 수 있다.

관리자는 Dropbox for Teams 관리 콘솔에서 이메일 초대를 수동으로 생성할 수 있는 도구를 갖추고 있다.

Active Directory와의 통합을 통해 기존의 Active Directory 시스템에서 계정을 자동으로 생성 및 제거할 수 있다.

Dropbox for Teams는 중앙 신원 제공자에 로그인하여 팀원이 접근할 수 있도록 구성할 수 있으며, SSO 구현은 SAML 2.0을 기반으로 한다.

Dropbox는 주요 신원 관리 제공자와 파트너십을 맺어 사용자가 자동으로 프로비저닝 및 해제될 수 있도록 지원한다.

3.7. Dropbox for Teams API 및 이중 인증
Dropbox for Teams API는 고객이 맞춤형 사용자 프로비저닝 및 신원 관리 솔루션을 구축하는 데 사용될 수 있다.

이중 인증은 사용자의 Dropbox 계정에 추가적인 보호층을 제공하며, 활성화 시 로그인 시 비밀번호와 함께 6자리 보안 코드가 필요하다.

관리자는 모든 팀원 또는 특정 팀원에 대해 이중 인증을 요구할 수 있으며, 이를 통해 인증 상태를 추적할 수 있다.

인증 코드는 문자 메시지 또는 TOTP 표준에 부합하는 앱을 통해 받을 수 있다.

사용자가 보안 코드를 받을 수 없는 경우, 16자리 일회용 백업 코드를 사용하거나, 추가 전화번호로 백업 코드를 받을 수 있는 옵션이 있다.

Dropbox는 USB 보안 키를 통해 인증할 수 있는 FIDO U2F 표준도 지원한다.

3.8. Dropbox 기업 보안 관리 기능
기업 설치 프로그램을 통해 관리자는 Windows용 Dropbox 데스크톱 클라이언트를 원격으로 설정할 수 있으며, 이는 관리 소프트웨어 솔루션을 통해 이루어진다.

Dropbox는 제3자 EMM 공급자와 통합되어, 관리자가 모바일 기기에서 팀원이 Dropbox를 사용하는 방식에 대한 더 많은 통제권을 제공한다.

관리자는 Dropbox Enterprise 계정을 통해 관리된 기기에서만 모바일 앱 사용을 제한하고, 앱 사용량을 파악하며, 분실된 기기를 원격으로 삭제할 수 있다.

관리자는 Dropbox Teams의 Advanced 및 Enterprise 플랜에서 사용자가 Dropbox와 동기화할 수 있는 기기의 수를 제한하고, 기기 승인을 사용자 또는 관리자 관리 방식으로 설정할 수 있다.

팀 관리자들은 팀 멤버에 대해 2단계 인증을 요구할 수 있으며, 이를 통해 계정 보안을 강화할 수 있다.

3.9. 드롭박스 비즈니스 보안 관리 기능
드롭박스는 사용자 비밀번호의 안전성을 높이기 위해 사용자에게 고유하고 추측하기 어려운 비밀번호 설정을 요구하며, 관리자는 팀 전체 또는 개별 사용자에 대해 비밀번호를 재설정할 수 있다.

관리자는 회사의 드롭박스 팀으로 초대된 사용자가 팀으로 이동하거나 개인 계정의 이메일 주소를 변경하도록 요구할 수 있으며, 이를 통해 초대 강제 적용 기능을 활용할 수 있다.

관리자는 회사 이메일 주소를 사용하는 드롭박스 계정 수와 같은 주요 정보를 확인할 수 있으며, 필요시 모든 사용자를 팀으로 강제 가입시킬 수 있다.

드롭박스 관리자는 팀원의 웹 세션 시간을 제어할 수 있으며, 세션 기간이 만료되거나 유휴 상태가 길어진 경우 자동으로 로그아웃된다.

관리자는 제3자 애플리케이션의 사용자 계정 접근 권한을 검토하고 취소할 수 있으며, 필요시 사용자의 컴퓨터와 모바일 장치를 언링크하여 보안을 강화할 수 있다.

3.10. Dropbox 보안 기능 및 사용자 데이터 보호
지문 인식 및 얼굴 인식 기능을 통해 사용자들은 iOS 기기에서 Touch ID 또는 Face ID를 사용하여 Dropbox 모바일 앱의 잠금을 해제할 수 있다. 안드로이드 기기에서는 지원되는 경우 지문 잠금 해제 기능을 사용할 수 있다.

Dropbox Support는 계정 관리자에게 일회용 보안 코드를 요구하여 사용자의 신원을 검증하며, 이 코드는 관리 콘솔에서만 얻을 수 있다.

각 사용자는 계정 설정에서 개인적인 활동 정보를 확인할 수 있으며, 공유된 폴더와 파일, 공유 링크, 이메일 알림 설정 등을 관리할 수 있다.

안전한 연결된 장치 목록은 사용자가 자신의 계정과 연결된 모든 컴퓨터 및 모바일 장치를 보여주며, 사용자는 장치를 해제하는 옵션이 있다.

Dropbox는 사용자 데이터를 제로 지식 암호화 방식으로 보호하여, 클라우드에 저장된 암호화된 데이터의 복호화 키는 오직 사용자의 장치에만 저장된다. 따라서 Dropbox는 사용자 데이터에 접근할 수 없다.

4. 🔒 Dropbox의 데이터 보안 및 암호화
   Dropbox는 사용자의 데이터가 해킹의 사건에서도 안전할 수 있도록 XChaCha20-Poly1305 알고리즘을 사용하여 데이터를 암호화하며, 모든 앱은 libsodium을 기반으로 한 암호화 구현을 사용한다.

데이터 암호화 시 192비트 nonce가 랜덤으로 생성되며, 이는 나중에 복호화에 사용된다. 기존의 알고리즘들과는 달리 XChaCha20-Poly1305는 랜덤 nonce를 지원한다.

Dropbox는 256비트 대칭 키를 128비트 엔트로피에서 Blake2 해시를 통해 생성하고, 이 키는 사용자의 기기에서 보관된다.

사용자의 12개 회복 단어는 128비트 키를 복구하는 데 필요한 방법으로, 이를 안전한 장소에 보관할 것이 권장된다.

ISO/IEC 27018 및 ISO/IEC 27701 인증을 통해, Dropbox는 사용자의 데이터 프라이버시와 보안을 최우선으로 고려하고 있으며, 이를 위해 연간 독립 감사를 받는다.

4.1. Dropbox의 데이터 암호화 방식
Dropbox는 XChaCha20-Poly1305를 사용하여 데이터를 암호화하며, 이는 암시적 인증을 위한 결합 모드로 작용한다.

데이터 암호화 과정에서 192비트 nonce가 생성되며, 이는 이후 복호화를 위해 암호화된 페이로드와 함께 저장된다.

XChaCha20-Poly1305는 무작위 nonce를 지원하므로, 매번 새로운 암호화 시 이전 nonce와 상관없이 새로운 무작위 nonce가 생성된다.

Dropbox는 libsodium을 통해 암호화 구현을 지원하며, 이 라이브러리는 감사를 받은 널리 배포되는 NaCl의 포크이다.

Dropbox 비밀번호 생성기는 각 플랫폼에서 암호적으로 안전한 랜덤 번호 생성기를 기본으로 사용하여 무작위 숫자를 생성한다.

4.2. 키와 복구 단어
256비트 대칭 키는 128비트의 엔트로피(사용자 키)에서 Blake2 해싱을 통해 생성된다. 이 암호화 키는 소유자의 기기에서만 저장된다.

iPhone의 경우, 암호화 키는 iOS 키체인에 저장되어 가장 안전한 저장소에 보관된다.

BIP-39 표준을 사용하여 12개의 복구 단어를 통해 128비트 키를 백업할 수 있다. 이는 대규모 무작위 키를 사람 친화적인 방법으로 표현하는 방식이다.

12단어는 실제로 132비트에 해당하며, 추가 4비트는 체크섬으로 오류를 식별하는 데 사용된다.

복구 단어는 기기를 잃거나 도난당했을 때 암호화 키를 복구하는 방법을 제공하며, 이를 안전한 장소에 인쇄하여 보관할 것을 권장한다.

4.3. 장치 등록 절차
새로운 등록 장치는 256비트 공개/비공식 장치 키 쌍을 무작위로 생성하고, 공개 키를 Dropbox 서버에 업로드한다.

사용자가 이전에 등록한 장치가 없는 경우, 등록 장치는 128비트 비밀 사용자 키를 무작위로 생성한다. 사용자 키와 장치 키 쌍은 보안 운영 체제 특정 위치에 저장된다.

사용자의 비밀번호 데이터를 초기화하고 암호화하여 Dropbox 서버에 암호화된 페이로드를 업로드한다.

사용자가 이전에 등록한 장치가 있을 경우, 등록 승인 요청이 각 장치로 전송된다. 이때 등록 장치의 공개 키가 요청에 첨부된다.

사용자가 등록된 장치 중 하나에서 요청을 승인하면, 해당 장치는 사용자 키를 X25519 ECDH와 XSalsa20-Poly1305 방식으로 암호화한 후 Dropbox 서버에 업로드한다.

4.4. Dropbox 비즈니스 보안_whitepaper 개요
사용자가 이전에 등록한 장치에 더 이상 접근할 수 없을 때, 12개의 복구 단어를 입력하여 사용자 키를 복원할 수 있다.

등록된 장치는 암호화된 비밀번호 데이터를 다운로드하고 사용자 키로 이를 복호화한다.

매일 많은 사람들과 조직들이 드롭박스에 중요 파일을 맡기며, 이는 드롭박스가 파일 보호와 개인 정보 보호를 책임져야 함을 의미한다.

드롭박스의 개인 정보 보호에 대한 약속은 모든 결정의 중심에 있는 중요한 요소이다.

4.5. Dropbox의 개인 데이터 보호 인증
ISO/IEC 27018과 ISO/IEC 27701은 클라우드에서 개인 데이터 보호를 위한 국제 기준으로, 드롭박스 포 팀즈가 최초로 인증을 받은 주요 클라우드 서비스 제공업체이다.

ISO/IEC 27018은 2014년 8월에 출판되었으며, 사용자 개인정보와 데이터 보호를 특별히 다룬다.

ISO/IEC 27701은 2019년에 출판된 최초의 인증 가능한 글로벌 개인정보 관리 표준으로, ISO/IEC 27001을 기반으로 정보 보안 관리 시스템을 확장하는 프레임워크를 제공한다.

드롭박스는 사용자의 데이터를 제어하고, 제공된 정보만을 바탕으로 서비스를 제공하며, 파일 및 페이퍼 문서를 추가, 수정, 삭제할 수 있다.

드롭박스는 사용자의 데이터에 대한 투명성을 강조하며, 데이터 저장 위치, 신뢰할 수 있는 파트너 및 계정이 닫힐 경우의 절차를 안내한다.

ISO/IEC 27018과 ISO/IEC 27701은 ISO/IEC 27001을 보완하는 표준으로, 드롭박스는 2021년 10월에 ISO/IEC 27001 인증 갱신을 받았다.

드롭박스는 인증 유지를 위해 독립 제3자에 의한 연간 감사를 시행하므로, 이러한 관행이 정기적으로 검토된다.

4.6. 데이터 전송 및 개인 정보 보호 규정
드롭박스는 유럽 연합, 유럽 경제 지역, 영국, 스위스에서 데이터를 전송할 때 계약과 표준 계약 조항 등 다양한 법적 메커니즘에 의존한다.

드롭박스는 EU-U.S. 및 스위스-U.S. 데이터 프라이버시 프레임워크와 영국 확대 프레임워크를 준수하며, 개인 데이터 처리에 대한 원칙을 아는 데 있어 미국 상무부에 인증받았다고 한다.

드롭박스는 개인 데이터가 원칙과 일치하지 않게 처리될 경우 추가적인 책임을 지며, 이와 관련된 불만 사항은 JAMS라는 독립적인 제3자를 통해 조사 및 해결된다.

GDPR은 2018년 유럽 연합의 규정으로, 개인 데이터 보호를 위한 포괄적인 프레임워크를 수립한다. 드롭박스는 이를 준수하기 위해 데이터 보호 책임자를 임명하고, 내부 프로세스를 강화하고 있다고 한다.

드롭박스는 EU 클라우드 행동 강령에 따라 GDPR 준수를 증명하였으며, 레벨 2 준수 마크를 획득해 기술적, 조직적, 계약적 조치를 이행했다고 밝히고 있다.

4.7. 드롭박스의 보안 및 개인정보 보호 정책
드롭박스의 개인정보 보호 및 데이터 보호 관련 정보는 드롭박스의 공식 웹사이트를 통해 확인할 수 있다.

보안 및 개인정보에 대한 다양한 규제 및 산업-specific 요구사항이 조직에 적용될 수 있다.

드롭박스는 고객 비즈니스의 특정 요구에 맞춘 준수 조치를 결합하여 가장 널리 수용되는 기준에 따른 접근 방식을 가진다.

4.8. ️ ISO 표준 및 Dropbox의 보안 인증
ISO는 정보 및 사회적 보안을 위한 세계적 기준을 개발하여 조직들이 신뢰할 수 있는 제품과 서비스를 개발할 수 있도록 도움을 준다.

Dropbox는 EY CertifyPoint를 통한 감사 과정을 통해 데이터 센터, 시스템, 애플리케이션, 사람 및 프로세스를 인증받았다.

ISO/IEC 27001은 전 세계적으로 인정받는 정보 보안 관리 시스템(Information Security Management System, ISMS) 기준으로, 보안 모범 사례를 포함한다.

ISO/IEC 27017은 클라우드 보안에 관한 국제 표준으로, 클라우드 서비스 제공 및 사용에 적용 가능한 보안 통제를 위한 지침을 제공한다.

ISO/IEC 27018은 개인 정보를 처리하는 클라우드 서비스 제공업체를 위한 프라이버시 및 데이터 보호 표준으로, 고객들이 규제 및 계약 상 요구 사항을 해결할 수 있는 기초를 제공한다.

4.9. 인증 및 보안 기준
ISO 27001에 따라 Dropbox for Teams는 개인정보 관리 시스템(PIMS)으로 인증받았으며, 개인정보 식별자 처리자로서 인정받았다.

SOC 보고서는 조직 내에서 구현된 내부 통제에 대한 보고 프레임워크로, Dropbox는 Ernst & Young LLP의 독립 감사로 시스템과 프로세스를 검증받았다.

SOC 3 보고서는 보안, 기밀성, 무결성, 가용성, 개인정보 보호와 관련된 다섯 가지 신뢰 서비스 기준를 포함하며, Dropbox는 해당 사항에 대한 독립 감사인의 의견을 포함하고 있다.

SOC 2 보고서는 고객에게 100개 이상의 통제를 포함한 상세한 수준의 통제 기반 보증을 제공하며, Dropbox의 프로세스에 대한 설명과 감사 결과도 포함된다.

Dropbox는 CSA STAR Level 2 인증과 Level 2 감사를 획득하였으며, 이는 ISO/IEC 27001, SOC 2 신뢰 서비스 기준, 그리고 CSA 클라우드 통제 매트릭스에 기반한 독립 평가 결과이다.

4.10. Dropbox의 규정 준수 및 보안 인증
Dropbox는 HIPAA와 HITECH 규정을 준수하기 위해 Business Associate Agreements (BAAs)를 제공하며, 관련 정보를 제공하는 제3자 보고서도 접근 가능하다.

NIST SP 800-171 R2에 따라 비정부 정보 시스템에서 제어된 비분류 정보를 보호하기 위한 지침을 제공하며, Dropbox의 시스템 및 프로세스는 Ernst & Young LLP에 의해 검증되었다.

Dropbox는 FERPA 및 COPPA를 준수하여 교육기관이 서비스 이용 시 필요한 계약 조항을 동의할 경우 학생 정보를 안전하게 관리할 수 있도록 지원한다.

FDA 21 CFR Part 11 규정을 따르며, 이와 관련한 백서와 도움말 센터 기사를 통해 준수 지원 방법을 설명한다.

Dropbox는 SOC 2 Type II 인증을 획득하여 고객 데이터 보호에 대한 헌신을 표명하며, 추가적인 규정 준수 인증을 달성하기 위한 노력을 지속하고 있다.

5. 🔒 Dropbox Sign의 문서 보안 및 인증
   Dropbox Sign은 기업의 중요한 문서, 계약 및 합의서의 보호를 최우선으로 하며, 이는 법적으로 구속력이 있는 서명을 포함한다. 문서 보안은 기업 운영에서 매우 중요하다.

모든 사용자 문서는 방화벽 뒤에 저장되며, 요청 시에는 발신자의 세션에 대한 인증이 이루어진다. 또한 데이터 전송에는 TLS(Transport Layer Security)와 AES 256비트 암호화가 사용된다.

모든 서명 요청 시, Dropbox Sign은 문서에 감사 추적 페이지를 부착하며, 이는 서명한 사람과 서명 시점을 기록한다. 변조 방지 감사 추적 기능을 통해 모든 조치가 철저히 기록되고 시간 스탬프가 부여된다.

Dropbox Sign은 해싱 기술을 활용하여 서명 이전과 이후 문서의 유일한 기록을 생성함으로써, 문서 간의 변조 여부를 증명할 수 있는 기능을 제공한다.

사용자 인증을 위한 여러 기능이 제공되며, 2단계 인증을 통해 사용자 식별도를 높일 수 있다. 이는 SMS로 전송된 고유 코드를 사용해야 하며, 관리자는 필수 인증 방법을 설정할 수 있다.

5.1. Dropbox Sign의 문서 보안
Dropbox Sign은 비즈니스에서 매우 중요한 문서, 계약 및 동의서를 다루며, 여기에는 법적 구속력이 있는 서명이 필요하다.

이러한 문서의 예로는 신입 직원 채용 문서, 판매 계약, 건물 임대 계약, 파트너 관계, 공급업체 계약 등이 있다.

문서에는 종종 민감한 정보가 포함되어 있어, 보안이 가장 중요한 문제이다.

Dropbox Sign Services는 문서와 관련된 거래의 보호를 최우선으로 하며, 모든 서명의 프라이버시, 보안, 보호를 보장하는 데 전념하고 있다.

이 백서에서는 보안에 대한 폭넓은 주제를 다루며, 최소 계약 가치를 구매하는 고객을 위해 맞춤형 보안 검토, 설문지 및 평가를 제공할 수 있는 옵션이 있다.

5.2. 문서 보안 및 감사 추적 시스템
문서는 방화벽 뒤에 저장되며, 요청할 때마다 발신자의 세션에 대해 인증을 수행한다.

데이터 전송에는 최고의 산업 관행인 TLS(Transport Layer Security)가 사용되며, 데이터는 SOC 1 Type II, SOC 2 Type I, ISO 27001 인증된 데이터 센터에 저장된다.

고객 문서는 AES 256비트 암호화를 통해 저장 및 암호화되어 있으며, 추가 정보는 보안 페이지에서 확인할 수 있다.

문서에 요청된 서명의 각 서명은 특정 감사 추적 페이지와 함께 부착되며, 이 페이지에는 서명자와 서명 시간의 전 세계 고유 식별자(GUID)가 포함된다.

Dropbox Sign에서는 여러 종류의 감사 추적 이벤트가 발생하며, 현재 모든 감사 추적 이벤트 목록은 보안 페이지에서 확인할 수 있다.

5.3. Dropbox Sign의 보안 기능
Dropbox Sign은 문서 서명 과정에서 문서의 보안과 변조 방지를 목적으로 설계되었다. 이는 해시 기술을 활용하여 서명 전후의 문서에 대해 각각 고유한 기록을 생성한다.

서명 전후의 문서에 변조가 없었음을 입증해야 할 경우, 두 개의 고유한 문서 기록을 제공하여 증명할 수 있다.

강력한 인증 기능을 제공하여 사용자가 문서 서명 발급이나 서명을 실행하기 전에 신원을 확인할 수 있도록 한다.

2단계 인증을 설정할 수 있으며, 이는 Google Authenticator에서 생성된 코드 또는 SMS로 전송된 코드의 입력을 요구한다.

팀 관리자는 어떤 방법으로 2단계 인증이 이루어질지를 강제 적용할 수 있으며, 단일 로그인(Single Sign-On)도 지원한다.

5.4. Dropbox Sign 인증 및 보안 기능
모든 비밀번호는 안전하게 해싱 및 솔팅되어 저장되며, 세션은 기본적으로 1시간 후 만료되지만 사용자가 'Remember Me'를 선택하면 30일까지 연장될 수 있다.

Signer Access Code를 통해 사용자는 문서를 보기 위해 입력해야 하는 4~12자의 알파벳 및 숫자 조합의 코드를 설정할 수 있다.

OAuth를 통해 API 호출 시 사용자를 대신해 인증을 지원하는 기능이 제공된다.

SAML 2.0을 지원하여 기업의 단일 로그인 기능을 가능하게 한다.

역할 기반 보안 시스템을 통해 팀의 구성원에게 서로 다른 권한을 부여하여 관리자가 팀 설정 및 청구 정보를 제어할 수 있도록 한다.

5.5. ️ 규정 준수 인증 및 보증
Dropbox Sign은 미국 공인회계사협회(AICPA)에서 설정한 SOC(Service Organization Controls) 보고서와 같은 여러 프레임워크 및 규정을 준수한다.

Ernst & Young LLP에 의해 수행된 감사 시리즈를 통해 시스템, 애플리케이션, 인력 및 프로세스의 유효성이 검증되었다.

SOC 3 보증 보고서는 보안, 기밀성, 무결성, 가용성, 프라이버시의 다섯 가지 신뢰 서비스 기준을 포함한다.

SOC 2 보고서는 고객 데이터 보호를 위한 100개 이상의 통제 수단을 포함하여, Dropbox Sign의 프로세스에 대한 상세한 설명을 제공한다.

ISO 27001은 세계적으로 인정받는 정보 보안 관리 시스템 표준으로, Dropbox Sign의 물리적, 기술적 및 법적 통제 사항을 지속적으로 관리하고 개선하는 데 초점을 맞춘다.

5.6. 데이터 보호 및 법적 준수 기준
ISO 27018은 개인정보 보호와 데이터 보호를 위한 국제 표준으로, 클라우드 서비스 제공업체가 고객을 위해 개인 정보를 처리하는 경우에 적용된다. 따라서 Dropbox Sign은 ISO 27018에 따라 고객의 규제 및 계약 요구사항을 다룰 수 있다.

HIPAA 및 HITECH 준수를 지원하는 Dropbox Sign은 의료 분야의 기술 발전을 장려하면서 건강 정보의 보안을 강화하는 법률이다. 이 법률은 의료 기관 및 개인에게 적용되며, 관련 문서는 고객 요청 시 제공된다.

미국 ESIGN 법은 전자 기록과 서명의 유효성을 인정하며, 서명 의도 증명 및 소비자 고지와 기록 보존을 요구한다.

UETA는 전자 서명을 손으로 쓴 서명과 동일한 법적 효력을 부여하며, 미국의 모든 주에서 채택되었으나 뉴욕주에서는 적용되지 않는다.

GDPR은 유럽 연합의 개인 데이터 처리 규제를 강화하여, Dropbox Sign은 이 규제를 준수하여 고객이 GDPR에 따라 서비스를 이용할 수 있도록 한다.

5.7. DocSend의 보안 기능 및 관리 도구
Dropbox DocSend는 안전한 문서 공유 플랫폼으로, 이메일 인증과 서명 계약서(NDA) 등의 고급 보안 기능을 제공하여 민감한 정보를 보호한다.

사용자는 문서 수준 분석을 통해 문서를 조회한 사람과 그들이 보낸 시간을 알 수 있으며, 허용 목록과 같은 기능으로 접근을 제한할 수 있다.

DocSend는 안전한 파일 전송과 동적 워터마킹을 통해 불법 복제를 방지하고, 가상 데이터룸(VDR)을 통해 여러 문서를 하나의 링크로 공유할 수 있다.

데이터는 AES 256비트 암호화로 보호되며, 모든 파일은 안전하게 전송되고 저장된다.

감사 추적 기능을 통해 모든 액션은 시간 기록이 가능하며, 사용자 인증이 강화되어 문서 접근 전에 사용자의 신원을 확인할 수 있다.

6. 🔐 End-to-End Encryption의 중요성 및 운영 방식
   End-to-End Encryption (E2EE)는 사용자가 Dropbox와 안전하게 데이터를 공유하고 협력할 수 있는 환경을 제공하며, 규정 준수와 지적 재산 보호를 돕는다.

사용자의 장치에서 데이터가 암호화되고 해독 키가 생성되므로 Dropbox 서버에서 데이터의 해독이 불가능하다.

E2EE는 데이터 접근을 제한하여 비인가 접근 및 데이터 유출로부터 보호하며, Dropbox 자체를 포함한 외부 공격자로부터도 사용자를 보호한다.

암호화 키 관리 시스템(EKMS)을 통해 팀 내 모든 사용자에게 암호화된 키에 대한 접근 권한을 부여함으로써 효율적인 키 관리가 이뤄진다.

복구 키와 장치 키를 등록하여 장치 간의 안전한 통신을 도모하며, 이로 인해 데이터에 대한 접근 및 복구가 용이하다.

6.1. 엔드 투 엔드 암호화 (E2EE) 개요
엔드 투 엔드 암호화는 선택된 팀 폴더에 대해 고객이 규정을 준수하고 지적 재산을 보호하며, 장치의 보안에 대한 신뢰를 증진할 수 있도록 돕는다.

E2EE는 사용자의 장치에서 데이터가 암호화되며, 이는 Dropbox 서버에 전송되기 전에 이루어지므로 외부의 무단 침입이나 위반을 방지한다.

Dropbox 서버는 공개 키와 암호화된 개인 또는 대칭 키를 저장하고 배포하는 핵심 요소로, 정기적인 비암호화 인증과 권한 부여를 담당한다.

팀은 사용자들의 집합으로, 각 팀은 공유된 암호화된 팀 키에 의해 암호적으로 표현되며, 팀이 소유한 파일에만 접근할 수 있도록 한다.

관리자는 사용자 및 팀의 매개 변수를 관리할 수 있는 권한을 부여받으며, 복구 키를 통해 새로운 사용자나 장치를 등록할 수 있는 능력을 가진다.

6.2. 직원 보안 관리 및 접근 제어
Dropbox는 사용자의 파일에 대한 접근 권한이 없다고 명시적으로 규정하여 사용자를 보호한다.

직원은 채용 시 배경 조사를 통과하고 보안 정책을 이해하며 보안 교육을 이수해야 한다.

직원의 접근 권한은 역할과 책임에 따라 부여되며, 퇴사 시 즉시 해제된다.

Dropbox의 보안 접근은 강력한 비밀번호, SSH 키 및 2단계 인증을 사용하는 조합으로 관리된다.

모든 접근 요청은 중요 관리자의 승인을 기반으로 하며, 생산 서버와 데이터 센터와 같은 자원에 대한 접근은 명확한 승인 절차를 따른다.

6.3. 최종 사용자 암호화 목표 및 위협 모델
최종 사용자 암호화는 사용자가 Dropbox에 대한 신뢰를 강화하며, 특정 시나리오로부터 보호한다. 이러한 시나리오는 위협 모델로 설명된다.

이 문서는 암호화 보호에만 초점을 맞추며, 정기적인 접근 제어 메커니즘이 팀원 간의 보다 세분화된 접근 제어를 허용한다.

위협 모델은 Dropbox 서버에 대한 비밀성, Dropbox 직원에 대한 비밀성, 다른 팀 및 제3자에 대한 비밀성 확보를 포함해야 하며, 암호화된 파일의 무결성과 파일의 가용성을 보장해야 한다.

키 검증을 비활성화하면 위협 모델이 축소되며, 이 경우 무결성과 비밀성은 액티브 공격으로부터 보장되지 않는다.

키 회전이 이루어지면 이전 팀원이 신뢰할 수 없게 되는 시나리오에서도 암호화된 파일의 비밀성이 보장될 수 있도록 다루어야 한다.

6.4. 팀 중심 접근 방식과 자동 장치 등록
팀 중심 접근 방식에서는 보안 경계가 팀 주위에 설정되어, 한 사용자가 팀 키에 접근할 수 있는 한 데이터 복구가 가능하다. 따라서 여러 사용자가 키를 잃더라도 데이터를 복구할 수 있는 장점이 있다.

이 접근 방식을 통해 사용자 경험이 향상되고 프로토콜의 복잡성이 단순화되어 보안 문제의 위험이 줄어들게 된다.

자동 장치 등록 기능은 비기술 사용자가 새로운 장치에서 end-to-end 암호화 설정을 수동으로 할 필요 없이 보다 쉽게 설정할 수 있도록 지원한다.

보안 보장은 웹 클라이언트보다 네이티브 애플리케이션에서 더 강력하게 제공되며, 웹 클라이언트는 보다 동적으로 제공되기 때문에 보장이 약해진다.

키 검증이 비활성화될 경우, Dropbox 서버와 그에 대한 쓰기 권한을 가진 직원에게 신뢰가 연장되며, 데이터에 접근하는 공격자는 팀 파일 내용에 대한 정보를 얻지 못하게 된다.

6.5. 엔드투엔드 암호화 및 접근 제어 관계
엔드투엔드 암호화 기능은 기존의 접근 제어 메커니즘을 보완하는 보안 개선 요소이다.

이 기능은 팀 외부의 위협으로부터 보호하며, 팀 내 구성원 간의 암호화 보호는 필요하지 않다.

팀 내 구성원 간의 접근 제어는 정기적인 ACL(Access Control Lists)을 통해 구현된다.

팀원이 퇴사하기 전까지는 해당 팀원이 모든 팀 파일에 접근할 수 있으며, 퇴사 시 새로운 콘텐츠는 새로운 키로 암호화된다.

6.6. 암호화 및 키 관리 시스템
모든 키와 키 자료는 장치에서 생성되며, Entity Key Pair는 비대칭 암호 화키 쌍을 나타낸다. 이 쌍은 항상 장치에서 생성되고, 개인 키는 장치를 떠나기 전에 암호화되어야 한다.

데이터 키는 Entity가 모든 종류의 데이터를 대칭적으로 암호화하는 데 사용되며, 각 데이터 단위는 새로운 고유의 데이터 키로 암호화된다. 대칭 키는 항상 다른 키에 의해 암호화된 형태로만 저장된다.

대칭 암호화에는 AES-256-GCM 알고리즘이 사용되며, 이 때 nonce는 장치 측에서 랜덤하게 생성된다.

비대칭 암호화에는 HPKE가 사용되며, 키 검증이 활성화되면 추가적인 인증 데이터가 포함된다. 팀 비밀 키와 네임스페이스 비밀 키는 암호화의 발신자로 역할을 한다.

암호화된 키 관리 시스템(EKMS)는 고객 측 암호화를 통해 데이터 기밀성을 보존하며, 모든 키가 장치에서 안전하게 암호화되어 서버 측에서 사용할 수 없도록 한다. 이는 강력한 종단 간 암호화를 확립한다.

6.7. EKMS의 키 종류와 관리 절차
File Key는 대칭 키로, 장치에서 생성되어 서버로 전송되기 전에 암호화되며, 기밀성을 보장한다.

Encrypted Team Folder Keys는 비대칭 키로, End-to-End Encryption으로 보호되는 폴더에 할당되고, 개인 키는 Team Key로 암호화되어 안전하게 서버로 전송된다.

Team Key는 팀에 특별히 할당된 비대칭 키로, 개인 키는 Recovery 및 Device Keys로 암호화되어 서버로 전송된다.

Device Key는 비대칭 키로, 개별 장치에 고유하게 할당되며, 오직 공용 키만 서버에 등록되고 개인 키는 해당 장치에서만 안전하게 저장된다.

Recovery Key는 특정 팀에 할당된 비대칭 키로, 관리자가 생성하며 항상 적어도 하나의 복구 키가 유지되어야 한다.

7. 🔑 접근 권한 철회 및 키 회전 개념
   현재 접근 권한 철회(Access Revocation)는 구현되지 않았으며, 팀원이 제거되어도 파일에 대한 접근이 정기적인 ACL을 통해서만 방지된다.

접근 권한 철회는 장치 및 복구 키의 제어된 삭제를 보장하며, 이전 팀원이 팀의 데이터 보안을 위협할 수 없도록 한다.

접근 권한 철회는 복구 키와 장치 키에 대한 권한 철회를 포함하며, 이 과정은 새로운 팀 키가 영향을 받는 복구 공개 키로 재암호화되지 않도록 한다.

키 회전(Key Rotation)은 데이터 보안 및 기밀성을 유지하는 필수 절차이며, 접근 권한 철회 없이는 수행될 수 없다.

관리자는 관리자 콘솔을 통해 키 회전을 시작할 수 있으며, 이 과정에서는 새 팀 키를 생성하고 기존 키의 유효성을 확인하는 단계를 거친다.

7.1. 접근 권한 해지 개념
접근 권한 해지는 중요한 보안 기능으로, 이전 팀원이 데이터의 보안을 위협할 수 없도록 장치 및 복구 키를 제어하여 삭제하는 것을 보장한다.

복구 키의 해지는 권한이 부여된 관리자가 수행할 수 있으며, 팀 키 회전이 시작될 때 새로운 팀 키는 해당 복구 공개 키로 재암호화되지 않아 새롭게 생성되거나 수정된 파일의 보안을 보장한다.

장치 키의 해지는 사용자가 팀을 떠날 경우 팀 키 회전을 통해 이루어지며, 새로운 팀 키는 해당 장치 공개 키로 재암호화되지 않는다.

키 회전은 데이터의 보안과 기밀성을 유지하기 위한 필수 과정이며, 이는 암호화 키를 업데이트하는 장치를 제공한다.

키 회전의 전제 조건은 접근 권한 해지로, 회전 전에 해지해야 할 사용자나 복구 키는 삭제되거나 비활성화로 표시되어야 한다.

7.2. 관리자에 의한 키 로테이션
관리자는 관리 콘솔을 통해 키 로테이션을 시작할 수 있으며, 새로운 팀 키는 로컬에서 생성된다.

새로운 팀 키의 지문은 관리자에게 표시되며, 이전 키 검증이 활성화된 경우 사용자에게 배포된다.

기존의 모든 활성화된 복구 키와 장치 키가 서버에서 검색되어 새로운 팀 개인 키가 재암호화된다.

각 기존 네임스페이스에 대해 새로운 네임스페이스 키가 도입되며, 이는 새로운 팀의 공개 키로 암호화된다.

기존 팀 키와 네임스페이스 키는 만료되며, 만료된 키는 암호화 작업에 사용되지 않고 오직 복호화에만 사용된다.

7.3. 외부 공유와 보안 메커니즘
외부 공유는 다른 팀과 협력 시 암호화 보호를 제공하며 곧 개발될 예정이다.

외부 팀은 End-to-End Encryption에 등록되어 있어야 하며, 이를 위해 유효한 팀 키 쌍이 필요하다.

외부 팀이 키 회전을 수행할 경우, 공유 폴더의 키도 함께 회전되며, 이는 보안 강화를 위한 과정이다.

팀 키 지문은 키 회전으로 인해 여러 팀 키가 사용될 수 있는 상황에서 보안을 유지하는 데 필수적이다.

Merkle Tree를 통해 팀 키 지문을 관리하고, 새로운 팀 키의 해시는 이전 Merkle Tree의 루트 해시와의 연동을 통해 계산된다.

7.4. 파일 암호화 및 복호화 과정
파일 콘텐츠는 대칭 암호화 알고리즘인 Blockwise AES-GCM을 사용하여 암호화된다.

암호화 과정에서 각 블록의 해시 값은 Dropbox 서버에 저장되지만, 서버에서 복호화할 수는 없으며, 장치에서 복호화 가능해야 한다.

파일을 암호화하기 위해 새로운 랜덤 AES-256 키(복호화 키)를 생성하고, 이를 파일 키로 암호화한다.

복호화 과정은 파일 암호화의 단계를 역으로 수행하고, 각 복호화된 블록의 해시가 예상 해시와 일치하는지 확인한다.

새로운 복호화 키가 생성될 때마다 각 암호화와 수정은 이루어지며, 이는 Blockwise-AES-256-GCM의 revision 제한을 줄인다.

7.5. 고급 키 관리
기업은 규정 준수 요구 사항을 충족하기 위해 정교한 보안 솔루션이 필요하다. 보안 팀은 회사 데이터 보호 방식을 감독하고 제어할 수 있는 가시성을 요구한다.

Dropbox에서는 제3자의 데이터 보호 솔루션 없이도 데이터 암호화 모델을 쉽게 채택할 수 있다. 이를 통해 암호화 키를 안전하게 관리하고 다양한 기능을 제공받을 수 있다.

자동화된 팀 암호화 키의 연간 정기 회전 기능이 있어, 위협이 감지될 경우 언제든지 팀 암호화 키를 수동으로 취소하여 데이터 접근을 영구적으로 제거할 수 있다.

Dropbox는 다층 암호화 모델을 사용하여 팀과 연관된 고유한 팀 암호화 키(TEK)를 생성하고 저장한다. 이 키는 산업 표준 하드웨어 보안 모듈(HSM)을 통해 관리된다.

고객은 Dropbox가 관리하는 암호화 키(DMEK) 기능을 통해 고유한 팀 수준의 암호화 키를 제공받아 데이터 보안 및 규정 준수에서 유연성을 증가시킬 수 있다.

[KimH4nKyul]

• 출처: 드롭박스 시큐리티 백서

[durara021]

📌 Dropbox 보안 요약 목차

1️⃣ Dropbox의 보안 개요
다층 보안 접근 방식 적용 (물리적 보안, 네트워크 보안, 암호화, 접근 제어)
정기적인 보안 점검, 침투 테스트, 위험 평가 수행

2️⃣ 데이터 보호 및 암호화
파일을 블록 단위로 저장 및 암호화 (AES-256, XChaCha20-Poly1305)
Magic Pocket & S3를 활용한 높은 데이터 내구성 및 가용성

3️⃣ 접근 제어 및 사용자 보안
이중 인증(2FA), 역할 기반 접근 제어(RBAC)
데이터 거버넌스, DLP(데이터 손실 방지) 적용

4️⃣ 기업 보안 및 규정 준수
ISO 27001, SOC 2, GDPR 등 글로벌 보안 인증 획득
법적 규제 준수를 위한 보안 정책 운영

5️⃣ Dropbox Sign & DocSend 보안
변조 방지 감사 추적, 법적 준수 기능 제공
문서 보호 및 안전한 외부 공유 지원

6️⃣ 엔드 투 엔드 암호화(E2EE) 및 키 관리
서버에서 데이터 복호화 불가능한 강력한 보안 구조
자동 키 회전 및 접근 권한 철회 기능 지원

📌 결론: Dropbox는 강력한 보안 인프라와 철저한 보안 정책을 통해 사용자 데이터를 안전하게 보호하며, 기업 및 개인 사용자에게 신뢰할 수 있는 클라우드 환경을 제공함. 🚀