5편에서 Harness를 도입했고, 6편에서는 여러 Harness 사이의 mismatch와 반복되는 Control을 더 바깥에서 관리하기 위해 Meta Harness까지 생각하게 됐다.
7편에서는 그 구조에서 사용할 AI Environment가 실제 SoC 업무에 투입 가능한지 Tool Calling, Response Time, 동시 Request, Resource 사용까지 포함해 Qualification했다.
그렇다면 Qualified된 Model과 Runtime이 Harness 안에서 정해진 Workflow를 수행하고 Task를 끝냈다면, 그 Result도 Engineering Result로 믿어도 될까?
실제 PoC에서는 그렇지 않았다.
Harness가 있다는 것과 Harness가 충분한 Control을 가지고 있다는 것은 다른 문제였다.
Agentic Capability ≠ Engineering Reliability
Model과 Agent가 업무를 수행할 수 있다는 것과, 그 결과를 Engineering Result로 신뢰할 수 있다는 것은 같은 일이 아니었다.
PoC를 진행하면서 몇 가지 실패가 반복됐다.
앞 Step이 실제로 만든 Output 구조와 다음 Step이 기대하는 구조가 달라졌는데 Workflow가 그 차이를 모르고 계속 진행하는 경우가 있었다.
앞 Step이 만든 Output에서 필수 Field가 빠지거나 Field Name, Data Type, Version 구조가 달라져 다음 Step이 기대하는 구조와 맞지 않는 문제(이후 Schema Drift로 표현)가 있었다.
내게 중요한 것은 이름보다 구조가 달라졌는데도 다음 Step이 그대로 진행될 수 있다는 점이었다.
5편에서 Contract를 명시해야 한다고 느꼈다면, 여기서는 Contract가 존재하는 것만으로 충분하지 않다는 것을 배웠다.
Contract가 있어도 실제로 맞는지 확인해야 했다
필수 Field, Data Type, Version, Schema, Mandatory Output을 다음 Step 전에 실제로 확인하는 Validation이 필요했다.
Agent가 실제 Repository를 확인하지 않고 존재하지 않는 Directory나 잘못된 File Path를 추론하는 문제(이후 Path Hallucination으로 표현)도 있었다.
표준 용어를 새로 정의하려는 뜻은 아니다.
해결 방향은 “더 잘 추측하게 하자”가 아니었다.
Path 추측 → Repository에서 실제 파일과 경로 확인 → 존재하는 Path 선택
실제 Source가 추론보다 먼저 오도록 바꿨다.
새로운 Evidence 없이 다른 Path를 찾고 Command와 Option을 바꾸고 Tool을 다시 호출하면서 비슷한 Action을 계속 반복하는 상태(이후 Stuck Loop로 표현)도 발생했다.
이름보다 중요한 것은 새로운 Evidence 없이 같은 Action이 반복된다는 점이었다.
여기서 배운 것은 Goal만 주면 언제 포기해야 할지도 자동으로 명확해지는 것은 아니라는 점이었다.
성공 조건만큼 Stop Condition이 필요했다.
동일 Failure 반복, 새로운 Evidence 없는 반복 Action, 필수 Input 부재, Permission 밖의 Action 필요, Human Decision이 필요한 Ambiguity, Token·Time·Compute Budget 초과.
이런 경우에는 계속하지 않고 멈추거나, 상태를 복구하거나, 사람의 판단으로 넘겨야 한다.
Stuck Loop는 결과의 신뢰성 문제이면서 Agent가 사용할 수 있는 Resource의 한계를 어디까지 둘 것인지의 문제이기도 했다.
상용 Model을 사용하던 중 Stop Condition 없는 반복 실행으로 짧은 시간 안에 사용 가능한 Token Limit에 도달한 경험도 있었다.
반대로 On-Premise라고 Loop가 사라지는 것은 아니다.
Local 환경에서는 GPU 점유, 다른 사용자 Latency, Concurrent Capacity 감소, 불필요한 Compute 소비로 나타날 수 있다.
Commercial Model에서는 반복 실행이 Token과 비용 증가로 이어질 수 있었고, On-Premise에서는 한 Agent의 반복 실행이 GPU와 Compute를 계속 점유해 다른 Engineer가 사용할 Resource와 응답성을 떨어뜨릴 수 있었다.
환경이 달라도 반복 실행에 대한 Boundary는 필요했다.
Session이 바뀌면 이전 Action, Decision, Failure, Current State, Remaining Work를 사람이 다시 설명해야 하는 문제(이후 Session Context Loss로 표현)도 있었다.
Project State가 Chat Session 안에만 존재하면 안 된다는 것을 느꼈다.
필요한 상태는 Session이 바뀌어도 복원 가능해야 했다.
Error가 없고 PASS처럼 보이지만 필수 Check나 Verification Step이 실제로 수행되지 않은 상태(이후 Silent PASS로 표현)가 가장 위험하게 느껴졌다.
중요한 것은 PASS가 실제 검증 완료를 의미하는지 다시 확인하는 것이었다.
필수 Check가 실제로 실행되지 않았는데, 검증 Step이 Skip되었는데, 잘못된 조건에서 Success Condition을 만족한 것으로 처리했는데,
Agent는 “완료”라고 말할 수 있다.
No Error ≠ Verified Success
Error가 없다는 것과 필요한 검증을 통과했다는 것은 다르다.
이런 실패를 겪으면서 Reliability를 보는 방식이 바뀌었다.
AI가 항상 맞는가?
보다
틀렸을 때 발견할 수 있는가?
잘못된 상태가 다음 Step으로 전파되는 것을 막을 수 있는가?
언제 멈춰야 하는가?
어떻게 복구하거나 사람에게 넘길 것인가?
가 더 중요해졌다.
내 경험을 설명하는 흐름으로 정리하면
실패 발견 → 잘못된 상태의 전파 차단 → 중단 또는 복구 → 사람에게 판단 요청
에 가깝다.
5편에서 Harness는 Component 사이의 Input, Output, State, Contract를 관리하는 바깥 구조에 가까웠다.
실제 Failure를 겪으면서 이미 도입한 Harness의 Control 기준은 더 구체화됐다.
입출력과 진행 조건 확인 실제 Repository와 Source 기준으로 동작 Permission과 Resource 범위 제한 반복되거나 불명확한 상태에서 중단 Session과 State 복구 Error가 없어도 필요한 검증 미실행 탐지
이런 Control은 특정 한 업무에서만 필요한 것이 아니었다.
여러 Harness에서 반복될수록 6편에서 말한 공통 Control을 분리해 관리해야 할 이유도 더 분명해졌다.
AI가 틀리지 않게 만드는 장치가 아니라, 틀릴 수 있다는 전제에서도 Workflow가 무너지지 않게 만드는 Engineering System에 가까워졌다.
Prompt에 Rule을 계속 추가하는 것만으로는 부족했다.
Schema 문제에는 Schema를 확인하라고 쓰고, Path 문제에는 존재 여부를 확인하라고 쓰고, Loop에는 반복하지 말라고 쓰고, Silent PASS에는 반드시 검증하라고 쓸 수 있다.
하지만 업무와 State, Model이 달라져도 그 Control이 매번 실제로 적용됐는지는 별개의 문제다.
그래서 이런 통제를 Agent가 기억해서 지키거나 스스로 “했다”고 보고하는 것에만 맡길 수 없다는 결론으로 갔다.
다음 편 — Agent가 “완료했습니다”라고 말할 때, 사람은 무엇을 보고 실제 수행과 검증을 확인할 수 있을까?