팀에 AI를 강제로 이식하기로 했습니다

안녕하세요, DevOps 챕터(같은 직무끼리 묶인 팀 단위입니다)의 sabo입니다. 지난 글에서 제 터미널의 AI 오케스트레이션 세팅 — 비싼 모델은 지휘만 하고 실행은 값싼 모델에 위임하는 구성 — 얘기를 했는데요. 세팅을 다듬을수록 이상한 기분이 들더라고요. 나는 점점 편해지는데, 옆자리는 그대로였습니다. 장애 일지 자동화도, 인프라 문서를 읽고 답하는 AI도 전부 제 로컬에만 있었습니다. 챕터를 책임지는 사람이 자기 생산성만 올리고 있으면 그건 그냥 취미 생활이죠.

그래서 챕터 차원의 AX(AI Transformation — 일하는 방식 자체에 AI를 이식하는 것)를 시작하기로 했습니다. 이 글은 그 계획입니다 — 왜 이런 고민을 하게 됐고, 어떻게 풀기로 했는지. 실제로 만들면서 겪는 이야기는 다음 편부터 씁니다.

설득 대신 강제

교과서적으로 하자면 팀원별 AI 활용 수준을 진단하고, 수준에 맞는 온보딩을 설계해야 합니다. 우리는 그렇게 안 하기로 했습니다. 전원이 한자리에 모여 구두로 합의할 수 있는 규모의 챕터에서 그건 오버엔지니어링이거든요. 협의를 거쳐서, AI 활용 방식을 팀에 그냥 강제 이식하기로 했습니다.

대신 조건이 하나 붙습니다. 강제가 작동하려면 "AI 쓰세요"가 아니라 "clone 받고 이 스킬로 이 업무 하세요"가 되어야 합니다. 명령만 있고 도구가 없으면 반발만 남으니까요. 그래서 이 계획의 대부분은 그 '바로 쓸 수 있는 도구'를 만드는 일입니다.

지식을 어디에 둘 것인가

AI 활용의 품질은 결국 AI에게 줄 수 있는 컨텍스트의 질로 결정됩니다. 그런데 그 지식이 제 로컬 곳곳에 흩어져 있었습니다. 정리하면서 잡은 원칙은 하나입니다. 변하는 지식은 조회하게 하고, 안 변하는 지식만 문서화한다.

• 런타임 인프라 상태 — 문서화하지 않습니다. kubectl, aws cli로 AI가 직접 조회합니다. 문서로 만드는 순간 썩기 시작하니까요. 문서에는 데이터가 아니라 "어떤 도구로 어떻게 조회하는지"만 남깁니다.
• 구성도, 서비스 용도 같은 정적 지식 — 자주 바뀌지 않는 것들이라 문서로 저장합니다.
• 자격증명 — Vault와 개인별 .env.local. 지식 레포에는 절대 들어가지 않습니다.
• 장애 사례, 트러블슈팅 이력 — 장애 대응 기록을 남기는 사내 장애처리일지 시스템과, 작업 디렉토리마다 두는 HISTORY.md(작업 경과 일지)에 쌓입니다.
• 절차 지식 — 이게 재미있는 부분인데, "장애 일지는 이렇게 쓴다" 같은 절차는 문서가 아니라 AI 스킬 자체로 코드화합니다. 스킬이 곧 지식베이스인 셈이죠.
• 결정 기록 — "왜 이 구조인가"는 가장 가치 있는데 가장 안 남는 지식입니다. 결정이 나올 때마다 한 단락씩이라도 남기기로 했습니다.

원칙을 세우자마자 예외도 발견했습니다. 도메인·인증서 인벤토리는 분명히 '변하는 데이터'인데 조회로 대체가 안 됩니다. 등록기관이 여러 곳이라 단일 CLI 조회가 불가능하거든요. 이런 건 어쩔 수 없이 스냅샷 문서로 남기되, 규칙을 붙였습니다. 스냅샷 문서는 상단에 갱신일을 반드시 적고, AI가 인용할 땐 "몇 월 기준"을 붙인다.

지식을 담을 그릇은 새로 만들 필요가 없었습니다. 얼마 전 인프라 지식과 접근 스크립트를 단일진실원천(SSOT, Single Source of Truth)으로 모아둔 레포가 이미 있었는데, 그게 그대로 "팀원 누구나 clone하면 자기 AI가 같은 지식을 갖는" 컨텍스트 레포 자리에 들어맞았습니다. 여기에 공용 스킬과 설정을 얹으면 됩니다.

컨텍스트도 코드처럼 — 다만 프로세스는 팀 크기만큼만

CLAUDE.md, 스킬, 훅 설정 같은 AI 컨텍스트는 GitLab으로 형상관리합니다. 이 바닥의 발전 속도상 컨텍스트도 계속 고도화될 게 뻔하거든요. 문서로 흩어지면 팀원마다 다른 AI를 쓰는 것과 같아집니다.

머지 절차는 일부러 가볍게 갑니다. 처음엔 MR 열고 정기 미팅에서 협의해 머지하는 그림도 그려봤는데, 이 인원 규모에서 그런 게이트는 형식이지 안전장치가 아닙니다. 어차피 옆자리에서 "이거 바꿀게요" 한마디면 끝날 일이니까요. 구두로 협의하고 main에 바로 머지합니다. 프로세스는 팀 크기에 맞아야지, 교과서에 맞을 필요가 없습니다.

가드레일은 얘기가 다릅니다. 이건 절차가 아니라 코드로 강제합니다. "live 서버 변경 전엔 확인하세요"라고 적어두는 게 아니라, live 패턴이 감지되면 실행 전에 확인을 강제하는 훅을 컨텍스트 레포에 넣어서 배포하는 방식입니다. 정책 문서가 아니라 설치되는 정책. 파괴적 명령 차단, GitOps 원본 우회 수정 금지, 시크릿 출력 방지, 그리고 누가 AI로 어떤 명령을 실행했는지 남는 감사 로그까지 같은 방식으로 갑니다. 권한도 처음엔 조회 전용 티어로 시작해서 단계적으로 풉니다.

상주 에이전트를 만들려다 접은 이야기

계획 중에 제일 애착이 갔던 아이디어가 있습니다. 팀원 각자의 PC에 협업 에이전트를 상주시키는 겁니다. 각 에이전트가 그 사람의 업무 디렉토리를 읽을 수 있고, 같은 네트워크 대역에서 API처럼 호출하면 "그 사람 지금 뭐 하고 있어?"에 답해주는 구조. 세션은 계속 유지하고요. 꽤 그럴듯해 보였습니다.

AI에게 이 설계를 리뷰시켰더니 반대하더군요. 근거가 뼈아팠습니다. 첫째, 제가 쓰려던 AI 실행 방식은 질문 하나 받아 답하고 종료되는 일회성이라 상주 서버 구조와 안 맞고, 억지로 세션을 길게 유지하면 대화 맥락이 계속 부풀면서 비용과 답변 오염이 같이 옵니다. 둘째, 파일시스템 접근 권한을 가진 AI를 포트로 노출하면 사무실 대역에 보안 구멍이 팀원 수만큼 생깁니다. 한쪽에서는 가드레일을 제도화하자면서 다른 쪽에서 구멍을 N개 뚫는 셈이라고요. 셋째, PC마다 미니 서비스를 하나씩 운영하게 됩니다. 재부팅, 프로세스 죽음, 버전 관리까지.

결정적이었던 건 이 한마디였습니다. 상태를 세션에 두지 말고 git에 둬라. 어차피 컨텍스트를 GitLab으로 형상관리하기로 했으니, 업무 현황도 똑같이 하면 된다는 겁니다.

그래서 계획이 이렇게 바뀌었습니다. 업무 현황 공유용 레포를 따로 두고, 팀원은 약속된 작업 디렉토리 컨벤션(YYMM_작업명/ + HISTORY.md)대로 일하면서 그 디렉토리를 이 레포로 공유합니다. "누가 뭐 하고 있어?"는 각자의 AI가 레포를 읽고 답합니다. 서버 0대, 세션 관리 없음, 보안 표면은 기존 GitLab 권한 그대로. 게다가 업무 이력이 git에 영구히 쌓이면서 위의 '이력 지식'과 자연스럽게 합쳐집니다.

컨텍스트 레포에 합치지 않고 분리하는 이유도 분명합니다. 컨텍스트 레포는 사람이 협의하고 반영하는 곳인데, 업무 현황은 무인 자동 커밋으로 쌓이는 곳입니다. 변경 주체가 다른 걸 한 레포에 섞으면 자동 커밋이 컨텍스트를 오염시킵니다.

사람이 깜빡하는 문제는 사람을 고치는 대신 자동화하기로 했습니다. 스케줄러가 알아서 커밋하고 푸시하고, 커밋 메시지도 쌓인 diff를 저렴한 모델에게 요약시켜서 자동으로 답니다. 약속을 사람의 성실함에 맡기지 않으려고요.

효과 파악을 위한 기록

도입 효과를 나중에 보고하려면 지금의 상태를 기록해둬야 합니다. 나중엔 못 잽니다. 장애 MTTR, MR 리뷰 리드타임, 그리고 업무 인벤토리를 정리하면서 업무별 소요시간을 자기신고로 받아둡니다. 이게 베이스라인입니다.

마치며

정리하면 — 지식은 "변하면 조회, 안 변하면 문서" 원칙으로 컨텍스트 레포에 모으고, 가드레일은 문서가 아니라 훅으로 설치하고, 업무 현황은 상주 에이전트 대신 git과 자동 커밋으로 공유하고, 시작 전에 베이스라인부터 재둡니다. 별도의 일정표는 없습니다. AI와 함께 틈나는 대로 굴리는 프로젝트라, 마일스톤 같은 걸 세워봐야 어차피 안 지켜지거든요.

계획은 늘 계획대로 안 되죠. 어디서 어떻게 어긋나는지가 다음 편부터의 본편이 될 겁니다. 비슷한 규모의 팀에서 AI 도입을 고민하는 분들께 이 계획이 참고가 되길 바랍니다. 읽어주셔서 감사합니다.