GN⁺: 효율적인 소프트웨어 개발에서 길을 잃어버린 것일까?
(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에서는 테스트를 충분히 하지 않게 되는 문제가 있음.
- "관용적 코드", "성능 최적화는 악의 근원" 같은 블로그 글을 많이 보고 개발 시간을 더 중요하게 여김. 예전엔 더 빨리 더 나은 코드를 작성하는 개발자들이 있었음.