Week 6 Learned

1. What

이번 주는 크게 세 가지를 함께 붙잡은 한 주였다. C 문법과 CSAPP를 다시 바닥부터 정리하는 일이었다. 

수요코딩회를 위한 SQL/RDBMS 구조 설계였다. AST 중심 구조와 SQL 처리 파이프라인을 정리했고, 단순한 아이디어가 아니라 구현 가능한 단계로 나누어 보는 흐름이 생겼다.

---

2. How

• 노트에서는 C 문법, CSAPP 학습 계획, SQL 파이프라인처럼 개념과 구조를 먼저 적었다.
• 회의에서는 매일 21시 공유, 월요일부터 상호 설명식 스터디, 외부 자료 보조 활용 같은 운영 방식을 정리했다.
• 코드에서는 Initial commit 이후 Linked List와 Stack/Queue 문제를 순서대로 풀면서 실제 구현 감각을 확인했다.
•  

---

3. Approach

이번 주 접근은 "개념 이해 -> 설명 가능한 수준까지 정리 -> 작은 단위 구현 -> 다음 설계로 확장"의 흐름이었다.

C와 CSAPP 쪽에서는 단순히 문법을 외우는 대신, 포인터와 함수 호출 과정이 성능과 메모리 이해로 이어지는 지점을 잡아 보려 했다.

수요코딩회 준비에서는 더 큰 덩어리를 잘게 쪼개는 방식이 보였다. Tokenizer/Lexer -> Parser -> Semantic Validation -> Executor -> Storage -> Output처럼 SQL 엔진을 단계별 파이프라인으로 나누는 방향으로 접근하였다.

---

4. Learned

설명 가능한 수준까지 이해해야 진짜로 남는다

민철이가 이해할 수 있도록 설명 가능한 수준이라는 회의 메모가 특히 인상적이었다. 이번 주에는 많이 읽는 것보다, 남에게 설명할 수 있을 정도로 정리하는 기준이 더 중요하다는 걸 다시 확인했다.

구현은 큰 목표보다 작은 단계로 나눌 때 움직인다

SQL 파이프라인 메모가 가장 잘 보여 준 부분이 바로 이것이었다. 전체 DB 엔진을 한 번에 만들겠다고 생각하면 막막하지만, Tokenizer/Lexer, Parser, Executor, Storage처럼 나누면 바로 다음 행동이 보인다.

---

5. Keep

• 기존 방식에만 머무르지 않고 새로운 시도를 해본 점은 계속 가져가고 싶다.
• 수요코딩회에서 분업 구조를 실제로 굴려 본 경험은 다음 작업에도 도움이 된다.
• 각자 다른 학습 관점과 풀이 관점을 공유한 분위기는 팀 학습에 분명한 장점이었다.
• Claude와 Codex를 비교하며 도구 활용 방식을 탐색한 점도 의미 있었다.
• 자리 배치를 조정하면서 소통 효율을 높이려 한 시도는 생각보다 중요했다.
• 설계 단계에서 인터페이스를 먼저 합의했던 방식은 구현 충돌을 줄이는 데 도움이 됐다.
• 발표를 준비하면서 한 사람이 아니라 같이 내용을 공유한 흐름도 좋았다.

---

6. Problem

• 발표자 선정이 매끄럽지 않으면 준비의 흐름도 같이 흔들릴 수 있었다.
• 설명이 부족한 순간에는 학습한 내용을 팀 안에서 충분히 전달하지 못했다.
• CSAPP 학습량 자체는 기대했던 만큼 충분하지 못했다.
• 개발환경이 통일되지 않아 구현과 협업이 매끄럽지 않은 구간이 있었다.

---

7. Try

• 다음에는 코드를 바로 읽는 대신 먼저 전체 흐름을 파악하고, 필요한 경우 주석을 통해 학습하는 방식을 더 적극적으로 써보려 한다.
• 과제 풀이 내용은 각자만 알고 넘어가지 말고, 팀 안에서 짧게라도 공유하는 루틴을 만들 필요가 있다.
• 설계 단계에서는 agent나 팀원 간 convention을 더 일찍 맞춰서 구현 기준을 통일해야 한다.
• 개발환경 문제는 Docker 같은 방식으로 최대한 빨리 통일하는 쪽이 낫다.
• 분업은 크게 나누는 것보다 최소 구현 -> push 단위로 더 잘게 쪼개야 효율이 좋아질 것 같다.

---

8. Make Up For

이번 주에 가장 먼저 메꿔야 하는 부분은 "좋은 메모를 실제 코드로 연결하는 것"이다.

• 2026-04-08에 정리한 SQL 파이프라인은 다음 주에 Tokenizer/Lexer 또는 Parser stub 코드로 바로 이어져야 한다.
• Linked List와 Stack/Queue처럼 문제풀이를 이어 갈 때는 문제 하나 -> 커밋 하나 -> 짧은 메모 하나의 리듬으로 남겨서 회고의 밀도를 높여야 한다.
• C 문법과 CSAPP는 더 읽는 것에 그치지 말고, 포인터와 함수 호출 과정을 직접 설명 가능한 문장으로 다시 정리해야 한다.
• 팀 작업에서는 발표자 선정, 환경 통일, convention 합의를 초반에 끝내서 뒤쪽 구현 단계의 마찰을 줄여야 한다.

이번 주가 "정리와 준비의 주간"이었다면, 다음 주는 이 준비를 실제 산출물로 바꾸는 주간이 되어야 한다.