No Silver Bullet - Essence and Accident in Software Engineering 논문 요약

[SE.A.01] 

“No Silver Bullet —Essence and Accident in  Software Engineering 에 대한 요약 

[Summary of No Silver Bullet —Essence  and Accident in Software Engineering]”

 

 

1. 서론 

“한 번에 완벽한 해결책은 없다.” 

늑대인간은 친숙한 모습에서 무서운 모습으로 예상치 못하게 변하는 특징이 있다. 은총알은 늑대인간을 한 번에 무너뜨릴 수 있는 무기이다. 친숙한 소프트웨어 프로젝트도 간단해보이지만 일정이 어긋나고, 예산이 부족하고, 결함이 생기면 공포스러운 괴물의 모습으로 변하는 특징을 가진다. 그래서 은총알처럼 소프트웨어의 비용을 빠르게 낮춰줄 하드웨어가 필요하다. 하지만 저자는 향후 10 년간 그런 하드웨어는 나타나지 않을 것이라고 말하며 그 이유를 살펴본다. 

 

2. Does It Have To Be Hard? – Essential Difficulties 

- 소프트웨어의 발전이 느린 것이 아니라 하드웨어의 발전이 너무 빠른 것이다. 30 년 동안 성능이 6 배 발전하는 것은 세상 어디에도 없다. 

- 소프트웨어 개발에서 어려운 것은 개념적 구조를 설계하고 테스트하는 것이다. 만약 이것이 참일 경우, 소프트웨어 개발은 더 어려워질 것이다. 

- 소프트웨어 엔티티의 본질은 데이터, 알고리즘, 함수가 서로 유기적을 연결된 구조이다. 이 본질은 각기 다른 표현형태여도 개념적 구조는 동일하다는 점에서 추상적이다. 그럼에도 불구하고 꽤 정확하고 상세하다. 

 

2-1. 소프트웨어의 특징: 소프트웨어 개발이 어려운 이유 

(1) 복잡성 

- 소프트웨어 엔티티는 그 크기에 비해 인간이 만든 구조물보다 훨씬 복잡하다. 

- 두 가지의 비슷한 서브루틴이 있으면 하나로 묶는다. 그렇기 때문에 컴퓨터, 자동화처럼 반복되는 구조가 거의 없다. 

- 소프트웨어의 복잡성은 본질적인 것이다: 복잡성 때문에 팀원 간 의사소통 오류, 상품 결함, 비용 초과, 일정 지연 등의 문제가 발생한다. (e.g., 구조가 복잡하면 새로운 기능을 추가하여 프로그램을 확장하기 어려움) 

 

(2) 적합성(호환성) 

- 다 서로 다른 사람이 만들기 때문에 인터페이스마다, 그때 그때마다 다르다. 

- 복잡성은 서로 다른 인터페이스의 호환성 문제로 발생한다. 하지만 이러한 복잡성은 소프트웨어를 재설계하는 것만으로 단순화될 수 없다. 

 

(3) 가변성 

- 소프트웨어 엔티티는 끊임없이 변화에 대한 압박을 받아왔다.

- 소프트웨어는 애플리케이션, 사용자, 법률, 운송 기계 등 끊임없이 변화하는 것들로 둘러 쌓여 있고, 이러한 것들이 소프트웨어의 변화를 압박한다. 

 

(4) 비가시성 

- 소프트웨어는 보이지 않고 상상할 수 없다. 

- 소프트웨어는 어떤 공간에 따로 내재되어 있는 것이 아니기 때문에 우리는 소프트웨어의 구조를 그릴 수 없다. 이로 인해 설계 과정이 지연되고 의사소통에 오류가 발생한다. 

 

3. Past Breakthroughs Solved Accidental Difficulties 

high-level language, time-sharing, Unified programming environments 는 소프트웨어의 본질적인 문제는 해결하지 못하고 우발적인 문제만을 해결한 요소이다. 

 

(1) high-level language 

- 소프트웨어의 생산성, 신뢰성, 단순성을 위한 가장 강력한 방법은 high-level 의 프로그래밍 언어를 발전시켜 사용하는 것이다. 이는 우발적인 복잡성으로 인한 문제도 해결할 수 있다. 

 

(2) time-sharing 

- 기계 언어의 복잡성처럼 느린 처리 속도는 본질적인 문제가 아닌, 우발적인 문제이다. 여기에서 비롯한 time-sharing 의 주요 효과는 시스템 응답 시간을 단축하는 것이다. 하지만 시간이 0 이 되고 사람이 인지할 수 있는 한계치인 100 밀리초를 넘긴 뒤에는 어떤 이점도 기대할 수 없다. 

 

(3) Unified programming environments 

- 통합개발환경, 각각의 새로운 도구들이 표준 형식을 따랐기 때문에 어떤 프로그램 환경에서도 적용할 수 있게 되었다. 

 

4. 꽤 괜찮은 방법들 

한 방에 해결해 줄 은총알은 없지만, 그래도 꽤 쓸만한 방법이 몇 가지 있다. 

 

(1) 소프트웨어를 만들지 말고 소프트웨어 제품을 구매해라. 

- 10 만 달러 비용의 소프트웨어 제품을 구매해도, 프로그래머 한 명의 연봉 정도에 불과하다.

- 소프트웨어 제품을 사서 공유하면 사용자당 비용을 획기적으로 줄일 수 있다. 

- 구매한 즉시 배송된다.

- 판매하는 제품을 자체 개발 제품보다 문서화가 잘 되어 있다. 

 

(2) 요구 사항 구체화 및 신속한 프로토타이핑 

- 소프트웨어 시스템을 구축할 때, 무엇을 구축할지 정확하게 정하는 것(기술 요구사항 설정)이 가장 어렵다.

- 동시에 고객은 자신이 원하는 것이 무엇인지 잘 모른다. 

- 따라서 개발자는 고객과 꾸준히 소통해야 하고, 고객을 위해 제품 요구 사항(프로토타입)을 반복적으로 추출하고 개선해야 한다. 

 

(3) 점진적인 개발 – 소프트웨어 구축이 아닌 성장 (하향식 성장, 하향식 설계) 

- 소프트웨어 프로그램은 한 번에 다 만드는 것이 아니라 점진적으로 개발하면서 성장해야 한다. (Harlan  Mills) 

- 별다른 기능이 없고 아무 쓸모가 없는 프로그램이라도 일단 실행되도록 만들어야 한다.

- 그 후 하위 프로그램의 동작과 호출로 개발하면서 조금씩 구체화한다. 

- 단순해도 실제로 동작하는 프로그램은 프로그래머의 의욕 증진에 좋은 영향을 준다. 

 

(4) 훌륭한 설계자 

- 최고의 설계자는 가능한 빨리 파악하는 게 좋다. 

- 담당 멘토를 지정하고 경력 파일을 꼼꼼히 관리한다. 또한 경력 개발 계획을 세우고 실천한다.

- 설계자는 서로 교류하고 자극 받으며 성장할 수 있는 기회가 있어야 한다. 

 

5. 의견 

소프트웨어 개발의 복잡성을 한 번에 해결할 마법 같은 해결책은 없다는 내용에 매우 공감하고, 비교적 오래된 논문이지만 현재의 프로그래밍에도 통용된다는 사실이 놀라웠다. 특히 마지막 해결책 내용 중 점진적인 개발을 하라는 내용은 “일단 하나만 해보자”는 생각을 가지고 프로그래밍하는 나와 겹쳐 보여서 더 인상 깊었다. 욕심이 많아서 한 번에 여러 가지 기능을 구현하려고 애쓰다가 결국 하나도 제대로 구현하지 못한 적이 더러 있었다. 원하는 기능을 구현하지 못해 만족감이 떨어지니 흥미도 잃었었는데 그 때마다 테스트용이라도 좋으니 아주 사소한 기능을 구현해내면 만족감을 느끼며 다시 흥미가 생겨 개발을 이어나갔다. 나는 이러한 경험을 통해 완벽할 수는 없어도 만족할 수는 있다고 느꼈다. 브룩스의 의견도 비슷한 맥락으로 시작한다고 생각한다. 브룩스는 소프트웨어의 문제를 한 방에 완벽히 해결할 은총알은 없으며, 미래에도 나오지 않을 것이라고 한다. 그리고 어차피 소프트웨어의 본질은 복잡하고 꾸준히 변화한다. 그러니 소프트웨어 개발자는 ‘문제를 완벽하게 해결하는 것’에 현혹되지 말고, 원칙과 기본을 지키면서 이것 저것 실행하다 보면 은총알은 못 돼도 납총알 정도는 될 수 있지 않을까라는 생각이 들었다.