Claude Code 법인 도입, 계약도 보안도 아닌 곳에서 넘어진다 — 성패를 가르는 단 하나의 질문

"직원들이 개인 계약으로 Claude Code를 쓰기 시작했어요. 회사 차원에서 제대로 법인 도입을 하고 싶은데, 뭐부터 정하면 됩니까?" — 요즘 경영자분들께 이 상담을 정말 자주 받습니다.

먼저 결론부터 쓸게요. Claude Code 법인 도입에서 넘어지는 회사는 계약 요금제나 보안 설정에서 넘어지는 게 아닙니다. 그 앞에 있는, 단 하나의 질문을 건너뛰기 때문에 넘어집니다. 이 글에서는 그 질문이 무엇인지, 그리고 왜 거기가 법인 도입의 성패를 가르는지를, 기업대상 Claude 및 Claude Code를 기준으로 2100명 이상을 가르치고 직원 1만 명 규모 기업의 법인 연수에도 경험해본 입장에서 before → after로 씁니다.

"법인 도입"을 툴 나눠 주는 이야기로 만든 회사부터 멈춘다

먼저 가장 흔한 실패 패턴부터.

법인 도입 상담을 받으면 화제는 대개 "어느 요금제를 계약할까", "보안을 어떻게 설정할까", "누구에게 계정을 나눠 줄까"에서 시작합니다. 물론 이것들도 정해야 합니다. 하지만 여기만 정하고 도입한 회사는 몇 주 뒤 이렇게 말해요. "넣긴 넣었는데, 결국 다들 전과 똑같은 방식으로 일하고 있다."

가볍게 여겨지기 쉽지만, 법인 도입이 잘 안 되는 회사의 대부분이 사실 여기서 멈춰 있습니다. 계약은 끝났다. 툴은 나눠 줬다. 그런데 사업의 실속은 아무것도 바뀌지 않았다.

왜일까요. "툴을 나눠 주는 것"과 "회사의 일이 AI로 돌아가는 것" 사이에는 상상 이상으로 깊은 골이 있기 때문입니다. 개인이 편리한 도구로 쓰는 것과 회사의 업무 기반으로 쓰는 것은 전혀 다른 일이거든요.

여기서 아깝다고 느끼는 지점이 있습니다. 모처럼 직원들이 자발적으로 Claude Code를 만지기 시작했는데, 회사 차원에서는 "개인의 편리한 도구" 수준에서 방치되고 있다는 것. 거기서 생긴 노하우는 개인의 머릿속에만 쌓이고, 그 사람이 그만두면 회사에서 사라집니다. 움직이기 시작하던 것이 회사의 자산으로는 아무것도 남지 않는다. 이것이 법인 도입을 "툴 배포"로 끝낸 회사에 일어나는 일입니다.

회계사의 눈으로 보면, 이건 "업무 가시화"와 "내부 통제" 이야기다

그럼 계약과 보안 설정 앞에 있는 "단 하나의 질문"이란 뭘까요.

"누구의, 어떤 판단 기준을 회사에 남길 것인가" — 이것입니다.

저는 회계사 출신으로, 숫자와 업무의 구조를 봐 온 사람입니다. 그 눈으로 Claude Code 법인 도입을 보면, 이건 툴 이야기가 아니라 예전부터 있던 두 가지 경영 테마가 그대로 나오고 있을 뿐이라는 걸 알게 됩니다.

• 업무 가시화 — 베테랑이나 대표의 머릿속에 있는 "왜 그렇게 하는가"라는 판단 기준을 말로 풀어 파일로 꺼내는 작업. 특정인 의존을 푸는, 바로 그 이야기입니다.
• 내부 통제 — "무엇을, 누구에게, 어디까지 넘겨도 되는가"의 경계선을 먼저 정해 두는 구조. 감사의 세계에서 말하는 통제를, AI라는 새 담당자에게도 작동시키는 이야기입니다.

Claude Code가 흥미로운 건, 이 둘을 한국어 파일 1장으로 AI에 넘길 수 있다는 점이에요. 판단 기준을 적어 내는 건 한국어 작업이고, 여기에 프로그래밍은 나오지 않습니다. 뒤집어 말하면, 이 두 가지(=판단 기준의 가시화와, 넘기지 않을 것의 경계선)를 정하지 않고 계정만 나눠 주면, 법인 도입은 "개인이 똑똑한 검색을 쓰는 상태"에서 한 발짝도 못 나갑니다.

법인 도입을 보안 설정 이야기로 축소해서는 안 된다는 것이, 제가 가장 먼저 전하고 싶은 말입니다. 설정은 중요하지만, 그것은 "무엇을 넘기지 않을 것인가"라는 판단 기준이 먼저 있어야 비로소 의미를 가집니다. 알맹이(판단 기준)를 정하지 않고 설정만 굳혀도 형식뿐인 통제가 됩니다.

before → after — 법인 도입이 "업무 기반"이 되면 이렇게 바뀐다

말로만 하면 전달이 어려우니 before → after로 나란히 놓습니다.

• before: 직원 각자가 개인 계약으로 Claude Code를 쓰고 있다. 사용법도, 어디까지 정보를 넘겨도 되는지의 판단도 사람마다 제각각. 좋은 사용법은 개인 안에 쌓이고 퇴사와 함께 사라진다. 계약과 배포는 끝났는데, 회사 차원의 일의 품질은 전과 다르지 않다.
• after: 회사의 판단 기준·절차·정보의 경계선이 파일에 실려 있어, 누가 Claude Code를 써도 "우리 회사의 방식"으로 AI가 움직인다. 정형적인 1차 대응(초안·정형화·분해)은 AI가 맡고, 사람은 최종 판단에 집중한다. 특정인에게 묶여 있던 노하우가 회사의 자산으로 파일에 남아 간다.

이 차이를 만드는 것이 앞서 말한 "업무 가시화"와 "내부 통제"입니다. 계약 요금제의 차이가 아니에요.

Claude Code 법인 도입에서 가장 먼저 정할 3가지

추상론만으로는 움직일 수 없으니, 법인 도입에서 가장 먼저 정해야 할 것을 3가지로 좁힙니다. 흔한 "계약·보안·배포" 체크리스트와는 일부러 다른 각도로 잡았습니다. 회사의 실속을 움직이는 건 이쪽 3가지이기 때문입니다.

① 누구의 판단 기준을 회사에 남길까(업무 가시화)

먼저, 지금 특정인에게 묶여 있는 업무를 하나 골라 그 주인의 판단 기준을 말로 풉니다. "이 대응은 왜 이렇게 하는가"를 적어 내는 것. 여기가 법인 도입의 가장 중요한 알맹이입니다.

요령은 전체 업무를 한 번에 하려 들지 않는 것. 사내에서 가장 자주 발생하는 정형 업무 1개만 골라서, 그 절차와 판단 기준을 10줄 적어 내는 데서 시작합니다.

② 무엇을 넘기고, 무엇을 넘기지 않을까(내부 통제의 경계선)

다음으로, 보안을 "설정"이 아니라 "판단 기준"으로 정합니다. 어떤 정보는 AI에 보여 줘도 되고, 어떤 정보는 안 되는가. 이 경계선을 업무별로 먼저 말로 풀어 둡니다.

Claude Code에서는 회사 전체에 작동하는 방침을 CLAUDE.md라는 파일 1장에 쓸 수 있습니다. 말하자면 회사의 헌법이에요. 프로그래밍은 나오지 않습니다. 한국어로 당신 회사의 판단을 적어 내기만 하면 됩니다. 실물의 이미지는 이렇습니다.

## 이 회사에서 AI에 맡기는 것
정형적인 1차 대응(초안·정형화·분해)까지. 최종 판단은 사람이 가진다.

## 어디에 무엇이 있는가
- 각 업무의 대응 방침 … docs/ 의 업무별 파일
- 과거 자료·문서의 틀 … templates/

## 기본 원칙(회사 공통)
- 사외로 나가는 문장은 "결론 → 이유 → 다음 요청" 순으로 쓴다
- 숫자·계약에 관련된 판단은 반드시 1차 자료를 확인한 뒤 쓴다

## 넘기지 않는 것(내부 통제)
- 고객의 개인정보·민감 정보를 외부 서비스의 학습에 넘기지 않는다
- 보여 줘도 되는 정보/보여 주지 않는 정보의 경계선을 업무별로 명기한다

"무엇을 넘기지 않을까"를 정하는 것도 당신 회사의 판단 기준의 일부입니다. 파일에 적어 두면 AI는 매번 그것을 지킵니다. 인간의 깜빡함보다 훨씬 단단해요. 감사의 언어로 말하면 이것이 통제입니다(물론 사용하는 서비스의 데이터 취급·이용 약관 확인은 전제입니다).

③ 어느 숫자를 움직이기 위한 것인가(투자 대비 효과)

세 번째는 경영자만 정할 수 있는 것입니다. 이 법인 도입으로 사업의 어느 숫자를 움직일 것인가를 먼저 정합니다.

법인 도입이 표류하는 회사는 "AI를 넣는 것" 자체가 목적이 되어 갑니다. 많이 자동화했다는 성취감은 남는데, 매출도, 영업 미팅 건수도, 처리 건수도 움직이지 않는다. 그러니 도입을 "할 일"이 아니라 "경영의 투자 판단"의 무대에 처음부터 올립니다. "월 툴 비용과 들이는 시간 대비, 인건비 몇 사람분의 가동이 뜨는가"로 봅니다. 숫자에 강한 경영자일수록 본래 여기가 특기일 겁니다.

"전산팀이 없는 회사"일수록 사실 법인 도입이 빠르다

여기서 많은 분의 고정관념 하나를 깨 드릴게요. "우리는 전산팀도 없고 잘 아는 사람도 없다. 법인 도입은 대기업 이야기 아닌가" — 그렇게 느끼는 1인 대표·전문 자격사(세무사·변호사 등) 사무소야말로 사실 가장 빨리 도입할 수 있습니다.

이유는 구조입니다. 1인 대표·전문 자격사 사무소는 결재자·이용자·정보의 경계선을 정하는 사람이 전부 당신 한 명입니다. 그래서 "어느 업무에 어디까지 AI를 넣을까"도, "무엇을 넘기지 않을까"도 당신 한 사람의 결단으로 즉시 정할 수 있어요. 회사원이 구조적으로 할 수 없는, 사업자만의 강점이 여기 있습니다.

반대로 규모가 큰 회사의 법인 연수에서 여러 번 본 것은 그 반대의 실패입니다. 권한이 분산되어 있어 "그 정보를 넘겨도 되는가"를 아무도 정하지 못한다. 업무의 판단 기준이 베테랑 개인의 머릿속에 있는데 가시화할 담당자가 없다. 기술이 아니라 판단 기준을 정하는 사람이 분산되어 있다는 것에서 넘어지는 겁니다.

예를 들어 이전에 생성형 AI 연수로 함께한 직원 1만 명 규모 기업에서는, 전 직원이 쓸 수 있는 사내 AI 챗 환경이 연수 시점에 이미 운영되고 있었습니다. 환경으로는 나무랄 데 없죠. 그런데도 다음 단계로 현장에서의 활용 촉진이 과제가 되어 있었다 — 는 것이 연수 의뢰의 배경이었습니다. 툴을 다 나눠 준 그다음 — "우리 업무의 어디에서, 무엇을 어디까지 맡길까"를 정하는 과정이 통째로 남아 있었던 거예요.

또 업무를 AI에 가르치려고 가시화를 시작하면 "특정인에게 묶여 있던 업무의 문제점이 먼저 보였다"는 목소리를 다른 연수처에서도 수없이 듣습니다. AI 도입의 입구에서 발견되는 것은 대개 AI 이전의 숙제입니다. 그리고 그 숙제는 툴을 아무리 나눠 줘도 해결되지 않습니다.

그래서 법인 도입의 속도는 회사 규모로 정해지지 않습니다. 판단 기준을 정할 수 있는 사람이 사내에 있는가로 정해집니다. 그 한 지점에서 1인 대표·전문 자격사 사무소는 가장 빠른 위치에 있습니다.

법인 도입에서 멈추는 회사의 3가지 공통점

지금까지 본 "넣었는데 안 돌아가는" 회사에는 공통점이 있습니다. 불안을 부추기려는 게 아니라, 미리 알아 두면 피할 수 있다는 것뿐입니다.

• 툴을 나눠 주고 만족하며 판단 기준을 쓰지 않는다 — 그래서 개인의 편리한 도구 수준에 머물고 회사에 아무것도 남지 않는다.
• 보안을 설정만으로 해결하려 한다 — "무엇을 넘기지 않을까"라는 판단 기준이 없으면 설정은 형식뿐인 통제가 된다.
• 첫 바퀴에서 완벽한 구조를 만들려 한다 — 구조는 대개 두 바퀴째에 완성됩니다. 처음 쓴 판단 기준은 반드시 어딘가 어긋나요. 실제 주고받으며 손보고 나서야 비로소 "말없이 맡길 수 있는 구조"가 됩니다. 처음부터 완벽을 노리면 움직이기 전에 숨이 찹니다.

셋 다 뿌리는 같습니다. 법인 도입을 "툴 이야기"라고 생각하는 것. 알맹이는 "판단 기준을 회사에 남기는 작업"입니다.

왜 범용 SaaS 계약이나 사람 채용으로는 같은 상태에 못 닿는가

"그거, 우수한 사람을 뽑거나 좋은 SaaS를 계약하면 되는 것 아닌가?" 하고 생각한 분도 있을 겁니다. 저도 예전엔 그렇게 생각했어요. 하지만 "회사의 판단 기준으로 AI가 움직이고 있다"는 상태에는 다른 수단으로는 닿지 못합니다.

• 채용: 가르친 판단 기준은 사람에게 깃들지만, 퇴사와 함께 회사에서 사라집니다. 교육에 몇 년을 들인 결과가 0으로 돌아갈 위험을, 1인 대표·전문 자격사 사무소일수록 감당할 수 없습니다.
• 범용 SaaS·패키지: 편리하지만 누가 계약해도 같은 기능이 움직일 뿐입니다. 당신 회사의 판단 기준·정보의 경계선·문서의 틀까지는 재현하지 못합니다.
• 단발성 ChatGPT 이용: 빨라지긴 하지만 회사의 컨텍스트는 매번 리셋됩니다. "우리 방식"은 AI 안에 전혀 남지 않습니다.

한편 파일에 쓴 판단 기준은 그만두지 않습니다. 잊지 않습니다. 게다가 써 넣을수록 더 똑똑하게 움직이게 됩니다. "회사의 판단 기준을, 그만두지 않고 잊지 않는 형태로 남기고, 누가 써도 그 방식으로 움직인다" — 이 상태는 판단 기준을 파일로 넘길 수 있는 Claude Code 같은 AI 에이전트로만 만들 수 있습니다. 이것이 법인 도입의 본질이 "툴 선정"이 아니라 "판단 기준의 이식"인 이유입니다.

2100명과 법인 연수 현장에서 확인해 온 것

여기까지 거창하게 썼지만, 이건 탁상공론이 아닙니다.

기업 대상 교육현장에서는 2100명 이상을 가르쳐 왔습니다. 그중 직업 엔지니어는 극소수. 나머지 거의 전원이 "터미널이 뭐죠?" 수준에서 시작한 비개발자입니다. 경영자부터 회사원까지 직종은 다양해요. 필요한 것은 코드를 쓰는 힘이 아니라 자기(자사)의 판단 기준을 말로 푸는 힘이라고, 그 전원을 보며 확신하고 있습니다.

그리고 AI 엔지니어로서 직원 1만 명이 넘는 기업의 법인 연수·도입 동행에도 들어가 왔습니다. 기업 교육에서 혼자 배우는 경영자·전문 자격사부터 대기업 현장까지 보면서, 성패를 가르는 분기점은 언제나 같았습니다. 툴을 나눠 줬는가가 아니라, 판단 기준을 가시화해 회사에 남겼는가입니다.

자사의 실례를 하나. 여러 AI 담당을 병렬로 돌리기 시작했을 무렵, 어느 담당이 자기 작업을 저장할 때 옆에서 다른 담당이 작업 중이던 파일까지 끌어들여 기록해 버리는 사고가 났습니다. AI에게 악의는 없습니다. "한꺼번에 저장해 줘"라는 제 지시의 애매함을 그대로 실행했을 뿐이에요.

결말은 김이 샐 만큼 수수했습니다. "저장하는 것은 자기가 변경한 파일만. 이름을 하나씩 지정한다" — 이 판단 기준을 회사의 헌법 파일에 몇 줄 써 넣은 겁니다. 그래도 "다른 담당의 작업을 끌어들이는" 사고는 형태를 바꿔 몇 번 더 일어났고, 그때마다 규칙을 한 단계씩 구체화해 왔습니다.

넘어질 때마다 판단 기준을 한 줄 파일에 더한다. 이 반복이 돌아보면 그대로 자사의 내부 통제 정비가 되어 있었습니다. 실패가 "개인의 반성"으로 사라지지 않고 "회사의 규칙"으로 남아 간다 — 이것이 이 구조의 가장 값진 지점이라고 생각합니다.

저 자신도 자사의 일상 업무 — 콘텐츠 발행 초안, 경리 사전 준비, 정형 대응 — 를 판단 기준을 넘긴 AI 담당별로 돌리고 있습니다. 그래서 "넣었는데 안 돌아간다"에서 멈추는 심정도, "한번 돌아가기 시작하면 예전으로 못 돌아간다"는 감각도 둘 다 몸으로 안다고 자부합니다.

자사에 Claude Code를 진심으로 "업무 기반"으로 넣고 싶은 경영자에게

마지막으로, 이 글을 읽고 손이 움직일 것 같은 분에게.

• 직원들이 쓰기 시작한 Claude Code를 개인의 편리한 도구로 끝내지 않고 회사의 업무 기반으로 남기고 싶은 경영자라면
• 보안을 "설정"이 아니라 "무엇을 넘기지 않을지의 판단 기준"부터 설계하고 싶은 분이라면
• 법인 도입을 "AI를 넣는 것"이 아니라 "사업의 어느 숫자를 움직일까"로 평가하고 싶은 분이라면

— 분기점은 계약도 보안 설정도 아니고, "판단 기준을 회사에 남길 수 있는가"의 한 지점입니다. 그리고 그 남기는 방법은 회사의 업무가 한 곳 한 곳 다른 이상, 본래 개별 설계가 됩니다.