Hacker News 의견

• 저자 의견

  • 추상화 자체가 아닌 무제한적인 적용에 반대함
  • 더 제한된 플랫폼으로의 회귀를 해결책으로 주장하지 않음
  • 사용자가 "더 기술적"이 되어야 한다고 주장하지 않음
  • 소프트웨어 위기를 이해하려면 "플랫폼 숙련도"와 "성장/출시 주기" 곡선을 이해해야 함
  • 이 글은 클릭베이트가 아니며, 개발자로서의 상황을 반영한 것임
  • 문제 해결의 일부를 제공하고자 하며, 후속 글을 계획 중임

• 소프트웨어 위기

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

• 소프트웨어 개발과 리더십

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

• 추상화의 필요성

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

• 도구와 정보

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

• GUI와 조합 가능성

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

• 소프트웨어의 중요성

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

• 모듈성과 추상화

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

• 프로젝트 관리 위기

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