매퉁이

한 일

저장소 하나에 지식과 코드를 같이 담았습니다. 2026-08-18에 만들었고, 지금까지 커밋은 101개예요.

최상위 구조는 이렇게 잡았어요.

raw/        원본 자료 — 사람이 넣고, 고치지 않는다
wiki/       위키 — Claude 가 쓴다
projects/   프로젝트별 폴더 — bait · blog · gunghap · quest
packages/   공유 코드 7개 — auth · config · db · ui · habitat · MCP 서버 둘
infra/      DB 하나, 컨테이너 하나
design/     원칙 · 도구 호출법 · 공유 껍데기
tools/      훅 스크립트
index.md · log.md · todo.md · schema.md · CLAUDE.md

지식 구조

카파시가 2026년 4월에 올린 LLM Wiki 패턴을 그대로 따라갔어요. 검색을 핵심에 두지 않고 컴파일하는 방식입니다. 질문할 때마다 원본을 다시 뒤지는 수고를 줄이려고, 자료를 만나는 시점에 위키로 옮겨 적어둡니다. 답도 그 위키를 바탕으로 해요.

계층은 셋으로 나눴습니다.

위키 아래에는 ideas services decisions synthesis concepts entities sources, 이렇게 일곱 갈래가 있어요. 그중 decisions가 결정 기록(ADR)이고, 지금까지 33건 쌓였습니다. 구조·스택·데이터 모델을 정했다면 코드를 쓰기 전에 여기에 먼저 적어요.

부속 파일은 넷입니다.

• index.md — 전체 카탈로그. 질문에 답하기 전에 가장 먼저 읽는 파일
• log.md — 시간순 추가 전용. 지금 122건
• todo.md — 할 일. [사람]이 붙은 것은 Claude가 못 하는 일입니다
• schema.md — 페이지 종류와 프론트매터 규칙

커맨드

슬래시 커맨드는 11개예요. 이 가운데 셋은 위키 연산(/ingest /query /lint)에 쓰고, 나머지 여덟은 작업용으로 씁니다. /idea /explore /new-service /adr /devlog /review /debate /quest-set이 있어요.

아이디어가 생기면 /idea로 등록합니다. /explore로 여러 번 굴려본 뒤 /new-service로 만들어요.

자동으로 도는 것

규칙을 문서에만 적어두면 잘 지켜지지 않더라고요. 그래서 훅으로 걸었습니다.

세션이 시작될 때는 아래 셋이 돌아가요.

• 미처리 원본 자료 알림
• 머지 안 된 브랜치 알림
• 결정 전부 + 미해결 충돌 + 위키가 어긋난 곳 + 막힌 [사람] 일

파일을 고치거나 명령을 치기 전에는 네 가지를 막습니다.

• 워크트리 안에서 위키 고치기
• 이미 쓴 번호로 새 결정 기록 만들기 · log.md 통째로 덮어쓰기
• git add -A 같은 범위 없는 스테이징과 경로 없는 커밋
• 블로그 문구를 고칠 때 말투 규칙을 다시 들려주기

한 번 갈아엎었다

처음에는 서비스를 apps/ 아래에 뒀어요. 그러다 2026-08-28에 projects/<프로젝트>/{app,design}으로 옮겼습니다. 기준은 소유하는 것은 도메인별로, 공유물은 기능별로예요.

프로젝트끼리는 서로 import하지 않습니다. 공유할 게 생기면 packages/로 올려요. 나중에 프로젝트 하나를 떼어낼 때는 git subtree split 한 줄이면 됩니다.

막힌 것

세션을 여러 개 동시에 돌리고 있습니다. 그런데 둘 다 master에서 돌면 훅이 아무것도 막지 못해요. 워크트리일 때만 걸리도록 해뒀기 때문입니다.

다음

이 환경에서 실제로 무엇이 걸리는지 적어보려고 합니다.