설계의 중요성
KDT 데브코스를 시작한지 벌써 1달이 지났고, 많은 내용들을 배웠다. 그리고 그 배웠던 것들을 이제 직접 구현해 보는 시간이 왔다. 첫 개인 프로젝트로 Notion Clone 미션이 나왔다. 물론 프로젝트 자체를 처음하는 건 아니라서 그렇게 떨리진 않았지만, 대부분 팀 프로젝트를 위주로 해왔고, 개인 프로젝트 경험은 상대적으로 부족한지라 약간의 우려는 있었다.
그런데 프로젝트를 시작하면서 나도 몰랐던 안좋은 습관이 나왔다. 팀 프로젝트를 진행하면 초반에 당연히 구조를 짜고, 어떤 함수를 짜야할지 고민하였다. 그런데 막상 개인 프로젝트가 시작되고, 명세서가 나온 직후, 별다른 고민 없이 컴포넌트 구조만 간단하게 짜고 바로 코드를 짜기 시작한 나를 발견하였다. 설계의 중요성을 잘 알고 있으면서 이러한 습관이 나왔다는 것 자체가 내 스스로가 좀 우려스러웠다. 설계의 목적이 잘못된 선택으로 인한 시간 낭비를 최소화 하기 위함인데, 이것을 남들과 협업하기 위해, 남들과 같은 내용을 공유하고 작업하기 위한 목적으로 사용했던건 아닌지 하는 생각이 들었다.
그 결과, 전체 개발 시간중 절반 가량을 잘못된 설계를 구현하는데 시간을 쏟아 부었다. 구현을 완성하긴 하였지만 다른 컴포넌트와 연동할 방법이 떠오르지 않는 결과물이었다. 설령 방법을 찾았다 하더라도, 하나의 루트로부터 data status를 처리하는 방식이 아닌, 컴포넌트간 1:1 연결을 통한 방법 밖에 없었다. 그럴 경우 컴포넌트의 수가 증가하고, 로직이 좀더 고도화 될 수록 status관리가 더 어려워질 것이 자명하였다.
결국 처음부터 다시 돌아갔다. 컴포넌트 구조부터 먼저 점검하고, 컴포넌트별로 필요한 함수가 무엇이고, 각각 어떤 기능을 담당하는지 설계를 하였다. 그리고 구현에 앞서 활용하면 좋을 자료구조를 선정하였다. 그리고 로직을 직접 따라가보면서 루트에서 status를 관리할 수 있는지 경우의 수를 따져가보며 점검을 확인하였다.
하루 개발 시간중 절반을 잘못된 구현에 할애했던 사실이 좀 아깝긴 했으나, 구현의 50%를 완성하고 발견한 것보다 초반에 발견한게 정말 다행이었다. 설계의 목적과 필요성에 대해 다시금 생각해보는 유익한 시간이었으며, 앞으로는 습관적으로 설계와 평가를 먼저하는 습관을 길러야 겠다. 알고리즘을 학습할 때처럼 말이다.
P.S. 그나마 다행인 점은 잘못된 설계를 구현하는 과정에서 만든 코드들이 나중에 재활용하는데는 문제 없게 구현한 덕에 일부만 고쳐서 활용할 수 있을것 같다
