ente 딥다이브
— 서버가 사진을 읽지 못하는 클라우드는 어떻게 만들까

1프로젝트 한줄 요약

Ente는 사진·인증 코드·문서 등을 기기에서 암호화한 뒤 클라우드에 보관하고 동기화하는 서비스와 앱들의 모음입니다. 대표 제품 Photos는 사진 백업·앨범·공유를, Auth는 2단계 인증 코드를, Locker는 중요한 문서와 자격 증명 보관을 다룹니다. 루트 README.md가 소개하는 세 제품이며, 실제 디렉토리에는 Ensu, Cast, Space 등 더 넓은 개발 영역도 보입니다.

이 저장소의 핵심은 서버에 데이터를 맡기면서도, 내용의 복호화 권한은 사용자의 기기에 두는 설계입니다. 서버는 계정 확인·접근 권한·저장 용량·암호문 위치를 관리합니다. 사진 내용을 이해하지 않아도 이 업무는 할 수 있습니다. 반대로 사진을 화면에 표시하려면 클라이언트가 키를 풀고 데이터를 복호화해야 합니다.

1-1. 사진 한 장을 올릴 때 벌어지는 일

1. 클라이언트가 파일 키를 만들고 사진·썸네일·메타데이터를 암호화합니다.
2. 파일 키를 앨범에 해당하는 컬렉션 키로 감싸서 함께 저장할 준비를 합니다.
3. Museum에서 업로드 권한과 저장 위치를 받고, 암호문을 객체 저장소에 보냅니다.
4. 파일 정보와 암호화된 키를 서버에 등록합니다. 다른 기기는 변경 내역을 받아 복호화합니다.

이 흐름은 web/packages/gallery/services/upload/upload-service.ts의 encryptFile()과 server/pkg/api/file.go의 CreateOrUpdate()로 연결해 읽을 수 있습니다. 화면을 그리는 코드보다 이 경로를 먼저 따라가면 제품의 중심을 빨리 잡을 수 있습니다.

2왜 주목받는가

2-1. 일상적인 문제를 어려운 제약 아래 해결합니다

2026-10-23 GitHub Trending Dart Daily 1위라는 순위는 관심의 신호입니다. 다만 순위만으로 유입 경로나 인기의 원인을 알 수는 없습니다. 기능·공개된 구현·최근 변화는 관심을 끌 만한 요소지만, 특정 사건이 순위를 만들었다고 단정할 근거는 아닙니다.

사진 백업에는 자동 업로드, 여러 기기, 공유, 검색이 필요합니다. 여기에 서버가 사진을 복호화할 수 없다는 제약을 더하면, 썸네일 생성과 내용 기반 분석을 어디서 할지부터 다시 정해야 합니다. Ente에서는 클라이언트 암호화 코드와 로컬 ML 연결 코드를 함께 읽을 수 있습니다.

2-2. 어떤 대안과 비교하면 장점이 보일까

루트 README는 Photos를 Apple·Google Photos의 대안으로 소개합니다. 아래 표는 개별 경쟁 제품의 최신 요금이나 설정을 판정하는 비교가 아니라, 그런 대안을 고를 때 살펴볼 설계 방식의 비교입니다. Ente 열은 커밋 939ee85 기준입니다.

Ente의 학습 가치는 암호화 알고리즘 하나보다, 암호화를 유지한 채 제품의 편의 기능을 연결하는 과정에 있습니다. 예를 들어 앨범 공유는 단순히 DB의 공개 여부를 바꾸는 일이 아닙니다. 상대방에게 컬렉션 키를 안전하게 전달하는 문제까지 포함합니다.

2-3. 2026년 10월의 변화: Rust CLI

docs/docs/cli/migration.md는 새 CLI가 2026년 10월 0.4.0부터 도입됐고, 기존 Go CLI는 전환기에 계속 지원하되 새 개발은 Rust CLI에서 진행한다고 설명합니다. 2026-10-23 GitHub 기준 최신 릴리스는 ente-cli-v0.4.0입니다. 커밋 939ee85의 rust/apps/cli/Cargo.toml은 이미 0.4.1을 선언합니다. 발표 버전과 개발 버전이 다른 정상적인 사례입니다.

기존 cli/README.md의 ente account add와 새 문서의 ente account login --app photos는 서로 다른 세대의 명령입니다. 검색으로 찾은 명령이 어느 구현을 가리키는지 확인하는 습관도 배울 수 있습니다. 이 변화가 당일 트렌딩의 직접 원인인지는 확인되지 않았습니다.

3기술 스택 전체 지도

3-1. 프론트엔드와 클라이언트

모바일 Photos 앱 선언 버전은 1.3.67+2158, 데스크톱 패키지는 1.7.31-beta입니다. 앱 버전·라이브러리 버전·SDK 제약은 서로 다른 숫자입니다. Flutter 버전은 앱 pubspec의 sdk: flutter만으로 알 수 없으므로 CI 설정까지 읽어야 합니다.

3-2. 백엔드와 공통 코어

같은 저장소에 있다고 해서 모든 앱이 모든 기술을 실행하는 것은 아닙니다. 예를 들어 Rust CLI는 SQLCipher를 활성화한 로컬 저장소와 OS 키링을 사용하도록 의존성을 선언하지만, 서버 PostgreSQL과 역할이 다릅니다. rust/apps/cli/Cargo.toml의 feature 목록이 이 차이를 드러냅니다.

3-3. 인프라·빌드·CI

• 서버 이미지: server/Dockerfile은 golang:1.26.10-alpine3.23에서 CGO_ENABLED=0으로 빌드하고 alpine:3.22에 실행 파일과 리소스를 복사합니다.
• 로컬 클러스터: server/compose.yaml은 Museum, postgres:15, pgsty/silo 객체 저장소, alpine/socat을 연결합니다. 일부 이미지 태그는 고정되지 않아 완전한 재현성은 별도 과제입니다.
• 웹 빌드: web/package.json은 npm workspace, npm@11.12.1, typescript 6.0.3을 선언합니다. build:photos는 필요한 WASM 빌드 뒤 Next 빌드를 진행합니다.
• 웹 배포: web/Dockerfile은 앱별 out 결과를 Nginx 이미지에 복사합니다. 이 경로에서는 Next 개발 서버를 그대로 운영하는 구조가 아닙니다.
• CI: .github/workflows/web-lint.yml은 Node 24에서 설치·감사·빌드·검사·테스트를, server-lint.yml은 PostgreSQL을 쓰는 테스트를 구성합니다.

4아키텍처 심화 분석

4-1. 전체 시스템: 제어 정보와 파일 본문은 다른 길을 갑니다

일반적인 서명 URL 업로드 경로를 단순화한 도식입니다. 모든 요청이 같은 경로를 쓰는 것은 아닙니다. 서버는 파일 내용을 읽지 않아도 소유권·용량·업로드 완료 여부를 검사할 수 있습니다. server/ente/file.go의 File에는 OwnerID, CollectionID, EncryptedKey, KeyDecryptionNonce가 함께 들어갑니다.

4-2. 패턴 ① 키를 다른 키로 감싸는 계층

architecture/README.md가 설명하는 키 계층은 업로드 구현에서도 확인됩니다. web/packages/gallery/services/upload/upload-service.ts의 encryptFile()은 generateBlobOrStreamKey()로 파일 키를 만들고, 마지막에 encryptBox(fileKey, collectionKey)를 호출합니다.

// encryptFile()의 실제 호출을 뽑아 흐름만 줄인 예시
const fileKey = await worker.generateBlobOrStreamKey();
const encryptedMetadata = await worker.encryptMetadataJSON(
    metadata,
    fileKey,
);
const encryptedFileKey = await worker.encryptBox(fileKey, collectionKey);
// 원본 함수는 사진 본문·썸네일·추가 메타데이터도 처리합니다.

모바일에서도 mobile/apps/photos/lib/module/upload/service/file_uploader.dart의 _tryToUpload() 안에 파일 키와 컬렉션 키를 CryptoUtil.encryptSync()로 연결하는 코드가 있습니다. 새 파일 등록 전에 decryptVerify(..., chunkLimit: 1)로 첫 청크를 대상으로 검증하는 경로도 보입니다. 이것을 파일 전체를 매번 검증한다는 의미로 확대하면 안 됩니다.

복호화 쪽은 rust/crates/collections/src/lib.rs의 open_collection_key()가 좋은 입구입니다. 내가 소유한 컬렉션이면 secretbox::decrypt()와 session.master_key를, 공유받은 것이면 sealed::open()과 내 비밀키를 사용합니다. 같은 반환 타입 Key가 하위 계층을 단순하게 만듭니다.

큰 파일에서는 “끝까지 받았는가”도 검사해야 합니다

rust/crates/core/src/crypto/stream.rs는 ENCRYPTION_CHUNK_SIZE = 4 * 1024 * 1024, 즉 4 MiB 단위 처리를 정의합니다. Encryptor는 마지막 조각에 Tag::Final을 붙이고, Decryptor::finish()는 그 표식을 못 봤으면 Error::StreamTruncated를 반환합니다.

// rust/crates/core/src/crypto/stream.rs: 실제 메서드
pub fn finish(self) -> Result<()> {
    if self.seen_final {
        Ok(())
    } else {
        Err(Error::StreamTruncated)
    }
}

조각마다 인증에 성공해도 마지막 몇 조각이 사라질 수 있습니다. 그래서 “읽을 데이터가 더 없다”와 “정상적인 마지막 표식을 확인했다”를 구분합니다. 이 파일의 test_decrypt_file_truncation_at_chunk_boundary() 같은 테스트 이름만 읽어도 중요한 실패 조건을 배울 수 있습니다.

4-3. 패턴 ② HTTP 처리·업무 규칙·저장소를 나눕니다

CreateOrUpdate()는 file.ID == 0이면 생성, 아니면 갱신으로 보냅니다. GetUploadURLWithMetadata()는 양수인 ContentLength, 허용 크기, MD5 값, 사용량을 확인합니다. 기존 묶음 API의 GetUploadURLs()에는 MaxUploadURLsLimit = 50 제한도 있습니다. 이 50은 사진 총개수 제한이 아니라 해당 API가 한 번에 발급할 URL 수의 제한입니다.

FileRepository.Create()는 BeginTx()로 시작하고 defer tx.Rollback()을 둡니다. 파일 행, 앨범과 파일의 연결, 객체 위치, 사용량, 복제 필요 기록을 처리한 뒤 Commit()합니다. main()은 이 repository와 controller를 구조체 필드로 조립합니다. 이름만으로 완벽한 계층 분리를 가정하기보다 실제 의존 방향을 보는 것이 좋습니다.

객체 업로드와 DB 등록은 서로 다른 작업이므로, 실패한 중간 상태를 정리하는 설계까지 있어야 업로드가 완성됩니다. server/pkg/controller/file.go의 getObjectURL()은 임시 객체 정보를 다루고, repository의 생성 경로는 ObjectCleanupRepo.RemoveTempObjectKey()와 markAsNeedingReplication()을 같은 DB 트랜잭션 안에서 호출합니다. DB 트랜잭션이 외부 객체 저장소까지 함께 되돌린다고 이해하면 안 됩니다.

4-4. 패턴 ③ 중복 실행을 합치고 변경분만 받습니다

mobile/apps/photos/lib/services/sync/sync_service.dart의 SyncService.sync()는 이미 실행 중이면 _existingSync!.future를 반환합니다. 새 동기화를 여러 개 만들지 않고 한 작업의 결과를 공유하는 방식입니다. 성공 여부와 관계없이 finally에서 completer를 완료하고 참조를 비웁니다.

// sync()의 중복 실행 처리 부분: 실제 소스 발췌
if (_existingSync != null) {
  _logger.warning("Sync already in progress, skipping.");
  return _existingSync!.future;
}
_syncStopRequested = false;
_existingSync = Completer<bool>();

연결 상태 변화, 계정 설정, 권한 허용 등 여러 사건이 동기화를 요청할 수 있습니다. 이 보호는 같은 SyncService 인스턴스의 실행 겹침을 다루며, 모든 기기의 분산 잠금을 뜻하지 않습니다. 이벤트 버스는 화면에 진행 상황을 알리는 통로이고 서버가 보내는 메시지 큐와도 구분해야 합니다.

remote_sync_service.dart의 _syncCollectionDiff(collectionID, sinceTime)는 getEncryptedFilesDiff()를 호출하고 삭제·갱신 내역을 반영합니다. 이어 latestUpdatedAtTime을 저장하고 hasMore이면 다음 페이지를 가져옵니다. 체크포인트를 언제 갱신하는지, 삭제가 어떤 형태로 전달되는지를 함께 읽어 보세요.

4-5. 패턴 ④ 공통 기능과 플랫폼 어댑터의 경계를 둡니다

rust/bindings/frb/photos/src/api/ml_indexing_api.rs의 analyze_image_rust()는 요청을 공통 형태로 바꾸고 spawn_blocking_with()에서 indexing::analyze_image()를 실행합니다. rust/bindings/napi/photos/src/lib.rs의 AnalyzeImageTask::compute()도 같은 공통 분석 함수를 부릅니다. Flutter와 Electron의 호출 방식은 달라도 분석 엔진을 함께 쓸 수 있는 구조입니다.

웹은 또 다른 경계가 있습니다. web/packages/base/crypto/index.ts의 createComlinkCryptoWorker()가 Worker를 만들고, web/packages/base/crypto/worker.ts의 CryptoWorker가 libsodium 함수들을 노출합니다. 암호화 작업이 화면의 주 실행 흐름을 오래 붙잡지 않도록 하는 구성입니다.

Rust의 WASM 바인딩도 있지만 웹 암호화가 전부 Rust로 바뀐 것은 아닙니다. rust/bindings/wasm/photos/Cargo.toml은 공통 WASM 모듈의 기능을 선택하고, 앞서 본 웹 업로드 경로는 CryptoWorker를 사용합니다. 공통화된 부분과 아직 별도로 유지되는 부분을 함께 읽는 것이 실제 모노레포 분석입니다.

5디렉토리 구조 해부

mobile/apps/photos와 web/apps/photos는 같은 제품의 다른 클라이언트입니다. 반면 server/pkg/api와 server/pkg/repo는 같은 서버의 다른 계층입니다. 이 두 분류를 혼동하면 “사진 코드가 왜 여러 군데 있지?”라는 의문이 생깁니다.

5-1. 처음에는 이 여섯 지점만 읽어도 됩니다

그다음 mobile/apps/photos/lib/db에서 기기의 장부를, server/migrations에서 서버 장부의 변경 이력을 보세요. 양쪽 모두 파일을 다루지만 로컬 파일과 서버 파일을 연결해야 하는 문제와 계정 전체의 권한을 관리하는 문제는 다릅니다.

6학습 포인트 (기술별)

6-1. Dart·Flutter: 비동기는 화면 밖에서도 중요합니다

Future는 나중에 끝나는 결과이고 Completer는 그 결과를 직접 완료시키는 도구입니다. SyncService.sync()에서 completer를 저장해 두는 이유는 여러 요청이 같은 진행 중 작업을 가리키게 하기 위해서입니다. finally가 빠지면 예외 이후에도 “실행 중” 상태가 남을 수 있다는 점을 생각해 보세요.

_registerListeners()는 연결 상태·계정 설정·구독 변경·동기화 상태를 듣습니다. 실습으로 각 이벤트의 발생 시점과 sync() 진입 조건을 표로 그려 보세요. UI 버튼 하나만 생각하는 예제보다 실제 앱에서 왜 중복 방지가 필요한지 잘 드러납니다.

6-2. Go·HTTP: 입력을 받는 함수와 결정을 내리는 함수를 나눕니다

FileHandler.CreateOrUpdate()에서 JSON 바인딩과 서버 시각 부여를 찾고, FileController.GetUploadURLWithMetadata()에서 용량 제한을 찾으세요. 실습은 “크기 0, 허용 크기 초과, 잘못된 MD5, 잔여 용량 부족”을 각각 어느 조건이 거절하는지 연결하는 것입니다.

server/pkg/middleware/auth.go의 TokenAuthMiddleware()도 같이 읽으세요. 토큰 검사와 앱 구분 뒤 사용자 ID를 요청 헤더에 설정합니다. 로그인한 사용자라는 사실과 특정 앨범을 수정할 수 있다는 권한을 별도로 확인해야 하는 이유를 설명해 보세요.

6-3. PostgreSQL: 테이블보다 먼저 불변 조건을 찾습니다

FileRepository.Create()는 파일 행 하나만 삽입하지 않습니다. 앨범 연결, 객체 위치, 사용량도 일치해야 합니다. 실습으로 SQL 단계마다 실패 표시를 놓고, Rollback()이 어떤 DB 변경을 되돌리는지 적어 보세요. 이미 S3에 올라간 암호문은 이 목록에 들어가지 않습니다.

6-4. Rust·암호화: 안전한 타입과 실패 경로를 읽습니다

rust/crates/core/src/crypto/secret.rs의 SecretVec·SecretString은 Zeroize와 ZeroizeOnDrop을 사용하고, 디버그 출력은 비밀 대신 [REDACTED]를 반환합니다. into_vec()처럼 일반 값으로 꺼내는 경로도 있으므로 모든 복사본이 자동으로 지워진다고 확대해서는 안 됩니다.

실습으로 secretbox.rs의 짧은 암호문 거절, 잘못된 키 테스트, stream.rs의 잘림 테스트를 읽으세요. 같은 결과를 다시 복호화하는 정상 사례뿐 아니라, 어떤 입력을 거절해야 하는지가 라이브러리 계약의 절반입니다.

6-5. 웹·Worker·FFI: 경계에서 생기는 비용을 봅니다

web/packages/base/crypto/index.ts는 Worker 안인지 확인해 직접 호출과 원격 호출을 나눕니다. Comlink는 다른 실행 흐름의 함수를 비동기 함수처럼 부르게 돕습니다. 화면이 멈추지 않는다는 이점과 별개로 데이터 전달·복사·오류 전달 비용은 남습니다.

실습으로 Flutter의 AnalyzeImageRequest와 N-API의 같은 목적 요청을 비교하세요. 전자는 image_path로 파일 위치를, 후자는 image_bytes로 바이트를 받는 경로가 있습니다. 공통 분석 엔진을 재사용하더라도 플랫폼에 맞춘 입력 변환이 필요한 이유를 설명할 수 있습니다.

6-6. ML·검색: 모델보다 데이터 이동을 먼저 봅니다

ml_indexing_api.rs의 init_ml_runtime()과 analyze_image_rust()는 ensure_indexing_models()를 거쳐 모델 경로를 확보합니다. 요청의 run_faces, run_clip, run_pets로 분석 종류를 선택합니다. 모델 다운로드와 분석 실행은 서로 다른 실패를 가진 작업입니다.

실습은 결과의 얼굴 목록과 CLIP 임베딩을 구분해 표로 정리하는 것입니다. 사진을 숫자 벡터로 바꾸는 단계와, 벡터를 저장·검색하는 단계도 다릅니다. rust/crates/photos/src/ml_db와 rust/crates/vecdb가 다음으로 읽을 곳입니다.

6-7. CI·릴리스: 테스트 실행 단위도 아키텍처입니다

.github/workflows/rust-test.yml은 workspace와 CLI를 별도 suite로 둡니다. 주석은 SQLCipher feature가 다른 SQLite 테스트에 합쳐지지 않도록 분리한다고 설명합니다. cargo test --locked와 실행 대상 분리는 단순 속도 조절을 넘어 의존성 조합을 통제하는 역할을 합니다.

한 기능을 배울 때는 정상 동작 하나와 실패 조건 하나를 반드시 짝지어 읽으세요. 동기화에는 중복 요청, 암호화에는 잘림, DB에는 부분 실패, 모델에는 다운로드 실패를 붙이면 기술 이름을 외우는 공부에서 시스템을 이해하는 공부로 넘어갈 수 있습니다.

7하드웨어 / 시스템 요구사항

7-1. 서버 문서가 명시하는 최소 조건

docs/docs/self-hosting/installation/requirements.md는 quickstart 클러스터에 CPU 1코어, RAM 1 GB를 최소 조건으로 적습니다. 이 수치는 공식 문서 기준이며, 대량 라이브러리의 처리량을 측정한 벤치마크나 소스 빌드 권장 사양은 아닙니다.

모바일 최소 버전은 Photos 앱의 설정 기준입니다. 서버 README에는 Docker 없이 단일 바이너리로 실행하는 선택지도 있으므로, Docker가 Go 서버 자체의 필수 런타임이라는 뜻은 아닙니다. 다만 DB와 객체 저장소는 별도로 준비해야 합니다.

7-2. 메모리 사용은 클라이언트에서도 생깁니다

rust/crates/core/src/crypto/argon.rs의 기본 상수는 INTERACTIVE 64 MiB·2회, MODERATE 256 MiB·3회, SENSITIVE 1 GiB·4회입니다. 그런데 derive_sensitive_adaptive()는 실제로 256 MiB·16회에서 시작하고, 실패하면 메모리를 절반으로 줄이고 반복 횟수를 늘려 128 MiB까지 시도합니다.

이는 architecture/README.md의 “SENSITIVE 한계에서 시작해 조절”이라는 개념 설명보다 구체적인 구현입니다. 상수 SENSITIVE가 존재한다고 실제 시작 메모리가 언제나 1 GiB인 것은 아닙니다. 또한 이 비용은 키 유도 작업의 값이지 로그인 전체나 앱 전체의 메모리 상한이 아닙니다.

7-3. 개발 PC 자원은 학습 범위에 맞춰 잡습니다

저장소에는 모든 제품을 한꺼번에 개발하는 PC의 공식 최소 RAM이 명시돼 있지 않습니다. 다음 수치는 학습을 위한 여유 자원 제안이며 측정된 공식 요구사항이 아닙니다. 소스 읽기만 할 때에는 전체 SDK를 설치할 필요가 없습니다.

rust/crates/ml/Cargo.toml에는 OS별 Core ML·WebGPU·XNNPACK 관련 feature가 나뉩니다. 이것이 서버에 GPU가 필수라는 뜻은 아닙니다. 분석 장치와 모델, 활성화된 실행 경로에 따라 실제 성능이 달라지므로 특정 초당 처리량은 제시하지 않습니다.

8직접 해볼 수 있는 실습 과제

첫 실습부터 계정이나 실제 사진을 준비할 필요는 없습니다. 읽은 코드의 입력·출력·실패 조건을 작은 결과물로 남기면 됩니다. 실습의 완료 기준은 코드를 많이 읽는 것이 아니라, 특정 실패 상황에서 데이터가 어떻게 남는지 설명하는 것입니다.

# 저장소 실행과 무관한 경계값 계산 예제
CHUNK = 4 * 1024 * 1024
for size in (0, CHUNK - 1, CHUNK, CHUNK + 1):
    chunks = max(1, (size + CHUNK - 1) // CHUNK)
    print(size, chunks)
# 청크 수: 차례대로 1, 1, 1, 2

9관련 기술 심화 학습 로드맵

하루에 폴더 하나씩 끝내려고 하면 규모에 압도되기 쉽습니다. 주당 4~6시간 정도를 가정한 학습 계획이며, 각 주의 마지막에 설명 그림이나 표 하나를 남깁니다. 처음 접하는 언어는 모든 문법을 끝내기보다 함수 입력·출력·조건문부터 읽어도 됩니다.

각 주에 새로운 기능을 하나 더 읽기보다 지난주 그림의 틀린 화살표를 고치는 데 시간을 쓰세요. 폴더 이름을 기억하는 것보다, 입력과 결과가 어느 경계에서 바뀌는지 설명하는 데 집중합니다.

9-1. 목표에 따라 마지막 두 주를 바꿔도 됩니다

• 모바일 개발: 로컬 파일과 서버 파일의 매칭, 업로드 큐, 권한 변화가 동기화에 미치는 영향을 더 추적합니다.
• 백엔드 개발: 접근 제어, 임시 객체 정리, 복제 필요 기록, DB 마이그레이션을 더 깊게 읽습니다.
• 시스템·Rust 개발: 비밀값 타입, 스트림 경계, 플랫폼 어댑터, feature 조합과 CI suite 분리를 연결합니다.
• 검색·ML 개발: 모델 확보 → 이미지 분석 → 벡터 저장 → 검색의 각 단계에서 데이터와 오류가 어떻게 바뀌는지 살펴봅니다.

이 저장소를 다 읽는 것보다, 한 흐름을 다른 사람에게 소스 근거와 함께 설명할 수 있는 상태가 더 좋은 학습 목표입니다. 예를 들어 “새 사진이 다른 기기에 나타나기까지”를 입력·암호화·저장·동기화·복호화로 나눠 설명해 보세요. 설명이 막히는 경계가 다음에 읽을 곳입니다.

10핵심 키워드 사전

11참고 링크

11-1. 공식 저장소와 문서

• Ente 공식 저장소 · 제품 소개, 기여 안내, 보안 정책의 시작점입니다.
• 커밋 기준 암호화 아키텍처 문서 · 키 계층과 공유의 개념을 읽습니다.
• Ente CLI 공식 도움말 · 새 명령과 자동화 방법. 온라인 문서는 이후 바뀔 수 있습니다.
• 새 CLI로 이전하는 공식 문서 · Go CLI와 Rust CLI 명령의 차이를 확인합니다.
• 자체 호스팅 도움말 · 설치·운영·복구 관련 문서의 입구입니다.
• 커밋 기준 시스템 요구사항 · CPU·RAM·Compose 버전의 근거입니다.
• 백업 공식 문서 · 객체 데이터와 DB를 함께 보존해야 하는 이유를 설명합니다.
• ente-cli-v0.4.0 릴리스 · 분석일의 최신 릴리스이며 Photos 앱 전체 버전과 구별합니다.

11-2. 이 글의 핵심 코드

• 웹 업로드 서비스 · 파일 키 생성과 암호화된 업로드 데이터 구성.
• 파일 controller · 업로드 조건 검사와 서명된 URL.
• 파일 repository · DB 트랜잭션과 임시 객체·복제 기록의 연결.
• 모바일 동기화 조정 · 진행 중 Future 공유와 이벤트 처리.
• 원격 증분 동기화 · 삭제·갱신·체크포인트·다음 페이지 처리.
• Rust 스트림 암호화 · 청크 경계와 정상 종료·잘림 테스트.
• Rust 로그인 흐름 · 인증 단계와 키 복호화를 연결하는 실제 상태 처리.
• Flutter와 Rust ML 연결 · 플랫폼 요청을 공통 분석 입력으로 변환.

11-3. 관련 기술을 더 배울 공식 자료

• Dart 비동기 학습 · Future와 async/await부터 익힙니다.
• Flutter 문서 · 화면과 플랫폼 통합을 공부할 때 참고합니다.
• Go 문서 · 구조체·메서드·오류 처리·DB 사용의 배경을 익힙니다.
• PostgreSQL 트랜잭션 · 여러 SQL을 묶는 의미를 확인합니다.
• Rust 공식 책 · 소유권과 Result를 익힌 뒤 공통 crate를 읽습니다.
• libsodium 문서 · secretbox·secretstream·키 유도의 배경을 확인합니다.
• Web Workers 문서 · UI 흐름과 별도 작업 실행의 관계를 공부합니다.
• ONNX Runtime 문서 · 모델 실행과 플랫폼별 실행 제공자를 구분합니다.

11-4. 현재 상태 (2026-10-23 확인)

11-5. 언어별 코드 규모와 집계 범위

커밋 939ee85 기준 Git 추적 일반 파일의 확장자별 물리적 줄 수입니다. 빈 줄·주석·테스트·추적된 생성 코드를 포함하며 Git 내부 데이터·비추적 파일·바이너리 자산은 아래 언어 집계에서 제외합니다. 직접 작성한 구현만의 줄 수나 기능의 복잡도 순위로 읽으면 안 됩니다.

대부분의 Dart는 mobile/에 있고, TypeScript 중 236,783줄은 web/에 있습니다. Rust에는 생성 바인딩도 포함됩니다. 집계는 확장자 기반이므로 HTML·CSS·문서·설정·번역 자산 전체의 합계와는 다릅니다. 누적 커밋 수와 기여자별 기여량을 산정하려면 전체 Git 이력이 필요합니다.

가장 오래 남길 배움은 암호화·저장·동기화의 경계마다 지켜야 할 조건을 찾아내는 읽기 습관입니다. 그 조건을 함수 이름과 함께 설명할 수 있다면, 다른 클라우드 앱을 볼 때도 같은 질문을 던질 수 있습니다.