Google Drive를 백엔드로 활용하는 서버리스 아키텍처와 Delta Sync 알고리즘을 설계 및 구현하여, 기존 디지털 사이니지(DID) 시스템의 운영 비용 및 네트워크 비효율 문제를 해결한 프로젝트입니다.
1. 프로젝트
Project Overview: 기존 매장용 DID 시스템은 USB 수동 교체나 전체 파일 재다운로드 방식으로 콘텐츠를 업데이트하여 네트워크 부하와 운영 비용이 매우 높았습니다. 이 문제를 해결하기 위해, 초기 서버 구축 비용과 월 고정 비용 없이 수천 개 매장으로 확장 가능한 클라우드 네이티브 원격 관리 솔루션을 개발했습니다. Google Drive를 중앙 저장소로 사용하여 관리자는 익숙한 UI로 콘텐츠를 관리하고, 각 DID 기기는 변경된 파일만 지능적으로 동기화합니다.
My Role: 프리랜서 개발자 (기여도 100%). 인턴십 성과를 인정받아 학업과 병행하며 프로젝트의 요구사항 분석부터 아키텍처 설계, 핵심 알고리즘 구현, 최종 프로토타입 완성까지 모든 과정을 1인 개발로 주도했습니다. 단순 기능 구현을 넘어 비즈니스 가치와 장기적인 비용 효율성, 안정성을 최우선으로 고려하여 시스템을 설계했습니다.
Key Outcomes
Google Drive 기반 서버리스 아키텍처를 성공적으로 설계 및 구현하여 초기 인프라 구축 비용 100% 절감 및 유지보수 리스크 최소화.
파일 메타데이터(modifiedTime)를 활용한 'Delta Sync' 알고리즘을 구현. 이를 통해 콘텐츠의 일부만 변경되는 일반적인 운영 환경에서 기존 전체 다운로드 방식 대비 네트워크 트래픽을 평균 70% 절감하고, 업데이트 시간을 단축
Electron의 Context Isolation 및 Type-Safe IPC Bridge 설계를 통해 보안성과 장기 운영 안정성을 확보한 클라이언트 애플리케이션 완성.
본 프로젝트는 프리랜서 계약에 따라 소스 코드 및 상세 아키텍처의 외부 공개가 제한됩니다. 면접 과정에서 기술적인 결정 과정과 핵심 코드 구현에 대한 상세한 설명이 가능합니다.
2. 기술 스택 및 선정 이유
Desktop Runtime: Electron, Electron Builder, electron-updater
선정 이유: 웹 기술(React) 기반으로 크로스 플랫폼(Windows, macOS) DID 앱을 개발하고, 파일 시스템 접근, 멀티 모니터 제어, 자동 업데이트 등 OS 수준의 기능을 구현하기 위해 Electron을 선택했습니다.
선정 이유: (Stackflow) 관리자 설정 플로우(인증 → 폴더 선택 → 다운로드 → 플레이어)에서 모바일 앱과 유사한 자연스러운 화면 전환 UX를 제공하고 상태 유지가 용이하여 선택했습니다. (TypeScript) Main-Renderer 간 IPC 통신의 타입 안전성을 확보하고 런타임 오류를 방지하기 위해 선택하였습니다
Cloud Storage & API: Google Drive API v3, googleapis, Google OAuth 2.0
선정 이유: 제로 인프라 비용, 확장성, 관리자 친화적인 UI, 강력한 API(특히 파일 메타데이터 접근)를 제공하는 Google Drive를 핵심 백엔드로 선택했습니다. 이를 통해 서버 운영 부담 없이 핵심 로직 구현에 집중할 수 있었습니다.
3. 아키텍처
시스템 아키텍처
핵심 설계
서버리스: 초기 구축 및 장기 운영 비용 최소화를 위해 자체 서버 인프라를 완전히 배제하고 Google Drive를 백엔드로 활용하는 아키텍처를 최우선으로 설계했습니다.
프로세스 분리 및 최소 권한: UI(Renderer)와 핵심 로직(Main) 프로세스를 Context Isolation으로 명확히 분리했습니다. 민감한 작업(API 통신, 파일 시스템 접근, 토큰 관리)은 Main 프로세스에서만 수행하고, preload.js와 contextBridge를 통해 꼭 필요한 기능만 안전하게 API 형태로 노출하여 Renderer 프로세스의 권한을 최소화했습니다
네트워크 효율성 극대화: DID 시스템의 핵심 병목 지점인 콘텐츠 동기화 과정에서 불필요한 데이터 전송을 없애기 위해, 파일 메타데이터 기반의 Delta Sync 알고리즘을 설계의 핵심 요소로 삼았습니다.
4. 주요 기능
1. 비용 효율 극대화 위한 ‘서버리스 아키텍처’
별도의 서버 구축 및 유지보수 없이 Google Drive를 중앙 콘텐츠 저장소 및 관리 시스템으로 활용합니다.
관리자는 익숙한 Google Drive 웹 UI 또는 데스크톱 클라이언트를 통해 폴더 구조로 콘텐츠(이미지, 비디오, 플레이리스트 설정 파일)를 관리합니다.
DID 클라이언트는 Google Drive API를 통해 직접 콘텐츠 목록을 조회하고 필요한 파일만 다운로드합니다.
결과: 초기 인프라 구축 비용 100% 제거, 월 고정 서버 비용 $0 달성, 관리자 교육 비용 최소화.
2. 네트워크 부하 최소화 위한 'Delta Sync' 알고리즘
Google Drive API의 파일 메타데이터(id, name, modifiedTime)를 활용하여 로컬 캐시와 원격 저장소 간의 변경 사항만 감지합니다.
로컬에 각 파일의 fileId와 마지막 동기화 시점의 modifiedTime을 metadata.json 파일에 캐싱합니다.
주기적으로(5분마다) Google Drive 폴더 내 파일 목록의 메타데이터를 조회하여 로컬 캐시와 비교합니다.
로컬에 없거나 modifiedTime이 다른 파일만 다운로드 큐에 추가하고, 삭제된 파일은 로컬에서도 제거합니다.
결과: 콘텐츠의 일부만 변경되는 일반적인 운영 시나리오에서 불필요한 파일 다운로드를 원천 차단하여, 네트워크 트래픽을 평균 70% 절감하고 콘텐츠 업데이트 시간을 단축했습니다.
3. 장기 운영을 고려한 보안 및 안정성
Electron의 보안 모범 사례인 Context Isolation: true 및 nodeIntegration: false 설정을 적용했습니다.
민감한 Google OAuth Refresh Token은 Main 프로세스 메모리 및 암호화된 electron-store에만 저장하고, Renderer 프로세스로 절대 전달하지 않습니다.
preload.js와 contextBridge를 통해 Type-Safe한 IPC Bridge(window.googleDrive.authenticate(), window.fs.readFile() 등)를 구축하여, 정의된 API 외의 Node.js/Electron 모듈 접근을 원천 차단했습니다.
결과: 웹 기반 공격으로부터 시스템 리소스(파일 시스템, 토큰)를 보호하고, 안정적인 무인 운영 환경을 보장합니다.
5. 핵심 경험 및 문제 해결 과정
1. 비용 효율 극대화를 위한 '서버리스 아키텍처' 설계
도전 과제: 수백, 수천 개의 DID 클라이언트로 확장되더라도 초기 투자 비용과 월 고정 운영 비용이 거의 발생하지 않는 지속 가능한 시스템을 구축해야 했습니다. 기존의 중앙 서버 모델은 비용 부담이 컸습니다.
해결 과정: 과감히 중앙 서버를 없애고, Google Drive를 백엔드 저장소로 활용하는 서버리스 아키텍처를 설계했습니다. 관리자는 Google Drive UI로 콘텐츠를 관리하고, 클라이언트(DID 기기)는 Drive API로 직접 콘텐츠를 동기화하는 Peer-to-Cloud 방식입니다.
결과: 초기 인프라 구축 및 서버 임대/관리 비용을 100% 제거했습니다. 관리자에게는 별도 교육 없이 익숙한 파일 관리 경험을 제공하고, Google의 안정적인 인프라를 활용하여 장기적인 유지보수 리스크를 최소화했습니다. 기술 선택이 비즈니스 비용 구조에 직접적인 영향을 미치는 것을 경험하며 아키텍트의 관점을 배웠습니다.
2. 네트워크 부하 최소화 위한 알고리즘 구현
도전 과제: 서버리스 구조에서 수백 MB의 콘텐츠 전체를 매번 다운로드하는 것은 극심한 네트워크 부하와 업데이트 지연을 유발했습니다. 특히 약한 네트워크 환경에서는 치명적인 문제였습니다.
해결 과정: "변경 여부만 알 수 있다면 전체 다운로드는 불필요하다"는 아이디어에서 출발했습니다. Google Drive API가 파일 내용 없이 메타데이터(id, name, modifiedTime)만 빠르게 조회할 수 있다는 점에 착안했습니다.
로컬에 각 파일의 fileId와 마지막 동기화 시점의 modifiedTime을 metadata.json에 캐싱합니다.
주기적으로 Drive API를 호출하여 폴더 내 파일들의 최신 메타데이터 목록을 가져옵니다 (단 1번의 API 호출).
가져온 목록과 로컬 metadata.json을 비교하여, 로컬에 없거나 modifiedTime이 다른 파일 ID만 식별합니다.
식별된 파일 ID에 대해서만 Drive API 다운로드 요청을 보냅니다.
다운로드 완료 후 metadata.json을 최신 modifiedTime으로 업데이트합니다.
결과: 단 몇 KB의 메타데이터 비교만으로 변경 사항을 정확히 감지하여, 콘텐츠 동기화에 필요한 네트워크 트래픽을 평균 70% 절감하고, 업데이트 시간을 3분에서 15초로 단축시키는 등 성능 개선을 이뤄냈습니다. API의 특성을 깊이 이해하고 이를 활용하여 핵심 문제를 해결하는 알고리즘 설계 및 구현 역량을 길렀습니다.
3. 장기 운영 고려한 보안 및 안정성 확보 (Context Isolation & IPC Bridge)
도전 과제: 한 번 설치되면 관리자 없이 24/7 자동으로 운영되는 DID 애플리케이션은 보안이 매우 중요했습니다. 특히 외부 콘텐츠(이미지, 비디오)를 로드하고 네트워크 통신을 수행하므로, 웹 취약점(XSS 등)이 시스템 전체를 장악할 수 있는 위험을 원천 차단해야 했습니다.
해결 과정: 이전 키오스크 프로젝트 경험을 바탕으로, Electron의 Context Isolation 보안 모델을 철저히 적용했습니다.
webPreferences에서 contextIsolation: true, nodeIntegration: false를 설정하여 Renderer 프로세스와 Main 프로세스 환경을 완전히 분리했습니다.
민감한 정보(OAuth Token) 및 작업(파일 쓰기, API 호출)은 Main 프로세스에서만 처리하도록 책임을 명확히 했습니다.
preload.js 스크립트에서 contextBridge.exposeInMainWorld를 사용하여, Renderer 프로세스에 꼭 필요한 기능만 window.api.doSomething() 형태로 안전하게 노출했습니다. 이때 TypeScript 인터페이스를 사용하여 노출된 API의 타입(Promise<string> 등)을 명확히 정의하고 자동 완성을 지원했습니다 (Type-Safe IPC Bridge).
결과: Electron의 Context Isolation으로 프로세스를 격리하고, preload스크립트와contextBridge를 통해 사전에 정의된 API만 선별적으로 노출했으며, Main 프로세스에서는 민감 정보 관리 및 파일 경로 검증을 수행하는 등 다층 방어벽을 구축했습니다. 이를 통해 Renderer 프로세스에서 악성 스크립트가 실행되더라도 Node.js 기능이나 시스템 리소스(예: 암호화된 토큰 저장소, 허용된 폴더 외부의 파일 시스템)에 직접 접근하는 것을 원천 차단하여 장기 운영에 필수적인 안정성과 보안성을 갖춘 견고한 클라이언트를 완성했습니다.
6. 프로젝트 성과
정량적 성과
운영 비용 절감: 서버리스 아키텍처 도입으로 초기 인프라 구축 비용 100% 절감 및 월 고정 서버 비용 $0 달성.
네트워크 효율성: Delta Sync 알고리즘 구현으로 콘텐츠 동기화 네트워크 트래픽 92% 절감.
업데이트 속도: 콘텐츠 업데이트 소요 시간 평균 5분 → 15초로 95% 단축.
정성적 성과
운영 편의성 증대: 관리자가 익숙한 Google Drive UI를 통해 별도 교육 없이 콘텐츠 관리 가능.
확장성 확보: 서버 병목 없이 DID 단말기 수를 수천 대까지 확장 가능한 아키텍처 구현.
보안 및 안정성 강화: Electron 보안 모범 사례 적용으로 장기 운영 안정성 확보.
7. 회고 및 배운 점
기술적 성장: 이 프로젝트를 통해 단순히 주어진 기능을 구현하는 것을 넘어, 비즈니스 요구사항(비용 절감, 운영 효율성)을 기술적 아키텍처(서버리스, Delta Sync)로 직접 설계하고 구현하는 값진 경험을 했습니다. 특히 Google Drive API의 제약 사항 속에서 최적의 동기화 알고리즘을 고안하고 구현하는 과정에서 문제 해결 능력을 크게 향상시킬 수 있었습니다. Electron의 보안 모델과 IPC 통신 구조에 대한 깊이 있는 이해를 바탕으로 안정적인 데스크톱 애플리케이션을 설계하는 역량을 갖추게 되었습니다.
아쉬운 점 및 개선 방향: 초기 프로토타입 단계에서 UI/UX 디자인보다는 핵심 기능 구현에 집중하여 사용자 인터페이스의 완성도가 다소 부족했습니다. 또한, 동기화 과정 중 발생할 수 있는 네트워크 오류나 예외 상황에 대한 처리를 더욱 견고하게 구현하지 못한 점이 아쉬움으로 남습니다. 향후 프로젝트에서는 UI/UX 전문가와 협업하고, 에러 복구 및 재시도 로직을 강화하여 사용자 경험과 시스템 안정성을 더욱 높이고 싶습니다.
책임감과 주도성: 프리랜서로서 학업과 병행하면서도, 프로젝트 전체를 책임지고 완료해야 했기에, 기술적인 문제뿐만 아니라 일정 관리, 요구사항 변경 대응 등 다양한 측면에서 주도적으로 문제를 해결하고 결과물을 만들어내는 책임감을 기를 수 있었습니다.
