코드가 무료일 때, 클로드는 왜 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 엔진을 포함한다; 최소 크기도 보통 수백 메가바이트다.
• 성능 – 느리게 느껴지거나 반응이 없을 수 있다.
• OS 통합 – 네이티브 OS 기능과의 통합이 그리 깊지 않다.

이 문제들은 영리한 개발과 플랫폼‑특화 코드를 통해 완화될 수 있지만, 드물게 그렇게 된다. 단일 코드베이스와 빠른 크로스‑플랫폼 배포의 장점이 단점을 능가하는 경우가 많다.

코딩 에이전트의 약속

코딩 에이전트는 잘 정의된 사양과 테스트 스위트가 주어졌을 때, 크로스‑플랫폼·크로스‑언어 구현에 뛰어나다 (사양‑주도 개발 기사). 이론적으로 이는 Electron의 장점을 대체할 수 있다: 하나의 사양과 테스트 스위트를 작성하고, 에이전트를 이용해 각 플랫폼에 맞는 네이티브 코드를 생성함으로써, 소규모·집중된 팀이 빠르고 성능 좋은 앱을 제공할 수 있다.

왜 여전히 Electron을 쓰는가

AI 코딩 도구 분야의 선두주자인 Anthropic조차도 Claude를 Electron 데스크톱 앱으로 배포한다—느리고, 버그가 많으며, 부피가 크다. 그 이유는 다음과 같다:

• “마지막 10 %” 문제 – 에이전트는 개발 초기 90 %를 훌륭히 처리하지만, 엣지 케이스, 실제 시나리오, 지속적인 유지보수는 여전히 어렵고 지루하며, 상당한 인간 감독이 필요하다.

• Anthropic의 Rust 기반 C 컴파일러 – 막대한 노력 끝에 컴파일러는 Opus의 한계에 부딪혔다. 팀은 다음과 같이 언급했다:

  The resulting compiler has nearly reached the limits of Opus’s abilities. I tried (hard!) to fix several of the above limitations but wasn’t fully successful. New features and bugfixes frequently broke existing functionality.

  (번역) 결과적인 컴파일러는 Opus의 능력 한계에 거의 도달했다. 위에 열거된 몇몇 제한사항을 (열심히!) 고치려 했지만 완전히 성공하지 못했다. 새로운 기능과 버그 수정이 기존 기능을 자주 깨뜨렸다.

  이 컴파일러는 시간과 노력에 비해 인상적이지만, 실제 사용하기엔 거의 쓸 수 없으며 “마지막 마일” 개발이 여전히 큰 장애물이다.

• 지원 범위 – macOS, Windows, Linux용 네이티브 빌드는 버그 수정 및 지원 작업량을 세 배로 늘리지만, Electron의 단일 래퍼는 많은 플랫폼‑특화 문제를 완화한다.

견고한 테스트 스위트와 사양이 있다면 완전 네이티브 Claude 데스크톱 앱을 만들 수 있겠지만, 최종 개발 단계의 오버헤드와 증가된 유지보수 부담이 여전히 상당하다.

결론

현 시점에서는 Electron이 여전히 타당하다. 코딩 에이전트는 놀라운 도구이지만, 마지막 마일 개발과 확대된 지원 범위 때문에 많은 팀에게는 실용적인 선택으로 Electron이 남아 있다.