목차5개 항목
출처와 참고
Nikita Prokopov의 「Software disenchantment」(2018)와 그 번역 「소프트웨어 환멸감」을 바탕으로 재구성한 노트다.
소프트웨어 비대화란
소프트웨어 비대화(software bloat)는 기능은 크게 늘지 않는데 크기·메모리·지연이 계속 커지는 현상이다. 하드웨어가 수십 배 빨라져도 앱 시작, 입력 반응, 페이지 로딩은 빨라지지 않는다. 늘어난 성능을 소프트웨어가 비효율로 다 써 버리기 때문이다(Wirth의 법칙: 소프트웨어는 하드웨어가 빨라지는 것보다 더 빨리 느려진다).
자동차·건축·항공기는 물리적 한계에 가깝게 최적화하는 것이 당연한데, 소프트웨어는 가능한 성능의 극히 일부로 돌아도 용인된다.
원인
| 원인 | 모습 |
|---|---|
| 「개발자 시간이 더 비싸다」 | 최적화를 미루는 근거가 되지만, 아낀 비용은 수많은 사용자의 시간·배터리·기기로 전가된다 |
| 가벼운 의존성 남용 | 작은 문제에 큰 패키지·프레임워크를 들여 전이 의존성과 충돌이 쌓인다 |
| 층 위의 층 | 이해하지 못한 계층을 감추려 또 계층을 얹는다 |
| 증상 치료 | 재시작, 워치독, 「일단 다시 시도」 같은 임시방편이 근본 원인을 가린다 |
| 예측 불가능한 구성 요소 | 결과를 설명·재현할 수 없는 도구는 신뢰성을 깎는다 |
| 낮아진 기대 | 사용자는 주어진 품질에 적응하므로, 기준을 지키는 일은 만드는 쪽의 몫이 된다 |
원칙
- 효율은 기본 가치다. 빠르고 작은 것은 나중에 덧붙이는 최적화가 아니라 설계 기준이다.
- 크기 증가는 경고 신호다. 기능 없이 커지는 코드·번들·이미지는 통제력을 잃었다는 뜻이다.
- 의존성을 아낀다. 들일 때마다 「직접 쓰면 몇 줄인가」, 「이 패키지가 끌고 오는 것은 무엇인가」를 묻는다.
- 원인을 이해한다. 엔지니어링은 시스템의 성능·구조·한계를 안팎으로 이해하는 일이다.
- 재현 가능하게 만든다. 빌드와 배포는 100% 재현 가능해야 신뢰할 수 있다.
- 데이터를 지킨다. 데이터 손실이나 충돌 해결을 사용자에게 떠넘기지 않는다.
- 오래 동작하게 만든다. 몇 년 뒤에도 돌아가도록 하위 호환을 고려한다.
- 주기적으로 걷어 낸다. 레거시를 교체하지 않으면 생태계가 굳어 변화의 여지가 사라진다.
한계
- 모든 코드를 극한까지 최적화할 수는 없다. 병목이 아닌 곳의 미세 최적화는 낭비다. 먼저 측정하고, 기본값은 효율적인 쪽으로 고른다.
- 추상화와 의존성은 생산성을 준다. 문제는 쓰는 것이 아니라 비용을 따지지 않고 쓰는 것이다.
정리
- 하드웨어의 발전을 소프트웨어의 비효율이 상쇄하면 진전이 아니다.
- 단순함이 성능과 품질의 원천이다. 불필요한 층을 쌓지 않으면 평범한 팀도 빠른 소프트웨어를 만든다.
- 품질 기준은 사용자가 아니라 만드는 사람이 세운다.
관련 노트: 삭제하기 쉬운 코드, 지속 가능한 웹 디자인, 책임감 있는 JavaScript, 기술 부채