Home > 열린마당 > 공개SW 소식

공개SW 소식

2013년 08월 16일 (금)

ⓒ CIO Korea, Matthew Heusser | CIO



현재 소프트웨어 개발 업계에는 객체지향 프로그래밍을 ‘또하나의 툴’로 보고 있다. 애자일 개발도 객체지향 프로그래밍처럼 또하나의 방법론일까? 아니면 대세일까?  컨설턴트인 매튜 허서가 전문가들을 만나 의견을 들어봤다.


지난 4월에 열린 소프트웨어 테스팅 전문가 컨퍼런스(Software Test Professionals Conference)에서 마지막 순서로 업계의 미래에 관한 패널 논의가 이루어졌다. 렉스 블랙은 "애자일 방식이 주류가 됐다"고 말했다. 패널로 참석한 그의 동료이자 플로리다공대(Florida Institute of Technology)의 교수인 켐 카너는 한편으로 애자일 소프트웨어 개발이 이미 주류로 자리잡고 있으며 애자일 방식을 채택하지 않은 기업들은 경쟁자들보다 뒤쳐질 위험에 처했다고 주장했다.


누가 옳은 것이며, 이것은 무슨 의미일까?


객체 지향 개발이 주류를 이룬 것은 사실이다
1998년 알리스테어 콕번은 객체 지향 프로젝트의 생존(Surviving Object-Oriented Projects)을 썼으며, 1년 후에는 로버트 바인더는 객체 지향 시스템 테스팅(Testing Object Oriented Systems)을 집필했다. 두 저자 모두 객체 지향 프로그래밍이 새로우며 무엇인가 굉장한 것을 제공함과 동시에 엄청난 위험에 직면하고 있다고 밝혔다. 객체 지향 컨퍼런스 OOPSLA는 세상을 바꾸고 있었다.


오늘날 임베디드 및 레거시(Legacy) 시스템 업계에서 필자가 인터뷰를 진행한 모든 기업들은 객체 지향 프로그래밍 언어(일반적으로 자바, 루비(Ruby), C# 등)를 사용하고 있다. 즉, '객체 지향'에 관한 책을 쉽게 발견할 수 있는 곳은 1학년생을 위한 컴퓨터 공학 수업시간이다. OOPSLA 또한 수 년에 걸쳐 쇠퇴하다가 2012년에 스플래시콘(Splashcon)이라고 하는 이벤트에서 다시 회생의 기회를 발견했다.


객체 지향 프로그래밍이 실패했다는 뜻은 아니다. 대신에 그 반대의 일이 발생하고 있다. 다른 것들과 마찬가지로 OOP도 주류를 이뤘다.


이런 일이 애자일에도 발생할 수 있다. 규모가 가장 컸던 애자일 컨퍼런스는 2008년에 1,500명이 참석했던 컨퍼런스였다는 사실에 놀랄 수도 있을 것이다.


기업의 애자일 개발 방식 영향을 바꾸는 규모와 장벽
산업 분석은 복잡하다. 예를 들어, 설문조사에 참여하는 사람들은 대부분 얼리어답터이며 변화에 열려 있고 커뮤니티에 ‘소속’돼 있을 가능성이 높다. 이 때문에 그들이 남들보다 일찍 설문조사 이메일을 받아볼 수 있는 것이다. 항공우주, 의약, 정부 등 자체적인 웹 사이트, 잡지, 뉴스소스 등을 가진 업계에서 근무하는 사람은 이런 설문조사가 존재한다는 사실조차 모를 것이다.


이런 점을 염두에 두더라도 "당신의 기관은 애자일 개발을 실시하고 있는가?"라는 질문에 84%가 "그렇다"라고 답한 버전원(VersionOne)의 2012 애자일 개발 설문조사(2013 Agile Development Survey) 등의 보고서를 무시하기는 어렵다. 그 중 54%는 스크럼(Scrum)을 사용하고 있다고 밝혔다.


설문조사 이상의 결과를 얻기 위해서 필자는 소프트웨어를 개발하고 이를 기업들에 통합하기 위해 노력하는 소프트웨어 개발기업을 찾아 보았다.


소프트웨어 AG(Software AG)는 내부 기술직으로 1,000명을 고용하고 있으며, 그 외에 수천 명의 직원들이 컨설팅 및 통합 업무를 담당하고 있다. 필자는 고객들이 무엇을 하고 있으며 소프트웨어 AG가 그들과 어떻게 상호작용하고 있는지에 대해 알아보기 위해 CMO 아이보 토테브를 만나보았다.


토테브는 애자일 도입의 장벽이 변화에 대한 장벽으로 작용하고 있다고 설명했다. 대형 레거시 프로젝트, 데이터베이스 프로젝트, 서비스를 보호하는 시스템 등은 변경이 어려우며, 추가적인 조율 및 의사소통을 필요로 하고 테스팅 사이클 또한 느린 것이 특징이다. 추가적인 간접비 때문에 애자일을 위한 간결한 테스트, 공개, 피드백 사이클 등이 더욱 어려워지고 있다.


애자일 코치 데이브 니콜렛도 이에 공감했다. 그가 설명했듯이 "팀이 자립적으로 다른 팀에 의존하지 않는다면 원하는 대로 빠르고 원활하게 진행할 수 있다. 변화를 조율해야 한다면 더욱 선제적인 기획이 이루어져야 한다. 하지만 그렇다고 해서 애자일이 '가능'하다는 뜻은 아니다. 이로 인해 간접비만 늘어날 뿐이다"는 것이다.


니콜렛이 느끼는 또 다른 큰 차이점은 기업의 규모다. 토테브와 마찬가지로 니콜렛도 소규모 프로젝트에 문서화된 프로세스가 필요하지는 않다는데 동의했다. 그는 계속해서 "200명이 일하는 회사에서 소프트웨어 개발에 참여하는 직원이 소수라면 프로세스가 전혀 필요하지 않을 수도 있다. 마찬가지로 2,000명이 일하는 기업에 수백 명이 소프트웨어 개발에 참여하고 있으며 기존의 프로세스와 레거시 코드베이스(Codebase)가 유지되고 있다면 애자일이 제공할 수 있는 것을 활용하기 위해 충분히 민첩하게 움직이지 못할 수도 있다"라고 말했다.


토테브 및 니콜렛과 대화를 나눈 후에 필자는 이제 마이크로소프트 등 소프트웨어 개발자들이 가장 큰 규모의 고객기반을 보유하고 있는 기업으로부터 고객들이 어떤 의견을 제시하고 있는지에 관해 들어보아야 할 때라고 느꼈다.


마이크로소프트의 고객들은 생각보다 애자일과 거리가 멀다?
마이크로소프트 비주얼 스튜디오 애플리케이션 생애주기 관리(Microsoft Visual Studio Application Lifecycle Management)는 많은 것을 의미하지만, 그 중 하나가 비주얼 스튜디오를 둘러싼 프로세스 ‘래퍼(Wrapper)’이다. 비주얼 스튜디오 제품관리 수석 책임자 카씩 라빈드란(karthik Ravindran)은 최신 버전에 관해 이야기했다.


라빈드란은 스크럼 프레임워크 내에서 활용하는 버전제어 및 스토리와 관련된 소프트웨어가 인기를 얻고 있다는데 동의했다. 그리고 그는 툴의 핵심 부분인 스크럼 템플릿(Scrum Template)을 선보였다. 해당 템플릿 내에서는 개발이 작업으로 정의되고 시간 단위로 예측 및 추적되며 실제 시간에 맞춰 조절되지 않는다.


이는 작업 소요 시간을 고려하지 않고 과거의 성과에 기초하여 측정하고 예측하는 것을 선호하는 대부분의 애자일 전문가들의 생각과 상반되는 이야기다. 라빈드란은 비주얼 스튜디오를 통해 선제적 조치가 가능하지만 ‘기성’ 템플릿과는 다르다고 설명했다.


개인적으로 고객 설문조사를 손쉽게 진행할 수 있는 마이크로소프트가 정확히 시장이 원하는 것을 개발할 수 있으며 시간에 따른 작업 산정이 (완료된 작업인) 산출량을 측정하여 미래의 싸이클을 예측하는 것보다 더욱 보편적이라 생각한다. 버전원의 연구에 따르면 놀랍게도 스크럼을 ‘수행하는’ 팀의 54%가 별다른 성과를 얻지 못하고 있다고 한다.


이 덕분에 객체 지향 프로그래밍이 실제로 어느 정도나 도입됐는지를 생각해 보게 되었다.


오늘날 OOP의 실태: 형태를 잡긴 했지만 실체는 존재하지 않는다
필자가 대화를 나눈 대부분의 사람들은 객체 지향 언어로 프로그램을 개발한다. 하지만 그들이 코드로 작성하는 것과 이행 패턴(Implementation Patterns)에서 켄트 벡이 지지하거나 클린 코드에서 로버트 C. 마틴이 지지하는 프로그램의 종류 사이에는 실제적인 차이가 존재한다.


소위 말하는 ‘공식적인’ 브랜드인 OOP ‘브랜드’는 1인 책임 및 의존성 역전 등의 규칙이 존재한다. 이런 규칙으로 인해 매우 엄격한 규칙 (7줄 이하의 코드 등)과 3개 이하의 순화 복잡도(Cyclomatic Complexity)로 이어진다 (즉, 코드의 테스팅이 쉽기 때문에 수정도 쉽다는 뜻이다).
필자가 인터뷰를 진행한 대부분의 사람들은 이런 규칙이 존재한다는 것을 인지하지 못하고 있었다. 대신에 그들은 객체 지향 언어를 사용해 기본적인 절차적 코드와 계승 및 캡슐화를 작성했다.


이를 뒤집어 오늘날의 ‘애자일’ 팀을 살펴보자. 필자는 여기서도 마찬가지라 생각한다. 벽을 넘어 흘러가는 카드들, ‘제품 소유자’, ‘스프린트(Sprint)’, 금새 사리지는 신생기업들, 시연일 등이 모두 애자일의 특징이다. 하지만 대부분의 경우에 있어서 관리자가 작업을 할당하고 개인이 수행하며 소급 적용하여 변경할 수 없는 기업의 기준에 따라 문서로 기록된다.


애자일 방식을 수용한 사람들이 응답했을 가능성이 높은 버전원 설문조사에서 팀들의 43%만이 테스팅으로 입증된 개발을 수행하며 30%는 페어 프로그래밍(Pair Programming)을 실시하는 것으로 나타났다.


애자일 개발이 꽤나 오래됐고 위험성은 일정한 형태를 갖추었지만 여전히 실체가 존재하지 않는 OOP와 동일하다.


기술적인 애자일 사례에서 문화적인 사례로 이행한다
존 컨은 또 다른 애자일 코치로 이런 위험을 ‘인간의 본성’으로 설명하고 있다. 저자 제리 와인버그는 이를 가리켜 무엇인가를 넓게 펴 바르면 두께는 더 얇아지는 딸기잼의 법칙(The Law of Strawberry Jam)으로 설명했다.


하지만 이것은 단순히 얇게 펼쳐지는 수준이 아니다. 이야기, 스프린트, 더욱 빈번한 공개 일정이 존재하는 프로젝트 관리 등의 사례는 테스팅으로 입증된 개발 과 지속적인 통합 등의 기술적 사례보다 더 높은 도입률을 달성했다. 기술적 사례는 팀의 프로세스 소유, 종합성, 독립적 팀, 꾸준한 페어링 등의 문화적인 것들보다 더 많이 도입되고 있다. 이 3가지 범주는 모두 ‘애자일’이지만 문화적 사례를 애자일의 ‘핵심적 특징’으로 볼 수도 있을 것이다.


오늘날 시장을 주도하는 기업들의 대다수는 애자일 소프트웨어의 프로젝트 관리 측면을 수용하고 있는 듯 하다. 나머지들의 경우, 개선의 여지가 있으며 이는 경쟁우위의 여지가 있음을 의미한다.


개인적으로는 긍정적인 현상이라 생각한다.


*Matthew Heusser는 컨설턴트이자 기고가다.




※ 본 내용은 한국IDG(주)(http://www.itworld.co.kr)의 저작권 동의에 의해 공유되고 있습니다.
Copyright ⓒITWORLD. 무단전재 및 재배포 금지


[원문출처 : http://www.ciokorea.com/news/18073]

맨 위로
맨 위로