대부분의 자율 소프트웨어 개발에 대한 논의는 에이전트가 코드를 작성하는 것에서 시작합니다. 에이전트가 이슈를 가져와 기능을 구현하고 pull request를 생성합니다. 데모가 작동하고 사람들은 기대에 부풉니다.
자율적인 전달이 안정적으로 작동하려면 먼저 누군가가 자율성이 작동할 엔지니어링 시스템을 설계해야 합니다. 프로젝트 구조, 기술 선택, 아키텍처 경계, 디자인 방향, 엔지니어링 규칙, 검증 메커니즘, 전문가 역할, 승인 경계 등이 그것입니다. 이러한 것들은 독립적인 에이전트들이 병렬로 추측하는 것으로부터 나와서는 안 됩니다.
제 접근 방식은 다른 책임 분담에서 시작합니다. 인간은 엔지니어링 시스템을 설계합니다. 전문 에이전트는 작업을 실행합니다. 비동기 루프는 작업이 언제 발생하고 다음에 무엇을 할지 조정합니다.
목표는 소프트웨어 개발에서 인간을 제거하는 것이 아닙니다. 판단, 맥락, 제품 이해가 필요한 결정에 인간의 참여를 집중하고, 더 많은 실행이 자체적으로 계속될 수 있는 환경을 구축하는 것입니다.
다음은 제가 결국 제가 지켜보지 않아도 실행될 프로젝트를 시작할 때마다 따르는 여섯 가지 단계입니다.
1단계: 인간이 엔지니어링 시스템을 설계합니다
프로젝트를 시작할 때, 저는 자율 에이전트에게 기반을 발명하도록 요청하지 않습니다.
먼저 중요한 부분을 결정합니다: 저장소가 어떻게 구성되어야 하는지, 어떤 기술을 사용할지, 주요 아키텍처 경계가 어떻게 작동하는지, 디자인 방향은 무엇인지, 어떤 엔지니어링 규칙을 따라야 하는지, 자율성이 어디에서 멈춰야 하는지. 이러한 결정이 이후 모든 것의 기초가 됩니다.
그런 다음 opencode-onboard를 사용하여 이를 저장소에 인코딩합니다.
/make-engineer는 프로젝트에 필요한 전문 AI 엔지니어를 생성합니다. 프론트엔드, 백엔드, 인프라, 테스트, 보안, 데이터, 모바일 등 제품이 요구하는 모든 분야입니다. 이들은 단순히 레이블만 다른 일반 에이전트가 아닙니다. 각 에이전트는 정의된 전문화, 일련의 능력, 그리고 엔지니어링 워크플로우 내에서 명확한 위치를 가지고 있습니다.
/make-architecture는 기술 구조와 경계를 ARCHITECTURE.md에 캡처합니다. /make-design은 시각적 언어, 디자인 토큰, 컴포넌트 패턴을 DESIGN.md에 캡처합니다. /make-guardrails는 이러한 모든 결정을 모든 에이전트가 준수해야 하는 구체적인 규칙으로 변환합니다. 아키텍처 경계, 명명 규칙, 테스트 기대치, 코드 스타일, 보안 제약, Git 관행 등이 포함됩니다. 이는 원래 개발자만 알고 있던 지식이 아니라 운영 환경의 일부가 됩니다.
저장소는 문서 이상을 포함하게 됩니다. 인코딩된 엔지니어링 조직과 그 안에서 작업할 모든 에이전트를 위한 공유된 진실의 원천을 포함합니다.
인간이 먼저 시스템을 정의합니다. 그래야만 자율 실행이 유용해집니다.
2단계: 대화형 기반이 자율성보다 먼저입니다
엔지니어링 시스템이 정의되면, 대화형으로 초기 프로젝트 기반을 구축합니다.
이 시점에서는 보통 /plan-quick과 /plan-apply를 사용합니다. /plan-quick은 집중된 목표를 분석하여 구체적이고 순서가 지정된 작업 시퀀스로 변환합니다. 완전한 사양 워크플로우보다 의도적으로 가볍습니다. 작업이 명확하고 가시성이나 제어를 잃지 않으면서 빠르게 진행하고 싶을 때 사용합니다. /plan-apply는 해당 작업을 구현하고 결과를 검증합니다.
이렇게 프로젝트의 기본 인프라를 구축합니다. 저장소 구조, 애플리케이션 스켈레톤, 데이터베이스 설정, 인증 기반, 디자인 시스템, 테스트 인프라, CI/CD 구성, 배포 기반 등이 포함됩니다.
프로젝트 초기 단계에는 이후에 구축되는 모든 것에 영향을 미치는 결정이 포함됩니다. 약한 추상화, 일관성 없는 폴더 구조, 불명확한 테스트 전략 등이 있습니다. 이러한 것들은 자율 에이전트가 작업을 시작하면 수백 번 반복될 수 있습니다. 실제로 그런 일이 발생하는 것을 보았습니다. 예쁘지 않습니다.
따라서 이 단계는 빠르고 AI 지원을 받지만, 감독을 받는 상태로 유지됩니다.
목표는 가능한 한 빨리 자율성을 최대화하는 것이 아닙니다. 목표는 프로젝트를 충분히 안정적이고 이해 가능하며 예측 가능하게 만들어 자율성이 나중에 그 안에서 안전하게 작동할 수 있도록 하는 것입니다.
3단계: 인간의 참여가 프로젝트 정책이 됩니다
기반이 준비된 후에는 전달 시스템이 얼마나 많은 자율성을 가져야 하는지 결정합니다.
이는 수동 개발과 완전 자동화 사이의 이분법적 선택이 아닙니다. 인간의 참여는 라이프사이클의 다양한 지점에서 존재할 수 있으며, 올바른 구성은 프로젝트에 따라 다릅니다.
완전히 감독되는 프로젝트는 인간이 이슈를 정제하고, 구현 계획을 승인하고, pull request를 검토하고, 병합을 승인하고, 배포를 승인해야 할 수 있습니다.
부분적으로 자율적인 프로젝트는 AI가 정제하고 구현하도록 허용하는 반면, 인간은 해결되지 않은 질문에 답변하고, 중요한 pull request를 검토하거나, 최종 병합에 대한 제어를 유지할 수 있습니다.
고도로 자율적인 프로젝트는 필요한 가드레일, 테스트, 품질 검사가 통과하면 시스템이 자동으로 변경을 정제, 구현, 검토, 병합하도록 할 수 있습니다.
요구사항이 불안정한 신제품은 성숙한 내부 도구보다 더 많은 인간의 참여가 필요합니다. 규제된 시스템은 작은 실험에는 불필요한 명시적 승인 게이트를 요구합니다. 그리고 동일한 프로젝트는 아키텍처, 테스트, 전달 메커니즘이 성숙해짐에 따라 시간이 지남에 따라 더 자율적으로 될 수 있습니다.
중요한 점은 자율성이 의도적으로 정의된다는 것입니다. 이슈 정제, 질문 해결, 계획 승인, pull request 검토, 병합 승인, 배포 승인. 이는 우발적인 중단이 아닙니다. 이는 엔지니어링 시스템에서 구성 가능한 게이트입니다.
모든 프로젝트는 다른 수준의 자율성을 선택하며, 그 경계는 프로젝트와 함께 진화합니다.
4단계: 아이디어가 지속 가능한 백로그 항목이 됩니다
대화형 콘솔은 여전히 아이디어를 조사하는 장소입니다.
아이디어가 불완전할 때는 /plan-explore를 사용합니다. 이는 구현 명령이 아닙니다. 협력적인 탐색 프로세스입니다. 에이전트가 저장소를 검토하고, 관련 컴포넌트를 매핑하고, 기존 패턴을 식별하고, 가정에 도전하고, 종속성을 추적하고, 위험을 고려하고, 실제로 무엇을 구축해야 하는지 결정하는 데 도움을 줍니다.
많은 개발 문제는 처음에는 코딩 작업처럼 보이지만 실제로는 이해 문제입니다. 불명확한 아이디어를 직접 자율 구현 워크플로우에 보내면 일반적으로 불명확한 구현이 생성됩니다. 탐색은 아이디어가 해결책에 조기에 확정되지 않으면서 실행 가능할 만큼 충분한 구조를 갖도록 합니다.
방향이 명확해지면 /ops-backlog를 사용하여 GitHub, Azure DevOps 또는 Jira에 구조화된 작업 항목을 만듭니다. 작업 항목은 대화형 사고와 비동기 실행 사이의 지속 가능한 핸드오프가 됩니다. 워크플로우의 다음 단계에 필요한 컨텍스트, 범위, 수락 기준, 위험, 해결되지 않은 질문, 종속성을 포함할 수 있습니다.
이 시점에서 백로그는 더 이상 단순히 작업이 저장되는 장소가 아닙니다. 인간, 에이전트, 루프 사이의 공유 조정 레이어가 됩니다.
인간은 아이디어를 만들고, 질문에 답변하고, 결정을 내립니다. 루프는 이슈 상태를 관찰하고 적격 작업을 선택합니다. 에이전트는 실행에 필요한 컨텍스트와 함께 집중된 작업을 받습니다.
백로그는 대화형 대화를 지속 가능한 작업으로 변환하여 대화가 끝난 후에도 계속 진행됩니다.
5단계: loop-task가 비동기 작업을 조정합니다
프로젝트, 엔지니어, 가드레일, 백로그, 승인 정책이 준비되면 로컬 머신이나 VM 내에서 loop-task를 구성합니다.
loop-task는 외부 오케스트레이션 루프를 실행합니다. 이 루프들은 지속적으로 백로그를 검사하고, 적격 작업을 식별하고, 적절한 엔지니어링 워크플로우를 호출하고, 각 이슈의 상태를 업데이트합니다.
정제 루프는 새 이슈를 선택하고, 조사하고, 사양을 개선하고, 정보가 누락된 경우 질문을 추가할 수 있습니다. 인간의 결정이 필요한 경우 이슈는 대기 상태로 전환됩니다. 사람이 가능할 때 답변하고, 정보가 나타나면 루프가 재개됩니다.
이슈가 충분히 명확해지면 구현 준비 상태로 전환됩니다. 구현 루프가 이를 선택하고 자율 엔지니어링 워크플로우를 호출합니다.
검토 루프는 pull request 피드백을 검사하고, 수정 사항을 조정하고, 필요한 워크플로우를 다시 실행하고, 변경을 수락 쪽으로 이동시킬 수 있습니다. 완료 루프는 수락된 작업을 병합하고, 관련 이슈를 닫고, 다음 적격 항목이 시스템에 진입하도록 허용할 수 있습니다.
루프는 서로 직접 통신할 필요가 없습니다. 지속 가능한 백로그 상태를 통해 조정합니다. 일반적인 이슈는 다음과 같은 라이프사이클을 통해 이동합니다:
새로 생성, 정제 중, 답변 대기 중, 구현 준비 완료, 구현 중, Pull request, 검토 중, 완료.
인간은 프로젝트 정책이 요구할 때마다 프로세스에 진입할 수 있지만, 시스템은 누군가가 지속적으로 터미널을 지켜보는 것에 의존하지 않습니다. 개발자가 오프라인 상태일 때도 VM은 계속 백로그를 확인하고 적격 작업을 진행시킵니다.
이것이 루프 엔지니어링의 중심에 있는 구분입니다:
에이전트는 작업을 실행합니다. 루프는 작업이 언제 존재하는지, 언제 시작해야 하는지, 어떤 워크플로우가 실행해야 하는지, 다음에 무엇이 발생하는지 결정합니다.
6단계: /plan-goal이 하나의 이슈를 처음부터 끝까지 실행합니다
구현 루프가 준비된 이슈를 찾으면 /plan-goal을 호출합니다.
이 명령은 제품 방향을 결정하거나 프로젝트 아키텍처를 발명하는 책임이 없습니다. 그러한 결정은 이미 이루어졌고 저장소에 인코딩되었습니다. 이 명령의 책임은 기존 엔지니어링 시스템 내에서 충분히 정제된 하나의 작업 항목을 실행하는 것입니다.
/plan-goal은 이슈를 읽고, 코드베이스의 관련 부분을 탐색하고, OpenSpec 제안을 생성하고, 구조화된 작업을 생성하고, 사양 또는 테스트 격차를 식별하고, 적절한 전문 엔지니어를 선택하고, 모델 티어를 할당하고, 종속성을 계산하고, 구현 작업을 병렬 실행 웨이브로 구성합니다.
독립적이고 저장소의 다른 영역을 수정하는 작업은 서로 다른 엔지니어에게 동시에 할당될 수 있습니다. 이전 작업에 의존하거나 동일한 파일을 건드리는 작업은 필요한 순서로 실행됩니다.
리드 에이전트는 작업을 조정하고, 각 결과를 수집하고, 집중된 커밋을 만들고, 테스트, 린팅, 타입 검사, 빌드를 실행합니다. 검증을 성공적으로 완료할 수 없는 경우 변경을 배송하지 않고 중단합니다.
구현이 유효하면 브랜치가 푸시되고 필요한 컨텍스트와 증거와 함께 pull request가 생성됩니다.
그러면 구성된 프로젝트 정책이 다음에 무엇이 발생할지 결정합니다. 인간이 pull request를 검토할 수 있습니다. 다른 AI 시스템이 검토를 수행할 수 있습니다. 고도로 자율적인 프로젝트는 모든 필수 검사가 통과하면 자동으로 병합할 수 있습니다. 다른 프로젝트에서는 최종 결정이 명시적으로 인간에게 남아 있습니다.
이것은 시스템의 두 가지 오케스트레이션 레이어를 드러냅니다. loop-task는 외부 오케스트레이션 레이어입니다. 백로그 라이프사이클을 관리하고 정제, 구현, 검토 또는 완료가 언제 발생해야 하는지 결정합니다. /plan-goal과 다른 opencode-onboard 명령은 내부 엔지니어링 워크플로우를 형성합니다. 이들은 특정 변경을 탐색, 계획, 할당, 구현, 검증 및 전달하는 방법을 이해합니다.
대화를 넘어서는 시스템
프롬프트 기반 개발의 한계 중 하나는 너무 많은 상태가 일시적인 대화 내에 존재한다는 것입니다.
아키텍처를 다시 설명해야 합니다. 이전 결정이 잊혀집니다. 중단된 구현을 재개하기 어렵습니다. 개발자는 매 단계 후에 에이전트가 무엇을 해야 하는지 결정하기 위해 계속 존재해야 합니다.
이 워크플로우는 그 상태를 지속 가능한 시스템으로 이동시킵니다. 저장소에는 아키텍처, 디자인 규칙, 엔지니어, 가드레일이 포함됩니다. OpenSpec에는 계획된 변경과 그 작업이 포함됩니다. Git에는 구현 기록과 복구 지점이 포함됩니다. 백로그에는 전달 상태와 인간의 결정이 포함됩니다. 로컬 머신이나 VM은 루프가 계속 실행되는 지속적인 환경을 제공합니다.
결과는 전체 소프트웨어 조직처럼 행동하려는 단일 자율 에이전트가 아닙니다. 서로 다른 구성 요소가 서로 다른 책임을 가진 조정된 시스템입니다.
인간은 방향, 제약, 책임 경계를 정의합니다. 전문 에이전트는 집중된 엔지니어링 작업을 실행합니다. 루프는 라이프사이클을 비동기적으로 조정합니다. 백로그가 이들을 연결합니다.
가장 중요한 변화는 에이전트가 더 많은 코드를 생성할 수 있다는 것이 아닙니다. 더 큰 변화는 고립된 AI 상호작용에서 지속적인 엔지니어링 시스템으로의 전환입니다.
매 작업 전에 저장소를 설명하는 대신, 프로젝트가 자체 아키텍처와 가드레일을 가지고 있습니다. 일반 에이전트에게 모든 것을 구현하도록 요청하는 대신, 작업은 전문가에게 할당됩니다. 매 단계 후에 무엇을 해야 할지 수동으로 결정하는 대신, 루프는 지속 가능한 워크플로우 상태에 반응합니다. 전체 프로세스를 대화 내에 유지하는 대신, 진행 상황은 이슈, 사양, 커밋, pull request, 로컬 상태에 지속됩니다.
인간의 역할은 사라지지 않습니다. 자율 실행이 작동하도록 허용되는 환경을 설계하는 방향으로 이동합니다.
이것이 제가 현재 구축하고 있는 모델입니다: 개발자가 먼저 엔지니어링 환경과 자율성 경계를 설정한 다음, 비동기 루프가 백로그 기반 전달 라이프사이클을 통해 전문 에이전트를 조정하는 인간 설계 AI SDLC입니다.
0에서 시작하여 루프가 스스로 실행될 때까지. 여섯 단계, 각 단계는 이전 단계 위에 구축되며, 각 단계는 조금 더 많은 상태를 대화 밖으로, 잊지 않는 시스템으로 이동시킵니다.
PS: loop-task, opencode-onboard 및 기타 도구를 ckgrafico.com에서 찾을 수 있습니다.
