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.
Claude는 이제 채팅창에 다 쏟아내는 대신 해당 파일에 새로운 발견 사항들을 추가합니다.
이 워크플로우가 마음에 드는 주된 이유는 아주 수동적으로 작동한다는 점입니다. 이런 이슈들을 찾기 위해 Skill이나 프롬프트를 만들 수도 있었겠지만, 그냥 작업하면서 발견하고 기록하면 되는데 굳이 토큰을 낭비할 필요가 있을까요? 유일한 주의점은, Claude에게 수정을 지시하기 전에 먼저 이슈를 검증해야 한다는 겁니다. Claude가 관련 코드의 제한된 맥락만 보고 이슈라고 판단하는 경우가 가끔 있거든요.

