소프트웨어 엔지니어들의 필독서인 클린 아키텍처를 읽고 있습니다. 다 읽진 못했고 현재는 3장을 읽고 있는데요, 분량이 많아 읽는 데 시간이 많이 걸릴 것 같으니 제가 인상깊었던 이 책의 1장부터 먼저 짧게 감상을 쓰려고 합니다.
이 책의 1장은 소프트웨어 아키텍처의 중요성에 대한 내용을 담고 있습니다. 소프트웨어의 탄생부터 시작해서 왜 아키텍처가 중요한지, 좋은 아키텍처를 설계하고 유지해 나가려는 노력을 지속하지 않으면 무슨 일이 발생할 수 있는지를 주제로 하고 있습니다. (이후로 "아키텍처"는 "구조"로 통일하겠습니다)
"왜" 좋은 구조를 짜야 하는지에 대한 답은 간단합니다. 좋은 구조로 만들어진 소프트웨어는 추가 개발이 간편해, 리소스를 적게 들이고도 유지보수할 수 있고 사이드 이펙트를 많이 발생시키지 않습니다. 어떤 개발자가 개발하더라도 간단하게 협업할 수 있습니다.
나쁜 구조가 유지되면 유지될수록, 서비스의 개발 수준에는 큰 차이가 없는데도 단순 유지보수만을 위해 수많은 개발 리소스가 필요하게 됩니다.
그런데 이 책은 "어떻게" 좋은 구조를 짜는지로 바로 넘어가는 대신, "왜" 나쁜 구조가 유지되는지에 대해 설명합니다.
좋은 구조가 좋다는 것은 모두가 압니다. 그리고 어떻게 좋은 구조를 만들지에 대한 지식도 인터넷이나 책을 찾아보면 얼마든지 알아낼 수 있습니다. 문제는 사람들이 좋은 구조의 중요성을 알고, 어떻게 좋은 구조를 만들지도 알 수 있는데도 좋은 구조를 짜려는 노력을 하지 않는다는 것입니다. 사람들은 보통 시간만 충분하다면 좋은 구조를 짤 수 있겠지만, 긴급한 개발 요구사항이 끊임없이 계속 들어온다는 이유로 좋은 구조를 짜는 것을 미룹니다.
그러나 이것은 인과관계의 원인과 결과를 착각한 것입니다. 나쁜 구조를 유지하면서 개발하면, 좋은 구조를 짜고 개발할 때보다 항상 더 느립니다. 스파게티 코드가 쌓이면서 생산성이 단축되기 때문입니다. 이는 장기적이든 단기적이든 똑같습니다.
조직 내에서 소프트웨어 개발자가 아닌 담당자는 "동작하는 것이 더 중요하니 구조 개선은 나중에 하자" 라고 얘기합니다. 이런 말에 속지 말라고 이 책은 이야기합니다. 동작하지만 변경이 점점 더 어려워지는 프로그램은 서비스를 늪으로 끌고 간다는 이야기였습니다.
저자는 좋은 구조를 위해서 싸워야 한다고 이야기합니다. 소프트웨어 개발자는 소프트웨어를 잘 관리해야 할 책임과 역할이 있고, 다른 부서가 자신들의 책임과 역할을 위해 싸우는 것처럼 개발자도 자신의 책임을 생각하고 좋은 소프트웨어를 위해 싸워야 한다고 이야기합니다.
느낀 점
저도 회사에서 일하면서 구조 개선에 대해 비슷한 이야기를 들은 적이 있습니다. "요구사항을 맞추는 것이 개발자가 더 편하게 개발하는 것보다 중요하다" 라는 이야기인데요, 이것 또한 비슷한 맥락이라고 생각합니다.
요구사항이 멈추는 일은 존재하지 않습니다. 요구사항은 시장/고객으로부터 나오고, 시장/고객은 절대 만족하지 않습니다. 서비스(와 그 안의 기능)은 시장/고객의 문제를 해결해 주기 위해 존재하는 것이고, 문제는 그 이면의 욕구로부터 나오므로 계속해서 발생할 수밖에 없습니다. 이러한 시장의 원리 때문에 모든 서비스는 계속해서 발전할 수밖에 없으며, 즉 요구사항은 "끊임없이" 나올 수밖에 없습니다.
그런데 나쁜 구조를 개선하기 위한 노력을 계속하지 않으면 언젠가 수많은 개발자들이 밤낮으로 일하고도 요구사항을 맞추지 못하게 되는 날이 올 것입니다. 그 때부터는 서비스가 발전할 수 없게 됩니다. 이미 너무 많은 코드가 작성되어 버려, 추가개발을 하는 비용이 추가개발로 얻을 이득보다 더 커져버렸기 때문입니다. 손익이 역전되어 이제는 좋은 구조로 바꾸지도 못하는 것입니다. 서비스가 밟아온 길의 종점이 오도가도 못하는 늪 정가운데인 것이죠. 이런 운명을 방지할 수 있는 해답은 소프트웨어 개발자의 손에 달려 있습니다.
읽으면서 회사에 다니면서 서비스를 개발하고 유지보수하고 있는 입장에서 공감이 많이 되는 부분이 많았습니다. 클린 아키텍처의 나머지 장도 읽어 나가면서, 실제로 그 내용을 같이 일하는 개발자들의 동의를 얻어 회사에 적용하려고 합니다.
댓글