▲

GN⁺: 소프트웨어 위기

 (wryl.tech)
1P by neo 2달전 | favorite | 댓글 1개

소프트웨어 위기

  • 소프트웨어 위기란?

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

  • 소프트웨어 위기의 원인

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

  • 현재의 소프트웨어 위기

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

  • 추상화의 문제

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

  • 개발자와 사용자 간의 격차

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

  • 책임의 부재

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

  • 해결책

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

  • 현재의 움직임

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

GN⁺의 정리

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

  • 저자 의견

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

  • 소프트웨어 위기

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

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

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

  • 추상화의 필요성

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

  • 도구와 정보

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

  • GUI와 조합 가능성

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

  • 소프트웨어의 중요성

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

  • 모듈성과 추상화

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

  • 프로젝트 관리 위기

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