Orchestro

Orchestro는 비즈니스 기능을 그것을 뒷받침하는 사용자 여정, 화면, 에이전트, 서비스, 데이터 파이프라인에 연결한다. 저장소 이력은 이전에 무슨 일이 있었는지 재구성하는 데 도움을 준다. 연결된 런타임 증거는 지금 무슨 일이 일어나는지 보여준다. 코드가 저장소에 있다고 해서 배포됐거나 쓰인다는 뜻은 아니며, 빠진 증거는 안심시키는 초록불로 바뀌지 않고 보이는 상태로 남는다.

실패한 가입은 사용자 피드백, 서버 오류, 이슈 트래커에 동시에 나타날 수 있다. Orchestro는 그것들을 하나의 문제에 대한 증거로 취급한다. 그래서 팀이 하나의 원인에 세 에이전트를 보내지 않는다. 각 이슈는 수리를 거듭해도 정체성을 유지한다. 이 점은 버그가 다시 돌아올 때 가장 중요하다.

플랫폼은 사용자가 설정한 권한 안에서 범위가 정해진 작업을 코딩 에이전트에 넘긴다. 작업은 한 번의 세션이 아니라 여러 날에 걸쳐 진행된다. 왜 중요할까. 대부분의 실제 수정은 단일 프롬프트가 아니기 때문이다. 이 점이 코딩 에이전트 워크플로의 체감을 바꾼다. 공급자 연동은 같은 이슈, 이력, 검사를 에이전트에 넘기므로, 두 번째 수정은 첫 에이전트의 증거를 첨부한 채 시작한다.

Advisor V1은 알려진 작업과 가용한 증거에 근거해 다음 단계를 제안한다. 권고는 승인과 분리돼 있다. 제안을 받아들이는 것과 실행을 시작하는 것은 별개의 단계이며, 프로젝트의 권한 설정이 무슨 일이 일어날 수 있는지를 계속 통제한다. 결정은 오래 남도록 기록된다. 그리하여 판단의 근거가 인사 이동을 넘어 살아남는다.

Orchestro는 병합된 풀 리퀘스트, 배포된 릴리스, 동작 검사, 제품 측정을 네 가지 별개로 유지한다. 각각이 작업이 도착했는지에 대해 서로 다른 질문에 답하기 때문이다. 동작 검사는 수정이 작동하는지 보여준다. 제품 측정은 그것이 유용했는지 판단하는 데 도움을 준다. 바로 이 구분이 핵심이다. 같은 버그가 새 코드 경로를 통해 다시 나타날 수 있고, 성공한 빌드로는 그것을 잡지 못한다.

각 기능에는 주 지표 하나와 최대 두 개의 보조 측정이 붙는다. 각각 정의, 모집단, 시간 창이 필요하다. 최신 데이터도 필요하다. 가드레일은 다른 결과를 보호한다. 그리고 '아직 이것을 측정할 수 없다'는 실패가 아니라 유효한 답으로 인정된다.