목표와 회고

우테코 레벨2 학습 내용 총정리

Creative_Lee 2023. 6. 19. 16:24

레벨2 학습 내용 총정리🤪

그야말로 대 환장 파티...! 레벨2를 마무리했다.

레벨1의 고된 시절이 생각나지 않을 만큼 정말 빠르게 지난 간 8주였다.

학습 내용을 정리하며 흐려지는 기억들을 주워 담아보자!


그래서 뭘 배웠어?🤷‍♂️

개인적으로 몰입했던 키워드는 다음과 같다.

  • React
  • CDD(with storybook)
  • UI / UX
  • 협업

1. React

 

질긴 인연

2년 전 이맘때에 React를 처음 배웠었다. 그저 문법을 외우고 작업물을 찍어내기 바빴다.

'React란 무엇이고, 왜 많은 사람들이 사용하는가?' 제일 기본이 되는 것조차 모르고 사용했었다.

 

이번 레벨 2에서는 React의 '근본'에 대한 것을 많이 학습했다. 


1-1. why React?🧐

누군가 '왜 react를 사용하는 거야?' 물으면 나는 이렇게 답변할 것이다.

React는 복잡한 사용자 인터렉션과 이벤트, 이에 따른 UI의 변화를 직접 컨트롤 할 필요없게 추상화되고 최적화된 라이브러리야.
때문에 개발자는 UI에 집중해서 선언적인 개발이 가능해~!

 

레벨1에서 바닐라JS만으로 어플리케이션을 구현하면서 여러 불폄함을 느꼈기 때문에, 비로소 이해하게 되었다고 생각한다. 


1-2. React - keyword

  • virtual dom
  • jsx
  • key
  • context API
  • controlled & uncontrolled Components 
  • memoization
  • custom hook
  • 재사용 가능한 컴포넌트

위 키워드 외에도 정말 많은 React 관련 키워드를 학습했다.

각 키워드마다 기억에 남는 에피소드 하나씩은 꼭 있는것 같다...ㅋㅋㅋ

React 코어와 관련된 내용도 내용이지만, 개인적으로는 custom hook과 같은 로직 분리 부분에서 많이 성장한 것 같다. 

컴포넌트 하나에 1000라인이 넘어갔던 옛 시절은 이제 상상도 할 수 없다.


1-3. 결국 여전히 중요한것은 관심사의 분리😬

레벨1에서부터 이어져서 결국 특정 컴포넌트의 관심사는 무엇인지, 어디까지 알고 어디까지 몰라야 하는지가 중요하다고 생각한다.

비동기 통신과 같은 방해꾼들을 어떻게 잘 분리할 것인지 더 많이 고민해 봐야 한다.


2. CDD(with storybook)

Component Driven Development 
작은 부품 단위의 컴포넌트에서 시작해 페이지 단위까지,
Bottom -  Up 방식으로 UI를 만들어 나가는 개발 방법론을 말한다.

밋밋해서 재탕


2-1. CDD / Bottom - Up 개발의 짜릿함🤪

과거의 나는 컴포넌트라는 개념이 전무했다.

Top-down 방식, 어쩌면 아무런 방식도 없이 그저 적당히 커지면 나누면서 개발했었다.

파일이 커져가는 것을 인지하지 못했고, 어디서부터 어느 정도를 컴포넌트로 구분해야 하는지 기준이 없었다.

때문에 어수선한 코드와 애매한 크기의 컴포넌트들이 즐비했다.

 

그런 내가 어쩌면 인생 처음으로 찐 Bottom-Up 방식의 개발을 해본 것이 아닐까 싶다.

가장 작은 단위의 컴포넌트부터 설계하고 storybook의 도움을 받아 UI로 확인하며 작성하는 경험은 정말 신세계였다.

비록 내가 적용하고 경험한 것은 일부분이겠지만, 앞으로의 컴포넌트 설계에 큰 도움이 될것이라 생각한다.


2-2. storybook

컴포넌트 단위의 독립적인 UI 개발 환경을 지원하는 툴 

 

평생을 Top-down으로 개발했던 사람으로서 스토리북을 잘 사용하기까지 다소 긴 시간이 걸렸다.

작은 단위의 컴포넌트를 만들어 가면서 차차 그 가치를 알게 되었다.

 

프로젝트와 독립적인 환경에서 컴포넌트 개발이 가능하다는 점 외에도

문서화와 배포를 통해 다른 개발자 및 타 직군에게도 컴포넌트를 보여주고 설명할 수 있다는 점이 좋았다. 

(크루들의 질문에 컴포넌트만 쏙쏙 보여주는 게 얼마나 편했는지 모른다.) 

 

앞으로의 모든 react 프로젝트에는 무조건적으로 사용할 것이다.😀


3. UI / UX 🎨

레벨 1에서 레벨 2 초반부까지는 기술, 지식적인 것에 치중한 면이 있었다.

이 모든건 사용자를 위함임을 잠시 잊었다.

 

깔끔하고 좋은 코드 vs UI / UX

사실 'vs'라고 표현해도 될까 싶은 정도로 둘 다 놓칠 수 없는 것들이다.

둘 사이의 경계를 잘 잡아 발전시켜 나가야 한다.

한정된 기간 안에 결과를 만들어 내면서 밸런스 있게 둘 다 챙기는 법을 조금씩 알아가고 있다.


4. 협업

아! 재밌다...!😆

인생 첫 백엔드와의 협업이었는데 정말 재밌었다.

사람도 너무 좋았고, 첫 협업 회의도 재미있었고, 개발하는 과정도 재미있었다. 

우여곡절 끝에 API를 적용하고  정상적으로 돌아가는 어플리케이션을 확인했을 때 정말 기분 좋았다.

배운 것도 참 많았고 마냥 신기했다ㅋㅋㅋ


4-1. MSW

Mock Service Worker
서비스 워커(Service Worker)를 사용하여 네트워크 호출을 가로채는 API 모킹(mocking) 라이브러리

백엔드와의 협업을 진행하기 앞서, MSW의 덕을 봤다.

API 완성을 기다릴 필요 없이 예상 명세를 토대로 mocking 로직을 작성해두고, 이를 기반으로 개발을 진행했다.

 

기본적으로는 성공, 실패 응답에 대해서 mocking을 작성하고 테스트했는데,

백엔드의 작업이 예상치 못하게 길어지는 경우에는 백엔드 로직의 일부를 작성해서 더 다양한 경우를 테스트해도 좋을 것 같다.


4-2. SOP / CORS 관련 에러와의 첫 만남

Same Origin Poilcy(동일 출처 정책)
동일한 Origin(Protocol, host, port) 사이에서만 리소스를 공유할 수 있다는 정책 
Cross Origin Resource Sharing(교차 출처 리소스 공유)
Origin이 다르더라도 리소스를 공유할 수 있도록 하는 정책.
SOP정책에 의해 제한되었던 교차 출처간 리소스 공유가 가능해졌다.

 

'왜 안돼?'를 가장 많이 외치게 한 에러가 아닐까 싶다...😵

개발 환경(http)에서 배포 서버(https)로 API 요청을 해놓고 안된다고 징징거린 적도 있었고(혼자😅),

백엔드 로직의 설정 누락인 경우도 있었다.(ex. Access Control expose headers)

무엇 하나 쉽게 내어주지 않는 브라우저의 보안정책에 시원하게 담궈지고 나서야 방향을 잡아갈 수 있었다.  

본격적인 프로젝트를 진행하게 되는 레벨3, 4에서는 간단한 에러나 빠르게 해결된 해프닝도 기록해보는 습관을 가지려고 한다.


🍚 더 꽉꽉 눌러담은 레벨2 🍚

꺼억~

고봉밥 만큼 적절하게 표현되는 짤이 없더라.

이번에도 아쉽긴 하다.

워낙 방대한 내용이었기 때문에 놓친 부분도 많다.

그럼에도 매 순간 노력했기에 한 공기 가득 채워졌다.

이제 절반을 마쳤다.

앞으로 진행하게 될 프로젝트도 정말 기대된다!

힘내보자 도현아!