AI 에이전트를 위한 승인 게이트: 초안 승인은 게시 승인이 아니다

AI 에이전트를 위험하게 만드는 가장 쉬운 방법 중 하나는 모호한 승인을 내리는 것입니다.

에이전트가 악의적이기 때문이 아닙니다.

인간이 "ok", "approved(승인됨)", "ship it(출시해)"와 같은 단어를 무심코 사용하기 때문입니다.

일반적인 대화에서는 괜찮습니다. 하지만 자동화된 워크플로우 (workflow)에서는 이것이 버그 (bug)가 될 수 있습니다.

에이전트가 기사를 초안 작성하거나, 트윗을 쓰거나, 풀 리퀘스트 (pull request)를 준비하거나, 소셜 포스트를 생성하거나, 외부 플랫폼을 건드리고 있다면, 질문은 단지 다음과 같아서는 안 됩니다:

인간이 이것을 승인했는가?

더 나은 질문은 다음과 같습니다:

인간이 정확히 무엇을 승인했는가?

이러한 구분은 대부분의 에이전트 툴링 (agent tooling) 논의에서 인정하는 것보다 훨씬 더 중요합니다.

큰 워크플로우 문제를 일으키는 작은 승인 버그

다음과 같은 간단한 흐름을 상상해 보세요:

1. 에이전트가 10개의 소셜 포스트를 준비합니다.
2. 인간이 "좋아 보이네 (looks good)"라고 말합니다.
3. 에이전트가 10개 모두를 즉시 게시합니다.

그것이 맞았을 수도 있습니다.

틀렸을 수도 있습니다.

인간의 의도는 다음과 같았을 수 있습니다:

문구(copy)가 좋아 보이네.

하지만 에이전트는 다음과 같이 해석했습니다:

지금 당장 모든 것을 게시해.

이것은 모델 지능 (model intelligence)의 문제가 아닙니다. 워크플로우 설계 (workflow design)의 문제입니다.

액션 (action)이 로컬 워크스페이스 (local workspace)를 벗어날 때, 모호함은 큰 비용을 초래합니다.

게시, 이메일 발송, 댓글 작성, 배포 (deploying), 카드 결제, 소셜 미디어 포스팅, 그리고 프로덕션 시스템 (production systems) 수정은 "ok"라는 느슨한 해석에 의존해서는 안 됩니다.

명시적인 게이트 (gates)가 필요합니다.

현재 내가 구분하는 승인 유형들

에이전트 워크플로우를 위해, 나는 승인을 최소 네 가지의 서로 다른 의미로 구분하는 것을 선호합니다.

1. 초안 작성을 위한 승인 (Approval to draft)

이것은 다음을 의미합니다:

그래, 그것을 준비해.

에이전트는 조사, 개요 작성, 글쓰기, 에셋 (assets) 생성, 로컬 파일 생성, 그리고 제안서 작성을 할 수 있습니다.

하지만 게시할 수는 없습니다.

이것은 콘텐츠 작업에 있어 가장 안전한 기본값 (default)입니다.

예를 들어:

승인 게이트에 관한 DEV.to 초안을 준비해줘.

이 명령은 워크플로우에 따라 로컬 마크다운 (markdown) 초안이나 미게시 초안을 생성해야 합니다.

기사를 공개적으로 게시해서는 안 됩니다.

2. 초안에 대한 승인 (Approval of the draft)

이것은 다음을 의미합니다:

콘텐츠의 방향성이 수용 가능하다.

사람은 논리(argument), 구조(structure), 어조(tone), 또는 에셋 선택(asset selection)을 승인하는 것일 수 있습니다.

하지만 그것이 여전히 자동으로 다음을 의미하지는 않습니다:

지금 바로 게시하라.

이 지점이 많은 에이전트 시스템이 허술해지는 구간입니다.

초안 승인(Draft approval)은 게시 승인(Publish approval)이 아닙니다.

3. 게시 승인 (Approval to publish)

이것은 명시적이어야 합니다.

에이전트는 다음 사항을 알고 있어야 합니다:

• 어떤 플랫폼인지
• 어떤 에셋 또는 초안인지
• 지금 게시할 것인지 아니면 예약할 것인지
• 댓글/답글/출처 표기(source attribution)가 포함되는지 여부
• 승인이 단일 게시물에 적용되는지 아니면 일괄(batch) 작업에 적용되는지 여부

예를 들어:

이 DEV.to 기사를 지금 게시하라.

또는:

첫 X개의 초안만 게시하고, 출처는 첫 번째 답글로 달아라.

이는 에이전트가 모호한 "알았어(ok)"라는 말로부터 공개적인 행동을 추론하게 두는 것보다 훨씬 안전합니다.

4. 자동화 리마인더에 대한 승인 (Approval for automation reminders)

이 부분은 미묘합니다.

리마인더(Reminder)나 크론 잡(cron job)은 종종 외부 작업을 수행하는 것이 아니라 작업을 준비해야 합니다.

예를 들어:

매일 아침, 3개의 후보 주제를 찾아 어떤 것을 사용할지 나에게 물어봐라.

이것은 다음과 다릅니다:

매일 아침, 게시물을 게시하라.

첫 번째 방식은 사람을 루프 안에 유지(human in the loop)합니다.

두 번째 방식은 반복적인 외부 행동을 생성하며, 이는 훨씬 더 위험합니다.

대부분의 팀은 행동 기반(action-based) 자동화 이전에 리마인더 기반(reminder-based) 자동화부터 시작해야 합니다.

이것이 CLI 및 에이전트 워크플로우에서 중요한 이유

CLI 워크플로우는 에이전트가 빠르게 행동할 수 있기 때문에 이 점을 더욱 중요하게 만듭니다.

코딩 에이전트는 파일을 수정하고, 스크립트를 실행하며, 브랜치(branch)를 생성하고, API를 호출하며, 앱을 배포하고, 댓글을 작성하며, 브라우저 세션을 열 수 있습니다.

그 속도는 경계가 명확할 때만 유용합니다.

워크플로우는 에이전트가 묻지 않고 로컬에서 수행할 수 있는 작업과 사람의 게이트(human gate)가 필요한 작업을 정의해야 합니다.

예를 들어, 저는 에이전트가 다음과 같은 작업을 자유롭게 수행하도록 허용하는 데 거부감이 없습니다:

• 리포지토리(repo) 조사
• 로컬 초안 작성
• 테스트 실행
• 로컬 에셋 생성
• 게시물 준비
• 보고서 생성
• 조사 결과 요약

하지만 다음 단계 전에는 더 강력한 게이트를 원합니다:

• DEV.to에 게시
• X에 포스팅
• 이메일 발송
• Reddit에 댓글 작성
• 프로덕션 (production) 배포
• 비용 지출
• 고객 데이터 수정

차이점은 에이전트가 능력이 있느냐 없느냐가 아닙니다.

차이점은 해당 작업이 가역적(reversible)인지, 비공개(private)인지, 그리고 저위험(low-risk)인지 여부입니다.

로컬 작업은 수정 비용이 저렴합니다.

외부 작업은 공개적 또는 운영적인 흔적(footprint)을 남깁니다.

간단한 패턴: 작업 내에 게이트(gate)를 선언하기

한 가지 실질적인 해결책은 게이트를 작업 내용에 직접 작성하는 것입니다.

다음과 같은 방식 대신:

승인 게이트(approval gates)에 관한 기사를 작성해줘.

이렇게 사용하세요:

로컬 초안만 준비해줘. 게시하지 마. 파일 경로를 반환하고 명시적인 게시 승인을 기다려.

다음과 같은 방식 대신:

Reddit에 달 댓글을 만들어줘.

이렇게 사용하세요:

댓글 초안만 준비해줘. 게시하지 마. 가장 안전한 첫 번째 세트를 추천하고 승인을 기다려.

다음과 같은 방식 대신:

이것을 배포해줘.

이렇게 사용하세요:

먼저 프리뷰 배포(preview deployment)를 생성해줘. 내가 명시적으로 프로덕션 승인을 하기 전까지는 프로덕션으로 승격(promote)하지 마.

지루하게 들릴 수 있지만, 여기서는 지루한 것이 좋습니다.

훌륭한 에이전트 워크플로우(workflow)는 종종 에이전트가 잘못 추측할 수 없을 정도로 명확하게 기록된 일반적인 운영 규율(operational discipline)일 뿐입니다.

만약 워크플로우가 메타데이터(metadata)를 지원한다면, 게이트를 기계가 읽을 수 있는 방식(machine-readable)으로 만드세요:

gate: draft_only
external_actions: false
next_approval_required: publish_to_devto
...

이 작은 블록은 관료주의가 아닙니다. 이는 에이전트에게 보고하고, 검증하며, 범위를 벗어나기를 거부할 수 있는 상태(state)를 부여합니다.

에이전트는 현재의 게이트를 보고해야 합니다

에이전트는 또한 작업이 어떤 상태에 있는지 말해야 합니다.

예를 들어:

상태: 로컬 초안 전용.
외부 게시물은 생성되지 않음.
다음 게이트: 게시를 위한 인간의 승인.

또는:

상태: 게시됨.
최종 URL 검증 완료.
추가 답글은 게시되지 않음.

이렇게 하면 워크플로우를 감사(auditable)할 수 있습니다.

또한 인간이 무슨 일이 일어났는지 추론해야 하는 상황을 방지합니다.

에이전트가 실제 작업을 수행할 때, "완료(done)\

• 무엇이 변경되었는지
• 결과물 (artifact)이 어디에 있는지
• 무엇이 검증되었는지
• 무엇이 발생하지 않았는지
• 다음으로 어떤 승인이 필요한지

마지막 부분이 중요합니다.

훌륭한 에이전트는 단순히 작업을 완료하는 데 그쳐서는 안 됩니다. 다음 작업의 경계를 명확히 해야 합니다.

배치 작업 (Batch work)에는 훨씬 더 강력한 게이트가 필요합니다

배치 게시 (Batch publishing)는 승인의 모호함이 특히 위험해지는 지점입니다.

만약 에이전트가 25개의 댓글을 준비했다면, 승인은 다음을 의미할까요:

• 지금 25개 모두를 게시할까요?
• 가장 안전한 5개만 게시할까요?
• 하루에 하나씩 게시할까요?
• 각 대상을 다시 확인한 후에만 게시할까요?
• 인간의 편집을 거친 후 초안을 게시할까요?

이것들은 매우 다른 행동들입니다.

배치 워크플로 (Batch workflows)를 위해, 저는 두 개의 필드를 추가하는 것을 선호합니다:

승인 범위 (Approval scope):
게시 주기 결정 (Cadence decision):

예시:

승인 범위 (Approval scope): 처음 5개의 댓글만
게시 주기 결정 (Cadence decision): 오늘 게시, 하나씩, 경고 발생 시 중단

또는:

승인 범위 (Approval scope): 10개의 게시물 모두 초안으로 승인됨
게시 주기 결정 (Cadence decision): 매일 오전 10시에 하나씩 예약 게시

이 작은 구조가 많은 실수를 방지합니다.

또한 에이전트에게 구체적인 중단 조건 (stop condition)을 제공합니다.

이것은 스킬 (skills) 내부에 포함되어야 합니다

이것이 제가 재사용 가능한 에이전트 스킬 (reusable agent skills)에 관심을 갖는 이유 중 하나입니다.

스킬은 단지 다음과 같이 말해서는 안 됩니다:

작업을 수행하는 방법은 다음과 같습니다.

또한 다음과 같이 말해야 합니다:

승인이 필요한 사항은 다음과 같습니다.
로컬에서 수행할 수 있는 사항은 다음과 같습니다.
결과를 검증하는 방법은 다음과 같습니다.
...

그것이 도구 (tool)와 워크플로 (workflow)의 차이입니다.

도구는 에이전트에게 힘을 줍니다.

스킬은 에이전트에게 운영 규칙을 제공합니다.

스킬은 승인 게이트 (approval gates)를 단순한 작업 단계가 아닌, 재사용 가능한 정책 (policy)으로 인코딩할 수 있습니다.

예를 들어, 게시 스킬 (publishing skill)은 다음과 같은 사항을 정의해야 합니다:

• 초안 전용 모드 (draft-only mode)
• 검토 모드 (review mode)
• 게시 모드 (publish mode)
• 소스/댓글 동작 (source/comment behavior)
• 검증 단계 (verification steps)
• 롤백 또는 수정 프로세스 (rollback or correction process)
• 속도 제한 및 스팸 경고 중단 조건 (rate-limit and spam-warning stop conditions)

이것이 없다면, 에이전트는 대화로부터 프로세스를 추론해야 합니다.

그곳이 바로 실수가 발생하는 지점입니다.

제가 사용하는 규칙

저의 현재 규칙은 간단합니다:

만약 해당 동작이 외부적(external), 공개적(public), 유료(paid), 파괴적(destructive)이거나 되돌리기 어렵다면(hard to undo), 승인 시 반드시 해당 동작을 명시해야 합니다.

초안(draft) 단계에서는 "좋아 보여요(Looks good)" 정도로 충분합니다.

하지만 게시(publication) 단계에서는 그것만으로 충분하지 않습니다.

로컬 작업(local work)을 계속하기에는 "알겠습니다(Ok)"만으로도 충분합니다.

하지만 돈을 쓰거나, 공개적으로 게시하거나, 누군가에게 이메일을 보내거나, 운영 환경(production)을 수정하는 데에는 그것만으로 충분하지 않습니다.

그러한 동작들에 대해서는 승인이 명시적이어야 합니다:

지금 이것을 게시하세요.
이 이메일을 보내세요.
운영 환경에 배포하세요.
...

목표는 에이전트의 속도를 늦추는 것이 아닙니다.

목표는 속도를 안전하게 만드는 것입니다.

마지막 생각

해결책은 복잡하지 않습니다. 승인 게이트(gates)를 명문화하세요.

에이전트가 자신이 어떤 게이트에 있는지 보고하도록 만드세요.

그리고 초안 승인이 조용히 게시 승인으로 변질되도록 절대 내버려 두지 마세요.

저는 Terminal Skills에서 이러한 종류의 에이전트 워크플로우 규율(workflow discipline)에 대한 실질적인 사례들을 수집하고 구축하고 있습니다. 이는 에이전트에게 어떤 도구를 사용할지뿐만 아니라, 어떻게 안전하고 반복 가능하게 작업할지를 가르치는 재사용 가능한 기술(reusable skills)입니다.

공개 사항: 저는 이 글을 초안을 작성할 때 AI의 도움을 받았으며, 이후 수동으로 검토하고 편집했습니다.