Sohit Kumar 작성. Prinevo.ai에서 최초 게재됨.
에이전트 기반 소프트웨어 개발 수명 주기(agentic SDLC), 또는 에이전틱 SDLC는 에이전트 팀과 함께 작업하여 전체 라이프사이클에 걸쳐 작업을 수행하는 방식으로 소프트웨어를 개발하는 방법입니다. 에이전트들은 요구사항을 구체화하고, 디자인을 제안하며, 변경 사항을 구현하고, 코드를 검토하며, 동작을 검증하고, 릴리스 작업을 준비합니다. 이들은 관련 컨텍스트(context)를 공유하고, 작업 결과와 발견 사항을 서로에게 전달하며, 동일한 승인된 목표를 향해 나아갑니다. 사람들은 작업의 방향을 주도하고 범위(scope), 품질(quality), 그리고 승인된 릴리스 결정에 대한 책임(accountability)을 유지합니다.
Conceptual workflow. Specialist agents share context and return findings for correction, with human owners steering the work.
개념적 워크플로우. 전문 에이전트들이 컨텍스트를 공유하고 수정할 발견 사항을 반환하며, 인간 소유자(human owners)가 작업을 주도합니다.
당신은 팀에게 기능 요청(feature request)을 제공합니다. 이 요청은 필요에 따라 변화하는 여러 단계를 거쳐 작업물을 운반해야 하며, 무언가 실패하면 수정할 결과로 반환하고, 당신의 판단이 필요한 증거 또는 결정을 가져와야 합니다.
제 autonomous software factories로 가는 길에 대한 에세이에서 저는 에이전트 팀이 엔지니어링 팀 옆에 앉아 있는 모습을 묘사했습니다. 일부 책임은 최소한의 개입만으로 수행될 수 있습니다. 다른 작업들은 제안에 도전하거나 최종 결정을 내리기 위해 엔지니어, 제품 오너(product owner), 또는 아키텍트가 필요합니다. 자율성의 수준은 각 단계마다 다를 수 있습니다.
각 에이전트는 무엇을 하나요?
소프트웨어 개발 수명 주기에는 여전히 문제 이해하기, 무엇을 구축할지 결정하기, 디자인하기, 구현하기, 그리고 결과를 확인하는 과정이 포함됩니다. 에이전트 기반 워크플로우에서는 전문 에이전트들이 정의된 책임과 결과물로 이러한 작업을 수행합니다.
| 단계 | 에이전트가 수행하는 작업 | 책임 있는 인간 오너(Owner)가 조정하거나 결정하는 사항 |
|---|
| 요구사항 (Requirements) | 요청을 명확히 하고, 모호성을 식별하며, 범위와 수용 기준을 초안 작성함 | 해당 동작이 올바른 문제를 해결하는지, 그리고 어떤 트레이드오프(tradeoffs)가 허용 가능한지 여부 |
| ... | | |
이것들은 다루어야 할 책임들입니다. 8개의 별도 서비스나 모든 변경 사항에 대한 모든 단계를 요구하지는 않습니다. 워크플로우는 적절한 경우 역할을 결합하거나 더 짧은 경로를 사용할 수 있습니다. 각 단계에 명확한 출력물과 책임 있는 오너를 지정하여 작업이 에이전트들 사이에서 누락되지 않도록 해야 합니다.
에이전트 팀은 하나의 기능을 어떻게 처리할까요?
워크스페이스 관리자가 멤버를 초대하도록 하는 예시적인 요청을 고려해 봅시다. 뷰어는 UI나 API 어느 쪽으로도 초대를 할 수 없어야 합니다.
요구사항 에이전트는 이러한 규칙들을 명시적으로 만들고 예상되는 실패 동작을 식별합니다. 디자인 에이전트는 API 권한 경로, UI, 초대 기록(invitation record), 백그라운드 이메일 워커를 확인합니다. 구현 에이전트는 승인된 규칙과 계약을 사용하여 변경 사항을 만듭니다.
리뷰어는 API가 요청자가 로그인했는지 여부는 확인하지만, 워크스페이스 역할은 확인하지 않는다는 것을 발견합니다. 그 발견 사항은 영향을 받은 리비전(revision)과 실패 시나리오와 함께 구현 단계로 되돌아갑니다.
수정 후, QA는 뷰어로서 직접 API 요청을 시도하고, 초대나 이메일 작업이 생성되지 않았는지 확인하며, 관리자 경로가 여전히 작동하는지 확인합니다. 만약 QA가 다른 실패를 발견하면, 그 발견 사항은 또 다른 수정을 위해 되돌아갑니다. 관련 검사들은 수정된 리비전에 대해 다시 실행됩니다.
Feature request
-> Requirements -> Design -> Plan
-> Implementation <-> Code review
...
도구는 그 루프를 닫아야 합니다. 인간은 동일한 발견 사항을 다른 채팅에 복사하고, 컨텍스트를 재구성하며, 다시 실행해달라고 요청하는 것을 기억할 필요가 없어야 합니다. 시스템은 그 발견 사항을 보존하고, 올바른 오너에게 라우팅하며, 그 해결책을 증거와 연결해야 합니다.
에이전트가 문제를 해결할 수 없는 경우, 명확한 차단점(blocker)과 이미 시도된 내용을 기록하며 실행을 중지해야 합니다. 반복적인 에이전트의 동의는 기능이 정확함을 증명하지 못합니다. 표준은 승인된 동작 방식과 독립적으로 검증 가능한 증거입니다.
에이전트를 연결하는 것은 무엇인가?
공유 컨텍스트(Shared context)는 에이전트에게 적용 가능한 비즈니스 규칙, 아키텍처, 계약 및 승인된 결정을 제공합니다. 소스와 개정 이력을 보이게 유지해야 합니다. 구현 요약은 유용하지만, 검토(review)와 QA가 기대할 수 있는 내용을 담는 유일한 진술이 될 수는 없습니다.
오케스트레이션 레이어(orchestration layer)는 인계를 관리합니다. 누가 작업을 소유하는지, 어떤 입력값이 필요한지, 어떤 의존성(dependencies)이 준비되었는지, 다음 작업이 시작되기 전에 승인이 필요한지를 추적합니다. 또한 작업이 이전 단계로 돌아갈 때 수정 이력도 보존합니다.
검증 레이어(verification layer)는 에이전트가 애플리케이션을 실행하고 동작을 검사할 수 있는 환경을 제공합니다. 생성된 테스트 계획은 유용한 준비 과정입니다. 이것 자체가 변경 사항이 테스트되었다는 증거는 아닙니다.
거버넌스(Governance)는 각 에이전트의 도구, 저장소 및 환경 접근 권한, 운영 한계 및 승인 범위를 지정합니다. 공유 컨텍스트가 모든 에이전트에게 모든 권한을 부여하는 것은 아닙니다. 학습(Learning)은 공유 지식과 운영 설정을 개선할 것을 제안하며, 이는 기본값(default)이 되기 전에 검토와 평가를 거칩니다.
소프트웨어 팩토리 구현 가이드는 이러한 지원 구성 요소를 구축하는 방법을 설명합니다. 이것들이 전문 에이전트들이 하나의 배포 시스템처럼 작동하게 만드는 요소입니다.
사람들은 어디에서 통제권을 유지하는가?
아키텍트는 제안된 설계가 회사가 아직 해결할 필요가 없는 규모 문제를 해결한다고 결정할 수 있습니다. 제품 책임자(Product owner)는 구현이 시작되기 전에 요구사항을 변경할 수 있습니다. 검증 담당자(verification owner)는 증거가 중요한 권한 케이스를 다루지 못한다는 것을 발견할 수도 있습니다.
워크플로우는 해당 담당자가 작업을 검사하고, 피드백을 제공하며, 책임 있는 에이전트에게 재지정할 수 있도록 해야 합니다. 승인이 필요한 경우, 이를 아티팩트 리비전(artifact revision)에 기록해야 합니다. 하위 작업이 계속 진행되려면 물질적인 리비전(material revision)에 대해 새로운 결정이 필요할 수 있습니다.
인간의 통제는 또한 실행을 일시 중지하고, 그 도구와 증거를 검사하며, 허용된 범위를 변경하거나 중단하는 것을 의미합니다. 이러한 제어 기능은 에이전트를 둘러싼 운영 체제(operating system)에 존재해야 합니다.
작고 경계가 명확한 수정 사항의 경우, 팀은 짧은 구현, 검토 및 검증 경로를 구성할 수 있습니다. 시스템 간의 기능(cross-system feature)은 구현이 확산되기 전에 요구사항 및 설계 승인이 필요할 수 있습니다. 또한 팀은 개별 에이전트를 호출하여 기존 PR을 검토하거나 검증하게 할 수도 있습니다.
워크플로우는 변경 사항에 맞춰져야 합니다. 팀이 책임이 잘 처리되고 있다는 증거를 갖게 될수록 자율성은 커집니다.
팀이 받아야 하는 것은 무엇인가?
검토자가 사용할 수 있는 PR의 경우, 승인된 동작(accepted behavior), 영향을 받은 구성 요소(affected components), 코드 리비전, 실제로 실행된 검사 항목, 결과 및 해결되지 않은 격차를 기대해야 합니다. 검토 발견 사항은 해결책이나 명시적인 소유자 결정이 있어야 합니다. 검증은 자신이 확인한 리비전과 환경을 식별해야 합니다.
샌드박스 통과(sandbox pass)가 프로덕션 배포가 완료되었음을 의미하지는 않습니다. 병합 권한, 롤아웃 결정, 프로덕션 검사 및 관찰은 그 자체로 관리되는 작업으로 남아 있습니다.
시스템을 팀이 여전히 필요로 하는 작업량으로 판단해야 합니다. 명확화, 조정, 환경 복구, 검토 및 수정에 얼마나 많은 시간이 투입되었습니까? 해당 실행(run)이 품질 기준을 충족하면서도 그 노력을 줄였습니까?
real-change evaluation scorecard는 대표적인 변경 사항에 대해 이를 평가할 수 있는 방법을 제공합니다. 팀이 평가할 수 있는 요청으로 시작한 다음, 각 에이전트가 무엇을 했는지 그리고 인간 검토자가 여전히 해결해야 할 것이 무엇인지 검사하십시오.
엔지니어링 팀을 에이전틱 SDLC로 전환하는 방법 보기.
