Next.js: 보안 붕괴

Vercel의 충격적인 발표 이후 개발자 커뮤니티에 새로운 공황 상태가 휩쓸었습니다. 13개의 새로운 Common Vulnerabilities and Exposures (CVEs)가 Next.js와 React에 동시에 영향을 미쳤습니다. 2026년 5월 변경 로그에 상세히 설명된 이 전례 없는 보안 릴리스는 수많은 프로덕션 애플리케이션을 즉시 위험에 빠뜨렸습니다. 엄청난 수의 결함으로 인해 Better Stack 채널과 같은 저명한 목소리들이 "I'm Done With NextJS..."라고 선언하며 광범위한 개발자들의 불만을 나타냈습니다.

심각도 등급은 암울한 그림을 그렸습니다. 이 취약점 중 6개는 '높음' 심각도 분류를 받아 긴급한 주의를 요구했습니다. 치명적인 결함에는 여러 Denial of Denial of Service of Denial of Service 벡터, 심각한 Server-Side Request Forgery (SSRF) 익스플로잇(일부는 최고 심각도로 기록됨), 그리고 다양한 Cross-Site Scripting (XSS) 기회가 포함되었습니다. 이것들은 이론적인 약점이 아니라 공격자들이 사용자 데이터를 침해하고, Denial of Services를 비활성화하며, 보안 조치를 우회할 수 있는 구체적인 경로였습니다.

이러한 CVEs의 영향은 여러 최신 Next.js 버전에 걸쳐 있었으며, 사실상 모든 활성 프로젝트에 즉각적인 업그레이드를 필수적으로 만들었습니다. 패치는 middleware 우회(Pages Router에서 서버 측 props를 노출시킨 7.5/10 심각도의 i18n 취약점과 같은)부터 cache poisoning 및 기타 교활한 문제에 이르기까지 다양한 문제를 해결했습니다. Vercel의 해결책은 명확했습니다: 노출을 완화하기 위해 모든 Next.js 설치를 지체 없이 업데이트하십시오.

이 최신 보안 폭탄은 React 생태계 내에서 지속적이고 불안정한 논쟁을 다시 불러일으킵니다: 서버 컴포넌트는 실수였을까요? 많은 중요한 취약점, 특히 7.5/10 심각도의 Denial of Denial of Service of Denial of Service 공격은 서버 컴포넌트의 기본 직렬화 형식인 React Flight Protocol에서 직접 비롯됩니다. 이는 올해 서버 컴포넌트 관련 CVEs의 세 번째 중요한 물결을 나타내며, 이 패러다임의 근본적인 보안 아키텍처에 대한 심각한 질문을 제기합니다. React Server DOM package를 피하는 TanStack Start와 같은 프레임워크는 영향을 받지 않아 보안 프로필의 증가하는 차이를 강조합니다.

치명적인 i18n middleware 우회는 Next.js의 Pages Router로 구축된 애플리케이션을 무단 데이터 접근에 노출시켰습니다. 10점 만점에 7.5점의 심각도를 가진 CVE로 식별된 이 결함은 공격자가 민감한 서버 측 데이터를 보호하도록 설계된 인증 로직을 우회할 수 있도록 허용했습니다. 이 취약점은 특히 Next.js의 국제화 (i18n) 기능을 활용하는 애플리케이션에 영향을 미쳤습니다.

우회를 악용하는 데는 최소한의 노력이 필요했습니다. 공격자는 먼저 렌더링된 모든 페이지의 `_next/data` 스크립트 내에서 일반적으로 발견되는 애플리케이션의 고유한 build ID를 얻었습니다. 이 ID를 사용하여 그들은 `getServerSideProps`에 의존하여 데이터를 가져오는 페이지를 대상으로 `/_next/data/[build ID]/[page].json`과 같은 직접 URL을 구성할 수 있었습니다. 이 직접 접근은 페이지의 데이터 페이로드를 JSON으로 검색하여 애플리케이션의 middleware에 구현된 모든 인증 검사를 완전히 우회했습니다.

근본 원인 분석 결과 Next.js의 i18n 통합 내에 결함 있는 로직이 발견되었습니다. i18n이 활성화되었을 때, 프레임워크의 middleware matcher는 페이지의 기본 경로(예: `/secret`)를 적절하게 보호하지 못했습니다. `/en/secret` 또는 `/fr/secret`와 같은 로케일별 변형은 middleware 인증을 올바르게 트리거했지만, 원시적이고 지역화되지 않은 데이터 엔드포인트는 보호되지 않은 상태로 남아 있었습니다. 이는 보안된 정보에 직접 접근할 수 있는 거대한 허점을 만들었습니다.

`getServerSideProps`를 통해 민감한 정보를 전달하는 애플리케이션에 미치는 영향은 상당했습니다. 권한 없는 사용자는 로그인 없이 사용자 이메일, 내부 플래그 또는 독점 헤드라인과 같은 기밀 데이터를 검색할 수 있었습니다. 이는 핵심 보안 가정을 훼손했으며, 미묘한 구성상의 오류가 프로덕션 환경에서 심각한 데이터 유출로 이어질 수 있음을 보여주었습니다.

최근 i18n middleware 우회(심각도 7.5점의 CVE)는 많은 Next.js 애플리케이션 내에 존재하는 더 심각한 아키텍처 취약점을 드러냈습니다. 개발자들은 middleware를 결정적인 보안 경계로 오해하는 경우가 많으며, 이는 "I'm Done With NextJS" 비디오가 직접적으로 반박하는 오해입니다. Next.js 문서 자체도 중요한 권한 부여를 위해 middleware에만 의존하는 것을 권장하지 않습니다.

Middleware 함수는 설계상 주로 요청 수정, 리디렉션 또는 기본적인 접근 제어를 위해 사용됩니다. 이들은 엣지 레이어에서 작동하므로 i18n 취약점이나 데이터 가져오기 엔드포인트에 대한 직접 접근과 같은 특정 우회 벡터에 취약합니다. 이러한 내재된 한계는 강력한 애플리케이션 보안을 위해 심층 방어(defense-in-depth) 전략을 요구합니다.

진정한 보안은 초기 요청 파이프라인뿐만 아니라 모든 계층에서 검사를 요구합니다. 서버 측 API 경로(server-side API routes) 및 `getServerSideProps` 또는 `getStaticProps` 함수 내에 포괄적인 인증 및 권한 부여를 직접 구현하십시오. 이는 middleware가 실패하거나 우회되더라도 민감한 데이터가 명시적인 서버 수준 유효성 검사에 의해 보호되도록 보장합니다.

중요한 권한 부여를 위해 middleware에만 전적으로 의존하는 것은 위험한 취약점을 만듭니다. 공격자는 우회를 악용하여 다음을 수행할 수 있습니다: - `_next/data` JSON 페이로드에서 이메일 또는 내부 플래그와 같은 민감한 사용자 데이터에 접근합니다. - 역할 기반 접근 제어를 우회하여 관리 인터페이스에 무단으로 진입합니다. - 애플리케이션 상태를 조작하거나 일반적으로 인증된 사용자에게만 제한된 작업을 수행합니다.

이러한 취약점이 웹 애플리케이션에 어떤 영향을 미칠 수 있는지에 대한 추가 정보는 Security Update: Multiple vulnerabilities in Next.js and React - Netlify와 같은 자료를 참조하십시오. 이러한 다층적 접근 방식은 단일 실패 지점이 전체 애플리케이션의 무결성을 손상시키는 것을 방지합니다.

공격자들은 Next.js 서버 컴포넌트와 React Server DOM 패키지를 활용하는 모든 프레임워크를 대상으로 하는 치명적인 서비스 거부(Denial of Service) 취약점을 발견했습니다. 10점 만점에 7.5점의 심각도 등급이 부여된 이 결함은 최소한의 노력으로 애플리케이션을 치명적인 속도 저하에 노출시킵니다. Next.js 애플리케이션에서 가장 간단한 서버 액션을 사용하는 개발자조차 취약했습니다.

익스플로잇 메커니즘은 서버에 엄청나게 부풀려진 페이로드를 전송하는 것을 포함합니다. 공격자들은 React Flight Protocol의 역직렬화 단계에서 서버의 처리 능력을 압박하도록 특별히 설계된 수천 개의 키와 포인터를 포함하는 요청을 만듭니다. 이 프로토콜은 React가 서버와 클라이언트 간에 컴포넌트 트리와 데이터를 직렬화하는 방식을 표준화합니다.

겉보기에는 무해해 보이는 이 데이터 구조는 알고리즘적 고장을 유발합니다. 역직렬화 프로세스는 이처럼 과도하게 크고 복잡한 페이로드에 직면했을 때, 문자열 비교에서 이차 복잡도(K * N)로 퇴화합니다. 이는 단일 잘못된 요청에 대해 예상 처리량을 훨씬 초과하는 놀라운 2억 회의 연산을 초래합니다.

그 영향은 즉각적이고 심각합니다. 일반적으로 0.02초 만에 해결될 요청이 단 한 번의 익스플로잇 실행 후 6초로 늘어납니다. 이러한 요청을 여러 개 연결하면 서버 스레드를 효과적으로 차단하여 애플리케이션이 응답하지 않게 되고 합법적인 사용자가 접근할 수 없게 됩니다.

React와 Next.js 엔지니어들은 React Flight 프로토콜 내의 서비스 거부 공격 (DoS) 취약점을 완화하기 위해 정교한 패치를 신속하게 개발했습니다. 이 익스플로잇은 이전에 공격자들이 단일의 악의적으로 조작된 요청으로 서버를 과부하 상태로 만들 수 있게 했습니다. 이 해결책은 주로 복잡한 데이터 구조 처리에서 어려움을 겪었던 역직렬화 프로세스를 목표로 했습니다.

개발자들은 들어오는 데이터 스트림을 역직렬화하기 위한 새로운 커서 기반 시스템을 구현했습니다. 이 독창적인 접근 방식은 프로토콜의 복잡한 컴포넌트 트리와 데이터를 놀라운 효율성으로 처리합니다. 전체 페이로드를 여러 번 파싱하는 대신, 커서 시스템은 데이터를 지능적으로 탐색하여 리소스 사용을 최적화합니다.

이 공학적 위업은 계산 복잡도를 극적으로 개선했습니다. 이전 역직렬화 방식은 중첩된 객체의 깊이를 나타내는 K와 총 항목 수를 나타내는 N으로 인해 K * N 복잡도를 겪었으며, 이는 기하급수적인 속도 저하를 초래했습니다. 새로운 시스템은 N + K로 작동하는 매우 효율적인 선형 복잡도를 달성합니다. 이 근본적인 변화는 서버가 페이로드를 처리하는 방식을 근본적으로 바꾸었습니다.

성능과 보안에 미치는 영향은 즉각적이고 심오했습니다. 벤치마크는 악성 페이로드에 대한 연산 횟수가 엄청나게 감소했음을 보여주었습니다. 이전에는 서버를 한계점으로 몰아붙이며 2억 회 이상의 연산을 유발했던 것이 이제는 약 20만 회의 연산만 필요하게 되었습니다. 이 결정적인 조치는 DoS 위협을 효과적으로 무력화하여 React Flight 프로토콜 기반 애플리케이션을 유사한 공격으로부터 보호했습니다.

다양한 취약점 중 가장 높은 심각도 점수를 받은 것은 8.6/10의 Server-Side Request Forgery (SSRF)로, 자체 호스팅 Next.js 애플리케이션에 영향을 미쳤습니다. 이 치명적인 결함은 심각한 신뢰 위반을 나타내며, 공격자들이 공개 서버를 내부 정찰 및 익스플로잇을 위한 무의식적인 공범으로 만들 수 있게 했습니다.

SSRF는 근본적으로 서버를 속여 공격자를 대신하여 접근 불가능한 내부 서비스에 요청을 하도록 만듭니다. 일반적으로 강력한 방화벽으로 보호되는 서버가 외부 악성 행위자의 명령에 따라 갑자기 자체 내부 데이터베이스, 캐싱 계층 또는 비공개 API에 연결하는 것을 상상해 보십시오. 이것이 SSRF 공격의 본질입니다.

이 Next.js 취약점을 악용하는 것은 놀라울 정도로 간단했습니다. 공격자들은 `Upgrade: websocket` 헤더와 사용자 지정 요청 대상을 포함하는 `curl` 요청을 만들었습니다. 겉보기에는 무해한 이 조합은 서버를 조작하여 내부 네트워크 내에서 임의의 연결을 시작하게 함으로써 외부 방어를 우회했습니다.

이 SSRF가 제시하는 위험은 치명적이었습니다. 이는 직접적인 firewall bypass를 제공하여 공격자들에게 조직의 가장 민감한 인프라로 들어가는 비할 데 없는 관문을 열어주었습니다. 일반적으로 격리되고 보호되는 내부 데이터베이스, Redis 인스턴스 및 기타 비공개 API는 손상된 Next.js 애플리케이션을 통해 직접 노출되었습니다.

이 취약점은 공격자가 내부 네트워크를 매핑하고, 민감한 데이터를 추출하거나, 심지어 Denial of Services에 직접 접촉하지 않고도 내부 시스템에서 작업을 트리거할 수 있음을 의미했습니다. 애플리케이션 보안에 대한 추가 지침을 찾는 개발자를 위해 Guides: Data Security - Next.js와 같은 자료는 귀중한 정보를 제공합니다. 쉬운 악용과 깊은 내부 접근 가능성이 결합되어 이 SSRF는 Next.js 보안 릴리스에서 가장 우려되는 공개 중 하나가 되었습니다.

Better Stack 비디오 "I'm Done With NextJS... 13 NEW vulnerabilities"는 도발적으로 server components가 실수였는지 물었습니다. 이 질문은 React Server Components (RSCs)의 내재된 보안 오버헤드에 대한 개발 커뮤니티 내의 커지는 우려를 명확히 합니다. 패러다임 전환은 상당한 "security tax"를 도입합니다. 이는 아키텍처 복잡성의 부인할 수 없는 증가와 확장된 공격 표면을 의미합니다.

RSCs를 구현하는 것은 서버-클라이언트 계약을 근본적으로 재정의하며, 전통적인 HTTP 요청-응답 주기를 넘어섭니다. 이 새로운 모델은 데이터 직렬화 및 역직렬화에 대한 세심한 처리를 요구하며, 종종 사용자 지정 프로토콜을 통해 이루어집니다. 비디오에서 인용된 Primeagen의 가슴 아픈 트윗은 이 도전을 완벽하게 요약합니다: "It's hard to make custom serialization protocols." RSCs의 핵심인 React Flight protocol은 정확히 그러한 사용자 지정 계층 역할을 하며, 그 복잡한 특성으로 인해 견고하고 안전한 구현이 매우 어렵습니다.

최근 13개 CVE에 대한 분석은 뚜렷한 패턴을 보여줍니다. 심각한 Denial of Denial of Service of Denial of Service 결함을 포함한 많은 취약점은 RSCs의 새로운 아키텍처와 Flight protocol의 복잡성에 직접적으로 기인합니다. 예를 들어, DoS 취약점은 RSCs의 기본 요소인 `React Server DOM` 패키지를 악용했습니다. 이것은 일반적인 API 버그가 아니었습니다. 이는 컴포넌트 트리와 데이터가 서버와 클라이언트 간에 어떻게 스트리밍되는지를 악용했습니다.

이 패턴은 서버 및 클라이언트 로직을 모호하게 하는 시스템에 내재된 고유한 보안 문제를 강조합니다. middleware bypass는 직접적인 Flight protocol 문제는 아니지만, i18n과 같은 기능을 포함한 새로운 라우팅 패러다임이 복잡한 프레임워크에서 어떻게 예상치 못한 공격 벡터를 도입할 수 있는지를 보여줌으로써 전반적인 "security tax"에 기여합니다. 개발자들은 이제 전통적인 HTTP 요청 유효성 검사를 넘어 컴포넌트 직렬화 및 하이드레이션 깊숙한 곳에 있는 위협을 고려해야 합니다. 이는 더 높은 수준의 정밀 조사와 전체 스택에 걸친 잠재적 악용에 대한 더 넓은 이해를 요구하며, 보안 분석의 부담을 애플리케이션의 훨씬 더 깊고 추상적인 수준으로 이동시킵니다.

TanStack Start는 최근 Next.js 취약점의 물결 속에서 완전히 무사했습니다. Next.js가 중요한 미들웨어 우회 및 Server-Side Request Forgery를 포함한 13개의 CVE에 씨름하는 동안, TanStack Start는 영향을 받지 않았습니다. 이러한 극명한 대조는 프레임워크 아키텍처와 보안 태세에 미치는 직접적인 영향에 대한 중요한 사례 연구를 제공합니다.

이러한 차이는 근본적인 설계 철학에 있습니다. Next.js는 종종 서버 경계와 암묵적인 데이터 흐름을 추상화하는 "마법"을 통해 개발자 편의성을 우선시합니다. 이 접근 방식은 강력하지만, React Flight protocol 또는 i18n routing과 같은 기본 메커니즘이 예기치 않게 작동할 때 숨겨진 공격 표면을 도입할 수 있습니다.

반대로 TanStack Start는 명확하게 정의된 loaders 및 액션을 통해 명시적이고 타입 안전한 접근 방식을 지지합니다. 개발자는 서버 측 작업을 명시적으로 선언하여 서버-클라이언트 경계를 명확하게 만듭니다. 이러한 아키텍처의 명확성은 프레임워크의 동작이 개발자 기대와 더 예측 가능하게 일치하므로 잘못된 구성이나 의도하지 않은 데이터 노출 가능성을 최소화합니다.

"마법"을 줄이는 프레임워크는 종종 개발자가 데이터 흐름 및 실행 환경에 직접 직면하도록 강제함으로써 보안을 강화합니다. 명시적인 서버 기능과 강력한 타입 검사를 강조하는 TanStack Start의 설계 선택은 본질적으로 더 안전하고 감사 가능한 개발자 경험을 촉진합니다. 이러한 예측 가능성은 Next.js가 최근 보안 릴리스에서 겪었던 우회 및 데이터 유출 취약점 유형에 대한 강력한 방어가 됩니다.

궁극적으로 이것은 한 프레임워크의 전반적인 우월성을 선언하는 것이 아니라 아키텍처적 교훈입니다. TanStack의 예외는 명시적인 설계, 명확한 서버 경계, 그리고 강력한 타입 안전성이 프레임워크의 공격 표면을 근본적으로 줄일 수 있음을 강조합니다. 이는 개발자와 프레임워크 작성자 모두에게 편의성 대 제어의 보안 함의를 고려하도록 도전합니다.

Next.js 개발자들은 긴급한 의무에 직면해 있습니다. 최근 공개된 13개의 CVE는 애플리케이션과 사용자 데이터를 보호하기 위한 즉각적이고 단호한 조치를 요구합니다. 미들웨어 우회 및 Server-Side Request Forgery와 같은 문제의 심각성을 고려할 때, 지연은 용납할 수 없는 위험을 초래합니다.

먼저, 현재 Next.js 및 React 버전을 정확히 식별하십시오. 이 기본적인 단계는 최근 패치된 취약점에 대한 노출 수준을 결정합니다. `npm list next` 및 `npm list react`를 사용하거나 `package.json`을 검사하여 이러한 중요한 종속성을 확인하십시오.

영향을 받는 모든 애플리케이션을 패치된 버전으로 즉시 업그레이드하십시오. Next.js 15.5.18 이상, React 19.0.6 이상을 목표로 하십시오. 이 릴리스에는 React Flight protocol을 통한 Denial of Denial of Service of Denial of Service를 포함하여 광범위한 보안 결함에 대한 중요한 수정 사항이 포함되어 있습니다. 이러한 취약점에 대한 추가 기술 정보는 CVE-2026-23864: React and Next.js Denial of Denial of Service of Denial of Service via Memory Exhaustion | Akamai와 같은 자료를 참조하십시오.

프레임워크 추상화에 보안이 의존하는 영역에 초점을 맞춰 애플리케이션 코드를 철저히 감사하십시오. 미들웨어 로직에 특히 주의를 기울여 인증 및 권한 부여 검사가 강력하며 i18n 결함과 같은 우회에 취약하지 않은지 확인하십시오. Server-Side Request Forgery 및 기타 데이터 노출 위험을 방지하기 위해 데이터 가져오기 패턴을 면밀히 검토하십시오.

Initiate a comprehensive team discussion about architectural risk와 미래 프레임워크 선택. 이 사건은 표면적인 API 사용을 넘어선 심층적인 보안 이해의 필요성을 강조합니다. 현재 프레임워크 선택이 조직의 보안 태세 및 위험 허용 범위와 일치하는지 평가하십시오.

특히 Next.js와 React에 영향을 미치는 전례 없는 13 CVEs의 홍수와 같은 최근의 폭로는 웹 개발의 중요한 기로를 나타냅니다. 이 사건은 현대 애플리케이션 구축을 지배하게 된 아키텍처 패러다임에 대한 필수적인 재평가를 강요합니다. 미묘한 Middleware Bypasses부터 심각한 Server-Side Request Forgery에 이르는 취약점의 광범위한 범위는 자기 성찰을 요구합니다.

통합된 server-driven UI frameworks는 탁월한 개발자 경험과 성능을 약속하지만, 의도치 않게 기본적인 보안 모범 사례를 앞질렀을까요? React Flight protocol을 통한 단일 잘못된 요청이 Denial of Denial of Service of Denial of Service를 유발하거나, i18n configuration flaw가 민감한 server-side props를 노출할 때 "server component 'security tax'"라는 주장은 상당한 설득력을 얻습니다.

개발자들은 server와 client logic을 통합하는 편리함을 받아들였지만, 이러한 긴밀한 결합은 본질적으로 새로운 attack surfaces를 생성합니다. 무엇이 어디서, 어떤 context에서 실행되는지에 대한 경계가 모호해지면서 현재의 security models가 완전히 다루지 못할 수 있는 복잡성이 발생합니다. 이는 견고한 threat modeling을 그 어느 때보다 어렵게 만듭니다.

미래 개발은 명시적이고 decoupled architectures에 대한 새로운 강조를 볼 수 있습니다. client와 server 간의 명확한 경계, 아마도 well-defined API contracts 및 distinct security domains을 통해 보안 추론을 단순화하고 systemic risk를 줄이는 방법으로 다시 선호될 수 있습니다. 단순성은 종종 보안과 직접적으로 관련이 있습니다.

반대로, Next.js와 같은 frameworks는 더욱 견고한 security primitives를 통합하고 더 엄격하고 proactive auditing을 거쳐 성숙하고 안정화될 수 있습니다. React Flight protocol Denial of Denial of Service of Denial of Service vulnerability에 대해 구현된 영리한 engineering fix는 압박 속에서도 신속하고 효과적인 remediation 능력을 보여줍니다.

TanStack Start가 이러한 광범위한 vulnerabilities로부터 눈에 띄게 면제된 것은 설득력 있는 대안적 관점을 제공합니다. 특히 React Server DOM package를 피하는 architectural choices는 다른 design philosophies가 본질적으로 다른 security profiles를 생성함을 시사합니다. 이는 framework approaches의 다양성에 대한 강력한 주장을 제시합니다.

ecosystem이 궁극적으로 어떤 길을 택하든, 이 episode는 보안이 afterthought로 남을 수 없다는 냉혹한 경고 역할을 합니다. 모든 architectural decision을 재고하고, 모든 dependency를 면밀히 조사하며, 다음 project의 첫 번째 코드 줄부터 resilient security posture를 우선시하십시오. 책임은 모든 developer에게 있습니다.

2026년 5월 릴리스에서 가장 중요한 Next.js vulnerabilities는 무엇입니까?

가장 중요한 vulnerabilities에는 높은 심각도의 Server-Side Request Forgery (SSRF) (8.6/10), 여러 Middleware Bypasses (7.5/10), 그리고 React Flight protocol을 표적으로 하는 Denial of Service (DoS) attack (7.5/10)이 포함됩니다.

React Server Components (RSCs)는 본질적으로 insecure한가요?

RSCs는 본질적으로 insecure하지 않지만, attack surface를 크게 확장하는 새롭고 복잡한 paradigm을 도입합니다. 이 'security tax'는 unsafe deserialization과 같은 vulnerabilities를 방지하기 위해 framework authors와 developers 모두에게 더 많은 diligence를 요구합니다.

이러한 vulnerabilities로부터 Next.js application을 어떻게 보호할 수 있습니까?

유일하게 보장된 해결책은 공식 Vercel 보안 권고에 명시된 패치된 버전으로 Next.js 및 React 종속성을 즉시 업그레이드하는 것입니다. WAF에만 의존하는 것은 충분하지 않습니다.

TanStack Start는 이러한 Next.js 취약점의 영향을 받았습니까?

아니요, TanStack Start는 React Server DOM 패키지나 Next.js와 동일한 아키텍처 패턴을 사용하지 않으므로 이러한 특정 CVE의 영향을 받지 않았습니다. 이는 더 명시적인 디자인의 보안 이점을 강조합니다.