정적 렌더링
1. 개요
1. 개요
정적 렌더링은 서버에서 웹 페이지의 HTML을 미리 생성하여 완성된 정적 파일 형태로 제공하는 웹 렌더링 방식이다. 이는 서버 사이드 렌더링의 한 형태로, 사용자의 요청이 들어오기 전에 모든 페이지의 최종 HTML을 빌드 타임에 미리 만들어 놓는다는 점이 특징이다.
이 방식은 콘텐츠가 자주 변경되지 않는 웹사이트, 검색 엔진 최적화가 중요한 페이지, 그리고 빠른 초기 로딩 속도가 요구되는 페이지에 주로 사용된다. 생성된 정적 파일은 CDN에 캐싱되어 전 세계 어디서나 빠르게 제공될 수 있으며, 서버는 단순히 미리 만들어진 파일을 전송하는 역할만 하면 되므로 서버 부하가 현저히 줄어든다.
정적 렌더링은 전통적인 클라이언트 사이드 렌더링과 대비되는 개념으로, 프론트엔드 개발 패러다임의 중요한 축을 이룬다. 자바스크립트 프레임워크의 발전과 함께, 정적 사이트 생성 도구의 등장으로 그 활용도가 크게 확대되었다.
이 접근법의 핵심은 모든 사용자에게 동일한 사전 렌더링된 HTML 콘텐츠를 제공한다는 점이다. 따라서 사용자별로 데이터가 실시간으로 달라져야 하는 매우 동적인 페이지에는 적합하지 않을 수 있지만, 그 외의 많은 경우에 뛰어난 성능과 안정성을 보장한다.
2. 원리
2. 원리
정적 렌더링의 원리는 웹 페이지의 HTML, CSS, 자바스크립트 파일을 사전에 빌드 과정에서 완전히 생성하여, 서버가 이러한 정적 파일들을 그대로 사용자에게 제공하는 것이다. 이는 사용자의 요청이 있을 때마다 서버에서 데이터베이스를 조회하거나 API를 호출하여 동적 콘텐츠를 생성하는 방식과 근본적으로 다르다. 대신, 빌드 타임에 모든 페이지의 최종 마크업을 생성해 놓기 때문에, 실제 사용자 접속 시에는 단순히 미리 만들어진 파일을 전송하는 것만으로 렌더링이 완료된다.
이 과정은 일반적으로 정적 사이트 생성기나 프레임워크의 빌드 명령을 통해 실행된다. 개발자는 템플릿, 컴포넌트, 그리고 필요한 데이터(예: 마크다운 파일, JSON 데이터)를 제공하면, 빌드 시스템이 이들을 조합하여 각 URL 경로에 해당하는 완전한 HTML 파일을 생성한다. 생성된 정적 파일들은 CDN에 배포되어 전 세계 사용자에게 빠르게 전달될 수 있다.
따라서 정적 렌더링은 서버 사이드 렌더링이나 클라이언트 사이드 렌더링과 달리 런타임에 서버 측 처리가 필요하지 않다. 이는 블로그, 문서화 사이트, 랜딩 페이지처럼 콘텐츠 업데이트 주기가 비교적 길고 사용자별로 맞춤화된 데이터가 필요하지 않은 경우에 매우 효율적인 원리를 제공한다. 최근에는 증분 정적 재생성과 같은 기술을 통해 빌드 타임 이후에도 선택적으로 페이지를 재생성할 수 있는 유연성이 추가되기도 했다.
3. 장점
3. 장점
정적 렌더링의 가장 큰 장점은 빠른 로딩 속도이다. 서버에서 미리 완성된 HTML 파일을 CDN을 통해 사용자에게 전달하기 때문에, 서버에서 매번 페이지를 생성하는 서버 사이드 렌더링이나 브라우저에서 자바스크립트를 실행해 돔을 구성하는 클라이언트 사이드 렌더링에 비해 초기 페이지 응답 시간이 현저히 짧다. 이는 사용자 경험과 직접적으로 연결되는 핵심 이점이다.
또한, 완성된 HTML을 검색 엔진의 크롤러에게 그대로 제공할 수 있어 검색 엔진 최적화에 매우 유리하다. 동적으로 콘텐츠를 생성하는 방식에서는 검색 엔진이 페이지 내용을 정확히 인덱싱하는 데 어려움이 있을 수 있지만, 정적 렌더링은 이러한 문제를 근본적으로 해결한다.
서버 측면에서는 부하가 크게 감소한다는 장점이 있다. 모든 페이지가 미리 생성된 정적 파일이므로, 사용자 요청 시 복잡한 데이터베이스 조회나 템플릿 연산을 수행할 필요가 없다. 이는 서버 자원을 절약하고, 동일한 하드웨어로 더 많은 트래픽을 처리할 수 있게 한다.
마지막으로, 캐싱 효율성이 뛰어나다. 변경되지 않는 정적 파일은 브라우저 캐시나 CDN에 오랜 시간 동안 저장되어 재사용될 수 있다. 이는 반복적인 사용자 접속 시 네트워크 트래픽을 추가로 발생시키지 않으며, 전 세계 어디에서나 일관된 빠른 속도로 콘텐츠를 제공하는 데 기여한다.
4. 단점
4. 단점
정적 렌더링은 사전에 생성된 HTML 파일을 제공하기 때문에, 콘텐츠가 실시간으로 자주 업데이트되어야 하는 동적 웹사이트에는 적합하지 않다. 사용자별로 맞춤화된 콘텐츠(예: 개인화된 대시보드, 실시간 주문 상태)를 보여주거나, 실시간 데이터(예: 주식 시세, 소셜 미디어 피드)를 표시하는 데에는 한계가 있다. 이러한 경우에는 서버 사이드 렌더링(SSR)이나 클라이언트 사이드 렌더링(CSR)이 더 적절한 접근 방식이 될 수 있다.
또 다른 단점은 빌드 시간이다. 사이트의 모든 페이지를 미리 생성해야 하므로, 페이지 수가 매우 많거나 콘텐츠 업데이트 빈도가 높을 경우 빌드 프로세스에 상당한 시간이 소요될 수 있다. 이는 개발 및 배포 주기에 영향을 미친다. 콘텐츠가 변경될 때마다 전체 사이트를 다시 빌드해야 하는 경우, 이 과정은 비효율적이고 시간이 많이 걸릴 수 있다.
마지막으로, 정적 렌더링은 서버 측 로직이나 데이터베이스 쿼리를 실행할 수 있는 능력이 제한적이다. 모든 페이지는 빌드 시점에 결정된 데이터를 기반으로 생성되므로, 사용자 요청 시점에 서버에서 추가적인 처리를 하거나 실시간 데이터를 가져와 페이지를 구성하는 것이 기본적으로 불가능하다. 이는 웹사이트의 기능적 유연성을 떨어뜨리는 요인이 된다. 이러한 문제를 완화하기 위해 증분 정적 재생성(ISR)이나 에지에서의 부분적 렌더링과 같은 하이브리드 접근법이 등장했다.
5. 사용 사례
5. 사용 사례
정적 렌더링은 콘텐츠가 상대적으로 고정적이고 자주 변경되지 않는 웹사이트에 매우 적합한 방식이다. 대표적인 사용 사례로는 기업 홈페이지, 블로그, 포트폴리오 사이트, 제품 카탈로그, API 문서 페이지, 랜딩 페이지 등이 있다. 이러한 사이트들은 사용자별로 다른 데이터를 보여줄 필요가 없거나, 콘텐츠 업데이트 주기가 빌드 주기보다 느린 경우가 많다. 예를 들어, 회사 소개나 연혁, 제품 설명서와 같은 정보는 빌드 시점에 한 번 생성해두면 이후 수정이 있을 때까지 동일한 HTML 파일을 제공할 수 있다.
검색 엔진 최적화가 매우 중요한 마케팅 중심의 웹사이트에서도 정적 렌더링은 핵심적인 역할을 한다. 검색 엔진 크롤러는 서버에서 미리 완성된 HTML을 즉시 받아볼 수 있으므로, 콘텐츠를 빠르고 정확하게 색인화할 수 있다. 이는 클라이언트 사이드 렌더링 방식처럼 자바스크립트 실행을 기다려야 하는 경우에 비해 확실한 SEO 이점으로 작용한다. 따라서 뉴스 기사, 백과사전, 교육 자료와 같은 정보 제공형 사이트에서도 널리 채택된다.
또한, 정적 렌더링은 매우 빠른 초기 로딩 속도를 보장하므로 사용자 경험이 중요한 서비스에서 선호된다. 전 세계적으로 사용자가 접속하는 콘텐츠 전송 네트워크에 정적 파일들을 배포하면, 지리적 위치에 관계없이 짧은 지연 시간으로 콘텐츠를 제공할 수 있다. 이는 이커머스 사이트의 상품 소개 페이지나 미디어 사이트의 기사 페이지처럼 사용자의 이탈을 줄여야 하는 상황에서 큰 장점이 된다.
6. 구현 방법
6. 구현 방법
6.1. 빌드 타임 정적 생성
6.1. 빌드 타임 정적 생성
빌드 타임 정적 생성은 웹 개발에서 정적 렌더링을 구현하는 핵심 방식 중 하나이다. 이 방식은 웹사이트나 애플리케이션을 실제 사용자에게 서빙하기 전, 즉 빌드 과정에서 모든 HTML, CSS, 자바스크립트 파일을 미리 생성해 정적 파일 형태로 만들어 놓는다. 이렇게 생성된 정적 파일들은 CDN이나 웹 서버에 배포되어 사용자의 요청이 들어오면 즉시 전달된다. 이 과정은 데이터베이스 쿼리나 복잡한 서버 측 로직 실행 없이 단순한 파일 전송으로 이루어지므로 응답 속도가 매우 빠르다.
이 방식은 콘텐츠의 업데이트 주기가 비교적 길고, 사전에 모든 페이지를 정의할 수 있는 경우에 가장 적합하다. 예를 들어, 기업 홈페이지, 블로그, 제품 설명서, 랜딩 페이지와 같이 콘텐츠가 자주 변경되지 않는 웹사이트를 구축할 때 효과적이다. 정적 사이트 생성기라고 불리는 Jekyll, Hugo, Gatsby와 같은 도구들이 이 방식을 주로 사용하며, Next.js나 Nuxt.js 같은 현대적 프레임워크도 빌드 타임 정적 생성을 위한 기능을 제공한다.
빌드 타임 정적 생성의 가장 큰 장점은 성능과 안정성이다. 모든 페이지가 미리 렌더링되어 있기 때문에 사용자는 최소한의 네트워크 지연만으로 콘텐츠를 볼 수 있어 초기 로딩 속도가 매우 빠르다. 또한 서버는 동적 렌더링 부담이 없어 서버 부하가 현저히 줄고, 생성된 정적 파일들은 캐싱이 매우 용이하여 CDN을 통한 글로벌 배포 효율성이 극대화된다. 이는 궁극적으로 사용자 경험을 향상시키고 운영 비용을 절감하는 효과를 가져온다.
그러나 이 방식은 실시간 데이터 반영에 한계가 있다. 빌드 시점 이후에 변경된 데이터는 사이트를 다시 빌드하고 배포하지 않는 한 사용자에게 보여줄 수 없다. 따라서 댓글, 실시간 주가, 개인화된 사용자 대시보드와 같이 빈번하게 업데이트되는 동적 콘텐츠를 처리하기에는 부적합할 수 있다. 이러한 단점을 보완하기 위해 증분 정적 재생성이나 클라이언트 사이드 렌더링을 혼용하는 하이브리드 접근법이 종종 사용된다.
6.2. 정적 사이트 생성(SSG)
6.2. 정적 사이트 생성(SSG)
정적 사이트 생성은 웹 개발에서 서버가 웹 페이지의 HTML을 미리 생성하여 완성된 정적 파일 형태로 제공하는 웹 렌더링 방식이다. 이는 빌드 타임에 모든 페이지를 사전에 생성하는 방식으로, 사용자의 요청이 있을 때마다 서버에서 동적으로 페이지를 생성하는 서버 사이드 렌더링과 구분된다.
이 방식은 콘텐츠가 자주 변경되지 않는 웹사이트에 특히 적합하다. 예를 들어, 기업 홈페이지, 블로그, 포트폴리오, 제품 문서나 마케팅 랜딩 페이지 등이 대표적이다. 또한 검색 엔진 최적화가 중요하거나 빠른 초기 로딩 속도가 요구되는 페이지에서 강점을 발휘한다.
정적 사이트 생성의 주요 장점은 빠른 로딩 속도와 검색 엔진 최적화의 용이성이다. 사전에 렌더링된 완전한 HTML 파일을 CDN을 통해 전송받기 때문에 사용자는 즉시 콘텐츠를 볼 수 있다. 또한 서버는 매 요청마다 페이지를 생성할 필요가 없어 부하가 감소하고, 생성된 파일은 캐싱 효율성이 매우 높다.
이를 구현하는 대표적인 프레임워크로는 Next.js, Gatsby, Nuxt.js, Hugo, Jekyll 등이 있다. 이러한 도구들은 마크다운 파일이나 API 등 다양한 데이터 소스에서 콘텐츠를 가져와 빌드 시점에 정적 HTML 파일을 생성하는 기능을 제공한다.
7. 관련 개념
7. 관련 개념
7.1. 서버 사이드 렌더링(SSR)
7.1. 서버 사이드 렌더링(SSR)
서버 사이드 렌더링은 웹 페이지를 서버 측에서 완전히 렌더링하여 완성된 HTML을 클라이언트에게 전송하는 방식이다. 이는 전통적인 웹 개발 방식으로, 사용자의 요청이 있을 때마다 서버가 데이터베이스에서 데이터를 가져와 템플릿과 결합하여 동적으로 페이지를 생성한다. 생성된 완전한 HTML 문서는 사용자의 브라우저로 전달되어 즉시 표시된다.
이 방식의 주요 장점은 검색 엔진 최적화에 매우 유리하다는 점이다. 서버에서 완성된 HTML 콘텐츠를 제공하므로 검색 엔진 봇이 페이지 내용을 쉽게 수집하고 색인할 수 있다. 또한, 초기 페이지 로딩 시 클라이언트 측에서 추가적인 자바스크립트 번들을 다운로드하고 실행할 필요 없이 콘텐츠를 바로 볼 수 있어, 느린 네트워크 환경이나 성능이 낮은 장치에서도 사용자 경험이 향상될 수 있다.
그러나 서버 사이드 렌더링은 사용자와의 상호작용이 많은 현대적 웹 애플리케이션에는 단점이 존재한다. 모든 페이지 요청이 서버를 거쳐 처리되어야 하므로, 사용자가 다른 페이지로 이동할 때마다 전체 페이지를 새로고침해야 하는 경우가 많다. 이는 단일 페이지 애플리케이션에 비해 매끄럽지 않은 사용자 경험을 초래할 수 있으며, 서버에 매 요청마다 렌더링 부하가 발생한다.
서버 사이드 렌더링은 전자상거래 상품 페이지, 뉴스 기사, 블로그 포스트와 같이 콘텐츠 중심이면서 검색 노출이 중요한 사이트에서 여전히 널리 사용된다. PHP, 루비 온 레일즈, 자바, 닷넷 등의 서버 측 기술 스택을 활용하는 전통적인 웹사이트 구조의 핵심 렌더링 방식이다.
7.2. 클라이언트 사이드 렌더링(CSR)
7.2. 클라이언트 사이드 렌더링(CSR)
클라이언트 사이드 렌더링(CSR)은 웹 페이지의 렌더링 작업이 사용자의 웹 브라우저에서 실행되는 자바스크립트에 의해 수행되는 방식을 의미한다. 이 방식에서는 서버가 최초 요청 시 거의 비어 있는 HTML 문서와 애플리케이션 로직을 담은 자바스크립트 번들 파일을 제공한다. 이후 브라우저는 이 자바스크립트 코드를 다운로드하고 실행하여, 필요한 데이터를 API 서버로부터 가져와 동적으로 DOM을 구성하고 화면을 완성한다.
이 접근 방식의 주요 장점은 초기 로딩 이후의 사용자 경험에 있다. 페이지 간 전환이나 데이터 갱신이 필요한 경우, 서버로부터 완전한 새 페이지를 요청하지 않고도 필요한 부분만 자바스크립트를 통해 빠르게 업데이트할 수 있다. 이는 싱글 페이지 애플리케이션(SPA)의 핵심 원리로, 데스크톱 애플리케이션과 유사한 매끄러운 상호작용을 제공한다. 또한, 서버는 정적 파일과 API 응답만 처리하면 되므로, 서버의 컴퓨팅 자원 부담이 상대적으로 적다.
그러나 클라이언트 사이드 렌더링은 몇 가지 명확한 단점을 지닌다. 가장 큰 문제는 검색 엔진 최적화(SEO)에 취약할 수 있다는 점이다. 검색 엔진 크롤러가 자바스크립트를 완전히 실행하지 못할 경우, 페이지의 실제 콘텐츠를 인덱싱하지 못할 수 있다. 또한, 사용자는 첫 화면을 보기까지 자바스크립트 번들의 다운로드, 파싱, 실행이 모두 완료되어야 하기 때문에 초기 로딩 속도가 느려질 수 있으며, 이는 특히 네트워크 환경이 좋지 않거나 저사양 기기에서 두드러진다.
따라서 클라이언트 사이드 렌더링은 대화형 요소가 많고 페이지 전환이 빈번한 웹 애플리케이션에 적합하다. 반면, 콘텐츠 중심이며 검색 노출이 중요한 사이트나 최초 접속 성능이 중요한 경우에는 정적 렌더링이나 서버 사이드 렌더링(SSR)이 더 나은 선택이 될 수 있다. 현대 웹 개발 트렌드에서는 이러한 단점을 보완하기 위해 Next.js나 Nuxt.js 같은 프레임워크에서 제공하는 하이브리드 렌더링 방식(예: 증분 정적 재생성(ISR))을 채택하는 경우가 많다.
7.3. 증분 정적 재생성(ISR)
7.3. 증분 정적 재생성(ISR)
증분 정적 재생성(ISR)은 정적 렌더링의 한계를 보완하기 위해 도입된 하이브리드 렌더링 방식이다. 기존의 정적 사이트 생성(SSG)이 빌드 시점에 모든 페이지를 한 번만 생성하는 방식이라면, ISR은 사이트가 배포된 후 런타임에서도 특정 조건에 따라 페이지를 재생성하거나 업데이트할 수 있다. 이는 빌드 타임에 모든 페이지를 미리 생성하는 데 걸리는 시간과 비용 문제를 해결하며, 콘텐츠 업데이트 주기가 다른 다양한 페이지를 효율적으로 관리할 수 있게 해준다.
ISR의 핵심 동작 원리는 다음과 같다. 먼저, 최초 요청 시에는 빌드 타임에 생성된 정적 페이지를 즉시 제공한다. 이후, 사전에 정의된 재검증(Revalidation) 주기가 지나면, 해당 페이지에 대한 다음 사용자 요청이 들어올 때 백그라운드에서 페이지를 재생성한다. 재생성 작업이 완료되면 기존의 캐시된 페이지를 새로운 버전으로 교체하고, 이후의 모든 요청에는 업데이트된 페이지를 제공한다. 이 과정에서 사용자는 항상 즉시 응답받는 정적 페이지를 경험하게 되며, 페이지 갱신은 투명하게 이루어진다.
이 방식은 콘텐츠가 자주 변경되지 않지만 주기적인 업데이트가 필요한 블로그, 이커머스 상품 페이지, 뉴스 기사 목록 등에 매우 적합하다. 예를 들어, 매일 한 번씩만 업데이트되는 블로그의 경우, ISR을 통해 24시간마다 페이지를 재생성하도록 설정하면 빌드 시간을 크게 단축하면서도 콘텐츠를 최신 상태로 유지할 수 있다. 또한, 트래픽이 매우 많은 페이지에서도 서버 부하를 분산시키고 빠른 응답 속도를 유지하는 데 유리하다.
ISR은 정적 사이트 생성(SSG)의 장점인 빠른 성능과 높은 SEO 효율을 유지하면서도, 서버 사이드 렌더링(SSR)의 동적 갱신 능력의 일부를 결합한 발전된 형태로 평가받는다. 이를 통해 개발자는 애플리케이션의 특성에 따라 각 페이지별로 최적의 렌더링 전략(SSG, ISR, SSR)을 유연하게 선택할 수 있는 환경을 갖추게 되었다.
8. 도구 및 프레임워크
8. 도구 및 프레임워크
정적 렌더링을 구현하는 데 널리 사용되는 도구와 프레임워크는 다양하다. 대표적인 정적 사이트 생성기로는 Jekyll, Hugo, Gatsby, Next.js 등이 있다. Jekyll은 루비 기반의 오래된 도구로, GitHub Pages와의 통합이 용이하다. Hugo는 Go 언어로 작성되어 매우 빠른 빌드 속도를 자랑하며, 단일 실행 파일로 간편하게 사용할 수 있다. Gatsby는 리액트와 그래프QL을 기반으로 하여 동적 데이터 소스와의 연동에 강점을 보인다.
최신 프론트엔드 프레임워크 생태계에서는 Next.js와 Nuxt.js가 정적 렌더링을 위한 강력한 기능을 제공한다. Next.js는 리액트 프레임워크로, getStaticProps와 getStaticPaths 같은 데이터 페칭 메서드를 통해 빌드 타임에 페이지를 정적으로 생성하는 정적 사이트 생성(SSG)을 공식적으로 지원한다. 마찬가지로 뷰.js 프레임워크인 Nuxt.js도 nuxt generate 명령어를 통해 정적 사이트를 생성할 수 있다.
이 외에도 엘레venty, Astro, SvelteKit과 같은 현대적인 도구들이 인기를 얻고 있다. Astro는 기본적으로 모든 콘텐츠를 정적 HTML로 렌더링하며, 필요한 경우에만 최소한의 자바스크립트를 보내는 "아일랜드 아키텍처"를 채택해 성능을 극대화한다. SvelteKit은 스벨트를 기반으로 한 풀스택 프레임워크로, 어댑터를 통해 정적 사이트로의 출력을 지원한다.
이러한 도구들은 마크다운, API, 데이터베이스 등 다양한 데이터 소스에서 콘텐츠를 가져와 사전 렌더링할 수 있으며, CI/CD 파이프라인과 연동하여 자동화된 배포를 구축하는 데 적합하다.
9. 여담
9. 여담
정적 렌더링은 웹 개발 초기부터 존재해 온 근본적인 방식이다. 초기의 웹사이트는 모두 정적 HTML 파일로 구성되었으며, 서버는 단순히 이 미리 작성된 파일들을 사용자에게 전달하는 역할만 했다. 이후 동적 웹사이트와 데이터베이스 기반 콘텐츠 관리 시스템(CMS)이 등장하면서 복잡한 상호작용이 가능해졌지만, 이는 성능과 서버 부하 측면에서 새로운 과제를 남겼다. 이러한 배경에서, 자바스크립트 프레임워크와 빌드 도구의 발전은 정적 렌더링을 현대적인 형태로 재해석하는 계기가 되었다.
정적 사이트 생성(SSG)은 이러한 현대적 접근법의 대표적인 예시다. 리액트, 뷰, 넥스트와 같은 도구들은 개발 단계에서 API나 데이터베이스로부터 데이터를 가져와 미리 모든 페이지의 HTML, CSS, 자바스크립트 파일을 생성한다. 이렇게 생성된 정적 파일들은 CDN(콘텐츠 전송 네트워크)에 배포되어 전 세계 어디서나 빠르게 제공될 수 있다. 이는 마치 공장에서 제품을 미리 대량 생산해 두는 것과 유사한 개념으로, 사용자 요청 시마다 서버에서 페이지를 새로 만드는 방식보다 훨씬 효율적이다.
정적 렌더링의 부활은 웹 성능과 사용자 경험(UX)에 대한 중요성이 커지면서 주목받기 시작했다. 특히 코어 웹 바이탈과 같은 페이지 경험 지표가 검색 엔진 랭킹에 직접적인 영향을 미치게 되면서, 빠른 첫 콘텐츠풀 페인트(FCP)와 최대 콘텐츠풀 페인트(LCP)를 보장하는 정적 렌더링의 가치는 더욱 높아졌다. 블로그, 문서화 사이트, 이벤트 페이지, 제품 소개 페이지 등 콘텐츠 업데이트 주기가 비교적 길고 SEO가 중요한 사이트에서 그 진가를 발휘한다.
물론, 모든 상황에 적합한 만능 해법은 아니다. 실시간 데이터가频繁하게 변하거나 사용자별로 맞춤화된 콘텐츠를 제공해야 하는 경우에는 서버 사이드 렌더링(SSR)이나 클라이언트 사이드 렌더링(CSR)이 더 적절할 수 있다. 그러나 증분 정적 재생성(ISR)과 같은 하이브리드 기술의 등장으로, 정적 렌더링의 한계였던 "데이터의 신선도" 문제도 점차 극복되고 있는 추세다.
