Tidy First ?
이 글에서는 켄트 벡의 "Tidy First?"를 통해 코드 정리 시점을 경제학적 관점에서 고찰하고, 효율적인 개발 방식을 제안합니다.
Contents
들어가며
이 책의 제목을 읽고, 코드 정리의 중요성에 대해 설명하는 책으로 예상했습니다. 이러한 저의 예상은 절반 정도만 맞는 예상이었습니다. 책 제목인 Tidy First ? 는 청유가 아니라 의문형 문장입니다. 이 책의 주제는 코드 정리 시점은 언제로 정해야 할까? 라고 생각합니다. 즉, 경우에 따라서는 코드를 영원히 수정하지 않는 것이 가장 합리적인 판단일 수 있다는 사실을 암시해 줍니다. 이러한 사실은 저에게 꽤나 큰 신선함으로 다가왔습니다.
이러한 사실에 충격을 받았던 이유를 곰곰이 생각해 보았습니다. 저는 저도 모르는 사이에 스스로 프로그래밍에 대한 이상과 현실을 나누고 있었습니다. 지금보다 연차가 낮았던 때에는, 현실의 프로그래머들이 좇아야 할 이데아가 존재한다고 믿었습니다. 개발자들은 이상적인 코드라는 이데아를 끊임없이 추구하며 살아야 한다고 생각했습니다. 저는 그 중에서도 리팩터링과 코드 정리를 가장 민감하게 생각했던 것 같습니다. 당시 저는 팀에서 운영하던 레거시 시스템으로 많은 스트레스를 받고 있었습니다. 당시 저의 가장 큰 목표는 레거시 시스템 개편이었고, 자연스럽게 리팩터링 과 같은 책들을 읽고 시스템을 고쳐나갔습니다. 보이스카우트 규칙 을 지키지 않는 것을 죄로 여기기도 하였습니다.
돌이켜보면, 이 때에 프로그래밍 실력이 많이 늘었던 것 같습니다. 수많은 코드들을 리팩터링 하기 위해서는 좋은 코드가 무엇인지 스스로 공부해 나가야 했습니다. 디자인 패턴들을 찾아 공부하고, 이를 실무에서 어떻게 적용할 수 있는지 많이 고민했습니다. 하지만 그와 동시에 "좋은 코드"에 매몰되어 더 중요한 가치를 놓치고 있던 시기였던것 같습니다. 저는 사용자와 회사의 이익을 위해 코드 정리를 하는 것이 아니라, 개발자로서의 만족을 위해 코드 정리를 했던 적이 많았습니다.
프로그래밍은 점점 하면서, 저는 이러한 고집을 조금씩 내려놓고 현실과 타협(?)을 종종 하게 되었습니다. 때로는 제품의 빠른 출시를 위해, 때로는 매출의 빠른 성장을 위해, 때로는 팀의 갈등을 막기 위해 타협을 하였습니다. 하지만 가끔씩은 개발자로서의 지켜야 할 양심이 파괴되는 듯한 기분이 들기도 했습니다. 이러한 과정들 사이에서, 제가 옳은 선택을 한 것인지 혼란스러운 지점들이 많았습니다.
켄트 벡의 Tidy First ? 는 이러한 저의 고민을 경제학적 관점에서 깨뜨려준 책입니다. 코드 정리는 필요한 경우가 많지만, 그것을 올바른 시기에 하는 것이 좋습니다. 켄트 백은 경제학적으로 코드 정리를 할 때의 편익이 비용보다 더 클 때 행하라고 주장합니다. 그렇다면 코드 정리의 편익과 비용은 어떻게 알 수 있을까요 ? 이 비용을 돈과 같이 정확히 측정할 수는 없을 것입니다. 하지만 경제학은 본질적으로 더 나은 선택을 위한 학문입니다. 우리는 다음과 같은 관점에서 소프트웨어 코드 정리의 시점을 가늠해 볼 수 있습니다.
오늘의 만원이 내일의 만원보다 값지다
오늘의 만원이 내일의 만원보다 가치가 큽니다. 왜 그럴까요 ? 먼저 내일의 만원은 오늘 사용할 수 없습니다. 다음으로, 오늘 만원을 받는다면 다른 부분에 투자를 하여 만원보다 더 높은 가치로 불릴 수 있습니다. 물론 잘못된 투자로 손해를 볼 수도 있지만, 오늘 선택할 수 있다는 점이 중요한 점입니다. 마지막으로, 내일 만원을 받지 못하게 될 가능성이 있기 때문에, 오늘 만원을 미리 받아두는 것이 안전합니다. 즉 돈을 받을 수 있다면 미리 받고, 돈을 내야 한다면 최대한 미루는 것이 낫습니다.
그런데 이것이 소프트웨어 개발과 무슨 관련이 있을까요 ? 비즈니스적인 관점에서 보았을 때, 기능 개발은 돈을 버는 것과 관련이 있고, 코드 정리는 비용을 지출해야 하는 경우가 많습니다. 소프트웨어 개발에 있어서 가장 큰 비용은 시간입니다. 정리하면, 비즈니스적인 관점에서 보았을 때, 기능 개발을 위해 많은 시간을 투자하고, 코드 정리는 꼭 필요할 때에 하는 것이 합리적입니다.
옵션은 변동성이 클수록 값지다
위의 내용을 바탕으로 생각해 보면, 기능 개발이 코드 정리보다 항상 앞서야 할까요 ? 대부분의 개발자들이 느끼듯이, 항상 그런 것이 진리는 아닙니다. 클린 코드에서도 말하듯이, 냄새나는 코드가 많아질수록 소프트웨어 개발의 비용도 늘어나기 때문입니다. 또한 코드 정리는 경제학적으로 더 많은 가치를 창출해내기도 합니다. 켄트 백은 금융 상품인 옵션을 통해 이를 설명합니다. 옵션의 가치는 변동성이 큰 시장에서 더 값집니다. 상품의 비싸지면 콜 옵션을 행사하여 구매하면 되고, 상품의 가치가 떨어지면 옵션을 행사하지 않으면 되기 때문입니다.
옵션을 코드 정리에 빗대어 생각해 볼 수 있습니다. 올바르게 코드 정리를 한다면, 변경에 용이한 형태로 코드의 구조가 변경됩니다. 만약 코드 변경의 가능성이 없는 시스템이라면, 굳이 옵션을 구매하지 않아도(코드 정리를 하지 않아도) 문제가 없습니다. 하지만 만약 변동성이 큰 시스템이라면, 코드 정리를 통해 설계의 선택지를 넓히는 것이 좋습니다.
켄트 백은 현금흐름할인과 옵션 개념을 통해 기능 개발과 코드 정리의 균형에 대해 설명하였습니다. 하지만 두 개념은 충돌하는 듯 보입니다. 현금흐름할인의 입장에서 보면, 코드 정리는 꼭 필요할 시점이 되기 전까지 미뤄야 합니다. 콜옵션의 개념에서 보면, 코드 정리를 통해 변동에 유연한 시스템을 만들어야 합니다. 그렇다면 우리는 실질적으로 어떠한 선택을 해야 할까요 ? 단순하게 생각하면, 편익이 비용보다 클 때에 코드 정리를 하면 됩니다.
비용(코드 정리) + 비용(코드 정리 후 동작 변경) > 비용(바로 동작 변경)
위의 등식이 성립할 때가 바로, 코드 정리를 해야 할 시점입니다.
그렇다면 엔지니어의 관점에서, 코드 정리를 통해서 얻을 수 있는 가장 큰 편익은 무엇일까요? 바로 코드 간의 결합도 를 제거할 수 있다는 사실입니다. 하지만 슬프게도, 한 종류의 코드 변경에 대한 결합도를 줄일수록 다른 종류의 코드 변경에 대한 결합도가 커지는 경우들이 종종 있습니다. 즉, 코드 정리는 항상 코드를 깔끔하게 만들어준다는 편견을 버리고, 적당한 수준으로 코드 정리를 하는 것 또한 중요합니다.
위의 관점들에서 살펴보았듯이, 코드 정리는 중요하지만 그것이 1순위가 되어서는 안됩니다. 켄트 백은 코드 정리는 소프트웨어 설계의 프링글스라고 설명합니다. 뚜껑을 열고 먹기 시작하면 멈출 수 없기 때문입니다. 이 책은 코드 정리의 의미에 대해 깊게 생각하게 해 준 계기가 되었습니다. 코드 정리는 꼭 필요하지만, 그것이 필요한 시점에 행해야 의미가 있습니다. 비즈니스를 위한 소프트웨어를 만드는 엔지니어는 한편으로는 철저한 경제학자가 되어야 한다는 생각도 들었습니다. 앞으로는 코드를 조금 다른 측면에서 바라보게 될 것 같습니다.
이것도 읽어보세요