결론
디자인 패턴 혐오증이라는 제목이지만, 사실 혐오하지 않아요. 디자인 패턴에 매달려 프로덕트를 멋지게 만든다는 목표를 잊어가는게 싫을 뿐이죠
디자인 패턴에 빠져 좋은 코드를 삭제하려고 한다면, ‘디자인 패턴을 확장해보자.’ , ‘우리만의 패턴을 만들어보자’ 라고 말할 수 있는 개발자가 되고싶어요
항상 생각하지만, 디자인 패턴이 갖춘 정의나 지식, 규칙보단 디자인 패턴이 주목하는 아이디어가 중요하다고 생각해요.( 저만의 생각입니다.. )
개요
지금부터 써볼 포스팅은 오롯이 필자의 경험에 의존합니다. 더군다나 무수한 디자인 패턴의 학습이 되지 않은 주니어 개발자의 시선이니 반론은 환영입니다..!
오늘 미팅에서 재미난 아이디어를 얻게되어, 나의 생각이 완전 삐뚤어진 생각은 아닐지도 몰라 적어봅니다.
우선 이번 미션, 나의 목표는 관심사의 분리였다.
GitHub - juunzzi/javascript-racingcar at step2
위 링크는 이번 미션을 구현한 레포지토리 링크입니다. MVC 패턴처럼 느껴지시나요? 그럴수도있다고 생각해요. 하지만 저는 개발하는 내내 MVC 패턴을 따르지 않고싶어 라고 생각했어요. 제가 집중한 부분은 관심사의 분리(UI로직과 비즈니스로직의 분리)였을 뿐이죠.
그래도 이전에 학습했던 영향인지, 반대로 가려고 해도 계속 생각이 나긴 하더라구요. 😭
아토믹 디자인 패턴으로 생겼던 과거 이슈
저는 과거 친구들과 만든 창업팀에서 서비스를 개발해본적이 있습니다. 소꿉놀이라고 생각하지만, 이 약 8개월의 삽질 기간 동안 뼈저리게 느꼇던게 있어요. 바로 디자인 패턴의 절대적인 적용이 프로덕트의 질을 향상시켜주지는 않는다는 사실이였습니다.
저희 개발팀은 아토믹 디자인 패턴을 UI개발에 적용하였습니다.
관련 지식은 이 악몽의 시작 링크에서 확인하실수있어요. 아토믹 디자인 패턴의 적용을 결심한 그 때부터 시작된 악몽들은 다음과 같아요.
1. 작은 컴포넌트를 합성하여 큰 컴포넌트를 만드는 아토믹 디자인 패턴의 방식은 리팩토링을 하지 못하도록 만들었어요
완전히 독립적인 컴포넌트를 작성하지 않는 이상, 사소한 변경에도 많은 부수효과를 만들더라구요.
이 부분은 저희 팀의 역량이 각자 다르고 낮아서 ( 완벽하게 디자인패턴에 따라 개발하지 못해 )
생긴 이슈일 수도 있지만, 세상 어느 팀의 모든 팀원이 역량이 높은 수준으로 같을 수 있을까요.
한명이라도 잘 못 짜게되면, 그 부수효과가 엄청날텐대 말이죠.
이 때부터 디자인 패턴의 절대적인 적용이 과연 맞는 것일까 의문을 갖게 만들었어요. 2. 규칙을 따라가다 보니 오히려 개발비용이 커지게 되었어요
특정 컴포넌트의 경우 아토믹 디자인 패턴이 말하는 5가지 개념 중 어디에 해당하는 지 고민하는 시간이 길어지게 되었어요. 3. 완벽한 모듈을 만들려고 하다보니 코드 가독성이 떨어지게 되었어요.
코드가독성이 떨어지다보니 이를 사용하는 사람에게 이해하는데
걸리는 시간과 정보의 양이 많아지게 되었고 결과적으로 이 또한 개발비용을 증가시키더군요. 4. 디자인 변경을 두려워하게 되었어요
디자인 변경에 많은 컴포넌트들이 민족 대이동을 하게되니, 개발 팀 입장에서는 디자인의 변경을 두려워하게 되더라구요.
여기서 디자이너와의 협업이슈는 덤으로 발생했구요. 간략하게는 이 정도로 설명드릴 수 있겠네요. 이 글을 읽어보시면 더 좋을 수도 있어요 stop using atomic design pattern
결국 위 이슈들은...
여러 문제들을 낳았고, 프로덕트의 질이 더 좋아질 수 있음에도 막게되었던 것 같아요.
디자인 변경이 두려운 우리들의 눈치를 보며, 디자이너는 소극적으로 변해갔고. 우리는 코드 개선점을 찾기를 거부하고, 현상 유지만을 바라며 지내왔으니까요.
그리고 아토믹 디자인 패턴으로 얻을 수 있는 이점은 굳이 패턴을 적용하지 않아도 얻을 수 있는 이점들이었어요. 이를 깨닫고 우리가 개발했던 과거를 돌아보니 결국 우리는 좋은 프로덕트를 만드는 데 집중하기보단 디자인 패턴을 적용하는데 집중 했던 것 같더라구요.
그래서 제가 해보고 싶은 말은
디자인 패턴을 적용할 수 있고, 이를 확장하거나 활용할 수 있다고 생각해요. 하지만 절대적으로 신뢰하며 적용하지는 않겠다는 거죠.
내가 생각하는 개발자로서의 목표는 사용자에게 제공할 프로덕트를 멋지게 만드는 일이지, 디자인 패턴이 합리적임을 완벽히 적용하는 것을 통해 증명하는 것이 아니라고 생각해요.
MVC 패턴을 적용하면서 여러분은 어떤 생각을 했나요 ??! 관심사의 분리가 잘된 결과물을 만들겠다는 목표였나요. 아님 많은 사람들을 통해 검증된 MVC 패턴이니 적용하면 무조건 괜찮겠지 하는 마음이었나요
디자인 패턴을 앞으로도 적용하게 된다면, 참고서로 활용 해보고 싶어요. 당연히 기본적인 내용은 학습을 해보고, 사소하게 적용도 해본 이후에 말이죠. 우리 팀, 프로젝트에 맞게 참고하면서 패턴을 확장해나갈까 싶은거죠!
제 생각은 변하게 될까요?
