# Claude는 왜 Electron 앱일까?

> Clean Markdown view of GeekNews topic #26890. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=26890](https://news.hada.io/topic?id=26890)
- GeekNews Markdown: [https://news.hada.io/topic/26890.md](https://news.hada.io/topic/26890.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-02-22T13:33:15+09:00
- Updated: 2026-02-22T13:33:15+09:00
- Original source: [dbreunig.com](https://www.dbreunig.com/2026/02/21/why-is-claude-an-electron-app.html)
- Points: 10
- Comments: 1

## Summary

**Electron**은 하나의 코드베이스로 여러 운영체제를 지원하며 빠르게 데스크톱 앱을 배포할 수 있게 합니다. 그러나 각 앱이 자체 **Chromium 엔진**을 포함해야 해 용량과 성능 문제가 뒤따릅니다. 최근 **코딩 에이전트**가 플랫폼별 네이티브 코드를 자동 생성할 수 있을 만큼 발전했지만, 실제 서비스 수준의 앱에서는 여전히 **‘마지막 10%’의 예외 처리와 유지보수**가 사람의 손을 필요로 합니다. 그래서 Anthropic의 **Claude 앱**처럼, 최신 AI 기업조차 Electron을 선택하는 현실적 이유가 남아 있습니다.

## Topic Body

- **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이 여전히 합리적인 선택**으로 평가됨  
- 코딩 에이전트는 놀라운 진전을 보이고 있으나, **완전한 대체 수단으로는 아직 미흡함**

## Comments



### Comment 51574

- Author: neo
- Created: 2026-02-22T13:33:15+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47104973) 
- Claude Code 팀의 Boris임  
  예전에 **Electron**을 개발하던 엔지니어들이 있어서 네이티브가 아닌 방식으로 만드는 걸 선호했음  
  이렇게 하면 웹과 데스크톱 간의 **코드 공유**가 가능해 동일한 UI/UX를 유지할 수 있음  
  물론 모든 건 트레이드오프의 문제이므로, 미래에는 바뀔 수도 있음
  - 사용자 입장에서라면 기능이 조금 줄더라도 CPU를 덜 잡아먹고 **끊김 없는 UI**를 원함  
    스택을 바꾸지 않아도 성능 최적화로 해결할 수 있을 것 같음. 모바일 앱도 마찬가지임
  - 코딩이 이미 해결된 문제라면서 왜 여전히 **가장 단순한 기술 스택**을 쓰는지 궁금함
  - Anthropic 같은 회사들이 AI 코딩 도구로 언어 간 포팅이 쉽다고 말하지만, 실제로는 다르게 행동함  
    말보다 **행동을 보는 게 중요함**이라는 교훈을 줌
  - “이게 너야?”라며 [YouTube 링크](https://www.youtube.com/watch?v=We7BZVKbCVw)를 공유함  
    그렇다면 그냥 “이거 안 구리게 만들어줘”라고 Claude에게 시키면 되지 않겠냐고 농담함
  - Electron 기반 여부보다 더 흥미로운 건, 만약 세 플랫폼용 네이티브 앱을 만들어야 한다면  
    **AI 에이전트들이 스펙과 테스트만으로 유지보수까지 가능할지**에 대한 질문임  
    특히 Opus 4.6 같은 모델의 한계를 고려했을 때 어떤 결과가 나올지 궁금함

- 코드가 공짜가 아닌 이유는 명확함  
  우리 팀도 6개월간 Claude를 많이 써봤지만, **버그율은 여전함**  
  AI는 만능 해결책이 아님
  - 1년쯤 지나면 팀 누구도 그 버그의 원인을 이해하지 못할 것 같음  
    AI에 사고를 **외주화**하면 시스템에 대한 정신적 지도를 잃게 됨
  - 겨우 3개월 전에 지속적인 코딩이 가능한 모델이 나왔고, 15일 전에도 큰 개선이 있었음  
    그런데 벌써 “왜 모든 걸 AI로 새로 안 쓰냐”는 말이 나오는 게 웃김
  - Shen의 “I’m stupid faster”라는 밈이 떠오름  
    [Imgur 링크](https://imgur.com/gallery/i-m-stupid-faster-u8crXcq) 참고  
    AI 코딩 에이전트가 완전히 그 수준은 아니지만, **속도만 빠른 실수**를 경계해야 함
  - 그렇다면 왜 Claude가 **QA 테스트**는 안 해주는지 궁금함

- OpenAI의 브라우저도 출시 4개월이 지났는데 아직 macOS 전용임  
  이미 **크로스플랫폼 엔진** 위에서 돌아가는데도 확장이 느린 건 의문임
  - 아마도 **사용자 채택률 저조**가 원인일 가능성이 높음

- “Free as in puppy”라는 표현이 재치 있었음  
  원래 제목이 “If code is free,”로 시작했다고 함
  - 이 댓글이 너무 웃겨서 블로그까지 찾아봤는데 정말 훌륭했음
  - “나는 강아지라 이해가 안 돼요”라며 농담 섞인 질문이 달림
  - “오래된 독일차가 공짜인 것과 비슷한 건가?”라는 유머도 이어짐

- 이 글과 스레드 전반이 전형적인 **HN식 논쟁 패턴** 같음  
  “AI 나쁨”, “JavaScript 나쁨”, “Electron 나쁨” 같은 반복적인 구도임  
  Electron은 사실상 **‘네 번째 OS 플랫폼’** 인데, 그걸 이해 못 하는 개발자들이 많음
  - Electron 앱을 전부 네이티브로 바꿔야 한다고 생각함  
    지금 앱들은 **패치된 웹사이트처럼 보이고**, 스타일 불일치와 버그가 많음  
    네이티브 Mac 앱을 만드는 게 훨씬 기분 좋음
  - 코드가 아니라 **엔지니어가 비용**임  
    Electron의 장점은 있지만, OS별 최적화가 거의 이뤄지지 않음  
    나쁜 네이티브 UI도 많고, 결국 **사람이 코드를 어떻게 짜느냐**의 문제임  
    Claude가 CLI 도구를 제공하는 상황이라면 Electron 선택은 합리적임
  - 글쓴이로서 말하자면, AI가 나쁘다고 한 적 없음  
    Electron의 장점을 인정했고, 선택 이유도 설명했음  
    다만 **Mac Studio 64GB RAM에서도 느리다**는 건 흥미로운 사실임
  - 300억 달러 규모의 회사가 이런 UX를 내놓는 건 납득하기 어려움  
    npm 의존성까지 기본 포함시키는 건 **기술적 자존심 부족**처럼 보임  
    “최고의 인재를 고용한다”는 슬로건과는 어울리지 않음
  - 내 24GB Mac도 Electron 앱들 때문에 항상 스왑을 씀  
    JavaScript를 좋아하지만 **RAM 사용량은 미쳤음**

- Anthropic은 “코드는 공짜”라고 한 적이 없음  
  그들은 **생산성 향상**을 강조했고, 실제로 대부분의 코드를 LLM으로 작성함  
  비판하려면 허수아비 논리가 아니라 **실제 문제점**을 지적해야 함
  - 그래도 “그렇게 생산성이 높고 비싼 엔지니어들이 있다면  
    왜 더 나은 결과물이 안 나오냐”는 의문은 남음
  - Claude Code 책임자가 며칠 전 “코딩은 거의 해결된 문제”라고 말했음  
    [Lenny’s Newsletter 인터뷰](https://www.lennysnewsletter.com/p/head-of-claude-code-what-happens) 참고
  - 실제로 “코드는 거의 공짜”라고 주장하는 사람들도 많음  
    이 글은 그런 사람들을 겨냥한 것 같음

- Felix임. **Claude Code Desktop**과 **Claude Cowork**의 Electron 앱을 담당함  
  우리 앱에는 Rust, Swift, Go 코드도 꽤 포함되어 있음  
  Electron을 쓰는 이유와 자체 엔진을 배포하는 이유를  
  [공식 문서](https://www.electronjs.org/docs/latest/why-electron)에 자세히 적어둠  
  Electron은 단지 **도구일 뿐**, 필요하면 다른 걸 쓸 수도 있음
  - Electron 얘기는 제쳐두고, 앱의 **UI/UX와 성능 문제**가 많음  
    CEO가 “코딩은 거의 해결된 문제”라 했는데 왜 이런 결과인지 묻고 싶음
  - 완전히 **AI 주도 코드**였다면 이런 트레이드오프 자체가 없었을 거라는 의견도 있음

- Claude 로그인 문제를 겪음  
  브라우저가 무한 로딩 상태에 빠지고, 로그인 클릭 시 회원가입으로 넘어감  
  이런 기본 기능이 불안정한 건 “코딩의 미래”라기엔 아쉬움

- 코드는 절대 공짜가 아님  
  결국 어떤 형태로든 **비용을 지불**하게 됨  
  AI가 코드를 다 쓴다 해도, 그걸 **이해할 사람**이 필요함  
  매뉴얼을 읽는 능력이 해커의 강점이며,  
  자신이 만든 제품의 작동 원리를 모르는 회사는 위험함

- Claude가 Electron을 쓰는 건 기술이 아니라 **문화적 문제**라고 생각함  
  스타트업이라면 Electron이 합리적이지만,  
  큰 회사라면 **네이티브 앱 품질과 UX**에 투자하는 게 맞음  
  자동화된 코딩이 가능해도 여전히 그렇게 하지 않는 건  
  오늘날 개발 문화가 “최고의 소프트웨어를 만들려는 의지”를 잃었기 때문임
