2024.03.29 TIL

어제 아주 중요한 깨달음 / 배움을 얻었다. 또 거인의 어깨에 선 덕분에..!!

길고 자세하게 쓰고 싶지만, 내일이 크루 배포 마감일인 이유로, 어제 공부한 내용을 끄적인 것을 여기 til 에도 적어본다. 조만간 시간을 어떻게든 내어서 이런 플랫폼쪽 지식을 좀 더 쌓아보고 싶다. 

 

SSR SSG 의 차이 

SSR 서버에서 html 을 만들어서 클라에 주면, 클라에서 그 html 파일을 가지고 렌더링. 

그렇게 되면, 빈 html 파일에서부터 시작하는 게 아니니까 속도가 빠르다는 장점이 있음. 대신에, 비동기적으로 데이터를 요청하고, 다시 서버에서 렌더링을 하기를 기다리고 이런 식으로 해야함. 

 

반면 SSG 는, 그걸 꼭 서버가 해야하는가? 서버에서 한 번 만든 html 파일을 어딘가에 꽁쳐두고, 걔를 가지고 와서 쓰는 것. 따라서 변경이 많지 않은 정적 사이트일수록 SSG 를 사용하는 것이 좋음. 

SSG 설정 시, next Image 를 사용하면 아니 되는데, 이유는 서버를 거치지 않기 때문. Next Image 의 경우 서버에서 한번 이미지 최적화를 거쳐서 사이즈를 리사이즈 해서 넘겨주는 것인데, 서버가 없으니 에러남. 그래서 이걸 해결하려면 cloudflare Next Images 같은 걸 써야함. 플구 크루 둘다 이걸 쓰고 있음. 

 

Yarn 3 가 yarn berry node modules 안 쓰는 것보다 더 빠름. 

 

Yarn install 은 상위 폴더에서 하면 안됨.. 그렇게 되면 밑에 프로젝트에서도 상위 폴더를 자꾸 참조하기 때문에 일일이 다 지워줘야함.. 

 

강제푸쉬는 되도록 하면 안됨. 다른 사람의 코드를 덮어 쓸 수 있기 때문에. 근데 대신에 git push --force-with-lease 이 친구를 쓰게 되면, 다른 사람의 코드를 덮어 쓰게 되는 경우, push 가 중단됨. 

 

 

어제의 깨달음 중 큰 거 하나는, 어떤 개념을 공부할 때 그걸 쉽게 내 언어로 표현해서 설명하는 것이 공부에 큰 도움이 된다는 것이었다. 

근데 나는 지금까지 어려운 기술 문서를 읽고, 한 번도, 단 한 번도 그걸 내 언어로 다른 사람에게 쉽게 설명해준 적이 없다. 그만큼 겉멋만 들고 실속은 없었다는 뜻이겠지.. 

근데 이게 참 쉬워보이지만 사실은, 그 어려운 내용을 정확하게 이해하고 있어야 설명할 수 있기 때문에 제일 어려운 방식인 것 같다. 그치만 이런 노력을 게을리 하면 안 되겠지..

 

++사실 오늘 아침에 리팩토링 2판을 읽었는데, 요게 내용이 나에겐 꽤 생소했다. 그 중 가장 기억에 남는 내용을 끄적여 보자면, 처음부터 완벽한 설계를 해도, 코드는 계속해서 고쳐지니까 프로그램의 무결성이 지켜지지 않는다. 해서 지속적으로 코드를 정리하는 것이 필요하다. 이때 정리는 어떤 변수의 상속 관계를 바꾸고, 함수를 분리하고, 변수를 제거 혹은 변경하는 간단한 방식의 조합으로 이뤄지는데 그게 바로 리팩토링이다. 

 

=> 이걸 좀 더 쉽게 내 언어로 설명하자면... 어떻게 한 번에 완벽하게 프로그램을 짜겟어~ 일단 한 70% 쯤 설계하고, 계속해서 "잘" 수정하면서 유지 보수하는 게 더 생존에 유리하더라~ 인 것 같다. 하하.. 이런 식으로 좀 남에게 쉽게 설명한다는 마인드로 앞으로도 꾸준히 어려운 기술들을 공부해나가야겠다. (내 언어로 바꿔보니 어렵게만 느껴졌던 것들이 재미있어지는 것 같기도 하고~ㅋㅋㅋㅋ)

 

 

아.. 그리고 또 내가 공부해야 할 사항들이 있는데, 

 

일단 스쿼시 머지..! 디벨롭 브런치에서 메인 브런치로 머지해서 프로덕션 배포할 때, 왜 스쿼시 머지를 쓰면 나중에 골이 아픈지, 왜 스쿼시 머지를 스면 브랜치가 날라가지는 것과 같은지 이유를 잘 모르겠어서 그거 공부해야 한다. 

그리고 현재 메이커스 크루에서 쓰고 있는 stitches 같은 경우는 서버 컴포넌트 지원을 포기해서.. 다른 라이브러리로 마이그레이션이 필요한다. 그래서 염두에 두고 있는 라이브러리가 panda 랑 emotion 이랑 vanilla-extract 등등이 있는데, 이유 있는 라이브러리 선택을 하고 싶어 고민중이다. panda 의 경우, 좋은 것은 stitches 에서 마이그레이션 하는 법이 있어서이고, 또 만약 어떤 값이 2번 이상 쓰였을 경우 이를 복사하고 변수화 해서 atomic 한 처리가 가능하기 때문에 좋다. 예를 들어, stitches 의 경우에도 이 기능을 제공해서, 개발자 도구를 켜서 element 를 찝어보면 var(-colors-white) 이런 식으로 나오는 걸 확인해볼 수 있는데, 이 변수의 경우 중복되는 값의 경우 stitcehs 가 알아서 변수화를 진행시켜서 메모리 사용량을 획기적으로 줄일 수 있었던 것이다. 

근데 어쨌든.. 제일 중요한 건 동료가 썼을 때 어떻게 하면 가장 편리하게 쓸 수 있게 해줄 것인가.. 인 것이고, 그쪽 방향으로 계속해서 생각하면서 라이브러리를 골라야할 것 같다. 

아, 또 내가 지금 구현 중인 모임 둘러보기 서비스에서 홈 화면 개선하는 것 중에 masonrygrid 라이브러리를 써서 구현했던 것을 반응형으로 만들어야 하는 것이 있었는데, 우리가 지금 SSG 환경이고, 따라서 Next/Images 를 쓰지 못하는 상황이기 때문에, 이미지 리사이징 툴로 wsrv.nl 을 사용하고 있는데 이게 debouncing 이 컴포넌트에 걸려 있어서 (줄어들 때마다 resize 를 하면 리소스가 그만큼 많이 드니까, debounce 를 걸어두었음.) 요걸 해결하려면.. 방법을 좀 뒤젹뒤젹 해봐야할 것 같다.. 

또 넥제 12 -> 13 마이그레이션도 사실 앱 라우터를 써보고 싶어서 였는데,,, 사실 현재 SSG 로 클라우드 플레어 배포가 되어 있고, 서버 컴포넌트를 적극적으로 쓸 일도 없고, SEO 도 필요없고,, 그런 상황에서 내 욕심에 앱 라우터로 마이그레이션을 쓰는 게 맞을까 하는 생각도 좀 들었다. 이때 edge run time 에 대한 것도 좀 공부를 해봐야할 것 같다. 그래도 다행히 클라우드 플레어 과금은 진행되지 않을 듯..! 

 

 

 

아 아 아 아ㅏㅏㅏㅏㅏㅏㅏㅏㅏ

나는 정말정말 모르는 게 많타. 헤헤 그치만 그래두 성장하고 있고, 앞으로 더더더더 성장할 거고, 그렇게 성장하고 있는 나를 볼 때 행복하니까!! 긍정적으로 생각하고, 모르는 거 많이 물어보면서 알아가야겠다. 오늘 하루도 화이팅하쟈 현수야. (그리고 이 글을 읽는 모든 사람들도 다 행복하고 긍정긍정한 하루 보내길!!)