Claude에게 작업 후 이상한 점들을 기록하도록 지시하기
Instruct Claude to flag weird stuff after every task.
핵심 요약
Claude가 작업 중 발견한 문제들을 채팅창 대신 별도 파일에 기록하게 하여 작업 흐름을 유지하는 팁.
- 워크플로우 최적화 — 작업 중 발견한 이슈를 채팅창이 아닌 별도 마크다운 파일에 기록하여 흐름 끊김 방지.
- CLAUDE.md 활용 — 작업 완료 후 TODO, 버그, 데드 코드 등을 자동으로 특정 파일에 정리하도록 지시.
- 검증의 중요성 — Claude가 기록한 이슈는 실제 수정 전 반드시 사람이 먼저 확인하여 오탐 방지.
- 확장성 고려 — 추후 기록된 이슈를 자동으로 검증하고 수정하는 전용 Skill 개발 가능성 시사.
제 CLAUDE.md에는 Claude Code가 작업 후 코드베이스에서 발견한 주목할 만한 사항들을, 현재 작업과 관련이 없더라도 모두 기록하도록 하는 지시사항이 있습니다. 미완성된 TODO, 잠재적 버그, 데드 코드, 코드 스멜 같은 것들이죠. 아주 잘 작동합니다. 문제는 이게 채팅창에 다 쏟아져 나와서, 제가 지금 당장 신경 쓰고 싶지 않은 문제들 때문에 흐름이 끊긴다는 거였어요. 그래서 한가한 오후가 되면 섹션 하나를 골라서 조금씩 처리하곤 하죠.
그래서 아예 code-observations.md라는 마크다운 파일에 덤프하도록 바꿨습니다. CLAUDE.md에 넣은 지시사항은 아래와 같습니다.
## Code Observations
After completing each task, log noteworthy findings you encountered while reading or working with the codebase into [todo/code-observations.md](todo/code-observations.md). The file persists across sessions so the team can triage during dedicated cleanup passes — see the file's header for entry format, severity tags, and the verify/resolve lifecycle.
**What to look for**(only things you actually encountered; don't go hunting):
-
**Unfinished implementations**: TODOs, stubs, placeholder logic, partially implemented features
-
**Dead code**: Unused functions, unreachable branches, commented-out blocks
-
**Possible bugs**: Unchecked errors, race conditions, off-by-ones, logic errors
-
**Unusual patterns**: Inconsistent conventions, surprising workarounds, anti-patterns
**How to log:**
1. Append a row to the matching section's table in `todo/code-observations.md` (Renderer / Main / FastAPI / DB / Directus / Build / Other). The header at the top of that file documents the exact column format, severity tags, and the `☐`/`☑` status glyphs.
2. Get the introducing commit's short hash via `git blame -L <line>,<line> <file>` and put it in the Hash column (backtick-wrapped). For non-code observations (e.g. Directus content) write `n/a`.
3. Append-only — never reorder or delete rows. Use the V/R status columns and strikethrough rules defined in the file for state changes.
**In your end-of-turn response**, mention findings only if directly relevant to the current task. Otherwise say "N new observations logged" so the user knows the log moved without re-listing everything. If there's nothing to log this turn, skip the section entirely.

