
얼마 전 새로운 회사로 이직했다.
풀필먼트 스타트업이고, 프론트 엔지니어로 일하게 되었다.
아직 일한지 한달도 안 돼서 벌써부터 '성공'기라고 하기는 조심스럽지만, 
성공기가 되도록 내가 잘 하면 되니까🔥

## 이직할 회사를 고르다

이전에 다니던 회사에서는 풀스택 엔지니어로 일을 했다.
JS, 리액트는 거의 집에서 내가 직접 프로젝트를 한 게 다였고 회사에서는 주로 파이썬으로 일을 했다.
파이썬도 재밌긴 했지만 어느순간부터는 JS와 프론트에 집중하고 싶다는 생각이 들었다.
회사에도 이야기를 해봤지만 회사에선 내가 백엔드 업무를 하길 원했고,
또 팀 없이 백엔드 시니어 1명과 개발을 해야해서 이직을 결심하게 되었다.
매일 퇴근 후 만들어둔 내 홈페이지와 사이드프로젝트들로 포트폴리오를 채웠다.

## 서류와 면접 준비

포트폴리오 등 서류는 2n군데에 제출했다. 그 중 서류 합격을 한 곳은 10군데정도 됐다. 
서류 합격 이후 과정은 다양했는데, 내 업무 스타일이나 가치관을 확인하는 구글 폼을 내게 했던 곳이나 
n가지 인성 질문을 답하라는 곳 등등 다양했다. 

가고 싶은 회사들에만 서류를 냈었지만 서류 제출 시와 서류 합격 후에 두번이나 가치관, 
인성 질문 리스트에 답하라고 한 곳은 정신적으로 너무 지쳐서 그냥 리타이어하겠다고 말했다. 
그 회사는 작은 스타트업이라 핏을 굉장히 중요하게 봤던 것 같다.
프론트엔드 과제도 2개 진행했었는데 손도 달달 떨리고... 어렵기도 했지만 재미가 더 컸다.

## 채용 프로세스동안 느낀 점

**이직 목표를 세우고, 휘둘리지 않기**

원티드로 회사를 알아봤는데, JD와 회사 소개만 보고 재밌어보인다! 하면 바로 원티드 이력서로 지원을 했다.
그런데 그렇게 하다보니 그 회사에 들어가고 싶은 간절함이 부족해서 내 시간과 에너지를 쓰는게 좀 주저되기 시작했다.
이직이라는게 내가 몇년간 다닐 곳을 찾는 건데 그런 마인드로 채용 프로세스를 하면 안 될 것 같아서 그 이후로는 좀 더 신중하게 이력서를 지원하기 시작했다.

지원서를 넣을 때 내 기준은 
1. **프론트엔드 직무 (No 풀스택)**: 이번 이직을 결심한 계기 자체가 프론트엔드 전문성을 쌓고 싶어서였기 때문이다. 
최종면접을 앞뒀던 회사에서 내가 풀스택으로 일해줬으면 하길래 다음 프로세스를 고사하기도 했다.
2. **회사 총 인원 30명 이상**: 내가 아직 주니어기 때문이다. 시니어가 있는 환경에서 일하고 싶어서 세운 최소한의 기준이었다.
또 나는 동료들에게서 큰 에너지와 인사이트를 얻는 타입이기 때문에 많은 동료들이 있는 회사에 가고 싶었다.
3. **No 메타버스, No 가상화폐**: 저 두 산업의 경우 아직 많이 불안정하다고 생각했다. 또 그냥 내가 메타버스보다는 실제로 만나서 소통하는 걸 좋아해서다.
내가 좋아하거나 성향이 맞을 것 같은 서비스를 하는 회사에 가고 싶었다.

**가장 가고 싶은 회사는 살짝 나중에 지원하자.**

그럼에도 가장 가고 싶은 회사는 좀 나중에 지원하는게 좋을 것 같은 이유는 `그래야 실제 면접 질문을 알 수 있고 긴장이 풀리기 때문`이다.
나같은 경력 이직의 경우, CS 지식만 물어보는게 아니라 내 이력, 경력에 대한 질문도 비중이 크다. 
먼저 면접보는 회사에서 뭘 물어보는지를 메모해뒀다가 보충하면 제일 가고 싶은 회사에서 더 완벽한 답을 할 수 있다.
이번에 이직한 회사도 가장 마지막에 면접을 본 회사였다.

**알고리즘 준비는 틈틈히**

길게 말 할 것도 없이... 하루 이틀에 되는 게 아니니 틈틈히 준비해놓기. 

## 면접

지금 회사의 면접 때 개발 리드 세분이 들어오셨었다.
모든 질문에 답을 하진 못했지만 채용공고 JD를 보며 준비한 질문들과 기존에 알고 있던 질문이 조화롭게 나와서
무난하게 답을 했다(고 믿는다).  
이건 입사 후 리드분한테 들은 건데, CTO님이 내 인터뷰 채점지에 '이 분은 뽑아도 될것 같다'고 적어두셨다고 한다. *감사합니다*...
면접 분위기가 좋았어서 최종 결과를 기다리던 일주일동안 이 회사에 꼭 가고 싶다는 생각을 많이 했었다.

최종 면접 일주일 후 합격 통보를 받고, 처우 협의 등 HR 프로세스를 거쳐 입사를 확정하였다.


## 거취 준비

퇴사하고 새로운 회사에 첫 출근하기까지는 약 3주가 걸렸다.
그동안 처우 협상도 하고 1박2일 가족 여행도 다녀오고… 지방에서 서울로 이사도 했다.
이사를 했는데 다시 이사를 해야하는 상황이 생겨 살짝 번거롭게 됐지만, 어디서든 내가 잘 꾸려 살아낼 거다(ㅋㅋㅋ)라는 믿음이 있다.
젊은 사람들이 많은 사는 동네라 그런가 집 근처에 그릭요거트 가게가 많아서 좋다.

## 온보딩

회사의 첫 인상이라고도 할 수 있는 온보딩!   
**아주 좋았다.** 

입사 첫날엔 HR 온보딩을 했는데 회사 소개, 회사가 하는 일, 각 팀이 하는 일의 자세한 설명을 들었다. 
중간중간 질문할 게 없을 정도로 내가 궁금했던 걸 다 알려주셨다. 

또 3개월 동안 1대1 온보딩을 도와줄 같은팀 동료가 있어서, 
업무 프로세스나 개발환경 세팅에 대한 도움을 받을 수 있었다. 짱...👼
입사 3일차에는 개발 프로세스를 확인해볼 목적으로 아주 작은 첫 PR을 올렸는데, 
혹여나 뭐가 잘못 될까봐 되게 긴장했었다. 이 글을 쓰는 지금은 그래도 많이 익숙해졌다.

또 회사 구성원 구조는 잘 몰랐는데 물류를 하는 IT회사다 보니 개발 인원이 많다. 
DevOps, QA 팀도 따로 있고 결제/정산 팀 등 업무가 세부적으로 나뉘어져있어서 각자의 일에 더욱 집중을 할 수 있는 환경이다.
일주일이 지난 지금까지도 꽤 만족스럽다.

**열심히 일해보자!**


대전 SI 기업에서 테헤란로 시리즈C 스타트업으로!

2년차 주니어 개발자의 첫 이직 성공기


모던자바스크립트 Deep Dive 1장을 읽으며 정리합니다.

## 자바스크립트란

프로그래밍 언어로써 기본 뼈대를 이루는 `ECMAScript`와 브라우저가 별도로 지원하는 
클라이언트 사이드 Web API(DOM, BOM, Canvas, `XMLHttpRequest`, `fetch`, SVG, Web Storage 등)을 아우르는 개념입니다.
웹 브라우저에서 동작하는 유일한 프로그래밍 언어입니다. 또 개발자가 별도의 컴파일을 하지 않는 인터프리터 언어입니다.
인터프리터 언어의 경우 한줄씩 바이트코드로 변환하고 즉시 실행합니다. 
마지막으로 **명령형/함수형/프로토타입기반 객체지향 프로그래밍**을 지원하는 멀티 패러다임 프로그래밍 언어입니다.

## 자바스크립트가 표준화된 이유

마이크로소프트 등 여러 회사들이 자사 브라우저에서만 동작하는 기능을 추가하면서, 크로스 브라우징 이슈가 생기기 시작했습니다.  
그래서 자바스크립트 표준사양인 **ECMAScript**가 출시됐습니다. 
각 브라우저 제조사들은 ECMAScript 사양을 준수해 브라우저에 내장될 JS 엔진을 구현합니다.

### 자바스크립트 성장의 역사

초창기 자바스크립트는 웹페이지의 보조적인 기능만 수행했습니다.  
하지만 시간이 변하면서 점점 자바스크립트의 역할이 많아졌고, 서버의 일을 클라이언트가 하게 되기도 했습니다.  
JS의 발전에서 중요했던 기술들은 크게 `Ajax`, `jQuery`, V8 JS Engine, `Node.js`, SPA 프레임워크들이 있는데요.

Ajax(Asynchronous JS and XML)는 **자바스크립트를 이용해 서버와 브라우저가 비동기 방식으로 데이터를 교환할 수 있는 통신기능**입니다.  
Ajax 이전에는 화면이 전환될 때마다 서버로부터 새로운 HTML을 전송받아 웹페이지 전체를 처음부터 다시 렌더링했는데요. 
변경하지 않아도 되는 부분의 HTML 코드를 서버로부터 다시 전송받기 때문에 불필요한 데이터 통신을 해야했습니다.

`jQuery`는 DOM을 쉽게 제어하게 해준 JS 라이브러리이고, V8 JS 엔진은 과거 웹 서버에서 수행되던 로직들이 클라이언트(브라우저)로 많이 이동하게 된 계기가 되었습니다.
`Node.js`는 구글 V8 JS 엔진으로 빌드된 JS 런타임 환경입니다. 원래는 브라우저의 JS 엔진에서만 동작하던 자바스크립트를 브라우저 밖으로 독립시켰습니다.  
덕분에 서버 사이드를 개발할 때에 JS를 쓸 수 있게 되었습니다. 마지막으로 앵귤러, 리액트 등 여러 SPA 프레임워크들이 등장했습니다.

모던자바스크립트 Deep Dive 1~3장

자바스크립트의 표준화와 발전 역사


[원문](https://frontendmastery.com/posts/the-new-wave-of-react-state-management)

위 아티클의 내용을 번역 및 요약하고, 중간중간 부가 설명을 추가했습니다.

## 상태관리란?

: 앱에서 text input, 확인, 라디오 버튼 등 UI 요소의 상태를 관리

### 리액트 전역 상태의 기준

리액트 쿼리의 철학을 따른다면 **서버 상태는 리액트 쿼리로 관리**하고 클라이언트 상태는 **해당 페이지/컴포넌트의 책임인지, 앱 전체의 책임인지에 따라 구분**한다.  
계정이나 설정 정보같이 **서버와 주고받는** 데이터, **화면과 무관한** 데이터나 
**컴포넌트를 가로지르는** 데이터(form 요소들)은 전역에서 관리하는 게 오히려 낫다.

최근 상태 관리의 움직임을 보면 예전보다 더 전역상태를 많이 지원하고 권한다. 
컴포넌트 데이터 교환이 props로 인해 복잡해진다면 전역 상태로 관리해도 무방하다.
다만 기존에 전역 상태를 쓰지 말라고 한 것은 전역 상태를 컴포넌트들이 수정하기 시작하면 어디서 수정된 건지 관리가 힘들기 때문이다.
그래서 최근 상태관리들은 대부분 수정 추적을 할 수 있도록 설계되어있다.
마지막으로 페이지나 UI를 가로지르는 state는 큰 전역으로 해야 추적과 디버깅이 편하다.

**결론**

1. 단순 UI 관련 state는 웬만해선 전역으로 넣지 않는다.
2. **여러 UI에서 공유하는 state는 전역으로** 넣는다
3. View단에 절대 state를 선언하지 않는다

### 모던 상태관리 라이브러리의 주 4가지 기능

1. State: 값이 바뀌면 해당 값을 쓰는 페이지나 컴포넌트가 자동 갱신
2. Mutation: 상태를 바꾸는 작업
3. Action: 어떤 작업의 결과가 나올때까지 상태가 바뀌지 않게 하고 결과값을 반영
4. Memoization: 특정 결과값이 상태가 바뀔때만 재계산되게 하는 기능

## 서론

하나의 리액트 앱 전역에서 공유되는 상태를 어떻게 하면 잘 관리할 수 있을까? 
리액트가 제공하는 가이드라인은  따로 없으므로 우리의 앱에 맞도록 잘 선택해야한다.
또, 왠만하면 로컬(밑부분)에서 시작해 필요한 만큼만 확장하자.

**요즘의 전역 상태관리 라이브러리들은**

각각 다른 접근법으로 동작한다. 또 각자 다른 문제점과 tradeoff를 가진다.
그렇기에 우리 앱에 가장 적절한 라이브러리를 선택하는 게 중요하다.

**전역 상태 관리 라이브러리가 해결하려는 문제**

첫째, **저장된 상태를 컴포넌트 트리 어디에서든 읽어올 수 있는가?** 
이 기능을 통해 상태를 메모리에 유지하고 `prop drilling`을 방지할 수 있다. 
초기에 리액트 유저들은 이 문제를 해결하고자 Redux를 무분별하게 사용했다.

## 상태를 저장하는 두가지 방식

1. 리액트 런타임 내부에 저장: 상태를 전파하기 위해 리액트 API인 `useState`, `useRef`
또는 `useReducer`를 활용한다. 
이 때 신경 써야할 부분은 리렌더링을 최적화하는 것이다.
2. 리액트 외부의 모듈 상태에 저장: 모듈 상태에는 싱글톤과 유사하게 상태를 저장할 수 있다. 
또한 구독(컴포넌트가 저장된 '상태'를 지켜보는 것) 을 통해 상태가 변경될 때만 렌더링하도록 최적화할 수 있다. 
다만 메모리 내부의 단일값(`싱글톤`)이므로 다른 subtree에서 사용되는 상태를 가질 수 없다.

둘째, **저장된 상태를 수정할 수 있는가?**

셋째, **렌더링을 최적화하는 메커니즘을 제공하는가?**
상태가 업데이트될 때 다시 렌더링할 시기를 감지하고 필요한 것만 다시 렌더링해야한다. 
사용자는 셀렉터 함수로 저장된 상태를 구독함으로써 이 프로세스를 수동으로 최적화할 수 있다. 
컴포넌트가 `selector`로 상태를 읽어 상태 변화가 일어났을 때만 리렌더링하는 방식이다. 
이 경우 유저가 원하는 대로 구독을 제어할 수 있지만 수동인지라 오류가 발생하기 쉽다. 
라이브러리가 자동으로 최적화하는 경우 사용이 편하다는 장점이 있다. 
`Valtio`라는 라이브러리는 `Proxy`를 사용해 상태의 업데이트와 컴포넌트가 다시 렌더링돼야하는 시기를 관리한다.

넷째, **메모리 사용을 최적화하는 메커니즘을 제공하는가?** 
리액트 라이프 사이클과 상태 저장을 엮으면 컴포넌트가 언마운트될 때 자동으로 가비지 컬렉션되도록 할 수 있다.
단일 전역 저장소 패턴의 Redux는 이를 개발자가 직접 관리해야한다. 
가비지 컬렉션이 자동으로 되는 걸 막기 위해 데이터를 계속 참조하고 있을테니 말이다. 
또 리액트 외부 모듈 상태에 저장하는 라이브러리를 쓸 때도, 상태가 컴포넌트들과 결합되지 않으므로 
수동으로 관리해줘야한다.

## 상태관리 생태계의 역사

리액트가 처음 나왔을때, 리액트는 MVC 패턴에서 View 역할을 하고자 했다. 
상태 관리 부재에 따른 불편함 때문에 페이스북의 `Flux` 패턴을 따와 상태 관리를 시작하게 되었다. 
이 패턴은 단방향 데이터 흐름과 예측 가능한 업데이트에 적합했다. 
그렇게 `Flux` 패턴을 사용한 대표적인 상태관리 라이브러리인 Redux가 사용되기 시작했다. 그러나…

**Redux의 약점**

1. Redux는 트리의 어느 곳에서나 상태에 액세스할 수 있다. 
적은 엔드 포인트를 통해서만 데이터를 가져오고, 상호 작용이 거의 없는 간단한 앱에서 쓰기에는 부담스럽다.

2. 모든 상태를 한 단일 저장소에 저장하게 한다. 
하향식 접근방식으로, 시간이 흐름에 따라 컴포넌트 트리의 맨 위에서 모든 상태를 빨아들이려 한다. 
(상태는 트리의 높은 위치에 있고 아래의 컴포넌트는 셀렉터로 필요한 상태를 끌어내린다.) 
독립적으로 분리된 복잡한 컴포넌트를 작업하기 어렵다.

그런데 사실, 대부분의 웹 앱이 서버에서 가져온 데이터(`서버 상태`)를 CRUD하는 것들이라 
서버의 캐시 문제를 해결하는게 더 우선이다. 그래서…

**더 간단한 접근을 위한 Hooks, Context API의 등장**

Redux 같이 무거운 추상화보다 훅과 기본 컨텍스트를 활용하는 방법이 뜨기 시작했다. 
(예시: `useState`, `useReducer`, `useContext` ) 간단한 앱의 경우 이것들을 사용하는게 더 나았다. 
이 경우 리렌더링을 최적화하는게 중요했다.

## 원격 상태 관리 문제를 해결하기 위한 라이브러리들의 등장

CRUD 스타일인 대부분의 웹앱을 위해선 전용 원격 상태 관리 라이브러리와 결합된 로컬 상태가 유용하다.
(`React-query`, `SWR`, `Relay`, `개선된 Redux` 등) 예를 들면 react-query는 앱에서 
서버 상태를 가져오기(`fetch`), 캐싱, 동기화 및 업데이트를 하게 도와주며 클라이언트 상태와 
서버 상태를 명확히 구분하게 해준다.

**주의할 점**

`State`는 관련 컴포넌트들과 최대한 가까이 배치하는 게 좋다. 
그래야 사이에 낀 컴포넌트들의 리렌더링과 부수효과를 줄일 수 있다.


'리액트 상태 관리의 새로운 흐름' 요약


## 첫 오프라인 원티드살롱 네트워크편
[6월 원티드살롱 네트워크편](https://www.wanted.co.kr/events/wantedsalon220629)에 다녀왔다.

**코로나 19 이후에 개발자 커리어를 시작했기 때문에 회사나 SNS 외부에서 개발자를 만나는게 쉽지 않았다.** 
그래서 원티드를 둘러보다가 바로 참여 신청을 눌렀던건데 어떻게 소모임 리더로까지 선정이 되었다.

![핑거푸드](/images/blog/2206/wanted1.jpg)

원티드 사무실이 있는 롯데타워 35층에 도착해서, 근처에 계셨던 분과 핑거푸드를 먹으며 대화하기 시작했다. 
그 분이 우아한 형제들 소속 기획자였는데, 세상 진짜 좁다고 느꼈다.
내가 개발 처음 배울 때 워크숍에서 알게 된 배민 개발자분의 이름을 말했더니 '방금까지 그 분이랑 이야기하고 왔다'고... 
ㅋㅋㅋㅋㅋㅋㅋㅋㅋ 이 맛에 네트워킹하지(?) 싶었다. 😉

가벼운 식사를 한 후엔 원티드에서 짠 팀대로 본격적인 네트워킹을 시작했다. **우리팀(8조)은 나까지 엔지니어 4명에 기획자 2명**이었다. 
엔지니어라고 또 같은게 아니라 임베디드 등 여럿 해보신 12년차 개발자분, 화공과 나와서 개발팀장하고 계신 분, 
기구 설계 엔지니어분과 1.5년차 쪼렙 개발자인 나까지 ㅋㅋㅋ  
기획 분야에서도 전략기획실에 있는 분이랑 A&R 기획자로 분야가 정말 다양했다.
그렇게 한 시간동안 자기 소개와 고민을 이야기했다.

## 8조의 고민

![원티드 살롱 모임](/images/blog/2206/wanted2.jpeg)

### 고인물

우리 조의 고민거리는 크게 **고인물**과 **전문성**이었다.  
실력(발전)이 없으나 윗자리를 차지하고 아랫 사람의 의견을 듣지 않는 임원진과
 직원에게 credit을 주지 않는 사람들에 대한 고민이 주로 나왔다.  
이야기를 들어보니 **대기업이든 중소기업이든, 한국이든 미국이든 상황은 다 비슷**한 것 같았다. 
다만 미국의 경우 프로젝트 매니저와 피플 매니저가 따로 있어서 동료때문에 힘든 경우 피플매니저에게 중재를 요청할 수 있다고 한다. (🫢) 
그런 사람을 어떻게 대해야할지에 대해서도 이야기해봤는데 결론은 '**현재에 충실하고 더 나은 사람이 돼서 다른 회사로 가자**'였다.
 어디 가든 상황은 비슷하니 내 발전에 좀 더 신경쓰는게 낫다는 거였다.  

이때 한 CEO의 이야기를 들었다. 그 사람은 성과를 낸 직원을 강단으로 불러서 
이 사람이 어떤 결과를 냈는지 모두에게 보여주고 퍼포먼스하듯, 시끄럽게 credit을 돌린다고 한다.
그 외에도 큰 선물을 미리 준비해두고 보이는 곳에 둔다는 등 직원들의 사기를 올리는 법을 확실히 아는 사람이었다. ㅋㅋㅋ
**보상이 핵심이다!**

### 전문성 (부제: 풀스택은 허상이다)

두번째로 '전문성'에 대한 이야기가 나왔다.
나포함 **모든 엔지니어들이 전문성에 대한 고민**을 하고 있었다.
2022년 6월 기준 나도 회사 프로젝트에서 파이썬을 자바스크립트나 리액트보다 더 많이 다뤘었다.  
그러다가 프론트도 백도 아닌 어중간한 상태가 되는 것 같아 아예 프론트엔드 엔지니어로 이직하려고 퇴사했는데, 
선배 개발자들이 내 선택에 응원을 보내주셔서 다시 한번 확신을 얻었다.
프론트엔드만 해도 배울 거, 공부할 게 너어어어어어무 많아서 다른 걸 공부하는 시간을 내기가 참 어렵다. 
영원히 공부하는 게 개발자의 숙명인 것을 요즘 들어 더 느낀다.

## 마무리

이렇게 한시간동안 이야기한 걸 요약해 발표하고, 단체사진을 찍은 후 해산하였다.  
짧은 시간이었지만 팀원들의 고민에 크게 공감할 수 있었고, 아직 대부분의 친구들이 대학생&대학원생인 나로선
 선배 직장인들의 이야기를 들을 수 있어 참으로 알찬 시간이었다.  
오늘의 만남을 소중히 하며 앞으로도 서로 영감과 고민을 나눌 수 있으면 좋겠다. 

끝!


조명, 온도, 습도... 좋은 사람들까지

원티드 살롱 네트워크편 다녀온 후기


## 3월

### 16일: 이력서를 쓰고 그대로 사는게 더 쉽다

예전에 누군가 '이력서를 나중에 쓰는 것보다 먼저 쓰고, 그대로 사는 게 더 쉽다'고 한 적이 있었다.  
그때는 그게 도대체 무슨 말인가 했는데, 어제 이력서를 쓰면서 100000퍼센트 이해했다.  

#### 이 문장의 속뜻

은 바로... '이력서를 쓰면서 내가 부족한 것을 파악하고, 그걸 해내라'는 거였다.  
나는 아직 프론트엔드 개발자로서 사이트의 성능을 개선한 적이 많지 않다.  
그래서 6월에 더 해볼 것을 나열해보겠다. (그래서 다음 이력서엔 당당하게 쓸 수 있게!)

### 22일: 운영체제 스터디가 끝났다. 

스터디 방식은 한 챕터씩 강의를 듣고 각자의 방식으로 정리한 뒤, 매주 수,일요일 저녁 9시에 줌에서 이야기를 하는 것이었다. 
각자 돌아가면서 인상깊었던 것과 생각을 말하고 퀴즈를 내고 함께 풀었다.

시간이 남으면 수다를 떨었는데 나뺴고 다 백엔드개발자셨다. 덕분에 백엔드 기술 이야기를 많이 들었다. 
스터디하면서 리눅스 코드에서 세마포어를 어떻게 구현했는지 보기도 하고 깃허브로 남의 코드를 보는 재미를 알게 되었다.

### 22일: 약 35일간 체지방 2.5kg 뺐다. 

일련의 기준을 충족하는(새벽오픈, 집에서 가까울것, 인클라인 기능 있는 트레드밀이 있을것) 헬스를 등록해서 자주 다녔다. 
다행히 근육은 0.2kg만 빠졌다. 근력운동을 유산소보다 더 많이 했는데. 역시 체지방 빼는 것보다 근육 늘리는게 더 어렵구나! 더 건강해지자 아좌아좍

### 29일: 짱 맛있는 초콜릿 발견

![chocolate](/images/blog/2203/choco1.jpg)
![chocolate](/images/blog/2203/choco2.jpg)  
(얼마전 미친 맛으로 나에게 큰 행복이 되었던 기라르델리 씨솔트 아몬드 다크 초콜릿)

새로운 음식 먹어보기, 새로운 나라 여행하기, 새로운 사람 만나기.
 모든 인간과 음식, 나라, 물건이 새로운 이야기를 가지고 있고 그런 이야기(& 의견)을 알게되는건 정말 즐거운 일이다. 결국 내 사고의 확장으로도 이어진다.

### 31일: 'MessageToMe'팀 첫 워크샵

![워크샵](/images/blog/2203/workshop1.png)
![게더타운](/images/blog/2203/workshop2.png)

게더타운에서 MessageToMe 팀 첫 워크샵을 했다. 프로젝트를 하면서 회의는 자주 했지만 실제로 얼굴을 드러내고 사적인 이야기를 한 건 처음이었다. 

## 4월

### 1st April Fool's day

![스택오버플로 테마](/images/blog/2204/so1.png)

아침에 에러 고치러 스택오버플로 들어갔는데 이렇게 보였다! ㅋㅋㅋ 만우절이라 그런 것 같았다. 
해결방법 찾으려고 화면 뚫어져라 보다가 가뜩이나 안 좋은 시력 더 나빠질뻔! 
보니까 테마가 추가돼서 저런 어지러운 테마부터 페이스북 느낌, 터미널 느낌까지 다양했다.

![스택오버플로 메인](/images/blog/2204/so1.png)

아 오늘부터 1일1JS 이론 공부 시작했다.

### 6th metacognition

![지식](/images/blog/2204/know.JPG)

개발자가 되고 다른 사람들의 지식에 감탄하면서 쭈구리 모드가 되곤 했는데, 힘이 되는 다이어그램이다. 
개발자로 커리어를 시작한 이후로는 (물론 내 첫 **직업**이 개발자지만 ㅋㅋㅋ) 공부를 어떻게 할 것인가를 자주 고민하고 있다. 
배우고 싶은 && 배워야할 게 많아서 그런 것 같다. 공부 방법과 방향 감각을 잃지 않아야한다.

![공부란 스키마를 닮아가는 과정](/images/blog/2204/learn.jpg)

친구가 보내준 이 트윗도 좋아한다. **공부는 나보다 전문적인 사람들의 스키마(신경회로 패턴)을 닮아가는** 과정. 
**마법적인 지름길은 없고,** 꾸준히 접하고 따라해보면서 점차 비슷해지는 것이다!

그래서 예전엔 재미있어보이는&흥미로운 아티클들만 읽었다면 요즘은 시간을 내서 읽는 중이다. 

### 18th 모바일 앱에서 사용자가 과도하게 큰 폰트를 사용한다면?

![제페토 UI](/images/blog/2204/bigfont.PNG)

사진 속 휴대폰은 우리 할머니의 것이다.  
스마트폰이 없는 동생이 제페토를 해보고 싶대서 할머니 휴대폰에 제페토를 설치하는 중이었다.  
그러다 발견한 문제였는데, 할머니는 가장 큰 크기의 폰트를 사용하고 있어 제페토 앱이 누르라고 하는 버튼을 누를 수가 없었다.  
아래의 로그인 버튼을 클릭하라고 했는데, 스크롤이 아예 안 됐다.  
`버튼을 누르세요!`라고 적힌 영역이 버튼 영역을 잡아먹은 것 같았다.  
결국 폰트 사이즈를 줄인 이후에야 버튼이 드러나 다음 차례로 진행할 수 있었다.  
이 문제는 접근성 이슈인 것 같은데, 아마 평균의 폰트 사이즈였다면 이 문제를 알아차리지 못 했을 것 같다.  
내가 짠 웹앱들도 변수를 준다면 이런 문제들이 많이 발생할 것 같다.  
오늘도 개발의 어려움과(고려해야할게 정말 많다). UI의 중요성을 깨달은 하루였다!

### 20th 서울시립미술관 남서울미술관

![남서울미술관 해체](/images/blog/2204/southart1.JPG)

얼마전 서울 사당역에 위치한 서울시립미술관 남서울미술관에 다녀왔다.  
벨기에 영사관으로 사용되었던 남서울미술관은 원래 종로에 있었다. 
그러다 1979년에 남현동으로 이전이 확정되었고 벽돌과 석재, 나무 하나하나를 `해체`해 그대로 옮겼다고 한다.  
그 건물이 이전된 거라고 하길래 건물을 부수고 그 자리에 새로 지은 것도 아니고, 그대로 이전할 수가 있지? 생각했는데  
처음 그 건물의 설계와 이전 후 재건축(이축)을 위한 설계가 아주 철저히 이뤄졌기 때문에 가능한 거였다.  

![남서울미술관 내부1](/images/blog/2204/southart2.JPG)
![남서울미술관 내부2](/images/blog/2204/southart3.jpg)

미술관 내부를 구경하면서 안정적인 이전을 가능하게 한 건축가들의 장인정신을 느낄 수 있었다.
`소프트웨어 장인`이라는 책이 떠올랐고, 덕분에 내가 이런 멋진 공간을 즐길 수 있구나 싶었다.
층고가 높은 건물을 사랑하는데, 채광도 좋고 삐걱거리는 나무 계단도 참 좋았다.

### 25th framework

[자바스크립트 프레임워크 전쟁은 끝났다](https://news.hada.io/topic?id=6395&utm_source=weekly&utm_medium=email&utm_campaign=202217)

**최고의 프레임워크는 사용자 코드에서 자신을 제거하는 프레임워크**

정말 맞는 말이다!
사용자가 프레임워크만의 문법을 덜 쓴다면 나중에 다른 개발자가 유지보수할 때도 읽기 쉽고  
또는 다른 프레임워크로 옮겨가야할 때도 편하다.  

(별개로, Geeknews weekly를 몇주째 구독중인데 내가 지금 받아보는 뉴스레터 중 가장 재미있고 깔끔하고 읽기 쉽다.  
운영자분들 적게 일하고 많이 버십시오~~)

## 5월

### '별말,씀' 프로젝트 & 협업의 어려움

요즘은 퇴근 후에도 '별말,씀' 프로젝트를 계속 개발 중이다.  
깃랩으로 작업하고 있어서, 깃허브 잔디에 소홀해진 게 아쉽다
팀원들이 깃랩을 쓰자고 해서 쓰는 중인데 딱히 깃허브보다 나은 점은 잘 모르겠다(여쭤봐야겠다).  
프론트엔드 개발하면서 파트를 나눴지만 공통적으로 필요한 컴포넌트들이 있어서 공통 컴포넌트는 내가 다 개발하고 있다.  
이 컴포넌트가 어떻게 해야 여러 다른 점들을 포용하면서도 한 가지 기능& 스타일을 유지할 수 있을까 생각을 하게 된다.  
그래서 optional 변수를 명시적으로 적어둘 수 있는 타입스크립트가 더 유용하게 느껴진다.  

그리고 기능별로 브랜치를 나눠서 작업하는데, 내가 브랜치 바꾸는 걸 자주 까먹는다.  
그래서 종종 `cherry-pick`을 한다.  
확실히 협업을 하니까 그만큼 컨플릭트도 더 자주 마주치지만 깃 명령어들과도 더 친해지고 있다.  

주2회로 화요일엔 프론트엔드 회의, 목요일엔 전체 회의를 하는데 팀원 모두가 열정을 가지고 프로젝트에 임하고 있어서 나도 더 열심히 하게 된다.  
'별말,씀'이라는 이름이 어제 회의에서 정해진 우리 서비스의 정식 이름이다.  
잘 마무리되길!

### GDB는 진짜 오래 걸린다(?)

회사에서 neo4j 를 사용해 GDB를 구축하는 업무를 맡고 있다.
근데 GDB는 진짜 오래 걸린다. 엣지(관계)를 연결할 때엔 쿼리로 노드를 검색해서 그 노드가 있으면 연결을 하는데, (이 전제가 없으면 없는 노드를 바로 생성해 연결한다.) 
그 검색이 진짜 오래 걸린다. 노드 수가 늘어날 수록 검색 속도는 더 느려지고, 요즘엔 1초에 엣지 하나를 생성하는 수준이다. 
엣지 3만개를 넣는다고 하면, 약 3만초가 걸리는 셈이다...

노드1과 노드2를 잇는 관계 생성 쿼리의 경우 노드1이 없으면 그 쿼리는 사실상 무용지물이 된다. 
그래서 원래는 DB 결과를 바로 GDB 쿼리로 만들었는데, 
두 노드 중 하나라도 없진 않은지 미리 확인하고, 하나라도 없으면 그 쿼리를 생략(break)하도록 로직을 추가하려고 한다. 

구체적인 방법은 생각하지 않았지만... ㅋㅋㅋ   
컴퓨터가 느린 경우도 있구나 싶다. 


### 송은 / 미술관을 다녀와서

![송은 미술관](/images/blog/2205/se1.jpg)

송은 미술관에 다녀왔다. 도산대로 한복판에 자리잡고 있는 거대한 비영리 문화공간. 이게 진정한 FLEX라고 생각한다. 
주말에 갔는데도 한적했던 송은 미술관! 트여있는 창과 높은 층고 덕분에 한숨 돌렸다.

![전시 도록](/images/blog/2205/se2.jpg)
![엘레베이터](/images/blog/2205/se3.jpg)

UI/UX 디자인을 할때 국내외 미술관 사이트를 많이 참고하는데, 하나같이 감각적이거나 깔끔하면서도 개성 있어서이다. 
따라하고 싶어도 따라하기 정말 어려운 것들.

전시 도록들을 보면 엄청 작은 글씨로 A4 한장에 빽빽히 들어차있는 경우가 많다. 
빳빳한 종이 말고 평범하게 얇은 A4가 주는 그 감성이 좋다.ㅋㅋㅋ `margin`과 `padding`이 적게 들어가 있는 것도 좋다.

송은 아트센터의 경우 길쭉네모네모한 폰트를 쓰고 있었는데, 세련됐으면서도 정갈해서 언젠가 웹사이트 디자인할 때 써보고 싶었다.

![미술관 밖 공간](/images/blog/2205/se4.jpg)

### Google IO 2022 구경

Google IO 2022가 열렸다.   

웹, 플러터, 안드로이드 등등 여러 분야를 게더타운처럼 탐험하면서 구경할 수 있었다.   
구글 맵존도 있었는데, 웹이랑 구글 맵 쪽이 제일 흥미로웠다 ㅋㅋㅋ   

![Google IO 2022](/images/blog/2205/googleio1.png)
![Google IO 2022](/images/blog/2205/googleio2.png)
![Google IO 2022](/images/blog/2205/googleio3.png)

2022년 3~5월의 짧은 기록


## 서론

다들 TDD, TDD 하는데 본 코드도 짜기 힘든데 테스트 코드를 같이 짜라고...? 
하는 생각에 테스트 코드를 작성하지 않는 분들이 많을 것 같다.

나도 항상 그래왔다. 그래서 해보지도 않고 미루기보다, 사람들이 왜 그렇게 입모아 
테스트의 중요성을 외치는지 알기 위해 내가 직접 테스트 코드를 짜고 적용해봤다.

## 리액트 테스팅 라이브러리

리액트 CRA에서 제공하는 [테스팅 라이브러리](https://testing-library.com/docs/queries/about)를 써봤다.  
일단은 이 페이지만 알아도 가벼운 테스트 코드를 작성할 수 있다.

## 테스트 코드 개발 시작

중요한 점은 TDD를 하려면 테스트 코드를 먼저 짜고, 그 다음 본 코드를 적어야한다는 거다. 

1. 원하는 기능이 작동하는지 테스트하는 테스트 코드 작성 (당연히 오류가 난다)
2. 오류가 나면, 그 오류를 고칠 수 있는 본 코드를 작성
3. 테스트 구동, 오류가 여전히 나면 본 코드를 수정 (테스트 성공할때까지 반복)
4. 테스트 성공
5. 리팩토링(후에도 테스트가 성공해야함) 

## 리액트 라우터 테스트

![라우팅 적용된 네비게이션 바](/images/blog/2205/navtest.gif)

(개발 중인 코드에 테스트 코드를 넣은거라 완전 TDD는 아님 주의)  
위 gif를 보면 App 컴포넌트 안에 리액트 라우터를 사용해 라우팅 정보를 넣어두었다.  
또 왼쪽에 네비게이션 바를 두어, 페이지를 이동할 수 있다.  
가장 먼저, **앱 실행 시 상단에 'LeadPet'이라고 적힌 네비게이션 바가 뜨는지** 확인하고 싶다.

``` js
    describe('<App />', () => {
        test('<App /> 렌더링 시 navBar가 뜨나요?', async ()=> {
            const history = createMemoryHistory()
            render(
                <Router location={history.location} navigator={history}>
                    <App />
                </Router>
            )

            await expect(screen.getByText('LeadPet')).toBeInTheDocument();
        });
    });
```

테스트 구동: `npm test App.test.js`

리액트 라우터 테스트 방법 또한 [공식 문서](https://testing-library.com/docs/example-react-router/)를 참고했다.  
라우터 정보가 없는 `App` 컴포넌트라면 그냥 `render(<App />)`로 테스트해도 되는데, 
라우터 정보가 있는 앱 컴포넌트의 경우 `useRoutes() may be used only in the context of a Router component.` 에러가 뜨므로 주의!

하단의 `expect`문장을 통해 **렌더링된 screen에 LeadPet이라는 텍스트가 있는지** 확인하고, 있으면 테스트를 통과하게 된다.

![테스트 성공](/images/blog/2205/testres1.png)

그럼 이렇게 테스트 성공!

 리액트 테스트 코드 짜는법, 리액트 테스팅 라이브러리 사용법


## SEO의 중요성

[공식문서 SEO](https://nextjs.org/learn/seo/introduction-to-seo)를 읽고 정리해본다.

**SEO(Search Engine Optimization)**이란 구글 등 검색엔진에서 뭔가를 검색했을 때 내 글이 잘 나오도록 최적화하는 것을 말한다.

마케팅을 전공했기 때문에 아주 익숙한 단어다. 웹사이트를 운영할 때 내 컨텐츠가 나만 보기 위한게 아니라면 SEO 적용은 필수다. SEO 랭킹이 높을 수록 내 컨텐츠를 더 많은 사람들이 볼 수 있다.

### Search Systems (검색 엔진)

#### 검색엔진들의 Search System

1. 크롤링: 웹사이트를 돌아다니며 그 안의 컨텐츠들을 긁어모은다.
2. 인덱싱: 크롤링된 데이터에 적절하게 접근할 수 있도록 저장할 위치를 찾는다.
3. 렌더링: JS 등 페이지 리소스를 실행한다.
4. 랭킹: 사용자 검색어와 관련된 페이지들을 엮어 순서대로 보여준다. 이때 각 검색엔진의 기준(알고리즘)대로 순위가 정해진다.

![구글 봇의 작동 순서](https://nextjs.org/_next/image?url=%2Fstatic%2Fimages%2Flearn%2Fseo%2Fgooglebot.png&w=3840&q=75)

## 구글의 페이지 처리 프로세스

React의 SEO 이슈와 대처 방안을 알아보자. 
(출처: Geek news Weekly)

1. SSR/SSG 적용 필수: 최초 렌더링 빠르게 & 검색 크롤러의 렌더링에 의존하지 않기
2. HTTP 상태코드 제대로 사용
3. Hashed URL 피하기
4. 링크는 꼭 `<a href>`로, div나 버튼 말고
5. 주요 HTML의 lazy loading 피하기
6. 기본 요소들은 다 챙길 것
    - Canonicalization
    - Structured data
    - XML sitemaps
    - Mobile-first
    - Website Structure
    - HTTPS
    - Title tags
    - Semantic HTML

## 링크 주스란?

1. 웹 페이지를 타고 흐르는 링크의 가치 (링크를 받고 있는 개수X링크 원본 사이트의 품질과 관련성)
2. 검색 순위를 결정하는 요소

- `rel="noopener"`: 새로 열린 페이지에 `window.opener` 객체가 존재하지 않음
- `rel="noreferer"`: `window.opener` 객체를 조작하지 못 하게 함 
(하지만 직접 트래픽으로 파악돼서 분석 및 추적 소프트웨어 수치 왜곡)
- `rel="nofollow"`: 페이지의 내부 링크주스를 전달하고 싶지 않을 때 씀

=> 구글 및 기타 검색엔진을 사용하려면 모든 스폰서 링크 및 광고에서 `rel="nofollow"`를 사용해야함.

## 웹 접근성을 위한 요소 'role'

HTML 코드 보면 `ul`, `ol`에 `role='list'`를 주고 `li` 태그에 `role='listitem'`을 주는 경우가 있다.
 웹 접근성을 위한 것으로, 스크린 리더나 보조 기기가 그 컴포넌트의 역할 등 정보를 더 잘 알게 하기 이다.


내 블로그 글을 구글에 뜨게 하려면 필수인 바로 그것

 Next.js SEO 하기 (검색엔진최적화)


## 서버 사이드 렌더링 (SSR)

Next.js는 서버 사이드 렌더링을 한다. 서버 사이드 렌더링이란
서버가 빌드 단계에서 페이지들을 미리 다 만들어두고 클라이언트가 접속 요청을 보내면 그때 그때 보내주는 방식이다.  
SSR은 빌드하면 기완성된 html이 생기고, 서버에서 브라우저에게 기완성 HTML+data를 합쳐 보내주기만 하면 된다.
그래서 빈 HTML을 받아 스크립트를 불러오는 등 브라우저에서 렌더링하는 CSR보다 첫 로딩이 빠르다.

전통적인 웹의 경우, 정적 페이지를 서버에서 만들어두고 보여주는 형식이었다. 이런 방식도 SSR이다.

## 서버 사이드 렌더링의 장점

1. 검색 엔진 최적화 (미리 만들어두고, 메타 데이터를 저장해두니 검색엔진이 데이터를 더 잘 모은다.)
2. 빠른 페이지 렌더링 (초기 로딩 속도 줄임)

### getServerSideProps

- SSR
- 요청 시 필요한 데이터를 미리 렌더링하는 경우에만 사용
- 페이지 요청 시마다 실행됨
- **정말 필요한 때만** 사용할 것 (CDN에 캐싱되지 않아 느림)! 데이터를 미리 렌더링할 필요가 없다면 클라이언트 측에서 데이터 페칭하기.

## 정적 사이트 생성 (SSG)

### getStaticProps

- 정적 페이지 생성 방식(Static Site Generation),
- 항상 서버에서 실행 (CSR 아님)
- 빌드(번들링) 단계에서 data fetching, JSON으로 저장하여 고정적으로 사용함
- 가져온 데이터를 Props에 담고 리턴하여 컴포넌트에 전달
- 페이지 요청 때마다 데이터를 가져오는게 아니라 성능 측면에서 뛰어남
- **빌드 후 고정된 내용**을 보여주는 페이지, SEO를 위해 속도가 빨라야하는 페이지에 적합

### getStaticPaths

`pages/[id].tsx`같은 형태의 다이나믹 라우팅 페이지 중 빌드 단계에서 **정적으로 생성할** 페이지를 정함

## fallback (true, false, blocking)

Next.js에서 fallback은 사용자가 `getStaticPaths`에서 만들어지지 않은 페이지에 접속했을 경우를 말한다.  
이런 상황에 fallback값을 두어 404를 띄우거나, 다른 방법으로 생성한 페이지를 보여줄 수 있다.

### fallback: true

`getStaticPaths`에서 만들어지지 않은 페이지에 접속했을 경우, 먼저 사용자에게 fallback 페이지를 보여줌.
이후 서버에서 static하게 페이지를 만들고 해당 페이지를 사용자에게 보여줌.

```js
// fallback = true일때 fallback 페이지

if(router.isFallback) {
    return <Loading />
}
```

### fallback: false

`getStaticPaths`에서 만들지 않은 페이지는 404로 연결됨

### fallback: blocking

`getStaticPaths`에서 만들지 않은 페이지에 접속하면 사용자에게 SSR한 static 페이지를 보여줌.
(동적 라우팅 페이지를 정적 페이지로 제공해야할 때 사용)

## 클라이언트 사이드 렌더링 (CSR)

10 페이지가 있으면 10페이지의 js 번들 파일을 모두 불러옴 vs SSR: 해당 페이지 (10분의 1)만 불러오면 되므로 초기 로딩속도가 빠름.


Categories