1주차

1. Next.js

SEO

• 첫 화면이 외부 API 에서 받아온 지도 데이터에 의존하기 때문애 동적 metadata 를 사용하기 어렵다

• 정적인 metadata 를 쓸거면, Next.js 를 안써도 된다

랜더링 기법

• 첫 화면 컨텐츠가, 서버에서 랜더링하는게 아니라, 사용자의 위치에 기반해서 API를 쏜 결과를 보여주는 방식이기 때문이다.

• SSR 이 의미가 많이 없다

• ISR, SSG 를 사용할 페이지가 별로 없다

• 그런 랜더링 기법들을 통한 크게 의미있는 성능 향상을 기대하기 어렵다

넥스트에서 제공하는 컴포넌트

• 이미지, 폰트, 로딩이, 에러

동환, 원석의 의견

• “React를 사용하여 새 앱이나 사이트를 구축하는 경우 프레임워크를 사용하는 것이 좋습니다”

• 위 이미지와 같이 Nextjs(app router) = react18로 흐름이 진행이 되고있다. 따라서 nextjs로 처음부터 진행을 하는것이 react(csr)로 만들고 마이그레이션 하는 것보다 나을 것 같다.

• next.js에 대해 사용하지 않고, 잘 알지 모르는 상태에서 next의 필요성에 대해 알 수 있을까?
• 공식문서와 구글링을 통해 next의 장단점과 필요성을 모두 단정짓는건 섣부른 판단일 수 있다.
• 우리가 이 기술에 대해 체감하지 못함 (POC를 검증을 이렇게 하자!)

• ❗ 거인의 어깨에 올라가보자

• 직접 문제를 해결해보는것도 좋지만 next가 왜 이걸 제공할지를 고민해보는게 더 좋지 않을까?
• csr을 사용하면서 어려운 점들이나 문제 찾아서 최적화
• next가 제공하는 것들 사용 → 왜 이것들을 제공하고 어떤 문제를 해결할까? ⇒ 이쪽이 더 많은 문제와 문제 해결 방식을 공부할 수 있다고 생각한다

• Next.js를 사용하는게 편하다고 하지만 불편한 점들 또한 분명히 나올 것이다
• ex) server component에는 document 객체가 없다
• server component에서도 돌아가는 hook을 만드는 경험을 하는건 의미가 있을 수 있다
• server component를 띄워야 하기 때문에 서버 자원에 대한 고민 또한 할 수 있다
• 이 불편함을 느끼고 왜 이렇게까지 하면서 ssr을 사용하려고 하는지도 고민하면 어떨까?

• 나중에 데브코스 끝나고 유지보수까지 생각하면 처음부터 ssr로 시작하는게 나을것 같다.
• 프로젝트 완성 이후까지도 생각해보고 싶다
• csr ⇒ ssr 마이그레이션? 힘들 수 있다
• ssr ⇒ csr 굴러가게 할 수 있다.

• 결론: next 사용에 대해 한번 더 생각해보기 (우리가 nextjs를 필요없다는 것을 판단할 수 있나?, 다음 플젝에서도 이런 고민은 계속 된다(뫼비우스의 띠))

2. 상태관리 도구로 뭘 쓸지

• Redux Toolkit
• 참고할 자료 기준으로 가장 많음

• Zustand
• 라이브러리 사이즈가 조금 작다
• 실제로 검증 가능한가?

• Jotai
• 자료가 많이 없음

• Recoil
• 무겁다

3. Webpack vs Vite

• 동환, 원석
• vite는 빠르고, 간편하기 때문에 써야한다
• 웹팩은 레거시가 될 것 같다
• DX 에서 번들러보다 프론트 개발(성능, 에러핸들링)에 더 시간을 투자하고 싶다
• 한달 반 동안 선택과 집중을 해야 하는데, 번들러에 들이는 시간비용을 줄이고 싶다.
• vite를 쓴다면 번들러의 개념, webpack, vite의 개념, vite를 사용해야하는 이유를 깊게 알자!

• 혜진
• 빠른 성능과 간편함이 우리가 한게 아니다
• 어필할 수 없다
• vite 는 빠르고 간편하니까 언제든 시작할 수 있다
• 써봤는데 학습곡선이 낮아서 굳이 이걸 공부? 써본 경험?

4. Test

5. UI

• 동환, 원석
• 디자인 시스템을 못 만들면 오히려 약점이 될 수 있다.
• 우리만의 디자인 시스템이 의미가 있을까?
• 다른 사람들이 우리의 디자인 시스템을 사용할 가치를 느끼게 할 수 있을까?
• 우리의 디자인 시스템에 신뢰성을 쌓기 어렵다
• 회사에서는 실제로 디자인 시스템 어떻게 믿어요? 하고 안 쓰는 경우가 많다
• 디자인 시스템을 만들려면 요구사항을 확실히 알고 만들어야 하는데 우리는 가정을 하고 만들어야 해야할텐데 이게 맞을까?
• 디자인 시스템을 만든다는건 여러 프로젝트에서 필요하고 재사용할때 도움이 될 때 의미가 있는데 다른 프로젝트에서도 우리의 디자인 시스템이 도움이 될지 알 수 있을까?
• 잘 짜여진 디자인 시스템이 많다. 잘 짜여진 디자인 시스템의 인터페이스를 사용해보고 개념을 내 것으로 흡수하고 싶다
• 결론 : 디자인 시스템까지 만드는 것은 과한 것 같다. ui library를 사용해보고 내부에 대해 고민해보고 싶다, or 컴포넌트를 만드는 것도 괜춘

6. 디자이너

• 동환, 원석
• 디자이너와 함께하면 디자이너와 협의 하는 시간이 오래 걸릴수 있다
• 하지만 이런 과정이 의미있다고 생각한다
• 디자이너는 사용자에게 동기부여해주는 사람이고 우리는 이것을 구현해주는 사람
• 우리는 구현에만 초점을 맞출 수 있는데 실제 프로덕션에서는 사용자에게 만족을 주는게 중요하다
• 보통 프론트엔드 개발에서 기능 구현에 집중할 때가 많은데 디자이너와의 협업에서 그외의 부분들을 생각해볼 수 있을 것 같다
• 결론: 디자이너와 함께 해보자
 

• 원석
• 4명이서 디자인을 쪼개서 해보는것도 도움이 될 것 같긴 하다.
• 디자인을 따라서 기능을 만드는데 개발자가 디자인을 하면 설계(흐름)가 용이할 것 같아서(?)
• 디자인을 할 줄 안다는 것이 단점이 될 순 없다. (UI / UX에 대한 역량 검증)

7. Tanstack/react-query

8. npm vs yarn vs yarn berry(PnP) vs pnpm

9. sentry 오버 엔지니어링일까요…?

태스크를 어떤 단위로 나눌지 조언해주실 수 있을까요

• 저번 프로젝트에서 태스크를 너무 크게 나눴던 것 같습니다

• 아니면 일정 산정과 태스크 분배에 대한 참고하기 좋은 자료