안녕하세요? 정리하는 개발자 워니즈입니다.
개인 블로그를 사람 손 없이 돌려보려고 자동 실행 슬롯을 걸어두고 엿새 동안의 실행 기록을 세어봤더니, 예정된 17개 슬롯 가운데 끝까지 정상 종료된 것은 5개뿐이었습니다. 성공률 29%. 그런데 정작 실패의 대부분은 필자가 짠 자동화 코드 안쪽이 아니라 그 밖에서 나 있었습니다. 완료 조건을 문장으로 적어두면 그다음은 알아서 돌아갈 것이라고 여기고 있었는데 실제로는 완료 조건에 도달할 기회조차 못 얻은 슬롯이 훨씬 많았던 셈입니다.
앞으로 지킬 기준을 한 줄로 줄이면 이렇습니다. 완료 조건을 정하는 데서 멈추지 않고 무엇을 실패로 셀 것인지까지 같은 자리에 적어둡니다.
무엇을 쟀는가: AI 자동화 슬롯 17개의 실행 기록을 상태별로 하나씩 분류했습니다.
무엇이 예상과 달랐는가: 실패 12건 중 8건이 코드와 무관한 실행 환경 쪽이었고 기록조차 남지 않은 슬롯이 3건이었습니다.
그래서 무엇을 바꿨는가: 실패 분류를 먼저 정의하고 검사기 자체에도 회귀 테스트를 붙였습니다.
완료 조건만 적어두면 알아서 돌 거라고 여겼습니다
필자가 세워둔 장치는 정해진 시각에 스스로 깨어나서 글을 하나 내보내고 홍보와 점검까지 마친 다음 기록을 남기고 끝나는 구조였습니다. 각 단계마다 통과해야 할 조건을 미리 문장으로 적어두었기 때문에 이 정도면 사람이 안 봐도 굴러갈 것이라고 생각하고 있었습니다.
그런데 엿새가 지나고 실행 기록을 열어봤을 때 눈에 들어온 것은 조건을 못 넘긴 실행이 아니라 조건 앞까지 오지도 못한 실행이었습니다. 완료 조건이라는 개념은 어디까지나 실행이 시작된 뒤에 의미가 있는 장치입니다. 그런데 필자는 그 조건 하나로 자동화 전체의 신뢰성을 담보하려 하고 있었던 것 같습니다.
17개 슬롯 중 다섯 개만 끝까지 갔습니다
기록을 상태별로 세어보니 다음과 같이 갈렸습니다.
상태
슬롯 수
성격
정상 종료
5
완료 조건까지 도달
사용량 한도로 실패
8
실행 환경 문제, 코드 수정으로 못 고침
자기 자신을 정지시킨 버그
1
자동화 코드 문제
시작 기록만 있고 끝이 없음
1
원인 불명, 사후 추적 불가
시작 기록 자체가 없음
2
위 버그의 파급, 아무 흔적도 안 남음
이 표에서 필자가 제일 오래 들여다본 줄은 마지막 두 줄이었는데요 실패했다는 사실조차 기록으로 안 남은 슬롯이 3개였기 때문입니다. 자동화가 실패하면 로그에 실패가 찍힐 것이라는 전제 자체가 성립하지 않고 있었던 셈이고 그래서 필자는 며칠 동안 장치가 정상적으로 돌고 있다고 믿고 있었습니다. 자동화된 요청과 사람의 방문이 총량 안쪽에서 섞여 있던 사례를 정리해본 적이 있는데요 이번 것도 결국 같은 계열이었는데 합계만 보고 있으면 없는 것과 실패한 것이 구분되지 않습니다.
AI 자동화 실패는 왜 코드 밖에서 더 많이 났을까요?
실패 12건 중 8건이 사용량 한도 때문이었습니다. 필자가 대화형으로 작업을 하는 동안 같은 사용량을 무인 슬롯도 함께 쓰고 있었기 때문에 필자가 낮에 뭔가를 열심히 하면 저녁 슬롯이 조용히 죽는 구조였습니다. 자동화 코드에는 아무 잘못이 없었고 실제로 그 부분을 몇 번 손봤지만 성공률은 움직이지 않았습니다.
여기서 얻은 것은 대책보다 관점 쪽인데요 AI 자동화의 신뢰성은 코드 품질과 실행 자원 확보라는 두 축으로 나뉘어 있고 이 둘은 서로를 대신해주지 않는다는 것입니다. 코드를 완벽하게 만들어도 자원을 못 잡으면 실행이 안 되고 자원이 넉넉해도 코드가 자기를 끄면 역시 안 됩니다. 필자는 그동안 첫 번째 축만 관리하면서 두 번째 축을 상수처럼 다루고 있었습니다.
GeekNews에 올라온 실전 루프 엔지니어링 요약에서는 자율성보다 완료 조건과 제약을 명확히 정의하는 것이 핵심이라고 정리하면서 작업하는 쪽과 검증하는 쪽을 나누라고 권합니다. 필자의 실측을 여기에 겹쳐보면 한 층이 더 필요해 보입니다. 완료 조건과 검증을 나눠놓아도 실행이 시작됐는지 자체를 확인하는 층이 없으면 흔적 없는 실패가 그대로 성공처럼 보이게 됩니다.
검사기가 알려준 것은 증상뿐이었습니다
두 번째 교훈은 좀 뼈아팠는데요 필자는 발행 후 점검을 자동화해두었기 때문에 문제가 생기면 알림이 뜨도록 되어 있었고 실제로 알림은 정확하게 떴습니다. 사이트맵에 새 글이 안 들어가고 있다는 신호가 나흘 동안 매일 올라왔습니다.
문제는 그 신호를 받고 필자가 향한 곳이었는데요 사이트맵에 글이 빠졌던 사건을 정리한 글에서 필자는 원인을 SEO 플러그인 쪽으로 지목했고 그 계층에서만 며칠을 만졌습니다. 뒤늦게 확인된 진범은 전혀 다른 곳에 있었습니다. 캐시 플러그인이 사이트맵 XML을 일반 페이지처럼 통째로 캐시해두고 있었기 때문에 요청이 애초에 원래 담당 코드까지 도달하지 못하고 있었습니다.
검사기는 무엇이 틀렸는지는 알려주지만 어느 계층에서 틀렸는지는 알려주지 않습니다. 검사 스코프와 결함 스코프가 어긋나 있으면 통과든 실패든 그 판정이 보장하는 범위는 생각보다 훨씬 좁습니다.
같은 축의 이야기를 Graph 엔지니어링과 Loop 엔지니어링을 비교한 글에서도 읽었습니다. 여러 판정이 서로 합의한다고 해서 신뢰성이 올라가지는 않고 외부의 실제 증거가 필요하다는 대목이 필자 사례와 정확히 맞물렸습니다. 필자의 알림은 나흘 내내 같은 말을 반복하면서 서로 합의하고 있었지만 어느 계층인지를 밝혀줄 외부 증거는 하나도 만들어내지 못했습니다.
규칙이 열일곱 개인데 회귀 테스트가 0건이면 어떻게 될까요?
세 번째는 검사기 자체의 문제였는데요 필자의 발행 검사기는 사고가 날 때마다 규칙을 하나씩 붙이는 방식으로 자라나서 어느새 열일곱 개가 되어 있었습니다. 그런데 이 규칙들을 고정해두는 회귀 테스트가 한 건도 없었습니다.
문제가 드러난 순간은 규칙 하나를 되돌릴 때였습니다. 되돌린 규칙 때문에 다른 규칙이 정상 제목까지 전부 걸러내기 시작했고 그것을 손으로 몇 번 넣어보다가 겨우 알아챘습니다. 검사기가 늘어날수록 규칙끼리 간섭할 여지도 같이 늘어나는데 정작 그 간섭을 잡아줄 장치는 없었던 셈입니다. 검사기를 믿었을 때 생기는 함정들을 따로 정리해둔 글이 있는데 이번 건은 그 목록에 하나를 더 보태는 사례였던 것 같습니다.
그래서 검사기에도 테스트를 붙였는데요 막아야 할 나쁜 사례뿐 아니라 통과해야 하는 정상 사례까지 함께 고정하는 것이 핵심이었습니다. 나쁜 사례만 모아두면 규칙을 세게 조일 때 정상 원고까지 막히는 쪽은 계속 열려 있게 됩니다.
이렇게 정리해보니 필자가 엿새 동안 실제로 만들고 있던 것은 자동화가 아니라 자동화를 감시하는 층이었던 셈입니다. 완료 조건은 그 층의 첫 칸일 뿐이고 실행이 시작됐는지, 실패가 기록으로 남는지, 판정을 내리는 장치 자체가 아직 멀쩡한지까지 세 칸이 더 필요했습니다. 앞의 세 가지 교훈이 서로 다른 사고처럼 보였지만 결국 같은 자리를 가리키고 있었는데 판단을 자동화에 넘겨준 만큼 그 판단이 여전히 작동하는지를 확인하는 몫이 필자 쪽으로 넘어와 있었습니다. 위에서 인용한 요약글에서도 작업은 위임해도 판단까지 위임하지는 말라고 적어두었습니다. 필자는 그 문장을 읽고서도 판단하는 장치를 만들어둔 것으로 판단을 지킨 셈이라고 넘기고 있었습니다.
정리
AI 자동화 슬롯 17개 중 정상 종료는 5개로 성공률 29%였고 나머지는 완료 조건에 닿지도 못했습니다.
실패 12건 중 8건이 사용량 한도라 코드 수정으로는 성공률이 움직이지 않았습니다. 신뢰성은 코드와 실행 자원 두 축으로 나뉘어 있었습니다.
검사기는 사이트맵 문제를 나흘 동안 정확히 알렸지만 원인 계층은 알려주지 않아서 필자는 엉뚱한 계층을 며칠 만졌습니다.
규칙 열일곱 개짜리 검사기에 회귀 테스트가 0건이어서 규칙 하나를 되돌리다 다른 규칙이 조용히 깨질 뻔했습니다.
그래서 완료 조건 문장 다음 줄에 무엇을 실패로 셀 것인지와 검사기 자체를 무엇으로 검증할 것인지를 같이 적기로 했습니다. 에이전트에게 일을 맡기는 방식을 정리해본 글을 쓸 때는 여기까지 생각이 닿지 못했는데요 위임의 난이도는 지시문보다 실패를 세는 쪽에 있었던 듯합니다.
