Code Smells 비유와 기술 부채
한국의 마틴 파울러가 되기
Kent Beck이 쓴 글 <Code “Smells”?>를 읽었습니다. 냄새나는 코드(code smells) 은유는 리팩토링을 아는 개발자라면 쉽게 받아들일 내용입니다. 그런데 리팩토링 맥락이 아니라 경제성을 맥락으로 설명하는 글을 보면서 흥미를 느끼게 되었습니다.
돈으로 설명하는 코드 품질
이런 식의 표현을 경제성의 맥락으로 쓴 글이라 생각합니다.
Sometimes code works but it will be hard to understand and safely change later. The code makes money by working but loses (future) money by being hard or unsafe to change.
요청에 따라 프로그램을 만들고 돈을 버는 사람들을 개발자 혹은 프로그래머라고 부릅니다. 그래서 작동하는 코드를 만들어서 돈을 번다고 할 수 있습니다. 코드를 추가하는 시점에서 당장은 그렇게 돈을 벌지만 나중에 바로 그 코드 때문에 수정이 어려워지면 돈을 잃는다고 할 수 있을까요?
당장 돈을 내놓아야 하는 일은 아닙니다. 하지만, 기회를 잃는다는 점에서 비용으로 생각할 수 있습니다. 이런 코드들로 쌓인 기회의 손실을 부르는 말이 있습니다. 바로 '기술 부채'입니다. 그런 생각을 떠올리다가 머릿속에 다음 그림이 그려졌습니다.
효용 가치가 있는 그림(혹은 생각)일까요?
수정의 용이성을 판단할 수 있는 방법
한편, 저는 아래 문장에 대한 이해도에 따라서 개발자를 나눌 수도 있다고 생각합니다.
Some programmers don’t distinguish between code that works and is easy to change and code that works and is hard to change. “It works, that’s all that matters.” Working now and changing later both matter, are both ways programmers create value. Only creating half the potential value is wasteful.
수정이 쉬운 코드인지 여부는 어떻게 알 수 있을까요? 프로그램을 구조화해 본 경험을 가진 개발자만이 그런 일이 가능합니다. 구조화란 같은 기능을 하더라도 다시 말해 결괏값이 같더라도 내부 구성을 바꾸는 일을 말합니다. 이미 이와 관계된 글을 쓴 기억이 있습니다.
제가 쓴 글인 <개발자가 테스트를 보는 세 가지 관점>에 보면 TDD를 테스트를 매개로 문제를 정교하게 정의하는 일이라는 주장 했습니다. 이 글을 본 조환 님은 TDD가 아니라 Kent Beck이 아예 'Spec(명세) 주도 개발'이라고 명했으면 좋겠다는 말을 한 일이 있습니다. 테스트 케이스가 구조화를 돕은 매개(도구)가 되어 줄 수 있다는 믿음이 둘 사이에 깔려 있으니 가능한 대화였습니다.
기술 부채는 낮은 코드 품질에 대한 것이 아니다
TDD가 아니더라도 그러한 구조화 경험과 방식이 없다면 그 개발자는 경력과 무관하게 '기술 부채'를 알더라도 어떻게 대처해야 할지 모를 것입니다. 이들에게 가능한 해법은 이런 발언입니다.
처음부터 다시 개발해야 해요.
다 갈아엎어야죠.
틀린 말은 아니지만, 방법적으로는 비효율적이고 대개는 고통을 수반하죠. 이렇게 생각을 끌어오니 예전에 썼던 글 <기술 부채는 낮은 코드 품질에 대한 것이 아니다>편을 찾게 됩니다. 그리고, Vaughn Vernon의 기술 부채는 코드 품질만의 문제가 아니고 도메인에 대한 부족한 이해 속에서 결과만 만든 대가라는 주장을 다시 만납니다.
냄새가 나도 당장 먹을 수는 있지만...
다시 Kent Beck의 글로 돌아가 보겠습니다.
To teach the difference between these 2 situations, my friend Massimo Arnoldi used the analogy of “smell”. Food might still be okay to eat if it smells bad but smelling bad is a warning. It’s also a warning of future problems. If it smells bad today it is going to be poison tomorrow.
그의 친구 Massimo Arnoldi의 "냄새" 비유에 대한 멋진 설명을 DeepL 도움을 받아 번역해 봅니다.
음식의 냄새가 나쁘더라도 먹어도 괜찮을 수 있지만, 냄새가 나쁘다는 것은 경고입니다. 또한 미래의 문제에 대한 경고이기도 합니다. 오늘 냄새가 나쁘면 내일은 독이 될 수 있습니다.
절묘한 비유입니다. 개발자는 작업 후에 찜찜함을 느끼거나 불안감을 가질 수 있지만 언제부터 큰 탈이 날지 알기 어렵습니다. 이런 점을 고려하면 코드에 유통 기한이 쓰여 있으면 좋겠다는 생각이 듭니다. 그런데 코딩이라는 것이 본래 개발자라는 사람에 의해 작위적으로 경계가 나뉘는 일입니다. 게다가 필연적으로 다양한 요인에 의해 영역이 분리되는 성질을 갖고 있습니다.
그래서 앞서 머릿속에 그렸던 그림은 확실치 않지만 효용 가치가 있을 듯하다는 생각이 들게 됩니다. 주관적 징후나마 기술 부채를 바라보는 표식이나 세분화된 인식 기록이 있다는 사실만으로도 기술 부채 관리 수준은 높아질 듯합니다.
'관리 수준'이라는 표현을 썼는데, 실행해 본 일은 아닌지라 조만간 작더라도 적용해 보고 효용성이 확인되면 생각을 실천방안으로 바꿔봐야겠습니다.
