i-node 직접 블록 (Direct Blocks) - 먼지처럼 작은 파일들을 빛의 속도로 삼켜버리는 고속 I/O 차선

핵심 인사이트 (3줄 요약)

본질: 디스크 철판에서 1개의 256바이트짜리 유닉스 i-node 껍데기 포인터 배열 장부를 열었을 때, 가장 앞단에 위치하는 12~15개 남짓의 C언어 배열 칸(Array Slots) 이다. 이곳엔 다중 레벨 트리(간접 지연)를 거치지 않고, 그 칸에 적힌 주소를 읽자마자 디스크 데이터 목적지로 1방에 다이렉트 레이저 점프 빔 타격 을 쏠 수 있는 물리 포인터가 적혀 있다.

가치: 현실 세계 리눅스 서버에 존재하는 파일의 80~90%는 고작 1KB~10KB 크기의 아주 작은 텍스트(로그, 환경설정) 파일들이다. 다이렉트 블록 배열 12칸만 있으면 12칸 × 4KB 블록 = 48KB 이내의 초소형 파일들은 "인덱스 장부를 1번 캐싱 $\to$ 디스크 모터 1번 다이렉트 이동" 이라는 $O(1)$ 초광속 레이턴시 스왑으로 끝장낼 수 있어, 극한의 I/O 병목 낭비를 타결 융합했다.

한계: 파일이 48KB를 1바이트라도 넘어가는 순간, 이 12칸의 하이패스 직접 차선은 꽉 차버려 무용지물이 된다. 이때부터는 어쩔 수 없이 디스크를 여러 번 긁어야 하는 "간접 블록(Indirect Block)" 이라는 악명 높은 다중 트리 톨게이트 늪으로 S/W 병목 스위칭이 강제로 일어나게 된다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: i-node 직접 블록 (Direct Blocks 인덱스 포팅 통치) 은 리눅스 계열(ext2, ext3 등) VFS 파일 시스템의 i-node 객체 구조체 구조 내에 하드코딩된 "직접 주소 지시 포인터 어레이 (Direct Pointer Array 12 Slots 마스킹)" 다. 이 포인터가 가리키는 디스크 주소는 "목차 장부" 가 아니라, 실제 알맹이 내용이 들어있는 "최종 데이터 블록(Data Block)" 이다.
필요성: 색인 할당(526~527장)에서 배운 교훈은 "거대한 트리(다중 수준 인덱스)를 타면 엄청난 파일을 저장할 순 있지만, 디스크 모터를 연속으로 2번, 3번씩 미친 듯이 긁고 탐색하느라(Overhead 지연 늪) $O(\log N)$ 의 I/O 레이턴시가 너무 느리다" 는 딜레마였다. 시스템 통계 팩트 폭격상 OS 커널이 다루는 파일의 대다수(90%)는 엄청나게 작다. "야! 90%의 빈도로 읽히는 작은 파일들한테 굳이 3단계 트리를 타게 해서 속도를 고문 암살할 필요가 있냐?? 12개 칸 정도는 트리 우회하지 말고 그냥 다이렉트로 디스크 본체 방 번호(Direct Address)를 직방으로 꽂아 주자!! O(1) 초광속 부스트 결착!" 이것이 다이렉트 블록의 존재 이유이자 i-node 하이브리드 설계의 정수(Mixed Scheme 진보)다.
💡 비유: 다이렉트 블록 구조는 은행 VIP 전용창구의 "서류 없이 곧바로 돈통 다이렉트 꺼내기 하이패스 룸!" 랑 똑같습니다!!
- (간접 트리 방식): 은행원이 손님 A에게 "저기 지하 1층 2번 서고 가서 비밀 장부 꺼내와! 장부 보면 5층 금고 주소 있다!" (느리고 뺑뺑이 서류 결재 데들락!)
- (다이렉트 방식 $O(1)$ 스왑 빔): "손님 B, 고작 1만 원 찾으시죠? 전용 장부(다이렉트 블록 12칸) 3번째 줄 보세요. '서랍장 2번 칸 1만 원 꺼내셈!' 끝!" 은행원이 다른 데 보내지 않고 자기 의자 밑 12개 서랍에서 바로 지폐를 쑤욱 빼주는(다이렉트 1단계 속도 $O(1)$ 빔) 초소형 맞춤형 고속 I/O 쾌적 렌더랍니다!
i-node 12칸 직접 블록과 물리 디스크 타격 ASCII 결속 다이어그램: 운영체제가 30KB짜리 작은 텍스트 파일을 12칸의 배열 안에서 어떻게 단숨에 처리하는지(No Indirect 스로틀) 맵핑 포팅 뷰를 까보면 다음과 같다.

  ┌────────────────────────────────────────────────────────────────────────────────┐
  │                 12개의 고속 하이패스 레인: Direct Block $O(1)$ 레이저 타격     │
  ├────────────────────────────────────────────────────────────────────────────────┤
  │                                                                                │
  │  [[ 145번 i-node (메모리에 떠 있는 객체 장부. 존나 빠름!) ]]                   │
  │  -------------------------------------------------------------                 │
  │   [0] 번째 Direct 포인터 ──▶ (디스크 물리섹터 `35번`) 직행 점프!               │
  │   [1] 번째 Direct 포인터 ──▶ (디스크 물리섹터 `99번`) 직행!                    │
  │   [2] 번째 Direct 포인터 ──▶ (디스크 물리섹터 `12번`) 직행!                    │
  │   ... (3번부터 6번까지 연속 읽기 4KB 덩어리들 우당탕)                          │
  │   [7] 번째 Direct 포인터 ──▶ (디스크 물리섹터 `105번`) ◀── 여기가 끝!          │
  │   [8] ~ [11] 번 포인터 ──▶ (NULL 빈칸. 아무것도 없음 공간 낭비 조금 발생)      │
  │                                                                                │
  │  =========================▼===================================                 │
  │                                                                                │
  │  [[ 하드디스크 모터 암(Arm)의 움직임 스루풋 렌더 결과 타결 ]]                  │
  │   커널 왈: "야! 다이렉트 포인터 8개(32KB) 읽었지? 간접 블록 톨게이트 탈 필요   │
  │             없다! 당장 35, 99, 12, ... 105번지 모터 핀 1번씩만 깔끔히 찍고,    │
  │             파일 끝내버려! 파일 읽기 속도 지연 0% 종료!"                       │
  └────────────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 만약 이 파일이 30KB였다면 데이터 블록(4KB 기준)은 $30KB / 4KB = 7.5개$, 총 8개의 디스크 철판 공간을 점유한다. i-node의 처음 12칸짜리 다이렉트 슬롯만으로도 8칸이라는 주소를 전부 적고도 4칸이나 넉넉히 남는(안전 수용 스로틀 이치!) 쾌적 포팅 이 성취된다. 즉, 파일을 읽기 위해 추가적인 "간접 인덱스 블록을 로딩하는 2번째 I/O, 3번째 I/O 오버헤드" 가 전혀 발생하지 않고, 오직 목표 데이터 블록만을 향해 1회성 다이브 레이저 타격 결착 락백을 수행해 백본 C드라이브를 지배하게 됨을 증명하는 렌더 뷰다.

📢 섹션 요약 비유: 이 Direct 하이패스 고속 타격 포팅은 아파트 택배원의 "저층 엘리베이터 무정차 다이렉트 계단 빔!" 랑 같습니다!!
- 택배상자가 아주 작고 배달 층수가 2층, 3층(48KB 이하 작은 파일)이라면? 택배 기사(모터 암)는 복잡하게 중앙 엘리베이터(간접 트리 지연 랙)를 기다리고 버튼 누르고 뭐 할 시간 낭비 없이! 그냥 곧장 1층 옆 계단(다이렉트 배열 블록) 을 우다다 뛰쳐 올라가 10초 만에 문 앞에 직방 배송(1방에 다이렉트 타격 $O(1)$)을 끝내버리는 초 극강 스피드 스펙 효율이랍니다!

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. 트레이드오프 SRE 폭발: 파레토 법칙(80/20)을 관통한 C언어 구조체의 기적

운영체제를 뜯어보면 S/W 설계자들은 철저하게 통계학(가장 많이 일어나는 일에 최적화를 쏟아붓자)에 미친 변태들이다.

i-node 구조와 파일 사이즈 통계 (리눅스 SRE 백본)	커널 다이렉트 12블록 슬롯 배열 속성 (Direct 렌더 뷰)	다중 간접 트리 (Indirect 530장 예고 톨게이트 늪)
통계적 점유 (파일 개수의 80~90% 마스킹 배정 레이어)	`~48KB` 미만의 아주 작은 쉘 스크립트, 소스 코드, 설정 파일(`nginx.conf`)들 수만 개가 리눅스 생태.	`48KB` 이상 용량의 몇몇 소수의 거대한 데이터베이스 테이블 캐싱 덩어리나 미디어 파일들.
I/O 레이턴시 최적화 튜닝 (Speed Vs Search Overhead 부스트)	90% 파일들이 이걸 타므로 디스크 1번 탐색(Data Block 직행) 만에 스루풋 처리! 전체 OS 체감 속도 향상 폭발!	속도는 2~3배 지연 모터 늪에 빠지나, 저장 용량을 기가, 테라바이트급으로 무한 스왑 팽창 록백 수용 보장.
메모리(RAM) 낭비 공간 딜레마 (Internal Fragmentation 결속)	내 파일이 1KB(블록 1개 슬롯 사용)일지라도 무조건! "나머지 놀고 있는 11개 슬롯 배열 허공 공간은 영구 버려짐(구조체 공구리 낭비 슬픔)."	동적 포인터이므로 필요할 때만 인덱스 블록을 하나 파서 매달면 그만! 낭비가 덜함 다형성 포팅 융합.

2. 공간 효율의 아킬레스건: 고작 12칸? 48KB따리 한도 초과 에러 폭파 (Overflow 늪)

"속도가 빠르다고? 그럼 다이렉트(Direct) 배열 칸을 12칸 말고 1,000칸으로 쫙 늘려버리면 만능 무결 스피드 I/O 뼈대가 되잖아?" $\to$ 이건 C언어 커널 메모리 아키텍처를 벼랑 끝으로 미는 OOM 파탄 소리다.

안티패턴 오염 폭파 (i-node 비대화와 RAM 식충이 멸망 데들락):
- 1개의 i-node 객체 크기는 보통 파일 시스템을 포맷할 때 256 바이트 (혹은 128B) 로 사이즈를 정확히 고정(Fixed Size 공구리 록백) 시켜 수천만 개를 양산해 둔다(528장 i-node 고갈 한계).
- 근데 다이렉트 포인터 배열을 1,000칸으로 늘리려면? 포인터 1줄당 4바이트 니까 $1000 \times 4B = 4000B (4KB)$! 이 무거운 배열 덩어리를 256 바이트짜리 i-node 1개 뱃속 구조체 안에 집어넣으려면 i-node의 기본 용량 자체를 무식하게 스로틀 10배 이상 키워야 터지지 않는다!
- 그럼 디스크 공간 앞쪽에 포맷 시 박아두는 i-node 1,000만 개의 총용량이 디스크를 기가바이트(GB) 단위로 다 처먹어버리는(메타데이터 쓰레기장 RAM OOM 식충 폭발) 환멸적 재앙 늪에 빨려든다.
SRE 극복 솔루션 패치 타결 (황금 비율 Golden Ratio : 고작 12개 스왑 컷):
- 데브옵스 엔지니어들은 이 극도의 딜레마 속에서 뼈를 깎는 타협을 도출 결착했다.
- "i-node 구조체 본체 크기는 가볍고 예쁘게 256 바이트로 고정하라! 그리고 메타데이터(권한시간) 쓰고 남은 자투리 여백에! 포인터 칸을 딱 15칸(Direct 12개 + Indirect 3개 짬뽕 뷰)만 할당해서 예쁘게 OOM 터짐 방지 수납을 완료 렌더 마스킹해라 통달!!"
- 이 고작 15칸이라는 기형적이고 절묘한 숫자. 이것이 바로 리눅스 시스템이 메모리를 극도로 아끼면서도, 세상 파일의 90% (48KB 이하)를 초광속으로 치워버리는 우주 궁극 설계 최적화 스펙의 근간 트리로 자리매김 빔을 쏜 것이다 증명 완료.
📢 섹션 요약 비유: 이 다이렉트 블록 개수 확장의 OOM 메모리 낭비 제약 포팅 뷰는 식당 메뉴판 상단의 "오늘의 베스트 식사 메뉴 12선(12 Direct) 한정 강제 제한 록백!" 랑 100% 동일 오류입니다!!
- 사장님이 "아 손님들 빨리 고르게 메뉴판 앞장에 베스트 메뉴 100개 다 넣을까?(다이렉트 포인터 1,000개 확장 뻘짓)" 고민합니다!
- 근데 메뉴 코팅지(256B i-node 제한 규격) 크기가 작아서 100개를 다 타이핑하면 글씨가 터져버려 넘칩니다(OOM 멸망 오버플로우)! "아 씨.. 할 수 없다. 메뉴판 앞장엔 가장 잘 팔리는 찌개, 볶음밥 딱 12개 베스트(12 Direct 블록!) 만 심플하게 적어 스왑 빔! 손님 90%는 이것만 보고 1초 만에 시키니까 겁나 빨라(다이렉트 타격 $O(1)$) 보장! 나머지 10% 희귀 메뉴는 뒷장 메뉴판(인다이렉트 점프 타임아웃 지연) 열어 보라고 넘겨 거시 컷 타결!!" 이 작은 마법의 제한이 결국 대기 줄(레이턴시)을 쾌적 제로로 소멸시킨답니다!

Ⅲ. 실무 융합 적용 및 안티패턴 (Direct I/O 부스트 튜닝과 조각 모음)

ext 로그 서버(Log Server)의 최적화 : "다이렉트 안에서 놀게 파일을 잘라 스왑(Log Rotation SRE)"

서버의 로그가 무한정 뚱뚱해져 48KB 를 초과하면? 이 12개짜리 다이렉트 황금 차선을 벗어나 "간접 트리 톨게이트 병목(Indirection 지연 모터 늪)" 을 타게 되며, 파일 쓰기 속도(I/O Write Throughput)가 급격히 하락 침몰한다.

안티패턴 현상 충돌 미스터리 (뚱뚱한 파일의 다중 트리 렉 스로틀 데들락):
- Nginx 웹서버 접근 로그 파일(access.log)을 1년 내내 백업 포팅 없이 그대로 방치했다. 용량이 5GB가 되었다.
- 새로운 로그 텍스트를 끝에 밀어넣을 때(Append) 커널은 145번 i-node의 Double Indirect 트리 나 Triple Indirect 트리 를 매번 3번, 4번씩 긁으며 디스크 트리를 타고 꼬리를 추적 탐색 쫓아가는 $O(N)$ 의 극악 타임아웃 레이턴시 비용을 쓰며 디스크 병목 스로틀(Disk I/O 100% Wait 파탄 멸망)을 일으켜 서버 전체를 기어 다니게 만든다!
SRE 폭증 진단과 해결 아크 (Log Rotation 로그 팽창 컷 찢기 타결 및 융합 통달):
- 경험 많은 리눅스 SRE 엔지니어는 절대! 절대! 로그 파일이 뚱뚱해져 다이렉트 레인(Direct Blocks 고속망 우주 부스트) 권역을 벗어나 트리 늪으로 빠지게 놔두지 않는다 포팅 결속!
- 엔지니어는 리눅스 백그라운드 크론 데몬 서버 봇 프로그램 logrotate 시스템 스위칭 마스킹을 발동시킨다! "야 로그봇아! 매일 자정 12시 땡! 치면? 20KB가 된 저 로그 파일을 칼같이 절단 잘라 분리하고(access.log.1 달아 아카이빙 복사 컷), 0바이트짜리 신선한 access.log 다이렉트 전용 초경량 객체 장부 뼈대 파일을 새로 파서 빔 생성해 결착 타격!"
- 이렇게 매일 파일을 토막 쳐 가볍게 소형화 유지시키면, 이 불쌍한 파일 덩어리 구조 객체는 365일 내내 무결한 12개의 Direct Block 고속 스로틀 하이패스 레인 위에서만 놀게 되어 인덱스 트리를 타는 지연 병목 파이프를 영원히 회피 피해 도축시켜 버리는 클라우드 트래픽 OOM 극복 최적화 신공이 발현 성취된다 보장! (이게 바로 쪼개기의 미학 시스템 결론.)

파일 I/O 시스템 로딩 렌더 (로그 팽창 부하율 Rate)	5GB 통짜 파일 (Indirect 트리 스택 늪 파탄 멸망)	10MB 분할 파일 수백 개 (Direct 마스킹 컷 타결 고속 융합)
정량 (물리 데이터 탐색 디스크 블록 읽기 히든 오버헤드 구조)	파일 끝 위치를 찾기 위해 인덱스 트리 노드들을 디스크에서 3번 연속 긁어 읽음 에러 늪.	단 1개의 i-node 다이렉트 10번째 배열 슬롯 빔 쏘면? 0.1초 만에 디스크 타격 $O(1)$ 스왑 종결!
정성 (자원 시스템 안정 데들락 부하 및 I/O Wait 병목 비율 뷰)	Disk I/O Wait 수치가 치솟아 CPU가 대기 상태로 노는 최악 OOM 병목 발진 서버 터짐!	디스크 헤드가 춤을 안 추니까, SSD/HDD 수명이 보존 쾌적 연장되며 수천 트래픽 무적 스펙 소화 보장 락!

Ⅳ. 기대효과 및 결론

'i-node 직접 블록 (Direct Blocks 12개 오프셋 배열 마법 캐싱 스로틀)' 아키텍처는 유닉스 계열 파일 시스템이 그토록 극단주의적 다형성 트리 혼합(다중 수준 트리 527장)이라는 복잡한 장부 결합 우주를 쓰면서도 속도 논란(느려터진 포인터 추적 레이턴시 병목 랙)을 모조리 찍어 누르고 극강의 승리 S/W 권좌를 차지하게 만들어 준 가장 소박하고도 위대한 "예외적 지름길 하이패스 렌더(Fast-Path Optimization)" 맵이다.
단 12~15개(OS별 상이 뼈대)의 C언어 제한된 고정 크기 Array 슬롯을 i-node 객체의 정중앙 흉부에다 강제로 박아둠(Static 공구리 록백 증거)으로써, 전체 우주 생태계 파일 개수의 90%를 차지하는 48KB 남짓한 먼지 파일들이 무거운 2차 트리 계층 인덱스를 밟지 않고도 곧장 I/O 모터 다이브를 때릴 수 있게 극단적 $O(1)$ 레이저 스피드를 쟁취 성취했다 결론 파싱. 비록 "파일이 거대해져 13번째 블록 데이터 조각" 을 쓰게 될 때는 눈물을 머금고 끔찍한 간접 블록(Indirect Block 트리 늪의 입구 개방!)의 굴레 속으로 점프 떨어지지만, 데브옵스 SRE 운영에 있어서는 "얼마나 많은 자원을 그 한도 내에 찢어 분리 욱여넣느냐(Logrotate 튜닝 결속)" 의 극강 실시간 묘수 철학 시스템 뷰를 영원히 남겨준 위대한 마스킹 렌더로 증명 부합된다.
📢 섹션 요약 비유: 요약하자면, 이 다이렉트 12블록 고속 컷 스왑 통치 뷰는 거대 워터파크의 "프리패스 고속 슬라이드 12개 프리존 선착순 탑승 마스킹!" 랑 100% 동일 오류 극복률입니다!!
- (다이렉트 프리존 장점 모터 점프) 몸가벼운 손님(48KB 미만 텍스트 미니 파일)이 딱 들어왔어요! 직원이 "오, 덩치 작고 가볍네? 복잡한 3단 계단(3중 트리 뺑뺑이) 올라가지 마시고요! 여기 입장권(i-node)에 적힌 바로 코앞 다이렉트 직행 1번 짧은 미끄럼틀 타고 $O(1)$ 광속 레이저 입수 다이빙 치세요 다이렉트 스피드 부스트 우앙!!"
- (한계 직면 트리 전환 렌더 슬픔) 그런데 몸무게 100kg 거구 손님(수십 기가 뚱뚱이 대용량 미디어 데이터)이 나타났어요 팽창 오버플로우!! 직원이 "헉! 이 다이렉트 12개짜리 약한 미끄럼틀 타면 고객님 무게 때문에 코팅지가 부서져 무너집니다(용량 초과 오버플로우)! 무겁고 힘드시더라도(지연 랙 모터 병목), 안전 튼튼 대형 멀티 슬라이드 트리(Indirect 블록 간접 톨게이트 늪) 3층 계단으로 돌아서 뺑뺑이 걷기 운동 등반 다이브 하셔야 탑승 OOM 안 나고 안전 수용됩니다 에러 파쇄!!" 이렇게 덩치(파일 크기 트레이드오프)에 따라 스피드 특혜와 공간 수용의 길을 완벽 분기 타결 마스킹 지어버리는 S/W 놀라운 융합 룰의 철학이랍니다!

📌 관련 개념 맵 (Knowledge Graph)

전조 지식 확장 설계 파편 단위	관계 통찰 설명 (진단 아크 체제 방어 부합 타격)
유닉스 i-node 메커니즘 전반 (바로 전 장 528번 뼈대와 직결 유전자)	이 Direct 슬롯 12개 칸막이 배열은, 아이노드의 심장(포인터 구역)에서 가장 첫 번째 줄에 박혀있는 전위 부대 핵심 무적 고속 스로틀이다. 메타데이터(크기 정보 등) 바로 밑에 딱 붙어서 1초 만에 철판 디스크로 모터를 직행시키는 영혼의 융합 SRE 구조.
단일/이중/삼중 간접 블록 (직속 다음 장 530번 우주 팽창 트리 브랜치 늪 폭쇄)	12번째 다이렉트 칸이 모두 꽉꽉 채워져 오버플로우 폭발 용량 멸망을 직면한 순간! 드디어 등장하는 최악의 레이턴시 오버헤드 늪이자 무한대 공간 수용 우주 팽창 부스트 뼈대! Indirect 트리가 어떻게 다이렉트 다음 블록 칸을 이어서 트리 팝업을 파생 생성하는지 연결 결속 컷 맵.
혼합 색인 Combined Index (527장 하이브리드 인덱스 마법 스왑)	1단계와 2단계 트리를 왜 잡종 짬뽕 시킬까 의문이었던 527장의 해답이 여기서 증명됐다! 대부분 파일이 12블록 수준의 피라미 찌꺼기들이니까 장부 낭비 세금 오버헤드 막으려고 가차 없이 이 다이렉트 구조를 융합 혼조 스위칭 시켜 벤치마킹 타결을 본 것 포팅 확정 설계도!
TLB 고속 캐시 버퍼 (메모리 7단원 MMU 징검다리 쾌속 우회 $O(1)$ 통달 기전)	메모리 병목 배울 때 "페이지 테이블 다 짚고 넘어가면 느리니까 버퍼 하이패스 TLB 캐시에 번호 찍어두고 $O(1)$ 1방 타워 록백 스킵하자 쾌적!" 이랑 소름 돋게 비슷한 논리! 긴 트리를 안 타고 단방에 번호표 보고 주파하는 Fast-Path 특권 최적화 튜닝 S/W 철학이 그대로 디스크 i-node 에 쌍둥이 수복 복제됨.

👶 어린이를 위한 3줄 비유 설명

똑똑한 유닉스 공룡은 컴퓨터 하드디스크 창고에 주소록 딱지 "아이노드(i-node 장부)" 를 만들 때, 처음 딱 12줄 빈칸 배열에 "초광속 하이패스 전용 직통 다이렉트 주소록 자리($O(1)$ 속도 빔)" 를 만들어 줬어요!
컴퓨터에 깔려있는 아주 작고 가벼운 메모장 내용 파일 조각들(90% 대부분)은 이 12줄 미니 다이렉트 칸 안에 쏙쏙 주소를 넉넉히 다 적을 수 있답니다 다이렉트 렌더 스왑! 그러면 복잡하고 뱅글뱅글 돌아가는 거대한 미로 트리(간접 톨게이트 병목)를 안 거치고, 눈빛만 번쩍! 하고 디스크에 다이브 꽂아서 1초 만에 파일을 꺼내올 수 있어요 I/O 극강 부스트!!
치명적 슬픔 발생 멸망! 영화같이 조각이 수십만 개 나오는 뚱뚱이 거인 대형 파일은 이 12줄 요약 포인터 칸에 주소를 다 적다가 튕겨 넘쳐 종이가 터져 오버플로우 에러가 납니다!! 어쩔 수 없이 다스스 긁히는 느림보 거북이 복잡한 우회 미로(간접 트리 530장 구조)를 타서 수십 번 길을 물어물어 찾아야 용량을 전부 큰 그릇에 수용 소화 담아낼 수 있는 트레이드오프(저울질 공간 타결) 마법 스위칭 록이 발동된답니다!