-
Electron은 HTML·CSS·JS 기반으로 Windows, Mac, Linux를 동시에 지원하는 데스크톱 앱을 만들 수 있는 프레임워크로, Slack·Discord·VS Code 등 다수의 앱이 이를 사용함
- 그러나 각 앱이 Chromium 엔진을 개별 포함하기 때문에 용량이 크고, 지연·비응답 문제가 발생하며, OS 기능과의 통합도 제한적임
-
코딩 에이전트가 명세와 테스트 기반으로 플랫폼별 네이티브 코드 생성을 수행할 수 있게 되면서, Electron의 장점이 줄어드는 듯 보임
- 하지만 실제로는 에이전트가 개발의 90%까지만 자동화할 수 있고, 마지막 10%의 예외 처리와 유지보수는 여전히 어렵고 인력 의존적임
- 따라서 Anthropic의 Claude 앱처럼, 에이전트 기술이 발전했음에도 Electron을 사용하는 현실적 이유는 여전히 존재함
Electron의 장점과 한계
- Electron은 웹 기술로 크로스플랫폼 데스크톱 앱을 구축할 수 있게 함
- 하나의 코드베이스로 Windows, Mac, Linux를 모두 지원
- 기존 웹앱 코드를 재활용할 수 있어 개발 효율성이 높음
- 단점으로는 앱 용량 증가와 성능 저하가 있음
- 각 앱이 자체 Chromium 엔진을 포함해 수백 MB 규모
- 반응 속도 저하, OS 기능 통합 부족 등의 문제가 발생
- 일부 문제는 OS별 최적화로 개선 가능하지만, Electron의 구조적 이점이 이를 적극 유도하지 않음
코딩 에이전트의 등장과 기대
- 최근 코딩 에이전트는 명세(spec)와 테스트를 기반으로 언어·플랫폼 간 구현을 자동화하는 능력을 보임
- 이론적으로는 하나의 명세와 테스트 세트로 각 플랫폼의 네이티브 앱을 생성할 수 있음
- 이를 통해 작고 집중된 팀이 고성능 네이티브 앱을 광범위한 시장에 제공할 수 있는 가능성이 제시됨
Claude와 Anthropic의 사례
- Anthropic은 Rust 기반 C 컴파일러를 코딩 에이전트로 구현했으나, 마지막 단계에서 한계에 부딪힘
- 새로운 기능 추가나 버그 수정 시 기존 기능이 깨지는 문제가 반복
- 결과물은 인상적이지만 실사용에는 부적합한 수준으로 평가됨
- Claude 데스크톱 앱 역시 Electron 기반으로 제작되어, 느리고 버그가 많으며 용량이 큰 앱으로 언급됨
‘마지막 10%’의 어려움
- 코딩 에이전트는 개발의 초기 90%를 빠르게 처리하지만,
현실 환경에서의 예외 처리·유지보수는 여전히 복잡하고 인력 개입이 필요함
- 실제 사용자 환경에서는 예상치 못한 시나리오가 누적되어 개발이 끝나지 않음
- 플랫폼별로 별도 앱을 만들 경우 버그·지원 범위가 3배로 확대되어 유지보수 부담이 커짐
- Electron은 공통 래퍼(wrapper)를 통해 이 문제를 일정 부분 완화
Electron을 계속 사용하는 이유
- 명세 기반 개발이 가능하더라도, 마지막 10%의 개발 비용과 유지보수 부담이 여전히 존재
-
에이전트 기술의 발전에도 불구하고, Electron의 단일 코드베이스 장점이 현실적으로 유효
- 현재 시점에서는 Electron이 여전히 합리적인 선택으로 평가됨
- 코딩 에이전트는 놀라운 진전을 보이고 있으나, 완전한 대체 수단으로는 아직 미흡함