기술 부채를 Code Smell로 관리할 수 있는가?
한국의 마틴 파울러가 되기
지난 글 <Code Smells 비유와 기술 부채>를 쓰면서 연쇄적으로 생각이 이어졌습니다. 생각을 정리할 겸 글을 씁니다.
사업 관리의 진행 단위와 제품이 쓰이는 방식의 불일치
생각의 확장에 영향을 준 두 사건이 있습니다. 먼저, (외주 프로그램 개발) 사업 관리 관점에서 공수와 타당성에 대한 논의를 하는 과정에서 느낀 불편함이었습니다. 왜 불편했을까요? 사후에 생각해 보면 합리적인 행동은 아니었다는 반성을 하게 됩니다.
사업 관리 관점에서 대가의 적정성은 투입한 용역 대금에 대한 정당성만 다룹니다. 상대방이 이를 벗어난 논의로 이야기를 끌어갈 때 피로감이 밀려왔다는 생각이 듭니다. 이런 피로감을 다스려야 할 시점에 아주 우연하게도 <떨림과 울림>에서 관련한 내용을 읽고 있었습니다.
우선 사업 관리 관점에서 기능 점수 등의 방법으로 치밀하게 공수산정을 하는 방법은 환원주의를 닮았습니다.
대상을 쪼개어 부분으로 나눈 다음, 이들로부터 전체를 이해하려는 방법을 '환원주의'라고 한다.
사업관리는 시스템의 효용 가치를 알지 못한다
환원주의는 굉장히 유용하지만, 모든 것을 설명할 수는 없습니다. 그 역시 한계를 가집니다. 이에 대한 <떨림과 울림>의 문구를 인용합니다.
양자역학은 이들 원자를 완벽하게 기술한다. 하지만 아무리 원자 각각을 들여다본들 소화불량이 무엇인지 알아낼 방법은 없다. <중략> 세포들이 모여 위장이 되는 과정에서 무엇인가 본질적인 변화가 일어났다는 뜻이다. <중략> 입자물리나 양자역학에서 위장을 바로 설명할 수는 없다. 위장이 원자들의 집합인 것은 맞지만 위장의 기능이나 성질을 원자로부터 이끌어내는 것은 불가능하기 때문이다. 원자가 많으면 뭔가 달라진다.
제가 '사업 관리'라고 부르는 일은 외주 개발을 뜻하기 때문에 사실 시스템이 어떻게 쓰이느냐를 다룰 수가 없습니다. 이러한 깨달음(?)은 이미 10여 년 전에 외주 개발 사업을 하면서 동시에 릴리즈와 운영에 참여했던 경험을 소환합니다. 이러한 맥락의 노력은 <개발의 시장 가치 측정을 위한 첫 발을 떼다>에 담겨 있습니다.
환원주의를 빌려와 설명하고자 한 부분은 개발자가 프로그램을 만들어 가는 순서 그리고 그 구성은 시스템이 사용되는 순서 그리고 구성과는 다르다는 사실을 분명하게 하려 한 것입니다.
기술 부채를 Code Smell로 관리한다는 말은 무슨 의미인가?
한편, 환원주의의 한계는 기술 부채에 대한 지난 글에서의 생각에 대해서도 시사하는 바가 있습니다. 아래 그림을 떠올린 후에 효용 가치를 따져 물은 일이 있습니다.
환원주의 관점에서는 말이 되지 않습니다. 냄새나는 코드를 모두 제거하면 기술 부채가 해결된다고 볼 수 있을까요? 총체적으로 그럴 수는 있지만, 냄새나는 코드를 모두 식별하는 일 자체가 인수분해 하듯이 할 수 있는 일이 아니란 생각이 듭니다.
하지만, 지난 글에서 다음과 같이 결론을 내린 이유는 환원주의적 관점이 아니었습니다.
주관적 징후나마 기술 부채를 바라보는 표식이나 세분화된 인식 기록이 있다는 사실만으로도 기술 부채 관리 수준은 높아질 듯합니다.
<현실과 시스템의 불일치, 그리고 UX의 역할>의 다음 그림처럼 두 개의 다른 세계를 인정하고 느슨하게 해결하는 방법을 '관리'라고 불렀다 할 수 있습니다.
예를 들어 자원 활용을 결정하는 ART 기구의 결정이 관리 관점을 대표합니다. 이때, 기술 부채 해소를 위해 (아마도 개발자인) 구성원이 제안한 Code Smell을 후보로 올려두고 논의를 하고 합의에 도달하면 기능을 추가하는 대신에 이를 제거하는 것을 상상했습니다.
'처음부터 다시 개발해야 해요.'와 같은 식의 발언 대신에 Code Smell을 항목화 해서 관리 대상으로 식별하는 일은 굉장히 유용한 일이란 생각이 듭니다.
빠른 적용과 실천 착수
어제 글을 동료와 공유하며 관리 수준과 실천 방안에 대한 논의를 했습니다. 그러다가 만들어 낸 그림입니다.
아직은 아이디어이기 때문에 이후에 실천을 한 후에 기록을 남기도록 하겠습니다.
