구축 사업 관리에 가려진 기술 부채
베터코드 인사이트의 시작 10편
<린 분석> 읽기 모임에서 지인들과 대화는 많은 영감을 준다. 그중에서 SI 기업에서 아키텍트 일을 하는 지인과 토론 과정이 매우 흥미로워 8월에 메모해 둔 일이 있다. 요즘 '기술 부채'에 대한 이야기를 하면서 SI 사업의 핵심 지표에 대해서 다른 시각으로 볼 수 있다는 생각에 메모를 다시 열어보고 글로 써본다.
SI 사업과 핵심 지표(KPI)
최초의 토론은 우습게도 내가 지인의 말을 오해하면서 시작되었다. SI 사업에서는 측정을 제대로 하지 않는다는 뜻으로 오해해 나는 반론을 했다. 내 반론은 대충 이런 식이었다.
SI에서 사업 수익성을 지나치게 강조하는 반면에 (코드) 품질이나 기술적 측면이 무시되는 것이 문제라 생각한다. 오히려 사업 성과에 대한 측정은 무엇보다 중시되는 모습이었다.
10 년이 더 지난 경험에 기초했지만, 전해 들은 SI 업계의 관행은 크게 바뀌지 않았다고 들었다. 또한, SI 업계 기술 임원과 근래 대화에서 아직도 투입공수(Man-Manth) 외에 중요하게 부각되는 지표가 없다는 대화를 했던 일도 떠오른다.
우리는 기술부서라 평가 안전지대
지인의 말은 회사가 아니라 부서나 직무에 대한 이야기였다. 회사는 평가가 엄격하지만, 기술부서에 대해서는 관리자들의 인식의 한계로 평가에 대해 의무감이 적다는 말이었다. 나는 바로 이해를 할 수 있었다. 지표화 할 수 없는 어려움을 극복하려는 기술 임원과의 대화가 그 문제에 대한 인식이었기 때문이다.
그리고 <XP 함께 읽기> 논의 일부가 떠올랐다. 지인이 말한 현상 바탕에는 이른바 테일러주의가 있다는 확신이 들었다.
찾아보니 XP Explained에 아래와 같은 내용이 나온다. 직접적인 연관이 있어 보이는 내용이다.
테일러주의식 사회공학의 두 번째 단계는 품질 부서를 따로 두는 것이다. 테일러는 작업자들은 할 수만 있다면 언제나 '꾀를 부린다' (느리게 일하거나 형편없이 일하지만...) <중략> 품질 부서를 따로 두는 일은 우리가 품질을 정확히 공학이나 마케팅이나 판매만을 중요하게 여긴다는 메시지를 전달한다. 그러나 그렇게 하면 공학 부서의 누구도 품질에 대해서는 책임을 지지 않게 된다
지표란 무엇인가?
오해의 저변에는 지표에 대한 서로 다른 이해가 깔려 있다고 생각한다. 보통 지표라고 하면 핵심 성과 지표(Key Performance Index)를 뜻한다. 하지만, 지표에 대한 서로의 경험과 이해가 매우 달랐다. 조직 생활을 오래 하신 분들의 특성은 지표에 대해 부정적인 경험을 갖는 분들이 많다는 점이다.
지표는 아키텍처와 아주 다른 주제이지만, 이런 경험을 들을 때 내가 떠올리는 느낌을 문구로 바꾸면 <아주 이상적인 아키텍처>편에서 만든 문단 제목이 떠오른다.
권력 구도로 인해 소통이 어려운 환경
그리고 통계학을 전공하고 기업에서 분석 업무를 하는 지인이 갈망하는 것이 바로 시장을 사실에 가깝게 반영한 사업 모델을 통해 분석하고 지표를 도출하는 일이라는 점을 지속적으로 느꼈다. 그런데, 왜 많은 기업이 그렇게 하지 못할까?
구축 사업 관리에 가려진 기술 부채
바로 위 문장은 8월의 나의 고민이었다. 그러나, 기술 부채 관련 발표를 하고 나서 다시 보니 느낌이 달랐다. 업계에서 장기간 풀 수 없는 문제로 보고 덮어둔 문제가 업계를 망가트리고 있는지도 모른다. <폭포수 방식 설계는 기술 부채를 남긴다> 편을 보면 대금 수령 문제로 인해 기술 부채가 당당하게(?) 입지를 굳힌다. 엔지니어 입장에서는 황당한 일이지만, 아주 오랫동안 관행으로 굳혀졌다.
엔지니어는 프로젝트 수행 방식 자체에 대한 의사결정 권한이 없다. 그들은 맨먼스를 구성하는 자원으로 취급될 뿐이다. 그러나, 계획을 잘 세운다고 해서 시스템의 품질이 높아질까? 구축 계획은 PM이 세우고, 개발은 개발자가 알아서 하는 분업이 효과적이지 않다면 더 나은 협업 방법을 찾아야 한다.
<건강한 조직이 만들어지는 배경> 편에서 그린 도식을 떠올려본다. 시스템의 최종 모습에 대해서는 능력을 보유한 개발자(혹은 엔지니어)에게 권한을 주고 정보를 요구해야 한다. 이를 통해서 PM의 부족한 능력을 채우는 일이 바로 스타들로만 구성된 축구팀을 평범한 축구팀이 이기는 조직력이다.
나는 (네카라쿠베가 아닌 회사라면) 기술 부채 문제가 충분히 어려운 문제라고 믿고 있다. 그래서, 문제 정의를 다시 하고 조직 차원에서 조직적으로 푸는 방식을 주장하는 중이다.
지난 베터코드 인사이트의 시작 연재
3. Funnel을 마케팅 말고 engagement 분석에?
5. 기술 부채는 무엇인가?
