원문 캡처 · github.com
원문 캡처 · github.com

Ross Shaw(로스 쇼)가 만든 BlastLoop는 AI 코딩 에이전트가 작업 범위에 맞는 수준에서 코드를 작성하고, 구조·운영·공격 관점의 테스트를 차례로 거치도록 하는 코딩 프레임워크다. 저장소는 버전 1.0.0이며, 원칙은 구조를 먼저 살피고 기능을 다룬 뒤 공격 테스트를 하는 것이다.

BlastLoop는 AI 코딩 에이전트가 팀의 작업 속도를 높이는 동시에 실패도 더 빠르게 만들 수 있다는 문제의식에서 출발한다. 각 변경 사항을 적절한 작업 수준의 담당자에게 맡기고, 결과물이 배포되기 전에 구조·운영·적대적 테스트를 정해진 순서로 통과하게 하는 운영 방식을 적용한다.

자세한 설명은 WORLDWRIGHT 3호의 AI Did Not Remove Engineering Failure. It Made It Faster.에서 볼 수 있다.

저장소를 프로젝트에 복제한 뒤 에이전트가 AGENTS.md를 참고하게 하면 5분 안에 시작할 수 있다. 작업 범위에 맞는 작성 프롬프트를 불러오고, 에이전트가 해당 범위에서 코드를 작성하게 한 다음 테스트를 순서대로 진행한다.

BlastLoop는 먼저 명세와 계획을 만들고 한 명의 구현자가 작업하는 방식이 아니다. 각 작성 단계가 자기 범위에 맞는 코드를 직접 만들어야 한다. T3에서 구조 문제가 발견되면 T1부터 다시 시작해 Blast, Mid, Inner 중 해당 작업 수준으로 수정 사항을 보내고, T2와 T3를 다시 실행한다.

각 단계의 인계 자료와 작업 배정 규칙은 docs/HANDOFFS.md에 정리돼 있다. 각 단계는 자기 관점에서 수정안을 제안할 수 있지만, 변경을 맡은 작업 수준이 최종 판단을 내리고 직접 구현한다.

Blast는 저장소 구조, 서비스 경계, 최상위 인터페이스, 공유 계약, 배포 구조 또는 새 기능의 뼈대를 바꾸는 시스템 수준의 코드를 작성한다. Mid는 시스템 재설계보다는 작지만 단일 패치보다는 큰 기능 단위, 서비스 모듈, 통합 지점, 하위 시스템 리팩터링을 맡는다. Inner는 몇 개의 파일·함수·테스트·어댑터에 한정된 작업을 수행한다. 범위가 명확하고 담당자가 정해진 작은 단위의 변경을 끝까지 처리한다.

테스트는 세 단계로 진행한다. T1은 잘못된 경계, 작업 수준에 맞지 않는 로직, 새는 추상화, 깨진 파일 소유권, 빠진 인터페이스, 잘못 배치된 공통 관심사를 찾아 코드 구조가 적절한지 판단한다. 일반적인 버그 수정 단계는 아니며, 수정이 필요하면 Inner, Mid, Blast 중 맞는 작성 단계로 돌려보낸다.

T2는 구조가 이미 적절한 경우 버그와 운영 문제를 직접 수정한다. 문제가 실제로는 아키텍처에 있다면 국소적으로 덮어 고치지 않고 T1으로 되돌린다. T3는 경계 사례, 오용, 경쟁 상태, 예상 밖의 입력, 취약한 가정, 보안 상태, 롤백 경로, 실패 동작을 살펴 결과물을 공격적으로 시험한다. T3에서 구조 문제가 나오면 T1으로 돌아가 Blast·Mid·Inner가 수정하고, 이어서 T2와 T3를 다시 진행한다. 구조적 결함은 국소 버그처럼 덧대는 대신 구조에 맞게 고쳐야 한다.

BlastLoop는 사실 검증기가 아니라 코딩·테스트 프레임워크다. GitHub Spec Kit과도 다르다. Spec Kit이 명세→계획→작업→구현→수렴 순서로 진행한다면, BlastLoop는 여러 코딩 수준과 단계별 테스트 루프를 결합한다. 특정 에이전트 스타일 하나와 경쟁하는 방식도 아니다. Spec Kit, 바이브 코딩, 집중형 로컬 구현 프롬프트, 레드팀·블루팀 테스트를 작업 수준이나 테스트 단계 안에서 함께 쓸 수 있다. 다만 공개된 버전은 관리 계층, 봇 위계, 비공개 자동화를 정의하지 않으며, 적대적 테스트만으로 이루어진 방법도 아니다. 적대적 테스트는 T3 단계에 해당한다.

BlastLoop는 하나의 코딩 스타일이나 계획 방식을 요구하지 않는다. Spec Kit은 코드 작성 전 계획에 활용할 수 있고, 바이브 코딩을 비롯한 구현 방식은 작업 범위에 따라 Blast·Mid·Inner 안에서 사용할 수 있다. 작업에 맞으면 Inner에서 집중형 로컬 구현 프롬프트를 쓸 수 있으며, 레드팀·블루팀 테스트는 T3에 적용할 수 있다. 프레임워크의 역할은 작업 수준을 고른 뒤 T1→T2→T3 순서로 진행하도록 배정하는 것이다. 유사한 공개 방법과의 간략한 비교는 docs/COMPARISON.md에서 확인할 수 있다.

저장소에는 프롬프트 선택을 안내하는 AGENTS.md, 작성·테스트 역할별 지침이 담긴 prompts/, 인계 자료와 소유권 규칙을 설명하는 docs/HANDOFFS.md, 유사 방법과의 비교를 담은 docs/COMPARISON.md, 작은 기능을 루프에 따라 진행하는 가상 예시인 examples/session.md가 포함돼 있다. 라이선스는 MIT이며 자세한 내용은 LICENSE에서 볼 수 있다.