제안 및 검증
제안 및 검증
ElevenAgents Architect의 변경 사항이 테스트, 검토되고 라이브 트래픽에 롤아웃되는 방식.
개요
ElevenAgents Architect가 변경 작업을 완료하면 제안으로 전달합니다. 제안에는 변경 사항이 담긴 브랜치, 변경 사항이 작동함을 보여 주는 테스트, 그리고 해당 브랜치를 main에 병합해 달라는 병합 제안이 포함됩니다. 이 페이지에서는 각 요소의 작동 방식, 찾는 위치, 그리고 대화에서 시작한 제안이 실제 트래픽에 적용되기까지의 과정을 설명합니다.
제안이란
제안은 기존 버전 관리 모델을 기반으로 합니다.
병합 제안은 팀원이 직접 여는 것과 같은 일반적인 ElevenAgents 병합 제안입니다. 별도의 객체 유형이 아닙니다.
병합 제안은 정확히 하나의 소스 브랜치와 하나의 대상 브랜치에 적용되므로, 하나의 제안에는 하나의 후보 솔루션이 담깁니다. 대안을 비교하려면 Architect에게 각각 별도 브랜치에 만들도록 요청하세요. 그러면 각 브랜치에 자체 제안이 생성되며, 실험으로 브랜치 간 트래픽을 분할할 수 있습니다.
Architect는 사용자를 대신해 작업하므로, Architect가 여는 병합 제안은 작성자가 사용자 이름으로 기록됩니다. Architect가 만들었다는 사실을 기록하는 필드는 없습니다. 팀에서 이를 알아야 한다면 제안 설명에 언급하세요.
제안 생성 방식
문제를 수정하거나 개선하도록 요청할 때, 또는 실패한 테스트, Spotlight 분석 결과, 분류 티켓을 전달할 때 Architect가 제안을 만듭니다. 각 단계에서 Architect가 호출하는 도구를 포함한 전체 과정은 작동 예시에서 확인할 수 있습니다. 간단히 말하면 다음과 같습니다.
- Architect가 조사하고 브랜치를 만든 다음, 해당 브랜치의 초안에 변경 사항을 스테이징합니다.
- Architect가 변경 사항을 위한 테스트와 시뮬레이션을 작성하고, 결과를 보여 주기 전에 대화에서 실행합니다.
- Architect가 게시 대화상자를 엽니다. diff를 검토하고 게시를 선택하면 변경 사항이 브랜치의 새 버전으로 커밋됩니다.
- Architect가
main에 대한 병합 제안을 열고, 브랜치의 실제 커밋과 테스트 실행 결과를 바탕으로 설명을 작성합니다. - 제안을 검토하는 동안 일부 실제 트래픽을 브랜치로 보낼 것을 Architect가 제안합니다. 이 작업에는 승인이 필요합니다.
어느 단계에서든 중단할 수 있습니다. 게시된 버전은 있지만 병합 제안이 없는 브랜치도 유용합니다. 직접 테스트하거나 나중에 제안을 열 수 있습니다.
대화 내 검증
Architect는 변경 사항을 만든 과정의 일부로 테스트를 작성하고 실행하며, 나중에 별도로 시작하는 단계가 아닙니다. 수정의 경우, 새 테스트가 변경 사항 없이는 실패하고 변경 사항이 있으면 통과함을 보여 주는 방식이 유용합니다. Architect는 원본 브랜치와 변경 사항이 포함된 초안을 대상으로 같은 테스트를 실행할 수 있습니다.
Architect가 모든 변경 사항에 대해 이 전후 검사를 자동으로 실행하지는 않습니다. 필요한 경우 요청하세요. 예: “새 시뮬레이션이 main에서는 실패하고 브랜치에서는 통과하는 것을 보여 준 다음 제안을 열어 줘.”
모든 성공 조건을 충족하면 테스트가 통과합니다. LLM 테스트에서는 에이전트의 응답이 성공 기준을 충족해야 합니다. 도구 호출 테스트에서는 예상한 도구가 예상한 매개변수로 호출되어야 합니다. 시뮬레이션에서는 시뮬레이션된 대화가 성공 조건을 충족해야 합니다. 불안정한 결과를 확인하려면 Architect에게 테스트를 여러 번 실행하도록 요청하세요. 각 테스트를 최대 50회 반복하고 통과율을 보고할 수 있습니다.
각 테스트 유형의 정의는 테스트에서 확인하세요.
제안 찾기
에이전트를 열고 버전 관리 > 제안으로 이동하세요. 목록은 상태, 작성자(작성자), 검토자(검토 대기 중, 검토 완료)별로 필터링할 수 있습니다. 대화에서 Architect가 연 제안은 사용자가 작성자로 표시됩니다.
Architect는 제안을 생성하는 즉시 대화에서도 제안 링크를 반환합니다.
제안 구성
제안 페이지에는 소스 및 대상 브랜치, 상태, 병합 가능 여부, 소스 브랜치가 대상보다 얼마나 뒤처지거나 앞서 있는지가 표시됩니다. 다음 탭이 있습니다.
개요
변경 사항
테스트 실행
대화
설명, 소스 브랜치의 커밋·검토·댓글 활동 타임라인, 댓글 입력란이 표시됩니다. 사이드바에는 검토자, 추천 검토자, 연결된 분류 티켓이 표시됩니다.
Architect가 작성하는 설명에는 항상 세 가지 섹션이 있습니다. 요약(각 주요 변경 사항과 이유), 테스트(실행한 테스트와 결과 또는 테스트를 실행하지 않았다는 설명), 검토 방법(중점적으로 확인할 내용과 실행할 테스트 또는 시도할 대화)입니다.
검토 및 병합
상태
병합 제안에는 다음 상태 중 하나가 적용됩니다.
제안이 열려 있는 동안 각 검토자의 최신 검토 상태는 승인됨 또는 변경 요청됨입니다. 별도의 “테스트됨” 또는 “검토 준비됨” 상태는 없습니다. 대신 테스트 결과는 테스트 실행 탭에 표시됩니다.
검토와 댓글은 소스 브랜치에 커밋된 새 버전과 함께 개요 탭의 활동 타임라인에 표시됩니다.
승인 및 병합 권한
- 에이전트에 대한 편집자 액세스 권한이 있는 사람은 작성자를 제외하고 제안을 검토할 수 있습니다. Architect는 사용자를 대신해 작업하므로, 대화에서 Architect가 연 제안은 승인할 수 없습니다. 팀원이 승인해야 합니다.
- 작성자가 아닌 사람의 승인이 하나 이상 있고 검토자 중 누구의 최신 검토도 변경 요청됨이 아닐 때 제안을 병합할 수 있습니다. 워크스페이스 관리자는 승인 없이 병합할 수 있습니다.
- 보호된 브랜치에 병합하려면 관리자 권한 또는 관리자의 승인이 필요합니다.
Architect는 병합 제안을 승인, 댓글 작성, 병합 또는 닫기할 수 없습니다. 이러한 단계는 항상 사람이 수행합니다. 전체 검토 규칙은 병합 제안을 참조하세요.
Architect는 요청하고 역할에 병합 권한이 있으면 제안 없이 브랜치를 직접 병합할 수 있습니다. 승인 필요 모드에서는 먼저 확인을 요청합니다. 자동 승인 모드에서는 요청하지 않습니다. 모든 변경 사항이 검토된 제안을 거쳐야 한다면 main에 브랜치 보호를 적용하세요.
병합 시 발생하는 일
병합 후 별도의 게시 단계는 없습니다. 병합하면 대상 브랜치에 새 버전이 작성되고, 해당 버전은 대상이 받는 트래픽 비율에 따라 즉시 실제 트래픽을 처리합니다. 대상이 main이고 트래픽 분할이 설정되지 않았다면 모든 호출자가 해당됩니다.
병합하면 다음도 수행됩니다.
- 소스 브랜치가 받던 실제 트래픽 비율을 대상으로 이동합니다.
- 기본적으로 소스 브랜치를 보관 처리합니다.
- 같은 브랜치에서 열린 다른 모든 제안을 닫습니다.
- 연결된 분류 티켓이 있다면 해결 처리합니다.
점진적 롤아웃
제안이 병합되기 전에 실제 호출자가 변경 사항을 사용하도록 실제 트래픽의 일부를 해당 브랜치로 보낼 수 있습니다.
트래픽 비율의 합계는 항상 100%여야 하며, 라우팅은 대화별로 결정론적입니다. 보호된 main에서 트래픽을 가져오는 것을 포함해 보호된 브랜치의 비율을 변경하려면 관리자가 필요합니다. 트래픽 배포를 참조하세요.
사전 대응형 제안
Architect는 요청하거나 실패한 테스트, Spotlight 분석 결과, 알림 또는 분류 티켓을 전달받으면 제안을 만듭니다. 아직 일정에 따라 에이전트를 검사하거나 자체적으로 제안을 열지는 않습니다.
현재 사전 대응 경로는 Spotlight와 후속 전달입니다. Spotlight는 에이전트의 대화를 지속적으로 모니터링합니다. 권장 조사 사항이 포함된 주간 요약을 생성하고, 실시간 알림을 발생시키며, 구성 변경을 추천합니다. Spotlight 분석 결과를 제안으로 전환하려면 다음 단계를 따르세요.
분류 티켓도 같은 방식으로 작동합니다. 실제 에이전트는 대화 중 검토할 문제를 표시할 수 있으며, 티켓에서 Architect와 논의를 선택하면 해당 티켓에 대한 조사가 시작됩니다.
Architect 받은편지함으로 보고서를 전달하는 예약 자동화 기능은 개발 중입니다. Architect 페이지의 받은편지함 탭은 이를 위한 자리 표시자입니다.