서론: 자동화 사고는 「대외 액션」에서 발생한다

나는 현재 1명의 경영자로서 10개 부문의 AI 에이전트(AI Agent)를 가동하며, 업무의 98%를 자동화하고 있다. launchd 작업은 17개, SNS 자동 게시물은 하루 27건, 기사 자동 공개는 하루 3개 채널이다. 월간 AI 운영 비용은 약 2만 엔(Claude Code Max)이며, 3월 매출은 약 196만 엔이었다.

하지만 이 자동화가 처음부터 평화로웠던 것은 아니다. 오히려 AI 경영의 진정한 어려움은 「만드는 것」이 아니라 「대외로 무언가를 내보내는」 순간에 있다.

나는 과거에 다음과 같은 실패를 경험했다.

• 영업 메일을 AI의 출력물 그대로 자동 전송하여, 경어가 망가진 메일이 거래처에 전달됨
• AI가 git push --force를 자동 실행하여 작업 중이던 브랜치가 삭제됨
• Zenn에 하루에 여러 개의 기사와 서적을 동시에 공개하려다 Rate Limit(속도 제한)에 걸려 모두 실패함
• 가짜 문의(더미 전화번호, 존재하지 않는 이메일)를 알아차리지 못하고 처리해 버림

이 모든 것은 「AI를 멈췄어야 했다」가 아니라, 「대외 액션을 직접 실행하게 했다」는 것이 본질적인 원인이었다. 본 기사에서는 내가 운용하고 있는 AI 경영의 「승인 파이프라인 (Approval Pipeline)」 설계를 그대로 공개한다.

원칙: read-only / draft / execute의 3계층

승인 파이프라인의 핵심은 모든 액션을 3가지 권한 레벨로 분류하는 것이다.

나의 리포지토리에서는 .company/steering/permissions.md에 이 임계치가 적혀 있으며, 모든 에이전트가 이 규칙을 따른다. CLAUDE.md에도 명시되어 있어, Orchestrator(경영 판단을 다루는 최상위 에이전트)가 「대외에 영향을 주는 액션을 직접 실행해서는 안 된다」는 원칙을 철저히 준수한다.

포인트는 「대외」와 「내부」의 경계를 어디에 긋느냐이다. 나의 기준은 심플하다. 취소하기 위해 누군가에게 머리를 숙여야 하는 것은 모두 draft로 분류한다. 코드의 커밋(Commit)은 내부이지만, git push는 외부이다. 테스트 실행은 내부이지만, 운영 환경 배포(Production Deployment)는 외부이다.

실패 1: AI의 출력을 그대로 보낸 메일

처음으로 승인 파이프라인의 필요성을 절감한 것은 영업 메일 자동 전송 사고였다. AI가 생성한 본문을 확인하지 않고 SMTP로 흘려보냈더니, 경어가 망가진 메일이 거래처에 도착했다. 내용 자체는 맞았지만, 비즈니스 메일로서는 실격이었다.

여기서 나는 「AI의 출력 품질을 높이는 것」이 아니라, 「AI에게 송신 권한을 주지 않는 것」 방향으로 선회했다. 구체적으로는 다음과 같다.

• 영업 에이전트는 메일 본문을 drafts/sales/2026-xx-xx-<id>.md에 작성한다.
• 동시에 .company/approval-queue.md에 [AQ-xxx] sales: <제목>을 추가한다.
• 아침의 /ai-ceo:morning 명령으로 승인 대기 목록이 일람화된다.
• 내가 /ai-ceo:approve AQ-xxx를 입력하면 비로소 송신 작업이 실행된다.
• 거절할 경우 /ai-ceo:reject AQ-xxx "이유"로 반려하며, 이유는 decisions 로그에 남는다.

이 설계의 핵심은 「송신 트리거가 항상 승인 ID의 존재에 의존한다」는 것이다. 드래프트 파일이 존재하는 것만으로는 발송되지 않는다. 승인 큐에서 삭제되어 decisions 로그에 기록되었다는 「양의 신호 (Positive Signal)」가 없는 한, SMTP 실행 함수는 호출되지 않는다.

이것만으로도 AI의 오생성(Misgeneration)은 「송신 전에 알아차릴 수 있는 사고」로 격하될 수 있다.

실패 2: git push --force에 의한 소실 사고

또 하나 잊을 수 없는 것은 AI가 git push --force를 자동 실행하여 브랜치를 삭제한 사건이다. 논리적으로는 정당한 조작이었으나, 결과적으로는 몇 시간 분량의 작업이 사라졌다.

이를 계기로 만든 것이 「절대 금지 리스트」이다. 승인 파이프라인 위에 덧씌우는 더 강력한 안전장치다.

• git push --force / --force-with-lease

• rm -rf

/ 이나 ~ 하위 디렉토리 -
DROP TABLE / TRUNCATE -

• 운영 DB(Production DB)로의 직접 연결
• npm publish / cargo publish 와 같은 공개 계열 -
• --no-verify 를 통한 커밋 - KDP 자동 출판 스크립트 (bot 판정 리스크가 있기 때문)

이것들은 "초안(draft)화하여 승인"하는 수준이 아니라, 애초에 실행 명령어 어휘(vocabulary)에 포함시키지 않습니다. 에이전트의 시스템 프롬프트(System Prompt)와 Claude Code의 settings.json 내 거부(deny) 규칙 양쪽 모두에서 차단하고 있습니다. "승인하면 해도 된다"가 아니라 "승인해도 실행 경로가 존재하지 않는" 상태를 만드는 것이 중요합니다.

승인 파이프라인은 사고를 "인지할 수 있는 사고"로 만들지만, 절대 금지 목록은 사고를 "일어날 수 없는 사고"로 만듭니다. 둘 다 필요합니다.

실패 3: Zenn 레이트 리밋(Rate Limit)과 "큐 내부의 경합"

세 번째 배움은 외부 플랫폼 측의 제약 사항입니다. Zenn에는 "1일 1콘텐츠"라는 레이트 리밋(Rate Limit)이 있는데, 저는 몇 번인가 여러 기사+서적을 동시에 공개하려다 배포 실패를 일으킨 적이 있습니다.

이는 "승인"만으로는 방지할 수 없습니다. 승인 시점에는 문제가 없어 보여도, 실행 시점에 외부 측의 상태가 제약에 걸리기 때문입니다. 그래서 저는 승인 파이프라인에 **실행 직전 게이트(Gate)**를 추가했습니다.

• 락 파일(Lock file) .locks/zenn-today.lock에 당일 공개일을 기록 - 공개 작업(Job)은 시작 시 락 파일을 체크
• 당일 이미 공개된 상태라면, 자동으로 다음 날로 일정 재조정(Reschedule)
• approval-queue.md의 해당 아이템은 "예약됨(Reserved)" 상태로 유지

즉 "승인 → 즉시 실행"이 아니라 "승인 → 실행 가능성 체크 → 실행 또는 일정 재조정"의 3단계 구조입니다. 유사한 메커니즘을 SNS(여러 프로덕트 게시물의 시간차 게시), KDP(연속 게시로 인한 bot 판정 회피), 이메일 발송(거래처별 최종 발송일 체크)에도 적용하고 있습니다.

여기서 제가 자주 스스로에게 되뇌는 말은 "자동화는 'AI의 능력을 제한하기 위한 것'이 아니라, '안심하고 위임하기 위한 메커니즘'이다"라는 문장입니다. 레이트 리밋 대책은 제한이 아니라, AI가 장기적으로 일할 수 있도록 환경을 정비하는 것입니다.

실패 4: 가짜 문의와 검증(Validation) 계층

승인 파이프라인의 또 다른 역할은 들어오는 액션의 필터링입니다. 문의 양식에 존재하지 않는 이메일 주소, 가짜 전화번호, 무관한 내용의 테스트 게시물이 흘러 들어오던 시기가 있었습니다.

AI 에이전트는 그것을 성실하게 "중요 리드(Lead)"로 취급하여 영업 플로우(Flow)에 태웠습니다. 여기서 제가 도입한 것은 승인 파이프라인의 입구 측 검증(Validation)입니다.

• 전화번호 자릿수 및 앞자리 체크
• 이메일의 MX 레코드(MX Record) 확인 체크
• 내용과 문의 양식 문맥 간의 관련성 점수
• 점수가 임계값 미만일 경우 "보류 큐(Pending Queue)"로 격리 후 CEO에게 알림만 전송

승인 파이프라인은 출구(대외 액션)뿐만 아니라, 입구(대외 인풋)에도 필요했습니다. "AI에게 자유롭게 판단하게 해도 되는 범위"를 좁게 유지하는 것이 결과적으로 자동화율을 높입니다.

아침 5분 운영: CEO가 하는 작업은 이것뿐

지금까지의 설계를 운영에 적용하면, 저의 아침은 다음과 같습니다.

• /ai-ceo:morning 을 실행 - 승인 대기 목록, 부문별 상태, KPI 요약, 추천 액션이 출력됨
• 승인 또는 거절을 판단하여 /ai-ceo:approve 또는 /ai-ceo:reject 를 입력 - 완료

평균 5분입니다. "아침 5분 만에 모든 부문을 파악하고 승인 버튼을 누르기만 하면 되는" 상태는 승인 파이프라인이 있기 때문에 성립됩니다. AI는 실행에 사용한다. 판단은 인간이 한다. 이 경계선을 유지하는 메커니즘이 바로 승인 파이프라인입니다.

설계 체크리스트

마지막으로, 이제부터 AI 경영이나 업무 자동화를 시작하려는 분들을 위해 제가 사용하고 있는 체크리스트를 남겨둡니다.

• 액션을 read-only / draft / execute로 분류했는가
• draft 액션의 출력 디렉토리와 명명 규칙을 결정했는가
• 승인 큐 (approval-queue.md 등 단일 장소)가 있는가
• 승인 ID 없이 실행하는 경로가 물리적으로 존재하지 않는가
• 절대 금지 리스트를 deny 설정과 프롬프트 양쪽 모두에 작성했는가
• 실행 직전 게이트 (Rate Limit, 멱등성 (Idempotency) 체크)가 있는가
• 입구 측의 유효성 검사 (Validation)가 있는가
• 거절 사유가 로그에 남고, 에이전트에게 피드백되는가
• 아침 요약 (Digest)에서 승인 대기 상태가 반드시 가시화되는가

이 중 하나라도 누락되면, 제 경험상 어디선가 사고가 발생합니다. 특히 "승인 ID 없이 실행하는 경로가 물리적으로 존재하지 않는가"는 설계 시 반드시 한 번은 코드 경로 (Code Path)를 따라가며 확인하는 것을 추천합니다. "호출 측을 신뢰하는" 설계는 AI 에이전트에게는 성립하지 않습니다.

요약

AI 경영에서 자동화의 본질은 AI에게 무엇이든 시키는 것이 아니라, AI에게 안심하고 위임할 수 있는 경계선을 설계하는 것입니다. 저는 "비용은 10분의 1이 되지만, 매출이 10배가 되는 것은 아니다"라고 생각합니다. 대신, CEO의 시간이 10배가 됩니다. 승인 파이프라인은 그 10배를 지탱하는 토대입니다.

저서에서는 여기서 소개한 승인 파이프라인의 구현 코드와 접근 방식을 포함하여, AI 경영의 운영 전체를 해설하고 있습니다. 괜찮으시다면 확인해 보시기 바랍니다.

• 도서 목록 (Zenn): https://zenn.dev/joinclass?tab=books

끝까지 읽어주셔서 감사합니다. 저희 회사의 다른 기사에서도 AI 경영 현장에서 일어나고 있는 일들을 그대로 공개해 나가겠습니다.

Discussion