글로벌 칼럼 | SW 개발 ‘속도’ 집착이 모든 것을 망치고 있다

지속적 배포(Continuous Delivery, CD)가 지배하는 세계에서 빈번한 개발 버전 릴리스는 일상이 됐고, 대부분 기업은 거의 매일 제품을 업데이트한다. CI/CD 파이프라인은 클라우드와 첨단 자동화 기술의 도움과 보안 및 품질에 대한 우려 속에 번성하고 있다. 문제는 속도가 이런 엔지니어링 팀의 성공을 측정하는 지배적인 지표로 굳어지고 있다는 사실이다. 결과적으로 사람과 프로세스, 제품 가치는 뒷전이 됐다. 
 

엔지니어링 속도를 유일한 지표로 사용할 때 우리가 놓치는 것은 무엇일까? 그 좁은 시야 바깥에서는 무슨 일이 일어날까?
 

어둠 속의 소프트웨어 개발 

스크럼의 부상과 함께 스토리 포인트 속도는 민첩한 소프트웨어 개발 수명 주기(SDLC)를 이끄는 주된 동력이 됐다. 이번 주에 팀이 완료한 스토리 포인트는 몇 개인가? 허용 기준을 충족하면서 더 많은 포인트를 전달하도록 하려면 어떻게 해야 할까? 모두 속도가 성공과 동의어로 취급되고 가속은 성공적인 엔지니어링 기업이 가장 중점을 두는 단어다. 더 많은 스토리 포인트를 전달한다는 것은 “일을 제대로 하고 있다”는 확실한 신호라고 보는 것이다. 

나름의 논리도 있다. 경영진 관점에서 출시 시기를 놓친 제품은 아무리 완벽해도 별 가치가 없다. 공학적인 천재성의 결정체라 하도 비즈니스 가치를 거의 또는 아예 창출하지 않는다면 “업계의 게임 체인저”가 아닌 “박물관 전시품”일 뿐이다. 출시 시기는 실제로 중요하다. 출시 속도가 5% 개선되면 ROI가 13% 증가한다는 연구 결과도 있다. 

그러나 필자는 속도에 대한 맹목적으로 집착하면 소프트웨어 솔루션의 실질적 영향을 최적화하는 데 중요한 여러 가지 요소를 놓치게 된다고 생각한다. 오로지 속도에만 집중할 때 우리가 묻지 않는 다음과 같은 질문을 생각해 보자. 
 

• 제품 사양이 적절히 작성되었으며 팀이 제품을 제공하고자 하는 방식과 조화를 이루는가? 
• 목표한 비즈니스 문제에 맞는 올바른 솔루션을 구축하고 있는가? 
• 향후 코드를 다시 쓰는 일을 피할 수 있도록 고품질의 코드를 제작할 수 있는가? 
• 처음부터 테스트 기반으로 코드를 작성해 리팩터링을 간소화하고 요구사항을 문서화할 수 있는가? 
• 얼마나 많은 기술적 마찰이 다음 반복으로 전달되는가? 
• 시스템이 안전하고 안정적이며 즉시 확장 가능한가?  

물론 속도와 품질은 모두 중요하다. 그러나 지금 엔지니어링 팀 전반에서 나타나는 속도 지표에 대한 집착은 모든 면에서 나쁜 습관을 조장할 뿐이다. 또한 대부분은 같은 지표 기반의 제공 평가에 대한 책임을 개발 주기의 모든 단계에 걸쳐 공정하게 묻지 않는다. 일반적으로 제품 팀은 속도를 기준으로 평가받지 않으며 제품 파이프라인의 여러 부분이 엔지니어링 지연에 대해 연대해서 책임을 지지도 않는다. 
 

지표가 놓치는 것 

사실 제품 사양의 속도를 측정하기는 어렵다. 일반적으로 제품 개발은 실험과 반복이 필요한 프로세스이고 나아가 예술적인 영역도 일부 포함되는 것으로 인식된다. 필자는 소프트웨어 엔지니어링도 마찬가지라고 생각한다. 엔지니어링 팀에 티켓을 발행하는 속도로만 제품 팀을 평가한다면 분명히 터무니없는 일일 것이다. 

제품 팀은 어느 시점이 되면 티켓을 생성하기 시작하는데, 이런 티켓이 올바르게 형성되고 팀에 의해 적절히 처리될 수 있는지를 나타내는 실질적인 지표는 없다. 가용한 시간 내에 현실적으로 그 티켓을 완료할 수 있는지에 대한 평가도 없다. 이런 작업에는 예상치 못한 이상 현상, 난관 및 지연에 대처하기 위한 백업 계획이 포함돼야 한다는 요구사항도 없다. 

엔지니어는 티켓을 처리하고 코드를 만들어 배포한다. 엔지니어의 생산성 평가에서 측정하는 속도가 바로 이 배포 속도다. 이 주기 안에서 제품 팀이 무심코 간과했거나 무시하고 넘어간 잠재적인 충돌이나 중요한 요구사항의 일부 티켓을 엔지니어링 팀이 넘겨받을 수 있다. 그러나 그 시점이면 엔지니어는 출시 날짜 또는 예상된 일정표에 맞춰 작업 중이고 속도에 따라 평가를 받는다. 속도는 KPI이므로 문제 해결 티켓에 소비되는 시간이 늘어나면 궁극적으로 팀의 전체 성과를 갉아먹게 된다. 

예를 들어 엔지니어만 알아볼 수 있는, 제품 측면에 대한 잘못된 이해에서 비롯된 요구사항이 있는 티켓을 받아서 그 사실을 파악하는 데 20분을 소비한다고 가정해 보자. 그 시간은 기능 테스트를 작성하거나 프로젝트를 진전시키는 뭔가를 개발하는 데 사용할 수도 있었던 귀중한 시간이다. 또한 이미 상당한 코딩 시간을 소비하고 나서야 티켓이 잘못되었다는 것을 깨닫는 경우도 종종 있다. 

20분 또는 오후의 반나절 정도는 타임라인 측면에서 큰 문제가 되지 않을 수도 있다. 그러나 여러 번 이런 문제가 반복되면 어느 순간 낭비한 시간을 메우기 위해 허겁지겁 애쓰게 되고 그 과정에서 점점 더 많은 '제품 부채(product debt)'가 발생하게 된다. 
 

잘못된 의사 결정 유도 

불완전한 티켓과 속도 기반의 KPI가 결합되면 엔지니어링 측면에서 나쁜 습관이 형성된다. 마감 기한이 유일하게 중요한 지표이고, 엔지니어는 앞으로 나아가기 전에 티켓부터 처리해야 한다면 결승선을 향한 경주에서 개발 측면은 처음부터 불리한 상태에 처하게 된다. 결과적으로 코딩은 부실해지고 결함은 만연하고 기술 부채는 프로젝트 품질을 끌어내린다. 성급한 제품 구성으로 인해 앞으로 새로운 기능을 추가하기 더 어렵게 되고, 악순환은 더 단단히 굳어져 반복된다. 단지 '시간만' 지켰을 뿐이다.

소프트웨어 엔지니어가 끊임없이 시간의 압박을 느끼고 최선의 작업을 하지 못하고 자신이 통제할 수 없는 지표에 쫓기는 환경은 번아웃과 빠른 이직을 유발한다. 개발팀, 그리고 업계는 지금이나 미래에나 뛰어난 인재를 이렇게 계속 잃는 상황을 감당해야 한다. 미국 노동 통계청에 따르면 소프트웨어 개발자에 대한 수요는 2021년부터 2031년 사이 25% 증가할 전망이다. 지금은 가장 귀중한 직원의 의지력을 테스트하거나 그들을 어디까지 몰아붙일 수 있을지 시험할 때가 아니라는 뜻이다.
 

닭이냐, 돼지냐 

모든 애자일 소프트웨어 개발 수명주기(SDLC)에서 문제 해결은 프로세스의 핵심적인 부분이다. 또한 개발의 결과물이 완벽하지 않을 것임은 누구나 아는 사실이다. 그래서 후속 테스트 단계가 있는 것이다. 그러나 티켓 품질과 관련된 KPI가 없으면 제품 팀은 프로세스를 재검토할 동기가 거의 없으므로 시스템은 계속해서 불필요한 쓰레기를 생산하고 그로 인해 엔지니어링 팀은 시간에 쫓겨 허덕이게 된다. 

스크럼에서 닭과 돼지의 우화는 이 역할의 차이를 잘 보여준다. 조리 과정에서 닭은 관여하는 정도지만 돼지는 모든 것을 걸어야 한다. 제품 팀은 좋은 요구사항, 나쁜 요구사항, 일반적으로는 그 중간 정도의 요구사항을 제시한다. 불완전성은 필연적이고 반복도 피할 수 없다. 그러나 일정이 계획을 벗어나게 되면, 심지어 최종 결과물이 더 가치 있는 솔루션이라도 해도 프라이팬 위에 올라가는 것은 엔지니어링 팀인 경우가 많다. 

속도가 협업과 품질 보증을 위한 중요한 순간에 방해가 되는 경우가 많음에도 불구하고 흔히 소프트웨어 개발의 유일한 진리처럼 간주되는 이유는 무엇일까? 제품 팀과 엔지니어링 팀은 기계적으로 티켓을 만들고 받고 실행할 것이 아니라, 서로 소통하면서 진정 효과적인 솔루션을 개발하는 데 필요한, 타협과 양보를 포용해야 한다. 여기에는 일이 티켓 계획대로 진행되지 않을 경우를 위한 충분한 대비도 포함된다. 
 

탓하지 않고 전진하기 

그래서, 잘못된 티켓에 대한 더 엄격한 징계가 필요하다는 말인가? 전혀 아니다. 제품 팀은 더 가치 있는 솔루션을 구축할 수 있도록 유예와 유연성이 주어져야 한다. 

소프트웨어 개발은 인간에 의해 인간을 위해 수행되는 과정이자 일종의 예술이다. 기계적인 속도에 대한 고집은 가능한 한 최상의 솔루션을 만드는 데 필요한 창의적 사고와 반복을 가로막는다. 발전은 선형적이고 예측 가능한 경로를 따르지 않는 경우가 많다. 접근 방식이 효과적이지 않으면 다시 돌아가서 다른 아이디어를 시도해야 한다. 이런 과정을 통해 조금 더 시간이 걸리더라도 더 많은 가치를 창출하는 더 좋은 방법을 찾을 수 있다. 어느 정도 숨돌릴 여유가 필요가 있는 것도 이 때문이다.

그러나 더 중요한 점은 제품 및 엔지니어링 팀이 개발 프로세스와 회고 과정에서 모두 더 긴밀하게 협력해서 긍정적인 결과와 지속적인 개선을 위해 협업해야 한다는 것이다. 사전에 더 적극적으로 커뮤니케이션하면 두 팀 모두 기능적 요구사항에서 코드화된 현실로의 전환을 다듬을 기회를 얻게 되므로 장기적으로 많은 시간을 절약할 수 있다. 

“탓하기 없는” 사후 검토의 원칙도 잊으면 안 된다. 책임 공유가 없으면 조직은 특정 스프린트에서 무엇이 잘못되었는지 섬세하게 이해하고 그다음 단계로 나아갈 수 없다. 탓하기 없는 문화에서는 누구의 “잘못”이든 관계없이 두 팀이 함께 문제가 발생한 이유가 무엇인지 분석해 상황의 전체적인 복잡성을 파악하고 앞으로 어떻게 수정해야 할지를 알아낸다. 물론 엔지니어링 팀이 작업의 효율성을 높여야 하는 경우도 있다. 그러나 제품 팀 역시 티켓의 지속적인 개선을 위해 반복적인 노력이 필요할 수 있다. 
 

모두가 협력 

속도와 같은 지표는 개발팀의 성공을 평가할 척도로는 적합하지 않다. 사실 이런 지표는 제품을 만드는 잘못된 길로 이끈다. 올바른 방법은 제품과 소프트웨어 개발 기능 두 영역에 걸쳐 신중하고 협력적으로 만드는 것이다. 속도가 전부가 아니다. 성공의 진정한 척도는 비즈니스 가치, 즉 제품 소유자가 엔지니어링 팀과 함께 정의한 가치와, 엔지니어링 팀이 그 가치를 전달하는 것, 두 가지의 조합이다. 

전제에 의문을 제기하고 가능성의 한계를 시험하는 대담한 제품 팀과, 그런 유형의 과제를 받아들이는 엔지니어링 팀이 없다면 우리는 아무런 목표도 달성할 수 없다. 이 두 그룹이 위험을 감수하고 역량의 한계를 시험하면서 최선의 역량을 발휘하도록 해야 한다. 제품 팀과 엔지니어링 팀이 협력해야만 위기를 돌파하고 예상을 뛰어넘고 경쟁에서 앞서나가는 고품질의 혁신적인 소프트웨어를 만들 수 있다.
editor@itworld.co.kr