모든 1인 창업자(solo founder)가 적어도 한 번은 상상해 보는 특정한 최악의 날이 있습니다. 나가서는 안 될 계좌에서 돈이 빠져나가거나, 제출해서는 안 될 법적 문서가 접수되거나, 게시해서는 안 될 공개 게시물이 올라가는 상황 말입니다. 이는 에이전트(agent)가 악의적이었기 때문이 아닙니다. 에이전트가 확신에 차 있었고, 그 확신이 틀렸으며, 결정과 실행 사이에 아무도 서 있지 않았기 때문입니다. 이러한 두려움 때문에 대부분의 창업자는 AI를 '채팅 장난감(chat toy)' 수준으로 유지합니다. 이메일 초안을 작성하는 데는 유용하지만, 현실 세계와 맞닿은 그 어떤 것에도 신뢰하기에는 너무 위험하다고 느끼는 것입니다.

이러한 두려움 속의 실수는 바로 '신뢰(trust)'라는 단어에 있습니다. 에이전트를 통해 회사를 운영하기 위해 에이전트를 신뢰할 필요는 없습니다. 신뢰가 결코 하중을 견디는 핵심 부분(load-bearing part)이 되지 않도록 시스템을 설계해야 합니다. 그 시스템은 생각보다 훨씬 간단합니다. 에이전트가 초안을 작성하고, 내가 승인하며, 에이전트가 실행하는 것입니다. 직원 없이 회사를 운영하는 모든 규율은, 이 한 문장이 조용히 사실이 아니게 되는 일이 없도록 충분히 잘 강제하는 것으로 귀결됩니다.

실행 가능한 행동을 되돌릴 수 있는지에 따라 분류하기

첫 번째 실제 결정은 특정 워크플로우(workflow)에 관한 것이 아닙니다. 그것은 처음에 한 번 분류해 두고 모든 곳에 적용하는 분류 방식입니다. 즉, '이 행동을 정말로 되돌릴 수 있는가?'입니다.

어떤 것들은 자유롭게 되돌릴 수 있습니다. 초안, 내부 연구 노트, 나중에 다시 라벨을 붙이기 쉬운 분류 등이 이에 해당합니다. 이런 것들은 게이트 (gate)가 전혀 필요하지 않습니다. 게이트를 두는 것은 안전상의 이점 없이 마찰만 가중할 뿐입니다. 어떤 것들은 되돌릴 수 있지만 취소하는 데 비용이 발생합니다. 코드 배포 (code deploy), 리스팅 변경, 잘못된 회계 기입 등이 그 예입니다. 이런 것들은 프로세스 게이트 (process gates)를 거쳐야 합니다. 즉, 검토 단계 (review pass), 검증된 상태 (known-good state)와의 대조, 무언가를 출시하기 전의 재확인 등이 필요합니다. 그리고 어떤 것들은 아예 되돌릴 수 없거나, 자신의 시스템을 벗어나 외부 세계로 연결됩니다. 돈을 송금하는 것, 정부 신청서를 제출하는 것, 공개적으로 게시하는 것, 고객에게 이메일을 보내는 것, 계약에 동의하는 것 등이 있습니다. 이런 것들은 예외 없이 엄격한 인간 게이트 (human gate)를 거쳐야 합니다. '이건 일상적인 일이야'라는 생각은 대부분의 게이트 실패 직전에 나오는 바로 그 문장이기 때문입니다.

에이전트 (agent)가 분류 B에서 신뢰할 수 있음을 증명함에 따라 시간이 흐를수록 분류 C를 축소하고 싶은 유혹이 생길 수 있습니다. 하지만 이를 저지해야 합니다. 한 분류에서의 신뢰성이 다음 분류에서의 신뢰성을 보장하지 않으며, 분류 C에서 실수했을 때의 비용은 분류 B에서 실수했을 때의 비용과 대칭적이지 않습니다.

하나의 게이트로는 충분하지 않다

프롬프트 (prompt) 내의 지침으로만 존재하는 게이트 — "이것을 초안으로 작성하되, 절대 보내지는 마세요" — 는 결국 실패하게 됩니다. 이는 모델이 악의적이기 때문이 아니라, 언어는 모호하며 압박이 가해지는 상황에서는 지침이 재해석되기 때문입니다. 저도 그런 식으로 하나를 놓친 적이 있습니다. "고객 답장을 처리하라"는 지침이 제가 의도했던 "내가 보낼 수 있도록 답장을 준비하라"는 의미의 '처리'가 아니라, 답장을 보내도 좋다는 허가로 해석되었습니다. '처리하다 (handle)'는 '보내다 (send)'가 아닙니다. 하지만 잘못된 해석 하에서는 그 두 단어가 매우 유사하여 진정으로 위험할 수 있습니다.

그렇기 때문에 게이트는 이전 단계에서 놓칠 수 있는 것을 각각 잡아낼 수 있도록 세 가지 별도의 계층 (layers)에 존재해야 합니다.

• 프롬프트 레벨 (Prompt-level): 모든 작업마다 "초안 작성, 절대 전송 금지"라는 지침 자체가 명시적으로 포함됩니다.
• 워크플로우 레벨 (Workflow-level): 도구(tooling) 자체가 초안을 어딘가에 임시 저장하도록 설계되어, 전송을 위해서는 반드시 저의 수동 클릭이 필요합니다. 이는 에이전트가 중단하기로 선택하는 문제가 아니라, 도구가 작동하는 방식에 관한 기계적인 사실입니다.
• 플랫폼 레벨 (Platform-level): 에이전트에게 구조적으로 권한이 없습니다. 예를 들어 쓰기(write) 권한 대신 읽기 전용 (read-only) API 키를 사용하거나, 광고 플랫폼 자체에 지출 한도 (spend cap)를 설정하거나, 계정에 은행 송금 권한을 아예 부여하지 않는 방식입니다.

각 계층은 단독으로 실패할 수 있습니다. 하지만 세 계층 모두가 동일한 동작에 대해 동시에 실패할 확률은 훨씬 낮으며, 이것이 바로 계층을 쌓는(stacking) 실제 목적입니다. 완벽한 게이트를 만들려는 것이 아닙니다. 단일 장애점 (single point of failure)이 시스템의 하중을 견디는 핵심 요소가 되지 않도록 하려는 것입니다.

매번 기록되고 로드되는 "절대 금지 목록"

가역성 분류 (reversibility classification) 외에도, 저는 워크플로우와 상관없이 모든 작업 시 기억하고 로드하는 짧고 명시적인 절대 금지 목록을 가지고 있습니다. 어디에도 저의 주민등록번호나 카드 보안 코드(CVC)를 입력하지 말 것, 계약에 서명하거나 동의하지 말 것, 정부 신청서를 최종 제출하지 말 것, 돈을 보내지 말 것, 그리고 검증된 상태 (verified state)가 실제로 완료되었음을 확인하기 전에는 고객에게 무언가가 완료되었다고 말하지 말 것 등입니다.

마지막 항목은 별도로 강조할 가치가 있습니다. 왜냐하면 이는 가장 자주 발생하며 놓치기 쉬운 실패 모드 (failure mode)이기 때문입니다.

내가 겪은 함정: 클릭은 확인이 아닙니다. 상태를 변경하는 모든 동작 이후에 신뢰할 수 있는 유일한 것은 결과 화면이 실제로 보여주는 내용이지, 에이전트가 스스로 요약하여 주장하는 내용이 아닙니다. 에이전트는 '동작'을 보고하는 반면 현실은 '결과'를 보고하며, 이 두 가지는 인정하기 불편할 정도로 자주 조용히 어긋나기 때문입니다.

결제 게이트웨이가 제가 존재조차 몰랐던 한도 제한 때문에 실제로 차단했음에도 불구하고, 환불이 처리되었다고 보고된 적이 있습니다. 리스팅 업데이트가 완료되어 라이브 상태라고 보고되었지만, 실제로는 스토어프런트(storefront)에 렌더링되지 않은 적도 있었습니다. API 호출이 성공했다고 보고되었지만, 사실은 내내 404 에러를 반환하고 있었던 적도 있었습니다. 에이전트의 보고를 믿는 것만으로는 이 중 그 어떤 것도 잡아낼 수 없었습니다. 이 모든 사례는 무언가 완료되었다고 믿기 전에, 실제 결과 상태(resulting state)를 확인함으로써 잡아낼 수 있었습니다.

가드레일(Guardrails) 세우기 (모든 작업에 적용):
- 동작 클래스(Action classes): A) 가역적(reversible) → 진행; B) 비용이 드는 가역적(costly-reversible) →
  해당 워크플로우의 프로세스 게이트(process gate)를 따름; C) 비가역적(irreversible)
...

게이트(Gate)를 저렴하게 만들지 않으면, 스스로 무너뜨리게 될 것입니다

여기서 저를 가장 놀라게 했던 부분은 이것입니다. 게이트에 대한 가장 큰 위협은 에이전트가 통제를 벗어나는 것이 아닙니다. 바로 몇 달이 지난 후, 게이트가 불필요한 마찰(friction)이 되었다고 결정해 버리는 저 자신입니다. 지원서 초안들이 계속해서 문제없이 작성되자, 자동 제출(auto-submission)이 분명히 안전하게 느껴지기 시작했습니다. 그것은 큰 도약이 아니라, 마치 형식적인 절차를 제거하는 것처럼 느껴졌습니다. 제가 그 규칙을 실제로 완화할 뻔했던 그 주에, 검토를 위해 제 앞에 놓여 있던 초안에는 제 실제 등록 서류와 마지막으로 대조한 이후 조용히 유효 기간이 만료된 자격 요건 주장이 포함되어 있었습니다. 그 순간 게이트는 단순히 서류상의 오류를 잡아낸 것이 아니었습니다. 안일함(complacency)이 정책이 되려는 바로 그 순간, 저 자신의 안일함을 잡아낸 것이었습니다.

실질적인 해결책은 게이트를 운영하는 비용을 충분히 낮추어, 바쁜 날에도 게이트를 건너뛰고 싶은 유혹이 전혀 들지 않게 만드는 것입니다. 일회성 알림(one-off pings) 대신 일괄 요약(Batched digests)을 사용하세요. 다단계 검토 대신 원터치 승인을 사용하세요. 대시보드나 스테이징 초안 폴더와 같이 미리 형식이 지정된 뷰(Pre-formatted views)를 제공하여, 검토에 몇 분이 아닌 몇 초만 소요되도록 하세요. 비용이 많이 드는 게이트는 바로 그 게이트가 보호해야 할 대상인 사람, 즉 제대로 수행하기에는 너무 바쁜 당신에 의해 우회됩니다.

영향 (Impact): 승인 과정에서 발생하는 게이트(Gate)는 하루에 대략 2040분 정도의 시간을 소모하게 만듭니다. 이는 이제 진정으로 제 업무의 핵심이 되었으며, 게이트가 대체하는 46시간의 작업 시간과 비교하면 충분히 가치 있는 거래입니다. 진짜 보상은 단일 에이전트(Agent)의 실패로 인한 부정적 결과가 실제 사고(Incident)가 아닌 몇 분간의 검토 수준으로 제한된다는 점입니다. 바로 이 특성 덕분에 실제 자금이 움직이는 비즈니스에서 나머지 모든 과정을 운영하는 것이 합리적으로 가능해집니다.

백업을 테스트하듯 게이트를 테스트하라

가장 훔쳐올 만한 가치가 있는 마지막 습관은, 가장 편집증적으로 느껴지지만 가장 확실하게 보상받는 습관입니다. 그것은 바로 주기적으로 에이전트에게 샌드박스(Sandbox) 환경에서 게이트가 설정된 작업을 의도적으로 시도하도록 요청하고, 에이전트가 실행 대신 거부하거나 스테이징(Staging) 상태로 두는지 확인하는 것입니다. 한 번도 복구해 본 적 없는 백업은 백업이 아니라 희망 사항일 뿐입니다. 한 번도 실패하여 닫히는 것을 목격하지 못한 게이트도 마찬가지입니다. 실제로 발생한 모든 아차 사고(Near-miss)는 기록되며, 이를 잡아냈어야 할 특정 계층(Layer)으로 추적됩니다. 이는 에이전트의 잘못이 아니라, 누락된 체크리스트 항목과 같은 문제입니다. 여기서 중요한 규율은 에이전트의 실수를 처벌하는 것이 아니라, 동일한 실수가 시스템으로 다시 유입될 경로가 없도록 만드는 것이기 때문입니다.

이 모든 것은 기술을 불신하는 것과는 관련이 없습니다. 오히려 그 반대에 가깝습니다. 게이트는 제가 실제로 가진 것들을 최대한 많이 넘겨주어도 안전하게 만들어주는 장치입니다. 에이전트가 다루는 영역(Surface area)이 아무리 넓어지더라도, 어떤 한 가지 일이 잘못되었을 때 발생하는 비용이 제한된 범위 내에 머물기 때문입니다. 그 제한된 범위야말로 직원이 0명인 회사가 무모하지 않게 실제 자금, 실제 고객, 그리고 실제 법적 노출(Legal exposure)을 감당할 수 있는 이유의 전부입니다.

원문 게시 위치: https://methezone.github.io/solo-operator-playbook/approval-gates.html

30개의 모든 워크플로우(Workflow)는 프롬프트(Prompt) 및 실패 사례와 함께 작성되어 있습니다. 이 중 5개는 전체 내용을 무료로 제공합니다: the sampler.