요즘 같이 신입들이 설 자리가 굉장히 없는 각박한 시기에, 얼마 전 운이 좋게 신입으로 게임 회사에 면접을 보게 되었습니다 🤣🤣🤣그런데 면접 중 다음과 같은 질문을 받을 수 있었는데, ‘포트폴리오를 확인해 보면 스프링 부트를 주로 사용해 왔는데, 스프링 부트는 보통 내장되어 있는 웹 서버로 Tomcat을 사용하는데도 불구하고 Nginx를 사용한 이유가 있을까요?’이러한 질문을 주셨는데 당시 많이 긴장되어 있는 상황이기도 하였고, 당장 생각나는 것은"저희가 프로젝트 환경상, EC2 한 대에서 프론트엔드와 백엔드를 함께 배포해야 하는 상황이었습니다. 따라서 하나의 도메인으로 모든 요청과 응답이 이루어지는데, 요청이 들어올 때 리버스 프록시 기능을 사용하기 위해 Nginx가 필요하기도 하였고, 보안적인 측면에서도 HTTPS를 사용해야 하기 때문에 Nginx를 사용했습니다."지금은 글로 작성하니까 나름 그럴싸하게 작성했지만, 실제로 대답할 때는 조금 어색하게 표현한 것 같아 후회가 듭니다.😅면접을 볼 때에는 당장 생각나는 것이 이것밖에 없었지만, 뒤늦게 면접관님의 의도를 떠올릴 수 있었습니다. 아마도 Nginx를 사용한 이유, 즉 웹 서버(WS)와 웹 애플리케이션 서버(WAS)의 차이점을 분명하게 이해하고 사용한 것인지를 물어보려고 하셨던 게 아닐까 하는 생각이 들었습니다.그래서 이제는 비슷한 질문을 받더라도 더 이상 실수하지 않게 다시 한 번 학습하고 리마인드를 해보려고 합니다.<hr>웹 서버(Web Server)는 웹 클라이언트(예: 웹 브라우저)로부터 HTTP 요청을 받아 정적 콘텐츠(HTML, CSS, JavaScript, 이미지 등)를 제공하는 소프트웨어입니다.<h2>웹 서버의 주요 역할</h2><h3>주요 기능</h3><ol><li>정적 콘텐츠 제공:<ul><li>HTML, CSS, JavaScript 파일 및 이미지 등과 같은 정적 파일을 클라이언트에 제공합니다. Q. 프론트엔드, 백엔드가 구분되어 사용되는 것이 보통입니다. HTML, CSS, JS 파일은 웹 서버에서 언제 어떤 상황에서 클라이언트에게 제공되는가 ? <ul><li>상황: 사용자가 웹 브라우저를 통해 특정 웹 페이지를 요청하는 경우<ul><li>사용자가 브라우저에서 <code spellcheck="false">http://example.com</code>을 입력하면, 브라우저는 해당 URL에 대한 HTTP 요청을 웹 서버로 보냅니다.</li><li>웹 서버(ex. Nginx)는 요청된 URL을 기반으로 적절한 파일을 찾아 클라이언트에 반환합니다. 여기서 정적 파일 제공이 이루어집니다.</li><li>예를 들어, Nginx와 같은 웹 서버가 <code spellcheck="false">/usr/share/nginx/html</code> 디렉토리에 웹페이지 파일을 저장하고 있다면, 다음과 같은 과정이 진행됩니다:<ul class="tight" data-tight="true"><li>사용자가 <code spellcheck="false">http://example.com/index.html</code>을 요청합니다.</li><li>웹 서버는 요청된 파일 경로를 확인하고, <code spellcheck="false">/var/www/html/index.html</code> 파일을 찾아 응답으로 반환합니다.</li></ul></li><li>HTML 파일 반환: 웹 서버는 <code spellcheck="false">index.html</code> 파일을 클라이언트(브라우저)에 반환합니다. 브라우저는 HTML 파일을 파싱하여 페이지의 기본 구조를 렌더링합니다.</li><li>CSS와 JavaScript 파일 요청: HTML 파일이 로드되면서, 페이지 내에 포함된 CSS 및 JavaScript 파일에 대한 추가 요청이 발생합니다. 예를 들어, HTML 파일에 다음과 같은 링크가 포함되어 있을 수 있습니다:<pre spellcheck="false"><code class="language-html">&lt;link rel="stylesheet" href="styles.css"&gt;
&lt;script src="app.js"&gt;&lt;/script&gt;</code></pre><ul class="tight" data-tight="true"><li>브라우저는 <code spellcheck="false">styles.css</code>와 <code spellcheck="false">app.js</code> 파일을 추가로 요청합니다.</li><li>웹 서버는 동일한 방식으로 이 파일들을 찾아 클라이언트에 반환합니다. </li></ul></li></ul></li><li>구체적인 예시사용자가 <code spellcheck="false">http://example.com</code>에 접속하면 다음과 같은 요청과 응답 흐름이 발생합니다:<ol class="tight" data-tight="true"><li>브라우저 요청: <code spellcheck="false">GET /index.html</code></li><li>웹 서버 응답: <code spellcheck="false">/var/www/html/index.html</code> 파일 반환</li><li>브라우저 요청: <code spellcheck="false">GET /styles.css</code></li><li>웹 서버 응답: <code spellcheck="false">/var/www/html/styles.css</code> 파일 반환</li><li>브라우저 요청: <code spellcheck="false">GET /app.js</code></li><li>웹 서버 응답: <code spellcheck="false">/var/www/html/app.js</code> 파일 반환 </li></ol></li></ul>이 과정을 통해 사용자는 웹 페이지를 볼 수 있게 되며, CSS로 스타일링된 페이지와 JavaScript로 동작하는 기능을 사용할 수 있게 됩니다. </li></ul></li><li>HTTP 요청 처리 및 응답:<ul class="tight" data-tight="true"><li>클라이언트의 HTTP 요청을 처리하고, 적절한 응답을 생성하여 반환합니다. </li></ul></li><li>URL 매핑 및 라우팅:<ul class="tight" data-tight="true"><li>요청 URL을 기반으로 적절한 파일이나 서비스로 요청을 라우팅합니다. 이는 리버스 프록시의 역할로, 클라이언트의 요청을 받아 적합한 백엔드 서버로 전달하고 결과를 다시 클라이언트에게 반환합니다. </li></ul></li><li>로드 밸런싱:<ul class="tight" data-tight="true"><li>여러 서버 간에 트래픽을 분산시켜 고가용성을 유지하고 성능을 향상시킵니다. </li></ul></li><li>보안 기능:<ul class="tight" data-tight="true"><li>SSL/TLS를 통한 데이터 암호화, IP 필터링, 사용자 인증 등 다양한 보안 기능을 제공합니다.</li></ul></li></ol><h3>웹 서버의 예시</h3><ul class="tight" data-tight="true"><li>Apache HTTP Server:<ul class="tight" data-tight="true"><li>오픈 소스 웹 서버로, 다양한 플랫폼에서 사용되며, 매우 널리 사용됩니다.</li></ul></li><li>Nginx:<ul class="tight" data-tight="true"><li>고성능 웹 서버로, 특히 높은 동시 연결 수를 처리할 수 있어 정적 파일 제공 및 리버스 프록시로 자주 사용됩니다.</li></ul></li></ul><hr>웹 애플리케이션 서버(Web Application Server, WAS)는 웹 서버와는 달리, 동적 콘텐츠를 생성하고 웹 애플리케이션의 비즈니스 로직을 처리하는 소프트웨어입니다. WAS는 클라이언트의 요청을 받아들여 데이터베이스와 상호 작용하고, 그 결과를 동적 웹 페이지 형태로 클라이언트에 반환합니다.<h2>웹 애플리케이션 서버의 주요 역할</h2><ol class="tight" data-tight="true"><li>비즈니스 로직 처리:<ul class="tight" data-tight="true"><li>클라이언트 요청을 처리하는 비즈니스 로직을 실행합니다. 예를 들어, 사용자의 로그인, 상품 검색, 주문 처리 등의 작업을 수행합니다. → 서블릿 기반 </li></ul></li><li>동적 콘텐츠 생성:<ul class="tight" data-tight="true"><li>JSP, 서블릿, EJB 등과 같은 기술을 사용하여 동적인 웹 페이지를 생성합니다. 클라이언트의 요청에 따라 실시간으로 콘텐츠를 생성하여 응답합니다. </li></ul></li><li>데이터베이스 연동:<ul class="tight" data-tight="true"><li>데이터베이스와 상호 작용하여 데이터를 조회, 삽입, 업데이트, 삭제하는 작업을 수행합니다. 이를 통해 클라이언트가 요청한 데이터를 처리하고 반환합니다. </li></ul></li><li>세션 관리:<ul class="tight" data-tight="true"><li>사용자 세션을 관리하여 사용자 상태를 유지하고, 인증 및 권한 부여를 처리합니다. 이를 통해 사용자의 로그인 상태를 유지하거나, 사용자별로 다른 콘텐츠를 제공할 수 있습니다. </li></ul></li><li>트랜잭션 관리:<ul class="tight" data-tight="true"><li>데이터베이스 트랜잭션을 관리하여 데이터의 일관성과 무결성을 보장합니다. 여러 작업이 하나의 트랜잭션으로 묶여 일관성 있게 처리되도록 합니다. </li></ul></li></ol><h3>웹 애플리케이션 서버의 예시</h3><ul class="tight" data-tight="true"><li>Apache Tomcat:<ul class="tight" data-tight="true"><li>오픈 소스 서블릿 컨테이너로, 서블릿과 JSP 기반의 웹 애플리케이션을 실행합니다.</li></ul></li></ul><hr><h2>정리</h2><img src="https://image.until.blog/thingk0/article/1716860951310" alt="until-318"><h3>이유 1: 정적 콘텐츠 제공</h3><ul><li>Nginx는 정적 콘텐츠(예: 이미지, CSS, JavaScript 파일 등)를 매우 효율적으로 제공할 수 있습니다. 이를 통해 스프링 부트 애플리케이션이 정적 리소스를 제공하는 부담을 줄이고, 동적 콘텐츠 제공에 집중할 수 있게 합니다.<blockquote>하지만, 보통 프론트엔드와 API 서버 조합으로 많이 사용하기 때문에, 사실상 정적 콘텐츠 제공에는 큰 메리트를 느끼기 어려웠습니다. 그러나 프론트엔드가 SPA일 경우에는 매우 유용하다고 생각합니다.</blockquote></li></ul><h3>이유 2: 리버스 프록시</h3><ul><li>리버스 프록시로서 Nginx는 클라이언트 요청을 스프링 부트 애플리케이션으로 전달합니다. 이를 통해 애플리케이션 서버를 보호하고, 로드 밸런싱 및 SSL 종료(SSL termination) 등의 기능을 제공합니다.<blockquote>실제로 제가 Nginx를 사용하는 가장 주된 이유는, 보통 프로젝트를 진행할 때 서버 인스턴스를 하나만 사용할 수 있는 상황이 많아서, 어쩔 수 없이 서버 안에서 프론트엔드, 인프라, 백엔드를 모두 배포해야 했기 때문입니다.이러한 이유로 Nginx의 리버스 프록시 기능은 매우 유용하고 필요했습니다. 그래서 다행히도 면접에서 가장 먼저 떠올린 리버스 프록시를 답변할 수 있었습니다 !!</blockquote></li></ul><h3>이유 3: 로드 밸런싱</h3><ul><li>로드 밸런싱을 통해 여러 대의 스프링부트 인스턴스에 트래픽을 분산시킬 수 있습니다. 이를 통해 고가용성과 성능을 향상시킬 수 있습니다.<blockquote>면접 중 로드 밸런싱 관련 질문을 받았고, 당연히 Nginx를 통해 로드 밸런싱이 가능하다는 것은 알고 있었습니다.하지만 더 좋은 답변을 위해서는 추후에 블루-그린 배포를 적용하거나 스케일 아웃을 염두에 두었을 때, 로드 밸런싱 기능이 필요하기 때문에 Nginx가 필요하다는 답변을 떠올리지 못했다는 것이 뒤늦은 후회로 남네요..🥲</blockquote></li></ul><h3>이유 4: SSL/TLS 처리</h3><ul class="tight" data-tight="true"><li>SSL/TLS 처리를 Nginx가 담당함으로써 스프링부트 애플리케이션은 암호화된 트래픽을 직접 처리하지 않아도 되므로, 성능과 보안 측면에서 유리합니다.</li></ul><h3>이유 5: 보안</h3><ul class="tight" data-tight="true"><li>보안 설정 및 접근 제어를 Nginx 레벨에서 관리함으로써 애플리케이션의 보안성을 향상시킬 수 있습니다. IP 제한, DDoS 방어, WAF(Web Application Firewall) 등을 설정할 수 있습니다.</li></ul><h3>이유 6: 고성능</h3><ul><li>고성능의 Nginx는 적은 리소스로 많은 요청을 처리할 수 있어, 특히 많은 동시 접속이 발생하는 상황에서 유리합니다.<blockquote>“ Nginx는 비동기 이벤트 기반으로 설계되어, 적은 리소스로도 많은 수의 동시 연결을 효율적으로 처리할 수 있고 다중 워커 프로세스를 통해 병렬로 작업을 수행하여 성능을 극대화하며 메모리를 효율적으로 사용하여 더 많은 요청을 처리할 수 있습니다. "라고도 대답할 수 있다면 아마 만점짜리 답변이겠죠..?</blockquote></li></ul><hr>즉, 저는 리버스 프록시와 보안 부분에서는 어느 정도 정답에 가까운 대답을 했다고 생각해요 ! 하지만 기억을 되돌려보면, 로드 밸런싱 부분에 대해서도 잠깐 질문을 받았는데, 급히 다른 질문으로 넘어갔던 것이 아쉽고... Nginx를 통해 로드 밸런싱, 성능, 그리고 정적 콘텐츠 제공에 대해서도 답변을 할 수 있었다면 더 좋았을 것 같아요.다음에 비슷한 질문을 받는다면, 기존 답변에 보완해서 더욱 멋진 답변을 해보도록 하겠습니다. 😃<img src="https://image.until.blog/thingk0/article/1718793769616" alt="until-611">

최근 게임 회사 면접에서 스프링 부트와 Nginx 사용 이유에 대한 질문을 받았습니다. 이번 포스팅에서는 웹 서버와 웹 애플리케이션 서버의 차이를 명확히 이해하고, Nginx 사용 이유를 깊이 있게 다뤄봅니다.

WAS가 있음에도 불구하고, 웹서버인 Nginx 를 사용하는 이유 - 개발자 면접 리마인드

<h3>코딩 테스트 준비 일지 14 일차</h3><ul class="tight" data-tight="true"><li>응시 사이트 : <a target="_blank" rel="noopener noreferrer nofollow" href="https://leetcode.com/">LeetCode</a></li><li>문제 : <a target="_blank" rel="noopener noreferrer nofollow" class="no-underline hover:text-blue-s dark:hover:text-dark-blue-s truncate cursor-text whitespace-normal hover:!text-[inherit]" href="https://leetcode.com/problems/capacity-to-ship-packages-within-d-days/">Capacity To Ship Packages Within D Days</a></li><li>난이도 : 중상</li><li>풀이시간 : 1h 39m</li></ul>A conveyor belt has packages that must be shipped from one port to another within <code spellcheck="false">days</code> days.The <code spellcheck="false">ith</code> package on the conveyor belt has a weight of <code spellcheck="false">weights[i]</code>. Each day, we load the ship with packages on the conveyor belt (in the order given by <code spellcheck="false">weights</code>). We may not load more weight than the maximum weight capacity of the ship.Return the least weight capacity of the ship that will result in all the packages on the conveyor belt being shipped within <code spellcheck="false">days</code> days.Example 1:<pre spellcheck="false"><code>Input: weights = [1,2,3,4,5,6,7,8,9,10], days = 5
Output: 15
Explanation: A ship capacity of 15 is the minimum to ship all the packages in 5 days like this:
1st day: 1, 2, 3, 4, 5
2nd day: 6, 7
3rd day: 8
4th day: 9
5th day: 10
Note that the cargo must be shipped in the order given, so using a ship of capacity 14 and splitting the packages into parts like (2, 3, 4, 5), (1, 6, 7), (8), (9), (10) is not allowed.</code></pre>Example 2:<pre spellcheck="false"><code>Input: weights = [3,2,2,4,1,4], days = 3
Output: 6
Explanation: A ship capacity of 6 is the minimum to ship all the packages in 3 days like this:
1st day: 3, 2
2nd day: 2, 4
3rd day: 1, 4</code></pre>Example 3:<pre spellcheck="false"><code>Input: weights = [1,2,3,1,1], days = 4
Output: 3
Explanation:
1st day: 1
2nd day: 2
3rd day: 3
4th day: 1, 1</code></pre>Constraints:<ul class="tight" data-tight="true"><li><code spellcheck="false">1 &lt;= days &lt;= weights.length &lt;= 5 * 104</code></li><li><code spellcheck="false">1 &lt;= weights[i] &lt;= 500</code></li></ul><h3>문제 풀이 접근</h3>이 문제 풀이는 단번에 접근할 수 없었다. 이분탐색 개념도 희미해져서 잘 몰랐을 뿐더러, 풀면서 이분탐색이 뭐였지? 하면서 개념을 다시 살펴보고 문제를 다시확인했다. 처음 설정한 방향성은 List 를 하나 더만들어서 [1,2,3,4,5,6,7,8,9,10]이 있다면, 이분 탐색으로 중간지점 인덱스 5, value 6 이하의 값을 1,2,3,4,5 해서 선적에 넣고 리스트 앞에서 다 날리고 이후에 [6,7,8,9,10] 에서 또 중간지점 인덱스 2 , value 8 이하의 점을 날리고 [8,9,10] 에서 8 날리고 9 날리고 10 날리고 하면 딱 될것 같아서 생각을 해봤으나, 3번의 예시가 보기좋게 응 아니야라는 메시지를 날렸다.결국 혼자 풀지못하고 풀이 영상을 확인하니 그제서야 접근 방식을 알았다. 방식은 인덱스로 이분탐색하면 안되는 것이 핵심이었다. 1. 무게 중 가장 큰 값이 Left 로 들어가고, 모든 무게의 합이 Right 로 들어간다 . 2. 여기서 조건에 따라 양 사이드를 땡기는 투포인터 느낌으로다가 L = mid + 1, R = mid -1 로 범위를 당겨온다. 3. 조건은 CalcDays &gt;= days 일 경우, Low = mid + 1 을 한다. ( 이 경우, 선적의 중량이 부족하다는 소리, 그래서 결국 몇일 더걸린다는 얘기니까 Low 를 땡겨서 선적의 중량을 올린다.) 반대 조건인 else 구문은 High = mid - 1 을 한다. ( 중량이 차고 넘치니까, 예산일정보다 빨리 끝난다는 얘기다. 그러니, 선적의 중량을 낮춘다.)<h3>예시 풀이</h3>2번이 테스트 하면서 잘 안됐었어서 2번으로 예시 풀이 하겠다.<pre spellcheck="false"><code>Input: weights = [3,2,2,4,1,4], days = 3
Output: 6
Explanation: A ship capacity of 6 is the minimum to ship all the packages in 3 days like this:
1st day: 3, 2
2nd day: 2, 4
3rd day: 1, 4</code></pre>이 중 가장 큰 값인 4, 를 Left, 모든 합 16 을 Right , mid 값은 이 중간 값 ( m 은 여기서 선적 용량 ) L = 4 , R = 16 , M = 10 M = 10 일때, CalcDays [3,2,2] , [4,1,4] =&gt; 2로 끝난다. 선적의 중량이 많다. 낮춘다. R = M - 1 로 변경 L = 4, R = 9 , M = 6 M = 6 일때, CalcDays [3,2] [2,4] [1,4] =&gt; 3그룹 이지만 실제 CalcDays 는 2 이다. 당긴다. R = 6 - 1 = 5 L = 4 , R = 5 , M = 5 M = 5 일때, CalcDays [3,2] [2] [4] [3,1] =&gt; 4, CalcDays &gt; Days L = 5 + 1 로 놓는다. While ( Left &lt;= Right ) 의 조건으로 빠져나와 Left를 반환하면 최적의 값을 출력할 수 있다.<h3>작성 코드</h3><pre spellcheck="false"><code>using System.Collections.Generic;
public class Solution {
public int ShipWithinDays(int[] weights, int days) { int low = 0;
 int high = 0;
 int mid = 0;

 for(int i = 0; i &amp;lt; weights.Length; ++i)
 {
 high += weights[i];
 low = Math.Max(low, weights[i]);
 }

 // 용량을 기준으로 BS 한다.
 // 예시 1번으로는, [10, 55] 로 BS 진행한다.
 

 while(low &amp;lt;= high)
 {
 int calcDays = 0; // 산정된 일 수 
 int nowSum = 0;

 mid = (low + high) / 2; // 용량

 for(int i = 0; i &amp;lt; weights.Length; ++i)
 {
 if(nowSum + weights[i] &amp;gt; mid)
 {
 // 현재 용량 선적보다 많다. 일 수를 추가해야함.
 nowSum =0;
 ++calcDays;
 }

 nowSum += weights[i];
 }

 // 여기서 용량 선적이 남으면, 다시 최적을 찾는다. 
 if(calcDays &amp;gt;= days)
 low = mid + 1;
 else 
 high = mid - 1;
 }

 return low;
}}</code></pre><h3>코드 결과</h3><img src="https://image.until.blog/sin0105/article/1718156679033" alt="until-457">

코딩테스트 항해99 클럽 - 14일차

[코딩테스트 일지 - 99클럽] 14일차 - Capacity To Ship Packages Within D Days

⚛️ React

<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