Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
개발자

예측 수치만으로 SW 엔지니어링을 통제하면 안 되는 이유

Jeremy Duvall | InfoWorld 2022.06.17
대다수의 소프트웨어 엔지니어링 예측은 무가치하다. 기업이 잘못된 방법이나 툴을 사용하기 때문이 아니다. 작업 분석 구조 또는 유추 기반? 기계적 또는 판단적 조합? 기능, 이용 사례, 또는 스토리 포인트? SEER-SEM, WMFP, 또는 와이드밴드 델파이? 툴은 어떤 것이든 좋다.
 
ⓒ Getty Images Bank

대다수의 예측이 의미 없는 이유는 이런 예측이 양질의 소프트웨어가 어떻게 만들어지는지에 근본적으로 잘못 이해하고 있기 때문이다. 그 피해는 단순히 비용을 초과하거나 데드라인 지키지 못하는 정도가 아니다. 실질적인 비즈니스 가치를 전달하는 대신 무의미한 지표를 중요시하면서 틀린 행동을 강요한다.
 

잡음과 비-결정주의는 소프트웨어 엔지니어링에 필연적

애자일 환경에서 예측은 흔히 스토리 포인트와 속도를 근거로 한다. 솔루션의 개별 부분을 제작하는 것이 얼마나 복잡한가, 이 복잡성 스토리를 완료하기까지 시간이 보통 얼마나 걸리는가 같은 것이다. 그러나 우리는 이런 식으로 예측해도 모든 것이 계획대로 되지는 않을 것임을 알고 있다. 그런데도 대부분 예측의 기저에는 이런 불확실성마저 수량화해 예측에 반영할 수 있다는 위험한 전제가 깔려 있다. 낙관적인 엔지니어가 일정 작업에 걸리는 시간을 15% 과소하게 추정하는 경향이 있다면 이런 점까지 고려해 예측을 개선한다는 것이다.

사전에 전체 프로세스를 구체화하고 측정하려는 이 강박은 엔지니어를 예측 가능한 작업 산물을 파이프라인에 꾸준히 집어넣는 기계로 바라보는 시스템에 그대로 이어진다. 즉, 소프트웨어 개발 과정의 비유는 마치 실제적인 것으로 취급되고, 허울뿐인 허상의 기능에 수량적 정당성을 덧씌우는 수학적 계산으로 변환된다.

그러나 다행히도 인간은 기계가 아니다. 그리고 약간 덜 명백하긴 하지만 사소하지만은 않은 소프트웨어 엔지니어링 작업의 복잡성은 사전에 정확히 예측하기가 거의 불가능하다. 엔지니어링 분야는 매우 새롭고 급속히 변화한다. 따라서 지난주의 성과를 바탕으로 다음 주의 속도를 예측하기가 쉽지 않다. 우리가 매일 직면하는 난제는 대개 새로운 것이고, 심지어 이미 알고 있는 것조차 머무르는 법이 없다.

예를 들어 가장 사소한 사례인 로그인 페이지를 보자. 숙련된 소프트웨어 엔지니어라면 수십 번 아니 수백 번 해본 일이다. 솔루션의 패턴을 잘 알고 있고 새로 로그인 페이지를 만들 때 시간이 얼마나 걸릴지 대충 예측할 수 있다. 그러나 인증 및 권한 부여를 다루는 새롭고 더 안전한 방식이 등장하면 어떻게 될까? 갑자기 기본적인 로그인 페이지의 작동 방식을 다시 생각해야 하고 다시 구현해야 한다.

대다수 소프트웨어 엔지니어링 난제는 로그인 페이지보다 훨씬 복잡하다. 큰 문제에 대처하고 실질적인 가치를 생성하는 작업이라면 더 그렇다. 과거에 해 본 적이 없거나 이제야 제대로 가능하다고 여겨지는 일이다.

결론적으로 이런 불확실성은 나쁘지 않다. 이는 개발자의 야심이 충분히 비현실적인 것이라는, 그리고 개발자가 유의미하고 유가치한 일을 하고 있다는 징후다. 따라서 이를 예측하는 작업 자체가 문제는 아니다. 임의로 예측하는 것이 문제인 것이다. 통계 전문가라면 시스템에 잡음이 너무 많다고 말할 것이다. 다시 말해 예측 안에 수정 가능한 것보다 가변성이 더 많은 것이다. 더구나 우리가 예측하려는 개발 작업은 근본적으로 비-결정적이다. '규칙적인 코딩 기계가 결정론적 작업을 처리한다'는 '미신'을 전제로 할 때 예측이 완전한 시간 낭비인 이유다. 그러나 시간 낭비는 시작일 뿐이다. 생각할 수 있는 피해의 최소치에 불과하다.
 

그릇된 예측은 비즈니스를 망친다

이런 무가치한 예측은 일하는 주체가 사람임을 고려하지 않는다. 더 나쁜 점은 시스템과 프로세스만 중요하다고 끊임없이 강조하는 것이다. 결국 조악한 엔지니어링, 인재 손실, 가치가 떨어지는 솔루션으로 이어진다. 이런 예측은 엔지니어가 강요받을 때만 작업한다는 잘못된 문화를 전제로 한다. 엔지니어가 자신의 작업이나 사용자에게 관심이 없음을 전제한다.

결국, 예측치보다 뒤처진다면? 가족, 친구, 행복, 건강을 잊고 더 '빡세게' 일해야 한다. 배정된 시간 내에 양질의 솔루션을 만들 수 없다면? 속성 픽스를 어떻게든 만들어 티켓을 마감해야 한다. 이로 인한 생겨나는 또 다른 문제를 해결하는 것은 다른 사람의 몫이다.

이렇게 되면 업무 방식도 바뀌게 된다. 기존보다 소프트웨어를 더 잘 만들 수 있는 새 아이디어가 떠올라도 일정을 망치지 않도록 그냥 자신 안에 묻어두게 된다. 더구나 예측을 가지고 직원을 괴롭히면 이들은 이내 편법을 배우게 된다. 최소한의 시간을 벌기 위해 복잡성을 과대평가하고, 너무 빨리 진행되면 속도를 늦춰 이후 작업의 예측 처리시간이 너무 줄어들지 않도록 할 것이다. 영리한 사람이라면 반드시 이렇게 할 것이다.
 

상호작용은 프로세스와 툴보다 더 많은 가치를 생성한다

“개인과 상호작용은 프로세스와 툴보다 우선한다(Individuals and interactions over processes and tools).” 이는 애자일 선언(Agile Manifesto)의 핵심 가치 중 하나다. 배려심 있고 윤리적인 인간으로서 우리가 모두 가치 있게 생각해야 하는 것에 대한 선언이다. 또한 프로세스보다 사람에 집중한다면 더 우수한 품질의 결과물을 얻을 수 있음을 강조한다.

생산적인 소프트웨어 엔지니어링 문화는 신뢰라는 토대 위에서 구축되고 인간관계에 의해 견인된다. 이는 중대한 문제를 해결하거나 유의미한 기회를 만드는 고품질 고가치 솔루션을 개발하려는 공통된 의지를 가진 성인의 사회적 네트워크이다. 이러한 문화에서 편법은 존재하지 않는다. 공통된 목적은 최선을 다하도록 장려한다.

이런 네트워크에서 개선이란 마감된 티켓이 아니라 생성된 가치에 의해 측정된다. 예측치보다 더 좋은 접근법을 발견하면 기꺼이 아이디어를 공유하게 된다. 왜냐하면 임의적 예측이 아니라 양질의 솔루션이 성공의 최종 지표임을 알기 때문이다.

이처럼 프로세스와 툴이 아니라 개인과 상호작용에 집중하면 개인은 최고의 가치를 발휘하고 팀은 협업에서 생성하는 가치를 배가시킨다. 이는 완전히 구체화된 제품의 세세한 예측치를 갖고 사람을 통제할 때보다는 덜 예측적일 수 있다. 하지만 이 통제와 예측성을 버리면 궁극적으로 더 탁월한 가치가 발현된다.
 

로드맵, 범위, 관계가 해법이다

가장 이상적인 것은 공동의 임무에 대해 합의하고, 공동의 비전에 소유권을 갖고, 그리고 얼마나 걸릴 것인지, 얼마나 비용이 들 것인지를 예측하지 않으면서 우수한 소프트웨어를 제작하기 위해 함께 일하는 것이다. 해결할 수 있는 크고 유의미한 문제, 만들 수 있는 정교한 솔루션에 대해서만 상상한다.

그러나 이런 방식은 비즈니스 환경에서 거의 현실적이지 않다. 예산 및 일정과 관련해 실용적 타협을 해야 한다. 이런 타협에서 핵심은 예측을 완벽히 배제하지 않는 대신 예측을 상호 신뢰의 문화 속의 대화로 바라보는 것이다.

제품 및 엔지니어링팀은 시작 시, 그리고 소프트웨어 개발 수명 주기의 전 기간에 걸쳐 개방적이고 솔직하게 대화해야 한다. 대화는 모두가 시간과 예산에 맞춰 중요한 문제를 해결하는 데 관심이 있고, 최선을 다할 것임을 전제로 한다. 예를 들면 이용할 수 있는 리소스를 가지고 우리가 달성할 수 있는 것은 무엇인가, 무엇을 언제 전달할 수 있는가, 시간과 리소스가 부족해질 때를 위한 예비 계획은 무엇인가 등의 논의에 집중하는 것이다.

이런 대화를 바탕으로 잠정적인 로드맵과 범위를 산정할 수 있다. 프로젝트가 어떻게 전개될 것인지, 완수까지 얼마나 걸릴 것인지에 관해 각 팀의 상한과 하한을 꺼내놓는 것이다. 또한, 개발이 진행될 때 대화는 계속된다.

프로젝트의 일정 측면이 예상보다 더 어려운 것으로 드러나면 일정 기능을 연기하는 방안을 논의하고, 더 단순한 솔루션을 선택하거나, 기간을 늘려 로드맵을 수정하는 것을 논의해야 한다. 개발 도중에 더 가치 있는 아이디어가 떠오르면 로드맵을 수정할 것인가, 아니라면 이를 다음 기회로 미룰 것인가와 같은 논의도 가능하다. 팀 내 혹은 팀 간의 관계가 건전하면 이런 대회는 항상 일어나고 한층 가치 있는 솔루션으로 이어진다.

정리하면, 무가치한 예측이 프로세스와 툴을 통해 지배할 때 이런 변화는 모두 예측을 빗나간 실패로 여겨진다. 그러나 실제로 실패는 예측 자체에 있다. 좋은 사람과 팀이 최선을 다할 것이라고 신뢰할 때 생성되는 더 큰 가치를 인식하는 데 실패한 것이다.

마감 시한과 티켓 대신에 임무와 비전을 가지고 조직을 운영할 수 있다. 모든 협업은 대화이며, 모든 프로젝트가 사전에 완벽하게 계획될 수 없고, 그래서도 안 되는 탐험의 여정임을 인식하고 수용해야 한다. 우리의 삶과 마찬가지로 엔지니어링에서 좋은 일은 시작하기 전에 계획한 것이 아닌 경우가 종종 있다. 앞으로 나아가면서 발견하는 것들 말이다.
editor@itworld.co.kr
 Tags 엔지니어링 예측
Sponsored

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.