스케줄러 수정 작업을 넘길 때 다음 기록이 남을 수 있다.
목표: 새 작업 수신을 일시 정지하고 실행 중인 데이터 가져오기는 끝까지 완료한다.
산출물: 핵심 패치는 저장됐고 명령줄 진입점은 아직 연결되지 않았다.
충돌: 현재 패치는 실행 중인 작업을 취소하며 테스트도 이 옛 동작을 검증한다.
다음 행동: 일시 정지의 의미를 고친 뒤 연결을 계속한다.
실행자: 현재 없음.
실행 중인 Agent가 없어도 일의 상태는 명확하다. 인수자는 이전 대화를 다 읽기 전에도 가장 중요한 결함을 발견할 수 있다. 핵심 코드가 현재 목표와 맞지 않아 바로 연결하면 잘못된 동작이 사용자에게 전달된다.
이는 교육용 기록이다. 공개 커밋 c9d6abe의 Flowness가 제안한 Work 설계를 보여 준다. 그 버전은 완전한 Agent 간 연속 경로를 여전히 설계 상태로 분류하므로, 본문은 예를 완료된 실행으로 취급하지 않는다.설계와 증거 상태
주소에서 근거로 돌아갈 수 있어야 한다
Work는 지속되는 일에 안정적인 조회 입구를 준다. 하지만 번호는 일을 찾도록 도울 뿐, 열었을 때 현재 사실이 보인다고 보장하지 않는다.
Flowness는 Work를 하위 기록의 투영으로 설계한다. 코드는 저장소에 있고 테스트 결과는 해당 버전을 가리키며 판단과 변경은 이벤트 기록에 남는다. 작업 뷰가 이 사실을 모은다. 핵심 패치의 버전이 바뀌면 단순히 초록색 “통과”를 보여 주는 대신 테스트가 어느 버전을 확인했는지 알려야 한다.
뷰에는 시간상의 위치도 있다. as_of_seq는 어느 이벤트까지 집계했는지를 나타낸다. 현재 뷰가 이벤트 147에 머물고 책임자가 148에서 일시 정지 요구를 바꿨다면, 시스템은 이 뷰가 새 결정을 포함하지 않았다는 것을 식별할 근거가 있다.WorkView 설계
이 입구는 인계 요약보다 후속 행동을 더 믿을 만하게 도울 수 있다. 요약은 당시 어떻게 생각했는지 설명한다. 현재 뷰는 그 해석 중 무엇이 나중에 바뀌었는지도 알아야 한다.
실행자가 중단되면 먼저 남긴 상태를 대조한다. 이전 실행은 정말 멈췄는지, 패치는 커밋됐는지, 어떤 파일이 임시 작업 공간에 있는지, 어떤 결과를 검사했는지 확인한다. 복구는 실제 상태가 결정한다. 이전 Agent의 “거의 끝났다”는 추정을 그대로 쓸 수 없다.
다음 행동에 필요한 맥락을 준비한다. Flowness는 이를 Context Capsule이라 부른다. 명확한 사실 시점에서 현재 목표, 관련 버전, 유효 제약, 산출물, 미해결 문제를 골라 넣는다. 스케줄러 예에서는 먼저 일시 정지 의미의 충돌을 해결해야 한다. 이때 전체 채팅 기록을 주면 다음 결정을 좌우하는 몇 자료가 묻힐 수도 있다.실행 상태 대조와 맥락 구성
새 Agent는 자기 실행을 시작해 같은 Work를 진전시킨다. 결과를 검사하면 다음 조회의 근거가 된다.
전제가 바뀌면 완료 기록도 다시 해석해야 한다
일시 정지를 처음에는 “모든 작업 중지”로 이해했을 수 있다. 뒤에 책임자가 실행 중인 가져오기는 완료해야 한다고 확인했다. 이 변화는 작업 설명에만 영향을 주지 않는다.
옛 테스트는 통과했어도 작업 취소를 검증했다. 핵심 코드, 테스트 단언, 명령줄 도움말은 같은 옛 전제에 의존할 수 있다. 일시 정지와 무관한 로그 형식까지 다시 만들 필요는 없을 수 있다.
이 판단에는 두 의존 관계가 필요하다. 작업이 실행 순서에서 어떻게 이어지는지, 산출물이 어느 버전의 해석 위에 서 있는지다. 전자만 있으면 연결이 테스트 뒤라는 것을 안다. 후자까지 있어야 테스트가 의존한 요구가 낡았음을 발견한다.
Flowness는 후속 작업을 바꾸는 관찰을 Finding이라 하고, Reflow가 영향을 받는 전제와 의존성을 찾아 다음 일을 조직하게 한다. 여기서는 “핵심 구현이 실행 중인 가져오기를 취소해 현재 요구와 충돌한다”라고 직접 적을 수 있다. 이후 계획은 핵심 동작으로 돌아가 진행 중 작업이 끝나는지 확인한 뒤 명령 진입점을 연결한다.Finding과 Reflow의 설계 관계
기존 산출물은 남는다. 바뀌는 것은 그것이 계속 뒷받침할 수 있는 판단이다. 옛 테스트 결과는 역사를 설명하지만 새 요구를 충족했다는 결론을 계속 지지할 수는 없다.
부분 재작업이 수고를 줄일지는 의존 기록의 정확성에 달려 있다. 빠진 관계는 조사해야 하고 영향 범위가 불명확하면 세밀한 분류보다 검증 범위를 넓히는 편이 더 쌀 수 있다. 따라서 이 설계는 실제 수정 과제에서 인수자의 잘못된 경로를 얼마나 줄이고 기록 비용을 얼마나 늘리는지 검증해야 한다.
실행 영속화 자체에는 성숙한 도구가 있다. Temporal은 이벤트 이력으로 워크플로 상태를 복구하고 Signal, Update 같은 새 입력을 받을 수 있다. LangGraph는 체크포인트와 영속 저장소로 그래프 상태와 스레드 간 데이터를 저장한다.Temporal 워크플로, 메시지 전달, LangGraph 영속화
Work 모델이 관심을 두는 것은 저장된 상태의 해석이다. 목표 버전, 대체된 판단, 영향을 받는 산출물, 인수자가 지금 얻어야 할 자료를 다룬다. 이 규칙은 기존 실행 엔진 위에 만들 수 있다. 작업표, 저장소, 워크플로가 관계를 완전하게 저장한다면 별도 병렬 데이터베이스는 동기화 부담만 늘린다.
“완료” 뒤에도 주소는 유용하다
핵심 로직을 고쳤다고 후속 일이 모두 사라지는 것은 아니다. Flowness는 서로 다른 이어가기 행동에 대응하는 네 상태를 구별한다.
| 상태 | 스케줄러 예에서의 의미 |
|---|---|
| 제작됨(built) | 검사할 수 있는 일시 정지 기능 산출물이 있다. |
| 통합됨(integrated) | 명령 진입점과 실제 호출 경로가 연결됐다. |
| 실제 사용됨(activated) | 대상 환경의 자연스러운 사용이 이 기능을 실제 호출했다. |
| 수락됨(accepted) | 검수 책임자가 필요를 충족한다고 확인했다. |
실제 사용의 정의는 테스트, 데모, 연습, 단순 배포 완료를 제외한다. 책임자의 수락도 명확한 대상이 있어야 하며 어느 버전의 결과를 받아들였는지 가리킬 수 있어야 한다.실제 사용과 수락의 정의
그러면 기다림이 구체적이 된다. 기능을 연결했지만 실제 일시 정지 수요가 아직 없을 수도 있고, 실제로 썼지만 책임자가 아직 검수하지 않았을 수도 있다. Agent를 계속 실행할 필요 없이 기다리는 이벤트, 책임자, 재확인 조건만 남기면 된다.
조건이 맞으면 같은 Work를 다시 열고 현재 버전을 대조해 다음 행동을 시작한다. 공개 인계 데모 명세도 이 경로를 시험하려고 준비되어 있다. 실행자 중단 뒤 새 실행자가 이전 Agent의 임시 기억 없이 영속 상태로 이어 갈 수 있는지 본다.인계 데모 명세
유지 담당자에게 그 주소가 결국 답해야 할 것은 실용적인 한 가지다. 오늘 다시 스케줄러를 손본다면 어디서 시작해야 하는가. 계속 답할 수 있어야 일이 대화 종료, 담당자 교체, 요구 변경을 넘어갈 수 있다.