PR 올리기 전에 내 브랜치에서 영향 범위(blast-radius) 체크했더니 진짜 문제를 찾아냄
Ran a blast-radius check on my own branch before opening the PR, found the actual problem
핵심 요약
Graft를 활용해 코드 변경이 미치는 영향 범위를 미리 확인하여 잠재적인 장애를 예방한 사례 공유.
- 영향 범위 분석 — Graft를 활용해 커밋 전 코드 변경의 의존성을 미리 파악함
- 자동화된 그래프 — Claude Code 세션과 동일한 그래프를 사용하여 별도 설정 없이 즉시 사용 가능함
- 상세 분석 옵션 — 기본값은 요약된 정보지만 --depth all 옵션으로 전체 의존성 확인 가능함
- 기술적 기반 — 모델의 추론보다는 AST와 언어별 LSP를 활용해 결정론적인 그래프를 생성함
github.com
원문 사이트로 이동
지난주에 PR 하나 올리려고 했거든. 함수 딱 하나에 길어봤자 8줄 정도? 너무 짧아서 설명 대충 적고 넘길까 싶었는데, 마침 그전부터 리포지토리에 Claude Code 훅으로 Graft를 연결해 둔 상태였어. 원래 세션 시작할 때 코드베이스 맵을 자동으로 불러와서 Claude가 매번 처음부터 다시 탐색 안 하게 하려고 썼던 건데, 이미 깔려 있길래 커밋하고 나서가 아니라 커밋하기 전에 내 변경 사항을 이 툴로 한번 훑어보기로 했지. 평소엔 이런 식으로 안 썼는데 말이야.
근데 웬걸, 그 8줄짜리 함수가 몇 달 동안 건드리지도 않았던 다른 기능 4개랑 엮여 있더라고. 심지어 그중 하나는 새벽 3시에 돌아가는 스케줄 작업이라 아무도 신경 안 쓰는 거였어. 그냥 올렸어도 깔끔하게 머지 됐을 거고, 아마 별문제 없었을지도 모르지. 근데 금요일에 배포하는 코드에 '아마 괜찮겠지'라는 찜찜함을 남기고 싶진 않잖아.
여기서 딱 감이 온 게, graft blast가 Claude Code에 억지로 끼워 맞춘 별개 툴이 아니라는 거야. 세션 시작할 때 훅이 읽어 들이는 그 그래프를 그대로 쓰는 거거든. 그냥 새로 세션을 여는 대신 내 커밋 안 된 변경 사항을 찍어보는 거라 graft init만 해두면 따로 설정할 것도 없고, 새로 배울 것도 없어. 그냥 수정할 때마다 백그라운드에서 알아서 동기화되는 그래프한테 질문 하나 더 던지는 셈이지. 파일 전체가 아니라 내가 건드린 함수 딱 하나를 기준으로 잡으니까, 한 줄 수정했다고 파일 전체 내용에 파묻히지도 않고.
처음 좀 큰 작업에 썼을 때 당황했던 건, 진짜 규모가 큰 PR은 영향 범위를 5개 영역으로 압축해서 보여준다는 거야. 모든 의존성을 일일이 나열하는 게 아니라 요약본을 보여주는 거지. 가볍게 체크할 땐 좋은데, 전체 의존 관계를 다 파악해야 할 땐 이걸로 부족해. 물론 --depth all 플래그를 쓰면 되긴 하는데, 기본값이 아닐 뿐이야.


