자동화를 처음 붙였을 때 가장 무서웠던 건 "AI가 이상한 걸 올리면 어쩌지"였습니다. 그래서 검수 단계를 겹겹이 쌓았죠. 그런데 정작 제가 실제로 당한 사고는 정반대였습니다. 아무 일도 일어나지 않았습니다. 이틀 연속으로 매일 돌아야 할 콘텐츠 파이프라인이 실행되지 않았는데, 저는 그걸 이틀이 지난 뒤에야 알았습니다. 에러 팝업도, 실패 알림도, 로그의 빨간 글씨도 없었습니다. 그냥 평소처럼 조용했습니다. 이걸 업계에서는 사일런트 페일러(silent failure), 조용한 실패라고 부릅니다. 코딩을 못 하는 1인 창업가가, 자기가 자는 동안 도는 AI 자동화가 조용히 멈췄을 때 그걸 어떻게 알아챌 것인가 — 오늘은 이 얘기를 해보려 합니다.
에러는 친절하다, 침묵은 잔인하다
먼저 감각을 좀 바꿔야 합니다. 에러는 사실 좋은 소식입니다. 뭔가가 빨간 글씨로 튀어나왔다는 건, 시스템이 "나 여기서 막혔어요"라고 손을 든 겁니다. 위치도, 이유도 대충 알려줍니다. 고치면 됩니다. 진짜 무서운 건 아무 소리도 안 나는 경우입니다. 제 경우엔 스케줄러가 세션을 백그라운드로 띄우는 방식에 문제가 있어서, 작업이 시작은 되는데 끝까지 못 가고 그냥 사라졌습니다. 스케줄러 입장에서는 "실행함"이고, 저에게는 "결과물 없음"입니다. 양쪽 다 자기 관점에서는 아무 문제가 없어요. 그 사이의 빈 공간에서 이틀이 증발한 겁니다.
1인 기업에서 이게 특히 치명적인 이유는 간단합니다. 저 대신 눈치채 줄 사람이 아무도 없습니다. 회사라면 누군가는 "어제 리포트 안 왔는데요?" 하고 물어봅니다. 혼자 하면 그 질문을 해줄 사람이 없습니다. 자동화의 목적 자체가 "내가 안 봐도 되게 하는 것"이니, 안 보고 있는 게 정상이고, 그래서 안 보이는 겁니다.
AI 자동화는 왜 유독 조용히 망가지나
일반 프로그램도 조용히 실패하지만, AI 에이전트는 한 단계 더 고약합니다. 이유는 두 가지입니다. 첫째, 실패가 한 지점이 아니라 사슬 전체에 퍼져 있습니다. 에이전트 관측(observability) 업계의 설명을 빌리면, 3단계에서 도구 호출 하나가 잘못됐는데 그게 8단계까지 조용히 판단을 오염시키는 식입니다. 개별 호출만 들여다보면 전부 정상으로 보이고, 세션 전체를 이어서 봐야만 문제가 드러납니다.
둘째, 실패한 결과물이 성공한 결과물처럼 생겼습니다. 프로그램이 실패하면 빈 화면이 나오거나 뻗습니다. AI가 실패하면 그럴듯한 글이 나옵니다. 잘못된 도구를 부르고도 뒤에 그럴듯한 응답을 붙이는 게 가장 흔한 조용한 실패 유형이라고 합니다. 저도 예전에 API가 "실패"라고 응답했는데 실제로는 게시가 성공해 있던 경우를 겪었습니다. 반대 방향의 불일치죠. 응답과 실제 결과가 따로 노는 순간, 로그만 믿으면 완전히 틀립니다. 그래서 결론은 이렇게 정리됩니다. 로그가 조용한 것을 정상이라고 믿으면 안 됩니다. 정상도 조용하고, 죽어도 조용합니다.
'없음'을 알람으로 바꾸는 법 — 하트비트 모니터링
여기서 가장 쓸모 있었던 개념이 하트비트 모니터링(heartbeat monitoring), 다른 말로 데드맨 스위치(dead man's switch)입니다. 보통의 감시는 밖에서 "너 아직 살아 있니?" 하고 찔러봅니다. 하트비트는 반대로, 일하는 쪽이 주기적으로 "나 아직 일하고 있어요" 하고 신호를 보내고, 신호가 안 오는 것 자체를 알람으로 취급합니다. 침묵이 곧 경보가 되는 구조죠. 비개발자 입장에서 이걸 실전으로 옮기면 이렇게 됩니다.
- 완료 신호를 남기게 시킨다. 작업이 끝나면 반드시 어딘가에 흔적을 남기게 합니다. 로그 파일 한 줄, 텔레그램 메시지 한 줄이면 충분합니다. 중요한 건 "성공했을 때만"이 아니라 끝났다는 사실 자체를 남기는 겁니다.
- 없으면 시끄러워지게 만든다. 예정 시각 + 여유시간이 지났는데 흔적이 없으면 알림이 오게 합니다. 실패를 감지하는 게 아니라 부재를 감지하는 겁니다.
- 매일 눈에 띄는 곳에 상태를 띄운다. 로컬 대시보드에 오늘 돌아야 할 것들의 체크리스트를 실시간으로 보여주면, 아침에 한 번 흘깃 보는 것만으로 "어제 세 개 중 두 개만 찍혔네"가 보입니다.
- 결과물이 있는지를 확인한다. 가장 원시적이지만 가장 정직한 방법입니다. "실행됐는가"가 아니라 "오늘 날짜 파일이 실제로 생겼는가"를 기준으로 삼는 거죠. 시스템이 뭐라고 말하든, 물건이 없으면 실패입니다.
넷 다 코딩 지식이 거의 필요 없습니다. 필요한 건 "성공했는지 묻지 말고, 물건이 나왔는지 확인한다"는 태도뿐입니다.
돌기는 도는데 품질이 무너질 때 — 검수 단계 만들기
하트비트는 "돌았는가"까지만 잡아줍니다. 더 어려운 문제는 돌긴 도는데 결과물이 서서히 이상해지는 경우입니다. 1인 기업 규모에서 거창한 평가(eval) 시스템을 만들 필요는 없습니다. 대신 이 정도는 확실히 효과가 있었습니다. 기계적으로 셀 수 있는 기준을 정해둔다 — 예컨대 "캡션은 항목당 몇 자 이상" 같은 숫자 규칙은 사람이 감으로 볼 필요 없이 글자 수만 세서 미달이면 통과를 안 시키면 됩니다. 원문 대조 검수 에이전트를 따로 둔다 — 글을 쓴 AI와 검수하는 AI를 분리하는 겁니다. 쓴 사람이 자기 글의 오류를 못 찾는 건 AI도 마찬가지입니다. 사고가 났으면 체크리스트에 영구히 박아둔다 — 비개발자 버전으로 옮기면 "한 번 당한 사고는 SOP 문서에 명시적으로 적어두고 매번 확인한다"입니다.
그리고 마지막 결정만 사람이 잡습니다. 초안 생성까지는 완전 자동, 발행 승인만 제 손. 이 경계선을 어디에 긋느냐가 사실상 자동화 설계의 전부입니다. 참고로 가트너는 에이전트형 AI 프로젝트의 40% 이상이 2027년 말까지 취소될 것으로 봤는데, 이유로 든 게 비용 급증, 불분명한 사업 가치, 그리고 부실한 리스크 통제였습니다. 2026년 중반 기준으로 실제 AI 에이전트를 배포한 조직은 17% 남짓이고, 성과가 나오는 쪽은 하나같이 "명확히 정의된 업무 + 사람의 감독"이라는 조건을 갖춘 경우였습니다. 무제한 자율성, 모호한 범위, 롤백 경로 없음이 실패 요인 목록의 상위권에 나란히 올라 있습니다. 혼자 일하는 사람에게 이건 오히려 좋은 소식입니다. 대기업이 조직 개편까지 해가며 풀어야 하는 문제를, 우리는 "어디까지 자동화하고 어디서 내가 끊을지"만 정하면 되니까요.
마치며
이번 사고에서 제가 배운 건 기술이 아니라 태도였습니다. 자동화를 붙인다는 건 일을 안 하게 되는 게 아니라, 일의 종류가 바뀌는 것입니다. 콘텐츠를 만드는 일에서, 콘텐츠가 만들어지고 있는지 확인하는 일로. 후자를 안 하면 전자도 어느 순간 조용히 사라집니다. 그래서 요즘 저는 새 자동화를 붙일 때 순서를 하나 바꿨습니다. 예전에는 "잘 돌아가게" 만드는 걸 먼저 했는데, 지금은 "안 돌아갔을 때 내가 어떻게 알게 되는가"를 먼저 정합니다. 이걸 못 정하면 자동화를 아예 켜지 않습니다. 감시 없는 자동화는 자동화가 아니라 그냥 방치니까요. 혼자서 AI로 자동화를 굴리며 겪은 이런 시행착오들은 「AI 회사를 만들었습니다 -실전편-」에도 정리해뒀습니다. 지금 돌고 있는 자동화가 있다면, 오늘 딱 하나만 확인해보시길 권합니다. 어제 그게 돌았다는 증거가 어디에 남아 있나요? 대답이 바로 안 나온다면, 그건 이미 멈춰 있을 수도 있습니다.
출처: Braintrust — Agent observability: The complete guide for 2026, Confident AI — AI Agent Observability, Drumbeats — Heartbeat Monitoring, OneUptime — Heartbeat and Dead Man's Switch Alerts, Gartner — Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027
작성: Art Gourmet