Claude는 왜 Electron 앱인가요?
Source: Hacker News
코드가 무료라면, 왜 모든 앱이 네이티브가 아닌가?
코딩 에이전트의 현황은 이 사실로 요약할 수 있습니다.
Claude는 Rust로 (거의) C‑컴파일러를 구현하는 에이전트 스웜에 2만 달러를 썼지만, 데스크톱 Claude는 Electron 앱입니다.
만약 익숙하지 않다면, Electron은 웹 기술—HTML, CSS, JavaScript—을 사용해 데스크톱 애플리케이션을 만드는 프레임워크입니다. Windows, macOS, Linux에서 동작하는 하나의 데스크톱 앱을 만들 수 있게 해 주며, 개발자가 기존 웹‑앱 코드를 재사용할 수 있게 합니다. 여러분이 매일 사용하고 있을 가능성이 높은 많은 앱이 Electron으로 만들어졌습니다: Slack, Discord, VS Code, Teams, Notion 등 (위키피디아 목록).
Electron의 단점
- 용량: 각 앱이 자체 Chromium 엔진을 포함하므로 최소 크기가 보통 수백 메가바이트에 달합니다.
- 성능: Electron 앱은 느리거나 반응이 느릴 수 있습니다.
- 통합: OS‑특화 기능과의 통합이 그리 깊지 않습니다.
이 문제들은 영리한 개발과 플랫폼‑특화 코드를 통해 어느 정도 완화될 수 있지만, 실제로는 드뭅니다. 단일 코드베이스, 크로스‑플랫폼 도달성, 웹 기술에 대한 친숙함이라는 장점이 많은 팀에게는 단점보다 더 큰 이점을 제공합니다.
코딩 에이전트의 약속
코딩 에이전트는 명확한 사양과 테스트 스위트가 주어졌을 때, 크로스‑플랫폼·크로스‑언어 구현에 뛰어납니다 (예시 기사). 이론적으로는 Electron의 장점을 무력화할 수 있습니다: 하나의 웹 앱을 작성하는 대신 하나의 사양을 작성하고 에이전트가 각 플랫폼에 맞는 네이티브 코드를 생성하도록 하면, 작은 집중된 팀으로도 빠르고 성능 좋은 앱을 제공할 수 있습니다.
우리가 아직도 Electron을 사용하는 이유
AI‑보조 코딩 분야의 선두주자인 Anthropic조차도 Claude를 Electron 데스크톱 앱으로 배포하고 있습니다—느리고, 버그가 많으며, 부피가 큽니다. 그 이유는 다음과 같습니다:
- “마지막 10 %” 문제 – 에이전트는 개발 초기 90 %를 잘 처리하지만, 엣지 케이스 처리, polishing, 지속적인 유지보수는 여전히 어렵고 지루하며 상당한 인간의 지도가 필요합니다.
- 현실 세계의 복잡성 – 소프트웨어가 실제 사용에 들어가면, 예상치 못한 복잡하고 엉뚱한 상황이 발생하고, 이는 에이전트가 완전히 자동화할 수 없는 인간의 판단을 요구합니다.
- 지원 범위 – macOS, Windows, Linux 세 개의 별도 네이티브 앱을 만들면 버그 수정 및 지원 작업이 세 배로 늘어납니다. Electron의 단일 래퍼는 많은 플랫폼‑특화 문제를 완화합니다.
Anthropic의 Rust‑기반 C 컴파일러 사례가 이 도전을 보여줍니다:
결과 컴파일러는 Opus의 능력 한계에 거의 도달했습니다. 위의 몇몇 제한 사항을 (열심히!) 고치려 했지만 완전히 성공하지 못했습니다. 새로운 기능과 버그‑수정이 기존 기능을 자주 깨뜨렸습니다.
시간과 팀 규모를 고려하면 컴파일러는 인상적이지만, 실제로는 거의 사용 불가능합니다. 마지막 마일이 어렵습니다.
결론
견고한 테스트 스위트와 사양이 있다면 완전 네이티브 Claude 데스크톱 앱을 만들 수 있을지도 모릅니다. 하지만 마지막 10 %를 다듬는 오버헤드와 늘어나는 유지보수 부담은 여전히 상당합니다. 현재로서는 Electron이 여전히 의미가 있습니다: 크로스‑플랫폼 빠른 배포를 가능하게 하고, 코딩 에이전트가 대부분의 개발을 담당합니다. 개발의 “마지막 마일”과 확대된 지원 범위가 Electron을 당분간은 여전히 관련 있게 만들고 있습니다.