효율적인 소프트웨어 개발에서 길을 잃어버린 것일까?
(rufatmammadli.medium.com)Microsoft Word 파일을 Google Docs에서 여는 것의 어려움
- 필자의 아버지가 Microsoft Word 문서 파일을 작업하기 위해 노트북에 Word를 설치해야 했음
- 필자는 아버지에게 Google Docs를 제안함
- 아버지가 이미 Google 계정을 가지고 있고, 사용하기 쉬우며, 클라우드 기반이고 자동 동기화되기 때문
- 그러나 약 30MB 크기의 문서 파일을 Google Docs에서 열었을 때 타이핑한 내용이 화면에 표시되는데 수 초가 걸리는 등 Chrome이나 Google Docs가 감당하기 어려웠음
- 결국 LibreOffice를 설치했고, 그 곳에서는 매우 빠르게 작동함
오늘날 소프트웨어 표준에 대한 고찰
- 성능 면에서 소프트웨어 개발이 퇴보하고 있는 것은 아닌지 의문이 듦
- 최신의 멋진 모던한 도구, 프레임워크, 언어들이 효율성 면에서 우리를 퇴보시키고 있는 것은 아닌지
- 웹앱과 브라우저를 다루기 위해 하드웨어 사양이 증가하고 있음
- 순수 네이티브 앱만 있었다면 불필요했을 것
- 모바일 폰이 8GB나 16GB의 RAM을 필요로 하는 이유가 무엇인지
- 웹은 UI 렌더링 엔진 래퍼 대신 네이티브 렌더링이 필요함
- 사양이 좋은 노트북에서도 30MB 크기의 Word 파일을 Google Docs에서 열 수 없는 이유는 브라우저가 더 많은 메모리와 CPU 사용량을 필요로 하기 때문
- 우리는 최적화되고 효율적이며 성능이 좋은 애플리케이션을 개발하는 방법을 잃어버린 것 같음. 이 문제를 해결해야 함
- 1966년의 2KB RAM Apollo 컴퓨터는 인류를 달에 보냈지만, 2024년에는 브라우저에서 30MB 문서 파일을 다룰 수 없음
- 오늘날 업계의 모든 사람들이 미래를 위해 PWA 애플리케이션에 집중하고 있기에 웹에 초점을 맞추고 있음
API 최적화의 중요성
- API 성능이 앱의 성능에 기여할 수 있기에 웹과 네이티브 앱 모두에서 API 최적화가 중요함
- 필자의 제품인 Onradar(https://onradar.io)는 API 모니터링을 통해 최적화에 도움을 줌
- Onradar는 API에 대한 가동 시간 모니터링과 플로우 기반 모니터링을 제공
- 플로우 에디터에서 관련 API로 가능한 사용자 시나리오를 만들고 Onradar가 24/7 테스트하도록 할 수 있음
- 인시던트 발생 시 알림을 제공함
GN⁺의 의견
- 구글 독스와 MS 오피스 간 호환성 문제는 오랫동안 지적되어 온 이슈임. 아직도 완벽하게 해결되지 않고 있어 사용자들에게 불편을 주고 있음. 두 회사가 좀 더 적극적으로 협력하여 이 문제를 해결했으면 함
- 웹앱의 성능 문제가 하드웨어 스펙의 증가로 해결되는 것은 근본적인 해결책이 아님. 한정된 자원을 효율적으로 사용하는 소프트웨어 개발이 필요함
- 네이티브 앱을 주장하는 것도 한 방법이지만, 웹의 장점을 살리면서 웹앱의 성능을 개선하는 것이 더 나은 방향일 것임. 웹앱의 휴대성과 접근성은 포기하기 어려운 장점임
- API 최적화와 모니터링은 전체 시스템 성능 향상에 기여할 수 있는 중요한 요소임. 특히 마이크로서비스 아키텍처가 대세가 되고 있는 요즈음 API 레이어에 대한 관심은 더욱 커질 수 밖에 없을 것임
- Apollo 시절과 비교하는 것은 적절치 않아 보임. 우주선 제어와 워드 프로세싱을 같은 선상에 놓기는 어려움. 요즘 소프트웨어는 워낙 방대하고 복잡해졌기에 Apollo 시절의 효율성을 기대하기는 힘들 것임
댓글과 토론
Hacker News 의견
요약:
- Apple과 Microsoft는 개발자 계정 필요, 바이너리 서명용 인증서 구매, 수익 공유 등으로 native app 개발을 방해하고 있음. 웹은 훨씬 간단하고 저렴한 대안임.
- Moore의 법칙 덕분에 소프트웨어는 수십 년 동안 하드웨어 발전에 무임승차해왔음. 이는 축복이자 저주였음.
- 개발자들은 완전히 통합되고 연결된 보편적 컴퓨팅 플랫폼(웹)을 좋아함. 사용자들은 성능이 충분히 좋으면 크게 신경 쓰지 않음. 좋은 소프트웨어를 만드는 것은 중요하지 않음.
- 비즈니스 결정들이 주요 원인임:
- 클라우드로 이동 - 기업은 정기 결제를 선호하고, 고객은 직접 IT 팀을 고용하지 않아도 됨
- 고객들이 온프레미스 SW 업그레이드를 거부하여 유지보수 주기가 길어지고 패치가 끝없이 이어짐
- 웹 개발은 여러 플랫폼 대응 개발에 비해 비용이 적게 듦
- 90년대 초 MS Word는 플로피 디스크로 배포되었고 실행 파일은 2MB였음. 지금은 GB 단위로 측정되지만 무엇이 개선되었는지 모호함.
- 경량 SW는 있지만 잘 선택되지 않음. Lua, SQLite, Fennel, Althttpd, Fossil, Mako Server 등 훌륭한 경량 SW가 있음.
- 프론트엔드의 경우 네이티브 앱과 웹 페이지를 선호하지만, Tiddlywiki 같은 웹앱도 나름의 장점이 있음. 하지만 여전히 Emacs보다는 리소스를 더 사용함.
- React 페이지 전환 시 드롭다운 렌더링이 오래 걸리는 사례가 있었음. 결국 리액트 코드를 수정하여 해결함.
- 회사에서 개발자에게 고성능 장비를 지원하다 보니, 오래된 일반 PC에서는 테스트를 충분히 하지 않게 되는 문제가 있음.
- "관용적 코드", "성능 최적화는 악의 근원" 같은 블로그 글을 많이 보고 개발 시간을 더 중요하게 여김. 예전엔 더 빨리 더 나은 코드를 작성하는 개발자들이 있었음.