기계가 읽을 수 있는 실패

개요

AI에게 실패는 텍스트가 아니라 입력이다. 그래서 failure format이 애매하면, AI는 실패를 이해하기보다 주변 코드에서 다른 우회를 추측한다.

좋은 AI 작업자 하네스는 failure를 machine-readable하게 만든다.

이 문서는 harness/ai 적용 레이어에서 failure를 어떻게 수정 가능한 입력으로 바꿀지 본다.

왜 형식이 중요한가

사람은 약간 모호한 에러도 문맥과 경험으로 보완할 수 있다. 하지만 AI는 가장 가까운 문자열과 패턴에 강하게 반응한다.

• rule id가 없으면 같은 실패를 묶기 어렵고
• 위치가 흐리면 수정 범위가 넓어지며
• 대안이 없으면 주변 shortcut을 추측한다

그래서 failure format은 설명 문장보다 구조가 중요하다.

좋은 failure format의 최소 요소

• stable rule identifier
• file / line / symbol 같은 위치 정보
• 관측된 위반 경로 또는 값
• 허용되는 canonical path
• 가능한 경우 실행해야 할 다음 check

이 다섯 가지가 있으면 AI는 실패를 보고 다음 행동을 비교적 좁은 범위로 수렴시킬 수 있다.

형식은 일관되어야 한다

같은 종류의 failure가 도구마다 다른 말로 나오면 안 된다.

• lint는 한 이름
• runtime은 다른 이름
• pre-commit은 또 다른 설명

이렇게 흩어지면 사람도 헷갈리고, AI는 더더욱 같은 규칙으로 연결하지 못한다.

가능하면 같은 rule id와 같은 canonical path를 공유하는 편이 좋다.

나쁜 failure format 패턴

• not allowed처럼 이유가 너무 짧다
• 위치가 없어서 어디를 고쳐야 할지 모른다
• 내부 구현 dump만 길고 대안이 없다
• 여러 위반을 한 문장에 뭉갠다
• failure마다 naming이 달라 searchability가 없다

이런 형식은 failure를 signal이 아니라 잡음으로 만든다.

pre-commit과 auto-correction에서 왜 중요해지는가

AI가 local gate를 통과하려면 실패가 곧바로 수정 입력으로 바뀌어야 한다.

• pre-commit에서 failure가 machine-readable하면 즉시 재시도 가능하다
• auto-correction loop에서 같은 failure를 정확히 재확인할 수 있다
• 반복 failure를 같은 rule bucket으로 묶어 개선 포인트를 읽을 수 있다

즉 failure format은 feedback loop와 correction loop를 이어주는 접점이다.

실무 질문

• rule id가 stable하게 남는가
• 위치 정보가 수정 범위를 좁혀주는가
• 허용되는 대안이 명시되는가
• 같은 규칙이 도구마다 같은 이름으로 보이는가
• AI가 이 failure를 보고 broad refactor가 아니라 local fix로 수렴할 수 있는가

요약

좋은 machine-readable failure는 다음을 만족한다.

• 규칙 이름이 안정적이고
• 위치가 정확하며
• 대안이 명시되고
• 도구 전반에 걸쳐 일관된다

하네스의 AI 적용에서 failure format은 부가 정보가 아니라, loop를 제대로 닫기 위한 핵심 인터페이스다.