고급 스크래핑 엔지니어라면 이런 경험이 있을 것이다: 완벽한 TLS 핑거프린트, 세밀하게 조정된 User-Agent, 정교한 헤더 순서까지 갖췄는데도 서버가 403을 반환한다. HTML이 로드되기도 전에 차단당한다. 2026년 기준, 그 원인의 상당수는 HTTP/2 지문 추출에 있다. 프로토콜 수준에서 클라이언트가 브라우저가 아니라는 것이 드러나는 것이다. 이 글은 HTTP/2 지문 추출의 기술적 작동 원리부터, 일관된 브라우저 지문을 구현하는 실전 코드까지 다룬다.
핵심은 간단하다: TLS 핑거프린트(JA3/JA4)가 Chrome 148을 주장하면서도, HTTP/2 SETTINGS 프레임의 HEADER_TABLE_SIZE가 4096을 보내면 서버는 즉시 max bot score를 부여한다. httpx, aiohttp, Go의 net/http 클라이언트가 정확히 이런 불일치를 일으킨다. 이 글은 그 원리를 분해하고, RFC 9113에 정의된 HTTP/2 프레임 구조를 기반으로 어떤 시그널이 탐지에 사용되는지 설명한 뒤, curl_cffi와 ProxyHat 레지덴셜 프록시를 조합해 일관된 Chrome h2 지문을 내보내는 방법을 코드로 보여준다.
HTTP/2 지문 추출이란 무엇인가: 프로토콜 수준의 식별
HTTP/2 지문 추출은 클라이언트가 서버와 HTTP/2 연결을 설정할 때 보내는 프레임들의 구조적 특징을 수집하여 클라이언트를 식별하는 기술이다. RFC 9113에 정의된 대로, HTTP/2 연결은 항상 클라이언트가 보내는 SETTINGS 프레임으로 시작하며, 이 프레임의 필드 값 조합이 클라이언트별로 고유한 패턴을 형성한다.
SETTINGS 프레임: 핵심 지문 필드
HTTP/2 클라이언트는 연결 시작 시 다음 파라미터들을 SETTINGS 프레임에 담아 전송한다:
- HEADER_TABLE_SIZE (0x1): HPACK 동적 헤더 테이블 크기. Chrome은
65536을, httpx는4096을 기본값으로 사용한다. 이 값 하나로 Chrome과 Python HTTP 클라이언트를 구분할 수 있다. - ENABLE_PUSH (0x2): 서버 푸시 허용 여부. Chrome 124+는
0(비활성화)을 보낸다. 일부 Python 클라이언트는 이 값을 아예 보내지 않는다. - MAX_CONCURRENT_STREAMS (0x3): 동시 스트림 최대 수. Chrome은
1000을, Go net/http는250을, httpx는 이 값을 생략한다. - INITIAL_WINDOW_SIZE (0x4): 플로우 제어 초기 윈도우 크기. Chrome은
6291456(6MB)을, httpx는65535(64KB)를 사용한다. 100배 차이가 난다. - MAX_FRAME_SIZE (0x5): 최대 프레임 크기. Chrome은
16384를 기본값으로 보낸다. - MAX_HEADER_LIST_SIZE (0x6): 헤더 리스트 최대 크기. Chrome은 보통
262144(256KB)를 설정한다.
이 값들의 순서와 존재 여부 자체가 지문이 된다. 예를 들어, Chrome은 HEADER_TABLE_SIZE, ENABLE_PUSH, MAX_CONCURRENT_STREAMS, INITIAL_WINDOW_SIZE, MAX_FRAME_SIZE 순서로 필드를 배치하지만, httpx는 HEADER_TABLE_SIZE, MAX_CONCURRENT_STREAMS, INITIAL_WINDOW_SIZE, MAX_HEADER_LIST_SIZE 순서로 보낸다. 필드의 조합뿐 아니라 순서까지 식별에 사용된다.
WINDOW_UPDATE 프레임
연결 수준 WINDOW_UPDATE 프레임은 플로우 제어 윈도우를 증가시킨다. Chrome은 SETTINGS 직후에 15663105 값으로 WINDOW_UPDATE를 보내 연결 윈도우를 15728640(15MB)로 확장한다. httpx는 이 프레임을 보내지 않거나 다른 값을 사용한다. 이 프레임의 존재 여부와 값이 또 하나의 식별 시그널이다.
스트림 우선순위 (Stream Priority)
HTTP/2에서 각 스트림은 가중치(weight)와 의존성(dependency)을 가진다. Chrome은 첫 번째 요청 스트림에 weight: 256, depends_on: 0, exclusive: false를 설정한다. 반면 대부분의 HTTP 라이브러리는 우선순위를 생략하거나 기본값(weight: 16)을 보낸다. RFC 9113은 우선순위 힌트를 선택적으로 처리하지만, JA4H 스펙에서는 이 값이 지문의 일부로 수집된다.
의사 헤더 순서 (Pseudo-header Order)
HTTP/2 요청은 :method, :authority, :scheme, :path 네 개의 의사 헤더로 시작한다. 그 순서는 클라이언트마다 다르다:
- Chrome:
m, a, s, p(:method, :authority, :scheme, :path) - Firefox:
m, p, a, s - Safari:
m, a, s, p(Chrome과 동일하지만 SETTINGS 값으로 구분) - httpx/hyper:
m, p, s, a(다름!)
이 의사 헤더 순서는 JA4H 지문의 h 섹션에 인코딩된다. m,a,s,p가 아니면 Chrome이 아니다.
아카마이 컴팩트 h2 지문 문자열
Akamai는 HTTP/2 클라이언트 식별을 위해 컴팩트한 지문 문자열을 사용한다. 이 문자열은 SETTINGS 값들을 순서대로 나열하고, WINDOW_UPDATE 값과 priority 정보를 이어 붙인 형태다. 예를 들어 Chrome 124의 아카마이 h2 지문은 대략 다음과 같다:
1:65536;2:0;3:1000;4:6291456;6:262144|15663105|0|m,a,s,p여기서 세미콜론으로 구분된 설정 ID:값 쌍이 SETTINGS 프레임이고, 파이프 뒤의 15663105가 WINDOW_UPDATE 값, 0이 우선순위 의존성, 마지막 m,a,s,p가 의사 헤더 순서다. Akamai는 이 문자열을 데이터베이스의 알려진 브라우저 지문과 비교하여, 일치하지 않으면 bot score를 즉시 상향한다.
JA4H 지문
FoxIO의 JA4H는 HTTP 클라이언트 식별을 위한 표준화된 지문 포맷이다. JA4H는 네 개의 섹션으로 구성된다:
http_version+number_of_headers+number_of_cookies- 헤더 이름 정렬 해시
- 의사 헤더 순서 + 단일 헤더 값 해시들
- 쿠키 이름 해시
JA4H의 핵심은 의사 헤더 순서를 masp, mpas 등 4글자 코드로 인코딩한다는 점이다. Chrome의 masp와 httpx의 mpsa는 명확히 다르며, 서버 측에서 단일 비교 연산으로 구분할 수 있다.
TLS(JA3/JA4)와 HTTP/2 지문의 불일치: 왜 max bot score가 부여되는가
2026년의 anti-bot 시스템은 TLS 지문과 HTTP/2 지문을 교차 검증한다. TLS ClientHello가 Chrome 148의 JA4 해시를 보여주는데, HTTP/2 SETTINGS 프레임의 HEADER_TABLE_SIZE가 4096이라면, 서버는 다음과 같이 추론한다:
- TLS 레이어에서 Chrome을 흉내냈다 (JA4 스푸핑).
- 하지만 HTTP/2 레이어는 스푸핑하지 않았다 (httpx/hyper 기본값 노출).
- 따라서 이 클라이언트는 자동화 도구이며, 의도적으로 브라우저를 위장하려 시도했다.
이 추론 결과는 단순한 '브라우저 아님' 판정보다 훨씬 위험하다. 의도적인 위장 시도로 분류되기 때문에, bot score는 즉시 최대치에 도달한다. Cloudflare, Akamai, Datadome 모두 이 교차 검증 로직을 사용한다.
구체적인 예를 보자. httpx의 기본 HTTP/2 설정은 다음과 같다:
HEADER_TABLE_SIZE: 4096 (Chrome: 65536)INITIAL_WINDOW_SIZE: 65535 (Chrome: 6291456)MAX_CONCURRENT_STREAMS: 미설정 (Chrome: 1000)WINDOW_UPDATE: 미전송 (Chrome: 15663105)- 의사 헤더 순서:
m, p, s, a(Chrome:m, a, s, p)
이 값들 중 단 하나만 틀려도 식별된다. httpx는 다섯 개 전부 틀리다. curl의 HTTP/2 구현(hyper 기반)도 마찬가지로 Chrome과 다른 SETTINGS 값을 보낸다. Node.js의 http2 모듈은 HEADER_TABLE_SIZE를 4096으로, MAX_CONCURRENT_STREAMS를 100으로 설정한다. Go의 net/http는 INITIAL_WINDOW_SIZE를 4194304(4MB)로 보내는데, 이는 Chrome의 6291456(6MB)와 다르다.
클라이언트별 HTTP/2 지문 비교
| 클라이언트 | HEADER_TABLE_SIZE | INITIAL_WINDOW_SIZE | WINDOW_UPDATE | 의사 헤더 순서 | Chrome 일치도 |
|---|---|---|---|---|---|
| Chrome 148 | 65536 | 6291456 | 15663105 | m,a,s,p | 100% |
| Firefox 128 | 65536 | 131072 | 12517377 | m,p,a,s | ~20% |
| httpx (Python) | 4096 | 65535 | 미전송 | m,p,s,a | 0% |
| Go net/http | 4096 | 4194304 | 12517377 | m,p,a,s | ~10% |
| Node.js http2 | 4096 | 33554432 | 미전송 | m,a,s,p | ~15% |
| curl (hyper) | 4096 | 2147483647 | 미전송 | m,p,a,s | 0% |
이 표에서 알 수 있듯, curl조차 Chrome과 완전히 일치하지 않는다. curl_cffi는 예외적으로, curl의 HTTP/2 스택을 BoringSSL과 함께 컴파일하여 Chrome의 TLS 및 HTTP/2 프레임을 정확히 재현한다. 이것이 curl_cffi가 2026년 스크래핑 엔지니어 사이에서 사실상 표준으로 자리잡은 이유다.
HTTP/3 (QUIC) 지문 추출: 다음 전선
HTTP/3는 QUIC 위에서 동작하며, TLS 1.3 핸드셰이크가 QUIC 패킷 안에 캡슐화된다. HTTP/3의 SETTINGS 프레임은 HTTP/2와 유사한 필드를 사용하지만, 전송 계층이 UDP 기반이라 추가 식별 시그널이 존재한다:
- QUIC 초기 패킷 크기: Chrome은 첫 QUIC 패킷에 약
1200바이트를 보낸다. - 연결 마이그레이션 동작: 클라이언트가 IP 변경 시 새 연결 ID를 사용하는 패턴.
- 혼잡 제어 알고리즘: Chrome은 BBR v2를, 대부분의 QUIC 라이브러리는 CUBIC를 사용한다. 패킷 타이밍 분석으로 구분 가능하다.
HTTP/3 지문 추출은 아직 HTTP/2만큼 보편화되지 않았지만, Cloudflare와 Akamai는 이미 QUIC 레벨의 클라이언트 식별을 프로덕션에 적용하고 있다. 2026년 기준, HTTP/3를 지원하는 스크래핑 클라이언트는 극히 제한적이므로, HTTP/3를 사용하는 클라이언트 자체가 의심스러운 시그널이 될 수 있다.
왜 프로토콜 스푸핑만으로는 부족한가: IP 평판의 역할
완벽한 HTTP/2 지문을 보내더라도, IP 주소가 데이터센터 대역이면 anti-bot 시스템은 추가 가산점을 부여한다. 프로토콜 지문과 IP 평판은 독립적으로 평가되며, 둘 중 하나라도 의심스러우면 전체 점수가 상향한다.
구체적인 시나리오를 보자:
- TLS 지문: Chrome 148 일치 ✓
- HTTP/2 SETTINGS: Chrome 일치 ✓
- 의사 헤더 순서:
m,a,s,p일치 ✓ - IP 주소: AWS
us-east-1대역 (AS14618) ✗
이 경우, 세 개의 프로토콜 시그널이 모두 일치해도, IP 평판 점수가 전체 bot score를 임계치 이상으로 끌어올린다. Cloudflare는 IP ASN을 데이터센터/클라우드/레지덴셜로 분류하며, 데이터센터 ASN에서 오는 요청은 기본적으로 10점 이상의 bot score를 받는다. 이는 프로토콜 지문이 완벽해도 무의미하다는 뜻이다.
따라서 레지덴셜 프록시는 프로토콜 스푸핑의 보완재가 아니라 필수 전제조건이다. 레지덴셜 IP는 ISP 대역에서 할당되며, anti-bot 시스템은 이를 '일반 사용자'로 분류한다. 프로토콜 지문 + 레지덴셜 IP 조합이 되어야 비로소 전체 bot score가 임계치 이하로 유지된다.
ProxyHat의 레지덴셜 프록시 네트워크는 전 세계 190개국 이상의 ISP 대역 IP를 제공한다. 프리패스 요금제는 트래픽 기반 과금으로, 스크래핑 부하에 맞춰 유연하게 확장할 수 있다. 모바일 프록시 옵션도 제공되어, 모바일 네트워크 ASN(예: T-Mobile, Verizon)에서 오는 요청으로 더 높은 신뢰도를 확보할 수 있다.
실전 구현: curl_cffi와 ProxyHat로 일관된 Chrome h2 지문 만들기
이제 실전 코드를 보자. 목표는 Chrome 148의 TLS 지문(JA4)과 HTTP/2 지문(SETTINGS, WINDOW_UPDATE, 의사 헤더 순서)을 동시에 재현하면서, ProxyHat 레지덴셜 프록시를 통해 ISP 대역 IP로 요청을 보내는 것이다.
방법 1: curl_cffi + ProxyHat (Python)
curl_cffi는 curl을 BoringSSL과 함께 빌드하여 Chrome의 TLS 및 HTTP/2 스택을 정확히 재현한다. impersonate 파라미터로 Chrome 버전을 지정하면, 해당 버전의 전체 프로토콜 지문이 자동으로 적용된다.
from curl_cffi import requests
# ProxyHat 레지덴셜 프록시 - 미국 IP
proxy_url = "http://user-country-US:your_password@gate.proxyhat.com:8080"
session = requests.Session(impersonate="chrome124")
response = session.get(
"https://tls.peet.ws/api/all",
proxies={"http": proxy_url, "https": proxy_url},
timeout=30
)
print(response.status_code)
print(response.json())
이 코드는 다음을 동시에 달성한다:
- TLS: Chrome 124의 ClientHello를 전송 (JA4 =
t13d1516h2_8daaf61527f1_b0da82dd1658) - HTTP/2 SETTINGS:
HEADER_TABLE_SIZE=65536, ENABLE_PUSH=0, MAX_CONCURRENT_STREAMS=1000, INITIAL_WINDOW_SIZE=6291456 - WINDOW_UPDATE:
15663105값 전송 - 의사 헤더 순서:
m,a,s,p - IP: 미국 ISP 대역 레지덴셜 IP
방법 2: 스티키 세션 + 지역 타겟팅
세션 기반 스크래핑이 필요한 경우, ProxyHat의 스티키 세션 기능을 사용하여 동일 IP를 유지할 수 있다. 사용자명에 session 플래그를 추가하면 된다:
from curl_cffi import requests
# 스티키 세션 + 도시 수준 지역 타겟팅
proxy_url = "http://user-country-US-city-newyork-session-r2d2:your_password@gate.proxyhat.com:8080"
session = requests.Session(impersonate="chrome124")
# 첫 번째 요청 - 로그인 페이지
r1 = session.get(
"https://example.com/login",
proxies={"http": proxy_url, "https": proxy_url},
timeout=30
)
# 두 번째 요청 - 같은 IP에서 폼 제출
r2 = session.post(
"https://example.com/login",
data={"username": "test", "password": "test"},
proxies={"http": proxy_url, "https": proxy_url},
timeout=30
)
방법 3: 실제 브라우저 + ProxyHat (Playwright)
가장 강력한 접근법은 실제 브라우저를 사용하는 것이다. Playwright는 Chromium을 직접 구동하므로, TLS, HTTP/2, JavaScript 환경, 캔버스 핑거프린트까지 모두 진짜 Chrome과 동일하다. ProxyHat 프록시를 브라우저에 직접 연결하면 된다:
from playwright.sync_api import sync_playwright
proxy_config = {
"server": "http://gate.proxyhat.com:8080",
"username": "user-country-US",
"password": "your_password"
}
with sync_playwright() as p:
browser = p.chromium.launch(
headless=True,
proxy=proxy_config
)
context = browser.new_context(
user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
"AppleWebKit/537.36 (KHTML, like Gecko) "
"Chrome/148.0.0.0 Safari/537.36"
)
page = context.new_page()
page.goto("https://example.com", timeout=30000)
content = page.content()
browser.close()
이 방식은 HTTP/2 지문뿐 아니라 JavaScript 실행 환경, 캔버스/WebGL 핑거프린트, WebRTC IP 누출 방지까지 모두 해결한다. 단, 리소스 사용량이 curl_cffi 대비 약 10배 높으므로, 대규모 스크래핑에는 curl_cffi를 우선 사용하고 JavaScript 렌더링이 필요한 경우에만 Playwright를 사용하는 하이브리드 전략이 권장된다.
방법 4: Node.js에서 curl-impersonate 사용
Node.js 환경에서는 node-curl-impersonate 또는 cycletls 패키지를 사용할 수 있다:
const { Session } = require('node-curl-impersonate');
const proxy = 'http://user-country-DE:your_password@gate.proxyhat.com:8080';
const session = new Session({ impersonate: 'chrome124' });
session.get('https://tls.peet.ws/api/all', {
proxy: proxy,
timeout: 30000
}).then(res => {
console.log(res.status);
console.log(res.json());
});
흔한 실수와 엣지 케이스
1. User-Agent와 HTTP/2 지문의 불일치
User-Agent 헤더에 Chrome/148.0.0.0을 적어도, HTTP/2 SETTINGS가 Chrome 148이 아닌 값을 보내면 불일치가 발생한다. anti-bot 시스템은 User-Agent 문자열에서 브라우저 버전을 추출하고, 해당 버전의 알려진 HTTP/2 지문과 비교한다. impersonate="chrome124"를 사용하면 User-Agent도 Chrome 124로 자동 설정되므로, 수동으로 User-Agent를 덮어쓰지 않는 것이 좋다.
2. HTTP/1.1 폴백
일부 프록시는 HTTP/2를 지원하지 않고 HTTP/1.1로 폴백한다. 이 경우 HTTP/2 지문이 아예 전송되지 않으므로, Chrome User-Agent와 HTTP/1.1 사용의 불일치가 발생한다. ProxyHat의 HTTP 프록시 게이트웨이(gate.proxyhat.com:8080)는 HTTP/2를 지원하는 CONNECT 터널을 사용하므로, 클라이언트-서버 간 HTTP/2 연결이 그대로 유지된다.
3. ALPN 협상 누락
TLS ALPN(Application-Layer Protocol Negotiation)에서 h2를 제공하지 않으면, 서버는 HTTP/1.1로 응답한다. curl_cffi는 ALPN에 h2,http/1.1을 자동으로 포함하지만, 일부 Python HTTP 클라이언트는 ALPN을 설정하지 않는다. ALPN이 없으면 HTTP/2 지문 추출 자체가 불가능해지며, 대신 HTTP/1.1 헤더 순서 분석으로 대체된다.
4. SOCKS5 프록시 사용 시 HTTP/2 유지
SOCKS5 프록시는 전송 계층만 터널링하므로 HTTP/2 프레임이 그대로 전달된다. ProxyHat의 SOCKS5 엔드포인트(gate.proxyhat.com:1080)를 사용할 수도 있다:
from curl_cffi import requests
proxy_url = "socks5://user-country-US:your_password@gate.proxyhat.com:1080"
session = requests.Session(impersonate="chrome124")
response = session.get(
"https://tls.peet.ws/api/all",
proxies={"http": proxy_url, "https": proxy_url},
timeout=30
)
5. 동시 요청 수와 MAX_CONCURRENT_STREAMS
Chrome은 MAX_CONCURRENT_STREAMS=1000을 설정하지만, 실제로는 단일 연결에서 동시에 6개 정도의 스트림을 사용한다. curl_cffi로 1500 requests/sec를 보낼 때, 각 요청이 새 연결을 열면 anti-bot 시스템이 비정상적 패턴으로 간주할 수 있다. 연결 풀을 적절히 관리하여, 단일 연결에서 과도한 스트림을 열지 않도록 해야 한다.
적절한 사용과 법적 고려사항
이 글에서 다룬 기술은 합법적인 용도로만 사용해야 한다. 구체적으로:
- 승인된 보안 연구: 자신이 소유하거나 승인받은 시스템에 대한 침투 테스트, 버그 바운티 프로그램.
- 공개 데이터 수집: robots.txt를 준수하고, 서비스 약관(ToS)을 위반하지 않는 범위의 공개 웹 페이지 스크래핑.
- SERP 모니터링: 검색 엔진 순위 추적을 위한 SERP 스크래핑 — 검색 엔진의 API 약관을 준수.
- 가격 모니터링: 경쟁사 공개 가격 페이지의 정기적 수집 — 웹 스크래핑 사용 사례 참조.
주의해야 할 법적 프레임워크:
- CFAA (Computer Fraud and Abuse Act): 미국에서 인증 시스템을 우회하여 시스템에 접근하는 것은 연방 범죄다. HTTP/2 지문 스푸핑이 '인증 우회'로 해석될 수 있는지는 맥락에 따라 다르며, 승인받지 않은 시스템에 대한 접근은 명백히 위반이다.
- GDPR (General Data Protection Regulation): EU에서 개인 데이터를 포함한 페이지를 스크래핑하는 경우, GDPR Article 6의 적법한 근거가 필요하다. 공개 페이지라도 개인 데이터가 포함되면 처리 근거가 요구된다.
- CCPA (California Consumer Privacy Act): 캘리포니아 주민의 개인 데이터를 수집하는 경우, 판매/공유 여부에 따른 통지 의무가 발생한다.
프록시 사용 자체는 불법이 아니지만, 프록시를 통한 접근이 대상 사이트의 ToS를 위반하는 경우, 계약법 위반 소송의 대상이 될 수 있다. 항상 대상 사이트의 robots.txt와 ToS를 확인하고, 불확실한 경우 법률 자문을 구해야 한다. ProxyHat 문서에서도 수용 가능한 사용 정책을 확인할 수 있다.
핵심 요약 (Key Takeaways)
HTTP/2 지문 추출은 2026년 anti-bot의 핵심 계층이다. TLS 지문만 맞추는 것으로는 부족하며, HTTP/2 SETTINGS, WINDOW_UPDATE, 의사 헤더 순서까지 일치해야 한다.
- SETTINGS 프레임이 가장 중요한 식별 시그널이다.
HEADER_TABLE_SIZE=4096은 Python HTTP 클라이언트의 즉각적인 탐지 원인이 된다. Chrome은65536을 사용한다. - TLS와 HTTP/2 지문은 교차 검증된다. JA4가 Chrome을 주장하는데 HTTP/2가 httpx 패턴이면, 의도적 스푸핑으로 간주되어 bot score가 최대치에 도달한다.
- 프로토콜 스푸핑만으로는 IP 평판을 넘을 수 없다. 데이터센터 IP에서 완벽한 Chrome 지문을 보내도, ASN 기반 bot score가 임계치를 넘긴다. 레지덴셜 프록시는 선택이 아닌 필수다.
- curl_cffi + ProxyHat 레지덴셜이 2026년의 실전 조합이다.
impersonate="chrome124"로 TLS+HTTP/2 지문을 동시에 재현하고,gate.proxyhat.com:8080으로 ISP 대역 IP를 확보한다. - JavaScript 렌더링이 필요한 경우 Playwright + ProxyHat을 사용한다. 실제 Chromium이 모든 핑거프린트 레이어를 자연스럽게 처리한다.
- 모든 접근은 승인된 보안 연구 또는 공개 데이터 수집 범위 내에서 수행해야 한다. CFAA, GDPR, CCPA를 포함한 법적 프레임워크를 준수하라.
프로토콜 수준의 탐지는 더 정교해질 것이고, HTTP/3 지문 추출이 보편화되면 추가 레이어의 일치가 필요할 것이다. 지금은 curl_cffi + 레지덴셜 프록시 조합으로 충분하지만, 지속적으로 대상 사이트의 탐지 로직 변화를 모니터링해야 한다. ProxyHat 위치 페이지에서 필요한 지역의 IP 가용성을 확인하고, 요금제에서 트래픽 요구사항에 맞는 플랜을 선택할 수 있다.
