같은 도구를 깔아도 결과가 갈린다 — 조직 운영과 부서 자동화 18문답

AI를 조직에 들이려는 자리에서는 물음이 거의 정해진 차례로 돌아온다. "무엇부터 바꾸나", "생산성이 올랐는지 어떻게 재나", "강제해야 하나", "도구가 너무 많은데 어떻게 줄이나" 같은 것들이다. 부서 자동화로 넘어가면 "어느 부서부터인가", "어디서 멈추나", "에이전트는 몇 개인가"가 그 뒤에 붙는다.

이 글은 그 열여덟 문항에 결론부터 답하고 근거를 뒤에 붙인다. 각 문항이 담는 것은 판정 한 줄과 그것을 받치는 근거까지다. 표·수치·각론은 이미 발행된 글이 갖고 있으므로 그쪽으로 넘긴다. 한 내용을 두 자리에서 읽게 하지 않는 것이 이 글의 규칙이다.

조직 전체의 틀은 빌더에서 오케스트레이터로 가는 조직 설계, 단계마다 사람이 승인하는 자리는 요구사항에서 운영까지 여섯 게이트와 개발·QA·배포 각론, 팀 인프라와 성숙도는 팀 공유 인프라 넷과 성숙도 0 → 1 → N, 부서 자동화의 공통 골격은 7부서 30에이전트의 공통 골격에 있다. 나머지 편은 각 문항이 자기 자리에서 연다.

핵심 판정 기준 정리

자주 걸리는 갈림길을 먼저 한 표에 모았다. 어느 쪽이 정답인가보다 무엇을 보고 가르는가가 요점이다. 아래 분류는 이 글이 열여덟 문항에서 골라 배열한 것이다.

Q. AI로 증강된 조직은 무엇부터 바꾸나

도구가 아니라 그 도구가 증폭할 시스템부터다. AI는 해결책이 아니라 증폭기라서, 잘 굴러가는 조직은 더 잘 굴러가게 하고 망가진 조직은 더 빨리 망가뜨린다.

그래서 먼저 깔 것은 도구 목록이 아니라 넷이다 — 명확한 AI 방침, 작은 배치, 리뷰 게이트, 쓸 만한 데이터. 순서를 뒤집으면 도구는 이미 있던 문제를 더 빠르게 재생산한다.

증폭기 명제의 출처와 그 위에 선 다섯 운영 원칙은 빌더에서 오케스트레이터로 가는 조직 설계의 「리더십 운영 원칙」 절에 있다.

Q. AI 생산성은 무엇으로 재나

개인 속도가 아니라 시스템 성과다. throughput 하나만 보면 함정에 빠진다 — 채택이 느는 동안 stability가 함께 내려간 구간이 실측돼 있기 때문이다.

그래서 함께 보는 것이 리드타임·재작업률·결함률·리뷰 부담이다. 넷은 조용히 나빠질 수 있는 항목들이고, 그래서 throughput 옆에 나란히 놓지 않으면 개선과 이전(移轉)이 구분되지 않는다. 속도가 오른 것인지 비용이 리뷰 쪽으로 옮겨 간 것인지를 가르는 것이 이 넷이다.

AI 사용량 자체를 KPI로 삼지 않는 것도 같은 이유다. 사용량을 목표로 걸면 사용량만 오르는 게이밍이 따라오고, 그러면 지표가 성과를 재는 것이 아니라 성과인 척하는 행동을 재게 된다.

측정 구조를 먼저 세운다는 것은 롤아웃 전에 baseline을 잰다는 뜻이다. 세 단계 롤아웃 표는 빌더에서 오케스트레이터로 가는 조직 설계의 「변화관리 — 롤아웃, 측정, 그리고 중단」 절에 있다.

Q. 주니어는 AI 때문에 성장이 막히나

실재하는 리스크다. 시니어는 이미 아는 것을 가속하지만, 주니어는 모르는 것을 배우려다 취약한 코드를 그대로 수용한다.

방어책은 게이트에 이해·검증 단계를 의무로 넣는 것이다. AI가 초안을 만들고 사람이 검증한다는 원칙이 여기서는 "읽고 설명할 수 있어야 통과"로 구체화된다. 주니어 쪽은 페어링과 코드리뷰로 받치고, 시니어 쪽은 멘토와 아키텍트로 자리를 옮긴다.

성장 기회가 오히려 앞당겨지는 자리도 여기 있다. AI가 70%를 빠르게 만들어도 마지막 30% — 엣지케이스와 보안 — 는 사람의 판단으로 남고, 그 30%가 주니어를 시니어 수준의 문제 앞에 평소보다 이른 시점에 데려다 놓는다.

디스킬링 관찰과 코드 품질 지표는 빌더에서 오케스트레이터로 가는 조직 설계의 「흔한 함정」에, 개발 단계에서 무엇을 AI가 하고 무엇이 사람 게이트로 남는지는 요구사항에서 운영까지 여섯 게이트와 개발·QA·배포 각론의 개발 절에 있다.

Q. 환각과 보안 사고는 무엇으로 막나

사후 점검이 아니라 기본값으로 깔린 가드레일이다. NIST AI RMF의 네 기능(Govern·Map·Measure·Manage)을 운영 체크리스트로 내려 쓰는 것이 출발점이다.

내려오는 항목 중 넷은 이렇다. ① 무엇을 허용하고 무엇을 금지하는지 명시한 방침 ② AI가 쓴 코드에도 똑같이 적용되는 TDD·정적분석·PR 리뷰 ③ 사내의 코드와 시크릿이 외부 모델로 새지 않도록 정한 데이터 등급과 허용 도구 ④ 누가 검토하고 누가 뒤집을 수 있으며 어디로 올리고 누가 책임지는지를 적어 둔 human-in-the-loop 문서.

넷 중 셋째는 방침만으로 지켜지지 않는다. 에이전트에게 도구를 쥐여줄 때 환경변수 파일 읽기와 임의 네트워크 호출을 권한 수준에서 거부해 두면, 같은 규칙이 사람의 주의력이 아니라 설정으로 강제된다. 방침은 무엇을 지킬지를 정하고, 권한 설정은 지키지 않을 방법을 없앤다.

네 기능이 체크리스트로 내려오는 과정은 빌더에서 오케스트레이터로 가는 조직 설계의 거버넌스 절에, 도구 권한을 허용·거부로 가르는 실제 표는 7부서 30에이전트의 공통 골격에 있다.

Q. 도구를 깔면 생산성이 오르나

오르지 않는다. 에이전트가 프로덕션에서 실패하는 진짜 이유는 모델 품질이 아니라 조직 컨텍스트의 부재다.

조직 컨텍스트는 모델이 갖고 있지 않은 것들이다 — 이 팀이 어떤 순서로 일하는지, 무엇을 승인이라고 부르는지, 어떤 코드가 이 레포에서 관례인지. 도구는 그것을 모르는 채로 들어오고, 그래서 도구가 늘어도 판단의 품질은 올라가지 않는다.

그래서 깔 것은 도구가 아니라 프로세스·규칙·공유 자산이다. 단계별 파이프라인을 먼저 정의해 AI가 초안을 만들고 사람이 승인하는 자리를 나누고, 그 위에 팀이 함께 쓰는 인프라를 올린다.

그 명제의 전문과 조직 컨텍스트가 무엇으로 이루어지는지는 팀 공유 인프라 넷과 성숙도 0 → 1 → N에 있다.

Q. 개인이 잘 쓰면 조직도 잘 쓰게 되나

되지 않는다. 개인기와 팀 시스템은 같은 것의 크고 작은 판본이 아니라 서로 다른 단계이고, 사이를 건너려면 별도의 작업이 필요하다.

세 단계로 놓으면 보인다. L1은 개인이 잘 쓰는 상태, L2는 팀원 누구나 같은 결과를 재현하는 상태, L3은 담당자가 바뀌어도 남는 상태다. L1에서 L2로 넘어가는 일에는 이름이 붙어 있다 — 외부화다. 한 사람의 머릿속에서만 돌던 판단 기준을 규칙과 게이트, 템플릿, 공유 컨텍스트의 형태로 옮겨야 옆자리가 같은 결과를 낸다. L2에서 L3으로 가는 일은 고착화이고, 성격이 또 다르다.

그래서 L1이 아무리 높아도 그 자체로는 L2가 되지 않는다. 팀 시스템으로 세는 것은 L2부터이고, 그 앞은 사람 수만큼의 개인기다.

3단 모델의 정의와 두 화살표(외부화·고착화)가 어떻게 다른지는 빌더에서 오케스트레이터로 가는 조직 설계의 3단 모델 절에 있다.

Q. AI 도입을 강제해야 하나

강제가 아니라 채택을 설계한다. 장치는 둘이다 — 디폴트를 바꾸는 쪽과 챔피언을 세우는 쪽.

디폴트를 바꾼 예는 "추가 인력을 요청하기 전에 AI로 안 되는 이유를 먼저 증명하라"로 채용 기준을 고친 사례다. 규칙 자체는 강제처럼 보이지만 실제로 바뀐 것은 기본 선택지이고, 그래서 사용을 감시하지 않고도 검토 순서가 바뀐다. 챔피언 쪽은 몇 명을 지목해 본업과 병행시키며 풀뿌리로 퍼뜨리는 방식이고, 규모는 직원의 약 7%다.

채택을 설계했다면 중단도 설계해야 한다. 60~90일 파일럿으로 baseline과 비교하고, 채택이 오르는 동안 리뷰시간과 취약점, 롤백과 재작업도 같이 오르면 롤아웃을 멈춘다. 중단을 판정하는 자리에 채택률이 아니라 부작용 지표가 놓여 있다는 점이 요점이다 — 잘 굴러가는 확산과 멈춰야 할 확산은 채택률이 똑같이 올라 있어서 채택률만으로는 갈리지 않는다.

두 사례의 원문은 빌더에서 오케스트레이터로 가는 조직 설계의 기업 사례 절에, 중단 기준 표는 같은 글의 「변화관리 — 롤아웃, 측정, 그리고 중단」 절에, 챔피언을 언제 지목하고 무엇을 의무화할지의 기간별 순서는 팀 공유 인프라 넷과 성숙도 0 → 1 → N에 있다.

Q. 도구가 너무 많은데 무엇으로 줄이나

개수를 세어 줄이는 것이 아니라 살 자리를 줄인다. 문제는 개별 선택이 아니라 단계마다 point SaaS를 하나씩 사는 접근이다.

도구가 하나 늘 때마다 함께 느는 것이 넷이다 — 통합, 계약, 학습, 보안검토. 전부 그 도구를 쓰기 위해서가 아니라 가지고 있기 위해 치르는 값이고, 그래서 각 도구가 그 단계에서 합리적인 선택이었어도 합계는 합리적이지 않을 수 있다. AI 투자의 상당 부분이 도구 난립으로 가치를 잃는다는 조사 수치가 가리키는 것이 이 누적이다.

그래서 방향은 도구를 더 잘 고르는 쪽이 아니라 흡수하는 쪽이다. 하네스 한 벌에 시스템 커넥터와 팀 절차를 넣고, 비-프로덕션 문서는 버전관리되는 마크다운 위키에 두고, 사람 승인이 필요한 게이트만 트래커에 남긴다. 남는 것은 도구 스무 개가 아니라 하네스 한 벌과 위키, 그리고 트래커 하나다.

그 조사 수치의 출처는 빌더에서 오케스트레이터로 가는 조직 설계의 「도입은 어디에서 실패하는가」 절에, 흡수한 뒤 무엇이 실제로 빠지는지의 대응표는 하네스·위키·게이트 세 레이어와 Skill 카탈로그 열하나에 있다.

Q. 어느 부서부터 자동화하나

가르는 것은 난이도가 아니라 설계 주제다. 고객과 사람을 직접 상대하는 네 부서 — 마케팅·영업·고객지원·인사 — 와 백오피스 세 부서 — 재무·법무·경영지원 — 는 걸리는 질문이 다르다.

고객을 향하는 부서에서 걸리는 질문은 "얼마나 잘 판단하는가"이고, 이것은 산출물 점수나 신뢰도 구간 같은 장치로 다룰 수 있다. 백오피스에서 걸리는 질문은 성격이 다르다 — 같은 입력이 두 번 들어와도 안전한지, 위험할 때 확실히 멈추는지, 여러 결과를 어떤 순서로 조립하는지다. 셋은 정확도를 올린다고 해결되지 않는다.

네 부서의 각론은 고객 접점 네 부서가 자동화를 멈추는 자리에, 남은 세 부서와 새 업무를 쪼개는 체크리스트는 백오피스 3부서와 자동화 등급 6축에 있다.

Q. 자동화를 멈추는 기준은 무엇인가

부서마다 다르고, 그래서 부서마다 따로 적어야 한다. 어려운 쪽은 무엇을 자동화할지가 아니라 어디서 멈출지를 어떻게 적어 두는가다.

같은 요구 — 사람이 개입할 자리를 명시하라 — 가 부서의 오류 비용 구조에 따라 다른 장치로 나타난다. 산출물에 점수를 매겨 임계 미만이면 사람에게 넘기는 곳, 특정 조건에서 승인을 요구하는 곳, 응답 신뢰도가 구간 아래로 내려가면 이관하는 곳, 법적 근거를 단 정지 게이트를 박아 두는 곳이 각각 있다. 장치의 종류가 넷인 것이지 기준이 하나인 것이 아니다.

적지 않으면 어떻게 되는가가 이 문항의 핵심이다. 멈춤 지점이 문서에 적혀 있지 않으면 그 자리는 자동화된 것이 아니라 감시에서 빠진 것이 된다. 사고가 나기 전까지 둘은 똑같이 잘 도는 것처럼 보인다.

네 부서가 각각 어떤 수치와 게이트로 멈추는지는 고객 접점 네 부서가 자동화를 멈추는 자리에 있다.

Q. 에이전트는 몇 개가 적정한가

개수는 편성에 따라 달라진다. 물어야 할 것은 개수가 아니라 무엇을 한 부서로 묶었는가다.

같은 총계 30이 서로 다른 조직도를 가리키는 일이 실제로 일어난다. 부서 수가 일곱으로 같아도 일곱 개의 이름과 배분이 갈리면 다른 세트이고, 법무부가 있는 세트에는 개발 부서가 없다. 총계를 동일성의 증거로 읽으면 서로 다른 조직도가 하나로 뭉개진다.

그래서 개수를 물을 때 실제로 정해야 하는 것은 부서 경계다. 순서가 반대면 숫자를 맞추려고 부서를 나누게 된다.

세 판본을 나란히 놓고 편성이 어디서 갈리는지 짚은 비교표는 7부서 30에이전트의 공통 골격에, 그중 한 세트를 부서별로 펼친 정의서는 여섯 부서 26종 에이전트 정의서에 있다.

Q. 사람 승인은 어느 단계에 두나

루프의 종료조건이 아니라 단계의 경계다. 관통 원칙은 하나다 — AI는 초안·분석, 사람은 승인·정책.

요구사항에서 운영까지를 여섯 단계로 자르고 단계 사이마다 번호 붙은 게이트를 놓으면, 승인은 "결과가 다 나온 뒤 한 번"이 아니라 "다음 단계로 넘어가기 전에 매번"이 된다.

각 게이트가 무엇을 승인하는지도 단계마다 다르다. 앞의 둘은 무엇을 할지(채택·우선순위), 가운데 둘은 어떻게 만들지(디자인 시스템·아키텍처), 뒤의 둘은 내보낼지(릴리스·배포)를 판정한다. 그리고 승인을 실제로 강제하는 것은 방침 문서가 아니라 서버사이드 설정이다 — 저장소의 approval rules가 없으면 게이트는 지키기로 한 약속에 머문다.

여섯 단계와 단계별 게이트의 통과 기준은 요구사항에서 운영까지 여섯 게이트와 개발·QA·배포 각론에 있다.

Q. 기획·디자인에도 AI가 붙나

붙는다. 다만 붙는 자리가 만드는 자리가 아니다. 기획이 실제로 막히는 곳은 문서를 쓰는 칸이 아니라 흩어진 정성 데이터에서 신호를 뽑는 칸이다.

회의·인터뷰·문의·리뷰가 쌓이는 속도는 사람이 읽는 속도를 넘어선 지 오래다. AI가 전사와 태깅, 클러스터링과 요약을 맡고, 무엇을 채택하고 무엇을 먼저 할지는 사람이 판단한다. 도구를 하나 더 사는 일이 아니라 두 칸의 담당을 바꾸는 일이다.

디자인에서는 병목이 반대 방향으로 움직인다. 시안·와이어프레임·컴포넌트를 대량으로 뽑을 수 있게 되면서 어려운 쪽이 그리는 일에서 디자인 시스템과 접근성, 브랜드 일관성을 지키는 일로 옮겨 간다. 그래서 디자이너의 일도 그리는 쪽에서 에이전트의 제약과 시스템 프롬프트를 설계하는 쪽으로 이동한다. 두 영역 모두 AI가 들어간 칸보다 사람 게이트가 새로 생긴 칸이 설계의 요점이다.

네 영역 각각에서 AI가 처리하는 칸과 사람 게이트가 어디로 갈리는지는 기획·디자인·마케팅·경쟁사 분석 네 영역의 AI 도구 지형에 있다.

Q. 팀 공유 인프라는 무엇부터 까나

넷을 동시에 세울 수 없으므로 순서가 있고, 그 순서는 두 축으로 적힌다 — 체감 ROI 순서와 기간별 단계다.

체감 ROI 순서의 첫 자리는 PR AI 코드리뷰다. 매일 체감되고, 리드타임과 버그를 조기에 잡고, 셀프호스팅이면 비용이 거의 들지 않는다. 다음이 이슈 자동 트리아지, 그다음이 지식관리 쪽이다. 앞의 둘을 먼저 놓는 이유는 팀의 신뢰를 사는 순서이기 때문이다.

기간별 축은 같은 목록을 다르게 자른 것이 아니라 실제로 다른 목록이다. 처음 30일은 baseline 측정과 방침 초안, 그다음 30일이 첫 자동화와 게이트 의무화, 그다음이 조직 컨텍스트를 만드는 구간이다. 두 축을 겹쳐 읽어야 "무엇이 먼저 값을 하는가"와 "언제 그것을 할 수 있는가"가 함께 잡힌다.

인프라 넷이 각각 무엇이고 두 축의 전체 목록이 어떻게 되는지는 팀 공유 인프라 넷과 성숙도 0 → 1 → N에 있다.

Q. 성숙도는 무엇으로 판정하나

단계 이름이 아니라 졸업 조건이다. 0·1·N 세 단계에 각각 다음으로 넘어가는 조건이 붙어 있고, 그 조건이 성숙도의 실제 정의다.

0단계의 졸업은 "누가 무엇을 쓰는지 파악됨"이다. 도입 여부가 아니라 가시성이 기준인 이유는 0단계의 실제 상태가 조직이 파악하지 못한 개인 사용(Shadow AI)이기 때문이다. 1단계의 졸업은 "자동화 한둘이 매일 쓰이고 측정됨"이고, 여기서 처음으로 측정이 조건에 들어온다. N단계의 졸업은 "사람이 바뀌어도 유지됨"이다.

세 조건을 나란히 놓으면 재는 대상이 사용량만이 아니라는 것이 드러난다. 개수가 들어가는 것은 1단계 하나뿐이고 그 조건도 개수만으로 닫히지 않는다. 사용량은 담당자가 떠나면 함께 사라지지만 온보딩에 내장된 것은 남고, 마지막 단계를 가르는 것이 그 차이다.

세 단계 표와 각 단계의 핵심 활동은 팀 공유 인프라 넷과 성숙도 0 → 1 → N에 있다.

Q. 레포에 무엇을 커밋하나

파일이 되어도 성질을 잃지 않는 것만 커밋한다. 층을 가르는 것은 무엇으로 만들었는가가 아니라 그것이 어디에 놓여야 하는가다.

커밋되는 쪽이 둘이다. 하나는 하네스 — 시스템 커넥터 설정, 팀 절차를 담은 Skill, 팬아웃용 서브에이전트, 컨벤션 파일, 자동화 게이트로 거는 훅이 대체로 레포 파일이 된다. 다른 하나는 지식 — 작업계획서·PRD·ADR·런북 같은 비-프로덕션 문서를 마크다운 위키로 두고 git으로 공유한다. 둘 다 파일이 되어 버전관리로 들어간다는 점이 같고, 그래서 팀 절차의 외부화가 파일 수준에서는 이 두 층의 모양을 한다.

레포 밖에 남는 것은 사람의 승인 행위와 그 감사추적이다. 커밋한다고 승인이 되는 것이 아니고, 로컬에서 만들어 넣은 파일은 그 자체로 승인의 증거가 되지 못한다. 그래서 셋째 층은 앞의 둘에 들어가지 못한 나머지가 아니라 파일로 만들면 그 성질을 잃는 것만 남은 층이다.

세 레이어를 가르는 도식과 하네스 층의 구성요소 표는 하네스·위키·게이트 세 레이어와 Skill 카탈로그 열하나에 있다.

Q. 부서 에이전트를 어떻게 정의하나

세 겹을 같은 순서로 쌓는다 — 위임 흐름 도식, 에이전트 요약표, 프롬프트 설계 기법.

첫 겹은 부서 안에서 일이 누구에게서 누구로 넘어가는지를 그리는 것이다. 인계 화살표에는 예외 없이 라벨이 달리고, 라벨이 없는 선은 소속 표시다. 둘째 겹은 에이전트마다 판단 축·고정된 산출 형식·명시된 안전장치를 한 줄로 적는 표이고, 셋째 겹이 그 줄을 실제 프롬프트로 내리는 기법이다.

여섯 부서를 이 순서로 펼친 정의서는 여섯 부서 26종 에이전트 정의서에, 부서 이름을 지웠을 때 남는 공통 5단계와 사람 개입 4등급은 7부서 30에이전트의 공통 골격에 있다.

Q. 무엇이 실패의 진짜 원인인가

모델이 아니다. 세 숫자가 같은 방향을 가리킨다 — 파일럿의 95%가 ROI에 미달하고, 투자의 72%가 가치를 잃고, KPI를 추적하는 곳은 20%에 못 미친다.

95%를 조사한 쪽이 원인으로 지목한 것은 모델 성능이 아니라 조직과 통합이었고, 72%를 조사한 쪽이 지목한 것은 도구 난립과 통제 밖 사용이었다. 그리고 성과를 가르는 가장 강한 예측변수로 지목된 KPI 추적을 하는 곳이 다섯 중 하나가 안 된다. 세 숫자를 겹쳐 놓으면 실패가 나는 자리가 모델 바깥이라는 것이 드러난다.

한 문장으로 줄이면 이렇다 — 병목은 이미 모델을 떠났고, 그 자리에 남은 것이 조직 컨텍스트다. 그래서 처방도 모델 교체가 아니라 프로세스·규칙·공유 자산 쪽에 있고, 이 글의 앞선 문항들이 그 처방을 하나씩 나눠 답한 것이다.

세 숫자의 출처는 빌더에서 오케스트레이터로 가는 조직 설계의 「도입은 어디에서 실패하는가」 절에, 조직 컨텍스트라는 진단이 어떤 인프라와 성숙도 단계로 내려오는지는 팀 공유 인프라 넷과 성숙도 0 → 1 → N에 있다.

용어 정리

여기까지가 "무엇부터 바꾸고, 무엇으로 재고, 어디서 멈추나"의 판단이다. 처음에 늘어놓은 일곱 개의 질문 — 무엇부터, 어떻게 재나, 강제할까, 어떻게 줄이나, 어느 부서부터, 어디서 멈추나, 몇 개인가 — 이 열여덟 문항 안에서 각각 자리를 찾았다. 갈리는 것은 도구가 아니라 그 도구가 놓이는 시스템이고, 그래서 판정 기준도 도구의 성능이 아니라 조직 쪽에 있다.

각 문항이 결론과 근거에서 멈춘 것은 그 아래가 없어서가 아니다. 표·수치·각론은 이 카테고리의 아홉 편에 이미 펼쳐져 있고, 문항마다 붙인 링크가 그 자리를 가리킨다. 질문에서 들어와 필요한 글 하나를 열고 나가는 것이 이 글의 쓰임이다.