한 줄 요약
AI와 함께 workflow를 만들 때 가장 어려운 일은 기능을 추가하는 일이 아니라, 무엇을 완료라고 부를 수 있는지 정직하게 정하는 일이었습니다.
출발점: 다 만들어졌는데도 남는 불안
Research Navigator에는 이미 많은 것이 있었습니다. 큰 일을 여러 leaf skill로 나눈 구조, 단계마다 입력과 산출물을 연결하는 Interface Card, 파일 변경을 감지하는 Proof, 사람이 승인한 범위를 남기는 Gate, 마지막 정상 상태를 확인하는 Snapshot, 문제를 책임 owner에게 보내는 finding, 그리고 이를 요약하는 dashboard까지요.
코드를 보면 “검증 가능한 workflow”처럼 보였습니다. 테스트도 있었습니다.
그런데 이 모든 것이 한 가지를 증명해 주지는 못했습니다.
여러 장치가 실제 실행 한 번 안에서 차례대로 작동했는가?
기능이 존재한다는 것과 기능들이 함께 작동했다는 것은 다른 주장입니다. 전자는 구현의 사실이고, 후자는 실행의 사실입니다.
legacy 기록을 새 기준에 맞춰 고치지 않은 이유
이미 완료된 연구기획 run 하나는 상태상 정상적으로 닫혀 있었습니다. 모든 stage가 done이었고 validator error도 없었습니다. 하지만 이 기록은 strict Artifact Contract와 Proof·Snapshot이 들어오기 전에 만들어진 legacy run이었습니다.
여기서 쉬운 선택은 과거 기록에 새 형식의 artifact를 덧붙이는 것입니다. 그러면 화면에는 완성된 strict run처럼 보일 수 있습니다.
하지만 그 방식은 과거 실행을 증명하는 것이 아니라, 과거 기록을 지금의 기준으로 다시 꾸미는 일입니다. 그래서 legacy run은 그대로 보존했습니다.
“완료”를 테스트 항목으로 바꾸다
완료를 감상이나 체크리스트가 아니라, 확인 가능한 회로로 정의했습니다.
정상 artifact
→ 승인 범위 기록
→ proof 생성·검증
→ snapshot 생성
→ 의도적 변경
→ stale 실패 증거
→ 가장 작은 책임 단계 식별
→ 그 단계만 수리
→ 같은 기준으로 재검증
이 정의에는 중요한 장점이 있습니다.
실패가 나도 전체 작업을 무효로 만들지 않습니다.
어떤 단계가 문제인지 말할 수 있어야 합니다.
수리 후에는 처음보다 느슨한 기준이 아니라 같은 기준으로 다시 확인합니다.
evidence가 없으면 “통과” 대신 다음 입력이나 승인을 기다리는 상태로 남깁니다.
사람과 AI의 역할을 나눈 방식
AI는 strict lifecycle을 검증할 synthetic harness와 테스트를 구성했습니다. 하지만 “기존 연구 run을 고칠 것인가”, “실제 자료를 쓸 것인가”, “어디까지를 완료로 주장할 것인가”는 사람이 정한 경계였습니다.
이 분담이 중요했습니다. AI가 작업을 빠르게 연결할 수는 있어도, 과장하지 않을 기준까지 자 동으로 정할 수는 없기 때문입니다.
이 날 남긴 결론
좋은 workflow는 실패하지 않는 workflow가 아닙니다. 실패가 났을 때 다음 질문에 답할 수 있는 workflow입니다.
무엇이 바뀌었는가?
어느 approval과 proof가 더는 유효하지 않은가?
누가 고쳐야 하는가?
정상인 부분을 건드리지 않고 어떻게 다시 확인할 것인가?
이 질문을 문서와 테스트 계약으로 고정해 두면, 다음 실행에서야 비로소 구현이 실제로 작동하는지 확인할 수 있습니다.
재사용할 수 있는 질문
이 자동화의 코드·문서·unit test와 실제 실행 증거를 분리해서 점검해줘.
기존 legacy 산출물은 소급 수정하지 말고, 별도 synthetic input으로 정상 경로와 failure/repair 경로를 검증할 최소 회로를 설계해줘.
완료·부분 완료·보류를 주장별 증거와 함께 구분해줘.
