개발일지 (12월 5주차 & 1월 1주차 회고)

 

 

 

Overview

 

회사에서 새롭게 읽게 되는 여러 코드들을 통해, 그리고 코로나 19의 거리두기 강화로 인한 재택근무로 인해 접하게 되는 콘텐츠의 양과 질이 동시에 높아졌던 한 주였던 것 같다. 무엇보다 월간 750만 유저가 사용하는 글로벌 서비스(Qanda)를 프로덕션 하는 회사이니만큼, 그만큼의 트래픽을 감당하기 위한 여러 아키텍처들을 보고, 또 질문하면서 어깨너머로 다양한 코드들을 익힐 수 있어서 굉장히 좋은 경험을 했던 한 주였다. 

 

 

Nextjs

 

Nextjs는 React JS에서 서버 사이드 렌더링(SSR)을 할 수 있도록 지원해주는 프레임워크이다. 사용해 본 결과, React JS에서 Next JS를 사용한다는 느낌보다는 Nextjs 프레임워크 내에서 React를 사용하는 느낌이 더 강했다. 공식 문서에서도 리액트 '라이브러리'가 아닌 프레임워크라고 소개하고 있고, 그만큼 자체적으로 지원하는 기능들이 많다. NextJS에 대해서는 여러 특징들도 많고, React 생태계에서 가장 잘 알려진 SSR 프레임워크이니만큼 나중에 제대로 관련된 포스팅을 진행해보려고 한다.

 

 

nextjs.org/(NextJs 공식문서)

Next.js by Vercel - The React Framework

 

클라이언트 사이드 렌더링(CSR)이 아닌 서버 사이드 렌더링을 하게 되면 초기에 HTML마크업을 서버에서 하게 되므로 시간이 조금 걸리지만, 클라이언트 쪽에서 첫 뷰가 나타나는데 걸리는 시간이 상대적으로 적기 때문에 대부분의 경우 더 좋은 사용자 경험(UX)을 제공한다. 특히 콴다와 같이 개발도상국등 인터넷 속도가 빠르지 않거나, 사용자가 사용하는 기기의 성능이 그리 좋지 않은 경우, 미리 서버에서 props를 받아서 HTML마크업을 완성시켜서 뷰를 보내주고 나중에 이벤트 핸들러 등만 붙이는 방식의 동작이 훨씬 더 나은 UX를 준다. 

 

 

이 과정에서 기존에 알고 있었던 Render의 개념과 다른 Hydrate라는 개념을 알게 되었다. CSR의 경우 맨처음에 서버로부터 빈 HTML이 넘어오기 때문에 자바스크립트 파일 실행을 통해 HTML의 Root Div에 가상 돔을 Attach 하여 뷰를 그린다. (React기준). 때문에 '렌더링' 과정이 필요하다. 하지만 Nextjs를 사용한 SSR의 경우 이미 마크업이 완성된 HTML이 넘어오기 때문에 이를 또다시 렌더링 하는 것은 리소스 낭비다. 따라서 HTML의 마크업에 맞추어 EventHandler 등 페이지를 Reactive 하게 만드는 과정들이 필요한데 이를 Hydrate라고 한다. Nextjs는 이를 알아서 해주기 때문에 Nextjs를 쓴다면 이에 대해서 심도 깊게 고민할 일은 잘 없을 것 같지만, 이면에 깔린 개념이 CSR과 다르다는 것을 이해하게 되었다.

 

(다음은 Nextjs공식문서에서  hydrate에 대해 안내하고 있는 글이다.)

nextjs will hydrate your application client-side to give it full interactivity (Automatic Static optimization)

 

 

Javascript

 

스위프트(Swift)를 틈틈히 공부하면서 자바스크립트와 유사한 점이 많다는 생각이 많이 들었다. 공부하는 김에 새로운 개념을 배울 때마다 이 개념이 자바스크립트에서는 어떻게 사용되고 있고, 어떤 차이점이 있는지를 비교해보는 것도 꽤 재밌을 것 같다는 생각이 들어서 틈틈이 정리해보려고 다짐했다. 

 

 

이번 주(라기엔 토요일이지만)에는 스위프트의 메모리 모델을 살펴보면서 자바스크립트의 메모리 모델과 상당히 유사한 점이 많아서 자바스크립트의 메모리 모델을 다시 한번 살펴보았다.

 

 

부끄럽지만, 원시 타입의 경우에도, '값'이 아닌 '메모리 주소'를 가리키고 있다는 사실을 새로 알게 되었다. 

let val1 = 1;
let val2 = 1;

위와 같이 선언하면, val1, val2는 다른 메모리 주소를 갖지만, (각각의 주소가 가리키는 값은 당연히 1, 1)

 

let val1 = 1;
let val2 = val1;

위와 같이 선언하면 val1, val2는 같은 메모리 주소를 갖는다는 점이었다.

 

 

그 외에도 참조형 변수를 선언하면, 해당 변수의 이름과 참조(Reference)는 런타임에 스택에 저장되지만, 해당 참조가 가리키는 진짜 값(예를 들면 배열이나 객체 그 자체)은 힙에 저장된다는 점들을 다시 한번 확인할 수 있었다.

 

medium.com/@ethannam/javascripts-memory-model-7c972cd2c239

JavaScript’s Memory Model

 

 

iOS

 

이번주부터 iOS공부를 시작했는데, Stanford에서 진행하는 SwiftUI를 사용한 iOS 개발 강의가 있어서 이 커리큘럼을 충실히 따라가려고 한다. 단순히 클론 코딩을 넘어서서 Swift라는 언어 자체에 대한 공부와, 여러 과제들을 통한 학습 시스템이 잘 되어 있는 것 같다.

 

 

지금 이 회고를 쓰는 시점에서 Lecture4 까지 이수한 상태이며, 최대한 1월 중으로 끝내고 올해 상반기 안으로 앱스토어에 앱을 하나 올리고 싶다는 목표가 생겼다.

 

cs193p.sites.stanford.edu/

CS193p - Developing Apps for iOS

 

스위프트라는 언어 자체가 자바스크립트와 비슷하다는 느낌을 상당히 많이 받았다. 자바스크립트가 '프로토타입'을 통해 OOP의 느낌들을 구현한다면, 스위프트는 '프로토콜'을 통해 이를 구현할 수 있다는 점에서 가장 크게 그렇게 느꼈던 것 같다.

 

그 외에도 HStack, ZStack, Geometry Reader 등을 통해 레이아웃을 구성하고 있는데, 이 부분이 상당히 React와 비슷하다는 생각이 들어  아직까지는 무리 없이 진행하고 있는 것 같다는 느낌이 들었다.

 

추후에 계속 iOS공부를 하면서 멀티쓰레딩, 최적화와 같은 이슈들에도 관심을 갖고 공부하면 좋을 것 같다는 생각이 들었다.

 

Etc

blog.shiren.dev/2020-06-15-%EC%9C%A0%EC%9A%A9%ED%95%9C%ED%85%8C%EC%8A%A4%ED%8A%B8%EC%BC%80%EC%9D%B4%EC%8A%A4%EB%A5%BC%EC%9C%84%ED%95%9C%EA%B0%9C%EB%B0%9C%EC%9E%90%EC%9D%98%EC%9E%90%EC%84%B8/?fbclid=IwAR2XHgIfCxMrAUCyB8P7vB2l2hlyF4t-AMjh869hYsu5tcFlK24elFpsd4Q

유용한 테스트 케이스를 위한 개발자의 자세