AI 코딩 에이전트에 구조 우선 공정을 적용하는 BlastLoop

Hacker News16일 전조회 1

AI 코딩 에이전트를 쓰는 팀이 늘면서 코드가 나오는 속도만큼 실패도 빨라졌다는 문제의식이 커지고 있다. Ross Shaw가 공개한 BlastLoop는 이 문제를 프롬프트 한 줄이 아니라 작업 공정의 문제로 다룬다. 코드를 쓰는 단계와 그것을 검증하는 단계를 분리하고, 각 단계에 명확한 소유자와 순서를 부여하는 것이 핵심이다. 표어는 "구조 먼저, 기능 다음, 공격은 그다음"이다.

빌드 계층은 세 가지 고도로 나뉜다. Blast는 저장소 구조, 서비스 경계, 최상위 인터페이스, 공유 계약, 배포 구조, 새 기능의 골격처럼 시스템 수준을 다룬다. Mid는 로컬 패치보다는 크지만 시스템 재설계보다는 작은 범위, 예컨대 기능 슬라이스나 서비스 모듈, 통합 지점, 하위 시스템 리팩터링을 맡는다. Inner는 몇 개의 파일과 함수, 테스트, 어댑터처럼 국소 단위에 집중한다. 중요한 전제는 하나의 구현자가 전체를 도맡는 방식이 아니라는 점이다. 각 고도가 자기 범위의 코드를 직접 생산한다.

검증은 T1, T2, T3 순서로 진행된다. T1은 구조 게이트로, 경계가 잘못 잡혔는지, 로직이 엉뚱한 고도에 놓였는지, 추상화가 새는지, 파일 소유권이 깨졌는지, 인터페이스가 빠졌는지, 횡단 관심사가 잘못 배치됐는지를 본다. 일반적인 버그 수정자가 아니라 코드의 형태가 맞는지를 판정하고 수정을 올바른 작성자에게 되돌려 보내는 역할이다. T2는 구조가 이미 건전할 때 버그와 운영 문제를 직접 고친다. 다만 문제의 실체가 아키텍처라면 국소적으로 덮지 않고 T1으로 되돌린다. T3는 결과물을 공격한다. 경계 조건, 오용, 경쟁 상태, 이상한 입력, 취약한 가정, 보안 태세, 롤백 경로, 실패 동작이 대상이다.

T3에서 구조적 결함이 드러나면 루프는 T3에서 T1으로 돌아가고, 다시 Blast·Mid·Inner 중 해당 고도가 수정한 뒤 T2와 T3를 재실행한다. 구조적 파손은 국소 버그로 덮지 말고 구조적으로 고치라는 규칙이 이 프레임워크의 요체다. 단계 간 인계에는 정해진 패킷과 라우팅 규칙이 요구되며, 각 단계는 자기 시점에서 수정을 제안할 수 있지만 결정과 구현은 해당 고도를 소유한 쪽이 한다.

배경에는 에이전트 도입이 실패 자체를 없애지는 못한다는 진단이 깔려 있다. 작성자는 별도 뉴스레터에서 AI가 엔지니어링 실패를 제거한 것이 아니라 더 빠르게 만들었다는 논지를 펼쳤고, BlastLoop는 그 실패를 운영 관점에서 통제하려는 시도다. 기존 방법론과의 관계도 분명히 해 둔다. 스펙 우선 방식인 GitHub Spec Kit과는 다르며, 특정 에이전트 스타일과 경쟁하지도 않는다. 스펙 기반 계획, 바이브 코딩, 국소 구현 프롬프트, 레드·블루 테스트는 각각 고도나 테스트 계층 안에 들어갈 수 있는 요소다. 대립하는 방법론이 아니라 작업을 올바른 고도로 라우팅하는 상위 루프를 지향한다.

적용 절차는 단순하다. 에이전트의 도움을 받을 프로젝트에 저장소를 복제하고, 에이전트가 AGENTS.md를 읽도록 지정한 다음, 작업 고도에 맞는 프롬프트 하나를 불러오면 된다. 시스템이나 저장소 형태를 바꾸는 일이면 blast, 하위 시스템이나 기능 슬라이스면 mid, 파일·함수 단위 변경이면 inner를 쓴다. 저장소에는 라우팅 카드 역할의 AGENTS.md, 역할별 지침이 담긴 prompts 디렉터리, 인계 패킷과 소유권 규칙을 정리한 docs/HANDOFFS.md, 인접 방법론과 비교한 docs/COMPARISON.md, 작은 기능이 루프를 도는 과정을 담은 examples/session.md가 포함돼 있다. 라이선스는 MIT다.

실무적으로 달라지는 지점은 리뷰 순서다. 구조 검토를 맨 앞에 두고, 그다음 버그와 운영, 마지막에 적대적 공격을 배치하면 에이전트가 만든 변경이 어느 고도에서 잘못됐는지 추적하기 쉬워진다. 반대로 구조 게이트를 건너뛰고 국소 수정만 반복하면 같은 결함이 다른 파일에서 되풀이되기 쉽다.

한계도 분명하다. 이 프레임워크는 코드 작성과 테스트를 다루는 도구이지 사실을 검증하는 진실 엔진이 아니다. 공개된 범위에는 관리 계층이나 봇 조직도, 비공개 자동화가 정의돼 있지 않으며, 적대적 테스트는 전체 방법의 일부인 T3에 해당할 뿐이다. 특정 코딩 스타일이나 계획 방식을 강제하지도 않는다.