추적과 관찰성
개요
하네스가 있어도 무엇이 반복 실패하는지 보이지 않으면 개선이 어렵다.
AI 작업에서는 특히 그렇다. 실패와 retry가 빠르게 반복되기 때문에, 관찰성이 없으면 같은 우회와 같은 stop reason이 계속 재생산된다.
이 문서는 trace and observability를 다룬다.
harness/ai 적용 레이어에서 반복 실패를 관찰 가능한 운영 신호로 남기는 방법을 다룬다.
왜 observability가 필요한가
좋은 loop도 측정되지 않으면 유지되지 않는다. 보통 다음 질문에 답할 수 있어야 한다.
- 어떤 rule violation이 가장 자주 반복되는가
- 어디서 retry budget이 자주 소진되는가
- 어떤 gate가 너무 늦거나 너무 크게 작동하는가
- 어떤 stop reason이 사람 개입을 가장 자주 부르는가
이 질문에 답하지 못하면, 실패는 개별 사건으로만 보이고 구조 개선으로 이어지지 않는다.
무엇을 남겨야 하는가
최소한 다음 정도는 남기는 편이 좋다.
- task id 또는 작업 단위 식별자
- rule id / failure code
- 실패 위치나 관련 표면
- 어떤 gate에서 실패했는가
- retry 횟수와 stop reason
- 사람 개입 여부
핵심은 모든 로그를 남기는 것이 아니라, 반복 패턴을 묶을 수 있는 축을 남기는 것이다.
trace는 loop를 설명해야 한다
AI 관찰성에서 중요한 것은 단순 실행 로그보다
루프가 어떻게 흘렀는가다.
예를 들면 다음을 보고 싶다.
- 어떤 변경 후 어떤 gate를 돌렸는가
- 어떤 failure를 받고 어떤 범위만 수정했는가
- 몇 번 재시도 후 멈췄는가
- 마지막 stop reason은 무엇이었는가
이 정도가 보이면 좋은 auto-correction loop인지 아닌지를 비교적 명확하게 판단할 수 있다.
어떤 지표가 유용한가
- rule bucket별 반복 실패 빈도
- task type별 retry budget 소진율
- pre-commit / local gate fail rate
- 사람 개입으로 escalated 되는 비율
- broad refactor로 번지는 실패 유형
- canonical path 안내 후 수렴 성공률
이런 지표는 단순 통계가 아니라, 어디의 하네스가 약한지 보여주는 신호다.
나쁜 observability 패턴
- 에러 텍스트만 남고 rule id가 없다
- retry는 보이는데 stop reason은 없다
- gate는 보이는데 어떤 task contract 아래서 발생했는지 모른다
- 로그는 많지만 rule bucket으로 묶을 수 없다
- broad refactor와 local fix를 구분하지 못한다
이런 상태에서는 많은 데이터를 가져도 개선 포인트는 흐려진다.
feedback loop closure와의 관계
feedback-design이 실패 메시지를 어떻게 설계할지를 다뤘다면,
이 문서는 그 실패가 운영 중에 어떻게 관찰되고 다시 구조 개선으로 돌아오는지를 다룬다.
즉 좋은 observability는 다음을 가능하게 한다.
- 같은 failure를 같은 bucket으로 묶기
- 약한 gate를 앞당기기
- vague한 failure format을 개선하기
- retry budget 정책을 조정하기
- 사람 개입이 필요한 지점을 더 빨리 발견하기
AI 코딩에서 왜 더 중요해지는가
AI는 문제를 더 빨리 드러내지만, 그만큼 노이즈도 더 빨리 만든다.
관찰성이 없으면 반복 실패가 그냥 소음처럼 느껴진다. 하지만 trace가 있으면 그 반복은 control gap을 드러내는 고품질 신호가 된다.
즉 AI는 observability를 더 귀찮게 만드는 존재가 아니라, 오히려 observability의 가치가 더 커지는 환경이다.
실무 질문
- 같은 failure를 stable rule bucket으로 묶을 수 있는가
- retry budget 소진과 stop reason을 볼 수 있는가
- 어떤 gate가 가장 자주 실패를 일으키는지 보이는가
- 사람 개입이 필요한 패턴을 따로 식별할 수 있는가
- 이 관찰 결과가 rule, gate, failure format 개선으로 실제 연결되는가
요약
좋은 AI observability는 다음을 만족한다.
- failure와 retry를 같은 패턴으로 묶을 수 있고
- gate, stop reason, escalation을 함께 볼 수 있으며
- 결과가 loop와 rule 개선으로 환류된다
하네스의 AI 적용에서 trace는 사후 기록이 아니라, 반복 실패를 구조 개선 신호로 바꾸는 측정 층이다.