부록 · EBS gp2·gp3 fio 실측은 gp3 선택을 어디까지 뒷받침하는가
100 GiB gp2에서 짧은 부하 시험만 하면 버스트 소진 뒤의 성능을 놓칠 수 있습니다. atomai의 EBS gp2 vs gp3 실측 벤치마크는 m5.xlarge 노드에 gp2와 gp3를 붙여 각각 fio로 측정했습니다. gp2는 2,700초 실행 중 약 33분이 지난 뒤 3,000 IOPS에서 300 IOPS로 내려갔습니다. 별도로 600초 측정한 gp3는 3,000 IOPS 근처를 유지했습니다.
이 기록은 02 hot 스토리지의 gp3 기준 성능과 gp2 버스트 설명에 연결됩니다. 실제 HyperDX 구성에 적용하려면 볼륨 크기, 노드의 EBS 한도, I/O 형태를 함께 봐야 합니다. 아래 수치는 원문이 보고한 단일 볼륨·단일 실행 결과이며 별도로 재측정하지 않았습니다.
근거 표기 — ✓ 원문 직접 확인 · Ⓥ 벤더·저자 주장 · Ⓑ 벤치마크 수치 · ≈ 눈대중·역산 · Σ 여러 사실을 이은 종합 추론 · ? 미확인. 각 절 끝의 ‘근거와 측정 조건’에 수치와 조건을 모았습니다.
1. 원문이 잰 워크로드와 조건
같은 m5.xlarge 노드에서 100 GiB gp2와 gp3를 번갈아 측정했습니다. 두 볼륨이 인스턴스의 EBS 한도를 나눠 쓰므로 부하를 겹치지 않았다고 원문은 설명합니다. 모든 측정은 페이지 캐시를 우회하는 direct I/O이며 테스트 파일은 8 GiB입니다.
| 부하 | 큐 깊이 | 실행 시간 |
|---|---|---|
| 4k 랜덤 읽기 | 32 | gp3 600초, gp2 2,700초 |
| 4k 랜덤 쓰기 | 32 | 120초 |
| 4k 랜덤 읽기 | 1 | 60초 |
| 1 MiB 순차 읽기·쓰기 | 8 | 60초 |
gp2의 기준 성능은 용량에 비례해 100 GiB에서는 300 IOPS입니다. 따라서 이 실험의 버스트 소진 결과는 기준 성능이 3,000 IOPS보다 낮은 gp2에 해당합니다. 단일 실행이어서 절대 수치의 편차를 평가할 수 없고, 원문도 실제 DB 캐시를 포함한 성능보다 크레딧 소진에 따른 변화를 읽도록 설명합니다.
근거와 측정 조건
| 항목 | 값 | 근거 |
|---|---|---|
| 환경 | Amazon EKS, Kubernetes 1.36, ap-northeast-2, EBS CSI 드라이버, fio 3.36(alpine:3.20 이미지), libaio 엔진 | ✓ |
| 노드 | m5.xlarge(4 vCPU, 16 GiB), Karpenter 프로비저닝. 원문이 적은 인스턴스 EBS 한도는 기준 6,000 IOPS·1,150 Mbps, 버스트 18,750 IOPS·4,750 Mbps | ✓ |
| 볼륨 | gp2 100 GiB 1개, gp3 100 GiB 1개. 기본 StorageClass 설정. 재실행용 매니페스트의 gp3는 3,000 IOPS·125 MiB/s | ✓ |
| 측정 순서 | 두 볼륨을 동시에 측정하지 않음. 테스트 파일 8 GiB를 1 MiB 순차 쓰기로 먼저 채움 | ✓ |
| 반복 횟수 | 단일 볼륨, 단일 실행. 원문이 다른 날·다른 볼륨에서는 IOPS의 편차가 있을 수 있다고 밝힘 | ✓ |
| 측정일 | 원문에 측정일 기재 없음. 문서의 마지막 업데이트는 2026-09-11 | ? |
| 사전 부하 이력 | 중단된 첫 시도가 같은 gp2 볼륨에 약 8분간 3,000 IOPS 부하를 줬고, 기록된 실행은 그로부터 약 13분 뒤. 원문은 이 이력이 절벽 시점에 미친 영향을 확인하지 못했다고 적음 | ✓ |
| 로그 처리 | IOPS 표는 두 로그의 첫 1초 샘플(둘 다 5,997)을 제외한 값. 원인은 원문도 미추적 | ✓ |
| 원문 스스로 둔 한계 | direct I/O라서 실제 DB의 캐시 효과는 반영되지 않음. 결과는 크레딧 모델의 모양이 본론이고 절대값은 아님 | ✓ |
출처: EBS gp2 vs gp3 실측 벤치마크 — 「테스트 환경」, 「fio 명령」, 「측정 1 — 4k 랜덤 읽기 45분: 크레딧 절벽」, 「해석 시 주의사항」
2. gp2 크레딧이 바닥나기 전과 후
랜덤 읽기에서 관측한 급락
큐 깊이 32의 4k 랜덤 읽기에서 크레딧이 남아 있던 gp2와 gp3는 평균 약 3,001 IOPS, 평균 지연 약 10.4 ms였습니다. gp2는 1,998초에 3,001 IOPS, 1,999초에 2,659 IOPS를 기록한 뒤 2,000초에 300 IOPS로 내려갔습니다. 이후 700초 동안 약 300 IOPS에 머물렀고 지연은 약 10 ms에서 약 106 ms로 늘었습니다.
원문은 이 지연을 동시 요청 수와 처리율로 설명합니다. 동시 I/O가 약 32일 때 초당 300개를 처리하면 32÷300, 약 106 ms가 됩니다. 큐 대기와 실제 처리 시간을 분리한 계산은 아닙니다. AWS 문서를 인용한 버스트 지속 시간 계산은 크레딧 버킷 540만을 초당 소진량 2,700으로 나눈 2,000초입니다. 기록상 전이는 1,999초부터 나타났습니다.
측정 전 부하 이력과 이 시점의 관계는 확인되지 않았습니다. 중단된 첫 시도가 같은 gp2에 부하를 줬으므로 단순 계산상 더 일찍 소진돼야 했지만 기록은 그렇지 않았습니다. 원문도 실측 시점을 일반화하지 말고 AWS 계산값을 계획 수치로 사용하도록 권합니다.
휴식 뒤 다시 사용한 크레딧
이어진 랜덤 쓰기에서는 gp2가 300 IOPS보다 높은 601 IOPS를 냈고 gp3는 3,025 IOPS였습니다. 원문은 gp2가 직전 120초 동안 쉬며 쌓은 36,000 크레딧을 쓰기 시험 중 다시 소모했다고 계산합니다. CloudWatch BurstBalance로 직접 확인한 결과는 아닙니다.
큐 깊이 1의 읽기 평균은 gp3 0.56 ms, gp2 1.65 ms였습니다. p50은 0.57 ms와 0.60 ms로 가까웠지만 p95는 gp3 0.63 ms, gp2 3.39 ms로 약 6배 차이가 났습니다. 이 실행에서는 스로틀의 영향이 중앙값보다 분포 꼬리에서 크게 나타났습니다.
근거와 측정 조건
| 주장 | 수치·조건 | 근거 |
|---|---|---|
| 큐 깊이 32 4k 랜덤 읽기, gp3 | 600초 평균 3,001 IOPS, 최소 2,991, 최대 3,004. 평균 지연 10.4 ms. fio 요약 기준 p99 12.9 ms | Ⓑ |
| 같은 조건, gp2 절벽 이전 | 0~1,999초 평균 3,001, 최소 2,997, 최대 3,005. 지연 약 10.4 ms | Ⓑ |
| 같은 조건, gp2 절벽 이후 | 2,000~2,700초 평균 300, 최소 297, 최대 304. 지연 약 106 ms. gp2 전체 구간의 p99는 109.6 ms | Ⓑ |
| 절벽 전이 | 1,998초 3,001 → 1,999초 2,659 → 2,000초 300 | Ⓑ |
| 절벽 시점의 이론값 | 100 GiB gp2 기준 3 IOPS/GiB × 100 = 300 IOPS, 버킷 5.4M, 5,400,000 ÷ (3,000 − 300) = 2,000초. 원문이 AWS 문서의 100 GiB 행과 같다고 서술 | Ⓥ ≈ |
| 절벽 시점 실측의 해석 한계 | 사전 부하 이력만 보면 절벽이 2,000초보다 이르게 나와야 하는데 실측은 1,999초. 원문은 원인을 확인하지 못했고 시점은 AWS 계산값을 계획 수치로 쓰라고 권함 | ✓ |
| 지연이 대기열 길이로 설명된다는 풀이 | 32 ÷ 300 ≈ 106.7 ms, 32 ÷ 3,000 ≈ 10.7 ms. 원문이 평균 동시 I/O 약 32일 때의 근사이며 큐 대기와 처리 시간을 나누지 않는다고 단서를 붙임 | Ⓥ ≈ |
| 4k 랜덤 쓰기, 큐 깊이 32, 120초 | gp3 3,025 IOPS·평균 10.3 ms·p99 12.0 ms. gp2 601 IOPS·평균 52.0 ms·p50 11.1 / p95 109.6 / p99 133.7 ms | Ⓑ |
| 쓰기에서 601이 나온 이유 | gp3 쓰기 중 gp2가 쉰 120초 × 300 = 36,000 크레딧을 120초에 소모하면 300 + 300 = 600 | Ⓥ ≈ |
| 4k 랜덤 읽기, 큐 깊이 1, 60초 | gp3 평균 0.564 ms·p50 0.569·p95 0.627·p99 0.872, 1,759 IOPS. gp2 평균 1.651 ms·p50 0.602·p95 3.391·p99 3.555, 603 IOPS | Ⓑ |
| 큐 깊이 1에서 gp2가 603 IOPS인 이유 | 60초 휴식에 쌓인 18,000 크레딧과 기준 300의 합이라는 원문의 계산 | Ⓥ ≈ |
| 크레딧 충전을 원문이 직접 확인했는지 | 읽기·쓰기 모두 CloudWatch BurstBalance 값은 제시하지 않음 | ? |
출처: EBS gp2 vs gp3 실측 벤치마크 — 「측정 1 — 4k 랜덤 읽기 45분: 크레딧 절벽」, 「측정 2 — 크레딧이 바닥난 뒤의 랜덤 쓰기: 3,025 vs 601 IOPS」, 「측정 3 — qd1 레이턴시: 낮은 동시성에서 본 분포」
3. gp3 기준 성능과 추가 프로비저닝 비용
gp3는 기본 3,000 IOPS·125 MiB/s이며 600초 읽기 동안 IOPS 변동은 1% 안쪽이었습니다. 1 MiB 순차 읽기·쓰기 결과는 각각 127.3·126.0 MiB/s로 설정한 125 MiB/s에 가까웠습니다. gp2도 130.3·128.9 MiB/s로 비슷했습니다. 원문은 170 GiB 이하 gp2의 처리량 상한이 128 MiB/s라 크레딧이 충분한 이 실행에서는 처리량 한도가 먼저 드러났다고 설명합니다.
원문이 2026-09에 조회한 서울 단가로 100 GiB의 월 비용은 gp3 $9.12, gp2 $11.40입니다. gp3의 기준을 넘는 성능은 IOPS와 처리량을 각각 추가합니다. 추가 IOPS당 월 $0.0057, MiB/s당 월 $0.0456을 적용하면 총 6,000 IOPS는 월 $26.22, 총 250 MiB/s는 월 $14.82입니다. 이 단가를 현재 가격표와 다시 대조하지는 않았습니다.
gp2에서 IOPS를 얻기 위해 용량을 늘리는 경우에는 비용 차이가 커집니다. 원문 계산에서 지속 3,000 IOPS를 위한 gp2 1,000 GiB는 월 $114.00, 같은 IOPS의 gp3 100 GiB는 $9.12로 12.5배 차이입니다. 두 구성은 저장 용량이 다르고, 원문은 gp2 1,000 GiB의 처리량도 250 MiB/s로 적었으므로 IOPS만 맞춘 비용 비교로 읽어야 합니다.
근거와 측정 조건
| 주장 | 수치·조건 | 근거 |
|---|---|---|
| gp3 순차 처리량 | 1 MiB 순차, 큐 깊이 8, 60초. 읽기 127.3 MiB/s·쓰기 126.0 MiB/s, 평균 지연 58.0·58.5 ms | Ⓑ |
| gp2 순차 처리량 | 같은 조건에서 읽기 130.3 MiB/s·쓰기 128.9 MiB/s, 평균 지연 56.7·57.3 ms. 원문은 1 MiB I/O를 256 KiB 4개로 세어 약 520 IOPS이므로 36,000 크레딧으로 충분하다고 풀이 | Ⓑ Ⓥ |
| 서울 단가 | gp2 $0.114/GB-월, gp3 $0.0912/GB-월, 추가 IOPS $0.0057/IOPS-월, 추가 처리량 $0.0456/MiB/s-월. 원문이 인용: AWS Pricing API, 서울 리전, 2026-09 조회. 우리가 가격표를 다시 조회하지는 않음 | Ⓥ |
| 월 비용 비교 | gp2 100 GiB $11.40(지속 300 IOPS, 버스트 3,000은 최대 33분), gp3 100 GiB $9.12(3,000 IOPS, 125 MiB/s), +6,000 IOPS $26.22, +250 MiB/s $14.82 | Ⓥ ≈ |
| 1,000 GiB gp2와의 비교 | gp2 1,000 GiB $114.00 ÷ gp3 100 GiB $9.12 = 12.5배. 원문은 gp2 1,000 GiB의 처리량을 250 MiB/s로 표기 | ≈ |
| 비용 표의 계산 | $9.12 + 3,000 × $0.0057 = $26.22, $9.12 + 125 × $0.0456 = $14.82. 원문의 산술이 서로 맞는 것은 확인함 | ✓ |
| 서울 단가가 현재도 같은지 | 가격 갱신 이후의 값은 확인하지 않음 | ? |
출처: EBS gp2 vs gp3 실측 벤치마크 — 「측정 4 — 순차 1 MiB: 처리량 상한은 둘 다 125–128 MiB/s」, 「테스트 환경」, 「비용으로 환산하면」
4. HyperDX 노드에 적용할 때 다른 조건
본편 §1.1은 gp3의 기준 3,000 IOPS·125 MiB/s가 버스트 없이 지속된다고 설명합니다. 이 실험은 gp3의 600초 평균 3,001 IOPS와 최소 2,991 IOPS를 확인했고 같은 크기의 gp2에서는 기준 300 IOPS로의 하락을 관찰했습니다. gp2 버스트와 gp3 기준 성능의 차이를 보여 주는 사례지만 gp3를 며칠씩 측정한 결과는 아닙니다.
가격 비교는 원문이 조회한 시점의 단가끼리 맞춰 볼 수 있습니다. 서울의 $0.0912 대 $0.114는 본편의 gp3가 GiB당 20% 저렴하다는 설명과 같습니다. 본편은 서울 추가 IOPS·처리량 단가를 미확인으로 두고 us-east-1의 $0.005·$0.04로 계산했습니다. 원문 서울 값과의 비율은 $0.0057÷$0.005, $0.0456÷$0.04가 모두 1.14이며 스토리지 단가 $0.0912÷$0.08과도 같습니다. 일치하는 산술과 별개로 현행 서울 단가를 확인한 것은 아닙니다.
본편 서두와 §1.4의 인스턴스 EBS 대역 확인도 이 측정에서 필요합니다. m5.xlarge 기준 대역 약 137 MiB/s는 gp3 기본 125 MiB/s와 가깝습니다. 처리량 설정을 올리기 전에 노드 한도를 확인하라는 방법은 같아도 r7g 노드의 한도나 ClickHouse 혼합 부하의 처리량까지 얻을 수는 없습니다.
| 본편의 설명 | 원문의 조건 | 옮길 수 있는가 |
|---|---|---|
| 노드당 1000Gi 안팎의 볼륨 예시(§6.2) | 100 GiB | 1,000 GiB gp2는 기준이 3,000 IOPS 이상이라 원문의 절벽이 생기지 않는다고 원문이 밝힘. gp3의 IOPS·처리량은 용량과 분리되지만 이 실측은 100 GiB만 잼 |
| r7g 노드의 지속 성능(§1.4, r7g.xlarge 156 MB/s, r7g.2xlarge 312 MB/s) | m5.xlarge, 기준 143.75 MB/s·6,000 IOPS | 인스턴스 계열과 크기가 다르므로 한도 수치를 가져오지 못함. 한도를 먼저 확인하라는 방법만 같음 |
| 300 MiB/s 정도로 올린 gp3 처리량(§1.4, §6.1) | 125 MiB/s 기본값만 측정. 250 MiB/s는 비용 표에만 있고 실측은 없음 | 처리량을 올렸을 때 실제로 그 값이 나오는지는 원문이 재지 않음 |
| ClickHouse 머지의 큰 순차 I/O(§3) | 4k 랜덤과 1 MiB 순차 단일 패턴을 따로 60~2,700초 측정, direct I/O, 8 GiB 파일 | 머지·조회가 겹친 혼합 부하와 파트 크기별 패턴은 이 실험에 없음 |
| gp3 지연 single-digit ms(§1.1) | 큐 깊이 1에서 평균 0.56 ms·p99 0.87 ms, 큐 깊이 32에서 평균 10.4 ms | 지연은 큐 깊이에 따라 한 자릿수 ms에서 1 ms 미만까지 달라짐. 본편 표기와 어긋나는지 단정하지 않고 조건을 나란히 적음 |
원문이 연결한 별도 ClickHouse 글의 풀스캔 125~137 MiB/s 정체는 이 부록에서 확인하지 않았습니다. 해당 수치를 이번 fio 결과의 일부로 사용하지 않습니다.
근거와 측정 조건
| 주장 | 수치·조건 | 근거 |
|---|---|---|
| 본편의 gp3 기준과 gp2 대비 설명 | 본편 §1.1의 3,000 IOPS·125 MiB/s, 버스트 없음, GiB당 20% 저렴, 서울 스토리지 $0.0912/GB-월 | ✓ |
| 서울 gp3 스토리지 단가의 일치 | 본편과 원문이 모두 $0.0912/GB-월 | ✓ |
| 서울 추가 IOPS·처리량 단가 | 본편은 미확인, 원문은 $0.0057·$0.0456로 보고. us-east-1 단가($0.005·$0.04)와의 비율은 스토리지 단가의 비율과 같은 1.14 | Ⓥ ≈ |
| 본편의 인스턴스 한도 | r7g.xlarge 기준 156 MB/s·6,000 IOPS, r7g.2xlarge 기준 312 MB/s·12,000 IOPS | ✓ |
| 원문의 인스턴스 한도 | m5.xlarge 기준 1,150 Mbps(143.75 MB/s, 약 137 MiB/s), 버스트 4,750 Mbps. 원문은 AWS 사양이 최대 성능을 24시간마다 최소 1회 30분 유지한다고 설명하며, 항상 정확히 30분만 허용된다는 뜻은 아니라고 적음 | ✓ |
| gp2 1,000 GiB에서 절벽이 없다는 서술 | 원문이 1,000 GiB 이상 gp2는 기준이 최소 3,000 IOPS라 절벽이 없다고 적음 | ✓ |
| 본편 §6.2와 원문의 볼륨 크기 | 본편 예시 1000Gi, 원문 실측 100 GiB | ✓ |
| ClickHouse 풀스캔 정체 | 원문이 다른 글을 가리킴. 그 글은 열지 않음 | ? |
| 지연 비교의 범위 | 본편은 지연을 single-digit ms로 적고 io2 BE의 sub-ms와 대비. 원문은 읽기 큐 깊이별 값만 있고 쓰기의 큐 깊이 1 값은 없음 | ✓ |
출처: EBS gp2 vs gp3 실측 벤치마크 — 「테스트 환경」, 「측정 3 — qd1 레이턴시: 낮은 동시성에서 본 분포」, 「측정 4 — 순차 1 MiB: 처리량 상한은 둘 다 125–128 MiB/s」, 「해석 시 주의사항」
5. 남은 gp2의 알람과 전환 절차
gp2를 유지한다면 용량별 기준 성능과 크레딧 잔량을 함께 봐야 합니다. 원문은 100 GiB에서 버스트 지속 시간을 2,000초로 계산하고, 334 GiB에서는 기준 성능이 1,002 IOPS가 된다고 설명합니다. 1,000 GiB 이상은 기준이 최소 3,000 IOPS이므로 이 실험과 같은 하락이 생기지 않는다는 서술입니다.
BurstBalance 알람도 같은 조건으로 계산했습니다. 100 GiB에 일정하게 3,000 IOPS를 가하면 잔량 약 15%가 소진 약 5분 전입니다. 실제 알람에는 평가 주기와 누락 데이터 처리를 별도로 반영하라고 원문은 단서를 붙였습니다.
전환 절차로는 VolumeAttributesClass를 이용해 기존 PVC 타입을 바꾸는 방법을 제시합니다. 원문이 인용한 수정 제한은 이전 수정이 completed인 뒤, 24시간 롤링 구간에서 볼륨당 최대 4회입니다. 타입·IOPS·처리량을 한 번에 묶으라는 조언은 본편 §6.1의 iops·throughput 조정 절차에도 참고할 수 있습니다. 타입만 바꾸면 gp2 성능을 보존하려고 gp3 기본보다 높은 처리량이 유지되어 추가 비용이 생길 수 있다는 경고도 있습니다.
이 절의 전환 조건은 원문의 설명입니다. 원문이 근거로 삼은 AWS 문서를 이 부록에서 직접 확인한 것은 아니므로 적용 버전과 수정 조건을 확인할 항목으로 남깁니다.
근거와 측정 조건
| 항목 | 수치·조건 | 근거 |
|---|---|---|
| gp2 기준과 버스트 | 3 IOPS/GiB. 100 GiB 기준 300 IOPS·버킷 5.4M·버스트 지속 2,000초. 334 GiB는 기준 1,002 IOPS. 1,000 GiB 이상은 기준이 최소 3,000 IOPS | Ⓥ |
| BurstBalance 알람 계산 | 절벽 5분 전은 잔량 약 15%. 일정한 3,000 IOPS 부하 가정. 알람 평가 주기와 누락 데이터 처리는 별도로 반영하라고 원문이 단서를 붙임 | Ⓥ ≈ |
| VolumeAttributesClass | Kubernetes 1.34에서 GA(storage.k8s.io/v1), EBS CSI의 ModifyVolume을 호출해 파드를 유지한 채 변경. 1.31~1.33은 v1beta1과 feature gate 확인 필요 | Ⓥ |
| EBS 수정 제한 | 이전 수정이 completed인 뒤에만 다음 수정 허용, 24시간 롤링 구간에 볼륨당 최대 4회. 1 TiB는 보통 최대 6시간 정도지만 더 걸릴 수 있음 | Ⓥ |
| 원문이 인용한 AWS 문서 | EBS gp2/gp3 performance, EBS modification considerations, EC2 EBS optimized bandwidth. 부록 작성 중 이 문서들을 직접 열지는 않음 | ? |
| 본편 §6.1의 조정 서술 | iops와 throughput을 이후 Elastic Volumes로 조정할 수 있다고 적음. 수정 횟수 제한은 언급하지 않음 | ✓ |
출처: EBS gp2 vs gp3 실측 벤치마크 — 「측정 1 — 4k 랜덤 읽기 45분: 크레딧 절벽」, 「해석 시 주의사항」, 「Kubernetes에서 gp3로 전환하기」 아래 「기존 PVC: VolumeAttributesClass로 무중단 변경」, 「남은 gp2에는 알람을」
6. 확인하지 못한 것
| 항목 | 상태 |
|---|---|
| 측정일, 측정 시각의 EBS 서비스 상태 | 원문에 없음 |
| gp2 절벽이 2,000초보다 1초 일찍 나온 이유 | 원문도 사전 부하 이력과의 관계를 확인하지 못함 |
| 처리량을 125 MiB/s보다 높게 프로비저닝한 gp3의 실측 | 원문에 없음 |
| 1,000 GiB 같은 큰 볼륨에서의 gp3 측정 | 원문에 없음 |
| ClickHouse 부하(머지·조회 혼합)에서의 gp3 동작 | 원문에 없음 |
| r7g 계열 인스턴스에서의 같은 실험 | 원문에 없음 |
| 서울 추가 IOPS·처리량 단가의 현행 값 | 원문이 보고한 값만 확인 |
| 원문이 인용한 ClickHouse 벤치마크, AWS 문서 | 열지 않음 |
참고 자료
- EBS gp2 vs gp3 실측 벤치마크 — atomai kubernetes-docs. 원문 제목 「EBS gp2 vs gp3 실측 벤치마크」. 마지막 업데이트 2026-09-11, 측정일은 원문에 없음. 이 글의 수치 전부의 출처
- EBS gp2/gp3 performance · EC2 EBS optimized bandwidth · EBS modification considerations — AWS. 원문이 근거로 든 문서이며 이 글에서는 열지 않음