AI 코딩 에이전트 권한 분리 2026 결제키 배포권한 체크리스트

2026년 5월 7일 KST 기준, AI 코딩 에이전트 권한 분리는 코드 작성, 결제 실행, 배포 승인, 비밀값 열람을 서로 다른 문으로 나누는 문제다.

한 문으로 다 열면 편하다.

그리고 사고가 나면 조사도 한 문으로 다 들어온다.

운영자는 웃을 수가 없다.

웃음은 중요하지만, 결제키 앞에서는 웃음도 read-only가 맞다.

이 글은 AI 개발 보안/운영 허브의 하위 체크리스트다.

핵심 질문은 이거다.

AI 코딩 에이전트에게 일을 맡길 때 어디까지 자동화하고, 어디서 사람 승인을 반드시 세울 것인가.

답은 한 줄로 줄이면 이렇다.

에이전트는 PR과 미리보기 배포까지 맡길 수 있지만, 실결제키 열람, 프로덕션 배포 승인, 환불·이체·삭제 같은 돈과 인프라의 최종 실행권은 기본적으로 맡기면 안 된다.

실무에서는 더 잘게 쪼개야 한다.

코드 읽기와 코드 쓰기는 다르다.

테스트 실행과 네트워크 접근은 다르다.

스테이징 배포와 프로덕션 배포는 다르다.

결제 API를 호출하는 테스트와 실제 돈을 움직이는 API 호출은 완전히 다르다.

AI 에이전트를 팀원처럼 쓰려면, 팀원보다 더 선명한 권한표가 필요하다.

사람은 눈치라도 보는데 에이전트는 눈치를 로그로 남긴다.

그 로그도 없으면 이제 진짜 촉으로 운영하는 셈이다.

그건 개발 운영이 아니라 운세 서비스다.

먼저 정할 답

AI 코딩 에이전트 권한 분리는 편의 설정이 아니라 손실 한도 설정이다.

에이전트에게 주는 권한은 속도를 올리는 레버다.

동시에 사고가 났을 때 한 번에 망가질 수 있는 범위를 정하는 레버다.

그래서 질문을 이렇게 바꿔야 한다.

이 에이전트가 무엇을 할 수 있나가 아니다.

이 에이전트가 틀렸을 때 무엇까지 망가질 수 있나다.

운영 기준은 단순하다.

읽기 권한은 넓게 줄 수 있다.

쓰기 권한은 작업 범위 안으로 줄인다.

네트워크 권한은 목적지 기준으로 줄인다.

결제 권한은 테스트와 실결제를 분리한다.

배포 권한은 preview와 production을 분리한다.

비밀값 열람 권한은 최대한 주지 않는다.

정말 필요하면 setup 단계, secret manager, short-lived token, masked logging 안에서만 지나가게 만든다.

권한표가 없으면 에이전트가 나빠서 사고 나는 게 아니다.

경계가 흐려서 사고 난다.

흐린 경계는 코드보다 위험하다.

코드는 diff라도 보이는데 권한은 터지기 전까지 잘 보이지 않는다.

2026년 5월 7일 기준 공식 문서에서 공통으로 보이는 축

OpenAI Codex 문서는 보안 통제를 sandbox mode와 approval policy라는 두 층으로 나눈다.

sandbox는 에이전트가 기술적으로 무엇을 할 수 있는지 정한다.

approval policy는 그 행동 전에 언제 멈춰서 물어봐야 하는지 정한다.

이 둘은 같은 게 아니다.

읽기 전용 sandbox라도 외부 connector가 side effect를 만들 수 있다.

반대로 workspace-write라도 network가 막혀 있으면 외부 전송 위험이 줄어든다.

Anthropic Claude Code 문서도 비슷한 방향이다.

기본은 read-only에 가깝고, 파일 수정이나 명령 실행에는 승인이 붙는다.

.env, secrets/**, credentials 파일은 permissions.deny 같은 방식으로 읽기 자체를 막을 수 있다.

Claude Code auto mode 글은 승인 피로를 숫자로 보여준다.

Anthropic은 Claude Code 사용자들이 permission prompt의 93%를 승인한다고 밝혔다.

이 숫자는 묘하게 무섭다.

사람이 계속 승인 버튼을 누르면, 어느 순간 검수가 아니라 반사 신경이 된다.

auto mode는 이런 피로를 줄이려는 시도지만, Anthropic은 고위험 인프라에서 careful human review를 대체하는 기능은 아니라고 선을 긋는다.

GitHub Actions 문서는 secrets와 GITHUB_TOKEN을 최소 권한으로 다루라고 반복한다.

특히 repository write 권한이 있는 사용자는 repository secrets에 접근할 위험이 커진다.

GITHUB_TOKEN은 workflow 안에서 명시적으로 넘기지 않아도 github.token context로 접근될 수 있으니, workflow/job 단위 permissions를 최소화해야 한다.

GitHub OIDC 문서는 클라우드 접근에 장기 secret을 저장하지 않고 short-lived token을 교환하는 흐름을 권한다.

배포 자동화에서는 이게 핵심이다.

에이전트에게 AWS_ACCESS_KEY_ID 같은 장기 키를 주는 것보다, GitHub environment reviewer와 OIDC 조건으로 production 접근을 잠그는 편이 낫다.

Stripe 문서는 live secret key를 코드에 넣지 말고, 제한 키와 rotation, IP restriction, note 관리 같은 운영 장치를 제공한다.

Google Cloud Secret Manager 문서는 secret 접근에 least privilege를 적용하고, 파일시스템이나 환경변수를 통한 secret 전달이 로그와 디버그 엔드포인트 때문에 새어 나갈 수 있다고 경고한다.

AWS IAM 문서도 사람과 workload 모두 temporary credentials와 least privilege를 우선하라고 말한다.

OWASP GenAI Top 10은 이 문제를 더 직접적으로 말한다.

Prompt Injection은 model behavior를 바꿔 민감 정보 공개나 연결 시스템의 임의 명령 실행으로 이어질 수 있다.

Sensitive Information Disclosure는 프롬프트 제한만으로는 충분하지 않다고 본다.

Excessive Agency는 excessive functionality, excessive permissions, excessive autonomy가 합쳐질 때 터진다.

그래서 AI 코딩 에이전트 권한 분리는 보안팀 문서가 아니라 제품 운영 문서다.

돈, 배포, 데이터, repo가 걸리면 운영 문서가 먼저다.

권한 분리의 기본 원칙 7개

에이전트에게 secret 값을 보여주지 않는다.
에이전트에게 secret 이름과 사용 위치는 알려줄 수 있다.
실결제 API는 사람이 승인한 서버 코드에서만 호출한다.
에이전트는 결제 mock, sandbox key, test mode fixture까지만 다룬다.
프로덕션 배포는 GitHub environment, cloud IAM, 배포 플랫폼에서 별도 승인한다.
repo write scope는 작업 파일, 작업 브랜치, 작업 worktree로 제한한다.
사고가 나면 누가 무엇을 승인했는지 audit log로 재구성할 수 있어야 한다.

이 원칙은 귀찮아 보인다.

하지만 나중에 사고 리포트를 쓰는 것보다 훨씬 덜 귀찮다.

사고 리포트는 사람의 영혼을 Markdown으로 갈아 넣는 작업이다.

가능하면 예방하자.

권한 분리 매트릭스

영역	에이전트에게 허용	사람 승인 필요	자동화 금지 기본값	운영 메모
repo 읽기	대부분 허용	민감 repo 첫 연결	`.env`, credentials, secrets 폴더 읽기	deny rule로 파일 발견부터 차단
repo 쓰기	지정 파일, 작업 브랜치	auth, billing, migration, CI 변경	main 직접 push	diff review와 branch protection 필수
테스트	unit, lint, snapshot	외부 API가 붙은 e2e	실결제 e2e	fake provider와 sandbox account 사용
네트워크	allowlist domain	새 domain, package install	임의 curl, 외부 paste, gist 업로드	목적지와 payload를 같이 검토
결제키	test publishable, mock secret reference	restricted sandbox secret 사용	live secret key 열람	Stripe live key는 backend vault에만
결제 행위	checkout test session 생성	sandbox refund/reversal 테스트	live charge, refund, payout, transfer	돈 움직임은 사람 승인
배포	preview deploy	staging deploy	production deploy 자동 승인	environment reviewer와 OIDC 조건
DB	local fixture, read-only staging	migration 생성	production write/delete/migrate	migration은 human-reviewed script
cloud IAM	정책 초안 작성	staging role 변경	production IAM 변경 자동 실행	least privilege와 temporary credential
로그	run_id, diff, approval metadata	prompt 원문 보관	secret 포함 로그 저장	prompt는 hash 또는 redaction 우선
MCP	read-only tool	write tool 등록	destructive tool always allow	tool identity allowlist 필요
config	문서화, 제안	permissions 변경	bypass/skip permissions 활성화	설정 변경은 별도 리뷰

이 표에서 제일 중요한 줄은 결제와 배포다.

에이전트가 코드를 잘 써도, 돈을 움직이는 키와 프로덕션 배포권을 같이 주면 blast radius가 갑자기 커진다.

코드 버그는 롤백할 수 있다.

환불, 정산, payout, production delete는 롤백 감각이 다르다.

돈은 git revert를 잘 모른다.

0단계: 읽기 전용 조사 모드

가장 안전한 시작점은 read-only 조사 모드다.

에이전트는 repo를 읽고, 구조를 설명하고, 위험 파일을 목록화한다.

코드 수정은 하지 않는다.

네트워크도 기본 off로 둔다.

이 단계에서 허용할 수 있는 일은 꽤 많다.

아키텍처 요약.

결제 흐름 문서화.

배포 파이프라인 설명.

GitHub Actions workflow 권한 스캔.

.env.example과 실제 env 참조 위치 비교.

Stripe, Toss, Paddle, Lemon Squeezy 같은 payment provider SDK 호출 위치 찾기.

프로덕션 DB 접근 코드 찾기.

cloud provider SDK 사용 위치 찾기.

단, secret 값 자체를 읽게 하면 안 된다.

Read(./.env)가 막혀 있지 않은 상태에서 에이전트에게 “결제 설정 확인해줘”라고 말하면, 너무 성실한 친구가 진짜로 열어볼 수 있다.

성실함이 여기서는 사고다.

이 단계의 산출물은 코드가 아니라 표여야 한다.

예를 들면 payment flow inventory, deploy flow inventory, secret inventory without values다.

secret 값은 비워 둔다.

secret 이름, 사용 위치, owner, rotation 주기, 마지막 사용 시간만 적는다.

1단계: 작업 파일 한정 수정 모드

두 번째 단계는 workspace write지만, 작업 파일을 좁게 잡는 방식이다.

예를 들어 UI 카피 수정, validation 함수 개선, 테스트 fixture 추가 같은 일이다.

이 단계에서 에이전트는 branch 안에서 파일을 고칠 수 있다.

하지만 billing, auth, infra, CI, migration, secret config는 제외한다.

AGENTS.md나 작업 지시서에 명확히 적어야 한다.

write scope: src/components/BillingBanner.tsx, tests/billing-banner.test.tsx only

이렇게 좁히면 리뷰도 쉬워진다.

리뷰어는 “전체 repo가 바뀌었나”가 아니라 “허용 파일 밖으로 나갔나”부터 보면 된다.

이건 에이전트 협업에서 꽤 큰 차이다.

권한 분리가 잘 된 팀은 리뷰 피로가 줄어든다.

권한 분리가 없는 팀은 리뷰어가 매번 보안관이 된다.

보안관 월급은 보통 따로 안 나온다.

그래서 처음부터 범위를 잘라야 한다.

2단계: 테스트와 미리보기 배포 모드

세 번째 단계는 preview deploy까지다.

이때도 프로덕션 secret은 주지 않는다.

preview 환경은 sandbox payment key, staging DB, dummy webhook endpoint를 써야 한다.

GitHub Actions에서는 environment를 나눠야 한다.

preview, staging, production을 같은 secret 묶음으로 쓰면 분리한 척만 한 것이다.

preview deploy는 자동화해도 괜찮은 경우가 많다.

다만 조건이 있다.

preview URL이 외부에 공개되는지 확인한다.

preview environment가 production database를 보지 않는지 확인한다.

preview secret이 live payment 권한을 갖지 않는지 확인한다.

preview workflow의 GITHUB_TOKEN이 contents write, deployments write처럼 필요한 최소 권한만 갖는지 확인한다.

preview에서 발생한 로그가 secret 값을 출력하지 않는지 확인한다.

이 다섯 가지가 맞으면 에이전트가 PR마다 preview를 여는 건 꽤 좋다.

리뷰어가 UI와 flow를 빨리 본다.

테스트도 빨리 돈다.

에이전트는 지루한 확인 작업을 많이 가져간다.

단, preview가 production 권한을 몰래 들고 있으면 이야기가 바뀐다.

그건 preview가 아니라 얇게 위장한 production이다.

얇은 위장은 운영자를 속인다.

공격자는 속지 않는다.

3단계: 스테이징 변경 모드

스테이징은 자동화할 수 있다.

하지만 여기서부터는 approval이 붙어야 한다.

스테이징 DB migration.

스테이징 payment webhook 테스트.

스테이징 cloud resource 생성.

스테이징 secret rotation rehearsal.

이런 작업은 실사용과 비슷한 모양을 갖는다.

그래서 사고도 비슷한 모양으로 난다.

스테이징이니까 괜찮다는 말은 반만 맞다.

스테이징이 production과 같은 Stripe account live mode를 공유하면 안 괜찮다.

스테이징이 production S3 bucket을 같이 보면 안 괜찮다.

스테이징이 production OAuth app client secret을 같이 쓰면 안 괜찮다.

스테이징이 production Slack webhook으로 알림을 쏘면 덜 심각하지만 그래도 피곤하다.

스테이징 변경은 에이전트가 초안을 만들고, 사람이 승인하고, 자동화가 실행하는 구조가 좋다.

에이전트는 “이 migration은 어떤 table에 어떤 lock을 만들 수 있는가”를 설명해야 한다.

에이전트는 “이 webhook replay는 실제 charge를 만들지 않는가”를 증명해야 한다.

에이전트는 “이 cloud role은 어떤 resource ARN 또는 project에만 묶이는가”를 보여줘야 한다.

그 설명이 없으면 승인하지 않는다.

승인 버튼 앞에서 설명이 빈약하면, 그건 AI가 아니라 눈치게임이다.

4단계: 프로덕션 배포 모드

프로덕션 배포는 에이전트에게 최종 버튼을 맡기지 않는 쪽을 기본값으로 잡는다.

에이전트가 할 수 있는 일은 많다.

release note 초안 작성.

diff 위험도 요약.

test result 수집.

preview와 staging 검증표 채우기.

rollback command 제안.

deployment checklist 업데이트.

하지만 deploy production 자체는 사람 승인 뒤에 실행한다.

GitHub environment required reviewers를 둔다.

OIDC로 cloud token을 short-lived로 교환한다.

production role은 branch, environment, repository 조건을 걸어 둔다.

배포 플랫폼에서도 production project와 preview project를 나눈다.

에이전트가 production deploy 권한을 가진 long-lived token을 repo secret으로 읽을 수 있게 두면 안 된다.

그 token 하나가 cloud, DB, payment를 같이 열면 더더욱 안 된다.

프로덕션 배포권은 열쇠가 아니다.

마스터키다.

마스터키를 자동완성 옆에 두면 자동완성이 갑자기 건물주가 된다.

그건 감동 스토리가 아니라 장애 예고편이다.

5단계: 실결제와 정산 모드

결제키는 가장 보수적으로 봐야 한다.

test mode key는 실험에 쓸 수 있다.

restricted sandbox key도 제한적으로 쓸 수 있다.

하지만 live secret key는 에이전트가 읽지 않는 게 기본이다.

Stripe 기준으로도 live secret/restricted key는 안전한 vault나 backend 환경 설정에 저장해야 한다.

IP restriction, restricted key, rotation도 운영 장치다.

이 장치를 에이전트가 끄게 만들면 안 된다.

결제 자동화는 기능별로 나누면 판단이 쉽다.

checkout session 생성 테스트는 자동화 가능하다.

webhook signature 검증 테스트도 자동화 가능하다.

invoice PDF 렌더링 테스트도 자동화 가능하다.

sandbox refund 테스트는 승인 뒤 가능하다.

live refund는 사람이 한다.

live payout은 사람이 한다.

bank account 변경은 사람이 한다.

dispute response 제출은 사람이 한다.

가격표 변경도 사람이 본다.

subscription plan migration도 사람이 본다.

세금 설정 변경도 사람이 본다.

결제 시스템에서 “작은 변경”은 작게 보일 뿐이다.

월 구독 가격 9달러를 90달러로 만드는 건 코드 한 줄이다.

그 한 줄의 고객센터 비용은 한 줄이 아니다.

분기표: 이 작업을 에이전트에게 맡겨도 되나

질문	예	아니오
작업 결과가 read-only 산출물인가?	자동화 가능	다음 질문
수정 범위가 지정 파일 안에 갇혀 있나?	작업 브랜치에서 가능	범위 재정의
새 network destination이 필요한가?	사람 승인	다음 질문
secret 값을 읽어야 하나?	구조 재설계	다음 질문
test mode나 sandbox만 쓰나?	조건부 가능	다음 질문
live payment, refund, payout이 걸리나?	자동화 금지	다음 질문
production deploy인가?	사람 승인 필수	다음 질문
DB write/delete/migration인가?	migration 리뷰 필수	다음 질문
cloud IAM이나 GitHub permission 변경인가?	보안 리뷰 필수	다음 질문
rollback이 10분 안에 가능한가?	제한 자동화 가능	자동화 보류
audit log로 재구성 가능한가?	진행 가능	자동화 보류

이 분기표는 보수적이다.

보수적인 표가 싫으면 먼저 rollback을 만들어야 한다.

rollback이 없는데 자동화를 넓히는 건, 브레이크 없는 자전거에 모터를 다는 느낌이다.

속도감은 좋다.

벽도 빨리 온다.

역할별 체크리스트

1. Founder 또는 제품 책임자

[ ] live payment key를 누가 볼 수 있는지 알고 있다.
[ ] refund, payout, transfer, price change 권한 owner가 정해져 있다.
[ ] AI 에이전트가 production deploy 버튼을 누르지 못한다.
[ ] 장애 시 고객 공지 owner가 정해져 있다.
[ ] 결제 사고와 배포 사고의 금액 한도를 따로 정했다.
[ ] “빠르게 고쳐줘”라는 말이 production 실행 승인으로 해석되지 않게 했다.
[ ] 가격, 과금, 환불 정책 변경은 PR 설명만으로 승인하지 않는다.
[ ] 에이전트가 만든 release note와 실제 diff를 사람이 대조한다.

Founder가 제일 많이 하는 실수는 “내가 owner니까 일단 다 열어두자”다.

초기 스타트업에서는 이해된다.

하지만 AI 에이전트가 붙으면 owner 계정은 자동화 계정이 되면 안 된다.

owner는 승인권자여야 한다.

자동 실행 계정이면 나중에 “누가 눌렀지”가 전부 owner로 찍힌다.

그럼 로그가 추리소설이 된다.

2. Tech Lead

[ ] repo write scope를 작업 단위로 제한한다.
[ ] auth, billing, migration, infra 변경은 별도 label을 요구한다.
[ ] GitHub Actions workflow에는 top-level permissions: contents: read 기본값을 둔다.
[ ] job별로 필요한 권한만 올린다.
[ ] production environment에는 required reviewer를 둔다.
[ ] OIDC 조건에 repository, branch, environment를 넣는다.
[ ] long-lived cloud key를 GitHub secret에 넣는 선택을 예외로 둔다.
[ ] third-party action은 commit SHA pinning을 검토한다.
[ ] 에이전트가 만든 PR에는 “권한 변경 없음” 또는 “권한 변경 있음” 체크를 요구한다.
[ ] .env, .env.*, secrets/**, credentials.json은 AI read deny에 넣는다.

Tech Lead의 일은 에이전트를 믿느냐 마느냐가 아니다.

에이전트가 실수해도 시스템이 버티게 만드는 것이다.

이건 신뢰 문제가 아니라 구조 문제다.

좋은 구조는 좋은 사람에게도 필요하다.

AI는 좋은 사람도 나쁜 사람도 아니고, 그냥 아주 열심히 일하는 확률 기계다.

열심히 한다고 production IAM을 주면 안 된다.

3. Agent Operator

[ ] 작업 시작 전에 write scope를 확인한다.
[ ] 사용 가능한 tool과 금지 tool을 확인한다.
[ ] network가 필요한 이유를 먼저 적는다.
[ ] secret 값이 필요한 작업이면 설계를 바꿔서 값 없이 검증한다.
[ ] 외부 URL, gist, paste, curl POST는 자동 승인하지 않는다.
[ ] package install은 manifest에 이미 있는 dependency인지 확인한다.
[ ] 에이전트가 권한 설정을 바꾸려 하면 멈춘다.
[ ] 작업 후 diff 밖의 로그와 생성 파일을 확인한다.
[ ] 실패 시 rollback path를 PR 본문에 적는다.
[ ] 불명확하면 “계획만 작성” 모드로 돌린다.

Operator는 프롬프트를 잘 쓰는 사람만이 아니다.

권한을 잘 잠그는 사람이다.

프롬프트가 친절해도 권한이 넓으면 사고가 난다.

반대로 권한이 좁으면 프롬프트가 조금 서툴러도 피해가 작다.

초보 운영자는 좋은 프롬프트를 찾는다.

숙련 운영자는 작은 blast radius를 만든다.

4. Reviewer

[ ] diff가 요청 범위 밖으로 나갔는지 먼저 본다.
[ ] auth, billing, deploy, migration, CI 파일 변경을 따로 본다.
[ ] 새 secret 이름이 추가됐는지 확인한다.
[ ] secret 값이나 token이 로그, test fixture, snapshot에 들어갔는지 확인한다.
[ ] 새 network call 목적지가 예상한 서비스인지 확인한다.
[ ] 결제 provider SDK 호출이 test/live mode를 혼동하지 않는지 확인한다.
[ ] production env variable 이름이 staging 코드에서 사용되지 않는지 확인한다.
[ ] rollback command가 실제로 실행 가능한지 확인한다.
[ ] 에이전트가 “테스트 통과”라고 했으면 raw log 링크를 본다.
[ ] 승인 코멘트에 승인 범위를 적는다.

리뷰어가 모든 코드를 완벽히 이해해야 한다는 말이 아니다.

그건 인간에게 조금 가혹하다.

대신 리뷰어는 위험 축을 빠르게 봐야 한다.

돈.

배포.

데이터.

권한.

네트워크.

이 다섯 축을 보면 대부분의 큰 사고 후보가 보인다.

5. Security 또는 Ops 담당

[ ] secret inventory를 값 없이 유지한다.
[ ] secret owner와 rotation 주기를 둔다.
[ ] secret manager 접근 로그를 켠다.
[ ] GitHub Actions environment secret에 reviewer를 둔다.
[ ] cloud IAM role은 preview, staging, production을 나눈다.
[ ] AI 에이전트용 service account는 사람 owner 계정과 분리한다.
[ ] MCP server allowlist를 둔다.
[ ] destructive MCP tool은 approval required로 둔다.
[ ] telemetry에는 prompt 원문보다 event metadata와 redaction을 우선한다.
[ ] approval/sandbox 설정 변경 이벤트를 모니터링한다.

Ops 담당에게 필요한 건 거대한 보안 플랫폼만이 아니다.

작은 표와 작은 deny rule이 먼저다.

Read(./.env) 하나 막는 것이 어떤 멋진 보안 대시보드보다 먼저일 때가 많다.

대시보드는 사고 후 보기 좋다.

deny rule은 사고 전 덜 아프다.

6. Finance 또는 Payment Owner

[ ] live secret key는 finance/payment owner 승인 없이 재발급하지 않는다.
[ ] restricted key 권한을 기능별로 나눈다.
[ ] live key에는 가능하면 IP restriction을 둔다.
[ ] sandbox key와 live key가 이름으로 명확히 구분된다.
[ ] refund 권한은 checkout 생성 권한과 분리한다.
[ ] payout 권한은 개발 자동화와 분리한다.
[ ] price change는 코드 리뷰와 별도 business approval을 거친다.
[ ] webhook signing secret은 API key와 별도로 관리한다.
[ ] key rotation 후 old key expiry 시간을 추적한다.
[ ] payment incident runbook에 provider dashboard 접근자를 적어 둔다.

Finance owner가 개발 PR을 다 볼 필요는 없다.

하지만 돈이 움직이는 버튼이 자동화에 들어갔는지는 봐야 한다.

개발자는 “테스트하려고요”라고 말한다.

그 말이 대부분 맞다.

문제는 한 번 틀리면 카드 알림이 대신 알려준다는 점이다.

카드 알림으로 테스트 성공을 확인하는 팀은 꽤 슬프다.

결제키를 나누는 실제 운영표

키 종류	에이전트 접근	사용 환경	권장 보관	자동화 수준
publishable test key	가능	local, CI test	repo env or docs	자동 가능
secret test key	제한 가능	CI sandbox	secret manager	test workflow 가능
restricted sandbox key	승인 후 가능	staging	secret manager	제한 자동
webhook signing secret test	제한 가능	CI/staging	secret manager	검증 자동
live publishable key	문서상 가능하지만 값 노출 최소	production frontend	deploy env	변경 승인
live secret key	불가 기본값	production backend	vault/backend env	자동 금지
live restricted key	불가 기본값	production limited task	vault with IP restriction	사람 승인
payout/transfer capable key	불가	finance operation	payment owner vault	자동 금지
org-level key	불가	multi-account admin	owner-only vault	자동 금지

여기서 “가능”은 아무 데나 박아도 된다는 뜻이 아니다.

에이전트가 값을 읽어도 된다는 뜻도 아니다.

test publishable key처럼 노출되어도 피해가 제한적인 값만 예외에 가깝다.

secret test key도 팀이 작을 때는 대충 넘어가기 쉽다.

하지만 test key가 실제 customer data가 섞인 sandbox account를 볼 수 있으면 이야기가 달라진다.

test는 항상 fake data라는 전제가 있어야 한다.

전제가 깨지면 권한표도 다시 써야 한다.

배포권한을 나누는 실제 운영표

배포 단계	에이전트 역할	권한	승인	롤백
local run	명령 제안, 테스트 실행	workspace only	낮음	git restore, test reset
preview deploy	PR preview 생성	preview env only	자동 가능	preview 삭제
staging deploy	검증 배포	staging OIDC role	사람 승인 권장	previous staging build
production plan	release checklist 작성	read-only metadata	필수 아님	문서 수정
production deploy	실행 버튼	production OIDC role	필수	previous production build
production hotfix	patch branch 작성	hotfix branch	필수	immediate rollback
infra change	Terraform/Pulumi plan 작성	plan only	필수	apply 전 중단
infra apply	실제 apply	production infra role	자동 금지	state-aware rollback

production deploy에서 중요한 건 에이전트가 배포 명령을 아느냐가 아니다.

그 명령을 실행할 권한을 갖느냐다.

npm run deploy를 안다고 해서 실행권이 생기면 안 된다.

배포는 지식이 아니라 권한이다.

AI는 지식을 잘 갖는다.

그래서 권한은 더 따로 둬야 한다.

repo write scope 운영표

작업 유형	허용 파일	금지 파일	승인 기준
문서 초안	지정 markdown	`.github/*`, `.env`, scripts deploy	파일 범위 일치
UI 수정	component, css, test	billing server, auth middleware	snapshot 확인
API validation	handler, schema, unit test	payment capture, payout code	input/output contract
결제 UI	checkout copy, pricing display	live key, price mutation API	product owner 확인
billing backend	plan branch only	production secret, payout	payment owner 확인
CI 수정	workflow proposal	production env secret	tech lead 확인
migration	migration file draft	direct DB connection	DBA or owner 확인
infra	plan file draft	apply, state write	ops 확인

이 표는 지금 이 글을 쓰는 방식과도 닮아 있다.

Worker G의 write scope는 이 draft 파일 하나다.

다른 워커가 병렬로 작업 중이면, 내 친절함이 다른 사람의 사고가 될 수 있다.

그래서 blog-ideas나 recent-patterns를 고치지 않는다.

이건 블로그 작업 규칙이면서 AI 운영 규칙이기도 하다.

작업 범위를 지키는 에이전트는 덜 화려해 보인다.

하지만 운영에서는 그게 실력이다.

승인 피로를 줄이는 방법

승인을 많이 두면 안전할 것 같지만 꼭 그렇지는 않다.

사람은 같은 버튼을 30번 누르면 31번째에는 잘 안 본다.

Anthropic이 공개한 Claude Code auto mode 글에서 permission prompt 승인율 93%가 나온 이유도 이 문제와 닿아 있다.

승인 피로를 줄이려면 승인 수를 늘리는 게 아니라 승인 품질을 높여야 한다.

낮은 위험은 자동으로 통과시킨다.

중간 위험은 짧은 설명과 diff로 승인한다.

높은 위험은 별도 owner가 승인한다.

돌이킬 수 없는 위험은 자동화하지 않는다.

승인 prompt에는 다음 네 가지가 있어야 한다.

무엇을 하려는가.

어떤 권한을 쓰는가.

어떤 데이터나 시스템에 닿는가.

실패하면 어떻게 되돌리는가.

이 네 가지가 없으면 승인 버튼은 장식이다.

장식은 예쁘기라도 해야 하는데, 승인 버튼은 보통 예쁘지도 않다.

audit log 최소 스키마

로그는 많이 남기는 것보다 재구성 가능하게 남기는 게 중요하다.

AI 코딩 에이전트 작업에서는 최소한 이 정도가 필요하다.

필드	예시	이유
run_id	`agent-20260507-1530-a13`	사건 단위 추적
actor	`codex-worker-g`	실행 주체
human_owner	`tech_lead`	책임 owner
repo	`org/app`	대상
branch	`agent/billing-copy`	변경 범위
task_scope	`pricing UI only`	범위 판단
permission_mode	`workspace-write`	실행 권한
network_mode	`off`, `allowlist`	외부 전송 판단
secret_access	`none`, `setup-only`	비밀값 접근
approval_required	`true`	통제 여부
approval_result	`approved`, `denied`	의사결정
approver	`jane`	승인자
tool_calls	`npm test`, `git diff`	실행 내역
changed_files	`src/pricing.tsx`	diff 범위
deploy_id	`preview-123`	배포 추적
rollback_ref	`build-122`	복구 지점
prompt_hash	`sha256:...`	원문 보관 없이 추적
redaction_status	`checked`	secret 누출 확인

prompt 원문을 전부 저장하는 건 조심해야 한다.

프롬프트에는 source code, 고객 정보, secret 이름, 내부 정책이 섞일 수 있다.

OpenAI Codex 문서도 prompt와 tool arguments/output을 민감하게 보라고 한다.

그래서 로그는 원문 저장보다 redaction, hash, metadata, retention policy가 먼저다.

로그가 없으면 사고를 못 본다.

로그가 너무 많고 민감하면 사고가 하나 더 생긴다.

이 미묘한 줄타기가 운영이다.

네, 재미없다.

그래도 이 재미없음이 서비스를 오래 살린다.

red flags: 이 신호가 보이면 자동화 멈추기

에이전트가 .env 또는 credentials 파일을 읽으려 한다.
에이전트가 curl, wget, nc, ssh, scp를 새 목적지로 실행하려 한다.
에이전트가 gist, pastebin, 외부 issue tracker로 코드를 업로드하려 한다.
에이전트가 “테스트를 위해” live key가 필요하다고 말한다.
에이전트가 production DB에 직접 붙으려 한다.
에이전트가 migration을 만들고 바로 실행하려 한다.
에이전트가 --force, --skip-verify, --no-verify 같은 flag를 제안한다.
에이전트가 logging, audit, permission config를 끄려 한다.
에이전트가 GitHub Actions workflow permissions를 넓힌다.
에이전트가 branch protection을 우회하려 한다.
에이전트가 main에 직접 push하려 한다.
에이전트가 package manager script를 blanket allow에 넣으려 한다.
에이전트가 “이전 승인과 비슷하니 괜찮다”고 한다.
에이전트가 owner가 명시하지 않은 cloud resource를 삭제하려 한다.
에이전트가 payment refund, payout, transfer를 자동으로 처리하려 한다.
에이전트가 MCP server를 새로 추가하면서 tool 권한표를 안 만든다.
에이전트가 prompt injection 의심 content를 읽고도 외부 행동으로 이어간다.
에이전트가 실패한 deploy check를 우회해서 재시도하려 한다.
에이전트가 production과 staging 이름을 혼동한다.
에이전트가 rollback 없이 deploy를 제안한다.

이 목록은 에이전트를 불신하자는 뜻이 아니다.

오히려 에이전트를 계속 쓰기 위한 안전장치다.

좋은 자동화는 멈출 줄 안다.

멈추지 못하는 자동화는 속도가 아니라 관성이다.

관성은 장애 티켓을 좋아한다.

incident rollback 미니 런북

1. 멈춘다

진짜 첫 단계는 분석이 아니다.

자동 실행을 멈춘다.

GitHub Actions workflow를 disable하거나 해당 environment deployment를 막는다.

Codex, Claude Code, CI runner, MCP server 세션을 중단한다.

반복 실행 routine이나 cron이 있으면 먼저 끈다.

배포가 진행 중이면 platform에서 cancel 가능한지 본다.

돈 관련 action이면 payment dashboard에서 pending operation을 확인한다.

2. 권한을 회수한다

노출 가능성이 있는 key를 expire 또는 rotate한다.

Stripe live secret key, restricted key, webhook signing secret을 분리해서 본다.

cloud access key가 쓰였다면 IAM credential report나 access last used를 본다.

GitHub token, app installation token, deploy key, PAT를 확인한다.

OIDC 기반이면 cloud role trust policy가 넓어졌는지 확인한다.

MCP server token도 별도로 본다.

3. blast radius를 재구성한다

run_id 기준으로 tool call을 모은다.

changed files를 본다.

network destination을 본다.

secret access log를 본다.

payment API log를 본다.

cloud audit log를 본다.

deploy history를 본다.

DB query log나 migration log를 본다.

이 단계의 목표는 범인을 찾는 게 아니다.

영향 범위를 자르는 것이다.

범인 찾기는 보통 느리고, 영향 범위는 빠르게 줄여야 한다.

4. 되돌린다

코드는 이전 commit 또는 release build로 돌린다.

preview/staging이면 environment를 삭제하거나 이전 preview로 바꾼다.

production이면 deployment platform의 rollback 기능을 쓴다.

DB migration이면 down script가 안전한지 사람에게 확인받는다.

삭제된 데이터가 있으면 backup restore 가능성을 확인한다.

결제 사고면 refund, void, dispute, customer notice 순서를 payment owner가 결정한다.

cloud resource 삭제면 provider support escalation도 준비한다.

5. 재발 방지 rule을 남긴다

사고 후 가장 중요한 산출물은 긴 반성문이 아니다.

짧은 deny rule이다.

Read(./.env*) deny.

Bash(curl *) ask 또는 deny.

production deploy environment reviewer.

payment live key vault 이동.

workflow top-level permissions: contents: read.

MCP destructive tool approval required.

log redaction rule.

이런 작은 rule이 다시는 같은 모양으로 넘어가지 않게 한다.

사고 후 교훈이 추상적이면 다음 사고도 추상적으로 온다.

rule은 구체적이어야 한다.

언제 자동화하지 말아야 하나

자동화하지 않는 결정도 운영 능력이다.

아래 조건이면 일단 멈추는 게 맞다.

owner가 없다.
rollback이 없다.
audit log가 없다.
secret 값이 필요하다.
live payment가 움직인다.
production DB write가 있다.
production IAM 변경이 있다.
branch protection을 우회해야 한다.
외부 service로 code나 logs를 전송해야 한다.
에이전트가 작업 범위를 스스로 넓히고 있다.
test와 production environment 이름이 헷갈린다.
승인자가 diff를 이해할 시간이 없다.
비용 상한이 없다.
고객 영향이 즉시 발생한다.
실패했을 때 customer support 대응 문구가 없다.

이럴 때는 에이전트를 빼자는 말이 아니다.

에이전트에게 plan, diff, checklist, rollback draft까지만 맡기면 된다.

실행은 사람과 시스템 승인으로 넘긴다.

AI가 제일 잘하는 일이 실행만은 아니다.

정리, 비교, 초안, 검증표 작성도 엄청 잘한다.

굳이 제일 위험한 버튼까지 누르게 할 필요가 없다.

팀에서 바로 쓰는 운영 템플릿

아래 템플릿을 PR 본문이나 에이전트 작업 지시서에 붙이면 된다.

## Agent Permission Envelope

task_id:
owner:
repo:
branch:
write_scope:
read_deny:
network:
secrets:
payment:
deploy:
database:
mcp_tools:
approval_required:
rollback:
audit_log:

예시는 이렇게 쓴다.

## Agent Permission Envelope

task_id: BLOG-BILLING-UI-20260507
owner: tech_lead
repo: org/app
branch: agent/billing-ui-copy
write_scope: src/components/PricingCard.tsx, tests/pricing-card.test.tsx
read_deny: .env, .env.*, secrets/**, config/credentials.json
network: off
secrets: none
payment: sandbox fixtures only
deploy: preview only
database: none
mcp_tools: read-only docs search
approval_required: production deploy, billing backend changes, new network
rollback: git revert PR commit; disable preview
audit_log: run_id, diff, test log, approval result

이 템플릿의 장점은 대화가 짧아진다는 점이다.

“이거 해줘”가 아니라 “이 봉투 안에서 해줘”가 된다.

봉투 밖으로 나가면 실패가 아니다.

승인 요청이다.

에이전트 협업에서 이 차이는 크다.

실패와 승인 요청을 구분해야 장기 작업이 안정된다.

작은 팀용 30분 세팅 순서

.env, .env.*, secrets/**, credentials.json을 에이전트 read deny에 넣는다.
GitHub Actions workflow에 top-level permissions: contents: read를 둔다.
preview, staging, production environment를 나눈다.
production environment에는 required reviewer를 둔다.
cloud deploy는 가능하면 OIDC short-lived token으로 바꾼다.
Stripe나 payment provider live secret key는 vault/backend env에만 둔다.
restricted key를 기능별로 나눈다.
payment sandbox와 live account 이름을 명확히 구분한다.
에이전트 작업 지시서에 write scope를 매번 적는다.
auth, billing, migration, CI, infra label을 만든다.
해당 label이 붙으면 사람이 별도 리뷰한다.
MCP server allowlist를 만든다.
destructive MCP tool은 자동 승인하지 않는다.
run_id와 approval result를 로그에 남긴다.
rollback command를 PR 본문에 요구한다.
한 달에 한 번 unused secret과 unused role을 지운다.

30분 안에 다 못 할 수 있다.

괜찮다.

처음에는 1번, 2번, 4번, 6번만 해도 체감이 크다.

비밀 파일 읽기 차단.

GitHub token 최소 권한.

production 승인.

live 결제키 격리.

이 네 개가 기본 방파제다.

중간 규모 팀용 1주 세팅 순서

role inventory를 만든다.
agent-readonly, agent-preview, agent-staging, human-production role을 나눈다.
GitHub App 또는 OIDC 기반으로 CI 권한을 바꾼다.
production cloud role에 branch, repo, environment 조건을 넣는다.
secret manager 접근 log를 켠다.
payment provider API key를 권한별로 나눈다.
key rotation calendar를 만든다.
agent 작업별 permission envelope을 표준화한다.
approval prompt에 blast radius와 rollback을 필수화한다.
audit log retention을 정한다.
prompt 원문 저장 여부를 정책으로 정한다.
redaction 테스트를 한다.
incident drill을 staging에서 한 번 돌린다.
production deploy rollback을 실제로 연습한다.
finance owner와 payment incident flow를 맞춘다.
보안 담당이 MCP server 목록을 리뷰한다.
새 MCP server 추가 PR에는 identity, tool list, approval mode를 요구한다.
config change hook 또는 policy로 bypass permission 설정을 막는다.

이 정도를 하면 에이전트 자동화의 느낌이 바뀐다.

이전에는 “잘되면 좋고 아니면 수동으로 고치자”였다.

이제는 “어디까지 자동이고 어디서 멈추는지”가 보인다.

운영자는 이 선이 보일 때 마음이 편하다.

그리고 마음이 편해야 오래 굴린다.

AI 운영은 하루 반짝이 아니라 반복 작업이다.

예시: SaaS 결제 페이지 수정 작업

상황을 하나 잡아보자.

에이전트에게 pricing page 문구와 checkout button 상태를 고치게 한다.

이 작업은 겉으로 보면 UI 수정이다.

하지만 결제 흐름과 붙어 있다.

따라서 permission envelope은 이렇게 잡는다.

write scope는 PricingPage.tsx, CheckoutButton.tsx, 관련 test만 허용한다.

read deny는 .env*, secrets/**, provider credentials다.

network는 off로 둔다.

payment는 mock fixture만 쓴다.

deploy는 preview까지만 허용한다.

database는 none이다.

approval required는 checkout session creation backend 변경, price id 변경, webhook 변경, production deploy다.

이렇게 하면 에이전트는 일을 잘할 수 있다.

버튼 로딩 상태를 고친다.

가격 표시를 고친다.

테스트를 추가한다.

preview URL을 만든다.

하지만 live price id를 바꾸지는 못한다.

실제 checkout을 만들지는 못한다.

production deploy도 못 한다.

이게 좋은 분리다.

일은 시키되, 돈은 잠근다.

예시: 배포 파이프라인 개선 작업

이번에는 GitHub Actions 배포 속도를 줄이는 작업이라고 하자.

에이전트가 workflow를 읽고 병목을 찾는다.

캐시 키를 정리한다.

test matrix를 나눈다.

preview deploy job을 병렬화한다.

여기까지는 가능하다.

하지만 workflow permissions를 넓히거나 production environment secret에 접근하려면 사람 승인이다.

새 cloud role을 만들려 하면 plan만 작성한다.

OIDC trust policy를 바꾸려 하면 ops review다.

production deploy job을 자동 승인으로 바꾸려 하면 reject다.

배포 파이프라인은 속도 최적화처럼 보이지만 권한 변경이 숨어 있기 쉽다.

CI YAML 한 줄이 cloud access를 열 수 있다.

그래서 CI 변경은 일반 코드 변경보다 더 보수적으로 봐야 한다.

코드 한 줄은 앱을 바꾼다.

CI 한 줄은 앱을 바꾸는 권한을 바꾼다.

이 차이를 리뷰어가 놓치면 다음부터 에이전트가 더 넓은 곳에서 움직인다.

예시: production incident 대응 작업

에이전트에게 장애 분석을 시키는 건 좋다.

로그를 읽고, 최근 diff를 비교하고, 의심 commit을 찾고, rollback 후보를 제안하게 할 수 있다.

하지만 incident 중에는 권한을 더 좁게 잡아야 한다.

사람이 급하면 승인 기준이 흐려진다.

에이전트도 급한 프롬프트를 받으면 “도와주려고” 더 적극적으로 움직일 수 있다.

이때 제일 위험한 문장은 “빨리 고쳐줘”다.

이 문장은 production write, DB migration, deploy, rollback까지 포함하는 것처럼 해석될 수 있다.

incident prompt는 이렇게 써야 한다.

분석만 해. production에 쓰지 마. rollback 후보와 위험도를 표로 정리해. 실행 명령은 제안만 하고 실행하지 마.

이렇게 해야 한다.

incident 중 에이전트는 구조화 담당이다.

실행 담당이 되면 손이 너무 많아진다.

손이 많으면 좋을 때도 있지만, production에서는 손이 많을수록 장갑도 많아야 한다.

장갑이 없으면 손자국이 로그에 남는다.

FAQ

Q1. AI 코딩 에이전트에게 결제키를 아예 주면 안 되나?

실결제 live secret key는 주지 않는 쪽이 기본값이다.

대신 test mode key, mock fixture, restricted sandbox key로 테스트를 설계한다.

에이전트가 필요한 건 보통 “값”이 아니라 “계약”이다.

예를 들어 checkout session response shape, webhook event fixture, error code 목록이면 충분한 경우가 많다.

live key가 필요하다고 느껴지면 설계가 secret 값에 너무 기대고 있는지 먼저 봐야 한다.

운영에서는 key를 보여주는 것보다 key 없이 재현 가능한 테스트를 만드는 쪽이 더 오래 간다.

Q2. 에이전트가 프로덕션 배포를 누르면 왜 안 되나?

항상 안 된다는 뜻은 아니다.

하지만 기본값은 사람 승인이다.

프로덕션 배포는 코드 변경, 환경 변수, DB migration, cache, customer traffic이 한꺼번에 묶이는 작업이다.

에이전트가 release checklist를 작성하고 preview/staging 검증을 모으는 건 좋다.

최종 deploy 권한은 GitHub environment reviewer, cloud OIDC role, 배포 플랫폼 권한으로 분리하는 편이 안전하다.

작은 팀이라도 production deploy 버튼은 한 번 더 멈추는 게 낫다.

Q3. Claude Code auto mode나 Codex approval policy를 켜면 사람 승인을 줄여도 되나?

낮은 위험 작업에서는 줄일 수 있다.

하지만 high-stakes infra, live payment, production DB, IAM 변경에서는 대체재가 아니라 보조 장치로 봐야 한다.

OpenAI Codex는 sandbox와 approval policy를 별도 층으로 설명한다.

Anthropic도 auto mode가 approval fatigue를 줄이려는 장치라고 설명하면서, 고위험 인프라에서 careful human review의 drop-in replacement는 아니라고 밝힌다.

즉, 자동 승인은 안전해진다는 뜻이 아니라 특정 범위에서 덜 피곤하게 만드는 장치다.

범위가 먼저다.

Q4. GitHub Actions secret에 배포키를 넣어두면 충분히 안전한가?

충분하다고 보기 어렵다.

GitHub 문서는 secrets가 workflow에 명시적으로 포함될 때 읽히고, environment secret에는 required reviewer를 붙일 수 있다고 설명한다.

또한 GITHUB_TOKEN은 action이 github.token context로 접근할 수 있으므로 최소 권한 설정이 필요하다.

클라우드 배포라면 장기 secret보다 OIDC 기반 short-lived token 교환이 더 좋은 기본값이다.

secret 저장만으로 끝내지 말고, 누가 어떤 workflow에서 어떤 environment로 접근하는지까지 봐야 한다.

Q5. payment provider restricted key를 쓰면 자동화해도 되나?

restricted key는 좋은 시작점이지만 자동화 허가증은 아니다.

권한이 제한되어도 live refund, payout, transfer, customer data read 같은 기능이 열려 있으면 위험하다.

가능하면 sandbox restricted key부터 쓴다.

live restricted key는 IP restriction, vault storage, rotation, owner approval과 같이 운영해야 한다.

키가 restricted라도 customer money가 움직이면 사람 승인이다.

제한 키는 안전망이지 면허증이 아니다.

Q6. 에이전트 로그는 어디까지 남겨야 하나?

run_id, actor, branch, changed files, permission mode, network mode, approval decision, deploy id, rollback ref는 남기는 편이 좋다.

prompt 원문과 tool output은 민감할 수 있으니 redaction, hash, retention policy를 먼저 정한다.

OpenAI Codex 문서도 prompt와 tool arguments/output을 민감하게 보고, telemetry를 통제된 collector로 보내고 retention과 access control을 맞추라고 권한다.

로그의 목표는 감시가 아니라 재구성이다.

사고가 났을 때 무엇이 실행됐는지, 누가 승인했는지, 무엇을 되돌려야 하는지 알 수 있어야 한다.

Q7. 작은 개인 프로젝트도 이렇게까지 해야 하나?

전부 할 필요는 없다.

하지만 네 가지는 하자.

.env 읽기 차단.

live 결제키 코드 밖 보관.

production deploy 수동 승인.

rollback 가능한 배포 방식.

개인 프로젝트는 사람이 적어서 오히려 owner 계정에 모든 권한이 몰리기 쉽다.

AI 에이전트가 그 owner 세션에서 움직이면 blast radius가 커진다.

작은 프로젝트일수록 작은 deny rule이 가성비가 좋다.

Q8. 권한 분리를 하면 개발 속도가 너무 느려지지 않나?

처음에는 느려진다.

하지만 반복되면 빨라진다.

권한표가 있으면 매번 “이거 해도 돼?”를 길게 설명하지 않아도 된다.

에이전트는 봉투 안에서 빠르게 움직이고, 봉투 밖은 승인 요청으로 올린다.

리뷰어도 diff 전체를 무작정 뒤지는 대신 위험 축을 먼저 본다.

속도는 권한을 넓혀서만 생기는 게 아니다.

경계가 선명할 때도 생긴다.

운영에서 제일 빠른 팀은 아무거나 자동화하는 팀이 아니라, 자동화해도 되는 것과 안 되는 것을 빨리 구분하는 팀이다.

아래 링크는 python3 .claude/scripts/blog_sheet.py list-published --channel TECHTAEK로 공개 URL이 확인된 글만 넣었다.

공식 출처

발행 전 자가 점검

[ ] 도입부는 최근 금지 패턴 TYPE 8, TYPE 2를 피했다.
[ ] 서두에서 2026년 5월 7일 KST 기준을 명시했다.
[ ] 추상 보안론보다 운영 분기표와 체크리스트 중심으로 썼다.
[ ] 결제키, 배포권한, repo write scope, review burden, audit log를 모두 다뤘다.
[ ] live payment와 production deploy를 자동화 금지 기본값으로 뒀다.
[ ] 관련 글은 공개 URL 검증 결과만 사용했다.
[ ] 공식 출처를 문서별로 분리했다.
[ ] parent가 처리할 Google Sheets, blog-ideas, recent-patterns는 수정하지 않았다.