자동화율 98%인데도, 쉴 수 없었다

나는 혼자서 회사를 경영하고 있다. AI (Claude Code)와 17개의 launchd 작업(job)으로 업무의 98%를 자동화했으며, SNS는 하루 27건 자동 배포, 기사는 Zenn · Qiita · note의 3개 채널에 자동 공개된다. 월 약 2만 엔의 AI 운영 비용으로 회사가 돌아가고 있다.

이 이야기만 들으면 "그럼 원하는 만큼 쉴 수 있겠네"라고 생각할 것이다. 실제로 나도 그렇게 생각했다.

하지만 현실은 달랐다. 자동화가 진행되면 진행될수록, 오히려 쉴 수 없게 되는 시기가 있었다. 이 기사에서는 그 "진짜 이유"와 내가 실제로 실행한 대책을 적는다.

왜 자동화해도 쉴 수 없는가

이유 1: 자동화는 「실행」을 대체하지만 「판단」을 대체하지 않는다

나의 경영 방침은 "AI는 실행에 사용한다. 판단은 인간이 한다"이다. 이것은 안전을 위한 철칙이지만, 뒤집어 말하면 판단이 필요한 한, 나는 시스템에서 떨어질 수 없다는 뜻이기도 하다.

대외 액션(메일 전송, 청구서 발행, SNS 게시물의 일부)은 모두 draft → 승인 → 실행의 파이프라인을 거치고 있다. 이 승인 파이프라인을 도입한 이유는, 과거에 AI의 출력을 확인 없이 자동 전송했다가 거래처에 경어가 어색한 영업 메일이 전달된 사고가 있었기 때문이다.

즉, 승인 플로우는 실패로부터 배운 필수적인 메커니즘이지만, 동시에 "매일 승인 버튼을 누르는 사람"을 필요로 한다. 1인 사장의 경우, 그것은 나밖에 없다.

이유 2: 자동화 시스템 자체가 「돌봐야 할 대상」이 된다

자동화는 방치할 수 있는 마법이 아니다. 나는 지금까지 다음과 같은 장애를 경험했다.

• cron이 macOS의 전체 디스크 접근(Full Disk Access) 문제로 전멸 (launchd로 전면 이행하여 해결)
• Zenn의 속도 제한(Rate Limit)에 여러 번 걸려 배포 실패 (1일 1콘텐츠 규칙을 락 파일(lock file)로 자동화)
• CLAUDE.md가 1,000행을 넘어 AI가 지시와 반대로 동작하기 시작 (200행 이내로 정리하여 해결)
• AI가 git push --force를 자동 실행하여 브랜치 소멸 (절대 금지 리스트를 작성)

자동화 작업(job)이 17개 있다는 것은, 17개의 "고장 날 수 있는 것"을 안고 있다는 뜻이다. 여행지에서 "오늘 자동 배포, 제대로 돌아갔을까" 하고 신경 쓰여 스마트폰을 열게 된다. 이것은 휴가가 아니다.

이유 3: 「쉬면 매출이 멈춘다」는 착각

1인 사장에게는 대역이 없다. 그래서 "내가 멈추면 = 회사가 멈춘다"라는 감각이 몸에 밴다.

하지만 냉정하게 숫자를 보면 이것은 절반은 착각이다. 당사의 2026년 3월 매출은 약 196만 엔으로 대부분 수탁(외주)이다. 서적 매출 약 2.1만 엔은 완전히 자동으로 발생하고 있다. 수탁 업무도 납기 기준으로 움직이고 있어, 1주일 쉰다고 해서 즉시 매출이 사라지는 것은 아니다.

멈추는 것은 매출이 아니라 「진척」이다. 그리고 진척이 1주일 멈춘다고 해서 회사가 망하지는 않는다. 이 구분이 가능해질 때까지, 나는 쓸데없이 휴가를 두려워하고 있었다.

내가 실제로 실행한 휴가 설계

대책 1: 승인을 「매일」에서 「배치(Batch)」로 바꾼다

이전에는 승인 대기가 발생할 때마다 대응했지만, 승인 큐(queue)를 재검토하여 긴급성에 따라 2가지로 분류했다.

• 즉시 승인이 필요한 것 (고객 대응 등) → 애초에 휴가 전에 발생원을 차단한다
• 쌓아두어도 되는 것 (SNS 초안, 기사 공개 등) → 주 1회 배치 승인으로 충분하다

직접 해보고 알게 된 것은, "즉시 승인이 필요한 것"은 사실 거의 없다는 사실이다. 아침 5분 동안 모든 부문을 파악하고 승인 버튼을 누르는 평상시의 운영을, 휴가 중에는 "3일에 한 번 5분"으로 걸러내도 아무것도 망가지지 않았다.

대책 2: 자동화 작업에 「휴가 모드」가 아니라 「실패해도 조용히 기다리는」 설계를 넣는다

처음에는 "휴가 중에는 모든 작업을 멈추자"라고 생각했지만, 이것은 악수였다. 멈춘 작업을 재개하는 것을 잊어버리거나, 재개 시 쌓여있던 큐가 한꺼번에 흘러나오는 등 2차 장애의 온상이 된다.

대신 채택한 것은, 실패 시 자동으로 재시도(retry)하고, 안 되면 큐에 쌓아두고 기다리는 설계다. Zenn의 속도 제한 대책으로 만든 락 파일 방식이 그대로 응용될 수 있었다. 작업은 실패해도 망가지지 않고, 다음 날 다시 시도한다. 내가 3일 동안 보지 않더라도, 시스템은 조용히 순서를 기다리고 있을 뿐이다.

"자동화는 『AI의 능력을 제한하기 위해서』가 아니라 『안심하고 위임하기 위한 메커니즘』"이라고 나는 생각한다. 휴가 설계도 마찬가지로, 안심하고 방치할 수 있는 고장 방식을 설계해 두는 것이 본질이다.

대책 3: 휴가 전에 「새로운 것」을 시작하지 않는다

과거의 가장 큰 실패는 10개 사업을 동시에 운영하여 9개 사업의 매출이 0원이었던 것이다. SaaS를 4개 만들었지만 전부 유저가 0명이었다. 이 경험을 통해 3개 사업에 집중하는 전략으로 전환했다.

휴가에도 동일한 원리가 적용된다. 휴가 전 1주일 동안 새로운 자동화 작업 (Automation Job)이나 새로운 전략을 준비해두면, 휴가 중에 그것이 문제를 일으킨다. 휴가 전에는 '안정화된 운영 (Mature Operation)'만을 남겨둔다. 새로운 일은 돌아와서 한다.

대책 4: 「모니터링하지 않기로」 결정한 항목을 명문화하기

의지력으로 「보지 않는 것」은 불가능하다. 그래서 나는 휴가 전에, 볼 항목과 보지 않을 항목을 텍스트로 적어두기로 했다.

• 볼 것: 승인 큐 (Approval Queue, 3일에 1회), 에러 에스컬레이션 (Escalation) 알림
• 보지 않을 것: SNS 반응, 액세스 분석 (Access Analysis), 매출 일일 추이

GA4의 수치는 휴가 중에 봐도 대응책이 없다. 대응책이 없는 정보는 휴가 중에는 노이즈 (Noise)일 뿐이다.

요약: 휴가는 「자동화의 졸업 시험」

자동화를 했음에도 쉴 수 없는 이유는 기술이 아니라 설계에 있다.

• 판단(승인)이 매일 필요한 구조로 되어 있다 → 배치화 (Batching)한다
• 시스템이 「고장 나면 즉시 대응」을 전제로 하고 있다 → 조용히 기다릴 수 있는 고장 방식으로 바꾼다
• 「쉰다 = 매출이 멈춘다」는 착각 → 멈추는 것은 진척도일 뿐이라고 숫자로 확인한다
• 휴가 전에 새로운 일을 준비해버린다 → 안정화된 운영만을 남긴다

나는 「비용은 10분의 1이 되지만, 매출이 10배가 되는 것은 아니다」라는 것을 뼈저리게 느꼈지만, 휴가에 대해서도 마찬가지다. 자동화는 마법처럼 자유를 주는 것이 아니다. 자유는, 방치에 견딜 수 있는 설계를 한 만큼 얻을 수 있다.

3일 동안 시스템을 보지 않아도 회사가 정상 운영되었을 때, 비로소 「자동화했다」라고 말할 수 있다. 휴가는 1인 사장의 자동화 졸업 시험이라고 생각한다.

📚 AI 경영·자동화의 실천 노하우를 서적으로 정리하고 있습니다

1인 사장 × AI의 경영 수법, Claude Code를 이용한 업무 자동화의 구체적인 구축 방법은 Zenn 서적에서 자세히 해설하고 있습니다.

👉 서적 목록은 이쪽으로

Discussion