6개 Repository AI Native 자동화 실습 05. owner가 판단하기 쉬운 queue 만들기

4편에서는 실패 로그를 바로 고치지 않고, 먼저 사람이 검토할 수 있는 보고서로 바꿔야 한다고 정리했습니다.

그다음에 남은 문제는 자연스럽게 owner의 판단이었습니다.

보고서가 많아지고 queue가 늘어나면 자동화가 좋아지는 것처럼 보입니다. 하지만 owner가 매번 diff, test log, build output, wiki lint 결과, deployment 상태를 직접 해석해야 한다면 그것은 위임이 아닙니다. AI가 일을 한 뒤 사람이 다시 운영 의미를 해석하는 구조가 됩니다.

그래서 5편에서는 Peter Steinberger식 maintainer loop를 그대로 복제하지 않고, 현재 6개 repository 운영 구조에 맞는 decision-ready queue로 줄여 적용한 과정을 정리합니다.

핵심은 간단했습니다.

owner가 raw log가 아니라 다음 선택지를 읽게 만드는 것입니다.

4편 이후 남은 문제는 판단 피로였습니다

실패 로그를 보고서로 바꾸면 상태는 좋아집니다.

실패 command가 무엇인지, 어떤 category인지, 첫 실패 신호가 어디인지, 다음에 무엇을 확인해야 하는지 보이기 때문입니다. 하지만 보고서가 생겼다고 해서 운영이 자동으로 편해지는 것은 아니었습니다.

보고서가 열 개 생기면 owner는 열 개의 보고서를 읽어야 합니다. source map, draft review, wiki lint, state diff, downstream build 결과가 모두 따로 올라오면 owner는 다시 묻게 됩니다.

지금 내가 결정해야 하는 것은 무엇인가.

이 질문이 닫히지 않으면 자동화는 일을 줄여 주는 대신 새로운 해석 업무를 만듭니다.

그래서 다음 단계는 더 많은 worker를 붙이는 일이 아니었습니다. owner에게 올라오는 질문의 모양을 줄이는 일이었습니다.

로그를 많이 주면 위임이 아니라 재해석이 됩니다

개발자는 근거를 많이 보여주고 싶어집니다.

npm test가 통과했고, npm run build가 통과했고, state가 다시 생성됐고, diff도 확인했고, 관련 문서도 업데이트했다고 말하고 싶습니다. 모두 필요한 근거입니다.

하지만 이 근거를 그대로 던지면 owner는 다시 운영자로 돌아갑니다.

테스트 통과가 배포 허가인지, state diff가 안전한지, rollback note가 필요한지, 지금 결재할 수 있는지 다시 해석해야 합니다.

그래서 queue summary의 첫 문장은 기술 bullet이 아니어야 했습니다.

먼저 쉬운 설명이 와야 했습니다. 이 줄이 무엇을 판단하는 줄인지, 현재 어디까지 안전한지, owner가 무엇을 고르면 되는지 먼저 말해야 했습니다. 기술 근거는 그 다음에 붙이면 됩니다.

queue의 첫 문장은 쉬운 설명이어야 했습니다

나쁜 보고는 이런 모양입니다.

Build queue
- npm test pass
- npm run build pass
- state regenerated
- output/state diff reviewed

틀린 말은 아닙니다.

하지만 owner는 이 bullet이 무엇을 뜻하는지 다시 판단해야 합니다. 사이트가 깨지지 않는다는 뜻인지, 공개 배포까지 해도 된다는 뜻인지, state diff는 사람이 봤다는 뜻인지 애매합니다.

그래서 같은 내용을 이렇게 바꾸기로 했습니다.

Build queue

쉬운 설명:
- 사이트가 깨지지 않고 빌드되는지 확인하는 줄입니다.
- 테스트와 빌드는 통과했고, 생성된 상태 파일 변경도 확인했습니다.
- 이 통과는 공개 배포 허가가 아니라 build 안정성 확인입니다.

상태:
- npm test pass
- npm run build pass
- state regenerated
- output/state diff reviewed

판정: pass

기술 근거는 줄지 않았습니다.

달라진 것은 읽는 순서입니다. owner는 먼저 의미를 읽고, 그 뒤에 근거를 확인합니다. 이 차이가 작아 보여도 운영 감각은 달라집니다.

네 가지 선택지로 질문을 줄였습니다

Peter Steinberger loop를 보면서 가장 유용했던 장면은 owner 질문의 축소였습니다.

owner에게 올라오는 질문은 가능한 한 네 가지로 줄일 수 있었습니다.

선택	뜻
결재	다음 단계로 진행합니다
반려	현재 방향을 중단하거나 다시 작성합니다
열쇠 하나	정확히 하나의 missing input, 권한, 경로, 결정만 제공합니다
택일	문서화된 대안 중 하나를 고릅니다

이 표가 있으면 agent도 질문을 다르게 만들게 됩니다.

"어떻게 할까요"라고 묻지 않습니다. 지금 필요한 것이 결재인지, 반려인지, missing input 하나인지, 선택지 중 하나인지 먼저 분류합니다.

이렇게 질문을 줄이면 owner의 일이 단순해집니다.

모든 상황을 다시 분석하는 사람이 아니라, 정리된 선택지에서 다음 권한을 여는 사람이 됩니다.

권한은 한 칸씩만 올라가야 했습니다

decision-ready queue에서 중요한 것은 권한 사다리였습니다.

조회 권한을 줬다고 수정 권한까지 준 것이 아닙니다. 수정 권한을 줬다고 push 권한까지 준 것도 아닙니다. push가 됐다고 merge가 허가된 것도 아니고, build가 통과했다고 public deploy가 허가된 것도 아닙니다.

권한은 한 칸씩 올라가야 했습니다.

조회
-> 수정
-> 푸시
-> 머지
-> 배포 또는 외부 적용

이 원칙은 개인 블로그 작업에도 필요했습니다.

초안을 작성해도 publish가 허가된 것은 아닙니다. publish artifact를 만들 수 있어도 downstream site에 복사하는 것은 별도 handoff입니다. site build가 통과해도 public deploy는 또 다른 결정입니다.

권한을 분리하면 자동화는 더 느려 보일 수 있습니다. 하지만 실제로는 사고가 줄어듭니다. 한 단계의 성공을 다음 단계의 허가로 착각하지 않기 때문입니다.

개인 저장소에서는 source, wiki, publish, handoff로 나눴습니다

개인 위키 저장소에서는 queue를 네 줄로 나눴습니다.

source queue는 원본 자료가 어디에서 왔고, 이 저장소에 보관해도 되는지 봅니다. 회사 원문, source trace, credential, raw evidence는 여기로 들어오면 안 됩니다.

wiki queue는 사람이 읽는 source of truth가 정리됐는지 봅니다. frontmatter, wikilink, index, log, wiki sync와 lint가 여기에 들어갑니다.

publish queue는 공개 글로 내보내도 되는지 봅니다. published: true, stable slug, concrete description, date-bearing path, related links가 핵심입니다.

downstream handoff queue는 output/blog artifact와 site content/posts로 넘겨도 되는지 봅니다. 여기서 통과해도 public deploy 허가는 아닙니다.

이렇게 나누면 한 번에 "발행해도 되나요"라고 묻지 않게 됩니다.

어느 줄이 통과했고, 어느 줄이 아직 owner 결정을 기다리는지 볼 수 있습니다.

사이트 저장소에서는 content, build, deploy로 나눴습니다

사이트 저장소에서는 질문이 조금 다릅니다.

여기서는 글 원본보다 독자-facing 결과물이 중요합니다. 그래서 content queue, build queue, deploy queue로 나눴습니다.

content queue는 post가 들어왔는지, frontmatter가 맞는지, 이미지 경로와 관련 링크가 살아 있는지 봅니다.

build queue는 테스트와 빌드가 통과하는지, state가 결정적으로 다시 생성되는지, output/state diff가 예상 범위인지 봅니다.

deploy queue는 public site에 반영해도 되는지 봅니다. target commit, rollback note, smoke check, owner decision이 여기로 올라옵니다.

예시는 이렇게 읽히는 것이 목표였습니다.

Deploy queue

쉬운 설명:
- 이제 실제 공개 사이트에 올릴지 결정하는 줄입니다.
- build는 통과했지만 rollback note가 없으면 공개 반영 전에 보완이 필요합니다.

상태:
- public deploy pending
- rollback note missing
- owner decision needed

판정: needs owner

needs owner는 실패가 아닙니다.

사람이 결정해야 하는 지점이 숨겨지지 않고 드러난 상태입니다. 이 상태가 있어야 owner가 결재할지, 보류할지, rollback note 하나만 제공할지 선택할 수 있습니다.

회사 쪽 적용은 구조만 공개할 수 있습니다

이 구조는 회사 쪽 저장소에도 일부 적용했습니다.

다만 공개 글에서는 구체 repository 이름과 적용 내역을 줄여 말해야 합니다. 회사 원문, source trace, review record, test evidence, issue key, screenshot, credential, 내부 payload는 개인 위키나 공개 글로 가져오면 안 됩니다.

그래서 회사 쪽 적용은 이렇게만 설명할 수 있습니다.

공유 하네스는 queue의 형식과 언어를 제공합니다. 개인 저장소는 공개 가능한 판단 기록과 글쓰기 source를 남깁니다. 회사 쪽 저장소는 자기 문맥 안에서 approval-gated queue를 유지합니다. 외부 action은 dry-run, review, exact confirmation, approval, execution note 없이는 열리지 않습니다.

이 정도면 충분합니다.

공개 글의 가치는 회사의 세부 사실이 아니라, 권한과 판단 표면을 분리한 운영 구조에 있습니다.

Stage 5를 보류한 이유

이번 작업에서 일부러 하지 않은 것도 있습니다.

5분마다 깨어나는 polling worker, 여러 worker thread의 자동 orchestration, 외부 action 자동 apply는 도입하지 않았습니다.

이유는 단순합니다.

현재 필요한 것은 더 강한 자동 실행이 아니라 더 명확한 owner decision surface였기 때문입니다. queue summary가 안정되지 않았는데 worker orchestration부터 붙이면, 빠르게 움직이는 애매한 시스템이 됩니다.

그래서 Stage 5는 보류했습니다.

먼저 문서와 template으로 queue의 모양을 닫습니다. 각 저장소에서 어떤 줄은 agent가 처리하고, 어떤 줄은 owner가 결재해야 하는지 확인합니다. 그 다음에 반복 작업이 충분히 검증될 때만 실행 표면을 넓히는 것이 맞다고 봤습니다.

위임자의 일은 로그를 해석하는 일이 아니었습니다

이번 5편의 결론은 위임자의 역할에 대한 것입니다.

AI에게 일을 맡긴다는 것은 사람이 아무것도 보지 않는다는 뜻이 아닙니다. 오히려 사람이 봐야 할 것을 더 또렷하게 남기는 일에 가깝습니다.

다만 사람이 봐야 하는 것은 raw log 전체가 아니어야 합니다. 사람이 봐야 하는 것은 지금 어느 queue가 막혔는지, 어떤 근거가 있고, 어떤 위험이 있으며, 다음 선택지가 무엇인지입니다.

그래서 decision-ready queue는 자동화 기능이라기보다 운영 언어에 가깝습니다.

AI가 더 많은 일을 할수록 owner에게 올라오는 질문은 더 작고 선명해야 합니다. 결재할 것인지, 반려할 것인지, 열쇠 하나를 줄 것인지, 문서화된 대안 중 하나를 고를 것인지.

그 질문이 작아질 때 비로소 위임이 시작됩니다.