이제야 용기내서 써보는 React Hook Form과 DRY vs WET

서두

 대략 6개월 전, 머리털 나고 처음해보는 팀 프로젝트 중 2주간의 프리 프로젝트를 끝내고, 바로 메인 프로젝트를 시작했습니다.

시작과 동시에 팀 편성 및 빌딩 시간을 가지고 다같이 아이디어 구축 및 기획, 와이어프레임과 디자인 작업, 유저 플로우 작성과 제출해야하는 산출물 문서 작성을 일주일간 진행했습니다.

 

 해당 기간동안 부트캠프에서 정해놓은 시간이 종료되면 확정되었던 새로운 기술 스택들 중 Next.js와 TypeScript를 공부했습니다. 아무래도 새로운 기술 스택들을 하나하나 공부할 시간이 부족하다보니 가장 핵심되는 기술 스택인 Next.js와 TypeScript를 틈틈이 영상을 보며 초기 세팅부터 간단한 CRUD와 배포까지 공부했습니다.(feat. 유튜브 생활코딩)

그나마 Next.js와 TypeScript는 React 기반의 프레임워크와 JavaScript의 슈퍼셋이였고, 그래도 가장 관심을 두었던 녀석들이라 익숙해지기는 했습니다만... 문제는 (이제 아토믹 패턴을 곁들인)첫 시작이였습니다.

 

아토믹 패턴

 프로젝트 단계에 진입하기전, 디자인 시스템을 공부했을때 처음으로 아토믹 패턴의 개발 방식을 알게 되었는데

아토믹 패턴으로 개발하면 재사용성이 높은 컴포넌트를 만들어 중복을 방지할 수 있다는 장점이 있다는 걸 알았고,
더불어 팀원분 중 한 분께서 이미 아토믹 패턴으로 개발을 하신 경험이 있었습니다.

(???: 공통 컴포넌트를 만들고 나중에 조합했을때 그.. 쾌감이 있습니다!!!)

그리하여 팀 회의에서 다들 아토믹의 장점과 적용했을 때 가져올 효과를 기대하며 결정하게 되었습니다.

 

 아토믹 패턴의 개발 방식을 간략하게 얘기하자면 제일 작은 단위의 원자와 그 원자들의 조합인 분자가 있고, 원자와 분자를 합쳐서 유기체를 만들고, 이렇게 만든 원자, 분자, 유기체들을 배치하고 구성하는 템플릿이 존재합니다.

끝으로 실제 데이터를 넣어 완성된 UI의 모습을 담고 있는 페이지까지 총 5단계를 거쳐 개발을 진행합니다.

사실... 제일 작은 단위부터 시작해서 제일 큰 단위로 가는 개발 방식은 첫 단계부터 오래걸릴 확률이 큽니다.

왜냐하면 프로젝트 규모가 크다면, 혹은 저처럼 아토믹 개발 방식이 처음이라면 제한된 마감기한 동안 수많은 원자만 만들다 끝나버리는(...) 불상사가 일어날 수 있기 때문입니다.(실제로 아토믹 패턴으로 진행하면 프로젝트를 못 끝낼 수 있으니 일단은 WET 방식으로 개발하세요.라고 얘기를 들었습니다. WET 방식은 아래에서 설명하겠습니다.)

 

 결론부터 말씀드리자면 아토믹 개발 방식으로 진행한 프로젝트는 성공적으로 끝났습니다.그럼 잘된거 아닌가요?

아토믹 개발 방식을 채택하고 나서 기획했을 당시에 프론트 팀원들 다같이 부팀장님의 끝내주는 디자인을 보면서 공통 컴포넌트에 대해 분석하고 이야기를 했었습니다. 그 후 제가 맡은 업무가 로그인과 회원가입에 사용할 공통 input 컴포넌트를 만드는 일이였는데

디자인을 보면서 '아, input 안에 placeholder랑 각 input에 맞는 icon이 있구나. 그리고 로그인이랑 회원가입 input이 크게 차이나는게 없네. SignInput 컴포넌트 하나 만들어서 재사용하면 되겠다.ㅎㅎ 이게 바로 아토믹~?' 하고 안일하게 생각했습니다...

 

 이로인해 개발을 시작할 당시 저는 큰 멘붕에 빠지게 됩니다.

'props를 넘겨서 공통 컴포넌트를 만들라고...? 공통 컴포넌트에서 어떤 props를 넘겨주어야 하지...?'

'interface로 props를 만들어줘야 하는건가...? 일단 구현이 당장 시급하니 구현부터 하자...!'

'react-hook-form의 register와 error의 type이 뭐지...? () => void랑 boolean인가...?'

낯선 기술 스택은 물론 아토믹 개발 방식을 해본적 없는 상태에서 구현하다 보니 알고있는 것도 낯설어지고, 코드의 질은 당연스럽게 떨어졌습니다. 결국 이해가 제대로 되지 못한채 코드를 작성하는 범법(?)을 저질렀고요...

 

 또한 이때 마음이 급해 영어로 적힌 공식문서를 보단 WET 방식의 코드들이 있는 블로그를 참고하면서 공통 컴포넌트 개발에 대한 막연함을 직면했습니다.

그래서 팀원분들께 도움을 요청했고, Live Share로 다같이 코드를 수정하고 에러를 고치며 큰 도움을 받아 덕분에 SignInput 컴포넌트를 만들 수 있었습니다.

이때 팀원분 중 한 분께서 React-Hook-Form의 공식 문서를 보면서 에러를 정확하게 해결하고, 필요한 부분만을 빠르게 찾아 적용하는 모습을 보면서 '아, 앞으로 나도 새로운 기술을 사용할 때 처음부터 공식 문서를 읽고 정확하게 적용하고 에러를 해결해야겠다.'고 생각하며 배울 수 있는 귀한 시간이였습니다.

하지만 뚝딱뚝딱 열심히 만든 컴포넌트에서 문제가 발생했는데, 단순히 input이라는 공통점을 가지고 SignInput 컴포넌트로 묶어 하나의 공통 컴포넌트를 만들다 보니 만들어야 하는 input이 text와 password로 두 가지 타입인 걸 놓쳤습니다.

이걸 하나로 묶어버리게 되니 비밀번호를 확인하는 input에서 비밀번호가 틀렸을 때 에러 메시지가 뜨지 않는 이슈가 발생했고 로그를 출력해보니 빈 값으로 출력이 되는걸 확인했습니다.

값을 관찰하고 있는 watch 메서드가 입력 값을 인식하지 못하는 문제였고, 이를 해결하기 위해 SignInput 컴포넌트 안에서 조건을 분기하기도 하고, 값을 얻을 수 있는 getValues 메서드를 사용해보기 했지만 해결되지 못한 채 결국 공통 컴포넌트의 가독성은 떨어지니 SignInput과 SignPasswordInput으로 분리하면서 다시 watch 메서드를 사용해 이슈를 해결했습니다.
(지금 생각해보면 SignInput 컴포넌트 이름도 SignTextInput으로 명명하는게 좋았을 것 같네요...)

그리고 다행인 점은 두 공용 컴포넌트가 로그인과 회원가입에서만 사용하는 컴포넌트라 SignInput과 SignPasswordInput의 더이상의 확장과 이슈는 없었습니다.

이후 찝찝한(?) 마음을 한 켠에두고, 다른 기능을 구현하면서 마침내 프로젝트를 성공적으로 끝냈습니다.

 

프로젝트 이후

 프로젝트가 끝나고 포트폴리오에 어떤 에러 상황을 기술할까 고민하던 저는 그나마 자신있게 해결했던 에러인 Next.js의 하이드레이션(hydration) 에러를 선택했습니다.

사실 프로젝트때 짰던 코드로 인해 자신감이 떨어져있던 상태였던지라... 흑흑 제일 고생했던 SignInput 컴포넌트를 만들 때 만난 고민과 문제 해결을 선택하지 못했습니다. 하지만 제목 그대로 이 주제에 관하여 겪었던 문제와 고민들, 그로인해 현재는 어떤 생각을 가지고 있는지 얘기하고 싶었습니다.

 

DRY vs WET

 위에서 계속 말씀드렸던 WET 방식에 관하여 설명하자면, 먼저 DRY 방식을 말씀드려야 합니다.
DRY는 "Don’t Repeat Yourself"의 약자로 동일한 코드를 반복하지 말라는 개발 원칙 중 하나입니다.
그와 반대로 WET은 "Write Everything Twice"는 추상화가 적절하게 이루어지지 않으면 반복되어지는 코드보다 더 큰 비용이 든다고 여기는 원칙입니다.(중복되는 코드를 돌려까기 위한)

즉, DRY는 공통 컴포넌트를, WET은 공통 컴포넌트가 아닌 반복적인 컴포넌트를 얘기할 수 있겠죠.

 

 사실 저는 '아토믹 패턴이 뜨는 트렌드다~ 재사용을 위해서 지향하는 개발 방식이다~' 등 그런 말들에 속아(?) 제대로 경험해보지 않고 아토믹 패턴을 개발 방식의 목표로 잡기도 했었습니다. 그 덕분에 팀 회의때 '아토믹 좋아요! 해보고 싶어요!'라 말했지요...

분명 아토믹 패턴은 재사용성 등 장점이 많고, 탄탄한 기획이 갖추어지거나 이미 이 패턴으로 개발하는게 익숙하다면 좋게 작용하겠지요.

다만, 저는 프로젝트를 할 당시 아래와 같은 상황이였기 때문에

 

1. 아토믹 패턴으로 개발해본적이 없었음

2. 전 프로젝트를 비롯하여 그동안 WET 방식으로 개발을 했었음

3. 아토믹 패턴만 신경쓰기에는 새롭게 쓰는 기술 스택이 대부분이였음

 

 그래서 최소한 위의 상황에서는 아토믹 패턴의 개발 방식이 정답이 아니구나를 깨달았습니다.

프론트엔드 개발자로서 사용자 경험을 중요하게 생각해야 하지만, 사용자 경험만큼 중요한게 개발자 경험이라 생각합니다.

개발을 할 때 경험해 보지 않은 방식이나 라이브러리를 바로 도입해서 사용하는 것이 아닌 충분한 시간을 가지고 직접 사용해보면서 조금이라도 장/단점을 파악한 후에 팀원 모두가 해당 기술에 경험이 있는지, 다같이 도입할 수 있느냐 없느냐를 판단해서 결정해야 한다고 생각합니다.

그러지않고 (저처럼)바로 도입하게 된다면... 마감기한에 쫓기는 개발자의 코드의 질은 점점 떨어질 것이고, 그런 코드는 다른 사람이 보기에도 이해할 수 없을 뿐더러 개발자 자신의 경험과 자신감은 점점 떨어질 것 입니다.

 

끝으로

 아직은 주니어 개발자(...라 하기엔 경력이 없어서 민망하네요.ㅎㅎ...)로서 많은 경험을 해보지 못했지만 적어도 개발을 할 때 이런 고민을 가지고 동료들과 토론하면서 더 나은 방향성을 찾아보고, 또 비슷한 상황이 왔을 때 조금 더 나은 상황 판단을 한다면 점차 발전하고 상황에 맞는 코드를 설계하는 개발자가 되지 않을까 기대해봅니다. 글을 읽어주신 모든 분께 감사합니다. :)

 

출처

1. https://tech.socarcorp.kr/dev/2024/03/06/socarplan-renewal.html#%ED%9A%8C%EA%B3%A0-%EC%9A%94%EC%95%BD-%EB%A7%88%EB%AC%B4%EB%A6%AC

쏘카플랜 개편기

2. https://dj-min43.medium.com/dry%EC%9B%90%EC%B9%99%EC%9D%84-%EA%BC%AD-%EC%A7%80%ED%82%AC-%ED%95%84%EC%9A%94%EB%8A%94-%EC%97%86%EC%8A%B5%EB%8B%88%EB%8B%A4-d05f137105e0

DRY원칙을 꼭 지킬 필요는 없습니다

3. https://www.figma.com/file/yL1b8KClwZHoBXDcCp4wei/GrowStroy?type=design&node-id=1%3A10&mode=design&t=aHjnc7gyzKOuxyke-1

Figma