Dropbox/Google Drive 대신, Locker로 나만의 클라우드 구축!

Locker는 Next.js 16을 프론트엔드(Frontend)로, PostgreSQL을 데이터베이스로 사용하며, tRPC를 통해 타입 안전한 API를 제공한다. 또한, BetterAuth를 사용하여 인증을 처리하고, UI는 Tailwind CSS로 구성되었다. 백엔드(Backend)는 Go로 구현되었으며, S3, R2, Vercel Blob 등 다양한 스토리지 제공자를 지원하여 유연성을 확보했다. 특히, 단일 환경 변수 설정만으로 스토리지 제공자를 변경할 수 있도록 설계되어, 데이터 격리 아키텍처(Data Isolation Architecture)를 쉽게 구현할 수 있다.

커뮤니티에서는 Locker가 Dropbox/Google Drive의 스토리지 비용 절감이라는 장점을 제공하지만, Dropbox의 핵심 가치는 OS와의 긴밀한 통합에 있다는 점을 지적한다. 즉, 데스크톱 및 모바일 운영체제에서 파일 동기화(File Synchronization)를 원활하게 지원하는 것이 중요하며, Locker는 이 부분에서 추가적인 노력이 필요하다는 의견이 제시되었다. 또한, 사용자 인터페이스(User Interface) 및 사용자 경험(User Experience) 개선에 대한 요구도 존재한다.

Locker를 사용하면 S3, R2, Vercel Blob 등 다양한 스토리지 백엔드를 선택할 수 있지만, 스토리지 비용(Storage Cost)을 고려해야 한다. 특히, 대용량 파일을 저장하고 트래픽이 많은 경우, S3의 비용이 Dropbox/Google Drive보다 높을 수 있다. R2는 트래픽 비용이 무료이므로 대안이 될 수 있으며, Google AI plan과 같은 번들 상품을 활용하는 것도 비용 효율적인 방법이 될 수 있다. 데이터 미저장 정책(Zero-Retention Policy)을 고려하는 사용자에게는 자체 하드웨어 구축도 대안이 될 수 있다.

Locker는 이메일/비밀번호 및 Google OAuth 인증을 지원하며, 세션은 암호화된 쿠키(Encrypted Cookies)를 사용하여 서버 측에서 관리된다. 또한, API 키를 통해 프로그래밍 방식(Programmatic Access)으로 파일에 접근할 수 있으며, tRPC를 통해 타입 안전성을 보장한다. 하지만, 데이터 미저장 정책(Zero-Retention Policy)을 구현하지 않으면, 서버가 영구적으로 사라질 경우 데이터 접근이 불가능해질 수 있다는 점을 유의해야 한다. GDPR 규제 준수(GDPR Compliance)를 위해서는 데이터 관리 및 접근 권한 설정에 대한 추가적인 고려가 필요하다.