F개발자의 에러로그

Javascript - 호이스팅에 관하여

보오 — Sun, 1 May 2022 14:13:30 +0900

자바스크립트에서 함수 호이스팅이란?

함수를 먼저 실행시키고 함수선언문(Function Declarations)을 나중에 작성해도 자바스크립트에서 해당 함수를 실행시킬 수 있는 것.

함수선언문(Function Declarations) - fucntion MyFunc(){} 형태의 함수 선언문
함수표현식(Function Expressions) - 변수에 함수를 할당하는 방식(JS의 유연한 특성)

→ JS 컴파일 시점에 나중에 선언된 함수에 대한 메모리를 할당해놓은 상태이기 때문에, 실행 시점에 선언된 함수의 식별자 정보를 이미 알고 있음.

정확히 말하면 자바스크립트는 함수만 호이스팅 할 수 있는게 아니라 변수까지 호이스팅 가능하다.

그 전에 자바스크립트가 변수를 할당하는 과정을 알아야 한다.

자바스크립트가 변수를 할당할 때 < 선언 → 초기화 → 할당 >의 과정을 거친다.

선언: 파싱 과정에서 변수 객체가 변수에 대한 식별자들을 수집하는 일
*초기화: 식별자에 메모리를 할당하고 undefined 상태를 부여함
할당: 변수 안에 직접 값을 넘겨줌

위 과정에 의해 var, let, const 호이스팅에 차이점이 발생한다.

선언된 함수는 상단에서 참조, 호출이 가능하다.
선언된 var는 상단에서 참조, 할당이 가능하다.
선언된 let, const는 상단에서 참조, 할당이 불가능하다.

왜 var는 되고 let, const는 안되나?

변수가 할당되기까지는 선언/초기화/할당의 3가지 단계를 거침

var는 호이스팅이 발생하면 선언과 초기화가 거의 동시에 이루어져서 실행 시점에 스코프 최상단에서 해당 변수에 대한 메모리가 살아있기 때문에 참조, 할당이 가능

let, const는 호이스팅이 발생 시 선언만 이루어지기 때문에 선언부를 만나기 전 까지는 초기화가 이루어지지 않은 상태. 따라서 해당 변수에 대한 메모리가 존재하지 않기 때문에 선언하기전에는 참조, 할당이 불가능

** let, const 선언문 전에 호출하는 경우 ⇒ 참조에러 발생

실제로 let 또는 const로 선언한 함수표현식을 상단에서 사용하려고 하면 초기화 하기 전에 접근할 수 없다는 ReferenceError가 나온다.

→ 위 현상을 TDZ(Temporal Dead Zone), 일시적 사각지대라고 한다. 변수는 존재하지만 초기화되어 있지 않은 상태이다.

** var에 함수를 할당하고 나중에 호출하는 경우 ⇒ 타입에러 발생

var 변수 sayHi는 참조는 가능하지만, 초기화만 이루어지고 함수가 할당이 되지 않은 상태이기 때문에 TypeError가 발생

참조에러(Reference Error): 엔진이 스코프에서 대상을 찾을 수 없을 때 발생. ex) 선언되지 않은 변수를 사용하려고 할 때, 없는 변수를 사용하려고 할 때
타입에러(Type Error): 엔진이 스코프 검색은 성공했으나, 대상을 가지고 불가능한 시도를 하였을 경우. ex) 함수가 아닌데 함수처럼 사용하려고 했을 때, iterable이 아닌데 iterator로 순회하려고 했을 때

참고 문서:

Arrow function | PoiemaWeb

[JS] ReferenceError / TypeError

함수 표현식 vs 함수 선언식

호이스팅에 대한 오해와 진실

JavaScript, 인터프리터 언어일까?

useSWR, 그리고 stale-while-revalidate

보오 — Wed, 13 Apr 2022 02:06:03 +0900

노션으로 깔끔하게 보기: https://glistening-seashore-ed4.notion.site/useSWR-stale-while-revalidate-0e829551bc624b338b9bcfae97faa4a1

useSWR, 그리고 stale-while-revalidate

useSWR을 사용하는 이유: 전역 상태관리를 위해 + 캐시를 효과적으로 사용하기 위해

glistening-seashore-ed4.notion.site

useSWR을 사용하는 이유: 전역 상태관리를 위해 + 캐시를 효과적으로 사용하기 위해

잠깐, SWR이 뭔데?

공식문서에도 나와있지만, 다들 눈에서 자동으로 필터링 했을 것이므로 한번 더 언급하자면 useSWR에서 SWR은 stale-while-revalidate의 약자이다.

stale-while-revalidate란?

RFC 5861에서 정의된 용어로, 캐시가 가지고 있는 stale response가 유효한 지 백그라운드에서 재검증하는 동안 해당 stale response를 즉시 리턴하여 네트워크 지연 시간을 숨기는 전략

stale response? 최신이 아닌 낡은 데이터

stale(사전적 의미): 신선하지 않은, 낡은, 썩은

쉬운 예시)

- 유통기한: max-age

- 실제 음식이 상했는지? stale-while-revalidate

⇒ 유통기한 지났다고 음식을 못먹나? 그건 No No.

배민 예시)

나에게 보이는 화면은 “접수 전"인데 실제 사장님은 이미 접수를 했음

response가 전달되기 전에는 “접수 전"이라는 데이터는 stale한 상태

실제 response가 와서 상태를 업데이트 시켜주기 전까지는 client에서는 이러한 stale 데이터가 존재하기 마련.

캐시컨트롤 예시)

Cache-Control: max-age=600, stale-while-revalidate=30 (캐시 유효기간은 5분, stale 기간은 30초로 설정한 상태)

- 600초 내에서는 이 데이터는 유효하다 → 계속 캐시에서 가져온다. (새로 요청 X)
- 600초가 지난 후 610초가 되었다면?
    → 이미 낡은 데이터. “stale”한 데이터로 취급. 일반적으로는 loader가 돌면서 API을 다시 호출해야함.
- 만약 stale-while-revalidate가 설정되어 있다면?
    → “캐시 유효기간이 지난 후에도 설정한 시간동안은 만료된(stale한 상태의) 캐시데이터를 받아오겠다”는 뜻
    → 610초에 조회 시 로더가 아닌 낡은 데이터를 일단 보여줌. 그동안 refetch가 진행되고 response가 오면 상태가 반영 됨.

그래서 stale-while-revalidate가 왜 좋은건데?

- latency가 숨겨짐: refetching 동안 loader을 보여줘야 하는 불필요한 UI 변경을 막음

- 좀 더 유연하게 캐시데이터를 활용할 수 있음: 만료되었다고 무조건 끝이 아니다!! (유통기한 지났다고 못먹는 음식이냐!!)

(출처: [LIVE] React Query와 상태관리 :: 2월 우아한테크세미나)

위 컨셉을 적용한 것이 react-query, useSWR 등의 라이브러리다.

useSWR을 사용하는 가장 큰 이유

두 가지 이유가 있다.

하나는 “상태관리를 전역으로 하기 위해”,

두번째는 위에서 언급한 “캐시를 효과적으로 사용하기 위해”이다.

알고 보면 두 개가 연결된 것인데, 첫번째부터 설명하겠다.

상태관리를 전역으로 하는 것이 뭔가요?

리액트와 같은 프레임워크에서 변할 수 있는 값이라면 모두 “상태”라고 지칭한다.

이 상태는 기본적으로 컴포넌트 단위로 관리가 된다.

예를 들어 유저정보를 보여주는 <UserProfile/>이라는 컴포넌트가 있고 해당 컴포넌트가 userInfo의 상태를 갖는다고 하자.

<UserProfile/> 컴포넌트는 대략 이렇게 생겼을 것이다.

const UserProfile = async() => {

	const { data: userInfo } = await axios('/user/me');

	return(
		<ul>
			<li>{userInfo.name}</li>
			<li>{userInfo.email}</li>
			<li>{userInfo.regDate}</li>
		</ul>
	)
}

userInfo는 비동기로 /user/me 라는 API를 통해 가져오는 데이터다.

그런데 개발하다보면 이 유저정보 데이터가 이 <UserProfile/> 컴포넌트에서만 쓰일리가 없다.

예를 들어 유저정보를 주문정보를 보여주는 <OrderInfo/>라는 컴포넌트에서도 보여준다고 가정해보자.

이 때, <OrderInfo/> 컴포넌트에서 userInfo을 얻는 방법은 두 가지가 있다.

1. ajax로 API에서 가져오기

2. UserProfile에서 사용하는 userInfo을 <UserProfile/>, <OrderInfo/> 둘 다 품고 있는 부모컴포넌트로 옮기고 부모컴포넌트에서 props로 상속받기

두 방법 다 비효율적이다. 1번은 같은 API을 중복으로 호출하는 문제가 있고, 2번은 <UserProfile/>, <OrderInfo/> 모두를 품고있는 부모를 찾아 상위 컴포넌트를 거슬러 올라가야 한다. (만약 교집합이 없다면 <App/>까지 올라갈 것이다..)

이런 비효율을 해결하기 위해 나온 것이 아직도 널리 쓰이고 있는 redux 상태관리 라이브러리다.

각 컴포넌트에서 필요한 상태를 전역으로 관리하여 컴포넌트에서 독립적으로 쓸 수 있도록 부모자식 상관없이 아무 컴포넌트에서나 막 꺼내 쓸 수 있도록 만든 것이 redux이다.

그러나 redux는 훌륭한 취지와는 다르게 사용하다보면 마냥 아릅답지만은 않다.

store을 만들고, store을 업데이트 할 수 있는 액션을 정의하고, 액션을 실행하는 reducer을 만들고.. 러닝커브도 러닝커브지만, 세팅하는데 필요한 boiler-plate가 많아진다. 한가지 상태관리를 위해 코드를 최소 30줄은 짜야 한다.

비효율을 해결하기 위해 나온 기술이 더 비효율 적인 상황이 발생한 것. ~~개발자는 언제나 비효율적인 것을 못참지. 특히 프론트개발자는 더더욱.~~

그래서 나온 것이 react-query, useSWR 등의 새로운 상태관리 라이브러리다.

구구절절한 화려하기만 한 boiler-plate 필요없이, 한줄이면 아주 간편하게 상태관리를 할 수 있다.

const { data } = useSWR(key);

네? 이걸로 전역 상태관리가 가능하다구요?

넵. 왜냐면 uswSWR은 여러 컴포넌트에서 데이터를 호출해도 내부적으로 캐시하여 상태를 ‘기억'하고 있거든요.

위의 <UserProfile/>, <OrderInfo/> 컴포넌트를 예시로 들자면 이렇게 쓸 수 있다.

const UserProfile = () => {

	const { data: userInfo } = useSWR('/user/me');

	return(
		<ul>
			<li>{userInfo.name}</li>
			<li>{userInfo.email}</li>
			<li>{userInfo.regDate}</li>
		</ul>
	)
}

// OrderList은 유저의 주문정보가 담긴 컴포넌트임.
const OrderInfo = () => {

	const { data: userInfo } = useSWR('/user/me');

	return(
		<div>
			<div>{userInfo.email}</div>
			<OrderList/>
		</div>
	)
}

위 코드를 처음 보면 “어? /user/me가 두번 호출되는거 아니야?”라고 생각할 수 있지만, useSWR에서 내장된 캐시로 데이터를 처리하기 때문에 실제로 요청은 1번만 가게 된다.

의심이 된다면 당장 네트워크 탭을 열어 확인해보자.

실제로 필자가 만들고 있는 앱에서는 useSWR을 사용해 유저정보를 가져오는 부분이 있는데, 총 29개의 컴포넌트에서 사용하고 있으나(헤더, 푸터, 등등) 요청은 단 한번만 간다.

이유는 useSWR의 첫번째 인자로 받는 string 값(— api_enpoint가 들어가는 자리)을 key라고 부르는데, 이 key가 같을 경우 uswSWR에서 같은 데이터라고 보고 상태를 공유하기 때문이다.

위 예시에서는 key가 ‘/user/me’로 같으니 컴포넌트가 달라도 상태가 전역으로 공유되어 한번만 요청하는 것이다.

그러면 앞서 언급한 두 가지 문제 — API 중복 호출, 부모 컴포넌트로부터 props을 내려받아야 하는 문제가 한번에 해결된다.

redux보다 훨씬 쉽고 간편하다. ~~(리덕스 이해하는데 2달 걸림...)~~

이러한 장점때문에 리덕스의 대안으로 급부상하여 useSWR 지분이 점점 커지고 있다.

여기까지가 첫번째 이유고, 두번째 이유는 “캐시를 효과적으로 사용하기 위해"이다.

공식문서를 보면 알겠지만, useSWR은 데이터 캐시에 대한 아주 다양한 옵션들이 있다.

이 옵션을 통해 처음에 언급한 stale 시간, cache 시간을 설정할 수 있으며 dedupingInterval, revalidateIfStale 등을 지정하여 유연하게 사용할 수 있다.

또한 mutate를 사용해 데이터를 즉각적으로 갱신 또는 API Response가 오기 전에 미리 갱신할 수 있다.

두번째 이유는 글이 너무 길어질 것 같으므로 useSWR 사용법과 함께 자세히 설명하겠다.

useSWR 사용법은 다음 포스팅으로..

— Reference

전역 상태 관리에 대한 단상 (stale-while-revalidate)

비동기 전역관리 redux 말고 편하게 SWR 로!

[Cloudflare 시리즈3] 클라우드플레어 사이트최적화 - 스피드

보오 — Sun, 10 Apr 2022 16:38:54 +0900

1. 클라우드플레어 작동원리

2. 클라우드플레어 사이트 최적화 - 캐싱

3. 클라우드플레어 사이트 최적화 - 스피드

클라우드플레어 스피드 메뉴에서는 사이트의 속도를 분석해주면서 다양한 최적화 서비스를 제공한다.

Speed 개요 탭에서는 속도 분석 결과를 제공하는데 자세히 보면 기준이 South Carolina, USA다.

즉, 미국 기준으로 1.1초 후에 페이지 로딩이 시작된다는 뜻으로 우리나라의 기준과 다소 맞지 않다.

이 부분은 그냥 패스하면 된다.

(구글 개발자도구로도 충분히 분석이 가능하니..)

최적화 탭을 보면 속도 개선을 위한 다양한 옵션이 있다.

이미지 크기 조정, Polish, 자동최소화, Brotli, URL 프리패치, 로켓 로더 등 엄청 많지만,

대부분이 유료이고 무료로 쓸 만한 것들로는 자동최소화와 로켓로더가 있다.

그러나 이 두개만 적용해도 충분히 속도가 향상된다.

1. 자동최소화(Auto Minify)

Minify를 하면 모든 주석과 공백이 제거되고 코드가 한 줄로 줄어들어 용량을 최소화 할 수 있다.

각 언어마다 미니파이 모듈도 있고 VSC 익스텐션도 있어서 직접 해줄 수도 있지만

클라우드플레어를 사용한다면 Auto Minify 설정으로 한번에 가능하다.

사진처럼 체크 해준 뒤 캐시 Purge(삭제)를 하면 바로 적용된다.

*** 응답 헤더의 cf-bgj: minify 설정은 클플을 통한 Auto minify가 되어있다는 뜻이다.

minify가 적용된 파일은 Response 탭을 통해 확인할 수 있는데 띄어쓰기, 줄바꿈 없이 코드가 깔끔하게 한줄로 바뀌어있다.

2. 로켓 로더(Rocket Loader) 켜기

페이지 로딩 시간을 지연시키는 요소 중 하나가 브라우저의 렌더링 차단이다.

일반적으로 브라우저는 html을 읽고 해석하여(이하 "파싱") 화면을 만드는데

중간에 css나 js를 만나면 파싱을 중단하고 css, js를 먼저 읽는다.

즉, 중간중간에 css나 js가 많이 끼어있을 수록 페이지 전체를 읽는 시간이 지연된다는 뜻이다.

그래서 보통은 css은 <head>영역에 넣고 js는 </body>태그 바로 직전에 넣을 것이다.

하지만 다른 이유로 중간에 js를 끼워넣는 경우도 있는데

이 때 js를 읽기 위해 html 파싱을 잠시 멈추는 것을 렌더링 차단이라고 한다.

이것을 방지하기 위해 클라우드플레어에서 로켓로더라는 서비스를 제공한다.

Speed>최적화 탭에서 확인할 수 있다.

로켓 로더가 하는 일은 이 렌더링 차단을 막는 일로

자바스크립트 로드를 지연시켜 페이지의 모든 컨텐츠(텍스트, 이미지, 글꼴 등)가 로드된 이후 자바스크립트를 읽도록 한다.

js에 defer속성과 비슷하다고 보면 된다.

(https://blog.asamaru.net/2017/05/04/script-async-defer/ 참고)

특정 파일 로켓 로더 제외하려면?

로켓로더를 섣불리 켰다가 문제가 발생할 수 있다.

**스크립트가 실행되어야만 렌더링할 수 있는 페이지의 경우(무조건 js를 먼저 읽어야 하는 경우)는 로켓로더 설정을 꺼줘야 한다.

이럴 때 제외할 스크립트 태그에 "data-cfasync=false" 속성을 추가한다.

// 클라우드플레어 로켓로더 설정 제외할 스크립트
<script data-cfasync = "false" src = "/ javascript.js"> </ script>

로켓로더를 키고 개발자도구 Lighthouse로 사이트 성능을 측정해보면

Eliminate render-blocking resources 시간이 확연히 줄어든 것을 볼 수 있다.

3. 정리하면서..

웹사이트의 성능은 매우매우 중요하다. 정신없이 개발하다보면 꼭 성능 이슈가 발생하는데, 사이트 성능은 SEO와도 직결되어 사이트 유입에 막대한 영향을 끼치므로 시간을 내서 투자해야 한다.

요즘엔 브라우저 성능이 워낙 좋아져서 거기서 거기라고 생각할 수 있지만, 메모리누수, 불필요한 로직이 쌓이고 쌓이다보면 웹을 점점 느리게 만든다. 그런 면에서 클플은 개발자가 일일이 설정해줘야 할 작업을 알아서 해주기 때문에 매우 편하고 강력한 서비스라고 할 수 있다. (물론 그 전에 코드로 할 수 있는 최적화 작업은 모두 해놓는 것이 기본)

"클라우드플레어가 좋대"라는 말만 듣고 단순히 등록만 해놓는 것 보다, 네트워크 구조와 클라우드플레어의 작동원리를 알고 자기 사이트에 맞게 설정한다면 클플을 120% 활용할 수 있다.

클플은 세계 1위 CDN 기업인 만큼 이 시리즈에서 설명한 것 보다 훨씬 많은 기능들(API제공, 보안설정 등)이 있으니, 여유될 때 한번씩 써볼 것을 추천한다.

[Cloudflare 시리즈2] 클라우드플레어 사이트최적화 - 캐싱

보오 — Sun, 10 Apr 2022 16:07:12 +0900

1. 클라우드플레어 작동원리

2. 클라우드플레어 사이트 최적화 - 캐싱

3. 클라우드플레어 사이트 최적화 - 스피드

클라우드플레어를 이용해 웹페이지 최적화를 하고 싶다면 수많은 메뉴 중 캐싱, 스피드 2가지만 알아도 충분하다.

1. Caching
2. Speed

이 페이지에서는 이 중 캐싱을 다룬다.

1. Caching 상태 분석

①Analytics 메뉴 활용하기

클라우드플레어는 기본적으로 모든 리소스를 캐시한다.

Analytics > Traffic 메뉴를 보면 친절하게 캐시된 요청과 캐시되지 않은 요청을 보기 쉽게 차트로 보여준다.

②네트워크창에서 헤더로 분석하기

네트워크 탭에서 CSS 필터링 한 결과

캐싱이 잘 되었다면 Size에 memory cache(또는 disk cache)로 나오고 Time이 모두 0이다.

캐시파일의 경우 TTFB가 확연히 줄어들어 SEO 향상에도 도움이 된다.

클라우트플레어 캐시 파일의 네트워크 탭

캐시되고 있는 파일 아무거나 클릭해보면

Response Headers의 속성으로 cache-control, cf-cache-status, server가 나온다.

이 때 캐시컨트롤은 클라우드플레어에서 설정한 값으로 나오는데,

예시 화면의 2678400은 초단위로 나타낸 것으로 캐시 TTL 설정으로 1달로 한 것이다.

server는 실제 사용중인 웹서버가 아닌 cloudflare로 표시된다.

cf-cache-status는 캐시 상태를 나타낸 것으로 바로 아래서 더 자세히 알아보자.

③cf-cache-status에 따른 캐시 상태 분석

HIT	정상적으로 캐시되고 있음
MISS	클라우드플레어 캐시서버에서 리소스를 못찾아 오리진서버(Origin Server)까지 간 상태 (아무것도 캐시되지 않은 최초 사이트 로드 시 발생함)
EXPIRED	파일이 캐시에 있지만 보관기간이 지나서 오리진서버로 갔다옴 (보통 해당 캐시파일을 지우거나 TTL 시간이 만료되면 발생함)
STALE	EXPIRED 되어서 오리진서버로 갔지만 해당 파일을 찾지 못함 (보통 해당 파일이 삭제된 경우 발생함)
BYPASS	헤더의 Cache-Control 설정이 "no-cache, private, max-age=0"인 경우 오리진서버로 직행함 >> 캐시컨트롤을 no-cache로 해놓으면 클라우드플레어는 캐싱하지 않음
UPDATING	오리진서버에서 캐시서버로 업데이트 중 (보통 캐시가 만료되어 오리진서버에 갔다가 다시 저장할 때 발생, 주로 요청이 많은 리소스 or 캐시 삭제 후 최초 접속했을 때 일어남)
DYNAMIC	사용자 정의에 따라 캐시하지 않기로 함

(클플 공식 문서: https://developers.cloudflare.com/cache/about/default-cache-behavior/ )

2. 클라우드플레어 캐시 규칙

클라우드플레어에도 물론 캐시 규칙이 있는데 다음과 같다.

① Cache-Control 헤더가 "no-cache, private, max-age=0" 중 하나로 설정되어 있을 경우 캐시하지 않는다.

② 반대로 Cache-Control 헤더가 **"public"**이면서 "max-age"가 0보다 큰 경우나 Expires 속성이 미래 날짜로 되어 있는 경우 캐시한다.

③ Cache-Control "max-age"와 Expires가 둘 다 설정된 경우 max-age를 따른다.

확장자 기준으로 캐시

다음의 확장자를 포함하는 파일들만 캐시한다.

bmp	ejs	jpeg	pdf	ps	ttf
class	eot	jpg	pict	svg	webp
css	eps	js	pls	svgz	woff
csv	gif	mid	png	swf	woff2
doc	ico	midi	ppt	tif	xls
docx	jar	otf	pptx	tiff	xlsx

이에 더하여 robots.txt 파일도 캐시한다.

3. 클플 캐시 삭제하기

클플에서는 기본적으로 캐시파일들의 업데이트 상태를 항상 확인하지만 간혹 파일의 변경이 일어났는데 이전 파일을 계속 불러오는 경우가 있다.

이때는 캐시플러시를 통해 삭제해줘야 한다.

캐싱 탭에서 할 수 있는데 사용자 지정 제거와 모두 제거 속성이 있다.

일반적인 웹사이트 캐시 제거시에는

모두 제거를 하면 사이트 전체 리소스의 캐시가 삭제되어 오리진 서버에서 한꺼번에 가져와야 하기 때문에 갑자기 많이 느려질 수 있다.

따라서 사용자 지정 제거를 통해 특정 파일만 제거하는 것이 안전하다.

캐시파일 url로 제거할 수 있는데, 예를 들어 static 경로의 style.css 라는 파일을 삭제하고 싶다면 "${DOMAIN}/static/style.css" 라고 입력하면 된다.

4. 브라우저 캐시 TTL 설정하기

TTL(Time To Live)은 캐시파일을 저장되는 시간을 의미한다.

클라우드플레어 캐싱 창에서는 TTL 또한 설정할 수 있는데 최소 30분~1년 단위로 가능하며

'기존헤더유지'를 선택하면 서버에서 설정해놓은 헤더대로 설정이 가능하다.

또한 개발 모드 ON으로 하면 캐시를 일시적으로 저장하지 않고 오리진 서버에서 바로 가져오게 된다.

(직접 끄지 않으면 3시간동안 유지된 후 자동으로 OFF 된다.)

캐시 TTL 기준은 어떻게 설정하면 좋을까?

ⓛ 바뀔 일이 잘 없는 컨텐츠는 보통 3개월 이상 길게 잡는다.
(파비콘 같이 거의 바뀔 일 없는 리소스는 1년 이상 길게 잡기도 한다.)

② 변동이 많은 리소스의 경우 15분~1시간으로 설정하기도 한다.

③ 캐시를 가능한 많이 활용하는 것이 좋다. 아무리 짧은 TTL이라도 no-cache보다 낫다.

5. 특정 리소스만 캐시하지 않게 하려면

여러 사정에 의해 특정 파일만 캐시에서 제외하고 싶을 때가 있다.

그럴 때 규칙 메뉴에서 "Page Rule 생성"을 누른 후

리소스 경로 입력 후 캐시 수준을 "바이패스", 원본 캐시 제어를 ON하면 된다.

네트워크 탭에서 cache-control이 "no-cache", cf-cache-status가 "DYNAMIC"으로 설정된 것을 확인할 수 있다.

추가로 규칙 탭에서는 캐시 제어 뿐만 아니라 리디렉션, 무결성검사, HTTPS만 사용하도록 설정 등 보안, DNS에 관한 다양한 룰을 설정할 수 있다.

[Cloudflare 시리즈1] 클라우드플레어 작동원리

보오 — Sun, 10 Apr 2022 15:11:21 +0900

1. 클라우드플레어 작동원리

2. 클라우드플레어 사이트 최적화 - 캐싱

3. 클라우드플레어 사이트 최적화 - 스피드

1. 클라우드플레어는 어떻게 작동하는가

클라우드플레어(Cloudflare)는 DNS와 CDN 서비스를 제공하는 미국 기업이다.

도메인 네임 서비스를 제공하면서 트래픽 필터링도 해주고 Ddos도 차단해주고 분석도 해주고 CDN도 알아서 해주고.. 보안이나 성능, 사이트 안정화 등 여러 면에서 아주 우수한 서비스를 제공한다.

많은 서비스가 있지만 프론트 엔지니어라면 사이트 성능 개선과 최적화에 초점을 맞추어 클라우드플레어를 이용해야 한다.

그 전에 알고 가야할 것이 있다.

①클라우드플레어에서는 기본적으로 캐싱을 해준다.
②(만약 프록시서버에서 캐싱 설정을 했으면)클라우드플레어에서 캐싱이 먼저 이루어진다.

이를 이해하려면 클라우드플레어의 동작 원리를 알아야 한다.

(좌) 일반적인 서버 (우) 클라우드플레어 경유하는 서버

만약 웹서버가 nginx 리버스프록시를 사용하고 있다면 이렇다.

<일반적인 DNS 서버>

DNS에서 Nginx 리버스 프록시 경유 후 실제 포트를 띄움

<클라우드플레어 경유하는 DNS 서버>

DNS에서 클라우드플레어에 들리고 Nginx 리버스 프록시 경유 후 실제 포트를 띄움

유저가 url에 도메인 주소를 치면 클라우드플레어를 경유하여 ip로 된 실제 웹 서버에 도달한다.

2. 캐싱은 어디서 일어날까?

①일반적인 캐싱

클라우드플레어가 없는 경우

클라우드플레어 없이 엔진엑스에서 캐싱을 한다면 위 그림처럼 요청서버와 엔진엑스 사이에서 일어날 것이다.

네트워크탭에서 간단하게 확인해볼 수 있는데,

Response Headers에 "X-Proxy-Cache" 속성이 프록시 서버 캐싱 여부를 말해준다.

②클라우드플레어 캐싱

클라우드플레어가 있는 경우

클라우드플레어를 사용한다면 오리진 서버로 도달하기 전에 캐싱이 일어난다.

역시 네트워크탭에서 보면 "cf-cache-status" 속성이 추가되었을 것이고 서버는 클라우드플레어로 바뀌어있을 것이다.

③만약 엔진엑스 캐싱과 클라우드플레어 캐싱이 동시에 적용되어 있다면?

애초에 엔진엑스까지 갈 일이 없으니 아무리 엔진엑스에서 캐시 설정을 해도 안될 것이다.

이때문에 종종 내가 설정한 Cache-Control이 덮어씌워질 때가 있는데

클라우드플레어에서 설정한 값으로 덮어씌워진 경우일 수 있다.

예를 들면 엔진엑스에서 max-age를 3달(7776000)로 설정했지만 클라우드플레어 설정에서 1달로 해놓았다면 max-age가 1달(2678400)로 바뀌어있을 것이다.

3. 클라우드플레어 캐싱 특징

①동적, 정적 파일 모두 클라우드플레어를 거친다.

설정하기 나름이지만 일반적으로는 거의 바뀌지 않는 정적 파일(js, css, img, favicon 등)만 캐시 서버를 거친다.

그러나 클라우드플레어는 그런거 없고 동적 파일까지 모두 클라우드플레어를 경유하도록 되어있다.

그리고 동적 파일만 분류하여 클라우드플레어를 거치지 않게 하는 것은 불가능하다.

Q. 캐싱이 필요없는 파일까지 클라우드플레어를 거치면 서버가 느려지지 않을까?

A. 그렇지 않다.클라우드플레어에 따르면 클플에서 전세계에 Edge를 두고 그 엣지들을 이어놓은 네트워크 회선을 사용하고 있기 때문에 거쳐야 할 hops 수가 줄어들어 오히려 빠르다고 한다.
그러나 이 부분은 주의해야할 것이 한국의 경우 엔터프라이즈 유저(유료 멤버)가 아니면 한국 Egde 사용이 불가하다고 한다. 상황에 따라 더 느려질 수 있다는 뜻이다.

②특정 파일만 캐싱되게 할 수 있다.

클라우드플레어 Page Rules 라는 메뉴에서 룰을 추가해줌으로써 일부 파일들은 캐싱이 되지 않게 또는 일부 파일들만 캐싱되게 설정할 수 있고 쿼리문으로도 제어가 가능하다.

nginx도 설정으로 가능하기 때문에 클플만의 특징은 아니지만 까다로운 정규식을 사용하지 않고 누구나 쉽게 설정할 수 있다는 점.

③클라우드플레어 캐싱 설정은 어디서 하는가?

클라우드플레어에는 다양한 기능들이 있는데 이 중 "Caching"에서 할 수 있다.

유료 멤버 대상으로는 캐시 분석까지 해주지만

무료여도 캐시 삭제, 캐시할 양 설정, TTL 설정 등 유용한 기능을 제공한다.

④사이트가 다운되어도 캐싱페이지를 보여주므로 일시적으로는 문제 없다.

클라우드플레어 최대 장점이라고 볼 수 있다.

캐시에 관한 최소한의 모든 것(1)

보오 — Sun, 27 Feb 2022 23:45:20 +0900

** 노션에서 더 편하게 보기

https://glistening-seashore-ed4.notion.site/f4a5838d303248918c146b40c9ac4b8a

캐시에 관한 최소한의 모든 것

캐시란?

glistening-seashore-ed4.notion.site

캐시란?

요청에 대한 응답의 복사본을 어딘가에 저장해놓고, 같은 요청이 들어오면 (서버에) 재요청하지 않고 저장한 복사본 데이터를 보내주는 것.

어떤 요청인가?

유저의 GET요청. 보통 POST요청은 캐시하지 않는다. 일반적으로 200, 301, 404 응답을 캐싱한다.

어디에 저장하나?

프록시 서버에 생성된 캐시 메모리 또는 클라이언트의 개인적인 공간(브라우저 등)에 저장한다. 이는 추후 설명하게 될 공유캐시(Public)/사설캐시(Private)가 된다.

왜 이런 행위(캐시)가 필요하나?

원본 데이터가 있는 곳은 원본 서버(Origin Server)라고 한다. 웹에서 클라이언트는 브라우저에서 요청을 시작한다. 브라우저를 통한 요청은 서버로 향하는데, 이때 오리진 서버로 가는 행위는 시간과 자원이 오래 걸린다. 그래서 그 사이에 캐시메모리라는 공간을 두고, 만약 클라이언트가 동일한 요청을 했고 그 요청에 대한 응답이 동일하다면, 굳이 서버까지 가지 않고 중간에 캐시메모리에서 데이터를 찾아서 던져주기로 한다. 클라이언트는 똑같은 상태의 데이터를 이전보다 더 빨리 받게 된다. 서버는 자원을 아끼고, 클라이언트는 응답을 더 빨리 받고 클라이언트, 서버 둘다 윈윈이다.

그러나 캐시메모리에는 명확한 제한이 있는데, 바로 크기다. 일시적으로 복사본을 저장하는 공간인 만큼 서버의 아주 작은 공간만을 할당 받는다.

그래서 캐시메모리가 다 차면 안에 있는 데이터를 삭제하여 공간을 만들고, 새로운 요청에 대한 응답을 다시 저장하는데 이때 어떤 데이터를 삭제할 것인지가 중요해지는데, 이를 결정하는 로직이 캐시 알고리즘이 있다.

캐시 알고리즘

캐시 교체 정책이라고도 하며, LRU, LFU, FIFO 등 여러 알고리즘이 있지만 LRU가 가장 많이 쓰인다.

LRU(Least Recently Used)

캐시메모리에서 사용된지 가장 오래된 페이지(— 캐시에서 각 데이터를 일컫는 말)를 지우는 방식

“오랫동안 쓰지 않은 데이터는 앞으로도 안쓸 것이다”라는 가정에서 나온 알고리즘이으로, 구현이 쉽고 가장 보편적인 방법이다.

LRU 알고리즘

요청이 들어온다.
캐시에 없는 데이터면 원본 서버에서 데이터를 가져온 후 응답해주면서 캐시에 저장한다.
캐시에 있는 데이터면 캐시에서 빼서 준다.
캐시에 없는 데이터를 요청하는데 캐시가 다 찼을 경우, 가장 마지막에 쓰인 데이터를 지우고 방금 요청한 캐시를 가장 뒤(tail)에 둔다.
캐시에 있는 데이터 요청 시 해당 데이터를 가장 뒤(tail)로 옮기고 응답한다.

중요한 것은 가장 최근 응답한 데이터는 항상 맨 뒤로 순서를 옮긴다는 것이다.

배열로 생각하면 head에 가까울 수록 오래된 데이터, tail에 가까울 수록 최신 데이터라는 것이다. (array.push → 최근 페이지)

사용 알고리즘은 Doubly Linked List, HashMap이며, 시간복잡도는 O(1)이다.

간단하고 빠른 알고리즘이지만, 캐시데이터가 언제 사용되었는지를 알기 위해 timestamp을 찍는데, 이 때 오버헤드가 발생할 수 있다는 단점이 있다.

자바스크립트로 LRU 구현하기

아주 유명한 알고리즘인 만큼 코테에도 자주 출제되는데, 자바스크립트로 간단하게 구현할 수 있다.

(tail에 있는 데이터가 가장 최신이라고 가정)

리퀘스트가 들어온다. 이 때,

1. 기존 캐시데이터에 있는지 확인 후

2. 캐시에 없으면(MISS)
2-1. 캐시에 넣어준다.
2-2. 캐시가 가득차있다면, 가장 오래된 데이터를 제거하고 넣어준다. (배열의 첫번째 데이터를 제거)

3. 캐시에 있으면(HIT)
3-2. 해당 데이터를 캐시의 가장 뒤로 보낸다. (배열의 마지막으로 보냄)
3-1. 캐시에서 데이터를 꺼낸 뒤 응답한다.

// 캐시에는 사이즈가 있다.
// 사이즈가 5인 캐시메모리(최초에는 비워져 있다고 가정)
const cache_size = 5;
const cache_memory = Array.from({ length: cache_size }, () => null);

// 클라이언트가 요청하는 데이터
const request = [3, 4, 5, 3, 1, 1, 3, 6, 1, 2, 3, 5, 7, 3, 1];

req.forEach((el) => {
  const idx = cache.indexOf(el);
  // MISS
  if (idx < 0) {
    if (cache.length < size) {
      cache.push(el);
    } else {
      cache.shift();
      cache.push(el);
    }
  } else {
    // HIT
    cache.splice(idx, 1);
    cache.push(el);
  }
});

console.log(cache);

// [2,5,7,3,1]

여기에서 드는 의문점이 있다. 왜 배열의 가장 첫번째가 아닌 마지막 데이터가 가장 최신 데이터라고 하는걸까?

궁금증을 풀기 위해 head가 가장 신선하다고 여기는 로직(array.unshift)도 테스트해보았다.

위 로직에서 마지막이 아니라 첫번째로 추가하는 것으로 바꾸면 이렇게 된다.

req.forEach((el) => {
  const idx = cache.indexOf(el);
  // MISS
  if (idx < 0) {
    if (cache.length < size) {
      cache.unshift(el);
    } else {
      cache.pop();
      cache.unshift(el);
    }
  } else {
    // HIT
    cache.splice(idx, 1);
    cache.unshift(el);
  }
});
console.log(cache);

// [1,3,7,5,2]

console.time, console.timeEnd로 시간을 계산한 결과

tail에 최신데이터를 넣은 함수는 0.084ms, head에 최신 데이터를 넣은 함수는 0.117ms가 걸렸는데, 아마 속도때문에 tail에 최신 데이터를 넣기로 한 것 같다.

HTTP 요청의 캐시 설정들: Cache-Control

MDN(https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Cache-Control)에 가면 이미 자세히 나와있지만, 공부할 겸 한번 더 정리해보았다.

** (!) 라고 표시한 것은 비표준임(호환성 확인하기)

max-age

캐시의 수명. 지정한 시간(초) 동안 유효하다. ** 리소스가 유효하다고 판단하는 최대 시간으로, 이 안에 리소스가 바뀌었다면 update된다. Expires와 차이: 거의 없는데 둘 다 있으면 max-age가 이긴다. (max-age > expires)

ex) max-age=3153600 // 1년동안 캐싱

s-max-age

공유 캐시(프록시 캐시)에만 적용되는 max-age. 사설캐시는 적용되지 않는다.

max-stale

만약 캐시데이터에 max-age, 유효기간이 지난 캐시가 있을 때 이 캐시를 사용할지 여부. 있으면 지정된 시간동안 이 캐시를 사용한다는 얘기 ex) max-stale=3600 // 캐시가 만료되고 나서도 1시간 동안은 이 캐시를 사용

stale-while-revalidate(!)

max-stale과 비슷하지만 비동기 요청 동안 사용된다. 요청하는 동안 유효기간이 지난 캐시를 얼마만큼(얼마나 오랫동안) 받아들일지 여부로, 요청에 최대한 빠르고 유연하게 대응하기 위한 것이다. SWR, ReactQuery에서 이 설정이 사용된다. ex) max-age=600, stale-while-revalidate=30 // 600초가 지나서 캐시가 만료된 상태이지만, 새로운 데이터를 원본서버에서 찾고 응답이 올 때까지 그 사이 30초 동안은 일단 만료된 캐시를 보냄.

must-revalidate

캐시 만료 후 다시 조회할 경우 반드시 오리진 서버에 요청한다는 것으로, 만료된 캐시를 절대로 재사용하지 않는 다는 것이다. (그 데이터가 원본서버 데이터와 동일하건 말건 간에)

proxy-revalidate

must-revalidate와 동일하지만 공유 캐시(프록시 캐시)에만 적용된다.

immutable(!)

(만료되지 않는 한) 응답 데이터가 계속 변하지 않을 것이니, 원본을 확인하지 않고 “계~속 캐시해라” 오리진 서버에 데이터가 바뀌었는지 확인하지 않는 것으로 주로 변하지 않는 폰트, 이미지 등에 쓰인다. 이 속성의 강점은 사용자가 페이지를 새로고침 할 때마다 매번 원본과 대조하지 않아도 되니, 불필요한 요청을 하지 않을 수 있다는 것이다.

public

- 공유캐시(프록시 캐시)

공유서버에 저장해도 되는지 여부를 나타냄

private

- 사설캐시

공용 응답이 아닌 유저 개개인의 민감한 정보를 저장해야 할 경우 사용하는 속성으로, 공유 서버(프록시)에 저장하지 않고 개인 공간(브라우저 등)에 저장한다.

only-if-cached

최신본이 있을 때 서버에 확인하지 않음

no-cache

캐시를 쓰기 전에 오리진 서버에 “이거 써도 되냐”고 컨펌 받음(재검증) → 캐시를 안한다는 뜻이 아님

no-store

캐시를 끄는 설정 → 이게 캐시 안한다는 뜻

요약

캐시 끄는 설정: no-cache, no-store, must-revalidate
캐시 키는 설정: public, max-age=31536000 // 1년

보너스

What is E-tag?

각 캐시를 구분짓기 위해 붙이는 숫자, 문자가 섞인 string값으로 원본 데이터가 변하면 E-tag도 변한다. 따라서 E-tag가 변하면 원본 서버에 다시 요청한다.

** E-tag의 단점은 서버 간에 값을 공유할 수 없다는 것이다. 즉, 서버마다 고유한 E-tag 값을 가지고 있어서 똑같은 데이터여도 서버가 여러개면 E-tag가 달라진다. 그러면 원본은 그대로인데 매번 상태가 바뀌었다고 판단하여 캐시가 무용지물이 된다. 이를 방지하기 위해 E-tag을 끄는 방법도 있다. E-tag을 꺼도 Last-Modified라는 타임스탬프로 최신 데이터인지를 판단할 수 있다.

HIT || MISS ?

네트워크 탭을 보면 이렇게 cache-status가 HIT 또는 MISS 등으로 나오는데, 캐시를 했는지, 안했는지 여부다. (cf-cache-status은 클라우드플레어 캐시임)

HIT: 캐시메모리에 있어서 캐시데이터를 가져온 상태
MISS: 캐시메모리에서 찾지 못해서 원본 서버에서 가져온 상태

HIT, MISS는 깊게 파보면 Hit latency(rate), Miss latency(rate) 등 과연 얼마나 잘 캐시하고 있는지 성능을 측정하는 척도로 쓰이는 개념이 있는데, 이번 글에서는 이정도로만 마치고 다음에 이어서 파보겠다.

[코딩테스트 기초] 회문문자열 판별(재귀함수, array splice을 이용하여 - javascript)

보오 — Sun, 20 Feb 2022 15:11:23 +0900

회문문자열(palindrome)은 거꾸로 읽어도 알파벳이 똑같은 글자를 말한다.

알고리즘의 가장 기초적인 문제로 자주 등장하는데, 자바스크립트에서는 reverse 메소드를 이용하여 많이 푼다.

여기에서는 재귀함수와 splice 메소드를 이용하여 풀어보겠다.

먼저 args로 넘어온 문자를 split을 이용해 Array로 만들어주고, 재귀함수(recursive)로 돌린다.

재귀함수를 사용할 때는 무조건 if/else 구문으로 조건을 만들 것.

특정 조건을 통과하면 true을 리턴, 아니면 false을 리턴하면 된다.

여기서 특정 조건은 두 개가 되는데,하나는 배열의 길이가 1 이하일 때.글자가 1글자면 무조건 회문문자열이 된다. ex) 'a', 'i', 'x', ...

나머지 하나는?

"첫번째 글자와 마지막 글자가 같을 때"이다.이 조건을 통과하면 재귀함수를 또 호출하는데, 이번에는 Array을 splice하여 배열의 첫번째 원소와 마지막 원소를 제해야 한다.이렇게 해서 더이상 나눌 수 없을 때(array.length<=1)까지 반복하여 끝까지 살아남으면 true, 아니면 false을 리턴하면 된다.

위 시나리오를 코드로 구현하면 이러하다.

// 회문 판별(리스트 슬라이스 이용)
function palindrome(letter) {
  const arr = letter.split("");
  function DFS(list) {
    if (list[0] === list(list.length - 1)) {
      DFS(list.splice(0, list.length - 1));
      return true;
    } else return false;
  }
  return DFS(arr);
}

이렇게 쉽게 회문문자열을 자바스크립트로 구현해보았다.

(p.s. 대/소문자 구분을 안한다면 최초에 toLowerCase() 또는 toUpperCase()을 사용하여 문자열의 대소문자를 통일해주면 된다.)

[코딩테스트 기본] 10진수를 2진수로 바꾸기 (Javascript)

보오 — Sun, 20 Feb 2022 12:22:11 +0900

사실 자바스크립트에서는 Object.prototype.toString() 이라는 Web API로 진수 변환을 바로 할 수 있다.

toString의 인자로 radix(기수)을 넣으면 바로 변환을 해준다. (2~36까지만)

그래서 3을 2진수로 바꾸고 싶으면 아래와 같이 하면 된다.

let n = 3;
let res = n.toString(2);
console.log(res);

위 결과는 '11'이 될 것이다.

그러나 개발자라면 웹 API를 이용하지 않고 그냥 만들 수 있어야 한다.

코드로 구현하기 전에 수학(!!)으로 10진수를 2진수로 바꿔보자.

10진수로 된 정수 a를 2진수로 바꾼다고 하면 a를 2로 나눈 나머지와 몫을 다시 2로 나눈 나머지, 몫을 다시 2로 나눈 나머지,, 이렇게 몫을 더이상 2로 나눌 수 없을 때까지 2로 나누고 나머지를 기억해놨다가 이어붙이면 된다.

글로 하면 머리아프니까 흔히 하던 식으로 해보자.

10진수를 2진수로 바꾸는 식

일반 나눗셈 하듯이 나누되, 아래로 식이 이어지면서 옆에 나머지를 쓴다. 나머지는 1 또는 0. 더이상 나눌 수 없을 때(몫이 1이 될 때)까지 나누고 최종적으로 남은 몫과 나머지를 이어붙인다.

위 과정을 코드로 구현하면 여러가지 방법이 있을 수 있겠지만, 재귀함수를 사용해서 쉽게 구현할 수 있다.

재귀함수는 어떤 함수를 자기 자신을 호출하는 함수이다.

재귀함수 호출 시 if/else 구문을 사용하여 원하는 답에 다다를 때 까지 if문으로 조건을 걸어주고, 그렇지 않으면 끊임없이 자기 자신을 호출한다.

시나리오를 작성해보면, 우선 함수가 특정 숫자(2진수로 바꾸어야 할 값)를 인자로 받고, 해당 숫자를 계속 2로 나눈다.

언제까지 나누냐, 더이상 나눌 수 없을 때 까지인데, 몫이 1이거나 혹은 인자가 0이 될 때 까지이다.

1로 하면 조건을 1보다 작거나 같게 걸어야 하지만, 더 깔끔하고 알아보기 쉽게 짜려면 인자가 0이 될 때 까지로 하는게 좋다.

0이 되면 재귀함수를 그만두면 되니까.

조건에 걸리지 않으면(나눌 수 있으면) 2로 나눈 나머지를 인자로 넣는다. 2로 나눈 나머지를 코드로 구현하면 주어진 String을 파싱하여 정수를 리턴하는 parseInt을 쓰면 된다.

그리고 나머지를 특정 변수에 담아 기억해놨다가, 최종 리턴값이 될 전역변수에 +=로 이어붙이면 된다.

이 때, 변수에 할당하는 순서가 중요한데, 재귀함수로 먼저 나누고 난 뒤의 몫을 할당해야 한다. 재귀함수로 나누기 전에 할당해버리면 숫자의 순서가 바뀌게 된다.

최종적으로 구현한 코드는 아래과 같다.

function solution(n) {
  let answer = "";
  function DFS(L) {
    // inner 함수(내부 함수)
    if (L === 0) return;
    else {
      DFS(parseInt(L / 2, 10));
      const k = L % 2;
      answer += String(k);
    }
  }
  DFS(n);
  return answer;
}

테스트로 위에 직접 구했던 3, 5, 18을 대입해보면 11, 101, 10010으로 잘 나오는 것을 확인할 수 있다.

[Next.js 에러로그] Error: Package subpath './lib/parser' is not defined by "exports"

보오 — Tue, 8 Feb 2022 22:50:48 +0900

nodejs + nextjs로 앱을 실행하던 중 갑자기 로컬에서 아래와 같이 패키지 에러가 났다.

로그는 Error: Package subpath './lib/parser' is not defined by "exports".. (이하 생략)

뭘 잘못 건드렸나.. npm 모듈을 다 지우고 다시 깔아봐도 같은 에러다.

구글링을 해보니 node 버전이 16 버전 이상인 경우 위 에러가 발생할 수 있다고 한다. (원인은 모른다..)

nvm current로 현재 버전을 확인해보니 버전이 갑자기 16으로 올라가있었다.

14 버전으로 급히 다운그레이드 후 재실행하니 아주 잘~된다.

오늘의 교훈: 알수없는 에러가 뜨면 node js 버전 호환성을 확인해보자!

[코딩테스트] 2022 KAKAO BLIND RECRUITMENT 신고 결과 받기 (Javascript)

보오 — Sun, 6 Feb 2022 15:11:15 +0900

문제 보러 가기: https://programmers.co.kr/learn/courses/30/lessons/92334

코딩테스트 연습 - 신고 결과 받기

문제 설명 신입사원 무지는 게시판 불량 이용자를 신고하고 처리 결과를 메일로 발송하는 시스템을 개발하려 합니다. 무지가 개발하려는 시스템은 다음과 같습니다. 각 유저는 한 번에 한 명의

programmers.co.kr

<나의 풀이>

function solution(id_list, report, k) {
    var answer = Array.from({length: id_list.length}, ()=>0);
    var report_map = new Map(); // 신고 명단
    id_list.forEach((id)=>{
        report_map.set(id, []); // 신고 명단 초기화(각 id마다 빈 배열을 할당)
    })
    var report_count = new Map(); // 피신고자 누적 횟수
    var report_set = new Set(report);

    report_set.forEach((re)=>{
        var [reporter, reported] = re.split(" ");
        // 신고 명단 작성
        report_map.set(reporter, [...report_map.get(reporter), reported]);
        // 피신고자 누적 횟수 계산
        if(report_count.has(reported)) report_count.set(reported, report_count.get(reported) + 1);
        else report_count.set(reported, 1);
    })

    const reported_list = Array.from(report_map.values());

    report_count.forEach((value, key)=>{
        if(value >= k) {
            reported_list.forEach((list, index)=>{
                if(list.includes(key)) answer[index] = answer[index] + 1;
            })
        }
    })

    return answer;
}

<해설>

이 문제를 풀기 위해서는 누가 누구를 신고했는지에 대한 "신고 명단"과, 누가 몇번 신고 당했는지에 대한 "피신고 누적 횟수"가 필요하다.
전자는 각 유저의 신고 명단에 최종 신고 처리된 사람들이 있다면 카운트해주기 위함이고, 후자는 각 유저별로 신고 당한 횟수가 k번을 넘었는지 알기 위함이다.

<사용 알고리즘>

Javascript Map, Set 자료형
Map, Set의 개념만 알고 있다면 두 개를 활용해서 충분히 풀 수 있는 문제다.

1. answer는 id_list의 갯수만큼 각 원소가 0으로 초기화된 배열로 만들어준다. (Array.from 이용)

구하고자 하는 값이 각 유저 별 최종 신고 완료 메일을 받은 횟수를 구하는 것이기 때문이다.

2. id_list의 순서대로 report_map을 빈 배열로 초기화 해준다.

이렇게 한 이유는 추후에 map의 value만을 가지고 최종 신고 처리된 사람들이 있다면 그 누적 값을 answer 배열에서 같은 index을 찾아서 바로 넣어주기 위함이다.

3. 피신고 누적 횟수를 구하기 위해 report_count을 Map 객체로 만든다.

4. report 배열로 신고 명단을 만드는데, 그 전에 ** 중복 신고 무효처리를 위해 Set을 이용, report 원본 배열에서 중복 제거를 해준다.

ex) "muzi prodo", "muzi prodo" 는 무지가 프로도를 2번이나 신고한 것이기 때문에 1번으로 친다.

5. 중복 제거된 report_set 배열을 forEach loop로 돌려서 신고명단을 작성함과 동시에, 피신고 횟수를 누적한다. (불필요한 for문의 반복을 피하기 위함)

6. 신고 명단(report_map)의 value만을 가져다가 id_list로 정렬된 신고 명단(reported_list) 배열을 구한다. (map.prototype.values 이용)

7. 누적 횟수 배열을 forEach loop을 돌려 k번 이상 신고된 유저가 있다면, reported_list에 해당 유저가 들어있는지 구한 후(array.prototype.includes 이용) 있다면 answer의 index번째 값에 1을 더한다.

<총평>

처음에 중복 제거하는 것을 깜빡하여 테스트 문제 2번을 틀렸었다. 중복 제거 로직만 잘 끼워넣으면 풀기에는 무난하다. Map, Set의 개념을 확실히 아는 것이 중요하다. 6~7번 과정은 좀 더 직관적이고 단순하게 할 수 있을 것 같은데 더 생각해봐야겠다.

p.s. 괜찮은 방법이 있다면 댓글로 공유 부탁드립니다~