좋은 설계란 무엇일까? : 유지보수가 쉬운 시스템을 만드는 것

 

우리가 하는 개발-코딩은, 진리를 추구하는 학문이나 과학이 아니다.

지식이나 법칙, 진리를 발굴한다거나 완전 무결한 최고의 시스템을 만들어내는게 우리의 목표가 아니다.

 

우리가 하는 것은 공학이다.

공학의 정의는 다양하나, ('실천적인 문제 해결', '기술적 해결책 제시', '현실적인 문제 해결'...)

공통으로 등장하는 키워드는 '문제 해결' 이다. 우리에게 당면한 문제를 효과적으로 해결하는 것. 그 것이 우리의 목표다.

 

문제를 해결하려면, '문제가 무엇인가?'에서 부터 출발해야 한다.

보통 공학에서 주어지는 문제란, 사업 방향성과 밀접하게 맞닿아 있다.

'어떤 방향으로 사업을 하기 위해서, 이런 프로덕트, 서비스가 필요합니다. 비용은 가능한 적게 들면 좋겠습니다.'

 

주목해야 하는 포인트는 비용이다. 물론, 여기서 비용이란 단순히 특정 기능을 개발하는데 드는 당장의 비용 뿐만 아니라, 만들어진 기능에 대한 유지보수 비용과 확장에 드는 미래 비용까지 모두 포함하는 개념이다. 비용은 곧 시간이라고 봐도 되겠다.

 

이제 좋은 설계에 대해서 정의내릴 수 있는데, 개발하고 유지보수하는데 비용이 적게 드는 설계가 좋은 설계다.

 

비용이 많이 드는 설계, 즉 잘못된 설계는 아래와 같은 문제가 생긴다.

• 추가적인 기능 요구사항이 들어왔을 때 확장 비용이 너무 많이 들어 수용 할 수 없는 경우가 발생
• 수정하기 어려워 유지보수 비용이 많이 듦 (시간이 오래 걸림)
• 처음부터 벽돌이 잘못 쌓인 건물 처럼, 이상한 구조로 확장되어 점점 비용이 증가하다 언젠가 한계에 다다름

 

경험적으로, 우리가 하는 개발이라는 일은 대부분 기존 코드베이스에서 일부를 수정하고 기능을 추가하는 식으로 이루어진다.

그래서 초기에 개발하는데 드는 비용을 아끼고 나중에 유지보수를 힘겹게 하는 것 보다,

초기에 비용을 좀 더 들여서 좋은 구조를 잡아가며 개발하고 나중에 유지보수 비용을 절감하는 것이 전체 비용 관점에서 훨씬 저렴하다.

 

 

결론. 우리의 목표, 좋은 설계에 대해서 더욱 구체적으로 정의하면, 좋은 설계란 유지보수가 쉬운 시스템을 만드는 것이 된다.

 

 

---

따라서 때로는 당장 눈에 보이지 않는 가치를 쫓는 것도, 궁극적으로 문제 해결에 도움이 된다.

시스템의 확장을 고려했을 때, 당장 필요하지 않더라도 선제적으로 설계하고 책임을 분리하는 것은 전체 비용 절감하기 위해 꼭 필요한 과정이다.

리팩터링도 경제적인 이익이 있기 때문에 하는 것.  

 

---

우리는 '과연 무결한 시스템을 추구하는 것이 문제 해결에 도움이 되는 것인가?'에 대해 가끔씩 점검해 볼 필요가 있다.

개발자가 개발자로서의 ego를 가지고 본인이 생각하는 좋은 방향으로 코드를 작성해 나가는 것은 나무랄 것이 없다.

하지만 그 방향이 정말로 문제 해결(유지보수 비용 절감)에 도움이 되는 방향인지, 본인의 욕심에서 비롯된 것일지는 숙고해 보아야 한다.

 

---

어떤 형태가 유지보수하기 쉬운 시스템인지는 각자가 처해있는 상황에 따라 다를 수 있다.

유지보수하기 쉬운 하나의 정답과 같은 설계가 존재하는 것이 아니다.

Good design is all about trade-offs