안녕하세요, AI師範(AI 시한)입니다.

갑자기 이상한 말을 하겠습니다. 저의 「회사」에는 8명의 직원이 있습니다. 하지만 인간은 저 혼자뿐입니다. 나머지 7석(그리고 사람이 아닌 1석)은 모두 Claude Code를 비롯한 AI 에이전트(AI Agent)가 앉아 있습니다.

이것은 SF적인 과장이 아니라, 지금 제 손에서 실제로 돌아가고 있는 운용 방식입니다. 저는 개인 개발자이지만, AI를 「똑똑한 보완 도구」로 사용하는 것을 어느 시점에서 그만두었습니다. 대신, 직책·발주서·검수·부서 간 연락 규칙을 갖춘 작은 조직으로서 운용하기 시작했습니다. 그러자 놀라울 정도로 업무가 차분하게 돌아가기 시작했습니다.

먼저, 그 조직도를 보여드리겠습니다. 직책명으로만 소개하겠습니다 (어떤 모델이 앉아 있는지는 여기서는 일부러 밝히지 않겠습니다. 이유는 다음 장에서 설명합니다).

사장(나·인간) ―― 목적·우선순위·불가역적인 판단·최종 승인만을 가짐
├─ 사장실: 비서
│ 접수·논점 정리·발주·성과물 통합·최종 검수
...

직원은 비서·CTO·개발과장·개발담당·정형담당·외부감사·준위임·자동화석의 8석입니다. 솔직히 말하면, 이 중 「자동화석」은 인격을 가지지 않습니다. 상태 전이(State Transition)나 재시도(Retry)를 담담하게 수행하는 결정론적인 코드(Deterministic Code)이며, 저는 이것을 직원이라고 부르지 않기로 했습니다. 그래도 자리는 마련해 두었습니다. 이유는 나중에 나올 「사고」와 관련이 있습니다.

이 기사에서는 왜 이런 번거로운 짓을 하고 있는지, 그리고 실제로 어떻게 「AI에게 업무를 발주」하고 있는지를 1차 정보 그대로 쓰겠습니다.

왜 「모델의 구분」이 아니라 「직책」인가

AI를 여러 개 사용한다고 하면, 많은 사람은 「어려운 태스크는 상위 모델, 간단한 태스크는 가벼운 모델」이라는 모델의 구분(Model Selection)을 떠올릴 것이라고 생각합니다. 저도 처음에는 그랬습니다. 하지만 이것으로는 잘 풀리지 않는 상황이 있었습니다.

문제는, 모델의 똑똑함과 그 태스크에 손을 대도 되는지가 별개의 문제였다는 점입니다.

예를 들어, 매우 똑똑한 모델이라 할지라도, 「자신이 작성한 코드를 스스로 합격 판정해도 되는가」라고 묻는다면 그것은 틀린 것입니다. 인간의 회사에서도 자신의 성과물을 스스로 검수하고 도장을 찍는다면, 그것은 그저 자기 신고일 뿐입니다. 제3자의 리뷰(Review)가 필요합니다.

그래서 저는 판단의 축을 「어떤 모델인가」에서 「어떤 직책인가」로 옮겼습니다. 직책은 세 가지를 가집니다.

권한: 무엇을 해도 되고 무엇을 해서는 안 되는가. 예를 들어 비서는 「통상적인 구현을 직접 하지 않는다」, 외부감사는 「조언에 머물며 구현은 하지 않는다」.

검수: 성과물의 합격 여부를 판정하는 담당. 여기에는 철칙이 있는데, 기안·설계·구현·승인을 담당한 자는 그 업무의 검수자가 될 수 없습니다. 저는 이것을 「기피(忌避)」라고 부르고 있습니다. 요컨대 이해상충(Conflict of Interest)의 회피입니다. 감사역이 직접 손을 댄 안건에서는 감사에서도 빠지게 합니다.

성과물의 형태: 무엇을 어떤 형태로 낼 것인가.

재미있는 점은, 같은 AI 모델이라도 장착하고 있는 직책이 바뀌면 지켜야 할 규칙이 바뀐다는 점입니다. 인격(말투나 호칭)은 어디까지나 화면의 외형적인 층에 가두고, 권한 판정에는 일절 사용하지 않기로 결정했습니다. 「똑똑하니까 맡긴다」가 아니라 「그 자리의 권한이니까 맡긴다」. 이 선을 그은 것만으로 AI에게 일을 맡길 때의 두려움이 상당히 줄어들었습니다.

참고로 업무의 난이도(L1L4)와 조작의 위험성(A0A3)도 별개로 봅니다. 「간단한 작업이지만, 운영 환경에 불가역적인 변경을 가하는」 것과 같은 조작은 난이도가 낮더라도 승인을 엄격하게 합니다. 난이도로부터 위험성을 추정하지 않는 것이 요령입니다.

발주서로 업무를 요청한다

그럼 실제로 어떻게 업무를 요청하는가. 저는 구두(채팅)로 어렴풋이 요청하는 것을 그만두고, 발주서라는 기계 판독 가능한 JSON으로 요청하도록 했습니다.

발주서에는 코드(안건 번호)·제목·의뢰문·접근 가능한 파일·예상 토큰·그리고 검수 합격 조건이 들어갑니다. 실제로 이 기사 자체도 한 장의 발주서로서 발주되었습니다. 간략화하면 다음과 같은 형태입니다.

{
"code": "D001",
"title": "무료 기사 1번째 드래프트 (Zenn용·AI師範 명의)",
...

흐름은 다음과 같습니다.

견적: 발주 전에 이 작업이 대략 어느 정도의 토큰과 수순(Turn)을 소비할지 견적을 냅니다. 과거의 실측 데이터를 바탕으로 "이런 종류의 문서 작업이라면 중간 수준에서 이 정도"라고 예측치를 잡습니다. 할당량(가용량)이 부족할 때는 무거운 모델을 피하는 등의 판단도 여기서 이루어집니다. -
자동 실행: 승인된 발주서는 통제 기반(Control Infrastructure)이 수거하여 헤드리스(Headless)로 실행합니다. 담당 AI는 의뢰문만을 의지하여 지정된 파일만을 생성합니다. 저는 이 동안 다른 일을 하고 있습니다. -
검수: 완성된 성과물을 verifyGreps와 같은 기계적인 체크에 겁니다. 위의 예라면 "frontmatter에 published가 있는가", "AI 사범(AI師範) 명의로 되어 있는가"를 정규 표현식으로 확인합니다. 기계적 체크를 통과한 후, 담당과는 다른 직책이 내용을 읽고 합격 여부를 판정합니다. 여기서도 기피(Avoidance) 규칙이 적용됩니다.

또 하나 중요한 것은 files의 존재입니다. 담당 AI에게는 "이 안건에서 건드려도 되는 것은 이 파일뿐이다"라고 명시합니다. 요청하지 않은 곳을 알아서 수정하는 사고를 구조적으로 억제하기 위해서입니다. 의뢰문만 건네주고 나머지는 자유롭게 맡기면, 대개 불필요한 일을 저지릅니다. 범위를 미리 고정해 두는 것이 AI에게 안심하고 일을 맡기는 요령이었습니다.

이 "견적 → 자동 실행 → 검수"를 돌린 횟수는 자세한 숫자는 다음 기사로 미루겠지만, 벌써 약 수백 건 규모에 달합니다. 좋았던 점은 요청한 내용이 기록으로 남는다는 점입니다. 발주서는 그대로 장부가 되어, 나중에 "언제, 무엇을, 어느 자리(Seat)에, 얼마의 견적으로 요청했고, 어떻게 검수했는지"를 추적할 수 있습니다. 모호한 채팅 의뢰로는 이것을 얻을 수 없었습니다. 인간을 상대하는 업무에서도 구두 약속보다는 한 장의 지시서가 다툼을 줄이는 것과 같은 이치라고 생각합니다.

사고와 사내 규정

순조롭게 들릴 수도 있겠지만, 사고도 있었습니다.

어느 날, 어떤 세션이 클린한 작업 토대를 만들려다가 공유 중인 작업 트리(Working Tree) 전체를 되돌리는 조작(git stash 종류)을 실행했습니다. 그런데 이 작업 트리에서는 여러 세션과 자동 실행이 상시 병행되고 있었기에, 다른 세션의 실행 중인 작업이나 통제 기반의 장부, 검수는 끝났지만 아직 반영되지 않은 성과물까지 아무런 경고 없이 되돌려질 뻔했습니다. 장부의 영구적 손실로 직결될 수도 있었던 아찔한 사건이었습니다.

이 사건 이후, 저는 "공유 작업 트리의 보전"이라는 사내 규정을 만들었습니다. 트리 전체를 수정하는 조작은 원칙적으로 금지. 클린한 토대가 필요하다면 전용으로 분리된 작업 트리에서 작업할 것. 반드시 필요한 경우에는 "실행 큐(Execution Queue)가 비어 있음을 확인·타 세션에 대한 사전 통지·동일한 차례 내에 복구까지 완수"라는 3가지 조건을 부과한다. ――이런 규정이 사고가 날 때마다 하나씩 늘어갑니다.

그리고 장의 서두에서 언급했던 사람이 아닌 "자동화 자리(Seat)". 그것은 상태 전이나 재시도와 같이 결정론적(Deterministic)이고 담담하게 수행해야 할 일을 인격이 있는 AI에게 맡기지 않기 위한 자리입니다. 사고의 대부분은 "지나치게 눈치를 보는(알아서 하려는) AI"로부터 발생합니다. 그렇기에 기계적으로 해야 할 일은 기계로 고정해 버립니다. 조직도에 사람이 아닌 자리가 하나 섞여 있는 것은 이러한 반성의 산물입니다.

"AI를 도구로 사용하기"에서 "AI를 조직으로 고용하기"로

여기까지 읽고, "개인 개발에서 그렇게까지 한다고?"라고 생각하셨을지도 모릅니다. 솔직히 번거롭습니다. 하지만 저는 AI와의 관계가 "도구를 사용하는 것"에서 "조직을 고용하는 것"으로 변했다는 실감이 있습니다.

도구는 사용할 때마다 모든 책임이 사용자에게 돌아옵니다. 반면, 조직은 권한·검수·기록·사고 대응의 메커니즘 자체가 업무를 뒷받침해 줍니다. AI가 똑똑해질수록 제가 원했던 것은 "더 똑똑한 하나의 AI"가 아니라, "똑똑한 AI들이 폭주하지 않고 협업하기 위한 수수한 메커니즘"이었습니다. 직책도, 발주서도, 기피도, 사고 때마다 늘어나는 규정도 모두 그것을 위한 것입니다.

만약을 위해 써두자면, 이것은 "AI로 쉽게 돈을 벌 수 있다"와 같은 종류의 이야기가 아닙니다. 오히려 처음에는 수고가 늘어납니다. 제가 흥미롭다고 생각하는 것은 개인이라도 제대로 제도를 갖추면 AI를 조직으로서 운용할 수 있다는 바로 그 사실입니다.

다음에는 이 기사에서 다루지 않은 "부서 간 연락"에 관한 이야기를 쓰겠습니다. 여러 세션이 병행되면 "이 일, 누가 맡지?", "이미 누가 하고 있지 않나?"와 같은 누락과 중복 처리가 반드시 발생합니다. 이를 방지하기 위해 제 조직에는 대기 순번 프로토콜(Waiting Turn Protocol)이라는 인계의 정본(正本) 규칙이 있습니다. 누락 제로·중복 처리 제로를 어떻게 기계 판독 가능한 규칙으로 담보하고 있는지, 다음 기사에서 자세히 보여드리겠습니다.

그럼, 다음에 뵙겠습니다. AI 사범(AI師範)이었습니다.

토론 (Discussion)