기술 부채는 무엇인가?
베터코드 인사이트의 시작 5편
내 주장을 말하기에 앞서 남들은 뭐라 하는지 찾아보기로 했다. 보통 위키피디아부터 보는 순서도 바꿔서 구글링부터 했다. 한국어를 쓰는 업계 사람들이 주목하는 개념이나 문제의식부터 보기로 한 것이다. 첫 페이지만 보아도 꽤 유용한 글이 많다.
당장 필요하지 않아 미룬 일로 생기는 대가
그래도 정의가 없으니 글을 쓰기 어렵다. 엄밀한 정의 대신에 구두로 내 생각을 압축한 문장을 만들었다. 당장 급한 코드만 작성하고 뒤따라해야 할 일을 미루었을 때 생기는 대가를 부채(debt)에 비유한 것이 기술 부채(Technical Debt)이다. <스크럼이 낡은 방식이긴 하다> 편에서 인용한 대로 Chris Richardson이 인용한 논문에 따르면 기술 부채에 따라 낭비되는 시간이 42%에 달한다고 한다.
미룬 일은 어떤 것들이 있을까? 나는 이에 대해 CTO 님과 논의한 일이 있는데, 듣다가 정리된 머릿속 표현은 아래와 같다.
다수 개발자들이 눈에 보이는 기능 수정만 편안히 할 수 있고,
그 외의 소프트웨어 공학적 노력은 할 여유를 받지 못한다
어떤 일들이 기술 부채를 만드는가?
구글링 첫 페이지, 그 주엥서도 첫 링크에는 8퍼센트 이호성 님의 글이 걸렸는데, 쉽게 알 수 있는 전형적인 사례가 잘 기록되어 있다.
출처: https://brunch.co.kr/@leehosung/2코드와 기술 문제에 대한 시각화
좋은 글이 많았지만 한 가지 사실이 빠져 있었다. 소통과 협업이 중요하다는 사실을 지적하는 글은 여럿 있었지만, 이를 위해서 적절한 시각화가 필요하다는 점이다. 4년 전에 <소프트웨어를 모르는 대한민국 기업의 위기> 라는 제목으로 발표할 때, 아래와 같은 슬라이드가 있었다.
출처: https://www.youtube.com/watch?v=fiY2VwKTvos시스템이나 코드가 개발자만 볼 수 있는 상태로 두면 그들에게만 의존하는 격이 아닌가? 물론, 코드 작성은 개발자의 몫이고 개발자와 그들의 팀워크가 가장 중요하다. 그래서 현실적으로는 코드 리뷰가 기술 부채를 자연스럽게 줄여나가는데 매우 중요한 역할을 한다.
문제는 아무리 개발 역량이 충분해도 개발자가 기술 부채를 줄일 시간을 확보할 수 없는 상황에서 발생한다. 코드만 봐서는 문제를 알 수 없는 의사결정권자나 PO, 기획자 등의 이해관계자에게 무엇이라 설명하고, 그들은 또 어떻게 판단하고 결정할 수 있을까? 내가 '시각화'를 언급한 이유가 그것이다. 그 문제가 무엇인지 보여야 나름의 잣대를 마련하여 결정하고 행동할 수 있다.
누구에게 무엇을 보이게 할 것인가?
4년 전에 <소프트웨어를 모르는 대한민국 기업의 위기> 라는 제목의 발표에서 소프트웨어가 경계가 보이지 않는 특성 탓에 겪는 시행착오에 대해 언급했다. 그리고 4년이 지나는 사이에 나는 현장에서 시도한 여러 가지 암묵지를 보편적인 해결책으로 만들 수 있을지 궁리하고 있다.
지난 3월에 <소프트웨어를 제품으로 만드는 길> 편에서 방향성에 대해 기록하기는 했지만, 구체화된 내용은 미미했다. 다행히 최근에 같은 문제를 고민하는 업계 동료와 교류하고, 베터코드 개발자들과 토론하는 과정에서 조금씩 가닥을 잡아 나가고 있다.
외주 개발 코드의 품질 관리 문제
시각화 대상 중에 외주 개발 프로젝트의 PM도 중요한 이해관계자다. SI 개발업을 하는 업계 핵심 기술팀에서 코드의 품질에 대해 PM(프로젝트 관리자)이 알지 못하는 문제를 시각화하는 시도가 있었고 흥미롭게 논의를 했던 일이 있다. 지인이 사내 발표를 하셨다고 하여 데모 화면을 요청했다.
아직 초기 단계라 분석의 깊이는 추가될 여지가 있겠으나 PM의 품질 관리를 위한 시각화 결과가 분명하다. 이런 지표가 없을 때는 눈에 보이는 WBS, 엑셀 기능 목록, 근태, 개발 업체 관리자의 말만 믿고 살얼음판 걷듯이 프로젝트를 관리하고 있다. 나는 이러한 시도가 PM들의 삶이 나아지는데 분명 기여를 할 것이라 확신한다.
기술 부채는 개발자의 문제만은 아니다
기술 부채의 끝은 차세대 프로젝트와 같은 전면 재개발이다. 과거에는 차세대 프로젝트가 흔했다. 프로그램을 쓰고 버리는 내용연수가 있던 시절이다. 나는 그때를 소프트웨어 산업 초기라고 부르고 있다. 지금은 그때와 많이 달라졌다. 앞으로는 소프트웨어를 구독하는 시대가 올 것이다. 흔히 SaaS라고 하는 빌려 쓰는 프로그램은 새로 개발할 수 없다. 나는 우리가 그 과도기에 있다고 믿는다.
이 시점에서 짧은 글로 분명하게 전할 수 있는 메시지는 기술 부채는 그냥 개발자에게 맡겨 두면 해결되는 일이 아니란 점이다. 그리고, 개발자들도 이 문제를 끌어안고 있지 말고 적극적으로 소통해야 한다는 말을 하고 싶다.
