자동화를 만들기 전에, AI에게 먼저 반대하게 만들었다 — personas → quality-gate 체인으로 게이트한 PoC

문제

자동화 스크립트를 짜기 직전에 멈췄다. 매일 8시간씩 Claude·Codex와 나눈 대화에서 쓸 만한 인사이트가 그대로 휘발되는 게 아까웠고, ~/.claude/projects/와 ~/.codex/sessions/를 뒤지면 사이트 콘텐츠 후보가 매일 나온다는 걸 알고 있었다. 손으로 정리하면 시간 부담, 안 하면 자산 누락. 그러니 매일 그 transcript를 긁어 글 초안까지 뽑는 파이프라인을 만들면 된다 — 여기까진 30분이면 설계가 끝났다.

문제는 그 다음이었다. 이 파이프라인의 입력은 회사 NDA·credentials가 섞인 내 실제 작업 로그다. "자동 발행"이 한 번이라도 잘못 돌면 유출은 영구적이고 되돌릴 수 없다. 내가 짠 계획이 멀쩡해 보일수록 위험했다 — 만든 사람이 자기 계획의 구멍을 보긴 어려우니까. 그래서 코드를 짜기 전에, AI 워크플로우로 내 계획을 먼저 공격하게 만들기로 했다.

의사결정

설계는 네 갈래로 갈렸다. 트리거를 수동으로 둘지 cron으로 돌릴지, 자동화 수준을 L0(제안만)에서 L3(자동 발행)까지 어디에 둘지, 원본 transcript를 어디서 끌어올지, 보안을 redaction에 맡길지 사람 검토에 맡길지. 혼자 표를 그리니 적을수록 시야가 한쪽으로 쏠렸다 — 편의를 적으면 유출을 잊고, 유출을 적으면 빠른 PoC라는 원래 목적을 잊었다.

그래서 두 단계 AI 체인을 걸었다. 먼저 personas로 네 시야를 바깥에 만들었다. 시니어 자동화 SWE, 법무, 콘텐츠 전략가, 그리고 운영 부담을 직접 지는 본인 — 네 페르소나를 각각 별도 Agent로 스폰해 같은 설계안을 두고 토론시켰다. 답이 갈리는 지점이 그대로 쟁점이 됐다.

SWE는 자동 트리거를 밀면서도 숨은 복잡성을 짚었다 — Codex transcript 정규화가 생각보다 무겁다.
법무는 한 축에서 단호했다. "L3 자동화 + 자동 redaction은 one-way door다. 한 번 새면 끝이니 절대 금지." 내가 편의를 보던 자리에서 그는 출구 없는 문을 봤다.
콘텐츠 전략가는 자동화의 정의를 다시 잡았다. "글을 더 쓰게 하는 도구가 아니라, 쓸 만한 순간을 놓치지 않게 하는 알람이다."
**운영 사용자(본인)**는 외부 페르소나가 못 본 걸 짚었다. 가장 두려운 건 기능 실패가 아니라 회사 정보 유출 단 1건, 그리고 이런 루틴의 내 **지속률이 35%**라는 사실. 거창하게 만들면 안 돌린다.

그 다음 quality-gate에 내 PLAN을 직접 통과시켰다. 6축 rubric 평균은 2.5/5, FAIL. 보안 관련 두 항목이 BLOCKING으로 걸렸고, 법무 페르소나의 판정은 "현 PLAN으로 publish 진행 절대 금지"였다. 내가 만든 계획을, 내가 세운 게이트가 막아세운 것이다.

여기서 멈추지 않고 게이트의 피드백을 설계에 되먹였다. 막힌 이유는 하나의 PoC가 "빠른 시연"과 "안전한 운영"을 동시에 만족하려 했기 때문이다. 그래서 범위를 둘로 쪼갰다 — v1은 publish를 원천 차단한 1회 시연 dry-run, v2는 4주 dry-run에 2주 publish를 더한 보수적 운영본으로. 시연용 v1만 다시 게이트에 넣으니 4.33/5 PASS. 같은 아이디어인데, 야망의 크기를 게이트가 통과시킬 만큼 줄여 살린 셈이다.

산출물

게이트를 통과한 v1을 실제로 한 번 돌렸다. 그날 transcript에서 콘텐츠 후보 2개(Log + Note)가 뽑혔고, 둘 다 손볼 가치가 있어 정식 글로 promote했다 — 파이프라인이 헛것이 아니라는 증거다.

v1 시연: .cache/daily/2026-05-19.mdx (publish는 코드 차원에서 차단)
추출된 콘텐츠 후보 2개 — 둘 다 정식 promote
SESSION.md — v2 작업자(미래의 나)에게 넘길 인계 컨텍스트
scripts/daily-log/ 베이스 디렉토리 + README

임팩트

이 PoC가 내게 남긴 건 코드가 아니라 일하는 방식이었다.

숫자가 거버넌스 비용을 드러냈다. 자동화 본 코딩은 1주면 되는데 보안 검증 dry-run에 4주가 필요했다 — 1:4. "만드는 비용"보다 "안전하게 운영할 비용"이 네 배 크다는 걸 착수 전에 알게 되니, L3 자동 발행을 향한 욕심을 일찌감치 접을 수 있었다.
AI 게이트가 내 야망을 조정했다. 한 PoC로 빠른 시연과 안전한 운영을 동시에 노린 욕심이 FAIL의 원인이었고, 범위를 v1/v2로 쪼개자 통과했다. 게이트 점수가 설계를 되먹임한, 사람 검토 없이 도는 결정론적 루프였다.
가장 위험한 BLOCKING은 본인 페르소나에서 나왔다. 외부 페르소나는 기능 위험을 봤지만, 운영자인 나만 "지속률 35%"를 봤다 — 안 돌리는 자동화는 0점이라는, 외부 리뷰어가 절대 못 짚을 리스크.

다음 보강

v2로 넘어갈 때 SESSION.md에 남겨둔 작업은 셋이다. Claude·Codex transcript를 한 형식으로 맞추는 Source Adapter, 법무 페르소나가 요구한 보안 게이트 구현, 그리고 4주 dry-run을 돌리며 "유출을 놓치는 비율(false negative)"을 실측하는 일. v1을 게이트로 막아 살린 그 판단을, v2에선 숫자로 검증할 차례다.

나는 자동화를 짜기 전에 그 자동화를 가장 잘 반대할 AI 팀을 먼저 소집하고, 그들이 내린 FAIL을 설계 수정의 입력으로 되먹이는 식으로 일한다 — 만든 사람의 사각지대를, 워크플로우로 메운다.