
## 서론

많은 개발자분들이 C++나 파이썬, 자바로 알고리즘 테스트를 준비합니다.  
하지만 이 경우는 백엔드 개발자가 많고, 요즘엔 많은 회사들이 프론트엔드 직군을 뽑을 때 
알고리즘 테스트 언어를 자바스크립트로 제한하죠. 

그래서 프론트엔드 개발자라면 실무 능력치도 키울 겸 자바스크립트로 코딩테스트를 준비하는게 좋아보입니다.  
다른 언어들보다 유저가 적은 만큼 문제와 best practices를 찾기 힘든 건 사실이지만요.  
오늘은 제가 자바스크립트로 알고리즘 문제를 풀어보면서 느낀 것과 배운 것을 적어보겠습니다.

## 자바스크립트 숫자 배열 정렬하기

```JavaScript
const arr = [1, 20, 3, 100, undefined]
console.log(arr.sort())     // 이 때의 값은?
```

위 코드에서 주석에 찍히는 배열은 어떤 모습일까요?  
배열의 원소를 올림차순으로 배열해 `[undefined,1,3,20,100]`일까요? 

정답은 `[1, 100, 20, 3, undefined]`입니다.  
자바스크립트 배열 기본 `sort()` 메서드는 파라미터로 콜백함수를 넣어주지 않을 경우, 
**배열 내 숫자를 문자열로 변환하고, UTF-16의 문자 순서대로** 배열을 정렬하기 때문입니다.  
그리고 모든 undefined는 배열의 뒷부분으로 정렬됩니다. 

그러면 자바스크립트에서 배열을 유니코드 말고 다른 기준으로 정렬하려면 어떻게 해야할까요?  
`Array.sort()` 의 옵셔널 파라미터인 `compareFn` 즉 **콜백함수**를 넘겨주면 됩니다.

`Array.sort()`는 `compareFn(a,b)`의 **리턴값**에 따라 배열의 원소를 정렬합니다.  
`compareFn(a,b)`의 리턴값이 0보다 크면 `b,a`  
`compareFn(a,b)`의 리턴값이 0보다 작으면 `a,b`  
`compareFn(a,b)`의 리턴값이 0이면 a와 b의 순서를 유지합니다.  
코드로 짜보면 이렇습니다.

```JavaScript
function compareFn(a, b) {
  if (a가 b보다 앞으로 와야하는 경우) {
    return -1;
  }
  if (b가 a보다 앞으로 와야하는 경우) {
    return 1;
  }
  
  return 0;
}
```

이렇게 **두 원소를 비교해 경우에 따라 -1과 0, 1을 반환하도록** 함수를 짜면  
커스터마이징된 정렬을 수행할 수 있게 됩니다.  
이 때 1,0만 반환하거나 -1,0만 반환한다면 정렬이 제대로 되지 않는다는 점 유의하세요!

문자열 배열 말고 숫자 배열의 원소를 비교할 땐 위 공식을 이용해 
a에서 b를 빼거나 b에서 a를 빼도록 하면 됩니다.  
a-b가 음수면 a가 b보다 앞으로 오고, 양수면 뒤로 정렬되는 거죠.  
(원소 중 `Infinity`, `NaN`이 없어야합니다.)

```JavaScript
const arr = [1, 20, 3, 100, undefined];

// 1: 함수 표현식
arr.sort(function (a,b) {
  return a-b;
})

// 2: 화살표 함수
arr.sort((a, b) => a-b)
```

이렇게요!



자바스크립트로 알고리즘 문제 풀때 주의해야할 것들

자바스크립트로 코딩테스트 준비하기


![마이크로소프트에서 바라보는 종로 전경](/images/blog/2209/main.jpg)

걸스인텍과 마이크로소프트에서 주최한 `CODE;WITHOUT BARRIERS MEETUP`에 다녀왔다.  
많은 여성 IT 종사자들을 만나볼 수 있다는 생각에 냉큼 신청했었는데 선정되어서 정말 기뻤다!
종로 놀러올 때마다 마이크로소프트 본사를 우러러봤었는데 오피스에 들어가볼 기회가 생겨 꿈만 같았다.

![다과](/images/blog/2209/cookies1.jpg)

2022년 9월 3일 10시 마이크로소프트에 도착해서는 다과를 나누면서 주변에 앉은 분들과
인사, 명함을 나눴다. 개발자도 있고 데이터 엔지니어나 PM 등 다양한 개발직군의 사람들이 있었다.  
(폴바셋 에그타르트 짱 맛있었다!)

## IT 업계의 유리천장

영국 이코노미스트 발표에 따르면 한국은 `2022년까지 10년 연속으로
OECD 29개국 중 유리천장이 가장 심한 국가`라고 한다.  
다른 분야에 비하면 IT 업계는 유리천장이 덜할 것 같지만, 통계에 따르면
시니어로 일하는 여성 IT 종사자 비율은 현저히 적었다. 
그 외에도 여러 지표들이 국내 IT 업계의 젠더 갭들을 나타내고 있었다.

## MS의 Diversity and Inclusion

그래서 MS에서는 전 세계의 남성과 여성이 기술을 배울 수 있는 접근성의 차이가 있다고 보았다.
인종, 성별, 종교, 국가 등 다양성을 높이고 배제되는 사람이 없는 생태계를 만들기 위해
접근성의 격차를 메우고자 D&I(`Diversity and Inclusion`) 미션을 세웠다. 

마이크로소프트의 과거 미션은 '전 세계 모든 가정이 PC에 MS 소프트웨어를 하나씩 가지도록 하는 것'이었지만 
지금은 '**지구상의 모든 사람과 조직이 더 많은 것을 성취하도록 역량을 지원하는 것**'이라고 한다.

## Truths and Insights

그래서 팀별로 개발자 커뮤니티 내 D&I를 활성화하기 위한 게임 `Truths and Insights`를 진행했다.
주어진 문장의 빈 칸을 채우면서 의견을 공유하는 게임인데, 
같은 IT 업계 종사자끼리 개발자로서 드는 고민이나 경험을 나눌 수 있었다.  

우리 조는 다 주니어 개발자였는데, 내가 입사 1년차 때 했던 고민을 하는 조원들이 많았다. 
그래서 내가 나눈 팁은 이와 같았다.

1. **구글링을 30분 이상 한다면 그건 내가 모르는 것**이다. 
**충분히** 고민하고 찾아봤는데도 모르겠다면 도움을 청하는 걸 두려워말자.
2. 동료에게 조언을 구할 때는 **문제 상황과 그 문제를 해결하기 위해 내가 해본 것, 결과**를 자세히 이야기하자.
3. 나이차가 많은 사수에게 어떻게 질문을 해야할지 모르겠다면 `저 고민이 있어요...`라고 물꼬를 틀자.

마지막 소감을 이야기할때 내가 나눈 팁이 큰 도움이 되었다고 한 조원이 있어 기뻤다.
시간이 좀 더 길었다면 더 깊은 이야기를 할 수 있었을 텐데 게임 시간이 약 2-30분밖에 안 돼서 아쉬웠다.

그럼에도 임파워링되는 자리였고, 
기술에의 접근성 격차를 줄이는 게 유리천장을 얇게 하는데 정말 중요한 요소라는 걸 깨달았다.
굳이 성별이 아니어도 서울과 비서울 지역의 개발자들이 얻는 기회와 인프라가 정말 다른데,
내가 기술 접근성 격차를 줄이기 위해 할 수 있는 일은 뭐가 있을까? 다시 한번 생각해보게 되었다.

아직은 나도 주니어고 모르는게 많아 다른 사람들을 끌어주는 일을 많이 하지 못했는데
먼 미래가 아니라 가까운 미래에 내가 할 수 있는 일들(Action item)을 찾아봐야겠다.

마지막으로 지하 1층에서 마이크로소프트에서 제공해준 부타동 솥밥을 먹었다. 
맛있었고, 즐거웠다. 

🔚

![걸스인텍xMS CODE;WITHOUT BARRIERS banner](/images/blog/2209/gitms.JPG)

광화문 마이크로소프트, 빌게이츠씨가 사준 밥, 즐거운 동료 개발자들과 함께

걸스인텍xMS CODE;WITHOUT BARRIERS 밋업에 다녀오다


## 첫번째 원동력: 사람

파스토에 다닌지 약 5주가 지났다.  
이직 회고를 작성해 소셜미디어에 공유했었는데, 어느날 이런 디엠이 왔다.

![대화1](/images/blog/2208/meet1.jpg)
![대화2](/images/blog/2208/meet2.jpg)

전 회사에서 며칠 함께 근무했던 분이 그 글을 보시고, 연락을 주신 거였다!  
나보다 몇개월 먼저 퇴사하셨었는데, 내 글을 보고 이직을 축하한다는 메시지를 주셨다.
개발자 세상이 좁다는 건 알고 있었지만 이렇게 다시 실감할 줄이야.

그와 더불어 그때의 내가 악조건(와이파이와 인터넷이 불가능한 내부망, 프로젝트 담당 공무원이 계속 바뀜 등등)에도 불구하고
눈이 반짝반짝했다는 이야기를 해주셔서, 지금의 나는 이때의 열정과 마음가짐을 잃지 않았는지 다시 한번 생각해보는 기회가 되었다.

사실 그때 힘든 환경에서 개발하는게 마냥 쉽지만은 않았지만,
그 경험덕분에 앞으로 어떤 환경이 주어지더라도 빠르게 적응해서 프로덕트를 만들어낼 수 있을 것이다.  
쉽지 않은 상황에서 나에게 가장 큰 원동력이 되어주는 건 바로 같이 하는 `동료들`이다.

## 두번째 원동력: 성취감

지금 회사에서는 지라로 업무 관리를 한다.
내가 맡은 업무의 설명과 개발 기간, 상태, 관련된 인물 등 업무 정보를 입력하는걸 '지라 티켓을 딴다'고 한다.
개발 진행상황을 계속 지라에 업데이트하는데... 이 지라 티켓을 관리하는게 너무 재미있다.

### 지라 재밌어요. 왤까요?

#### 1. 업무 상태를 바꿀 때의 손맛

할 일을 지라 티켓으로 배정받고 하나하나 끝낼 때마다 지라 티켓 상태를 `진행 중`에서 `개발 완료`로 바꾼다.
아이에게 성취감을 주려면 일을 잘개 쪼개서 작은 성취를 여러개 맛보게 하라고 했던가. 지라 티켓 상태를 바꿀 때가 바로 그렇다.
손맛이 있다. 꽤 큰 심리적 보상으로 다가온다.

#### 2. 내가 한 일을 정량적으로 체크 가능

지라에는 스토리포인트(`SP`)라는 '해당 업무를 끝내는데 얼마의 시간이 걸리는지를 산정하는 지표'가 있다.
`SP`는 담당자가 아니라 개발자 평균을 기준으로 산정된다.
지라 내 쿼리문을 작성해 내가 한 달동안 완료한 스토리 포인트를 조회할 수 있다.
1점이 반나절 기준이니 만약 8월에 SP 40점만큼의 일을 완료했다면 20일치의 일을 했다고 볼 수 있다.

## 결론: 사람과 성취감이 내 원동력이다

결론적으로 직장인으로서의 나를 `move forward`하게 해주는 가장 큰 두가지는 사람과 성취감이다.  
외향적인 성격이란 자기 외부, 즉 사회와 사람에게서 힘을 얻는 성격이라고 했는데 내가 정말 그렇다.
함께 성장하고 의견을 나눌 수 있는 동료들을 만나 긍정적인 피드백을 주고받는 게 생각보다 큰 힘이 된다.

앞으로도 성취감과 생산성을 높게 유지할 방법을 계속 찾으면서 **지속 가능한 개발, 회사 생활**을 해야겠다.
직장인 생활 1.5년차... 직장인으로서 나만의 스트레스 해소법과 동기부여 방법을 찾아가고 있는 것 같아 기쁘다.


직장인으로서의 나를 계속 앞으로 나아가게 해주는 원동력은... (더보기)

My biggest motivation


[원문](https://matt-rickard.com/reflections-on-10-000-hours-of-programming)

무엇에서든 월드 클래스 실력을 가지는 방법은 올바른 방법대로 약 만 시간의 시간을 훈련하는 것이다. [아웃라이어, 말콤글래드웰]

글쓴이가 순전히 **코딩**(소셜 스킬, 매니징 스킬 등 제외)을 만 시간 하며 느낀 것을 적었다. 
그는 의도적으로 코드를 일만 시간 짜보았다고 한다. 그 중에서 보다 와닿은 것을 번역해보았다.

1. 공식문서를 읽는 것이 스택오버플로우에서 답을 찾는 것보다 거의 항상 빠르다.
2. 많은 경우에 당신이 찾는 답은 인터넷에 있지 않다. 그 말은 그 문제가 어렵거나 중요하거나 둘 다라는 것이다.
3. 가능한 한 코드를 많이 지워라
4. Syntactic sugar는 보통 나쁘다.
5. 단순하게 하는 건 어렵다.
6. 다양한 종류의 툴을 갖고 적절한 때에 무엇을 사용할지 알아두어라.
7. git이나 bash처럼 자주 사용되는 것들의 내부 원리를 알아두어라.
8. 반복되는 워크플로우의 경우 당신만의 툴을 만들어두어라. 자기가 직접 만든 게 그 무엇보다도 빠르다.
9. 만약 코드가 못생겼다면, 그건 나쁜 실수일 경우가 많다.
10. docstring이 아닌 주석을 달아야하는 코드는 리팩토링이 필요하다. 
11. 당신의 프로그램이 프로덕션에서 어떻게 구동되는지 이해 못한다는 것은 그 프로그램을 이해하고 있지 않단 뜻이다. 
최고의 엔지니어들은 자신의 프로그램이 모든 환경에서 어떻게 작동하는지 안다.
12. 11번은 빌드 파이프라인에서도 마찬가지다.
12. 쉽게 재작성할 수 있는 소규모 라이브로리나 일부분만 사용할 큰 라이브러리의 경우, 의존성을 직접 갖지 말아라.
13. [룰을 깨야할 때를 알아라. "don't repeat yourself" 같은 규칙의 경우, 가끔은 조금 반복하는게 더 낫다.](https://matt-rickard.com/dry-considered-harmful/)
14. 변수명을 정확하게 지어라. 예술과 같은 작업이다.
15. 결과적으로, 다른 분야의 엔지니어들은 세상을 다르게 바라본다.
16. 몇몇 프로그래머들은 다른 사람보다 10배 이상 효율적이다. 
17. 10배 더 나은 프로그래머인 것과 10배 더 나은 직원이 되는 데에는 연관이 없다. (어쩌면 반비례할 수도 있다.)
18. 좋은 API들은 사용하기 쉽고, 잘못 사용하기가 더 어렵다.

Reflections on 10,000 hours of programming

'일만 시간 프로그래밍을 한 개발자가 느낀 점' 번역


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

## 이직할 회사를 고르다

이전에 다니던 회사에서는 풀스택 엔지니어로 일을 했다.
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월의 짧은 기록


## 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'`을 주는 경우가 있다.
 웹 접근성을 위한 것으로, 스크린 리더나 보조 기기가 그 컴포넌트의 역할 등 정보를 더 잘 알게 하기 이다.


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