백엔드 챕터의 AI Native 전환 설계: Claude Code 세미나 다음에 와야 할 것

5주 세미나를 끝낸 다음 주, 챕터원 한 명이 슬랙으로 물었다. "세미나 잘 들었어요. 그래서 우리는 이제 뭘 해야 하나요?" 그 한 줄이 이 글의 출발점이다. 세미나는 awareness를 만든다. 그러나 "이제 뭘 해야 하나요"라는 질문이 나왔다는 건 그 awareness가 워크플로우와 아직 연결되지 않았다는 신호다.

5주에 걸친 Claude Code 세미나가 끝났다. 발표를 마치고 정리하면서 동시에 떠오른 두 가지가 있었다. 하나는 보람이었고, 다른 하나는 불안이었다. 챕터원들이 도구의 구조를 이해하게 됐다는 보람, 그리고 그 이해가 실제 일상 작업에 통합되지 않으면 한 달 안에 사라질 거라는 불안. 챕터 오너로서 다음 6개월을 어떻게 끌고 가야 할지, 아직 챕터 차원의 합의가 만들어지기 전에 내가 먼저 정리해 둬야 할 설계 노트를 적는다.

이 글은 "AI 도구 도입기"가 아니다. 도구는 이미 손에 있다. 그러나 챕터 단위의 측정·표준·학습·자산 운영은 모두 아직 없다. 챕터 단위로 AI Native 워크플로우를 어떻게 설계하고, 무엇을 측정하고, 어떤 표준을 두고, 챕터 자산을 어떻게 묶어 배포할지를 챕터 오너로서 제안하기 위한 출발선 노트로 적어 둔다.

1. 자리 잡기: 세미나가 남긴 것, 남기지 못한 것

먼저 출발선을 정직하게 짚자. 5주 세미나가 남긴 것은 분명하다.

챕터원 대부분이 Claude Code의 단일 API 요청 구조, Memory의 두 슬롯, Hook의 라이프사이클, Skill의 3단계 로딩, Sub-agent 격리라는 다섯 장의 멘탈 모델을 공유한다.
발표 후 자연스럽게 슬랙에서 "이건 hook 자리지?", "skill로 묶으면 되는 건가?" 같은 공용 어휘가 돌기 시작했다.

그러나 세미나가 남기지 못한 것도 분명하다.

챕터원들의 일상 작업에 AI 워크플로우가 통합되지 않았다. 도구는 알지만 "어디서부터 어떻게 쓸지"는 각자 다르다.
표준이 없다. CLAUDE.md, skill, sub-agent를 각자 만들고 각자 버리고 있다. 어느 누구도 옆 자리의 그것을 재사용하지 않는다.
측정이 없다. "더 빨라졌다", "도움 됐다"는 인상은 있지만, 챕터의 가용 능력이 실제로 얼마나 늘었는지 숫자로 답할 수 없다.

세미나 직후 한 챕터원이 슬랙에서 한 말이 이걸 정확히 요약했다.

"이제 뭘 해야 하나요?"

이 질문에 답하는 것이 챕터 오너의 다음 6개월이다. 세미나는 awareness를 만들었고, 다음은 workflow integration이다. 두 단계 사이의 거리를 줄이는 일이 진짜 AX 전환이다.

2. AI Native가 정확히 뜻하는 것

이 단어가 가벼워서 위험하다. "AI Native"라고 부르면 진취적이지만, 정의가 흐릿하면 실행도 흐릿해진다. 그래서 가장 먼저 챕터 차원에서 합의해야 할 것이 정의 그 자체다. 내가 합의의 출발점으로 제안하려는 정의는 이것이다.

AI Native = 작업의 기본 단위가 "사람의 손글씨 코드"가 아니라 "사람이 설계한 AI 파이프라인"이 되는 상태.

이 정의를 합의 후보로 두는 이유는 두 가지다.

도구 도입이 아니라 워크플로우 재설계: AI를 쓰는 것과 AI Native는 다르다. "필요할 때 ChatGPT에 물어본다"는 도구 사용이고, "티켓 한 줄을 받으면 분해·개발·리뷰·MR이 한 파이프라인에서 흐른다" 가 AI Native다.
개인의 능력이 아니라 챕터의 가용 능력: AI Native 상태는 한 명의 슈퍼유저가 만드는 게 아니다. 챕터의 평균 멤버가 표준화된 파이프라인을 안전하게 호출할 수 있어야 한다. 한 사람만 잘하면 그건 의존성이지 전환이 아니다.

이 정의가 챕터 안에서 합의되면 챕터 오너의 일이 자연스럽게 따라온다고 본다. 챕터 오너의 일은 "도구를 평가하는 것"이 아니라 "챕터의 가용 능력이 실제로 늘어나도록 워크플로우를 설계하는 것" 이 되어야 한다. 새 도구의 매력에 빠지기 쉬운 자리지만, 매력에 빠지는 건 챕터 오너가 할 일이 아닐 것이다.

3. 챕터 멤버의 4단계 성숙도

다음으로 짚어야 할 것은, 챕터원이 한 덩어리가 아니라는 사실이다. 같은 챕터 안에서도 AI 사용 수준은 4단계로 분포한다.

챕터 멤버 4단계 성숙도

LV1 Tool Aware: "존재는 안다." 가끔 시도하지만 결과를 신뢰하지 않고, 일상 워크플로우와 분리되어 있다. 챕터의 30~40%가 여기다.
LV2 Tool User: "필요할 때 쓴다." 단발 질의 위주로 코드 조각을 받아 쓴다. 매번 처음부터 시작하고, 결과 검증 비용이 크다. 챕터의 40~50%.
LV3 Workflow Integrator: "단계에 끼워 넣는다." 사내 skill, sub-agent, hook을 직접 작성한다. 자신의 워크플로우 일부를 자동화한다. 15~20%.
LV4 Native: "기본 작업 단위가 AI다." Orchestrator를 설계하고, 작업 단위가 티켓이 아니라 에이전트 파이프라인이다. 5~10%.

이 분포를 인정하지 않으면 모든 전환 시도가 헛돈다. 세미나는 LV1과 LV2 사이의 다리만 놓았다. LV2 → LV3, LV3 → LV4로 가는 다리는 세미나로 놓이지 않는다. 각 단계별 병목이 다르기 때문이다.

LV1의 병목은 진입 장벽이다. 처방은 첫 1주 핸드홀딩과 "오늘 한 가지 일을 AI로 해 본다" 챌린지. 시간 절감을 가시화해서 다음 단계로 미는 게 핵심.
LV2의 병목은 컨텍스트 재공급 비용과 결과 검증 비용이다. 처방은 공용 CLAUDE.md 베이스라인과 skill 카탈로그. 매번 처음부터 시작하지 않게 한다.
LV3의 병목은 표준 부재다. 각자 잘하지만 옆 사람과 다른 방식이다. 처방은 공용 skill 저장소와 패턴 카탈로그 ADR.
LV4의 병목은 검증·관측의 부재다. 파이프라인이 잘 돈다고 믿지만, 실패율·재시도율·잘못 머지된 비율을 답할 수 없다. 처방은 자동 리뷰 사이클과 KPI 리포팅.

목표 분포를 한 줄로 적자면 이렇다.

6개월 안에 LV1을 10% 미만으로 줄이고, LV3+를 50% 이상으로 끌어올린다.

이 목표가 측정 가능해야 한다. 그래서 다음이 측정 축이다.

4. 설계의 네 축: 측정·학습·표준화·자산화

AX 전환을 챕터 단위로 끌고 가려면 네 가지 축을 동시에 굴려야 한다. 한 축만 빠져도 다른 축의 효과가 줄어든다.

설계의 네 축

측정 (Measure): 무엇이 좋아지고 있는지 숫자로 답할 수 있어야 한다.
학습 (Learn): 멤버를 LV1 → LV2 → LV3 → LV4로 끌어올리는 구조.
표준화 (Standardize): 각자 만들고 각자 버리는 패턴을 챕터 자산으로 누적.
자산화 (Operate): 누적된 자산을 Plugin 단위로 묶어 챕터 전원이 동일하게 받아 쓰는 배포·버전 관리 체계.

이 네 가지가 같은 우선순위가 아니다. 측정과 표준화가 먼저, 학습과 자산화가 그 위다. 측정과 표준이 없으면 학습 효과를 알 수 없고, 자산화는 빈 자산을 묶어 봐야 가치 없다.

5. 측정: AX의 KPI를 무엇으로 잡는가

측정 없는 도입은 비용이다. "AI 쓰니까 좋아진 것 같다"는 인상은 챕터 오너가 의사결정을 정당화하는 데 써서는 안 된다. 챕터에 KPI 측정 체계는 아직 없는 상태이고, 무엇을 KPI로 잡을지부터가 합의 과제다. 내가 KPI 후보로 제안하려는 것은 네 가지다.

활성 사용률 (Daily Active Use): 챕터원 중 그 날 AI 도구를 의미 있게(단순 검색 아닌 코드 작성·리뷰·문서 작성 등에) 사용한 비율. 도구 텔레메트리나 자기 보고로 측정.
통합도 (Workflow Integration Ratio): 한 PR이 머지되기까지의 단계(설계·구현·테스트·리뷰·문서·티켓 갱신) 중 AI가 사람을 1회 이상 보조한 단계 비율.
PR 생산성 변화 (Cycle Time Delta): 티켓 생성 → PR 머지까지 걸린 시간의 분포 변화. 평균이 아니라 분포(P50·P90)를 본다.
잘못된 의존도 (Unverified Merge Rate): AI가 생성한 결과를 사람이 검증하지 않고 머지한 비율. 이 수치가 올라가는 건 위험 신호다.

한 가지 강조하고 싶은 점: 활성 사용률만 올리는 데 집중하면 안 된다. "활성 사용률 80% 달성"이라는 보고서가 보기 좋아도, 잘못된 의존도가 같이 올라가면 챕터의 코드 품질이 망가지는 중이라는 뜻이다. 속도 KPI와 안전 KPI를 같은 보고서에 묶는 것, 그게 챕터 오너가 가져가야 할 책임이라고 본다.

측정은 도구 텔레메트리만으로 부족할 것이다. 격주 1회 익명 설문(2분짜리)으로 멤버의 자기 평가를 같이 모으는 방식을 함께 도입하려 한다. "오늘 도구가 가장 잘 도와준 일은?", "가장 큰 마찰은?" 두 질문이면 충분할 거라고 본다.

6. 표준화의 첫 후보: 이슈 트래커 통합 워크플로우 케이스

표준화가 추상적인 단어로만 남으면 아무것도 일어나지 않는다. 챕터가 실제로 누적해 갈 자산이 있어야 한다. 내가 표준화 1순위 후보로 잡고 있는 것은 "이슈 트래커 통합 워크플로우" 다. 이걸 패턴 단위로 일반화해서 적어 둔다.

Orchestrator + Sub-agent 패턴

문제는 익숙하다. 부모 티켓 하나를 받으면 다음의 단계가 따라온다.

작업을 하위 단위로 분해
하위 티켓을 이슈 트래커에 생성
브랜치 생성 + 상태 전이
각 하위 단위 개발
코드 리뷰
MR 생성

이 6단계 중 4번(개발)에만 사람이 깊이 들어가고, 나머지는 모두 정형화된 노동이다. 게다가 4번도 하위 티켓 간 의존성이 명확하면 병렬 가능하다. 즉 이 워크플로우 전체가 Orchestrator + Sub-agent 패턴으로 묶일 수 있다는 뜻이다.

내가 챕터 표준 후보로 정리해 둔 패턴의 구조는 이렇다. 아직 챕터 차원에서 합의되진 않았고, 다음 격주 패턴 공유 세션에 1순위 안건으로 올릴 예정이다.

한 줄 명령으로 시작. /<orchestrator-skill> <담당자> <부모 티켓 키> 하나면 6단계 전체가 흐른다.

메인 컨텍스트는 의사결정·승인·리포팅만 담당. 무거운 작업(N회 API 호출, 코드 diff, 빌드 로그, 리뷰 출력)은 모두 sub-agent로 위임한다. 메인이 일을 직접 하지 않고, 결과 요약만 받는다.

Phase 분리. Phase 1·2(사전 탐색, 병렬) → Phase 3(사용자 승인, 인터랙션) → Phase 4·6(티켓·상태 전이, 배치) → Phase 7(의존성 DAG 기반 병렬 개발) → Phase 8(자동 리뷰 사이클) → Phase 9(MR 생성). 각 phase의 출력이 다음 phase의 입력으로 흐른다.

모델·effort 차등 할당. 사고가 깊이 필요한 자리(Planner, 코드 작성, 리뷰)는 비싼 모델 + 높은 effort. 정형화된 API 호출이나 페이로드 합성은 싼 모델 + 낮은 effort. 모든 자리에 같은 모델을 쓰는 건 비용 낭비이고, 반대로 사고 단계에 싼 모델을 쓰는 건 산출물 품질 낭비다.

병렬 정책. 의존성이 없는 하위 단위는 N개를 동시에 개발한다(단일 메시지에 N개 agent 블록). 의존성이 있는 자리(예: cherry-pick, 통합 리뷰)는 순차. "병렬화하지 않는 자리"를 명시하는 게 병렬화 자체보다 중요하다.

자동 리뷰 사이클. 코드 작성이 끝나면 자동으로 리뷰 → 수정 → 재리뷰 루프가 돈다. 베스트 케이스는 1사이클에 수렴. 최대 5사이클 후 미수렴 시 사람에게 보고. 사람이 모든 리뷰의 첫 라운드를 보지 않는다. 첫 라운드는 AI가, 사람은 수렴 결과만 본다.

글로벌 원칙. 모든 sub-agent에 공통으로 박는 규칙들이 있다. 예: "이슈 본문·커밋·MR 어디에도 AI 흔적(Co-Authored-By Claude, Generated with Claude 등)을 남기지 않는다", "승인 전에는 리모트 변경 금지", "테스트 없는 결과물 반환 금지". 이 원칙들이 sub-agent 프롬프트마다 반복되어 들어간다.

이 패턴의 진짜 가치는 단순한 자동화가 아니다. "메인 컨텍스트는 의사결정만" 이라는 원칙이 박혀 있다는 점에 있다. 메인이 코드 diff를 직접 보면 컨텍스트가 금세 차서 후반 phase에서 사고력이 떨어진다. 컨텍스트 보호는 LV3 → LV4로 가는 단 하나의 결정적 차이다. LV3까지는 "AI를 잘 쓰는" 자리고, LV4는 "AI 시스템을 설계하는" 자리다.

이 패턴 하나가 챕터의 표준 자산으로 자리 잡으면, 누가 새로 들어와도 이 한 줄 명령으로 평소 반나절 걸리던 정형 노동을 30분에 끝낼 수 있게 된다. 그게 우리가 만들어야 할 표준화의 결과물이다. 한 명의 능력이 아니라 챕터의 평균 능력이 올라가는 것. 다음 6개월의 첫 우선순위는 이 패턴을 챕터 합의로 끌어올려 책임자와 함께 v1으로 굳히는 일이다.

7. 학습: 세미나 다음의 학습 구조

세미나는 LV1과 LV2 사이의 다리를 놓는다. 그 다음의 다리들은 다른 구조여야 한다. 챕터에는 아직 세미나 이후의 학습 구조가 없다. 내가 챕터에 제안하려는 학습 구조는 세 층이다.

(1) 핸드홀딩 (LV1 → LV2)

새 멤버 또는 LV1에 머물고 있는 멤버에게 첫 1주 동안 1:1 페어를 붙인다. 페어는 LV3+ 멤버. 주제는 단순하다.

오늘 일감 중 하나를 골라 AI 도구로 같이 해결한다.
어디서 시간이 절감됐는지, 어디서 오히려 마찰이 늘었는지 같이 기록한다.
1주가 끝나면 그 멤버의 자기 평가를 LV1 → LV2로 끌어올린다.

이 구조의 핵심은 시간 절감을 본인이 직접 체감하는 것이다. 추상적인 설득은 효과가 없다.

(2) 페어 작성 세션 (LV2 → LV3)

LV2 멤버 두 명이 한 자리에 앉아 자신의 워크플로우에서 가장 반복적인 정형 노동을 skill 또는 sub-agent로 만든다. 격주 1회 90분. 산출물은 매번 하나의 skill 또는 하나의 sub-agent.

이 자리에서 만들어진 자산이 챕터의 공용 저장소에 올라간다. 옆 사람이 만든 skill을 다음 주에 자기 워크플로우에 끼워 쓰는 경험을 한 번 하면, LV2 → LV3가 자연스럽게 일어난다.

(3) 격주 패턴 공유 세션 (LV3 → LV4)

LV3+ 멤버들이 격주 1회 모여 자신의 워크플로우에서 새로 발견한 패턴을 공유한다. 짧은 데모 + 짧은 토론. 형식보다 빈도가 중요하다.

이 자리에서 결정되는 것 중 하나가 "이 패턴은 챕터 표준으로 올린다" 라는 판단이다. 모든 패턴이 표준이 되지는 않는다. 2~3명이 독립적으로 같은 패턴을 발견했을 때가 표준화 신호다. 한 사람의 취향은 표준이 되지 않는다.

8. 표준화의 자산 카탈로그

학습이 자산을 만들면, 그 자산을 어디에 어떻게 보관하느냐가 표준화의 실체다. 챕터에 자산 카탈로그라고 부를 만한 운영 체계는 아직 없다. 내가 챕터에 제안하려는 자산 카탈로그의 다섯 범주는 이렇다. 다섯 범주를 각각 따로 굴리지 않고, 다음 9번 섹션에서 다룰 Plugin이라는 하나의 배포 단위로 묶어 챕터원이 한 번에 받아 쓰게 한다.

공용 CLAUDE.md 베이스라인: 모든 챕터 프로젝트에 기본으로 들어가는 컨벤션. 코드 스타일·테스트 규칙·금지 사항·언어(한글 응답 등). 변경은 ADR 한 페이지를 거친다.
Skill 카탈로그: 챕터 멤버 누구나 호출할 수 있는 공용 skill 모음. 카테고리는 "이슈 트래커 통합", "코드 리뷰", "마이그레이션 가이드 작성", "문서화" 등. 각 skill에는 책임자 1명이 명시된다.
Sub-agent 카탈로그: 위와 동일한 구조. 단, sub-agent는 메인 skill이 호출하는 자리라 카탈로그가 더 작다. 종류가 너무 많으면 오히려 메인이 어떤 걸 호출할지 결정 못 한다.
Hook 컨벤션: PreToolUse / PostToolUse / Stop hook의 사용 규칙. 보안 hook(예: 비밀번호 노출 차단)은 챕터 표준으로 전부 강제.
Output Style 컨벤션: 응답 톤·길이·언어. 한국어 응답 default, 코드 주석은 영어 등.

각 자산에는 책임자 1명을 명시해야 한다는 게 같이 제안하려는 운영 원칙이다. "공용 자산은 모두의 것"이라는 말은 듣기 좋지만, 책임자가 없으면 6개월 안에 망가진다고 본다. 책임자가 있어야 PR이 들어왔을 때 누가 머지를 판단할지가 명확해진다.

9. 정책: CLAUDE.md와 rules를 챕터 합의로 굳힌다

8장의 다섯 범주 중 CLAUDE.md와 rules(예: .claude/rules/ 안에 누적되는 코드 스타일·보안·도메인·워크플로우 규칙)는 다른 자산과 결이 다르다. skill·sub-agent·hook은 호출되는 능력이지만, CLAUDE.md와 rules는 모든 호출의 기반에 항상 깔려 있는 정책이다. 매 요청의 컨텍스트로 자동 동봉되고, sub-agent 프롬프트마다 반복 주입되며, 멤버 누군가가 한 줄을 수정하면 챕터 전원의 일이 그날부터 달라진다.

그래서 이건 단순한 자산 관리가 아니라 챕터의 헌법을 만들고 갱신하는 절차라고 본다. 챕터에는 아직 이 헌법의 합의 메커니즘이 없다. 내가 합의를 제안하려는 운영 형태는 셋의 축으로 정리된다.

9-1. 위계: global · chapter · project 세 층

정책을 한 덩어리로 두면 충돌이 일어난다. 챕터 표준이 특정 프로젝트의 도메인 규칙을 덮어 쓰거나, 반대로 프로젝트 임시 규칙이 챕터 전반의 표준을 흩어 놓는다. 그래서 정책은 세 층의 위계로 둔다고 본다.

Global (개인): ~/.claude/CLAUDE.md. 개인 선호·환경 의존(예: "한국어로 응답", "코드 주석은 영어"). 챕터가 관여하지 않는다.
Chapter (팀): Plugin으로 배포되는 공통 정책. 코드 스타일·보안·테스트·도메인·AI 흔적 제거 같은 사내 컨벤션. 챕터 전원이 같은 버전을 쓴다.
Project (저장소): 각 저장소 루트의 CLAUDE.md. 그 프로젝트의 도메인·아키텍처·금지 사항. 챕터 정책을 오버라이드하지 않고 보완한다.

위계 규칙은 단순히 하나만 둔다. 하위가 상위를 부정할 수 없다. 프로젝트 CLAUDE.md가 챕터 정책에 적힌 "AI 흔적 제거"를 끄지 못한다. 부정이 아닌 추가만 허용한다. 이 규칙이 무너지면 위계의 의미가 없다.

9-2. 변경 절차: ADR 기반 합의

정책 변경의 가장 큰 함정은 "한 명이 좋아 보여서 슬쩍 머지한다" 이다. 정책은 모든 작업의 기반에 깔리므로, 한 줄의 변경이 챕터 전원의 행동을 바꾼다. 그래서 정책 변경에는 다른 자산보다 무거운 절차가 필요하다.

내가 제안하려는 절차는 ADR(Architecture Decision Record) 기반 합의다.

제안 (Proposed): 변경을 원하는 멤버가 한 페이지 ADR을 작성해 MR 올린다. ADR에는 변경 내용, 이유, 영향 범위, 검토된 대안, 그리고 롤백 시나리오가 들어간다.
공개 검토 (Review): 격주 패턴 공유 세션에서 5분 안건으로 다룬다. 모든 LV3+ 멤버에게 노출. 비공개 머지를 막는 게 핵심.
합의 (Accepted): 책임자 + 챕터 오너의 approve. 합의되면 plugin minor/major bump와 함께 배포.
폐기 (Superseded): 새 ADR이 기존을 대체하면 기존 ADR을 Superseded by ADR-NNNN으로 마킹. 삭제하지 않는다. 왜 그렇게 바꿨는지의 흐름이 보존된다.

이 절차의 무게가 의도된 무게다. 정책은 자주 바뀌면 정책이 아니게 된다. 한 분기에 들어오는 정책 ADR이 3~5개를 넘으면 정책 합의 체계 자체가 흔들리고 있다는 신호다.

9-3. 글로벌 원칙: 모든 sub-agent에 반복 주입되는 한 줄들

CLAUDE.md와 rules의 정책이 진짜로 강제되려면, sub-agent 호출 때 그 정책이 프롬프트에 반복 주입돼야 한다. 메인이 잘 지키더라도 sub-agent가 그 약속을 모르면 깨진다. 6장에서 짧게 짚었던 글로벌 원칙들이 이 자리에 들어간다. 챕터 차원에서 합의하고 plugin에 박아 두려는 글로벌 원칙 후보는 이런 것들이다.

AI 흔적 제거: 커밋 메시지, MR 본문, 이슈 댓글 footer 어디에도 Co-Authored-By Claude, Generated with Claude Code 같은 라인 금지.
승인 없는 리모트 변경 금지: 사용자 승인 전에 이슈 생성·브랜치 push·MR 생성 금지.
테스트 없는 결과물 반환 금지: subtask-developer는 코드만 변경하고 테스트 없이 종료하지 않는다.
한글 리터럴 보존: 이슈 본문·커밋 메시지에 한글을 \uXXXX 유니코드로 이스케이프하지 않는다(ADF 변환 시 깨짐).
빌드 검증 범위: compile main 단독이 아니라 compile main + test까지 통과해야 완료.
민감 정보 차단: 환경 변수·시크릿·운영 DB 접속 정보는 컨텍스트에 절대 노출 금지(hook 보강).

이 원칙들을 한 자리에 모아 두고, sub-agent 프롬프트 템플릿이 자동으로 prepend하게 한다. 사람이 매번 복붙하지 않는다.

한 가지 강조하고 싶다. 정책은 "지키자"는 합의가 아니라 "자동으로 지켜지게 한다"는 설계다. CLAUDE.md에 적어 둔 한 줄을 멤버 모두가 의지로 지킬 거라고 믿는 순간 정책은 무너진다. hook으로 검증하거나, sub-agent 프롬프트에 자동 주입하거나, CI 게이트로 막거나 중 하나의 자동화 장치가 같이 따라와야 그 정책은 산다.

9-4. 정책의 적용 형태: 자동 컨텍스트 · hook · CI 게이트

같은 정책이라도 어디서 강제되는지가 효력을 결정한다. 우리가 적용 형태를 셋으로 나눠 두려는 이유다.

자동 컨텍스트 (CLAUDE.md / rules import): 모든 요청에 컨텍스트로 동봉. "이렇게 해 줬으면 한다"는 가이드. 위반해도 동작은 한다. 가장 약한 강제력.
Hook 차단: PreToolUse / PreCommit hook으로 위반을 동작 자체에서 막는다. "비밀번호 패턴이 커밋에 들어가면 차단" 같은 자리. 가장 강한 강제력.
CI 게이트: MR 단계에서 정적 분석·테스트로 검증. 자동 컨텍스트와 hook 사이의 중간 강제력.

정책마다 적합한 강제력이 다르다. "AI 흔적 제거"는 CI 게이트가 어울리고(MR에 들어오면 막는다), "민감 정보 차단"은 hook이 맞고(요청 단계에서 막는다), "한글 리터럴 보존"은 자동 컨텍스트로 안내하는 게 충분하다. 정책 ADR을 쓸 때 어느 강제력 층에 둘 것인가를 함께 적는다.

9-5. 정책 본문과 강제력 자산의 분리

여기서 한 가지 분명히 짚어 둬야 할 게 있다. CLAUDE.md와 rules/ 같은 정책 본문은 Claude Code Plugin이 패키징할 수 있는 컴포넌트가 아니다. Plugin이 들고 갈 수 있는 건 실행되는 자산(skills, commands, agents, hooks, MCP servers, output styles)에 한정된다. 공식 문서가 명시하듯, plugin 루트의 CLAUDE.md는 프로젝트 컨텍스트로 로드되지 않는다.

이 사실이 정책 운영을 두 갈래로 분리시킨다. 내가 챕터에 제안하려는 분리 형태는 이렇다.

정책 본문 (Policy Repo): CLAUDE.md, rules/, docs/adr/를 담는 별도의 사내 Private GitLab repo. 챕터원이 자기 프로젝트 루트에 git submodule 또는 사내 dotfiles 동기화 스크립트로 가져온다. 변경은 MR + ADR.
정책 강제력 (Chapter Plugin): 정책을 실제로 강제하는 자산만 Plugin으로 패키징. 즉 hook(예: 민감 정보 차단·AI 흔적 검출), skill의 SKILL.md system prompt에 박힌 글로벌 원칙, agent의 system prompt에 박힌 동일 원칙. Plugin이 활성화되면 sub-agent 호출 때 그 정책이 자동 prepend된다.

같은 정책이 두 저장소 양쪽에 동시에 표현돼야 한다는 점이 운영의 까다로움이다. "AI 흔적 제거"라는 한 가지 정책이, Policy Repo의 rules/global-principles.md에 본문으로 존재하고, Chapter Plugin의 hook과 sub-agent system prompt 안에 강제력으로 존재한다. 두 곳이 어긋나면 정책이 깨진다. 그래서 정책 ADR을 쓸 때 두 저장소 양쪽의 PR을 같은 ADR 번호로 묶는 규약을 같이 두려고 한다.

10. 자산화: Private GitLab Plugin으로 묶는다

8번에서 정리한 다섯 범주의 자산을 그대로 흩어진 파일로 관리하면 6개월 안에 다시 무질서로 돌아간다. 누가 어떤 버전을 쓰는지 알 수 없고, 누가 수정했는지 추적되지 않으며, 새로 합류한 챕터원은 어디서 어떤 자산을 가져와야 할지 알지 못한다. 그래서 자산을 하나의 배포 단위로 묶는 운영 형태가 필요하다. 내가 챕터에 제안하려는 형태는 사내 Private GitLab을 Claude Code Plugin marketplace로 쓰는 방식이다.

Claude Code의 Plugin은 skills, agents, commands, hooks, output-styles, MCP 서버 정의를 하나의 디렉토리로 묶은 패키지다. marketplace에 등록만 되어 있으면 /plugin marketplace add <git-url> 한 줄로 챕터원의 환경에 표준 자산이 동일하게 깔린다. 우리가 만들 챕터 plugin 묶음의 구조는 이렇게 잡으려 한다.

backend-chapter-plugin/             # 사내 GitLab Private repo (Plugin)
├── .claude-plugin/
│   └── plugin.json                 # name, version, description
├── skills/                         # 호출 가능한 능력
│   ├── issue-tracker-workflow/     # 이슈 트래커 통합 워크플로우 (6장)
│   │   └── SKILL.md                #   - system prompt 안에 글로벌 원칙 박힘
│   ├── migration-plan-writer/      # 마이그레이션 가이드 작성
│   └── code-review-cycle/          # 자동 리뷰 사이클
├── agents/                         # sub-agent
│   ├── planner.md                  # Opus · max  (system prompt에 글로벌 원칙)
│   ├── subtask-developer.md        # Opus · high
│   ├── review-cycler.md            # Opus · high
│   ├── issue-bulk-operator.md      # Haiku · low
│   └── mr-creator.md               # Sonnet · low
├── hooks/                          # 정책 강제력 (PreToolUse / PreCommit)
│   └── hooks.json                  # 민감 정보 차단·AI 흔적 검출
├── output-styles/
│   └── chapter-default.md          # 한국어 응답·코드 영어 주석 등
└── CHANGELOG.md

여기서 이 plugin에 CLAUDE.md·rules/·docs/adr/는 들어가지 않는다는 점을 한 번 더 짚어 둔다. Claude Code Plugin은 실행되는 자산(skill·agent·hook·MCP·output style·command)만 패키징한다. 9-5에서 정리한 대로 정책 본문은 별도의 Policy Repo에서 관리되고, 챕터원의 프로젝트 루트에 submodule 또는 dotfiles 형태로 가져간다. Plugin은 그 정책을 실제로 강제하는 자산만 담는다.

backend-chapter-policy/             # 사내 GitLab Private repo (Policy Repo)
├── CLAUDE.md                       # 챕터 베이스라인
├── rules/
│   ├── global-principles.md
│   ├── code-style.md
│   ├── testing.md
│   ├── security.md
│   └── domain-rules.md
├── docs/adr/
│   └── 0001-ai-trace-removal.md
└── CHANGELOG.md

즉 챕터원이 받아 쓰는 자산은 Plugin marketplace 한 곳 + Policy Repo 한 곳, 두 저장소다. Policy Repo의 한 줄이 바뀌면 ADR이 동반되고, 같은 ADR 번호로 Plugin 쪽의 hook이나 sub-agent system prompt가 함께 갱신된다.

설치는 단순하다.

/plugin marketplace add gitlab.<our-domain>/backend-chapter/plugin-marketplace
/plugin install backend-chapter@chapter-marketplace

이 운영 형태가 가져오는 가치는 넷이다.

버전 관리: v1.0.0, v1.1.0, v2.0.0. semver로 표시되니 챕터원이 어떤 버전을 쓰고 있는지 분명해진다. breaking change(예: 글로벌 원칙 변경, sub-agent 입력 스키마 변경)는 major bump로 알린다.
변경 이력: GitLab MR/commit이 그대로 자산의 변경 이력이다. "왜 이 글로벌 원칙이 들어왔지?"라는 질문에 commit log + ADR이 답을 한다.
권한과 감사: Private GitLab의 group access control이 그대로 자산의 접근 권한. 사내 SSO·감사 로그가 별도 작업 없이 따라온다.
CI 게이트: marketplace repo에 머지되기 전 CI에서 plugin.json 스키마 검증, skill markdown 헤더 검증, 위험 hook 정적 분석 등을 돌릴 수 있다. 자산이 안전한 상태로만 챕터원에게 배포되게 한다.

이 자리에서 한 가지 강조하고 싶다. "Plugin marketplace를 사내에서 운영한다"는 결정 자체가 거버넌스다. 별도 위원회나 별도 도구가 필요 없다. PR/MR이 들어오면 책임자가 리뷰하고, 통과되면 다음 버전으로 자동 배포된다. 가장 단순한 형태가 가장 오래 간다.

운영 규칙은 가볍게 셋만 박는다.

모든 plugin 변경은 MR을 거친다. 직접 push 금지. 책임자 1명의 approve가 필요.
breaking change는 ADR과 함께. plugin의 major bump는 docs/adr/ 안의 한 페이지짜리 ADR을 동반.
CHANGELOG는 한국어로 두 줄 이내. "v1.2.0: 이슈 트래커 통합 워크플로우에 자동 리뷰 사이클 추가" 정도면 충분.

자산을 plugin으로 묶는다는 한 가지 결정이 표준화의 운영 형태와 거버넌스를 동시에 해결한다. 챕터 차원에서 이걸 합의로 끌어올리는 게 6개월 차의 가장 큰 매듭이다.

11. 6개월 로드맵

여기까지의 정리를 챕터 운영 계획으로 압축한다.

Month 1: 측정 인프라 + 정책 베이스라인

도구 텔레메트리 수집 설정(가능한 범위 안에서).
격주 2분 설문 시작.
Policy Repo 생성. 공용 CLAUDE.md 베이스라인 v1 + rules 핵심 5종(global-principles · code-style · testing · security · domain-rules) 합의. ADR 1호로 박는다.
LV1 멤버 식별. 핸드홀딩 페어 매칭.

Month 2~3: 표준 자산 첫 묶음

이슈 트래커 통합 워크플로우 skill v1 머지. 책임자 지정.
페어 작성 세션 시작(격주 1회).
자산 카탈로그 운영 규칙 ADR.
KPI 첫 베이스라인 측정.

Month 4: 학습 구조 본격화

LV2 → LV3 페어 작성 세션 정착.
LV3+ 패턴 공유 세션 시작.
1차 KPI 리포팅. 안전 KPI(잘못된 의존도)도 같이.

Month 5: 안정화

자산 카탈로그 v2. 사용 빈도 낮은 자산 정리.
LV1 비율 목표(10% 미만) 점검.
자동 리뷰 사이클의 수렴률·실패율 측정.

Month 6: 자산화 v1 배포

Backend Chapter Plugin v1.0.0을 사내 GitLab marketplace에 배포. 6장의 이슈 트래커 통합 워크플로우 skill + 핵심 sub-agent 묶음 + 정책 강제력 hook + output style을 하나의 plugin으로 묶는다.
Policy Repo와 Plugin이 같은 ADR 번호로 동기화되어 있는지 점검. 어긋난 정책 없음을 확인.
챕터 전원 /plugin marketplace add ... 한 번 + Policy Repo submodule 한 번으로 동일한 표준 환경 확보. 책임자 각 1명 명시.
2차 KPI 리포팅. 속도 KPI와 안전 KPI(잘못된 의존도)를 같은 슬라이드에 둔다.
다음 분기 우선순위 결정: plugin v1.x 안정화 vs 새 skill 묶음 추가.

12. 시니어 시선 인사이트

① 챕터 오너의 일은 도구 평가가 아니라 가용 능력 분배다

새 도구가 매주 나온다. 매주 평가해 보고 싶은 욕구가 생긴다. 그건 챕터 오너의 일이 아니다. 챕터 오너의 일은 챕터의 평균 멤버가 안전하게 호출할 수 있는 워크플로우를 설계하는 것이고, 이미 검증된 도구의 활용도를 끌어올리는 것이 새 도구를 평가하는 것보다 훨씬 큰 ROI를 낸다.

새 도구는 LV4 멤버 한 명에게 평가를 위임한다. 그가 한 달 뒤 "이건 챕터에 가져올 가치가 있다" 또는 "아직 아니다"를 판단하면 된다.

② 측정 없는 전환은 비용일 뿐이다

"AI 쓰니까 좋아진 것 같다"는 인상은 의사결정 근거가 될 수 없다. 챕터 오너로서 가장 두려운 자리는 "좋아진 것 같은데 사실은 코드 품질이 망가지고 있는 상태" 다. 속도 KPI와 안전 KPI를 항상 같이 본다. 잘못된 의존도가 같이 올라간다면 그건 전환이 아니라 부채 누적이다.

측정이 부담스럽다는 말이 가장 많이 나온다. 부담스러운 측정은 안 한다. 격주 2분 설문 + 도구 텔레메트리 두 가지면 충분하다. 측정의 비용보다 측정이 없을 때의 비용이 훨씬 크다.

③ 표준화는 자산이 누적될 때만 의미가 있다

"표준을 만들자"는 회의가 결과 없이 끝나는 가장 흔한 자리다. 표준은 자산이 누적되는 자리에서 발견되는 것이지, 회의로 합의되는 게 아니다.

페어 작성 세션이 격주로 돌아 6개월간 24개의 skill이 챕터 저장소에 올라왔다면, 그중 자주 쓰이는 5~6개가 표준이 된다. 회의로 "이걸 표준으로 하자" 결정하는 게 아니라, 자주 쓰이는 자산이 자연스럽게 표준이 되는 흐름을 만든다.

④ LV3과 LV4의 차이는 컨텍스트 보호다

LV3까지는 "AI를 잘 쓰는 사람"이다. LV4는 "AI 시스템을 설계하는 사람"이다. 둘 사이의 단 하나의 결정적 차이는 메인 컨텍스트를 보호한다는 사고다.

LV3 멤버는 한 세션 안에서 모든 일을 직접 한다. 코드 diff도 직접 보고, 빌드 로그도 직접 본다. 컨텍스트가 금세 찬다. LV4 멤버는 sub-agent에 격리시키고, 자신은 결과 요약만 받는다. 컨텍스트 보호가 곧 사고력 보호다.

챕터 오너의 일 중 하나는 이 단 하나의 차이를 LV3 멤버들에게 정확히 가르치는 것이다. 이건 도구의 기능 설명이 아니라, 시스템 설계의 멘탈 모델이다.

⑤ 정책은 의지로 지켜지지 않는다, 자동화 장치로 지켜진다

CLAUDE.md에 "AI 흔적을 남기지 말자"라고 적는 것과, 그 정책이 실제로 지켜지는 것은 다른 일이다. 정책을 글로 적어 두고 "지키자"고 합의하는 순간, 3개월 뒤 챕터의 절반은 그 정책을 잊는다. 이건 멤버의 의지 문제가 아니라, 사람의 주의력에 의존한 정책은 반드시 깨진다는 일반 법칙이다.

그래서 챕터 오너로서 정책을 합의로 끌어올릴 때 항상 같이 결정해야 하는 것이 "이 정책은 어디서 자동으로 지켜지게 할 것인가" 다. 자동 컨텍스트(CLAUDE.md / rules 자동 주입), hook 차단, CI 게이트 중 하나가 정책마다 붙어야 한다. 자동화 장치 없는 정책은 ADR이 아니라 메모일 뿐이다.

⑥ 6개월은 짧지 않다, 그러나 충분하지도 않다

흔히 "AX 전환은 1~2년 걸린다"는 말이 나온다. 그 말도 맞고, "6개월 안에 의미 있는 변화를 만들지 못하면 전환은 결국 안 일어난다"는 말도 맞다. 두 명제가 모순이 아니다.

6개월은 챕터의 평균 멤버가 자신의 워크플로우 변화를 인지하기에 충분한 시간이다. 그 인지가 일어나면, 그 다음 1년은 빠르게 흐른다. 6개월 안에 그 인지를 만들지 못하면, 그 다음 1년은 처음 6개월의 반복일 뿐이다.

그래서 6개월 로드맵은 빠르게 가기 위한 계획이 아니라, 정확히 어느 시점에 어떤 자산이 있어야 하는지를 정하는 계획이다. 빠르게 가는 게 목표가 아니라, 6개월 후에 챕터의 가용 능력이 측정 가능하게 늘어나 있는 것이 목표다.

마무리: 한 문장으로 줄이면

세미나는 챕터에 awareness를 만든다. AI Native 전환은 그 awareness를 workflow integration으로 옮기는 일이고, 그 일은 측정·학습·표준화·자산화라는 네 축을 동시에 굴려야 한다. 한 축만 빠져도 나머지가 망가진다.

다음 액션 아이템은 다섯이다.

측정 인프라 v1: 격주 2분 설문 + 도구 텔레메트리. 베이스라인 측정 한 달 내.
챕터 정책 베이스라인: 공용 CLAUDE.md + rules 핵심 5종(global-principles·code-style·testing·security·domain-rules)을 ADR 1호로 합의. 정책마다 강제력 층(자동 컨텍스트 / hook / CI 게이트) 명시.
공용 자산 카탈로그 첫 묶음: 이슈 트래커 통합 워크플로우 skill 한 개. 책임자 1명 지정.
학습 구조 시작: LV1 핸드홀딩 페어 매칭 + LV2 페어 작성 세션 격주 시작.
두 저장소 골조 동시 생성: 사내 Private GitLab에 (a) Policy Repo(CLAUDE.md · rules/ · docs/adr/)와 (b) Chapter Plugin marketplace repo(plugin.json 스키마 + CI 게이트)를 같이 만든다. Plugin의 첫 콘텐츠는 정책 본문이 아니라 정책 강제력 hook 한 개 + 글로벌 원칙이 박힌 sub-agent system prompt. 나머지 자산은 누적되는 대로 채워 넣는다.

세미나를 끝낸 다음 주에 들어온 "이제 뭘 해야 하나요?"라는 질문에 대한, 챕터 오너로서의 답은 이거다. 세미나는 도착점이 아니라 출발점이었다. 앞으로 6개월, 측정 가능한 가용 능력 증가를 만들어 내는 게 다음 무대다. 그 무대에 같이 서 있는 챕터원들이 있다는 게, 이 출발점이 가질 수 있는 가장 큰 자산이다.