SSL/TLS 암호화편집자 확인

SSL은 넷스케이프 커뮤니케이션스가 1994년에 개발한 보안 소켓 계층 프로토콜이다. 초기 버전인 SSL 1.0은 공개되지 않았으며, 1995년에 공개된 SSL 2.0이 최초의 널리 사용된 버전이었다. 그러나 SSL 2.0에는 여러 보안 결함이 발견되어 1996년에 SSL 3.0이 출시되었다.

TLS는 SSL의 후속 프로토콜로서, 인터넷 엔지니어링 태스크 포스가 표준화를 주도하여 1999년에 RFC 2246으로 TLS 1.0을 발표했다. TLS 1.0은 SSL 3.0을 기반으로 하지만 호환되지 않는 몇 가지 중요한 보안 개선 사항을 포함한다. 기술적으로 SSL과 TLS는 별개의 프로토콜이지만, 역사적 연속성과 일반적인 통용어로 인해 두 용어가 혼용되어 왔다.

두 프로토콜의 주요 버전과 연표는 다음과 같다.

현대적인 보안 표준에서는 오래되고 취약한 SSL 2.0, SSL 3.0 및 TLS 1.0, TLS 1.1의 사용을 중단할 것을 강력히 권고한다. 현재는 TLS 1.2와 TLS 1.3이 안전한 통신을 위한 표준 프로토콜로 자리 잡았다. 일반적으로 "SSL"이라고 부르는 기술의 대부분은 실제로는 최신 TLS 프로토콜을 가리킨다.

SSL/TLS는 통신의 안전을 보장하기 위해 세 가지 핵심 보안 목표를 달성한다. 이는 기밀성, 인증, 무결성이다. 각 원리는 특정 암호학적 기술을 통해 구현되며, 함께 작동하여 종단 간 보안 채널을 형성한다.

기밀성은 오직 의도된 수신자만이 메시지 내용을 알 수 있도록 보장하는 것을 의미한다. 이를 위해 대칭키 암호화 방식을 사용한다. 핸드셰이크 과정에서 협상된 대칭키를 사용하여 실제 데이터를 암호화하고 복호화한다. 대표적인 알고리즘으로는 AES와 ChaCha20 등이 있다.

인증은 통신 상대방의 신원을 확인하는 과정이다. 주로 공개키 기반 구조를 활용하며, 서버는 인증서를 클라이언트에게 제출한다. 이 인증서는 신뢰할 수 있는 인증 기관에 의해 서명되어 있어, 클라이언트는 서버의 공개키와 신원을 검증할 수 있다. 선택적으로 클라이언트도 인증서를 제출하여 상호 인증을 수행할 수 있다.

무결성은 전송 중인 데이터가 변조되거나 손상되지 않았음을 보장한다. 이는 메시지 인증 코드 또는 전자 서명 기술을 통해 달성된다. 해시 함수를 사용하여 데이터에서 고정 길이의 다이제스트를 생성하고, 이를 비밀키로 암호화하거나 서명하여 수신측에서 검증한다. TLS에서는 일반적으로 HMAC이나 AEAD 암호화 스위트를 사용한다.

핸드셰이크 프로토콜은 클라이언트와 서버가 통신을 시작하기 전에 보안 매개변수를 협상하는 과정이다. 이 과정은 크게 네 가지 주요 단계로 나뉜다. 핸드셰이크가 완료되면, 협상된 대칭키를 사용한 실제 데이터 암호화 통신이 시작된다.

첫 번째 단계는 'Client Hello'이다. 클라이언트는 서버에 연결을 시도하며 지원하는 TLS 버전, 사용 가능한 암호화 스위트 목록, 그리고 클라이언트가 생성한 무작위 데이터를 보낸다. 서버는 이에 응답하여 'Server Hello' 메시지를 보낸다. 서버는 클라이언트가 제안한 항목들 중에서 협상할 TLS 버전과 암호화 스위트 하나를 선택하고, 서버 자신이 생성한 무작위 데이터를 함께 회신한다.

다음 단계에서 서버는 자신의 디지털 인증서를 클라이언트에게 전송한다. 이 인증서에는 서버의 공개키와 서버의 신원 정보가 포함되어 있다. 필요한 경우, 서버는 클라이언트 인증을 요구하기 위해 'Certificate Request' 메시지를 보낼 수 있다. 서버는 'Server Hello Done' 메시지를 보내 이 단계를 마친다. 클라이언트는 받은 인증서를 검증하고, 신뢰 체인을 통해 발급 기관(CA)을 확인한다.

마지막 단계에서 클라이언트는 'Pre-master Secret'이라는 또 다른 무작위 데이터를 생성한다. 클라이언트는 서버 인증서에서 얻은 공개키로 이 값을 암호화하여 서버에 전송한다. 서버는 자신의 개인키로 이를 복호화한다. 이제 클라이언트와 서버 양측은 'Client Random', 'Server Random', 'Pre-master Secret'이라는 세 가지 값을 공유하게 된다. 양측은 동일한 알고리즘을 사용해 이 세 값을 조합하여 실제 데이터 암호화에 사용할 세션키(대칭키)를 각자 독립적으로 생성한다. 이후 'Change Cipher Spec' 메시지로 암호화 방식 전환을 알리고, 'Finished' 메시지를 교환하여 핸드셰이크 과정이 무결하게 완료되었음을 확인한다.

SSL/TLS 핸드셰이크의 핵심 목표는 클라이언트와 서버가 안전하게 통신하기 위한 대칭키를 협상하고 교환하는 것이다. 비대칭키 암호화는 초기 보안 채널 수립과 신원 확인에 사용되며, 이후 실제 데이터 암호화에는 효율성이 높은 대칭키가 사용된다.

핸드셰이크 과정에서의 키 협상은 주로 다음 단계를 따른다.

1. 클라이언트 헬로(Client Hello): 클라이언트가 지원하는 암호화 스위트 목록과 Client Random이라는 난수를 서버에 보낸다.

2. 서버 헬로(Server Hello): 서버는 선택한 암호화 스위트와 Server Random이라는 난수를 클라이언트에 응답한다.

3. 인증서와 키 교환: 서버는 자신의 공개키가 포함된 디지털 인증서를 전송한다. 이후 서버는 선택한 키 교환 알고리즘에 따라 pre-master secret 생성을 위한 공개키 파라미터(예: Diffie-Hellman 공개값)를 전송한다.

4. pre-master secret 생성: 클라이언트는 검증된 서버의 공개키로 pre-master secret을 암호화하거나, 협상된 Diffie-Hellman 파라미터를 사용하여 서버와 독립적으로 pre-master secret을 계산한다. 이 값을 서버에 전송한다(필요한 경우).

5. 세션 키 도출: 클라이언트와 서버 양측은 Client Random, Server Random, pre-master secret을 입력값으로 하여 동일한 암호화 스위트에 정의된 키 도출 함수를 실행한다. 이 과정을 통해 실제 데이터 암호화와 무결성 검증에 사용될 일련의 대칭키(세션 키)를 생성한다.

이 방식의 장점은 비대칭키 암호화의 강력한 보안을 이용해 초기 신뢰를 구축한 후, 효율적인 대칭키 암호화로 통신 성능을 확보한다는 점이다. 특히 TLS 1.3에서는 보안을 강화하고 지연을 줄이기 위해 지원하는 키 교환 메커니즘을 Diffie-Hellman 계열로 제한하고, 과정을 단순화하였다.

인증서는 공개키 암호화 시스템에서 주체(예: 웹 서버)의 신원과 공개키를 바인딩하는 디지털 문서이다. 주로 X.509 표준 형식을 따르며, 신뢰할 수 있는 제3자인 인증 기관(CA)이 서명하여 발급한다. 인증서의 주요 역할은 클라이언트(예: 웹 브라우저)가 접속하려는 서버의 신원을 확인하고, 해당 서버의 진위 여부를 검증할 수 있게 하는 것이다. 이를 통해 중간자 공격을 방지하고 안전한 키 교환의 기반을 마련한다.

인증서는 여러 필드로 구성된다. 주요 필드는 다음과 같다.

클라이언트는 접속 시 서버로부터 이 인증서를 받아 검증 과정을 수행한다. 먼저 인증서의 유효 기간을 확인하고, 클라이언트가 내장한 신뢰할 수 있는 루트 인증서 저장소를 통해 인증서 서명 체인을 추적하여 발급 CA의 신뢰성을 검증한다. 최종적으로 CA의 공개키로 인증서의 디지털 서명을 검증함으로써, 해당 인증서가 위변조되지 않았고 명시된 서버가 실제 그 소유자임을 보장받는다.

인증서는 도메인 이름을 검증하는 수준에 따라 DV 인증서, OV 인증서, EV 인증서 등으로 분류된다. 가장 일반적인 DV 인증서는 도메인 소유권만을 확인하는 반면, EV 인증서는 법적 실체에 대한 엄격한 검증을 거쳐 발급되며, 브라우저 주소창에 조직 이름을 표시하는 등의 시각적 차이가 있다.

CA는 신뢰할 수 있는 제3자로서, 웹사이트나 서비스의 신원을 확인하고 디지털 인증서를 발급하는 기관이다. 이 기관들은 자신의 루트 인증서를 주요 웹 브라우저와 운영체제에 미리 등록하여 신뢰의 기반을 형성한다. 사용자가 HTTPS 웹사이트에 접속하면, 서버는 CA가 서명한 인증서를 제시한다. 브라우저는 내장된 신뢰할 수 있는 루트 인증서 목록을 사용해 해당 서버 인증서의 서명 체인을 검증한다. 이 검증이 성공해야만 통신이 계속된다.

신뢰 체인은 루트 인증서, 중간 인증서, 서버 인증서로 구성된 계층 구조이다. 루트 CA는 보안이 극도로 강화된 오프라인 환경에 보관되며, 직접 서버 인증서를 발급하기보다는 중간 CA 인증서를 발급한다. 중간 CA가 실제 서버 인증서 발급 업무를 수행한다. 이 다층 구조는 루트 키의 노출 위험을 줄이고, 인증서 발급 및 폐지 관리의 유연성을 높인다. 체인의 각 단계에서 상위 인증서의 개인키로 하위 인증서에 서명하여 위조를 방지한다.

신뢰 체인 검증은 최종 서버 인증서부터 시작하여 루트 인증서까지 거슬러 올라간다. 브라우저는 서버 인증서의 발급자 필드를 확인하고, 해당 발급자(중간 CA)의 인증서를 필요로 한다. 이 인증서는 서버에 의해 전송되거나 브라우저 캐시에서 조회된다. 중간 인증서의 서명을 루트 인증서의 공개키로 검증하고, 이 과정을 신뢰할 수 있는 루트에 도달할 때까지 반복한다. 체인 상의 모든 인증서가 유효하고(만료되지 않았고, 폐지되지 않았으며, 도메인과 일치함) 서명이 검증되면 연결은 신뢰할 수 있는 것으로 판단된다.

HTTPS는 HTTP 프로토콜에 SSL/TLS 암호화 계층을 적용한 보안 통신 방식이다. 기본적인 동작 흐름은 클라이언트(웹 브라우저)가 서버에 접속 요청을 보내면, 핸드셰이크 프로토콜 과정을 통해 암호화 통신 채널을 수립하는 것으로 시작한다. 이 과정에서 서버는 디지털 인증서를 클라이언트에 제공하고, 클라이언트는 이를 검증하여 서버의 신원을 확인한다. 이후 협상된 세션 키를 사용하여 실제 HTTP 요청과 응답 데이터를 암호화하여 주고받는다.

구체적인 데이터 흐름은 다음과 같다. 사용자가 https://로 시작하는 URL에 접근하면, 먼저 TLS 핸드셰이크가 완료되어 암호화된 TLS 레코드 층의 터널이 형성된다. 이후의 모든 HTTP 메시지(헤더와 본문 포함)는 이 터널을 통해 암호화된 상태로 전송된다. 예를 들어, 로그인 시 입력한 비밀번호나 결제 정보 같은 민감한 데이터는 네트워크 상에서 가로채더라도 복호화되지 않는 암호문 형태로 이동한다.

HTTPS 연결의 보안 속성은 다음과 같은 세 가지 핵심 요소를 제공한다.

이 방식은 표준 HTTP의 동작을 변경하지 않으면서 통신 경로의 보안만을 강화한다. 따라서 기존의 HTTP 기반 애플리케이션 로직은 그대로 유지한 채, 전송 계층에서의 보안을 보장받을 수 있다. 최근에는 웹의 기본 보안 모델로 자리 잡아, 대부분의 현대 웹 브라우저는 HTTPS 연결이 아닌 사이트에 대해 보안 경고를 표시한다.

HTTPS는 기본적으로 TCP 포트 443을 사용하여 통신한다. 이는 HTTP가 사용하는 포트 80과 구분되는 표준 포트 번호이다. 웹 브라우저가 https:// 프로토콜 스킴으로 접속을 시도하면, 서버의 443번 포트로 연결을 시도하는 것이 기본 동작 방식이다.

서버 설정에서는 특정 가상 호스트에 대해 포트 443에서 SSL/TLS 암호화 연결을 수신하도록 구성해야 한다. 주요 웹 서버 소프트웨어의 기본 설정 파일 예시는 다음과 같다.

포트 443 외에 다른 포트를 사용하는 것도 기술적으로 가능하지만, 이는 표준이 아니며 방화벽이나 클라이언트 측에서 예상치 못한 문제를 일으킬 수 있다. 또한, HTTP/2 및 HTTP/3 프로토콜은 일반적으로 암호화된 연결을 전제로 하며, 대부분의 구현에서 HTTPS를 통해서만 동작한다.

기본 설정에는 강력한 암호화 스위트 선택, 전송 계층 보안 프로토콜의 안전한 버전(예: TLS 1.2 또는 TLS 1.3) 활성화, 그리고 공개 키 인증서의 정기적인 갱신 관리가 포함된다. 또한, HTTP Strict Transport Security 헤더를 설정하여 클라이언트가 향후 모든 연결을 강제로 HTTPS로 시도하도록 하는 것이 보안을 강화하는 일반적인 관행이다.

TLS 1.2와 TLS 1.3은 SSL/TLS 프로토콜의 주요 버전으로, 보안성과 성능 면에서 상당한 차이를 보인다. TLS 1.3은 2018년에 공식 표준으로 확정되었으며, 설계 철학 자체가 TLS 1.2와 구분된다. 가장 핵심적인 목표는 보안을 강화하면서도 연결 설정 속도를 높이는 것이었다.

가장 두드러진 차이는 핸드셰이크 과정의 단순화와 가속화이다. TLS 1.2의 핸드셰이크는 일반적으로 두 번의 왕복(RTT)이 필요했지만, TLS 1.3에서는 최초 연결 시에도 한 번의 왕복(1-RTT)으로 기본 연결을 완료할 수 있다. 또한, 이전에 연결한 적이 있는 클라이언트의 경우 제로 RTT(0-RTT) 모드를 지원하여 데이터를 첫 번째 메시지부터 암호화하여 전송할 수 있다[5]. 이는 연결 지연 시간을 크게 줄여 웹 페이지 로딩 속도를 향상시킨다.

보안 측면에서는 오래되고 취약한 것으로 알려진 암호화 요소들을 대거 제거하였다. TLS 1.3에서는 RSA 키 교환, SHA-1 해시 함수, CBC 모드 암호화, 그리고 정적 DH(Diffie-Hellman) 등이 필수 지원 목록에서 제외되었다. 대신 모든 키 교환은 디피-헬먼(Diffie-Hellman) 방식의 변형인 ECDHE 또는 일반 DHE를 사용하도록 강제하여 전달 비밀성(Forward Secrecy)을 기본으로 보장한다. 또한 협상 가능한 암호화 스위트 목록이 크게 간소화되어 안전하지 않은 옵션을 제거하였다.

프로토콜 설계 자체도 더욱 간결해졌다. TLS 1.2에서는 협상을 위해 사용되던 불필요한 메시지와 확장 기능들이 정리되었고, 핸드셰이크가 끝나기 전부터 암호화된 데이터 전송이 시작될 수 있도록 변경되었다. 이러한 변화로 인해 TLS 1.3은 보안 강화와 성능 개선이라는 두 마리 토끼를 모두 잡은 것으로 평가받으며, 현대적인 웹과 애플리케이션 보안의 사실상의 표준으로 자리 잡고 있다.

암호화 스위트는 TLS 연결을 설정할 때 협상되는 특정 암호화 알고리즘과 키 교환 프로토콜, 해시 함수의 조합을 말한다. 이 조합은 통신의 기밀성, 무결성, 인증을 보장하는 데 사용된다. 하나의 암호화 스위트는 키 교환 방식, 대칭 암호화 알고리즘, 메시지 인증 코드(MAC) 알고리즘을 명시한다[6].

TLS 1.2에서는 클라이언트와 서버가 지원하는 스위트 목록을 교환한 후, 공통으로 지원하는 가장 강력한 스위트를 선택한다. 과거에는 RC4나 CBC 모드의 블록 암호와 결합된 MD5 또는 SHA-1 해시 함수를 사용하는 취약한 스위트가 널리 사용되었다. 시간이 지남에 따라 BEAST 공격, POODLE 공격과 같은 취약점이 발견되며 이러한 약한 조합은 점차 사용이 중단되었다.

TLS 1.3은 보안을 대폭 강화하기 위해 암호화 스위트의 수와 구성을 간소화했다. 안전하지 않은 것으로 알려진 모든 알고리즘을 제거하고, 키 교환과 인증을 분리하며, 반드시 전달 비밀성을 제공하는 키 교환 방식(예: DHE 또는 ECDHE)을 사용하도록 했다. 또한 대칭 암호화에 AES-GCM이나 ChaCha20-Poly1305 같은 현대적인 인증 암호화 방식을 필수로 채택하여 암호화와 무결성 검증을 단일 연산으로 처리한다.

중간자 공격(MITM, Man-in-the-Middle)은 통신 경로 상에 침입자가 개입하여 송수신자 사이의 통신을 가로채거나 조작하는 공격 방식이다. SSL/TLS의 주요 목적은 이러한 공격을 방어하여 통신의 기밀성과 무결성을 보장하는 것이다.

SSL/TLS는 공개키 암호화와 디지털 인증서를 기반으로 한 상호 인증을 통해 MITM 공격을 방어한다. 클라이언트(예: 웹 브라우저)는 서버가 제공하는 인증서를 검증한다. 이 인증서는 신뢰할 수 있는 인증 기관(CA)에 의해 서버의 공개키와 신원 정보가 서명되어 있어 위변조가 어렵다. 클라이언트는 내장된 CA 목록을 통해 인증서의 유효성과 서명 체인을 확인한다. 이를 통해 공격자가 자신의 인증서를 위조하여 제공하는 것을 방지할 수 있다.

핸드셰이크 과정에서 협상된 세션 키는 서버의 공개키로 암호화되어 전송되거나, 디피-헬만 키 교환과 같은 방식을 통해 안전하게 공유된다. 이로 인해 통신이 시작된 후의 모든 데이터는 이 세션 키로 암호화되며, 중간에서 패킷을 가로채도 내용을 복호화할 수 없다. 또한 메시지 인증 코드(MAC)나 AEAD 암호화 모드를 사용하여 데이터 무결성을 보호하여 전송 중 변조를 탐지할 수 있다.

최신 TLS 1.3 프로토콜은 보안을 더욱 강화하여 과거에 취약했던 암호화 스위트와 키 교환 방식을 제거하고, 핸드셰이크 과정을 단축하여 공격 표면을 줄였다. 또한 HSTS(HTTP Strict Transport Security)와 같은 확장 메커니즘은 클라이언트가 항상 HTTPS를 사용하도록 강제하여 SSL 스트리핑 공격[7]을 효과적으로 차단한다.

TLS 1.0과 SSL 3.0은 설계상의 결함과 오래된 암호화 기술로 인해 현재는 안전하지 않은 것으로 간주된다. 특히 POODLE 공격은 SSL 3.0의 취약점을 이용하여 암호화된 통신을 해독할 수 있게 한다[8]. 이로 인해 주요 브라우저와 서버에서는 이러한 구버전 프로토콜 사용을 중단했다.

특정 암호화 알고리즘 조합인 암호화 스위트도 보안 위협을 초래할 수 있다. RC4 스트림 암호는 편향성을 가지고 있어 공격자가 통계적 분석을 통해 평문을 복구할 수 있는 가능성이 있다. 또한 CBC 모드를 사용하는 블록 암호에서 패딩 오라클 공격이 발생할 수 있다. 다음은 대표적인 취약한 암호화 스위트의 예시이다.

TLS 1.3은 이러한 역사적 취약점을 근본적으로 해결하기 위해 설계되었다. 이전 버전과의 하위 호환성을 포기하고, 안전하지 않은 것으로 알려진 알고리즘과 기능(예: 압축, 정적 RSA, 정적 DH 키 교환)을 완전히 제거했다. TLS 1.3에서는 전방위 보안을 제공하는 AEAD 암호 스위트만을 지원한다.

서버와 클라이언트는 최신 프로토콜 버전(TLS 1.2 이상, 바람직하게는 TLS 1.3)을 사용하고, 강력한 암호화 스위트만을 활성화하도록 구성해야 한다. 정기적인 보안 감사와 구성 검토를 통해 오래되거나 취약한 프로토콜과 알고리즘이 사용되지 않도록 관리하는 것이 중요하다.

웹 서버에서 SSL/TLS를 설정하는 과정은 사용하는 서버 소프트웨어에 따라 다르지만, 공통적으로 인증서와 개인키를 서버에 설치하고 적절한 프로토콜과 암호화 스위트를 구성하는 작업을 포함한다. 가장 일반적인 웹 서버인 Apache HTTP Server와 Nginx를 기준으로 기본 설정 방법을 설명한다.

Apache 서버에서는 mod_ssl 모듈이 활성화되어 있어야 한다. 주요 설정은 httpd.conf 또는 가상 호스트 설정 파일 내 VirtualHost 블록에서 이루어진다. 핵심 지시어는 SSLEngine on으로 SSL/TLS를 활성화하며, SSLCertificateFile과 SSLCertificateKeyFile 지시어로 각각 공개 인증서 파일과 개인키 파일의 경로를 지정한다. 필요에 따라 중간 인증서 체인 파일은 SSLCertificateChainFile로 설정한다. Nginx의 경우, 서버 블록(server) 설정 내에서 listen 지시어에 ssl 매개변수를 추가하고, ssl_certificate와 ssl_certificate_key 지시어로 인증서와 개인키 파일의 경로를 명시한다.

보안 강화를 위해 프로토콜 버전과 암호화 스위트를 명시적으로 제한하는 것이 중요하다. 오래되고 안전하지 않은 SSL 2.0, 3.0 및 TLS 1.0, 1.1은 사용하지 않도록 비활성화하고, 최소한 TLS 1.2 이상만 허용하도록 설정한다. 또한 강력한 암호화 스위트만을 허용하는 목록을 구성해야 한다. 설정 후에는 온라인 검사 도구를 이용해 인증서가 올바르게 설치되었는지, 강력한 암호화를 사용하는지, 그리고 HTTP Strict Transport Security 같은 보안 헤더가 설정되었는지 확인하는 것이 좋다.

인증서 발급은 일반적으로 인증 기관(CA)을 통해 이루어진다. 먼저, 서버 관리자는 공개키와 서버 정보(도메인명, 조직명 등)를 포함한 인증서 서명 요청(CSR)을 생성한다. 이 CSR을 선택한 CA에 제출하면, CA는 해당 도메인의 소유권을 확인한 후 서버의 공개키에 자신의 개인키로 서명하여 디지털 인증서를 발급한다[9]. 발급받은 인증서(일반적으로 .crt 또는 .pem 확장자)와 해당 개인키를 웹 서버에 설치하면 HTTPS 연결이 가능해진다.

인증서에는 유효 기간이 명시되어 있어 정기적인 갱신이 필수적이다. 대부분의 CA는 만료되기 90일 전부터 갱신 절차를 시작할 수 있도록 한다. 갱신은 기존 인증서를 재발급받는 과정으로, 새로운 CSR을 생성할 수도 있고, 기존 키 페어를 재사용할 수도 있다. 갱신 시에는 도메인 소유권 재검증이 필요할 수 있다. 갱신된 인증서를 서버에 적용하기 위해서는 웹 서버 소프트웨어(예: Apache, Nginx)를 재시작하거나 설정을 다시 불러와야 한다.

인증서 발급 및 관리를 간소화하기 위해 Let's Encrypt와 같은 무료 자동화 CA가 널리 사용된다. 이들은 ACME 프로토콜을 사용하여 도메인 검증과 인증서 발급, 갱신을 완전히 자동화한다. 서버에 Certbot과 같은 ACME 클라이언트를 설치하면, 인증서 발급부터 웹 서버 설정 업데이트, 정기적 자동 갱신까지 모든 과정을 스크립트로 처리할 수 있다. 이는 인증서 만료로 인한 서비스 중단 위험을 크게 줄인다.