1. 은탄환은 존재한다. 바로 여기에!
많은 투고자가 타당한 수정사항이나 불명확한 부분을 지적해주었고, 어떤 이들은 감사하게도 조목조목 분석하여 반론을 제기하기도 했다. 이번 장에서는 그런 개선점들을 공유하고 여러 반론을 다루어보겠다.
2. 모호하게 쓴 글이 오해를 산다.
- 부수성
'은탄환은 없다' 에서 말하는 부수적 에 의미는 우연히 일어난다 거나 불운하다 는 것이 아니라, 부차적 또는 종속적 이라는 의미에 더 가깝다.
소프트웨어 제작에서 본질적 이라고 한 부분은 마음 속에서 개념적 구조물을 만드는 과정이며, 부수적 이라고 한 부분은 그 구조물을 구현하는 과정에 해당한다.
- 사실의 문제
부수적 또는 개념 표현에 관련된 부분은 저자의 생각에는 이제 전체의 절반이나 그 이하로 줄어든 것 같다. 이 비율은 사실의 문제이므로, 이론적으로는 측정을 통해 그 값을 정할 수 있다.
'은탄환은 없다' 에서 명백하게 주장하는 바는, 부수적인 부분이 전체의 에 못 미친다면 마법으로든 뭐든 그것을 완전히 제거한다 해도 생산성에 자릿수 하나 만큼의 향상을 가져올 수 없다는 것이다. 우리는 본질적인 것을 공략해야 한다.
- 그렇다면 본질적인 어려움이 해소될 가망은 없는가?
1990년 브래드 콕스가 발표한 탁월한 논문 '은탄환은 있다' 에서는 문제의 개념적 본질을 공략하기 위한 접근법으로 재사용 과 상호교환 가능한 구성요소의 도입 을 호소력있게 주장하고 있다.
하지만 콕스는 두 가지 면에서 '은탄환은 없다' 를 잘못 이해하고 있다.
- 저자의 주장은 "오늘날 프로그래머들이 소프트웨어를 만드는 방법상에 어떤 결함으로부터" 소프트웨어 분야의 어려움이 비롯된 것이 아닌, 본질적인 어려움은 설계되고 만들어질 소프트웨어 기능의 복잡성에 이미 내재되어 있고 그 시기나 방법은 무관하다는 것이다.
- 개념적 구조물을 빚어내는 일에는 확실히 복잡성, 호환성, 변경 가능성, 비가시성이라는 본질적인 어려움이 내재되어 있다. 하지만 이런 어려움 각각으로 인해 생기는 문제들은 개선할 여지가 있다.
3. 복잡성은 여러 수준이다.
복잡성 은 내재된 어려움 중 가장 심각한 것이지만, 모든 복잡성이 불가피하지는 않다. 다른 사람이 만들었거나 자신이 과거에 만든 것을 재사용한, 좀 더 높은 수준의 덩어리를 가지고 소프트웨어를 성장시키면, 복잡성의 단계 하나를 통째로 회피할 수 있다.
'은탄환은 없다' 는 복잡성이라는 문제를 공략하는 것을 전적으로 지지하며, 향후 진전에 대해 상당히 낙관적이다. 또한 소프트웨어 시스템에 다음과 같이 불가피한 복잡성을 추가하는 것 역시 옹호한다:
- 여러 층으로 된 모듈이나 객체들에 의한 계층적 복잡성
- 시스템이 항시 동작하기 위한 점진적 복잡성
4, 하렐(Harel)의 분석
데이비드 하렐이 1992년에 발표한 'Biting the silver bullet' 은 출간된 논문 중에서 가장 면밀하게 '은탄환은 없다' 를 분석하였다.
- 비관주의, 낙관주의, 현실주의
하렐은 '은탄환은 없다' 와 파르나스(Parnas)의 1984년 논문 'Software Aspect of Strategic Defense Systems' 둘 다를 "아주 암울하다" 라고 평가하나 이는 글의 분위기를 잘못 이해한 것이다.
'은 탄환은 없다' 는 이렇게 명시적으로 쓰고 있다. "10년 후를 내다 보아도 은 탄환은 시야에 들어오지 않는다. ... 그렇지만 회의주의가 곧 비관주의는 아니다. ... 왕도는 없지만 길은 있다."
설사 '은탄환은 없다' 가 모든 이에게 비관적으로 보였다 해도, 문제될 것이 있을까? 어떤 것도 빛보다 빠를 수 없다는 아인슈타인의 주장이 "절망적ㅇ"이거나 "암울한" 것일까? 계산 불가능한 것이 존재한다는 괴델의 결론은 어떤가? '은탄환은 없다'는 소프트웨어 본성 자체가 그런 은탄환이 있음직하지 않도록 만들고 있다라는 것을 밝혀내려고 시도한다.
우리에게는 너무 자주 스스로의 낙관성을 따르는 경향이 있다 (또는 우리 후원자들의 낙관적인 희망을 이용하려는 것일 수도 있다.) 우리는 너무 자주 이성의 목소리를 묵살하고 만병통치약 장수의 유혹에 기꺼이 귀를 기울인다.
- "암담한" 주제들
하렐은 '은탄환은 없다' 속에 암담함을 느끼게 하는 세 가지 주제가 있다고 본다.
* 본질과 부수성을 뚜렷하게 구분한 점: 첫 번째 것은, 논문의 요점이므로 소프트웨어가 왜 어려운지 이해하는 데 이 구분이 절대적으로 중요하다고 여전히 믿는다. 그 구분은 어떤 동작이 필요한지 결정할 때 확실한 안내가 되어준다.
* 은탄환 후보 각각을 개별적으로 검토한 점: 다양한 호부들은 자신이 홀로 은탄환이 될 수 있다는 화려한 주장과 함께 개별적으로 제안되었다. 그 주장은 하나씩 따로 다루는 것은 역시 공평한 일이다. 내가 동의하지 못하는 것은
그 제안에 담긴 기법들이 아니라 그것들이 마법처럼 동작하기를 기대하는 일이다.
* 예측 대상 기간이 "의미있는 진전을 기대" 할 정도로 충분한 시간이 아닌 겨우 10년인 점: 예측 기간을 40년 정도가 아니라 10년으로 잡은 것은, 우리가 10년을 넘는 기간에 대해 제대로 예측해 본 적이 없다는 점을 어느 정도 고려한 것이다.
- 하렐의 사고 실험
하렐은 '은탄환은 없다' 가 동일한 주장을 담고서 1986년이 아닌 1952년에 쓰였다고 가정하는 사고 실험을 제안한다. 하지만 이런 논증은 통하지 않는다.
'은탄환은 없다' 가 도입부에서 주장한 바는, 1950 년대 프로그래밍 분야에서는 부수적 어려움들이 본질적인 것을 전적으로 압도하고 있었고, 지금은 더 이상 그렇지 않으며 부수적 어려움의 제거가 자릿수 하나만큼의 발전에 영향을 미쳤다는 것이다.
그는 이어서 소규모 프로그램에 가정되었던 고장과 오류, 기한 초과 같은 것들이 이후 25년에 걸쳐 어떻게 자릿수 하나 만큼 개선되었는지 서술하고 있다.
하지만 사실 1950년대의 최첨단 기술은 혼자 만드는 소규모 플로그램이 아니었기에 1952년 이래의 소프트웨어 분야가 1인 규모 프로그램으로부터 기술적으로 발전해 나갔다고 주장하기는 어려울 것이다.
- 은탄환이 여기에 있다.
하렐은 이어서 그 자신이 은탄환, 바닐라 프레임워크 라는 모델링 기법을 제시한다. 이 프레임워크의 모델링은 본질적인 내용, 즉 개념들을 적절히 빚고 디버깅하는 것을 다루고 있어서 획기적인 것이 될 가능성이 있고, 나도 그러기를 바란다.
- 비가시성
하렐과 내 견해는 상당히 근접해 있다. 내 주장은 소프트웨어 구조를 3차원 공간 안에 담을 수 없으며, 따라서 평면이든 그 이상으 차원이든 도표 하나에 개념적 설계를 대응시킬 자연스러운 방법은 없다는 것이었다. 각기 다른 측면을 나타내는 여러 벌의 도표가 필요하며 어떤 경우는 도표로 나타낼 방도가 없다는 점을 그도 인정하고 나도 동의하는 바이다.
5. 존스의 의견: 생산성은 품질을 따라간다.
존스는 "생산성", 즉 단위 입력당 소프트웨어 산출물이 아닌, "품질"에 집중해야 하며 그 결과로 생산성은 따라올 것이라 얘기한다.
그는 체계적 품질관리의 부재가 일정 붕괴 사이에 강한 상관관계가 있음을 보여주는 데이터를 제시한다. 보엠(Boehm)은 IBM 의 우주 왕복선용 소프트웨어처럼 품질을 극단적으로 추구할 경우 생산성이 다시 하락하는 점을 지적한다. 코키(Coqui) 역시, 체계적인 소프트웨어 개발을 위한 규율들은 생산성보다 품질 측면, 특히 대형사고의 회피를 염두에 두고 개발한다고 주장한다.
6. 그러면 생산성은 어떻게 되었는가?
- 생산성 수치
생산성을 나타내는 수치는 정의하는 것도 아주 어렵고, 조정도 어려우며, 찾아보기도 힘들다. 톰 드마르코는 "온갖 기술 덕택에 10년간 자릿수 하나 만큼의 발전이 있을 거라고 한 기대는 낙관적이었다. 내가 본 어떤 조직도 자릿수 하나 만큼의 발전을 이뤄내지 못했다" 라고 말한다.
- 패키지 소프트웨어: 만들지 말고 사라.
1986년에 '은탄환은 없다' 에 수록되었던 주장 중에서 하나는 옳았음이 판명된 것 같다. "대량 판매용 시장의 개척이야 말로 소프트웨어 공학에서 가장 의미심장하며 장기적인 트렌드다." 업계 전체 관점에서 볼 때, 대량 판매용 소프트웨어는 자가 제작이든 아니든, 맞춤형 소프트웨어 개발과 비교하면 거의 새로운 산업이라고 할 수 있을 정도다.
- 지적 작업을 위한 전동 공구
마이크로소프트 웍스나 통합성이 좀 더 뛰어난 클라리스 웍스같은 도구 세트는 엄청난 유연성을 제공한다. 그리고 주택 소유자의 전동 공구 세트처럼, 이런 저런 작업에 몇몇 도구만 빈번히 사용하다보면 거기에 점차 익숙해지기 마련이다. 이런 도구들은 전문가가 아니라 일반인이 사용하기에 편리해야 한다.
7. 객체지향 프로그래밍: 놋쇠 탄환으로도 충분할 것인가?
- 더 큰 부품으로 만들기
객체 지향 프로그래밍의 한 측면은, 그것이 모듈화 와 명확한 인터페이스를 강제하는 규율 이라는 것이다. 두 번째 측면은 부품들의 내부적인 구조와 설계를 알 수 없다는 캡슐화 개념을 강조한다. 다른 측면은 클래스들의 계층적 구조 및 가상 함수를 수반하는 상속 을 강조한다. 또 다른 면으로는, 특정 자로형은 오직 그 자로형에 고유한 연산으로만 조작될 수 있음을 보장하는 엄격한 추상적 자료형 을 강조한다.
객체지향 접근법의 매력은 종합 비타민의 그것과 같다. 단번에 (즉 프로그래머 재교육 시에) 그 모두를 갖출 수 있게 된다. 이것은 상당히 장래성 있는 개념이다.
- 객체 지향 기법의 성장은 왜 더디었는가?
제임스 코긴스(James Coggins는 이런 설명을 제시한다:
문제는, 객체 지향적 프로그램을 짠다는 이들이 그동안 오십보백보 수준의 애플리케이션으로 실험해온 데다가 낮은 수준의 추상화를 지향했다는 것이다. 예를 들면 그들이 만들어 왔던 클래스는 '연결 리스트'나 '집합' 따위였지 '사용자 인터페이스' 나 '방사광선', '유한 요소 모델' 같은 것이 아니였다.
객체 지향 개념의 원류 중 하나로 꼽히는 논문을 썼던 데이비드 파르나스는 이런 서신을 보내왔다:
답은 간단합니다. 객체 지향이라는 것이 여러 종류의 복잡한 언어에 결부되어 있었기 때문입니다. 사람들은 객체 지향이 설계의 한 종류라고 가르치면서 그에 따른 설계 원칙을 알려주는 대신, 특정한 도구를 사용하는 것이 객체 지향이라고 가르쳐 왔습니다. 우리는 어떤 도구를 가지고 좋은 프로그램도 나쁜 프로그램도 만들 수 있지요. 설계하는 법을 가르치지 않는다면, 언어는 뭐가 되었든 간에 별로 중요하지 않습니다.
- 선투자된 비용, 하향식 효과
"객체 지향 기법이 첫 번째나 그 다음 프로젝트 개발을 당겨 주는 일은 결코 없겠지만, 그 제품군의 다섯 번째는 엄청나게 빨리 미나들어질 것이다"
예상되기는 하나 확실치는 않은 장래의 이익을 보고 돈을 미리 거는 행위는 투자자들이 날마다 하는 일이다. 하지만 상당수의 프로그래밍 조직에서는 이런 행위에 기술적 영량이나 행정적 능숙함보다 더 드문 덕목인 진정한 경영적 용기가 필요하다.
이처럼 몹시 극단적인 선제 투자 및 사후 회수의 특성이야말로 객체 지향 기법 도입을 저해하는 가장 큰 요소가 아닌가 한다.
8. 재사용에 대해서는 어떠한가?
소프트웨어 제작의 본질을 공략하는 가장 좋은 방법은 아예 만들지 않는 것이다. 패키지 소프트웨어는 그러기 위한 방법 중 하나일 뿐이다. 프로그램 재사용은 또 다른 방법이다.
- 전사적 수준의 재사용은 어떻게 되어 가는가?
드마르코는, 대량 판매용 패키지가 출현하여 데이터베이스 시스템 같은 일반적 기능을 제공하는 데 적함해짐에 따라, 애플리케이션 코드 재사용에 대한 압박과 한계 효용이 모두 상당히 줄었다고 말한다. "재사용 가능한 모듈드은 어쨌거나 일반적 기능인 경향이 있었다."
요든은 이렇게 추정한다. "경험으로 볼 때, 이처럼 재사용 가능한 구성 요소를 만드는 데에는 일회성일 때부도 두 배의 비용이 든다." 이것은 앞서 1장에서 논의한, 제품화에 드는 바로 그 비용이다. 그러므로 내 추정치는 세 배다.
확실히 재사용의 형태가 여러 가지로 다양하기는 하지만, 지금쯤 그러리라고 기대했던 정도에는 미치지 못한다. 배워야 할 것은 여전히 많다.
9. 대규모 어휘를 배우는 일: 예측 가능했지만 예측하지 못한, 소프트웨어 재사용에 대한 문제
사고가 더 높은 수준에서 이루어질수록 다루어야 할 사고의 기본 요소도 늘어난다. 그래서 프로그래밍 언어는 기계어보다 더 복잡하고, 자연 언어는 그보다 훨씬 복잡하다. 고수준의 언어일수록 어휘가 더 많고, 문법이 더 복잡하며, 의미가 더 풍부하다.
어휘를 익히는 일은 재사용을 막는 진입 장벽의 작지 않은 일부를 이룬다. 프로그래밍을 하는 사람이 재상용의 이점을 최대한 얻기 위해서는 그 멤버들의 문법(즉 외부 인터페이스) 및 의미(상세한 기능적 동작)들을 익혀야만 한다.
소프트웨어 재사용 문제의 해결을 위해서는, 사람들이 언어를 습득하는 방법에 관련된 방대한 지식 체계를 동원하는 연구가 필요하다. 그 중 몇 가지는 아주 명백하다:
- 사람들은 문장의 문맥 속에서 언어를 배운다. 따라서 우리는 부품에 해당하는 라이브러리뿐 아니라 그것들이 조합된 제품 사례도 많이 공유할 필요가 있다.
- 사람들은 철자 외에 아무것도 암기하지 않는다. 문법이나 의미는 문맥 속에서 실제로 단어를 사용하면서 점진적으로 배운다.
- 사람들은 호환되는 객체들의 하위 집합이 아니라 문법적 클래스에 의해 단어 조합 규칙을 분류한다.
10. 탄환 위의 그물: 자리에 변동 없음
1995년, 독자의 생각을 글래스(R. L. Glass)는 1988년도 저술에서 정확히 요약하고 있다:
소프트웨어 개발은 개념적으로 어려운 일이라는 것. 마법같은 해결책이 목전에 있지는 않다는 것. 이제 혁명적인 발전을 기다리거나 희망하기보다는 점진적 개선 방안을 모색해야 할 때라는 것.
소프트웨어 분야의 어떤 이들은 이것을 맥 빠지는 얘기로 여긴다. 그들은 여전히 혁신적인 돌파구가 머지 않았다고 생각하는 이들이다. 하지만 우리 중 또 어떤 이들, 즉 우리를 현실주의자라고 생각할 정도로 무뚝뚝한 이들은 이 얘기를 신선한 공기와 같이 여길 것이다.
우리는 드디어 그림의 떡보다는 더 가능성 있는 무언가에 집중할 수 있게 된 것이다.
필자가 이전 챕터에서 정리했던 내용의 대부분이 등장해서 깜짝 놀랐다. 사람의 생각이란게 대체로 다 비슷한 것 같다. 다행히 관련된 내용을 책의 저자가 다시금 꺼내 들고와 정확하게 잘 정리해주었으며 답변도 명쾌했다.
출처
[책] 맨먼스 미신: 소프트웨어 공학에 관한 에세이 (프레더릭 브룩스 지음; 강중빈 옮김)
