💎 지난 이야기...
과거의 나는 2022년 1월부터 Ady라는 광고 판매 플랫폼 프로젝트를 맡아서 개발했어. 모든게 처음이었던 과거의 나는 혼자 도메인 파악부터 UI/UX 디자인까지 2달동안 끝내고 드디어 2022년 3월에 개발을 제대로 시작했어.
💎 개발 기술 스택 정하기
정말 개발은 나와 백엔드 개발자님 두명이 거의 모든 걸 정하고 개발해왔다고 생각하면 돼. 그래서 어떤 기술 스택을 사용해서 개발을 할 지 정하는 것 부터 선택의 기로에 섰었어.
하지만 4월 전까지 POC (Proof of Concept)로 하나의 프로세스를 연결해보는 것이 목표였기에 모든 기술 스택을 다 비교해 볼 시간이 없었어.
🎯 React vs. Next.js
기술 스택을 정할 때는 reference를 적극 활용하는 것도 도움이 됐었어. 2022년 초였으니까 그때 당시 react가 거의 프론트엔드 개발의 default 기술 스택이었어. 나는 네카라쿠배당토의 채용공고 사이트에서 어떤 기술을 사용하는지 확인해봤고 React와 Next.js를 많이 사용하더라고.
나는 React만 사용하는 것과 Next.js 사이에서 고민을 했었어. 사실 이때까지 React와 Next.js 둘다 한번도 사용조차 해보지 않은 상태였고 당연히 둘의 장단점을 완벽하게 모르는 상태였지. 그래서 열심히 서치를 한 결과, Next.js framework를 사용하기로 결정했어. 그 이유는 다음과 같아.
- Dynamic Routes: 라우팅을 자동으로 해준다.
- SSR: Server Side Rendering이 편하다.
결국엔 library인 React보다는 framework인 Next.js를 사용해서 개발을 하는 게 혼자서 개발하기엔 더 편하다고 판단했고 그래서 Next.js로 개발하기로 했어.
🎯 Javascript vs. Typescript
이 부분에서는 나는 Typescript를 정했어. 사실 프론트엔드 개발전에 학부생일때에는 Java나 C#처럼 타입이 있는 언어를 사용했는데 Javascript처럼 타입이 없는 언어는 뭔가 단전에서 올라오는 거부감이 있었거든.
내 블로그 글에서 Typescript는 항상 옳지는 않다라는 글이 있어. 그 글에 써있는 것처럼 Javascript를 꼭 배제할 필요는 없는 것 같아.
"엥? 뭔소리야?" 라고 생각하는 사람들이 있을 수 있어.
근데 이건 내가 개발을 하면서 Javascript를 사용했어도 좋았을 것 같다라고 생각하게 만든 이유가 있어.
Typescript는 항상 모든 데이터의 타입을 미리 정해줘야 해. 근데 개발 초기에는 설계가 완벽하지 않으면 데이터 타입이 정말 자주 변경이 돼. 그럴때마다 타입을 찾아서 바꿔주고 해야하는데 이게 생각보다 시간을 많이 잡아먹더라고.
그렇다보니까 초반에는 Javascript로 짜고 어느정도 시간이 지나면 Typescript로 바꿔주는 게 좋을 것 같다는 생각도 해. 근데 이건 정말 취향차이고 결국엔 Typescript로 변경해줘야 하다보니 처음부터 Typescript로 짜는것도 매우 무방하다는게 내 결론이야.
🎯 React-query vs. SWR
state 관리 라이브러리들이야. 이 기술 스택을 정할때만 하더라도 보내는 데이터는 몇개 안됐고 validation도 필요없었어. 그렇다보니 React-query만 사용하면 데이터를 주고받는것까지 다 처리해줘서 react-query를 사용했어. state를 관리해주고 refetch같은 정말 편한 기능들을 제공해줬고 swr과 다르게 useMutation()도 지원해줘서 react-query를 사용했어.
🎯 React-hook-form
Ady의 특성 상 form 사용이 매우 잦더라고. 그래서 React-hook-form을 나중에 추가로 도입하게 돼. 그 이유는 정말 form에 최적화 되어있던 라이브러리였기 때문이야. 처음에는 정말 데이터를 하나하나 받아서 requirement 처리만 해줬는데도 손이 많이 가더라고. 그리고 input 컴포넌트만 한 프로세스 당 최소 10개인데 그 input 컴포넌트마다 useState를 붙여줬어. 그러다보니 코드는 점점 복잡해지고 내가 쓴 코드인데도 관리하기가 너무 어려워지더라고. 그래서 어떻게 해야할지 찾아보다가 react-hook-form이란걸 찾았어. 기본적인 validation을 할 수 있고 설정하는 것도 매우 편하고 데이터를 한번에 받아주는게 너무 편하더라고. 그래서 React-hook-form을 사용하기로 결정했지.
🎯 Tailwindcss
사실 css는 다른 걸 염두해두지는 않았어. css도 기본적인거 말고는 잘 모르고 있었는데 내가 Next.js를 배우려고 들었던 노마드코더 니콜라스의 캐럿마켓 클론코딩 강의에서 Tailwindcss강의도 같이 해줘서 강의를 들었었거든.
사용도 직관적이었고 코드에 직접 다 넣어줘서 내 개인적인 생각으로는 component 개념이 있는 Next.js에서는 딱이라고 생각했어.
게다가 Tailwindcss가 dynamic하게 class를 가져오기때문에 dev환경에서도 빠르게 개발하기 좋다고 하더라고. 나는 아직 만족하면서 쓰고있지만 Styled Components도 이후에 한번 써보고 비교해보려고 해.
💎 페이지 만들기
일단 가장 먼저 한 일은 컴포넌트 만들기가 아니였어. 처음에 UI/UX 디자인부터 컴포넌트를 생각하지 않고 그냥 만들었고 컴포넌트를 하나하나 다 만들기에는 시간이 너무 없었던 것이지.
그래서 일단 정말 돌아가게만 코드를 짜서 페이지들을 만들었어. 그래도 Next.js에서는 pages 디렉토리 안에 있는 페이지는 그 파일 이름 자체가 주소가 되기때문에 이름은 심사숙고해서 소문자와 '-'만 사용해서 만들었지.
그 외에는 fetch도 생으로 하고 div 태그 안에 div 태그 안에 (...반복)같은 코드를 짜놓았지.
🎯 컴포넌트
이제 이렇게 빠르게 코딩하고 나니 반복되는 코드가 잘 보이더라고. 그래서 일단 반복되는 코드 위주로 컴포넌트를 만들기 시작했어. 근데 정말 재사용성 이런건 하나도 고려하지 않고 그냥 반복되는 코드만 컴포넌트로 만들었던 것 같아.
개발 자체는 빠르긴 정말 빨랐어. 그렇게 나름 뿌듯한 마무리를 했었지.
💎 Proof of Concept
이제 기술 스택을 정했으니 다 딱딱 맞춰서 잘 돌아가는지 확인할 차례겠지. 이때 정말 어떻게든 돌아가게 만들었던 것 같아. 백엔드와 프론트엔드를 연결하고 승인 프로세스를 연결하고 카카오 친구톡을 연결해서 하나의 큰 도메인 프로세스를 완성했어.
일단 기능은 잘 돌아갔고 엄청 뿌듯하더라고. 뭔가 한단계를 끝내놨고 이 한단계를 끝내는데 한달 반정도가 걸렸거든. 그래서 나는 그땐 9월까지는 모든 개발이 마무리 될 것이라고 생각했지.
하지만 그건 정말 나의 착각이었어.
"💡 여기까지가 개발의 초기단계였어. 다음 글에서는 데이터 설계와 프론트엔드 개발에 대해 적어볼께."
