크래프톤 정글 — Week 6 WIL

이번 주는 C 문제를 많이 풀었다고 적기엔 조금 다르게 남는다.
포인터를 어디에 다시 연결해야 하는지, 순회 순서를 왜 그렇게 잡아야 하는지, SQL 한 줄이 실제 파일 저장까지 어떤 단계로 흘러가는지를 계속 설명해야 했다.
돌아가기만 하면 됐던 구현이 이번 주에는 자꾸 설명 부족으로 걸렸다.

이번 주를 한 줄로 정리하면

지난주 WIL이 상태 정의와 실행 구조를 보는 감각을 붙잡는 시간이었다면, 이번 주는 그 감각을 더 작은 포인터 조작과 더 큰 SQL 처리 파이프라인 양쪽에 동시에 써본 주였다. 자료구조 C 실습에서는 연결 리스트, 스택/큐, 이진 트리, 이진 탐색 트리를 한 문제씩 손으로 구현하면서 연결과 순서 제어를 다시 봤고, Mini SQL 프로젝트에서는 개인 공부용 최소 엔진과 팀 결과물을 나란히 놓고 parser, storage, trace, demo 구조를 더 입체적으로 이해했다. 결국 이번 주를 묶는 질문은 하나였다. 이 구현은 왜 이 구조여야 하는가, 그리고 그 이유를 남에게 설명할 수 있는가. [지난주 WIL] [Source] [Source] [Source]

이번 글에서는 문제를 하나씩 나열하기보다, 이번 주 공부를 실제로 끌고 갔던 흐름들을 공개 블로그 기준으로 다시 묶어 보려고 한다. 자료구조 문제는 “연결을 어떻게 바꾸는가”와 “순서를 어떻게 제어하는가”로, Mini SQL은 “어디까지를 최소 구현으로 남기고 어디부터 구조를 쪼갤 것인가”로 다시 읽어보면 이번 주의 결이 훨씬 선명해진다.

🧭 이번 주 학습 축

자료구조 재배선 시리즈 연결 리스트 · 스택 · 큐 포인터와 보조 자료구조가 실제로 순서를 어떻게 바꾸는지 보기

트리 순회 시리즈 이진 트리 · 이진 탐색 트리 재귀와 반복, 방문 순서, 구조 판별을 한 묶음으로 보기

Mini SQL 구현 시리즈 개인 최소 엔진 · 팀 구조화 돌아가는 구현에서 설명 가능한 구현으로 무게 중심이 이동한 흐름

문제해결

이번 주 자료구조 실습에서 가장 크게 남은 건, 자료구조 문제를 “함수 하나 구현하기”가 아니라 “어떤 연결을 바꾸고 어떤 순서를 유지할 것인가”로 보기 시작했다는 점이다. 연결 리스트 7문제는 결국 삽입 위치를 찾고, 앞뒤 절반을 분할하고, 최댓값 노드를 앞으로 보내고, 재귀로 뒤집는 식으로 링크를 어떻게 다시 잇는지를 계속 묻고 있었다. 스택과 큐 문제도 비슷했다. 큐를 뒤집거나 괄호 균형을 검사할 때 핵심은 API를 외우는 일이 아니라, 스택을 보조 공간으로 두면 순서를 어떻게 뒤집을 수 있는지 이해하는 데 있었다. [Source] [Source] [Source] [Source]

트리 쪽으로 넘어가면 질문이 조금 달라졌다. 두 트리가 같은 구조인지, 높이는 얼마인지, 자식이 하나인 노드가 몇 개인지, 증손자가 있는 노드를 찾을 수 있는지 같은 문제는 결국 현재 노드 하나를 보고 끝나는 게 아니라 서브트리를 어떤 규칙으로 다시 읽을 것인가를 요구했다. 이진 탐색 트리 후반부에서는 중위/전위/후위 순회를 재귀 없이도 스택으로 구현할 수 있는지까지 이어졌고, 같은 순회라도 한 개 스택과 두 개 스택 버전이 왜 다른 감각을 주는지 비교하게 됐다. 이번 주 문제해결은 알고리즘 이름보다, 자료가 실제로 어떤 순서와 연결을 가지는지 설명하는 쪽에 더 가까웠다. [Source] [Source] [Source] [Source]

설계

이번 주 설계에서 가장 선명했던 대비는 Mini SQL 개인 버전과 팀 결과물이었다. 개인 레포를 다시 보면 설계의 첫 문장은 “무엇을 만들 것인가”보다 “무엇을 일부러 만들지 않을 것인가”에 가깝다. INSERT와 SELECT만 지원하고, CREATE TABLE은 빼고, 한 파일에 SQL 한 문장만 두며, 테이블은 이미 존재한다고 가정한다. tokenizer도 따로 두지 않고 cursor parser가 바로 키워드와 값을 읽는다. 저장도 catalog 없이 CSV 헤더를 스키마처럼 쓰는 단순한 row-store 구조다. 겉으로는 빠진 게 많아 보여도, 덕분에 입력 → 파싱 → statement → executor → CSV 저장이라는 최소 왕복 경로를 손으로 따라갈 수 있었다. [Source]

팀 레포는 여기서 한 단계 더 나간다. tokenizer, parser, AST, optimizer, executor, storage를 분리하고, trace와 demo를 통해 각 단계가 실제로 무엇을 내놓는지 보여준다. 그렇다고 무작정 복잡하게 키운 것도 아니다. 현재 구조를 AST-only로 두고, 설명에 필요한 만큼만 계층을 쪼갠다. 이 대비가 꽤 크게 남았다. 개인 버전이 “최소 엔진을 실제로 끝까지 돌린다”는 설계라면, 팀 버전은 “그 엔진이 어떤 단계를 거쳐 움직이는지 다른 사람도 읽을 수 있게 한다”는 설계였다. 이번 주에는 설계를 멋있는 추상 단계라기보다, 어디까지는 단순하게 남기고 어디부터는 구조를 분리할지 정하는 일로 더 자주 보게 됐다. [Source]

구현

구현 쪽에서는 “정답 함수 하나 만들기”보다, 그 함수가 실제 포인터와 순서를 어떻게 움직이는지 보는 쪽이 더 크게 남았다. 연결 리스트에서는 직접 새 노드를 끼워 넣기보다 기존 헬퍼 함수를 재사용하며 인덱스를 먼저 찾는 흐름이 보였고, 스택과 큐에서는 하나의 자료구조를 다른 자료구조 구현에 재활용하거나 보조 구조로 써서 순서를 바꾸는 감각이 반복됐다. 트리와 BST에서는 재귀로 푸는 버전과 반복문 + 스택으로 푸는 버전이 나란히 나오면서, 순회는 결과 문자열이 아니라 방문 순서를 어떤 도구로 보존하느냐의 문제라는 점이 더 선명해졌다. [Source] [Source] [Source] [Source]

Mini SQL 구현도 비슷했다. 개인 버전에서는 parser가 SQL 문자열을 손으로 따라가며 statement 구조체를 채우고, storage가 헤더 기준으로 row를 재배치해 append 하는 흐름을 직접 붙잡았다. 팀 버전에서는 여기에 trace와 demo가 더해지면서, token JSON과 statement JSON, executor 결과와 table snapshot까지 하나의 흐름으로 읽히게 만들었다. 이번 주 구현은 “코드가 된다”에서 끝나지 않고, 그 코드가 어떤 중간 구조를 거쳐 파일과 출력으로 이어지는지까지 같이 보는 쪽으로 더 기울었다. [Source]

협업

이번 주 협업에서 남은 건 속도보다 먼저 언어를 맞추는 일이었다. Mini SQL 팀 결과물에서 tokenizer, parser, AST, optimizer, executor, storage라는 단계 이름이 정리돼 있으니, 어디서 문제가 생겼는지를 이야기할 때도 훨씬 선명했다. “뭔가 SQL이 안 된다”가 아니라 “token은 잘렸는데 statement가 이상하다”, “executor 전까지는 맞는데 storage 반영이 이상하다”처럼 말할 수 있게 되는 순간부터 협업도 달라진다. 실제 구현보다 이 구조를 설명 가능한 형태로 나누는 과정이 협업의 질을 더 크게 바꾸는 장면처럼 느껴졌다. [Source]

자료구조 글 27개를 하나씩 정리한 경험도 비슷한 쪽으로 남았다. 같은 카테고리 안에서 문제를 한 줄로 설명하고, 핵심 함수와 체크 포인트를 다시 쓰다 보니 “나는 아는데 설명이 안 되는 부분”이 꽤 분명하게 드러났다. 혼자 구현한 코드라도 공개 글로 다시 적으면 설명되지 않는 부분이 남고, 팀 프로젝트에서는 그 설명 불가능한 부분이 곧 협업 비용이 된다. 이번 주에는 구현 그 자체만큼이나, 구현을 다른 사람도 따라갈 수 있게 분해하고 이름 붙이는 일이 계속 중요하게 보였다.

📊 핵심 역량별 WIL

1️⃣ 문제해결 (Problem Solving)

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

목표: 자료구조 문제를 함수 이름이 아니라 연결, 순서, 구조 규칙으로 읽는다.

이번 주에는 연결 리스트, 스택·큐, 이진 트리, BST 문제를 한 문제씩 풀면서 결국 같은 질문으로 다시 모이게 됐다. 어디를 다시 연결해야 하는가, 어떤 순서로 꺼내야 하는가, 현재 노드에서 어떤 서브트리 조건을 봐야 하는가가 핵심이었다. 특히 BST 후위 순회를 한 개 스택과 두 개 스택으로 각각 구현하면서, 결과가 같아도 내부 사고 과정은 다를 수 있다는 점이 더 크게 남았다. [Source] [Source] [Source]

이번 주에 더 분명해진 것: 이제는 문제를 풀고 나서도 값이 아니라 링크가 어디서 끊기고 다시 이어지는지, 순회 결과보다 그 순서를 어떤 도구로 만들었는지가 먼저 남는다.

💡 이번 주에 자꾸 걸린 장면
→ 연결 리스트 문제를 보면 값보다 next를 어디에 다시 잇는지부터 먼저 보게 됐다.
→ BST 후위 순회는 결과가 같아도 한 개 스택과 두 개 스택을 같은 풀이처럼 넘기기 어려워졌다.

2️⃣ 설계 (Design)

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

목표: 무엇을 만들지보다 무엇을 일부러 남길지 먼저 정한다.

Mini SQL 개인 버전에서 먼저 남은 건 범위를 강하게 자르는 설계였다. `INSERT`, `SELECT`, 한 문장 SQL, CSV 헤더 기반 저장, cursor parser 같은 선택은 화려하진 않지만 핵심 왕복 경로를 흐리지 않게 했다. 팀 결과물에서는 반대로 tokenizer, parser, AST, optimizer, executor, storage를 나눠서 설명 가능한 구조로 옮겼다. 이번 주 설계는 예쁜 구조를 찾는 일보다, 지금 단계에서 어떤 경계를 세워야 하는지를 정하는 일에 더 가까웠다. [Source]

이번 주에 더 분명해진 것: 개인 버전은 덜 넣을수록 전체 흐름이 또렷해졌고, 팀 버전은 단계를 나누자마자 대화가 쉬워졌다. 설계는 결국 욕심을 줄여 구조를 보이게 만드는 판단에 가까웠다.

💡 이번 주에 자꾸 걸린 장면
→ 개인 Mini SQL에서는 tokenizer를 먼저 넣기보다 cursor parser 하나로 끝까지 가는 쪽이 오히려 더 잘 보였다.
→ 팀 버전은 단계 이름을 나누고 나서야 “지금 어디까지 맞는지”를 말할 수 있게 됐다.

3️⃣ 구현 (Implementation)

정의: 설계된 내용을 실제로 동작하는 코드로 작성

목표: 포인터, 순회, 파싱, 저장 같은 내부 과정을 손으로 끝까지 따라간다.

자료구조 문제에서는 작은 함수 하나도 결국 포인터 재배선과 순회 순서 제어로 귀결됐다. Mini SQL에서는 parser가 statement를 만들고 executor가 CSV에 반영하는 최소 흐름을 먼저 잡았고, 팀 버전에서는 그 과정을 trace와 demo로 다시 드러냈다. 이번 주 구현은 문법보다 실행 장면을 더 자주 떠올리게 만든 쪽이었다. [Source] [Source] [Source]

이번 주에 더 분명해진 것: 큐를 뒤집는 짧은 함수도 push와 pop의 흐름을 손으로 못 따라가면 구현한 느낌이 들지 않았고, SQL도 parse에서 save까지 한 번 이어 붙여 봐야 비로소 손에 들어왔다.

💡 이번 주에 자꾸 걸린 장면
→ 큐를 뒤집는 문제와 SQL 한 줄을 CSV에 반영하는 흐름이 둘 다 “중간 단계를 손으로 따라가야 안심되는 구현”으로 남았다.
→ helper 함수나 보조 스택을 쓰는 이유를 바로 설명하지 못하면 구현이 끝난 느낌이 들지 않았다.

4️⃣ 품질 (Quality)

정의: 버그 없는 안정적인 코드 및 테스트 작성

목표: 정답 여부보다 실패할 조건과 경계부터 먼저 본다.

이번 주 실습 함수들은 대부분 크지 않았지만, 그만큼 NULL 검사, 빈 스택, 빈 트리, 끝까지 순회했을 때의 조건이 더 잘 보였다. Mini SQL 쪽도 마찬가지였다. 헤더와 값 순서가 어긋나면 어떻게 되는지, trace와 demo가 실제 데이터 파일을 직접 오염시키지 않게 하려면 어떤 보호가 필요한지 같은 지점이 결국 품질 문제였다. 눈에 보이는 큰 버그보다 작은 경계 조건이 더 오래 남은 주였다. [Source] [Source] [Source]

이번 주에 더 분명해진 것: 이번 주엔 큰 버그보다 빈 리스트, 빈 트리, 경계 인덱스, demo 파일 오염 같은 작은 조건들이 더 오래 남았다. 구현 도중에 위험한 장면이 먼저 떠오르지 않으면 뒤에서 다시 크게 돌아오게 됐다.

💡 이번 주에 자꾸 걸린 장면
→ 작은 C 함수일수록 빈 리스트, 빈 스택, 빈 트리를 먼저 떠올리게 됐다.
→ Mini SQL demo도 돌아가기만 하는 버전과 작업 파일을 덜 위험하게 다루는 버전은 다르게 보이기 시작했다.

5️⃣ 유지보수 (Maintenance)

정의: 가독성이 좋고 수정이 용이한 코드 작성

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

이번 주에는 한 C 파일을 한 글로 정리하는 과정 자체가 유지보수 감각을 다시 보여줬다. 함수 하나를 설명하려고 하면 결국 입력 흐름, 핵심 구현 단계, 체크 포인트를 분리해 적어야 했다. Mini SQL도 엔진과 프론트를 분리해 두었기 때문에 "실제 구현 증명"과 "설명용 화면"을 구분해서 다시 읽을 수 있었다. 유지보수는 결국 내가 나중에 봤을 때 구조를 빠르게 복원할 수 있느냐의 문제라는 점이 더 분명해졌다. [Source] [Source] [Source]

이번 주에 더 분명해진 것: 27개 글을 다시 쓰면서 통과한 코드인데도 설명 순서가 안 잡히는 파일들이 있었고, 그런 문제들은 대체로 구조가 아직 머릿속에서 덜 정리된 코드였다.

💡 이번 주에 자꾸 걸린 장면
→ C 파일 하나를 글로 다시 쓰려니 입력, 핵심 흐름, 체크 포인트가 바로 안 잡히는 문제는 다시 읽어야 했다.
→ 설명 순서가 꼬이는 코드는 결국 구조도 아직 덜 정리된 코드처럼 보였다.

6️⃣ 협업 (Collaboration)

정의: 팀원과 소통하며 시너지를 내는 과정

목표: 역할 분담 전에 구조와 용어부터 맞춘다.

Mini SQL 팀 결과물에서 남은 협업 포인트는 구현 속도보다 구조 언어였다. tokenizer, parser, AST, optimizer, executor, storage라는 말이 먼저 정리돼 있으니 문제를 설명할 때도 훨씬 선명했다. 어디가 깨졌는지, 지금 보고 있는 결과가 어느 단계 산출물인지 말할 수 있어야 협업도 빨라진다. 이번 주에는 “같이 만든다”보다 “같은 구조를 같은 이름으로 본다”가 더 중요하게 남았다. [Source]

이번 주에 더 분명해진 것: “SQL이 안 된다”보다 “parser 전까지는 맞고 storage 반영에서 어긋난다”처럼 말할 수 있을 때 협업이 훨씬 빨라졌다. 구현 속도보다 구조를 같은 이름으로 부르는 일이 먼저였다.

💡 이번 주에 자꾸 걸린 장면
→ “SQL이 안 된다”보다 “parser 전까지는 맞고 storage 반영에서 어긋난다”처럼 말할 수 있을 때 협업이 훨씬 빨라졌다.
→ 구조 이름을 먼저 맞추지 않으면 구현 속도가 붙어도 금방 다시 꼬였다.

7️⃣ 태도 (Attitude)

정의: 자기주도적인 학습과 과제에 대한 몰입

이번 주에는 “대충 이런 구조겠지”라고 넘기던 부분이 계속 걸렸다.

연결 리스트에서 포인터 한 칸이 바뀌는 이유, 트리 순회가 같은 결과를 내도 왜 내부 흐름이 다른지, SQL 한 줄이 어떤 단계를 거쳐 파일에 저장되는지 같은 장면을 자꾸 다시 설명하게 됐다. 설명이 안 되면 아직 손에 안 들어왔다는 감각이 훨씬 선명해졌다. [Source] [Source] [Source]

이번 주에 더 분명해진 것: 이번 주에는 “정답이 나왔다”보다 “이 포인터 이동과 이 순회 순서를 내가 다시 말로 복원할 수 있는가”가 더 자주 기준이 됐다.

💡 이번 주에 자꾸 걸린 장면
→ 포인터 한 칸을 왜 그렇게 옮기는지 말이 막히면 결국 그 부분을 다시 붙잡게 됐다.
→ 결과만 맞는 코드보다, 내가 다시 설명할 수 있는 코드가 더 오래 남았다.

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

정의: 서비스의 가치와 사용자 입장을 고려하는 시각

목표: 만들 수 있는 것과 보여줄 수 있는 것을 구분해서 본다.

이번 주에는 Mini SQL 팀 결과물의 demo와 trace를 보면서, 구현이 된다는 것과 다른 사람이 이해할 수 있게 보여줄 수 있다는 것이 다르다는 점이 크게 남았다. 설명 가능한 구조, 안전한 demo workspace, 중간 결과를 보여주는 trace는 결국 사용자의 시선과 운영의 시선을 같이 고려하는 문제였다. 기술적으로 가능하다고 끝나는 게 아니라, 이걸 어떻게 설명하고 보여줄 것인지까지 포함해야 결과물이 된다. [Source]

이번 주에 더 분명해진 것: 이번 주엔 기능이 있다는 사실보다, 그 기능이 trace와 demo로 어떻게 보이는지가 더 크게 남았다. 보여줄 수 없는 구현은 끝난 구현처럼 느껴지지 않았다.

💡 이번 주에 자꾸 걸린 장면
→ 결과 화면 하나보다 trace처럼 중간 단계가 보이는 구조가 더 설득력 있게 느껴졌다.
→ demo용 데이터와 실제 작업 파일을 어떻게 분리할지도 구현의 일부처럼 보이기 시작했다.

9️⃣ AI 활용 (AI Utilization)

정의: AI 도구를 활용하여 생산성을 극대화하는 능력

목표: 도구가 코드를 빨리 만들어도 구조 판단은 직접 쥔다.

바이브 프로젝트라는 이름답게 도구 도움을 받는 흐름은 있었지만, parser를 cursor 방식으로 둘지 tokenizer를 나눌지, trace를 어떤 단계까지 보여줄지 같은 결정은 결국 직접 내려야 했다. 이번 주에는 AI를 많이 쓰는 것보다, 무엇을 단순하게 남기고 무엇을 구조화할지 스스로 기준을 세운 뒤 도구를 붙이는 쪽이 더 중요하게 느껴졌다. [Source]

이번 주에 더 분명해진 것: 이번 주에는 생성 속도 자체보다 “이 구조를 어디까지 단순하게 둘지”를 먼저 정한 뒤 도구를 붙일 때 훨씬 덜 흔들렸다. 방향이 흐리면 결과도 빠르게 흐려졌다.

💡 이번 주에 자꾸 걸린 장면
→ SQL 구조를 내가 먼저 자르지 않으면 도구가 코드를 채워도 기준은 더 흐려졌다.
→ 이번 주에는 빠른 생성보다 “어디까지를 내가 이해하고 있는가”를 계속 확인하게 됐다.

🔟 학습 민첩성 (Learning Agility)

정의: 새로운 기술이나 개념을 빠르게 습득하는 능력

목표: 넓은 범위를 하나의 중심 질문으로 묶어 간다.

이번 주는 범위만 보면 꽤 넓었다. 작은 C 자료구조 함수 27개와 Mini SQL 구현 회고가 한 주 안에 같이 있었기 때문이다. 그런데 실제로는 덜 흩어졌다. 둘 다 결국 “이 구조는 왜 이렇게 움직이는가”, “내가 이 흐름을 남에게 설명할 수 있는가”라는 질문으로 다시 묶였기 때문이다. 연결 리스트의 재배선과 SQL parser의 단계 분리는 스케일만 다를 뿐 같은 질문 위에 있다는 점이 이번 주를 덜 산만하게 만들었다. [Source] [Source]

이번 주에 더 분명해진 것: 연결 리스트의 재배선과 SQL parser의 단계 분리는 전혀 다른 주제처럼 보였지만, 둘 다 중간 구조를 설명할 수 있어야 안심되는 작업이었다. 이번 주는 범위보다 질문이 더 오래 남았다.

💡 이번 주에 자꾸 걸린 장면
→ 연결 리스트 재배선과 SQL parser 단계 분리가 전혀 다른 주제처럼 보여도 둘 다 “중간 구조를 설명할 수 있는가”로 다시 묶였다.
→ 범위가 넓어도 같은 질문이 남으면 오히려 덜 흩어진다는 걸 이번 주에 더 강하게 느꼈다.

체크리스트

이번 주 체크리스트는 단순히 “무슨 문제를 풀었는가”를 남기는 용도가 아니다. 이번에는 각 묶음마다 어떤 질문으로 봤는지, 지금은 어떤 문장으로 이해하고 있는지, 아직 어디가 불안한지까지 같이 적어두기로 했다. 자료구조 C 실습은 연결 리스트, 스택·큐, 이진 트리, BST라는 네 축으로, Mini SQL은 개인 최소 구현과 팀 구조화라는 두 축으로 정리하는 편이 이번 주의 결을 훨씬 잘 보여준다. [Reference]

🧭 이번 주 학습 지형도

자료구조 재배선 시리즈 연결 리스트 · 스택 · 큐 삽입, 분할, 뒤집기, 균형 검사처럼 연결과 순서를 바꾸는 문제들

트리 순회 시리즈 이진 트리 · BST 재귀와 스택으로 구조 판별과 순회를 구현하는 문제들

Mini SQL 구현 시리즈 개인 최소 엔진 · 팀 결과물 작은 엔진을 끝까지 돌리는 감각과 설명 가능한 구조로 나누는 감각

이번 주 상세 체크리스트

체크 기준
이번 주 체크리스트는 각 항목마다 세 가지를 남긴다.
1) 이번 주에 반복해서 붙잡은 핵심 질문
2) 지금 시점에서 내가 붙잡고 있는 이해 문장
3) 다음에 다시 손으로 확인해야 할 남은 포인트

상태	분야	핵심 질문 · 이해 문장 · 남은 포인트	관련 글
🔁	연결 리스트	핵심 질문 지금 보고 있는 노드의 값이 아니라 next를 어디서 끊고 어디에 다시 이어야 하는가? 이해 문장 삽입, 분할, 최댓값 노드 이동, 재귀 뒤집기까지 전부 링크의 방향과 연결 지점을 다시 잡는 문제였다. 남은 포인트 재귀 뒤집기나 절반 분할처럼 포인터가 세 개 이상 얽히는 순간은 아직 손으로 한 번 더 그려보는 편이 안전하다.	161 ~ 167
✅	스택 · 큐	핵심 질문 순서를 바꾸고 싶을 때 지금 필요한 건 새 알고리즘이 아니라 보조 저장 공간 하나인가? 이해 문장 큐 뒤집기, 특정 값 제거, 괄호 균형 검사는 결국 스택이나 큐를 잠시 세워두고 다시 꺼내며 순서를 제어하는 연습이었다. 남은 포인트 순서를 잠깐 저장하는 문제인지, 실제 자료구조 상태를 영구히 바꾸는 문제인지는 더 빠르게 구분해야 한다.	168 ~ 174
🔁	이진 트리	핵심 질문 현재 노드 하나를 보는 것으로 끝나는가, 아니면 왼쪽과 오른쪽 서브트리의 성질을 같이 끌고 와야 하는가? 이해 문장 높이, 한쪽 자식 개수, 기준값 비교, 최소값, 증손자 존재 여부는 전부 서브트리를 어떤 규칙으로 읽을지 정하는 문제였다. 남은 포인트 증손자 존재처럼 조건이 한 번 더 깊어지는 문제는 재귀 반환값 설계를 더 깔끔하게 적어보는 연습이 필요하다.	175 ~ 182
🔁	BST	핵심 질문 같은 순회 결과를 만들더라도 그 순서를 어떤 자료구조로 보존하고 있는가? 이해 문장 레벨 순서, 반복 전위, 한 개 스택 후위, 두 개 스택 후위를 비교해보니 순회는 출력 문자열보다 방문 순서를 어떻게 통제하는지의 차이가 더 중요했다. 남은 포인트 후위 순회 한 개 스택 버전은 아직 조건 분기와 직전 방문 노드 추적을 더 매끈하게 설명할 필요가 있다.	183 ~ 187
✅	Mini SQL 개인 구현	핵심 질문 SQL 전체를 흉내 내기보다, 가장 짧은 왕복 경로를 먼저 끝까지 붙일 수 있는가? 이해 문장 cursor parser, 작은 statement 구조체, CSV 헤더 기반 저장처럼 범위를 강하게 자른 덕분에 입력 → 파싱 → 실행 → 저장을 한 번에 설명할 수 있었다. 남은 포인트 지금 구조가 단순한 대신 tokenizer 분리나 schema 관리가 왜 빠졌는지는 앞으로도 계속 의식하고 설명해야 한다.	160
🔁	Mini SQL 팀 결과물	핵심 질문 돌아가는 엔진을 넘어, 다른 사람이 지금 어느 단계까지 맞는지 읽을 수 있는 구조를 만들 수 있는가? 이해 문장 Tokenizer → Parser → AST → Optimizer → Executor → Storage를 분리하고 trace와 demo를 붙이니, 구현 자체보다 설명 가능한 구조가 별도의 가치라는 점이 더 선명해졌다. 남은 포인트 trace와 demo가 교육용/시연용으로는 강하지만, 실제 작업 데이터와 안전하게 분리되는 기준은 앞으로 더 단단하게 봐야 한다.	160

✍️ 이번 주 체크리스트를 이렇게 묶은 이유
이번 주는 문제를 많이 풀었다는 사실보다, 같은 질문이 다른 스케일에서 반복됐다는 점이 더 중요했다. 연결 리스트의 포인터 재배선, 트리의 순회 규칙, SQL 파이프라인의 단계 분리는 결국 모두 “구조를 설명 가능한 단위로 다시 보는 일”에 가까웠다.

마무리

이번 주를 지나고 나니, 연결을 어떻게 다시 잇는지, 순회를 어떤 순서로 돌리는지, SQL 한 줄이 어떤 중간 단계를 거쳐 파일까지 가는지 같은 장면을 예전처럼 대충 넘기기가 조금 어려워졌다. 리스트 문제를 풀 때도, 트리 순회를 적을 때도, Mini SQL을 다시 볼 때도 결국 걸리는 건 “왜 이 구조로 가야 하는가”였다.

이번 주에는 코드가 된다는 사실보다, 그 코드의 내부 흐름을 어디까지 설명할 수 있는지가 더 자주 남았다. 포인터 한 칸, 스택 하나, parser 단계 하나를 얼버무리면 구현은 돌아가도 이해는 끊긴다. 지금은 적어도 어떤 부분을 그냥 넘기면 안 되는지가 전보다 분명해졌다. [Source] [Source] [Source]