▲

Claude는 왜 Electron 앱일까?

 (dbreunig.com)
1P by GN⁺ 11시간전 | ★ favorite | 댓글 1개
  • 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이 여전히 합리적인 선택으로 평가됨
  • 코딩 에이전트는 놀라운 진전을 보이고 있으나, 완전한 대체 수단으로는 아직 미흡함
▲
GN⁺ 11시간전  [-]
Hacker News 의견들

  • Claude Code 팀의 Boris임
    예전에 Electron을 개발하던 엔지니어들이 있어서 네이티브가 아닌 방식으로 만드는 걸 선호했음
    이렇게 하면 웹과 데스크톱 간의 코드 공유가 가능해 동일한 UI/UX를 유지할 수 있음
    물론 모든 건 트레이드오프의 문제이므로, 미래에는 바뀔 수도 있음

    • 사용자 입장에서라면 기능이 조금 줄더라도 CPU를 덜 잡아먹고 끊김 없는 UI를 원함
      스택을 바꾸지 않아도 성능 최적화로 해결할 수 있을 것 같음. 모바일 앱도 마찬가지임
    • 코딩이 이미 해결된 문제라면서 왜 여전히 가장 단순한 기술 스택을 쓰는지 궁금함
    • Anthropic 같은 회사들이 AI 코딩 도구로 언어 간 포팅이 쉽다고 말하지만, 실제로는 다르게 행동함
      말보다 행동을 보는 게 중요함이라는 교훈을 줌
    • “이게 너야?”라며 YouTube 링크를 공유함
      그렇다면 그냥 “이거 안 구리게 만들어줘”라고 Claude에게 시키면 되지 않겠냐고 농담함
    • Electron 기반 여부보다 더 흥미로운 건, 만약 세 플랫폼용 네이티브 앱을 만들어야 한다면
      AI 에이전트들이 스펙과 테스트만으로 유지보수까지 가능할지에 대한 질문임
      특히 Opus 4.6 같은 모델의 한계를 고려했을 때 어떤 결과가 나올지 궁금함

  • 코드가 공짜가 아닌 이유는 명확함
    우리 팀도 6개월간 Claude를 많이 써봤지만, 버그율은 여전함
    AI는 만능 해결책이 아님

    • 1년쯤 지나면 팀 누구도 그 버그의 원인을 이해하지 못할 것 같음
      AI에 사고를 외주화하면 시스템에 대한 정신적 지도를 잃게 됨
    • 겨우 3개월 전에 지속적인 코딩이 가능한 모델이 나왔고, 15일 전에도 큰 개선이 있었음
      그런데 벌써 “왜 모든 걸 AI로 새로 안 쓰냐”는 말이 나오는 게 웃김
    • Shen의 “I’m stupid faster”라는 밈이 떠오름
      Imgur 링크 참고
      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 인터뷰 참고
    • 실제로 “코드는 거의 공짜”라고 주장하는 사람들도 많음
      이 글은 그런 사람들을 겨냥한 것 같음

  • Felix임. Claude Code Desktop과 Claude Cowork의 Electron 앱을 담당함
    우리 앱에는 Rust, Swift, Go 코드도 꽤 포함되어 있음
    Electron을 쓰는 이유와 자체 엔진을 배포하는 이유를
    공식 문서에 자세히 적어둠
    Electron은 단지 도구일 뿐, 필요하면 다른 걸 쓸 수도 있음

    • Electron 얘기는 제쳐두고, 앱의 UI/UX와 성능 문제가 많음
      CEO가 “코딩은 거의 해결된 문제”라 했는데 왜 이런 결과인지 묻고 싶음
    • 완전히 AI 주도 코드였다면 이런 트레이드오프 자체가 없었을 거라는 의견도 있음

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

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

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

답변달기