개요

No Silver Bullet - Essence and Accident in Software Engineering
은총알은 없다 - 소프트웨어 공학에 있어 본질과 부수성

  • [[Brooks-s-law]]{프레드 브룩스}가 1986년에 쓴 논문이다.
  • 1986년, IFIP(International Federation for Information Processing) 학회의 초청 논문으로 회보에 실렸다.
  • 1987년 4월, IEEE Computer Society의 월간지인 "Computer" Volume 20, issue 4에 다시 실렸다.
  • [[Mythical-Man-Month]] 20주년 판에도 수록되었다(16장).

프레드 브룩스의 주장을 요약하자면 다음과 같다.

  • (1986년 기준으로) 앞으로 10년간 소프트웨어 분야에서 프로그래밍 생산성을 10배 이상 향상시킬 발전은 나타나지 않을 것이다.
  • 소프트웨어 개발은 본질적으로 빠른 발전이 불가능한 분야이다.

감상

논문을 찬찬히 읽어보면 1980년대에 쓴 글인데도 2018년 현재에도 큰 공감을 느낄 수 있었다.

특히 인공지능이나 자동 프로그래밍 등은 부수적인 문제를 해결할 뿐이며 본질적인 문제는 해결하지 못한다는 말이 인상 깊었음.

내용 정리

은총알이란 무엇인가

  • 늑대인간 : 평범한 인간의 모습을 하고 있다가 공포스러운 괴물로 변신한다.
  • 은총알 : 늑대인간을 잡을 수 있는 유일한 무기.

소프트웨어 프로젝트에서의 은총알

  • 평소에는 별 문제 없어 보이지만, 일정이 어긋나고 예산이 초과되면서 결함이 있는 프로젝트가 되기도 한다.
  • 은총알은 소프트웨어 제작비용을 급격히 떨어뜨려줄 수 있는 마법의 아이템을 말한다.
    • 즉 일종의 만병통치약을 말한다.

프레드 브룩스의 주장 : 소프트웨어 프로젝트에서 은총알이란 존재할 수 없다.

소프트웨어는 왜 하드웨어처럼 빠르게 발전하지 못하는가?

무어의 법칙: 하드웨어는 2년 마다 두 배씩 발전하고 있다.

  • 소프트웨어 분야가 늦게 진보하는 것이 아니다.
  • 하드웨어가 이례적으로 빠르게 진보하고 있는 것이다.

그리고 소프트웨어 개발은 하드웨어 개발과 본질적인 차이가 있다.

소프트웨어 개체의 본질은 데이터 세트, 데이터 항목 간 관계, 알고리즘, 함수 호출처럼 서로 맞물리는 개념으로 이루어진 구조물이다. 표현 방법은 여러 가지로 달리 하더라도 개념적 구조물은 동일하다는 점에서 이 본질은 추상적이다. 추상적이라 해도 그 구조물은 고도로 정밀하며 풍부한 세부 내용을 담고 있다.

  • 소프트웨어를 만드는 데 있어 정말 어려운 부분은 개념적 구조물의 명세, 설계, 테스트이다.
  • 신택스 오류 같은 건 개념적 오류에 비하면 아무것도 아닌 문제나 다름없다.

이 전제가 참이라면, 은총알은 존재할 수 없다.

소프트웨어 개발은 원래 엄청 어려운 일인 것이다.

복잡성, 호환성, 변경 가능성, 비가시성

소프트웨어 개체들은 그 크기에 비해 인간이 만든 어떤 구조물보다 복잡하다.

  • 인간이 만든 다른 구조물들은 비슷한 점들이 반복되는 특성이 있다.
  • 소프트웨어는 비슷한 점들이 있으면 분리해서 서브루틴/함수/클래스로 묶기 때문에 반복되는 점들이 매우 적다.
  • 소프트웨어는 본질적으로 복잡성을 다루는 기술이다.
    • 복잡성 때문에 의사소통, 비용 초과, 일정 지연, 부작용이 따르는 확장 등이 발생한다.

여러 인터페이스에 맞추다 보면 복잡성이 증가한다.

  • 수많은 인터페이스가 사용법이 다르고, 버전마다 다르고, 아무튼 다 다르다.
    • 수많은 사람들이 인터페이스를 각자 다르게 설계하기 때문이다.

소프트웨어 제품은 지속적으로 변화하는 것들에 둘러싸여 있다.

  • 응용 분야
  • 사용자
  • 법률
  • 주위의 다른 장비들
  • 문화적 배경

그리고 소프트웨어는 눈에 보이지 않으며, 구조를 시각화하기도 어렵다.

과거의 성과들

이후엔 과거의 성과들을 나열하며 평가한다.

주로 부수적인 복잡성을 해결하는 데에는 도움이 되었으나, 본질적인 복잡성은 해결하지 못한 사례들이다.

  • 고급 언어
  • 시분할 방식
  • 객체 지향 프로그래밍
  • 인공 지능
  • 자동 프로그래밍
  • …등등

괜찮은 해법들

은탄환은 없지만, 괜찮은 방법들이 있다.

복잡성 자체를 겨냥하는 해법들은 쓸만하지 않을까?

소프트웨어를 만들지 않고, 소프트웨어 제품을 구매한다

  • 가장 급진적인 해결책이다.
  • 그 어떤 제품이라도 새로 만드는 것보다는 사는 쪽이 더 저렴하다.
    • 10만 달러 짜리 제품이라도, 프로그래머 1명을 1년 유지하는 것과 비슷한 정도의 비용이다.
    • 구매하는 즉시 납품이 이루어진다.
    • 판매하는 제품은 문서화가 잘 되어 있다.
    • 유지보수도 더 나은 편이다.

마이크로소프트 오피스나 AWS 등을 떠올려보면 프레드 브룩스의 이 급진적인 솔루션이 꽤나 그럴싸하다는 생각이 든다.

요구 사항 상세화와 고속 프로토타이핑

  • 고객들도 자기가 무엇을 원하는지 모른다.
  • 고객들은 무슨 질문을 해야 하는지도 모른다.
  • 고객들은 명세가 필요한 세부 수준까지 문제를 고민해 본 적도 없다.
  • 고객들이 소프트웨어 제품의 요구 사항을 정확하게 명세하는 일은 불가능하다.
    • 제품의 실제 버전을 몇 개 만들어본 이후에나 어느 정도 가능하다.

따라서

  • 고객과 설계자는 꾸준히 소통해야 한다.
  • 반복적으로 신속하게 프로토타입을 만들 수 있는 방법 및 도구를 개발해야 한다.

점진적 개발

한 번에 다 만들려 하지 말고, 점진적으로 개발하며 성장시키는 방법.

  • 제대로 하는 일이 없더라도(내용 없는 함수 호출 등) 일단은 실행되는 형태로 만들어야 한다.
  • 시스템의 모양을 조금씩 갖춰가는 방법.
  • 단순하더라도 실제로 동작하는 시스템이 있으면 개발자들의 사기와 의욕에도 좋은 영향을 준다.

탁월한 설계자 육성

  • 체계적인 방식으로 최고의 설계자를 빨리 찾아낼 것. (경험이 적은 사람도 있다)
  • 설계자 후보는 멘토를 붙여주고, 경력 파일을 꾸준히 관리해준다.
  • 설계자 후보를 어떻게 성장시킬지 계획을 세우고 실천한다.
    • 설계는 물론이고 리더쉽도 함께 키워야 한다.
  • 설계자들이 서로 소통하며 자극을 줄 수 있는 기회를 제공해야 한다.

Computer지에 실린 No Silver Bullet 표지