| SW 개발자가 되는 것은「무거운 책임이자 특권」 UML과 래쇼날 로즈 개발자 그래디 부치 인터뷰 |
| 김창준 ( 마이크로소프트웨어 ) 2002/11/14 |
| 좋은 소프트웨어를 빨리 만들기 위해서는 오늘날 무엇이 필요한가요? 사실 그 질문보다도 문제는 더욱 복잡합니다. 품질과 시간에 대한 압력을 조율하는 것은 프로젝트에 주어지는 여러 가지 공학적인 영향(engineering forces) 중 두 가지를 조절하는 것에 불과합니다. 비용, 일정, 기능, 호환성, 성능, 확장성(scalability), 효율(throughput), 신뢰성, 실패 안전/결함 허용(fail safe/fault tolerance), 복원력(resilience) 등이 모두 프로젝트의 비즈니스적이고 경제적인 맥락 전반에서 균형을 맞추어야 할 것들입니다. 이 모두를 고려해 반복 가능하고 예상할 수 있는 방식으로 조율하는 것은 본질적으로 어렵습니다. 이런 것들을 극복하기 위해서는 무엇이 필요할까요? 배리 보엠(Barry Boehm)은 소프트웨어 경제학에 대한 자신의 작업에서, 프로젝트를 위한 리소스 요구에 영향을 미치는 네 가지 주요 요소가 복잡성, 프로세스, 팀, 도구라고 말합니다. 그렇기 때문에 무엇이든지 간에 복잡성을 관리할 수 있게 하고, 계획된 프로세스를 제공하며, 팀에게 자신감과 힘을 주고, 도구를 통해 작업을 자동화하는 것들이 큰 도움이 될 것입니다. 왜 여전히 ‘소프트웨어 위기(crisis)’가 있을까요? 최근의 통계(예컨대 스탠디쉬 그룹 보고서 같은)에 따르자면, IT 프로젝트의 상당수가 실패하거나 혹은 그럴 위험이 있다고 합니다. 실질적인 문제가 무엇이라고 보십니까? 내재적인 문제는 아마도 품질이 좋은 소프트웨어를 만들어 내는 것은 투자자와 개발자로 이루어진 한 팀의 집합적인 노력을 필요로 하는, 매우 어려운 지적 작업이라는 것이지 않을까요. 복잡도는 점점 증가하고 있고 거기서 문제는 더욱 악화됩니다. 궁극적으로 소프트웨어 개발은 인간 활동(human activity)입니다. 이 말은 근본 문제는 결국 인간에 관련된 것이지 기술에 관한 것이 아니라는 말이 됩니다. 하지만 기술적 요소들이 우리 문제 속 깊이 포함되어 있다는 사실 때문에 작업이 복잡해집니다. 프레드 브룩스(Fred Brooks)가 말했듯이 소프트웨어에는 본질적으로 도무지 피할 수 없는 복잡성이 있습니다. 컴포넌트 기반 개발, UML, AOP(Aspect-Oriented Programming), 애자일, 웹서비스, 닷넷 혹은 최근 시장의 주목을 받고 있는 그 무엇이 이런 문제를 해결하는 데 도움이 될 것이라고 생각하십니까? 그렇다면 어떤 면에서 그렇게 생각을 하시나요? 그것들은 모두 어떤 해법의 요소가 될 수 있는 것들입니다. 제가 보기에는 우리가 소프트웨어를 개발하는 방식에 어떠한 혁명이 있었다고 생각지 않으며, 장래에 그러한 혁명이 있을 것이라 기대하지도 않습니다. 진보는 다른 의미있는 공학적 활동과 마찬가지로 과거의 기반 위에서 진화의 방식으로 이루어집니다. 말씀하신 것의 대부분은 본질적으로 추상화나 프로세스와 상관이 있습니다. 인간은 복잡성을 추상화를 통해 다스립니다. 실제로 소프트웨어 공학의 전체 역사는 우리의 언어나 메쏘드, 프로세스 등에서 보듯이 추상화 레벨을 증가시키는 것이었습니다. CBD (Component Based Development), UML, AOP, 웹 서비스, 닷넷, J2EE 모두가 추상화 레벨을 올려주는 예입니다. 애자일 메쏘드들과 RUP(Rational Unified Process)는 모두 프로세스를 관리하는 요소입니다. 거듭 말하지만 개발은 인간 활동이며 우리가 효과적인 베스트 프랙티스(예컨대, ‘테스트 우선’과 아키텍처를 성장시켜 나가는 것 등)를 발견할 수 있는 한 소프트웨어 개발을 어렵게 만드는 마찰점 몇 군데를 공격할 수 있지 않을까 합니다 |
