라디컬에드워드 X세대

논쟁의 장(場)

이론이 먼저냐, 실제가 먼저냐?

• 두 단어의 개념 사이의 순서는 어떨까.?
• 일반적으로는 무의식중에 이론이 “먼저 나와서 실제의 틀을 마련” 생각하지만 이는 심각한 결함, 뿌리 깊은 오해...
• 책에서 몇가지 예를 드는데 “비행기를 날게 하는 익형 날개”,“열역학과 증기 기관”, “시분활 시스템”,..
• 저자 자신의 개인적 경험을 떠올려 보면 실제가 이론을 앞선다는 개념이 타당한것으로 판단.
  • 프로그래밍 스타일
  • 컴파일러
  • 시뮬레이션
  • 사용자 인터페이스 설계
  • 설계
• 하지만 결국 이론이 급격하게 성장하고 그 성장을 실제가 따라가지 못하는 시기가 올것이라고 얘기 하고 있음
• 즉 결론은 실제(경험적 지식)을 중시하되 이론을 무시하지 말자(?) 이 정도가 아닐까 생각됨

위험하며 오도(誤導)하다

• 오도(誤導) : 사전적 의미로 그릇된 길로 이끎(http://krdic.naver.com/detail.nhn?docid=27588300)
• 스타워즈 방어 시스템(SDI) – 예전에 뉴스를 본것 같은데 레이건이 인공위성을 통해서 미사일도 격추하고 머 그랬던거 같음(http://news.naver.com/main/read.nhn?mode=LSD&mid=sec&sid1=104&oid=001&aid=0000069641)
• 데이비드 파나스 교수가 SDI처럼 복잡한 시스템의 소프트웨어 문제는 극복하기 불가능 하다라고 주장하고 위원회 보직을 사임했다고 함
• 그때 발표한 논문의 내용을 중심으로 저자가 소프트웨어를 성공적으로 구축하기 힘든 이유에 덧붙여 소프트웨어 분야의 현 실정을 얘기하고자 함
• 논문 내용의 몇가지 부분을 발췌 하면
  • “새 프로그래밍 언어가 극적인 향상을 가져 오리라 기대해서는 안되며, 프로그래밍 환경 문제가 우리 분야의 진짜 장애물은 아니다.”
    • 자동 프로그래밍 시스템, AI 머 이런거를 다시 저자가 들먹이는데.. (사실 저건 제가 봐도 아니올시다 인데. ) 이에 대한 파나스가 비판적 시각을 피력
  • “우리는 소프트웨어 신뢰성을 보장하는 방법을 알지 못한다.”
  • 진실로 소프트웨어 연구가 제대로된 연구가 될려면 실무자를 연구에 참여시켜야 한다. 머 이런 결론을 파나스가 낸다고 합니다.
  • 즉 저자가 내리고 싶은 결론은 소프트웨어 생산성을 비약적으로 향상시킬 계기, 몇 배로 껑총 끌어올릴 방법은 언어, 도구, 자동 프로그래밍 방법론, 소프트웨어 정형 검증, 인공 지능, 요즘 인기 있는 소프트웨어 연구 주제 그 어느것오 아니다란~,.... (그럼 없나.????)

은총알은 없다(No silver bullet)

• No silver bullet : The Mythical Man-Month-Essay on software engineering” -Brooksm Frederrick P, Jr 책에 보면 No silver bullet 글이 수록되어 있음 – 대충 글이 소프트웨어 개발의 본질적 어려움에 대해서 논한것으로 지름길은 없다.? 머 이런 내용이 수록되어 있습니다.
• 소프트웨어 생산성이 극적으로 좋아지지 않는 문제에 대한 관점
  • 데이비드 파나스 : 소프트웨어 연구가 실무를 비약적으로 향상 시키지 못했으며, 사실상 향상 시킬 수 없고, 일부 연구는 “위험하고 오도할 소지가 있다“고 말한다.
  • 프레드릭 브룩스 : 은총알 논문에서 소프트웨어 개발은 어렵고 앞으로도 어려울 것이다. 라고 말함
• 그래서 결론은 “소프트웨어 개발은 개념적으로 어렵고, 만병통치약이 없으며 실무자는 혁명적인 도약을 고대하지 말고 점진적인 발전을 추구해야 한다”

가장 뛰어나고 명석한 두뇌들이 내놓은 보고서

• “향후 십년 동나 소프트웨어 생산성, 안정성, 적시정을 10이상 향상 시킬 기술적 발전은 눈 씻고 찾아봐도 없다.”
• “업계 실무에서 최고 수준과 평균 수준이 이렇게 차이나는 분야는 거의 없다”
• “진짜 문제는 기술이 아나다. 오늘날 정말 심각한 문제는 관리다.”
• 위 문구는 80년대 후반 미 국방과학부 특별 위원회가 군용 소프트웨어에 관하여 내놓은 보고서의 시작 부분
• 20년전 나온 보고서 지금도 유효할까.? -> 저자는 “네” 라고 하는것 같음
• 조사 결과 몇가지는 살펴 보면
  • 시스템 분석이 관하여, 소프트웨어 개발에서 요구사항 정의가 ‘가장 어려운 부분’ 이라고 지적 – 해결 방법으로는 프로토타이핑을 지지함
  • 4세대 언어(4GL)에 관하여, 3GL과 4GL을 혼합한 접근 방식이 안전하다고 제안한다. (20년이 지난 지금으로서 사실 4GL 언어중 어떤게 남았는지 생각해보면 흐음~~~~ 위의 제안도 좀 고민 되네요)
  • 에이다에 관하여, 에이다는 우수한 언어이므로 지원해야 하지만 소프트웨어 문제가 하나의 언어로 해결될 사안은 아니라는 사실을 지적함
  • 점진적 구현에 관하여, 보고서는 소프트웨어 개발에 부족한 점을 인정하는 능력은 ‘직업적 겸손’ 이라 칭한다. 전체 소프트웨어를 개발하는 과정에서 최소 완성 버전을 만들어 초기에 출시하라고 제안한다.
  • 기성품 소프트웨어에 관하여, 소프트웨어를 제작하는 최선의 방법은 ‘아예 제작하지 않기’ 라고 함
  • 소프트웨어 평기 기준이 필요함
• 추천 사항 몇가지
  • 점진적 개발과 프로토타이핑 : 보고서는 점진적 시스템 개발 방법과 프로토타이핑을 강력히 지지한다.
  • 재사용 : 기존 소프트웨어 컴포넌트와 시스템을 재사용해야 하는다 입장 역시 강력히 지지한다.
  • 에이다 : 군용 표준 언어로 사용을 강력히 지지한다.
  • 4GL : 보고서는 4GL언어 지원에 미온적 태도를 보인다. ‘생명주기비용’,‘생산성/유지보수성‘을 트래이드오프 해보라~
  • 위험 관리 : 관리 방식의 중요성을 강조
    • 1. 프로젝트에서 최고 위험 10가지를 밝힌다.
    • 2. 각 위험별 대처 방안을 세운다.
    • 3. 매달 최고 위험 목록, 대처 방안, 결과를 수정한다.
    • 4. 월간 프로젝트 검토 회의에서 위험 상태를 점검한다.
    • 5. 적절한 조치를 취한다.
  • 평가 기준 : 제품 품질을 측정하는 기준의 필요성을 강조
    • 1. 포상 (금전적 보상) 제도 마련
    • 2. 품질과 완성도를 측정하는 기술과 평가하는 기준을 개발
    • 3. 구현 상태를 평가하는 기준을 개발하라
• 결론
  • 새로운 기술 개발을 시도하거나 개발 중인 기술에서 적당히 초점을 변경하기 보다는, 소프트웨어 조달이라는 주제를 완전히 재검토하고 태도와 절차와 정책을 변경해야 한다
  • 다시 말해 기술적 도약이 소프트웨어를 구제 하지 못한다.