AI 자동화 플로우의 진짜 위험 — 환각보다 무서운 4가지 함정과 가드레일
지난 6개월간 32마리 AI 에이전트가 돌아가는 블로그 발행 파이프라인을 운영했어요. n8n이나 cron 같은 자동화 도구에 LLM을 끼워넣으면 "완전 자동"이 되겠다는 기대로 시작했죠. 실제로 매일 3편씩 글이 나오긴 합니다. 하지만 그 과정에서 마주친 진짜 위험은 사람들이 떠올리는 "환각"이 아니었어요. 조용한 실패, 거짓 성공, 그리고 관측 부재가 훨씬 치명적이었습니다. AI 자동화의 진짜 함정은 눈에 안 보이는 곳에 숨어 있더라고요.
4가지 함정과 제가 세운 가드레일은 뭔가요?
함정 1. 조용한 실패 — 5개월간 몰랐던 조회수 수집 중단
제 쇼츠 채널에서 조회수 수집이 멈춘 적이 있어요. 2026년 3월부터 8월까지 5개월간, 매일 새벽 2시에 실행되는 analytics-cron.sh가 돌긴 돌았는데 조회수가 0건으로 찍혔죠. 로그엔 "HTTP 403 insufficient authentication scopes"만 남아 있었어요. OAuth refresh token의 스코프가 youtube.upload 전용이라 읽기 권한이 없었던 거예요. 그 결과, 성과 학습 엔진이 매일 "표본 없음"으로 무변경 종료했습니다. 소재 최적화가 멈췄죠.
가드레일: 크리덴셜이 있는데 API가 실패하면 exit 1로 cron을 터뜨립니다. || echo로 감싸서 조용히 넘어가게 두지 않아요. Sheepdog이라는 관제 에이전트가 4시간마다 토큰·cron 잡·프로세스를 점검하고, 이상하면 즉시 알림을 쏩니다.
함정 2. 거짓 green — 미실행이 성공으로 보이는 함정
|| echo로 감싼 명령어가 종료코드 127(명령 없음)을 삼켜서, 미실행이 성공으로 보이는 거짓 green이 반복됐어요. 문서엔 "배선됨"이라 적혔는데 실제론 없던 단계도 있었죠. 한 달간 미실행이었는데 아무도 몰랐습니다.
가드레일: 실패를 성공으로 위장하지 마세요. 명령어 실행 후 종료코드를 확인하고, 실패면 즉시 알림을 보내세요. 제 경우 watchdog이 cron 잡 상태를 직접 점검해서 "등록돼 있는데 안 돈" 케이스를 잡아냅니다.
함정 3. 관측 부재 — 알림이 mock 게이트 뒤에 있어서
운영 경보 알림 단계가 mock 게이트 뒤에 있어서, 로컬 테스트 모드에선 알림이 아예 안 나갔어요. 실전 동작을 확인할 방법이 없었죠. 보이지 않으면 망가져도 모릅니다.
가드레일: 관측 장치를 먼저 세우세요. Anthropic 공식 문서에도 "Safety and guardrails" 섹션이 별도로 있는 데엔 이유가 있어요. 모델 자체의 안전성만으론 부족하고, 시스템 레벨의 방어선이 필요하거든요. 제 경우 NOTIFY_FORCE_LIVE=1 플래그로 mock 모드에서도 알림을 강제하고, 반환값을 체크해서 실제로 전송됐는지 확인합니다.
함정 4. 비용 폭발 — 루프가 꼬이면 하루 수십만 원
LLM API는 호출 한 번에 돈이 나가요. 루프가 꼬이면 끔찍하죠. 2026년 7월 중순에 claude API가 불안정해져서 재시도가 반복됐는데, 그때 예산 하드캡이 터졌어요.
가드레일: config/budget.json에 dailyhardcap을 설정하세요. 초과 시 즉시 중단됩니다. 모든 LLM 호출은 .omc/audit/audit-log.jsonl에 SHA256 해시체인으로 기록돼서, 누가 언제 무슨 모델로 얼마나 썼는지 추적 가능해요. 신뢰가 아니라 검증이 답입니다.
예상되는 반론에 대한 제 생각
"테스트하면 되잖아요?"
맞아요, 테스트는 필수죠. 제 파이프라인엔 스모크 테스트 18개가 있고, 게이트 16종을 직접 실행해보는 검증도 있어요. 하지만 모든 엣지케이스를 못 잡아요. grep -c로 개수만 세면 오탐(unprocessed→nproc)을 못 잡거든요. 테스트는 거짓 red를 막지만, 거짓 green은 실전에서 터져요. 그래서 관측 장치가 필요합니다. 테스트로 방어하고, 관측으로 보완하는 거죠.
"사람도 실수하는데, AI만 탓하는 거 아니에요?"
공정한 지적이에요. 사람도 토큰 스코프를 잘못 설정하고, crontab에 등록 안 하고 넘어갈 수 있죠. 하지만 차이는 규모예요. 사람은 하루에 3개 작업을 합니다. AI 파이프라인은 하루에 32개 에이전트가 병렬로 돌아요. 실수 하나가 5개월간 반복될 수 있죠. 그래서 전 AI를 탓하는 게 아니라, AI를 쓸 때 필요한 가드레일 수준이 다르다고 주장하는 겁니다. 사람한테는 "주의하세요"로 충분하지만, AI한테는 "코드로 강제하세요"가 답이에요.
AI 자동화, 어떻게 접근해야 할까요
6개월간 배운 건, AI 자동화는 "완전 자동"이 아니라 "감시형 자동"이어야 한다는 거예요. 사람이 매번 개입할 순 없지만, 사람이 언제든 멈출 수 있어야 합니다.
구체적으로 시작하려면? 먼저 결정론 게이트 3개만 세워보세요. 중복 검사, 길이 검사, 금지어 검사. 이것만으로도 환각의 80%는 막아집니다. 그다음엔 실패 알림을 붙이세요. Slack이든 Discord든, 뭔가 터지면 사람이 알아야 해요. 마지막으로 예산 하드캡을 걸어두세요. 루프가 폭주해도 파산은 안 합니다.
AI 자동화의 진짜 위험은 환각이 아니에요. 보이지 않게 망가지는 것이에요. 관측하고, 검증하고, 차단하세요. 그게 제가 6개월간 삽질하며 배운 전부입니다.
자주 묻는 질문
Q. 자동화를 어디까지 맡기고 어디부터 사람이 개입해야 하나요?
A. 판단이 필요한 지점에 사람을 세워야 해요. 데이터 수집·변환·검증처럼 규칙이 명확한 단계는 자동으로 두고, 발행·삭제·비용 지출처럼 되돌리기 어려운 액션엔 승인 단계를 넣으세요. 제 경우 글 생성은 자동이지만 실제 게시는 사람이 검수합니다. 자동화가 제안하고 사람이 결정하는 구조가 안전해요.
Q. 이미 돌아가는 자동화에 관측을 나중에 붙이려면 뭘 먼저 하나요?
A. 로그부터 세우세요. 각 단계가 시작·종료될 때 타임스탬프와 상태를 기록하고, 파일로 남기세요. 그다음 이상 패턴을 정의하세요. "30분 안에 종료돼야 하는데 1시간째 돌고 있다"처럼요. 마지막으로 알림을 연결하세요. 처음엔 모든 실패를 다 알리고, 노이즈가 보이면 그때 필터링하면 돼요.
Q. 혼자 운영하는 1인 개발자도 이런 가드레일이 필요한가요?
A. 오히려 더 필요해요. 팀이 있으면 누군가 눈치채지만, 혼자면 조용히 망가져도 몰라요. 규모가 작을 땐 복잡한 시스템보다 간단한 체크리스트가 답입니다. "매일 아침 이 3가지 수치를 확인한다" 같은 루틴을 정하고, 수치가 이상하면 파고드세요. 자동화가 작을수록 망가졌을 때 고치기도 쉬워요.