AI 자동화 완료 조건만으론 왜 부족할까요?
완료 조건이라는 개념은 어디까지나 실행이 시작된 뒤에 의미가 있는 장치입니다. 조건을 못 넘긴 실행보다 조건 앞까지 오지도 못한 실행이 더 많을 수 있다는 뜻인데요, 완료 조건 하나로 자동화 전체의 신뢰성을 담보할 수는 없습니다. 여기서 챙길 것은 대책보다 관점 쪽인데요 AI 자동화의 신뢰성은 코드 품질과 실행 자원 확보라는 두 축으로 나뉘어 있고 이 둘은 서로를 대신해주지 않는다는 것입니다. 코드를 완벽하게 만들어도 자원을 못 잡으면 실행이 안 되고 자원이 넉넉해도 코드가 자기를 끄면 역시 안 됩니다. GeekNews에 올라온 실전 루프 엔지니어링 요약에서는 자율성보다 완료 조건과 제약을 명확히 정의하는 것이 핵심이라고 정리하면서 작업하는 쪽과 검증하는 쪽을 나누라고 권합니다. 여기에 한 층이 더 필요해 보입니다. 완료 조건과 검증을 나눠놓아도 실행이 시작됐는지 자체를 확인하는 층이 없으면 흔적 없는 실패가 그대로 성공처럼 보이게 됩니다.검사기가 알려주는 것은 왜 증상뿐일까요?
검사기는 무엇이 틀렸는지는 알려주지만 어느 계층에서 틀렸는지는 알려주지 않습니다. 검사 스코프와 결함 스코프가 어긋나 있으면 통과든 실패든 그 판정이 보장하는 범위는 생각보다 훨씬 좁습니다.같은 축의 이야기를 Graph 엔지니어링과 Loop 엔지니어링을 비교한 글에서도 읽었습니다. 여러 판정이 서로 합의한다고 해서 신뢰성이 올라가지는 않고 외부의 실제 증거가 필요하다는 대목입니다. 같은 알림이 며칠 내내 같은 말을 반복해도, 어느 계층인지를 밝혀 줄 외부 증거가 없으면 판정끼리 합의만 하는 셈입니다.
검사기 규칙에도 회귀 테스트가 필요한 이유
검사기 규칙이 늘어날수록 검사기 자체에도 테스트가 필요한데요 막아야 할 나쁜 사례뿐 아니라 통과해야 하는 정상 사례까지 함께 고정하는 것이 핵심이었습니다. 나쁜 사례만 모아두면 규칙을 세게 조일 때 정상 원고까지 막히는 쪽은 계속 열려 있게 됩니다. 정리해 보면 필요한 것은 자동화가 아니라 자동화를 감시하는 층입니다. 완료 조건은 그 층의 첫 칸일 뿐이고 실행이 시작됐는지, 실패가 기록으로 남는지, 판정을 내리는 장치 자체가 아직 멀쩡한지까지 세 칸이 더 필요합니다. 위에서 인용한 요약글에서도 작업은 위임해도 판단까지 위임하지는 말라고 적어두었습니다.정리
- 완료 조건은 실행이 시작된 뒤에만 의미가 있습니다. 실행이 시작됐는지부터 확인하는 층이 따로 필요합니다.
- AI 자동화의 신뢰성은 코드 품질과 실행 자원 확보라는 두 축으로 나뉘고, 한쪽이 다른 쪽을 대신하지 않습니다.
- 검사기는 무엇이 틀렸는지는 알려 주지만 어느 계층인지는 알려 주지 않습니다.
- 완료 조건 문장 다음 줄에 무엇을 실패로 셀 것인지와 검사기 자체를 무엇으로 검증할 것인지를 같이 적어 둡니다. 에이전트에게 일을 맡기는 방식을 정리해본 글을 쓸 때는 여기까지 생각이 닿지 못했는데요 위임의 난이도는 지시문보다 실패를 세는 쪽에 있었던 듯합니다.
함께 보면 좋은 글
새 글이 올라오면 Threads @wonizz.ai 에도 올립니다. 팔로우해 두면 피드에서 바로 볼 수 있습니다.