승인 파이프라인은 「안전장치」였어야 했다

나는 1인 기업을 AI 에이전트 군단으로 운영하고 있다. 10개 부문의 AI 에이전트가 기사 작성, 영업, 경리, 출판까지 분담하며 자동화율은 98%에 달한다. 17개의 launchd 작업(job)이 매일 알아서 회사를 돌리고 있다.

이 체제의 심장부가 바로 「승인 파이프라인」이다. AI가 대외 액션(메일 전송, SNS 게시, 청구서 발행 등)을 실행하기 전에 반드시 초안(draft)을 만들어 승인 큐(queue)에 쌓는다. CEO인 내가 승인 버튼을 눌러야만 비로소 실행된다.

왜 이 메커니즘을 만들었는가. 과거에 뼈아픈 경험을 했기 때문이다. 영업 메일을 AI에게 확인 없이 자동 전송하게 했더니, 거래처에 경어 사용이 어색한 메일이 전달되었다. 다른 날에는 AI가 git push --force를 자동 실행하여 브랜치가 삭제되기도 했다. 「AI는 실행에 사용한다. 판단은 인간이 한다.」 —— 이 원칙을 지키기 위해 draft → 승인 → 실행의 파이프라인을 도입했다.

그런데 이 안전장치가 이번에는 나 자신을 무너뜨리러 왔다.

월 300건. 승인 큐가 폭주했다

자동화를 진행할수록 AI가 생성하는 초안(draft)은 늘어난다. SNS 자동 배포는 하루 27건(9개 프로덕트 × 3개 채널), 기사는 매일 3개 채널에 공개되며, 영업 파이프라인도 자동으로 돌아간다. 처음에는 하루 몇 건에 불과했던 승인 대기가 어느샌가 월 300건을 넘어서고 있었다.

아침 다이제스트를 열면 승인 대기 건이 20건씩 나열되어 있다. 1건당 30초씩 확인해도 10분이 걸린다. 게다가 내용을 살펴보면 9할은 「승인 이외의 선택지가 없는」 것들이었다. 템플릿대로의 SNS 게시, 정형화된 기사 공개, 이미 수백 번 승인해 온 패턴의 반복.

이것은 본말전도다. 「아침 5분 만에 모든 부문을 파악하고 승인 버튼만 누르면 되는」 경영을 목표로 했는데, 승인 버튼을 누르는 작업 자체가 병목 현상(bottleneck)이 되었다. 승인이 지체되면 실행도 지체된다. 실제로 홈페이지 리뉴얼 영업에서는 21개 사분의 제안서가 완성되었음에도 불구하고, 승인 대기 상태로 메일 전송이 정체되어 결국 단 한 건도 보내지 못한 채 사업 자체를 폐지했다. 승인 큐는 안전장치인 동시에, 막히면 회사 전체를 멈추게 하는 단일 장애점(single point of failure)이었다.

전건 승인을 그만두기로 한 결단

해결 방향은 두 가지였다.

• 승인을 빠르게 한다 (UI 개선, 알림 최적화)
• 승인을 줄인다 (자동 승인 도입)

나는 2번을 선택했다. 승인을 빠르게 하더라도 건수가 계속 늘어나는 한 끝없는 소모전이 될 것이기 때문이다. 다만 「전부 자동 승인」은 논외다. 경어가 어색한 메일 사건을 반복할 수는 없다.

필요했던 것은 「어디까지를 AI에게 위임하고, 어디서부터 인간이 판단할 것인가」의 경계선을 감각이 아닌 규칙으로서 명문화하는 것이었다.

승인 기준의 자동화 — 3층 모델

내가 도달한 것은 액션을 3개 층으로 분류하는 모델이다.

제1층: read-only (승인 불필요 · 자동 실행)

분석 · 리포트 · 사내 파일 업데이트 등 외부로 영향을 주지 않는 액션. 이것은 애초에 큐에 쌓지 않는다. 당연해 보이지만, 초기에는 「만약을 위해」 리포트 생성까지 승인 대상으로 삼았었다. 만약을 위한 승인은 건수가 늘어나면 전체의 신호를 희석시킨다.

제2층: execute (임계치 내 · 자동 승인)

대외 액션 중 「과거에 동일한 패턴으로 승인 완료」되었으며 「금액 · 영향이 임계치 내」인 것. 구체적으로는,

• 템플릿화된 SNS 게시 (문구 패턴이 승인된 템플릿과 일치)
• 정형화된 기사 공개 (품질 점수가 기준치 이상)
• 월액 ¥5,000 미만의 기존 서비스 결제

이것들은 자동 승인하고 실행 로그(log)만 남긴다. 포인트는 「승인 이력 그 자체를 승인 기준으로 변환하는 것」이다. 내가 과거 100번 승인한 패턴은 101번째에도 승인한다. 그렇다면 그 패턴 자체를 규칙화하면 된다.

제3층: draft (인간의 승인 필수)

• 신규 거래처에 대한 메일 (첫 컨택은 반드시 인간이 확인)
• 금액 임계치를 초과하는 결제 · 청구
• 과거에 승인 패턴이 없는 새로운 종류의 액션
• 파괴적인 조작 (force push, 삭제 계열은 절대 금지 리스트로 즉시 차단)

이 3층 구조화를 통해 월 300건의 승인 대기는 월 30건 전후까지 줄었다. 10분의 1이다. 게다가 남은 30건은 「정말로 나의 판단이 필요한 것」뿐이기에, 1건당 사용할 수 있는 사고 시간은 오히려 늘어났다.

예외 설계 — 자동 승인의 「허점」을 막기

자동 승인을 도입하면 반드시 예외 케이스가 발생한다. 운용하며 알게 된 함정 3가지를 공유한다.

함정 1: 패턴 일치의 위양성 (False Positive)

「템플릿 일치 시 자동 승인」으로 설정했더니, AI가 템플릿을 미묘하게 변형한 게시물도 통과해 버렸다. 대책으로서 일치 판정을 「구조의 일치」가 아닌 「승인된 템플릿 ID + 변수 부분만 교체」로 엄격화했다. AI에게 자유 기술(Free-text)을 맡기는 순간, 그것은 새로운 종류의 액션(Action)으로 간주하여 제3층으로 분류한다.

함정 2: 임계값(Threshold) 경계를 노린 분할

월간 비용 분석을 통해 알게 된 사실인데, 임계값 미만의 결제가 여러 번에 걸쳐 나누어 발생한 적이 있었다. 악의적인 의도는 아니었으나 AI의 최적화 결과였으며, 합산하면 임계값을 초과하는 상황이었다. 대책은 「동일 수신처에 대한 결제는 월간 합산하여 임계값 판정」이다. 임계값은 건당 단위가 아니라 누적치로 보아야 한다.

함정 3: 예외의 예외를 너무 많이 만듦

「이 케이스는 특별하니까」라며 규칙을 계속 추가하다 보면, CLAUDE.md가 1,000행을 넘어 AI가 혼란에 빠졌던 경험이 재현된다. 실제로 승인 규칙도 너무 늘어나서 모순이 생길 뻔했다. 지금은 승인 규칙을 1개 파일로 관리하며 상한선을 정해두고, 분기마다 재고 조사를 한다. 규칙은 더하는 것보다 빼는 것이 더 어렵다. 그렇기에 정기적인 삭제를 시스템화했다.

「위임을 위한 제한」이라는 사고방식

이 경험을 통해 얻은 결론은 다음과 같다.

자동화의 본질은 「AI의 능력을 제한하는 것」이 아니라, 「안심하고 위임하기 위한 메커니즘을 만드는 것」에 있다. 승인 파이프라인을 전수 인간이 체크하도록 했던 초기에는 AI를 신뢰하지 못했다. 하지만 그러면 인간이 병목(Bottleneck)이 되어 자동화의 의미가 사라진다.

그렇다고 전수 자동화를 하면, 경어 사용이 어색한 메일이 다시 날아온다.

정답은 그 중간이 아니라, 「신뢰의 실적을 규칙으로 계속 변환하는 프로세스」였다. 승인 이력이 쌓일수록 자동 승인의 범위가 넓어지고, 새로운 종류의 액션만이 인간에게 도달한다. 회사가 성장하여 액션 건수가 10배가 되어도, 인간의 승인 부하는 늘어나지 않는 구조가 된다.

월 5만 엔의 AI 투자로 회사는 돌아간다. 다만 돌리는 것은 CEO의 판단——그 판단을 「어디에 쓸 것인가」를 설계하는 것이 AI 시대 경영자의 일이라고 생각한다.

요약

• 승인 파이프라인은 안전장치이지만, 전수 승인은 월 300건에서 한계에 도달한다
• 액션을 read-only / execute / draft의 3개 층으로 분류하고, 승인 이력을 규칙화한다
• 예외 설계의 요점: 패턴 일치의 엄격화, 임계값의 누적 판정, 규칙의 정기적인 재고 조사
• 자동 승인은 「AI에 대한 신뢰의 실적」을 메커니즘으로 변환하는 프로세스

내가 AI 에이전트로 1인 기업을 운영하는 시스템의 전체 모습은 Zenn에서 서적으로 공개하고 있습니다. 승인 파이프라인 설계나 부문별 에이전트 구성에 관심이 있는 분들은 꼭 확인해 보시기 바랍니다.

Discussion