이론 과제 - To-Letter/To-Letter-front GitHub Wiki

glb & gltf 압축 - glTF-Pipeline으로 glb모델들의 용량 줄이기(아직 완성x 추가 할 예정)
-> 실행해본 후기로는 로딩시간만 줄여주고 브라우저에 렉은 똑같다.

241023 논의점 기준으로 앞서 설명해주신 내용에 실패하셨다는 내용 읽었습니다..
현실적으로 받고 출력해야하는 데이터가 너무 많고 커서 그런 것 같은데
저희 플젝이 실상 느려지기 시작한게 나무 모델 수가 늘어나면서였잖아요??
https://dosomthing.tistory.com/5
위 링크를 읽으면서 생각해봤는데 코드상에서 해결 보는건 로딩시간 줄여주는 정도로 그치는 것 같아서
이번엔 실질적으로 느리게 만드는 원인인 나무 모델을 처리해보는게 어떨까합니다!!
위 링크 읽어보면 3번에서 반복되는 Geometry를 합성해보라는 내용이 나오더라구여, 
또 불필요하게 큰 텍스쳐 해상도를 낮추라는 말도 있고...
나무 모델들을 여러개 만들어서 애초에 하나로 합치는 작업을 해보고자합니다... 
물론 3d 모델링과 연이 없던 탓에 시간이 좀... 걸릴 수 있을 것 같아요...

Context vs recoil
Context와 recoil 모두 상태 관리에 쓰이는 기능입니다.
Context는 리액트의 내장 기능이고 recoil 은 상태 관리 라이브러리라는 점.
제 생각에는 recoil을 쓰는 것이 좋다고 생각합니다. 저 시점에서는 관리할 전역 상태 값이 setMenuNumber 하나였지만 앞으로 계속 추가돼서 전역적으로 관리해야 합니다.
여기서 Context는 Provider로 하위 컴포넌트들을 감싸 하위 컴포넌트에서 Provider의 value 값을 공유해 주는 시스템입니다.
문제는 Context Api는 하위의 자식들이 Provider의 값이 변경되면 그 Context를 구독하고 있는 하위 자식들의 모든 것들이 다시 렌더링이 된다는 점에서 트리구조의 단점인 
props의 문제점은 되풀이된다고 생각합니다.
반면에 recoil은 atom이라는 공유 상태와 selectors는 atom의 상태를 get 함수나, set 함수로 업데이트 가능하게 해줍니다.
여기서 recoil을 선택한 이유는 recoil은 atom의 상태가 변경되면 구독하고 있는 컴포넌트들이 다시 렌더링 되면서 이걸 전역적으로 공유합니다.
recoil은 변경된 atom의 상태를 공유하고 있는 컴포넌트들만 다시 렌더링 한다는 점에서 쓸모없는 리렌더링을 없애주기에 당장 지금의 작은 전역 상태 관리가 아니라 미래의 
더 큰 전역 상태 관리에는 recoil이 적합하다고 판단했습니다.

사실상 PopupContext와 MenuContext는 Context 독립성 탓에 둘 중 하나의 값이 바뀐다고 해서 
다른 쪽을 구독하고 있던 컴포넌트들까지 리랜더링이 되지 않는다. 
다만 MenuContext의 값이 바뀌었을 경우  MenuContext를 구독한 컴포넌트들의 자식 컴포넌트(MenuContext를 구독하고 있지 않은)들도
 리랜더링 된다는 점에서 혹시 모를 불필요한 자원 낭비를 방지하기 위해 recoil을 사용하는 것이 좀 더 나은 선택이라고 생각한다.

또한, 위 커밋 번호 기준 

1. 계정 관련 모달 창의 끄고 켜고 관리
2. 켜져있다면, 어떤 창이 켜져야하는지(로그인, 회원가입, 소셜 회원가입, 메일 인증 등)
3. 메일 인증을 위한 값 저장

의 값들이 관리되어야 하고, threeJS를 사용하는 프로젝트 특성 상 모달 창으로 관리되어야 하는 값들이 더 늘어날 가능성이 있기 때문에 여러 상태 관리를 위해 recoil을 선택.

 - Debounce
 계속 반복되서 발생되는 이벤트들중 마지막 이벤트만 실행
ex) 실시간 검색 : 원래하면 문자 하나하나마다 요청을 계속 보내야하기때문에 굉당히 비효율적이며 서버에 부담이 갑니다.
하지만 Debounce를 사용하면 일정 delay로 설정한 시간을 넘긴 마지막 요청을 서버에 보내기 때문에 서버 부담도 내려가고 효율은 올라갑니다.
 - Throttle
 이벤트를 발생시키고 일정 주기마다 해당 이벤트를 실행X
ex) 무한 스크롤 : 스크롤을 할 때 데이터를 받아오는데 Throttle을 쓰지 않으면 스크롤 이벤트는 드래그 한번에 엄청 많은 이벤트가 발생합니다.
그래서 Throttle을 사용해서 요청을 일정시간동안 딜레이를 줘서 딜레이시간 주기에 맞춰 이벤트를 발생시키는 개념입니다.

Debounce와 Throttle는 JavaScript에서 자주 사용되는 최적화 기법으로, 
자주 발생하는 이벤트(ex> 스크롤, 입력 등)의 호출 빈도를 줄여 성능을 개선하는 방법. 
개념은 비슷하지만 동작 방식이 다름

1. Debounce (디바운스)
 - Debounce는 여러 번 발생하는 이벤트 중 마지막 이벤트만 실행.
   이벤트가 발생하면 타이머를 설정하고, 일정 시간이 지나기 전에 동일한 이벤트가 다시 발생하면 타이머를 리셋. 
   설정된 시간이 지나면 마지막 이벤트가 실행.
 - 검색창 자동 완성(동시에 수많은 요청이 일어나지만 마지막 시간을 기준으로 발동해야 함.)

2. Throttle (쓰로틀)
 - Throttle은 이벤트가 여러 번 발생하더라도 일정 시간 간격으로만 실행되도록 제한. 
   지정된 시간 동안에는 한 번만 이벤트가 실행되며 그 시간 이후 다시 실행 가능.
 - 스크롤 이벤트(마찬가지로 여러 번 요청이 일어나지만 스크롤 이벤트가 일어났다는 사실이 중요, 일정 시간 내에 여러 번 발동해서는 안됨.)

1. 시멘틱마크업
시멘틱마크업이란 HTML로 웹의 골자를 만들 때 div를 마구잡이로 붙이는 형식이 아닌 의미론적(Semantic) Markup을 이용해서 웹의 뼈대인 HTML을 구성하는 것입니다.
예를 들어 웹 front의 첫 공부 단계인 HTML을 공부하다 보면 header, nav, main, section, footer 등의 태그들을 봤을 것입니다. 하지만 만들다 보면 위의 태그들을 하나
하나 알맞게 사용한 적은 많이 없습니다. 보통 div안에 div를 넣어서 div지옥을 만들어버립니다.

사실 이러한 의미 없는 마크업은 단점이 명확합니다.
 1) 당연하게도 가독성이 떨어진다. 자신이 만든 수많은 div태그들 사이에서 수정해야 할 부분을 잘 찾지 못한 경험은 모두 있을 겁니다.
 2) 중요! 검색어 노출에 불리하다. SEO(Search Engine Optimization) 검색 엔진 최적화 점수가 높을수록 웹사이트는 검색 최상단에 노출되게 되는데 의미 없는 마크업을 
 사용하면 봇은 HTML요소들이 어떤 목적인지 파악하지 못하기 때문에 자연스레 SEO점수가 낮아집니다.
 3) 웹 접근성에 좋지 않다. 웹 접근성은 모든 사용자, 사회적 약자를 포함하는 사용자에게 웹 콘텐츠를 공평하게 접근할 수 있도록 보장하는 개념입니다. 사회적 약자를 위
 한 많은 소프트웨어가 존재한다. 하지만 시멘틱마크업에 기초하지 않은 의미 없는 마크업을 이용해서 웹사이트를 만든다면 위에서 말한 사회적 약자를 위한 소프트웨어들이 
 작동하는데 어려움을 줍니다. 결과적으로 웹 접근성을 떨어뜨리는 것입니다.

2. SSR(server side rendering) vs CSR(client side rendering)
SSR은 서버 사이드 렌더링으로 말 그대로 서버에서 완전한 HTML을 보내주는 형식입니다. 서버에서 완전한 HTML파일을 받기 때문에 웹사이트의 첫 로딩이 빠르다는 장점과 초
기 HTML파일에 모든 데이터가 있기 때문에 SEO에 관련해서 봇이 데이터 수집이 가능해서 SEO점수가 높습니다.(검색어 노출에 유리)
하지만 단점으로는 새로고침 때마다 서버에서 데이터를 받아와야 하기 때문에 요즘같이 웹사이트에 정보가 많은 시대에는 서버에 부담을 주고 초기 페이지 이동속도를 제외하
고는 나머지 페이지 이동 속도는 느립니다.
CSR은 클라이언트 사이드 렌더링으로 클라이언트(브라우저) 측에서 서버에서 데이터를 받아 화면을 그리기 시작하는 방식입니다. HTML 파싱부터 JS파일 읽어오기까지 브라우
저에서 담당하기 때문에 첫 화면을 그리는데 ssr비해 시간이 좀 걸립니다. 그리고 검색엔진 최적화 부분에서 초기에 HTML을 받아오는 데 시간이 걸려 ssr보다는 검색엔진 최
적화 성능은 떨어집니다.
하지만 첫 페이지 이후에는 ssr처럼 항상 서버에 데이터를 요청해서 페이지를 새로고침하는 게 아니라 처음에 이미 모든 데이터를 받아왔기 때문에 그 정보만 수정하여 ssr보
다 빠르게 페이지 로드가 가능하여 UX측면에서는 도움이 됩니다. 그리고 필요한 데이터만 서버에서 받아오므로 서버에 부담도 줄어듭니다.

3. 웹 접근성
웹의 모든 사용자(사회적 약자를 포함한)에게 평등하게 웹 콘텐츠에 접근할 수 있는 것을 말합니다.

4. 웹 표준
웹 표준은 W3C에서 권고하는 웹에서 표준적으로 사용되는 기술이나 규칙을 말합니다.
사용자가 어떠한 브라우저, 운영체제에서 웹사이트를 보든 동일하게 보이고 정상적으로 작동할 수 있는 규칙들을 담고 있습니다.
웹 표준을 준수하면 유지 보수의 용이, 검색엔진 노출, 웹 호환성 향상, 웹 접근성 향상 등의 장점이 있습니다.

5. 크로스 브라우징
크로스 브라우징이란 우리가 개발한 웹이 다양한 브라우저에서 웹을 만든 개발자의 의도에 맞게 작동하는 것을 말합니다. 말하자면 다양한 브라우저의 버전들과의 웹의 호환
성을 말하는 것입니다. 다양한 브라우저의 버전에서 웹이 동일하게 만드는 것이 아닌 동등성(등가성)을 갖춰야 한다는 것입니다. 동등성에 대한 명확한 기준은 없으나 다양한 
브라우저가 있듯이 브라우저의 렌더링 엔진(페이지를 렌더링 할 때 실질적으로 작업을 하는 엔진)도 다르기 때문에 이에 맞추고 서비스하는 대상에 맞춰서 개발하는 것이 좋
다고 생각합니다.
크로스 브라우징은 여러 브라우저 버전에서 웹 페이지, 웹 애플리케이션 등을 개발자가 의도한 대로 보여줄 수 있기에 웹 표준, 웹 접근성과 더불어 중요한 개념이라고 생각
합니다.

1. 시맨틱 마크업
HTML 요소가 그 콘텐츠의 의미를 나타내도록 구조화한 것. 시맨틱 마크업을 사용하면 웹 페이지의 내용이 더 의미있게 설명되고, 
브라우저나 검색 엔진 혹은 스크린 리더 같은 기계가 페이지를 더 잘 이해할 수 있다. 현재 App.tsx 안의 Home.tsx 안에서 
캔버스를 통한 threejs 랜더링을 지원하고 있기 때문에 외부 요소에서 시맨틱 마크업을 처리해주는 것도 좋을 것 같다.

2.csr
서버에서 인덱스라는 HTML파일을 클라이언트에 보내주면 CSR에서 사용되는 가상 추상적인 id root와 어플리케이션에서
 필요한 자바 스크립트 링크만 들어가 있다. html은 비어져 있기 때문에 처음에는 접속하면 빈화면만 보이고,
서버로부터 필요한 로직, 구동시 사용되는 프레임워크와 라이브러리 및 소스코드가 담긴
(링크된)어플리케이션 자바스크립트를  다운 받아 동적으로 HTML을 생성하여 최종적인 어플리케이션을 보여주게 된다.
TTV와 TTI가 동시에 보장. 다만, 첫 화면이 보이기까지 시간이 걸리며 ssr에 비해 상대적으로 seo가 좋지 않다.

3. ssr
클라이언트가 웹 사이트에 접속하면 서버에서 필요한 데이터를 모두 가져와서 HTML 파일을 만들게 되고 
이렇게 잘 만들어진 HTML 파일을 동적으로 조금 제어할 수 있는 소스코드와 함께 클라이언트에게 전송함.
클라이언트 측에서는 잘 만들어진 HTML 문서를 받아와 바로 사용자에게 보여줄 수 있음. CSR을 사용했을 때보다
페이지 로딩이 빨라지며 모든 컨텐츠가 HTML에 담겨져 있기 때문에 seo가 조금 더 효율적이다. 
TTV자체는 빠르나, 필요 js다운까지 시간이 걸려 TTI와 조금 더 느림.

4. 웹 표준
웹 표준이란 웹 콘텐츠와 애플리케이션이 일관되고 효율적으로 작동할 수 있도록 규정된 표준을 말함.
이 표준은 웹 기술이 호환성과 접근성을 높여 다양한 디바이스와 브라우저에서 동일하게 작동하도록 보장함.
웹 표준을 준수하면 웹사이트나 웹 애플리케이션이 유지보수하기 쉽고, 다양한 플랫폼에서 일관된 사용자 경험을 제공 가능.

5. 웹 접근성
웹 접근성이란 모든 사용자가 장애나 제약 없이 웹 콘텐츠를 쉽게 접근하고 사용할 수 있도록 보장하는 것을 의미.
시각 장애, 청각 장애, 운동 장애, 인지 장애 등 다양한 장애를 가진 사용자뿐만 아니라, 인터넷 연결이 불안정하거나
구형 장치를 사용하는 사람들도 포함됨.

6. 크로스 브라우징
웹사이트나 웹 애플리케이션이 다양한 웹 브라우저(Chrome, Firefox, Safari, Edge, Internet Explorer 등)에서
일관되게 잘 작동하도록 개발 및 테스트하는 과정을 의미. 사용자들이 사용하는 브라우저는 서로 다른 렌더링 엔진을 가지고 있기 때문에,
웹 표준을 준수하지 않는 브라우저나 고유의 해석 방식 때문에 문제가 발생할 수 있다.
크로스 브라우징을 통해 이러한 문제를 최소화하고, 최대한 많은 사용자가 동일한 경험을 할 수 있도록 보장한다.