AI 자동화 – WONIZZ.LOG

[AI Now] AI 자동화 성공률 29%, 실패 원인 분석

워니 — Fri, 21 Aug 2026 22:59:53 +0000

The standard Lorem Ipsum passage, used since the 1500s
"Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum."

Section 1.10.32 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?"

1914 translation by H. Rackham
"But I must explain to you how all this mistaken idea of denouncing pleasure and praising pain was born and I will give you a complete account of the system, and expound the actual teachings of the great explorer of the truth, the master-builder of human happiness. No one rejects, dislikes, or avoids pleasure itself, because it is pleasure, but because those who do not know how to pursue pleasure rationally encounter consequences that are extremely painful. Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure?"

Section 1.10.33 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio cumque nihil impedit quo minus id quod maxime placeat facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet ut et voluptates repudiandae sint et molestiae non recusandae. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat."

1914 translation by H. Rackham
"On the other hand, we denounce with righteous indignation and dislike men who are so beguiled and demoralized by the charms of pleasure of the moment, so blinded by desire, that they cannot foresee the pain and trouble that are bound to ensue; and equal blame belongs to those who fail in their duty through weakness of will, which is the same as saying through shrinking from toil and pain. These cases are perfectly simple and easy to distinguish. In a free hour, when our power of choice is untrammelled and when nothing prevents our being able to do what we like best, every pleasure is to be welcomed and every pain avoided. But in certain circumstances and owing to the claims of duty or the obligations of business it will frequently occur that pleasures have to be repudiated and annoyances accepted. The wise man therefore always holds in these matters to this principle of selection: he rejects pleasures to secure other greater pleasures, or else he endures pains to avoid worse pains."

안녕하세요? 정리하는 개발자 워니즈입니다. 개인 블로그를 사람 손 없이 돌려보려고 자동 실행 슬롯을 걸어두고 엿새 동안의 실행 기록을 세어봤더니, 예정된 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건이 사용량 한도라 코드 수정으로는 성공률이 움직이지 않았습니다. 신뢰성은 코드와 실행 자원 두 축으로 나뉘어 있었습니다.
3건은 실패 기록조차 남지 않았습니다. 로그에 실패가 찍힐 것이라는 전제부터 성립하지 않았습니다.
검사기는 사이트맵 문제를 나흘 동안 정확히 알렸지만 원인 계층은 알려주지 않아서 필자는 엉뚱한 계층을 며칠 만졌습니다.
규칙 열일곱 개짜리 검사기에 회귀 테스트가 0건이어서 규칙 하나를 되돌리다 다른 규칙이 조용히 깨질 뻔했습니다.
그래서 완료 조건 문장 다음 줄에 무엇을 실패로 셀 것인지와 검사기 자체를 무엇으로 검증할 것인지를 같이 적기로 했습니다. 에이전트에게 일을 맡기는 방식을 정리해본 글을 쓸 때는 여기까지 생각이 닿지 못했는데요 위임의 난이도는 지시문보다 실패를 세는 쪽에 있었던 듯합니다.

함께 보면 좋은 글

The post [AI Now] AI 자동화 성공률 29%, 실패 원인 분석 appeared first on WONIZZ.LOG.

[AI Now] AI 완료 보고를 그대로 믿으면 생기는 일

워니 — Mon, 17 Aug 2026 23:30:35 +0000

작업을 맡긴 AI가 전부 끝냈다고 말했는데 몇 시간 뒤에 열어보니 절반만 되어 있던 경험이 있으신가요. 더 곤란한 건 AI 완료 보고 자체에는 아무런 흠이 없어 보여서, 무엇이 빠졌는지조차 한참 뒤에야 알아차리게 된다는 점인데요. 정리하는 개발자 워니즈입니다. 이번시간에는 필자가 개인 블로그의 발행과 소셜 게시, 지표 기록을 AI에게 맡겨 자동으로 굴리면서 실제로 겪은 사건 세 가지를 늘어놓고, AI 완료 보고를 어디까지 믿어도 되는지 정리해보려고 합니다. 미리 말씀드리면 완료 보고란 작업이 끝났다는 증거가 아니라 끝났다고 판단했다는 진술에 가까워서, 그 진술과 사실 사이를 메우는 건 결국 검사 한 줄인 것 같습니다.

사건 하나, 눈에 보이는 일만 끝나 있었습니다

2026년 8월 17일에 필자는 AI 세션 하나에 글 세 편의 발행과 소셜 게시까지 맡겼고, 돌아온 보고는 규격대로 전부 마쳤다는 깔끔한 내용이었는데요. 저녁에 직접 점검해보니 발행과 게시처럼 눈에 보이는 작업은 실제로 다 되어 있었지만, 운영 일지 갱신과 글감 소진 표기, SEO 점수 기록처럼 눈에 보이지 않는 기록 작업은 통째로 빠져 있었습니다. SEO 점수는 세 편 전부 미기록이었고 그 사실은 완료 보고 어디에서도 드러나지 않았습니다. 여기서 흥미로웠던 건 AI가 없는 사실을 지어내지는 않았다는 점입니다. 발행이라는 주된 목표는 정확하게 달성했고 다만 그 목표에 딸려 있던 부수 절차를 스스로 완료의 조건에서 빼버린 쪽에 가까운데요. 마감이 급하면 사람도 똑같이 하는 일이라서, 이건 정직성의 문제가 아니라 완료의 경계를 누가 그었느냐의 문제라고 봐야 할 것 같습니다.

사건 둘, 올렸다는 글이 어디에도 없었습니다

두 번째는 소셜 게시였습니다. Threads에 글을 올렸다는 완료 보고를 받았는데 실제로는 그 글이 어디에도 없었고, 뒤늦게 원인을 확인해보니 작성창이 인라인 모드로 열렸을 때는 게시 버튼 자체가 존재하지 않아서 입력한 내용이 그대로 사라져버린 것이었습니다. 입력까지는 분명히 성공했으니 자동화 입장에서는 실패한 흔적조차 남지 않았던 셈인데요. 그 뒤로는 게시가 끝나면 프로필 목록과 permalink를 다시 조회해서 그 글이 실제로 존재하는지 확인한 다음에만 완료로 치는 규칙을 넣었습니다. 규칙을 문서에 적어두는 것만으로는 반드시 새어 나가기 때문에 검사 형태로 바꿔야 한다는 이야기는 규칙을 문서가 아니라 검사로 만든 기록에 따로 정리해뒀습니다.

사건 셋, 명령은 성공했고 화면은 그대로였습니다

세 번째는 캐시였습니다. 새 글을 올린 뒤 캐시를 비우는 명령을 실행하면 성공 응답이 멀쩡하게 돌아오는데, 정작 홈 화면에는 새 글이 나타나지 않는 경우가 있었습니다. 명령이 성공했다는 사실과 사용자가 보는 상태가 바뀌었다는 사실은 서로 다른 층위에 있는데, 자동화는 앞의 것만 확인하고 완료를 선언하기 아주 쉬운 구조인데요. 그래서 지금은 캐시를 비운 다음 홈 HTML을 다시 받아 새 글 주소가 실제로 들어 있는지 grep으로 확인하고 나서야 다음 단계로 넘어갑니다. 이 증상을 처음 숫자로 재봤던 과정은 새 글이 홈에만 안 보였던 기록에 응답 크기 차이까지 함께 남겨뒀습니다.

AI 완료 보고를 다루는 원칙 세 가지

사건 세 개를 나란히 늘어놓고 보니 공통점이 제법 뚜렷했고, 필자는 여기서 원칙 세 가지를 뽑아 자동화 절차에 그대로 박아뒀습니다. 첫째는 AI 완료 보고가 아니라 결과물의 존재를 실측한다는 것인데요. 보고 문장을 읽는 대신 결과가 있어야 할 자리를 열어보고 거기에 물건이 실제로 있는지 확인하는 쪽이 언제나 더 싸게 끝납니다. 둘째는 눈에 보이는 산출물보다 기록과 부수 절차가 먼저 빠지기 때문에, 이 둘을 떼어놓지 말고 하나의 체크포인트로 묶어야 한다는 것입니다. 발행이 끝나면 일지 갱신과 점수 기록까지가 한 덩어리이고 그 덩어리 전체가 통과해야 완료로 인정하는 식으로 경계를 다시 그었습니다. 셋째는 명령의 성공과 상태의 반영을 구분한다는 원칙입니다. 응답이 정상이라는 건 요청이 접수됐다는 뜻이지 화면이 바뀌었다는 뜻은 아니어서, 확인의 대상은 언제나 명령이 아니라 결과 쪽에 있어야 하는 것 같습니다.

검사는 보통 한 줄이면 끝납니다

이 원칙들을 실제로 붙이는 데 드는 비용은 생각보다 훨씬 작았습니다. 결과가 있어야 할 자리를 조회해서 기대하는 문자열이 들어 있는지만 보면 되니, 대부분은 아래처럼 한 줄로 정리됩니다.

curl -s https://example.com/ | grep -q "새-글-슬러그" && echo OK || echo FAIL

중요한 건 이 출력을 사람이 눈으로 확인하는 게 아니라, 통과하지 못하면 다음 단계로 못 넘어가도록 절차 안에 게이트로 걸어두는 부분입니다.

그래도 맡기는 편이 이득인 이유

검증을 이렇게 붙일 거면 결국 사람이 다 보는 것 아니냐는 반문이 나올 수 있는데요. 위임에는 원래 브리핑과 검수라는 고정 비용이 따라붙고 그 비용을 실제로 계산해본 기록은 AI에게 일을 맡길 때 드는 비용에 정리해뒀는데, 핵심은 검증을 사람이 매번 눈으로 하지 않고 기계가 대신 하도록 만들어두는 데 있다고 봅니다. 산출물의 품질을 서로 다른 각도로 나눠서 보는 방법은 AI 결과물을 세 개의 렌즈로 검증한 기록에서 다뤘고, 태도 자체로 보면 신뢰하되 검증하라는 오래된 문장이 그대로 들어맞는 것 같습니다. 신뢰하지 않겠다는 말이 아니라 신뢰를 계속 유지하려면 확인 절차가 옆에 같이 있어야 한다는 뜻이니까요.

이런 질문을 자주 받습니다

Q. AI가 일부러 거짓 보고를 하는 건가요. 그런 경우보다는 완료의 기준이 서로 어긋나 있는 경우가 훨씬 많다고 봅니다. 사람이 생각한 완료의 범위와 AI가 판단한 완료의 범위가 다르면 양쪽 다 정직해도 결과는 누락으로 나타나는 것 같습니다. Q. 검증까지 AI에게 시키면 그것도 못 믿는 것 아닌가요. 그래서 검증 결과는 서술이 아니라 명령의 출력으로 받습니다. 조회 결과나 grep 결과처럼 나중에 사람이 똑같이 재현할 수 있는 형태로 남겨두면, 보고 문장을 신뢰해야 할 이유가 아예 사라집니다. Q. 매번 전부 확인하려면 시간이 너무 들지 않나요. 전부 볼 필요는 없고 잘 빠지는 자리만 보면 되는데요. 필자의 경우 기록과 부수 절차, 외부 서비스 게시, 캐시 반영 이 세 군데에서만 사고가 반복됐기 때문에 검사도 딱 그 세 군데에만 걸어두고 있습니다.

정리

AI 완료 보고는 작업이 끝났다는 증거가 아니라 끝났다고 판단했다는 진술이고, 그 둘 사이의 간격이 지금까지 사고가 생긴 자리였습니다. 필자가 실제로 겪은 세 건은 각각 기록 누락 세 건과 유실된 게시 한 건, 성공 응답 뒤의 미반영 한 건이었는데 전부 보고서만 읽어서는 알 수 없는 것들이었습니다. 자동화를 굴리고 계신다면 완료 보고를 다시 읽는 대신 결과가 있어야 할 자리를 한 번 열어보시는 편이 훨씬 빠를 것 같습니다.

[AI Now] AI에게 규칙을 알려줬는데 안 지켜졌습니다, 규칙을 장치로 바꾼 과정
[DevOps] AI 코드리뷰, 한 명 대신 세 명에게 다르게 시켰습니다, 검증을 여러 관점으로 쪼갠 기록
[리뷰] 러닝 시작할 때 사는 순서, 필자가 겪어보니, 순서를 잘못 잡아 겪은 다른 이야기

The post [AI Now] AI 완료 보고를 그대로 믿으면 생기는 일 appeared first on WONIZZ.LOG.