Why Software Development Methodologies Suck by Hubert Shin

원문보기

소프트웨어 개발 기법들과 방법론들 주변에는 마치 종교에 대해 전쟁을 하듯 많은 독단(dogma)들이 존재한다. 단계별로 나누어 수행하는 방법론을 통해 소프트웨어 개발의 리스크를 관리하는 방법은 과연 효과적인가? 아니면 사실상 그냥 리스크를 관리하는 듯한 연극(필자는 kabuki라 표현함)만 하는 것인가? TDD는 실제로 높은 품질의 코드를 만드는 기법인가? 과연 패어 프로그램은 실제로 더 나은 코드 리뷰 방식인가? 아니면 컨설팅 비용만 증가시키는 방식인가? 난 이제부터, 이러한 논쟁들에 대해 과학적 증거만으로 결론 지으려하는 시도는 매우 부족하다는 이야기를 하려고 한다. 그리고 훌륭한 기법을 선택하면서 동시에 고객에게 전달할 소프트웨어의 실제 가치를 높일 수 있는 두 가지 원칙을 소개하려 한다. 이 두 가지는 싸이클 타임을 줄이고 피드백을 늘리는 것이다.

Michael Feathers 는 관찰을 통해 다음과 같이 이야기 한다.

항상 마지막에는, 어떤 프로그래밍 언어를 선택했느냐 또는 선택한 방법론의 어땠었는지 보다 개발자들의 기술력이 훨씬 중요한 변수라는 것을 우리가 받아들여야 한다고 생각합니다. 솔직히, 우리는 언어나 방법론이 가장 먼저 부러뜨려야 할 주제라는 망상 때문에, 모두가 이를 해결하려고 프로젝트에서 꽤나 고생하고 있습니다.(그리고 이것은 모두가 알고 있지요.) 아마도 이 현상은 비용만 생각하는 관점때문에 사람은 언제든 교체가 가능한 자원이라는 생각의 연장선이라 생각합니다.

그의 말에 따르면, 결국 우리가 프로젝트를 시작할 때 해결해야 할 진짜 문제는 어떻게 능력있는 개발자를 가려 내느냐이다. 하지만 여전히 IT분야에서 생산성이라는 지표는 지금까지도 누구나 인정할 수 있도록 정의되지 못했다. 때문에 능력 있는 개발자를 뽑는 기준 자체에서부터 무엇을 선택해야 할 지 매우 어려운 문제이다. 코드 라인수(이는 여전히 가장 인기 있는 측정 지표이다.)를 능력 지표로 삼는다면, 개발자들이 코드를 작성 할 때 코드 한 라인이 수행하는 품질에 대해 매우 심각한 문제가 발생하게 될 것이다. 왜냐하면 이 지표로 인해, 코드를 충분히 고민해야 할 대상으로 보지 않을 것이기 때문이다. 마찬가지로 만약 일한 시간이 얼마나 많은 지로 사람을 평가한다면 온종일 사무실을 떠나지 않는 프로젝트 내 영웅 같은 사람을 만들어 내게 되는데, 경험적으로 볼 때 이 영웅들은 프로젝트의 지연을 야기하는 경우가 많다. 왜냐하면, 이들은 보통 굳이 받아들이지 않아도 될 리스크까지 프로젝트 초기에 떠안으려 한기 때문이다. 또한 매우 긴 작업 시간은 사람들을 바보같이 만들어 결국 낮은 품질의 제품을 만들게 한다. 상황이 이렇기에, 여전히 IT 전문가들을 위한 분야별 표준이나 이를 평가하는 시스템은 사실상 없는 상태이다. 그래서, 여전히 좋은 사람들을 뽑는 기술은 사실 과학이라기 보다는 예술에 가깝다.

심리학자들도 IT분야가 왜 기술 습득이 어렵고 기술 수준을 측정하기도 어려운지 언급한 적이 있다. Daniel Kahneman은 빠르게 그리고 천천히 생각하기라는 책에서 다음과 같이 이야기한다. 기술 습득에는 기본적으로 두 가지 조건이 있다. 첫째로, 규칙이 존재하고 예상 가능한 환경, 둘째로, 긴 시간동안 실천하는 기법을 통해 이 규칙들을 배울 수 있는 기회이다.

하지만, 전통적인 소프트웨어 프로젝트는 규칙적이고 예상 가능한 환경과는 거리가 멀다. 제대로 된 유일한 지표라 할 수 있는 프로젝트의 성공(프로젝트의 끝에 기대하던 가치를 만들어 냈느냐)여부도 프로젝트 안에서 수행한 중요한 의사결정들이 그 성공이나 실패에 어떠한 영향을 이끌었는지 알기 어렵다. 또한 오랜 시간 동안 경험한 피드백을 받기 위해 필요한 인력, 즉 처음부터 프로젝트에 투입되어 현재까지 누군가 남아있는 경우는 더더군다나 드물다. 위와 같은 이유로 소프트웨어 개발 프로젝트에서, 어떤 의사결정이 근본 원인이 되어 성공이나 실패를 이끌었는지 아는 것이 현실적으로 불가능하다. (인공지능에서는 이것을 신뢰할당문제(credit-assignment problem)이라고 한다)


이러한 문제 때문에, IT전문가들이 기술을 습득하고 이 기술을 기반으로 성공적인 제품이나 서비스로 결과가 나왔다는 것을 증명하기 매우 어렵다. 이러한 증명 대신에, 개발자들이 보이는 해동은 이 습득한 기술로 가능한 빠르게 "개발 완료" 라고 선언함으로 자신의 목표에 다다랐다는 것을 증명하곤 한다. 하지만, 실질적으로 이들이 선언한 "완료"는 타 기능들과 통합여부나 제품으로서 고객에게 전달될 상태인지 여부와는 거리가 먼 경우가 많다. 다른 기능적으로 분할된 분야들에도 비슷한 문제가 발생한다.

소프트웨어 프로젝트가 규칙이 없고 복잡하다는 문제는 또 다른 문제를 일으킨다. 기술, 기법 그리고 방법론들을 통해 얻은 데이터가 실제적으로 효과가 있음을 나타내기는 극도로 어렵다. 또한 환경적인 특징 때문에 도출된 데이터들을 일반화하기는 거의 불가능에 가깝다.

Laurent Bossavit가 쓴 훌륭한 책인 "소프트웨어 엔지니어링의 레프리콘들"은 소프트웨어 개발에 구전되어 오는 전설같은 이야기인 "변경비용(또는 결함비용)곡선" 등과 같은 이론에 멋진 한방을 날리고 있다. 이 책은 개발자의 생산성을 측정하는 어떤 숫자 놀음이나(an order of magnitude), 정확성의 원뿔(the cone of certainty)같은 아이디어를 비롯한 소프트웨어 개발 방법론의 주춧돌이 되는 여러 가지 이론들에 대해 정확성을 문제 삼는다. 그는 이들을 포함한 많은 이론을 기술하면서, 이 이론들의 만들어진 기초가 기껏 컴퓨터를 전공하는 몇몇 학생들에게 매우 캐쥬얼한 방식으로 실험하여 얻은 데이터를 기반으로 했거나, 효과적으로 제어될 수 없는 프로젝트 환경 등에서 나온 조잡한 데이터를 이용하여 정립된 것이라 표현한다. 그는 이 연구결과의 구성은 방법론적으로 문제가 있거나 제대로 분석되지 않은 내용을 통해 기초되었다라고 주장한다. 또한 어떤 도메인에도 적용할 수 없는 가장 터무니 없는 발견으로 일반화되었다고 덧붙인다.


그의 이론대로라면, 애자일 개발 방식이 워터폴보다 낫다던지, 반대로 워터폴이 애자일 방식보다 낫다는지 따위의 일반적인 주장들 어떤 것이든 심각하게 받아들일 수 없다는 것을 알게 된다. "thought leaders"들의 직관들도 또한 부족한 가이드이다. Kahneman은 이 내용에 대해 다음과 같이 밝힌다. "사람들이 자신의 직관에 대해 가지고 있는 자신감은 사실 실효성을 볼 때 신뢰할만한 내용은 아니다. 전문가의 직관을 평가할 때는 항상 그것을 실제로 배울 수 있는 적당한 기회와 정형화된 환경이 있는지를 평가해야 한다." Ben Nutler-Cole이 쓴 "왜 소프트웨어 개발 방법론들은 멋진가?"이라는 포스팅에서 보면, 새로운 방법론을 소개하는 행위는 방법론을 적용하는 사람들의 의도에 맞게 어떤 결과든 얻을 수 있다고 이야기 한다.

위의 논지를 보면, 아마도 당신은 팀을 어떻게 일하도록 할 지 결정해야 할 때, 아무것도 할 수 없는게 아니냐고 반문할 수 있다. 하지만, 왜 소프트웨어 개발은 규칙적인 환경이 아님을 상각해보라. 그리고 왜 실험하기 어려운지, 역량을 습득하기 힘든지, 왜 어떤 기법과 의사결정이 성공으로 또는 실패로 이르게 하는지를 생각해보라. 이런 모든 경우들의 가장 근원적인 원인(왜 환경이 규칙적일 수 없는지에 대한 이유)은 변경을 일으키고 그 변경에 대한 결과를 얻어내는 것까지의 피드백 주기가 너무 느리다는 것이다. 여기서 내가 사용한 단어 "변경"은 요구사항의 변경 뿐만이 아니라, 방법론의 변경, 개발 기법의 변경, 비즈니스 계획의 변경 또는 코드 또는 설정의 변경 모두를 포함하는 것으로 이해해야 한다.

이 싸이클 타임을 줄이면 훨씬 많은 이익을 얻을 수 있다. 싸이클 타임을 줄이는 것은 소프트웨어 개발에 린 사상을 입힐 때 가장 중요한 원칙 중 하나이다. 짧은 싸이클 타임은 훌륭한 제품을 창조해 내는데 가장 필요한 것이다. Bret Victor 는 그의 훌륭한 발표가 담긴 비디오 클립인 "원칙을 발명해내기"에서 다음과 같이 말한다. "창조의 대부분은 무언가를 발견하는 것인데, 보통 당신이 실제로 무엇이든 해보면서 그것을 확인하지 않으면 아무것도 발견할 수 없다"

나에게는 이것이 가장 중요한 부분이다. 우리가 현실에서, 지속적인 개선을 연습하면서, 팀이나 개인이 어떻게 더 나아질 지 배우면서, 동시에 기술을 익히고 훌륭한 제품이나 서비스를 창조해 내는 것은 사실상 불가능한 일이다. 하지만 만약, 우리가 피드백 주기를 가능한한 가장 짧게 가져가면서 상관관계를 알게 되고 원인과 결과를 식별해 낼 수 있다면 이야기는 다르다.

실제로 피드백을 얻는데까지 짧은 싸이클 타임을 갖는 것의 이익은 매우 중요하다. 사람들은 이것을 비즈니스 모델에 가장 중요한 평가요소로 봐야 한다. 만약 당신이 당신 제품을 설치형 패키지나 Saas(Software as a service)중 어떠한 형태로 가져갈 지 결정해야 한다면, 싸이클 타임을 짧게 하기 위해 당신을 SaaS를 선택해야 할 것이다.(내 경험을 통해 말하자면 이렇다) 만약, 당신이 하드웨어랑 연관된 시스템을 만든다면, 프로토타입을 가능한한 빠르게 만들도록 하라. 또한 소프트웨어와 하드웨어를 둘 다 모듈화 하여 빨리 업데이트가 가능하고 독립적으로 구성하라. 3D 프린팅은 앞서 이야기한 바의 좋은 예이다. 왜냐하면 그것은 소프트웨어 개발 어플리케이션에서 시작하여 하드웨어 시스템으로 진화되면서 만들어졌기 때문이다. Cross-Functional Teams에서 일하는 것은 만약 충분히 짧은 싸이클 타임을 가져가기에 더 좋을 수도 나쁠 수도 있는 조건이 된다.

"훌륭한 사람들을 많이 고용하여 스스로 관리하고 운영되도록 하라"라고 말하는 소프트웨어 방법론들은 왜 문제인지 이제 알겠는가? 왜냐하면 이들은 보통 근본을 이해하지 않고 피상적인 행위(필자는 cargo-cult behaviour라고 표현함) 만을 이끌기 때문이다. 예를들어 스탠드업 미팅을 하고, 우선순위화된 백로그가 있고 심지어 지속적 통합까지 하고 있는데 왜 우리 프로젝트는 여전히 문제가 있고 지연되는지 묻는다면, 여러분의 프로젝트는 가장 중요한 것을 잊었기 때문이다라고 말하고 싶다. 바로 제대로된 조직을 만들지 않았기 때문이다. 제대로된 조직은 최대한 빠른 템포로 일하는 방법을 배우고 서로 적응한다.


핑백

덧글

댓글 입력 영역