AI 네이티브 컴퍼니 구축 사례 2026 Claude Code 사내 ERP 체크리스트

AI 네이티브 컴퍼니는 직원들이 AI 툴을 몇 개 쓰는 회사가 아니라, 업무 데이터가 한곳에 모이고 다음 액션이 시스템 안에서 실행되는 회사에 가깝다. 윤자동의 윤비서 사례는 Claude Code로 내부 ERP와 AI 비서를 직접 만든 운영 예시다.

AI 네이티브라는 말은 멋있다. 문제는 멋있는 말일수록 회의실에서 빨리 부풀어 오른다는 점이다. “우리도 AI 네이티브로 가자”는 말은 좋은데, 다음 문장이 “그래서 노션에 페이지 하나 만들자”로 끝나면 조금 허전하다. 이름표만 새로 붙인 수동 업무가 되기 쉽다.

윤자동 윤용승 대표 사례에서 흥미로운 지점은 AI를 잘 쓴다는 말보다 데이터 흐름이다. 프로젝트, 고객, 미팅 기록, 매출, 세금계산서, 일정, 업무 할당이 한 시스템으로 모이고, Slack에서 자연어로 요청하면 내부 비서가 다음 액션을 처리한다. 이건 챗봇보다 ERP에 가깝다.

이번 글은 영상에서 소개된 윤비서 사례를 바탕으로, 작은 팀이 Claude Code나 비슷한 AI 코딩 에이전트로 사내 ERP를 만들 때 무엇부터 설계해야 하는지 정리한다. 핵심은 “Claude Code로 만들 수 있다”가 아니다. 무엇을 자동화하면 안 되는지까지 같이 정하는 것이다.

먼저 잡을 답

AI 네이티브 회사의 출발점은 툴 도입이 아니라 데이터 중앙화다. 미팅, 고객, 결제, 입금, 세금계산서, 업무 요청이 서로 다른 앱에 흩어져 있으면 AI는 똑똑한 검색창 정도로 끝난다. 반대로 데이터가 업무 객체로 모이면 AI는 다음 액션을 제안하거나 일부 실행할 수 있다.

윤비서 사례의 구조를 단순화하면 네 층이다.

[입력층] 미팅 녹음, 명함, Gmail, Google Drive, 결제, 입금 알림, GitHub, 직원 요청
    ↓
[데이터층] 고객, 프로젝트, 매출, 문서, 일정, 업무, 리포트
    ↓
[처리층] Claude Code, OCR, API, Zapier, Slack app, 필요 시 MCP
    ↓
[액션층] 할 일 배정, 세금계산서 초안, 일정 등록, 리포트, 고객 후속 연락

이 흐름에서 제일 중요한 층은 데이터층이다. 입력 도구와 AI 모델은 바뀔 수 있다. 하지만 고객, 프로젝트, 매출, 업무라는 객체 정의가 흔들리면 모든 자동화가 흔들린다. AI 네이티브는 멋진 prompt보다 지루한 schema에서 시작한다. 지루한 게 이긴다. 억울하지만 그렇다.

노션에서 사내 ERP로 넘어가는 이유

영상에서는 노션 같은 기성 SaaS가 데이터가 많아질수록 속도, 모바일 사용성, 관계형 데이터 관리에서 한계가 생겼다고 설명한다. 이 지점은 많은 작은 팀이 겪는 흐름이다. 처음에는 노션 DB 하나로 충분하다. 고객, 프로젝트, 미팅, 할 일을 한 화면에 놓으면 뭔가 회사가 정리된 느낌이 난다.

하지만 업무가 늘면 질문이 바뀐다. “이 고객의 최근 미팅과 견적 상태, 결제 여부, 세금계산서 발행 여부, 다음 액션을 한 번에 볼 수 있나?” 이 질문에 답하려면 단순 페이지보다 관계형 데이터와 권한, 자동화 로그가 필요해진다.

사내 ERP를 만들겠다는 말은 거창하지만, 첫 버전은 작아야 한다. 고객 테이블, 프로젝트 테이블, 미팅 테이블, 업무 테이블 네 개만으로도 시작할 수 있다. 중요한 건 테이블 수가 아니라 관계다.

객체	최소 필드	다음 액션 예시
고객	이름, 회사, 담당자, 상태	후속 연락 생성
프로젝트	고객, 계약상태, 담당자, 마감일	업무 템플릿 생성
미팅	고객, 요약, 결정사항, 녹취 링크	할 일 추출
매출	고객, 결제일, 금액, 세금계산서 상태	발행 확인

이 네 객체가 잡히면 AI가 할 일이 선명해진다. 미팅 요약을 고객에 붙이고, 결정사항을 업무로 만들고, 결제 상태를 보고 세금계산서 확인을 띄운다. 반대로 객체가 없으면 AI는 매번 긴 텍스트를 읽고 “좋은 요약”만 만든다.

Claude Code는 ERP 제작자가 아니라 빠른 구현자다

Anthropic의 Claude Code overview는 Claude Code를 터미널에서 동작하는 agentic coding tool로 설명한다. 기능 설명에는 자연어로 기능을 요청하면 계획을 세우고 코드를 작성하며, 코드베이스를 탐색하고, 버그를 고칠 수 있다는 내용이 포함된다.

이런 도구는 작은 내부 도구를 빠르게 만드는 데 잘 맞는다. 예를 들어 “고객 목록, 프로젝트 상세, 미팅 기록 입력 화면, Slack 요청 webhook” 정도는 기존 프레임워크 위에 빠르게 붙일 수 있다. 문제는 Claude Code가 ERP의 업무 정책까지 대신 정해주지는 않는다는 점이다.

ERP는 화면보다 정책이 어렵다. 누가 고객 정보를 볼 수 있는가. 누가 세금계산서 상태를 바꿀 수 있는가. 자동으로 생성된 업무는 누가 승인하는가. Slack에서 요청한 일정은 바로 등록할 것인가, 승인 대기로 둘 것인가. 이 질문은 코드 문제가 아니라 운영 문제다.

그래서 Claude Code에게 맡길 일과 사람이 정할 일을 나눠야 한다.

영역	AI에게 맡기기 좋은 일	사람이 닫아야 할 일
화면	CRUD 화면, 필터, 검색	권한별 화면 노출 정책
데이터	schema 초안, migration	개인정보 보존 기간
자동화	webhook 처리, 요약, 초안	실행 승인 기준
리포트	일일 요약, 누락 체크	매출/세금 최종 판단

이 표를 건너뛰고 바로 구현하면 데모는 빨리 나온다. 대신 운영에 들어가는 순간 “이 버튼 누르면 실제 세금계산서가 나가나?” 같은 질문이 터진다. 그런 질문은 데모 영상에는 잘 안 나오지만, 회사에서는 제일 크게 들린다.

Slack 호출은 버튼이 아니라 권한 입구다

영상에서 인상적인 부분은 Slack에서 자연어로 윤비서를 호출해 비정형 일정이나 요청을 처리하는 흐름이다. 직원이 별도 웹 화면에 들어가지 않아도 시스템을 움직일 수 있다는 장점이 있다.

Slack 공식 API 문서는 Web API, Events API, slash commands 같은 기능을 안내한다. Slash command는 사용자가 메시지 입력창에서 명령을 입력하면 app으로 payload가 전송되는 구조다. 이런 구조를 쓰면 /assistant 고객사 A 다음 미팅 잡아줘 같은 흐름을 만들 수 있다.

하지만 Slack은 편한 만큼 위험한 입구다. 채팅창은 문장이 짧고, 맥락이 생략되고, 실수로 채널을 잘못 고르는 일이 있다. 그래서 Slack 요청은 바로 실행보다 초안 생성과 승인 대기가 기본값이어야 한다.

처음에는 아래 세 단계가 안전하다.

Slack 요청을 받는다.
ERP 안에 “제안된 액션”으로 저장한다.
담당자가 승인하면 일정, 업무, 문서 생성으로 넘어간다.

특히 이메일, 세금계산서, 고객 개인정보, 결제, 계약서가 연결되면 자동 실행을 더 조심해야 한다. AI가 “아마 이 고객일 것”이라고 추정한 상태에서 실제 문서를 보내면 사고다. “아마”는 내부 메모에는 쓸 수 있지만, 외부 발송 버튼 앞에서는 멈춰야 한다.

권한과 로그는 첫 버전에 넣어야 한다

Claude Code settings 문서는 권한 설정, 환경변수, hooks, deny rules, 민감 파일 제외 같은 구성을 설명한다. 이 문서는 Claude Code 자체 설정에 관한 내용이지만, 사내 ERP에도 같은 원칙이 필요하다. 무엇을 허용하고, 무엇을 물어보고, 무엇을 막을지 정해야 한다.

내부 ERP 첫 버전에 꼭 들어가야 하는 최소 로그는 아래다.

로그	이유
누가 요청했는가	책임과 후속 확인
어떤 데이터가 입력됐는가	오입력 추적
AI가 무엇을 제안했는가	자동 판단 검토
사람이 무엇을 승인했는가	실행 책임 분리
외부 API가 무엇을 실행했는가	장애와 비용 추적

로그가 없으면 자동화는 편하지만 회고가 안 된다. 한 번은 괜찮다. 두 번부터는 팀이 불안해진다. 세 번부터는 “그냥 수동으로 하자”가 나온다. 자동화 프로젝트가 망하는 이유는 AI가 멍청해서만이 아니다. 증거가 없어서 신뢰를 잃는 경우가 많다.

권한도 처음부터 넓게 열 필요가 없다. 고객 데이터 조회, 미팅 요약 생성, 업무 초안 생성은 상대적으로 낮은 위험이다. 외부 이메일 발송, 세금계산서 발행, 결제 취소, 계약서 수정은 높은 위험이다. 높은 위험 액션은 approval queue를 거쳐야 한다.

작은 팀의 30일 도입 순서

첫 30일은 “완전한 AI ERP”보다 “하나의 반복 업무를 중앙 DB에 붙이는 것”이 목표여야 한다.

첫 주에는 객체를 정한다. 고객, 프로젝트, 미팅, 업무 중 어디부터 시작할지 고른다. 추천은 미팅 기록이다. 회의가 끝나면 요약, 결정사항, 할 일이 생기고, 이 데이터가 고객과 프로젝트에 자연스럽게 연결되기 때문이다.

둘째 주에는 입력 자동화를 붙인다. 녹음 파일, Google Drive 문서, Gmail 링크, 수동 입력 폼 중 하나만 고른다. Zapier나 API를 써도 좋지만, 처음부터 모든 입력을 연결하지 말자. 입력이 많아지면 오류도 많아진다.

셋째 주에는 Slack에서 조회만 가능하게 한다. “오늘 내 할 일”, “고객 A 최근 미팅”, “이번 주 미완료 업무”처럼 읽기 중심 명령을 만든다. 쓰기 명령은 나중이다. 읽기가 안정되면 팀이 시스템을 믿기 시작한다.

넷째 주에는 승인 대기 액션을 붙인다. Slack 요청으로 업무 초안을 만들고, 웹 화면에서 사람이 승인하게 한다. 이때부터 AI가 단순 요약기가 아니라 운영 보조자가 된다. 단, 최종 실행은 사람이 닫는다.

실수 TOP 7

첫 번째 실수는 “AI 네이티브”를 도구 구독 목록으로 착각하는 것이다. ChatGPT, Claude, Gemini, Zapier를 모두 쓰는 회사가 AI 네이티브인 건 아니다. 데이터와 액션이 연결되어야 한다.

두 번째 실수는 노션을 버리면 바로 ERP가 된다고 생각하는 것이다. 노션의 한계가 생겼다면 원인은 도구가 아니라 데이터 모델일 수 있다. 맞춤 ERP도 객체 정의가 흐리면 같은 문제가 반복된다.

세 번째 실수는 Slack 명령을 바로 실행 버튼으로 만드는 것이다. 채팅은 편하지만 오입력과 권한 실수가 쉽다. 초반에는 조회와 초안 생성까지만 맡기는 편이 안전하다.

네 번째 실수는 세금계산서와 결제를 빨리 자동화하는 것이다. 이 영역은 금액, 날짜, 상대방 정보, 발행 책임이 모두 엮인다. 사람 승인, 감사 로그, 롤백 절차 없이 자동 실행하면 작은 실수가 큰 설명회가 된다.

다섯 번째 실수는 AI가 만든 요약을 원본처럼 취급하는 것이다. 미팅 녹취, 이메일, 결제 알림, 세금계산서 원문 링크는 남겨야 한다. 요약은 편한 뷰이고, 원본은 증거다.

여섯 번째 실수는 운영자가 한 명뿐인 시스템을 만드는 것이다. 만든 사람이 휴가 가면 멈추는 자동화는 자동화가 아니라 개인기다. 최소한 실행 방법, 장애 대응, 권한 회수 방법은 문서로 남겨야 한다.

일곱 번째 실수는 첫 버전에 너무 많은 기능을 넣는 것이다. ERP라는 말에 속으면 안 된다. 첫 버전은 미팅 기록 자동 정리, 고객 후속 액션, 업무 배정 하나만 잘해도 충분하다.

따라 하기 체크리스트

작은 팀이 이 사례를 따라 한다면 아래 질문부터 답해야 한다.

우리 회사의 핵심 업무 객체 3개는 무엇인가?
각 객체의 원본 데이터는 어디서 들어오는가?
AI가 제안만 하고 사람이 승인해야 하는 액션은 무엇인가?
Slack에서 조회만 허용할 명령은 무엇인가?
외부 발송, 결제, 세금, 계약 관련 액션은 어떻게 막을 것인가?
모든 자동화 결과에 원본 링크와 실행 로그가 남는가?

이 질문에 답이 없으면 Claude Code를 켜도 일단 멈추는 편이 낫다. 코드는 금방 나온다. 하지만 운영 기준 없는 코드는 회사 안에서 오래 버티기 어렵다.

내가 이 사례에서 가져갈 핵심은 하나다. AI 네이티브는 “AI에게 일을 시킨다”가 아니라 “AI가 일할 수 있게 회사 데이터를 정리한다”다. 순서가 바뀌면 멋진 챗봇은 생겨도 운영 시스템은 잘 안 생긴다.

FAQ

AI 네이티브 컴퍼니는 AI 툴을 많이 쓰는 회사인가?

아니다. AI 툴 사용량보다 업무 데이터와 실행 흐름이 연결되어 있는지가 더 중요하다. 고객, 프로젝트, 미팅, 매출, 업무 같은 객체가 연결되고 AI가 다음 액션을 제안하거나 일부 실행할 수 있어야 한다.

Claude Code로 사내 ERP를 바로 만들어도 되나?

작은 프로토타입은 가능하다. 다만 실제 운영에 쓰려면 권한, 로그, 개인정보, 백업, 롤백, 외부 API 실행 기준을 먼저 정해야 한다. Claude Code는 구현을 빠르게 도울 수 있지만 운영 책임을 대신 지지는 않는다.

노션 대신 맞춤 ERP를 만들 기준은 무엇인가?

관계형 데이터가 많아지고, 조회 속도와 모바일 사용성, 권한, 자동화 로그가 중요해질 때 검토할 수 있다. 단순 문서와 가벼운 DB 수준이면 노션을 유지하면서 입력 규칙을 정리하는 것이 더 싸다.

Slack에서 자연어로 업무를 처리하면 위험하지 않나?

위험할 수 있다. 그래서 초반에는 조회와 초안 생성부터 시작하고, 일정 등록, 이메일 발송, 세금계산서 발행 같은 실행은 승인 대기를 거치는 편이 안전하다.

첫 자동화 대상으로 무엇이 좋은가?

미팅 기록 정리가 좋다. 원본, 요약, 결정사항, 할 일이 자연스럽게 생기고 고객이나 프로젝트와 연결하기 쉽다. 결제와 세금 자동화는 로그와 승인 구조가 잡힌 뒤에 붙이는 편이 낫다.

AI 네이티브 컴퍼니 구축 사례 2026 – Claude Code로 사내 ERP 만들 때 먼저 볼 체크리스트