# 소프트웨어 위기

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

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=15723](https://news.hada.io/topic?id=15723)
- GeekNews Markdown: [https://news.hada.io/topic/15723.md](https://news.hada.io/topic/15723.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2024-07-07T09:57:59+09:00
- Updated: 2024-07-07T09:57:59+09:00
- Original source: [wryl.tech](https://wryl.tech/log/2024/the-software-crisis.html)
- Points: 1
- Comments: 1

## Topic Body

##### 소프트웨어 위기

- **소프트웨어 위기란?**
  - 1968년 첫 NATO 소프트웨어 공학 회의에서 "소프트웨어 위기"라는 용어가 처음 사용됨
  - 이 회의들은 프로그래밍 관행을 정의하고 체계화하려는 초기 노력 중 하나였음
  - 1969년 아폴로 11호 발사와 같은 시기에 마지막 NATO 소프트웨어 공학 회의가 열림

- **소프트웨어 위기의 원인**
  - 1972년 튜링상 수상자인 Edsger Dijkstra는 소프트웨어 위기의 원인을 하드웨어의 복잡성과 속도의 증가로 설명함
  - "기계가 더 강력해질수록 프로그래밍 문제도 커짐" - Edsger Dijkstra

- **현재의 소프트웨어 위기**
  - 현재는 소프트웨어 위기에 대해 많이 언급되지 않음
  - 새로운 언어와 조직 방법의 개발로 인해 문제를 해결했다고 생각함
  - 그러나 이는 진정한 편안함이 아닌 패배와 수용의 감각에서 비롯된 것일 수 있음

- **추상화의 문제**
  - 소프트웨어 위기를 해결하기 위한 다양한 노력이 있었지만, 대부분 "추상화"를 통해 문제를 해결하려고 함
  - 추상화는 성능의 대가를 치르면서 어느 정도 독립성을 제공함
  - 개인용 컴퓨터의 상업화 이후, 추상화는 기본적인 사고 방식이 됨

- **개발자와 사용자 간의 격차**
  - 소프트웨어 위기는 소프트웨어를 만드는 사람뿐만 아니라 사용하는 사람에게도 영향을 미침
  - 사용자는 저자가 제공하는 것 외에는 거의 통제할 수 없음
  - Alan Perlis: "좋은 아이디어가 있다면 책임질 준비가 되어 있어야 함"

- **책임의 부재**
  - 소프트웨어 제작자는 자신이 만든 도구의 책임에서 벗어나 있음
  - 상업화가 진행되면서 이러한 경향이 강화됨
  - 추상화는 어려운 생각을 피하기 위한 도구로 사용됨

- **해결책**
  - 소프트웨어 위기의 해결책은 더 제한된 플랫폼으로의 회귀가 아닌, 추상화 계층의 수를 제한하고 정보 보존을 요구하는 것임
  - 프로그래밍 모델, 사용자 인터페이스, 기본 하드웨어는 얕고 구성 가능해야 함
  - 도구의 사용자에게 권한을 부여해야 함

- **현재의 움직임**
  - Handmade, Permacomputing, 레트로 컴퓨팅 등 소프트웨어 위기에 대한 인식을 높이기 위한 움직임이 있음
  - 이러한 반문화 운동은 건강 신호이며, 상황이 나아질 수 있음을 시사함

##### GN⁺의 정리
- 소프트웨어 위기는 하드웨어의 복잡성과 속도의 증가로 인해 발생한 문제임
- 현재는 추상화를 통해 문제를 해결하려고 하지만, 이는 성능의 대가를 치름
- 소프트웨어 제작자는 자신이 만든 도구의 책임에서 벗어나 있으며, 이는 상업화로 인해 강화됨
- 해결책은 추상화 계층의 수를 제한하고 정보 보존을 요구하는 것임
- Handmade, Permacomputing 등의 움직임은 소프트웨어 위기에 대한 인식을 높이고 있음

## Comments



### Comment 27033

- Author: neo
- Created: 2024-07-07T09:57:59+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=40882583) 
- **저자 의견**
  - 추상화 자체가 아닌 무제한적인 적용에 반대함
  - 더 제한된 플랫폼으로의 회귀를 해결책으로 주장하지 않음
  - 사용자가 "더 기술적"이 되어야 한다고 주장하지 않음
  - 소프트웨어 위기를 이해하려면 "플랫폼 숙련도"와 "성장/출시 주기" 곡선을 이해해야 함
  - 이 글은 클릭베이트가 아니며, 개발자로서의 상황을 반영한 것임
  - 문제 해결의 일부를 제공하고자 하며, 후속 글을 계획 중임

- **소프트웨어 위기**
  - 프로젝트 예산 초과, 일정 초과, 비효율적 소프트웨어, 낮은 품질, 요구사항 미충족, 유지보수 어려움, 소프트웨어 미제공 등의 문제를 포함함
  - 성공적인 소프트웨어는 무시되고 실패와 결함만 주목받음
  - 컴퓨터가 데스크탑에 도달하기까지 수백 개의 추상화를 거치며, 이는 전 세계적으로 매일 수십억 번 발생함

- **소프트웨어 개발과 리더십**
  - 자동차 회사 리더십은 기술적 지식을 강조하지만, 애자일 소프트웨어 개발에서는 기술적 역량이 낮은 계층에서 끝남
  - 소프트웨어 개발자는 철학적 고려 없이 티켓 단위로 작업하며, 리더십 역할로 승진되지 않음
  - 소프트웨어 위기에 대한 인식은 취미 활동으로 제한될 가능성이 큼

- **추상화의 필요성**
  - 추상화는 필수적인 도구이며, 나쁜 추상화나 너무 많은 추상화가 문제임
  - 소프트웨어 개발은 더 쉬워졌고, 문서화도 잘 되어 있음

- **도구와 정보**
  - 올바른 도구를 알면 소프트웨어 개발은 매우 쉬움
  - 대부분의 사람들이 알고 있는 도구는 좋지 않으며, 자본의 영향이 큼
  - 예를 들어, 서버리스 환경에서 복잡한 마켓플레이스 앱을 3시간 만에 구축하는 비디오를 만들었지만, 조회수가 적었음

- **GUI와 조합 가능성**
  - UNIX 도구를 사용할 때 얕고 조합 가능한 경험을 함
  - GUI는 서로 소통하지 않으며, 조합 가능하지 않음
  - GUI와 셸 파이프라인을 결합한 도구를 실험 중임

- **소프트웨어의 중요성**
  - 대부분의 소프트웨어는 치명적이지 않으며, 품질이 낮아도 큰 문제가 되지 않음
  - 대부분의 소프트웨어 개발자는 실리콘밸리와 같은 동기부여 없이 작업함

- **모듈성과 추상화**
  - 인터넷과 같은 복잡한 시스템은 계층화된 추상화로 유지됨
  - 소프트웨어 도구는 70년대 이후로 크게 개선됨
  - 예를 들어, VSCode의 copilot을 사용하면 전체 API를 자동 완성할 수 있음

- **프로젝트 관리 위기**
  - 소프트웨어 위기보다는 프로젝트 관리 위기가 존재함
  - 계획 담당자와 전달 담당자 간의 격차가 있음
  - 소프트웨어 개발의 상업화로 인해 다양한 수준의 사람들이 참여할 수 있음
  - 이는 음식 산업과 유사하며, 레스토랑 위기라고 말하지 않음