처음에는 문제가 보이는 곳을 고쳤다.
Script 결과가 잘못되면 Script를 수정했다.
AI가 업무를 잘못 이해하면 Knowledge를 보강했다.
Document가 부족하면 생성 방식을 바꿨다.
Agent가 예상과 다르게 움직이면 Prompt나 Agent 동작을 수정했다.
Problem 발생 → 문제가 보이는 Component 수정 → 다시 실행
당시에는 당연하고 합리적인 방식이었다.
그리고 대부분 수정 직후에는 정상처럼 보였다.
그런데 시간이 지나면서 이상한 감각이 쌓였다.
“이거 전에 비슷한 문제를 고치지 않았나?”
완전히 같은 Error가 반복된 것은 아니었다.
파일도 달랐고, 업무도 달랐고, 실행 조건도 달랐다.
하지만 성격은 비슷했다.
이전 Context를 다시 찾지 못한다.
새로운 Knowledge와 기존 Script의 가정이 어긋난다.
앞 Step의 Output과 다음 Step이 기대하는 Input이 다르다.
변경된 State를 다른 Component가 모른다.
Agent가 생각한 “완료”와 사람이 기대한 “완료”가 다르다.
형태는 달라도 반복되는 흐름은 비슷했다.
Problem 발생 → 수정 → 일단 해결 → Condition이나 Context 변화 → 비슷한 문제 재발 → 다시 수정하는 반복 패턴(이후 Recurring Fix Loop로 표현)이 계속 보이기 시작했다.
핵심은 각 Component를 개별적으로 고치는 것만으로 전체 문제가 닫히지 않는다는 점이었다.
각 Component가 개별적으로 맞는 것과 Workflow 전체가 일관된 것은 같은 일이 아니었다.
Script 자체는 정상일 수 있다.
Knowledge 내용도 맞을 수 있다.
Agent도 지시받은 Task를 수행했을 수 있다.
Document도 실제 Result를 기록했을 수 있다.
그런데 Knowledge가 기대하는 Input과 Script가 만드는 Output이 다르거나, Agent가 이해한 Current State와 실제 Project State가 다르거나, 앞 Step이 생각한 Completion과 다음 Step이 기대하는 Completion이 다르면 전체 Workflow는 틀어질 수 있었다.
여기서 관심이 “Context를 남겨야 한다”에서 “Component들이 같은 상태와 전제를 공유해야 한다”로 조금씩 이동했다.
문제 뒤에는 사람이 서로 당연하다고 생각한 전제가 숨어 있었다.
“당연히 이 위치에 파일이 있겠지.” “앞 Step이 끝났다면 이 Output이 있겠지.” “이 값이면 성공이라고 봐도 되겠지.” “이 Schema는 다음에도 같겠지.”
Component와 Interface가 많지 않고 한 사람이 전체 흐름을 충분히 이해할 수 있을 때에는 이런 전제의 상당 부분을 사람이 문맥으로 메울 수 있다.
SoC처럼 연결되는 Component와 Step, State와 Condition이 많아질수록 그 ‘당연함’을 개인의 기억과 경험에 맡기는 방식은 점점 불안정해진다.
AI가 들어오면서 새로 생긴 문제라기보다, 사람이 암묵적으로 메우던 연결 조건을 System이 명시적으로 다뤄야 한다는 문제가 더 선명해진 셈이다.
사람은 문맥으로 이런 빈틈을 메운다.
하지만 Script와 Agent 사이에서는 그 ‘당연함’이 자동으로 공유되지 않는다.
사람이 문맥으로 메우던 조건을 명시적인 규칙으로 바꿔야 했다
여기서 Contract는 S/W/System Engineering에서 사용하는 의미다.
앞뒤 Step이나 Component 사이에서 어떤 Input과 Output을 주고받는지, 어떤 State를 전제로 하는지, 어떤 조건을 만족해야 다음 단계로 갈 수 있는지를 명시한 규칙(이후 Contract로 표현)이 필요했다.
실제 실행에서는 그 조건이 지켜졌는지도 확인할 수 있어야 한다.
Input Format과 Schema, 필수 Output, Success Condition, 앞 Step의 State, 다음 Step으로 진행하기 위한 조건.
서로 당연하다고 생각하던 전제를 명확히 정해 둔 Contract로 바꾸는 것이다.
Prompt를 계속 더 정교하게 만드는 것도 필요할 수 있다.
하지만 Prompt가 좋아져도 Script Version, Knowledge, Current State, 앞뒤 Step의 Contract가 서로 어긋나면 Workflow 전체 문제는 남는다.
그래서 질문 자체가 바뀌기 시작했다.
“이 Script를 어떻게 고칠까?” “이 Prompt를 어떻게 바꿀까?”
에서
“이 Component들이 서로 어떤 조건과 상태 안에서 함께 움직이게 해야 할까?”
로.
필요했던 것은 Agent보다 바깥에서 어떤 Input을 사용할지, 어떤 Knowledge가 현재 유효한지, Current State가 무엇인지, 앞 Step의 결과가 다음 Step의 조건을 만족하는지, 언제 멈춰야 하는지, 무엇을 완료라고 볼지를 잡아주는 구조였다.
Workflow 전체를 관리할 구조가 필요했다
다만 지금의 AWARE AI Architecture를 당시부터 알고 있었다고 소급해서 말하고 싶지는 않다.
당시에는 이런 바깥의 관리 구조(이후 Harness로 표현)가 필요하다고 생각했다.
그때의 이해는 단순했다.
“Agent와 Script를 각각 계속 고치지 말고, 이들이 어떤 조건과 상태 안에서 함께 움직일지를 바깥에서 관리해야 하지 않을까?”
이 정도였다.
돌아보면 이때부터 관심의 중심이 조금씩 바뀌었다.
AI가 이 일을 할 수 있는가라는 Capability의 질문에서, AI가 어떤 조건과 경계 안에서 이 일을 하게 할 것인가라는 통제와 일관성의 질문으로.
다음 편 — Model과 Agent가 계속 바뀐다면, 그동안의 시행착오와 Learning까지 다시 만들어야 할까?