김마늘의 테크 레시피

 VMware vSphere의 공유 데이터 스토어로는 VMware vSAN을 사용한 HCI 구성하거나 혹은 외부 스토리지를 제공하는 방식이 있습니다. 외부 스토리지는 대표적으로 SAN과 NAS가 있을 수 있는데, 이번 포스팅에서는 Synology NAS의 SAN Manager를 활용, iSCSI를 통해 제공된 VMware vSphere 공유 데이터 스토어에 대한 튜닝을 통해 얼마나 성능 향상을 이룰 수 있는지 확인해 보도록 하겠습니다.

테스트 환경

• 스토리지 네트워크 MTU 1500: 점보 프레임 설정 시 ESXi 호스트가 먹통되는 문제 발생으로 기본값 사용
• 동일한 L2 네트워크에 NAS와 ESXi 호스트를 두어, 스위치 레벨에서 트래픽을 처리하도록 설계
• Synology NAS iSCSI LUN과 VM의 디스크 모두 Thick Provisioning 구성
• 캐시 효과 배제를 위해 NAS 물리 메모리 용량의 1.5배인 24GB로 테스트 데이터 설정

테스트 시나리오

 Test VM의 블록 디스크의 위치와, ESXi의 설정을 변경해 가면서 IOPS 성능의 변화를 측정합니다.

• 테스트 도구: Fio
• 방식
  • 테스트 시작 전 24GB 전체 영역에 데이터를 기록하는 과정을 선행하여 Test VM의 시스템 레벨의 할당 오버헤드 제거
  • 테스트 시 실제 데이터를 읽어 오도록 강제하여 MPIO 네트워크 대역폭과 디스크 I/O 성능을 정확히 타격하도록 설계
  • 각 테스트간 60초의 휴지 기간을 가지고 실행
• 측정 결과 집계: 총 3회를 측정하여 평균값을 도출

테스트 데이터 생성 스크립트

fio --name=warmup_fill \
    --filename=fio_test_file.dat \
    --ioengine=libaio \
    --rw=write \
    --bs=1M \
    --direct=1 \
    --numjobs=1 \
    --size=24G \
    --group_reporting

• 앞서 언급한 NAS의 캐시 효과 배제를 위해 NAS 물리 메모리의 1.5배인 24GB 테스트 데이터를 준비

테스트 스크립트

COUNT=3				# Test 횟수
OUTPUT_PREFIX="test name"		#fio 테스트 결과 파일 이름 prefix

echo "==== FIO 벤치마크 시작 (총 ${COUNT}회) ===="

for i in $(seq 1 $COUNT); do
    echo ""
    echo "[$(date '+%H:%M:%S')] ${i}회차 진입: 60초 대기 후 테스트 시작..."
    sleep 60

    echo "[$(date '+%H:%M:%S')] ${i}회차 측정 시작 (5분)..."
    fio --name=benchmark_mpio_test \
        --filename=fio_test_file.dat \
        --ioengine=libaio \
        --rw=randrw \
        --rwmixread=70 \
        --bs=4k \
        --direct=1 \
        --numjobs=4 \
        --size=24G \
        --runtime=300 \
        --time_based \
        --iodepth=32 \
        --group_reporting \
        --output-format=json \
        --output="${OUTPUT_PREFIX}_${i}.json"

    echo "[$(date '+%H:%M:%S')] ${i}회차 완료 -> ${OUTPUT_PREFIX}_${i}.json 저장됨"
done

iSCSI 설정 - 테스트 전 기본 설정

공통 설정 - IOPS 대기열 맞춤

• ESXi에서 확인되는 iSCSI 타겟 LUN의 대기열 크기와 Synology NAS의 iSCSI 서비스의 I/O 대기열 수준을 동일하게 설정

[비교군 1] MPIO 기본 설정

• 소프트웨어 스토리지 어댑터를 생성하고 NAS의 iSCSI 서버 IP 중 하나를 동적 검색으로 등록하면 다중 경로 설정이 자동으로 생성
• 다중 경로 지정 정책의 기본 정책은 가장 최근에 사용됨(VMware)로 이는 NAS에서 제공하는 경로 중 가장 최근에 사용된 경로를 계속 사용하는 것으로, 해당 경로가 실패할 때 다른 경로로 변경됨(Active - Standby 설정)

[비교군 2] 라운드 로빈 기본 설정

• 라운드 로빈 정책을 통해 다중 경로를 돌아가면서 사용할 수 있도록 선택
• 라운드 로빈 기본 설정값은 1000 IOPS 마다 경로를 변경

# esxi 호스트에 shell로 접근 후 아래 명령어를 수행
# Storage device list 확인
esxcli storage nmp device list | grep -i "Device Display Name" -B 1

naa.6001405722e8deed16d2d4662d8c32df
   Device Display Name: SYNOLOGY iSCSI Disk (naa.6001405722e8deed16d2d4662d8c32df)
--
naa.60014056b78746cda247d45dbd8576de
   Device Display Name: SYNOLOGY iSCSI Disk (naa.60014056b78746cda247d45dbd8576de)
--
naa.6001405e5b0f035db767d4b26da2d1da		# 튜닝 대상 데이터 스토어
   Device Display Name: SYNOLOGY iSCSI Disk (naa.6001405e5b0f035db767d4b26da2d1da)
   
# 데이터 스토어 기본 IOPS 정책 확인
esxcli storage nmp psp roundrobin deviceconfig get -d naa.6001405e5b0f035db767d4b26da2d1da

   Byte Limit: 10485760
   Device: naa.6001405e5b0f035db767d4b26da2d1da
   IOOperation Limit: 1000			# 1000 IOPS 마다 경로 변경이 기본 설정
   Latency Evaluation Interval: 0 milliseconds
   Limit Type: Default				# 기본 라운드 로빈 정책
   Number Of Sampling IOs Per Path: 0
   Use Active Unoptimized Paths: false

[비교군 3] 라운드 로빈 IOPS 정책 수정

# 위에서 살펴본 튜닝 대상 디스크에 대해서 아래 명령어를 실행하여 IOPS 정책을 변경
esxcli storage nmp psp roundrobin deviceconfig set --type=iops --iops=1 --device=naa.6001405e5b0f035db767d4b
26da2d1da

# 정책 변경 확인
esxcli storage nmp psp roundrobin deviceconfig get -d naa.6001405e5b0f035db767d4b26da2d1da

   Byte Limit: 10485760
   Device: naa.6001405e5b0f035db767d4b26da2d1da
   IOOperation Limit: 1			# 1 IOPS 마다 경로 변경 정책 설정됨
   Latency Evaluation Interval: 0 milliseconds
   Limit Type: Iops			# IOPS 기준으로 경로 변경 정책 설정됨
   Number Of Sampling IOs Per Path: 0
   Use Active Unoptimized Paths: false

• 1 IOPS 마다 iSCSI 경로를 변경하도록 설정하여 극한의 성능 향상을 노리는 설정

[비교군 4] 라운드 로빈 IOPS 정책 수정 + Synology NAS I/O 정책 변경

• LUN에 대한 I/O 버퍼를 해제하고 직접 디스크에 읽고 쓰는 설정을 활성화
• 데이터가 물리 디스크에 안전하게 기록되었음을 확인할 때까지 완료 신호를 주지 않는 설정으로 안정성 향상의 목적

테스트 결과 및 심층 분석

 총 4가지 시나리오에 대한 FIO 벤치마크 결과, iSCSI MPIO 튜닝(라운드 로빈 IOPS=1)이 단일 물리 네트워크 환경에서 드라마틱한 성능 향상을 가져옴을 확인했습니다. 하지만 이면에는 운영 입장에서 반드시 알아야할 Trade-off가 숨겨져 있는것도 확인할 수 있었습니다.

테스트 결과

심층 분석

Insight 1. 기본값(Default)의 함정: 대역폭 낭비

 가장 먼저 눈에 띄는 것은 기본 설정인 [비교군 1] - MPIO 기본 설정과 [비교군 2] - 라운드 로빈 기본 설정의 비효율성 입니다.

• 현상: [비교군 1]과 [비교군 2]의 설정에서는 대역폭이 약 68 - 78 MB/s에 머물렀습니다. 이는 1 Gbps 네트워크의 최대 한계의 60 - 70% 수준 밖에 활용하지 못하는 수준입니다.
• 원인: TCP 단일 세션의 한계입니다. ESXi가 단일 경로를 고집하거나[비교군 1] 경로 변경 주기가 너무 길면[비교군 2], 4K 랜덤 I/O와 같은 작은 블록 전송 시 윈도우 사이즈와 응답 대기(RTT)로 인해 물리 대역폭을 가득 채우지 못합니다. 고속도로는 뚫려 있는데 톨게이트를 하나만 열어둔 셈입니다.

Insight 2. IOPS=1 튜닝: 물리적인 최대치에 도달

 라운드 로빈 정책의 경로 변경 임계값을 1 IOPS로 수정[비교군 3]한 후, 생각보다 놀라운 성능 향상이 관찰되었습니다. 구형 NAS임에도 불구하고 예상보다 고무적인 수치가 나와주었습니다.

• 성과: 대역폭이 107.58MB/s까지 치솟았습니다. 이는 이더넷 오버헤드를 제외하면 사실상 1Gbps 물리 회선을 95% 이상 포화 시킨 수치입니다.
• 핵심: 물리적인 업링크는 1개뿐이지만, '다중 세션(Multi-Session)' 효과를 톡톡히 봤습니다. 1 IOPS마다 경로를 바꿔가며 NAS의 여러 포트로 세션을 분산시켰고, 이를 통해 I/O 큐(Queue)를 병렬로 처리하여 단일 세션의 병목을 소프트웨어적으로 극복해냈습니다.

Insight 3. 속도와 안정성의 Trade-off (P99 Latency & Kubernetes)

 하지만 모든 지표가 긍정적인 것만은 아닙니다. 하위 1%의 느린 응답 속도를 나타내는 P99 Latency의 변화를 주목해야 합니다. 특히 Kubernetes 관점에서 말이죠.

• 현상: 평균 성능은 좋아졌지만, P99 Latency는 **14.99ms(MRU) → 21.8ms(Tuned)**로 오히려 악화되었습니다. 이는 대역폭 포화로 인한 네트워크 큐잉 지연(Queuing Delay) 때문입니다.
• Kubernetes 환경에서의 의미: 이 수치는 etcd와 같은 민감한 워크로드에 치명적일 수 있습니다. etcd는 쓰기 작업마다 fsync를 수행하는데, P99 지연시간이 지속적으로 20~30ms를 넘어가면 리더 선출(Leader Election) 실패나 API 서버 응답 저하로 이어질 수 있습니다. 즉, 처리량(Throughput)을 얻는 대신 응답의 균일성(Stability)을 일부 희생한 결과입니다.

Insight 4. 벤치마크와 현실의 차이: 단일 vs 다중 워크로드

 이번 테스트 결과는 단일 VM이 스토리지를 독점할 때의 최대 성능이라는 점을 기억해야 합니다.

• Noisy Neighbor: 실제 운영 환경에서 여러 VM이 동시에 부하를 준다면(Multi-Workload), NAS의 대기열이 가득 차면서 Latency는 이보다 훨씬 더 튀게 될 것입니다.
• 의의: 따라서 이 결과값(27k IOPS)은 항상 보장되는 성능이 아니라, 이 인프라가 견딜 수 있는 물리적 한계점(Baseline)으로 해석하는 것이 타당합니다.

번외 분석: NAS 쓰기 캐시(Bufferd I/O)는 필수인가?

 마지막으로 데이터 무결성을 위해 직접 I/O를 활성화했을 때의 결과는 상당히 실망스러웠습니다.

• 성능 붕괴: 쓰기 지연시간(Avg)이 47.69ms로 튜닝 전보다도 6배 이상 느려졌으며, 전체 대역폭은 31.92 MB/s로 곤두박질쳤습니다.
• 교훈: SATA SSD 기반의 RAID 5 환경에서는 '패리티 연산(Read-Modify-Write)' 오버헤드가 매우 큽니다. 이를 NAS의 RAM 캐시가 받아주지 못하면, 아무리 네트워크를 튜닝해도 디스크단에서 병목이 발생함을 알 수 있습니다. 따라서 홈랩 환경에서는 성능은 버퍼(Cache)로 챙기는 것이 현실적인 정석입니다.

결론 및 제언: 성능과 안정성의 균형 찾기

 이번 실험을 통해 단일 1Gbps 망에서도 iSCSI 튜닝은 선택이 아닌 필수라는 점을 증명했습니다. 하지만 단순히 설정을 바꿨다고 끝이 아닙니다. 다음의 운영 전략이 병행되어야 합니다.

1. 최적의 튜닝 조합

 단일 1Gbps 링크의 물리적 한계를 극복하기 위해서는 라운드 로빈 (IOPS=1) 설정과 NAS의 쓰기 캐시(Buffered I/O 활성화가 가장 효과적인 해법임이 확인되었습니다. (대역폭 약 57% 향상)

2. 현실적인 운영 해법 (Hybrid Approach)

 하지만 앞서 분석했듯, 이 설정은 네트워크를 한계까지 밀어붙여 P99 Latency를 불안정하게 만들 수 있습니다. 따라서 Kubernetes와 같은 민감한 워크로드를 운영한다면 다음과 같은 전략을 추천합니다.

• 기반 설정: 스토리지 성능 극대화를 위해 RR IOPS=1을 유지합니다.
• 안정성 확보: ESXi 레벨에서 VM별 IOPS 제한(Limit)이나 SIOC(Storage I/O Control)를 적용합니다.
  • 일반 VM: IOPS를 적절히 제한하여 스토리지 큐를 독점하지 못하게 방지
  • 중요 VM (etcd/Control Plane): 제한을 풀거나 높은 우선순위(Shares)를 부여하여 Latency 보장

3. 마무리

 이번 테스트는 단순히 숫자를 높이는 튜닝이 아니라, 제한된 홈랩 자원 환경에서 성능·안정성·운영 복잡도 사이의 균형점을 어디에 두어야 하는지를 고민하는 과정이었습니다.

 스토리지 튜닝에 ‘무조건적인 정답’은 없습니다. 내 인프라의 한계를 명확히 알고, 워크로드의 성격에 맞춰 의도적으로 Trade-off를 선택하는 것이야말로 엔지니어링의 핵심임을 다시 한번 확인할 수 있었습니다.

 국내에도 생각보다 많은 분들이 홈 랩을 구축하고, 운용하고 있는 것으로 알고 있습니다. 베어메탈 환경에 직접 리눅스로 서버 환경을 구축할 수도 있지만, Hypervisor를 사용한다면 가상화를 통한 조금 더 유연한 인프라 환경을 구현할 수 있습니다. 저도 여러 Hypervisor들 중에 가장 익숙한 ESXi를 활용하여 인프라 가상화 환경을 구축하고 있습니다.

홈 랩의 숙명 - 하드웨어 호환성

 VMware ESXi는 네트워크 인터페이스에 대한 호환성에 많이 인색한 편입니다. 오로지 Intel의 컨트롤러만을 사용하는 네트워크 인터페이스를 지원하기 때문에 ESXi를 하이퍼바이저로 선정한 사람들에게 숙명적으로 따라오는 것이 이 네트워크 인터페이스에 대한 고민입니다. 저 역시도 여기에서 자유롭지 못했습니다. 사용 중인 미니 PC네트워크 인터페이스의 개수가 1개에, 컨트롤러는 리얼텍 r8168입니다.

 자세한 하드웨에 사양은 위 포스팅에 상세하게 작성해 두었는데... 어쨌든, 리얼텍 r8168을 사용하기 위해서는 ESXi 커스텀 드라이버가 설치된 ISO가 필요했고, 이를 위해 열심히 구글링 한 결과 다른 사람들도 이런 고민이 이미 예전부터 있었다는 것을 알 수 있었습니다. 그중 몇 가지 방법들을 시도해서 겨우 ESXi 커스텀 ISO를 만들어낼 수 있었습니다. 혹시 ESXi 커스텀 이미지를 생성하실 분들은 아래 자료를 참고해 주시면 되겠습니다.(저도 여러 번의 시도 끝에 6.7 버전으로 ISO 이미지를 생성하는 데 성공했습니다.)

홈 랩 인프라 확장과 네트워크 분리의 필요성

 문제는 다음입니다. 홈 랩 인프라가 확장되면서 VM들의 서비스 네트워크와 스토리지용 네트워크 분리가 필요해졌습니다. 문제는 서버가 미니 PC라 확장성이 제한적이라는 점이었습니다. 이를 위해 여러가지 방법을 찾던 중 VMware 진영에서는 홈 랩 인프라 구축에 신선과도 같은 William Lam의 게시글이나 구익환 님의 블로그 등을 참고하여 그 가능성을 발견하였고, 역시나 안 되는 게 없구나 라는 생각으로 ipTIME U1G를 구매하고 테스트해봤습니다.

 flings라는 VMware 사용자 커뮤니티에서 ESXi 버전에 맞는 커뮤니티 드라이버를 다운로드하고 설치를 진행했습니다. 자세한 방법이나 명령어는 아래 사이트를 참조했습니다.

 다행히도 ESXi에서 USB 어뎁터를 잘 인식하여 VM들의 서비스 네트워크와 스토리지 네트워크를 분리할 수 있는 가능성이 열렸습니다. 다만... 생각지도 못한 문제에 부딪힙니다.

VLAN과 MTU의 환장의 조합

 아무래도 홈 랩 환경이다 보니 스토리지 전용 스위치를 사용하기에는 비용문제도 있어 1대의 스위치에서 VLAN을 통해 논리적으로 네트워크를 구분하여 사용하려 했습니다. NAS의 iSCSI 타겟과 ESXi의 소프트웨어 iSCSI 어뎁터 간의 인식은 문제가 없이 잘 진행되었는데 디스크를 VMFS 형식으로 포맷하려고 하면 꼭 타겟이 유실되면서 제대로 작동하지 않는 것이었습니다. 이때 물리적 연결에 사용한 네트워크 인터페이스가 앞서 말씀드린 ipTIME USB 이더넷 어뎁터인데 여기에 치명적인 문제가 있었습니다.

 바로 VLAN 태그에 대한 오프로딩 기능이 없다는 점이었습니다. 정확히는 네트워크 드라이버의 문제인지, 어뎁터의 문제인지는 모르겠으나 어쨌든 여기에서 문제가 생긴다는 것이었습니다. 보통의 경우 MTU를 1500으로 설정한 상태에서 ping 테스트를 하면 최대 1472바이트까지 전송이 가능합니다. 그 이유는 ICMP 헤더 8바이트와 IP 헤더 20 바이트 때문인데, 만약 중간 구간에 VLAN까지 있다면 추가로 4바이트가 더 필요합니다. 보통의 경우 하드웨어 레벨에서 이를 오프로딩 처리하기 때문에 VLAN에 속한 호스트의 MTU가 1500이어도 문제가 없지만 그렇지 못한 경우에는 문제가 발생하게 됩니다.

 그에 대한 트러블 슈팅에 관한 자세한 내용은 위 포스팅을 참고해 주세요. 어쨌든 이런 이유로 외장 USB NIC의 경우 MTU를 1450으로 설정하니 iSCSI 타겟 유실과 같은 문제가 발생하지 않고 정상 작동하는 것을 확인할 수 있었습니다.

성능 욕심과 USB NIC의 뻥카

 그러던 중, 점보 프레임을 사용해 보면 어떨까 하는 생각을 하게 됩니다. 하지만 여전히 VLAN 구간을 지나므로 VLAN 태그 오프로딩 기능이 없다는 점을 감안하여 MTU 사이즈를 안전한 8000 정도로 사용해 보기로 했습니다. NAS의 네트워크 구성, 스위치의 MTU 사이즈, 분산 스위치의 MTU를 조정하고 테스트를 수행했습니다.

 우선 VMware vSphere에서는 분산스위치의 MTU 사이즈를 조절하면 그의 업링크 인터페이스의 MTU 사이즈 역시 같은 값으로 동기화됩니다. 이를 통해 외장 USB NIC에는 MTU 최대 사이즈인 9000이 되도록 하고 iSCSI 어뎁터의 종단점인 VMkernel의 MTU를 8000으로 조정하기로 합니다. NAS 쪽도 MTU 사이즈를 8000으로 맞춥니다.

#esxcli 명령어를 통해 nic의 MTU 상태를 확인

[root@esxi01:~] esxcli network nic list

Name    PCI Device    Driver  Admin Status  Link Status  Speed  Duplex  MAC Address         MTU  Description
------  ------------  ------  ------------  -----------  -----  ------  -----------------  ----  -----------------------------------------------------------------------------------------
vmnic0  0000:01:00.0  r8168   Up            Up            1000  Full    b0:41:6f:09:28:dc  1500  Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
vusb0   Pseudo        uether  Up            Up            1000  Full    58:86:94:31:6c:41  9000  Realtek USB 101001000 LAN

 위 내용에서 장치의 이름이 vusb0인 것이 바로 외장 USB NIC입니다. MTU 사이즈가 9000으로 조정된 것을 확인할 수 있습니다. 또한, VMkernel 어뎁터의 MTU는 8000인 것을 확인할 수 있습니다. 당연하게도 NAS 쪽의 MTU도 8000으로 조정을 하였습니다.

 이렇게 하니 우선은 iSCSI 연결에는 문제가 없었습니다. 그런데 그다음이 문제였죠. 앞선 상황과 같이 계속 iSCSI 타겟이 유실되는 것이었습니다. 처음에는 VLAN 태그 오프로딩 문제인가 싶어 미세하게 MTU를 조정해 보았지만, 역시나 제대로 작동하지 않는 것을 확인할 수 있었습니다. 정말 혹시나 싶어서 ping -d -s를 통해 전송되는 최대 프레임의 크기를 측정해 보았습니다. 그랬더니 아래와 같은 결과를 얻을 수 있었습니다.

#데이터 크기를 8000으로 esxi 호스트에서 NAS로 ping 테스트
#실패

[root@esxi01:~] ping -d -s 8000 10.10.10.100

PING 192.168.20.254 (10.10.10.100): 8000 data bytes
sendto() failed (Message too long)
sendto() failed (Message too long)
sendto() failed (Message too long)

--- 10.10.10.100 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss


#데이터 크기를 1472로 하여 프레임 데이터 합계가 1500바이트가 되도록 테스트
#실패

[root@esxi01:~] ping -d -s 1472 10.10.10.100

PING 10.10.10.100 (10.10.10.100): 1472 data bytes

--- 10.10.10.100 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss


#데이터 크기를 1468로 하여 프레임 데이터 합계가 1496바이트가 되도록 테스트
#성공

[root@esxi01:~] ping -d -s 1468 10.10.10.100
PING 10.10.10.100 (10.10.10.100): 1468 data bytes
1476 bytes from 10.10.10.100: icmp_seq=0 ttl=64 time=0.691 ms
1476 bytes from 10.10.10.100: icmp_seq=1 ttl=64 time=0.733 ms
1476 bytes from 10.10.10.100: icmp_seq=2 ttl=64 time=0.767 ms

--- 10.10.10.100 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.691/0.730/0.767 ms

 혹시나 싶었던 의심이 확신이 되는 순간이었습니다. 명령어 조회를 통해, 또는 UI를 통해 설정했던 MTU값들이 그저 '뻥카'였던 겁니다. 표시만 그렇게 될 뿐, 실제 USB NIC의 MTU는 1500으로 고정이며 당연하게도 VLAN 태그 오프로딩 기능도 없으므로 실질적으로는 1496이 최대 MTU 사이즈인 것입니다. 이런 이유 때문에 MTU가 1450일 때는 아무런 문제 없이 잘 작동했던 것이구요. 역시 외장 USB NIC이 원인인지, 커뮤니티 드라이버가 원인인지 명확하지는 않지만, 그래도 여기에서 문제가 발생하는 것은 확실해졌습니다.

 다시 VMkernel과 NAS쪽의 MTU 사이즈를 1468로 낮추고 iSCSI 연결을 하니 문제 없이 잘 작동하는것을 확인할 수 있었습니다. 역시 공식적으로 지원하지 않는 하드웨어를 사용하는데에는 많은 어려움이 있군요.

 요 며칠 동안 MTU 때문에 많이 골치를 썩었습니다. 사실 요즘에야 PMTUD(Path MTU Discovery)나 MMS와 같은 기술덕에 이 부분을 크게 신경 쓰지 않는다고는 하는데, 이처럼 호환성이 담보되지 않는 특수한 경우에서는 여전히 문제가 될 소지가 있는 것 같습니다. 덕분에 많은 것을 배웠고 이해할 수 있는 소중한 경험이었습니다.