하네스 템플릿 전담 세션을 새로 만들고, v3.0을 릴리스했다. 그리고 직접 써보면서 3시간 안에 버그 3개를 잡았다. 다이브베이스에 적용한 리팩토링 10개 Task도 전부 완료해서 종료 판정.
이날 생긴 것들
어제까지 Planner / Developer / Reviewer 3개 세션으로 돌아가던 구조에, 오늘 두 가지가 추가됐다.
- 하네스 전담 세션: 템플릿 자체를 점검하고 개선하는 역할. 코드베이스에서 완전히 분리.
- 다이브베이스 통합 세션: 하네스 시스템을 전반적으로 살피면서 다이브베이스에 적용하는 역할.
역할이 분리되니까 "지금 템플릿을 고치는 건지, 프로젝트를 고치는 건지"가 명확해졌다. 전날까지는 이게 섞여 있었다.
1부: 하네스 템플릿 v3.0
무엇이 추가됐나
Slash Commands — /plan, /develop, /review
기존엔 역할을 전환할 때 프롬프트를 길게 타이핑해야 했다. 이제 한 단어면 된다. /review를 치는 순간 Claude가 Reviewer 모드로 들어간다.
Auto-lint Hook — post-edit-lint.sh
파일을 수정할 때마다 자동으로 프로젝트 타입에 맞는 린터가 실행된다. PostToolUse 훅으로 걸어놓으니, Developer가 커밋 전에 "린터 돌려야 하는데" 를 신경 쓸 필요가 없어졌다.
Verify 템플릿 — templates/verify.md
Planner가 구현 계획을 쓸 때, 검증 계획도 별도 파일로 작성하게 됐다. 리뷰 단계에서 Reviewer가 이 파일을 참조해서 체크한다.
Plan Mode Rules
3개 이상 파일을 수정하거나 COMPLEXITY: HIGH인 작업은 Planner가 plan을 먼저 작성해야 Developer가 시작할 수 있다. 규칙으로 박아놓으니 큰 작업을 plan 없이 바로 구현하는 일이 없어졌다.
/blog 커맨드
handoff, git log, reviews를 읽어서 블로그 포스트 초안을 자동 생성한다. 이 글도 그 결과물이다.
2부: 릴리스 후 3시간, 버그 3개
v3.0을 릴리스하고 바로 다이브베이스에 적용해서 써봤다. 3시간 안에 fix 커밋 3개가 나왔다.
Fix 1 — /review 출력이 영어였다
README는 한국어인데 커맨드 터미널 출력만 영어로 나왔다. 사용자 경험이 일관되지 않은 거라 바로 한국어로 바꿨다.
Fix 2 — Reviewer가 verify.md를 읽지 않고 있었다
v3에서 verify 템플릿을 추가했지만, Reviewer 워크플로우에 해당 파일을 읽는 단계를 빠뜨렸다. 새 기능을 추가하면 기존 워크플로우에서 참조가 연결되어 있는지 반드시 확인해야 한다는 교훈.
Fix 3 — report/handoff가 커밋에 빠지고 있었다
가장 치명적인 버그였다. Reviewer 워크플로우가 APPROVE → commit → report/handoff 순서로 동작하고 있어서, report와 handoff 파일이 커밋에 포함되지 않았다. report + handoff를 먼저 작성하고 commit을 마지막으로 이동했다.
워크플로우에서 순서는 정말 중요하다. 문서로만 보면 절대 발견 못 할 버그다. 직접 돌려봐야 보인다.
3부: 다이브베이스 리팩토링 완주
어제 시작한 다이브베이스 개선 Task를 전부 마무리했다. 오늘 완료된 것만 10개.
프로세스 정비
Task 7 Reviewer 승인(어제 넘겼던 대형 파일 분리 2,186줄 → 790줄)을 통과시키고, 하네스 문서 언어를 영문으로 통일했다. 한영 혼재가 생각보다 혼선을 많이 만든다.
리팩토링 5개
| Task | 내용 |
|---|---|
| Task 8 | 공유 유틸 5개를 dive_log_utils.dart로 추출 — 스쿠버/프리다이빙 리포에 중복된 로직 통합 |
| Task 9 | 미사용 의존성 3개 제거 (collection, equatable, build_runner) |
| Task 10 | Logs feature에 State 레이어 추가 — Riverpod 패턴 완성 |
| Task 11 | AppException 계층 도입 — Repository 전체 에러 처리 표준화 |
| Task 12 | 레거시 fetch 메서드를 features/logs/data/로 이동 |
테스트: 22개 → 70개
테스트가 없던 코드베이스에 하루 만에 48개가 추가됐다.
- Task 13: 유틸 함수 26개 + 리포지토리 validation 22개 = 48개 유닛 테스트
- Task 14:
mocktail기반 Supabase 목 인프라 구축 + 통합 테스트 15개 추가
Supabase 목킹이 생각보다 까다로웠다. SupabaseQueryBuilder가 Future를 구현하고 있어서 thenReturn이 안 먹고 thenAnswer를 써야 했다. 빌더 체이닝(select().eq().maybeSingle())도 단계마다 다른 타입을 반환해서 FakePostgrestBuilder와 FakeInsertBuilder를 따로 만들어야 했다. 한번 잡아놓으니 이후 테스트 추가 속도가 빨라졌다.
정리
ai/디렉토리(Python 스크립트 22개) 삭제 — 3-Role 워크플로우로 완전히 대체- 아카이브 문서 25개 삭제 —
handoff/archive/로 정책 일원화
숫자로 보는 하루
| 지표 | 값 |
|---|---|
| 완료 Task | 10개 (Task 8–16 + H1/H1C) |
| 커밋 | 17개 |
| 테스트 | 22개 → 70개 (+48) |
| 삭제한 파일 | 47개 |
| 제거한 의존성 | 3개 |
회고
"만들고 → 써보고 → 고친다" 사이클이 짧을수록 좋다. v3 릴리스 후 3시간 안에 fix 3개. 문서로만 검토했으면 Fix 2, 3은 절대 못 찾았다.
리팩토링 순서가 생명이다. Task 8(공유 유틸 추출) → Task 13(유틸 테스트) 순서가 맞았다. 테스트를 먼저 썼으면 리팩토링 후 테스트를 다시 고쳐야 했을 것이다. 이미 동작하는 코드의 구조를 바꾸는 거라면, 구조가 안정된 후에 테스트를 쓰는 게 효율적이다.
3-Role 워크플로우 2일차. 17커밋 전부 dart analyze 통과 + 테스트 통과 상태로 들어갔다. Reviewer가 매 Task마다 검증하니까 "나중에 한꺼번에 고치자"가 생길 틈이 없다. 다만 작은 Task에도 Plan → Dev → Review 3단계를 밟다 보니 오버헤드가 있다. Task 15(파일 삭제)같은 건 Plan 없이 바로 해도 됐을 것 같다.
다음에 할 것: 실제 프로젝트에서 쌓인 피드백으로 하네스 v3.1 다듬기, auto-lint hook 실사용 검증, Epic 플래닝 워크플로우 실전 테스트.
