Amy = {afterMobi, ...mobi}

💬 Mobi 2기 수료 후 작성한 회고록

Mobi?

Mobi는 여태까지 게시글에 종종 나타난 Peanut 님이 운영하는 비영리 단체입니다.

모비는 값비싼 사교육, 현실적 시간 투자의 결여에 겁먹은 세상의 모든 비전공자들을 위해 무료로 교육을 제공하고 취업 이후의 인프라 형성을 통해 새로운 시작을 응원하는 비영리 단체입니다. 현재는 내부 추천으로만 운영되고 있으며 향후 홈페이지 개설 및 외부 공개를 통해 영역을 점차 확장해 나갈 예정입니다.

때는 바야흐로 2022년...

2022년 상반기, 처음 학원에서 프론트엔드 관련 수업을 듣게 되었습니다. 당시에 자바스크립트가 너무 어려웠고, 결론부터 말하면 강의는 진도를 채 따라가기도 전에 끝나 있었습니다.

해당 수업이 끝나갈 무렵, 딱 3번 Peanut 님이 대리로 강의를 진행해주신 적이 있습니다. 그때 대략적인 Peanut 님의 강의 진행 방식과 mobi에 대해서 알게 되었고, 듣는 그 순간 "아, 저 강의다." 라는 확신이 들었습니다.

그리고 2023년 4월

기존에 듣던 강의가 23년 1월에 종료되고 곧바로 다시 학원을 찾아가 Peanut 님의 강의가 있는지 확인했습니다. 저에겐 두 가지의 선택지가 있었습니다.

1. 1기가 수강 중이던 강의 (중도 투입)
2. 2기가 수강할 강의 (처음부터 함께)

저는 2번을 선택 후 3월 한 달동안 유튜브로 자바스크립트 영상도 중간 중간 보고, DeepDive 책도 구매해 읽으며 4월 강의를 기다렸습니다.

당시 Peanut 님이 22년도 강의 수강생들에게 자바스크립트 문제가 있을 때 스스로 코드를 구상하는 능력이 부족하다며 DeepDive 책 읽기 등을 추천해주셨습니다.

이전 강의와는 달리 끝까지 진도를 따라가기 위해 동료 학습에도 참여했고 최종적으로 mobi도 함께할 수 있게 되었습니다.

Mobi의 기준 중 하나가 잘 소통할 수 있는가였고 저는 이 부분을 조금이라도 보완하기 위해 동료 학습에 참여도 했지만 여전히 부족했습니다. 그래도 부족한 부분을 Mobi를 통해 극복할 수 있을 것 같다는 Peanut 님의 의견으로 최종 합격이 되었습니다.🙂

💬 memoirs

📖 during Mobi

Mobi를 통해 얻은 것이 정말 많지만 그 중에서 크게 두 가지 정도를 꼽을 수 있을 것 같습니다.

1. 미래에 대한 방향성

Mobi에서 제공되는 커리큘럼을 토대로 학습하면서 구체적으로 내가 어떤 부분이 부족한지 알 수 있었습니다. 아마 수업 시간에 배운 todolist들만 복습하다가 "이제 뭐하지...?" 하며 삽질만 했을 것 같아요. Mobi를 통해 배운 내용을 스스로 찾아서 공부하기까지 과연 몇 달이 걸렸을지...
2기가 종료된 현재, Mobi를 통해 알게된 것들을 토대로 이제는 놓고 온 부분들이 있다면 보완해가면서 NextJS 공부를 하고 있습니다.

Mobi에 들어오지 않았더라면 어떤 걸 더 공부해야 하는지 몰라 많이 방황했을 것 같습니다.

2. 협업의 중요성과 필요성

무엇보다 같은 처지에 놓인의 사람들과 함께 공부를 하면서 서로 의지하며 같이의 가치를 경험할 수 있었던 것이 가장 예상 못한 배움이었습니다.

mobi 이전에는 "조별 과제는 사회악이다,"라는 말을 지지할 정도로 같이 과제를 하는 것을 선호하지 않았습니다. 같이 조율해서 진행하는 것보다 혼자했을 때의 결과가 좋았던 경험이 지배적이라 후자가 더 효율적이라 판단하게 됐던 것 같습니다.

그래서 mobi에서도 이런 인식에 변화가 생길 거라고는 생각도 못했고, 그저 '페어로써 소통만 잘하면 되겠지,' → '소통이 잘 되려면 어떻게 말을 하면 좋을까?' 정도만 고민을 해봤습니다.

하지만 후반부로 갈수록 함께 토이 프로젝트를 진행하면서 같이했을 때의 시너지를 체감하게 되었고 이제는 오히려 같이 진행할 때 더욱 열정적으로 임하게 되는 사람이 된 것 같습니다.

mobi에서 매주 일요일 한 주에 내가 공부한 것이 무엇인지 공유하는 시간인 Weekly I Learned(WIL)을 가졌는데 같이 프로젝트를 진행하거나 공부를 하다보면 WIL을 매일하고 있다는 생각이 들면서부터 같이 진행하는 것에 즐거움을 느끼게 된 것 같습니다.

Details

구체적으로 어떤 커리큘럼을 토대로 어떻게 성장해 나가고 있는지 정리해보자면 :

1️⃣ 꾸준한 학습 습관 만들기 (평균 학습량의 증가)

저를 포함해 전체적으로 모든 인원의 평균 학습량이 증가했습니다.
초반에는 1인 당 하루 공부 시간이 약 2시간 정도 되었는데 끝날 때 즈음엔 6~8시간 정도가 되었습니다. 같이 토이 프로젝트를 진행할 때만큼 열정적이진 않지만 mobi가 종료된 지금도 매일 공부를 꾸준히 하고 있습니다.

디스코드에 출석부 기능이 추가되고 더욱 직관적으로 내 공부 시간을 확인할 수 있게 되면서부터 더 열심히 하게 됐습니다.

생각보다 몇 시간 집중 못했을 때에는 '얼른 재정비하고 다시 해봐야겠다,' 라거나 '오늘은 이쯤해볼까' 싶다가도 다른 사람들이 열심히 하고 있으면 '좀 더 힘내보자' 등 좋은 자극제가 되어주었습니다.

---

2️⃣ 디자인 시스템 적용과 관련 다양한 라이브러리의 사용

• story-book
• emotion
• styled-component
• tailwind-css

---

디자인 시스템이 적용된 재사용 가능한 컴포넌트를 만들어보면서 다양한 css 관련 라이브러리를 사용해봤습니다.

컴포넌트 주도 개발(CDD)에 대해 알아보면서 재사용이 용이한 컴포넌트에 대해서, 그리고 디자이너와의 협업에 대해서 한 번 더 생각해볼 수 있는 시간을 가질 수 있었습니다.

• 관련 주차 github 보러 가기 👉 story-book repo
• 관련 주차 진행 후 작성한 게시글 보러 가기 👉 let's storybook
• story-book에 대해서 정리한 게시글 보러 가기 👉 what's storybook

---

이전까지는 라이브러리 사용에 거부감이 좀 있었습니다. 공식 문서를 읽는 것도 미숙했고, 읽는 거 뿐인데도, 분명 읽고 시도한 건데도 오류가 발생하는 것 때문에 싫었습니다. 라이브러리를 사용할 바엔 그냥 손수 다 만든다는 생각이 자리잡혀 있었습니다.

하지만 많은 라이브러리를 사용할 수 밖에 없는 과제를 만나 페어와 함께 공식 문서를 읽어가며 사용해보니 "별 거 없네," 싶을 정도로 잘 사용했던 것 같아요.
막상 사용해보니 다 다른게 아닌 라이브러리들 간의 비슷한 사용법들이 보여 신기했고, 라이브러리 사용에 대한 두려움이 조금 사그라든 계기가 됐습니다.

---

3️⃣ 의존성 주입과 관심사 분리

의존성 주입과 관심사 분리는 수업 때부터 Peanut 님이 강조하던 부분이라 중요하다는 것은 익히 알고 있었습니다.
강의를 들을 때에는 의존성 주입(DI) === 관심사 분리라고만 생각했는데 그저 대표적인 사례였다는 것을 알게 되었습니다.
Mobi에서 주어진 과제를 하면서 느슨한 관계에 대해 한 번 더 생각해보고 아래 세 가지의 사례를 살펴보며 의존성 주입에 대해 다시 생각해보는 계기가 되었습니다.

(1) 전역 상태관리를 활용한 관심사 분리
(2) 모듈화를 활용한 관심사 분리
(3) 커스텀 훅함수를 활용한 관심사 분리

이전에는 의존성 주입을 위해 관심사 분리를 하기 급급했지만 이제는 공통된 부분을 묶어 관리할 포인트를 줄이는 것이 중요하다는 것을 알게 되었습니다.

---

4️⃣ RHF와 YUP을 활용한 유효성 검사

처음 프로젝트를 진행한 MMM에서는 훅함수를 직접 만들어 관리를 했던 게 생각납니다... 당시엔 공부하면서 진행할 여유가 없다고 생각해서 라이브러리 사용을 거의 못했는데 사용을 해본 뒤 돌이켜보면 시간적 여유가 없었던 게 아니라 심적 여유가 없었던 게 아닐까 싶습니다.

RHF로 form을 관리하고, 유효성 검사 라이브러리까지 사용했을 때 너무 간결하고 빠르게 회원가입/로그인 로직이 완성돼서 놀랐던 기억이 납니다. 마치 불을 발견한 느낌? 👀

• RHF + yup 활용한 github repo 보러 가기 👉 RHF
• RHF + zod 활용한 토이 프로젝트 보러 가기 👉 chap-chap
• chap-chap 회고 게시글 보러 가기 👉 chap-chap memoirs

5️⃣ 보일러 템플릿을 활용한 폴더 및 컴포넌트 구조 설계

프로젝트를 진행할 때마다 새로운 폴더 구조를 생각해내는 것보다 기존의 틀에서 특성에 맞게 수정을 하는 쪽이 좀 더
나아가 재활용 가능성이 높은 파일들의 경우 만들어둔 폴더에 미리 넣어둠으로써 더욱 효율적인 개발 환경에서 코드를 칠 수 있게 되었던 것 같습니다.

• 보일러 템플릿에 대한 게시글 보러 가기 👉 let's boiler-template
• 보일러 템플릿을 적용한 github repo 보러 가기 👉 boilerplate

---

6️⃣ 상태 최적화

부주의한 부모, 독립적인 자식 : 자식 컴포넌트가 하는 일을 반드시 부모가 알 필요가 없다!

해당 컴포넌트에서 props 전달이 이루어졌을 때 이 상태는 부모 컴포넌트가
알 필요가 있는 상태인지 확인 후 상황에 맞게 상태가 프롭스 드릴링(props drilling)되고 있는 것인지, 상태 해체(상태 올리기)가 필요한지 등을 고려해 컴포넌트의 구조를 나누는 것에 대해서 배웠습니다. 그리고 의도하지 않은 리랜더를 방지를 위해 상태의 개수를 최소화하는 것을 염두에 두고 코드를 짜게 되었습니다.

컴포넌트 구조 나누기에 대하여 생각해보기

1. 가독성이 좋지 않을 때
2. 관심사 분리를 해야할 때
3. 상태를 최적화 해야할 때
4. 재사용이 되는 컴포넌트일 때

[사례 01]

특정 배열을 map 돌리는 부분이 들어가 있다면 가독성이 좋지 않을 수 있습니다. 이럴 때에는 map 부분을 따로 분리해 추상화의 레벨을 같게 해줄 수 있습니다. 이와 마찬가지로 특정 코드가 반복된다면 이를 재사용할 수 있는지 한 번 고민해봐야 합니다.

[사례 02]

todoList에서 props 드릴링 및 부모가 알 필요가 없는 상태를 context를 톧해 관리 했습니다.

페이지네이션과 필터 등 다양한 기능을 하는 코드들이 한 파일 안에 적혀 있어 가독성이 좋지 않습니다. 한 페이지에는 한 가지의 기능만을 분리하는 것이 읽기에도 유지보수를 하기에도 용이하므로 관심사에 따라 분리를 해주는 것이 좋습니다.

before

after

[사례 03]
ref를 사용하기 이전에 state를 정의하고 onChange 함수를 사용하여 ContentBox의 값을 업데이트 하는 방식으로 코드를 작성하였지만, 이렇게 코드를 작성할 경우 ContentBox의 값이 변경될 떄 마다 상태가
변경되고 리렌더 되는 문제가 발생하여 ref를 사용하여 상태를 최적화 시켰습니다.

상태의 최적화가 제대로 이뤄지지 않아 props의 전달이 너무 많아진 사례입니다. 상태명에 '페이지'가 들어간 것들은 전부 페이지네이션과 관련된 상태들로 부모와 filter 파일에선 굳이 알 필요가 없습니다.
아래 코드를 보면 userListPerPage를 map 돌리는 과정에서 필요한 상태들이 페이지네이션으로 들어가지 못하고 상위 폴더로 나와 있습니다.
이 부분을 user_table.js로 분리하게 되면 부모로부터 자식이 과도한 props의 전달 받는 것을 줄일 수 있습니다.

before

after

[사례 04]
재사용이 되는 컴포넌트라면 상태도 전역으로 관리하는 것처럼 컴포넌트도 전역으로 사용할 수 있도록 컴포넌트화하는 것이 좋습니다.
최상위 폴더에 분리시켜 import하는 것이 전체적인 코드의 길이도 줄어들어 가독성이 좋아질 뿐 아니라 유지 보수에도 용이합니다.

아래와 같이 userList는 여러 파일에서 재사용이 됩니다. 아래 코드가 모든 파일마다 들어가 있다면 코드의 길이도 너무 길어지고
아래의 코드가 각각 페이지네이션과 필터 파일에 들어간다면 정작 어떤 코드가 페이지네이션/필터의 기능을 하는 코드인지 이해하기 어려워집니다.
따라서 임의의 user 배열을 생성하는 함수와 그 함수를 호출해 userList를 만들어내는 코드들을 전역으로 관리할 수 있도록 최상위 폴더 components에 분리시켰습니다.

after

---

7️⃣ 주소를 활용한 URL 히스토리 관리하기

• 필터링
• 페이지네이션
• 주소로 값 관리하기

위 상태 최적화를 고민하며 진행한 과제는 admin-toggle-page 입니다.
상태 최적화를 고민하며 필터링과 페이지네이션 기능을 구현했고 주소로 값을 관리해 뒤로가기가 가능하도록 했습니다.

• github repo 보러 가기 👉 admin-toggle-page
• 주소 관련 게시글 보러 가기 👉 URLsearchparams

---

8️⃣ 타입스크립트 개념에 대한 이해와 리액트 프로젝트 활용

• 타입스크립트 타입 정리한 게시글 보러가기 👉 TypeScript Types
• effective typescript 정리 게시글 보러 가기 👉 what's TypeScript
• 타입스크립트와 open API를 활용한 토이 프로젝트 👉 chap-chap
• chap-chap 회고 👉 chap-chap memoirs

---

9️⃣ 모비톤을 활용한 프로젝트 경험

• 타입스크립트 활용
• 무한스크롤링
• 백엔드 API 분석

여태까지 다른 페어와 함께 프로젝트를 진행하면서 백엔드 API를 제대로 분석하지 않았다는 사실을 뒤늦게 깨달았습니다. 백엔드가 어떤 형태로 데이터를 주고 있는지 확인을 제대로 하지 않은 채 임의로 퍼블리싱 및 기능을 구현한 뒤 API를 적용하느라 또 코드를 변경하느라 시간을 많이 낭비하고 있었습니다.
그래서 mobi에서의 마지막 토이 프로젝트를 진행할 때에는 시퀸스 다이어그램(sequence diagram), 썬더 클라이언트 등을 활용해 데이터의 형태와 내용을 확인한 후 진행할 수 있도록 했습니다.

• 토이 프로젝트 github repo 보러 가기 👉 postMobism
• postMobism 회고 게시글 보러 가기 👉 postMobism memoirs

---

after Mobi

mobi를 통해서 프로젝트를 어떻게 진행하면 되는지에 대한 전반적인 과정을 제대로 파악할 수 있었습니다.

하지만 mobi에 모여 있던 사람들은 아직 FE개발자들 뿐이었기 때문에 디자이너 그리고 BE개발자와의 소통 및 협업을 제대로 진행해 본 적이 없습니다.
FE개발자도 같은 강사님께 배운 사람들이라 컨벤션이나 폴더 구조 등 의견이 불일치하는 경우가 거의 없었습니다.

그래서 위의 부족한 부분들은 우선 nextJS 공부를 마친 뒤 외부 프로젝트를 통해 경험해볼 생각입니다.