Intro
항상 설계에 대한 발표를 한번 해보고 싶었습니다.
그래서 이번에 설계에 대한 발표를 했는데 개인적으로 아쉬움이 많이 남았습니다.
시간이 없어 준비를 많이 못하기도 했고 (사실 블로그도 애기 재우고 새벽에 쓰고 있답니다.)
하고 싶은 이야기의 반도 하지 못한것 같습니다.
그래서 하고 싶었던 이야기를 좀 더 블로그를 통해 해보도록 할게요
팀이 설계한다.
팀장을 처음 하게된 날 부터 생각하는 팀의 이상적인 모습이 있습니다. 아마 개발자라면 한번 쯤 생각해 보았을 그런 팀이죠. 자유롭게 의견을 나누고, 바쁠때는 함께 고생하고, 서로 부족한 부분을 케어해주고, 기술적으로 성장하는 그런 팀이요. 그래도 요즘은 셀메이트 개발팀이 점점 그런 팀이 되어 가는것 같아 좋습니다.
다만 한가지 설계에 대해 이야기 할 때 만큼은 조금 답답할때가 있습니다. 설계가 추상적인 이야기를 하다 보니 다른 논의에 비해 상대적으로 의견차이가 잘 좁혀지지 않는 경우가 많았습니다. 그래서 설계에 대한 논의를 하다보면 이야기가 길어지는 경우가 많고 그렇다 보니 설계에 대한 이야기를 잘 안하게 됩니다. 그러면 어떻게 되냐하면 제가 설계를 거의 다 하는 그런 상황이 되지요.
그건 사실 제가 바라는 팀의 모습이 아닙니다. 저는 팀이 설계하기를 바랍니다. 그렇다면 무엇부터 시작하는게 좋을까요? 저는 팀 구성원 전체가 좋은 설계가 무엇인지에 대해 합의해야 한다고 생각해요. 그러기 위해 설계에 대한 기본 지식에서 부터 시작하면 좋을것 같았습니다.
좋은 설계
그럼 좋은 설계란 무엇일까요?
좋은 설계의 요건에는 여러가지가 있겠지만
제가 생각하는 좋은 설계에서 가장 중요한것은 팀 구성원이 잘 이해하는 설계 입니다.
그런 설계는 그럼 어떻게 만들어질까요?
첫번째, 일단 설계에 대한 기본 지식을 공유해야 합니다.
제가 발표했던 클린 아키텍처와 같은 개념들이 그런것이 되겠네요.
두번째, 설계에 대한 이야기를 자주 해야 합니다.
그런 대화속에서 지향점이 정렬되어 갈겁니다.
저는 시간이 많이 걸린다는 이유로 설계에 대한 지향점을 정렬할 기회를 앗아가고 있었는지도 모르겠습니다.
세번째, 두번째에 이어 잘못된 설계에 대해 이야기하고 고쳐나가야 합니다.
우리는 잘못된 설계를 보며 “이딴 설계를 누가한거야?” 라며 탓하기 보다는
“어떻게 했으면 좋은 설계가 되었을지” 에 대해 이야기 해야 합니다.
클린 아키텍처
저는 이번 블로그에서는 해당 내용에 대해 길게 다루지 않겠습니다.
발표로 한번 들었을 것이기도 하고 관련자료는 쉽게 검색해 볼 수 있는 내용들입니다.
Chat GPT 많이 쓰시죠? 저는 여러분들이 GPT에게 물어봤으면 하는 몇가지 질문을 써볼게요
- solid 원칙을 예시를 들어 알려줘
- 객체지향에 대해 알려줘
- 소프트웨어 개발 3대 원칙 : KISS, YAGNI, DRY 에 대해 설명해줘
- 클린 아키텍처에 대해 설명해줘
- 클린 아키텍처에서 말하는 계층에 대해 상세하게 설명해줘
그리고 각 질문의 답에 더 깊게 알고 싶거나 잘 이해되지 않는 부분에 대해 계속해서 질문해보세요.
가급적이면 클린 아키텍처를 포함한 관련 서적을 읽어 보시는 것을 추천 드립니다.
변경이 쉽다 = 의존성 관리가 잘 되어 있다.
클린 아키텍처에 대해 조금 만 이야기를 해보자면 결국 책에서 말하고자 하는 핵심은 의존성 관리입니다. 그 최종 목적은 “변경을 쉽게 하고 싶다.” 이지요.
반대로 변경을 어렵게 하는것이 잘못된 의존성 방향, 강한 의존관계입니다.
예를 들어 A를 고치고 싶습니다. 그런데 A를 의존하는 파일이 수십개입니다.
그래도 고쳐야 했기에 A를 의존하는 모든 파일을 테스트 하며 개발을 완료 합니다.
그런데 A를 전혀 의존하고 있지 않은 G에서 에러가 발생합니다.
왜냐하면 G는 F를, F는 E를 … B는 A를 의존하고 있었기 때문입니다.
이런 경우를 저는 수도 없이 경험했습니다.
그래서 책은 도와줍니다.
개념의 경계선을 그을수 있게 도와주고 (계층)
의존성의 방향이 어떻게 되어야 하는지 도와주고 (저수준에서 고수준으로 - 외부에서 내부로)
의존성을 약하게 할 수 있게 도와줍니다. (추상화)
그리고 잘못된 의존성을 바로 잡을 수 있게 도와주죠. (의존성 역전)
변경이 어렵다 = 의존성 관리가 잘 안되어 있다.
자 그러면 프로젝트에서 어떤 변경이 어려운 경우는 두가지가 됩니다.
1. 내가 설계에 대해 기본 지식이 없다.
2. 프로젝트의 설계가 잘못되어 있다.
자 우리는 이제 설계에 대한 팀의 기본지식을 습득했습니다.
그러면 이제 변경이 어렵다면 2번 밖에 남지 않겠네요. 참 다행입니다.
이제 우리는 잘못된 설계를 바로 잡기만 하면 됩니다!
설계 바로잡기
잘못된 설계는 늘 존재합니다.
이유는 다양하지만 저는 크게 두가지 이유라고 생각해요.
1. 설계를 잘 몰라서
2. 설계 할 시간이 없어서
2번은 가능한 피하도록 하세요.(쉽지는 않겠지만)
왜냐하면 이렇게 잘못 설계된 코드는 부메랑 처럼 되돌아 옵니다.
그런 코드는 수정하는데 고비용 / 하이리스크인 경우가 많이 있습니다.
하지만 우리는 그런 코드를 수정해야만 합니다.
그럼 이런 코드를 수정할때 우리에게는 몇가지 선택지가 있습니다.
- 좋은 설계로 모두 수정하기
- 기존 설계를 변경하지 않기
- 점진적으로 변경하기
시간이 허락한다면 1번을 하면 됩니다.
우리가 생각하는 설계 대로 코드를 뜯어 고치고 테스트 코드를 작성 하는거죠.
하지만 고쳐야할 기존 설계의 수준과 범위에 따라 거의 프로젝트 전체를 수정해야 할 수도 있습니다.
2번은 어떨까요? 설계를 그대로 두고 필요한 부분만 변경하는 겁니다.
하지만 이것 또한 경우에 따라 더 큰 비용과 리스크가 있을 수 있습니다.
앞에서 말한 예시처럼 수정해야 할 코드가 수많은 코드에서 의존하는 코드라면 더 그럴테지요.
그래서 저는 대부분의 경우에 3번을 선택합니다.
사실 1번을 하고 싶지만 시간이 허락되지 않는 경우가 많기 때문이지요.
보통 그 과정은 다음 스텝으로 이루어 집니다.
STEP 1. 최종적으로 만들고자 하는 설계를 그려본다.
STEP 2. 지금 문제가 되는 부분을 최소한의 비용으로 설계된 대로 작성한다.
STEP 3. 설계를 변경해야 하는 다른 부분들은 TODO 주석을 달거나 기술부채로 남겨둔다.
그리고 팀은 남겨진 잘못된 설계에 대해 인식하고 잘못된 설계를 재생산 하지 않으며 가능한 다른 작업중에 남겨진 잘못된 설계를 수정해가야 겠습니다.
원칙을 지키는 수준 정하기기
때때로 우리는 설계 원칙을 지키지 않는 결정을 할 수 있습니다.
원칙을 너무 강력하게 따르는 코드는 너무 파편화 되거나 생산성을 저하시킬 수 있기 때문이지요.
그래서 효율을 위해 원칙을 지키지 않기로 했다면 그것이 예외 라는 것을 다른 구성원이 알수 있게 해야 합니다.
주석을 다는 것은 다음 사람을 위한 아주 좋은 편지가 될거에요.
설계를 위해 투쟁하라
클린 아키텍처에서 나오는 말입니다.
제가 생각하는 이 말의 의미는 설계에 필요한 시간을 반드시 확보하라. 입니다.
여러가지 방법이 있겠지만 저는 비개발자를 포함한 팀 전원이 그 시간의 필요성에 대해 이해하고 있어야 한다고 생각해요.
그 시간이 없을때 얼마나 많은 비용이 발생하는지 투자 했을때 얼마나 이득이 있는지에 대해 이야기하고 설득해야 합니다.
프로젝트를 진행하다가도 종종 우리는 설계의 첫단추를 잘못 끼웠음을 깨달을 때가 있습니다. 그런 상황에서 우리는 외부에 설계 변경에 큰 시간이 필요하다는 것을 설득할 자신이 없기에 보통은 어떻게든 끼워 맞춰서 개발을 완료하는 시도를 하지요.
아마 경험해보신 분들은 아실거에요. 그때 끼워 맞춘 그 코드들이 몇배로 다시 되돌아 온다는 것을.
좋은 설계의 힘에 대한 경험
이번에 클린 아키텍처를 읽기 직전에 결제 프로젝트를 진행 했습니다. 셀메이트의 결제 시스템을 이관하는 과정이 었습니다.
요구사항은 아주 복잡했고 저는 처음 해보는 node 진영의 nest js 프레임 워크를 쓰면서 개발해야 했습니다. 그것도 한달 안에 말이죠.
그리고 그렇게 잘 설계되지 못했다고 생각한한 그 코드는 1월 2일 릴리즈 되었고 그 이후 저는 리팩토링 작업을 하고 있습니다. 구체적으로는 일부의 설계변경과 데이터 구조의 변경입니다.
그런데 생각보다 그렇게 큰 비용이 들지는 않고 있어요. 그 이유는 nest js에서의 구조가 나름 클린한 아키텍처를 가지고 있기 때문입니다.
특히 module, controller, service, repository를 기본 구조로 가져가는데 그 자체로 변경이 쉬워지는 경험을 하고 있습니다.
이번에 설계에 대해 공부해보니 이런 설계에 대한 부분들이 좀 더 명확하게 보이는 것 같아요.
더욱더 추상화된 설계를 해보고 싶은데 그건 아마 다음 도전 과제가 될 것 같네요.
마치며
이번 기회에 설계에 대해 생각해보며 느끼는 것은 설계가 아주 이타적인 행위라는 것입니다.
팀 구성원이 많으면 많을 수록 우리는 팀이 지금도 앞으로도 쉽게 변하는 코드를 남기기 위해 좋은 설계를 해야 합니다.
그 말은 미래의 나 뿐만이 아닌 다른 팀원들들 생각하며 설계해야 한다는 의미이기도 해요.
아주 이타적이지 않나요?
그래서 감사드립니다. 설계에 대해 고민하고 있는 당신에게.
이번을 기회로 우리 팀에서는 설계에 대한 이야기를 많이 하게 될 것 같습니다. 그리고 그런 이야기 들이 셀메이트라는 큰 덩어리를 좋은 설계로 바꿔나는 초석이 되지 않을 까 싶습니다.
앞으로 여러분들과 재밌고 즐겁게 좋은 설계, 좋은 개발을 해나갈 날들이 기대되네요.
감사합니다.