12월 2주차 기록

인생은 회전목마

프론트엔드 공부

자바스크립트는 왜 프로토타입을 선택했을까

이미 다 아는 내용이라고 생각했는데, 철학적인 접근을 바탕으로 자바스크립트의 프로토타입, this, 호이스팅을 다루고 있는 점이 무척 흥미롭다.

C++, Java 등 잘 알려진 객체지향 프로그래밍 언어의 class는 본질을 가리키는 이데아와 실존하는 현실을 구분하는 개념으로 이해하면 쉽다.

class Chair {
...
}
Chair myChair = new Chair();

Chair 클래스는 이데아에 존재하는 추상적인 개념이며, 현실세계에 실제 의자를 만들기 위해서는 new 키워드를 사용하여 구체적인 인스턴스를 생성해야 한다.

플라톤의 이데아 이론은 아리스토텔레스에 이어져 분류(Classification) 개념으로 정립된다.

개체의 속성이 동일한 경우 개체 그룹이 같은 범주에 속한다.

자바스크립트의 프로토타입은 이 ‘분류’ 이론을 정면으로 반박한다. ‘승리’와 ‘패배’와 같은 명확한 결론이 없는 것이다. 어떤 개체들의 공통 속성을 정의하는 대신, ‘의미’에 초점을 두었다.

의미사용이론은 비트겐슈타인 일생의 후기에 등장한 이론으로, ‘사용(use)’에 의해 ‘의미(meaning)’이 결정된다는 의미다. 즉 단어의 ‘진정한 본래의 의미’란 존재하지 않고 ‘상황과 맥락에 의해서 결정된다’는 것이다.

의미사용이론과 유사한 것이 바로 가족 유사성(Family Resemblance) 이다. 갈색 머리, 안경, 수염 등 한 가족이 공유하는 전형적인 특징들은 모든 가족 구성원에게 적용되는 특성은 아니지만, 우리는 이를 ‘가족’으로 분류한다.

Rosch의 프로토타입 이론은 이를 바탕으로 한다. 우리는 사물을 분류할 때 가장 유사성이 높은 것부터 순서대로 등급을 매기는데, 이때 가장 높은 등급을 가진 객체가 바로 원형 즉 프로토타입이라는 것이다.

객체는 ‘정의’로부터 분류되는 것이 아니라 가장 좋은 보기(prototype)로부터 범주화된다. 이러한 분류 체계에서는 새로운 대상을 추가하여 분류해야 할 때, 새로운 대상의 몇 가지 특징만 원형(prototype)과 비교확인만 하면 된다.

여기서 또 중요한 것은, 같은 단어라 할지라도 누가 어떤 상황(context)에서 접하느냐에 따라 의미가 달라진다.

프로토타입 이론은 프로토타입 기반 객체지향 프로그래밍 언어인 자바스크립트에 구현되어 있다.

프로토타입 기반 OOP 언어의 특징은 다음과 같다.

• 개별 객체(instance) 수준에서 메소드와 변수를 추가
• 객체 생성은 일반적으로 복사를 통해 이루어짐
• 확장(extends)은 클래스가 아니라 위임(delegation)
  • 현재 객체가 메시지에 반응하지 못할 때 다른 객체로 메시지를 전달할 수 있게 하여 상속의 본질을 지원
• 개별 객체 수준에서 객체를 수정하고 발전시키는 능력은 선험적 분류의 필요성을 줄이고 반복적인 프로그래밍 및 디자인 스타일을 장려
• 프로토타입 프로그래밍은 일반적으로 분류하지 않고 유사성을 활용하도록 선택 결과적으로 설계는 맥락에 의해 평가

변수의 의미는 어휘적인(lexical), 실행 문맥(execution context) 에서의 의미가 된다.

위 개념에 따라 자바스크립트에서는 호이스팅과 this 바인딩이 이루어진다.

프로토타입 기반 언어인 자바스크립트에서는 ‘단어의 의미가 사용되는 근처 환경’에서의 ‘근처’를 어휘적인 범위(lexical scope)로 정의한다. 자바스크립트 엔진은 코드가 로드될 때 실행 컨텍스트를 생성하고 그 안에 선언된 변수, 함수를 실행 컨텍스트의 최상단으로 호이스팅한다. 이 범위를 가리켜 렉시컬 스코프라고 한다.

this 역시 실행 맥락에 따라서 결정된다. 어디에 ‘정의’되었는지가 아니라, 어디서 어떻게 ‘발화’되었는지에 따라 달라지는 것이다. 프로그래밍적으로는 실행(invoke)하는 ‘객체’에 중점을 두고 있다.

따라서 아래와 같이 발화(invoke)할 객체를 직접 정할 수 있다.

foo.bar();
bar.call(foo);
const boundBar = bar.bind(foo);

저자는 프로토타입을 ‘클래스’의 다른 구현이 아닌, 완전히 새로운 인식 하에 만들어진 이론으로 보고 등장 배경을 철학적인 개념과 접목시켜 설명하고 있다. 프로토타입과 호이스팅, this로 이어지는 흐름까지 한번에 정리해볼 수 있는 재미있는 관점이다. 각 이론에 대한 구체적인 예시들은 아래 링크👇 에서 확인해보자!

Ref https://medium.com/@limsungmook/자바스크립트는-왜-프로토타입을-선택했을까-997f985adb42

React Server Component

서버 컴포넌트라니. 완전 새로운 논의다. 페이스북… 아니 메타에서 내놓은 소개 영상이 첨부되어 있다.

서버 컴포넌트는 말그대로 서버에서 내려주는 컴포넌트다. App.js가 아닌 App.server.js 등의 이름으로 서버 컴포넌트를 생성한다. 클라이언트에서 사용하는 컴포넌트는 물론 App.client.js라고 사용한다. 아무 postfix도 붙지 않은, App.js와 같은 컴포넌트는 서버와 클라이언트에서 모두 사용 가능한 공유 컴포넌트(Shared Component) 가 된다.

서버 컴포넌트에서 클라이언트 컴포넌트를 import해서 사용할 수도 있다. 이때 서버 컴포넌트에서 클라이언트 컴포넌트로 내려주는 props는 반드시 serializable해야 한다. 따라서 serialize가 불가능한 함수 등을 props로 내려줄 수는 없다.

서버 컴포넌트의 가장 큰 특징은, 서버 컴포넌트에서 사용하는 라이브러리들은 번들 파일에 포함되지 않는다는 것이다! 클라이언트에서 webpack이 할 일이 줄어든다. 번들 크기도 꽤나 획기적으로 감소한다. Dan 선생님이 말씀하시길, 발표 시점 29% 정도가 줄어들었다고 한다.

✅ 서버 컴포넌트 vs SSR 기존의 SSR(Server-Side Rendering)과 달리 서버 컴포넌트는 유저 인터랙션 발생 시 클라이언트가 완전히 다시 그려지지 않는다. 서버 컴포넌트는 HTML이 아닌 특별한 포맷으로 된 파일을 렌더링하기 때문이다. SSR과 서버 컴포넌트는 별개의 개념으로, 두 가지를 함께 사용할 수도 있다. (성능 문제로 권장하지는 않는다)

✅ 파일 IO react-fs 등의 라이브러리를 이용하여 서버 컴포넌트에서 파일을 미리 읽어 클라이언트에서 가공하여 렌더링할 수 있다. 이는 블로그처럼 정적 컨텐츠가 많은 앱에서 사용 시 편리하다. 어쩌면 Gatsby를 대체할 수도?

✅ DB Query 서버 컴포넌트는 DB에 곧바로 접근할 수 있다. 물론 보안상 권장하지는 않는다. 이때 DB 데이터가 변경되어도 변경된 데이터에 따른 UI만 업데이트되고, 기존 클라이언트의 UI는 그대로 남아있다.

✅ Pending 서버 컴포넌트는 Suspense와도 함께 잘 동작한다. 서버 컴포넌트는 완전한 HTML을 내려주는 것이 아니라, 스트리밍 기법으로 클라이언트에 데이터를 내려주기 때문이다.

클라이언트는 응답이 올 때까지 알아서 대기하며, 먼저 도착한 응답들을 먼저 받기도 한다. 또 응답을 받을 때까지 클라이언트가 처리할 유저 인터랙션들은 여전히 유효하다.

리액트에서 야심차게 내놓은 서버 컴포넌트의 등장 배경과 유효성을 살펴봤다. 정리해보면 다음과 같다.

• 서버 컴포넌트는 번들 크기를 줄여준다.
• 서버 컴포넌트를 사용하여 백엔드 자원에 직접 접근할 수 있다.
• 서버 컴포넌트를 사용하면 꼭 필요한 코드만 로드할 수 있다.
• 서버 컴포넌트는 모든 구체적인 use case에서 개발자에게 선택권을 준다.
  • 데이터 요청이나 인터랙션을 어디서(서버/클라이언트) 할 것인지 개발자가 결정할 수 있으며, 공유 컴포넌트로도 사용 가능하다.
• 서버 컴포넌트를 사용하여 서버 중심의 현대적인 UX 멘탈 모델을 설계할 수 있다.
  • 이제 클라이언트는 오로지 UI에만 집중할 수 있게 되었다.

리액트 팀은 서버 컴포넌트의 개발을 위해 현재 Next.js 팀 등과 협업하여 다양한 기능들을 발전시켜나가고 있다고 한다. 앞으로 여러 milestone들을 깨나갈 서버 컴포넌트에 관심을 가지고 지켜봐야겠다 😎

Ref https://github.com/reactwg/server-components

기타

2021 당신의 일상생활을 바꾼 앱

금융 1위가 업비트라니… 1, 2, 3위 모두 업비트-토스-카카오뱅크가 차지하고 있다니 진짜 금융권의 판도가 완전히 뒤바뀐 것이 실감난다. 소셜 앱에서 네이버 카페와 카카오스토리가 아직도 유효한 것도 신기하다.

Ref http://jmagazine.joins.com/forbes/view/334960

프로그래머스 개발자 설문조사

취업한 척 하고 슬며시 설문 참여

Ref https://programmers.co.kr/events/survey-2022

Tailwind CSS v3.0

Tailwind CSS의 메이저가 업데이트되었다.

Ref https://tailwindcss.com/blog/tailwindcss-v3

개발자라면 알아야 할 정규표현식

Ref https://yozm.wishket.com/magazine/detail/1197/ https://regexlearn.com/?fbclid=IwAR2W5OPJ-OJNJiSSi6NtWY7mpxdvjHDzPL0DVJJGTW1_yRPOxZ087cc8oLo

오늘의집 MSA Phase

MSA(MicroService Architecture)란 작고, 독립적으로 배포 가능한 각각의 기능을 수행하는 서비스로 구성된 프레임워크다. 반대 개념인 Monolithic Architecture는 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 형태를 가리킨다. 부분적인 장애 대응과 서비스의 변경을 유연하게 하고, 배포 시간의 단축을 위해서 MSA를 사용하는 것이 대세가 되고 있는 듯하다.

블로그에서는 오늘의집 기존 Rails 서버에서 클라이언트 코드를 분리하는 과정을 소개하고 있다.

클라이언트와 서버의 관심사를 분리하고, 클라이언트 코드가 독립적으로 움직일 수 있는 클라이언트 서버를 만들었다. git subtree를 사용하여 저장소의 히스토리를 보존하고, Github Actions를 활용하여 각 레포에 동기화 스크립트를 작성했다.

클라이언트 서버는 react-rails를 사용하여 React에서 핸들링 가능한 내용만 필터링하여 걸러내고, 아닌 것은 전부 Ruby 서버에서 처리하도록 했다. 개발 서버와 프로덕션 서버를 분리하여 개발 환경에서는 webpack을, 프로덕션 환경에서는 static provider를 사용하도록 구현했다.

싱글스레드로 동작하는 Node.js의 한계를 극복하기 위해 React를 렌더링하기 위한 스레드 풀을 구성하고, 렌더링을 할 때마다 잠시 빌려 쓰는 방식으로 동시 처리량을 늘렸다.

Ref https://www.bucketplace.co.kr/post/2021-12-03-오늘의집-msa-phase-1-프론트엔드-분리작업/ https://wooaoe.tistory.com/57

ES Proposals

언젠가 나도 Proposal을 올려보고 싶다.

Ref https://www.proposals.es/

새로운 React 프레임워크, Remix

리액트의 오랜 불편함이었던 SSR, SEO, 라우팅 문제에 대한 대안을 제공한다. 어떤 기능들을 제공하는지 한번 살펴봐도 좋을 것 같다. 그런데 이름이 Remix라 서치하기가 너무 어렵다. 😵

Ref https://remix.run/ https://dev.to/ishubhamprakash/remix-a-new-react-framework-from-the-creators-of-react-router-5886

시니어가 주니어에게

소프트웨어도 결국 사람을 돕기 위한 것이다. 다른 사람을 돕기 위한 마인드를 갖추자! 자기객관화와 자신감과 친절함은 덤.

그리고 뻔한 말이지만 본인만의 페이스로 차근차근, 덤덤하게. 지금의 나에게 아낌없이 투자하고, 조금이라도 더 행복하게 지내자. 취업이 안 되는 건 내 잘못이 아니다. 신기한 일은 자주 일어나지 않는다.

Ref https://www.inflearn.com/pages/for-junior-developers-20211207

마무리

쇼미더머니10의 ‘회전목마’라는 노래에 완전히 꽂혀서 매일 100번씩 듣고있다…🎠 올해가 2주 남았다. 괜히 몽글몽글해진다. 금요일에는 크루들과 함께 최근에 이사한 크루의 (강제)집들이를 갔다. 폴라로이드도 첫 개시하고, 밤늦게까지 신나게 놀다 나왔다.

아직도 면접, 지원, 코딩테스트, 과제전형의 연속이다. 하나 둘 취업에 성공하는 크루들이 생겨나고, 옛 친구들의 소식들도 들려온다. 이런지가 너무 오래돼서 그런지, 엄청나게 큰 타격은 없다.

우연히 ‘나미야 잡화점의 기적’을 읽기 시작했다. 아직까진 역시나 유치한 내용이지만, 그런 감성을 또 너무 좋아하는 걸 어떡해 🤷‍♀️