연결된 뒤에 찾아오는 것은 언제나 똑같은 질문이다. "그럼, AI에게 어디까지 맡겨도 되는가?" 기술적으로 가능한 것과 운영으로서 허용하는 것은 일치하지 않는다. 일치하지 않은 채로 나아가면 속도는 사고가 된다. Kagoshimaniax OS에서는 그 경계에 Human Approval이라는 이름을 붙였다. 인간의 승인. 짧은 말이지만, 사상으로서 길게 작용한다.

나는 코드를 쓸 줄 모른다. 그래서 "승인 플로우를 구현했다"기보다는, "승인 없이는 진행할 수 없는 문화를 두었다"는 감각에 가깝다. 문화는 버튼보다 강할 때가 있다. 버튼은 우회된다. 문화는 대화의 처음으로 되돌아간다.

Vol.03에서 AI의 폭주에 대해 썼다. 멈추는 방법은 범위를 좁히는 것, 쓰기를 뒤로 미루는 것, 기록을 남기는 것이었다. Connector Platform에서 읽기와 일일 축적이 돌아가기 시작하자 다음 유혹이 찾아왔다. "읽을 수 있다면 쓸 수도 있지 않을까?", "제안까지 자동화했으니 실행도?"

유혹은 악의가 아니다. 효율화의 연장선이다. 하지만 지역 미디어의 실전은 실험장이 아니다. 기사, SEO 설정, 캐시, SNS——한 번의 실수가 검색과 신뢰에 영향을 미친다. 영향을 주는 것을 모델의 자신감에 맡길 이유는 없다. 모델은 책임을 지지 않는다. 책임을 지는 것은 아침의 10분을 사용하는 인간이다.

그래서 사상을 먼저 두었다. AI는 제안자. 실전의 변경은 사람이 승인한다.

테마는, Human Approval을 사상으로 채택하고, 조작의 안전 분류까지 적용한 것이다.

자동화해도 좋은 영역과 승인이 필요한 영역을 나눈다. 커넥터를 통한 일일 취득, 리포트 생성, 백업——이러한 읽기 중심의 처리는 원칙적으로 자동화 측에 둘 수 있다. 반면 공개, 삭제, 설정 변경, SNS 게시——실전에 닿는 조작은 승인 없이는 실행하지 않는다. 이것은 기능의 리스트가 아니라 운영의 약속이다.

사상이 문서가 된 것은 쓰기 계열 MCP의 전수 조사부터였다. WordPress, SEOPress, WP Rocket, Imagify, Obsidian, Metricool——"할 수 있는 것"은 한 번 나열해 보면 무서울 정도로 많다. 나열한 뒤에 색을 칠했다. Green, Yellow, Red. 색은 직관을 돕는다. 직관은 비엔지니어의 판단 속도를 높인다.

docs/action-safety-policy.md

와 docs/automation-policy.md

에 담긴 말은 어렵지 않다. "제안까지는 자동으로 해도 좋다. 실전 조작은 Human Approval 필수." 반복해서 적음으로써 AI에게 보내는 요청문에도 스며든다. 스며들면 갑자기 "설정을 바꿔줘"라는 말을 듣기 어려워진다.

사상을 시험하기 위해서는 작은 Green 조작이 필요했다. Step45에서 Obsidian의 create-note를 Human Approval을 포함하여 구현했다. 승인 체크가 없으면 버튼은 작동하지 않는다. 로직에서도 거부된다. 덮어쓰기는 하지 않는다. 감사 로그에는 본문이 아니라 해시(Hash)만 남긴다. 실전 사이트에는 손대지 않는다. 실패해도 상처가 적은 곳에서 승인의 형태를 배운다.

Step46에서는 WP Rocket의 retest-page-insights를 같은 틀에 올렸다. 캐시 계열은 무섭다. 그래서 승인 전에 Safety 표시, 실행 후의 확인, JSONL 감사——공통 플로우를 재사용했다. 재사용은 사상이 기능이 되었다는 증거다.

실패담: 나는 종종 "Green이라면 승인이 필요 없지 않을까?"라고 말하려 했다. 빨리 편해지고 싶은 마음은 이해한다. 하지만 Version 0.5에서는 Green이라도 Human Approval을 붙인다고 결정했다. 붙이는 이유는 습관을 만들기 위해서다. 처음부터 예외를 늘리면 예외가 표준이 된다. 표준이 "일단 실행"이 되면 Red 조작이 섞여 들어온다.

또 다른 실패는 승인을 형식으로만 만드는 것이다. 체크박스에 표시만 하고 내용을 읽지 않는다. 형식뿐인 승인은 승인의 부정이다. 그래서 확인 화면에 Safety 표시를 두었다. 무엇이 일어날지를 실행 전에 언어로 표현한다. 언어로 표현할 수 없는 조작은 실행하지 않는다.

세 번째는 아직 개방하지 않은 조작에 대한 조급함이었다. SEOPress의 제목 변경, Imagify의 압축——미래의 Must 후보로 보이고 있다. 하지만 롤백(Rollback) 방침이 확립되지 않은 것을 승인이 붙었으니 안전하다고 말할 수는 없다. 사상은 준비되지 않은 조작을 멈추는 힘이 되기도 한다.

신뢰는 단 한 번의 자동화가 아니라, 몇 번이고 승인을 거친 이력에서 태어난다. 이력은 감사 로그와 테스트에 남겼다. 승인 없이는 실행 불가함을 단위 테스트(Unit Test)로 확인할 수 있었을 때, 비로소 "사상"이 "사양(Specification)\

Actions 화면을 처음 열었던 날을 기억한다. 버튼은 눈에 띈다. 눈에 띄는 버튼은 누르고 싶어진다. 누르고 싶게 만드는 설계는 위험하다. 그래서 승인 체크가 없으면 disabled 상태로 유지된다는 것을 확인했다. 그 확인은 어린 시절 '누르지 마시오'라고 적힌 버튼을 볼 때와 같은 안도감을 주었다. 이것은 유희가 아니라, 운영 환경(Production) 바로 옆에서 장난치지 않기 위한 UI다.

Obsidian의 create-note를 시도했을 때, 덮어쓰기를 할 수 없는 사양이 오히려 든든했다. 실패하더라도 기존 노트는 파괴되지 않는다. 파괴되지 않는다는 것은 비엔지니어(Non-engineer)가 처음으로 쓰기 작업을 접하기 위한 조건이다. 조건이 갖춰지고 나서야 비로소 WP Rocket과 같은 운영 환경에 가까운 조작으로 나아갈 수 있다. 순서를 건너뛰고 싶다는 마음은 매번 찾아온다. 찾아올 때마다 사상(Philosophy)이 그것을 멈춰 세운다.

Metricool의 OAuth나 일일 커넥터(Daily Connector)는 승인 없이 돌아가는 쪽에 두었다. 이 부분을 혼동하면 '전부 승인'도 '전부 자동'도 모두 파탄 난다. 파탄이란 현장의 언어로 말하자면 '무엇을 믿어야 할지 모르는' 상태다. 그 상태가 아침의 10분을 가장 많이 앗아간다.

Vol.03에서 폭주를 막았던 이야기는 지금 다시 읽어보면 Human Approval의 서막처럼 보이기도 한다. 멈추는 방법은 '하지 않는 것'이었다. 사상은 '하지만, 승인한다'로 진화했다. 진화는 부정으로부터가 아니라, 경계의 정밀화(Precision)로부터 왔다. 정밀화는 리뷰(Review)와 문서(Documentation)가 뒷받침했다. 뒷받침이 없다면 사상은 슬로건으로 끝나고 만다.

SNS나 공개에 관한 이야기가 나왔을 때, 나는 항상 한 번 손을 멈췄다. 멈추는 이유를 언어화하는 것이 서툴렀다. 서툰 채로 나아가면 나중에 '왜 허락했는가'를 설명할 수 없다. 설명할 수 없는 허가는 사고의 온상이다. 그래서 automation-policy에 '게시물은 Human Approval 필수'라고 명문화했다. 명문화는 미래의 나에게 보내는 편지다.

Human Approval은 AI 불신이 아니다. AI를 계속 사용하기 위한 조건에 가깝다. 제안은 환영한다. 조사, 초안 작성, 비교, 리스크 열거——이 부분은 맡기는 편이 빠르다. 맡긴 뒤에 마지막 한 걸음(Last push)만을 사람이 담당한다. 그 한 걸음의 무게를 알고 있기에 제안의 질도 올라간다. 질이 올라가는 이유는 책임의 소재가 명확하기 때문이다.

또한, 승인은 느림이 아니다. 느림이란 판단을 생략하지 않는 것에 대한 비용이다. 생략한 판단은 밤에 돌아온다. 돌아왔을 때의 비용이 더 높다. 아침의 10분은 승인을 포함한 설계로 지켜내야 할 시간이다.

비엔지니어에게 사상은 코드보다 쓰기 쉽다. 작성된 사상은 ADR이나 CHANGELOG와 함께 성장한다. 성장하면 리뷰의 기준이 된다. 기준이 있으면 구현(Implementation)의 속도에 휘둘리기 어렵다.

Human Approval은 장래의 AI 기능을 뒤로 미루기 위한 핑계가 아니다. 오히려 반대로, AI를 운영 환경(Production)에 가깝게 만들기 위한 조건이다. 제안의 질이 올라가면 승인하는 판단도 빨라진다. 빨라지는 이유는 내용을 이해하고 있기 때문이다. 이해는 통째로 떠넘기는 것(丸投げ)에서는 생기지 않는다. 대화와 문서, 그리고 단 한 번의 작은 실행이 이해를 쌓아 올린다.

Red의 조작을 미배선(Unwired) 상태로 남겨두는 것도 사상의 일부다. '할 수 있지만 멈춰두고 있다'는 것은 약함이 아니라 설계다. 설계를 이야기할 수 있게 되면 스테이크홀더(Stakeholder)——이 경우에는 미래의 나——에게 설명할 수 있다. 설명할 수 있다는 것은 운영 OS의 자산이 된다.

• 기술적으로 가능한 것과 운영으로서 허용하는 것은 별개
• 커넥터·리포트·백업은 자동화, 운영 환경 변경은 승인
• Green 단계에서도 처음에는 승인을 붙여 습관을 만든다
• 작고 얕은 조작으로 승인 플로우(Approval Flow)를 검증할 수 있다
• 감사 로그(Audit Log)와 테스트가 사상을 사양(Specification)으로 고정한다
• 준비되지 않은 조작은 승인이 있더라도 개방하지 않는다

다음에는 사상을 지탱한 또 다른 기둥——리뷰와 문서화——에 대해 쓰겠다. 구현보다 리뷰가 더 효과적이었던 일상의 이야기다.

Documentation First, ADR, Architecture Review——멈춰 보였던 시간에 대한 이야기를 씁니다.