No Silver Bullet (은총알은 없다)

1986년, Fred Brooks가 쓴 <No Silver Bullet – Essence and Accident in Software Engineering>이라는 논문을 읽고 정리한 내용입니다.

 

worrydream.com/refs/Brooks-NoSilverBullet.pdf

 

늑대인간: 익숙한 사람의 모습에서 공포스러운 괴물로 변하는 특성.

은총알: 유일하게 늑대인간을 죽일 수 있는 무기.

소프트웨어 프로젝트도 이런 특성 가짐.(간단하고 문제 없어보이지만 일정에 문제가 생기고 예산이 부족하면 제품에 결함있는 괴물이 되기도함) → 우리는 하드웨어만큼 비용을 빠르게 낮춰줄 은총알을 원한다.

그러나 지난 10년을 보면 은총알은 존재하지 않는다.

Does It Have to Be Hard? - Essential Difficulties

1. 소프트웨어의 발전이 느린것이 아니라 하드웨어의 발전이 너무 빠른 것.
2. 하드웨어는 2년마다 2배씩 발전. 그러나 다른 기술중 어떤 것도 하드웨어만큼 빠르게 발전한게 없음.
3. 소프트웨어 발전의 본질적 어려움.소프트웨어 구축에서의 어려움이 바로 이 개념적 구성의 명세, 설계, 테스트.
4. 소프트웨어 엔티티의 본질은 데이터 세트, 데이터 항목 간 관계, 알고리즘 및 함수 호출과 같은 서로 연동되는 개념으로 구성된 것. 표현 방법은 여러 가지로 달리 하더라도 개념적 구성은 동일하다는 점에서 이 본질은 추상적임. 그럼에도 이것은 매우 정밀고 상세함.

복잡성(complexity)

소프트웨어 엔티티는 크기에 비해 매우 복잡한 구조. 반복되는 구조가 많은 컴퓨터나 건물과는 완전히 다름.

소프트웨어 엔티티의 확장은 단순히 동일한 요소를 더 크게 반복하는게 아니라 서로 다른 요소가 증가하는것. (비선형 증가)

수학과 물리학은 복잡한 현상의 단순화 된 모델을 구성하여 그 모델에서 속성을 도출하고 실험을 통해 이러한 속성을 검증함으로써 큰 발전을 이룸. 그러나 이 패러다임은 복잡성이 본질 일 때는 작동하지 않음.

호환성(Conformity)

소프트웨어는 여러 다른 사람들에 의해 설계 되었기 때문에 임의의 복잡성이 있음.

많은 복잡성은 다른 인터페이스에 대한 호환성에서 비롯되는데, 이러한 복잡성은 재설계만으론 단순화 될 수 없음.

변경가능성(Changeability)

소프트웨어 엔티티는 자동차나 건물에 비해서 훨씬 빈번하게 변화의 압력을 받음. 어플리케이션, 사용자, 법률,기계, 문화적 매트릭스에 둘러 쌓여있는데 이것들은 지속적으로 변경됨.

비가시성(invisibility)

소프트웨어는 보이지 않으며 시각화할 수 없음. 본질적으로 공간에 내재되어 있지 않기 때문에 구조를 도표화하기 어려움. 이는 설계과정과 의사소통을 심각하게 방해함.

 

Past Breakthroughs Solved Accidental Difficulties

고급언어

소프트웨어 생산성, 신뢰성 및 단순성에 커다란 기여(5배 이상의 이득). 프로그래머가 추상적 인 프로그램에서 상상하는 모든 구조를 제공하여 원하는 구성을 구현하고 프로그램에 내재되지 않은 전체수준의 복잡성 제거.

그러나 발전 속도는 점점 줄어든다. 고급언어의 정교함은 오히려 언어 숙달에 대한 사용자의 지적작업을 증가 시킴.

Time-sharing (시분할)

시간의 공유는 (고급언어만큼은 아니지만) 생산성과 품질을 크게 향상시킴. 주요 효과는 시스템 응답 시간을 단축시키는 것.

그러나 인간의 눈에 띄는 임계값인 약 100밀리초를 넘어서는 어떠한 이점도 없음

Unified programming environments

통합라이브러리, 통합파일형식,파이프 및 필터 등을 제공해 개별프로그램을 함께 사용.

각각의 새로운 도구가 표준 형식을 사용하는 모든 프로그램에 적용될 수 있기 때문에 발전을 이끌었음.

 

Hopes for the Silver

Ada 및 기타 고급언어의 향상

Ada는 언어 개념의 진화적인 개선을 반영 할뿐만 아니라 실제로 현대적인 설계와 모듈화를 장려하는 기능을 구현함. 그럼에도 은총알은 아님. 왜? 그것은 또 다른 하이레벨 언어 일 뿐이며, 그러한 언어의 가장 큰 성과는 기계의 우연한 복잡성에서 단계적 해결책에 대한 보다 추상적인 진술로의 전환임. 그러나 문제가 제거되면 나머지 문제는 더 줄어들고 그 문제 제거로 얻는 보상은 더욱 줄어들게됨.

객체지향 프로그래밍

추상 데이터 유형과 계층적 유형 이 두가지는 소프트웨어 구축 기술의 진정한 발전을 나타냄. 두가지 모두 고차원의 우발적 어려움을 없애고 고차 설계 표현을 가능하게함.

그러나 설계 표현에서 우발적인 어려움을 없애는 것 이상은 할 수 없음. 설계자체의 복잡성은 필수적.

인공지능

두가지 정의

AI-1 : 이전에는 인간 지능을 적용해야만 해결할 수 있었던 문제를 해결하기 위해 컴퓨터를 사용.

Al-2 : 휴리스틱 또는 규칙 기반 프로그래밍으로 알려진 특정 프로그래밍 기술 세트 사용.

이 분야에도 고유한 기술이 있는 것이 아님. 대부분의 작업은 문제에 따라 다르며,이를 전달하는 방법을 보려면 약간의 추상화나 창의성이 필요.

전문가 시스템

인공 지능에서 가장 발전된 부분이자 가장 널리 적용되는 부분은 전문가 시스템을 구축하는 기술.

전문가 시스템은 일반화 된 추론 엔진과 룰베이스를 포함하고, 입력 데이터와 가정을 취하고, 룰베이스에서 파생 된 추론을 탐색하여, 결론과 조언을 도출하고, 사용자에 대한 추론을 다시 추적하여 결과를 설명하는 프로그램. 결정론적 논리 외에도 확률적 데이터 및 규칙을 처리할 수 있음.

그러나 전문가 시스템 실현엔 많은 어려움이 있음. 자신이 일을하는 이유를 아는 명료하고 자기 분석적인 전문가를 찾고 그들이 아는 것을 추출하여 규칙 기반으로 추출하는 효율적인 기술을 개발하는 것...(좋은 전문가를 보유해야 가능한 일임)

자동 프로그래밍

이 기술은 깔끔한 속성을 가진 경우가 거의 없는 일반 소프트웨어 시스템의 더 넓은 세계로 일반화되기는 매우 어려움.

그래픽 프로그래밍

플로우차트는 설계도구로써 별 쓸모가 없음.(소프트웨어의 시각화는 매우매우 어려움). 오늘날 화면은 픽셀단위로 너무 작아 상세한 소프트웨어 다이어그램의 범위와 해상도를 표시 할 수 없음.(극히 일부의 작은 부분만 볼 수 있다)

프로그램 검증

현재 프로그래밍의 많은 노력들이 테스트와 버그 수정에 쓰임. 설계단계에서 소스의 오류를 찾아 제거할 수 있는 은총알은 없다.

검증은 매우매우 많은 작업, 노동력 필요 → 테스트 부하를 줄일 수는 있지만 제거할 수는 없음.

소프트웨어 작업에서 가장 어려운것이 안정적이고 일관된 사양에 도달하는 것

환경 및 도구

일관된 인터페이스를 만드는 일관된 파일 형식, 일반화된 도구 → 단순한 의미의 오류로 부터 해방!

환경에 있어선 통합 데이터베이스 시스템.

생산성, 신뢰성 모두에서 가치있음. 그러나 본직적으로 지금부터의 이익은 미미할것.

워크스테이션

개별 워크 스테이션의 성능과 메모리 증가 → 컴파일 속도는 향상될 수 있으나 기계속도의 10배는 프로그래머의 하루중 생각하는 시간을 가장 큰 활동으로 만듦.

 

Promising Attacks on the Conceptual Essence

작업의 개념적 구성 요소가 대부분의 시간을 소요 → 단순히 개념의 표현인 작업 구성 요소에 대한 어떠한 활동도 생산성을 크게 향상시키지 못함. 따라서 소프트웨어 문제의 본질인 복잡한 개념 구조의 공식화를 다루는 쪽을 생각해 봐야함.

괜찮은 방법들이 있긴 하다.

Buy versus build

새로 만드는 것보다 구입하는것이 더 저렴함. (10만달러짜리 소프트웨어 == 프로그래머의 1년, 심지어 사면 바로 쓸 수 있음. 훨씬 잘 문서화되어있고 유지관리 잘돼있음.)

Requirements refinement and rapid prototyping

소프트웨어 구축에서 가장 어려운 부분은 무엇을 구축할지 정확히 결정하는것.

소프트웨어 빌더가 클라이언트를 위해 수행하는 가장 중요한 일은 제품의 요구 사항을 반복적으로 추출하고 개선하는 것. 반복적인 소통이 필요.(클라이언트는 본인이 무엇을 원하는지 정확히 알지 못하기 때문)

클라이언트가 소프트웨어 엔지니어와 함께 작업하더라도 일부 버전의 제품을 시도하기 전에 최신 소프트웨어 제품의 정확한 요구 사항을 완전하고 정확하며 정확하게 지정하는 것은 거의 불가능함.

시스템의 신속한 프로토타이핑을위한 접근 방식과 도구를 개발하는 것이 중요!!

Incremental development

구축하는 개념적 구조가 미리 정확하게 지정하기엔 너무 복잡하해 결함없이 구축하기에 어려움이 있다면 근본적으로 다른 접근 방식을 취해야함.

적절한 더미 하위 프로그램 집합을 호출하는 것 외에는 쓸모가 없더라도 시스템이 먼저 실행되어야 한다. 그런 뒤 하위 프로그램들이 차례로 개발되어 아래 수준의 빈 스텁에 대한 행동이나 호출로 구체화되어야 한다.

소프트웨어는 하향식으로 성장하기 때문에 하향식 설계의 접근방법이 필요.

단순한 시스템이라도 제대로 실행되면 사기진작 효과를 줌.

Great Designer

좋은 설계는 좋은 설계자에게서 나온다.

훌륭한 설계자를 성장시키는 방법을 개발하는 것이 중요.

<훌륭한 설계자를 성장시키는 방법>

• 가능한 한 빨리 최고의 설계자를 체계적으로 식별.
• 잠재 고객 개발을 담당 할 경력 멘토를 지정하고 경력 파일을 신중하게 보관.
• 최고 디자이너와 함께 엄선 된 견습생, 고급 정규 교육 에피소드 및 단기 과정을 포함하여 각 잠재 고객에 대한 경력 개발 계획을 고안하고 유지.
• 성장하는 설계자들이 서로 상호 작용하고 자극 할 수있는 기회를 제공.