크래프톤 정글 — Week 7 WIL

 

크래프톤 정글 · 주간 회고

크래프톤 정글 — Week 7 WIL

 

이번 주는 구현을 더 많이 했다기보다, 지금 보고 있는 구조를 설명 가능한 상태로 끝까지 밀어붙인 주에 가까웠다.
malloc은 빈 공간을 찾는 함수 묶음이 아니라 탐색 경로를 설계하는 문제처럼 보이기 시작했고, CS:APP 9장은 그 allocator가 결국 어떤 가상 메모리 바닥 위에 놓이는지 연결해 줬다. Mini SQL 쪽에서는 B+Tree와 디스크 persist, 성능표 해석을 다시 보면서 인덱스가 자료구조이면서 동시에 저장장치 문제라는 것도 더 또렷해졌다.

이번 주를 한 줄로 정리하면

지난주 WIL이 상태 정의와 실행 구조를 보는 감각을 붙잡는 시간이었다면, 이번 주는 그 감각을 메모리 관리와 저장 구조 쪽으로 더 깊게 밀어 넣은 주였다. Malloc Lab은 implicit free list에서 explicit free list, 그리고 segregated free list로 가면서 결국 힙을 어떻게 순회할지보다 탐색을 어디서 시작하고 어떤 메타데이터를 남길지의 문제로 읽히기 시작했다. CS:APP 9장은 페이지 테이블, TLB, 메모리 매핑을 통해 allocator가 올라가는 운영체제의 바닥을 정리해 줬고, Mini SQL 쪽에서는 B-Tree와 B+Tree의 차이를 다시 보며, 결국 데이터베이스 구현은 파서나 문법보다도 인덱스를 어떤 저장 모델 위에 올려둘 것인지가 더 오래 남는 문제라는 걸 다시 확인하게 됐다. [지난주 WIL] [189] [190] [191] [192] [193] [Study Repo]

🧭 이번 주 학습 축

Malloc Lab 구현 시리즈

implicit free list → explicit free list → segregated free list로 옮겨가며 빈 블록 관리 방식과 탐색 시작점이 어떻게 달라지는지 글과 코드 둘 다로 다시 정리했다. 마지막에는 실습 레포의 현재 mm.c가 범용 segregated free list allocator 쪽으로 이미 많이 나아가 있다는 것도 확인했다.

CS:APP 9장 정리 시리즈

가상 주소, 페이지 테이블, TLB, 페이지 폴트, 메모리 매핑, 9.9절 allocator를 한 흐름으로 다시 묶었다. 특히 “malloc이 운영체제가 주는 페이지 위에서 어떤 층을 맡는가”를 스스로 설명 가능하게 만드는 데 시간을 많이 썼다.

Mini SQL · B+Tree 심화 읽기

팀 결과물과 개인 persist 관점을 다시 비교하면서, 왜 결국 B+Tree가 인덱스의 중심에 남았는지, 성능표를 읽을 때 warm cache와 cold cache를 어떻게 구분해야 하는지, 그리고 “돌아가는 구현”과 “설명 가능한 구현” 사이의 간격이 어디서 생기는지를 더 구체적으로 봤다.

문제해결

이번 주 문제해결에서 가장 크게 남은 건, allocator를 더 이상 “함수 다섯 개가 서로 부르는 구조”로만 보지 않게 됐다는 점이다. 1편 글에서는 implicit free list와 boundary tag, split, coalesce를 함수별로 따라갔지만, 실제로 머리에 더 오래 남은 질문은 왜 free block을 힙 전체에서 찾게 만들었는가, 왜 false fragmentation이 생기며 coalesce는 왜 꼭 상수 시간이어야 하는가 쪽이었다. 2편과 3편으로 넘어가면서는 explicit free list와 segregated free list가 사실 “더 좋은 자료구조를 쓴다”보다 탐색 대상을 힙 전체에서 free block으로 줄이고, 다시 size class별 입구로 나누는 과정처럼 보였다. 결국 문제를 푼다는 건 코드를 몇 줄 바꾸는 일이 아니라, 시스템이 무엇을 매번 전부 보고 있었고 무엇을 이제는 안 보게 됐는지 설명하는 일이었다. [Implicit] [Explicit] [Segregated]

CS:APP 9장도 비슷했다. 처음엔 “MMU가 번역한다”, “TLB가 빠르게 해 준다” 같은 문장을 외우는 쪽에 가까웠는데, 이번에는 페이지 테이블이 DRAM에 있는데 왜 또 TLB가 필요한지, 유효 비트가 0일 때 왜 캐시되지 않음과 비할당됨이 갈리는지, 가상 메모리가 결국 디스크와 RAM 사이를 어떻게 관리하는지를 질문-답변 형태로 끝까지 밀어붙였다. 그래서 이번 주 문제해결은 계산식 자체보다, 상태 구분을 하나씩 정확히 세우는 쪽으로 더 많이 기울었다. [CSAPP 9장 정리]

설계

이번 주 설계에서 가장 선명했던 장면은 탐색 공간을 어떻게 줄일 것인가였다. implicit free list는 단순하지만 할당된 블록까지 함께 보게 되고, explicit free list는 free block만 따로 엮어 전체 순회를 줄인다. segregated free list로 넘어가면 여기서 한 단계 더 나아가, free list 하나만 빠르게 만드는 것이 아니라 요청 크기에 따라 들어갈 입구 자체를 다르게 배정한다. “자료구조를 바꿨다”보다 “탐색 시작점을 바꿨다”는 표현이 더 맞는 순간이 이번 주에는 꽤 자주 있었다.

이 감각은 Mini SQL/B+Tree 글을 정리하면서도 그대로 이어졌다. B-Tree와 B+Tree의 차이를 단순 요약으로 끝내지 않고, 왜 결국 실제 인덱스는 B+Tree가 더 많이 남았는지, 왜 leaf scan과 range query가 중요해지는지, 그리고 팀 레포와 개인 persist 관점이 무엇을 서로 다르게 강조하는지를 다시 보게 됐다. 인덱스는 “탐색 속도가 빠르다”는 말로 끝나는 구조가 아니라, 저장 장치 위에서 순차 접근과 갱신을 어떤 비용으로 감당할지를 설계하는 문제로 남았다. [Mini SQL / B+Tree]

실습 레포를 보며 설계 쪽에서 특히 남은 부분
현재 레포의 malloc-lab/mm.c 상단 설명만 봐도 이미 “범용 segregated free list allocator”, “prev_alloc 비트”, “allocated block footer 제거”, “offset 기반 explicit free list”, “제자리 realloc” 같은 키워드가 붙어 있다. 즉 이번 주 흐름은 교재의 기본 구현을 읽는 수준에서 끝난 게 아니라, 실제 실습 파일 안에서 메타데이터 비용과 탐색 정책까지 더 미세하게 만지는 단계로 넘어간 셈이었다. [mm.c]

구현

구현 쪽에서는 “새 기능을 하나 더 붙였다”보다, 이미 있는 흐름을 정확한 언어로 다시 쓰는 일이 더 크게 남았다. allocator 글 3편을 쓰는 동안에는 mm_init, extend_heap, find_fit, place, coalesce 같은 함수들이 서로 어떤 메타데이터 약속 위에서 움직이는지를 코드 흐름 중심으로 다시 적었다. 글을 쓰기 위해 그림도 다시 그렸고, SVG가 깨지면 plain HTML 블록 도해로 내려가며 설명 방식을 바꾸기도 했다. 이번 주 구현은 코드만의 문제가 아니라, 코드 흐름을 독자가 실제로 따라갈 수 있게 다시 조립하는 문제이기도 했다.

CS:APP 9장 글도 비슷했다. 단순 요약이 아니라, 책을 읽으며 실제로 걸렸던 질문을 남기는 방식으로 정리하다 보니 “PTE는 어디에 저장되는가”, “TLB는 왜 필요하며 페이지 테이블은 왜 DRAM에 있는가”, “메모리 매핑은 왜 공유 객체와 연결되는가” 같은 문장들이 결국 allocator와 다시 이어졌다. 이번 주 구현은 코드와 글이 분리되지 않았다. 코드를 이해한 뒤 글을 쓴 게 아니라, 글을 쓰는 과정에서 구현 경로가 더 선명해진 쪽에 가까웠다.

협업

이번 주 협업에서 더 크게 남은 건 구현 속도보다 구조를 같은 이름으로 부르는 일이었다. Mini SQL 쪽은 팀 레포와 개인 관점을 함께 읽으면서, tokenizer, parser, executor, storage, index 같은 단어를 같은 의미로 맞추지 않으면 결국 성능표나 구조 비교도 제대로 대화가 안 된다는 걸 다시 느꼈다. 특히 팀 결과물과 개인 persist 관점을 비교한 분석 문서를 보면, “지금 보고 있는 차이가 파서 계층의 차이인지, B+Tree 노드 설계의 차이인지, 저장 모델의 차이인지”를 같은 문장으로 구분해 말하는 일이 협업의 시작점처럼 보였다.

allocator 쪽도 마찬가지였다. implicit, explicit, segregated라는 말을 정확히 구분하고, “이번 변경이 힙 전체 순회를 없애는 일인지”, “free list를 여러 개로 나누는 일인지”, “footer를 언제 남기고 언제 지우는지”를 같은 언어로 말할 수 있어야 코드 리뷰도 덜 흔들린다. 이번 주에는 협업이 역할 분담보다 먼저 용어를 붙들고 구조를 같은 해상도로 보는 일처럼 남았다. [Repo]

📊 핵심 역량별 WIL

1️⃣ 문제해결 (Problem Solving)

정의: 주어진 문제를 정의하고 논리적으로 해결하는 능력

목표: allocator와 가상 메모리 문제를 함수 이름이나 용어 암기로 보지 않고, 상태 전이와 탐색 경로 문제로 읽는다.

이번 주에는 malloc을 “메모리를 준다”는 인터페이스가 아니라, free block을 어떤 기준으로 찾고, 남는 공간을 어떻게 쪼개고, 붙어 있는 블록을 언제 다시 합칠 것인가의 문제로 다시 봤다. CS:APP 9장 쪽도 마찬가지였다. 유효 비트, 페이지 테이블, TLB, 페이지 폴트 같은 키워드는 결국 “지금 이 페이지는 어디에 있고, 누가 그걸 알고 있으며, 왜 느려지지 않는가”를 단계별로 나누는 문제로 남았다.

이번 주에 더 분명해진 것: 이번 주에는 코드를 다 읽었다는 느낌보다, 그 코드가 어떤 상태를 기준으로 갈리는지 설명할 수 있을 때 비로소 이해했다는 느낌이 들었다.

💡 이번 주에 자꾸 걸린 장면
→ false fragmentation과 coalesce의 필요성을 설명하려면 결국 “왜 이 두 free 블록을 아직 하나로 못 보는가”를 말할 수 있어야 했다.
→ TLB가 왜 필요한지 설명하려면 페이지 테이블이 어디 있고 왜 거길 매번 갈 수 없는지부터 다시 말해야 했다.

2️⃣ 설계 (Design)

정의: 효율적이고 확장 가능한 시스템 구조를 기획하는 능력

목표: 탐색 비용과 메타데이터 비용을 같이 보며, 어디서부터 구조를 쪼개야 하는지 판단한다.

implicit → explicit → segregated로 넘어가는 흐름은 이번 주 설계의 핵심 장면이었다. 바뀐 건 free list 개수가 아니라, 시스템이 “어디부터 탐색을 시작할지”를 다시 설계한 것이다. Mini SQL/B+Tree 쪽에서도 비슷했다. B+Tree는 더 복잡한 자료구조라서가 아니라, 실제 인덱스 workload와 저장 장치 특성 위에서 더 자연스럽게 남는 구조로 읽히기 시작했다.

이번 주에 더 분명해진 것: 설계는 기능을 많이 넣는 일이 아니라, 어떤 비용을 안 보게 만들지 결정하는 일에 더 가까웠다.

💡 이번 주에 자꾸 걸린 장면
→ explicit free list는 “자료구조 업그레이드”보다 “힙 전체를 안 보게 만드는 설계”로 보였다.
→ B+Tree 비교도 결국 range scan과 저장 모델을 같이 보지 않으면 설계 얘기가 공중에 뜨는 느낌이 강했다.

3️⃣ 구현 (Implementation)

정의: 설계된 내용을 실제로 동작하는 코드로 옮기는 능력

목표: 함수 경로와 중간 메타데이터가 실제로 어떻게 바뀌는지 끝까지 따라간다.

이번 주 구현은 새 알고리즘을 많이 추가했다기보다, 이미 있는 구현의 내부 흐름을 정확한 언어로 복원하는 일에 가까웠다. allocator 3편을 쓰는 동안 블록 헤더, 풋터, prev_alloc 비트, split, coalesce, segregated list bucket이 실제 코드에서 어떤 순서로 바뀌는지 다시 추적했다. 실습 레포의 현재 mm.c는 이미 범용 segregated allocator 방향으로 확장되어 있어서, 이번 주 구현 감각은 교재 복사보다 “기본 모델에서 얼마나 더 멀리 갔는가”를 읽는 데도 연결됐다.

이번 주에 더 분명해진 것: 구현은 결과가 돌아가는 순간보다, 중간 메타데이터가 왜 그렇게 바뀌는지 내가 직접 복원할 수 있을 때 비로소 손에 들어왔다.

💡 이번 주에 자꾸 걸린 장면
→ place와 coalesce는 함수 하나 설명이 아니라 상태 전이 전체를 같이 설명해야 했다.
→ CSAPP 9장 글도 요약보다 질문-답변형으로 풀어야만 이해가 붙었다.

4️⃣ 품질 (Quality)

정의: 버그 없는 안정적인 코드 및 검증 습관

목표: 정답 여부보다 먼저 경계 조건과 오해하기 쉬운 상태를 분리한다.

allocator에서는 작은 메타데이터 오해 하나가 전체 힙 붕괴로 이어진다. allocated block footer를 없애는 최적화, prev_alloc 비트 유지, free block 삽입/삭제 순서 같은 부분은 성능보다 먼저 일관성을 요구하는 영역이었다. Mini SQL 쪽에서도 성능 측정은 수치를 뽑는 것보다, 지금 본 표가 bind mount 영향인지 warm cache 영향인지 구분하는 쪽이 더 중요하게 남았다.

이번 주에 더 분명해진 것: 이번 주에는 큰 버그보다 “상태를 잘못 이름 붙이는 것”이 더 위험하게 느껴졌다.

💡 이번 주에 자꾸 걸린 장면
→ “유효 비트 0” 하나로 캐시되지 않음과 비할당됨을 같이 보면 설명이 바로 무너졌다.
→ allocator 성능도 수치만 보고 해석하면 설계 판단이 틀어지기 쉬웠다.

5️⃣ 유지보수 (Maintenance)

정의: 가독성이 좋고 수정이 용이한 코드와 문서를 남기는 능력

목표: 나중에 다시 봐도 구조가 바로 복원되는 기록을 남긴다.

이번 주에는 공부 자체보다 정리물이 유지보수 감각을 더 강하게 건드렸다. allocator 글을 1편, 2편, 3편으로 나누어 쓰면서 어떤 변화가 함수 단위로 일어났는지 남기지 않으면 이후 단계에서 왜 이 선택을 했는지 금방 잊히는 구조라는 걸 느꼈다. CSAPP 9장 글도 질문을 따라가며 정리해 두니 다음에 다시 봤을 때 “내가 어디서 막혔는지”가 구조로 남는다.

이번 주에 더 분명해진 것: 설명 가능한 글이 남아 있으면 코드도 다시 읽히지만, 설명 순서가 안 잡히면 구조 이해도 함께 흐려진다.

💡 이번 주에 자꾸 걸린 장면
→ allocator 그림을 다시 그리려니 교재 그림을 이해한 것과 내 언어로 복원하는 것은 다른 일이라는 게 드러났다.
→ 함수 하나를 글로 설명 못 하면 나중에 코드도 다시 오래 봐야 한다는 감각이 더 강해졌다.

6️⃣ 협업 (Collaboration)

정의: 팀원과 같은 구조를 보고 같은 언어로 설명하는 능력

목표: 구현 전에 구조 용어와 해석 기준을 먼저 맞춘다.

이번 주에는 역할 분담보다 먼저 용어가 중요하게 남았다. Mini SQL 쪽에서 parser, storage, index, trace, demo 같은 단어를 같은 뜻으로 쓰지 못하면 비교 문서도 성능표도 금방 흐려진다. allocator 쪽도 implicit, explicit, segregated, prev_alloc, footer 제거 같은 단어가 정확히 맞아야 코드 대화가 된다.

이번 주에 더 분명해진 것: 협업은 속도보다 먼저 해상도를 맞추는 일에 가까웠다.

💡 이번 주에 자꾸 걸린 장면
→ “SQL 성능이 안 좋다”보다 “이 표는 storage보다 캐시 조건 차이를 더 많이 먹었다”라고 말할 수 있어야 대화가 붙었다.
→ allocator도 “좀 더 빠르게 만들자”보다 어떤 탐색 경로를 없애는지 먼저 말해야 논의가 선명해졌다.

7️⃣ 태도 (Attitude)

정의: 자기주도적으로 질문을 깊게 밀어붙이는 태도

목표: “대충 이해한 것 같다”에서 멈추지 않고, 막힌 문장을 끝까지 정리한다.

이번 주엔 특히 “왜?”를 너무 오래 붙든 것 아니냐는 생각이 들 정도로, 사소해 보이는 질문들을 끝까지 따라갔다. MMU를 왜 굳이 쓰는지, TLB는 왜 필요한지, footer는 왜 필요한지, segregated free list에서 size class를 왜 나누는지 같은 질문이 계속 다시 나왔다. 그런데 오히려 그 반복 덕분에 이번 주 내용이 한 묶음으로 남았다.

이번 주에 더 분명해진 것: 설명이 막히는 지점을 그대로 두면, 나중에 더 큰 구조를 볼 때 다시 같은 데서 막힌다.

💡 이번 주에 자꾸 걸린 장면
→ “이건 그냥 그런가 보다”라고 넘기려던 부분이 결국 글을 쓸 때 다시 제일 크게 걸렸다.
→ 이번 주에는 이해보다 질문 지속 시간이 더 중요하게 느껴졌다.

8️⃣ 비즈니스 이해 (Business Understanding)

정의: 구현을 사용자와 설명 가능성의 관점에서 다시 보는 시각

목표: “동작한다”와 “남에게 납득시킬 수 있다”를 구분해 본다.

Mini SQL 글을 쓰면서 특히 크게 남은 건, 돌아가는 엔진 하나보다 그 엔진을 어떻게 보여주고 비교하고 설명할 것인가가 결과물의 질을 더 바꾼다는 점이었다. trace와 demo, 성능표의 읽는 법, in-memory 버전과 persist 버전의 차이를 분리해서 말할 수 있어야 구현이 단순한 실습을 넘어 결과물처럼 보이기 시작한다.

이번 주에 더 분명해진 것: 실제로 남는 건 기능 목록보다 구조를 어떻게 공개적으로 설명했는가 쪽이었다.

💡 이번 주에 자꾸 걸린 장면
→ 같은 성능표라도 독자가 오해 없이 읽을 수 있게 쓰는 일이 생각보다 훨씬 어려웠다.
→ 공부 글도 결국 “남이 이 흐름을 따라올 수 있는가”를 계속 묻게 됐다.

9️⃣ AI 활용 (AI Utilization)

정의: 도구의 속도를 활용하되 구조 판단은 직접 쥐고 가는 능력

목표: 빠른 정리 도구를 써도 핵심 개념과 그림 복원은 직접 검증한다.

이번 주 공부는 질문-답변형 정리 도구를 많이 쓰는 흐름과 닿아 있었지만, 실제로는 그 결과를 그대로 믿지 않고 다시 검증하는 시간이 더 길었다. 교재 그림을 그대로 쓰지 않고 다시 그린다거나, allocator 설명이 코드와 정확히 맞는지 다시 보는 작업은 결국 구조 판단을 내가 쥐고 있어야만 가능한 종류의 일이었다.

이번 주에 더 분명해진 것: 빠르게 정리된 문장보다, 그 문장을 그림과 코드에 다시 대입해 봤을 때 안 깨지는지가 더 중요했다.

💡 이번 주에 자꾸 걸린 장면
→ “설명은 그럴듯한데 실제 mm.c 흐름과 안 맞는 부분”을 다시 잡아내는 데 시간이 더 들었다.
→ 그림도 자동 생성보다 HTML에서 실제로 안 깨지는 형태로 다시 내려야 했다.

🔟 학습 민첩성 (Learning Agility)

정의: 넓게 흩어진 개념을 하나의 중심 질문으로 다시 묶는 능력

목표: allocator, VM, B+Tree를 서로 다른 장이 아니라 같은 질문 위에 놓는다.

이번 주 범위는 겉으로 보면 꽤 넓었다. malloc lab 구현, CSAPP 9장 정리, Mini SQL/B+Tree 회고가 한 주 안에 같이 있었다. 그런데 실제로는 “이 구조는 왜 이렇게 움직이고, 내가 그 중간 상태를 설명할 수 있는가”라는 질문 하나로 다시 묶였다. 그래서 allocator의 free list 설계와 페이지 테이블/TLB, 그리고 B+Tree leaf scan이 완전히 다른 얘기처럼 남지 않았다.

이번 주에 더 분명해진 것: 범위가 넓어도 질문이 하나로 묶이면 오히려 덜 흩어진다.

💡 이번 주에 자꾸 걸린 장면
→ allocator의 탐색 입구와 B+Tree의 탐색 경로가 스케일만 다를 뿐 비슷한 질문으로 남았다.
→ 운영체제 장과 실습 레포가 분리된 공부가 아니라 하나의 층위로 연결되기 시작했다.

체크리스트

이번 주 체크리스트는 “무슨 글을 몇 편 썼는가”를 남기는 용도가 아니다. 이번에는 각 묶음마다 어떤 질문으로 봤는지, 지금은 어떤 문장으로 이해하고 있는지, 다음에 다시 손으로 확인해야 할 남은 포인트가 무엇인지까지 같이 적어둔다. allocator는 구현 단계를 나누어 봐야 하고, CSAPP 9장은 장 전체를 층위별로 묶어야 하며, Mini SQL은 자료구조·스토리지·측정이라는 세 축을 같이 봐야 이번 주의 결이 선명해진다.

 

🧭 이번 주 학습 지형도

Allocator 구현 시리즈
implicit · explicit · segregated · 현재 seg allocator
메타데이터와 탐색 입구가 어떻게 바뀌는지 보기

CS:APP 9장 정리 시리즈
가상 주소 · 페이지 테이블 · TLB · mmap · allocator 연결
운영체제 바닥과 사용자 수준 할당기를 한 흐름으로 보기

Mini SQL / B+Tree 비교 시리즈
B-Tree vs B+Tree · 팀 결과물 · persist 관점 · 성능표 해석
인덱스를 자료구조와 저장장치 문제로 같이 보기

 

상태	분야	핵심 질문 · 이해 문장 · 남은 포인트	관련 글
✅	Implicit Free List	핵심 질문 헤더와 풋터, split, coalesce는 왜 같이 봐야 하는가? 이해 문장 implicit allocator는 “블록을 하나 찾는다”가 아니라, 헤더/풋터 메타데이터를 믿고 힙 전체를 징검다리처럼 건너뛰는 모델이었다. 남은 포인트 경계 태그 병합을 글로는 설명할 수 있지만, trace 기준 성능과 공간 효율을 숫자로 같이 비교하는 건 한 번 더 보고 싶다.	189
✅	Explicit Free List	핵심 질문 힙 전체 순회를 free block 순회로 줄이면 실제로 뭐가 달라지는가? 이해 문장 explicit free list는 단순히 포인터 두 개를 더 넣는 게 아니라, 시스템이 더 이상 alloc block을 볼 필요 없게 만드는 구조였다. 남은 포인트 LIFO 삽입과 주소순 삽입의 차이를 성능과 단편화 관점에서 더 또렷하게 비교해 보고 싶다.	190
🔁	Segregated Free List	핵심 질문 size class를 나누는 건 결국 어떤 비용을 줄이기 위한 선택인가? 이해 문장 segregated free list는 free list를 많이 만든 구조가 아니라, 요청 크기에 따라 탐색 입구를 미리 잘라 둔 구조로 이해됐다. 남은 포인트 현재 실습 레포의 일반화된 seg allocator와 교재 수준 segregated fit 사이에서 어떤 최적화가 실전적인 차이를 만드는지 더 뜯어보고 싶다.	191 mm.c
✅	CS:APP 9장	핵심 질문 allocator는 운영체제의 가상 메모리 위에서 정확히 어느 층을 맡는가? 이해 문장 페이지 테이블과 TLB는 주소 번역을 맡고, 메모리 매핑은 파일과 가상 주소 공간을 연결하며, malloc은 그 위의 힙 페이지를 다시 잘게 나누는 사용자 수준 할당기다. 남은 포인트 다중 레벨 페이지 테이블과 캐시 통합 쪽은 실제 하드웨어 그림과 같이 한 번 더 복습하고 싶다.	193
✅	Mini SQL / B+Tree	핵심 질문 왜 결국 B+Tree가 실제 인덱스 쪽에서 더 많이 남는가? 이해 문장 이번 주엔 인덱스를 탐색 알고리즘이 아니라 range scan, leaf 연결, 저장 모델, persist 전략까지 같이 보는 구조로 다시 읽게 됐다. 남은 포인트 in-memory 엔진과 디스크 persist 버전을 같은 조건에서 더 엄밀하게 비교하는 기준은 다음 주에도 계속 가져갈 것 같다.	192 vivecoding
🧪	성능 측정 해석	핵심 질문 지금 본 성능 수치가 진짜 구현 차이인지, 실험 조건 차이인지 어떻게 구분할 것인가? 이해 문장 이번 주 성능표는 숫자보다 조건 해석이 더 중요했다. bind mount, named volume, warm cache, cold cache를 분리하지 않으면 결과를 쉽게 과장하게 된다. 남은 포인트 측정 자동화와 실험 표준화는 다음에 더 체계적으로 잡아야 한다.	192

마무리

이번 주를 끝내고 보니, 구현이 더 편해졌다고 말하긴 어렵다. 오히려 allocator를 함수 집합으로 넘기지 못하게 됐고, 가상 메모리를 그림 한 장으로 적당히 덮어두기도 어려워졌고, Mini SQL의 성능표도 숫자만 보고 만족하기 더 힘들어졌다.

그래도 이번 주에 남은 건 분명하다. 이제는 “돌아간다”는 말만으로는 잘 안 넘어간다. 어디서 탐색이 시작되는지, 중간 상태를 누가 기억하는지, 그 구조를 내가 다른 사람에게 끝까지 설명할 수 있는지가 더 자주 걸린다. 아마 다음 주에도 새 기능보다 먼저, 그 설명 안 되는 부분이 다시 제일 크게 보일 것 같다.