오늘 아침, 매일 돌던 이미지 생성이 한 장도 안 나왔습니다. 로그를 열어보니 서버가 준 답은 HTTP 500이었습니다. 500은 "서버 쪽에 문제가 생겼다"는 뜻입니다. 그러니까 제 잘못이 아니고, 저쪽이 잠깐 아픈 거고, 좀 있다 다시 하면 된다는 뜻이죠.
그래서 다시 돌렸습니다. 또 500. 세 번째도 500. 그때까지 제가 세운 가설은 "외부 서비스 장애, 기다리면 복구됨"이었습니다. 완전히 틀린 가설이었습니다.
응답 본문을 열어보니 안에 이렇게 적혀 있었습니다. 402 — 잔액이 부족합니다. 그 서비스가 그날 아침부로 익명 무료 사용을 없애고 유료 잔액제로 바꾼 겁니다. 제 잔액은 0이었고요. 기다려도 절대 복구될 리 없는 상황을, 저는 "곧 복구되겠지"로 읽고 있었습니다. 오늘은 이 얘기를 해보려고 합니다. AI 자동화 에러를 만났을 때, 왜 화면에 뜬 에러 메시지를 그대로 믿으면 안 되는가.
1. 조용한 실패와는 정반대의 함정
예전에 자동화가 조용히 멈추는 문제를 다룬 적이 있습니다. 아무 소리도 안 나서 며칠이 지나도 모르는 경우요. 그때 내린 결론은 "침묵을 정상이라고 믿지 말라"였고, 대책으로 알림 구조를 다시 짠 얘기도 따로 썼습니다.
오늘 겪은 건 정확히 그 반대입니다. 시스템은 시끄러웠습니다. 에러를 냈고, 로그에 남겼고, 숫자까지 붙여줬습니다. 그런데 그 숫자가 틀린 곳을 가리키고 있었습니다.
이게 더 고약한 이유가 있습니다. 침묵은 최소한 "나는 모른다"는 상태로 남겨둡니다. 그런데 틀린 에러 메시지는 나에게 확신을 줍니다. "서버 문제네, 내가 할 건 없네." 그 확신 때문에 저는 엉뚱한 방향으로 세 번을 더 시도했습니다. 아무 정보가 없었다면 오히려 더 빨리 본문을 열어봤을 겁니다.
2. AI 자동화 에러가 유독 틀린 이유를 대는 세 가지 구조
왜 이런 일이 생길까요. 오늘 사건을 뜯어보니 세 겹이었습니다. 코딩을 몰라도 이해되는 수준으로 풀어보겠습니다.
첫째, 에러는 여러 계층을 건너오면서 뭉개집니다. 실제로 문제가 난 곳은 결제 계층("잔액 없음")인데, 그 앞단의 중계 서버는 그 사정을 모릅니다. "뒤쪽에서 뭔가 실패했다"는 것만 알고, 그래서 가장 무난한 번호인 500을 붙여 내보냅니다. 정확한 이유는 본문 안쪽에 텍스트로 딸려오지만, 대부분의 자동화 코드는 번호만 보고 본문은 버립니다. 제 코드도 그랬고요.
둘째, 2차 증상이 1차 원인을 덮어버립니다. 재시도를 하다 보니 중간에 다른 에러도 섞여 나왔습니다. "이 IP는 동시에 1건만 처리 가능"이라는 메시지였죠. 여기에 함정이 있습니다. 제 코드는 60초를 기다리다 끊었는데, 서버 쪽 대기열에는 제 요청이 그대로 남아 있었습니다. 그래서 다음 재시도가 조금 전의 자기 자신에게 막혀 거절당한 겁니다. 이때 제가 만약 이 메시지만 봤다면 "동시 요청을 줄이자"는 엉뚱한 수리를 시작했을 겁니다. 진짜 원인은 여전히 잔액이었는데요.
셋째, 재시도가 증거를 지웁니다. 보통 재시도는 착한 설계로 여겨집니다. 그런데 재시도는 첫 번째 실패의 내용을 덮어씁니다. 가장 정직한 정보는 대개 맨 처음 실패에 들어 있습니다. 두 번째부터는 내 재시도가 만들어낸 소음이 섞이기 시작하거든요. 게다가 이 출력들이 화면에 바로 안 뜨고 버퍼에 갇혀 있다가 사라지면, 겉보기엔 "에러도 없이 결과물만 0장"인 상태가 됩니다.
3. 그래서 순서를 바꿨습니다 — 비개발자용 3단계
이번 일로 제 장애 대응 순서를 이렇게 바꿨습니다. 셋 다 코딩 지식이 필요 없고, AI에게 시키기만 하면 되는 것들입니다.
1단계 — 번호 말고 본문을 보여달라고 한다. AI에게 자동화를 맡기고 있다면 이 한 줄이면 됩니다. "실패하면 상태 번호만 말고 응답 본문 전체를 그대로 로그에 남겨줘." 오늘 사건에서 제가 3분 만에 끝낼 수 있었던 걸 한참 헤맨 이유는 딱 이것 하나였습니다. 답은 처음부터 본문 안에 적혀 있었거든요.
2단계 — 첫 번째 실패만 따로 보관한다. "재시도 중 첫 실패의 응답은 따로 남겨줘"라고 시켜두세요. 나중에 원인을 찾을 때 읽어야 할 건 마지막 실패가 아니라 첫 실패입니다.
3단계 — 품질 말고 '개수'를 기록한다. 이게 제일 값싸고 효과가 좋았습니다. 결과물의 내용을 평가하려 들지 말고, 규모만 숫자로 남기는 겁니다. 오늘 이미지 몇 장 나왔는지, 글자 수가 몇 자인지, 수집한 항목이 몇 개인지. 평소 10장 나오던 게 0장이면 내용을 한 글자도 안 읽고도 즉시 이상합니다. 판단은 비싸고 계수는 공짜입니다.
4. 한 가지 더 — "무료"는 조용히 끝납니다
오늘 사건의 진짜 교훈은 기술이 아니라 의존에 있었습니다. 제가 쓰던 건 무료로 열려 있던 서비스였습니다. 그게 어느 날 아침 유료로 바뀌었고, 그쪽은 저에게 통보할 의무가 없습니다. 저는 고객이 아니었으니까요.
1인 기업이 AI로 자동화를 짜다 보면 무료로 열린 API를 여러 개 엮게 됩니다. 그 편리함 덕분에 혼자서도 회사가 굴러가는 건 사실입니다. 다만 그중 하나가 유료로 돌아서는 날, 내 파이프라인은 그날 아침 예고 없이 멈춥니다. 그래서 요즘은 외부 서비스를 붙일 때 질문을 하나 더 합니다. "이게 내일 갑자기 유료가 되면, 오늘 하려던 일은 어떻게든 끝낼 수 있나?"
오늘 저는 이미지 생성을 제 컴퓨터에서 직접 그리는 방식으로 바꿔서 하루치 작업을 끝냈습니다. 바깥에서 만들던 것보다 화려하진 않습니다. 대신 남의 사정으로 멈추지 않습니다. 이런 판단을 어떤 기준으로 내리고 어떻게 구조를 짜왔는지는 「AI 회사를 만들었습니다 -실전편-」에 정리해뒀습니다.
마무리 — 에러 메시지는 증언이지 진단이 아닙니다
정리하면 이렇습니다. 침묵도 못 믿고, 에러 메시지도 못 믿습니다. 그럼 뭘 믿느냐. 물건이 나왔는지를 믿습니다.
에러 메시지는 목격자의 증언에 가깝습니다. 거짓말을 하려는 건 아닌데, 자기가 본 것만 말합니다. 중계 서버는 잔액 얘기를 모르고, 대기열은 결제 얘기를 모릅니다. 각자 자기 자리에서 본 것만 정직하게 말하는데, 그걸 그대로 원인이라고 읽으면 엉뚱한 데를 고치게 됩니다.
혹시 지금 "외부 서비스 장애인 것 같다"며 재시도를 돌려두신 자동화가 있다면, 재시도를 멈추고 맨 처음 실패의 응답 본문 한 번만 열어보시길 권합니다. 저는 그 안에서 세 자리 숫자 하나를 발견했고, 그날의 나머지 일정을 구했습니다.
작성: Art Gourmet · 본문의 사건(HTTP 500 응답 본문 안의 402 잔액 부족, 무료 티어의 유료 전환, 동시 요청 제한 메시지, 60초 타임아웃과 서버 대기열의 어긋남)은 2026년 9월 20일 오전 자사 자동화 파이프라인에서 직접 관측한 내용입니다. 특정 서비스의 요금 정책은 이후 달라질 수 있습니다.