⚛️ React

React는 웹 프레임워크 시장에서 매우 인기 있는 라이브러리입니다. 2018년 React Conf에서 Hooks가 발표된 이후, 기존 클래스 컴포넌트 방식에서 함수형 컴포넌트 방식으로의 전환이 급격히 이루어졌습니다. 다양한 Hooks 중에서도 useEffect와 useLayoutEffect의 차이를 이해하지 못해 혼란스러워하는 경우가 많습니다. 이 글에서는 두 Hook의 작동 방식을 자세히 알아보고, 어떤 상황에서 각각을 사용하는 것이 좋은지 정리해보려고 합니다.<h2>사전 개념</h2>두 Hook을 이해하기 전에, React의 렌더링 과정에서 발생하는 주요 단계 두 가지를 먼저 정리해 보겠습니다.<ul><li>Render: DOM 트리를 구성하기 위해 각 요소의 스타일 속성을 계산하는 과정입니다.</li><li>Paint: 실제 화면에 렌더링된 레이아웃을 표시하고 업데이트하는 과정입니다.</li></ul><h2>useLayoutEffect</h2><img src="https://image.until.blog/morethanmin/article/1730560964253.png" data-width="100%" data-align="center" alt="1955">useLayoutEffect는 컴포넌트가 렌더링된 직후, 화면에 그려지기 전에 동기적(synchronous)으로 실행됩니다. 이 동작 특성 덕분에 DOM을 조작하는 코드가 포함되어도 화면에 반영되기 전에 즉시 실행되기 때문에, 사용자는 깜빡임이나 불필요한 레이아웃 변경을 경험하지 않습니다.이와 같은 이유로 useLayoutEffect는 화면에 즉시 반영되어야 하는 CSS 조작이나 DOM 크기 조정 등의 작업에 적합합니다. 그러나 모든 렌더링 전에 동기적으로 실행되므로 실행 시간이 길어질 경우, 첫 화면 표시가 느려질 수 있습니다.<h2>useEffect</h2><img src="https://image.until.blog/morethanmin/article/1730560955057.png" data-width="100%" data-align="center" alt="1954">useEffect는 컴포넌트가 렌더링되고 화면에 그려진 후에 실행됩니다. 이 Hook은 비동기적(asynchronous)으로 실행되기 때문에, DOM에 변화를 주더라도 사용자가 화면에서 깜빡임이나 레이아웃 변화가 감지되기 쉽습니다. 예를 들어, 데이터를 가져오는 작업이나 이벤트 핸들러 설정과 같은 비동기 작업은 useEffect 내에서 안전하게 수행할 수 있습니다.<blockquote>주의: useEffect가 DOM에 직접적으로 영향을 주는 작업을 포함할 경우, 렌더링 후 깜빡임이 발생할 수 있어 사용 경험이 떨어질 수 있습니다.</blockquote><h2>결론</h2>일반적으로는 useEffect를 기본으로 사용하는 것이 성능상 유리합니다. 예를 들어 데이터 패칭, 이벤트 핸들러 등록, 상태 초기화 및 정리와 같은 작업들은 useEffect를 사용하는 것이 적합합니다. 그러나 화면 깜빡임을 최소화해야 하는 상황이라면 useLayoutEffect를 고려해 볼 수 있습니다. 예를 들어, 특정 상태가 초기 렌더링에 따라 다르게 적용되어 화면에 순간적인 깜빡임이 발생하는 경우, useLayoutEffect가 더 나은 사용자 경험을 제공할 수 있습니다.<h2>Reference</h2><a data-type="bookmark" href="https://pubudu2013101.medium.com/what-is-the-real-difference-between-react-useeffect-and-uselayouteffect-51723096dc19" target="_blank"><div class="content"><div><div class="title">What is the real difference between React useEffect and useLayoutEffect?</div><div class="description">If you are a React.js developer, you will know that these are widely used React.js hooks when doing frontend development. Most of us…</div></div><div class="href">https://pubudu2013101.medium.com/what-is-the-real-difference-between-react-useeffect-and-uselayouteffect-51723096dc19</div></div><img src="https://miro.medium.com/v2/resize:fit:1200/1*ZtfwJC3TDzDVvonp5S5asA.jpeg"></a>

React는 웹 프레임워크 시장에서 매우 인기 있는 라이브러리입니다. 2018년 React Conf에서 Hooks가 발표된 이후, 기존 클래스 컴포넌트 방식에서 함수형 컴포넌트 방식으로의 전환이 급격히 이루어졌습니다. 다양한 Hooks 중에서도 useEffect와 useLayoutEffect의 차이를 이해하지 못해 혼란스러워하는 경우가 많습니다. 이 글에서

React에서 useEffect와 useLayoutEffect 차이점

Apache Kafka

서버 컴포넌트와 TanStack Query를 같이 적용하게된 스토리를 적어보고자 한다.<h1>목표</h1>우선 내가 구현하고자 하는 내용의 조건은 다음과 같다.<ol start="NaN"><li>서버 컴포넌트에서 n개의 데이터를 불러와 SEO를 위해 페이지를 미리 채워 놓을것.</li><li>무한 스크롤을 이용해 데이터를 더 로드할 수 있을 것</li><li>새로고침 전까지 클라이언트에서 계속 캐싱하고 있을 것</li><li>다른 카테고리 선택시 클라이언트에서 refetching 하여 데이터를 보여줄 것</li></ol>그리고 걸린 제약 조건은 다음과 같다.<ol start="NaN"><li>데이터 fetching은 third-party 라이브러리를 사용하며, 이는 서버 사이드에서만 동작하며 클라이언트에서 호출할 수 없다.</li></ol><h1>구현 과정</h1><h2>1. 서버 컴포넌트에서 데이터 Prefetching</h2><a target="_blank" rel="noopener noreferrer nofollow" href="https://tanstack.com/query/latest/docs/framework/react/guides/advanced-ssr#nesting-server-components">TanStack Query 공식 문서</a>에서 가이드해주는 방법을 참고하여, 부모가 되는 서버 컴포넌트를 작성했다.<code spellcheck="false">page.tsx</code><pre spellcheck="false"><code>export default async function PostPage() {
 &nbsp;const queryClient = new QueryClient()
​
 // prefetch할 query를 지정한다.
 &nbsp;await queryClient.prefetchQuery({
 &nbsp; &nbsp;queryKey: ['posts'],
 &nbsp; &nbsp;queryFn: () =&gt; PostService.getPostsByTag("initial"),
 })
​
 &nbsp;return (
 &nbsp; &nbsp;&lt;HydrationBoundary state={dehydrate(queryClient)}&gt;
 &nbsp; &nbsp; &nbsp;&lt;Posts /&gt;
 &nbsp; &nbsp;&lt;/HydrationBoundary&gt;
 )
}</code></pre>위 코드에서 <code spellcheck="false">&lt;HydrationBoundary state={dehydrate(queryClient)}&gt;</code> 이 부분은 서버에서 가져온 데이터를 클라이언트 컴포넌트에서 사용하기 위해 직렬화를 해주는 과정이다. 직렬화가 왜 필요한지는 여기서 설명하지 않겠다.<h2>2. 무한 스크롤을 위한 클라이언트 컴포넌트 작성</h2>이제 무한 스크롤을 위해 <code spellcheck="false">useInfiniteQuery</code>를 사용할 클라이언트 컴포넌트 부분을 살펴보자. prefetch한 데이터를 가져오기 위해서는 <code spellcheck="false">usePrefetchInfiniteQuery</code> 훅을 사용해야 한다.<code spellcheck="false">Post.tsx</code><pre spellcheck="false"><code>export default function Posts() {
 &nbsp;const { data, fetchNextPage, isFetchingNextPage } = await queryClient.prefetchInfiniteQuery({
 &nbsp; &nbsp;queryKey: ["posts"],
 &nbsp; &nbsp;queryFn: () =&gt; PostService.getPostsByTag("initial"),
 &nbsp; &nbsp;initialPageParam: undefined,
 });
 &nbsp;
 &nbsp;// ...생략
​
 &nbsp;return (
 &nbsp; &nbsp;&lt;div&gt;
 &nbsp; {data....}
 &nbsp; &nbsp;&lt;/div&gt;
 )
}</code></pre><h3>첫 번째 문제: 서버 사이드 전용 함수 호출</h3>여기서 첫 번째 문제가 발생했다. <code spellcheck="false">queryFn</code>에 들어가는 비동기 함수는 서버에서 실행되는 함수인데, 클라이언트 사이드에서 호출하니 에러가 발생했다.이를 해결하기 위해 Next.js의 server action을 사용했다.<pre spellcheck="false"><code class="language-typescript">const getPostsAction = async (tag: string, startCursor?: string) =&gt; {
 &nbsp;"use server";
 &nbsp;return await BlogService.getPostsByTag(tag, startCursor);
};</code></pre>위와 같이 감싸 준다음, <code spellcheck="false">getPostsAction</code>를 클라이언트 컴포넌트에 <code spellcheck="false">props</code>로 내려주거나, 파일을 따로 분리해서 export한 후, 클라이언트에서 import해서 사용해도 된다. 나는 후자의 방법을 선택했다.<pre spellcheck="false"><code class="language-typescript">const { data, fetchNextPage, isFetchingNextPage } = useInfiniteQuery({
 &nbsp;queryKey: ["posts"],
 &nbsp;queryFn: ({ pageParam }: { pageParam: string | undefined }) =&gt;
 &nbsp; &nbsp;getPostsAction({ startCursor: pageParam, tag }),
 &nbsp;initialPageParam: undefined,
 &nbsp;getNextPageParam: (lastPage, pages) =&gt; lastPage.next_cursor || undefined,
 &nbsp;staleTime: Infinity,
 &nbsp;gcTime: Infinity,
});</code></pre>지금까지의 과정을 통해 초기 데이터도 서버에서 만들어져 초기 HTML에 포함되어 나왔고, 무한 스크롤을 통한 클라이언트에서의 데이터 페칭도 정상적으로 진행 되었다.<h3>두 번째 문제: 캐싱 문제</h3>근데 캐싱이 안된다..!! 다른 페이지로 이동했다 다시 돌아오면 클라이언트 사이드에서 스크롤을 통해 가져온 데이터는 사라져 있었다. 아무리 <code spellcheck="false">staleTime</code>과 <code spellcheck="false">gcTime</code>의 옵션을 변경해도 마찬가지였다.원인은 다음과 같았다. 서버 컴포넌트(<code spellcheck="false">page.tsx</code>)가 실행 될 때마다 <code spellcheck="false">queryClient</code>를 새로 생성하기 때문에 캐시가 남아 있지 않게되고, <code spellcheck="false">staleTime</code>등의 옵션은 별 의미가 없어진다.그럼 서버에서 생성한 <code spellcheck="false">queryClient</code>를 밖으로 빼면 되지 않나? 라고 생각할 수 있지만, 서버에서 만들어지다 보니 다른 사용자들끼리 공유가될 수 있는 문제가 있다.<blockquote>참조: <a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/TanStack/query/discussions/5268">https://github.com/TanStack/query/discussions/5268</a></blockquote><h3>해결</h3>따라서 나는 서버에서 <code spellcheck="false">queryClient.prefetchQuery</code> 쓰는 것을 포기하고 다음과 같은 방법을 적용 했다.<ol><li>우선 초기 데이터를 fetching한 뒤, 데이터를 컴포넌트에 <code spellcheck="false">props</code>로 내려줬다.</li></ol><pre spellcheck="false"><code class="language-typescript">async function PostPage() {
 &nbsp;const initialPosts = await getPostsAction({ tag: "all" });
​
 &nbsp;return (
 &nbsp; &nbsp;&lt;section&gt;
 &nbsp; &nbsp; &nbsp;&lt;BlogPostList
 &nbsp; &nbsp; &nbsp; &nbsp;initialPosts={initialPosts}
 &nbsp; &nbsp; &nbsp;/&gt;
 &nbsp; &nbsp;&lt;/section&gt;
 );
}</code></pre><ol start="2"><li>전달 받은 데이터를 <code spellcheck="false">placeholderData</code>에 넣어 사용했다.</li></ol><pre spellcheck="false"><code>const getPlaceholderData = (): InfiniteData&lt;
 &nbsp;BlogPostsResultType,
 &nbsp;string | undefined
&gt; =&gt; {
 &nbsp;const cache = queryClient.getQueryData&lt;
 &nbsp; &nbsp;InfiniteData&lt;BlogPostsResultType, string | undefined&gt;
 &nbsp;&gt;(["posts", "all"]);
 &nbsp;return (
 &nbsp; &nbsp;cache || {
 &nbsp; &nbsp; &nbsp;pages: [initialPosts],
 &nbsp; &nbsp; &nbsp;pageParams: [],
 &nbsp; }
 );
};
​
const { data, fetchNextPage, isFetching, isFetchingNextPage } =
 useInfiniteQuery({
 &nbsp;queryKey: ["posts", selectedTag],
 &nbsp;queryFn: ({ pageParam }: { pageParam: string | undefined }) =&gt;
 &nbsp; &nbsp;getPostsAction({ startCursor: pageParam, tag: selectedTag }),
 &nbsp;initialPageParam: undefined,
 &nbsp;getNextPageParam: lastPage =&gt; lastPage?.next_cursor,
 &nbsp;placeholderData: getPlaceholderData(),
 &nbsp;refetchOnMount: false,
 &nbsp;staleTime: Infinity,
 &nbsp;gcTime: Infinity,
 });</code></pre><code spellcheck="false">placeholderData</code>가 아닌 <code spellcheck="false">initialData</code>에 넣을 수도 있지만, 내 조건에서는 태그를 선택시 태그에 맞는 데이터를 보여줘야했고, 데이터 페칭시 이전 데이터를 활용하여 화면에 데이터가 사라지는 것을 막기 위해 <code spellcheck="false">placeholderData</code>를 사용했다.<blockquote>참조: <a target="_blank" rel="noopener noreferrer nofollow" href="https://tkdodo.eu/blog/placeholder-and-initial-data-in-react-query">https://tkdodo.eu/blog/placeholder-and-initial-data-in-react-query</a></blockquote><h1>결론</h1>SSR, RSC 등과 클라이언트 데이터 페칭 라이브러리인 TanStack Query를 적절하게 섞어서 사용할 수 있지만, 아직 완벽하게 사용할 수는 없는 느낌을 받았다. 서버측에서의 렌더링이 유행처럼 되가고 있으니 조만간 TanStack Query에서도 지원이 제대로 되었으면 좋겠다.

서버 컴포넌트와 TanStack Query를 활용해 특정 기능을 구현한 과정을 공유하고자 합니다.

서버 컴포넌트와 TanStack Query 사용기

<h3>0. 16.8버전 이전의 함수 컴포넌트</h3>0.14 버전에서 소개된 함수 컴포넌트는 staless functional component, 이른바 무상태 함수 컴포넌트였다. 별도의 상태 없이 단순히 어떠한 요소를 정적으로 렌더링하는 것이 목적이었다.즉, 함수 컴포넌트는 클래스 컴포넌트에서 별다른 생명주기 메서드나 상태가 필요없이 render만 하는 경우에만 제한적으로 사용됐다. 함수 컴포넌트가 각광받기 시장한 것은 16.8버전에서 hook이 등장한 이우였다.함수 컴포넌트에서 hook이 등장한 이후 함수 컴포넌트에서 상태나 생명주기 메서드 비슷한 작업을 흉내낼 수 있게되자 상대적으로 보일러플레이트가 복잡한 클래스 컴포넌트보다 함수 컴포넌트를 많이 쓰기 시작했다.<h1>1. 클래스 컴포넌트</h1>기본적으로 클래스 컴포넌트를 만들려면 클래스를 선언하고, extends로 만들고 싶은 컴포넌트를 extends해야한다.<ul class="tight" data-tight="true"><li>React.Component</li><li>React.PureComponent</li></ul><pre spellcheck="false"><code class="language-jsx">// Component 제네릭에 props, state를 순서로 넣어준다.
class SampleComponent extends React.Component&lt;SampleProps, SampleState&gt;
</code></pre><ul><li>constructor(): 컴포넌트가 초기화되는 시점에 호출된다. 컴포넌트의 state를 초기화해주는 역할을 한다.</li><li>super(): 컴포넌트를 만들면서 상속받은 상위 컴포넌트에 접근할 수 있게 도와준다.</li><li>props: 함수 인자에 넣는 것과 비슷하게 컴포넌트에 특정 속성을 전달하는 용도로 쓰인다.</li><li>state: 클래스 컴포넌트 내부에서 관리하는 값을 의미한다. 값은 항상 객체여야만 하고, 해당 값에 변화가 있을 때 리렌더링이 발생한다.</li><li>method: 렌더링 함수 내부에서 사용되는 함수이며, 보통 DOM에서 발생하는 이벤트와 함꼐 사용된다.<ul><li>constructor에서 this를 바인드 하는 방법: 생성된 함수에 bind를 활용해 강제로 this를 바인딩해야 한다. (일반적인 함수로 메서드를 만든다면 this가 undefined로 나온다. 생성자가 아닌 일반 함수로 호출하게 되면 this 전역 객체가 바인딩 되기 때문이다.<pre spellcheck="false"><code class="language-jsx">this.handleClick = this.handleClick.bind(this)
</code></pre></li><li>화살표 함수를 쓰는 방법: 실행 시점이 아닌 작성 시점에 this가 상위 스코프로 결정되는 화살표 함수를 사용한다면 굳이 바인딩을 하지 않아도 된다.<pre spellcheck="false"><code class="language-jsx">const sampleFunction = () =&gt; {}
</code></pre></li><li>렌더링 함수 내부에서 함수를 새롭게 만들어 전달하는 방법: 메서드 내부에서 새롭게 함수를 만들어서 전달하는 방법이다.<pre spellcheck="false"><code class="language-jsx">&lt;button onClick={()=&gt; this.handleClick()}&gt;증가&lt;/button&gt;
</code></pre>그러나 이 방법을 사용하게 되면 매번 렌더링이 일어날 때마다 새로운 함수를 생성해서 할당하게 되므로 최적화를 수행하기 매우 어려워진다.</li></ul></li></ul><h2>클래스 컴포넌트의 생명주기 메서드</h2>클래스 컴포넌트를 사용하면서 가장 많이 언급되는 것이 바로 생명주기이다. 클래스 컴포넌트는 많은 코드가 생명주기 메서드에 의존하고 있다.생명주기 메서드가 샐행되는 시점은 크게 3가지로 나눌 수 있다.<ul class="tight" data-tight="true"><li>마운트(mount): 컴포넌트가 마운트(생성)되는 시점<ul class="tight" data-tight="true"><li>가상 돔에 붙는 순간</li></ul></li><li>업데이트(update): 이미 생성된 컴포넌트 내용이 변경(업데이트)되는 시점<ul class="tight" data-tight="true"><li>상태나 UI가 변경이 될 때</li></ul></li><li>언마운트(unmount): 컴포넌트가 더이상 존재하지 않는 시점<ul class="tight" data-tight="true"><li>컴포넌트가 사라질 때, DOM 트리가 빠질 때</li></ul></li></ul><h3>render()</h3>리액트 클래스 컴포넌ㅌ의 유일한 필수 값으로 항상 쓰인다.목적: 컴포넌트 UI를 렌더링 하기 위해서 쓰인다.실행 시점: 마운트와 업데이트 과정에서 일어난다.💡 한가지 주의해야 할 점은 render() 함수는 항상 순수해야 하며 부수 효과가 없어야 한다.<blockquote>부수 효과가 있으면 return 값이 변경될 수 있기 때문에 화면에 나오는 부분을 예측할 수 있도록 순수해야 한다.</blockquote>같은 입력값(props 또는 state)이 들어가면 항상 같은 결과물을 반환해야 한다는 뜻이다. 따라서 render() 내부에서 state를 직접 업데이트하는 this.setState를 호출해서는 안된다.state를 변경하는 일은 클래스 컴포넌트의 메서드나 다른 생명주기 메서드 내부에서 발생해야 한다. 그러므로 이 함수는 항상 최대한 간결하고, 깔끔하게 작성하는 것이 좋다.<h3>componentDidMount()</h3>클래스 컴포넌트가 마운트되고 준비가 됐다면 그 다음으로 호출되는 메서드가 바로 componentDidMount()이다.목적: render와 다르게 내부에서, state 값을 변경할 수 있기 때문에 UI를 업데이트 하기 위해 쓰인다.실행 시점: 컴포넌트가 마운드되고 준비되는 즉시 실행된다.💡 componentDidMount는 만능이 아니며 성능 문제를 일으킬 수 있음에 주의하자.일반적으로 state를 다루는 것은 생성자(constructor)에서 하는 것이 좋다. componentDidMount에서 this.setState를 허용하는 것은 다음과 같다.<ol class="tight" data-tight="true"><li>생성자 함수에서 할 수 없는 것</li><li>API 호출 후 업데이트</li><li>DOM에 의존적인 작업</li></ol><h3>componentDidUpdate()</h3>목적: 일반적으로 state나 props의 변화에 따라 DOM을 업데이트하는 등에 쓰인다.실행 시점: 컴포넌트 업데이트가 일어난 이후에 바로 실행된다.💡 그러나 적절한 조건문으로 감싸지 않는다면 this.setState가 계속해서 호출되는 일이 발생할 수 있다.<h3>componentWillUnmount()</h3>목적: 메모리 누수나 불필요한 작동을 막기 위한 클린업 함수를 호출하기 위한 최적의 메소드다.실행 시점: 컴포넌트가 언마운트되거나 더 이상 사용되지 않기 직전에 호출된다.이 메서드 내에서는 this.setState를 호출할 수 없다, 다음과 같은 상황에서 주로 사용한다.<ol class="tight" data-tight="true"><li>이벤트 제거 (window.removeEventListener)</li><li>API 호출을 취소</li><li>setInterval, setTimeout으로 생성된 타이머 제거</li></ol><h3>shouldComponentUpdate()</h3>목적: state나 props 변경으로 리액트 컴포넌트가 다시 리렌더링되는 것을 막고 싶을 때 사용한다.실행 시점: this.setState가 호출되면 리렌더링을 일으킨다. 그러나 해당 생명주기 메서드는 컴포넌트에 영향을 받지 않는 변화에 대해 정의할 수 있다.💡 일반적으로 state 변화에 따라 컴포넌트가 리렌더링 되는 것은 굉장히 자연스러운 일이므로, 해당 메서드를 사용하는 것은 성능 최적화 상황에서만 고려해야 한다.앞서 클래스 컴포넌트에는 두가지 유형, 즉 Component와 PureComponent가 있다. 이 둘의 차이점이 바로 해당 생명주기를 다루는데 있다.Component의 경우 버튼을 누르는 대로 즉 state가 업데이트되는 대로 렌더링이 일어나지만, PureComponent는 state의 값이 업데이트되지 않아서 렌더링이 일어나지 않았다. PureComponent는 state 값에 대해 얕은 비교를 수행해 결과가 다를 때만 렌더링을 수행한다.PureComponent는 먼저 얕은 비교만 수행하기 때문에, state가 객체와 같이 복잡한 구조의 데이터 변경은 갑지하지 못하기 때문에 개발자가 생각한대로 제대로 작동하지 않는다. 또한 애플리케이션에서 대다수의 컴포넌트가 PureComponent로 구성돼있다면 오히려 성능에 역효과를 미칠 수 있다.<blockquote>PureComponent의 경우 객체의 참조값이 바뀌어야 업데이트 된다, hook의 경우는 객체의 참조값을 갈아치운다.</blockquote><h3>지금까지 언급한 생명주기 메서드 정리</h3>렌더단계: virtualDOM에서 그려지는 과정커밋단계: 실제 브라우저에 반영하는 단계<h3>static getDerivedStateFromProps()</h3>이제는 사라진 componentWillreceiveProps를 대체할 수 있는 메서드다.실행 시점: render()를 호출하기 직전에 호출된다.static으로 되어 있어 this에 접근할 수 없다. 여기서 반환하는 객체는 해당 객체의 내용이 모든 state로 들어가게 된다.💡 명심해야 할 점은 해당 메서드도 마찬가지로 모든 redner() 실행 시에 호출된다는 점이다.<h3>getSnapShotBeforeUpdate()</h3>최근에 도입된 메서드중 하나로, componentWillUpdate()를 대체할 수 있는 메서드다.실행 시점: DOM이 업데이트되기 직전에 호출된다.다음과 같은 상황에서 주로 사용한다.<ol class="tight" data-tight="true"><li>렌더링되기 전에 윈도우 크기를 조절</li><li>스크롤 위치 조정</li></ol><h3>⭐&nbsp;getDerivedStateFromError()</h3>목적: 자식 컴포넌트에서 에러가 발생했을 때 렌더링 하기 위해 사용한다.실행 시점: 자식 컴포넌트에서 에러가 발생했을 때 호출된다.getDerivedStateFromError(error)를 인수로 받는다. 여기서 error는 하위 컴포넌트에서 발생한 에러를 말한다.💡 getDerivedStateFromError는 반드시 state 값을 반환해야 하며, 부수효과를 발생해서는 안된다.그 이유는 getDerivedStateFromError의 실행시점 때문이다. 자식 컴포넌트에서 에러가 발생했을 때 어떻게 렌더링할 지 결정하는 용도로 제공되기 때문에 반드시 미리 정의해둔 state 값을 반환해야 한다.또한 여기서 말하는 부수효과란 에러에 따른 상태 state를 반환하는 것 외의 모든 작업을 의미한다. (ex. console.error)<h3>⭐&nbsp;componentDidCatch()</h3>해당 3가지 메서드 getSnapShotBeforeUpdate, getDerivedStateFromError, componentDidCatch는 아직 리액트 훅으로 구현돼 있지 않기 때문에 이 3가지 메서드가 필요하다면 반드기 플래스 컴포넌트를 사용해야 한다.목적: 자식 컴포넌트에서 에러가 발생했을 때 렌더링 하기 위해 사용한다.실행 시점: 자식 컴포넌트에서 에러가 발생했을 때 호출된다, getDerivedStateFromError에서 에러를 잡고 state를 결정한 이후에 실행된다.componentDidCatch(error, 어떤 컴포넌트가 에러를 발생시켰는지 해당 컴포넌트의 정보를 가지고 있는 info)를 인자로 받는다.💡 componentDidCatch는 getDerivedStateFromError에서 하지 못했던 부수 효과를 수행할 수 있다.getDerivedStateFromError는 렌더 단계에서 실행되지만, componentDidCatch는 커밋단계에서 실행디기 때문이다.일반적으로 앞의 두 메서드는 ErrorBoundary, 즉 에러 경계 컴포넌트를 만들기위해 많이 사용된다. 그러나 모든 에러를 잡아낼 수 있는 것은 아니다. ErrorBoundary 외부에 있는 에러는 잡을 수 없다.이를 반대로 생각하여 ErrorBoundary를 여러 개 선언해서 컴포넌트 별로 에러 처리를 다르게 적용할 수 있다. 이렇게 하면 에러가 발생한 컴포넌트 트리 영역만 별도로 처리해서 애플리케이션 전체에 에러가 전파되어 표시되는 것을 방지할 수 있다.<blockquote>해당 메서드는 주로 에러 로깅할 때 사용한다. (GA, Centry) → 특정 컴포넌트에서 어떠한 에러가 발생했는지 알 수 있기 때문</blockquote><h2>클래스 컴포넌트의 한계</h2><ul class="tight" data-tight="true"><li>데이터 흐름을 추적하기 어렵다.<ul class="tight" data-tight="true"><li>데이터를 바꿀 수 있는 위치가 너무 많다.(DidUpdate, DidMount…)</li></ul></li><li>애플리케이션 내부 로직의 재사용이 어렵다.<ul class="tight" data-tight="true"><li>로직을 재사용하려면 HOC를 통해 해결이 가능하지만, 고차 컴포넌트를 많이 감싸게 되면 래퍼 지옥에 빠져들 위험성이 커진다.</li></ul></li><li>기능이 많아질수록 컴포넌트의 크기가 커진다.</li><li>클래스는 함수에 비해 상대적으로 어렵다.</li><li>코드 크기를 최적화하기 어렵다.<ul class="tight" data-tight="true"><li>번들 크기를 줄이는 게 어렵다.</li></ul></li><li>핫 리로딩을 하는 데 상대적으로 불리하다.</li></ul><blockquote>트리 쉐이킹 → 나무를 흔든다 → 나무에 걸려있는게 떨어진다</blockquote>중복선언된 로직을 호이스팅 하여 미사용된 함수/변수를 지운다. (메모리 낭비이기 때문)변수명을 바꿔준다 → 변수 명을 길게 한 것을 최소화하기 위해<blockquote>핫 리로딩 → 변경사항이 일어나면, 앱을 다시 시작하지 않고서도 해당 변경된 코드만 업데이트하여 변경 사항을 빠르게 적용하는 기법</blockquote><h2>함수 컴포넌트</h2><ol class="tight" data-tight="true"><li>render 내부에 필요한 함수를 선언할 때 this 바인딩을 조심할 필요가 없음</li><li>state는 객체각 아닌 각각의 원시값으로 관리되어 훨씬 사용하기 편하다.</li><li>렌더링하는 코드인 return에서 굳이 this를 사용하지 않아도 props와 state에 접근할 수 있게 됐다.</li></ol>

0. 16.8버전 이전의 함수 컴포넌트0.14 버전에서 소개된 함수 컴포넌트는 staless functional component, 이른바 무상태 함수 컴포넌트였다. 별도의 상태 없이 단순히 어떠한 요소를 정적으로 렌더링하는 것이 목적이었다.즉, 함수 컴포넌트는 클래스 컴포넌트에서 별다른 생명주기 메서드나 상태가 필요없이 render만 하는 경우에만 제한적

2-3. 클래스 컴포넌트와 함수 컴포넌트

병렬처리는 다른 방법도 있지만 일단 이 포스트에서는 Promise.all과 Worker_threads의 차이를 한번 알아보자잇일단 이 두개를 무슨 목적으로 쓰는걸까?<ol><li>성능 : 여러개의 작업을 동시에 처리해서, 실행 시간을 단축시킬래!</li><li>효율 : 여러개의 코어를 가진 프로세서를 다 활용하고싶어!</li><li>확장성 : 요청이 많아도 잘 대응해보고싶어!</li></ol>뭐 다른 이유도 많겠지만 당장 떠오르는건 이정도인 것 같네잉구현 코드부터 볼까! 다들 nest cli는 글로벌로 설치 되어있잖어~<pre spellcheck="false"><code>nest new nestjs-concurrency-test --strict</code></pre>main.ts<pre spellcheck="false"><code>import { NestFactory } from '@nestjs/core';

import { AppModule } from './app.module';

async function bootstrap() {
 const app = await NestFactory.create(AppModule);
 await app.listen(3000);
}
bootstrap();

//여긴 뭐 없다잉 </code></pre>app.controller.ts<pre spellcheck="false"><code>import { Controller, Get, Query } from '@nestjs/common';

import { AppService } from './app.service';

@Controller()
export class AppController {
 constructor(private readonly appService: AppService) {}

 @Get('promise-all')
 async testPromiseAll(@Query('i') iterations: string): Promise&lt;string&gt; {
 const start = Date.now();
 const result = await this.appService.testPromiseAll(parseInt(iterations) || 10000000);
 const end = Date.now();

 return `Promise.all: ${end - start} milliseconds, result: ${result}`;
 }

 @Get('worker-threads')
 async testWorkerThreads(@Query('i') iterations: string): Promise&lt;string&gt; {
 const start = Date.now();
 const result = await this.appService.testWorkerThreads(parseInt(iterations) || 10000000);
 const end = Date.now();

 return `Worker Threads: ${end - start} milliseconds, result: ${result}`;
 }
}</code></pre>컨트롤러에 엔드포인트 두개를 맛있게 만들었엉 NestJS는 다들 아는거 맞지? 모르면 물어봐잉쿼리 파라미터 i를 받아서 몇번 반복할건지 처리할거임 ㅋㅋ 파라미터 없으면 천만번 ㅅㄱ링리턴값은 시간이 얼마나 걸렸는지 보여줄거임. result는 사실 별로 안중요해. 어차피 파라미터가 같다면 둘은 같은 값을 뱉을것실제 로직은 당연히 서비스코드에 있으니까 별거없지? (사실 서비스코드도 별거없음)app.service.ts<pre spellcheck="false"><code>import { Injectable } from '@nestjs/common';
import path from 'path';
import { Worker } from 'worker_threads';

@Injectable()
export class AppService {
 computation(iterations: number): number {
 return Array.from({ length: iterations }, (_, i) =&gt; Math.sqrt(i)).reduce(
 (acc: number, cur: number) =&gt; acc + cur,
 0,
 );
 }

 async testPromiseAll(iterations: number): Promise&lt;number&gt; {
 const tasks = Array(4)
 .fill(null)
 .map(() =&gt; this.computation(iterations / 4));

 const results = await Promise.all(tasks);

 return results.reduce((acc: number, cur: number) =&gt; acc + cur, 0);
 }

 async testWorkerThreads(iterations: number): Promise&lt;number&gt; {
 const workerPath = path.resolve(__dirname, 'workers/worker.js');
 const workers = Array(4)
 .fill(null)
 .map(
 () =&gt;
 new Promise&lt;number&gt;((resolve, reject) =&gt; {
 const worker = new Worker(workerPath, { workerData: { iterations: iterations / 4 } });

 worker.on('message', resolve);
 worker.on('error', reject);
 }),
 );

 const results = await Promise.all(workers);

 return results.reduce((acc: number, cur: number) =&gt; acc + cur, 0);
 }
}
</code></pre>일단 Promise.all, worker_threads 에서 처리할 computation 함수를 맛있게 만들었당(처음에 for문으로 했다가 멋있어 보이려고 reduce 썼잔어 ㅋ)이 함수는 iterations 만큼 배열을 만들고, 제곱근을 계산해서 그 합을 반환할거야이 코드도 별거없어. 두 함수 다 태스크를 4개로 나눠서 처리한다다만 두 함수는 각각 다른 방식으로 동시성을 구현하는데, testPromiseAll 에서는 비동기 특성을 활용해서 동시성을 구현하지만 결국엔 '단일 스레드'에서 실행된다.testWorkerThreads 에서는 실제로 다중 스레드를 사용해서 병렬적으로 처리한다잉결과를 한번볼까?파라미터 i 를 1000000 (백만)으로 주었을때<img src="https://image.until.blog/rolldeep-stepmerrily/article/1724119606249" alt="until-1252"><img src="https://image.until.blog/rolldeep-stepmerrily/article/1724119620802" alt="until-1253">백만번으로는 사실 별 차이 없다 ㅇㅅㅇ 오히려 promise-all로 구현했을때 아주 조금 더 빨리, 혹은 비슷한 결과가 나옴근데 i를 10000000 (천만)으로 주었을땐<img src="https://image.until.blog/rolldeep-stepmerrily/article/1724119686200" alt="until-1254"><img src="https://image.until.blog/rolldeep-stepmerrily/article/1724119693533" alt="until-1255">2배 이상 차이가 난단말이지, 여러번 시도해도 worker-threads가 2배 이상 빠르다!그럼 이 두 방식 각각의 장단점이 뭔지 알아볼까잇<ol><li>Promise.all 의 장단점<ul><li>장점<ul><li>매우 구현이 간편하다!</li><li>메모리를 덜 씀</li><li>Node.js 환경 말고도 브라우저에서도 쓸수 있겠지?</li></ul></li><li>단점<ul><li>CPU단에서 실제 병렬 처리는 하는것은 아님</li><li>하나의 스레드에서 실행되기 때문에 여러 작업중에 하나가 블로킹되면 전체 성능이 떡락할지도?</li></ul></li></ul></li><li>Worker Threads의 장단점<ul><li>장점<ul><li>실제로 다중 코어를 활용함</li><li>각각의 Worker가 독립되어서 안정성이 높음</li><li>무거운 연산을 할땐 엄청 빠르다!</li></ul></li><li>단점<ul><li>구현이 좀 상대적으로 귀찮음(사실 쓰기 좀 꺼려지는 가장 큰 원인)</li><li>메모리를 많이 씀</li><li>오버헤드가 발생할지도..?</li><li>Node에서 지원하기 때문에 Node가 아니면 못써잉</li></ul></li></ul></li></ol>그럼 또 이제 어디에 쓰면 좋을지 알아봐야겠지<ol><li>Promise.all 활용처<ul><li>비동기 API를 한번에 호출 할 때</li><li>간단한 병렬 처리만을 필요로 할 때</li><li>I/O 작업을 동시에 처리할 때 </li></ul></li><li>Worker Threads 활용처<ul><li>엄청 거대한 데이터 처리</li><li>엄청 복잡한 연산</li><li>CPU가 두뇌 풀가동 해야할 때(이미지나 동영상 등 ?)</li><li>백그라운드에서 오래오래 실행되어야할 때</li></ul></li></ol><h1>결론</h1>알잘딱으로 잘 선택해야한다.Promise.all 이 편하긴해.. 자매품 Promise.race도 애용하자

병렬처리는 다른 방법도 있지만 일단 이 포스트에서는 Promise.all과 Worker_threads의 차이를 한번 알아보자잇일단 이 두개를 무슨 목적으로 쓰는걸까?성능 : 여러개의 작업을 동시에 처리해서, 실행 시간을 단축시킬래!효율 : 여러개의 코어를 가진 프로세서를 다 활용하고싶어!확장성 : 요청이 많아도 잘 대응해보고싶어!뭐 다른 이유도 많겠지만 당

[NestJS] Promise.all 과 Worker_threads의 차이

Spring

<h2>1. 프로젝트 생성</h2> "스프링 부트 스타터 사이트를 이용해 프로젝트 생성" <a target="_blank" rel="noopener noreferrer nofollow" href="https://start.spring.io">https://start.spring.io</a> <ul><li>프로젝트 선택<ul><li>Project: Gradle Project</li><li>Spring Boot: 3.2.5</li><li>Packaging: Jar</li><li>Java: 17</li></ul></li><li>Project Metadata<ul><li>Group: demo</li><li>Artifact: demo</li></ul></li><li>Dependencies: Spring Web, Thymeleaf</li></ul><blockquote>선택을 마친 후 Generate 를 클릭하면 zip파일 형태로 다운받아진다. 프로젝트의 실체를 보기 위해서는 압축을 해제하고 원하는 폴더에 넣은 후 IntelliJ에서 Import를 해야 한다. Import 방법: <code spellcheck="false">Open or Import</code> 클릭 → 다운받은 프로젝트 폴더로 찾아가 <code spellcheck="false">build.gradle</code> 파일 열기</blockquote>"Gradle 전체 설정" <code spellcheck="false">build.gradle</code><pre spellcheck="false"><code class="language-auto">plugins {
	id 'java'
	id 'org.springframework.boot' version '3.2.5'
	id 'io.spring.dependency-management' version '1.1.4'
}

group = 'com.example'
version = '0.0.1-SNAPSHOT'

java {
	sourceCompatibility = '17'
}

repositories {
	mavenCentral()
}

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
	implementation 'org.springframework.boot:spring-boot-starter-web'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
	testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
	compileOnly 'org.springframework.boot:spring-boot-devtools'
}

tasks.named('test') {
	useJUnitPlatform()
}</code></pre><ul><li>동작 확인<ul><li>기본 메인 클래스 실행</li><li>스프링 부트 메인 실행 후 에러페이지로 간단하게 동작 확인(<code spellcheck="false">http://localhost:8080</code> ) </li></ul></li></ul><h3>IntelliJ Gradle 대신에 자바 직접 실행</h3>최근 IntelliJ 버전은 Gradle을 통해서 실행 하는 것이 기본 설정이다. 이렇게 하면 실행속도가 느리다. 다음과 같이 변경하면 자바로 바로 실행해서 실행속도가 더 빠르다.<ul><li>Preferences → Build, Execution, Deployment → Build Tools → Gradle<ul><li>Build and run using: Gradle → IntelliJ IDEA</li><li>Run tests using: Gradle → IntelliJ IDEA</li></ul></li></ul><h2>2. 주요 라이브러리 살펴보기</h2><blockquote>Gradle은 의존관계가 있는 라이브러리를 함께 다운로드 한다. 때문에 <code spellcheck="false">Spring Web</code>이랑 <code spellcheck="false">Thymeleaf</code> 겨우 2개 추가했을 뿐인데 정말 많은 라이브러리들이 꽉꽉 들어차있는 것을 볼 수 있다. 이처럼 물밑에서는 수많은 라이브러리들은 서로가 서로를 의존하고 있는데, <code spellcheck="false">Gradle</code>은 개발자가 그 모든 라이브러리들을 일일이 추가할 필요없이 '사용하겠다'라고 선언만 해주면 알아서 필요한 것들을 가져와 설치해준다.</blockquote>"스프링 부트 라이브러리"<ul><li>spring-boot-starter-web<ul><li>spring-boot-starter-tomcat: 톰캣 (웹서버)</li><li>spring-webmvc: 스프링 웹 MVC</li></ul></li><li>spring-boot-starter-thymeleaf: 타임리프 템플릿 엔진(View)</li><li>spring-boot-starter(공통): 스프링 부트 + 스프링 코어 + 로깅<ul><li>spring-boot<ul><li>spring-core</li></ul></li><li>spring-boot-starter-logging<ul><li>logback, slf4j</li></ul></li></ul></li></ul>“테스트 라이브러리”<ul><li>spring-boot-starter-test<ul><li>junit: 테스트 프레임워크</li><li>mockito: 목 라이브러리</li><li>assertj: 테스트 코드를 좀 더 편하게 작성하게 도와주는 라이브러리</li><li>spring-test: 스프링 통합 테스트 지원</li></ul></li></ul><h2>3. View 환경설정</h2><h3>Welcome Page 만들기</h3><code spellcheck="false">resources/static/index.html</code><pre spellcheck="false"><code>&lt;!DOCTYPE html&gt;
&lt;html lang="en"&gt;
&lt;head&gt;
 &lt;meta charset="UTF-8"&gt;
 &lt;title&gt;Welcome Page&lt;/title&gt;
&lt;/head&gt;
&lt;body&gt;
 Hello, This is Welcome Page.
&lt;/body&gt;
&lt;/html&gt;</code></pre><ul><li>스프링 부트가 제공하는 Welcome Page 기능<ul><li><code spellcheck="false">static/index.html</code> 을 올려두면 Welcome Page 기능을 제공한다.</li></ul></li><li>thymeleaf 템플릿 엔진<ul><li>thymeleaf 공식 사이트: <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.thymeleaf.org/">https://www.thymeleaf.org/</a></li><li>스프링 공식 튜토리얼: <a target="_blank" rel="noopener noreferrer nofollow" href="https://spring.io/guides/gs/serving-web-content/">https://spring.io/guides/gs/serving-web-content/</a> </li></ul></li></ul><code spellcheck="false">demo/controller/HelloController</code><pre spellcheck="false"><code class="language-java">package com.example.demo.controller;

import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.GetMapping;

@Controller
public class HelloController {

 @GetMapping("hello")
 public String hello(Model model) {
 model.addAttribute("name", "전병우");
 return "about-me";
 }

}
</code></pre><code spellcheck="false">resources/templates/about-me.html</code><pre spellcheck="false"><code>&lt;!DOCTYPE html&gt;
&lt;html lang="ko" xmlns:th="http://www.thymeleaf.org"&gt;
&lt;head&gt;
 &lt;meta charset="UTF-8"&gt;
 &lt;title&gt;About Me&lt;/title&gt;
&lt;/head&gt;
&lt;body&gt;
 &lt;p th:text="'안녕하세요. 저는 ' + ${name} + '입니다.'"&gt;&lt;/p&gt;
&lt;/body&gt;
&lt;/html&gt;</code></pre>"thymeleaf 템플릿엔진 동작 확인" <a target="_blank" rel="noopener noreferrer nofollow" href="http://localhost:8080/hello">http://localhost:8080/hello</a> "동작 흐름 그림"<img src="https://image.until.blog/jeonbw06/article/1716809002033" alt="until-307"><ul><li>컨트롤러에서 리턴 값으로 문자를 반환하면 뷰 리졸버(<code spellcheck="false">viewResolver</code>)가 화면을 찾아서 처리한다.<ul><li>스프링 부트 템플릿엔진 기본 viewName 매핑</li><li><code spellcheck="false">resources:templates/</code> + (ViewName) + <code spellcheck="false">.html</code></li></ul></li></ul><blockquote>참고: <code spellcheck="false">spring-boot-devtools</code> 라이브러리를 추가하면, <code spellcheck="false">html</code> 파일을 컴파일만 해주면 서버 재시작 없이 View 파일 변경이 가능하다. IntelliJ 컴파일 방법: 메뉴 build → Recompile</blockquote><h2>4. 빌드하고 실행하기</h2>터미널로 이동 1. <code spellcheck="false">./gradlew build --scan</code> 2. <code spellcheck="false">cd build/libs</code> 3. <code spellcheck="false">java -jar demo-0.0.1-SNAPSHOT.jar</code> 4. 실행 확인

[Spring Boot] Ch 1. 프로젝트 환경설정

<blockquote>Dawn입니다. 사내에서 활용하고 있는 아파치 카프카에 대해서 더욱 알아가고자 공부를 하고 있습니다. 강의를 들으면서 내용을 제 생각과 섞어 정리한 부분이기 때문에 글 내용이 완전한 정답이라고는 할 수 없습니다. 더욱 나은 데이터 엔지니어가 되고자 노력하겠습니다. 감사합니다.</blockquote><h2>초기의 스타트업</h2><img src="https://image.until.blog/dawn-py/article/1727054642391.png" alt="until-1441">기업이 막 생겨나서 초기 서비스가 시작되었을 때는 대게 이렇게 소스데이터(예를 들어 데이터베이스)가 어떤 서비스 내 타켓 데이터로 흘러가는 형식입니다. 서비스가 막 생겨났기 때문에 시스템 규모가 작아 위와 같은 형식이 문제가 되지는 않습니다. 누군가가 코드를 작성하고 데이터를 받아 추출 후 변환하고 로딩하게 되는겁니다.<h2>기업이 확대</h2><img src="https://image.until.blog/dawn-py/article/1727054652308.png" alt="until-1442">점점 기업이 발전하게 되면 자연스럽게 많은 소스 시스템을 갖게 되는데 이때 동일하게 타깃 시스템도 많아지게 됩니다. 정보를 공유하기 위해서는 소스 시스템이 모든 타깃 시스템에 데이터를 전송해야 하기 때문에 데이터 통합 문제는 위와 같이 복잡한 형태를 이루게 됩니다.위와 같은 아키텍쳐는 예를 들어 4개의 소스 시스템이과 6개의 타깃 시스템이 있다면 서비스를 운영하기 위해서는 24개의 통합을 코드로 작성해서 소스데이터를 추출하고 변환하고 로딩해야 합니다. 여간 번거로운 일이 아니죠.또한 모든 소스데이터가 모두 동일한 통신 프로토콜로 전송받는다는 보장도 없습니다. 이제는 TCP, HTTP, REST, FTP, JDBC 등으로 여러 방식으로 데이터가 전송되기 때문입니다.그리고 이러한 데이터가 모두 같은 형식이라는 것도 보장할 수 없습니다. JSON이 될 수도 있고, CSV, Binary, Parquet 등등 다양한 형식으로 데이터가 구성되기때문입니다.이러한 문제를 주먹구구식으로 해결한다고 했을 때 관리의 문제와 비용의 증가가 가장 큰 문제점이라고 할 수 있습니다.지금은 대기업이 된 링크드인 또한 이와 동일한 문제가 있었습니다. 링크드인이 이러한 문제를 어떻게 풀었는지는 <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.google.com/url?sa=i&amp;url=https%3A%2F%2Fwww.linkedin.com%2Fpulse%2Flinkedin-apache-kafka-muhammad-waqas-dilawar&amp;psig=AOvVaw1OjL81dhH37D0ql7MA0vfO&amp;ust=1726248601132000&amp;source=images&amp;cd=vfe&amp;opi=89978449&amp;ved=0CBcQjhxqFwoTCPj08qb3vYgDFQAAAAAdAAAAABAS">해당 링크</a>를 통해 읽어보면 좋을 것 같습니다.<h2>카프카</h2><img src="https://image.until.blog/dawn-py/article/1727054661037.png" alt="until-1443">잠깐 언급했듯이 링크드인은 이러한 문제를 해결하고 이벤트 스트리밍 데이터를 한 곳에 모아서 관리하는 Kafka라는 시스템을 개발하게 됩니다. 카프카는 데이터 중개 플랫폼으로서 소스데이터가 생산(Producer)해내는 데이터를 스트림 형식으로 변환시키고 타깃 시스템이 데이터를 가져가거나 혹은 전달해주는 역할을 합니다. 중간 관리자 역할로 존재하고 분산되어 있던 데이터의 흐름을 연결해서 관리하기 때문에 링크드인은 더욱 확장성있는 이 시스템을 통해 다양한 서비스를 만들게 됩니다.오늘은 카프카가 무엇인지 왜 필요한지에 대해서 간략하게 설명해 보았습니다. 정리도 하면서 글을 써 내려가니 복잡하고 어렵지만 제 글을 읽으면서 도움이 되셨으면 하는 마음에 마무리 지었던 것 같습니다. 다음에는 더 나은 글로 인사드리겠습니다. 감사합니다.

왜 많은 기업은 카프카를 선택할까

[Kafka] 1. 카프카의 필요성

변경이 잦은 프론트엔드에서 어떻게 건강한 테스트코드를 작성할 수 있을까?

Vitest + MSW 로 유연한 단위 / 통합 테스트코드 작성해보기

백준

책으로만 공부하는 습관을 바꾸기 위해 백준 단계별로 풀기를 같이 할 것이다 일단 기본 문법을 하고 바로 백준 풀어야지 풀면서 모르는 걸 추가로 공부해 봐야겠다 해보면서 방향을 수정하다 보면 맞는 공부 방법이 나올 것 같다<a target="_blank" rel="noopener noreferrer nofollow" href="https://www.acmicpc.net/step/1">https://www.acmicpc.net/step/1</a> 이 링크로 들어가면 단계별로 풀 수 있습니다^-^<hr><h2>(2557) Hello World! 출력하기</h2><pre spellcheck="false"><code>console.log("Hello World!"); </code></pre><h2>(1000) 두 정수 입력 받고, 합 출력하기</h2><pre spellcheck="false"><code>const fs = require("fs");

const input = fs.readFileSync("/dev/stdin").toString().split(' ');

const A = parseInt(input[0]);
const B = parseInt(input[1]);

console.log(A + B);</code></pre>입력받아야 하므로 위 2줄을 입력해야 한다. fs (file system) 모듈 불러오기입력값을 읽어오기 위해서는 file system을 요구해야함<pre spellcheck="false"><code>const fs = require("fs");</code></pre>파일 읽어오기 (동기)<pre spellcheck="false"><code>fs.readFileSync('/dev/stdin').toString()</code></pre>백준에서 JS로 문제풀기 위해서는 이렇게 해야한다고 한다/def/stdin 이 경로 외워야한다readFile(비동기) / readFileSync(동기): 코드를 순차적으로 실행하기 위해 readFileSync를 이용<ul><li>동기식 순차적으로 일을 처리한다. 특정 작업이 수행중이라면 다음 작업을 받지 않고 해당 작업이 끝날떄까지 기다린다</li><li>비동기식 동기식과 다르게 들어오는 모든 일을 우선 받아두고 끝났다는 이벤트가 전달되면 해당 이벤트를 처리한다비동기 키워드들 : Callback, Promise, Promise.all, async , await</li></ul>파일 읽어오기 (split)문자열을 일정한 구분자로 잘라서 배열로 지정코드에서는 공백을 기준으로 나누어 배열로 만들었다문제에서 두 정수라고 했으므로 parseIntsplit 메서드에 의해 문자열 배열로 변환되기 때문에 input[0]으로 접근<pre spellcheck="false"><code>const A = parseInt(input[0]); 
const B = parseInt(input[1]);</code></pre><h2>(1001) 두 정수 입력 받고, 차 출력하기</h2><pre spellcheck="false"><code>const fs = require("fs");
const input = fs.readFileSync("/dev/stdin").toString().split(" ");

const A = parseInt(input[0]);
const B = parseInt(input[1]);

console.log(A - B);
</code></pre><h2>(10998) 두 정수 입력 받고, 곱 출력하기</h2><pre spellcheck="false"><code>const fs = require("fs");
const input = fs.readFileSync("/dev/stdin").toString().split(" ");

const A = parseInt(input[0]);
const B = parseInt(input[1]);

console.log(A * B);
</code></pre><h2>(1008) 두 정수 입력 받고, 나누기 출력하기</h2><pre spellcheck="false"><code>const fs = require("fs");
const input = fs.readFileSync("/dev/stdin").toString().split(" ");

const A = parseInt(input[0]);
const B = parseInt(input[1]);

console.log(A / B);
</code></pre><h2>(10869) 두 자연수 입력 받고 더하기, 빼기, 곱하기, 나누기, 나머지 출력하기</h2><pre spellcheck="false"><code>const fs = require("fs");
const input = fs.readFileSync("/dev/stdin").toString().split(" ");

const A = parseInt(input[0]);
const B = parseInt(input[1]);

console.log(A + B);
console.log(A - B);
console.log(A * B);
console.log(parseInt(A / B));
console.log(A % B);</code></pre>JS에서 몫만 구하기 위해서는 parseInt(A / B) 이렇게 해야한다<h2>(10926) 이미 존재하는 아이디일때 놀람 출력</h2><pre spellcheck="false"><code>const fs = require("fs");
const input = fs.readFileSync("/dev/stdin").toString().trim();
console.log(`${input}??!`);</code></pre>trim() 문자열 양 끝의 공백을 제거한 문자열을 반환 공백이 없어도 예외가 발생하지 않고 새 문자열이 반환(즉 복사본)-&gt;한 쪽 긑의 공백만 제거한 문자열을 반환하려면 trimStart(), trimEnd() 사용하기<h2>(18108) 불기 연도를 서기 연도로 변환하기</h2><pre spellcheck="false"><code>const fs = require("fs");
const input = fs.readFileSync("/dev/stdin").toString().split(" ");

const A = parseInt(input[0]);
console.log(A - 543);</code></pre><h2>(10430) 세 수가 주어졌을때, 4가지 값을 구하는 프로그램</h2><pre spellcheck="false"><code>const fs = require('fs');
const input = fs.readFileSync('/dev/stdin').toString().split(' ');
const a = parseInt(input[0]);
const b = parseInt(input[1]);
const c = parseInt(input[2]);

console.log((a+b)%c);
console.log( ((a%c)+(b%c))%c );
console.log( (a*b%c) );
console.log( ((a%c)*(b%c))%c );</code></pre><h2>(2588) 곱셈</h2><pre spellcheck="false"><code>const fs = require('fs');
const input1 = fs.readFileSync('/dev/stdin').toString().split('\n');
const a = Number(input1[0]); // 첫 번째 줄
const b = input1[1]; // 두 번째 줄 각 문자

const b1 = a * Number(b[2]); //일의자리
const b2 = a * Number(b[1]); //십의 자리 
const b3 = a * Number(b[0]); //백의 자리 
const total = a * Number(b); //전체 자리 곱

console.log(b1);
console.log(b2);
console.log(b3);
console.log(total);</code></pre>Number()숫자로 표현하는 객체이다문자열을 숫자로 변환할때 많이 사용오로지 숫자 타입의 문자열만 Number 타입으로 변환한다소수점을 표시 할 수 있다<h2>(11382) 꼬마 정민</h2><pre spellcheck="false"><code>const fs = require('fs');
const input = fs.readFileSync('/dev/stdin').toString().split(' ');
const a = parseInt(input[0]);
const b = parseInt(input[1]);
const c = parseInt(input[2]);

console.log(a + b + c);</code></pre><h2>(10171) 고양이</h2><pre spellcheck="false"><code>console.log(`\\ /\\
 ) ( ')
( / )
 \\(__)|`)
</code></pre>백틱을 사용하면 여러 줄을 한 번에 출력할 수 있다백 슬래시는 2번 입력해야 출력된다 <ul><li>\n 줄바꿈</li><li>\\ 백슬래시</li><li>\' 작은 따옴표</li><li>\" 큰 따옴표</li></ul><h2> (10172) 개</h2><pre spellcheck="false"><code>console.log(`|\\_/|
|q p| /}
( 0 )"""\\
|"^"\` |
||_/=\\\\__|`)</code></pre><img src="https://image.until.blog/swmg03/article/1721235685286" alt="until-877">

이제는 더 이상 물러날 곳이 없다

백준 JS 풀기 - 입출력과 사칙연산

Python

<blockquote>macOS 사용 도중 파이썬 패키지를 설치하기 위해 pip를 사용하자 보안 경고가 발생하며 설치가 거부되었다. 이를 해결하는 방법에 대해 다룬다.</blockquote><h3>도대체 무슨 에러인가?</h3><img src="https://image.until.blog/xeros/article/1727225853116.png" alt="until-1518">Python의 최신 PEP 668 표준에 의해, macOS 환경에서 pip를 통한 패키지 설치가 제약되는 문제라고 한다. 아무래도 최근에 애플에서 맥에 여러가지 보안 강화 조치와 제약이 추가되었는데 여기에 영향을 받은 패치가 아닐까 싶다.이 문제를 해결하는 방법은 크게 3가지정도로 구분할 수 있다.<h3>1. 가상 환경을 사용하는 방법</h3>다음과 같이 Python 가상 환경을 만들어서 사용하면 독립된 공간을 만들어서 사용하기에 pip를 정상적으로 사용할 수 있게 되며 패키지의 버전 문제로 인한 충돌을 피하기도 쉽다. 하지만 매 파이썬 프로젝트마다 가상 환경을 생성해주어야하고 터미널을 열 때마다 <code spellcheck="false">source</code>를 지정해 주어야 한다는 번거로움이 따른다.<ol><li>가상 환경 생성</li></ol><pre spellcheck="false"><code class="language-bash">python3 -m venv path/to/venv</code></pre><ol start="2"><li>가상 환경 활성화</li></ol><pre spellcheck="false"><code class="language-bash">source path/to/venv/bin/activate</code></pre><ol start="3"><li>패키지 설치</li></ol><pre spellcheck="false"><code>pip install supabase</code></pre><h3>2. pip에서 사용자 플래그 추가</h3>시스템 패키지 환경을 보호하기 위해 설치를 사용자 환경으로 제한하여 설치하도록 한다.그냥 귀찮음도 덜하고 보안도 챙기고 무난한 방법인듯하다.<pre spellcheck="false"><code class="language-bash">pip install --user supabase</code></pre><h3>3. break-system-package 옵션 또는 pip.conf 수정</h3>그냥 보안 권고사항을 무시하고 기존에 pip처럼 다이렉트 설치를 가능하게 하는 옵션을 붙여서 사용하면 된다.<pre spellcheck="false"><code class="language-bash">pip install &lt;package name&gt; --break-system-packages</code></pre>근데 매번 이 옵션을 붙이는것도 귀찮다면 아예 <code spellcheck="false">pip.conf</code> 파일을 수정해서 영구적으로 해당 명령을 활성화 시키는것 역시 가능하다.<ol><li><code spellcheck="false">pip.conf</code> 파일 생성</li></ol><pre spellcheck="false"><code class="language-bash">mkdir -p ~/.config/pip
vi ~/.config/pip/pip.conf</code></pre><ol start="2"><li>아래 내용을 추가한다.</li></ol><pre spellcheck="false"><code class="language-bash">pip install supabase --break-system-packages</code></pre><h3>왜 이런 보안조치가 시행되었는가?</h3>애플이 원래도 보안쪽으로는 깐깐했지만 갑자기 이런 기존 시스템에 영향을 줄 수도 있는 패치를 한 원인이 궁금해서 찾아보니 간략하게 설명하자면 pip를 사용한 시스템 전역 패키지 설치가 운영 체제의 패키지 관리자와 충돌할 수 있어 이를 방지하려는 목적이라고 한다. 패키지를 가상 환경이나 사용자 환경에만 설치하도록 유도해서 종속성 관리 문제를 해결하고 보안 취약점을 줄이기 위한 조치인듯 하다.마찬가지로 <code spellcheck="false">Homebrew</code> 역시 현재 공식 홈페이지에 나와있는 Installation 방법을 따라하고 추가적인 수정을 거치지 않으면 명령어 인식이 안된다.

macOS에서 pip externally-managed-environment 에러를 픽스하는 방법

macOS에서 pip install시 error: externally-managed-environment 에러가 발생하는 문제

웹뷰를 작업하면서 겪는 여러 트러블 슈팅 경험을 공유해요

📱 Webview

🪟 Window

<img src="https://image.until.blog/morethanmin/article/1716115237924" alt="until-88">react-query에서 useQuery를 사용하면 staleTime과 gcTime 을 이용해 데이터를 효율적으로 다룰 수 있다. 둘의 차이점을 알아보자.<h2>staleTime</h2><blockquote><ul><li>The time in milliseconds after data is considered stale. This value only applies to the hook it is defined on.</li><li>If set to <code spellcheck="false">Infinity</code>, the data will never be considered stale</li></ul></blockquote><code spellcheck="false">staleTime</code>은 불러온 데이터가 fresh한 시간을 나타낸다. defaultValue는 0으로, 리액트 쿼리에서는 기본적으로 불러온 데이터는 fresh하지 않다고 간주한다.기본 값을 사용하게 된다면 해당 hook을 사용하는 컴포넌트가 mount 될 때마다 data fetching을 시도할 것이다.데이터의 stale여부에 따라서 적절하게 조절해줌으로써 최적화 해줄 수 있다.아래 예시는 until.lbog 에서 사용하는 특정 블로그 정보를 가져오는 훅이다.<pre spellcheck="false"><code class="language-typescript">import { useSuspenseQuery } from '@tanstack/react-query'
import { GetBlogResponse, createGetBlog } from 'src/apis/blog/[username]'
import { queryKeys } from 'src/constants/queryKeys'

const useBlogQuery = () =&gt; {
 const username = useUsername();
 const { data } = useSuspenseQuery&lt;GetBlogResponse&gt;({
 queryKey: queryKeys.blog.username.body(username),
 queryFn: createGetBlog(username),
 staleTime: Infinity,
 })
 return data
}

export default useBlogQuery</code></pre>staleTime을 <code spellcheck="false">Infinity</code>로 설정한 이유는 무엇일까?기본적으로 블로그 정보는 서버사이드에서 불러온 이후 변경되는 경우가 거의 없다. 해당 훅은 블로그에서 전반적으로 사용하고 있기 때문에 staleTime이 0일 경우에는 화면을 전환될 때마다 비효율적인 데이터 패칭이 계속해서 일어날 것이라고 판단하였다.프로필 수정, 팔로우, 팔로잉와 같이 데이터가 더이상 fresh하지 않은 경우에는 <code spellcheck="false">queryClient.invalidateQuery</code>를 통해 명시적으로 갱신해줌으로써 해결할 수 있다.물론 위 방식의 경우 외부적인 요인에 의해 특정 블로그 정보가 변경되는 경우에는 해당 블로그에 재 접속하지 않는 이상 갱신되지 않을 수 있다는 점은 감안해야한다.아래 예시는 게시글 리스트를 가져오는 훅이다.<pre spellcheck="false"><code>import { useSuspenseInfiniteQuery } from '@tanstack/react-query'
import { queryKeys } from 'src/constants/queryKeys'
import {
 GetArticlesParams,
 createGetUserArticles,
} from 'src/apis/blog/[username]/articles'
import useBlogData from 'src/blog/hooks/useBlogData'
import useArticleParams from './useArticleParams'

const useArticlesInfiniteQuery = () =&gt; {
 const blogData = useBlogData()
 const { order, query, tag } = useArticleParams()

 const params: GetArticlesParams = {
 order: order || undefined,
 query: query || undefined,
 tagSlug: tag || undefined,
 }

 const { data, ...infiniteQuery } = useSuspenseInfiniteQuery({
 queryKey: queryKeys.blog.username.articles.list(blogData.username, params),
 queryFn: async ({ pageParam }) =&gt; {
 const getUserArticles = createGetUserArticles(blogData.username)

 return await getUserArticles({ page: pageParam, ...params })
 },
 initialPageParam: 0,
 getNextPageParam: (data) =&gt; (data.hasMore ? data.page + 1 : undefined),
 })

 if (!data) throw new Error('Suspense Error')

 return { data, ...infiniteQuery }
}

export default useArticlesInfiniteQuery
</code></pre>위 훅에서는 반대로 <code spellcheck="false">staleTime</code>을 설정하지 않고 기본값(0)을 사용했다.그 이유는 훅의 영향 범위가 <code spellcheck="false">useBlogQuery</code> 와 같이 전반적인 블로그 페이지에서 사용되는 것이 아닌 하나의 특정된 페이지에서만 사용하기에 때문이다<h2>gcTime (cacheTime)</h2><blockquote><ul><li>The time in milliseconds that unused/inactive cache data remains in memory. When a query's cache becomes unused or inactive, that cache data will be garbage collected after this duration. When different garbage collection times are specified, the longest one will be used.</li></ul></blockquote><code spellcheck="false">gcTime</code> 은 데이터가 사용되지 않는 상황에서 memory에 유지될 수 있는 시간을 의미하고, defaultValue는 클라이언트 사이드에서는 5분, 서버사이드에서는 Infinity로 지정된다.일반적으로 클라이언트 사이드에서 해당 값을 변경하는 경우는 크게 없었던 것 같다.데이터 패칭에 직접적인 영향을 주지 않기 때문이다.다만 서버사이드에서는 Infinity로 설정되기 때문에 얘기가 달라진다. 메모리에 계속해서 데이터가 누적되는 경우에는 해당 값을 적절히 지정해 주는 것이 필요할 것 같다.<h2>결론</h2>어떻게 잡아주더라도 http 통신을 하는 웹페이지 안에서 데이터는 불일치하는 경우는 발생할 수 밖에 없다.데이터의 특성에 따라 적절한 캐싱 시간을 조절함으로써 불일치하는 경우를 최소화 할 수 있도록 하는것이 최선인 것 같다.

react-query에서 useQuery를 사용하면 staleTime과 gcTime 을 이용해 데이터를 효율적으로 다룰 수 있다. 둘의 차이점을 알아보자.staleTimeThe time in milliseconds after data is considered stale. This value only applies to the hook it is define

react-query의 staleTime과 gcTime

기타

useRef로 컴포넌트 위치로 이동시키기<pre spellcheck="false"><code class="language-javascript">const dodyRef = useRef();
dodyRef.current.scrollIntroView({behavior: "smooth"})
</code></pre>

useRef로 컴포넌트 위치로 이동시키기const dodyRef = useRef();
dodyRef.current.scrollIntroView({behavior: "smooth"})


[기타] react에서 컴포넌트 위치로 스크롤 시키기

2024년 7월 13일 오후 10:30#3 강에서의 useAxiosFetch 와, #4 강 Workthrough 에서의 useAxiosFetch 가 조금 달라진 것을 뒤늦게 확인하였습니다.#3 강의 useAxiosFetch ver.01 에서는, AbortController 의 axios 버전인 <code spellcheck="false">axios.CancelToken.source()</code> 를 사용했습니다만,제 불찰로, #4 강의 useAxiosFetch ver.02 에서는, AbortController 기능 자체가 누락됐습니다.useAxiosFetch ver.01 에서의 코드는<pre spellcheck="false"><code class="language-jsx">const { data, loading, error } = useAxiosFetch();
</code></pre>이렇게 훅 자체에서 fetch action 이 트리거 되는 구성이었는데요..useAxiosFetch ver.02 의 코드는 이렇게…<pre spellcheck="false"><code class="language-jsx">const { fetchData, data, loading, error } = useAxiosFetch();
</code></pre>fetch action 펑션을 리턴하는 구조로 바뀌었습니다. useAxiosFetch ver.01 의 코드를 저도 기억하지 못하고 있었고, 당연히 useAxiosFetch ver.02 의 코드가 이어져 왔다고 생각했는데, 혼란을 드리게 되어서 죄송합니다.어쨌든, useAxiosFetch ver.02 의 방식이 제가 생각했던 그 구조가 맞습니다. 그리고, useAxiosFetch ver.02 의 코드에 AbortController 를 추가해서 완성된 코드를 남기고 넘어가야 겠다는 생각이 들어서 보완 아티클을 작성합니다.<h3>useAxiosFetch ver.03</h3>useAxiosFetch ver.02 에서 AbortController 를 추가하려면, 조금은 더 복잡한 코드가 될 것 같습니다.useAxiosFetch 훅 내부에서는 fetch 요청을 취소해야 하는지를 판단할 수 없습니다. 취소 요청은 useAxiosFetch 를 호출한 부모 컴포넌트 에서 발생하기 때문이지요.따라서, useAxiosFetch 가 fetch action 을 취소하는 데에는 두가지 해결방법이 있습니다.첫번째는, useAxiosFetch ver.03 이 모든 fetch action 에서 직전 fetch action 을 cancel 시키는 것이고,두번째는, useAxiosFetch ver.03 이 추가로, <code spellcheck="false">cancelRequest</code> 펑션을 추가해서 리턴하는 방법입니다.두가지 방법을 모두 시도해본 결과, cancel 펑션을 추가로 리턴하는 건, 지나친 복잡성을 불러왔고, "YAGNI" (You Aren't Gonna Need It) 원칙에도 맞지 않았습니다.그래서 첫번째 방법, 모든 fetch action 직전에 이전 fetch action 을 cancel 시키는 방법을 쓰기로 결정하였습니다.<pre spellcheck="false"><code class="language-tsx">/* 2024-07-14 15:45:35

useAxiosFetch ver.03
Typescript 로 작성되었지만, JS 에서는 타입 부분만 살짝 제거하고 사용하시면 될 것 같습니다.

*/

import { useState, useRef, useCallback, useEffect } from "react";
import axios, {
 AxiosRequestConfig,
 AxiosResponse,
 AxiosError,
 Canceler,
} from "axios";
import axiosInstance from "@/util/axiosInstance";

interface State&lt;T&gt; {
 data: T | null;
 loading: boolean;
 error: AxiosError | null;
}

function useAxiosFetch&lt;T&gt;() {
 const [state, setState] = useState&lt;State&lt;T&gt;&gt;({
 data: null,
 loading: false,
 error: null,
 });

 const cancelRef = useRef&lt;Canceler | null&gt;(null);

 const cancelPreviousRequest = () =&gt; {
 if (cancelRef.current) {
 cancelRef.current("Request canceled due to new request");
 cancelRef.current = null;
 }
 };

 const fetchData = useCallback(
 async (endpoint: string, config: AxiosRequestConfig = {}) =&gt; {
 cancelPreviousRequest();

 setState((prev) =&gt; ({ ...prev, loading: true }));

 try {
 const response: AxiosResponse&lt;T&gt; = await axiosInstance.request&lt;T&gt;({
 url: endpoint,
 ...config,
 cancelToken: new axios.CancelToken((c) =&gt; {
 // 다음 렌더링 또는 fetch 액션에서 참조할 cancel 펑션을 ref 에 보관한다.
 cancelRef.current = c;
 }),
 });

 setState({
 data: response.data,
 loading: false,
 error: null,
 });

 return response.data;
 } catch (error) {
 if (!axios.isCancel(error)) {
 setState({
 data: null,
 loading: false,
 error: error as AxiosError,
 });
 }
 throw error;
 }
 },
 []
 );

 useEffect(() =&gt; {
 return () =&gt; {
 cancelPreviousRequest();
 };
 }, []);

 return { fetchData, ...state };
}

export default useAxiosFetch;
</code></pre>useAxiosFetch 를 사용하고 있는 부모 컴포넌트에서의 코드는 특별히 바꿔줄 게 없습니다.이렇게 우리의 useAxiosFetch ver.03 이 완성되었습니다.조금은 더 복잡해진 느낌이지만, Fetch action에서 AbortController 는 꼭 필요하다고 생각합니다.fin.

2024년 7월 13일 오후 10:30#3 강에서의 useAxiosFetch 와, #4 강 Workthrough 에서의 useAxiosFetch 가 조금 달라진 것을 뒤늦게 확인하였습니다.#3 강의 useAxiosFetch ver.01 에서는, AbortController 의 axios 버전인 axios.CancelToken.source() 를 사용했습니다

# 4-1 useAxiosFetch 보완

웹서버 공부중에 큰 도움됐습니다!
좋은 정리글 감사합니다. 🫡

한번 확인해볼게요. 커뮤니티 접속하셔서 오류보고 채널에 남겨주시면 좀더 자세히 파악이 가능할 것 같아요. 항상 감사드려요!

감사합니다!! 원래 morethanlog를 써보려다가 프론트쪽은 너무 몰라서 실패하고, 다시 velog를 사용하려다가 우연히 until을 출시하셨다고 들어서 후다닥 사용해봤는데 너무 좋아서 다시 velog에서 이사 왔습니다!! until 만들어주셔서 너무 감사해요ㅎㅎ 열심히 해보겠습니다 감사합니다!

(+) 아 그리고 임시저장하고 나갔다가 들어오면 제목만 살아있고 내용은 사라지는 버그가 있던데 혹시 제가 이상한 걸까요!?

<img src="https://image.until.blog/morethanmin/article/1716045513650" alt="until-71">항상 맥북만 사용하다가 이번에 데스크탑을 맞추게 되면서 개발환경을 윈도우에서 세팅하게 되었다.<h2>fnm이란?</h2>노드 버전을 관리할 수 있게 해주는 매니저로 nvm과 유사하지만 윈도우에서는 nvm이 지원되지 않기 때문에 fnm를 사용해보려고한다.<h2>winget으로 fnm 설치하기</h2>파워쉘에서 아래와 같이 입력하여 설치할 수 있다.<pre spellcheck="false"><code>winget install Schniz.fnm</code></pre><h3>0x8a15000f 오류가 발생하는 경우</h3>마이크로소프트 스토어에서 앱 설치 관리자를 업데이트 해주면 된다.<img src="https://image.until.blog/morethanmin/article/1716045690970" alt="until-72"><h2>fnm으로 node 설치하기</h2><h3>프로필 설정</h3>우선 <code spellcheck="false">PowerShell</code>프로필에 환경변수를 등록해야한다.<code spellcheck="false">~\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1</code> 경로에 아래와같이 입력 해주면 된다.<pre spellcheck="false"><code>fnm env --use-on-cd | Out-String | Invoke-Expression</code></pre><h3>PowerShell 실행시 PSSecurityException 오류가 발생하는 경우</h3>기본적으로 스크립트 삽입하는 것이 막혀있기 때문에 설정을 바꿔줘야한다.관리자 권한으로 <code spellcheck="false">PowerShell</code> 을 실행해서 아래와 같이 입력한다.<pre spellcheck="false"><code>Set-ExecutionPolicy RemoteSigned</code></pre><h3>node 설치</h3>이제 <code spellcheck="false">PowerShell</code> 을 재부팅하고 아래와 같이 입력해 노드를 설치하면된다.<pre spellcheck="false"><code>fnm use --install-if-missing 20</code></pre><hr>그럼 이제 node를 사용할 수 있다! 근데 PowerShell도 그렇고 여러 이슈들도 그렇고 좀 귀찮은 것 같다. 좀 더 사용해보다가 정 안되면 wsl을 사용해야겠다.

항상 맥북만 사용하다가 이번에 데스크탑을 맞추게 되면서 개발환경을 윈도우에서 세팅하게 되었다.fnm이란?노드 버전을 관리할 수 있게 해주는 매니저로 nvm과 유사하지만 윈도우에서는 nvm이 지원되지 않기 때문에 fnm를 사용해보려고한다.winget으로 fnm 설치하기파워쉘에서 아래와 같이 입력하여 설치할 수 있다.winget install Schniz.fn