Electron 대신 15MB SwiftUI 메뉴 바 앱을 만든 이유
(dev.to)제가 사용해 본 모든 developer dashboard는 잊어버리기 일쑤인 browser tab이거나, 고작 숫자 세 개를 보여주려고 200MB의 RAM을 잡아먹는 Electron app뿐이었습니다. 저는 다른 것을 원했습니다. menu bar에 조용히 자리 잡고, 필요한 정보만 보여주며, 작업에 방해가 되지 않는 그런 도구 말이죠. 그래서 Pulse를 만들었습니다. 문제점 저의 일상적인 workflow는 Claude Code, Codex, OpenRouter와 같은 여러 AI coding tool들을 동시에 사용하는 것인데, 각 도구마다 별도의 browser tab에 usage dashboard가 떠 있습니다. 게다가, 저는 여러 local...
- 1Binary 크기 혁신: Electron(~200MB) 대비 SwiftUI(15MB)로 약 92% 감소
- 2메모리 효율성: Idle RAM 사용량을 120MB에서 12MB 수준으로 1/10 절감
- 3사용자 경험: 네이티브 API 활용으로 다크 모드 및 알림 기능의 완벽한 통합
- 4트레이드오프: macOS 전용이라는 플랫폼 제한과 SwiftUI의 높은 학습 곡선 수용
- 5핵심 가치: 컨텍스트 스위칭을 최소화하는 '보이지 않는 유틸리티' 구현
왜 중요한가
배경과 맥락
업계 영향
한국 시장 시사점
AI 큐레이터 의견: 이 글은 '기술적 편의성'과 '사용자 경험(UX)의 본질' 사이의 트레이드오프를 날카롭게 지적합니다. 많은 창업자가 빠른 출시를 위해 Electron이나 웹 기술을 선택하지만, 제품의 핵심 가치가 '상주하며 정보를 제공하는 것'이라면 기술 스택 선택의 기준은 '개발 속도'가 아닌 '시스템과의 조화'가 되어야 합니다.
스타트업 창업자라면 'Over-engineering'을 경계하되, 제품의 'Residency(상주성)'를 고민해야 합니다. 만약 당신의 제품이 사용자의 백그라운드에서 계속 돌아가야 하는 유틸리티라면, 100MB의 RAM을 더 쓰는 것은 단순한 비용 문제가 아니라 사용자 이탈의 직접적인 원인이 될 수 있습니다. '작고, 빠르고, 조용한' 제품이 주는 강력한 사용자 경험은 기술적 한계를 극복한 결과물입니다.
댓글
아직 댓글이 없습니다. 첫 댓글을 남겨보세요.