74 lines
6.2 KiB
Markdown
74 lines
6.2 KiB
Markdown
---
|
|
title: "빠른 개발"
|
|
description: 출력 품질을 보호하는 체크포인트를 포기하지 않고 사람이 개입하는 검토의 마찰을 줄입니다
|
|
sidebar:
|
|
order: 4
|
|
---
|
|
|
|
의도를 넣으면 코드 변경이 나오고, 사람이 개입하는 검토 단계는 가능한 한 적게 사용합니다. 품질은 희생하지 않습니다.
|
|
|
|
모델이 체크포인트 사이에서 더 오래 실행되게 한 뒤, 작업이 인간 판단 없이 안전하게 계속될 수 없거나 최종 결과를 리뷰할 때만 사람을 다시 불러옵니다.
|
|
|
|
|
|
|
|
## 왜 존재하나요?
|
|
|
|
사람이 개입하는 검토 단계는 필요하지만 비용이 큽니다.
|
|
|
|
현재 LLM은 여전히 예측 가능한 방식으로 실패합니다. 의도를 잘못 읽고, 공백을 자신 있게 추측으로 채우고, 관련 없는 작업으로 흐름이 새며, 잡음 많은 리뷰 출력을 만듭니다. 동시에 지속적인 인간 개입은 개발 속도를 제한합니다. 사람의 주의력이 병목이 됩니다.
|
|
|
|
`bmad-quick-dev`는 이 절충점을 다시 조정합니다. 워크플로가 안전을 위한 충분히 강한 경계를 만든 뒤에는 모델이 더 긴 구간을 감독 없이 실행하도록 신뢰합니다.
|
|
|
|
## 핵심 설계
|
|
|
|
### 1. 먼저 의도를 압축합니다
|
|
|
|
워크플로는 사람과 모델이 요청을 하나의 일관된 목표로 압축하는 것에서 시작합니다. 입력은 거친 의도 표현일 수 있지만, 워크플로가 자율적으로 실행되기 전에는 실행 가능한 만큼 작고, 명확하고, 모순이 없어야 합니다.
|
|
|
|
의도는 다양한 형태로 올 수 있습니다. 몇 문구, 버그 추적기 링크, 계획 모드 출력, 채팅 세션에서 복사한 텍스트, 또는 BMAD의 `epics.md`에 있는 스토리 번호일 수 있습니다. 마지막 경우 워크플로는 BMAD 스토리 추적 규칙을 이해하지는 않지만, 스토리 자체를 가져와 실행할 수 있습니다.
|
|
|
|
이 워크플로는 인간 통제를 없애지 않습니다. 통제를 소수의 가치가 큰 순간으로 옮깁니다.
|
|
|
|
- **의도 명확화** - 정돈되지 않은 요청을 숨은 모순 없는 하나의 일관된 목표로 바꿉니다
|
|
- **사양 승인** - 고정된 이해가 만들 올바른 것인지 확인합니다
|
|
- **최종 결과 검토** - 최종 결과를 받아들일 수 있는지 사람이 결정하는 핵심 체크포인트입니다
|
|
|
|
### 2. 가장 작은 안전한 경로를 선택합니다
|
|
|
|
목표가 명확해지면 워크플로는 정말 한 번에 처리 가능한 변경인지, 더 완전한 경로가 필요한지 결정합니다. 작고 영향 범위가 거의 없는 변경은 바로 구현으로 갈 수 있습니다. 그 밖의 모든 것은 모델이 더 오래 혼자 실행되기 전에 더 강한 경계를 갖도록 계획을 거칩니다.
|
|
|
|
### 3. 더 적은 감독으로 더 오래 실행합니다
|
|
|
|
경로 결정 이후 모델은 더 많은 작업을 스스로 수행할 수 있습니다. 더 완전한 경로에서는 승인된 사양이 모델이 적은 감독으로 실행하는 경계가 되며, 이것이 설계의 핵심입니다.
|
|
|
|
### 4. 올바른 계층에서 실패를 진단합니다
|
|
|
|
의도가 틀려 구현이 틀렸다면 코드 패치는 잘못된 수정입니다. 사양이 약해서 코드가 틀렸다면 diff 패치도 잘못된 수정입니다. 워크플로는 실패가 시스템에 들어온 계층을 진단하고, 그 계층으로 돌아가 다시 생성하도록 설계되었습니다.
|
|
|
|
리뷰 발견 사항은 문제가 의도, 사양 생성, 로컬 구현 중 어디에서 왔는지 결정하는 데 쓰입니다. 정말 로컬 문제만 로컬 패치를 받습니다.
|
|
|
|
### 5. 필요할 때만 사람을 다시 부릅니다
|
|
|
|
의도 인터뷰는 사람이 개입하는 과정이지만 반복 체크포인트와는 다른 중단입니다. 워크플로는 반복 체크포인트를 최소화하려 합니다. 초기 구체화 이후 사람은 워크플로가 판단 없이 안전하게 계속할 수 없을 때와 마지막 리뷰 시점에 주로 돌아옵니다.
|
|
|
|
- **의도 공백 해소** - 리뷰가 워크플로가 의도를 안전하게 추론할 수 없었음을 보여줄 때 다시 들어옵니다
|
|
|
|
나머지는 더 긴 자율 실행 후보입니다. 이 절충은 의도적입니다. 오래된 패턴은 지속적인 감독에 더 많은 사람의 주의력을 씁니다. 빠른 개발은 모델에 더 많은 신뢰를 주지만, 사람의 판단이 가장 큰 효과를 내는 순간을 위해 주의력을 아낍니다.
|
|
|
|
## 리뷰 시스템이 중요한 이유
|
|
|
|
리뷰 단계는 버그를 찾기 위해서만 있는 것이 아닙니다. 추진력을 잃지 않고 수정을 올바른 경로로 보내기 위해 있습니다.
|
|
|
|
이 워크플로는 하위 에이전트를 생성할 수 있거나, 적어도 명령줄로 다른 LLM을 호출하고 결과를 기다릴 수 있는 플랫폼에서 가장 잘 동작합니다. 플랫폼이 기본으로 지원하지 않는다면 이를 수행하는 스킬을 추가할 수 있습니다. 컨텍스트 없는 하위 에이전트는 리뷰 설계의 핵심입니다.
|
|
|
|
에이전트 기반 리뷰는 보통 두 방식으로 잘못됩니다.
|
|
|
|
- 발견 사항이 너무 많아 사람이 노이즈를 걸러야 합니다.
|
|
- 관련 없는 이슈를 끌어들여 현재 변경의 흐름을 깨고, 모든 실행을 즉석 정리 작업으로 바꿉니다.
|
|
|
|
빠른 개발은 리뷰를 분류 작업으로 다뤄 둘 다 해결합니다.
|
|
|
|
어떤 발견 사항은 현재 변경에 속합니다. 어떤 발견 사항은 그렇지 않습니다. 발견 사항이 현재 작업과 인과적으로 연결되지 않은 부수적 이슈라면, 워크플로는 즉시 처리하도록 강제하지 않고 미룰 수 있습니다. 이렇게 하면 실행이 집중되고 무작위 곁가지가 주의력 예산을 소비하지 않습니다.
|
|
|
|
분류는 때때로 완벽하지 않습니다. 괜찮습니다. 수천 개의 낮은 가치 리뷰 댓글로 사람을 압도하는 것보다 일부 발견 사항을 잘못 판단하는 편이 보통 낫습니다. 이 시스템은 모든 이슈를 빠짐없이 회수하는 것보다 신호 품질을 최적화합니다.
|