BMAD-METHOD/docs/ko-kr/explanation/checkpoint-preview.md

title	description	sidebar
체크포인트 미리보기	목적에서 세부 사항에 이르기까지의 변경 과정을 단계별로 안내하는, LLM을 활용한 인간 중심 검토	order 3

bmad-checkpoint-preview는 LLM이 보조하는 대화형 human-in-the-loop 리뷰 워크플로입니다. 코드 변경을 목적과 컨텍스트에서 세부 사항까지 안내해, 출시할지, 다시 작업할지, 더 파고들지에 대해 충분한 정보를 바탕으로 판단할 수 있게 합니다.

일반적인 흐름

bmad-quick-dev를 실행합니다. 의도를 명확히 하고, 사양을 만들고, 변경을 구현합니다. 완료되면 사양 파일에 리뷰 경로를 붙이고 에디터에서 엽니다. 사양을 보니 여러 모듈에 걸쳐 20개 파일이 변경되었습니다.

diff를 눈으로 훑을 수도 있습니다. 하지만 20개 파일쯤 되면 눈대중 리뷰가 흔들리기 시작합니다. 흐름을 놓치고, 떨어진 두 변경 사이의 연결을 놓치거나, 충분히 이해하지 못한 것을 승인할 수 있습니다. 그래서 "checkpoint"라고 말하면 LLM이 변경을 따라가게 해 줍니다.

자율 구현에서 인간 판단으로 돌아오는 이 전환이 주된 사용 사례입니다. 빠른 개발은 최소 감독으로 오래 실행됩니다. 체크포인트 미리보기는 사용자가 다시 운전대를 잡는 지점입니다.

왜 존재하나요?

코드 리뷰에는 두 실패 모드가 있습니다. 하나는 리뷰어가 diff를 훑고 눈에 띄는 것이 없어 승인하는 경우입니다. 다른 하나는 모든 파일을 꼼꼼히 읽지만 흐름을 잃는 경우입니다. 나무는 보지만 숲을 놓칩니다. 둘 다 같은 결과를 낳습니다. 중요한 것을 잡지 못한 리뷰입니다.

근본 문제는 순서입니다. 원시 diff는 파일 순서로 변경을 보여주지만, 이 순서는 이해가 쌓이는 순서와 거의 일치하지 않습니다. 왜 필요한지 알기 전에 도우미 함수를 보고, 어떤 기능을 지원하는지 알기 전에 스키마 변경을 봅니다. 리뷰어는 흩어진 단서에서 작성자의 의도를 재구성해야 하고, 그 재구성 과정에서 집중력이 무너집니다.

체크포인트 미리보기는 재구성 작업을 LLM에게 맡겨 이 문제를 해결합니다. diff, 사양(있다면), 주변 코드베이스를 읽고 git diff가 아니라 이해를 위해 설계된 순서로 변경을 제시합니다.

작동 방식

워크플로는 다섯 단계입니다. 각 단계는 이전 단계 위에 쌓이며 "이게 뭐지?"에서 "출시해도 되나?"로 점진적으로 이동합니다.

1. 방향 잡기

워크플로는 변경(PR, 커밋, 브랜치, 사양 파일, 현재 Git 상태)을 식별하고 한 줄 의도 요약과 영역 통계를 생성합니다. 변경 파일 수, 건드린 모듈, 논리 줄 수, 경계 넘나듦, 새 공개 인터페이스 등입니다.

이 단계는 "내가 보고 있는 게 맞나?"를 확인하는 순간입니다. 코드를 읽기 전에 리뷰어는 올바른 것을 보고 있는지 확인하고 범위 기대치를 맞춥니다.

2. 둘러보기

변경은 파일이 아니라 관심사 기준으로 구성됩니다. "입력 검증"이나 "API 계약" 같은 응집력 있는 설계 의도입니다. 각 관심사에는 왜 이 접근을 택했는지 짧은 설명과 리뷰어가 코드에서 따라갈 수 있는 클릭 가능한 path:line 지점이 붙습니다.

이 단계는 설계 판단입니다. 리뷰어는 코드가 정확한지가 아니라 시스템에 맞는 접근인지 평가합니다. 관심사는 하향식으로 배치됩니다. 가장 높은 수준의 의도가 먼저 나오고 보조 구현이 뒤따릅니다. 리뷰어는 아직 보지 않은 것에 대한 참조를 만나지 않습니다.

3. 상세 검토

리뷰어가 설계를 이해한 뒤 워크플로는 실수했을 때 영향 범위가 가장 큰 2-5개 지점을 드러냅니다. 이들은 [auth], [schema], [billing], [public API], [security] 같은 위험 범주로 태그되고, 틀렸을 때 얼마나 많이 깨지는지 기준으로 정렬됩니다.

이것은 버그 찾기가 아닙니다. 자동화 테스트와 CI가 정확성을 다룹니다. 상세 검토는 위험 인식을 활성화합니다. "틀렸을 때 비용이 가장 큰 곳은 여기입니다." 특정 영역을 더 깊게 보고 싶다면 "이 영역을 더 파고들어 줘"라고 말해 정확성에 초점을 맞춘 재리뷰를 요청할 수 있습니다.

사양이 적대적 리뷰 루프를 거쳤다면 그 발견 사항도 여기서 드러납니다. 고쳐진 버그가 아니라, 리뷰 루프가 리뷰어가 알아야 한다고 표시한 결정입니다.

4. 테스트

변경이 작동하는 것을 수동으로 관찰하는 방법 2-5개를 제안합니다. 자동화 테스트 명령이 아니라 어떤 테스트 모음도 주지 못하는 확신을 만드는 수동 관찰입니다. 시도할 UI 상호작용, 실행할 CLI 명령, 보낼 API 요청과 각 예상 결과가 포함됩니다.

사용자에게 보이는 동작이 없다면 그렇다고 말합니다. 가짜 확인 작업은 만들지 않습니다.

5. 마무리

리뷰어가 결정을 내립니다. 승인, 재작업, 계속 논의 중 하나입니다. PR을 승인한다면 워크플로가 gh pr review --approve를 도울 수 있습니다. 재작업한다면 문제가 접근 방식, 사양, 구현 중 어디에서 왔는지 진단하고 특정 코드 위치와 연결된 실행 가능한 피드백 초안을 돕습니다.

보고서가 아니라 대화입니다

워크플로는 각 단계를 최종 답이 아니라 출발점으로 제시합니다. 단계 사이 또는 단계 도중에도 LLM과 대화하고, 질문하고, 구성 방식에 이의를 제기하고, 다른 스킬을 불러 다른 관점을 얻을 수 있습니다.

• "오류 처리를 고급 도출로 다시 검토해 줘" - 특정 영역 분석을 다시 생각하고 다듬게 합니다
• "이 스키마 마이그레이션이 안전한지 파티 모드로 토론해 줘" - 집중 토론에 여러 에이전트 관점을 불러옵니다
• "코드 리뷰 실행" - 적대적 리뷰와 엣지 케이스 분석을 포함한 구조화된 에이전트 기반 발견 사항을 생성합니다

체크포인트 워크플로는 선형 경로에 가두지 않습니다. 구조가 필요할 때는 구조를 주고, 탐색하고 싶을 때는 여지를 남깁니다. 다섯 단계는 전체 그림을 보게 하기 위한 것이지만, 각 단계에서 얼마나 깊게 들어갈지와 어떤 도구를 가져올지는 전적으로 사용자에게 달려 있습니다.

리뷰 경로

둘러보기 단계는 권장 리뷰 순서가 있을 때 가장 잘 작동합니다. 이는 사양 작성자가 리뷰어를 변경으로 안내하기 위해 쓴 지점 목록입니다. 사양에 이 정보가 있으면 워크플로가 그대로 사용합니다.

작성자가 만든 경로가 없으면 워크플로가 diff와 코드베이스 컨텍스트에서 생성합니다. 생성된 경로는 작성자가 만든 경로보다 품질이 낮지만, 파일 순서로 변경을 읽는 것보다는 훨씬 낫습니다.

사용 시점

주요 시나리오는 bmad-quick-dev에서의 인계입니다. 구현이 끝났고, 리뷰 경로가 붙은 사양 파일이 에디터에 열려 있으며, 출시 여부를 결정해야 합니다. "checkpoint"라고 말하면 됩니다.

단독으로도 동작합니다.

• PR 리뷰 - 특히 몇 개 파일을 넘거나 여러 영역에 걸친 변경이 있을 때
• 변경 온보딩 - 직접 작성하지 않은 브랜치에서 무슨 일이 있었는지 이해해야 할 때
• 스프린트 리뷰 - 스프린트 상태 파일에서 review로 표시된 스토리를 집어올 수 있습니다

"checkpoint" 또는 "이 변경을 따라가며 설명해 줘"라고 호출하세요. 어떤 터미널에서도 작동하지만 IDE(VS Code, Cursor 등) 안에서 더 편하게 사용할 수 있습니다. 워크플로가 모든 단계에서 path:line 참조를 생성하고, IDE 내장 터미널에서는 이들이 클릭 가능하므로 리뷰 경로를 따라 파일 사이를 이동할 수 있습니다.

아닌 것

체크포인트 미리보기는 자동화 리뷰의 대체물이 아닙니다. 린터, 타입 검사기, 테스트 모음을 실행하지 않습니다. 심각도 점수를 붙이거나 통과/실패 결정을 만들지 않습니다. 사람이 가장 중요한 곳에 판단을 적용하도록 돕는 읽기 가이드입니다.